Microsoft Cluster Mimarisinde Quorum Yapilandirmasi ve Split Brain Senaryosu

Ahmet Musa KOSALI 02/03/2014

0 6 dakika okuma süresi

Cluster sisteminin temeli oy sahipliği üzerine kurulmuştur. Cluster’a dâhil sunucuların en az yarısından 1 fazlası yani (

kuralına istinaden ayakta olması gerekmektedir. Eğer Cluster’ınız içerisindeki sunucu sayınız yukarıdaki örnekte verdiğim gibi 3 node’tan oluşuyorsa en az iki sunucunun ayakta kalması servis sürekliliğini sağlayacaktır. Fakat sunucu sayınız çift ise servisinizin ayakta her daim kalabilmesi için Cluster’ınıza ekleyeceğiniz ortak bir diski QUORUM olarak tanımlayarak toplam oy sayınızı teke çıkartmış olursunuz.

Daha rahat anlaşılması için şöyle örnek verebiliriz: 2 Site ve her Site’da 2 sunuculu cluster kurmak istiyorsunuz. Bu durumda Cluster oy sayınız ( olduğundan eğer Site’larınızdan birinde bir problem olursa Cluster’ınız down olacaktır. Bu sorunu çözmek için cluster’a ek olarak eklenecek yeni bir diski Quorum olarak tanımlamak gerekmektedir. Bu durumda Cluster oy sayınız ( olacaktır yani site’larınızdan birinde bir problem olduğunda servis sürekliliğiniz devam edecektir.

Default’ta cluster’a dâhil tüm node’lar oy kullanır. Server 2012 ile birlikte hangi node’ların oy kullanabileceği belirlenebilmektedir. Asenkron veri replica edilen ve 100 metre mesafeden uzakta bulunan 2012 SQL Geo Cluster node’larınızı olası bir problemle karşılaşmamak için oy verme hakkının alınması gerekmektedir. Bu işlem ister Failover Manager tool’u üzerinden isterseniz de PowerShell üzerinden yapabilirsiniz. Bu işlemi PowerShell üzerinden yapmak isterseniz aşağıdaki komutu kullanabilirsiniz. ContosoFCNode1 yerine sunucu ismini yazarak ve NodeWeight Değeri 0 verirseniz oy kullanmayacaktır. 1 olarak vermeniz durumunda ise oy sistemine dâhil olduğunu göstermektedir.

(Get-ClusterNode ContosoFCNode1).NodeWeight=0

Server 2012’de bu özelliğe ek olarak her bir node kapatıldığında oy sistemi yeniden hesaplanmaktadır. Eğer sunucularınızı düzenli bir şekilde sırayla kapatacak olsanız cluster tek node’la bile çalışacaktır. Fakat düzensiz kapatmalarda hesaplamanın yapılmasına imkan tanınmayacağından servis kesintisi yaşanabilir.

Cluster’ı yapılandırdığınızda belirlemiş olduğunuz isim ve ip adresi birlikte CLUSTER GROUP’u oluşturmaktadır. Eklenen Quorum diskine sahip olan node Cluster Group’a da sahiptir. Cluster konfigürasyon bilgisi hem Quorum diskinde tutulduğu gibi her bir node’un register’ında Hkey_Local_Machine altında cluster klasörü altında yer almaktadır. Quorum diski üzerindeki 0.hive isimli dosyasında yer aldığı bu bilgi Quorum diskine sahip sunucu üzerindeki register’da Hkey_Local_Machine altında 0.cluster klasörü altına replica edilmektedir. Quorum diski failover yapıldığında 0.cluster klasörü silinir taşınan sunucu üzerinde oluşturulur. Buradaki bilgi belli aralıklarla tüm cluster’ın node’larına senkronize edilir ki bir şekilde Quorum diski veya Quorum diskine sahip sunucu kaybedilir veya erişilemez olursa Cluster down olmasın.

Cluster’ın temel çalışma mantığı SHARED NOTHİNG MODELİ üzerine kuruludur. Yani tüm cluster’a ait node’lar tüm diskleri görürler fakat sadece bir node disklerin sahibi olur. Sahibi olan node yazma ve okuma hakkına sahiptir. Diğerleri sadece erişir. Cluster’ın disk erişim kontrolünü Server 2003 ve öncesi sistemlerde “SCSI BUS” komutları ile yapılırken 2008 ve sonrası sistemlerde “SCSI 3 Serial Persisten Reservation” komutları ile sağlamaktadır. Aşağıda bu konunun daha iyi anlaşılması için aynı disklerin pasif ve aktif node üzerindeki görüntüleri sunulmuştur. Bu ekran görüntüsünde görüleceği gibi diskin sahibi olunan node üzerinden bakıldığında disk label bilgileri görülebilirken pasif node üzerinde sadece size bilgisi okunmaktadır.

Bir node Quorum diskini göremez veya erişemezse bu durumda öncelikle kendi cluster servisini restart eder. Eğer sorun çözülmez ise kendini restart eder.

Split Brain Seneryosu:

Quorum konusunu işleyipte “Split Brain” senaryosuna değinmemek olmaz. Tüm High Availability sistemlerde network temelli erişim kesintilerini ifade eden SPLIT BRAIN senaryosu Microsoft Failover Cluster sisteminde node ve site sayısına göre değişiklik arz etmektedir. “Split Brain senaryosu nedir ve nasıl oluşur?” konusunu aktarmadan öncelikle temel Cluster öğeleri hakkında bazı bilgileri hatırlayalım.

Klasik ve basit cluster yapısında Nodelar arasındaki cluster iletişimi için bir heartbeat dediğimiz PRİVATE network’üne birde cluster’da hizmet verdiğimiz servisin dış ortamla iletişimde bulunduğu PUBLİC network’üne ihtiyaç bulunmaktadır.

Cluster’ın ilk yapılandırdığınızda Cluster servisi için bir ip ve makine ismi tahsis edilir. Buna aynı zamanda Cluster Group’da denir. Cluster Group için tahsis edilen ip adresi Quorum’un sahibi olduğu sunucu üzerindeki Public network’üne bağlanarak erişime açılır / hizmet verir. Cluster üzerinden hizmet verecek servisin yapılandırması işleminde de bir adet ip ve isim tahsis edilir. Buda aynı Cluster servisi gibi hangi node üzerinde çalışıyorsa o sunucunun Public network’ünü kullanarak hizmet verir. Bu durumda Cluster ve 1 adet Servisin aynı sunucu üzerinde çalışıyorsa toplamda bir makineye ait 3 ip adresi bulunuyor olarak görülecektir.

Cluster’da her bir isim, disk ve ip birer Resource olarak adlandırılır. Cluster servisi ayrı üzerinde çalıştırdığı her bir servis de ayrı olmak üzere Group olarak ifade edilir ve grup bazlı node’lar arası taşıma yapılabilmektedir. Örneğin SQL servisini cluster yaptığınızı düşünelim. Bu durumda “SQL Server (MSSQLSERVER)” ve “Cluster Group” olmak üzere 2 adet grup bulunmaktadır.

Cluster’ın asıl görevi resourse’lerin ve node’ların devamlı olarak sağlık bilgisinin kontrolünü yapıp güvenilirliği sabit kılmaktır. Disklerin güvenilirliğini SCSI3 komutlarıyla sağlarken node’ların güvenilirliğini private (heartbeat) interface’i üzerinden belli aralıklara yaptığı kontrollerle sağlamaktadır. Eğer Private interface’i üzerinden sağlık bilgisini alamazsa Public interface üzerinden sağlık bilgisini almaya çalışır (Bu özellik 2008’de vardı fakat tam olarak çalışmıyordu. 2008r2 ve sonrası sistemlerde kesinlikle geçerlidir). Eğer Public üzerinden node/node’ların sağlık bilgisi de alınamazsa Default Gateway’e ping atarak sorunun kendisinin çalıştığı sunucuda/node’da mı yoksa sağlık bilgisi gelmeyen node/node’larda olup olmadığını anlaya çalışır.

Network üzerinden diğer node’lara ve gateway’e erişemeyen sunucu öncelikle Default olarak 1 kere cluster servisini restart eder. Eğer servisin restart olması sorunu çözmezse sunucuyu restart eder. Restart sonrası hala diğer node’larla erişim sağlanmıyorsa fail vererek servisi stop’a çekilir. Başka bir makalemde Cluster policy’leri anlatılacağından burada bu konuya girmeyeceğim.

Buraya kadar yapılan anlatımlarla bir cluster sisteminde olmazsa olmazları gördük. Şimdi ise Microsoft Failover Cluster’da hangi durumlarda Split Brain oluşur ve çözüm önerilerini örnekleriyle inceleyelim:

Yukarıda örneğini vermiş olduğumuz topolojide 1. Site’da 2 diğer site’da 1 adet node’un bulunduğu toplam 2 Site içinde 3 node’lu cluster yapınız olduğunu ve 2 node’un bulunduğu Site1’de network problemi olduğunu düşünelim. Site2’deki node tek kalacağından çoğunluk sağlanamaz ve Cluster düşer. Eğer site’lar arasında senkron data transferi varsa ve Site1’in ayağa kalkma süresi fazla sürecekse kesinti süresini azalmak için yapılması gereken tek şey komut satırından “net start clussvc /forcequorum” veya “Net Start ClusSvc /FQ” PowerShell komutuyla online yapabilirsiniz

Yukarıdaki topoloji örneği verilen 2 Site’lı ve her Site’da 2 node’lu yapıda Site’lar arasında network problemi yaşadığını düşünelim. Gateway’e ping atamayan sunucular kendini restart edecek ve sorun devam ederse cluster servisini kapatacaktır. 4 Node’lu yukarıdaki örnekte eğer sunucular gateway’e erişiyor fakat site’lar arasındaki node’lar birbirlerine erişemiyorlarsa bu durumda Quorum diskini tutan resourceleri üzerine alır.

Quorum Modelleri şunlardır;

4 Quorum tipi bulunmaktadır. Bu adımlar ilk cluster yapılandırılmasında yapılacağı gibi sonradan da yapılabilmektedir. Özellikle sonradan node ekleme veya çıkartma süreçlerinde dikkat edilmesi gereken önemli bir konudur.

Node Majority: Sadece sunucuların oy kullanımını içeren Quorum modelidir. Eğer Cluster’a eklediğiniz sunucu sayısı tek sayıda ise bu model kullanılmaktadır.

Node and Disk Majority: Oy kullanımında hem sunucuların yer aldığı hem de witness diskin kullanıldığı kısımdır. Bu seçeneği Çift sayıda sunucumuz olduğunda servis sürekliliğini sağlamak için Quorum’a dedicate ortak bir disk seçilerek yapılır.

Node and File Share Majority: “Node and Disk Majority” ile benzer özelliklere sahiptir. Quorum için ortak bir diskin bulunmadığı zamanlarda kullanılmaktadır. Fark olarak Tüm Node’ların erişebileceği bir paylaştırılmış dosya kullanılmasıdır. Bu yapıda dikkat edilecek 2 nokta var; birincisi fileshare alanın network erişim kaybının olmaması ikincisi ise NTFS olarak formatlı bu disk üzerindeki paylaşımın en az SMB v2.1’i desteklemesidir. Önerilen ise File Server olarak Windows Server 2008r2 ve üstü bir sunucu üzerinde konumlanmış ortamın kullanmanızdır.

Eğer ilk defa cluster’ı kuruyorsanız kurulum aşamasında Quorum tanımlamasını yapılmaktadır. Sonradan da aşağıdaki adımları uygulayarak gerekli değişiklikleri yapabilirsiniz.

Server 2008 üzerinde Quorum yapılandırması:

Failover Cluster Management çalıştırılır. Gelen ekranda oluşturmuş olduğumuz Cluster ismi üzerinden sağ tıklayarak önce “More Actions” arkasından da “Configure Cluster Quorum Setting” tıklanır.

Gelen ekranda yapacağımız Quorum tipi seçilir.

“Node and Disk Majority” seçilirse bir sonraki adımda hangi diski QUORUM olarak yapılandıracağınızı soracaktır. Eğer File Share seçeneği seçilirse bu sefer paylaşılmış dosyanın path’ini tam olarak yazmanız istenilecektir. Bu işlemlerden sonra yazma testleri yapılır. Bir sorun görülmez ise seçtiğiniz Quorum tipi Failover Cluster Manager üzerinde Quorum Configuration alanında görüntülenecektir.

Server 2012 üzerinde Quorum yapılandırması:

Gelen ekranda “Advanced quorum configuration and witness selection” seçilir

Gelen ekranda Oy kullanacak sunucuları seçilir. Eğer Node’larınızdan 100 Km’den fazla uzaklıkta Asenkron replica olanlar var ise önerim bu sunucuların oy hakkının alınması yönünde. Çünkü networksel sebeplerden ötürü Cluster’ınız down olmasın.

Default’ta Cluster servisi eklenen node’ların oy hakkını kendisi otomatik olarak yönetir. Eğer siz bu dinamik yapıyı elle yönetmek isterseniz gelen ekranda “Allow cluster to dynamically .. . . . .” yazan tiki kaldırın.