Merhaba,
Daha önce hem sahada kendimin bizzat karşılaştığı hem de gittiğim kurumlarda denk geldiğim bir sorun/durum ile ilgili yazmak istiyorum. Arka planda çalışan bir uygulamaınızın ya da sizin için kritik bilgileri mail atan ya da önemli bilgiler dönen bir scriptinizin olduğunu var sayalım. Ki bir çok sistem yöneticisinin kritik scriptleri ya da application/tool kullanımları mevcuttur. Bu script’ler ya da application’lar genellikle sunucu üzerinde çalışır, ve genelde sistem yeniden başladığında, manuel müdahale olmadan ayağa kalkmaz ve işler yavaşlar, kullanıcılar şikâyet eder, belki de kayıplar başlar.
İşte tam bu noktada, Windows Server Failover Cluster devreye giriyor. Muhtemelen Failover Cluster hizmetini SQL Server, File Server gibi standart rollerde çalıştırılmasına aşinasınızdır. Hatta Sql Always On yapılanmasını anlattığımız bir yazımız da blogumuzdaki bu linkte mevcut. Peki bu standart roller dışında bir şey çalıştırmak istiyorsanız ne yapacaksınız? Cevap basit. Failover Cluster üzerindeki Generic Application, Generic Script ve Generic Service rolleri.
Bu yazıda, herhangi bir .exe dosyasını ya da bir Windows servis bileşenini nasıl yüksek erişilebilir hale getireceğinizi adım adım anlatıyor olacağım. İki Bölüm halinde olan yazımızda önce servis için daha sonra da uygulama için örnekleme yapıyor olacağız. Keyifle okumanızı temenni ederim.
BÖLÜM 1
- Generic Service, bir Windows servisinin cluster tarafından yönetilmesini sağlar. Cluster, bu servisin çalışıp çalışmadığını izler; servis durursa yeniden başlatır, node arızasında başka bir sunucuda aynı servisi çalıştırır.
Bu tanıma dayanarak, örneğimizde, network üzerinden sunucuların process time değerlerini okuyarak csv dosyasına kaydeden bir servisimi, Generic Service ile HA (High Availability) hale getireceğim. Tabi ki sizin servisiniz, yapınızda daha farklı bir işi yapan, networkteki sunucular üzerindeki farklı bilgileri okuyan, istediğiniz değerleri monitor eden ve ya erp çözümleriniz için sürekli olarak arka planda bilgi girişi sağlayan/okuyan vs vs gibi servisler olabilir. Ben örnek olsun diye basit bir servis scripti ile yoluma devam ediyorum.
Servis içeriğinde yapılacak işin kodu aşağıdaki gibidir. FS-01 ve FS-02 failover sunucularındaki processor time değerlerini okuyarak C diskinde bir lokasyona csv olarak kaydedecek. Tabi ki farklı dosyalar olmaması açısından network üzerindeki bir dosyaya yazarak merkezi bir report çıktısı sağlanabilir fakat ben örnekte de daha iyi gösterebilmek adına bu şekilde kodladım. Kodun en basit hali ile; Servis işini yaparken çıktı üzerine, sunucuda bireysel mi yoksa FC Role üzerinde mi çalıştığını (RunAtServer), hangi zamanda çalıştığını (Time), hangi sunucu için veriyi çektiğini (ServerName) ve istediğimiz counter değerini (ProcessorTime) yazacaktır.
Servisimin Failover Cluster sunucuları üzerinde kurulumunu sağlıyorum ve kurulum sonrası servisim her iki sunucumda da aşağıdaki gibi stop şekilde beklemektedir. Tabi ki servis kodlarının doğru çalışabilmesi için, servisin sunucular üzerinde yetkili bir hesap ile çalıştırılması gerekmektedir. Bu sebeple ben fsadmin kullanıcısını kullandım.
Not : Tier yapılarında dikkat etmeniz gereken bir konu ise, hesap sunucu üzerinde yetkili olsa dahi Deny logon as a service gibi kısıtlamalara takılmıyor olması gerekmektedir.
Daha sonra Failover Cluster konsolumuzu açıyoruz ve servisimizi HA yapı çalışması için gerekli ayarları yapıyoruz. (Failover yapılandırması için yukarıda da bahsettiğim gibi, ilgili linkten failover kurulum adımlarını yapabilirsiniz. Linkteki makalede sadece SQL Server kurulumuna geçmeyeceksiniz.)
Failover konsolunda Roles kısmına sağ click yaparak Configure Role… (1) seçeneğini seçiyoruz. Açılan pencerede Next ‘e tıklayarak Select Role penceresine geliyoruz. Bu aşamada Generic Service (2) seçeneğini seçtikten sonra HA çalışmasını istediğimiz service ‘i seçiyoruz. Bizim örneğimiz için bu servis Test Service for Failover (3).
| 1 | 2 | 3 |
 |
 |
 |
