Windows Server Failover Cluster (WSFC) yapılarında sistemin sürekliliği, sadece sunucuların fiziksel olarak açık olmasına değil, bu sunucuların kendi aralarında kurdukları “demokratik” uzlaşıya bağlıdır. Bu uzlaşı mekanizmasının kalbinde ise Quorum (Çoğunluk) kavramı yer alır. Quorum, bir cluster yapısının hangi durumlarda hizmet vermeye devam edeceğini, hangi durumlarda ise veri bütünlüğünü korumak adına kendini durduracağını belirleyen karar mekanizmasıdır. Bu yazımızda, özellikle iki düğümlü (2-node) yapılarda sıkça karşılaşılan “bir sunucu düşerse cluster neden kapanır?” sorusunu, Current Vote değerleri ve senaryolar üzerinden detaylandıracağız.
Bir Failover Cluster yapısında, sunucuların (node’ların) üzerinde bir servis (SQL, File Server vb.) çalışmasa bile, Cluster servisinin kendisinin hayatta kalabilmesi için “Quorum” (Çoğunluk) şarttır.
Cluster mekanizması matematiksel bir kurala göre çalışır: Toplam Oy Sayısının Yarısından Fazlası (n/2 + 1) hayatta olmalıdır.
- Mevcut Durum: Toplam oy gücü (Current Vote toplamı) = 1 (0 + 1).
- Kritik Eşik: Cluster’ın çalışmaya devam etmesi için gereken minimum oy sayısı 1‘dir.
- Senaryo (S2 Düşerse): S2 düştüğünde elinizde kalan oy sayısı 0 olur.
- Sonuç: Oy sayısı 1’in altına düştüğü için Cluster servisi otomatik olarak Stop durumuna geçer. S1 sunucusu fiziksel olarak açık olsa bile, Failover Cluster Manager’ı açtığınızda “Cluster’a bağlanılamıyor” hatası alırsınız.
Şu anki yapınızda S1’in oyu 0 olduğu için S1 aslında bir “izleyici” gibi konumlanmış durumda. Karar verici mekanizma tamamen S2‘nin elinde.
Eğer S2 düştüğünde S1’in tek başına Cluster’ı ayakta tutmasını istiyorsanız, bir Witness (Tanık) eklemeniz şarttır.
- File Share Witness: Ortak bir paylaşım klasörü (3. bir nokta) oy hakkına sahip olur.
- Disk Witness: Ortak bir storage alanı oy hakkına sahip olur.
Bu durumda toplam oy sayısı 3 olur (1+1+1). S2 düşse bile S1 ve Witness sayesinde elinizde 2 oy kalır ve Cluster kesintisiz çalışmaya devam eder.
“Cluster’a bağlanılamıyor” hatası alındığında, genellikle Quorum kaybedildiği için Cluster servisinin kendini korumaya alıp durmasından kaynaklanır. Sizin durumunuzda S2 sunucusu (tek oy sahibi) düştüğünde, S1 sunucusu “yeterli oyum yok” diyerek servisi durduracaktır.
Bu durumda sistemi ayağa kaldırmak için şu adımları izleyebilirsiniz:
Eğer node’ların yarısından fazlası kapalıysa ve elinizdeki aktif node (S1) üzerinden sistemi zorla açmak istiyorsanız, PowerShell’i yönetici olarak açıp şu komutu kullanmalısınız:
net start ClusSvc /fq
- -fq (Force Quorum): Bu parametre, “Çoğunluk aranmaksızın cluster’ı başlat” anlamına gelir. S1 tek başına ayağa kalkar ve rolleri üzerine alır.
Eğer servis “Force” komutuna rağmen başlamıyorsa, Windows Servisler (services.msc) üzerinden Cluster Service‘in durumunu kontrol edin.
- Event Viewer içerisinde System loglarına bakıldığında. Event ID 1135 veya 1177 hataları, quorum kaybı yaşandığını teyit eder.
Cluster tekrar ayağa kalktığında, bir daha aynı hatayı almamak için bir Witness eklemelisiniz. 2 node’lu yapılarda Witness hayati önem taşır.
Eğer sisteminizde 2 node varsa ve witness yoksa, Microsoft Dynamic Quorum kullanarak oyları dengeler (ekran resmindeki 0 ve 1 durumu budur). Ancak bu durum, “oy sahibi” olan sunucu (S2) kapandığında risk yaratır.
S1 üzerinden sistemi zorla başlattığınızda (Force Quorum), S2 tekrar geri geldiğinde bir çekişme olmaması için S2’nin cluster servisi otomatik olarak senkronize olacaktır.
Quorum yapısı eklendikten sonra Current vote bölümünde oy hakkını görmüş oluyoruz.
İki sunucu birden düşerse cluster ayakta kalmaz. Sisteminizde bir Witness olsa bile (toplam oy sayısı 3 olur: S1 + S2 + Witness), çoğunluğu (n/2 + 1) sağlamak için en az 2 oy gereklidir.
- İki sunucu da düştüğünde, elinizde sadece 1 oy (Witness) kalır.
- 1 < 2 olduğu için “Quorum” kaybedilir ve cluster servisi tüm kaynakları (SQL, File Server vb.) durdurarak kendini kapatır.
İki sunucu down oldu, sonra sadece 1 tanesi ayağa kalkarsa durumda ne olmaktadır. Burada kritik nokta “Dynamic Quorum” ve “Witness” türüdür. Normal şartlarda süreç şöyle işler:
- İki sunucu birden kapandığında cluster “çökmüş” sayılır. Sadece S1 ayağa kalktığında, S1 tek başına toplam oyların (3 oyun) salt çoğunluğunu sağlayamadığı için cluster servisi otomatik olarak “Running” durumuna geçmez.
- S1 ayağa kalktığında Witness ile iletişim kursa bile (2 oy eder), genellikle cluster’ın sağlıklı bir şekilde operasyona başlaması için diğer node’dan haber bekler veya manuel müdahale (Force Quorum) ister.
- Eğer sunucular sırayla düşseydi (önce S2, sonra bir süre sonra S1), Dynamic Quorum sayesinde cluster ayakta kalabilirdi. Ancak aynı anda/arka arkaya “down” durumunda sistem kendini korumaya alır.
Özetle
| Durum | Kalan Oy | Cluster Durumu |
| S1 ve S2 Aktif | 3 / 3 | Sağlıklı |
| S2 Düştü (S1 + Witness Aktif) | 2 / 3 | Ayakta |
| S1 ve S2 Düştü | 1 / 3 | Down |
| S1 Geri Geldi (S2 Kapalı) | 2 / 3 | Beklemede / Manuel Müdahale Gerekebilir |
Özetle, bir Failover Cluster yapısında Quorum, sistemin beyni görevini görür. Özellikle 2-node konfigürasyonlarda, oyların eşitliği veya yetersizliği durumunda “split-brain” (çift başlılık) riskini önlemek için sistem kendini otomatik olarak kapatır. Bu riskleri minimize etmenin ve yüksek erişilebilirliği gerçek anlamda sağlamanın yolu, yapıya mutlaka bir Witness (Tanık) dahil etmekten geçer. Unutulmamalıdır ki; doğru yapılandırılmamış bir Quorum modeli, donanımınız ne kadar güçlü olursa olsun beklenmedik kesintilere davetiye çıkaracaktır.
Başka makalede görüşmek dileğiyle..
Allah’ın mescidlerini, yalnızca Allah’a ve ahiret gününe iman eden, namazı dosdoğru kılan, zekatı veren ve Allah’tan başkasından korkmayanlar onarabilir. İşte, hidayete erenlerden oldukları umulanlar bunlardır. Tevbe Suresi, 18. Ayet
