Mengonfigurasi DNN untuk instans kluster failover

Berlaku untuk:SQL Server di Azure VM

Tip

Ada banyak metode untuk menyebarkan grup ketersediaan. Sederhanakan penyebaran Anda dan hilangkan kebutuhan akan Azure Load Balancer atau nama jaringan terdistribusi (DNN) untuk grup ketersediaan AlwaysOn Anda dengan membuat komputer virtual (VM) SQL Server Anda di beberapa subnet dalam jaringan virtual Azure yang sama. Jika Anda telah membuat grup ketersediaan dalam satu subnet, Anda dapat memigrasikannya ke lingkungan multi-subnet.

Pada Microsoft Azure Virtual Machines, nama jaringan terdistribusi (DNN) merutekan lalu lintas ke sumber daya kluster yang sesuai. Hal ini menyediakan cara yang lebih mudah untuk tersambung ke instans kluster failover SQL Server (FCI) daripada nama jaringan virtual (VNN), tanpa memerlukan Azure Load Balancer.

Artikel ini mengajarkan Anda untuk mengonfigurasi sumber daya DNN untuk merutekan lalu lintas ke instans kluster failover Anda dengan SQL Server di Microsoft Azure Virtual Machines untuk ketersediaan tinggi dan pemulihan bencana (HADR).

Untuk opsi konektivitas alternatif, pertimbangkan nama jaringan virtual dan Azure Load Balancer sebagai gantinya.

Gambaran Umum

Nama jaringan terdistribusi (DNN) menggantikan nama jaringan virtual (VNN) sebagai titik koneksi ketika digunakan dengan instans kluster failover Grup Ketersediaan AlwaysOn pada komputer virtual SQL Server. Hal ini meniadakan kebutuhan akan lalu lintas perutean Azure Load Balancer ke VNN, menyederhanakan penyebaran, pemeliharaan, dan mengatasi kegagalan.

Dengan penyebaran FCI, VNN masih ada, tetapi klien tersambung ke nama DNS DNN, bukan nama VNN.

Prasyarat

Sebelum Anda menyelesaikan langkah-langkah dalam artikel ini, Anda harus sudah:

Membuat sumber daya DNN

Sumber daya DNN dibuat dalam grup kluster yang sama dengan SQL Server FCI. Menggunakan PowerShell untuk membuat sumber daya DNN di dalam grup kluster FCI.

Perintah PowerShell berikut menambahkan sumber daya DNN ke grup kluster SQL Server FCI dengan nama sumber daya <dnnResourceName>. Nama sumber daya digunakan untuk mengidentifikasi sumber daya secara unik. Pilih nama yang masuk akal bagi Anda dan unik di seluruh kluster. Jenis sumber daya harus Distributed Network Name.

Nilai -Group harus berupa nama grup kluster yang sesuai dengan SQL Server FCI di mana Anda ingin menambahkan nama jaringan terdistribusi. Untuk instans default, format khususnya adalah SQL Server (MSSQLSERVER).

Add-ClusterResource -Name <dnnResourceName> `
-ResourceType "Distributed Network Name" -Group "<WSFC role of SQL Server instance>"

Misalnya, untuk membuat sumber daya DNN dnn-demo Anda untuk SQL Server FCI default, gunakan perintah PowerShell berikut ini:

Add-ClusterResource -Name dnn-demo `
-ResourceType "Distributed Network Name" -Group "SQL Server (MSSQLSERVER)"

Mengatur nama DNS DNN kluster

Atur nama DNS untuk sumber daya DNN dalam kluster. Kluster kemudian menggunakan nilai ini untuk merutekan lalu lintas ke simpul yang saat ini menghosting SQL Server FCI.

Klien menggunakan nama DNS untuk menyambungkan ke SQL Server FCI. Anda dapat memilih nilai unik. Atau, jika Anda sudah memiliki FCI dan tidak ingin memperbarui string koneksi klien, Anda dapat mengonfigurasi DNN untuk menggunakan VNN saat ini yang sudah digunakan klien. Untuk melakukannya, Anda perlu mengganti nama VNN sebelum mengatur DNN di DNS.

