İçeriğe geç

vSAN Stretched Clusters

Stretched Clusterları anlatmaya öncelikle cluster’ın ne ifade ettiğine bakarak başlayabiliriz. Cluster, vSphere ortamında sanal makinelerinizin yürütüldüğü ESX Serverların bir kümesidir. Clusterlar tipik olarak bir single failure domainde örneğin bir data centerdadır. Single failure domainlerde bir host fail olduğu zaman diğer hostlar onun iş yükünü üstlenirler. Tüm hostların fail olduğu bir durumda ise iş yükünü üstlenecek kimse olmadığından bir disaster recovery durumu ortaya çıkmaktadır. İşte burada da devreye vSAN Stretched Clusterlar girmektedir. Stretched clusterlarda, clustera farklı failure domainlerde, örneğin biri A site’ında biri B site’ında olan ekstra hostlar ekleyebiliriz. Böylelikle herhangi bir durumdan ötürü A’daki hostlarımı kaybettiğimde B’deki hostlarım hala çalışmaya devam edecek ve A’daki iş yükünü (sanal makineleri) kendi üzerlerine alabileceklerdir.

vSAN Stretched Clusterlar tüm site’ın kaybına karşı esneklik sağlamaktadırlar. Ayrıca vSAN, vSphere High Availability (HA) ile de entegre şekilde çalışmaktadır. vSphere HA sayesinde bir site beklenmedik şekilde offline olduğunda, bu site’da bulunan sanal makineler veri kaybı yaşamadan diğer site’da otomatik olarak yeniden başlatılır.

vSAN Stretched Clusterlar disaster recovery durumlarında da oldukça kullanışlıdır. Böyle bir durumda bir sitedaki sanal makineler vMotion ile diğer site’a migrate edilebilirler.

Strectched clusterlar sitelar arasındaki redundancy ve failure protection’ı sağlamak için Fault Domainler kullanır. Stretched clusterdaki her site ayrı bir fault domainde bulunur.

vSAN Stretched Cluster 3 adet Fault Domain’den meydana gelmektedir: Primary ya da Preferred Site, Secondary Site ve Witness Host. Her fault domain farklı bir site’ı temsil eder. Witness host fail olduğunda veya maintenance mode’a girdiğinde vSAN bunu bir site failure olarak kabul eder.

vSAN Stretched Cluster ilk tanıtıldığında, mirroring sitelar arasındaki verileri korumak için tek seçenekti. Mirroringde veriler sitelar arasında birer replica ile mirror edilmiş yani yansıtılmıştır. Metadata (vSAN witness objects) ise üçüncü bir site’ta vSAN Witness Host’ta tutulur.

vSAN 6.6 ile birlikte artık secondary level of failure yapılandırılabilir hale gelmiştir. Bu özellik site içinde ve sitelar arasında esneklik sağlamaktadır. Örneğin RAID-5 Erasure Coding ile aynı sitedaki verileri korurken RAID-1 Mirroring ile de farklı sitedaki verileri koruyabilmektedir.

vSAN Stretched Clusterdaki local failure protection özelliği downtime süresini en aza indirmek için esnekliği arttırmaktadır. Bu özellik, bileşenlerin yeniden senkronize edilmesi veya yeniden yapılması gereken durumlarda siteler arası trafiği de azaltır veya ortadan kaldırır. Vsphere Web Client’taki Storage Policy aracılığıyla bu özelliği yapılandırıp, yönetebilmekteyiz. Aşağıdaki şekil All-Flash Stretched Cluster yapılandırmasının bir parçası olan Storage Policy’deki kuralları göstermektedir.

Primary level of failures to tolerate 1’e ayarlandığında vSAN verileri stretched clusterın main siteları arasında yansıtır (mirroring).

Secondary level of failures to tolerate ise sitedaki verilerin nasıl korunacağını belirler. Örneğin yukarıdaki storage policy’de RAID-5 Erasure Coding kullanılmıştır. Bu da sitedaki bir hostun kaybının tolere edilebileceği anlamına gelmektedir.

Karışıklığın önlenmesi için HTML5 tabanlı vSphere Client’ta bu işlem biraz daha farklıdır. Burada Storage Policy Wizard, Site Disaster Tolerance ve tolere edilebilecek failure sayısını açıkça sormaktadır.

vSAN Stretched Cluster konusu temel olarak bu şekilde anlatılabilir. Umarım faydalı olmuştur.

Tarih:vSAN

İlk Yorumu Siz Yapın

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir