Bagikan melalui

Mendesain kluster vSAN yang direntangkan

Dalam artikel ini, pelajari cara merancang kluster vSAN yang direntangkan untuk cloud privat Azure VMware Solution.

Latar belakang

Infrastruktur global Azure dipecah menjadi Wilayah. Setiap wilayah mendukung layanan untuk geografi tertentu. Dalam setiap wilayah, Azure membangun pulau infrastruktur yang terisolasi dan berlebihan yang disebut zona ketersediaan (AZ). AZ bertindak sebagai batas dalam manajemen sumber daya. Komputasi dan sumber daya lain yang tersedia untuk AZ terbatas dan dapat habis oleh permintaan pelanggan. AZ dibangun agar tangguh secara independen, yang berarti kegagalan dalam satu AZ tidak memengaruhi AZ lainnya.

Dengan Azure VMware Solution, host ESXi yang disebarkan dalam kluster vSphere standar secara tradisional berada dalam satu Zona Ketersediaan Azure (AZ) dan dilindungi oleh ketersediaan tinggi (HA) vSphere. Namun, ini tidak melindungi beban kerja dari kegagalan Azure AZ. Untuk melindungi dari kegagalan AZ, satu kluster vSAN dapat diaktifkan untuk mencakup dua zona ketersediaan terpisah, yang disebut kluster vSAN diperluas.

Kluster yang direntangkan memungkinkan konfigurasi Fault Domain vSAN di dua AZ untuk memberi tahu vCenter Server bahwa host berada di setiap Zona Ketersediaan (AZ). Setiap domain kesalahan dinamai sesuai dengan AZ yang berada di dalamnya untuk meningkatkan kejelasan. Saat Anda memperluas kluster vSAN di dua Zona Ketersediaan (AZ) dalam suatu wilayah, jika salah satu AZ mengalami gangguan, hal itu dianggap sebagai peristiwa vSphere HA dan mesin virtual akan dimulai ulang di AZ yang lain.

Manfaat kluster yang direntangkan:

  • Meningkatkan ketersediaan aplikasi.
  • Berikan kemampuan tujuan titik pemulihan nol (RPO) untuk aplikasi perusahaan tanpa perlu mendesain ulang, atau menyebarkan solusi pemulihan bencana (DR) yang mahal.
  • Cloud privat dengan kluster yang direntangkan dirancang untuk memberikan ketersediaan 99,99% karena ketahanannya terhadap kegagalan AZ.
  • Memungkinkan pelanggan untuk fokus pada persyaratan dan fitur aplikasi inti, alih-alih ketersediaan infrastruktur.

Untuk melindungi dari skenario split-brain dan membantu mengukur kesehatan situs, Saksi vSAN terkelola dibuat di AZ ketiga. Dengan salinan data di setiap AZ, vSphere HA berusaha memulihkan dari kegagalan apa pun hanya dengan memulai ulang mesin virtual.

Diagram berikut menggambarkan kluster vSAN yang direntangkan di dua AZ.

Diagram menunjukkan kluster terkelola vSAN yang direntangkan yang dibuat di Zona Ketersediaan ketiga dengan data yang disalin ke ketiganya.

Diagram berikut menggambarkan arus normal lalu lintas jaringan dalam kluster vSAN yang direntangkan di dua AZ.

Diagram menunjukkan lalu lintas jaringan NSX VMware untuk kluster vSAN terkelola yang direntangkan.

Singkatnya, kluster yang direntangkan menyederhanakan kebutuhan perlindungan dengan menyediakan kontrol dan kemampuan tepercaya yang sama selain skala dan fleksibilitas infrastruktur Azure.

