Cara menggunakan Azure Site Recovery (ASR) untuk mereplikasi Windows Server Failover Cluster (WSFC) yang menggunakan SIOS DataKeeper untuk penyimpanan cluster

Pendahuluan

Jadi, Anda telah membangun SQL Server Failover Cluster Instance (FCI), atau mungkin cluster SAP ASCS/ERS di Azure. Setiap node cluster berada di Availability Zone (AZ) yang berbeda, atau mungkin Anda memiliki persyaratan latensi yang ketat dan menggunakan Placement Proximity Groups (PPG) dan semua node Anda berada di Availability Set yang sama. Terlepas dari skenarionya, Anda sekarang memiliki tingkat ketersediaan yang jauh lebih tinggi untuk aplikasi penting bisnis Anda daripada jika Anda hanya menjalankan satu instans.

Sekarang kamu punya ketersediaan tinggi (HA) tertutup, apa yang akan kamu lakukan untuk pemulihan bencana ? Bencana regional yang menyebabkan beberapa AZ jarang terjadi, tetapi seperti yang ditunjukkan oleh sejarah baru-baru ini, Ibu Pertiwi benar-benar dapat memberikan pukulan. Anda ingin bersiap jika seluruh wilayah offline.

Azure Site Recovery (ASR) adalah penawaran pemulihan bencana sebagai layanan (DRaaS) Microsoft yang memungkinkan Anda mereplikasi seluruh VM dari satu wilayah ke wilayah lain. Itu juga dapat mereplikasi mesin virtual dan server fisik dari lokal ke Azure, tetapi untuk tujuan posting blog ini kami akan fokus pada kemampuan Azure Region-to-Region DR.

Menyiapkan Pemulihan Situs Azure

Kami akan menganggap Anda telah membangun cluster Anda menggunakan Penjaga Data SIOS . Jika tidak, berikut adalah beberapa petunjuk untuk membantu Anda memulai.

Instans Failover Cluster dengan SQL Server di Azure VMs SIOS DataKeeper Cluster Edition untuk disk berbagi cluster SAP ASCS/SCS Kami juga akan menganggap Anda sudah familiar dengan Azure Site Recovery. Alih-alih panduan lain tentang pengaturan ASR, saya sarankan Anda membaca yang terbaru dokumentasi dari Microsoft. Artikel ini akan berfokus pada beberapa hal yang mungkin tidak Anda pertimbangkan dan langkah-langkah spesifik yang diperlukan untuk memperbaiki cluster Anda setelah failover ke subnet yang berbeda.

Wilayah Berpasangan

Sebelum Anda memulai jalur DR, Anda harus mengetahui konsep Azure Paired Regions. Setiap Wilayah di Azure memiliki Wilayah DR pilihan. Jika Anda ingin mempelajari lebih lanjut tentang Wilayah Berpasangan, kunjungi dokumentasi memberikan latar belakang yang bagus. Ada beberapa yang sangat bagus manfaat menggunakan wilayah pasangan Anda, tetapi terserah Anda untuk memutuskan wilayah mana yang ingin Anda gunakan untuk meng-host situs DR Anda.

Lokasi Cloud Witness

Ketika Anda awalnya membangun cluster Anda, Anda harus memilih jenis saksi untuk kuorum Anda. Anda mungkin telah memilih File Share Witness atau Cloud Witness. Biasanya salah satu dari jenis saksi tersebut harus berada di AZ yang terpisah dari node cluster Anda.

Namun, ketika Anda mempertimbangkan bahwa, jika terjadi bencana, seluruh cluster Anda akan berjalan di wilayah DR Anda, ada opsi yang lebih baik. Anda harus menggunakan saksi awan, dan menempatkannya di wilayah DR Anda. Dengan menempatkan saksi cloud Anda di wilayah DR, Anda memberikan ketahanan tidak hanya untuk kegagalan AZ lokal, tetapi juga melindungi Anda jika seluruh wilayah gagal dan Anda harus menggunakan ASR untuk memulihkan kluster Anda di wilayah DR. Melalui keajaiban Dynamic Quorum dan Dynamic Witness, Anda dapat yakin bahwa meskipun wilayah DR Anda offline untuk sementara, hal itu tidak akan memengaruhi kluster produksi Anda.

