Merhaba,
Farkettim ki vSan’la ilgili bir çok şey yazmış olmama rağmen temelleri ile ilgili hiç bir makale yazmamışım bu eksikliği kapatmak için kapsamlı bir makale yazdım.
VMware vSan ESXI sunucuların kernel’inde çalışan sanal makineler için paylaşımlı depolama alanı oluşturan yazılım tabanlı bir mimari kullanır. ESXI hostlar üzerinde bulunan diskleri, vSan sayesinde sanallaştırarak tek bir veri depolama havuzu olarak kullanır. Harici bir veri depolama gereksinimini ortadan kaldırır. vSan cluster bazlı olarak etkinleştirilir ve etkinleştirdikten sonra, ESXI sunucular üzerinde takılı olan diskleri önce kendi içinde gruplar. Disk gruplarında en az bir cache diski bulunmalıdır. Cache disklerin görevi kapasite disklerine veri yazmaktır. Cache disklerin içerisinde veri depolama yapılmaz, veri depolama için kapasite diskleri bulunmaktadır. Kapasite diskleri bir vSan cluster’da en az bir en fazla altı adet bulunabilir. Kapasite disklerinin görevi veri depolamaktır. vSan mimarisi sayesinde cluster’a üye bütün sunucuların disk gurubundaki cache ve kapasite disklerini veri depolama kuralına göre birlikte kullanabilir. Cluster’a üye bütün sunucuların disk gruplarını içeren tek bir vSan Datastore oluşturulur. Tek bir vSan veri depolama havuzu, her sanal makine veya her sanal disk için farklı servis seviyeleri sağlayabilir. Sanal makineler oluşturulduğunda, vSan sanal makineleri her sanal makinenin gereksinimlerine göre en uygun kaynaklara yerleştirmek için bu kuralı kullanır.
Bu konuya bir Örnek vermek gerekirse; Bir SQL sanal makinesini düşünelim, sanal makinenin “C” diskini Raid 5, SQL’in kurulduğu “D” diskini Raid 1, Log disklerinin bulunduğu “E” diskini Raid 6 şeklide ayarlanabilir ve bu işlemlerin tamamı vCenter üzerinden yapılabilir.
vSan yukarıdaki özellikleri kullanırken DRS, HA, FT gibi VMware’in temel özelliklerini kullanmaya devam edilmesini sağlar.
vSan hibrit veya All-Flash cluster olarak çalışacak şekilde yapılandırılabilir. Hibrit yapılarda cache katmanı için flash ürünler kullanılırken depolama alanı için dönen disk teknolojisinde ürünler kullanılabilir.
All-Flash cluster’lar için flash diskler kullanılırken, cache diskleri yazma temelli disklerden oluşur.
vSan Cluster’lar disk yapılarına göre VMware’in izin verdiği en yüksek değerlere ulaşabilirler. Örn: vSan cluster’ınız, tek bir cluster’da 64 ESXI sunucuya kadar büyüyebilir.
vSan yapısı verileri obje adı verilen esne container’lar halinde depolar ve yönetir. vSan veri havuzunda bir sanal makine oluşturulduğunda , vSan, her sanal disk için birden çok bileşenden oluşan bir dizi obje oluşturur. VMDK’ları 255 GB’lık Chunk’lar halinde barındırır. vSan, sanal disk gereksinimlerinin belirtilen Sanal makine veri depolama kuralına göre uygulandığını doğrular.
vSan koruma kuralına bağlı olarak kaç replika oluşturulması gerektiğini, performans kuralına göre her replica için ayrılmış flash cache okuma miktarı ve her replica için kaç strip’in oluşturulacağı belirler. Bu gerekliliklerin cluster’da yerleştirileceği yeri ve doğru cluster kaynaklarının kullanıldığını doğrular. vSan, sanal diskin kuralla uyumluluk durumunu sürekli olarak izler ve raporlar. vSan, mirror ve witnesses gibi gerekli koruma bileşenlerinin ayrı sunuculara veya fault domain’lere yerleştirildiğini doğrular.
Örneğin; vSan cluster’ında çalışan bir sanal makine’nin hata anında, veri depolama kuralında tercih edilen koruma faktörüne göre, verinin kaç sunucu üzerinde replikasının bulunduğunu kontrol eder ve hata alınan sunucu dışındaki sunucularda kurala göre replikalarını oluşturur. Hizmet kesintisi olmaması için oluşturulan cluster’da ne kadar çok sunucu varsa verinin replikasının oluşturulabileceği anlamına gelir.
vSan kendine özgü bazı tanımlar ve/veya hatalar içermektedir. Bunlar;
vSan Veri Deposu aşağıda bulunan nesne türlerini içermektedir:
- VM Home Namespace: VMX, log dosyaları, vmdk’lar ve snapshot delta description dosyaları gibi tüm sanal makine yapılandırma dosyalarının toplandığı alan Virtual Machine Home Directory’dir.
- VMDK: Sanal makinenin, sanal sabit disk sürücüsünün içeriğini depolayan bir sanal makine diski ve ya .VMDK dosyasıdır. Sanal makine içerisine yazılan verilerin tutulduğu alandır.
- VM Swap Object: Sanal makine açıldığında oluşturulur.
- Snapshot Delta VMDKs: Sanal makinenin snapshot’u alındığında oluşturulur.
- Memory object: Sanal makine Suspending duruma getirildiğinde veya snapshot memory option seçildiğinde oluşturulur.
Sanal Makine Uygunluk Durumu: Compliant ve Noncompliant
Bir sanal makine, nesnelerinden biri veya daha fazlası atanan veri depolama kuralı gereksinimlerini karşılayamadığında noncompliant (uyumsuz) olarak kabul edilir. Sanal makineler veri depolama kuralında tanımlanan gereksinimlere uygunsa, sanal makinelerinizin durumu Compliant (Uyumlu) olarak kabul edilir. vCenter üzerinde vSan tabı altındaki Physical Disk Placement kısmından sanal makinelerin objelerinin uyumluluk durumu görülebilir.
vSan Bileşenler Arızası Durumu : Degraded ve Absent
Degraded: vSan kalıcı bir bileşen arızası tespit ederse ve bileşenin çalışma durumuna gelmeyeceğini varsayarsa, bu bileşen Degraded State durumdadır.
Bu Sorunlar Neden Olur?
- Cache disk hatası
- Kapasite (Manyetik veya Flash disk) hatası
Absent: vSan, bileşenin çalışma durumunu iyileştirip geri yükleyebileceği geçici bir bileşen arızası tespit ederse bu bileşen Absent durumdadır. Varsayılan olarak, vSan 60 dakika sonra Absent durumundaki bileşenlerini yeniden oluşturmaya başlar. 60 dakikalık bu süre değiştirilebilir fakat VMware uzmanları tarafından yapılan çalışmalarda bakım için gerçekleştirilen operasyonlar (güncelleştirme, yeniden başlatma vs) testlerinde ESXI hostların tekrardan hizmet vermeye başlaması için ideal süre olarak 60 dakika belirlenmiştir.
Bu Sorunlar Neden Olur?
- Network Bağlantısı Sorunu
- Fiziksel network kartı
- ESXi host kaybı
- Bulunamayan (çıkan, çalışmayan vs) flash caching aygıtı
- Bulunamayan (çıkan,ç alışmayan manyetik disk veya flash kapasite aygıtı
Veri depolama kuralına göre objelerin sağlıklı şekilde çalışabilmesi için gerekli olan yedekliliğin sağlandığı koşullarda, objeler Healthy (sağlıklı) durumdadır. Objelerin sağlıklı bir şekilde (veri depolama kuralına göre) barındırılamayacağı durumlarda nesneler Unhealthy (sağlıksız) duruma geçer. vSan verilerin sağlıklı bir şekilde barındırılabilmesi için Witness barındırır.Witness, yalnızca meta data içeren ve herhangi bir gerçek uygulama verisi içermeyen bir bileşendir. Potansiyel bir arızadan sonra, ayakta kalan veri deposu bileşenlerinin mevcudiyeti ile ilgili bir karar verilmesi gerektiğinde kilit görevi görür. Witness, disk biçimi 1.0’ı kullanırken vSan veri havuzunda meta data için yaklaşık 2 MB, sürüm 2.0 ve üstü için disk formatı için 4 MB alan tüketir.
Veri Depolama Yönetimi /Storage Policy-Based Management (SPBM)
vSan veri depolama kuralını kullanırken, performans ve kullanılabilirlik gibi sanal makine veri depolama gereksinimlerini bir kural (policy) olarak tanımlanır. vSan cluster içerisinde sanal makineleri dağıtırken bir veri depolama kuralı uygulamıyorsanız, vSan otomatik olarak varsayılan kuralı uygular. Varsayılan kural Primary Level of Failures to Tolerate (PFTT) 1 olarak ayarlanmıştır. Her obje için tek bir disk Stripe olacak şekilde ve Thin hazırlanmış sanal disk kuralıdır.
Veri depolama yönetimi vSan’la birlikte bazı yeni terimler hayatımıza girdi.
Number of Failures to Tolerate (FTT): Sunucular üzerinde, ağ bağlantısı, disk, disk grubu veya fiziksel sunucunun fiziksel aygıt arızalarına karşı korumasını sağlar. FTT seviyesi ne kadar yüksek olursa verinin koponentleri o kadar fiziksel yedekli olur.
Komponentler ne kadar çok host’a dağıtılırsa veri kaybı riski o kadar düşük olmaktadır. Her koruma seviyesi için gereken en düşük host gerekliliği aşağıdaki tabloda verilmiştir.
| FTT | Mirror copies | Witnesses | Minimum hosts | Hosts + maintenance |
| 1 | 2 | 1 | 3 hosts | 4 hosts |
| 2 | 3 | 2 | 5 hosts | 6 hosts |
| 3 | 4 | 3 | 7 hosts | 8 hosts |
Fault Tolerance Method: Cluster’da bulunan sanal makinelerin sanal disklerinin birbirinden farklı performans ve veri yedekliliği ihtiyaçları bulunmaktadır. Bu ihtiyaçları sağlamak için veri depolama kuralları yazılırken raid yöntemi belirlenir. vSan yazılım tabanlı bir veri depolama çözümü olduğu için Raid mimarisi de yazılım temellidir.
| Number of failures to tolerate | Erasure coding | Minimum hosts | Hosts + maintenance |
| 1 | RAID 5 | 4 hosts | 5 hosts |
| 2 | RAID 6 | 6 hosts | 7 hosts |
FTT ve FTM belirlerken kullanılan tolerans seviyesi ve method’a göre sanal makinelerin boyutları değişmektedir. Aşağıdaki tablo üzerinden bir sanal makinenin FTT ve FTM kurallarına göre vSan Data Store üzerinde kaplayacağı yer görülmektedir.
| FTT LEVEL | FTT METHOD | MIN NUMBER OF HOSTS | MULTIPLICATION FACTOR | RAW CAPACITY BASED ON 100TB USABLE |
| FTT=1 | Mirror | 3 | 2x | 200TB |
| FTT=2 | Mirror | 5 | 3x | 300TB |
| FTT=3 | Mirror | 7 | 4x | 400TB |
| FTT=1 | RAID5 | 4 | 1.33x | 133TB |
| FTT=2 | RAID6 | 6 | 1.5x | 150TB |
vSan’da verinin korunması ve performansı için çok fazla opsiyon bulunmaktadır. Bu opsiyonların bir bölümü yukarda belirtildiği gibi veri merkezinin içinde olup bir bölümü içinde ikinci veri merkezi opsiyonu bulunmaktadır. Bu durumda da vSan’la birlikte hayatımıza giren Stretched Cluster kavramı gündeme geliyor.
Stretched Cluster; Mevcut veriler, iki ayrı veri merkezine eş zamanlı şekilde yazılır, bu lokasyonların birincisi sanal makinelerin çalıştığı Preferred, ikincisi ise adından da anlaşılacağı gibi Secondary’dir. Veri merkezlerinden birinin kesinti yaşaması durumunda kural’a tabi olan sanal makineler yeniden başlatılarak Secondary veri merkezinde çalışmaya başlarlar.
Stretched Cluster oluşturmak için gerekli olan lisans bilgisini tabloda görebilirsiniz;
Stretched Cluster oluşturabilmek için iki veri merkezi arasında en fazla 5 MS gecikme olması, veri merkezlerinin arasındaki bağlantının Layer 2 ve 10 Gbe olması gerekmektedir. En düşük 3+3+1, en yüksek 15+15+1 olmak üzere bir yapı kurulabilir. Burada +1’i temsil eden node Witness node’dur. Witness sunucusunun iki veri merkezi haricinde üçüncü bir noktada olması olası bir felaketten etkilenmeden Witness’ın doğru karar vermesini sağlamak içindir.
