Google Distributed Cloud dirancang untuk membatasi cakupan kegagalan dan memprioritaskan fungsi yang penting untuk kelangsungan bisnis. Dokumen ini menjelaskan dampak kegagalan terhadap fungsionalitas cluster Anda. Informasi ini dapat membantu Anda memprioritaskan area yang perlu dipecahkan masalahnya jika Anda mengalami masalah.
Fungsi inti Google Distributed Cloud mencakup kategori berikut:
- Menjalankan workload: Workload yang ada dapat terus berjalan. Hal ini adalah pertimbangan paling penting untuk menjaga kelangsungan bisnis. Meskipun cluster Anda mengalami masalah, workload yang ada dapat terus berjalan tanpa gangguan.
- Mengelola workload: Anda dapat membuat, mengupdate, dan menghapus workload. Ini adalah pertimbangan terpenting kedua untuk menskalakan workload saat traffic meningkat, meskipun cluster mengalami masalah.
- Mengelola cluster pengguna: Anda dapat mengelola node, memperbarui, mengupgrade, dan menghapus cluster pengguna. Hal ini kurang penting daripada pertimbangan siklus proses aplikasi. Jika ada kapasitas yang tersedia di node yang ada, ketidakmampuan untuk mengubah cluster pengguna tidak memengaruhi workload pengguna.
- Mengelola cluster admin: Anda dapat mengupdate dan mengupgrade cluster admin. Hal ini adalah pertimbangan yang paling tidak penting karena cluster admin tidak menghosting workload pengguna apa pun. Jika cluster admin Anda mengalami masalah, workload aplikasi Anda akan terus berjalan tanpa gangguan.
Bagian berikut menggunakan kategori fungsi inti ini untuk menjelaskan dampak jenis skenario kegagalan tertentu.
Mode kegagalan
Jenis kegagalan berikut dapat memengaruhi performa cluster Google Distributed Cloud.
Kegagalan host ESXi
Dalam skenario kegagalan ini, host ESXi yang menjalankan instance virtual machine (VM) yang menghosting node Kubernetes mungkin berhenti berfungsi atau terpisah dari jaringan.
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Mengelola cluster admin | |
|---|---|---|---|---|
| Gangguan | Kemungkinan gangguan dan pemulihan otomatis | Kemungkinan gangguan dan pemulihan otomatis | Gangguan dan pemulihan otomatis | Gangguan dan pemulihan otomatis |
| Explanation | Pod yang berjalan di VM yang dihosting oleh host yang gagal akan terganggu, dan otomatis dijadwalkan ulang ke VM lain yang responsif. Jika aplikasi pengguna memiliki kapasitas workload cadangan dan tersebar di beberapa node, gangguan tidak dapat diamati oleh klien yang menerapkan percobaan ulang. |
Jika kegagalan host memengaruhi VM bidang kontrol di cluster pengguna non-HA atau lebih dari satu VM bidang kontrol di cluster pengguna HA, akan terjadi gangguan. | Jika kegagalan host memengaruhi VM bidang kontrol atau VM pekerja di admin cluster, akan terjadi gangguan. | Jika kegagalan host memengaruhi VM bidang kontrol di cluster admin, akan terjadi gangguan. |
| Pemulihan | vSphere HA otomatis memulai ulang VM di host yang responsif. | vSphere HA otomatis memulai ulang VM di host yang responsif. | vSphere HA otomatis memulai ulang VM di host yang responsif. | vSphere HA otomatis memulai ulang VM di host yang responsif. |
| Pencegahan | Deploy workload dengan cara HA untuk meminimalkan kemungkinan gangguan. | Gunakan cluster pengguna HA untuk meminimalkan kemungkinan gangguan. | — | — |
Kegagalan VM
Dalam skenario kegagalan ini, VM mungkin dihapus secara tidak terduga, boot disk mungkin rusak, atau VM mungkin disusupi karena masalah sistem operasi.
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Mengelola cluster admin | |
|---|---|---|---|---|
| Gangguan | Kemungkinan gangguan dan pemulihan otomatis | Kemungkinan gangguan dan pemulihan otomatis | Gangguan dan pemulihan otomatis/manual | Gangguan dan pemulihan manual |
| Explanation | Pod yang berjalan di VM worker yang gagal akan terganggu, dan Pod tersebut akan otomatis dijadwalkan ulang ke VM lain yang berfungsi dengan baik oleh Kubernetes. Jika aplikasi pengguna memiliki kapasitas workload cadangan dan tersebar di beberapa node, gangguan tidak dapat diamati oleh klien yang menerapkan percobaan ulang. |
Jika VM bidang kontrol di cluster pengguna non-HA atau lebih dari satu VM bidang kontrol di cluster pengguna HA gagal, 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. |
| Pemulihan | VM yang gagal akan dipulihkan secara otomatis jika perbaikan otomatis node diaktifkan di cluster pengguna. | VM yang gagal akan dipulihkan secara otomatis jika perbaikan otomatis node diaktifkan di cluster admin. | VM pekerja yang gagal di cluster admin akan dipulihkan secara otomatis 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. |
| Pencegahan | Deploy workload dengan cara HA untuk meminimalkan kemungkinan gangguan. | Gunakan cluster pengguna HA untuk meminimalkan kemungkinan gangguan. | — | — |
Kegagalan penyimpanan
Dalam skenario kegagalan ini, konten dalam file VMDK mungkin rusak karena penonaktifan VM yang tidak benar, atau kegagalan datastore dapat menyebabkan data etcd dan PersistentVolumes (PV) hilang.
Kegagalan etcd
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Mengelola cluster admin | |
|---|---|---|---|---|
| Gangguan | Tidak ada gangguan | Kemungkinan gangguan dan Pemulihan manual | Gangguan dan pemulihan manual | Gangguan dan pemulihan manual |
| Explanation | — | Jika penyimpanan etcd di cluster pengguna non-HA atau lebih dari satu replika etcd di cluster pengguna HA gagal, akan terjadi gangguan. | Jika penyimpanan etcd di cluster pengguna non-HA atau lebih dari satu replika etcd di cluster pengguna HA gagal, akan terjadi gangguan. Jika replika etcd di cluster admin gagal, akan terjadi gangguan. |
Jika replika etcd di cluster admin gagal, akan terjadi gangguan. |
| Pencegahan | — | Google Distributed Cloud menyediakan proses manual untuk memulihkan dari kegagalan. | Google Distributed Cloud menyediakan proses manual untuk memulihkan diri dari kegagalan. | Google Distributed Cloud menyediakan proses manual untuk memulihkan diri dari kegagalan. |
Kegagalan PV aplikasi pengguna
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Mengelola cluster admin | |
|---|---|---|---|---|
| Gangguan | Kemungkinan gangguan | Tidak ada gangguan | Tidak ada gangguan | Tidak ada gangguan |
| Explanation | Workload yang menggunakan PV yang gagal akan terpengaruh. Deploy workload dengan cara HA untuk meminimalkan kemungkinan gangguan. |
— | — | — |
Kegagalan load balancer
Dalam skenario kegagalan ini, kegagalan load balancer dapat memengaruhi beban kerja pengguna
yang mengekspos Layanan jenis LoadBalancer.
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Mengelola cluster admin | |
|---|---|---|---|---|
| Gangguan dan pemulihan manual | ||||
| Explanation |
Akan ada gangguan selama beberapa detik hingga load balancer standby memulihkan koneksi VIP panel 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 dengan bertambahnya jumlah node load balancer. Dengan kurang dari 5 node, gangguan berada dalam waktu 10 detik. |
|||
| Pemulihan | HA Seesaw otomatis mendeteksi kegagalan dan melakukan failover untuk menggunakan instance cadangan. Google Distributed Cloud menyediakan proses manual untuk memulihkan diri dari kegagalan Seesaw. |
|||
Memulihkan cluster yang rusak
Bagian berikut menjelaskan cara memulihkan cluster yang rusak.
Pemulihan dari kegagalan host ESXi
Google Distributed Cloud mengandalkan vSphere HA untuk memberikan pemulihan dari kegagalan host ESXi. vSphere HA dapat terus memantau host ESXi dan otomatis memulai ulang VM di host lain jika diperlukan. Hal ini transparan bagi pengguna Google Distributed Cloud.
Pemulihan dari kegagalan VM
Kegagalan VM dapat mencakup hal berikut:
Penghapusan VM yang tidak terduga.
Kerusakan boot disk VM, seperti boot disk yang menjadi hanya baca karena log spam jurnal.
Kegagalan booting VM karena masalah penyiapan jaringan atau disk dengan performa rendah, seperti VM tidak dapat melakukan booting karena alamat IP tidak dapat dialokasikan untuk VM tersebut.
Kerusakan sistem file overlay Docker.
Hilangnya VM bidang kontrol admin karena kegagalan upgrade.
Masalah sistem operasi.
Google Distributed Cloud 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 khusus karena tidak dikelola oleh cluster Kubernetes, dan ketersediaannya tidak memengaruhi kelangsungan bisnis. Untuk pemulihan kegagalan VM bidang kontrol admin, hubungi Cloud Customer Care.
Pemulihan dari kegagalan penyimpanan
Beberapa kegagalan penyimpanan dapat dimitigasi oleh vSphere HA dan vSAN tanpa memengaruhi Google Distributed Cloud. Namun, kegagalan penyimpanan tertentu mungkin muncul dari tingkat vSphere yang menyebabkan kerusakan atau kehilangan data pada berbagai komponen Google Distributed Cloud.
Informasi stateful cluster dan beban kerja pengguna disimpan di tempat berikut:
- etcd: Setiap cluster (cluster admin dan cluster pengguna) memiliki database etcd yang menyimpan status (objek Kubernetes) cluster.
- PersistentVolumes: Digunakan oleh komponen sistem dan workload 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 andal untuk mendeteksi kerusakan data. Anda perlu melihat log Pod etcd jika Anda mencurigai bahwa data etcd rusak atau hilang.
Pod etcd yang tertunda/error/berulang tidak selalu berarti data etcd rusak atau hilang. Hal ini dapat disebabkan oleh error pada VM yang menghosting Pod etcd. Anda harus melakukan pemulihan etcd berikut hanya untuk kerusakan atau kehilangan data.
Untuk 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 membawa cluster ke status sebelumnya. Jika cadangan diambil sebelum aplikasi di-deploy dan kemudian cadangan tersebut digunakan untuk memulihkan cluster, aplikasi yang baru di-deploy tidak akan berjalan di cluster yang dipulihkan. Misalnya, jika Anda menggunakan snapshot etcd cluster admin yang diambil sebelum membuat cluster pengguna, bidang kontrol cluster pengguna akan dihapus dari cluster admin yang dipulihkan. Oleh karena itu, sebaiknya Anda mencadangkan cluster setelah setiap operasi cluster penting.
Kegagalan kehilangan atau kerusakan 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 node yang rusak dan kuorum etcd masih ada. Skenario ini dapat terjadi di cluster HA, tempat data salah satu replika etcd rusak atau hilang. Masalah dapat diperbaiki tanpa kehilangan data dengan mengganti replika etcd yang gagal dengan replika baru dalam status bersih. Untuk mengetahui informasi selengkapnya, lihat Mengganti replika etcd yang gagal.
Dua node dari cluster etcd tiga node (cluster pengguna HA) rusak permanen karena kerusakan atau kehilangan data. Kuorum hilang, sehingga 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 satu node (cluster admin atau cluster pengguna non-HA) rusak secara permanen karena kerusakan atau kehilangan data. Kuorum hilang, jadi Anda harus membuat cluster baru dari cadangan. Untuk mengetahui informasi selengkapnya, lihat Memulihkan cluster pengguna dari cadangan (non-HA).
Pemulihan dari kerusakan atau kehilangan PV aplikasi pengguna
Anda dapat menggunakan solusi penyimpanan partner tertentu untuk mencadangkan dan memulihkan PersistentVolume aplikasi pengguna. Untuk mengetahui daftar partner penyimpanan yang telah memenuhi syarat untuk Google Distributed Cloud, lihat Partner Penyimpanan yang Siap untuk GDC.
Pemulihan dari kegagalan load balancer
Untuk load balancer Seesaw yang dibundel, Anda dapat memulihkan dari kegagalan dengan membuat ulang load balancer. Untuk membuat ulang load balancer, upgrade Seesaw ke versi yang sama seperti yang ditunjukkan dalam dokumentasi versi 1.16 Mengupgrade load balancer untuk cluster admin.
Jika terjadi kegagalan load balancer cluster admin, bidang kontrol mungkin tidak dapat dijangkau. Jalankan 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 ini menggunakan node cluster sebagai load balancer. Perbaikan node otomatis tidak dipicu pada masalah load balancer. Anda dapat mengikuti proses manual untuk memperbaiki node.
Langkah berikutnya
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.
Anda juga dapat melihat bagian Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang sumber dukungan, termasuk yang berikut:
- Persyaratan untuk membuka kasus dukungan.
- Alat untuk membantu Anda memecahkan masalah, seperti log dan metrik.
- Komponen yang didukung, versi, dan fitur Google Distributed Cloud untuk VMware (khusus software).