Date: Januari 18, 2018
Bagaimana Replikasi Asinkron Bisa Digunakan dalam Cluster Multi-Situs? Bukankah Data Out Of Sync?
Saya telah mengajukan pertanyaan ini lebih dari beberapa kali, jadi saya pikir saya akan menjawabnya di posting blog pertama saya. Jawaban dasarnya adalah ya, Anda bisa kehilangan data dalam kegagalan yang tak terduga saat menggunakan replikasi asinkron dalam cluster multi-situs. Dalam dunia ideal, setiap perusahaan akan memiliki koneksi serat gelap ke situs DR mereka dan menggunakan replikasi sinkron dengan cluster multi-situs mereka, sehingga menghilangkan kemungkinan kehilangan data. Namun, kenyataannya adalah bahwa dalam banyak kasus, konektivitas WAN ke situs DR memiliki latency terlalu banyak untuk mendukung replikasi sinkron. Dalam kasus tersebut, replikasi asinkron adalah alternatif yang sangat baik.
Apa Pilihan Saya?
Ada lebih dari beberapa opsi ketika memilih solusi replikasi asinkron untuk digunakan dengan klaster multi-situs WSFC Anda. Ini termasuk solusi berbasis array dari perusahaan seperti EMC, IBM, HP, dll. dan solusi berbasis host, seperti yang dekat dan saya sukai, "SteelEye DataKeeper Cluster Edition". Karena saya mengenal DataKeeper dengan baik, saya akan menjelaskan bagaimana semua ini bekerja dari calon DataKeeper.
Bagaimana dengan SteelEye DataKeeper?
Saat menggunakan SteelEye DataKeeper dan replikasi asinkron, kami mengizinkan sejumlah penulisan untuk disimpan dalam antrian asinkron. Jumlah penulisan yang dapat antri ditentukan oleh "tanda air tinggi". Ini adalah nilai yang dapat disesuaikan yang digunakan oleh DataKeeper untuk menentukan berapa banyak data yang bisa berada dalam antrian sebelum kondisi mirror diubah dari "mirroring" menjadi "dijeda". Status "dijeda" juga dimasukkan kapan saja ada kegagalan komunikasi antara server sekunder dan primer. Sementara dalam keadaan berhenti, failover otomatis di cluster multi-situs dinonaktifkan, sehingga membatasi jumlah data yang dapat hilang dalam kegagalan yang tidak terduga. Jika kumpulan data asli dianggap "hilang selamanya", maka data yang tersisa pada server target dapat dibuka secara manual dan node cluster kemudian dapat dibawa ke layanan.
Saat berada dalam keadaan "berhenti sejenak", DataKeeper mengizinkan antrian asinkron mengalir sampai mencapai "tanda air rendah", dan pada saat mana cermin memasuki keadaan "resync" sampai semua data sekali lagi sinkron. Pada saat itu, cermin sekali lagi berada dalam keadaan "mirroring" dan failover otomatis sekali lagi diaktifkan.
Selama link WAN Anda tidak jenuh atau rusak, Anda seharusnya tidak pernah melihat lebih dari beberapa menulis pada waktu tertentu dalam antrian asinkron ini. Dalam kegagalan yang tak terduga (pikirkan kabel daya yang ditarik) Anda akan kehilangan tulisan yang ada di antrian asinkron. Ini adalah trade off yang Anda buat ketika Anda menginginkan tujuan titik pemulihan yang mengagumkan (RPO) dan tujuan waktu pemulihan (RTO) yang Anda capai dengan cluster multi-situs, namun tautan WAN Anda memiliki latensi terlalu banyak untuk mendukung replikasi sinkron secara efektif.
Coba The SteelEye DataKeeper
Luangkan waktu untuk memantau Antrian DataKeeper Async melalui Windows Performance Logs and Alerts. Saya pikir Anda akan terkejut menemukan bahwa sebagian besar waktu antrian async kosong karena efisiensi mesin replikasi DataKeeper. Bahkan di masa-masa penulisan yang berat, antrian async jarang tumbuh sangat besar dan selalu terkuras segera. Jadi jumlah data yang berisiko pada waktu tertentu minimal. Dibandingkan dengan alternatif dalam bencana untuk dipulihkan dari cadangan semalam, jumlah penulisan yang bisa Anda hilangkan dalam kegagalan tak terduga menggunakan replikasi asinkron sangat minim!
Tentu saja, ada beberapa kasus di mana bahkan kehilangan satu menulis pun tidak dapat ditolerir. Dalam kasus tersebut, disarankan untuk menggunakan opsi replikasi sinkron SteelEye DataKeeper di koneksi LAN latency berkecepatan tinggi dan rendah.
Diproduksi ulang dengan izin dari Clusteringformeremortals.com