Ketersediaan tinggi dan pemulihan dari bencana (disaster recovery)

Halaman ini menjelaskan opsi ketersediaan tinggi di Google Distributed Cloud (software khusus) untuk VMware.

Fungsi inti

Arsitektur dengan cluster pengguna yang sangat tersedia
Arsitektur dengan cluster pengguna yang sangat tersedia (Klik untuk memperbesar)

Penginstalan khusus software untuk Google Distributed Cloud for VMware mencakup admin cluster dan satu atau beberapa cluster pengguna.

Cluster admin mengelola siklus proses cluster pengguna, termasuk pengguna pembuatan, pembaruan, upgrade, dan penghapusan cluster. Di cluster admin, admin master mengelola node pekerja admin, yang mencakup master pengguna (node yang berjalan bidang kontrol cluster pengguna terkelola) dan node add-on (node yang berjalan 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 mencakup Kubernetes API server Kubernetes, scheduler 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, workload yang ada kehilangan kemampuan pengelolaan dari Kubernetes API server ini jika bidang kontrolnya tidak ada.

Workload dan layanan dalam container di-deploy di pekerja cluster pengguna node. Setiap node pekerja tunggal tidak boleh terlalu penting untuk ketersediaan aplikasi selama aplikasi di-deploy dengan pod redundan yang dijadwalkan di beberapa worker node.

Mengaktifkan ketersediaan tinggi

vSphere dan Google Distributed Cloud menyediakan sejumlah fitur yang berkontribusi ke ketersediaan tinggi (HA).

vSphere HA dan vMotion

Sebaiknya aktifkan dua fitur berikut di cluster vCenter yang menghosting cluster Google Distributed Cloud Anda:

Fitur ini meningkatkan ketersediaan dan pemulihan jika host ESXi gagal.

vCenter HA menggunakan beberapa host ESXi yang dikonfigurasi sebagai cluster untuk memberikan pemulihan dari pemadaman layanan dan HA hemat biaya untuk aplikasi berjalan di virtual machine. Sebaiknya Anda menyediakan vCenter dengan host tambahan dan mengaktifkan Pemantauan Host HA vSphere dengan Host Failure Response ditetapkan ke Restart VMs. VM Anda kemudian dapat dimulai ulang secara otomatis pada {i>host<i} lain yang tersedia jika terjadi kegagalan {i>host<i} 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 periode nonaktif aplikasi sepenuhnya dan memastikan kelangsungan bisnis.

Cluster Admin

Google Distributed Cloud mendukung pembuatan admin dengan ketersediaan tinggi (HA) klaster. Cluster admin HA memiliki tiga node yang menjalankan komponen bidang kontrol. Untuk informasi tentang persyaratan dan batasan, lihat Cluster admin dengan ketersediaan tinggi.

Perhatikan bahwa ketidaktersediaan bidang kontrol cluster admin memengaruhi fungsi cluster pengguna yang ada atau workload apa pun yang berjalan pada pengguna klaster.

Ada dua node add-on di cluster admin. Jika yang satu turun, yang satunya lagi masih dapat melayani operasi cluster admin. Untuk redundansi, Google Distributed Cloud menyebarkan Layanan add-on penting, seperti kube-dns, di kedua node add-on.

Jika Anda menetapkan antiAffinityGroups.enabled ke true di cluster admin Google Distributed Cloud, secara otomatis membuat DRS vSphere aturan anti-afinitas untuk node add-on, yang menyebabkannya tersebar di dua {i>host<i} fisik untuk HA.

Cluster pengguna

Anda dapat mengaktifkan HA untuk cluster pengguna dengan menetapkan masterNode.replicas ke 3 di file konfigurasi cluster pengguna. Jika cluster pengguna memiliki Pesawat Kontrol V2 diaktifkan (direkomendasikan), 3 node bidang kontrol berjalan di cluster pengguna. Cluster pengguna kubeception dengan ketersediaan tinggi (HA) lama menjalankan tiga node bidang kontrol di cluster admin. Setiap bidang kontrol node juga menjalankan replika etcd. Cluster pengguna terus berfungsi selama ada satu bidang kontrol yang berjalan dan kuorum {i>etcd<i}. Dan seterusnya kuorum mengharuskan dua dari tiga replika dst berfungsi.

Jika Anda menetapkan antiAffinityGroups.enabled ke true di cluster admin Google Distributed Cloud akan otomatis membuat DRS vSphere aturan anti-afinitas untuk tiga node yang menjalankan bidang kontrol cluster pengguna. Hal ini menyebabkan VM tersebut tersebar di tiga host fisik.

Google Distributed Cloud juga membuat aturan anti-afinitas DRS vSphere untuk node pekerja di cluster pengguna Anda, yang menyebabkan node tersebut tersebar di setidaknya tiga {i>host<i} fisik. Beberapa aturan anti-afinitas DRS digunakan sesuai kumpulan node cluster pengguna berdasarkan jumlah node. Hal ini memastikan bahwa node pekerja dapat menemukan host untuk dijalankan, meskipun jumlah host lebih sedikit daripada jumlah VM di kumpulan node cluster pengguna. Sebaiknya Anda menyertakan {i>host<i} fisik tambahan di cluster vCenter Anda. Juga konfigurasikan DRS agar sepenuhnya otomatis sehingga jika {i>host<i} tidak tersedia, DRS dapat secara otomatis memulai ulang VM pada {i>host<i} lain yang tersedia tanpa melanggar VM aturan anti-afinitas.

Google Distributed Cloud memiliki label node khusus, onprem.gke.io/failure-domain-name, yang nilainya ditetapkan ke ESXi yang mendasarinya nama {i>host<i}. Aplikasi pengguna yang menginginkan ketersediaan tinggi dapat disiapkan podAntiAffinity aturan dengan label ini sebagai topologyKey untuk memastikan bahwa pod aplikasi mereka tersebar di berbagai VM serta host fisik. Anda juga dapat mengonfigurasi beberapa kumpulan node untuk cluster pengguna dengan {i>datastores<i} dan label {i>node<i} khusus. Anda juga dapat menyiapkan podAntiAffinity aturan dengan label node khusus tersebut sebagai topologyKey untuk mencapai ketersediaan setelah kegagalan datastore.

Agar memiliki HA untuk workload pengguna, pastikan cluster pengguna memiliki jumlah yang memadai replika di bawah nodePools.replicas, yang memastikan jumlah pengguna yang diinginkan node pekerja cluster 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 dipaket

Untuk load balancer MetalLB yang dipaketkan, Anda mencapai HA dengan memiliki lebih dari satu node dengan enableLoadBalancer: true.

MetalLB mendistribusikan layanan ke node load balancer, tetapi untuk satu hanya ada satu {i>leader<i} {i>leader<i} yang menangani semua lalu lintas untuk layanan tersebut.

Selama upgrade cluster, terjadi periode nonaktif saat node load balancer diupgrade. Durasi gangguan failover MetalLB bertambah seiring dengan jumlah node load balancer meningkat. Dengan kurang dari 5 node, gangguan memerlukan waktu 10 detik.

Load balancer Seesaw paket

Untuk load balancer Seesaw paket, Anda dapat mengaktifkan HA dengan menetapkan loadBalancer.seesaw.enableHA hingga true dalam file konfigurasi cluster. Anda juga harus mengaktifkan kombinasi pembelajaran MAC, transmisi palsu, dan mode {i>promiscuous<i} pada grup porta load balancer.

Dengan HA, dua load balancer disiapkan dalam mode pasif aktif. Jika status load balancer mengalami masalah, yaitu traffic gagal beralih ke load balancer pasif.

Selama upgrade load balancer, terjadi periode nonaktif. Jika HA adalah untuk load balancer, periode nonaktif maksimumnya adalah dua detik.

Load balancer F5 BIG-IP terintegrasi

Platform F5 BIG-IP menyediakan berbagai Layanan untuk membantu Anda meningkatkan keamanan, ketersediaan, dan performa aplikasi. Untuk Google Distributed Cloud, BIG-IP menyediakan akses eksternal dan Layanan load balancing L3/4.

Menggunakan beberapa cluster untuk pemulihan dari bencana

Men-deploy aplikasi dalam banyak cluster di beberapa vCenter atau Platform GKE Enterprise dapat menyediakan 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 bencana, alih-alih menyiapkan cluster baru. Berikut adalah ringkasan umum untuk mencapai hal ini:

  • Buat cluster admin dan cluster pengguna lain di pusat data sekunder. Dalam arsitektur multi-cluster ini, kita mengharuskan pengguna memiliki dua admin di setiap pusat data, dan setiap cluster admin menjalankan satu cluster pengguna.

  • Cluster pengguna sekunder memiliki jumlah worker node minimal (tiga) dan mode hot standby (selalu aktif).

  • Deployment aplikasi dapat direplikasi di kedua vCenter dengan menggunakan Sinkronisasi Konfigurasi, atau pendekatan yang direkomendasikan adalah menggunakan toolchain DevOps (CI/CD, Spinnaker) aplikasi yang sudah ada.

  • Jika terjadi bencana, ukuran cluster pengguna dapat diubah ke node.

  • Selain itu, pengalihan DNS diperlukan untuk merutekan lalu lintas antara cluster ke pusat data sekunder.