Mengonfigurasi Jaringan Khusus untuk Komunikasi Grup Ketersediaan

Grup Ketersediaan AlwaysOn SQL Server 2012 memerlukan titik akhir pencerminan basis data untuk setiap contoh SQL Server yang akan menjadi tuan rumah replika grup ketersediaan dan/atau sesi pencerminan basis data. Titik akhir contoh SQL Server ini kemudian dibagikan oleh satu atau beberapa replika grup ketersediaan dan/atau sesi pencerminan database dan merupakan mekanisme untuk komunikasi antara replika utama dan replika sekunder terkait.

Bergantung pada beban kerja modifikasi data pada replika utama, persyaratan throughput perpesanan grup ketersediaan bisa jadi tidak sepele. Aktivitas ini juga sensitif terhadap lalu lintas dari aktivitas grup non-ketersediaan bersamaan. Jika throughput menderita karena bandwidth terdegradasi dan lalu lintas bersamaan, Anda dapat mempertimbangkan untuk mengisolasi lalu lintas grup ketersediaan ke adaptor jaringan khusus miliknya sendiri untuk setiap instans SQL Server yang menghosting replika ketersediaan. Postingan ini akan menjelaskan proses ini dan juga menjelaskan secara singkat apa yang mungkin Anda harapkan dalam skenario throughput yang menurun.

Untuk artikel ini, saya menggunakan lima node virtual guest Windows Server Failover Cluster (WSFC). Setiap node di WSFC memiliki instance SQL Server sendiri yang berdiri sendiri menggunakan penyimpanan lokal yang tidak dibagikan. Setiap node juga memiliki adaptor jaringan virtual terpisah untuk komunikasi publik, adaptor jaringan virtual untuk komunikasi WSFC, dan adaptor jaringan virtual yang akan kami dedikasikan untuk komunikasi grup ketersediaan. Untuk tujuan posting ini, kami akan fokus pada informasi yang diperlukan untuk adapter jaringan khusus grup ketersediaan di setiap node:

Menyiapkan grup ketersediaan menggunakan NIC khusus hampir identik dengan proses NIC bersama, hanya untuk "mengikat" grup ketersediaan ke NIC tertentu, pertama-tama saya harus menetapkan LISTENER_IP argumen di CREATE ENDPOINT perintah, menggunakan alamat IP yang disebutkan di atas untuk NIC khusus saya. Di bawah ini menunjukkan pembuatan setiap titik akhir di lima node WSFC:

:CONNECT SQL2K12-SVR1
 
USE [master];
GO
 
CREATE ENDPOINT [Hadr_endpoint] 
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (192.168.20.31))
    FOR DATA_MIRRORING (ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES);
GO
 
IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
END
GO
 
USE [master];
GO
 
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [SQLSKILLSDEMOS\SQLServiceAcct];
GO
 
:CONNECT SQL2K12-SVR2
 
-- ...repeat for other 4 nodes...

Setelah membuat titik akhir yang terkait dengan NIC khusus ini, langkah saya selanjutnya dalam menyiapkan topologi grup ketersediaan tidak berbeda dengan skenario NIC bersama.

Setelah membuat grup ketersediaan saya, jika saya mulai mendorong beban modifikasi data terhadap basis data ketersediaan replika utama, saya dapat dengan cepat melihat bahwa lalu lintas komunikasi grup ketersediaan mengalir pada NIC khusus menggunakan Pengelola Tugas pada tab jaringan (bagian pertama adalah throughput untuk NIC grup ketersediaan khusus):

Dan saya juga dapat melacak statistik menggunakan berbagai penghitung kinerja. Pada gambar di bawah, Inetl[R] PRO_1000 MT Network Connection _2 adalah NIC grup ketersediaan khusus saya dan memiliki sebagian besar lalu lintas NIC dibandingkan dengan dua NIC lainnya:

Sekarang memiliki NIC khusus untuk lalu lintas grup ketersediaan dapat menjadi cara untuk mengisolasi aktivitas dan secara teoritis meningkatkan kinerja, tetapi jika NIC khusus Anda memiliki bandwidth yang tidak mencukupi, seperti yang Anda harapkan kinerja akan menurun dan kesehatan topologi grup ketersediaan akan menurun.

Misalnya, saya mengubah NIC grup ketersediaan khusus pada replika utama menjadi bandwidth transfer keluar 28,8 Kbps untuk melihat apa yang akan terjadi. Tak perlu dikatakan, itu tidak baik. Throughput NIC grup ketersediaan turun secara signifikan:

Dalam beberapa detik, kesehatan berbagai replika menurun, dengan beberapa replika berpindah ke status "tidak sinkron":

Saya meningkatkan NIC khusus pada replika utama menjadi 64 Kbps dan setelah beberapa detik ada lonjakan awal juga:

Sementara keadaan membaik, saya menyaksikan pemutusan berkala dan peringatan kesehatan pada pengaturan throughput NIC yang lebih rendah ini:

Bagaimana dengan statistik menunggu terkait pada replika utama?

Ketika ada banyak bandwidth pada NIC khusus dan semua replika ketersediaan dalam keadaan sehat, saya melihat distribusi berikut selama pemuatan data saya selama periode 2 menit:

HADR_WORK_QUEUE mewakili utas pekerja latar belakang yang diharapkan menunggu pekerjaan baru. HADR_LOGCAPTURE_WAIT mewakili penantian lain yang diharapkan hingga catatan log baru tersedia dan menurut Books Online, diharapkan jika pemindaian log ditangkap atau dibaca dari disk.

Ketika saya cukup mengurangi throughput NIC untuk membuat grup ketersediaan ke status tidak sehat, distribusi tipe tunggu adalah sebagai berikut:

Kami sekarang melihat jenis tunggu teratas baru, HADR_NOTIFICATION_DEQUEUE . Ini adalah salah satu jenis menunggu "hanya penggunaan internal" seperti yang didefinisikan oleh Books Online, yang mewakili tugas latar belakang yang memproses pemberitahuan WSFC. Yang menarik adalah jenis menunggu ini tidak mengarah langsung ke masalah, namun pengujian menunjukkan jenis menunggu ini naik ke posisi teratas terkait dengan penurunan throughput perpesanan grup ketersediaan.

Jadi intinya adalah mengisolasi aktivitas grup ketersediaan Anda ke NIC khusus dapat bermanfaat jika Anda menyediakan throughput jaringan dengan bandwidth yang cukup. Namun jika Anda tidak dapat menjamin bandwidth yang baik bahkan menggunakan jaringan khusus, kesehatan topologi grup ketersediaan Anda akan terganggu.