Tair (Redis OSS-compatible) adalah layanan database key-value berperforma tinggi yang dapat digunakan untuk menyimpan volume besar data penting dalam berbagai skenario. Topik ini menjelaskan solusi pemulihan bencana yang disediakan oleh Tair (Redis OSS-compatible).
Evolusi solusi pemulihan bencana
Instans dapat mengalami kegagalan karena berbagai alasan, seperti kegagalan perangkat atau listrik di pusat data. Dalam kasus tersebut, pemulihan bencana menjamin konsistensi data dan ketersediaan layanan.
Gambar 1. Evolusi Solusi Pemulihan Bencana
Solusi pemulihan bencana | Tingkat perlindungan | Deskripsi |
★★★☆☆ | Node master dan replika ditempatkan pada mesin yang berbeda di zona yang sama. Jika node master gagal, sistem high availability (HA) melakukan failover untuk mencegah gangguan layanan yang disebabkan oleh single point of failure (SPOF). | |
★★★★☆ | Node master dan replika ditempatkan di dua zona berbeda dalam wilayah yang sama. Jika zona tempat node master berada terputus karena faktor-faktor seperti kegagalan daya atau jaringan, sistem HA melakukan failover untuk memastikan ketersediaan terus-menerus dari seluruh instans. | |
★★★★★ | Dalam arsitektur Global Distributed Cache, sebuah instans terdistribusi terdiri dari beberapa instans anak yang menyinkronkan data secara real-time melalui saluran sinkronisasi. Manajer saluran memantau status kesehatan instans anak dan menangani pengecualian yang terjadi pada instans anak, seperti alih otomatis antara node master dan replika. Global Distributed Cache cocok untuk skenario seperti pemulihan bencana geo, redundansi geo-aktif, akses aplikasi terdekat, dan penyeimbangan beban. |
Solusi HA zona tunggal
Semua instans mendukung arsitektur HA zona tunggal. Sistem HA memantau status kesehatan node master dan replika serta melakukan failover untuk mencegah gangguan layanan akibat SPOF.
Arsitektur Penyebaran | Deskripsi |
Gambar 2. Arsitektur HA untuk instans master-replika standar Sebuah instans master-replika standar beroperasi dalam arsitektur master-replika. Jika sistem HA mendeteksi kegagalan pada node master, sistem mengalihkan beban kerja dari node master ke node replika dan node replika mengambil alih peran sebagai node master. Setelah pemulihan, node master asli bekerja sebagai node replika. | |
Gambar 3. Arsitektur HA untuk instans kluster multi-replika Pada instans kluster multi-replika, data disimpan pada shard data. Setiap shard data terdiri dari satu node master dan beberapa node replika. Node master dan replika diterapkan pada mesin berbeda dalam arsitektur HA. Jika node master gagal, sistem HA melakukan alih otomatis master-replika untuk memastikan ketersediaan layanan yang tinggi. | |
Gambar 4. Arsitektur HA untuk instans pemisahan baca/tulis
|
Solusi pemulihan bencana antar-zona (multi-zona)
Tair (Redis OSS-compatible) menyediakan solusi pemulihan bencana antar-zona yang melibatkan beberapa zona. Jika beban kerja Anda diterapkan dalam satu wilayah dan memiliki persyaratan tinggi terhadap pemulihan bencana, Anda dapat memilih mode penyebaran multi-zona yang mendukung pemulihan bencana antar-zona saat membuat instans. Untuk informasi selengkapnya, lihat Langkah 1: Membuat instans.
Gambar 5. Buat Instans Pemulihan Bencana Lintas Zona 
Setelah membuat instans pemulihan bencana lintas zona, node replika dengan spesifikasi yang sama dengan node master ditempatkan di zona berbeda dari node master. Node master mensinkronkan data ke node replika melalui saluran khusus.
Jika terjadi kegagalan listrik atau kesalahan jaringan pada node master, node replika mengambil alih peran node master. Sistem memanggil operasi API pada server konfigurasi untuk memperbarui informasi routing node proxy. Selain itu, Tair (Redis OSS-compatible) menyediakan mekanisme sinkronisasi Redis yang dioptimalkan. Mirip dengan pengenal transaksi global (GTID) pada MySQL, Tair (Redis OSS-compatible) menggunakan pengenal operasi global (OpID) untuk menunjukkan offset sinkronisasi dan menjalankan thread tanpa lock di latar belakang untuk mencari OpID. Sistem menyinkronkan log biner AOF (binlog) secara asinkron dari node master ke node replika. Anda dapat melakukan pengendalian aliran sinkronisasi untuk memastikan kinerja Redis.
Solusi pemulihan bencana lintas wilayah
Saat bisnis Anda berkembang ke beberapa wilayah, akses lintas wilayah dan jarak jauh dapat menyebabkan latensi tinggi serta menurunkan pengalaman pengguna. Global Distributed Cache untuk Tair dapat membantu Anda mengurangi latensi tinggi akibat akses lintas wilayah. Global Distributed Cache memiliki manfaat berikut:
Memungkinkan Anda langsung membuat instans anak atau menentukan instans anak yang harus disinkronkan tanpa perlu membangun redundansi ke dalam aplikasi Anda. Ini secara signifikan mengurangi kompleksitas desain aplikasi dan memungkinkan Anda fokus pada pengembangan aplikasi.
Menyediakan kemampuan replikasi geo untuk mengimplementasikan pemulihan bencana geo atau redundansi geo aktif.
Fitur ini cocok untuk skenario sinkronisasi data lintas wilayah dan penerapan bisnis global di industri seperti multimedia, game, dan e-commerce. Untuk informasi selengkapnya, lihat Global Distributed Cache.
Gambar 7. Arsitektur Global Distributed Cache untuk Tair 
Cara merespons kegagalan
Kegagalan seperti kerusakan perangkat, pemadaman listrik pusat data, dan bencana alam dapat diklasifikasikan sebagai kegagalan node master atau kegagalan tingkat zona. Meskipun probabilitas terjadinya kegagalan tersebut rendah, dampaknya dapat menyebabkan instans sementara tidak dapat menulis data, mengalami gangguan koneksi sesaat, atau bahkan downtime total hingga kehilangan data. Keandalan instans sangat bergantung pada arsitekturnya. Dalam kebanyakan kasus, arsitektur kluster memberikan keandalan yang lebih tinggi. Untuk meminimalkan dampak kegagalan, instans multi-zona dengan beberapa replika secara otomatis melakukan failover saat terjadi kegagalan, sehingga meminimalkan downtime. Bagian berikut menjelaskan cara instans dengan solusi pemulihan bencana berbeda merespons kegagalan.
Merespons kegagalan node
Saat node master gagal, mekanisme penanganannya bervariasi tergantung pada konfigurasi penerapan instans:
Jika instans memiliki beberapa node replika dalam satu zona, sistem secara otomatis melakukan failover saat node master gagal. Sistem memilih node replika dengan latensi replikasi terendah sebagai node master baru dan memperbarui hubungan routing.
Jika instans diterapkan di beberapa zona, sistem secara otomatis melakukan failover saat node master gagal. Sistem memilih node replika di zona lain sebagai node master baru dan memperbarui hubungan routing. Namun, hal ini dapat menyebabkan akses lintas zona antara instans dan layanan lainnya.
CatatanUntuk mencegah akses lintas zona dalam arsitektur kluster multi-zona, beban kerja diprioritaskan dialihkan ke node replika di zona primer ketika tersedia node replika di zona primer maupun sekunder.
Merespons kegagalan tingkat zona
Saat terjadi kegagalan tingkat zona seperti pemadaman listrik atau kebakaran, seluruh pusat data menjadi tidak tersedia. Mekanisme penanganannya bervariasi tergantung pada konfigurasi penerapan instans:
Jika instans diterapkan di satu zona, instans menjadi tidak tersedia. Anda harus menunggu zona tersebut pulih. Dalam kasus ini, Anda dapat membuat instans di zona lain berdasarkan data cadangan historis.
Jika instans diterapkan di beberapa zona, alih otomatis dipicu.
Dari segi keamanan, Anda dapat memilih beberapa zona dan membuat beberapa node replika di setiap zona untuk meminimalkan downtime. Namun, Anda harus mempertimbangkan probabilitas kegagalan, pentingnya data bisnis, dan biaya.
Prinsip-prinsip di atas juga berlaku untuk instans anak Global Distributed Cache. Namun, ketika satu instans anak gagal, ketersediaan instans anak lainnya tidak terpengaruh. Untuk mencegah kegagalan penulisan data akibat kegagalan satu instans anak, kami merekomendasikan agar Anda menerapkan instans anak Global Distributed Cache di beberapa zona.
Referensi
Mencegah alih otomatis lintas zona dengan menentukan jumlah node kustom