Bagikan melalui

Listener Grup Ketersediaan, Konektivitas Klien, dan Kegagalan Aplikasi (SQL Server)

  • Artikel

Topik ini berisi informasi tentang pertimbangan untuk konektivitas klien Grup Ketersediaan AlwaysOn dan fungsionalitas failover aplikasi.

Catatan

Untuk sebagian besar konfigurasi pendengar umum, Anda dapat membuat listener grup ketersediaan pertama hanya dengan menggunakan pernyataan Transact-SQL atau cmdlet PowerShell. Untuk informasi selengkapnya, lihat Tugas Terkait, nanti dalam topik ini.

Pendengar Grup Ketersediaan

Anda dapat menyediakan konektivitas klien ke database grup ketersediaan tertentu dengan membuat pendengar grup ketersediaan. Pendengar grup ketersediaan adalah nama jaringan virtual (VNN) yang dapat disambungkan klien untuk mengakses database dalam replika utama atau sekunder dari grup ketersediaan AlwaysOn. Pendengar grup ketersediaan memungkinkan klien untuk terhubung ke replika ketersediaan tanpa mengetahui nama instans fisik SQL Server yang disambungkan klien. String koneksi klien tidak perlu dimodifikasi untuk menyambungkan ke lokasi replika utama saat ini.

Pendengar grup ketersediaan terdiri dari nama pendengar Sistem Nama Domain (DNS), penugasan port pendengar, dan satu atau beberapa alamat IP. Hanya protokol TCP yang didukung oleh pendengar grup ketersediaan. Nama DNS pendengar juga harus unik di domain dan di NetBIOS. Saat Anda membuat listener grup ketersediaan baru, itu menjadi sumber daya dalam kluster dengan nama jaringan virtual (VNN) terkait, IP virtual (VIP), dan dependensi grup ketersediaan. Klien menggunakan DNS untuk mengatasi VNN menjadi beberapa alamat IP lalu mencoba menyambungkan ke setiap alamat, hingga permintaan koneksi berhasil atau hingga waktu permintaan koneksi habis.

Jika perutean baca-saja dikonfigurasi untuk satu atau beberapareplika sekunder yang dapat dibaca, koneksi klien niat baca ke replika utama dialihkan ke replika sekunder yang dapat dibaca. Selain itu, jika replika utama offline pada satu instans SQL Server, dan replika utama baru online pada instans SQL Server lain, listener grup ketersediaan memungkinkan klien untuk terhubung ke replika utama baru.

Untuk informasi penting tentang listener grup ketersediaan, lihat Membuat atau Mengonfigurasi Listener Grup Ketersediaan (SQL Server).

Konfigurasi Listener Grup Ketersediaan

Pendengar grup ketersediaan ditentukan oleh yang berikut:

Nama DNS unik
Ini juga dikenal sebagai nama Virtual Network (VNN). Aturan penamaan Direktori Aktif untuk nama host DNS berlaku. Untuk informasi selengkapnya, lihat konvensi Penamaan di Direktori Aktif untuk komputer, domain, situs, dan artikel KB OU.

Satu atau beberapa alamat IP Virtual (VIP)
VIP dikonfigurasi untuk satu atau beberapa subnet tempat grup ketersediaan dapat melakukan failover.

Konfigurasi alamat IP
Untuk pendengar grup ketersediaan tertentu, alamat IP menggunakan Dynamic Host Configuration Protocol (DHCP) atau satu atau beberapa alamat IP statis.

  • DHCP (Dynamic Host Configuration Protocol)

    Jika grup ketersediaan berada di satu subnet, Anda dapat mengonfigurasi semua alamat IP listener grup ketersediaan untuk menggunakan DHCP. Untuk lingkungan pra-produksi, DHCP menawarkan penyiapan mudah untuk grup ketersediaan yang tidak memerlukan pemulihan bencana ke situs jarak jauh pada subnet terpisah. Namun, Anda tidak boleh menggunakan DHCP bersama dengan pendengar grup ketersediaan di lingkungan produksi. Ini karena, jika waktu henti, jika sewa IP DHCP kedaluwarsa, waktu tambahan diperlukan untuk mendaftarkan kembali alamat IP DHCP baru yang terkait dengan nama DNS pendengar. Waktu tambahan akan menyebabkan kegagalan koneksi klien.

  • Alamat IP statis

    Di lingkungan produksi, sebaiknya listener grup ketersediaan menggunakan alamat IP statis. Selain itu, di mana grup ketersediaan diperluas di seluruh subnet di domain multi-subnet, pendengar grup ketersediaan harus menggunakan alamat IP statis.

Konfigurasi jaringan hibrid dan DHCP di seluruh subnet tidak didukung untuk listener grup ketersediaan. Ini karena ketika failover terjadi, IP dinamis mungkin kedaluwarsa atau dirilis, yang membahmi ketersediaan tinggi secara keseluruhan.

Memilih Port Pendengar Grup Ketersediaan

Saat mengonfigurasi pendengar grup ketersediaan, Anda harus menunjuk port. Anda dapat mengonfigurasi port default ke 1433 untuk memungkinkan kesederhanaan string koneksi klien. Jika menggunakan 1433, Anda tidak perlu menunjuk nomor port dalam string koneksi. Selain itu, karena setiap pendengar grup ketersediaan akan memiliki nama jaringan virtual terpisah, setiap pendengar grup ketersediaan yang dikonfigurasi pada satu WSFC dapat dikonfigurasi untuk mereferensikan port default yang sama 1433.

Anda juga dapat menunjuk port pendengar non-standar; namun ini berarti bahwa Anda juga perlu secara eksplisit menentukan port target dalam string koneksi Anda setiap kali menyambungkan ke listener grup ketersediaan. Anda juga perlu membuka izin pada firewall untuk port non-standar.

Jika Anda menggunakan port default 1433 untuk VPN pendengar grup ketersediaan, Anda masih perlu memastikan bahwa tidak ada layanan lain pada node kluster yang menggunakan port ini; jika tidak, ini akan menyebabkan konflik port.

Jika salah satu instans SQL Server sudah mendengarkan pada port TCP 1433 melalui pendengar instans dan tidak ada layanan lain (termasuk instans tambahan SQL Server) di komputer yang mendengarkan port 1433, ini tidak akan menyebabkan konflik port dengan listener grup ketersediaan. Ini karena listener grup ketersediaan dapat berbagi port TCP yang sama di dalam proses layanan yang sama. Namun beberapa instans SQL Server (berdampingan) tidak boleh dikonfigurasi untuk mendengarkan pada port yang sama.

Menggunakan Listener untuk Menyambungkan ke Replika Utama

Untuk menggunakan pendengar grup ketersediaan untuk menyambungkan ke replika utama untuk akses baca-tulis, string koneksi menentukan nama DNS pendengar grup ketersediaan. Jika replika utama grup ketersediaan berubah ke replika baru, koneksi yang ada yang menggunakan nama jaringan pendengar grup ketersediaan terputus. Koneksi baru ke pendengar grup ketersediaan kemudian diarahkan ke replika utama baru. Contoh string koneksi dasar untuk penyedia ADO.NET (System.Data.SqlClient) adalah sebagai berikut:

Server=tcp: AGListener,1433;Database=MyDB;IntegratedSecurity=SSPI

Anda masih dapat memilih untuk langsung mereferensikan instans nama SQL Server replika utama atau sekunder alih-alih menggunakan nama server pendengar grup ketersediaan, namun jika Anda memilih untuk melakukannya, Anda akan kehilangan manfaat koneksi baru yang diarahkan secara otomatis ke replika utama saat ini. Anda juga akan kehilangan manfaat perutean baca-saja.

Menggunakan Listener untuk Menyambungkan ke Replika Sekunder Read-Only (Perutean Baca-Saja)

Perutean baca-saja mengacu pada kemampuan SQL Server untuk merutekan koneksi masuk ke pendengar grup ketersediaan ke replika sekunder yang dikonfigurasi untuk memungkinkan beban kerja baca-saja. Koneksi masuk yang mereferensikan nama pendengar grup ketersediaan dapat 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. Untuk informasi selengkapnya, lihat Mengonfigurasi Replika Ketersediaan untuk perutean Read-Only, nanti di bagian ini.

  • 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). Untuk informasi selengkapnya, lihat Niat Aplikasi Baca-Saja dan Perutean Read-Only, nanti di bagian ini.

Untuk Mengonfigurasi Replika Ketersediaan untuk Perutean Read-Only

Administrator database harus mengonfigurasi replika ketersediaan sebagai berikut:

  1. Untuk setiap replika ketersediaan yang ingin Anda konfigurasi sebagai replika sekunder yang dapat dibaca, administrator database harus mengonfigurasi pengaturan berikut, yang hanya berlaku di bawah peran sekunder:

    • Akses koneksi harus diatur ke "semua" atau "baca saja".

    • URL perutean baca-saja harus ditentukan.

  2. Untuk setiap replika ini, daftar perutean baca-saja harus ditentukan untuk peran utama. Tentukan satu atau beberapa nama server sebagai target perutean.

Tugas Terkait

Read-Only Niat Aplikasi dan Perutean Read-Only

Properti string koneksi niat aplikasi mengekspresikan permintaan aplikasi klien untuk diarahkan baik ke versi baca-tulis atau baca-saja dari database grup ketersediaan. Untuk menggunakan perutean baca-saja, klien harus menggunakan niat aplikasi baca-saja dalam string koneksi saat menyambungkan ke pendengar grup ketersediaan. Tanpa niat aplikasi baca-saja, koneksi ke pendengar grup ketersediaan diarahkan ke database pada replika utama.

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.

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

Server=tcp:AGListener,1433;Database=AdventureWorks;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly

Dalam contoh string koneksi ini, klien mencoba menyambungkan ke pendengar grup ketersediaan bernama AGListener pada port 1433 (Anda juga dapat menghilangkan port jika listener grup ketersediaan mendengarkan pada 1433). String koneksi memiliki properti yang ApplicationIntent diatur ke ReadOnly, menjadikan ini string koneksi niat baca. Tanpa pengaturan ini, server tidak akan mencoba perutean koneksi baca-saja.

Database utama grup ketersediaan memproses permintaan perutean baca-saja yang masuk dan mencoba menemukan replika online baca-saja yang bergabung ke replika utama dan dikonfigurasi untuk perutean baca-saja. Klien menerima kembali informasi koneksi dari server replika utama dan terhubung ke replika baca-saja yang diidentifikasi.

Perhatikan bahwa niat aplikasi dapat dikirim dari driver klien ke instans SQL Server tingkat bawah. Dalam hal ini, niat aplikasi baca-saja diabaikan dan koneksi berlanjut seperti biasa.

Anda dapat melewati perutean baca-saja dengan tidak mengatur properti koneksi niat aplikasi ke ReadOnly (ketika tidak ditunjuk, defaultnya adalah ReadWrite selama masuk) atau dengan menyambungkan langsung ke instans replika utama SQL Server alih-alih menggunakan nama pendengar grup ketersediaan. Perutean baca-saja juga tidak akan terjadi jika Anda terhubung langsung ke replika baca-saja.

Tugas Terkait

Melewati Listener Grup Ketersediaan

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 berada 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 string koneksi pencerminan database selama hanya ada satu replika sekunder dan melarang koneksi pengguna. Untuk informasi selengkapnya, lihat Menggunakan String Koneksi Database-Mirroring dengan Grup Ketersediaan, nanti di bagian ini.

Menggunakan String Koneksi Pencerminan Database dengan Grup Ketersediaan

Jika grup ketersediaan hanya memiliki satu replika sekunder dan tidak dikonfigurasi untuk mengizinkan akses baca ke replika sekunder, klien dapat terhubung ke replika utama dengan menggunakan string koneksi pencerminan database. 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 Penyedia Data SQL Server Native Client atau .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 Menyambungkan Klien ke Sesi Pencerminan Database (SQL Server).

