HA Mimarisi (FDM)

HA Mimarisi (FDM)
Adem YETİM tarafından 4 sene önce eklendi. 2,568 kez okundu.

Bu makalemde HA’in çalışabilmesi için kullandığı bir ajan olan FDM hakkında detaylı bilgi paylaşacağım. vSphere 5.0, FDM denen Fault Domain Manager adlı bir ajanı kullanır. Aşağıdaki anlattığım bölümler vSphere 5.0 ve üst versyionlarına özeldir. Gerekli yerlerde spesifik versiyon numaraları belirtilmiş bulunmaktadır.

vSphere 5.0 yeni bir HA mimarisi ile birlikte gelmektedir. HA, AAM tarafından güçlendirilen bu kısıtlamaların bazılarını aydınlatmak için baştan aşağıya yeniden yazılmıştır. 5.0’ın bir parçası olan ve FDM olarak adlandırılacak olan HA daha az karmaşa ve daha yüksek dayanıklılık sunmaktadır. UI açısından çok fazla değişiklik yoktur ama çalışma şekli olarak değişiklikler mevcuttur, primary/secondary nod konsepti yerine otomatik eleme süreçli master/slave  kavramı mevcuttur. Her neyse, şimdilik bunlar fazla detay, daha sonra bu konuya döneceğiz. Öncelikle temel bileşenlerle başlayalım. Bahsedildiği üzere ajanın tamamı yeniden yazıldı ve VPXA’ya bağımlılık yok edildi. vSphere 4.1 ve öncesinde VPXA ile iletişime geçmek için çevirici kullanmak yerine HA direkt olarak hostlarla iletişim kurmaktadır.

 

vSphere 5.0’daki bağlantıların yönetim şekli aşağıda gösterilen diyagram’daki gibidir.

FDM

Buradaki önemli husus ise şudur ki FDM ayrıca vCenter ile ve vCenter FDM ile iletişim kurar. vSphere 5.0’da HA sanal makinelerin durumu hakkında bilgi toplamak için vCenter’a yardım eder ve vCenter sanal makinelerin korunma durumunu kullanmak için kullanılır. Hepsinin tepesinde ise vCenter sanal makinelerin korunma ve korunmasızlıklarından sorumludur. Bu sadece kullanıcı kaynaklı sanal makine açılış veya kapanışlarına değil, aynı zamanda vCenter’in master HA’nın etkilenen sanal makineleri korumamasını istediği noktada ESXi hostunun vCenter’dan ayrıldığı durumda da uygulanabilir. Korumanın tam olarak ne anlama geldiğini makalenin ilerleyen kısımlarında anlatacağım. Değinmek istediğim bir husus var, eğer vCenter mevcut olmazsa clusterda herhangi bir değişiklik yapmak mümkün olmayacaktır. vCenter korunan sanal makinelerin, cluster konfigürasyonunun, sanal makine-host uyumunun ve host üyeliğinin ayarlarının doğruluk kaynağıdır. Yani tasarım olarak HA vCenter olmadan hatalara tepki verecekse clusterı konfigüre etmek veya görüntülemek için vCenter’a güvenir.

HA yönetimi/hata raporlaması ile ilgili 2 minör ama çok önemli değişiklikten bahsetmek istiyorum:

  • DNS’e bağımsızlık
  • Syslog işlevselliği

5.0 HA DNS’e bağlı olmadığı için sadece IP adresleri ile çalışmaktadır. Bu FDM’in getirdiği önemli gelişimlerden birisidir. Bu aynı zamanda HA’nın host adında vurguladığı karakter sayısının limitinin kaldırılması anlamına gelmektedir (vSphere 5.0 öncesinde host adları 26 karakter ile sınırlı idi.). Bir diğer önemli değişiklik ise HA log dosyalarının ESXi’nin sunduğu normal log işlevinin bir parçası oldukları gerçeğidir ki bu da /var/log’un içinde log dosyası bulabileceğiniz anlamına gelmektedir.

FDMlog

 

