Membangun layanan dengan ketersediaan tinggi (HA) menggunakan Persistent Disk regional

Persistent Disk Regional adalah opsi penyimpanan yang dapat Anda gunakan untuk menerapkan layanan ketersediaan tinggi (HA) di Compute Engine. Persistent Disk Regional secara sinkron mereplikasi data antara dua zona di region yang sama dan memastikan HA untuk data disk hingga satu kegagalan zona.

Dokumen ini menjelaskan cara menggunakan Persistent Disk regional untuk membangun layanan dengan ketersediaan tinggi (HA).

Membangun layanan ketersediaan tinggi dengan Persistent Disk regional

Bagian ini menjelaskan cara membangun layanan dengan ketersediaan tinggi (HA) dengan Persistent Disk regional.

Pertimbangan desain

Sebelum mulai mendesain layanan dengan ketersediaan tinggi (HA), pahami karakteristik aplikasi, sistem file, dan sistem operasi. Karakteristik ini adalah dasar desain dan dapat mengesampingkan berbagai pendekatan. Misalnya, jika aplikasi tidak mendukung replikasi tingkat aplikasi, beberapa opsi desain yang terkait tidak akan berlaku.

Demikian pula, jika aplikasi, sistem file, atau sistem operasi tidak toleran terhadap error, penggunaan persistent disk regional atau bahkan snapshot persistent disk zonal mungkin tidak dapat dilakukan. Toleransi error didefinisikan sebagai kemampuan untuk pulih dari penghentian tiba-tiba tanpa kehilangan atau merusak data yang sudah di-commit ke persistent disk sebelum error.

Pertimbangkan hal-hal berikut saat mendesain untuk ketersediaan tinggi:

Pengaruh penggunaan persistent disk regional atau solusi lain terhadap performa penulisan aplikasi dan disk.
Batas waktu pemulihan layanan. Pahami seberapa cepat layanan Anda harus pulih dari pemadaman layanan di zona tertentu dan persyaratan SLA.
Biaya untuk membangun arsitektur layanan yang tangguh dan andal.

Dari segi biaya, opsi berikut adalah untuk replikasi aplikasi sinkron dan asinkron:

Gunakan dua instance database dan VM. Dalam hal ini, item berikut menentukan total biaya:
- Biaya instance VM
- Biaya persistent disk
- Biaya mempertahankan replikasi aplikasi
Gunakan VM tunggal dengan persistent disk regional. Untuk mencapai ketersediaan tinggi dengan persistent disk regional, gunakan instance VM dan komponen persistent disk yang sama, tetapi sertakan juga persistent disk regional. Persistent disk regional memiliki biaya per byte dua kali lipat dibandingkan persistent disk zona karena persistent disk ini direplikasi dalam dua zona.

Namun, penggunaan persistent disk regional dapat mengurangi biaya pemeliharaan karena data secara otomatis direplikasi ke dua replika tanpa perlu mempertahankan replikasi aplikasi.
Jangan memulai VM kedua hingga failover diperlukan. Anda dapat mengurangi biaya host lebih besar lagi dengan memulai VM pencadangan hanya sesuai permintaan selama failover, bukan mempertahankan VM sebagai hot standby.

Bandingkan biaya, performa, dan ketahanan

Tabel berikut menyoroti kompromi dalam biaya, performa, dan ketahanan untuk berbagai arsitektur layanan.

Arsitektur layanan dengan ketersediaan tinggi (HA)	Snapshot persistent disk zonal	Tingkat aplikasi sinkron	Tingkat aplikasi asinkron	Solusi HA menggunakan persistent disk regional
Melindungi dari aplikasi, VM, kegagalan zona¹
Mitigasi terhadap kerusakan aplikasi (Contoh: intoleransi error aplikasi)		²	²
Biaya	$	$$ Dua instance database atau VM yang berjalan, penyiapan dan pemeliharaan replikasi aplikasi, dan jaringan lintas zona.	$$ Dua instance database atau VM yang berjalan, penyiapan dan pemeliharaan replikasi aplikasi, dan jaringan lintas zona.	$1,5x - $$ Biayanya sama dengan replikasi aplikasi jika Anda menggunakan hot standby. Anda dapat memperoleh biaya yang lebih rendah dengan menjalankan VM cadangan sesuai permintaan selama failover. Jaringan lintas zona antar-replika persistent disk regional tidak dikenai biaya.
Performa Aplikasi	Tanpa efek	Kompromi antara performa aplikasi dengan replikasi sinkron	Tanpa efek	Tidak ada efek untuk sebagian besar aplikasi
Cocok untuk aplikasi dengan persyaratan RPO rendah (Toleransi sangat rendah terhadap kehilangan data)	Kehilangan data bergantung pada kapan snapshot diambil	Tidak ada kehilangan data³	Kehilangan data karena replikasi bersifat asinkron	Tidak ada kehilangan data
Waktu pemulihan penyimpanan sejak bencana⁴	O(menit)	O(detik)	O(detik)	O(detik)—untuk memasang disk secara paksa ke instance VM standby

¹ Penggunaan persistent disk atau snapshot regional tidaklah cukup untuk melindungi dari dan mengurangi kegagalan serta kerusakan. Aplikasi, sistem file, dan mungkin komponen software lainnya harus konsisten dengan error atau menggunakan semacam quiescing.

² Replikasi beberapa aplikasi memberikan mitigasi terhadap beberapa kerusakan aplikasi. Misalnya, kerusakan aplikasi utama MySQL tidak menyebabkan instance VM replikanya juga rusak. Tinjau dokumentasi aplikasi untuk mengetahui detailnya.

