Kahveler hazır mı? Hazırsa haydi kaldığımız yerden devam edelim.
Bugünkü yazımda sistemde oluşabilecek hata ve arızalara karşı vSAN’ın savunma gardını konuşacağız.
vSAN Storage Policy
vSAN object based bir storage olduğu için objelerin koruması yapılır ve objelerin korumasının yapılabilmesi için de bizim o objelerin yapılacağı politikaları hazırlamamız gerekir. ( Ne çok obje dedim :D)
vSAN’da storage policy base management imkanı vardır. İsterseniz varsayılan politikaları kullanır, isterseniz de ihtiyacınıza göre politika oluşturabilirsiniz. vSAN’ın defaultta bir policysi bulunur.
Object Repair Timer
Objeler komponentlerden oluşur. Komponentler gün gelir arızalanabilir. Sistemde hatayı görebilmek adına vSAN’ın da bir işlemde bulunması gerekebilir. Amaç hata anında, bir disk arızasında sistem recovery senaryosunu devreye alsın olmalıdır. Peki komponentler hangi durumlarda olabilir?
Absent: Hata/arızadan dolayı oluşur. Geri dönüşünün olduğuna inandığı belirsizlikleri temsil eder diyebiliriz.
Active-State: Aynı vSAN objesini oluşturan komponentler birbirleri arasında sync yapamadığında karşımıza çıkar.
Degrated: Sistemde büyük bir arıza gibi algılanabilir. Aslında bir arızadan kaynaklı alınan uyarıdır. Mesela ESXI sunuculardan birini reboot edersem componentler degrated duruma düşer. Beklemediği anda gelen sürprizlere tepkisidir.
vSAN bir hata tespit ettiğinde onu onarmak için belli bir süre bekler. Bu süreye “object repair timer” denir. Bu süre defaultta 60 dkka olarak ayarlanmıştır. Dilerseniz bu süreyi değiştirebilirsiniz.
Host Isolation Response
Eğerki bir sunucu clusterın diğer üyelerinden cevap alamıyor ve dolayısıyla da default gatewayine gidecek duruma geliyorsa, ve gatewayden de cevap alamıyorsa “Host Isolation Response”‘u uygulayacaktır. vSAN’daki yapıda gateway vSAN networkü olacaktır.
Burada 3 seçenekten birini cevap olarak ayarlamanız mümkündür. Disabled seçerseniz default gatewayine ping atamadın beklemeye devam et demiş olursunuz. Host fail durumda ama üzerindeki vmler çalışmaya devam eder. Power off and restart VMs’i seçerseniz fişini çeker gibi düşünelim, diğeri de makine içinden kapatma talimatı vermektir. İhtiyacınıza göre tercih edebilirsiniz.
Fault Domain
Amacı veriyi domainler arasında bölmek, yani sistemizdeki sunucuları gruplamaktır. Bir örnek ile açıklayacak olursak aşağıdaki şekilde bir vSAN Cluster yapımız olsun. 4 sunucumuz var ve bunlar 2 farklı kabinde olsun. Kabinler arası da bağlantı olduğunu düşünelim. Bir sanal makinemi 2 farklı kabinette oluşturulmus vSAN’a atarsam 3 ihtimalle çalışabilir. Kabin 1’de çalışabilir, kabin 2 ‘de çalışabilir ya da verileri kabin ve kabin 2’ye dağılabilir. Ama biz isteriz ki mirror yapımız olsun, kabin 1’e bir şey olma ihtimalinde verim diğer kabinde de olsun. Peki bunu yapabilr miyiz? Normal şartlarda yapamayız. Amaaa vSAN’ın fault domain özelliği ile bunu yapmak mümkün. Eğer sanal makinemin 1 komponentinin 1-2 hostunda, diğer komponentimin de 3-4 hostlarında durmasını istiyorsak fault domaini kullanabiliriz.
vSAN cluster‘ında bulunan her host dolaylı olarak fault domain kabul edilir. vSAN, tüm vSAN nesnelerinin bileşenlerini, Number of Failures to Tolerate kuralına göre otomatik olarak cluster’daki Fault Domain’lere dağıtır.
NumberOfFailuresToTolerate = 1 olan bir sanal makineyi deploy ederken 2n+1 kuralına uymalıyız. Yani burada 1 arızayı tolere etmek için 3 ESXi hostumuzun olması gerekecektir. Eğer 3 arızayı tolere etmek istiyorsak 2*3+1=7 ESXi hostuna sahip olmalıyız.
Son olarak fault domain konfigürasyonu yapılmamışsa ve fault domain veya host kaybı yaşanırsa, çabucak yeniden oluşturulamayacaktır. Bu durum için, VMware ek bir host veya Fault Domain bulundurulmasını tavsiye ettiğini belirtmek isterim.
Bugünlük de müessesemizden bu kadar. Yarın mesai var, ben kaçar. Herkese kolaylıklar 🐸
Kubikolog 