Kluster Failover Windows Server dengan Microsoft SQL Server di Azure VM

Artikel
06/02/2023

Berlaku untuk:SQL Server di Azure VM

Artikel ini menjelaskan perbedaan saat menggunakan fitur Kluster Failover Windows Server dengan Microsoft SQL Server di Azure VMs untuk ketersediaan tinggi dan pemulihan bencana (HADR), seperti untuk Grup Ketersediaan AlwaysOn (AG) atau instans kluster failover (FCI).

Untuk mempelajari selengkapnya tentang fitur Windows itu sendiri, lihat dokumentasi Kluster Failover Windows Server.

Gambaran Umum

Solusi ketersediaan tinggi Microsoft SQL Server pada Windows, seperti Grup Ketersediaan AlwaysOn (AG) atau instans kluster failover (FCI) mengandalkan layanan Windows Server Failover Clustering (WSFC) yang mendasarinya.

Layanan kluster memantau koneksi jaringan dan kesehatan node dalam kluster. Selain untuk pemeriksaan kesehatan yang dilakukan Microsoft SQL Server, pemantauan ini ditujukan sebagai bagian dari grup ketersediaan atau fitur instans kluster failover. Jika layanan kluster tidak dapat mengjangkau node, atau jika peran AG atau FCI dalam kluster menjadi tidak sehat, maka layanan kluster memulai tindakan pemulihan yang tepat untuk memulihkan dan membawa aplikasi dan layanan secara online, baik pada node yang sama atau pada node lain dalam kluster.

Pemantauan kesehatan kluster

Untuk memberikan ketersediaan tinggi, kluster harus memastikan kesehatan berbagai komponen yang membentuk solusi kluster. Layanan klaster memantau kesehatan kluster berdasarkan sejumlah parameter sistem dan jaringan untuk mendeteksi dan merespons kegagalan.

Mengatur ambang batas untuk menyatakan kegagalan penting untuk mencapai keseimbangan antara segera menanggapi kegagalan, dan menghindari kegagalan palsu.

Ada dua strategi untuk memantau:

Pemantauan	Deskripsi
Agresif	Memberikan deteksi kegagalan yang cepat dan pemulihan kegagalan keras, yang memberikan tingkat ketersediaan tertinggi. Layanan kluster dan SQL Server kurang memaafkan kegagalan sementara dan dalam beberapa situasi mungkin gagal secara prematur atas sumber daya ketika ada pemadaman sementara. Setelah kegagalan terdeteksi, tindakan korektif yang mengikuti mungkin membutuhkan waktu ekstra.
Santai	Memberikan deteksi kegagalan yang lebih pemaaf dengan toleransi yang lebih besar untuk masalah jaringan sementara yang singkat. Menghindari kegagalan sementara, tetapi juga memperkenalkan risiko menunda deteksi kegagalan sejati.

Pengaturan agresif di lingkungan kluster di cloud dapat menyebabkan kegagalan dini dan pemadaman yang lebih lama, oleh karena itu strategi pemantauan yang dilonggarkan direkomendasikan untuk kluster failover pada Azure VMs. Untuk menyesuaikan pengaturan ambang batas, lihat praktik terbaik kluster untuk detail selengkapnya.

Heartbeat kluster

Pengaturan utama yang mempengaruhi heartbeat kluster dan deteksi kesehatan antara node:

Pengaturan	Deskripsi
Tunda	Ini mendefinisikan frekuensi di mana heartbeat kluster dikirim di antara node. Penundaan adalah jumlah detik sebelum heartbeat berikutnya dikirim. Dalam kluster yang sama terdapat pengaturan penundaan yang berbeda yang dikonfigurasi antara node pada subnet yang sama, dan antara node yang berada di subnet yang berbeda.
Ambang Batas	Ambang batas adalah jumlah heartbeat yang dapat dilewatkan sebelum kluster mengambil tindakan pemulihan. Dalam kluster yang sama terdapat pengaturan ambang yang berbeda yang dikonfigurasi antara node pada subnet yang sama, dan antara node yang berada di subnet yang berbeda.

Nilai default untuk pengaturan ini mungkin terlalu rendah untuk lingkungan cloud, dan dapat mengakibatkan kegagalan yang tidak perlu karena masalah jaringan sementara. Agar lebih toleran, gunakan pengaturan ambang yang santai untuk kluster failover di Azure VMs. Lihat praktik terbaik kluster untuk detail selengkapnya.

