vCenter'da cluster, HA ve DRS

Host'ları vCenter'a tek tek eklemek de mümkün. O zaman vCenter sadece merkezi bir arayüz oluyor. Asıl kazanç host'ları bir cluster'da topladığında geliyor: bir host çökünce üzerindeki VM'ler diğerlerinde kendiliğinden açılıyor (HA), host'lar arasındaki yük kendiliğinden dengeleniyor (DRS), bakım için bir host'u boşaltmak tek tık oluyor.

Bu yazıda üç host'luk bir cluster kurup HA ve DRS'i, varsayılan değerlerin nerede yetmediğini anlatarak açıyorum.

Datacenter ve cluster

vCenter'da her şey bir datacenter nesnesinin altında duruyor. Fiziksel bir veri merkezi olması gerekmiyor, sadece bir klasör gibi. Ağlar ve datastore'lar datacenter düzeyinde tanımlandığı için iki farklı datacenter nesnesi arasında VM taşımak daha zahmetli. Tek bir lokasyon için tek datacenter yeterli.

vSphere Client'ta vCenter'a sağ tıklayıp "New Datacenter", adı Merkez. Sonra datacenter'a sağ tıklayıp "New Cluster", adı Uretim. Sihirbaz bu noktada HA, DRS ve vSAN'ı açmak isteyip istemediğini soruyor. Ben ilk aşamada hepsini kapalı bırakıyorum, host'ları ekledikten sonra tek tek açıyorum. Bir şey ters giderse sebebini ayırmak kolay oluyor.

Sihirbazda bir de cluster'ın vSphere Lifecycle Manager ile tek bir image üzerinden yönetilip yönetilmeyeceği soruluyor. Ben bunu açık bırakıyorum. Image ile yönetimde cluster'daki bütün host'ların ESXi sürümü, sürücüleri ve firmware eklentileri tek bir tanımdan geliyor. Eski "baseline" yöntemi vCenter 8'de hâlâ çalışıyor ama kullanımdan kaldırılacak olarak işaretli, vCenter 9'da ise hiç yok. Yarın 9'a geçmek istediğimde cluster'ı image yönetimine çevirmekle uğraşmamak için yeni cluster'ı baştan image ile kuruyorum.

Host eklemek

Cluster'a sağ tıklayıp "Add Hosts". Host'ları FQDN ile, root hesabıyla ekliyorum. Sihirbaz host'un sertifikasının parmak izini gösteriyor, ilk eklemede onaylıyorsun.

Host eklenince vCenter, host'ta vpxuser adında bir hesap oluşturup bundan sonra host'la bu hesap üzerinden konuşuyor. Root parolasını değiştirmek vCenter bağlantısını koparmıyor.

Host'lar eklendikten sonra root ile doğrudan host'a girilmesini kısıtlamak için lockdown mode var. Normal modda host'a sadece vCenter üzerinden erişiliyor, Host Client ile doğrudan giriş kapanıyor (DCUI hâlâ açık). Bunu açmadan önce vCenter erişilemez olduğunda host'a nasıl gireceğini planla: "Exception Users" listesine acil durum için bir hesap eklemek ya da DCUI'ye fiziksel ya da iLO/iDRAC erişimi.

EVC: farklı nesil CPU'lar

vMotion ile çalışan bir VM'i bir host'tan diğerine taşımak için iki host'un CPU'larının VM'e aynı özellikleri sunması gerekiyor. Aynı modeli aldığın üç host için sorun yok. Ama iki yıl sonra cluster'a yeni nesil bir host eklediğinde yeni CPU'nun ek özellikleri yüzünden VM'ler eski host'lara taşınamıyor.

EVC (Enhanced vMotion Compatibility), cluster'daki bütün host'ların VM'lere aynı CPU nesli gibi görünmesini sağlıyor. Cluster'da Configure, Configuration, VMware EVC altından mevcut host'ların en eskisine göre bir mod seçiliyor.