Perilaku Koneksi Klien pada Failover

Ketika failover grup ketersediaan terjadi, koneksi persisten yang ada ke grup ketersediaan dihentikan dan klien harus membuat koneksi baru untuk terus bekerja dengan database utama yang sama atau database sekunder baca-saja. Saat failover terjadi di sisi server, konektivitas ke grup ketersediaan mungkin gagal, memaksa aplikasi klien untuk mencoba kembali menyambungkan sampai primer sepenuhnya kembali online.

Jika grup ketersediaan kembali online selama upaya koneksi aplikasi klien tetapi sebelum periode batas waktu koneksi, driver klien mungkin berhasil terhubung selama salah satu upaya coba lagi internalnya dan tidak ada kesalahan yang akan muncul ke aplikasi dalam hal ini.

Mendukung Failover Multi-Subnet Grup Ketersediaan

Jika Anda menggunakan pustaka klien yang mendukung opsi koneksi MultiSubnetFailover dalam 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 untuk SQL Server nama Instans Kluster Failover. Mengaktifkan opsi ini menambahkan pengoptimalan tambahan, bahkan untuk skenario subnet tunggal.

Opsi MultiSubnetFailover koneksi 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 2014.

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

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

Opsi MultiSubnetFailover koneksi harus diatur ke True meskipun grup ketersediaan hanya mencakup satu subnet. Ini memungkinkan Anda untuk mengonfigurasi klien baru terlebih dahulu untuk mendukung rentang subnet di masa mendatang tanpa perlu perubahan string koneksi klien di masa mendatang dan juga mengoptimalkan performa failover untuk kegagalan subnet tunggal. MultiSubnetFailover Meskipun opsi koneksi tidak diperlukan, opsi ini memberikan manfaat dari kegagalan 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.

Listener Grup Ketersediaan dan Sertifikat SSL

Saat menyambungkan ke pendengar grup ketersediaan, jika instans SQL Server yang berpartisipasi menggunakan sertifikat SSL bersama dengan enkripsi sesi, driver klien yang terhubung harus mendukung Nama Alternatif Subjek dalam sertifikat SSL untuk memaksa enkripsi. SQL Server dukungan driver untuk sertifikat Subject Alternative Name direncanakan untuk ADO.NET (SqlClient), Microsoft JDBC dan SQL Native Client (SNAC).

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.

Misalnya, jika WSFC memiliki tiga listener grup ketersediaan dengan nama AG1_listener.Adventure-Works.com, , AG2_listener.Adventure-Works.comdan AG3_listener.Adventure-Works.com, Nama Alternatif Subjek untuk sertifikat harus ditetapkan sebagai berikut:

CN = ServerFQDN  
SAN = ServerFQDN,AG1_listener.Adventure-Works.com, AG2_listener.Adventure-Works.com, AG3_listener.Adventure-Works.com

Listener Grup Ketersediaan dan Nama Prinsipal Server (SPN)

Nama Prinsipal Server (SPN) harus dikonfigurasi di Direktori Aktif oleh administrator domain untuk setiap nama pendengar grup ketersediaan untuk mengaktifkan Kerberos untuk koneksi klien ke pendengar grup ketersediaan. 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.

setspn Gunakan alat baris perintah Windows untuk mengonfigurasi SPN. Misalnya untuk mengonfigurasi SPN untuk grup ketersediaan bernama AG1listener.Adventure-Works.com yang dihosting pada sekumpulan instans SQL Server semua 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.

Tugas Terkait

Konten terkait

Lihat juga

Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server)
Konektivitas Klien AlwaysOn (SQL Server)
Tentang Akses Koneksi Klien ke Replika Ketersediaan (SQL Server)
Sekunder Aktif: Replika Sekunder yang Dapat Dibaca (Grup Ketersediaan AlwaysOn)
Menyambungkan Klien ke Sesi Pencerminan Database (SQL Server)