Terhubung pada listener grup ketersediaan AlwaysOn

Berlaku untuk:SQL Server

Setelah mengonfigurasi pendengar grup ketersediaan, Anda harus memperbarui string koneksi untuk menyambungkan ke listener grup ketersediaan AlwaysOn. Ini akan merutekan lalu lintas dari aplikasi Anda secara otomatis ke replika yang dimaksudkan tanpa harus memperbarui string koneksi secara manual setelah setiap failover.

Koneksi ke replika utama

Tentukan nama DNS pendengar grup ketersediaan di string koneksi untuk menyambungkan ke replika utama untuk akses baca-tulis.

Misalnya, untuk menyambungkan ke replika utama di SQL Server Management Studio melalui pendengar, masukkan nama DNS pendengar di bidang nama server:

Selama failover, ketika replika utama berubah, koneksi yang ada ke pendengar terputus dan koneksi baru dirutekan ke replika utama baru.

Contoh string koneksi dasar untuk penyedia ADO.NET (System.Data.SqlClient):

Server=tcp: AGListener,1433;Database=MyDB;Integrated Security=SSPI  

Anda dapat memverifikasi replika mana yang saat ini Anda sambungkan melalui pendengar dengan menjalankan perintah Transact-SQL (T-SQL) berikut:

SELECT @@SERVERNAME

Misalnya, ketika SQLVM1 adalah replika utama saya:

Anda masih dapat terhubung langsung ke instans SQL Server menggunakan nama instans replika utama atau sekunder alih-alih menggunakan pendengar grup ketersediaan. Namun, Anda kemudian akan kehilangan manfaat koneksi baru yang dirutekan secara otomatis ke replika utama baru saat ini. Selain itu, Anda akan kehilangan manfaat perutean baca-saja, di mana koneksi yang ditentukan dengan read-intent secara otomatis dirutekan ke replika sekunder yang dapat dibaca.

Menyambungkan ke replika baca-saja

Perutean baca-saja mengacu pada perutean koneksi pendengar masuk secara otomatis ke replika sekunder yang dapat dibaca yang dikonfigurasi untuk memungkinkan beban kerja baca-saja.

Koneksi secara otomatis dirutekan ke replika baca-saja jika berikut ini benar:

• Setidaknya satu replika sekunder diatur ke akses baca-saja, dan setiap replika sekunder baca-saja dan replika utama dikonfigurasi untuk mendukung perutean baca-saja.

• string koneksi mereferensikan database yang terlibat dalam Grup Ketersediaan. Alternatif untuk ini adalah login yang digunakan dalam koneksi memiliki database yang dikonfigurasi sebagai database defaultnya. Untuk informasi selengkapnya, lihat artikel ini tentang cara kerja algoritma dengan perutean baca-saja.

• string koneksi mereferensikan pendengar grup ketersediaan, dan niat aplikasi dari koneksi masuk diatur ke baca-saja (misalnya, dengan menggunakan kata kunci Application Intent=ReadOnly di string koneksi ODBC atau OLEDB atau atribut koneksi atau properti).

Atribut niat aplikasi disimpan dalam sesi klien selama masuk dan instans SQL Server kemudian akan memproses niat ini dan menentukan apa yang harus dilakukan sesuai dengan konfigurasi grup ketersediaan dan status baca-tulis database target saat ini di replika sekunder.

Misalnya, untuk menyambungkan ke replika baca-saja menggunakan SQL Server Management Studio, pilih Opsi pada kotak dialog Koneksi ke Server, pilih tab Parameter Koneksi ion tambahan, lalu tentukan ApplicationIntent=ReadOnly dalam kotak teks:

Contoh string koneksi untuk penyedia ADO.NET (System.Data.SqlClient) yang menunjuk niat aplikasi baca-saja:

Server=tcp:AGListener;Database=AdventureWorks;Integrated Security=SSPI;ApplicationIntent=ReadOnly  

Untuk informasi selengkapnya, lihat Mengonfigurasi Akses Baca-Saja pada Replika Ketersediaan (SQL Server)

Port non-default

Saat membuat pendengar, Anda menunjuk port untuk digunakan pendengar. Jika port adalah port default 1433, maka Anda tidak perlu menentukan nomor port saat menyambungkan ke pendengar Anda. Namun, jika port bukan 1433, maka port harus ditentukan dalam string koneksi dalam format listenername,port seperti:

Contoh string koneksi untuk penyedia ADO.NET (System.Data.SqlClient) yang menentukan port non-default untuk pendengar:

Server=tcp:AGListener,1445;Database=AdventureWorks;Integrated Security=SSPI 

Melewati pendengar

Meskipun listener grup ketersediaan mengaktifkan dukungan untuk pengalihan failover dan perutean baca-saja, koneksi klien tidak diperlukan untuk menggunakannya. Koneksi klien juga dapat langsung mereferensikan instans SQL Server alih-alih menyambungkan ke pendengar grup ketersediaan.

Untuk instans SQL Server, tidak relevan apakah koneksi masuk menggunakan listener grup ketersediaan atau menggunakan titik akhir instans lain. Instans SQL Server akan memverifikasi status database yang ditargetkan dan mengizinkan atau melarang konektivitas berdasarkan konfigurasi grup ketersediaan dan status database saat ini pada instans. Misalnya, jika aplikasi klien terhubung langsung ke instans port SQL Server dan terhubung ke database target yang dihosting dalam grup ketersediaan, dan database target dalam status utama dan online, maka konektivitas akan berhasil. Jika database target offline atau dalam status transisi, konektivitas ke database akan gagal.

Atau, saat bermigrasi dari pencerminan database ke grup ketersediaan AlwaysOn, aplikasi dapat menentukan pencerminan database string koneksi selama hanya satu replika sekunder yang ada dan melarang koneksi pengguna.

String koneksi pencerminan database

Jika grup ketersediaan hanya memiliki satu replika sekunder dan dikonfigurasi dengan ALLOW_CONNECTIONS = READ_ONLY atau ALLOW_CONNECTIONS = NONE untuk replika sekunder, klien dapat terhubung ke replika utama dengan menggunakan pencerminan database string koneksi. Pendekatan ini dapat berguna saat memigrasikan aplikasi yang ada dari pencerminan database ke grup ketersediaan, selama Anda membatasi grup ketersediaan ke dua replika ketersediaan (replika utama dan satu replika sekunder). Jika Anda menambahkan replika sekunder tambahan, Anda harus membuat pendengar grup ketersediaan untuk grup ketersediaan dan memperbarui aplikasi Anda untuk menggunakan nama DNS pendengar grup ketersediaan.

Saat menggunakan string koneksi pencerminan database, klien dapat menggunakan SQL Server Native Client atau Penyedia Data .NET Framework untuk SQL Server. string koneksi yang disediakan oleh klien harus secara minimal memberikan nama satu instans server, nama mitra awal, untuk mengidentifikasi instans server yang awalnya menghosting replika ketersediaan yang ingin Anda sambungkan. Secara opsional, string koneksi juga dapat memberikan nama instans server lain, nama mitra failover, untuk mengidentifikasi instans server yang awalnya menghosting replika sekunder sebagai nama mitra failover.

Untuk informasi selengkapnya tentang string koneksi pencerminan database, lihat Koneksi Klien ke Sesi Pencerminan Database (SQL Server).

Failover multi-subnet

Jika Anda menggunakan pustaka klien yang mendukung opsi koneksi MultiSubnetFailover di string koneksi, Anda dapat mengoptimalkan failover grup ketersediaan ke subnet yang berbeda dengan mengatur MultiSubnetFailover ke "True" atau "Ya", tergantung pada sintaks penyedia yang Anda gunakan.

Catatan

Kami merekomendasikan pengaturan ini untuk koneksi tunggal dan multi-subnet ke pendengar grup ketersediaan dan ke nama Instans Kluster Failover SQL Server. Mengaktifkan opsi ini menambahkan pengoptimalan tambahan, bahkan untuk skenario subnet tunggal.

Opsi koneksi MultiSubnetFailover hanya berfungsi dengan protokol jaringan TCP dan hanya didukung saat menyambungkan ke pendengar grup ketersediaan dan untuk nama jaringan virtual apa pun yang terhubung ke SQL Server.

Contoh string koneksi penyedia ADO.NET (System.Data.SqlClient) yang memungkinkan failover multi-subnet adalah sebagai berikut:

Server=tcp:AGListener,1433;Database=AdventureWorks;Integrated Security=SSPI; MultiSubnetFailover=True  