EVC'yi cluster boşken ya da VM'ler kapalıyken açmak en kolayı. Çalışan VM'ler varken daha yüksek bir mod seçmek sorun değil, ama mevcut VM'lerin kullandığı özellikleri kısan bir mod seçemiyorsun. Yeni bir cluster kuruyorsan VM taşımadan önce EVC'yi aç. Bugün gerek görmesen de ileride farklı nesil bir host eklemek için kapıyı açık bırakıyor.

HA: bir host gidince

HA'yı açmak için cluster ayarlarında, Configure, vSphere Availability, "Edit" ile vSphere HA'yı işaretlemek yeterli. Açıldığında host'lardan biri "primary" seçiliyor ve diğerlerini izliyor. Bir host'tan haber alınamazsa primary o host'taki VM'leri diğer host'larda yeniden başlatıyor.

Bunu anlamak önemli: HA bir VM'i kesintisiz başka host'a taşımıyor, yeniden başlatıyor. VM bir iki dakikalık bir kesinti yaşıyor, işletim sistemi açısından elektrik kesilip geri gelmiş gibi. Sıfır kesinti gerekiyorsa o "Fault Tolerance" ve kısıtları çok daha fazla.

Önemli bir ayrıntı da HA'nın vCenter'a bağlı olmadan çalışması. Açılışta vCenter host'lara HA ajanını kuruyor, sonrasında host'lar birbirini kendi başına izliyor. vCenter VM'inin kendisi çöken host'taysa bile HA onu başka bir host'ta açabiliyor.

Varsayılan ayarlardan üçüne mutlaka bakıyorum:

Admission control. HA, bir host çöktüğünde VM'leri açabilecek yeri cluster'da hazır tutmaya çalışıyor. Admission control buna uymayan VM'lerin açılmasını engelliyor. Üç host'luk bir cluster'da bir host'un çökmesine dayanmak için kaynakların yaklaşık üçte birinin boş durması gerekiyor. Varsayılan yöntem olan "Cluster resource percentage" bu yüzdeyi host sayısına göre kendisi hesaplıyor. Bunu kapatmak cluster'ı kâğıt üzerinde daha verimli gösteriyor, ama bir host çöktüğünde VM'lerin bir kısmı açılamıyor. Ben açık bırakıyorum.

Datastore heartbeat. Primary bir host'tan ağ üzerinden haber alamadığında host'un gerçekten çöktüğünü mü yoksa sadece ağının mı koptuğunu anlamak için ortak datastore'lara bakıyor. Bunun için en az iki ortak datastore gerekiyor. Tek datastore varsa cluster'da "The number of vSphere HA heartbeat datastores for this host is 1, which is less than required: 2" uyarısı çıkıyor. İkinci bir datastore yoksa bu uyarıyı gizlemek yerine bir tane eklemeyi düşün.