Şuna dikkat ediniz; eğer vSphere 5.0 vCenter Server’ı ESX/ESXi 4.1 veya daha önceki hostlara eklerseniz yeni vSphere HA Ajanı (FDM) vCenter ajanı ile birlikte yüklenecektir.

 

Master ve Slave Mekanizması

Yukarıda da bahsedildiği gibi vSphere High Availability tamamen yenilenmiştir… Bunun anlamı eski bazı kısıtlamaların kaldırılması, uygulama ve tasarım ile ilgili bir takım değişiklikler yapılabilmesidir..

Bu bölümde değineceğimiz konular vSphere 5.0’öncesinde HA’nın bir parçası olan primary/secondary nod kavramı etrafındaki değişimlerdir. Bu konsept sizi belirli açılardan kısıtlamaktaydı… VMware /vSphere’daki yenilikler, geçmişte  nodlar için 5 adetlik limit vardı. Sanal makinenin yeniden başlatılması veya bir gereklilik olduğu durumlarda  en azından  her zaman 1 primary nodunuz olmasını istersiniz. Tahmin edebileceğiniz üzere, bu durum Blade ortamlarında veya Geo-Dispersed clusterlarda tasarımınıza kısıtlama getirmekteydi.

vSphere 5.0 bu kısıtlamaları tamamen kaldırmıştır. Blade ortamınız var ve cluster’da 32 host mu barındırmak istiyorsunuz? Artık yapabilirsiniz, çünkü primary/secondary nod kavramı artık ortadan kalktı. HA artık  (Master/Slave) adı verilen bir mekanizma kullanmakta. Açıkçası bu sistem düzgün. Nodlarınızdan birisi Master oluyor ve diğerleri de Slave haline geliyorlar. Sanıyorum ki bazılarınız “Eğer primary noda bir şey olursa ne olacak?” diye soruyorsunuzdur. Bu çok basit; master nod hata verdiğinde bir seçim süreci başlatılır ve slave nodlardan birisi master olarak kalınan yerden devamı sağlar. Bunun üstüne bir de Geo-Dispersed cluster örneğini ele alalım; bağlantı hatası nedeni ile cluster ikiye ayrıldığında her “bölüm” kendi master nodunu seçer. Bu da network hataya düştüğünde konumsal olarak ayrışmış clusterlar da bile iş yüklerinin yeniden başlatımına olanak tanır…

Peki master nelerden sorumludur? En basit haliyle primary nodların üstlendiği görevler şunlardır;

  • Hataya düşen sanal makineleri yeniden başlatmak
  • vCenter ile durumu değiştirmek
  • Slave durumlarını gözlemlemek

Master nod hata verdiğinde bir seçim süreci başlatılır. HA master seçimi 15 saniye sürer. Seçim süreci basit ama sağlamdır. Seçime giren ve data merkezleri ile en yüksek bağlantı sayısına sahip host master olarak seçilir. Eğer aynı veri deposu sayısına sahip 2 veya daha fazla host varsa en yüksek Yönetilen Nesne ID’sine sahip olan seçilir. 9 1’den büyük olduğu için 99 10’ü yener. 4.1 ve daha öncekilerdeki haliyle karşılaştırıldığında bu büyük bir gelişmedir.

Hangi hostun seçimi kazandığı ve master olduğunu merak edenler clusterın özet tablosuna girsin ve “Cluster Durumu”nu tıklasın.

 

HA Cluster Status

 

Masterın bir hostun down mı değil mi olduğunu nasıl bildiği halen merak edilmekte. Aslında cevap basit bunu anlamak için HA, heartbeat’i dinliyor!

 

Heartbeat’ler

vSphere 5.0 iki farklı heartbeat mekanizması kullanır. İlki network heartbeat mekanizmasıdır. Her slave master’a heartbeat’i iletir, ve master da slavelerin her birine. Bu atışlar her saniye otomatik olarak yollanır. Bir slave  atış alamadığı zaman kendisinin mi clusterdan ayrıldığını veya master’ın izole olup olmadığı veya arızaya düşüp düşmediğini belirlemeye çalışır. Bu durumları ileride detaylı olarak değineceğiz.