Penting untuk dipahami bahwa cloud privat kluster yang direntangkan hanya menawarkan lapisan ketahanan tambahan, dan mereka tidak mengatasi semua skenario kegagalan. Misalnya, cloud privat kluster yang direntangkan:

  • Jangan lindungi dari kegagalan tingkat wilayah dalam Azure atau skenario kehilangan data yang disebabkan oleh masalah aplikasi atau kebijakan penyimpanan yang direncanakan dengan buruk.
  • Memberikan perlindungan terhadap kegagalan zona tunggal tetapi tidak dirancang untuk memberikan perlindungan terhadap kegagalan ganda atau progresif. Misalnya:

    • Meskipun berbagai lapisan redundansi terintegrasi dalam fabric, apabila kegagalan antar-AZ terjadi sehingga mempartisi situs sekunder, vSphere HA mulai mematikan mesin virtual beban kerja (VM) di situs sekunder.

      Diagram berikut menunjukkan skenario pemartisian situs sekunder.

      Diagram menunjukkan ketersediaan tinggi vSphere mematikan komputer virtual beban kerja di situs sekunder.

    • Jika partisi situs sekunder berujung pada kegagalan situs utama, atau mengakibatkan kegagalan partisi penuh, vSphere HA akan mencoba merestart VM beban kerja di situs sekunder. Jika vSphere HA mencoba menghidupkan ulang VM beban kerja di situs sekunder, VM beban kerja akan diletakkan dalam status tidak stabil.

      Diagram berikut menunjukkan kegagalan situs pilihan dan skenario pemartisian jaringan lengkap.

      Diagram menunjukkan ketersediaan tinggi vSphere yang mencoba memulai ulang komputer virtual beban kerja di situs sekunder ketika kegagalan situs yang disukai terjadi.

      Diagram menunjukkan ketersediaan tinggi vSphere yang mencoba menghidupkan ulang komputer virtual beban kerja di situs sekunder ketika isolasi jaringan lengkap terjadi.

      Diagram berikut menunjukkan arus lalu lintas jaringan dalam kluster vSAN yang tersebar selama kegagalan total situs.

      Diagram menunjukkan aliran lalu lintas VMware NSX untuk kluster rentang vSAN terkelola selama kegagalan lokasi lengkap.

Perlu dicatat bahwa jenis kegagalan ini, meskipun jarang, berada di luar cakupan perlindungan yang ditawarkan oleh cloud privat kluster yang direntangkan. Karena jenis kegagalan langka tersebut, solusi kluster yang direntangkan harus dianggap sebagai solusi ketersediaan tinggi multi-AZ, yang bergantung pada vSphere HA. Penting bagi Anda untuk memahami bahwa solusi kluster yang direntangkan tidak dimaksudkan untuk menggantikan strategi Pemulihan Bencana multi-wilayah yang komprehensif yang dapat digunakan untuk memastikan ketersediaan aplikasi. Alasannya adalah karena solusi Pemulihan Bencana biasanya memiliki sarana manajemen dan kontrol terpisah di wilayah Azure yang terpisah. Kluster yang direntangkan Azure VMware Solution memiliki satu bidang manajemen dan kontrol yang direntangkan di dua zona ketersediaan dalam wilayah Azure yang sama. Misalnya, satu vCenter Server, satu kluster NSX Manager, satu pasangan VM NSX Edge.

Ketersediaan wilayah kluster yang direntangkan

Kluster yang direntangkan Azure VMware Solution tersedia di wilayah berikut:

  • UK South (di AV36, dan AV36P)
  • Eropa Barat (di AV36, dan AV36P)
  • Jerman Barat Tengah (pada AV36, dan AV36P)
  • Australia Timur (pada AV36P)
  • East US (di AV36P)

Kebijakan penyimpanan didukung

Kebijakan SPBM berikut didukung dengan PFTT "Dual Site Mirroring" dan SFTT "RAID 1 (Mirroring)" diaktifkan sebagai kebijakan default untuk cluster:

  • Pengaturan toleransi bencana untuk situs (PFTT):
    • Cerminan situs ganda
    • Tidak ada - simpan data di pilihan
    • Tidak - simpan data pada pengaturan yang tidak dipilih
  • Kegagalan dalam mentoleransi secara lokal (SFTT)
    • 1 kegagalan – RAID 1 (Pencerminan)
    • 1 kegagalan – RAID 5 (Pengkodian penghapusan), memerlukan minimal empat host di setiap AZ
    • 2 kegagalan – RAID 1 (Cermin)
    • 2 kegagalan – RAID 6 (Pengodean penghapusan), memerlukan minimal enam host di setiap AZ
    • 3 kegagalan – RAID 1 (Mirroring)

FAQ

Apakah ada wilayah lain yang direncanakan?

Saat ini, ada lima wilayah yang didukung untuk kluster yang direntangkan.

Jenis SLA apa yang disediakan Azure VMware Solution dengan kluster yang direntangkan?

