Membantu! Saya Tidak Dapat Menghubungkan Ke Server Saya Multi-Subnet Failover Cluster
Banyak pelanggan saya yang mengalami masalah ini. Untuk mengatasinya, saya biasanya memberi tahu mereka hal-hal berikut
Tautan itu memiliki semua yang perlu Anda ketahui.
Mereka tidak menjelaskan secara detail tentang apa yang harus dilakukan jika koneksi Anda tidak mendukung multisubnetfailover = true. Jika koneksi Anda TIDAK mendukung parameter itu, kemudian setel register ke server palsu dan bersihkan DNS. Prosedur itu dijelaskan paling baik di sini.
Bagaimana SQL Server Multi-Subnet Failover Cluster Sebenarnya Bekerja?
Secara umum orang tidak mengetahui bagaimana SQL Server Multi-Subnet Failover Cluster bekerja. Dukungan pengelompokan failover multi-subnet ditambahkan di Windows Server 2012 dengan penambahan teknologi “ATAU” ketika menentukan ketergantungan sumber gugus. Ini memungkinkan orang untuk mengizinkan sumber daya Cluster Name bergantung pada Alamat IP x.x.x.x ATAU Alamat IP y.y.y.y.
x.x.x.x akan menjadi sumber daya IP kluster yang valid di Subnet A. y.y.y.y akan menjadi alamat IP kluster yang valid di Subnet B. Hanya satu alamat yang akan online pada waktu tertentu, alamat mana yang valid untuk subnet sumber daya yang sedang berjalan.
Microsoft SQL Server mulai mendukung konsep ini dimulai dengan SQL Server 2012 dengan kedua instance failover cluster (FCI) menggunakan solusi pengelompokan SANless 3-pihak seperti SIOS DataKeeper dan SQL Server Always On Availability Groups.
Secara default jika Anda membuat SQL Server Multi-Subnet Failover Cluster, klaster harus secara otomatis dikonfigurasi secara optimal. Ini termasuk mengatur dua alamat IP, menambahkan dua record A ke DNS dan mengatur registerallprovidersIP menjadi true. Namun, di sisi klien, Anda harus memberi tahu bahwa Anda terhubung ke kluster failover multi-subnet, jika tidak, koneksi tidak akan dibuat.
Mengkonfigurasi Klien
Mengkonfigurasi klien dilakukan dengan menambahkan multisubnetfailover = true ke string koneksi. Dokumentasi Microsoft ini adalah sumber yang bagus. Tetapi jika Anda hanya mencari multisubnetfailover = true Anda akan menemukan banyak informasi tentang pengaturan itu.
Jangan itu tidak setiap aplikasi akan mendukung menambahkan itu ke string koneksi. Jika Anda menemukan diri Anda dalam situasi itu, Anda harus meminta vendor aplikasi Anda untuk menambahkan dukungan untuk itu atau menunjukkan kepada Anda bagaimana melakukannya.
Jangan khawatir. Semua tidak hilang jika Anda menemukan diri Anda dalam situasi itu. Anda akan ingin mengubah perilaku kluster sehingga pada saat failover DNS diperbarui, sehingga record A tunggal yang terkait dengan titik akses klien kluster akan diperbarui dengan alamat IP yang baru. Ini adalah pengganti dua catatan A dalam DNS, satu dengan setiap alamat IP cluster, yang merupakan perilaku default dalam cluster multi-subnet.
Bantuan Ada Di Jalan
Artikel ini referensi SharePoint, Anda dapat mengabaikan itu, sisa artikel ditulis dengan cukup baik untuk menggambarkan proses yang harus Anda ikuti.
Sorotan dari artikel itu adalah sebagai berikut …
Dapatkan-ClusterResource "[Nama Jaringan]" | Set-ClusterParameter RegisterAllProvidersIP 0Setelah memulai kembali objek-nama-cluster (pada dasarnya memulai kembali peran) & membersihkan semua "A" catatan secara manual (pembersihan tidak dilakukan secara otomatis) kita dapat melihat A-records lama kita masih dalam DNS jadi kita perlu untuk menghapusnya secara manual.
Selain langkah-langkah tersebut, saya menyarankan Anda untuk mengurangi TTL pada HostRecordTTL seperti yang dijelaskan dalam artikel ini.
Sorotan dari artikel itu adalah sebagai berikut.
PS C: > Dapatkan-ClusterResource –Name cluster1FS | Set-ClusterParameter -Name HostRecordTTL -Nilai 300
Dengan Nilai 300, Anda berpotensi menunggu hingga 5 menit agar klien Anda terhubung kembali setelah kegagalan, atau bahkan lebih lama jika memiliki infrastruktur Active Directory yang besar dan replikasi AD membutuhkan waktu untuk memperbarui semua server DNS di seluruh infrastruktur Anda.
Anda akan ingin mencari tahu apa TTL yang optimal untuk memfasilitasi rekoneksi klien cepat tanpa lebih membebani server DNS Anda dengan sekelompok permintaan Pencarian DNS.
Jenis konfigurasi ini umum dalam konfigurasi pemulihan bencana di mana situs DR Anda berada di subnet yang berbeda. Hal ini juga sangat umum dalam penyebaran HA di AWS karena Zona Ketersediaan berbeda dalam subnet yang berbeda.
Beri tahu saya jika Anda memiliki pertanyaan tentang SQL Server Multi-Subnet Failover Cluster. Anda selalu dapat menghubungi saya di Twitter @daveberm
Sebuah jaringan yang berfungsi dengan benar di Azure [/ caption]
Hal pertama yang saya lakukan adalah menaikkan instance saya yang ada ke D64sv3 dan menggunakan -P 64. Saya melihat peningkatan yang signifikan
. Melihat kembali pada umpan Twitter, sepertinya masalah awalnya dimulai satu atau dua jam sebelum itu. 
Dengan cepat menjadi jelas bahwa pemadaman memiliki dampak penyebaran yang lebih luas daripada hanya wilayah AS Tengah Selatan seperti yang dilaporkan semula. Sepertinya layanan yang bergantung pada Azure Active Directory dapat berdampak juga dan pelanggan yang mencoba menyediakan langganan baru mengalami masalah. 
Dan 24 jam kemudian masalah belum sepenuhnya teratasi dan sesuai dengan pembaruan terakhir pagi ini … Jadi apa y
a
ng bisa Anda lakukan untuk meminimalkan dampak dari gangguan awan biru ini? Tidak ada yang bisa menyalahkan Microsoft atas bencana alam seperti sambaran petir. Tetapi pada akhir hari jika satu-satunya rencana pemulihan bencana Anda adalah menelepon, men-tweet, dan mengirim email ke Microsoft hingga masalah teratasi, Anda baru saja menerima kebangkitan yang kasar. Terserah Anda untuk memastikan bahwa semua basis tercakup ketika datang ke rencana pemulihan bencana Anda.