Daha sonra gelen ekranda bu cluster için bir isim ve ip girmemizi istiyor. İlgili değerleri ben m3gService ve 172.10.10.180 (1) şeklinde giriyorum ve Next ‘e tıklıyorum. Eğer servisinizin bir disk ihtiyacı var ise, bunu burada seçebilirsiniz. Servisimin disk ihtiyacı bulunmadığından ben herhangi bir disk seçmeden (2), Next ile devam ediyorum. Yine servisiniz Regedit’ üzerine bir şeyler yazıyor ise, diğer node’ a aktarılması için ilgili regedit değer(ler)ini burada girmenizistenmektedir. Benim servisimde regedit ‘e yazılan herhangi bir şey olmadığından, boş bırakarak Next (3) ile devam ediyorum.
| 1 | 2 | 3 |
 |
 |
 |
Son pencere olan Confirmation penceresinde bana ayarlarımın bir özeti sunularak devam etmem istenmektedir. Next ile devam ediyorum.
Summary ekranında bana işlemin başarıyla gerçekleştiğini gösteren bir pencere ile karşılaşıyorum.
Failover Cluster konsolumuzu da kontrol edersek aşağıdaki gibi bir görüntü ile karşılaşmamız gerkemetkedir.
Not : Summary ekranında successfully configured role seçeneğini görseniz dahi tanımlanan rol’ ün sağlıklı çalışmadığını ve Failed olduğunu görebilirsiniz. Bunun sebebi Summary ekranındaki OU üzerinde ilgili VCO ‘yu (benim örneğimde m3gService) oluşturma yetkisi olmadığındandır. Ya bu OU seviyesinde ilgili kullanıcının Create Computer Object yetkisi olmalı, ya da domain admin yetkisine sahip kullanıcılardan, bahsi geçen VCO ‘yu oluşturmalarına müteakip disable etmeleri ve VCO üzerinde CNO (Cluster Name Object) ‘e (benim örneğimde FS-Cluster) Full-Control yetkisinin tanımlanması talep edilmeli. Her iki durumdan bir tanesi sağlandığında ilgili rol sağlıklı bir şekilde kurulum tamamlanacaktır. Hatta rol failed olduktan sonra dahi VCO oluşuturulursa da, rol sağlıklı bir şekilde Running duruma dönecektir. Bunun ile ilgili Microsoft makalesine buradan erişebilirsiniz.
 |
 |
Şimdi gelelim kontrollerimize…
Öncelikle FS-01 üzerinde scriptte belirttiğim C:\Reports dizinine gidiyor ve çıktı dosyasının içeriğini inceliyorum. FS-02 sunucusunda aynı dizinin boş olduğunu da görüyorum. Keza rol sahibi FS-01 olduğundan servis burada çalışmakta ve bu sunucunun dizinine yazdığından FS-02 sunucusunda dizinin boş olması beklenti dahilinde bir durum.
 |
 |
Sunucunlar üzerinde servis kontrolü yaparsak, servisin FS-01 sunucusunda çalışırken (Role Sahibi olduğundan), FS-02 sunucusunda çalışmadığını görürüz. Hatta en başta Startup Type = Automatic olmasına rağmen, şu anda Manual durumda olmasının sebebi, artık kontrolü failover cluster hizmetinin almış olmasından kaynaklanmaktadır.
 |
 |
Failover Cluster üzerinde Rol ‘ü diğer sunucuya aktarmaya çalışınca bakalım neler olacak?
| FS-01 | FS-02 |
 |
 |
Görüldüğü üzere rol sahipliği FS-02 sunucusuna geçti, servis FS-01 de stop duruma geçerek, FS-02 sunucusunda Running duruma gelmiştir. Ayrıca sahiplik devri FS-01 sunucusunda yaklaşık 15:43:48 zamanına denk geldiğinden, loglar FS-02 sunucusunda 15:44:00 zamanında başlamış görünmektedir. Sadece servisin yapacağı kodları kullanarak servisimizi HA yapıya getirdik.
Not: Servis tüm node’lara aynı adla yüklenmiş ve aynı yapılandırmaya sahip olmalıdır.
Ayrıca servisinizin kapanma, loglama ve hata durumlarına toleranslı olması gerekmektedir. Biz burada en basit haliyle işleyecek bir servis yazdık fakat servisiniz kapanma ve hata durumlarına karşı ne kadar sağlam ve toleranslı ise, Failover hizmetinde de o kadar sağlıklı çalışacaktır.
BÖLÜM 2
- Generic Application, belirli bir uygulamayı (örneğin bir .exe dosyasını) Failover Cluster üzerinde çalışan bir kaynak haline getirmemizi sağlar. Uygulamamızın kendisi cluster-aware olmasa bile, cluster tarafından başlatılıp durdurulabilir, başka bir node’a failover edilebilir. Yani siz sadece uygulamanızı çalıştıracak kodları yazın, yük devretme kod blokları ile uğraşmayın, yük devretme işini Windows Server üzerinde çalışan Failover Cluster hizmeti halleder.
Halleder diyorum ama halledecek mi uygulamalı örneğimiz ile bir bakalım. 🙂
Senaryomuz şu; ortamınızda ERP sistemleriniz ya da farklı işlemleriniz için internet üzerinden her dakika Döviz kurlarını çeken ve ilgili SQL tablosuna işleyen bir uygulama olduğunu düşünün. Bu tablodan alınan değerler doğrultusunda fatura tutarları netleşiyor, sevkiyat ve masraf tutarları değişiyor, sipariş ürünlerin ödeme tutarları belirleniyor vs vs. Yani önemli bir uygulama. Simüle edebilmek adına internetten döviz kurlarını çeken ve bunu SQL sunucuya değil de csv’ye yazdıran bir application yazdım. Fakat bu applicaiton sadece işini yapıyor. Cluster çalışmaymış, yük devretmeymiş, diğer sunucuda çalışıyorsa ben durayımmış gibi durumlardan haberi yok. E kodun içinde araştırma yapayım gidip bir kaç makale okuyayım kodu da olmayınca, sadece işini yapıyor yazık :))
Applicaiton için about ve .exe ismi aşağıdaki gibidir. Application .exe dosyamı her iki Failover Cluster sunucusunda da aynı yere kopyalıyorum (benim örneğimde “C:\Program Files(x86)\m3g\“) ve daha sonra Failover Cluster konsolumuzu açıyorum.
 |
 |
