Google Distributed Cloud dirancang untuk membatasi cakupan kegagalan dan memprioritaskan fungsi yang penting bagi kelangsungan bisnis. Dokumen ini menjelaskan pengaruh fungsi cluster Anda saat terjadi kegagalan. Informasi ini dapat membantu Anda memprioritaskan area untuk memecahkan masalah jika Anda mengalami masalah.
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.Fungsi inti Google Distributed Cloud mencakup kategori berikut:
- Menjalankan workload: Workload yang ada dapat terus berjalan. Ini adalah pertimbangan yang paling penting untuk mempertahankan kelangsungan bisnis. Meskipun cluster Anda mengalami masalah, workload yang ada mungkin akan terus berjalan tanpa gangguan.
- Mengelola workload: Anda dapat membuat, memperbarui, 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, mengupdate, 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 akan memengaruhi beban kerja 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, beban kerja 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 dapat berhenti berfungsi atau menjadi partisi 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 sehat. Jika aplikasi pengguna memiliki kapasitas beban kerja cadangan dan tersebar di beberapa node, gangguan tidak dapat diamati oleh klien yang menerapkan percobaan ulang. |
Jika kegagalan host memengaruhi VM panel kontrol di cluster pengguna non-HA atau lebih dari satu VM panel kontrol di cluster pengguna HA, akan terjadi gangguan. | Jika kegagalan host memengaruhi VM bidang kontrol atau VM pekerja di cluster admin, 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 sehat. | vSphere HA otomatis memulai ulang VM di host yang sehat. | vSphere HA otomatis memulai ulang VM di host yang sehat. | vSphere HA otomatis memulai ulang VM di host yang sehat. |
| 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, disk booting 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 pekerja 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 beban kerja 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 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 platform kontrol cluster admin, lihat Memperbaiki VM platform kontrol cluster admin. |
Untuk memulihkan VM platform kontrol cluster admin, lihat Memperbaiki VM platform 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 VM dimatikan secara tidak teratur, atau kegagalan datastore dapat menyebabkan data etcd dan PersistentVolumes (PV) hilang.
Kegagalan etcd
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Mengelola cluster admin | |
|---|---|---|---|---|
| Gangguan | Tanpa 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 diri dari kegagalan. | Google Distributed Cloud menyediakan proses manual untuk memulihkan dari kegagalan. | Google Distributed Cloud menyediakan proses manual untuk memulihkan dari kegagalan. |
Kegagalan PV aplikasi pengguna
| Menjalankan workload | Mengelola workload | Mengelola cluster pengguna | Mengelola cluster admin | |
|---|---|---|---|---|
| Gangguan | Kemungkinan gangguan | Tanpa gangguan | Tanpa gangguan | Tanpa 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 |
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 meningkat seiring bertambahnya jumlah node load balancer. Dengan kurang dari 5 node, gangguan terjadi dalam waktu 10 detik. |
|||
| Pemulihan | Seesaw HA otomatis mendeteksi kegagalan dan gagal menggunakan instance cadangan. Google Distributed Cloud menyediakan proses manual untuk memulihkan 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 menyediakan pemulihan dari kegagalan host ESXi. vSphere HA dapat terus memantau host ESXi dan otomatis memulai ulang VM di host lain jika diperlukan. Hal ini bersifat 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 jurnal spam.
Kegagalan booting VM karena masalah penyiapan jaringan atau disk berperforma rendah, seperti VM tersebut tidak dapat melakukan booting karena alamat IP tidak dapat dialokasikan ke 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 panel kontrol admin, hubungi Layanan Pelanggan Cloud.
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 mencurigai bahwa data etcd rusak atau hilang.
Pod etcd yang tertunda/error/looping error tidak selalu berarti data etcd rusak atau hilang. Hal ini mungkin disebabkan oleh error pada VM yang menghosting Pod etcd. Anda harus melakukan pemulihan etcd berikut hanya untuk kerusakan atau kehilangan data.
Agar dapat memulihkan (ke status cluster terbaru) dari kerusakan atau hilangnya 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. Jika pencadangan dilakukan sebelum aplikasi di-deploy, lalu pencadangan tersebut digunakan untuk memulihkan cluster, aplikasi yang baru di-deploy tidak akan berjalan di cluster yang dipulihkan. Misalnya, jika Anda menggunakan snapshot etcd dari cluster admin yang diambil snapshot-nya 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 penting.
Kegagalan kerusakan atau 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 node yang rusak dan kuorum etcd masih ada. Skenario ini mungkin terjadi di cluster HA, tempat 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 mengetahui 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, sehingga penggantian replika etcd yang gagal dengan replika baru tidak akan membantu. Status cluster harus dipulihkan dari data cadangan. Untuk 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 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 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 dipaketkan, 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 Anda.
Jika terjadi kegagalan load balancer cluster admin, bidang kontrol mungkin tidak dapat dijangkau. Jalankan upgrade di VM bidang kontrol admin tempat ada 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.