Microsoft Windows Server 2012 Failover Clustering Gelişmiş Ayarlar
Failover Clustering rolü, Server 2012’nin diğer özelliklerindeki gibi geliştirildi. Birçok yenilik, edinim maliyetlerinin ucuz olması tercih edilebilirliğini görünür oranda arttırdı. Fakat Exchange 2010 ile hayatımıza giren Database Availability Group için bile önkoşul olan Failover Clustering özelliği genel olarak Hyper-V ile anılmakta. Yapılabilecek diğer yüksek erişilebilirlik senaryolarını diğer makalelerde ele almaya çalışacağım.
Bu makale içerisinde yüksek erişilebilirlik senaryoları için geçerli ve Server 2008’den bu yana bulunan bazı temel özellikler ve gelişmiş ayarlarla ilgili bilgiler, küçük senaryolar ve nasıl kullanılabilir örneklerini okuyabilirsiniz.
Öncelikle Server 2012 için Serhat Akıncı Hoca tarafından hazırlanmış başlangıç makalesini incelemenizi
öneriyorum:
Failover Cluster rolü içerisinde yeralacak yüksek erişilebilir uygulamalar için Server 2008 R2’den ilk bakışta pek fark yok gibi görünmektedir. Fakat Hyper-V rolüne eklenen replica özelliği ile birlikte çalışacak Hyper-V Replica Broker ve File server için geliştirilen Scale-Out File server, daha önceleri iSCSI target eklentisi ile yapabildiğimiz ama şimdi geliştirilerek gömülü bir hal kazanmış iSCSI Target Server özellikleri önemlidir. Aşağıdaki resimde sol tarafta Server 2012 ve sağda Server 2008 R2 ile oluşturabileceğiniz yüksek erişebilir uygulama veya servisleri görebilirsiniz.
Makalemizin konusu gelişmiş ayarlar olduğu için diğer ayrıntılara girmiyoruz.
Öncelikle denemelerimizi yapacağımız bir uygulamaya yüksek erişilebilirlik kazandırarak başlıyoruz. Hesap makinesi uygulamasını yüksek erişibilir hale getireceğiz. Öncelikle sihirbazımız içerisinde hesap makinesi ile ilgili bir ön tanımlama olmadığından Generic Application seçiyoruz.
İlerleyen adımda uygulamanın yolunu belirterek gerekiyorsa çalışması sırasında kullanacağı parametreleri belirliyoruz. Hesap makinesi, son derece basit bir uygulama olduğundan, herhangi bir parametreye veya ilerleyen adımlarda göreceğiniz depolama (storage) ve registry ayarlarını belirtmeye gerek olmayacak.
“Client access point” kullanıcıların oluşturduğumuz failover yapısına erişecekleri noktayı belirtmektedir. Cluster içerisinde kurulum aşamasında otomatik belirlenen veya sonrasında bizim ekleyebileceğimiz ağ kartlarının ayarları ile uyumlu bir IP adresi belirlenmesi gerekmektedir.
Tüm ayarların tamamlanmasından sonra uygulamamız yüksek erişilebilirlik için hazır hale gelmiştir.
Uygulamanın çalışırlığının kontrolü için temel olarak DNS üzerindeki kaydın oluşup oluşmadığının sorgulanması ve ping atma işlemlerini yapabiliriz.
Ek olarak daha önce “tlist” olan fakat Server 2012 ile “tasklist” komutu ile calculator “client access point”i için çalışan servisleri sorgulayabiliriz. Bu sırada sorgunuzun sağlığı açısından, “core servisler”e sahip node üzerinde calc.exe çalışıyorsa kapatmanızı öneririm. Aksi takdirde bu komutla birden fazla calc.exe göreceksiniz, task manager üzerinden PID kontrolü ile hangisinin yüksek erişilebilir olduğunu ayırt etmeniz gerekecektir.
Bu işlemlerle yaptığınız işlemin çalıştığından emin olarak Failover Cluster Manager üzerinden devam edeceğiz. Calculator adındaki uygulamanızın üzerine tıkladığınızda, ayarlarla ilgili bir özet görünecektir.
Bu uygulamaya bağımlı kaynakları kontrol etmek için “Resources” sekmesini kullanabilirsiniz. (1) Uygulama adınız, bunun için oluşturduğunuz client access point (CAP) ve çalışan uygulamanız bu şekilde görünür.
Buradaki genel bakışımızda iki detay dikkatimizi çekebilir. Bunlardan birincisi “Priority” (2) diğeri “Preferred Owners” (3) ayarıdır.
Priority (öncelik)
seviyesi Server 2012 ile gelmiş yeni bir özelliktir. Daha önceki sürümlerde uygulamaların bulunduğu node üzerinde herhangi bir sorun meydana geldiğinde tüm yüksek erişilebilir (HA) uygulamalar diğer node üzerine aynı anda geçmekteydi. Cluster özelliği her ne kadar aynı donanımsal özelliklere sahip sunucular üzerinde önerilse de her zaman için bu koşulları sağlamak pek mümkün olmayabiliyor. Özellikle büyük organizasyonlarda her sunucuyu aynı anda yenilemek veya tüm sunucuların donanım arttırma maliyetlerine katlanmak sıkıntı yaratabiliyor. Elinizdeki eski bir sunucuya RAM alamadığınız durumlarda bir sunucunuzu eksik değerle çalıştırmak zorunda kalabilirsiniz.
Bu senaryonun bir sanal sunucu HA (virtual machine) yapısında olduğunu düşünürsek, yüksek RAMli sunucunuz üzerindeki tüm sanal sunucuların, eksik olana aktarılması sırasında tüm sunucuların bu node üzerinde sorunsuz başlamasını bekleyemeyiz. İhtiyacımıza göre eğer bu sunuculara öncelik kazandırabilirsek sorunsuz bir failover yapımız olabilir. Bunun için aşağıda görüldüğü gibi varsayılan değeri “Medium” olan önceliği değiştirebiliriz. Aynı zamanda sunucunun otomatik başlamasının önüne de geçebiliriz.
Priority işi ortaya çıkmadan önce bu işlemi “Preferred Owners” değerini değiştirerek yapmak da mümkündü. Bu özellik hala yerini korumaktadır. Yukarıda bahsettiğim mantıkla birden fazla node sahibi olduğunuz yerlerde eksiklik veya performans ihtiyaçlarınıza göre HA bir uygulamanın bulunduğu yerden sonra nereye gideceğini de belirleyebilirsiniz. Bunun için uygulamanızın üzerinde sağ tıklayarak veya yukarıda resimdeki “Any node” hyper-linkine tıklamalısınız.
Özellikler penceresinde varsayılan olarak tüm nodelarınızın seçili olmadığını görürsünüz. Aslında bu şekilde uygulamalarınız tüm nodelarınız üzerinde gezebilir durumdadırlar. Eğer herhangi bir node dizisini (1) seçerseniz “Up” ve “Down” (2) butonlarının da aktive olduğunu görebilirsiniz. Bu şekilde cluster yapınızı tamamen kapattığınızda açılan sunucuların bu sıraya göre sunuculara dağıldığını veya bu sıraya göre failover olduklarını göreceksiniz. Örnekteki seçime göre calculator adındaki uygulamamız bir sonraki failover işleminde CP2012CLS2 sunucusuna geçecektir. (ve daha sonrasındaki failover durumunda tekrar CP2012CLS1 sunucusuna dönecektir.)
Özellikler penceresinden devam ettiğimizde “Failover” sekmesinde de birkaç ek özellik tanımlanabilir. Uygulamamız belirli sure içerisine (varsayılan değer 6 saat) belirleyeceğimiz adet kadar (varsayılan değer 1) sorun yaşaması durumunda artık cluster servisi tarafından herhangi bir failover, restart vs. işleme tabi tutulmayacak hale gelir. Bu şekilde herhangi bir matematik denklemini söze döküyormuş gibi oldu ama ilerleyen satırlardaki örnekte tam olarak ne işe yaradığını daha rahat anlayabilirsiniz.
Buradaki diğer ayar failback durumlarındaki işlemle ilgilidir. Failover özelliği adı gibi sürekli düşme üzerine bir yapı olmayıp, ayağa kalkmayı da içermektedir. Örneklemek gerekirse herhangi bir sebeple nodelarınızdan birinin üzerindeki cluster servisi durduğunda veya ulaşılamadığında üzerinde HA uygulama yukarıda belirlediğimiz gibi herhangi başka bir sunucunun üzerine düşecektir. Fakat sorunlu sunucu üzerindeki problem giderildikten sonra HA uygulamamız varsayılan olarak olduğu yerde kalır.
Ancak bir sonraki döngü onu ilk sunucuya taşırsa veya elle geri dönmesini sağlarsak asıl sunucusuna döner. Bu da mesela önemli bir sunucumuzun donanımsal özellikleri düşük bir sunucuda biz durumdan haberdar olana kadar çalışması ve haliyle performans kaybı yaşamamız demektir. Özellikle NIC teaming yapılandırdığımız senaryolarda geniş ağ kapasitesine sahip olduğumuz bir sunucu dururken 100Mbit/sn lik bir sunucu üzerinden SQL çalıştırmamız büyük bir performans kaybı olabilir. Aynı şekilde işlemci, disk I/O performansı da sorun olacaktır.
İşte bu sebeplerle çalışma performansından memnun kaldığımız sunucuya, sorun giderildikten sonra geri dönme işlemini “allow failback” seçeneğini seçerek yapabiliriz. “immediately” seçeneği ile sunucu ayağa kaltıktan hemen sonra “failback between” seçeneği ile ayağa kalktıktan belirli bir süre sonra dönüş işlemini otomatik hale getirebiliriz. Zaman belirleme node üzerindeki yüklü servislerinizin zaman gerektirmesi veya service pack güncellemeleri sırasında birden fazla tekrar başlatma gerekebildiğinden tercih ededilebilir. Service pack geçişi sırasında veya bu sunucuya hyper-v rolü yüklerken sunucuların sürekli quick migrate oluyor olması servis kesintisine yol açacaktır. O yüzden bu ayarları her türlü durumu düşünerek yapın.
Bu ayarlamalarımızdan sonra uygulamamızın biraz detayına inebiliriz. Yapılandırdığımız calculator uygulaması bahsettiğim gibi “resources” sekmesinde bize biraz ayrıntılı bir görünüm sunmuştu. Bu görünümde “roles” altındaki “calc Application” özelliklerini kontrol edersek “general” sekmesinde çalışan uygulamamızın yolunu görebiliriz.
“Dependencies” (bağımlılıklar) sekmesi bizim için önemli olabilecek bir yerdir. Varsayılan olarak herhangi bir rol HA uygulamamıza bağımlıdır. Yani eğer HA yapımız başlamazsa uygulamamız da başlamayacaktır veya biz calculator adındaki HA yapımızı durduğumuzda otomatik olarak buna bağlı tüm kaynak ve roller duracaktır.
Aşağıdaki resimde görülebileceği gibi calculator uygulamasına bağımlı olan “calc Application” adındaki rolümüz calculatorü kapatınca kapandı. Tam ters durumu düşünürsek “calc Application” rolünü başlatmak istediğimizde bu öncelikle bağımlı olduğu calculator HA uygulamasını başlatmaya çalışacaktır. Daha sonra da kendisini.
Kısacası yıllardır süregelen “yumurta mı tavuktan, tavuk mu yumurtadan çıkar?” sorusuna, Microsoft eğer bağımlılıkları tanımlıysa birbirlerinden çıkıyorlar işte diyor.
HA bir uygulamanın veya bir kaynağın bağımlılık raporu, üzerine sağ tıkladıktan sonra “more actions” altındaki “show dependency report (bağımlılık raporunu göster)” ile alınabilir. Rapor yine bir Microsoft klasiği kullanıcı dostu arayüz ile hem text biçiminde, hem de şema ile çıkacaktır.
Anlattıklarımı rapor üzerinden tekrarlamak gerekirse, HA uygulamamız networke, calc rolümüz de uygulamamıza bağımlı durumdadır. Dolayısıyla network kaynağımızı pasif duruma getirirsek tüm uygulamamız pasiflenecektir. Networkü tekrar başlatırsanız diğer hiçbir kaynağınız otomatik başlamaz. Ancak en alttaki calc rolünü başlatırsanız diğer tüm kaynaklar sırayla başlayacaktır.
Bu durum gayet mantıklı görünmekle birlikte kullanıcının ihtiyaçlarına yönelik olarak değiştirilebilir durumdadır. Örnek olarak rolümüzün içeriğine bir vbs scripti ekleyelim. Bunu yapmak için HA uygulamanın üzerinde sağ tıklayıp “Add resources (kaynak ekle)” altından “generic script” seçelim. İlk aşamada script yolunu belirtmeliyiz. Ben sunucularımda bir vbs script oluşturup her ikisini de aynı dosya yoluna attım. Yeri c:\test\new.vbs olarak belirledim. Generic scriptlerin tanımlarıyla ilgili olarak http://msdn.microsoft.com/en-us/library/aa373089(VS.85).aspx ve http://msdn.microsoft.com/en-us/library/aa372844(VS.85).aspxadreslerinden yararlanabilirsiniz.
Dikkat edilmesi gerekenler:
*vbs scriptinizin gerçekten bir resource belirtiğine emin olun. “merhaba dünya” burada işlemiyor. (execution failed hatası alabilirsiniz.)
*Scriptinizi benim gibi nodelar için ortak erişilebilir bir alana değil de local disklerden çalıştıracaksanız her iki cihazda da bulunduğundan emin olun. Aksi takdirde herhangi bir node için doğruysa, bir hata almayacaksınız. Doğru olan node uygulamanın halihazırda bulunduğu node değilse sorunsuz çalışabileceği node’a otomatik failover olacaktır. (denemelerinizi lab ortamında yapmanın inanılmaz çekiciliği)
*Vbs içeriğinize göre ilk oluşturma sonrasında kaynağı pasif durumda görebilirsiniz. Aktive ettiğinizde (bring online) sorunsuz açılacaktır.
Yukarıda bahsettiğim gibi, script yolunuzun eş olduğuna dikkat etmezseniz işleminizi bitirdikten sonra şu ana kadarki bütün resimlerde CP2012CLS1 üzerinde görünen sunucunuz birden CP2012CLS2 sunucusu üzerine geçecektir.
Bu aşamadan sonra yukarıdaki özellikler penceresinde “Dependencies” sekmesinde bıraktığımız ayarlarımıza “Policies” üzerinden devam edelim. Daha önce bahsettiğimiz gibi özellikler HA uygulamalar için de, altındaki kaynaklar için de ayrı ayrı belirlenebilmektedir. Biz şuan yeni oluşturduğumuz “new script” kaynağı üzerindeki özelliklerden “policies” sekmesine gidelim.
Burada odaklanacağımız yer kaynağımızla ilgili failover ayarlarımız. Yukarıda görüldüğü gibi başlangıç olarak bu kaynağa bağımlı başka bir kaynağımız yoksa “if resource fails, do not restart (kaynak sorunluysa yeniden başlatma)” seçilebilir. Bu durum aynı HA uygulama üzerinde birden fazla rolünüz varsa kullanılabilir. Mesela hesap makinesi yanına bir de notepad koyduysanız ve bununla çok da işiniz yoksa seçilebilir. Ama mantık önemli sunucuları yüksek erişilebilir yapmak olduğundan yukarıda görünen varsayılan değerler otomatik olarak tanımlanmışlardır.
Buradaki tanıma göre, 15 dakika boyunca (period for restarts), her 0,5sn’de bir (delay between restarts) ,en fazla 1 kere (maximum restarts in the specified period) yeniden başlatma denenir, eğer başlatma başarısız olursa bu kaynağın içinde bulunduğu tüm yapı diğer sunucuya taşınır (if restart is unsuccessful, fail over all resources in this Role) hala başlatılamamışsa 1 saat sonra tekrar denenir (if all restarts attempts fail)
Şimdi buradaki ayarlarla biraz oynayalım. Deneme periyodunu 5 sn. Tekrar deneme sayısını 2 ye çekelim. Bu sırada sunucumuz CP2012CLS2 üzerindedir ve vbs scriptimiz bu sunucuda düzgünken diğer sunucuda ismi new2.vbs olarak değiştirilmiştir. Diğer node üzerine move etmeye çalıştığımızda oradan buraya geri dönmesini bekliyoruz.
Olması gerektiği gibi taşınma işlemimiz başlıyor. Ve CP2012CLS1 üzerinde new.vbs olmadığından beklendiği gibi new script rolümüz failed durumda.
Fakat bir süre bekledikten sonra calculator uygulamamızın diğer tüm kaynaklar çalışıyor olmasına rağmen failed durumda kaldığını görüyoruz.
Hemen uygulama üzerinde sağ tıklayıp critical events (kritik olaylar) sorguladığımızda olması gerektiği gibi 1 sn. Arayla iki defa deneme yapıldığı görülüyor (dikkatliler için not: ilk kayıt failover olma anıdır, kurallarınız bundan sonra işler). Fakat dönmesiyle ilgili bir kayıt yok.
Policies sekmesini tekrar incelediğimizde ”başlatma sorunlarında diğer node’a taşın” seçeneğini işaretlemediğimiz ortaya çıkıyor. Meğer o kadar da dikkatli değilmişsiniz J
Bu seçeneği işaretleyip bir de tekrar deneme için bekleme zamanını 2 dakikaya çekiyoruz.
Bundan sonra isterseniz 2 dakika bekleyip, isterseniz elinizle start service derseniz, aşağıda görebileceğiniz gibi CP2012CLS1 üzerindeki uygulamanızın CP2012CLS2 üzerine otomatik olarak failover olduğunu görebilirsiniz.
Bu işlemi çeşitli kereler denediğinizde az önce oldu ama şimdi neden olmuyor ki sorusunu soracaksınız. Çünkü sunucu bir sonraki seferde Failed durumda olduğu yerde kalacak. Bunu sorgulamak için tekrar critical events içerisine bakmalısınız. Burada “… has exceeded its failover threshold” bilgisini göreceksiniz.
İşte burada daha önce matematiksel denklem gibi anlattığım ayar önem kazanıyor. Calculator üzerinde sağ tıklayıp özelliklerini açtığınızda karşınıza çıkacak “failover” sekmesindeki değerler: geçmiş 6 saat için en fazla bir sorunda failover denemesini kesiyorduk. Ama bu değeri 1 saate düşürüp tekrar deneme sayısını 1’den 20’ye yükseltirsek işlem sorunsuz devam edecektir.
Tekrar ya 2 dakika bekleyin ya da elinizle start service yapın, “failed” sunucunuz diğer node’a taşınacaktır.
Sonraki aşamamız “Advanced Policies” sekmesiyle ilgili. Daha önce “preferred owners” altında açıkladığım değerler seçilmese de sunucu otomatik olarak tüm nodelarda dolaşabilecektir ayarı aslında burada gizli duruyor. Fakat ismi farklı olarak “possible owners (olası sahipler)” şeklindedir. Buradaki ayar da duruma göre değiştirilebilir.
Ek olarak kaynakların sağlık durumlarının kontrolleri de buradan ayarlanabilmektedir. Basic ile thorough farkı detaylı olmasındadır.
Ayarlamalarımız bu kadarla bitmiyor. İlerleyen makalelerde network ile ilgili ayarlamalar, performans arttıcı etmenler, anlattıklarımızın power shell ile yapılması, eski cluster.exe ile ilgili örneklerden bahsedeceğim.
