Failover süreci çoğu zaman tek bir parametreye bağlıymış gibi düşünülür. Oysa SQL Server Always On Availability Group (AG) ve Windows Server Failover Cluster (WSFC) mimarisinde failover, birden fazla katmanın birlikte çalışması sonucunda gerçekleşir. Bu katmanların her biri farklı bir bileşeni izler ve belirli koşullar oluştuğunda sürece katkı sağlar.
Bu makalede failover mekanizmasını katmanlı (layered) mimari yaklaşımıyla ele alacağız.
Layer 1 — Network / Heartbeat Katmanı (Node-to-Node İletişim)
Failover zincirinin en alt katmanı network seviyesidir. Burada Windows Failover Cluster, node’ların birbirleriyle iletişim kurup kuramadığını kontrol eder. Detaylı bilgi için ilgili makale okunabilir.
Cluster üyeleri belirli aralıklarla birbirlerine heartbeat (kalp atışı) sinyali gönderir. Bu iletişim aşağıdaki parametrelerle yönetilir:
- SameSubnetDelay
- SameSubnetThreshold
- CrossSubnetDelay
- CrossSubnetThreshold
Eğer bir node, belirlenen süre boyunca diğer node’lardan heartbeat yanıtı alamazsa, cluster ilgili node’u erişilemez (down) olarak işaretler. Bu durumda roller sağlıklı node’a taşınır.
Bu katman tamamen ağ iletişimi ile ilgilidir. Çoğu yanlış failover vakasının kök nedeni burada başlar.
Layer 2 — Cluster Service Katmanı (ClusSvc)
İkinci katmanda doğrudan Windows Cluster Service (ClusSvc) devrededir. Bu servis:
- Node’un gerçekten çalışıp çalışmadığını
- İşletim sisteminin yanıt verip vermediğini
- Cluster servisinin ayakta olup olmadığını
kontrol eder.
Aşağıdaki durumlar bu katmanda failover’a neden olabilir:
- Cluster servisinin çökmesi
- Sunucunun yeniden başlaması
- İşletim sistemi hatası (OS crash)
Bu seviyede oluşan problemler genellikle daha nettir ve doğrudan node kaybı olarak değerlendirilir.
Layer 3 — AG Resource Katmanı (Lease ve Health Monitoring)
Bu katmanda SQL Server Always On Availability Group devreye girer. SQL Server ile Windows Cluster arasında bir “lease” mekanizması bulunur. İlgili makaleden detaylı bilgi alınabilir.
Temel parametreler:
- LeaseTimeout
- HealthCheckTimeout
- FailureConditionLevel
SQL Server, cluster’a belirli aralıklarla lease yenilemesi yapar. Eğer lease süresi içinde yenileme gerçekleşmezse cluster, SQL Server’ı yanıt vermiyor olarak kabul eder.
Ayrıca SQL Server iç sağlık kontrolleri (sp_server_diagnostics) başarısız olursa HealthCheckTimeout devreye girer. Belirlenen FailureConditionLevel seviyesine göre AG resource failed durumuna geçebilir ve failover başlatılabilir.
Bu katman, network ile SQL engine arasındaki köprüdür.
Layer 4 — SQL Server Engine Sağlık Katmanı
Bu katman tamamen SQL Server motorunun iç sağlığı ile ilgilidir.
Kontrol edilen başlıca durumlar:
- SQL Server servisinin çalışır durumda olması
- Scheduler deadlock oluşumu
- IO subsystem yanıt süreleri
- Kritik memory pressure
- Severity 20 ve üzeri fatal hatalar
FailureConditionLevel değeri, hangi tip hatalarda otomatik failover yapılacağını belirler. Daha düşük seviyeler daha agresif failover davranışı anlamına gelir.
Bu katmanda sorun yaşandığında network sağlam olsa bile failover gerçekleşebilir.
Layer 5 — Storage Katmanı
Storage katmanı özellikle Failover Cluster Instance (FCI) yapılarında kritik öneme sahiptir.
Kontrol edilen durumlar:
- Disk erişilebilirliği
- Storage timeout
- CSV (Cluster Shared Volume) erişimi
Disk kaybı veya storage timeout oluşursa resource failed olur ve failover gerçekleşir.
Always On AG mimarisinde shared disk kullanılmaz. Ancak ciddi IO problemleri Layer 4 üzerinden yine failover tetikleyebilir.
Layer 6 — Application / Client Katmanı
En üst katman uygulama ve istemci seviyesidir. Bu katman failover başlatmaz ancak kesinti süresini doğrudan etkiler.
Önemli noktalar:
- Client bağlantı davranışı
- MultiSubnetFailover parametresi
- Listener erişilebilirliği
- Connection timeout süresi
Yanlış yapılandırılmış istemci bağlantıları, failover süresini gereksiz yere uzatabilir.
Katmanların Genel Sıralaması
Layer 6 → Client
Layer 5 → Storage
Layer 4 → SQL Engine Health
Layer 3 → AG Resource (Lease & HealthCheck)
Layer 2 → Cluster Service
Layer 1 → Network Heartbeat
Failover çoğu zaman yukarıdan aşağıya değil, aşağıdan yukarıya tetiklenir. Yani küçük bir network gecikmesi, zincirleme şekilde AG failover’a kadar ilerleyebilir.
Gerçek ortamda en sık görülen zincir şudur:
Network threshold çok düşük ayarlanır →
Node kısa süreli unreachable olur →
Cluster node’u down sayar →
SQL lease yenilenemez →
AG failover tetiklenir
Bu durumda sorun SQL Server değildir. Problemin kaynağı Layer 1’dir.
Production ortamlarında doğru analiz yapılmadığında, SQL tarafında gereksiz ayarlamalar yapılabilir. Oysa çoğu zaman çözüm network timeout değerlerinin doğru ayarlanmasıdır.
Bu makalede SQL Server Always On Failover Mekanizması Katmanlı Mimari ve Tetikleme Süreçleri’ni detaylı bir şekilde görmüş olduk. Başka makalede görüşmek dileğiyle..
“…Olur ki (bazen) hoşunuza gitmeyen bir şey sizin için hayırlı olur ve hoşunuza giden bir şey de sizin için şer olur. (Hayırlı ve doğru olanı) Allah bilir, siz bilemezsiniz.” Bakara Suresi; 216. Ayet