Konsistensi Multi-VM

Saat menggunakan ASR untuk mereplikasi cluster, penting untuk mengaktifkan Konsistensi Multi-VM untuk memastikan bahwa titik pemulihan setiap node cluster berasal dari titik waktu yang sama. Itu memastikan bahwa replikasi tingkat blok DataKeeper yang terjadi di antara VM akan dapat dilanjutkan setelah pemulihan tanpa memerlukan sinkronisasi ulang lengkap.

Poin Pemulihan Konsisten Crash

Titik pemulihan konsisten aplikasi tidak didukung di kluster yang direplikasi. Saat mengonfigurasi opsi replikasi ASR, jangan aktifkan titik pemulihan konsisten aplikasi.

Simpan Alamat IP Setelah Failover?

Saat menggunakan ASR untuk mereplikasi ke situs DR Anda, ada cara untuk menjaga alamat IP VM tetap sama. Microsoft menjelaskannya dalam artikel berjudul Pertahankan alamat IP selama failover . Jika Anda dapat menjaga alamat IP tetap sama setelah failover, ini akan menyederhanakan proses pemulihan karena Anda tidak perlu memperbaiki alamat IP cluster atau titik akhir mirror DataKeeper, yang didasarkan pada alamat IP.

Namun, dalam pengalaman saya, saya belum pernah melihat orang yang benar-benar mengikuti panduan di atas, jadi memulihkan cluster di subnet yang berbeda akan memerlukan beberapa langkah tambahan setelah pemulihan sebelum Anda dapat membawa cluster online.

Upaya Kegagalan Pertama Anda

Rencana pemulihan

Karena Anda menggunakan Konsistensi Multi-VM, Anda harus melakukan failover VM Anda menggunakan Rencana Pemulihan. Itu dokumentasi memberikan panduan yang cukup mudah tentang cara melakukannya. Rencana Pemulihan mengelompokkan VM yang ingin Anda pulihkan bersama untuk memastikan semuanya failover bersama-sama. Anda bahkan dapat menambahkan beberapa grup VM ke Rencana Pemulihan yang sama untuk memastikan bahwa seluruh infrastruktur Anda gagal secara teratur.

Rencana Pemulihan juga dapat meluncurkan skrip pasca pemulihan untuk membantu failover menyelesaikan pemulihan dengan sukses. Langkah-langkah yang saya jelaskan di bawah semuanya dapat ditulis sebagai bagian dari Rencana Pemulihan Anda, sehingga sepenuhnya mengotomatiskan proses pemulihan lengkap. Kami tidak akan membahas proses itu dalam posting blog ini, tetapi Microsoft mendokumentasikan proses ini .

Alamat IP Statis

Sebagai bagian dari proses pemulihan, Anda ingin memastikan VM baru memiliki alamat IP statis. Anda harus menyesuaikan properti antarmuka di Portal Azure sehingga VM selalu menggunakan alamat yang sama. Jika Anda ingin menambahkan alamat IP publik ke antarmuka, Anda juga harus melakukannya saat ini.

konfigurasi jaringan

Setelah VM yang direplikasi berhasil dipulihkan di situs DR, hal pertama yang ingin Anda lakukan adalah memverifikasi konektivitas dasar. Apakah konfigurasi IP sudah benar? Apakah instans menggunakan server DNS yang tepat? Apakah resolusi nama berfungsi dengan benar? Bisakah Anda melakukan ping ke server jarak jauh?

Jika ada masalah dengan komunikasi jaringan maka sisa langkah yang dijelaskan di bawah ini pasti akan gagal. Jangan lewatkan langkah ini!

