Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Berlaku untuk:
SQL Server
Artikel ini memberikan petunjuk cara menyambungkan ke sebuah listener grup ketersediaan Always On untuk SQL Server. Pendengar grup ketersediaan adalah nama jaringan virtual yang digunakan klien untuk menyambungkan ke database yang dihosting dalam grup ketersediaan. Pendengar menyediakan titik akhir koneksi yang konsisten untuk aplikasi klien, terlepas dari replika ketersediaan mana yang saat ini menghosting database utama. Pendengar juga memungkinkan dukungan untuk perutean baca-saja dan failover otomatis.
Setelah mengonfigurasi pendengar, perbarui string koneksi Anda untuk mengarahkan ke pendengar sehingga lalu lintas aplikasi secara otomatis dirutekan ke replika yang dimaksudkan tanpa harus memperbarui string koneksi secara manual setelah setiap failover.
Menyambungkan ke replika utama
Tentukan nama DNS pendengar grup ketersediaan dalam string koneksi untuk menghubungkan ke replika utama guna 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 listener terputus dan koneksi baru dirutekan ke replika utama yang baru.
Contoh string koneksi dasar untuk penyedia ADO.NET (Microsoft.Data.SqlClient atau System.Data.SqlClient):
Server=tcp: AGListener,1433;Database=MyDB;Integrated Security=SSPI
Catatan
Microsoft.Data.SqlClient adalah penyedia data ADO.NET yang direkomendasikan untuk pengembangan aplikasi baru. Ini mendukung kata kunci string koneksi yang sama dengan System.Data.SqlClient. Untuk informasi selengkapnya, lihat Pengenalan namespace Microsoft.Data.SqlClient.
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:
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 ketentuan berikut dipenuhi:
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 algoritma bekerja 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 tujuan aplikasi disimpan dalam sesi klien selama login. Instans SQL Server memproses niat 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 dengan menggunakan SQL Server Management Studio, pilih Opsi pada kotak dialog Sambungkan ke Server , pilih tab Parameter Koneksi Tambahan , lalu tentukan ApplicationIntent=ReadOnly dalam kotak teks:
Contoh string koneksi untuk penyedia ADO.NET (Microsoft.Data.SqlClient atau 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 tidak standar
Saat membuat pendengar jaringan, Anda menetapkan port yang akan digunakan oleh 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 (Microsoft.Data.SqlClient atau System.Data.SqlClient) yang menentukan port nondefault untuk pendengar:
Server=tcp:AGListener,1445;Database=AdventureWorks;Integrated Security=SSPI
Mengabaikan pendengar acara
Meskipun listener grup ketersediaan memungkinkan dukungan untuk pengalihan failover dan perutean baca-saja, koneksi klien tidak diwajibkan 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 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 berhasil. Jika database target offline atau dalam status transisi, konektivitas ke database gagal.
Atau, saat bermigrasi dari pencerminan database ke grup ketersediaan Always On, aplikasi dapat menentukan string koneksi pencerminan database selama hanya ada satu replika sekunder 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 setidaknya menyertakan nama satu instans server, nama mitra awal, untuk mengidentifikasi instans server yang awalnya menghosting replika ketersediaan yang ingin Anda hubungi. Secara opsional, string koneksi juga dapat menyertakan nama instans server lain, yaitu nama mitra failover, untuk mengidentifikasi instans server yang awalnya menghosting replika sekunder sebagai mitra failover.
Untuk informasi selengkapnya tentang string koneksi pencerminan database, lihat Menyambungkan 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 (Microsoft.Data.SqlClient atau 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. Opsi ini memungkinkan Anda 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. Driver klien mencoba membuka soket TCP untuk setiap alamat IP secara paralel yang terkait dengan grup ketersediaan. Driver klien menunggu IP pertama untuk merespons dengan sukses dan setelah itu, menggunakannya untuk koneksi.
Pendengar dan sertifikat TLS/SSL
Saat terhubung ke listener grup ketersediaan, jika instans SQL Server yang berpartisipasi menggunakan sertifikat TLS/SSL bersamaan dengan enkripsi sesi, driver klien yang terhubung perlu mendukung Subject Alternative Name di 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 satu grup ketersediaan, sertifikat harus mencantumkan nama domain yang sepenuhnya memenuhi syarat (FQDN) dari server, serta FQDN dari pendengar.
CN: Win2019.contoso.com
SAN: Win2019.contoso.com, Listener2019.contoso.com
Dengan konfigurasi ini, koneksi Anda 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 pendengar 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 Service Principal Name (SPN) di Active Directory untuk setiap listener kelompok ketersediaan guna mengaktifkan Kerberos untuk koneksi klien ke listener. 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.