Network heartbeat’i her iki konseptte de benzer, ancak yeni olan ve vSphere 5.0 ile tanıtılan ise Veri Deposu heartbeatidir.

Datastore Heartbeat

 

vSphere 5.0 öncesi HA’yı bilenler muhtemelen bilirler ki sanal makine yeniden başlatmaları her zaman tetiklenir, sadece management network izole edilse ve sanal makine halen çalışıyor olsa bile. Tahmin edebileceğiniz gibi bu hosta gereksiz bir baskı yüklemektedir. Veri deposu heartbeat mekanizmasının tanıtılması ile beraber bu ortadan kalkmıştır. Veri deposu heartbeat sistemi dayanıklılığa yeni bir seviye katmakta ve arızalı host ile izole/ayrılmış host arasında ayrım yapma olanağı sağlamaktadır.

Veri deposu heartbeat sistemi master’ın, management network aracılığı ile erişilemeyen hostun durumunu daha doğru belirleyebilmesine olanak sağlar. Yeni veri deposu heartbeat mekanizması sadece master’ın hostların arızalı mı yoksa izole mi olduklarını anlamak için hostlarla kurduğu iletişimi kaybettiği durumlarda kullanılır. Yukarıdaki ekran görüntüsünde de görüldüğü üzere iki veri deposu vCenter tarafından otomatik olarak seçilmektedir. Gerekli olursa ve olduğunda veya kendiniz seçmek istediğinizde spesifik rakamlar verebilirsiniz. Ancak ben vCenter’ın karar vermesini tavsiye ederim.

Bahsedilmiş olduğu üzere fabrika ayarı olarak 2 veri deposu seçecektir. Bununla birlikte veri deposu heartbeat için daha fazla veri deposuna izin vermek adına ileri seviye ayarlamalar yapmak da mümkündür (das.heartbeatDsPerHost). Çoklu depolama cihazlarınız olduğunda ve her birinden bir veri deposu almak istediğinizde bunu yapmak isteyeceğinizi tahmin edebiliyorum ama genel olarak konuşursak bu ayarı fabrika ayarı olarak bırakmanın pek  çok senaryo için yeterli olduğunu düşünüyorum.

Peki bu heartbeat mekanizması nasıl çalışıyor? HA mevcut VMFS dosya sistemi kilitleme mekanizmasını destekler. Kilitleme mekanizması da dosya üzerinde kilit oldukça güncellenen ve “heartbeat bölgesi” denen bölgeyi kullanır. Bir veri deposunun heartbeat bölgesini güncellemek için host toplamda en azından bir açık dosyaya ihtiyaç duymaktadır. HA da özel olarak veri deposu heartbeat için bir dosya yaratarak açık bir dosyanın var oluşunu garantiler. Diğer bir deyişle, tasarlanan heartbeat’i veri depolarında her host için bir dosya yaratılır, tıpkı aşağıdaki ekran görüntüsündeki gibi. HA basit bir şekilde heartbeat bölgesinin güncellenip güncellenmediğini kontrol edecektir.

 

FDM Status

Eğer heartbeat için hangi veri deposunun seçildiği hususunda meraklı iseniz clusterınızdaki özet sekmesine gidin ve “Cluster Durumu”nu tıklayın. 3. Sekme olan “Heartbeat Veri Depoları” bu sorunuza cevap verecektir.

Datastore Heartbeat

İzole olan ve Bölüntülenen

Davranışta bir değişikliğe neden olduğu için izolasyon ve bölüntüleme arasındaki farka değinmek istiyorum. Her şeyden evvel master’a network bağlantısını kaybettiğinde ama arızada olmadığında bir host ya izole ya da bölüntülenmiş olarak değerlendirilir. Durumlar arasındaki farkı ve kriterleri aşağıda açıklamadan evvel izolasyon amacının ne olduğu ile ilgili kısa bir bilgi vereyim:

“ESX hostları heartbeat’i alınmadığında izolasyonu kontrol için IP adreslerini kullanırken, [x] = 1‐10’dir (örnek olarak aşağıdaki ekran görüntüsüne bakınız). HA ise izolasyon adresi olarak ön ayarlı geçit olarak VMware kullanır ve ilave kontrol noktası olarak değer sunar. İkincil hizmet konsolu yedekli çalışmak amacı ile kullanılıyor olduğunda bir izolasyon adresinin eklenmesini öneririm.”

Bahsedildiği üzere 2 değişik durum mevcuttur:

 İzole

  • Master’dan heartbeat’i almamaktadır
  • Herhangi bir seçim trafiği almaz
  • İzolasyon adresine ping atamaz

Bölüntülenmiş

  • Master’dan heartbeat’i almamaktadır
  • Seçim trafiği almaktadır
  • (bazı noktalarda durumun vCenter’a raporlandığı yerde yeni master seçilecektir)

Bir izolasyon durumunda master’ın seçilen izolasyon tepkisi ve uygunluğuna bağlı olarak host master’dan ayrılmıştır ve onun üzerinden çalışan sanal makineler yeniden başlatılabilecektir. Aynı anda birden çok hostun izole olması da gerçekleşebilir. Birden çok sayıda host izole olduğunda ama management network üzerinden birbirleri ile iletişim kurabildiğinde buna network bölüntülemesi adı verilir. Network bölüntülemesi olduğunda bir master seçim süreci ortaya çıkar, yani bu bölüm dahilindeki bir host arızası veya network izolasyonu gömülü sanal makine(ler)in uygun aksiyonu ile sonuçlanacaktır.

vSphere 5.1 ile “das.failuredetectiontime”(das arıza tespit zamanı) adı verilen gelişmiş bir seçenek tanıtıldı. Tam olarak aynı değil, ama değişik bir adla benzer bir konsept. “das.config.fdm.isolationPolicyDelaySec” adlı bu yeni gelişmiş ayar izolasyon tepkisi tetiklenmeden önce geçecek süreyi belirlemenize olanak tanımaktadır! Ön ayar olarak vSphere 5.x ile izolasyon tepkisi ~30 saniye sonra tetiklenmektedir. Eğer bunu uzatma gerekliliğiniz varsa bu gelişmiş ayar kullanılabilir. Genel olarak konuşursak bir sorun olduğunda sadece arıza süresini uzatacağından bunun kullanılmasını önermemekteyim.

 

VM’leri yeniden başlatmak

Dışarıdan bakıldığında 5.0’da HA’nın ne şekilde davrandığı aynen görülebilmektedir. VM yeniden başlatımlarının ne şekilde ele alındığı ile ilgili bazı değişikliklerden bahsedeceğim. Dikkat çekmek istediğim şeyler:

  • Yeniden başlatma öncelik değişiklikleri
  • Yeniden başlatma yeniden deneme değişiklikleri
  • İzolasyon tepki ve tespit değişiklikleri

 

Yeniden başlatma öncelik değişiklikleri

Bahsetmek istediğim ilk şey VM’lerin yeniden başlatmak için önceliklendirilme şekillerindeki değişikliktir. Aşağıda sanal makinelerin yeniden başlatılma sıralarının tamamını listeledim:

  • Ajan sanal makineler
  • FT ikincil sanal makineler
  • Yüksek yeniden başlatım öncelikli olarak konfigüre sanal makineler (VM),
  • Orta yeniden başlatım öncelikli olarak konfigüre sanal makineler (VM)
  • Düşük yeniden başlatım öncelikli olarak konfigüre sanal makineler (VM)

Peki nedir bu Ajan VM’ler? Bunlar virüs tarama veya vShield gibi servislerin sunabileceği hizmetleri sunan sanal makinelerdir. FT ikincil sanal makineler sanırım mantıklı gelmektedir, tıpkı listenin kalanı gibi. Aklınızda tutunuz; eğer bunlardan birisi yeniden başlatımda hata verse bile HA kalan sanal makineleri yeniden başlatmaya devam edecektir.

 