Kuorum

Meskipun kluster dua simpul akan berfungsi tanpa sumber daya kuorum, sangat diharuskan bagi pelanggan untuk menggunakan sumber daya kuorum untuk memiliki dukungan produksi. Validasi kluster tidak akan meluluskan kluster apa pun tanpa sumber daya kuorum.

Secara teknis, kluster tiga simpul dapat bertahan saat kehilangan satu simpul (hingga dua simpul) tanpa sumber daya kuorum. Tetapi setelah kluster kehilangan dua simpul, ada risiko bahwa sumber daya yang dikelompokkan akan luring dalam kasus kehilangan simpul atau kegagalan komunikasi untuk mencegah skenario split-brain. Mengonfigurasi sumber daya kuorum akan memungkinkan sumber daya kluster untuk tetap daring hanya dengan satu simpul daring.

Bukti disk adalah opsi kuorum yang paling tangguh, tetapi untuk menggunakan bukti disk pada Microsoft SQL Server di Azure VM, Anda harus menggunakan Azure Shared Disk yang memberlakukan beberapa batasan untuk solusi ketersediaan tinggi. Dengan demikian, gunakan bukti disk saat Anda mengonfigurasi instans kluster failover dengan Azure Shared Disks, jika tidak, gunakan bukti cloud jika memungkinkan.

Tabel berikut ini mencantumkan opsi kuorum yang tersedia untuk Microsoft SQL Server di Azure VMs:

	Bukti cloud	Bukti disk	Bukti file bersama
OS yang didukung	Windows Server 2016+	Semua	Semua
Deskripsi	Bukti cloud adalah jenis bukti kuorum kluster failover yang menggunakan Microsoft Azure untuk memberikan suara pada kuorum kluster. Ukuran default adalah sekitar 1 MB dan hanya berisi stempel waktu. Bukti cloud sangat ideal untuk penyebaran di beberapa situs, beberapa zona, dan beberapa wilayah. Gunakan bukti cloud jika memungkinkan, kecuali Anda memiliki solusi kluster failover dengan penyimpanan bersama.	Bukti disk adalah disk kecil yang dikelompokkan dalam grup Cluster Available Storage. Disk ini sangat tersedia dan dapat gagal di antara simpul. Ia berisi salinan database kluster, dengan ukuran default yang biasanya kurang dari 1 GB. Bukti disk adalah opsi kuorum pilihan untuk kluster apa pun yang menggunakan Disk Bersama Azure (atau solusi disk bersama apa pun seperti SCSI, iSCSI, atau saluran fiber SAN yang digunakan bersama). Clustered Shared Volume tidak bisa digunakan sebagai bukti disk. Mengonfigurasi disk bersama Azure sebagai bukti disk.	Bukti file bersama adalah berbagi file SMB yang biasanya dikonfigurasi pada server file yang menjalankan Windows Server. Ia mempertahankan informasi pengklusteran dalam file log bukti, tetapi tidak menyimpan salinan database kluster. Di Azure, Anda dapat mengonfigurasi berbagi file di komputer virtual terpisah dalam jaringan virtual yang sama. Gunakan bukti berbagi file jika bukti disk atau bukti cloud tidak tersedia di lingkungan Anda.

Untuk memulai, lihat Konfigurasikan kuorum kluster.

Nama jaringan virtual (VNN)

Untuk mencocokkan pengalaman lokal untuk menyambungkan ke listener grup ketersediaan atau instans kluster failover, gunakan VM SQL Server Anda ke beberapa subnet dalam jaringan virtual yang sama. Memiliki beberapa subnet meniadakan kebutuhan akan ketergantungan ekstra pada Azure Load Balancer untuk merutekan lalu lintas ke solusi HADR Anda. Untuk mempelajari selengkapnya, lihat Multi-subnet AG,dan Multi-subnet FCI.

Dalam lingkungan lokal tradisional, sumber daya kluster seperti instans kluster failover atau Grup Ketersediaan AlwaysOn mengandalkan Nama Microsoft Azure Virtual Network untuk merutekan lalu lintas ke target yang sesuai - baik instans kluster failover, atau pendengar grup ketersediaan AlwaysOn. Nama virtual mengikat alamat IP di DNS, dan klien dapat menggunakan nama virtual atau alamat IP untuk terhubung ke target ketersediaan tinggi mereka, terlepas dari node mana yang saat ini memiliki sumber daya. VNN adalah nama dan alamat jaringan yang dikelola oleh kluster, dan layanan kluster memindahkan alamat jaringan dari node ke node selama peristiwa failover. Selama kegagalan, alamat diambil offline pada replika utama asli, dan dibawa secara online pada replika utama baru.

Pada Microsoft Azure Virtual Machines di subnet tunggal, komponen tambahan diperlukan untuk merutekan lalu lintas dari klien ke Nama Jaringan Virtual sumber daya kluster (instans kluster failover, atau listener grup ketersediaan). Di Azure, penyeimbang muatan memegang alamat IP untuk VNN yang diandalkan sumber daya Microsoft SQL Server kluster dan diperlukan untuk merutekan lalu lintas ke target ketersediaan tinggi yang sesuai. Penyeimbang muatan juga mendeteksi kegagalan dengan komponen jaringan dan memindahkan alamat ke host baru.

Penyeimbang muatan mendistribusikan alur masuk yang tiba di ujung depan, lalu merutekan lalu lintas tersebut ke instans yang ditentukan oleh kumpulan di ujung belakang. Anda mengonfigurasi arus lalu lintas dengan menggunakan aturan penyeimbangan muatan dan pemeriksaan kondisi. Dengan Microsoft SQL Server FCI, instans kumpulan back-end adalah mesin virtual Azure yang menjalankan Microsoft SQL Server, dan dengan grup ketersediaan, kumpulan back-end adalah pendengar. Ada sedikit keterlambatan kegagalan saat Anda menggunakan penyeimbang muatan karena pemeriksaan kondisi melakukan pemeriksaan aktif setiap 10 detik secara default.

Untuk memulai, pelajari cara mengonfigurasi Azure Load Balancer untuk instans kluster failover atau grup ketersediaan.

OS yang didukung: Semua
Versi SQL yang didukung: Semua
Solusi HADR yang didukung: Instans kluster failover dan grup ketersediaan

Konfigurasi VNN bisa rumit karena merupakan sumber kegagalan tambahan, dapat menyebabkan keterlambatan dalam deteksi kegagalan, dan ada overhead dan biaya yang terkait dengan mengelola sumber daya tambahan. Untuk mengatasi beberapa batasan ini, SQL Server memperkenalkan dukungan untuk fitur Nama Jaringan Terdistribusi.

Distributed network name (DNN)

Untuk mencocokkan pengalaman lokal untuk menyambungkan ke listener grup ketersediaan atau instans kluster failover, gunakan VM SQL Server Anda ke beberapa subnet dalam jaringan virtual yang sama. Memiliki beberapa subnet meniadakan kebutuhan akan ketergantungan ekstra pada DNN untuk merutekan lalu lintas ke solusi HADR Anda. Untuk mempelajari selengkapnya, lihat Multi-subnet AG,dan Multi-subnet FCI.

Untuk SQL Server VM yang digunakan ke satu subnet, fitur nama jaringan terdistribusi menyediakan cara alternatif bagi klien SQL Server untuk terhubung ke instans kluster failover SQL Server atau listener grup ketersediaan tanpa menggunakan penyeimbang beban. Fitur DNN tersedia mulai dari SQL Server 2016 SP3, SQL Server 2017 CU25, SQL Server 2019 CU8, di Windows Server 2016 dan yang lebih baru.

Saat sumber daya DNN dibuat, kluster mengikat nama DNS dengan alamat IP semua simpul dalam kluster. Klien akan mencoba menyambungkan ke setiap alamat IP dalam daftar ini untuk mencari sumber daya mana yang akan disambungkan. Anda dapat mempercepat proses ini dengan menentukan MultiSubnetFailover=True dalam string koneksi. Pengaturan ini memberi tahu penyedia untuk mencoba semua alamat IP secara paralel, sehingga klien dapat tersambung ke FCI atau listener secara instan.

Nama jaringan terdistribusi disarankan daripada penyeimbang muatan jika memungkinkan karena:

