Cluster Sorunu [!]

Panik olmayalim ve durumu incelemeye baslayalim. Onun için de ilk araçlarimizi toparlayalim.

Windows Server 2003 e kadar default davranis olarak server cluster node lari arasi system event log lari replike edilirdi. Elbette bu kapatilabiliyordu, ama amaç herhangi bir disaster senaryosunda bir nodeda sadece erisilebiliniyorsa, iki node un en temel verilerini toparlayabilmekti. Ancak cluster loglari replike olmuyordu ve ondan da uzun vadede cluster loglari hem text formatinda yürütmenin ve system event loglari replikeetmenin gereksiz bir overhead ve sorumluluk oldugu kararina varildi. Performans sorunu olarak bazen çok asiri durumlarda replikasyon tam olmuyordu veya cluster loga bütün bilgiler flush olamiyordu. Böyle durumlarda performans biraz daha iyi olabilsin diye de cluster logun boyutu çok küçük birakiliyordu ve genelde bir iki gün içerisinde kendisini overwrite ediyordu. Zaten her türlü troubleshooting için genelde post mortem bütün node lara erisebilir ve veri toplanabilir oldugu için, replikasyon kendi amacinda kullanilmiyordu ve çok kez kapatiliyordu. Ondan Windows Server 2008 den intibaren hem text formatinda cluster logu tutulmasindan ve default system event log replikasyonundan vaz geçildi.
Bizim için bu su demek: Windows Server 2003 clusterimiz varsa, her node da C:\Windows\Cluster altinda o node un cluster logunu bulabilirsiniz ve bu log kopyaladiginiz an günceldir.
Windows Server 2008 den intibaren cluster log bir trace oldugu için (Event Tracing for Windows ,ETW) ilk text formatina parse edilmelidir. Bir node da ‘cluster log /generate’ komutunu çalistirirsak normalde her node da C:\Windows\Cluster\Reports altinda cluster logu bulabiliriz. Burada log komutun çalistirildigi an günceldir. Yani bir ay sonra o parse edilmis logu alirsak, o bir ay öncesine kadar güncel olmusbir logdur.
Cluster logu hep circular queue mantigi ile çalisir ve belli bir boyutta kendi üstüne yazmaya baslar.

Nodelardan system event loglarini error, warning ve critical eventlere göre filteledikten sonra incelemeye basliyoruz. Bu bizim sorun senaryosunu anlamaizi sagliyor. Örnegin bir 1069 eventi hangi grupdaki hangi resource un ne zaman hangi node da fail ettigini gösterir, ama daha fazla detay vermez. Bu detayi da cluster logda bulabiliriz. Ancak 1069 eventi ile korele eden cluster log kayitlarini bulamiyor olabilirsiniz. Bunun nedeni basittir, yanliszama na bakiyorsunuzdur. Log, sistem zaman dilimi ile alakali olmayip hep gmt dedir. Türkiye gmt+2 zaman dilimindedir. Yani system event logda saat 3 (gmt+2) de düsen kaydi, cluster log da, iki saat geride saat 1 (gmt+0) de bulabiliriz. Ancak loglari 2 saat fark ile analiz etmek yeterince karmasik bir durum olmadigi için, bunu bütün yil yapmiyoruz. Yazin bir saat daha ekliyoruz. :) Yaz saatinde aslinda gmt+3 e geçmis oluruz ve system event log ve cluster log arasindaki fark 3 saate çikar. Yani yaz saatinde system event logda ki saat 3 kaydini, cluster log da saat 12 de bulabiliriz. Bu yapinin elbetteki çok mantikli bir nedeni var; o da geo clusterlar. Örnegin farkli kitalarda, farkli zaman dilimlerinde ve farkli yaz/kis saati uygulamalari olan ülkelerde duran node larin loglarini analiz ederken kolaycana zamanlari sasirip yanlis yorumlamak mümkün. Mesela ABD, ve Türkiye dahil olmak üzere, Avrupa farkli zamanlarda yaz/kis saati geçislerini yapiyorlar; ve örnegin bazi orta dogu ülkeleri hiç saat degisikligi yapmiyor. Bazen de ülkeler kendi takvimlerine göre istisna yapabiliyorlar. Cluster log sabit gmt olmasaydi, mesela bütün bu ülkeler üzerine dagilmis bir clusterin problem sonrasi incelenmesi çok daha zor olurdu.

Simdi event log daki hatalar i ve beraberindeki cluster log kayitlarini kronolojik bir siraya dizebiliriz. Su an ne olmus oldugunu loglanabilir detayina kadar biliyoruzdur. Peki ama logdaki herseyi anliyor muyuz? Kayitlarin tam olarak hangi konteksde düstüklerini ve ne demek olduklarini anlamak gerekebilir.
Onun içinde ilk mimariyi daha iyi anlamamiz gerekebilir.

Cluster in en önemli parçasi her node da hep çalisan clussvc.exe cluster servisidir. Aslinda cluster in da yaptigi üstünde çalisan kaynaklarin ve bunlarin ihtiyaci olan diger kaynaklarin durumlarini kontrol etmek ve gerektiginde kurtarici adimlari uyarlamaktir. Yani cluster in kendisi hiçbiryabanci kodu gerçek anlamda çalistirmaz. Örnegin DHCP clusterlanmisise, cluster lokalde çalisanservisin sadece aktif node da açik olmasini saglar ve DHCP in kullandigi disk, network name ve IP gibi kaynaklarinda durumunu kontrol eder. Bu basit tanimlamanin arka planda dönen detaylarini asagidaki modüllerin özetinden sonra bulabilirsiniz.

Cluster in konfigürasyonureplika denilen CLUSDB de tutulur. Bunu her nodeda cluster klasöründe bulabiliriz. Bunun ile ilgili yapilan degisikliklerden dolayiolusan farklari da ortak bir lokasyonda bir temp dosyasinda tutariz. Bu örnegin file share witness,witness disk veya Quorum da durabilir. Elbette replikanin son versiyonu güncel olarak kabul edilir ve bu degisiklikler içerse de node lar tarafinda uyarlanir. Yani bir node kapaliyken yapilmis olan degisiklerikendisi açildiginda hemen uyarlar. Her sart altinda burada sorun olmasini engelleyen ve dogru replikanin seçilmesini saglayan algoritma paxos olarak geçer. CLUSDB yi cluster servisi çalisiyorsa lock etmistir, ancak servis duruyorsa örnegin registry e yükleyebilirsiniz. Clussvc.exe de bunu zaten çalistiginda ilk olarak HKLM altinda Cluster olarak yükler. Burada bütün konfigürasyon detaylarini görebilirsiniz. Cluster in kullandigi bütün bilgiler buradadir. HKLM\0.Cluster olarak da ortak bölgedeki replika yüklenir.

Diskler ile ilgili islemlerden clusdisk.sys modülü sorumludur. Network tarfindaki sürücü clusnet.sys dir. Kendisi bir sanal adaptör yaratir. Cluster TCP Port 3343 ü kullanir. Bu iki modül disinda cluster in Kernel tarafinda çalistirdigi baska modül yoktur.

Usermode tarafinda ayrica cluster.exe çalisir. Asil cluster yönetim islemlerini bu modül ile yapariz. Failover cluster manager da yaptigimiz islemlerde arka planda hep cluster.exe çagrilir. Örnegin cluster logu da kendisi olusturur. System32 altinda olan tek modüldür. Diger user mode modüllerin hepsi cluster klasöründedirler.

