Arsitektur referensi ini paling cocok untuk kasus penggunaan berikut:
- Anda memerlukan perlindungan regional selain perlindungan per zona untuk aplikasi penting Anda.
Arsitektur referensi ketersediaan ini menggabungkan replika baca dalam region untuk HA dan di seluruh region untuk DR. Deployment multi-region ini melindungi dari gangguan signifikan, termasuk pemadaman listrik yang meluas dan bencana alam berskala besar.
Pertimbangan arsitektur referensi ketersediaan
Saat Anda mengevaluasi arsitektur referensi ketersediaan ini, pertimbangkan faktor-faktor berikut:
- Latensi dan bandwidth jaringan dalam region dan di seluruh region
- Penempatan geografis database dan server aplikasi
- Strategi untuk memindahkan workload hanya baca ke replika
- Men-deploy ketersediaan tinggi di region DR jarak jauh
Load balancing hanya baca mungkin diperlukan, terutama jika Anda menggunakan server aplikasi regional, sehingga permintaan diteruskan ke database terdekat untuk respons tercepat. Untuk mengetahui informasi selengkapnya, lihat Meminta pemilihan rute ke Load Balancer Aplikasi klasik multi-region.
Pemantauan tambahan mungkin diperlukan untuk replikasi lintas region guna memastikan bahwa jeda replikasi tidak mulai meningkat karena beban transaksi atau kapasitas jaringan.
Untuk memastikan DR Anda berhasil, pastikan Anda melakukan pengujian DR secara menyeluruh. Penting untuk menguji fungsi dan throughput aplikasi jika ada koneksi jaringan latensi tinggi antara server aplikasi dan database.
Arsitektur HA dalam region dan DR lintas region
Gambar 1 menunjukkan konfigurasi HA dan DR yang disarankan dengan tiga database standby replika baca di tiga zona ketersediaan dan dua region.
Gambar 1. AlloyDB Omni dengan opsi ketersediaan tinggi lintas region dan pencadangan.
Seperti yang diilustrasikan Gambar 1, replikasi streaming sinkron ke replika lokal (dalam region yang sama) memberikan ketersediaan tinggi, sementara replikasi streaming asinkron ke replika jarak jauh yang terpisah secara geografis memberikan perlindungan pemulihan dari bencana regional. Dalam seluruh konfigurasi, hanya instance utama yang dapat melakukan operasi baca-tulis, sementara replika lainnya dapat melayani kueri baca.
Konfigurasi replikasi dari replika utama ke replika dalam region dalam mode sinkron, sementara replikasi ke replika lintas region harus dikonfigurasi dalam mode asinkron untuk menghindari latensi yang memengaruhi performa penulisan utama. Jika terjadi kegagalan regional, penyiapan ini dapat menyebabkan RPO selain nol. Namun, penyiapan ini memungkinkan RTO yang lebih cepat jika terjadi kegagalan. Hal ini karena database utama tidak perlu menunggu konfirmasi dari database standby jarak jauh sebelum melakukan transaksi.
Anda dapat membuat cadangan lintas region tambahan dari database replika baca, sehingga menambahkan redundansi pada cadangan yang diambil dari database utama.
Pencadangan replika baca
Saat Anda menggunakan deployment Kubernetes, deployment sekunder di region alternatif akan otomatis disiapkan dengan cadangan tambahan. Jika Anda menggunakan deployment non-Kubernetes, Anda dapat memilih untuk men-deploy cadangan sesuai kebutuhan bisnis Anda. Pertimbangkan hal berikut:
- Jika cadangan jarak jauh Anda mungkin rentan terhadap kegagalan region, Anda perlu memulai cadangan tambahan di region alternatif.
- Jika Anda memerlukan redundansi cadangan, Anda harus membuat cadangan replika baca regional.
Lokasi replika baca untuk mendukung ketersediaan multi-zona
Dalam deployment non-Kubernetes, Anda dapat memilih replika baca tertentu untuk mengambil peran utama jika terjadi kegagalan utama. Operator Kubernetes AlloyDB Omni secara otomatis menangani penempatan node di zona dan node tempat pod harus di-deploy. Beberapa opsi konfigurasi yang memengaruhi penempatan, seperti afinitas dan toleransi pod, tersedia dalam konfigurasi database yang digunakan untuk men-deploy dengan operator AlloyDB Omni.
Migrasi dari arsitektur khusus HA ke arsitektur HA dan DR
Untuk deployment non-Kubernetes, Anda harus membuat standby baru di region baru dan menambahkan konfigurasi ini ke konfigurasi cluster Patroni. Untuk deployment Kubernetes, Anda perlu membangun deployment Kubernetes regional baru, yang disebut cluster database sekunder, dan mengaktifkan replikasi lintas pusat data.
Penerapan
Saat memilih arsitektur referensi ketersediaan, perhatikan manfaat, batasan, dan opsi berikut.
Manfaat
- Melindungi dari kegagalan zona dan instance
- Melindungi dari kegagalan regional
- RTO berkurang saat database mengalami kegagalan regional
Batasan
- Anda dapat mengurangi RPO untuk pemulihan regional dengan replikasi sinkron, tetapi pendekatan ini menyebabkan latensi tambahan untuk performa transaksi. Untuk DR dan replikasi region jarak jauh, sebaiknya Anda hanya menggunakan replikasi asinkron.
- Mengonfigurasi streaming WAL PostgreSQL dalam mode sinkron menawarkan nol kehilangan data (
RPO=0
) selama operasi normal atau failover umum. Namun, pendekatan ini tidak melindungi dari kehilangan data dalam situasi kesalahan ganda tertentu, seperti saat semua instance standby hilang atau tidak dapat dijangkau dari instance utama, dan hal ini segera diikuti dengan memulai ulang instance utama.
Opsi perlindungan data
- Arsitektur Ketersediaan Standar untuk opsi pencadangan dan pemulihan.
- Arsitektur Ketersediaan yang Ditingkatkan untuk opsi ketersediaan tinggi.
Langkah berikutnya
- Ringkasan arsitektur referensi ketersediaan AlloyDB Omni.
- Ketersediaan Standar AlloyDB Omni.
- Ketersediaan yang Ditingkatkan untuk AlloyDB Omni.
- Bekerja dengan replikasi lintas pusat data.
- Meminta pemilihan rute ke Load Balancer Aplikasi klasik multi-region..