Başlangıç > VMware > 212: vCenter Server 6.5 High Availability

212: vCenter Server 6.5 High Availability

vCenter sunucuları için HA çözümü, uzun zamandır müşteriler tarafından talep edilen bir özellik idi, elimizde bir takım seçenekler olmasına rağmen gerçek anlamda bir HA çözümü sunamıyordu. Bu alternatifler;

  • vSphere HA: Geleneksel yöntem ile host seviyesinde yedeklilik.
  • vSphere 6.0 Fault Tolerance: vSphere 6.0 ile desteklenen, 2 vCPU veya 4 vCPU’luk küçük ortamlar için ideal denebilecek bir çözüm (FT limitasyonundan dolayı).
  • vCenter Server Watchdog: vSphere 6.0 ile birlikte Watchdog servisi, VPXD servislerini monitör eden ve erişilemediği durumda servisi yeniden başlatmayı deneyen bir eklenti. Uygulama seviyesinde koruma sağlıyor iken, OS veya donanım seviyesinde yetersiz kalıyor.
  • Windows Server Failover Cluster: vCenter 5.5 Update 2 ve sonrası için geçerli bir senaryo. Elbette vCenter sunucusunun Windows olma durumu söz konusu.
  • VMware vCenter Server Heartbeat: “End of Availability” olmuş bir ürün.

Not: Bu çözümler ile ilgili daha detaylı bilgi için (KB1024051)

Bir çok kurum, belirli bir noktaya kadar, vCenter servislerinin HA senaryosu üzerinde çok durmamıştır, hem tüm sunucuyu kaybetme olasılığımızın düşük olması, hem de VM’lerin çalışmaya devam edecek olmasından dolayı. Ancak günümüzde, vCenter çok daha büyük bir ekosistemin kalbinde yer aldığından dolayı (yedekleme sistemleri, vRA, NSX, OpenStack gibi), RTO süresinin uzamasının etkileri daha büyük olacaktır. Bu yüzden de, vSphere 6.5 ile birlikte native bir HA çözümü geliştirildi, vCenter Server High Availability (VCHA).

Not: Ürün GA olduğunda bahsedilen özelliklerde değişiklikler söz konusu olabilir.

Öncelikle bu çözüm sadece vCenter Server Appliance (VCSA) için geçerli. Windows temelli sunucuda bu özelliği kullanamayacağız.

Genel olarak çözüm, VCHA özelliğini etkinleştirdiğinizde, iki adet daha VC üretilmesi ve elimizdeki üç adet VC ile aktif, pasif ve witness yapısının oluşturulması şeklinde. Bu sunucular dış dünya ile normal ethernet adaptörlerinden (eth0) ile konuşuyor iken kendi aralarında da private bir hattan ve ayrı bir adaptör (eth1) üzerinden konuşuyor olacaklar. Bu eth1 arabirimleri üzerinden, aktif ve pasif VC arasında dosya ve veritabanı senkronizasyonu gerçekleşecek. Witness VC ise, her hangi bir split-brain senaryosunu engellemek amacı ile konumlandırılacak.

vcha

VCHA’i etkinleştirdiğinizde, orjinal VC’den klon çıkılarak pasif VC oluşturuluyor ve eth1 konfigürasyonları yapılıyor. Bu model, aktif-pasif bir model olduğundan birim zamanda sadece bir adet VC’nin public IP’si aktif durumda, pasif VC’nin portu “admin shut” durumunda. Tanımlama sonrası da aktif VC ile pasif VC arasında dosya ve DB senkronizasyonu başlıyor. Aktif sunucu eğer kapanırsa, pasif sunucu portu aktif oluyor ve vCenter servisleri ayağa kaldırılıyor. Burada servislerin ayağa kalkma süresi doğrultusunda tahmin edilen RTO süresi 5 dakika ancak bu ortamınıza göre daha uzun veya kısa olabilir. IP aynı kaldığından dolayı, client’lar için değişen her hangi bir konu olmuyor.

VC tarafı için getirilen bu HA özelliğinin bir güzel tarafı da, PSC için de geçerli olması. Yani daha önceden NLB ile yaptığımız aktif-pasif yük dağıtımı için de alternatif oluşturuyor bu çözüm.

Burada private link ile ilgili 10ms RTT gereksinimi var. Aktif ve pasif VC arasında bu gereksinim anlamlı iken, witness VC ile neden 10ms mertebesinde olduğu belirsiz. Tahminim, ürün GA olduğunda veya sonrasında witness ile ilgili gereksinimin 100-200ms mertebelerine çıkması olacaktır (VSAN witness appliance’da olduğu gibi).

VMware’ın özellikle üzerinde durduğu bir nokta var, bunun bir HA çözümü olduğu, DR çözümü değil. DB replikasyonu vPostgres üzerinden senkron bir şekilde gerçekleşecek. Senkron replikasyonun anlamı, veri replike edilen DB üzerinde commit edilmeden, aktif DB üzerinde de commit edilmeyeceği olduğundan dolayı performans etkileri oluşturabilecek bir düzen, bu yüzden aradaki RTT önemli.

Son olarak, tam VCHA özelliğini adreslemese de, vermek istediğim bir bilgi var. vSphere 6.0 versiyonunda, VC sunucularını cmsso-util komutu ile başka bir PSC sunucusuna register ettirebiliyorduk, hatta resmi olarak desteklenmese bile teknik olarak başka bir site içerisinde bulunan PSC üzerine de yapabiliyorduk. 6.5 ile ilgili edindiğim bilgi, artık bunun mümkün olmayacağı yönünde. Eğer PSC sunucularınızı site’lar arası yedeklemeyi ve problem esnasında manuel repoint etmeyi düşünüyorsanız, bu artık mümkün olmayacak.

Kategoriler:VMware Etiketler:, ,
  1. Henüz yorum yapılmamış.
  1. No trackbacks yet.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

w

Connecting to %s

%d blogcu bunu beğendi: