Merhaba, bu yazımda Failover Cluster yapılandırmasının son yazısı Bölüm 4 ile yazımızı bitireceğiz. Failover Cluster üzerindeki en önemli kısımlardan birisi de sorun gidermedir.
Failover Sürecinin Hızlandırılması ve Kesintisiz Hizmet Sağlanması
Bir failover cluster’ın amacı, bir düğüm arızalandığında veya bakıma alındığında üzerindeki hizmetleri diğer düğümlere otomatik aktarmaktır. Bu süreç ne kadar hızlı olursa, hizmet kesintisi o kadar kısa olur. Failover süresini etkileyen birkaç faktör vardır ve bunların bazıları yapılandırılabilir:
Heartbeat Zaman Aşımı
Cluster düğümleri birbirlerine sürekli “yaşıyor musun?” sinyalleri (heartbeat) gönderir. Varsayılan olarak Windows Server, aynı subnet içindeki düğümler için her 1 saniyede bir heartbeat gönderir ve 10 saniye boyunca cevap alamazsa ilgili düğümü sağlıksız kabul eder. Farklı subnet’teki düğümler için eşik daha yüksektir (CrossSubnetThreshold varsayılan 20). Yani pratikte, bir düğüm gerçekten arızalandığında cluster bunu ~10 saniye içinde fark eder. Bu eşikler, cluster’ın ağ koşullarına göre daha agresif veya daha toleranslı olacak şekilde ayarlanabilir.
Örneğin, çok düşük gecikmeli ve güvenilir bir ağınız varsa, threshold değerini 5’e düşürmek failover algılamasını ~5 saniyeye indirebilir. Ancak ağınızda zaman zaman 2-3 saniyelik kesintiler olabiliyorsa bu kadar düşük threshold yanlış pozitiflere yol açar (düğüm aslında yaşıyor ama geçici network kopukluğunda cluster onu düşürür). Microsoft genelde varsayılan değerlerin dengeli olduğunu belirtir ve sorun yaşanmadıkça değiştirmeyi önermez. Eğer cluster event log’larınızda Event ID 1135 (düğüm iletişim kaybı) gibi hatalar görürseniz ve ağda kısa kesintiler tespit ederseniz, bu threshold’ları yükseltmeyi (daha az agresif yapmayı) düşünebilirsin.
Öte yandan, kritik sistemlerde failover’ın çok hızlı olması gerekiyorsa, tüm altyapının bu hıza dayanıklı olduğundan emin olup threshold’ı bir miktar düşürebilirsiniz. Bu ayarlar PowerShell ile (Get-Cluster).SameSubnetThreshold vs. şeklinde yapılır. Değişiklik sonrası cluster servisinin restart edilmesi gerekebilir.
Hizmet ve Uygulama Ayarları
Cluster üzerinde çalışan her rolün de kendi failover davranış ayarları vardır. Örneğin bir Generic Service rolü kullanıyorsanız, o servis durduğunda cluster hemen diğer düğüme geçmek yerine önce yerel yeniden başlatmayı deneyebilir (Varsayılan Policies ayarlarına göre). Bu durumda failover biraz gecikir. Böyle roller için Failover Threshold ve Period ayarlarını gözden geçirerek ihtiyaç halinde doğrudan failover yaptırabilirsiniz. Bir başka örnek, SQL Server Failover Cluster Instance gibi uygulamalar bellek dökümü alıp kapanırken belirli bir süre gerekir – cluster bu süreyi bilir ve sabırla bekler. Bu gibi uygulama spesifik durumlar dışında, cluster genelde maksimum birkaç dakika içinde diğer düğümde hizmeti ayağa kaldırır.
Plansız vs Planlı Failover
Eğer failover bir düğüm arızası nedeniyle beklenmedik şekilde gerçekleşiyorsa, VM gibi durumlarda o VM bir crash yaşayacak ve diğer hostta reboot olacaktır (bu süre OS’nin boot süresine bağlıdır). Bunu hızlandırmak için, VM’lerin “Automatic Start Action” ayarlarında cluster failover durumunda hemen başlatılacak şekilde tanımlı olması lazım (default öyledir). Planlı failover durumunda (örneğin bakım için bir düğümü boşaltırken), Hyper-V canlı taşıma yapacağından kesinti olmayacaktır; diğer uygulamalarda da “Move” komutu genelde zarurî kesinti süresini azaltır. Cluster-Aware Updating gibi mekanizmalar planlı failover’ı otomatize ederek kesintisizliği artırır.
Sürekli Erişilebilirlik Özellikleri
Bazı iş yükleri, Windows cluster üzerinde “sürekli erişilebilir” şekilde çalışabilir. Örneğin Hyper-V VM’leri, canlı göç veya hızlı yeniden başlatma sayesinde kullanıcıların çoğunlukla fark etmeyeceği şekilde taşınabilir. Scale-Out File Server üzerinde bir SMB paylaşımı sunuyorsanız, SMB 3.0 Transparent Failover özelliği sayesinde istemci oturumları cluster node değişimini kesinti olmadan atlatabilir.
Bu gibi modern özellikleri kullanmak, kesintisiz hizmet hedefinde önemlidir. Eğer uygulamanız bu tür bir özellik sunmuyorsa (örneğin eski tip bir veritabanı sunucusunu cluster generic service ile çalıştırıyorsanız), o zaman failover olduğunda kısa bir kesinti kaçınılmaz olacaktır – bunu en aza indirmek için belki client tarafında yeniden deneme (retry) mekanizmaları koyulabilir.
Özetle, failover süresini hızlandırmak için cluster parametrelerini ortamınıza uygun şekilde ayarlayabilir, planlı geçişleri mümkün olduğunca kullanabilir ve sürekli erişilebilirlik özelliklerini devreye alabilirsiniz. Ancak agresif ayarların stabiliteyi riske atmaması için dikkatli test edilmesi şarttır. Prodüksiyon öncesi bir test ortamında farklı senaryoları (network kesintisi, sunucu freeze, uygulama çökmesi vb.) deneyip cluster’ın davranışını ölçün.
Event Viewer ve Cluster Log’larını İzleme
Bir cluster’ın stabilitesini sağlamak için proaktif izleme çok kritiktir. Windows Failover Cluster, yaşanan olaylar hakkında Windows Olay Görüntüleyicisi’ ne ve kendi loglarına detaylı kayıtlar düşer. Bu kayıtların düzenli takibi, sorunları erken tespit etmeyi sağlar.
Event Viewer (Olay Görüntüleyicisi)
Her cluster düğümünde, System ve Application loglarının yanı sıra özellikle FailoverClustering adında özel bir log kategori vardır. Olay Görüntüleyicisi’nde Applications and Services Logs > Microsoft > Windows > FailoverClustering altında cluster ile ilgili event’lar listelenir.
- Event 1135: Bir veya daha fazla düğümün cluster iletişiminin koptuğunu ve üyelikten çıkartıldığını belirtir (genelde network partition – iletişim kopması).
- Event 1177: Quorum yetersizliği nedeniyle cluster servisinin durduğunu belirtir.
- Event 1069: Bir cluster kaynağının (ör. bir disk ya da Ağ Adı) arızalandığını ve failover deneniyor olabileceğini gösterir.
- Event 1205: Bir kaynak veya kaynak grubunun beklenmedik şekilde offline olduğunu gösterebilir.
- Event 1254: Cluster network’lerinin durum değişikliklerini (yeni network keşfi, network down vs.) gösterir.
- Event 1558: Quorum konfigürasyonu ile ilgili bilgi (ör. tanık atandı/çıkarıldı gibi).
Bu logları düzenli olarak veya bir merkezi izleme aracı ile takip edin. Özellikle Critical veya Error seviyesinde cluster event’i gördüğünüzde, hemen inceleyin. Örneğin event 1135 alıyorsanız, bir düğüm sürekli cluster’dan düşüyor olabilir – bu da ağ kartı problemi veya switch port flapping gibi bir işaret olabilir. Event’lerin detay kısmı genelde sorunun hangi düğüm ya da kaynakla ilgili olduğunu ve bazen hata kodlarını içerir.
Failover Cluster Diagnostic Log (Cluster.log)
Cluster servisi, her düğümde detaylı bir tanılama logu tutar (genellikle C:\Windows\Cluster\Reports\Cluster.log). Bu log insan tarafından okunması zor bir metindir ancak derin sorun giderme için gereklidir. Neyse ki Microsoft, bu logu kolay toplamak için bir komut sunmuştur: Get-ClusterLog. Bu komut, tüm düğümlerdeki cluster.log dosyalarını tek bir yerde toplar ve okunaklı hale getir. Örneğin Get-ClusterLog -Destination C:\logs -TimeSpan 5 komutu, son 5 dakikayı kapsayan cluster loglarını tüm düğümlerden alıp C:\logs klasörüne kopyalar. Bu loglarda zaman damgaları, event ID’leri, hata kodları ve cluster iç işlemlere dair satırlar göreceksiniz. Özellikle bir kesinti veya failover sonrası Get-ClusterLog alıp ilgili zaman damgasını aramak çok faydalıdır (log içinde “ERR” veya belirli resource isimlerini arayabilirsiniz).
Performans İzleme
Windows Performance Monitor (perfmon) kullanarak cluster ile ilgili sayaçları izleyebilirsiniz. Örneğin “Cluster Shared Volumes” sayaçları ile CSV üzerindeki IO gecikmeleri veya “Cluster Hearthbeat” sayaçları ile paket istatistikleri takip edilebilir. Bu proaktif izlemede anormal bir artış, ileride sorun yaratabilecek bir durumun habercisi olabilir.
Üçüncü Parti ve Merkezileştirilmiş İzleme
Eğer System Center Operations Manager (SCOM) gibi bir izleme aracınız varsa, cluster için hazır yönetim paketlerini kullanarak detaylı izleme kurabilirsiniz. Veya daha hafif bir yöntem olarak Windows’un Event Subscriptions özelliği ile cluster event’ lerini bir merkezi sunucuda toplayabilirsiniz. Ayrıca bazı cluster metrikleri WMI üzerinden de çekilebilir; PowerShell ile belli aralıklarla Get-ClusterNode vb. komutları çalıştırıp sonuçları kontrol eden özelleştirilmiş izleme de yapabilirsiniz.
Hem Windows Olay Logları hem cluster logları, cluster sağlığı hakkında bilgi hazinesidir. Bir cluster yöneticisi olarak, beklenmedik olaylara ait logları inceleme alışkanlığı edinin. Örneğin gecenin bir yarısı cluster kaynakları failover yapmışsa (Event 1069 vs.), ertesi gün bunun kök sebebini loglardan araştırıp çözmelisiniz. Bu proaktif yaklaşım, küçük bir sorunun büyük bir kesinti haline gelmesini engeller.
Yük Dengeleme ve Performans için En İyi Uygulamalar
Cluster ortamlarında sık karşılaşılan durumlardan biri de yükün düğümler arasında dengesiz dağılmasıdır. Örneğin tüm aktif işler bir düğümde, diğer düğüm ise boşta bekleyebilir. Bu, kaynakların verimsiz kullanımı demektir. Windows Server 2016 ile gelen Node Fairness (Düğüm Adilliği) özelliği, Hyper-V sanal makine cluster’larında bu durumu otomatik iyileştirebilmektedir.
VM Load Balancing (Node Fairness)
Bu özellik sayesinde cluster, belirli aralıklarla düğümlerin CPU ve bellek kullanımını analiz eder; eğer bir düğümün çok yüklü, diğerinin boş olduğunu tespit ederse, bazı VM’leri canlı taşıma ile boş düğüme aktarır. Windows Server 2016’da tanıtılan bu mekanizma, her 30 dakikada bir çalışarak %80 üzeri dolu bir host tespit ederse ondan daha boş bir hosta VM taşıyabilir. Varsayılan “Low” agresiflik seviyesinde, bir host %80’den fazla memory doluluğuna ulaşırsa dengeleme tetiklen. Daha agresif modlar ayarlanabilir (Medium: %70, High: ortalama +%5 üzerinde olanı taşı. Bu sayede cluster içi kaynak kullanımı optimize edilir ve hiçbir düğüm kapasite aşımına uğramaz.
VM Load Balancing özelliği varsayılan olarak etkindir ve genelde ek bir kurulum gerektirmez. Failover Cluster Manager’da cluster özelliklerinde “Balance Virtual Machine Load” gibi bir ayar ile konfigüre edilebilir. Bu özellikle birlikte, anti-affinity (karşılıklı uzak durma) kuralları da tanımlanabilir – örneğin aynı uygulamanın iki VM’sinin asla aynı hostta toplanmaması kuralı. Node Fairness bu kurallara riayet ederek taşımaları yap. Sonuç olarak, eğer Hyper-V cluster kullanıyorsanız, Node Fairness’in açık olduğundan emin olun (default açık gelir). Bu, performans dengesizliğini önlemeye yardımcı olur ve manuel müdahale ihtiyacını azaltır.
Manuel Yük Dengeleme
Hyper-V dışı senaryolarda veya Node Fairness’in olmadığı durumlarda, yöneticinin rol dağılımına dikkat etmesi gerekir. Örneğin bir iki düğümlü File Server cluster’ında tüm paylaşımları tek bir rolde tutmak yerine, iki ayrı File Server rolü oluşturup paylaşımları bölüştürerek her düğümün bir aktif rolü olmasını sağlayabilirsiniz (aktif/aktif benzeri bir dağılım; bir kaynak diğerinde de standby olacaktır yine).
Yine SQL Server AlwaysOn Availability Groups gibi teknolojiler, cluster ortamında iki düğümde de aktif yük çalıştırabilmenize imkân verir (birinde bir veritabanı primary, diğerinde ikinci veri tabanı primary gibi). Yani cluster’ınızın mimarisi izin veriyorsa yükü paralel paylaştırmak en iyi uygulamadır. Tek bir düğüme tüm yükü yığmak, o düğüm arızalandığında diğer düğümün aniden maksimum yükü almasına da yol açar ki bu performans problemlerine neden olabilir.
Performans Ayarları
Cluster düğümlerinde enerji tasarrufu ayarlarını kapatmak (Windows ve BIOS tarafında “High Performance” güç planı seçmek) genellikle tavsiye edilir. Yük altında CPU’nun hız düşürmesi, cluster zamanlamalarını etkileyebilir. Yine C-State, P-State gibi işlemci derin uyku modları kritik sistemlerde kapatılabilir (çok düşük latency isteyen ortamlarda).
NIC’lerde RSS (Receive Side Scaling) aktif olmalıdır ki yüksek trafikte tek CPU çekirdeği tıkanmasın. Depolama tarafında, eğer cluster’ınız bir SAN kullanıyorsa HBA Queue Depth gibi ayarlar I/O performansını etkileyebilir – bunlar üreticinin önerilerine göre set edilmelidir.
Networking Best Practice
Cluster networklerinde jumbo frame kullanımı (özellikle depolama replikasyon veya Live Migration için) uygun yapılandırıldığında performansı artırabilir. Ancak tüm switch ve NIC’lerin desteklediğinden emin olun, aksi halde tutarsız MTU yüzünden paket kayıpları yaşanır. QoS (Quality of Service): Hyper-V cluster’larında, farklı trafik tiplerine (LM, depolama, VM, management) QoS politikaları uygulamak, bir trafiğin diğerini bastırmasını önler. Örneğin Live Migration’a network’ün en fazla %50’sini kullan diyebilirsiniz, böylece istemci bağlantıları tamamen sıkışmaz.
İzleme ve Kapasite Planlama
Yük dengeleme yapısı oturtulduktan sonra bile, zamanla cluster kaynak kullanımı artabilir. Bu yüzden CPU, bellek, disk IOPS ve ağ kullanımlarını periyodik olarak izleyip kapasite planlaması yapın. Eğer cluster’da sürekli yüksek bir stres varsa, belki yeni bir düğüm ekleyerek 3 düğümlü cluster’a geçmek düşünülebilir (Windows failover cluster sonradan düğüm eklemeyi destekler; yeni düğüm ekleyip validation testini geçirdikten sonra cluster’a join edilebilir). Düğüm ekleme, yükü daha fazla node’a yayarak hem performansı hem dayanıklılığı artırır.
Sonuç olarak, cluster’ınızın dengeli, izlenebilir ve ölçeklenebilir olmasına özen gösterin. Windows Server’ın sunduğu otomatik dengeleme özelliklerini (CAU, Node Fairness vb.) kullanın, ama aynı zamanda manuel incelemelerle de emin olun. Unutmayın ki cluster da bir canlı sistemdir; düzenli bakım, izleme ve iyileştirme ister.
Olası Hatalar ve Sorun Giderme Yöntemleri
Bir cluster’ı kurmak kadar, onu düzgün işletmek de önemlidir. Karşılaşılabilecek yaygın sorunlar ve bunların giderilmesine yönelik ipuçlarından bazıları şunlardır:
Cluster Oluşumu Sırasında AD/DNS Hataları
Cluster oluştururken “Access denied” veya “Network name cannot be found” gibi hatalar alırsanız, büyük olasılıkla cluster adı nesnesi (CNO) AD’de oluşturulamadı. Bu durumda, cluster’ı oluşturduğunuz hesabın yetkilerini kontrol edin.
Gerekirse AD’de bilgisayar konteynerine o hesap için Create Computer objects iznini verin veya önceden bir bilgisayar hesabı oluşturup doğru adla, hesabı cluster düğümlerinin makinelerine sahiplik verin. DNS tarafında ise, cluster adı için zaten var olan bir A kaydı olmadığından emin olun (çakışma olmamalı). Çözüm: AD/DNS izin ve kayıt sorunlarını giderip cluster kurulumunu tekrar deneyin.
Cluster Servisi Başlamıyor (Quorum Yetersizliği)
Eğer bir cluster’ı yeniden başlatmaya çalıştığınızda cluster servisinin başlamadığını görürseniz (özellikle birden fazla düğüm aynı anda down olmuşsa), sebebi quorum’un sağlanamaması olabilir. Örneğin 2 node + tanık cluster’da, her iki node da kapandıktan sonra sadece biri açılırsa normalde quorum yok (1 oy / 3 toplam). Bu durumda cluster kendini başlatmaz. Çözüm: Bu senaryoda ya tanık kaynağını da aktif hale getirmelisiniz (ör. dosya tanığıysa paylaşımı yeniden erişilebilir yapın) ya da Force Quorum (Yalnızca-Okuma Modunda Başlatma) yöntemini uygulamalısınız.
Force quorum için o düğümde komut satırından net start clussvc /fq (Windows Server 2008) veya PowerShell Start-ClusterNode -FixQuorum (2012 ve sonrası) kullanılabilir. Bu, cluster’ı tek düğümle başlatıp quorum yok sayarak çalıştırır; sonra diğer düğümler eklenir. Ancak bu yöntem dikkatli kullanılmalıdır, mümkünse destek dokümanlarına göre adımları izleyin.
Cluster Node Sürekli İşlem Dışına Çıkıyor (Eviction)
Bir düğüm belirli aralıklarla cluster’dan düşüyor (evict oluyor) ve sonra geri geliyorsa, genelde bunun sebebi ağ iletişimi problemleri ya da donanım sorunlarıdır. Event Viewer’da 1135 hataları veya 1177 gibi kayıtlar bunu gösterebilir. Adım 1: İlgili düğümün sistem ve cluster loglarını kontrol edin; network kesintisi mi var yoksa düğüm tamamen mi kitlenmiş? Adım 2: NIC’lerin ve switch’lerin istatistiklerine bakın (drop, error var mı). Gerekirse sorunlu NIC’i değiştirin veya sürücüsünü güncelleyin. Adım 3: Heartbeat threshold’larını biraz artırmak sorunu maskeleyebilir ama esasen network altyapısı istikrarlı olmalıdır. Bu sorun bazen bir düğümün yüksek CPU load altında kalması ve heartbeat’e zamanında cevap verememesiyle de oluşabilir – Perfmon ile CPU’yu izleyin, çok sık tepeye vuruyorsa Node Fairness vs. ile yükü dengeleyin veya kaynak ekleyin.
Cluster Kaynakları Online Olamıyor
Cluster Name, Disk gibi kaynakların durumunun Failed olduğunu görürseniz, altındaki sebebi anlamak gerekir. Cluster Name Failed: Genelde AD veya DNS sorunu olabilir (CNO’nun şifresi senkronize değil veya AD silinmiş olabilir). Olay günlüklerinde 1207, 1222 gibi event’ler bu durumda çıkar. AD’de CNO nesnesinin durumu ve parolası kontrol edilmeli; çözüm için Microsoft’un “Reset-ClusterNetworkNameResource” komutu işe yarayabilir (CNO’yu resetleyip şifresini yenilemek için).
Disk Kaynağı Failed
İlgili paylaşımlı disk tüm düğümlerden görülebiliyor mu kontrol edin. Kablolama, SAN durumu, iSCSI oturumları vb. sağlam olmalı. Disk signature değiştiyse cluster onu bulamayabilir; diski cluster dışına çıkarıp tekrar eklemek gerekebilir. Event log’da disk releted hatalar (1037, 1069 reason 4 vb.) inceleyin. Gerekirse cluster validation storage testini tekrar çalıştırın.
Performans Sorunları
Cluster çalışıyor ancak yavaşlık yaşanıyorsa, hangi kaynak dar boğaz bunu bulmak lazım. Disk IO yüksek mi, ağ mı tıkanıyor, CPU mu 100% gibi ayırt edin. Örneğin CSV kullanan Hyper-V cluster’da bir VM yavaşsa, belki CSV “redirected mode”a düşmüştür (Event 5120 genelde bunu söyler). Bu, bir network sorunu yüzünden olabilir. Veya cluster’daki bir düğüm sürekli yüksek CPU’da ise, Node Fairness devreye girmeyebilir (belki Windows Server 2012 kullanıyorsunuz, onda bu özellik yok).
O durumda manuel dengeleme yapın. Çözüm: Performans sorunları genellikle altyapı iyileştirmesi (daha hızlı disk, daha fazla bellek, daha çok düğüm ekleme) veya konfigürasyon optimizasyonu (ör. bir cluster parametresini değiştirme) ile çözülür. Loglarda gecikme ile ilgili kayıtlar (mesela “SQL took longer than expected to respond”) yakalarsanız, o bileşene odaklanın.
Quorum Yapılandırma Hataları
Yanlış quorum seçimi cluster’ı riske sokabilir. Örneğin 2 node cluster’ı tanıksız bırakırsanız, bir node giderse diğeri de çalışamaz. Bu, bir hata değil ama tasarım kusuru olur. Cluster event’lerinde “quorum lost” gibi bir şey görürseniz hemen yapınızı gözden geçirin. Çözüm: Her zaman uygun bir tanık ekleyin veya cluster’da tek sayı düğüm bulundurun. Özellikle 2 düğümlü cluster’da tanıksız çalışmayın – bu, her iki node up iken sorun çıkarmasa da bir node düşünce diğerini de indirecektir.
Sorun Giderme Yaklaşımı
Bir cluster sorunu ortaya çıktığında yapmanız gereken, önce etkiyi azaltmak, sonra kök nedeni bulup düzeltmektir. Örneğin bir düğüm arızalandı, cluster çalışıyor ama yedeklilik yok – önce o düğümü izole edin (cluster’dan evict edip bakım moduna alın), cluster’ın kalanıyla hizmet devam etsin. Sonra o düğümdeki problemi detaylı inceleyin (minidump, hardware diagnostics). Microsoft’un cluster ile ilgili destek makaleleri, bilinen hatalar ve çözümler için değerli bir kaynaktır. Örneğin failover cluster için yayınlanmış toplu güncelleştirme notlarını incelemek, belki de yaşadığınız sorunun bir hotfix’inin olduğunu gösterebilir.
Son olarak, bir cluster ortamını yönetirken mutlaka güncel Microsoft dokümantasyonlarını elinizin altında bulundurun. Örneğin Microsoft Learn – Failover Clustering sayfaları, hemen her konuda detay içerir. Ayrıca Technet forumları, Microsoft Q&A ve ilgili bloglar da gerçek dünya sorunlarına çözümler barındırır. Cluster üzerinde çalışırken emin olmadığınız bir ayarı değiştirmeden önce mutlaka araştırın; çünkü cluster, yanlış bir ayarla tüm hizmetlerinizi kesintiye uğratabilir.
