Pengklusteran multi-subnet SQL Server

Berlaku untuk:SQL Server

Kluster failover multisubnet SQL Server merupakan konfigurasi tempat setiap node kluster failover terhubung ke subnet yang berbeda atau sekumpulan subnet yang berbeda. Subnet ini dapat berada di lokasi yang sama atau di situs yang tersebar secara geografis. Kluster di situs yang tersebar secara geografis terkadang disebut sebagai kluster peregangan. Karena tidak ada penyimpanan bersama yang dapat diakses semua simpul, data harus direplikasi antara penyimpanan data pada beberapa subnet. Saat Anda mereplikasi data, ada lebih dari satu salinan data yang tersedia. Oleh karena itu, kluster failover multi-subnet juga menyediakan solusi pemulihan bencana selain menyediakan ketersediaan tinggi.

Kluster failover multi-subnet SQL Server (dua node, dua subnet)

Ilustrasi berikut menggambarkan instans kluster failover (FCI) dengan dua simpul dan dua subnet di SQL Server.

Diagram yang memperlihatkan arsitektur multi-subnet dengan MultiSubnetFailover.

Konfigurasi instans kluster failover multi-subnet

Berikut adalah beberapa contoh FCI SQL Server yang menggunakan beberapa subnet:

  • SQL Server FCI SQLCLUST1 mencakup Node1 dan Node2. Node1 tersambung ke Subnet1. Node2 tersambung ke Subnet2. Penyiapan SQL Server melihat konfigurasi ini sebagai kluster multi-subnet dan mengatur dependensi sumber daya alamat IP ke OR.

  • SQL Server FCI SQLCLUST2 mencakup Node1, Node2, dan Node3. Node1 dan Node2 terhubung ke Subnet1. Node 3 tersambung ke Subnet2. Penyiapan SQL Server melihat konfigurasi ini sebagai kluster multi-subnet dan mengatur dependensi sumber daya alamat IP ke OR. Karena Node1 dan Node2 berada di subnet yang sama, konfigurasi ini menyediakan ketersediaan tinggi lokal tambahan.

  • SQL Server FCI SQLCLUST3 mencakup Node1 dan Node2. Node1 ada di Subnet1. Node2 ada di Subnet1 dan Subnet2. Penyiapan SQL Server melihat konfigurasi ini sebagai kluster multi-subnet dan mengatur dependensi sumber daya alamat IP ke OR.

  • SQL Server FCI SQLCLUST4 mencakup Node1 dan Node2. Node1 terhubung ke Subnet1 dan Subnet2. Node2 juga terhubung ke Subnet1 dan Subnet2. Penyiapan SQL Server mengatur dependensi sumber daya alamat IP ke AND.

    Catatan

    Konfigurasi ini tidak dianggap sebagai konfigurasi kluster failover multi-subnet karena simpul kluster berada pada kumpulan subnet yang sama.

Pertimbangan sumber daya alamat IP

Dalam konfigurasi kluster failover multi-subnet, alamat IP tidak dimiliki oleh semua simpul di kluster failover, dan semuanya mungkin tidak online selama startup SQL Server. Mulai dari SQL Server 2012 (11.x), Anda dapat mengatur dependensi sumber daya alamat IP ke OR. Melakukannya memungkinkan SQL Server untuk online ketika setidaknya ada satu alamat IP valid yang dapat diikatnya.

Catatan

Dalam versi SQL Server sebelum SQL Server 2012 (11.x), teknologi stretch V-LAN digunakan dalam konfigurasi kluster multi-situs untuk menyediakan satu alamat IP bagi failover antar situs. Sekarang setelah SQL Server dapat mengkluster simpul di berbagai subnet, Anda dapat mengonfigurasi kluster failover SQL Server di beberapa situs tanpa menerapkan teknologi stretch V-LAN.

Sumber daya alamat IP ATAU pertimbangan dependensi

Anda mungkin ingin mempertimbangkan perilaku failover berikut jika Anda mengatur dependensi sumber daya alamat IP ke OR:

  • Ketika ada kegagalan salah satu alamat IP pada simpul yang saat ini memiliki grup sumber daya kluster SQL Server, failover tidak dipicu secara otomatis sampai semua alamat IP valid pada simpul tersebut gagal.

  • Ketika failover terjadi, SQL Server akan aktif jika dapat terikat ke setidaknya satu alamat IP yang valid pada node saat ini. Alamat IP yang tidak mengikat ke SQL Server saat startup akan tercantum dalam log kesalahan.

Ketika SQL Server FCI dipasang berdampingan dengan instans mandiri Mesin Database SQL Server, berhati-hatilah untuk menghindari konflik nomor port TCP pada alamat IP. Konflik biasanya terjadi ketika dua instans Mesin Database dikonfigurasi untuk menggunakan port TCP default (1433). Untuk menghindari konflik, konfigurasikan satu instans untuk menggunakan port tetap nondefault. Mengonfigurasi port tetap biasanya lebih mudah pada instans mandiri. Mengonfigurasi Mesin Database untuk menggunakan port yang berbeda mencegah konflik alamat IP/ port TCP yang tidak terduga yang memblokir startup instans ketika SQL Server FCI gagal ke simpul siaga.

Latensi pemulihan klien selama failover

Secara bawaan, FCI multisubnet mengaktifkan sumber daya kluster RegisterAllProvidersIP pada nama jaringannya. Dalam konfigurasi multi-subnet, alamat IP online dan offline dari nama jaringan keduanya terdaftar di server DNS. Aplikasi klien kemudian mengambil semua alamat IP terdaftar dari server DNS dan mencoba menyambungkan ke alamat, baik secara berurutan atau paralel. Ini berarti bahwa waktu pemulihan klien dalam failover multi-subnet tidak lagi bergantung pada latensi pembaruan DNS. Secara default, klien mencoba alamat IP secara berurutan. Ketika klien menggunakan parameter opsional MultiSubnetFailover=True dalam string koneksinya, klien akan mencoba alamat IP secara bersamaan dan terhubung ke server pertama yang merespons. Konfigurasi ini dapat membantu meminimalkan latensi pemulihan klien saat failover terjadi. Untuk informasi selengkapnya, lihat Konektivitas klien AlwaysOn (SQL Server) dan Membuat atau mengonfigurasi listener grup ketersediaan (SQL Server).

Dengan pustaka klien warisan atau penyedia data non-Microsoft, Anda tidak dapat menggunakan parameter MultiSubnetFailover dalam string koneksi Anda. Untuk membantu memastikan bahwa aplikasi klien Anda berfungsi secara optimal dengan FCI multi-subnet di SQL Server, coba sesuaikan batas waktu koneksi dalam string koneksi klien sebesar 21 detik untuk setiap alamat IP tambahan. Konfigurasi ini memastikan bahwa upaya koneksi ulang klien tidak kehabisan waktu sebelum dapat menelusuri semua alamat IP di FCI multi-subnet Anda.

Periode batas waktu koneksi klien default untuk SQL Server Management Studio dan sqlcmd adalah 15 detik.

Catatan

Jika Anda menggunakan beberapa subnet dan memiliki DNS statis, Anda harus memiliki proses untuk memperbarui catatan DNS yang terkait dengan pendengar sebelum Anda melakukan failover. Jika tidak, nama jaringan tidak akan aktif.