Instans Kluster Failover AlwaysOn (SQL Server)
Berlaku untuk:
SQL Server
Sebagai bagian dari penawaran SQL Server AlwaysOn, Always On Failover Cluster Instances memanfaatkan fungsionalitas Windows Server Failover Clustering (WSFC) untuk memberikan ketersediaan tinggi lokal melalui redundansi pada instans kluster failover tingkat instans server-a (FCI). FCI adalah instans tunggal SQL Server yang diinstal di seluruh simpul Windows Server Failover Clustering (WSFC) dan, mungkin, di beberapa subnet. Pada jaringan, FCI tampaknya merupakan instans SQL Server yang berjalan pada satu komputer, tetapi FCI menyediakan failover dari satu simpul WSFC ke node lainnya jika simpul saat ini menjadi tidak tersedia.
FCI dapat memanfaatkan Grup Ketersediaan untuk menyediakan pemulihan bencana jarak jauh di tingkat database. Untuk informasi selengkapnya, lihat Pengklusteran Failover dan Grup Ketersediaan (SQL Server).
Catatan
Edisi Pusat Data Windows Server 2016 memperkenalkan dukungan untuk Storage Spaces Direct (S2D). Instans Kluster Failover SQL Server mendukung S2D untuk sumber daya penyimpanan kluster. Untuk informasi selengkapnya, lihat Storage Spaces Direct di Windows Server.
Instans Kluster Failover juga mendukung Volume Bersama Terkluster (CSV). Untuk informasi selengkapnya, lihat Memahami Volume Bersama Kluster dalam Kluster Failover.
Dalam Artikel ini:
Manfaat Instans Kluster Failover
Ketika ada kegagalan perangkat keras atau perangkat lunak server, aplikasi atau klien yang terhubung ke server akan mengalami waktu henti. Ketika instans SQL Server dikonfigurasi untuk menjadi FCI (alih-alih instans mandiri), ketersediaan tinggi instans SQL Server tersebut dilindungi oleh adanya simpul redundan di FCI. Hanya salah satu simpul dalam FCI yang memiliki grup sumber daya WSFC pada satu waktu. Jika terjadi kegagalan (kegagalan perangkat keras, kegagalan sistem operasi, kegagalan aplikasi atau layanan), atau peningkatan yang direncanakan, kepemilikan grup sumber daya dipindahkan ke simpul WSFC lain. Proses ini transparan bagi klien atau aplikasi yang terhubung ke SQL Server dan ini meminimalkan waktu henti yang dialami aplikasi atau klien selama kegagalan. Berikut ini mencantumkan beberapa manfaat utama yang disediakan instans kluster failover SQL Server:
Perlindungan pada tingkat instans melalui redundansi
Failover otomatis jika terjadi kegagalan (kegagalan perangkat keras, kegagalan sistem operasi, kegagalan aplikasi atau layanan)
Penting
Dalam grup ketersediaan, failover otomatis dari FCI ke simpul lain dalam grup ketersediaan tidak didukung. Ini berarti bahwa FCI dan simpul mandiri tidak boleh digabungkan bersama-sama dalam grup ketersediaan jika failover otomatis adalah komponen penting solusi ketersediaan tinggi Anda. Namun, kopling ini dapat dibuat untuk solusi pemulihan bencana Anda.
Dukungan untuk berbagai solusi penyimpanan, termasuk disk kluster WSFC (iSCSI, Fiber Channel, dan sebagainya) dan berbagi file blok pesan server (SMB).
Solusi pemulihan bencana menggunakan FCI multi-subnet atau menjalankan database yang dihosting FCI di dalam grup ketersediaan. Dengan dukungan multi-subnet baru di Microsoft SQL Server 2012 (11.x), FCI multi-subnet tidak lagi memerlukan LAN virtual, meningkatkan pengelolaan dan keamanan FCI multi-subnet.
Tidak ada konfigurasi ulang aplikasi dan klien selama failover
Kebijakan failover fleksibel untuk peristiwa pemicu terperinci untuk failover otomatis
Failover yang andal melalui deteksi kesehatan berkala dan terperinci menggunakan koneksi khusus dan bertahan
Konfigurasi dan prediksi dalam waktu failover melalui titik pemeriksaan latar belakang tidak langsung
Penggunaan sumber daya yang dibatasi selama failover
Rekomendasi
Di lingkungan produksi, kami sarankan Anda menggunakan alamat IP statis bersama alamat IP virtual Instans Kluster Failover. Sebaiknya jangan gunakan DHCP di lingkungan produksi. Jika waktu henti, jika sewa IP DHCP kedaluwarsa, waktu tambahan diperlukan untuk mendaftarkan ulang alamat IP DHCP baru yang terkait dengan nama DNS.
Gambaran Umum Instans Kluster Failover
FCI berjalan dalam grup sumber daya WSFC dengan satu atau beberapa simpul WSFC. Ketika FCI dimulai, salah satu simpul mengasumsikan kepemilikan grup sumber daya dan membawa instans SQL Server-nya secara online. Sumber daya yang dimiliki oleh simpul ini meliputi:
Nama jaringan
Alamat IP
Disk Bersama
Layanan Mesin Database SQL Server
Layanan SQL Server Agent
Layanan SQL Server Analysis Services, jika diinstal
Satu sumber daya berbagi file, jika fitur FILESTREAM diinstal
Kapan saja, hanya pemilik grup sumber daya (dan tidak ada simpul lain dalam FCI) yang menjalankan layanan SQL Server masing-masing dalam grup sumber daya. Ketika failover terjadi, apakah itu failover otomatis atau failover yang direncanakan, urutan peristiwa berikut terjadi:
Kecuali terjadi kegagalan perangkat keras atau sistem, semua halaman kotor dalam cache buffer ditulis ke disk.
Semua layanan SQL Server masing-masing dalam grup sumber daya dihentikan pada simpul aktif.
Kepemilikan grup sumber daya ditransfer ke simpul lain di FCI.
Pemilik grup sumber daya baru memulai layanan SQL Server-nya.
Permintaan koneksi aplikasi klien secara otomatis diarahkan ke simpul aktif baru menggunakan nama jaringan virtual (VNN) yang sama.
FCI online selama kluster WSFC yang mendasarnya berada dalam kondisi kuorum yang baik (sebagian besar node WSFC kuorum tersedia sebagai target failover otomatis). Ketika kluster WSFC kehilangan kuorumnya, baik karena perangkat keras, perangkat lunak, kegagalan jaringan, atau konfigurasi kuorum yang tidak tepat, seluruh kluster WSFC, bersama dengan FCI, dibawa offline. Intervensi manual kemudian diperlukan dalam skenario failover yang tidak direncanakan ini untuk membangun kembali kuorum di node yang tersedia yang tersisa untuk membawa kluster WSFC dan FCI kembali online. Untuk informasi selengkapnya, lihat Mode Kuorum WSFC dan Konfigurasi Pemungutan Suara (SQL Server).
Waktu Failover yang Dapat Diprediksi
Bergantung pada kapan instans SQL Server Anda terakhir kali melakukan operasi titik pemeriksaan, mungkin ada sejumlah besar halaman kotor di cache buffer. Akibatnya, failover berlangsung selama yang diperlukan untuk menulis halaman kotor yang tersisa ke disk, yang dapat menyebabkan waktu failover yang panjang dan tidak dapat diprediksi. Dimulai dengan Microsoft SQL Server 2012 (11.x), FCI dapat menggunakan titik pemeriksaan tidak langsung untuk membatasi jumlah halaman kotor yang disimpan dalam cache buffer. Meskipun ini mengonsumsi sumber daya tambahan di bawah beban kerja reguler, itu membuat waktu failover lebih dapat diprediksi serta lebih dapat dikonfigurasi. Ini sangat berguna ketika perjanjian tingkat layanan di organisasi Anda menentukan tujuan waktu pemulihan (RTO) untuk solusi ketersediaan tinggi Anda. Untuk informasi selengkapnya tentang titik pemeriksaan tidak langsung, lihat Titik Pemeriksaan Tidak Langsung.
Kebijakan Monitor Kondisi andal dan Failover Fleksibel
Setelah FCI berhasil dimulai, layanan WSFC memantau kesehatan kluster WSFC yang mendasar, serta kesehatan instans SQL Server. Dimulai dengan Microsoft SQL Server 2012 (11.x), layanan WSFC menggunakan koneksi khusus untuk melakukan polling instans SQL Server aktif untuk diagnostik komponen terperinci melalui prosedur tersimpan sistem. Implikasi dari ini adalah tiga kali lipat:
Koneksi khusus ke instans SQL Server memungkinkan polling dengan andal untuk diagnostik komponen sepanjang waktu, bahkan ketika FCI berada di bawah beban berat. Hal ini memungkinkan untuk membedakan antara sistem yang berada di bawah beban berat dan sistem yang benar-benar memiliki kondisi kegagalan, sehingga mencegah masalah seperti failover palsu.
Diagnostik komponen terperinci memungkinkan untuk mengonfigurasi kebijakan failover yang lebih fleksibel, di mana Anda dapat memilih kondisi kegagalan apa yang memicu failover dan kondisi kegagalan mana yang tidak.
Diagnostik komponen terperinci juga memungkinkan pemecahan masalah failover otomatis yang lebih baik secara retroaktif. Informasi diagnostik disimpan ke file log, yang dikolokasikan dengan log kesalahan SQL Server. Anda dapat memuatnya ke dalam Penampil File Log untuk memeriksa status komponen menjelang kemunculan failover untuk menentukan penyebab failover tersebut.
Untuk informasi selengkapnya, lihat Kebijakan Failover untuk Instans Kluster Failover
Elemen Instans Kluster Failover
FCI terdiri dari sekumpulan server fisik (node) yang berisi konfigurasi perangkat keras serupa serta konfigurasi perangkat lunak identik yang mencakup versi sistem operasi dan tingkat patch, dan versi SQL Server, tingkat patch, komponen, dan nama instans. Konfigurasi perangkat lunak yang identik diperlukan untuk memastikan bahwa FCI dapat berfungsi penuh karena gagal di antara simpul.
Grup Sumber Daya WSFC
SQL Server FCI berjalan dalam grup sumber daya WSFC. Setiap simpul dalam grup sumber daya mempertahankan salinan pengaturan konfigurasi yang disinkronkan dan kunci registri check-point untuk memastikan fungsionalitas penuh FCI setelah failover, dan hanya salah satu simpul dalam kluster yang memiliki grup sumber daya pada satu waktu (simpul aktif). Layanan WSFC mengelola kluster server, konfigurasi kuorum, kebijakan failover, dan operasi failover, serta VNN dan alamat IP virtual untuk FCI. Jika terjadi kegagalan (kegagalan perangkat keras, kegagalan sistem operasi, kegagalan aplikasi atau layanan) atau peningkatan yang direncanakan, kepemilikan grup sumber daya dipindahkan ke simpul lain di FCI. Jumlah simpul yang didukung dalam grup sumber daya WSFC bergantung pada edisi SQL Server Anda. Selain itu, kluster WSFC yang sama dapat menjalankan beberapa FCI (beberapa grup sumber daya), tergantung pada kapasitas perangkat keras Anda, seperti CPU, memori, dan jumlah disk.
Biner SQL Server
Biner produk dipasang secara lokal pada setiap simpul FCI, proses yang mirip dengan penginstalan mandiri SQL Server. Namun, selama startup, layanan tidak dimulai secara otomatis, tetapi dikelola oleh WSFC.
Penyimpanan
Bertentangan dengan grup ketersediaan, FCI harus menggunakan penyimpanan bersama antara semua simpul FCI untuk database dan penyimpanan log. Penyimpanan bersama dapat berupa disk kluster WSFC, disk pada SAN, Storage Spaces Direct (S2D), atau berbagi file pada SMB. Dengan cara ini, semua simpul dalam FCI memiliki tampilan data instans yang sama setiap kali failover terjadi. Namun, ini berarti bahwa penyimpanan bersama memiliki potensi menjadi titik kegagalan tunggal, dan FCI tergantung pada solusi penyimpanan yang mendasar untuk memastikan perlindungan data.
Nama Jaringan
VNN untuk FCI menyediakan titik koneksi terpadu untuk FCI. Ini memungkinkan aplikasi untuk terhubung ke VNN tanpa perlu mengetahui simpul yang saat ini aktif. Ketika failover terjadi, VNN didaftarkan ke simpul aktif baru setelah dimulai. Proses ini transparan bagi klien atau aplikasi yang terhubung ke SQL Server dan ini meminimalkan waktu henti yang dialami aplikasi atau klien selama kegagalan.
IP virtual
Dalam kasus FCI multi-subnet, alamat IP virtual ditetapkan ke setiap subnet di FCI. Selama failover, VNN di server DNS diperbarui untuk menunjuk ke alamat IP virtual untuk subnet masing-masing. Aplikasi dan klien kemudian dapat terhubung ke FCI menggunakan VNN yang sama setelah failover multi-subnet.
Konsep dan Tugas Failover SQL Server
| Konsep dan Tugas | Artikel |
|---|---|
| Menjelaskan mekanisme deteksi kegagalan dan kebijakan failover yang fleksibel. | Kebijakan Failover untuk Instans Kluster Failover |
| Menjelaskan konsep dalam administrasi dan pemeliharaan FCI. | Administrasi dan Pemeliharaan Instans Kluster Failover |
| Menjelaskan konfigurasi dan konsep multi-subnet | Pengklusteran Multi-Subnet SQL Server (SQL Server) |
Topik Terkait
| Deskripsi topik | Artikel |
|---|---|
| Menjelaskan cara menginstal SQL Server FCI baru. | Membuat Kluster Failover SQL Server Baru (Penyiapan) |
| Menjelaskan cara meningkatkan ke kluster failover SQL Server. | Meningkatkan Instans Kluster Failover SQL Server |
| Menjelaskan Konsep Pengklusteran Failover Windows dan menyediakan tautan ke tugas yang terkait dengan Pengklusteran Failover Windows. | Kluster Failover Windows Server dengan SQL Server |
| Menjelaskan perbedaan dalam konsep antara simpul dalam FCI dan replika dalam grup ketersediaan dan pertimbangan untuk menggunakan FCI untuk menghosting replika untuk grup ketersediaan. | Pengklusteran Failover dan Grup Ketersediaan (SQL Server) |
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk