Yüksek erişilebilirlik altyapılarında en yanıltıcı arızalar, sistemin tamamen erişilemez hale geldiği durumlar değildir.
Bazen bütün sunucular erişilebilir görünür, servisler çalışır, kaynak tüketimleri normal seviyededir ve temel bağlantı testleri herhangi bir problem göstermeyebilir.
Buna rağmen uygulama tarafında bağlantılar kesilmeye başlar.
SQL Server Always On Availability Group ortamında yaşadığımız bir olay tam olarak bu şekilde ilerledi.
İlk bakışta tablo oldukça sakindi:
- Cluster üyeleri erişilebilirdi.
- Windows Cluster servisleri çalışıyordu.
- SQL Server instance’larında olağan dışı bir kaynak kullanımı yoktu.
- Network erişimi mevcuttu.
- Listener DNS ve IP kaynakları görünürde aktifti.
Ancak kullanıcıların gördüğü tablo tamamen farklıydı.
Uygulamalar belirli aralıklarla veritabanı bağlantısını kaybediyor, Listener üzerinden kurulan oturumlar kapanıyor ve Availability Group zaman zaman beklenmedik şekilde devre dışı kalıyordu.
Sorunun en zor tarafı ise klasik sağlık kontrollerinin büyük bölümünün başarılı olmasıydı.
İlk Müdahaleler Neden Sonuç Vermedi?
Üretim kesintilerinde zaman baskısı arttıkça hızlı değişiklik yapma eğilimi de artar.
Bu olayda da ilk değerlendirmeler cluster quorum ve node sayısı üzerinde yoğunlaştı.
Mevcut yapıya ilave bir sunucu dahil edildi ve witness mimarisinde değişikliğe gidildi.
Beklenti, cluster karar mekanizmasının daha dayanıklı hale gelmesiydi.
Fakat operasyon tamamlandıktan sonra bağlantı kesintileri aynı şekilde devam etti.
Yeni node eklenmişti.
Cluster topolojisi değişmişti.
Ama asıl arıza hâlâ yerindeydi.
Burada önemli bir gerçeği yeniden gördük:
Bir sistemin mimarisini büyütmek, sorunun kaynağını ortadan kaldırdığı anlamına gelmez.
Özellikle dağıtık sistemlerde nedeni bilinmeyen bir probleme yeni bileşen eklemek, bazen yalnızca incelenecek bağımlılık sayısını artırır.
Bu noktadan sonra konfigürasyon değiştirmek yerine olayın meydana geldiği saniyelere odaklandık.
Kırılma Noktası: Cluster İletişim Kayıtları
WSFC logları zaman bazlı olarak incelendiğinde tekrar eden bir örüntü ortaya çıktı.
NetFT katmanında bazı node çiftleri arasında peş peşe heartbeat kayıpları oluşuyordu.
Ardından UDP iletişiminin kesildiğini gösteren kayıtlar geliyordu.
Örneğin loglarda buna benzer olaylar bulunuyordu:
Microsoft Failover Cluster Virtual Adapter (NetFT)
Node-02 -> Node-03 : Multiple consecutive heartbeat packets missed
Node-02 -> Node-01 : Multiple consecutive heartbeat packets missed
Node-02 -> Node-03 : UDP communication lost
Node-02 -> Node-01 : UDP communication lostBu kayıtlar bizi SQL Server’ın iç çalışma mekanizmasından çok, cluster üyelerinin birbirleriyle kurduğu iletişime yönlendirdi.
Network tamamen kesilmiyordu.
Uzun süreli bir erişim problemi de bulunmuyordu.
Bunun yerine çok kısa süren, klasik kontroller sırasında yakalanması zor bağlantı düzensizlikleri oluşuyordu.
Başka bir ifadeyle:
Network erişilebilirdi ancak cluster açısından yeterince kararlı değildi.
Bu ikisi aynı şey değildir.
Ping Testi Neden Yetersiz Kaldı?
Troubleshooting sırasında sık yapılan hatalardan biri, network sağlığını yalnızca ICMP testiyle değerlendirmektir.
Bir hedefin ping’e cevap vermesi, iki cluster üyesi arasındaki iletişimin zamanlama açısından kesintisiz olduğunu kanıtlamaz.
WSFC, üyelerin belirli periyotlarla birbirlerine sağlık sinyali göndermesine dayanır.
Bu sinyallerden art arda belirli sayıda kayıp yaşanırsa cluster, diğer node’un durumuyla ilgili karar vermek zorunda kalır.
Dolayısıyla ağ üzerindeki birkaç saniyelik oynama;
- kullanıcı tarafında fark edilmeyebilir,
- standart ping testi sırasında görülmeyebilir,
- monitoring ekranlarında ortalama değerleri bozmayabilir,
ancak cluster heartbeat mekanizmasını etkileyebilir.
Bizim senaryoda sorun tam olarak bu zaman aralığında ortaya çıkıyordu.
Olay Zinciri Nasıl İlerliyordu?
İnceleme sonucunda yaşanan akışı şu şekilde modelledik:
Kısa süreli network kararsızlığı
→
Heartbeat paketlerinin ardışık biçimde kaybedilmesi
→
NetFT haberleşmesinin bozulması
→
Cluster üyeleri arasındaki sağlık değerlendirmesinin olumsuz etkilenmesi
→
Availability Group kaynağının riskli duruma geçmesi
→
Client bağlantılarının Listener üzerinden kesilmesi
Dışarıdan görülen yalnızca son adımdı.
Uygulama ekibi “database bağlantısı koptu” diyordu.
Fakat kök neden, çok daha aşağıdaki iletişim katmanında başlıyordu.
İncelenmesi Gereken Parametreler
Bu tip vakalarda üç ayar özellikle önem kazanır:
SameSubnetDelaySameSubnetThresholdLeaseTimeout
Bu parametreler aynı amacı yerine getirmez.
Bu nedenle tek bir başlık altında düşünülmemeleri gerekir.
SameSubnetDelay Ne İşe Yarar?
SameSubnetDelay, aynı subnet üzerindeki cluster üyelerinin birbirlerine heartbeat gönderme sıklığını belirler.
Örneğin değer 1000 ms ise node’lar yaklaşık olarak her saniye birbirlerinin erişilebilirliğini kontrol eder.
Basitleştirilmiş görünüm:
Node-A ---- heartbeat ----> Node-B
Node-A <--- heartbeat ----- Node-BBuradaki temel amaç diğer cluster üyesinin hâlâ iletişim kurabildiğini doğrulamaktır.
Fakat tek bir heartbeat’in kaybolması, node’un doğrudan arızalı kabul edilmesine neden olmaz.
Bu noktada ikinci parametre devreye girer.
SameSubnetThreshold Ne Belirler?
SameSubnetThreshold, art arda kaç heartbeat cevabının alınamamasına izin verileceğini belirler.
Dolayısıyla Delay ve Threshold birlikte düşünüldüğünde cluster’ın yaklaşık tolerans aralığı ortaya çıkar.
Örnek olarak:
SameSubnetDelay : 1000 ms
SameSubnetThreshold : 5konfigürasyonunda teorik pencere yaklaşık olarak:
1000 × 5 = 5000 msseviyesindedir.
Yani node’lar arasındaki iletişim yaklaşık beş saniyelik bir tolerans alanına sahiptir.
Ancak burada dikkat edilmesi gereken nokta şudur:
Bu süre sadece bir sayı değildir.
Gerçek üretim ortamında;
- sanallaştırma host yoğunluğu,
- NIC davranışı,
- network congestion,
- switch tarafındaki anlık gecikmeler,
- driver problemleri,
- CPU scheduling,
- güvenlik cihazları
gibi birçok unsur bu pencereyi etkileyebilir.
LeaseTimeout Neden Ayrı Değerlendirilmeli?
Heartbeat ile lease mekanizması zaman zaman aynı kavrammış gibi ele alınır.
Oysa farklı sağlık kontrollerini temsil ederler.
Heartbeat mekanizması esas olarak cluster üyelerinin birbirleriyle haberleşmesini takip eder.
Lease ise SQL Server ile cluster servisinin birlikte yürüttüğü sağlık kontrol sürecinin bir parçasıdır.
Bunu şöyle düşünebiliriz:
Cluster heartbeat
NODE-01 <----------> NODE-02
Buna karşılık lease katmanı:
SQL Server <----------> Windows Failover Clusterilişkisini ilgilendirir.
SQL Server belirlenen süre içerisinde lease yenilemesini gerçekleştiremezse, işletim sistemi ve SQL servisleri tamamen çalışıyor görünse bile Availability Group resource sağlık kontrolünden geçemeyebilir.
Bu yüzden sadece node heartbeat değerlerine bakarak analiz yapmak eksik kalabilir.
Önce Ölç, Sonra Değiştir
Bu tür bir problemde doğrudan threshold artırmak doğru başlangıç değildir.
İlk olarak mevcut değerlerin ne olduğu kayıt altına alınmalıdır.
Örneğin:
Get-Cluster |
Select-Object SameSubnetDelay, SameSubnetThresholdAvailability Group kaynak parametreleri tarafında ise:
Get-ClusterResource -Name "AG_Name" |
Get-ClusterParameter -Name LeaseTimeoutkomutlarıyla mevcut yapı kontrol edilebilir.
Sonrasında cluster logları, SQL Server kayıtları ve olay zamanları karşılaştırılmalıdır.
Amaç şu soruya yanıt bulmaktır:
Gerçek kesinti süresi mevcut tolerans sınırını ne kadar aşıyor?
Bu soru cevaplanmadan yapılan ayar değişiklikleri tahmine dayanır.
Uygulanan Kalibrasyon
Loglardan elde edilen zamanlamalar doğrultusunda cluster’ın kısa süreli iletişim kayıplarına daha fazla tolerans göstermesi sağlandı.
Örnek bir ayarlama:
(Get-Cluster).SameSubnetDelay = 1000
(Get-Cluster).SameSubnetThreshold = 20Bu durumda yaklaşık iletişim toleransı:
1000 ms × 20 = 20000 msseviyesine çıkar.
Availability Group resource tarafında da lease süresi ihtiyaç doğrultusunda genişletilebilir:
(Get-ClusterResource -Name "AG_Name").LeaseTimeout = 60000Değişiklik sonrasında mutlaka doğrulama yapılmalıdır:
Get-Cluster |
Select-Object SameSubnetDelay, SameSubnetThreshold
Get-ClusterResource -Name "AG_Name" |
Get-ClusterParameter -Name LeaseTimeoutBizim ortamımızda ilgili eşikler loglardan gözlemlediğimiz davranışa göre yeniden ayarlandıktan sonra tekrarlayan Availability Group kopmaları ortadan kalktı.
Fakat Burada Kritik Bir Nokta Var
Threshold yükseltmek ile network problemini çözmek aynı şey değildir.
Bu ayrımı özellikle vurgulamak gerekir.
Eğer altyapıda gerçek bir paket kaybı, NIC problemi, switch sorunu, virtualization kaynaklı latency veya network congestion bulunuyorsa bunların ayrıca giderilmesi gerekir.
Heartbeat toleransını artırmak yalnızca cluster’ın kısa süreli bozulmalara karşı vereceği tepkiyi değiştirir.
Yani:
Altyapıdaki hatayı onarmak yerine, cluster’ın o hataya toleransını yükseltmiş olabilirsiniz.
Bu nedenle tuning işlemi, root cause analysis yerine kullanılmamalıdır.
İki süreç birbirini tamamlamalıdır.
Failover Süresi ile Tolerans Arasındaki Denge
High Availability tasarımında toleransı yükseltmenin bir maliyeti vardır.
Cluster bir node’un gerçekten arızalandığını anlamadan önce daha uzun süre beklerse gerçek bir kesintide failover kararı da gecikebilir.
Bu yüzden hedef hiçbir zaman:
“Mümkün olan en yüksek threshold değerini kullanalım.”
olmamalıdır.
Hedef şudur:
Gerçek ortam davranışına uygun en düşük güvenli toleransı belirlemek.
Başka bir ifadeyle, ayarlar iki uç arasında dengelenmelidir:
Çok agresif değerler
→ küçük dalgalanmalarda gereksiz failover riski.
Çok toleranslı değerler
→ gerçek arızalarda geç tepki riski.
Doğru değer bu iki senaryonun ortasında, sistemin iş gereksinimlerine göre bulunmalıdır.
Olaydan Çıkardığımız Teknik Sonuçlar
Bu vaka bize birkaç önemli noktayı tekrar hatırlattı.
İlk olarak, cluster’a yeni bir node eklemek otomatik olarak daha stabil bir sistem oluşturmaz.
Problem iletişim katmanındaysa yeni bir node, mevcut sorunu ortadan kaldırmak yerine yeni network ilişkileri oluşturabilir.
İkinci olarak, ürün varsayılanları her altyapı için ideal kabul edilmemelidir.
Default değerler çoğu zaman başlangıç konfigürasyonudur.
Yoğun işlem yapan kritik sistemlerde RTO beklentileri, network karakteristiği ve uygulama davranışı dikkate alınarak değerlendirilmelidir.
Üçüncü olarak, yalnızca SQL Server loglarına bakmak yeterli değildir.
Always On mimarisi tek başına SQL Server’dan oluşmaz.
Aşağıdaki katmanların tamamı olayın bir parçasıdır:
- SQL Server
- Windows Server Failover Cluster
- NetFT
- İşletim sistemi
- Network altyapısı
- Sanallaştırma platformu
- Client bağlantı davranışı
Her katmanın olay zamanındaki durumu birlikte analiz edilmelidir.
“Network mü, Database mi?” Sorusu Neden Yanlış?
Kriz anında ekipler genellikle problemi sahiplenmek yerine sınırlandırmaya çalışır.
“Bizim tarafta sorun görünmüyor.”
“SQL servisi çalışıyor.”
“Network monitoring temiz.”
“Windows tarafında alarm yok.”
Bu ifadelerin her biri tek başına doğru olabilir.
Ama dağıtık bir sistem yine de çalışmıyor olabilir.
Çünkü problem çoğu zaman tek bir bileşenin tamamen bozulması değil, bileşenler arasındaki ilişkinin bozulmasıdır.
Bu nedenle doğru soru:
“Hangi ekipte problem var?”
değil,
“Hangi sağlık kontrolü başarısız oldu ve bunu hangi kayıt doğruluyor?”
olmalıdır.
Bu yaklaşım troubleshooting sürecini tahminden çıkarıp kanıta dayalı hale getirir.
Yüksek erişilebilirlik ortamlarında “sunucu ayakta” bilgisi tek başına yeterli değildir.
Bir node işletim sistemi açısından çalışıyor olabilir.
SQL servisi aktif olabilir.
Network kartı bağlantıyı kaybetmemiş olabilir.
Monitoring sistemi yeşil görünebilir.
Ancak cluster üyeleri beklenen zaman aralığında birbirleriyle iletişim kuramıyorsa yüksek erişilebilirlik zinciri yine kırılabilir.
Always On problemlerin analizinde bu nedenle yalnızca servislerin çalışıp çalışmadığına değil, servislerin ve node’ların birbirleriyle ne kadar sağlıklı iletişim kurduğuna bakmak gerekir.
Çünkü bir HA mimarisini ayakta tutan şey sadece çalışan sunucular değildir.
Asıl belirleyici olan, bileşenlerin doğru süre içerisinde birbirlerini hâlâ “sağlıklı” olarak görebilmesidir.