³ Kehilangan data berarti hilangnya data yang tidak dapat dipulihkan yang dikirim ke penyimpanan persisten. Semua data yang tidak di-commit akan tetap hilang.

⁴ Performa failover tidak mencakup pemeriksaan sistem file serta pemulihan dan pemuatan aplikasi setelah failover.

Membuat layanan database dengan ketersediaan tinggi (HA) menggunakan persistent disk regional

Bagian ini membahas konsep tingkat tinggi dalam membangun solusi HA untuk layanan database stateful (MySQL, Postgres, dll.) menggunakan persistent disk regional dan Compute Engine.

Jika ada pemadaman layanan secara luas di Google Cloud, misalnya, jika seluruh region menjadi tidak tersedia, aplikasi Anda mungkin tidak akan tersedia. Bergantung pada kebutuhan Anda, pertimbangkan teknik replikasi lintas-regional untuk ketersediaan yang lebih tinggi.

Konfigurasi HA database biasanya memiliki setidaknya dua instance VM. Sebaiknya instance VM ini adalah bagian dari satu atau beberapa grup instance terkelola:

Instance VM utama di zona utama
Instance VM standby di zona sekunder

Instance VM utama memiliki setidaknya dua persistent disk: boot disk dan persistent disk regional. Persistent disk regional berisi data database dan data lain yang dapat berubah dan harus dipertahankan di zona lain jika terjadi pemadaman.

Instance VM standby memerlukan boot disk terpisah agar dapat dipulihkan dari pemadaman terkait konfigurasi, yang dapat disebabkan oleh upgrade sistem operasi, misalnya. Anda tidak dapat memaksa pemasangan boot disk ke VM lain selama failover.

Instance VM utama dan standby dikonfigurasi untuk menggunakan load balancer dengan traffic yang diarahkan ke VM utama berdasarkan sinyal health check. Konfigurasi ini juga dikenal sebagai hot standby. Skenario pemulihan dari bencana untuk data menguraikan konfigurasi failover lainnya, yang mungkin lebih sesuai untuk skenario Anda.

Tantangan dengan replikasi database

Tabel berikut mencantumkan beberapa tantangan umum dalam menyiapkan dan mengelola replikasi sinkron atau semi-sinkron aplikasi (seperti MySQL) dan perbandingannya untuk memblokir replikasi dengan persistent disk regional.

Tantangan	Replikasi sinkron atau semi-sinkron aplikasi	Blokir replikasi dengan persistent disk regional
Mempertahankan replikasi stabil antara replika utama dan failover.	Ada sejumlah hal yang bisa terjadi dan menyebabkan instance VM keluar dari mode HA: Kesalahan konfigurasi parameter replikasi seperti sertifikat SSL tidak cocok atau ACL tidak ada di sisi utama. Pemuatan tinggi pada instance VM utama menyebabkan replika failover tidak dapat mengikutinya. Bug yang menyebabkan masalah replikasi seperti masalah aplikasi, kesalahan konfigurasi OS, atau kegagalan Docker. Kegagalan infrastruktur, seperti pertentangan CPU, VM frozen, atau gangguan jaringan perantara.	Kegagalan penyimpanan ditangani oleh persistent disk regional. Hal ini terjadi secara transparan pada aplikasi, kecuali kemungkinan fluktuasi performa disk. Harus ada health check yang ditentukan pengguna untuk menemukan masalah aplikasi atau VM dan memicu failover.
Waktu failover menyeluruh lebih lama dari yang diinginkan.	Waktu yang dibutuhkan untuk operasi failover tidak memiliki batas atas. Menunggu semua transaksi untuk di-replay (langkah 2 di atas) dapat memakan waktu yang lama, bergantung pada skema dan beban pada database.	Persistent disk regional menyediakan replikasi sinkron, sehingga waktu failover dibatasi oleh jumlah latensi berikut: Pembuatan VM sekunder, kecuali jika sudah ada instance VM hot standby yang tersedia. Memaksa pemasangan persistent disk regional. Inisialisasi aplikasi.
Split-brain	Untuk menghindari split-brain, kedua pendekatan ini memerlukan ketentuan untuk memastikan bahwa hanya ada satu pendekatan utama dalam satu waktu.

Health check

Health check yang digunakan oleh load balancer diterapkan oleh agen health check. Agen health check memiliki dua tujuan:

Agen health check berada di dalam VM utama dan sekunder untuk memantau instance VM dan berkomunikasi dengan load balancer untuk mengarahkan traffic. Fungsi ini berfungsi paling optimal jika dikonfigurasi dengan grup instance.
Agen health check menyinkronkan dengan bidang kontrol regional khusus aplikasi dan membuat keputusan failover berdasarkan perilaku bidang kontrol. Bidang kontrol harus berada di zona yang berbeda dari instance VM yang kondisinya dipantau.

Agen health check itu sendiri harus bersifat fault tolerant. Misalnya, perhatikan bahwa, pada gambar berikutnya, bidang kontrol dipisahkan dari instance VM utama yang berada di zona us-central1-a, sedangkan VM standby berada di zona us-central1-f.

Peran agen health check di
VM.

Peran agen health check dalam instance VM utama dan standby.

Langkah selanjutnya

Pelajari cara membuat dan mengelola volume Persistent Disk regional.
Pelajari cara membangun aplikasi web yang skalabel dan tangguh di Google Cloud.
Tinjau panduan perencanaan pemulihan dari bencana.