Roles Ksımından Configure Role… seçeneğini seçtikten sonra Before You Begin ekranında Next ile devam ediyorum. Select Role penceresinde Generic Application seçip Next ile devam ediyorum. Generic Application Settings penceresinde uygulamamın .exe yolunu istemektedir. Hangi dizinde hangi .exe ‘yi çalıştıracağını bilmek en doğal hakkı sonuçta. Benim uygulamam herhangi bir parametre almadığından o kısmı boş geçerek bir sonraki adım için Next ile devam ediyorum. Clietn Access Point penceresinde cluuster için bir isim ve ip belirtmem gerekiyor. Gerekli ayarları yazdıktan sonra Next ile devam ediyorum.
 |
 |
 |
Uygulamam herhangi bir diske ihtiyaç duymadığından ve regedit ile herhangi bir etkileşimi olmadığından Next ile ilerliyor ve Confirmation penceresinde ayarlarımı kontrol ettikten sonra devam ediyorum.
Not : Burada ikinci ve DHCP üzerinden ip görmenizin sebebi; uygulama internet üzerinden döviz kuru çekmesi gerektiğinden sunucuya ikinci bir ethernet ekleyerek NAT modunda kullanmamdan kaynaklıdır.
 |
 |
 |
Ve nihai pencere olarak rolümüzün başarıyla kurulduğunu ve Running durumda olduğunu göstermektedir.
Uygulamanın FS-01 sunucusunda çalıştığını görmekteyiz. FS-02 sunucusunda kontrolleri yaptığımızda Test Application ‘a ait herhangi bir process göremiyoruz.
 |
 |
 |
Peki FS-01 sunucusunda uygulamayı stop ediyorum.
Görüldüğü gibi uygulama saniyeler içinde farklı bir process id ile tekrar ayağa kalktı. Peki uygulama işlemi gibi değil de node bazlı bir sorun olursa? Diğer sunucuda ayağa kalkar mı?
 |
 |
Kısa zaman içinde diğer node üzerinde ayağa kalkarak FS-02 sunucusu üzerinde application çalışır vaziyete geldi. Hatta FS-02 üzerinde de Stop-Process komutunu çalıştırdığımda yine uygulamanın saniyeler içinde ayağa kalkmış olduğu görülmektedir. Çünkü bu bölümün başında da söylediğim gibi;
- Uygulamamızın kendisi cluster-aware olmasa bile, cluster tarafından başlatılıp durdurulabilir, başka bir node’a failover edilebilir.
Generic Application ve Generic Service rolleriyle, bu tür uygulamalara minimum maliyetle maksimum güvenlik sağlayabilirsiniz. Yazılımınız büyük olmayabilir ama onun ayakta kalması bazen tüm sistemin yükünü taşır.
Ek not olarak;
- Olay günlüklerini mutlaka takip edin. Biz burada basit bir uygulama ve servis üzerinden örneklendirdik. Fakat uyglamanız düzgün kapanmıyorsa, cluster bunu bir problem olarak algılar ve ona göre işlem yapar.
- Uygulama/servis/sccript tabanlı izlemeler yapıyor iseniz bağımlılıklarını mutlaka kontrol edin. Disk doluluğu vs gibi.
- Örneklerimizde regedit ve disk gibi isterler yoktu fakat sizin gereksinimlerinizde bunlar var ise, erişim ve yazma gibi yetkilerin bulunduğundan emin olun.
Sonuç mu?
SONUÇ : “Cluster sadece SQL için kurulmaz. Bazen sahada en çok değeri, adını bile bilmediğiniz bir servis ya da exe dosyası üretir.”
Sistem yöneticilerim! Size sahip sesleniyorum… Sahip çıkalım .exe ‘ye…
Faydalı olması dileğiyle.
