Halaman ini menjelaskan opsi ketersediaan tinggi (HA) di GKE di VMware, cara menyiapkan komponen GKE tertentu di VMware untuk HA, dan cara melakukan pemulihan dari bencana.
Fungsi inti
GKE di VMware mencakup cluster admin dan satu atau beberapa cluster pengguna.
Cluster admin mengelola siklus proses cluster pengguna, termasuk pembuatan, update, upgrade, dan penghapusan cluster pengguna. Dalam cluster admin, master admin mengelola node pekerja admin, yang mencakup master pengguna (node yang menjalankan bidang kontrol cluster pengguna terkelola) dan node add-on (node yang menjalankan komponen add-on yang mendukung fungsi cluster admin).
Untuk setiap cluster pengguna, cluster admin memiliki satu node non-HA atau tiga node HA yang menjalankan bidang kontrol. Bidang kontrol meliputi server Kubernetes API, penjadwal Kubernetes, pengelola pengontrol Kubernetes, dan beberapa pengontrol penting untuk cluster pengguna.
Ketersediaan bidang kontrol cluster pengguna sangat penting untuk operasi workload seperti pembuatan workload, peningkatan dan penurunan skala, serta penghentian. Dengan kata lain, pemadaman bidang kontrol tidak mengganggu beban kerja yang sedang berjalan, tetapi beban kerja yang ada akan kehilangan kemampuan pengelolaan dari server Kubernetes API jika bidang kontrolnya tidak ada.
Workload dan layanan dalam container di-deploy di node pekerja cluster pengguna. Setiap node pekerja tidak boleh menjadi faktor penting untuk ketersediaan aplikasi selama aplikasi di-deploy dengan pod redundan yang dijadwalkan di beberapa node pekerja.
GKE di VMware didesain untuk memastikan bahwa kegagalan diisolasi ke area fungsional sebanyak mungkin dan untuk memprioritaskan fungsi yang penting bagi kelangsungan bisnis.
Fungsi inti GKE di VMware mencakup kategori berikut:
Siklus proses aplikasi
Beban kerja yang ada dapat berjalan secara berkelanjutan. Ini adalah fungsi terpenting untuk memastikan kelangsungan bisnis.
Anda dapat membuat, memperbarui, dan menghapus beban kerja. Ini adalah fungsi terpenting kedua karena GKE di VMware perlu menskalakan beban kerja saat traffic meningkat.
Siklus proses cluster pengguna
Anda dapat menambahkan, memperbarui, mengupgrade, dan menghapus cluster pengguna. Hal ini kurang penting karena ketidakmampuan untuk memodifikasi cluster pengguna tidak memengaruhi beban kerja pengguna.
Siklus proses cluster Admin
Anda dapat mengupdate dan mengupgrade cluster admin. Ini adalah yang paling tidak penting karena cluster admin tidak menghosting beban kerja pengguna apa pun.
Mode kegagalan
Jenis kegagalan berikut dapat memengaruhi performa GKE di cluster VMware.
Kegagalan host ESXi
Host ESXi yang menjalankan instance virtual machine (VM) yang menghosting node Kubernetes dapat berhenti berfungsi atau menjadi jaringan terpartisi.
| Workload yang ada | Membuat, mengupdate, dan menghapus workload | Siklus proses cluster pengguna | Siklus proses cluster Admin |
|---|---|---|---|
| Kemungkinan gangguan + pemulihan otomatis |
Kemungkinan gangguan + pemulihan otomatis |
Gangguan + pemulihan otomatis |
Gangguan + pemulihan otomatis |
Pod yang berjalan pada VM yang dihosting oleh host yang gagal akan mengalami gangguan, dan otomatis dijadwalkan ulang ke VM responsif lainnya. Jika aplikasi pengguna memiliki kapasitas workload cadangan dan tersebar di beberapa node, gangguan tidak dapat diamati oleh klien yang mengimplementasikan percobaan ulang. |
Jika kegagalan host memengaruhi VM bidang kontrol di cluster pengguna non-HA atau lebih dari satu VM bidang kontrol di cluster pengguna dengan ketersediaan tinggi (HA), maka akan terjadi gangguan. | Gangguan akan terjadi jika kegagalan host memengaruhi VM bidang kontrol atau VM pekerja di cluster admin. | Jika kegagalan host memengaruhi VM bidang kontrol di cluster admin, terjadi gangguan. |
| HA vSphere secara otomatis memulai ulang VM pada host yang responsif. | HA vSphere secara otomatis memulai ulang VM pada host yang responsif. | HA vSphere secara otomatis memulai ulang VM pada host yang responsif. | HA vSphere secara otomatis memulai ulang VM pada host yang responsif. |
| Men-deploy workload dengan cara HA untuk meminimalkan kemungkinan gangguan. | Gunakan cluster pengguna dengan ketersediaan tinggi (HA) untuk meminimalkan kemungkinan gangguan. |
Kegagalan VM
VM mungkin dihapus secara tidak terduga, atau boot disk mungkin rusak. Selain itu, VM mungkin disusupi karena masalah sistem operasi.
| Workload yang ada | Membuat, mengupdate, dan menghapus workload | Siklus proses cluster pengguna | Siklus proses cluster Admin |
|---|---|---|---|
| Kemungkinan gangguan + pemulihan otomatis |
Kemungkinan gangguan + pemulihan otomatis |
Gangguan + pemulihan otomatis/manual |
Gangguan + pemulihan manual |
Pod yang berjalan pada VM pekerja yang gagal akan terganggu, dan Pod tersebut akan otomatis dijadwalkan ulang ke VM responsif lainnya oleh Kubernetes. Jika aplikasi pengguna memiliki kapasitas workload cadangan dan tersebar di beberapa node, gangguan tidak dapat diamati oleh klien yang mengimplementasikan percobaan ulang. |
Jika VM bidang kontrol dalam cluster pengguna non-HA atau lebih dari satu VM bidang kontrol di cluster pengguna dengan ketersediaan tinggi (HA), akan terjadi gangguan. | Jika VM bidang kontrol atau VM pekerja di cluster admin gagal, akan terjadi gangguan. | Jika VM bidang kontrol di cluster admin gagal, akan terjadi gangguan. |
| VM yang gagal akan otomatis dipulihkan jika perbaikan otomatis node diaktifkan di cluster pengguna. | VM yang gagal akan otomatis dipulihkan jika perbaikan otomatis node diaktifkan di cluster admin. | VM pekerja yang gagal di cluster admin akan otomatis dipulihkan jika perbaikan otomatis node diaktifkan di cluster admin. Untuk memulihkan VM bidang kontrol cluster admin, lihat Memperbaiki VM bidang kontrol cluster admin. |
Untuk memulihkan VM bidang kontrol cluster admin, lihat Memperbaiki VM bidang kontrol cluster admin. |
| Men-deploy workload dengan cara HA untuk meminimalkan kemungkinan gangguan. | Gunakan cluster pengguna dengan ketersediaan tinggi (HA) untuk meminimalkan kemungkinan gangguan. |
Kegagalan penyimpanan
Konten dalam file VMDK mungkin rusak karena penghentian VM secara halus, atau kegagalan datastore dapat menyebabkan data etcd dan PersistentVolumes (PV) hilang.
kegagalan etcd
| Workload yang ada | Membuat, mengupdate, dan menghapus workload | Siklus proses cluster pengguna | Siklus proses cluster Admin |
|---|---|---|---|
| Tidak ada gangguan | Kemungkinan gangguan + Pemulihan manual |
Gangguan + Pemulihan manual |
Gangguan + Pemulihan manual |
| Jika penyimpanan etcd di cluster pengguna non-HA atau lebih dari satu replika etcd di cluster pengguna dengan ketersediaan tinggi (HA) gagal, akan terjadi gangguan. | Jika penyimpanan etcd di cluster pengguna non-HA atau lebih dari satu replika etcd di cluster pengguna dengan ketersediaan tinggi (HA) gagal, akan terjadi gangguan. Jika replika etcd dalam cluster admin gagal, akan terjadi gangguan. |
Jika replika etcd dalam cluster admin gagal, akan terjadi gangguan. | |
| GKE di VMware menyediakan proses manual untuk pulih dari kegagalan. | GKE di VMware menyediakan proses manual untuk pulih dari kegagalan. | GKE di VMware menyediakan proses manual untuk pulih dari kegagalan. |
Kegagalan PV aplikasi pengguna
| Workload yang ada | Membuat, mengupdate, dan menghapus workload | Siklus proses cluster pengguna | Siklus proses cluster Admin |
|---|---|---|---|
| Kemungkinan gangguan | Tidak ada gangguan | Tidak ada gangguan | Tidak ada gangguan |
Beban kerja yang menggunakan PV yang gagal akan terpengaruh. Deploy workload dengan cara HA untuk meminimalkan kemungkinan gangguan. |
Kegagalan load balancer
Kegagalan load balancer dapat memengaruhi beban kerja pengguna yang mengekspos Layanan jenis LoadBalancer.
| Workload yang ada | Membuat, mengupdate, dan menghapus workload | Siklus proses cluster pengguna | Siklus proses cluster Admin |
|---|---|---|---|
| Gangguan + Pemulihan manual |
|||
|
Terjadi gangguan selama beberapa detik hingga load balancer standby memulihkan koneksi VIP bidang kontrol admin. Gangguan layanan mungkin berlangsung hingga 2 detik saat menggunakan Seesaw, dan hingga 300 detik saat menggunakan F5. Durasi gangguan failover MetalLB bertambah seiring peningkatan jumlah node load balancer. Dengan kurang dari 5 node, gangguan terjadi dalam waktu 10 detik. Seesaw HA secara otomatis mendeteksi kegagalan dan beralih untuk menggunakan instance cadangan. GKE on VMware menyediakan proses manual untuk pulih dari kegagalan Seesaw. |
|||
Mengaktifkan ketersediaan tinggi
vSphere dan GKE di VMware menyediakan sejumlah fitur yang berkontribusi terhadap ketersediaan tinggi (HA).
HA vSphere dan vMotion
Sebaiknya aktifkan dua fitur berikut di cluster vCenter yang menghosting GKE Anda di cluster VMware:
Fitur ini meningkatkan ketersediaan dan pemulihan jika host ESXi gagal.
vCenter HA menggunakan beberapa host ESXi yang dikonfigurasi sebagai cluster untuk memberikan pemulihan
yang cepat dari pemadaman dan HA yang hemat biaya untuk aplikasi
yang berjalan di virtual machine. Sebaiknya sediakan cluster vCenter
Anda dengan host tambahan dan
aktifkan Pemantauan Host HA vSphere
dengan Host Failure Response yang ditetapkan ke Restart VMs. VM Anda kemudian dapat
secara otomatis dimulai ulang di host lain yang tersedia jika terjadi kegagalan host ESXi.
vMotion memungkinkan migrasi langsung VM tanpa periode nonaktif dari satu host ESXi ke host ESXi lainnya. Untuk pemeliharaan host terencana, Anda dapat menggunakan migrasi langsung vMotion untuk menghindari periode nonaktif aplikasi sepenuhnya dan memastikan kelangsungan bisnis.
Cluster admin
GKE di VMware mendukung pembuatan cluster admin dengan ketersediaan tinggi (HA). Cluster admin dengan ketersediaan tinggi (HA) memiliki tiga node yang menjalankan komponen bidang kontrol. Untuk mengetahui informasi tentang persyaratan dan batasan, lihat Cluster admin ketersediaan tinggi.
Perhatikan bahwa ketidaktersediaan bidang kontrol cluster admin tidak memengaruhi fungsi cluster pengguna yang sudah ada atau beban kerja apa pun yang berjalan di cluster pengguna.
Ada dua node add-on di cluster admin. Jika salah satunya tidak aktif, server yang lain
masih dapat melayani operasi cluster admin. Untuk redundansi,
GKE di VMware menyebarkan Layanan add-on yang penting, seperti kube-dns,
di kedua node add-on.
Jika Anda menetapkan antiAffinityGroups.enabled ke true di file konfigurasi
cluster admin, GKE di VMware akan otomatis membuat aturan anti-afinitas
vSphere DRS
untuk node add-on, yang menyebabkan node tersebut tersebar di
dua host fisik untuk HA.
Cluster pengguna
Anda dapat mengaktifkan HA untuk cluster pengguna dengan menetapkan masterNode.replicas ke 3 dalam
file konfigurasi cluster pengguna. Jika cluster pengguna mengaktifkan Controlplane V2 (direkomendasikan), 3 node bidang kontrol akan berjalan di cluster pengguna.
Cluster pengguna kubeception dengan ketersediaan tinggi (HA) lama
menjalankan tiga node bidang kontrol di cluster admin. Setiap node bidang kontrol
juga menjalankan replika etcd. Cluster pengguna terus berfungsi selama ada satu bidang kontrol yang berjalan dan kuorum etcd. Kuorum etcd mengharuskan dua dari tiga replika etcd berfungsi.
Jika Anda menetapkan antiAffinityGroups.enabled ke true dalam file konfigurasi
cluster admin, GKE di VMware akan otomatis membuat aturan anti-afinitas
DRS vSphere untuk tiga node yang menjalankan bidang kontrol cluster pengguna.
Hal ini menyebabkan VM tersebut tersebar di tiga {i>host<i} fisik.
GKE di VMware juga membuat aturan anti-afinitas DRS vSphere DRS untuk node pekerja di cluster pengguna Anda, yang menyebabkan node tersebut tersebar di setidaknya tiga host fisik. Beberapa aturan anti-afinitas DRS digunakan per kumpulan node cluster pengguna berdasarkan jumlah node. Hal ini memastikan bahwa node pekerja dapat menemukan host untuk dijalankan, meskipun jumlah host kurang dari jumlah VM di kumpulan node cluster pengguna. Sebaiknya sertakan host fisik tambahan di cluster vCenter Anda. Selain itu, konfigurasikan DRS agar sepenuhnya otomatis sehingga jika host menjadi tidak tersedia, DRS dapat otomatis memulai ulang VM di host lain yang tersedia tanpa melanggar aturan anti-afinitas VM.
GKE di VMware mempertahankan label node khusus,
onprem.gke.io/failure-domain-name, yang nilainya ditetapkan ke nama host ESXi
yang mendasarinya. Aplikasi pengguna yang menginginkan ketersediaan tinggi dapat menyiapkan
aturan podAntiAffinity dengan label ini sebagai topologyKey untuk memastikan bahwa
Pod aplikasinya tersebar di berbagai VM dan juga di host fisik.
Anda juga dapat mengonfigurasi beberapa kumpulan node untuk sebuah cluster pengguna dengan datastore yang berbeda dan label node khusus. Demikian pula, Anda dapat menyiapkan aturan podAntiAffinity dengan label node khusus tersebut sebagai topologyKey untuk mencapai ketersediaan yang lebih tinggi setelah terjadi kegagalan datastore.
Agar memiliki HA untuk workload pengguna, pastikan cluster pengguna memiliki replika dalam jumlah
yang cukup dalam nodePools.replicas, yang memastikan jumlah node pekerja cluster
pengguna yang diinginkan dalam kondisi berjalan.
Anda dapat menggunakan datastore terpisah untuk cluster admin dan cluster pengguna untuk mengisolasi kegagalannya.
Load balancer
Ada dua jenis load balancer yang dapat Anda gunakan untuk ketersediaan tinggi.
Load balancer MetalLB yang dipaketkan
Untuk
load balancer MetalLB paket,
Anda mencapai HA dengan memiliki lebih dari satu node dengan enableLoadBalancer: true.
MetalLB mendistribusikan layanan ke node load balancer, tetapi untuk satu layanan, hanya ada satu node pemimpin yang menangani semua traffic untuk layanan tersebut.
Selama upgrade cluster, akan ada periode nonaktif saat node load balancer diupgrade. Durasi gangguan failover MetalLB bertambah seiring peningkatan jumlah node load balancer. Dengan kurang dari 5 node, gangguan terjadi dalam waktu 10 detik.
Load balancer Seesaw Gabungan
Untuk
load balancer Seesaw paket,
Anda dapat mengaktifkan ketersediaan tinggi (HA) dengan menetapkan
loadBalancer.seesaw.enableHA ke true dalam file konfigurasi cluster.
Anda juga harus mengaktifkan kombinasi pembelajaran MAC, transmisi palsu, dan mode {i>promiscuous<i} pada grup port load balancer.
Dengan ketersediaan tinggi (HA), dua load balancer disiapkan dalam mode pasif aktif. Jika load balancer yang aktif mengalami masalah, traffic akan beralih ke load balancer pasif.
Selama proses upgrade load balancer, ada beberapa periode nonaktif. Jika HA diaktifkan untuk load balancer, periode nonaktif maksimum adalah dua detik.
Load balancer BESAR F5 F5 terintegrasi
Platform F5 BIG-IP menyediakan berbagai Layanan untuk membantu Anda meningkatkan keamanan, ketersediaan, dan performa aplikasi Anda. Untuk GKE di VMware, BIG-IP menyediakan akses eksternal dan Layanan load balancing L3/4.
Untuk informasi lebih lanjut, lihat Ketersediaan tinggi IP BESAR.
Memulihkan cluster yang rusak
Bagian berikut menjelaskan cara memulihkan cluster yang rusak.
Pemulihan dari kegagalan host ESXi
GKE on VMware mengandalkan vSphere HA untuk menyediakan pemulihan dari kegagalan host ESXi. vSphere HA dapat terus memantau host ESXi dan otomatis memulai ulang VM di host lain jika diperlukan. Ini bersifat transparan terhadap GKE pada pengguna VMware.
Pemulihan dari kegagalan VM
Kegagalan VM dapat mencakup hal berikut:
Penghapusan VM yang tidak terduga.
Kerusakan boot disk VM; misalnya, boot disk menjadi hanya-baca karena log jurnal spam.
Kegagalan booting VM karena masalah penyiapan jaringan atau disk berperforma rendah; misalnya, VM tidak dapat melakukan booting karena alamat IP tidak dapat dialokasikan ke sana karena beberapa alasan.
Kerusakan sistem file overlay Docker.
Hilangnya VM bidang kontrol admin karena kegagalan upgrade.
Masalah sistem operasi.
Kegagalan VM yang dibahas di bagian ini tidak mencakup kerusakan atau kehilangan data pada disk data PV atau etcd yang terpasang ke VM. Untuk itu, lihat Pemulihan dari kegagalan penyimpanan.
GKE di VMware menyediakan mekanisme pemulihan otomatis untuk node add-on admin, bidang kontrol pengguna, dan node pengguna. Fitur perbaikan otomatis node ini dapat diaktifkan per cluster admin dan cluster pengguna.
VM bidang kontrol admin bersifat spesial karena tidak dikelola oleh cluster Kubernetes, dan ketersediaannya tidak memengaruhi kelangsungan bisnis. Untuk pemulihan kegagalan VM bidang kontrol admin, hubungi Dukungan Google.
Pemulihan dari kegagalan penyimpanan
Beberapa kegagalan penyimpanan dapat dimitigasi oleh HA dan vSAN vSphere tanpa memengaruhi GKE di VMware. Namun, kegagalan penyimpanan tertentu mungkin muncul dari level vSphere, yang menyebabkan kerusakan atau kehilangan data di berbagai GKE di komponen VMware.
Informasi stateful dari cluster dan beban kerja pengguna disimpan di tempat-tempat berikut:
etcd
Setiap cluster (cluster admin dan cluster pengguna) memiliki database etcd yang menyimpan status (objek Kubernetes) cluster tersebut.
PersistentVolumes
Digunakan oleh komponen sistem dan beban kerja pengguna.
Pemulihan dari kerusakan atau kehilangan data etcd
etcd adalah database yang digunakan oleh Kubernetes untuk menyimpan semua status cluster, termasuk manifes aplikasi pengguna. Operasi siklus proses aplikasi akan berhenti berfungsi jika database etcd cluster pengguna rusak atau hilang. Operasi siklus proses cluster pengguna akan berhenti berfungsi jika database etcd cluster admin rusak atau hilang.
etcd tidak menyediakan mekanisme bawaan yang dapat diandalkan untuk mendeteksi kerusakan data. Anda perlu melihat log Pod etcd jika mencurigai bahwa data etcd rusak atau hilang.
Pod etcd yang tertunda/error/error-looping tidak selalu berarti bahwa data etcd rusak atau hilang. Hal ini dapat disebabkan oleh error pada VM yang menghosting Pod dll. Anda harus melakukan pemulihan etcd berikut hanya untuk kerusakan atau kehilangan data.
Agar dapat memulihkan (ke status cluster terbaru) dari kerusakan atau kehilangan data etcd, data etcd harus dicadangkan setelah operasi siklus proses apa pun di cluster (misalnya, membuat, memperbarui, atau mengupgrade). Untuk mencadangkan data etcd, lihat Mencadangkan cluster admin dan Mencadangkan cluster pengguna.
Memulihkan data etcd akan mengembalikan cluster ke status sebelumnya. Dengan kata lain, jika cadangan diambil sebelum aplikasi di-deploy, lalu cadangan tersebut digunakan untuk memulihkan cluster, aplikasi tidak akan berjalan di cluster yang dipulihkan. Misalnya, jika Anda menggunakan snapshot etcd dari cluster admin yang di-snapshot sebelum membuat cluster pengguna, cluster admin yang dipulihkan akan menghapus bidang kontrol cluster pengguna. Oleh karena itu, sebaiknya Anda mencadangkan cluster setelah setiap operasi cluster kritis.
Kegagalan kerusakan/kehilangan data etcd dapat terjadi dalam skenario berikut:
Satu node dari cluster etcd tiga node (cluster pengguna HA) rusak secara permanen karena kerusakan atau kehilangan data. Dalam hal ini, hanya satu {i>node<i} yang rusak dan kuorum etcd masih ada. Hal ini mungkin terjadi di cluster HA, dengan data salah satu replika etcd rusak atau hilang. Masalah ini dapat diperbaiki tanpa kehilangan data dengan mengganti replika etcd yang gagal dengan replika baru dalam status bersih. Untuk informasi selengkapnya, lihat Mengganti replika etcd yang gagal.
Dua node dari cluster etcd tiga node (cluster pengguna HA) rusak secara permanen karena kerusakan atau kehilangan data. Kuorum hilang, jadi mengganti replika etcd yang gagal dengan yang baru tidak akan membantu. Status cluster harus dipulihkan dari data cadangan. Untuk mengetahui informasi selengkapnya, lihat Memulihkan cluster pengguna dari cadangan (HA).
Cluster etcd node tunggal (cluster admin atau cluster pengguna non-HA) rusak secara permanen karena kerusakan atau kehilangan data. Kuorum hilang, jadi Anda harus membuat klaster baru dari cadangan. Untuk mengetahui informasi selengkapnya, lihat Memulihkan cluster pengguna dari cadangan (non-HA).
Pemulihan dari kerusakan atau kehilangan PV aplikasi pengguna
Pelanggan GKE di VMware dapat menggunakan solusi penyimpanan partner tertentu untuk mencadangkan dan memulihkan PersistentVolume aplikasi pengguna.
Untuk daftar partner penyimpanan yang telah memenuhi syarat untuk GKE di VMware, lihat Partner Penyimpanan Anthos Ready.
Pemulihan dari kegagalan load balancer
Untuk load balancer Seesaw yang dipaketkan, Anda dapat memulihkan diri dari kegagalan dengan membuat ulang load balancer. Untuk membuat ulang load balancer, upgrade Seesaw ke versi yang sama seperti yang ditunjukkan pada bagian Mengupgrade load balancer untuk cluster admin.
Dalam kasus kegagalan load balancer cluster admin, bidang kontrol mungkin berada di luar jangkauan. Akibatnya, Anda perlu menjalankan upgrade di VM bidang kontrol admin yang memiliki akses bidang kontrol.
Untuk load balancer terintegrasi (F5), hubungi Dukungan F5.
Untuk load balancer MetalLB yang dipaketkan, load balancer menggunakan node cluster sebagai load balancer. Perbaikan node otomatis tidak dipicu jika ada masalah load balancer. Anda dapat mengikuti proses manual untuk memperbaiki node.
Menggunakan beberapa cluster untuk pemulihan dari bencana (disaster recovery)
Men-deploy aplikasi dalam beberapa cluster di beberapa vCenter atau platform GKE Enterprise dapat memberikan ketersediaan global yang lebih tinggi dan membatasi radius ledakan selama pemadaman.
Penyiapan ini menggunakan cluster GKE Enterprise yang sudah ada di pusat data sekunder untuk pemulihan dari bencana, bukan menyiapkan cluster baru. Berikut adalah ringkasan umum untuk mencapainya:
Buat cluster admin dan cluster pengguna lain di pusat data sekunder. Dalam arsitektur multi-cluster ini, kami mewajibkan pengguna untuk memiliki dua cluster admin di setiap pusat data, dan setiap cluster admin menjalankan cluster pengguna.
Cluster pengguna sekunder memiliki jumlah worker node minimal (tiga) dan bersifat hot standby (selalu berjalan).
Deployment aplikasi dapat direplikasi di kedua vCenter menggunakan Config Sync, atau pendekatan yang lebih disukai adalah menggunakan toolchain DevOps (CI/CD, Spinnaker) aplikasi yang sudah ada.
Jika terjadi bencana, ukuran cluster pengguna dapat diubah sesuai jumlah node.
Selain itu, pengalihan DNS diperlukan untuk merutekan traffic antar-cluster ke pusat data sekunder.