Solusi menyeluruh lebih andal karena Anda tidak lagi harus mempertahankan sumber daya penyeimbang muatan.
Menghilangkan pemeriksaan penyeimbang muatan meminimalkan durasi kegagalan.
DNN menyederhanakan provisi dan pengelolaan instans kluster failover atau listener grup ketersediaan dengan SQL Server di komputer virtual Azure.

Sebagian besar fitur SQL Server bekerja secara transparan dengan FCI dan grup ketersediaan saat menggunakan DNN, tetapi ada fitur tertentu yang mungkin memerlukan pertimbangan khusus.

OS yang didukung: Windows Server 2016 dan yang lebih baru
Versi SQL yang didukung: SQL Server 2019 CU2 (FCI) dan SQL Server 2019 CU8 (AG)
Solusi HADR yang didukung: Instans kluster failover dan grup ketersediaan

Untuk memulai, pelajari cara mengonfigurasi sumber daya nama jaringan terdistribusi untuk instans kluster failover atau grup ketersediaan.

Ada pertimbangan tambahan saat menggunakan DNN dengan fitur Microsoft SQL Server. Lihat Interoperabilitas FCI dan DNN dan Interoperabilitas AG dan DNN untuk mempelajari lebih lanjut.

Tindakan pemulihan otomatis

Layanan kluster mengambil tindakan korektif ketika kegagalan terdeteksi. Ini dapat memulai ulang resource pada node yang ada, atau gagal sumber daya ke node lain. Setelah langkah-langkah korektif dimulai, mereka membutukan beberapa waktu untuk menyelesaikannya.

Misalnya, grup ketersediaan yang dimulai ulang online per urutan berikut:

IP pendengar online
Nama jaringan pendengar sedang daring
Grup ketersediaan online
Database individual melalui pemulihan, yang dapat memakan waktu tergantung pada sejumlah faktor, seperti panjang log ulang. Koneksi dirutekan oleh pendengar hanya setelah database sepenuhnya pulih. Untuk mempelajari lebih lanjut, lihat Memperkirakan waktu failover (RTO).

Karena pemulihan dapat memakan waktu, pemantauan agresif yang diatur untuk mendeteksi kegagalan dalam 20 detik dapat mengakibatkan pemadaman menit jika peristiwa sementara terjadi (seperti pemeliharaan Azure VM yang mempertahankan memori). Mengatur pemantauan ke nilai 40 detik yang lebih santai untuk membantu menghindari gangguan layanan yang lebih lama.

Untuk menyesuaikan pengaturan ambang batas, lihat praktik terbaik kluster untuk detail selengkapnya.

Lokasi node

Node dalam kluster Windows pada komputer virtual di Azure mungkin dipisahkan secara fisik dalam wilayah Azure yang sama, atau dapat berada di wilayah yang berbeda. Jarak dapat memperkenalkan latensi jaringan, seperti memiliki node kluster yang tersebar di antara lokasi di fasilitas Anda sendiri. Di lingkungan cloud, perbedaannya adalah bahwa dalam wilayah Anda mungkin tidak menyadari jarak antara node. Selain itu, beberapa faktor lain seperti komponen fisik dan virtual, jumlah hop, dll juga dapat berkontribusi pada peningkatan latensi. Jika latensi antara node menjadi perhatian, pertimbangkan untuk menempatkan node kluster dalam grup penempatan kedekatan untuk menjamin kedekatan jaringan.

Batas sumber daya

Saat mengonfigurasi komputer virtual Azure, Anda menentukan batas sumber daya komputasi untuk CPU, memori, dan IO. Beban kerja yang memerlukan lebih banyak sumber daya daripada komputer virtual Azure yang dibeli, atau batas disk dapat menyebabkan masalah perorma komputer virtual. Penurunan kinerja dapat mengakibatkan pemeriksaan kesehatan yang gagal baik untuk layanan kluster, atau untuk fitur ketersediaan tinggi Microsoft SQL Server. Penyempitan sumber daya dapat membuat node atau sumber daya muncul ke kluster atau Microsoft SQL Server.

Operasi SQL IO intensif atau operasi pemeliharaan seperti pencadangan, indeks, atau pemeliharaan statistik dapat menyebabkan komputer virtual atau disk mencapai batas throughput IOPS atau MBPS, yang dapat membuat Microsoft SQL Server tidak responsif terhadap pemeriksaan IsAlive/LooksAlive.