Yeniden başlatma deneme değişiklikleri

Geçmişte 4.1’de yeniden başlatma yeniden denemelerinin nasıl çalıştığını ve temel olarak yeniden başlatma deneme sayısının ön ayar olarak 6 olduğunu, 1 tetiklenmiş yeniden başlatım ve “das.maxvmrestartcount” tarafından belirlenen 5 yeniden deneme olduğunu açıklamıştım. 5.0 ile bu durum değişti ve toplam yeniden başlatma sayısı maksimum 5 olarak belirlendi. Her ne kadar bu küçük bir değişiklik olarak görülse de bunu anlamak önemlidir. Zaman çizelgesi de bir miktar değişti ve 5.0’da aşağıdaki hale geldi:

  • T0 – Başlangıç Yeniden Başlatma
  • T2m – Yeniden başlatma denemesi 1
  • T6m – Yeniden başlatma denemesi 2
  • T14m – Yeniden başlatma denemesi 3
  • T30m – Yeniden başlatma denemesi 4

Burada “m” dakikayı ifade etmektedir ve master’ın yeniden başlatılmanın hata verdiğini tespit ettikten kaç dakika sonra yeniden deneme olacağı belirtilmektedir. Yani T0 ve T2m durumlarında yeniden denemeler 2 dakika ve 10 saniye sonra olacaktır.

 

Tüm hostlar kapalı ise?

Peki cluster’daki tüm hostlar eş zamanlı olarak kapanırsa ne olur? Haydi, bu senaryoyu açıklayalım ve HA’nın nasıl tepki vereceğini de ekleyelim:

  • Güç Kesintisi, tüm hostlar kapalı
  • Hostlar için enerji geri gelir
  • İlk host açılır açılmaz bir seçim süreci tetiklenir ve bir master seçilir
  • Master, HA tarafından korunan tüm VM’leri içeren listeyi okur
  • Master, korunan olarak listelenen ama çalışmayan bu VM’lerin yeniden açılışlarını başlatır

Bu noktada dikkat çekmek istediğim bir şey de vSphere 5.0 ile artık eğer bir VM admin tarafından temiz şekilde kapatıldı ise veya hata/izolasyon nedeni ile kapatıldıysa bunu izleyebiliyoruz. Eğer temiz şekilde kapatıldılarsa yeniden başlatılmayacaklardır, ama bu senaryoda elbette ki temiz şekilde kapatılmadılar ve VM’ler yeniden başlatılacak. vSphere ile ilgili harika bir gelişme de artık hangi host veya neredeki primary nod diye düşünmenize gerek yok, yani siz bunlardan istediğiniz bir hostu açabilirsiniz. HA kalanı sizin için sıraya dizecektir!

 

İzolasyon tepkisi ve tespiti değişiklikleri

Bir diğer önemli değişiklik de İzolasyon Tepki ve İzolasyon Tespit mekanizmasındadır. Yine dışarıdan bakıldığında pek bir şey değişmemiş görünse de değişmiştir ve ben size basit tutarak neyin neden değiştiğini anlatmaya çalışacağım. İlki “das.failuredetectiontime” itirazıdır. Pek çoğunuzun bu gelişmiş ayarı hostun izolasyon tepkisini tetikleme zamanını ayarlamak için kullandığınızı biliyorum; dürüst olmak gerekirse bu artık mümkün değil ve gerekli de değil. Eğer benim diğer makalelerimi yakından incelediyseniz umarım artık buna gerek olmamasının sebeplerinden biri olan veri deposu heartbeatini görmüşsünüzdür. Bir diğer sebep ise izolasyon tepkisi tetiklenmeden önce hostun sanal makinelerin yeniden başlatılabilecek olup olmadıklarını ve bunun tüm networkün çökmesi olup olmadığını teyit edecek olmasıdır.