Host isolation response. Bir host ağdan koptuğunu fark ettiğinde (yönetim ağındaki gateway'e ping atamıyorsa) üzerindeki VM'lere ne yapacağı. Varsayılan "Disabled", yani VM'ler izole host'ta çalışmaya devam ediyor. Host'un sadece yönetim bağlantısı koptuysa bu sorun değil, VM'ler kendi ağlarından hizmet vermeye devam ediyor. Ama host'un bütün ağı gittiyse (switch arızası, kopan kablolar) VM'ler çalışıyor görünüyor, kimse onlara ulaşamıyor ve HA onları başka yerde açmıyor, çünkü diskleri hâlâ izole host'ta kilitli. Yönetim ve VM trafiği aynı fiziksel bağlantılardan geçiyorsa bence "Power off and restart VMs" daha mantıklı: izole kalan host VM'leri kapatıyor, kilitler açılıyor, HA VM'leri sağlam host'larda başlatıyor.

Yönetim ağının gateway'i ping'e cevap vermiyorsa (bazı güvenlik duvarları vermiyor) host her zaman izole olduğunu sanır. O zaman gelişmiş ayarlarda das.isolationaddress0 ile ping atılacak başka bir adres ver. Aynı VLAN'da her zaman ayakta olan bir adres, örneğin bir DC, bunun için iyi bir aday.

DRS: yükü dağıtmak

DRS, VM'leri açılırken en uygun host'a yerleştiriyor ve çalışırken host'lar arasında dengesizlik oluşursa vMotion ile taşıyor. Açmak için cluster ayarlarında, Configure, vSphere DRS. Otomasyon seviyesi üç tane:

Seviye	Yerleştirme	Dengeleme
Manual	Öneri sunar	Öneri sunar
Partially Automated	Kendisi yapar	Öneri sunar
Fully Automated	Kendisi yapar	Kendisi yapar

Ben "Fully Automated" ve varsayılan migration threshold'u (3) öneriyorum. Daha agresif eşikler VM'leri gereğinden sık taşıyor, her vMotion küçük de olsa bir performans etkisi demek. DRS'e güvenmekte tereddüt ediyorsan bir hafta "Manual"da çalıştırıp önerilerine bak, mantıklı geliyorsa otomatiğe al.

DRS'in günlük işte en çok hissedilen tarafı bakım modu. Bir host'a sağ tıklayıp "Enter Maintenance Mode" dediğinde DRS üzerindeki bütün VM'leri diğer host'lara taşıyor. Host boşalınca güncelleme yapıp yeniden başlatıyorsun, çıkınca DRS VM'leri yeniden dağıtıyor.

Lisans konusunu da kontrol et. DRS, Broadcom'un vSphere Foundation ve VCF paketlerinde var (eskiden Enterprise Plus'taydı), daha alt paketlerde olmayabiliyor. Lisansın DRS içermiyorsa bakım modunda VM'leri elle taşıman gerekiyor.

Kurallar: aynı yerde olmaması gerekenler

İki DC'yi, iki DNS sunucusunu ya da bir uygulamanın iki web sunucusunu aynı host'ta çalıştırmak, o host çöktüğünde ikisini birden kaybetmek demek. DRS bunu kendiliğinden bilemez. Cluster'da Configure, VM/Host Rules altından bir kural ekliyorum:

• Tür: "Separate Virtual Machines"
• VM'ler: dc01, dc02

DRS artık bu iki VM'i aynı host'a koymuyor. HA da bir host çöktüğünde kuralları dikkate alıyor, ama yer yoksa kuralı esnetip VM'i yine de açıyor. Bu doğru davranış: DC'nin kurala uymayan bir host'ta çalışması, hiç çalışmamasından iyi.

Ters yöndeki kural "Keep Virtual Machines Together", sürekli birbiriyle konuşan iki VM'i (uygulama ve veritabanı) aynı host'ta tutmak için. Bu daha az gerekiyor, çünkü host çökünce ikisi birden gidiyor.

VM'leri belirli host'lara bağlayan "VM to Host" kuralları da var. Lisansı host başına sayılan bir yazılım için işe yarıyor. Burada "must" ile "should" arasındaki farka dikkat: "must run on" kuralında HA bile o VM'i grubun dışındaki bir host'ta açmıyor. Lisans zorunluluğu yoksa "should" kullan.

Çalıştığını görmek

Kâğıt üzerinde her şey yeşil olabilir. HA'nın gerçekten çalıştığını görmenin yolu, iş saatleri dışında bir test: bir test VM'inin çalıştığı host'u Host Client'tan değil, doğrudan iLO/iDRAC üzerinden kapat ve VM'in kaç saniyede başka host'ta açıldığına bak. Cluster'ın "Monitor" sekmesindeki vSphere HA, Summary kısmı hangi host'un primary olduğunu ve her host'un HA durumunu gösteriyor.

DRS için de basit bir kontrol: cluster'ın Summary sayfasındaki DRS skoru ve "Monitor, vSphere DRS, Recommendations" altında bekleyen öneri olup olmadığı. Fully Automated'da öneri birikiyorsa VM'lerin taşınmasını engelleyen bir şey var: genelde bir VM'e bağlı ISO, ya da sadece bir host'ta tanımlı bir port group.

O ikinci sebep, bir sonraki yazının konusu. Ağ ayarlarını host başına değil cluster genelinde tek yerden yapmak.

Sıradaki yazı: vSphere Distributed Switch ile ağ yapılandırması