AlwaysON Wait Types and Network Isolation Practice
Merhabalar,
Bu yazımda sizlere SQL Server 2012 ile hayatımıza dahil olan AlwaysON özelliğinin Network katmanında nasıl izole edilebileceğinden bahsetmeye çalışacağım.
AlwaysON ,SQL Server üzerinde kullanabileceğimiz HA/DR(High Availability/Disaster Recovery) çözümlerinden en güncel ve güvenilir olanıdır. Bize sunduğu Listener(VNN) ,Auto-Failover ,Sync/Async replika ve Availability Group(AG) seçenekleriyle hem esneklik hem de kullanım kolaylığı sunar. Diğer HA çözümleri ve Alwayson kurulumu hakkında aşağıdaki linklerden bilgi alabilirsiniz.
https://www.mssqltips.com/sqlservertip/2482/sql-server-high-availability-options/
https://www.sqlrx.com/steps-for-installing-sql-server-alwayson-availability-groups/
Bu yazıda odaklanacağımız kısım Alwayson yapısının Network kullanımını optimize etmek ve projemiz açısından en verimli şekilde bu özelliği kullanmak.
Alwayson beklemeleri nelerdir?
AlwaysOn’a dahil edilen veritabanları haberleşme ve senkronizasyonu sağlamak için Network katmanını aktif bir şekilde kullanır. Bu kullanımları AlwaysON beklemeleri(AlwaysON Waits) başlığı altında toplayabiliriz. Backup ,Monitoring , Management gibi işlerde network katmanında ayrıca yük oluşturur. Bu sebeple AlwaysON beklemelerini networksel olarak ayrıştırma yoluna gideceğiz. AlwaysON beklemelerinde en sık görülen birkaç tanesini inceleyelim. Aşağıdaki sorguyu Veritabanında çalıştırdığımız zaman bize AlwaysON beklemelerini ve bunların bekleme süreleri hakkında bilgi verecektir.
NOT : Burada AlwaysON beklemelerinin network katmanında yarattığı yüke odaklanıyoruz. Bu beklemelerin Veritabanı tarafında bir sürü farklı sebebi olabilir.
SELECT * FROM sys.dm_os_wait_stats WHERE wait_type LIKE ‘%hadr%’ ORDER BY wait_time_ms DESC;
Yukarıda gördüklerimiz 65 adet AlwaysON beklemesinin sadece 6 tanesidir. Bunlardan bazılarını inceleyelim.
HADR_LOGCAPTURE_WAIT : Bu beklenen bir bekleme tipidir. Log kayıtlarının kullanılabilir olmasının beklenmesidir. Connection tarafından yeni log kayıtlarının oluşturulması veya Cache’de olmayan log kayıtlarını okurken I/O tamamlanması sırasında oluşur.
HADR_WORK_QUEUE : AlwaysON AG’lerde ‘background worker thread’ yeni bir görev ataması beklerken oluşur. Bu normal bir beklemedir.
HADR_NOTIFICATION_DEQUEUE : Bu Internal bir beklemedir. Yani WSFC(Windows Server Failover Cluster) bildiriminlerinin bir sonraki bildirimi beklediğini işleyen arkaplan işlemleridir.
HADR_CLUSAPI_CALL : WSFC API çağırmak amacıyla non-preemptive moddan preemptive moda geçmeyi bekleyen SQL Server thread’i dir.
HADR_GROUP_COMMIT : Transaction commit işleminin birden çok işlem kaydının tek bir günlük bloğuna yerleştirilebilmesi için bir grubun işlemesine izin vermeyi beklemesidir. Bu bekleme Log I/O, Log capture ve Log gönderme operasyonlarında beklenen bir durumdur.
HADR_COMPRESSED_CACHE_SYNC : Birden çok ikincil veritabanına gönderilen günlük log bloklarının gereksiz sıkıştırılmasını önlemek için kullanılan sıkıştırılmış log bloklarının Cache’ine erişim beklenmesi durumudur.
HADR_SYNC_COMMIT : Senkronize secondary veritabanlarının log’u harden etmesini bekleyen Transaction Commit işlemidir. Bu bekleme tipi AG’lerde logların gönderim zamanı, yazılması ve onaylanmasını işaret eder.
Burada Potansiyel Problem Nedir?
Yukarıda AlwaysON bekleme tiplerinin bir kısmına göz attık. Peki burada bizi önlem almaya iten konu nedir?
Bu haberleşme isteklerinin hepsi Network katmanı üzerinden yapılmaktadır. Örneğin veritabanına çok yüklü bir UPDATE veya INSERT işlemi HADR_SYNC_COMMIT beklemelerini arttıracağı için veritabanı diğer isteklere zaman ayıramayacak öncelikle verinin güvenliğini sağlamak için senkronizasyon işleminin bitmesini bekleyecek ve bu sırada diğer işlemlerin hepsini sekteye uğratacaktır. Bu da Network bandwith’i sature edebilir ve veritabanını kullanılamaz hale getirebilir. Ayrıca data senkronizasyonunda gecikmeye sebep olabilir. Bu sebeple Network anlamında bir iyileştirme yapmamız gerekmektedir.
Çözüm
Bu konuyu AlwaysON Network trafiğini ayrı bir NIC(Network Interface Card) üzerinde ayrı bir VLAN’a alarak çözmemiz mümkün. Böylece AlwaysON haberleşmeleri kendine özel bir Network üzerinden haberleşeceği için bu haberleşmeyi daha hızlı yapabilecek ve performansı yükseleceğinden Response Time iyileşmesi sağlanacaktır.
Uygulama
Öncelikle tüm sunuculara ayrı bir NIC eklendiğinden emin olmamız gerekiyor. Daha sonra Alwayson trafiği için kullanacağımız VLAN’da AG’deki sunucu sayısı kadar IP alınıp bu IP’lerin NIC üzerinde konfigüre edildiğinden emin olunur. Sonraki işlem ise AG Endpointlerinin yeni aldığımız bu IP ile değiştirilmesidir. Bu işlemi AG kurulumundan önce veya sonra yapabiliriz.
NOT : AG Endpoint değiştirme işlemini çalışan bir sistem üzerinde denemeyiniz. Network paket kayıplarına yol açabileceğinden problem yaşayabilirsiniz.
Benim kullandığım Checklist içerisinde bu işlemi genelde AG kurulumundan sonra yapıyorum. Siz kurulum öncesinde de yapabilirsiniz. Aşağıdaki T-SQL komutlarını SSMS üzerinde ‘Query’ tabına tıklayıp ‘SQLCMD Mode’ seçtikten sonra Primary Replica üzerinde çalıştırıyoruz ve işlem burada bitiyor.
Aşağıda görebileceğiniz gibi AG üzerine sağ tıklayıp ‘Proterties’ seçeneğinden Endpointlerin değişip değişmediğini kontrol edebilirsiniz.
Peki bu kadar kısa gözüken bir işlem neden uzun uzun anlattık?
Konu hakkında elimden geldiğince detaylı açıklama yaparak sadece işlemi yapmayı değil , hangi sebeplerden dolayı bu çalışmayı yaptığımızı anlatmak istedim.
Daha sonraki yazılarımda bu konuda daha fazla detaya girmeye çalışacağım.
Bir sonraki yazımda görüşmek üzere…