Cloud privat yang dibuat dengan kluster yang direntangkan vSAN dirancang untuk menawarkan komitmen ketersediaan infrastruktur 99,99% ketika kondisi berikut ada:

Apakah saya bisa memilih zona ketersediaan tempat cloud privat disebarkan?

Tidak. Kluster yang diperluas dibuat di antara dua zona ketersediaan, sementara zona ketiga digunakan untuk menyebarkan simpul pengamat. Karena semua zona secara efektif digunakan untuk menyebarkan lingkungan kluster yang direntangkan, pilihan tidak diberikan kepada pelanggan. Sebagai gantinya, pelanggan memilih untuk menyebarkan host di beberapa AZ pada saat pembuatan cloud privat.

Apa saja batasan yang harus saya waspadai?

  • Setelah cloud privat dibuat dengan kluster yang direntangkan, cloud tersebut tidak dapat diubah ke cloud privat kluster standar. Demikian pula, klaster cloud privat standar tidak dapat diubah ke klaster cloud privat yang diperluas setelah pembuatan.
  • Skala keluar dan skala masuk dari kluster terentang hanya dapat terjadi secara berpasangan. Minimal enam node dan maksimum 16 node didukung di lingkungan kluster yang diperluas. Untuk informasi selengkapnya, lihat Batas, kuota, dan batasan langganan dan layanan Azure.
  • Mesin virtual beban kerja pelanggan dinyalakan ulang dengan prioritas vSphere HA sedang. VM manajemen memiliki prioritas hidupkan ulang tertinggi.
  • Solusinya bergantung pada vSphere HA dan vSAN untuk menghidupkan ulang dan replikasi. Tujuan waktu pemulihan (RTO) ditentukan oleh jumlah waktu yang dibutuhkan vSphere HA untuk memulai ulang VM pada AZ yang bertahan setelah kegagalan satu AZ.
  • Saat ini tidak didukung di lingkungan kluster yang diperluas:
    • Fitur yang baru dirilis seperti IP Publik di level NSX Edge dan penyimpanan eksternal, seperti penyimpanan data ANF.
    • Addon pemulihan bencana seperti VMware SRM, Zerto, dan JetStream.
  • Buka dukungan tiket dari portal Azure untuk skenario berikut (pastikan untuk memilih Kluster yang Direntangkan sebagai Tipe Masalah):
    • Hubungkan cloud privat ke kluster cloud privat yang diperluas.
    • Hubungkan dua kluster cloud privat yang diperluas dalam satu wilayah.

Latensi seperti apa yang harus saya harapkan antara zona ketersediaan (AZ)?

Kluster vSAN yang direntangkan beroperasi dalam waktu pulang pergi (RTT) 5 milidetik dan bandwidth 10 Gb/s atau lebih di antara Zona Ketersediaan (AZ) yang menghosting VM beban kerja. Penyebaran kluster yang direntangkan Azure VMware Solution mengikuti prinsip panduan tersebut. Pertimbangkan informasi tersebut saat menyebarkan aplikasi (dengan SFTT pencerminan situs ganda, yang menggunakan penulisan sinkron) yang memiliki persyaratan latensi yang ketat.

Dapatkah saya mencampur kluster yang direntangkan dan standar di cloud privat saya?

Tidak. Campuran kluster yang direntangkan dan standar tidak didukung dalam cloud privat yang sama. Lingkungan kluster yang direntangkan atau standar dipilih saat Anda membuat cloud privat. Setelah cloud privat dibuat dengan kluster yang direntangkan, asumsinya adalah bahwa semua kluster yang dibuat dalam cloud privat tersebut direntangkan secara alami.

Berapa biaya solusinya?

Pelanggan dikenakan biaya berdasarkan jumlah simpul yang disebarkan dalam cloud privat.

Apakah saya dikenakan biaya untuk simpul saksi dan lalu lintas antar Availability Zone (AZ)?

Tidak. Pelanggan tidak melihat biaya untuk node saksi dan lalu lintas antar-AZ. Simpul saksi sepenuhnya dikelola layanan, dan Azure VMware Solution menyediakan manajemen siklus hidup yang diperlukan dari simpul saksi. Karena seluruh solusi dikelola sebagai layanan, pelanggan hanya perlu mengidentifikasi kebijakan SPBM yang sesuai untuk ditetapkan pada mesin virtual beban kerja. Sisanya dikelola melalui Microsoft.