Önceki vSphere versiyonlarına göre izolasyon tespit mekanizması da değişmiştir. Aşağıdaki zaman çizelgesi bir vSphere 5.0 hostu için zaman çizelgesidir:

  • T0 – Host izolasyonu (slave)
  • T10s – Slave “seçim durumu”na girer
  • T25s – Slave kendini master olarak seçer
  • T25s – Slave “izolasyon adreslerine” ping atar
  • T30s – Slave kendini izole ilan eder ve izolasyon tepkisini “tetikler”

Bir vSphere 5.1 hostu için bu zaman çizelgesi, hostun kendini izole ilan etmesinden sonra konfigüre izolasyon tepkisini vermesi için en az 30 saniye gecikmenin girmesi nedeni ile biraz değişmektedir. Bu gecikme das.config.fdm.isolationPolicyDelaySec gelişmiş ayarını kullanarak arttırabilirsiniz.

  • T0 – Host izolasyonu (slave)
  • T10s – Slave “seçim durumuna” girer
  • T25s – Slave kendini master olarak seçer
  • T25s – Slave “izolasyon adreslerine” ping atar
  • T30s – Slave kendini izole ilan eder
  • T60s – Slave izolasyon tepkisini “tetikler”

Aşağıdaki diagramda gözüktüğü gibi:

HA

 vSphere 5.1 ve 5.0’da izolasyon tespit karşılaştırması

Bu aşamanın tamamlanmasının ardından (yeni) master hostun izole edildiğini öğrenir ve slave’den gelen bilgiler ışığında sanal makineleri yeniden başlatır.

Eğer vSphere 5.1’de bir master izole edilirse zaman çizelgesi aşağıdaki gibi olacaktır:

  • T0 – Hostun izolasyonu (master)
  • T0 – Master “izolasyon adreslerine” ping atar
  • T5s – Master kendini izole olarak ilan eder
  • T35s – Master izolasyon tepkisini “tetikler”

Anlaşıldığı gibi ortada açık bir fark vardır ki bir slave izole olduğunda veya bölümlendirmeyle ayrıldığında gerekli olan seçim süreci master izole olduğunda tetiklenmemektedir. Bir husus daha; izolasyon tepkisi tetiklenmeden önce host, sanal makineleri yeniden başlatabilir olup olmadığını teyit edecektir.

 

Sorularınız için VMware Türkiye Kullanıcı Grubu sayfasından bana ulaşabilirsiniz.

 

NOT: Bu metin Duncan Epping’in “HA Deepdive” isimli orijinal makalesinden Türkçe’ye tercüme edilmiştir. Makalenin aslına ulaşmak isteyen okurlarımız aşağıdaki linki takip edebilirler.

 

  • Burhan Abdiler: Elinize sağlık Fatih Bey , detaylı incelemeniz konuyu tamamen açıklayıcı nitelikte ....
  • Tufan ULU: Adem kardeşim, tebrik ediyorum ve başarılarının devamını diliyorum,...
  • Rafet Arslanyı lmaz: Adem Hocam, Tebrikler.. Umarım devamıda gelir :)...
  • Serkan ERSAN: Çok başarılı ve güzel bir anlatım olmuş. Emeğinize sağlık, teşekkürler....
  • Adrenalin .: Teşekkürler Adem Bey....

Bu içerik için henüz hiç kimse görüş bildirmemiş. İlk olarak siz yorum yazamaya ne dersiniz ?

Yorum ekleyin

Doğrulama Kodunuz : 66119786

ÖNEMLİ:
Yorumlarınızı eklerken lütfen girmiş olduğunuz bilgilerin size ait olduğundan emin olunuz. Geçersiz posta adresleri iel yapılan yorumlara yanıt vermek istenildiğinde size ulaşamayacağımız için, geçerli / aktif olarak kullandığınız posta adresiniz ile yorum eklemeniz daha sağlıklı olacaktır. Her yorum yazarı tarafından sorumlu tutulur.

Sayfa başı

Güncellemeler, yeni eklenen içeriklerden anında haberdar olmak için mail listemize adınızı soyadınızı ve posta adresinizi yazarak abone olabilirsiniz.

Adınız Soyadınız
E posta adresiniz
Kaydol