Opsi koneksi MultiSubnetFailover harus diatur ke True meskipun grup ketersediaan hanya mencakup satu subnet. Ini memungkinkan Anda untuk melakukan prakonfigurasi klien baru untuk mendukung rentang subnet di masa mendatang tanpa perlu perubahan string koneksi klien di masa mendatang dan juga mengoptimalkan performa failover untuk failover subnet tunggal. Meskipun opsi koneksi MultiSubnetFailover tidak diperlukan, opsi ini memberikan manfaat dari failover subnet yang lebih cepat. Ini karena driver klien akan mencoba membuka soket TCP untuk setiap alamat IP secara paralel yang terkait dengan grup ketersediaan. Driver klien akan menunggu IP pertama merespons dengan sukses dan setelah itu akan menggunakannya untuk koneksi.

Pendengar & sertifikat TLS/SSL

Saat menyambungkan ke pendengar grup ketersediaan, jika instans SQL Server yang berpartisipasi menggunakan sertifikat TLS/SSL bersama dengan enkripsi sesi, driver klien yang terhubung harus mendukung Nama Alternatif Subjek dalam sertifikat TLS/SSL untuk memaksa enkripsi.

Sertifikat X.509 harus dikonfigurasi untuk setiap simpul server yang berpartisipasi di kluster failover dengan daftar semua pendengar grup ketersediaan yang diatur dalam Nama Alternatif Subjek sertifikat.

Format untuk nilai sertifikat adalah:

CN = Server.FQDN  
SAN = Server.FQDN,Listener1.FQDN,Listener2.FQDN

Misalnya, Anda memiliki nilai berikut:

Servername: Win2019   
Instance: SQL2019   
AG: AG2019   
Listener: Listener2019   
Domain: contoso.com  (which is also the FQDN)

Untuk WSFC yang memiliki grup ketersediaan tunggal, sertifikat harus memiliki nama domain yang sepenuhnya memenuhi syarat (FQDN) server, dan FQDN pendengar:

CN: Win2019.contoso.com
SAN: Win2019.contoso.com, Listener2019.contoso.com 

Dengan konfigurasi ini, koneksi Anda akan dienkripsi saat menyambungkan ke instans (WIN2019\SQL2019), atau pendengar (Listener2019).

Tergantung pada bagaimana jaringan dikonfigurasi, ada subset kecil pelanggan yang mungkin perlu menambahkan NetBIOS ke SAN juga. Dalam hal ini, nilai sertifikat harus:

CN: Win2019.contoso.com
SAN: Win2019,Win2019.contoso.com,Listener2019,Listener2019.contoso.com

Jika WSFC memiliki tiga listener grup ketersediaan, seperti: Listener1, Listener2, Listener3

Maka nilai sertifikat harus:

CN: Win2019.contoso.com
SAN: Win2019.contoso.com,Listener1.contoso.com,Listener2.contoso.com,Listener3.contoso.com

Listener dan Kerberos (SPN)

Administrator domain harus mengonfigurasi Nama Prinsipal Layanan (SPN) di Direktori Aktif untuk setiap pendengar grup ketersediaan untuk mengaktifkan Kerberos untuk koneksi klien ke pendengar. Saat mendaftarkan SPN, Anda harus menggunakan akun layanan instans server yang menghosting replika ketersediaan. Agar SPN berfungsi di semua replika, akun layanan yang sama harus digunakan untuk semua instans di kluster WSFC yang menghosting grup ketersediaan.

Gunakan alat baris perintah Windows setspn untuk mengonfigurasi SPN. Misalnya untuk mengonfigurasi SPN untuk pendengar grup ketersediaan bernama AG1listener.Adventure-Works.com yang dihosting pada sekumpulan instans SQL Server yang semuanya dikonfigurasi untuk dijalankan di bawah akun corp\svclogin2domain :

setspn -A MSSQLSvc/AG1listener.Adventure-Works.com:1433 corp\svclogin2  

Untuk informasi selengkapnya tentang pendaftaran manual SPN untuk SQL Server, lihat Mendaftarkan Nama Perwakilan Layanan untuk Koneksi Kerberos.

Langkah berikutnya

Setelah Anda berhasil terhubung ke pendengar, pertimbangkan untuk membongkar beban kerja baca-saja dan pencadangan ke replika sekunder untuk meningkatkan performa. Anda juga dapat meninjau berbagai strategi pemantauan grup ketersediaan untuk memastikan kesehatan grup ketersediaan Anda.

Untuk informasi selengkapnya tentang grup ketersediaan, lihat Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server).