Penyeimbang Beban

Seperti yang mungkin Anda ketahui, kluster di Azure mengharuskan Anda mengonfigurasi penyeimbang beban agar konektivitas klien berfungsi. Penyeimbang beban tidak gagal sebagai bagian dari Rencana Pemulihan. Anda perlu membangun penyeimbang beban baru berdasarkan cluster yang sekarang berada di vNet baru ini. Anda dapat melakukan ini secara manual atau membuat skrip ini sebagai bagian dari Rencana Pemulihan Anda agar terjadi secara otomatis.

Grup Keamanan Jaringan

Berjalan di subnet baru ini juga berarti Anda harus menentukan Grup Keamanan Jaringan apa yang ingin Anda terapkan pada instans ini. Anda harus memastikan bahwa instance dapat berkomunikasi di seluruh port yang diperlukan. Sekali lagi, Anda dapat melakukan ini secara manual, tetapi akan lebih baik untuk membuat skrip ini sebagai bagian dari Rencana Pemulihan Anda.

Perbaiki Alamat IP Cluster

Jika Anda tidak dapat membuat perubahan yang dijelaskan sebelumnya untuk memulihkan instans Anda di subnet yang sama, Anda harus menyelesaikan langkah-langkah berikut untuk memperbarui alamat IP cluster dan alamat DataKeeper untuk digunakan di subnet baru.

Setiap cluster memiliki alamat IP cluster inti. Apa yang akan Anda lihat jika Anda meluncurkan UI WSFC setelah failover adalah bahwa cluster tidak akan dapat terhubung. Ini karena alamat IP yang digunakan oleh cluster tidak valid di subnet baru.

Jika Anda membuka properti dari sumber daya Alamat IP tersebut, Anda dapat mengubah alamat IP menjadi sesuatu yang berfungsi di subnet baru. Pastikan untuk memperbarui Jaringan dan Subnet Mask juga.

Setelah Anda memperbaiki Alamat IP itu, Anda harus melakukan hal yang sama untuk alamat cluster lain yang Anda gunakan di sumber daya cluster Anda.

Perbaiki Alamat Cermin DataKeeper

Cermin SIOS DataKeeper menggunakan alamat IP sebagai titik akhir cermin. Ini disimpan dalam pekerjaan cermin dan cermin. Jika Anda memulihkan cluster berbasis DataKeeper di subnet yang berbeda, Anda akan melihat bahwa mirror muncul dalam status Resync Pending. Anda juga akan melihat bahwa IP Sumber dan IP Target mencerminkan subnet asli, bukan subnet situs DR.

Memperbaiki masalah ini melibatkan menjalankan perintah dari SIOS yang disebut CHANGEMIRRORENDPOINTS . Penggunaan untuk CHANGEMIRRORENDPOINTS adalah sebagai berikut.

emcmd <NEW source IP> CHANGEMIRRORENDPOINTS <volume letter> <ORIGINAL target IP> <NEW source IP> <NEW target IP> Dalam contoh kita, perintah dan output tampak seperti ini.

Setelah perintah berjalan, GUI DataKeeper akan diperbarui untuk mencerminkan alamat IP baru seperti yang ditunjukkan di bawah ini. Cermin juga akan masuk ke kondisi pencerminan.

Kesimpulan

Anda sekarang telah berhasil mengonfigurasi dan menguji pemulihan bencana dari aplikasi penting bisnis Anda menggunakan kombinasi SIOS DataKeeper untuk ketersediaan tinggi dan Azure Site Recovery untuk pemulihan bencana. Jika Anda memiliki pertanyaan, atau ingin berkonsultasi dengan SIOS untuk membantu Anda merancang dan menerapkan ketersediaan tinggi dan pemulihan bencana untuk aplikasi penting bisnis Anda seperti SQL Server, SAP ASCS dan ERS, SAP HANA, Oracle atau aplikasi penting bisnis lainnya, silahkan hubungi kami .