Gunakan perintah ini untuk mengatur nama DNS untuk DNN Anda:

Get-ClusterResource -Name <dnnResourceName> | `
Set-ClusterParameter -Name DnsName -Value <DNSName>

Nilai DNSName adalah yang digunakan klien untuk tersambung ke SQL Server FCI. Misalnya, untuk klien agar tersambung ke FCIDNN, gunakan perintah PowerShell berikut ini:

Get-ClusterResource -Name dnn-demo | `
Set-ClusterParameter -Name DnsName -Value FCIDNN

Klien sekarang akan masuk ke FCIDNNstring koneksi mereka ketika menyambungkan ke SQL Server FCI.

Peringatan

Jangan hapus nama jaringan virtual (VNN) saat ini karena merupakan komponen yang diperlukan dari infrastruktur FCI.

Mengganti nama VNN

Jika Anda memiliki nama jaringan virtual dan ingin klien terus menggunakan nilai ini untuk tersambung ke SQL Server FCI, Anda harus mengganti nama VNN saat ini menjadi nilai tempat penampung. Setelah VNN saat ini diganti namanya, Anda bisa mengatur nilai nama DNS untuk DNN ke VNN.

Beberapa pembatasan berlaku untuk mengganti nama VNN. Untuk informasi selengkapnya, lihat Mengganti nama FCI.

Jika menggunakan VNN saat ini tidak diperlukan untuk bisnis Anda, lewati bagian ini. Setelah Anda mengganti nama VNN, kemudian atur nama DNS kluster DNN .

Atur sumber daya DNN secara daring

Setelah sumber daya DNN Anda diberi nama yang dengan tepat, dan Anda telah menetapkan nilai nama DNS di kluster, gunakan PowerShell untuk mengatur sumber daya DNN secara daring di kluster:

Start-ClusterResource -Name <dnnResourceName>

Misalnya, untuk memulai sumber daya DNN dnn-demo Anda, gunakan perintah PowerShell berikut:

Start-ClusterResource -Name dnn-demo

Mengonfigurasi kemungkinan pemilik

Secara default, kluster mengikat nama DNS DNN ke semua simpul dalam kluster. Namun, simpul dalam kluster yang bukan bagian dari SQL Server FCI harus dikecualikan dari daftar kemungkinan pemilik DNN.

Untuk memperbarui kemungkinan pemilik, ikuti langkah-langkah berikut:

  1. Buka sumber daya DNN Anda di Pengelola Kluster Failover.

  2. Klik kanan sumber daya DNN dan pilih Properti.

    Shortcut menu for the DNN resource, with the Properties command highlighted.

  3. Kosongkan kotak centang untuk simpul apa pun yang tidak berpartisipasi dalam instans kluster failover. Daftar kemungkinan pemilik untuk sumber daya DNN harus sesuai dengan daftar kemungkinan pemilik untuk sumber daya instans SQL Server. Misalnya, dengan asumsi bahwa Data3 tidak berpartisipasi dalam FCI, gambar berikut adalah contoh menghapus Data3 dari daftar kemungkinan pemilik untuk sumber daya DNN:

    Clear the check box next to the nodes that do not participate in the FCI for possible owners of the DNN resource

  4. Pilih OK untuk menyimpan pengaturan Anda.

Hidupkan ulang instans SQL Server

Gunakan Pengelola Kluster Failover untuk menghidupkan ulang instans SQL Server. Ikuti langkah-langkah ini:

  1. Buka sumber daya SQL Server Anda di Pengelola Kluster Failover.
  2. Klik kanan sumber daya SQL Server, dan buat menjadi luring.
  3. Setelah semua sumber daya terkait sudah luring, klik kanan sumber daya SQL Server dan ubah menjadi daring lagi.

Perbarui string koneksi

Perbarui string koneksi aplikasi apa pun yang terhubung ke SQL Server FCI DNN, dan sertakan MultiSubnetFailover=True dalam string koneksi. Jika klien Anda tidak mendukung parameter MultiSubnetFailover, berarti klien Anda tidak kompatibel dengan DNN.

Berikut adalah contoh string koneksi untuk SQL FCI DNN dengan nama DNS FCIDNN:

Data Source=FCIDNN, MultiSubnetFailover=True

Selain itu, jika DNN tidak menggunakan VNN asli, klien SQL yang tersambung ke SQL Server FCI perlu memperbarui string koneksi mereka ke nama DNS DNN. Untuk menghindari persyaratan ini, Anda bisa memperbarui nilai nama DNS menjadi nama VNN. Tetapi Anda harus mengganti VNN yang ada dengan tempat penampung terlebih dahulu.

Pengujian failover

Uji kegagalan sumber daya dalam kluster untuk memvalidasi fungsionalitas kluster.

Untuk menguji kegagalan, ikuti langkah-langkah berikut:

  1. Sambungkan ke salah satu simpul kluster SQL Server dengan menggunakan RDP.
  2. Buka Pengelola Kluster Failover. Pilih Peran. Perhatikan simpul mana yang memiliki peran SQL Server FCI.
  3. Klik kanan peran SQL Server FCI.
  4. Pilih Pindahkan, lalu pilih Kemungkinan Simpul Terbaik.

Pengelola Kluster Failover menunjukkan peran, dan sumber dayanya menjadi offline. Sumber daya kemudian berpindah dan kembali menjadi daring di simpul lain.

Uji konektivitas

Untuk menguji konektivitas, masuk ke komputer virtual lain dalam jaringan virtual yang sama. Buka SQL Server Management Studio dan sambungkan ke SQL Server FCI dengan menggunakan nama DNS DNN.

Jika perlu, Anda dapat mengunduh SQL Server Management Studio.

Hindari konflik IP

Ini adalah langkah opsional untuk mencegah alamat IP virtual (VIP) yang digunakan oleh sumber daya FCI untuk ditetapkan ke sumber daya lain di Azure sebagai duplikat.

Meskipun pelanggan sekarang menggunakan DNN untuk tersambung ke SQL Server FCI, nama jaringan virtual (VNN) dan IP virtual tidak dapat dihapus karena mereka adalah komponen yang diperlukan dari infrastruktur FCI. Namun, karena tidak ada lagi load balancer yang memesan alamat IP virtual di Azure, ada risiko bahwa sumber daya lain pada jaringan virtual akan diberi alamat IP yang sama dengan alamat IP virtual yang digunakan oleh FCI. Hal ini berpotensi menyebabkan masalah konflik IP duplikat.

Konfigurasikan alamat APIPA atau adaptor jaringan khusus untuk memesan alamat IP.

Alamat APIPA

Untuk menghindari penggunaan alamat IP duplikat, konfigurasikan alamat APIPA (juga dikenal sebagai alamat tautan-lokal). Untuk melakukannya, jalankan perintah berikut:

Get-ClusterResource "virtual IP address" | Set-ClusterParameter 
    –Multiple @{"Address"="169.254.1.1";"SubnetMask"="255.255.0.0";"OverrideAddressMatch"=1;"EnableDhcp"=0}

Dalam perintah ini, "alamat IP virtual" adalah nama sumber alamat VIP kluster, dan "169.254.1.1" adalah alamat APIPA yang dipilih untuk alamat VIP. Pilih alamat yang paling sesuai dengan bisnis Anda. Atur OverrideAddressMatch=1 untuk mengizinkan alamat IP berada di jaringan apa pun, termasuk ruang alamat APIPA.

Adaptor jaringan khusus

Sebagai kemungkinan lain, konfigurasikan adaptor jaringan di Azure untuk memesan alamat IP yang digunakan oleh sumber alamat IP virtual. Namun, ini menggunakan alamat di ruang alamat subnet, dan ada overhead tambahan untuk memastikan adaptor jaringan tidak digunakan untuk tujuan lain.

Pembatasan

  • Klien yang terhubung ke pendengar DNN harus mendukung parameter MultiSubnetFailover=True dalam string koneksi.
  • Mungkin ada lebih banyak pertimbangan ketika Anda bekerja dengan fitur SQL Server lainnya dan FCI dengan DNN. Untuk informasi selengkapnya, lihat FCI dengan interoperabilitas DNN.

Langkah berikutnya

Untuk mempelajari selengkapnya, lihat: