Date: Maret 26, 2019
Tag: SQL Server Failover Cluster Instance
Mencapai SQL Server Ketersediaan Tinggi, Pemulihan Bencana Dengan Campuran Grup Selalu Tersedia dan SANless SQL Server Failover Cluster Instances
pengantar
Topik pencampuran SQL Server Failover Cluster Instances (FCI) dengan Always On Availability Groups (AG) didokumentasikan dengan cukup baik. Namun, sebagian besar konfigurasi dokumen dokumentasi yang tersedia yang mengasumsikan bagian SQL Server FCI dari solusi menggunakan penyimpanan bersama. Bagaimana jika saya ingin membangun SANless SQL Server FCI menggunakan Storage Spaces Direct (S2D), apakah saya masih dapat menambahkan SQL Server AG ke dalam campuran? Sayangnya, jawaban untuk pertanyaan ini adalah tidak. Sampai hari ini, kombinasi S2D berbasis SQL Server FCI dan Always On AG ini tidak didukung. Saya sebelumnya menulis blog tentang batasan S2D ini di sini. Namun, kabar baiknya adalah Anda BISA membangun SANless SQL Server FCI dengan SIOS DataKeeper dan masih memanfaatkan Always On AG untuk hal-hal seperti sekunder yang dapat dibaca. Anda masih harus mematuhi aturan yang sama yang berlaku ketika mencampur SQL Server FCI tradisional berbasis SAN dan Always On AGs, tetapi sebagian besar untuk mencapai SQL Server ketersediaan tinggi hampir sama. Replikasi Sinkronisasi DataKeeper umumnya digunakan antara node di pusat data atau wilayah cloud yang sama, tetapi Anda mungkin ingin mereplikasi secara tidak sinkron ke node tambahan di wilayah berbeda untuk pemulihan bencana. Dalam hal ini, jika Anda harus membawa DR node online setelah kegagalan tak terduga, Anda harus menghapus konfigurasi Always On AG dan mengkonfigurasi ulang mereka. Persyaratan ini sangat mirip dengan apa yang Microsoft terbitkan di sini sehubungan dengan mengembalikan snapshot asinkron dari SQL Server Always On AG yang berjalan di dalam VM.
Grup yang Tersedia
Pada dasarnya, Instance SQL Server Failover Cluster Instance dengan DataKeeper terlihat seperti turunan tunggal dari SQL Server sejauh yang selalu ada pada Wizard Grup Ketersediaan. Konfigurasi Selalu Aktif AG persis sama seperti jika Anda hanya membuat Selalu Aktif AG antara dua contoh SQL Server Standalone (non-clustered). Kebingungan nyata muncul pada kenyataan bahwa dalam konfigurasi ini semua server berada di kluster failover yang sama. Tetapi SQL Server FCI hanya dikonfigurasi untuk berjalan hanya pada node cluster di mana SQL Server diinstal sebagai SQL Server Clustered. Node lain berada di cluster yang sama. Namun, SQL diinstal pada node tersebut sebagai Mesin Virtual SQL Server Standalone, bukan Mesin Virtual Clustered. Agak membingungkan. Pada dasarnya apa yang terjadi adalah bahwa Always On AG memanfaatkan model kuorum dan pendengar WSFC. Dengan demikian semua Replika AG harus berada di WSFC yang sama, meskipun mereka biasanya tidak menjalankan contoh SQL Server yang dikelompokkan. Jika Anda benar-benar bingung tidak apa-apa, kebanyakan orang bingung ketika mereka pertama kali mencoba membungkus kepala mereka dengan konfigurasi hybrid ini. Manfaat nyata dalam konfigurasi seperti ini adalah bahwa SQL Server Failover Cluster Instance dapat menjadi lebih baik dan lebih hemat biaya (lebih lanjut tentang ini nanti *) Solusi Ketersediaan Tinggi daripada Selalu Di AG dalam banyak keadaan, tetapi tidak memiliki kemampuan untuk menawarkan replika sekunder yang dapat dibaca. Menambahkan replika sekunder Always On AG yang dapat dibaca menjadi opsi yang layak untuk mengatasi kebutuhan ini. Dan menggunakan SIOS DataKeeper menghilangkan kebutuhan untuk SAN untuk SQL Server FCI, yang membuka kemungkinan mengkonfigurasi SQL Server FCI di mana node berada di pusat data yang berbeda, yang juga berarti dukungan untuk SQL Server FCI yang menjangkau Zona Ketersediaan di Azure dan AWS. Harap perhatikan bahwa gambar di bawah ini hanya satu konfigurasi yang memungkinkan. Beberapa node cluster FCI, beberapa AG, dan beberapa Replika semuanya didukung. Anda hanya dibatasi oleh batasan yang diberlakukan oleh versi SQL Server Anda. Artikel ini sepertinya mendokumentasikan langkah-langkah pengaturan dengan cukup baik. Tentu saja, alih-alih penyimpanan bersama untuk SQL FCI, Anda akan menggunakan SIOS DataKeeper untuk membangun FCI seperti yang saya dokumentasikan di sini.
Grup Ketersediaan Dasar
Pada SQL Server 2016 yang diperkecil "Kelompok Ketersediaan Dasar" menjadi tersedia di SQL Server Edisi Standar, membuat konfigurasi ini mungkin bahkan dalam SQL Server Edisi Standar. AG Dasar terbatas pada basis data tunggal per Grup yang Tersedia, Replika Tunggal (2-simpul). Namun, mereka tidak mendukung replika sekunder yang dapat dibaca sehingga kasus penggunaannya dalam konfigurasi hibrid ini sangat terbatas.
Grup Ketersediaan yang Didistribusikan
AG terdistribusi yang diperkenalkan di SQL Server 2016 juga didukung dalam konfigurasi hibrid ini. AG terdistribusi sangat mirip dengan AG biasa, tetapi Replika tidak perlu berada di cluster yang sama, atau bahkan di Domain Windows yang sama. Microsoft mendokumentasikan kasus penggunaan utama dari Grup Ketersediaan Terdistribusi sebagai berikut:
- Pemulihan bencana dan konfigurasi multi-situs yang lebih mudah
- Migrasi ke perangkat keras atau konfigurasi baru, yang mungkin termasuk menggunakan perangkat keras baru atau mengubah sistem operasi yang mendasarinya
- Meningkatkan jumlah replika yang dapat dibaca melebihi delapan dalam satu kelompok ketersediaan tunggal dengan menjangkau beberapa kelompok ketersediaan
Ringkasan
Jika Anda menyukai gagasan SQL Server FCI untuk SQL Server ketersediaan tinggi, tetapi menginginkan fleksibilitas replika sekunder hanya baca, solusi hibrid ini mungkin hanya hal yang Anda cari. FCI SQL Server tradisional berbasis FCI, dan bahkan FCI berbasis Storage Spaces Direct (S2D), membatasi Anda untuk pusat data tunggal. SIOS DataKeeper membebaskan Anda dari batas SAN Anda dan memungkinkan konfigurasi seperti SQL Server FCI yang menjangkau Zona Ketersediaan atau Wilayah Cloud. Ini juga menghilangkan ketergantungan pada SAN, memungkinkan Anda untuk memanfaatkan perangkat penyimpanan berkecepatan tinggi yang terpasang secara lokal tanpa melepaskan SQL Server Failover Cluster Instance Anda.
* Cara Menghemat Uang
Sebelumnya saya berjanji saya akan memberitahu Anda bagaimana cara menghemat uang dengan melakukan ini semua dengan SQL Server Standard Edition. Jika Anda dapat hidup dengan replika yang dapat dibaca yang merupakan snapshot berbasis waktu, Anda dapat melewati Always On AGs sepenuhnya dan cukup gunakan fitur snapshot sisi target SIOS DataKeeper untuk secara berkala mengambil snapshot konsisten volume aplikasi di server target tanpa memengaruhi replikasi yang sedang berlangsung atau ketersediaan. Begini caranya …
Buat 2-node SQL Server FCI dengan SQL Server Standard Edition dan hemat sejumlah uang pada lisensi SQL. Namun masih mereplikasi data ke simpul ke-3 di luar cluster untuk tujuan pelaporan atau DR. Jika Anda mengambil snapshot dari volume di server ketiga ini, snapshot ini dapat diakses dengan benar. Dengan cara ini, Anda dapat me-mount database tersebut dari instance SQL Server mandiri untuk menjalankan laporan akhir bulan, menyalin ke arsip, atau Anda bahkan mungkin ingin menggunakan snapshot itu untuk secara cepat dan mudah memperbarui lingkungan QA dan Test / Dev Anda dengan SQL terbaru data. Saya harap Anda menemukan panduan untuk membuat untuk mencapai SQL Server ketersediaan tinggi, pemulihan bencana dengan campuran Grup Ketersediaan Selalu dan Instan SQL Server Failover Failover Cluster berguna.