Son executable Resource Host Subsystem, rhs.exe dir. Yaziliminizi cluster aware yapmak isterseniz, bunun için bir resource DLL yazabiliriz. Cluster a o resource hakkinda bir blue print vermis oluruz, resource la cluster in konusmasini saglayabiliriz. Iste yazilimin cluster tarafinda görüstügü kisimda rhs.exe dir.Rresourcelar bunun içinden çalisabilir. Örnegin bir generic script resource u çalistirisaniz, task manager da yeni bir cmd.exe degil de, yeni bir rhs.exe processi görebilirsiniz. Her resource kendi rhs.exe si ile beraber çalisabilir, veya bir çok resource bir rhs.exe yi kullanir. Bir resource onun ile ilgili rhs.exe sinin crash olmasina neden olursa, o resource artik kendi rhs.exe si ile çalismaya devam eder (rhs izolasyonu).

Clussvc.exe yi islevsel görevlerine görefarkli mantiksal modüllere/yöneticilerebölebiliriz. Bu spesifik detaylar ile log kayitlari eklenir. Ondan asagidaki açilimlar cluster log analizini çok kolaylastirabilir. Ayrica cluster servisinin görevlerinin özeti olarak da anlayisimizi arttirabilir, çünkübu abstraksiyonun nedeni cluster i daha iyi anlayabilmek içindir. Bu yapi sadece log da kullanilir. Böylece nereden hatanin geldigini gördügümüzde hemen analizimize yön verebiliriz.

Object Manager [OM] , Node larda bellekde tutulan bilgilerin yönetiminden sorumludur. Bütün kaynaklarin ve ortamin durumu ve hangi node da hangi resourcelarin online oldugu bilgisinden sorumludur. Yani bu cluster in ‘bilinç üstü’ kismidir.
Host Manager [HM] , cluster olusturma, örnegin sifirdan veya reboot dan sonra nodelarin cluster a eklenmesi gibi görevlerden sorumludur. Node larin durumlarini takip eder.
Membership Manager [MM] , dinamik güncellemelerden, HKLM\System\CCS\Services\ClusSvc\Parameters dan soruuludur.
Global Update Manager [GUM] , her türlü bilgilerin node lar arasi iletilmesinden sorumlu.
Resource Control Manager [RCM] , rcm.exe in clussvc.exe tarafinda görüstügü kisim. Online, offline, failed, online pending, offline pending, partial online gibi statüleri onaylar, Create, delete, property changes gibi islemleri yapar ve cluster.exe ile  move ve failover gibi islemleri yapar.
Topology Manager [TM] , network tarafi ile ilgilenir.
Network Manager [NM] , cluster network leri ile igilenir.
Interface Manager [IM] , network adaptörleri ve özelliklerinden sorumludur. Örnegin NIC in Up, failed ve networkün unreachable networkde: up, down, partitioned statülerin kararlarini verir. Örnegin bir networkde sadece bir node un NIC i arizali olursa bu network partitioned olur.
Database Manager [DM] , bütün replikalardan sorumludur. Örnegin CLUSDB/registry ile ilgili sorun kayitlari beraberinde görürüz.
Quorum Manager [QUORUM] , seçilmis quorum modelinde quorum a varilip varilmadigi karari verir. Security Manager [SM] , bunla beraber Security Validator [SV] danda authetication vs. hatalar görülebilir.

Ilk system event loglarindan sorunun senaryosunu anladik. Sonra cluster logda iliskin hatalari bulduk ve yorumladik. Simdi cluster sorununu anlamisdurumdayiz ve asil simdi baska ne veriye ihtiyacimiz oldugunu belirleyebiliriz, troubleshooting ve arastirmalara girisebiiriz. Buraya kadar gelmeden, sorunu anlamadan troubleshooting verimsiz olabilir.

Cluster log ile ilgili linkler:
https://support.microsoft.com/kb/168801 How to turn on cluster logging in Microsoft Cluster Server
https://support.microsoft.com/kb/286052 The meaning of state codes in the Cluster log
https://support.microsoft.com/kb/225081 Cluster resources quorum log size defaults to 64 KB
https://technet.microsoft.com/en-us/library/cc961673.aspx Interpreting the Cluster Log
https://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf Paxos

Basar Güner