Jika SQL Server Anda mengalami kegagalan tak terduga, periksa untuk memastikan Anda mengikuti semua praktik terbaik kinerja dan memantau server untuk disk atau pembatasan tingkat VM.

Pemeliharaan platform Azure

Sama seperti layanan awan lainnya, Azure secara berkala melakukan pembaruan untuk meningkatkan keandalan, performa, dan keamanan prasarana host untuk komputer virtual. Tujuan pembaruan ini mulai dari mem-patch komponen perangkat lunak di lingkungan hosting hingga meningkatkan komponen jaringan atau menonaktifkan perangkat keras.

Sebagian besar pembaruan platform tidak memengaruhi VM pelanggan. Saat pembaruan tanpa dampak tidak dimungkinkan, Azure memilih mekanisme pembaruan yang paling tidak berdampak pada VM pelanggan. Sebagian besar pemeliharaan berdampak bukan nol menjeda komputer virtual selama kurang dari 10 detik. Dalam kasus tertentu, Azure menggunakan mekanisme pemeliharaan yang mempertahankan memori. Mekanisme ini menjeda VM hingga 30 detik dan mempertahankan memori dalam RAM. VM kemudian dilanjutkan, dan jamnya secara otomatis disinkronkan.

Pemeliharaan yang mempertahankan memori berfungsi untuk lebih dari 90 persen VM Azure. Ini tidak bekerja untuk seri G, M, N, dan H. Azure semakin menggunakan teknologi migrasi langsung dan meningkatkan mekanisme pemeliharaan yang mempertahankan memori untuk mengurangi durasi jeda. Ketika VM dimigrasikan langsung ke host yang berbeda, beberapa beban kerja sensitif seperti Microsoft SQL Server mungkin menunjukkan sedikit penurunan kinerja dalam beberapa menit menjelang jeda VM.

Penyempitan sumber daya selama pemeliharaan platform dapat membuat AG atau FCI muncul ke layanan kluster. Lihat bagian batas sumber daya dari artikel ini untuk mempelajari selengkapnya.

Jika Anda menggunakan pemantauan klaster yang agresif, jeda komputer virtual yang diperpanjang dapat memicu kegagalan. Kegagalan akan sering menyebabkan lebih banyak downtime daripada jeda pemeliharaan, sehingga disarankan untuk menggunakan pemantauan yang santai untuk menghindari memicu kegagalan saat komputer virtual dijeda untuk pemeliharaan. Lihat praktik terbaik kluster untuk informasi selengkapnya tentang pengaturan ambang kluster di Azure VM.

Pembatasan

Pertimbangkan batasan berikut saat Anda menggunakan FCI atau grup ketersediaan dan SQL Server di Microsoft Azure Virtual Machines.

MSDTC

Microsoft Azure Virtual Machines mendukung Koordinator Transaksi Terdistribusi Microsoft (MSDTC) pada Windows Server 2019 dengan penyimpanan pada Volume Bersama dalam Kluster (CSV) dan Azure Standard Load Balancer atau pada komputer virtual SQL Server yang menggunakan disk bersama Azure.

Di Azure Virtual Machines, MSDTC tidak didukung untuk Windows Server 2016 atau yang lebih lama dengan Volume Bersama dalam Kluster karena:

Sumber daya MSDTC dalam kluster tidak dapat dikonfigurasi untuk menggunakan penyimpanan bersama. Pada Windows Server 2016, jika Anda membuat sumber daya MSDTC, penyimpanan bersama yang tersedia untuk digunakan tidak akan ditampilkan, bahkan jika penyimpanan tersedia. Masalah ini telah diperbaiki di Windows Server 2019.
Penyeimbang beban dasar tidak menangani port RPC.

Langkah berikutnya

Sekarang setelah Anda membiasakan diri dengan perbedaan saat menggunakan Kluster Failover Windows dengan Microsoft SQL Server di Azure VMs, pelajari tentang fitur ketersediaan tinggi grup ketersediaan atau instans kluster failover. Jika Anda siap untuk memulai, pastikan untuk meninjau praktik terbaik untuk rekomendasi konfigurasi.