vSAN OSA ve ESA’nın Mimari Farklılıkları

vSAN OSA (Original Storage Architecture), vSAN’ın geleneksel mimarisidir. Bu modelde, her disk grubu bir önbellek katmanı (SSD) ve bir kapasite katmanından (HDD veya SSD) oluşur. OSA, hem hibrit (HDD+SSD) hem de tamamen flaş yapılandırmaları destekler ve geleneksel RAID yapılandırmalarını (RAID-1 ve RAID-5/6) kullanır. Ancak, OSA’nın önbellek temelli yapısı, modern NVMe cihazlarının tam performansını ortaya koyma konusunda sınırlamalara sahiptir.

vSAN ESA (Express Storage Architecture) ise vSAN 8 ile tanıtılan modern bir mimaridir. ESA, NVMe cihazları optimize bir şekilde kullanan, disk gruplarını ortadan kaldıran ve tüm cihazları tek bir depolama havuzunda birleştiren bir yapıya sahiptir. Bu sayede daha yüksek performans, daha basit yönetim ve daha iyi depolama verimliliği sağlar. ESA’nın daha az manuel yapılandırma gereksinimi ve gelişmiş veri dayanıklılığı özellikleri, büyük ölçekli veya performans odaklı ortamlar için önemli avantajlar sunar.

vSAN OSA Mimari Diyagramı

Bu diyagram, vSAN OSA’nın disk grupları ve önbellek katmanlarını içeren geleneksel yapısını gösterir.

vSAN ESA Mimari Diyagramı

Bu diyagram, vSAN ESA’nın NVMe tabanlı, disk grubu olmayan modern mimarisini temsil eder.

Performans Karşılaştırması

OSA, geleneksel disk gruplarına ve önbellekleme mekanizmalarına dayalı olduğundan, performans genellikle önbelleğe bağlıdır. Bu, okuma/yazma gecikmesini artırabilir ve toplam throughput değerlerini sınırlayabilir.

ESA, NVMe’nin sağladığı düşük gecikme avantajını tam anlamıyla kullanır. Disk grubu yapısı bulunmadığından, ESA doğrudan depolama cihazlarına erişim sağlayarak daha yüksek IOPS, daha düşük gecikme ve daha yüksek bant genişliği sunar. ESA’nın performans optimizasyonu sayesinde, özellikle yüksek IOPS gerektiren uygulamalarda ciddi farklar oluşur.

vSAN OSA ve ESA Performans Karşılaştırma Grafiği

Bu grafik, OSA ve ESA’nın okuma/yazma gecikmesi ve IOPS değerlerindeki farkları gösterir.

Verimlilik ve Kaynak Kullanımı

OSA, RAID-1 mirroring gibi yapılandırmalara dayandığından daha fazla depolama aşımı yaratabilir. Deduplication ve compression işlemleri genellikle sonradan yapılır ve bu da verimliliği sınırlayabilir. Ayrıca, geleneksel RAID yöntemleri, modern NVMe cihazlarının potansiyelini tam anlamıyla kullanma konusunda kısıtlayıcı olabilir.

ESA, inline deduplication ve compression gibi özelliklerle çok daha verimlidir. RAID-5/6 benzeri dayanıklılık sağlayarak, kapasite açısından daha az aşım oluşturur. ESA’nın daha verimli veri yönetimi, özellikle büyük veri kümeleriyle çalışan ortamlar için ciddi maliyet tasarrufları sunabilir.

Ölçeklenebilirlik ve Yönetim Kolaylığı

OSA, disk gruplarını genişletme yoluyla ölçeklenir, ancak bu yöntem daha fazla fiziksel donanım, manuel yapılandırma ve daha karmaşık bir yönetim süreci anlamına gelir. Özellikle büyük ölçekli ortamlar için yönetim karmaşıklığı artabilir.

ESA, basitleştirilmiş ölçeklenebilirlik sunar. Disk grubu bulunmadığı için yeni cihaz eklemek çok daha hızlıdır. Tek bir depolama havuzu üzerinden yönetim sağlandığından, daha az hata ve daha kolay kapasite planlaması yapılabilir. Bu da ESA’yı büyük ölçekli, hızlı büyüyen altyapılar için ideal bir çözüm haline getirir.

vSAN OSA ve ESA Ölçeklenebilirlik ve Yönetim Diyagramı

Bu diyagram, OSA ve ESA’nın ölçeklenebilirlik ve yönetim süreçlerindeki farklılıklarını gösterir.

Maliyet Karşılaştırması

OSA (Original Storage Architecture) genellikle daha düşük başlangıç maliyetlerine sahiptir. Bunun temel nedeni, hibrit yapılandırmaları (HDD + SSD) desteklemesi ve geleneksel RAID yapılandırmalarını kullanmasıdır. Ancak, bu yapılandırmalar daha fazla fiziksel kapasite gerektirdiği için, uzun vadede toplam sahip olma maliyeti (TCO) artabilir. Özellikle, RAID 1 (mirroring) ve RAID 5/6 (erasure coding) yapılandırmalarında kullanılan ek depolama kapasitesi, işletme giderlerini zamanla yükseltebilir.

ESA (Express Storage Architecture) ise, tamamen NVMe cihazlara dayalı olduğundan başlangıçta daha yüksek bir yatırım maliyeti gerektirir. NVMe cihazların fiyatları, geleneksel SSD’lere kıyasla daha yüksek olmasına rağmen, ESA’nın sunduğu gelişmiş sıkıştırma ve deduplikasyon özellikleri sayesinde depolama verimliliği önemli ölçüde artar. Ayrıca, ESA mimarisi daha az kapasite aşımı gerektirdiği için, uzun vadede depolama maliyetlerini azaltabilir. Bu durum, özellikle büyük veri kümelerine sahip ortamlarda, toplam sahip olma maliyetini dengeleme veya düşürme avantajı sağlayabilir.

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post VMware vSAN OSA ve ESA Karşılaştırması: Mimari, Performans ve Verimlilik appeared first on BURAK AKTAŞ.

Bu makale, Cluster Health – CLOMD Liveness Check hakkında bilgi verir ve vSAN Health Service’in neden bir hata raporlayabileceğini açıklar.

CLOMD (Cluster Level Object Manager Daemon), bir vSAN kümesinin çalışmasında kritik bir rol oynar. Her ESXi ana bilgisayarında çalışır ve şu görevlerden sorumludur:

• Yeni nesne oluşturma
• Arızalar sonrası mevcut nesnelerin onarımını başlatma
• Veri taşıma ve tahliyeleri yönetme (Maintenance Mode’a girme, vSAN’den disk çıkarırken veriyi tahliye etme, dengeyi sağlama ve yeniden dengeleme işlemlerini tetikleme, politika değişikliklerini uygulama vb.)

CLOMD, doğrudan veri yolu işlemlerine katılmaz ancak veri yolu işlemlerini tetiklediği için birçok yönetim iş akışında ve hata senaryosunda kritik bir bileşendir.

Şu işlemler sırasında CLOMD gereklidir:

• Virtual Machine (VM) Power On
• Storage vMotion to vSAN

Bu işlemler bir swap object oluşturmayı gerektirir ve nesne oluşturma işlemi CLOMD tarafından yönetilir.

Ayrıca, vSAN 6.0 itibarıyla bellek anlık görüntüleri (memory snapshots) nesne olarak saklanır. Bu nedenle, memory state içeren bir snapshot almak da CLOMD’yi gerektirir.

Diğer Önemli Daemon’lar

vSAN kümesinin sağlıklı çalışmasını sağlamak için çeşitli daemon’lar görev yapar:

EPD (Entry Persistence Daemon)

• Her vSAN kümesindeki ESXi ana bilgisayarında çalışır.
• Silinen nesnelerin bileşenlerinin sızdırılmadığından emin olur.

CMMDSD (Cluster Monitoring, Membership, and Directory Service Daemon)

• CMMDS (Cluster Monitoring, Membership and Directory Service) içeriğini korur.
• Küme bağlantılarını izler ve küme metadata dağıtımı için ana dağıtım altyapısıdır.
• Küme sağlığı ve ağ bağlantılarının durumunu korur.

OSFSD (Object Store File System Daemon) – vSAN 8.0U2 ile Eklendi

• ESXi üzerinde çalışan ve sanal makineler için dağıtılmış bir dosya sistemi sağlayan bir daemon’dur.
• vSAN’in birincil depolama işlevine ek olarak file services sunmasına olanak tanır.

CMMDSTIMEMACHINED (Cluster Monitoring, Membership, and Directory Service Time Machine Daemon) – vSAN 8.0U2 ile Eklendi

• ESXi üzerinde çalışır ve nesne versiyonları için geçmiş metadata kayıtlarını tutar.
• Metadata tutarsızlıklarını geri alma yeteneği sunarak, vSAN kümesinin kurtarılmasını sağlar.

Hangi vSAN Sürümlerinde Geçerlidir?

• VMware vSAN 6.x
• VMware vSAN 7.x
• VMware vSAN 8.x

Çözüm: Cluster Health – vSAN Daemon Liveness Check Nedir?

Bu kontrol, aşağıdaki daemon’ların çalışır durumda olup olmadığını test eder:

• CLOMD
• EPD
• CMMDSD
• OSFSD (vSAN 8.0U2 ile eklendi)
• CMMDSTIMEMACHINED (vSAN 8.0U2 ile eklendi)

Özellikle CLOMD için:

• Tüm ESXi host’larda çalıştığından emin olunur.
• Servisin istatistikleri sorgulanarak yanıt verip vermediği kontrol edilir.

Diğer daemon’lar için sadece çalışıp çalışmadığı test edilir.

Not: Bu kontrol, nesne oluşturma, yeniden dengeleme gibi işlevlerin çalıştığını garanti etmez ancak ilk seviye bir sağlık değerlendirmesi yapar.

Hata Durumu Ne Anlama Gelir?

Eğer bu kontrol hata veriyorsa, CLOMD, EPD, CMMDSD, OSFSD ve CMMDSTIMEMACHINED daemon’ları beklenildiği gibi çalışmıyor olabilir. İlgili ESXi host’ta durum kontrol edilmelidir.

CLOMD’nin sağlığını test etmek için:

• Bir sanal makine oluşturma testi yapılabilir (Proactive tests).
• Çünkü bu işlem, nesne oluşturmayı tetikler ve CLOMD’nin düzgün çalışıp çalışmadığını test etmenin iyi bir yoludur.

Daha fazla bilgi için: CLOM Daemon Liveness Check

Hata Durumu Nasıl Giderilir?

1. Standart Küme İçin

Tüm ESXi host’larda, aşağıdaki servislerin çalıştığından emin olunmalıdır:

• CLOMD
• EPD
• CMMDSD
• OSFSD
• CMMDSTIMEMACHINED

2. Stretched Cluster veya Metadata Cluster İçin

Aşağıdaki tabloya bakarak, ilgili node’da servisin çalışması gerekip gerekmediğini kontrol edin.

Eğer ESXi host’ta bir daemon çalışmıyorsa, ilgili daemon’ın durumu “Abnormal” olarak görünecektir.

3. Manuel Kontroller

ESXi host üzerinde daemon’ların durumunu kontrol etmek için:

/etc/init.d/cmmdsd status && /etc/init.d/epd status && /etc/init.d/clomd status && /etc/init.d/cmmdsTimeMachine status && /etc/init.d/osfsd status

Eğer bir daemon çalışmıyorsa, aşağıdaki komut ile yeniden başlatabilirsiniz:

/etc/init.d/cmmdsd restart && /etc/init.d/epd restart && /etc/init.d/clomd restart && /etc/init.d/cmmdsTimeMachine restart && /etc/init.d/osfsd restart

Eğer vSAN Daemon Liveness Check hala başarısız oluyorsa veya bu kontrol düzenli olarak başarısız olmaya devam ediyorsa, VMware Support ile iletişime geçilmelidir.

Daha fazla bilgi için: Creating and Managing Broadcom Support Cases

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post vSAN Health Service – Cluster Health – Daemon Liveness Check appeared first on BURAK AKTAŞ.

vSAN ESA ve RAID Yapıları

vSAN’ın ESA mimarisi, geleneksel RAID konfigürasyonları yerine erasure coding kullanarak daha yüksek verimlilik, performans ve veri güvenliği sağlamaktadır. Aşağıda, vSAN ESA’nın desteklediği RAID konfigürasyonları ve her biri için gerekli minimum host sayıları açıklanmıştır.

1. RAID-1 (Mirroring – Aynalama)

• Minimum Host Sayısı: 2
• RAID-1, veriyi iki düğüm arasında aynalayarak korur.
• Her iki düğüm de aktif olmalı ve erişilebilir olmalıdır.
• Eğer bir düğüm arızalanırsa, diğer düğüm verinin tam bir kopyasını sakladığı için veri kaybı yaşanmaz.

2. RAID-5 (Erasure Coding – 3+1)

• Minimum Host Sayısı: 3
• Desteklenen Cluster Boyutu: 3-5 host
• RAID-5, parite bazlı veri koruma mekanizması kullanarak hem depolama verimliliğini artırır hem de tek bir düğüm arızasına karşı koruma sağlar.
• En az 3 host gereklidir, böylece veri ve parite blokları dağıtılabilir.
• Eğer bir host donanım arızası yaşarsa, diğer hostlar üzerinden veri erişimi devam eder.

3. RAID-6 (Erasure Coding – 4+2)

• Minimum Host Sayısı: 4
• Desteklenen Cluster Boyutu: 6+ host
• RAID-6, iki parite bloğu kullanarak çift hata toleransı sağlar.
• En az 4 host gereklidir ve bu yapılandırma, iki hostun aynı anda arızalanması durumunda bile veri erişimini sürdürebilir.
• RAID-5’ten farklı olarak, daha fazla veri koruması sunduğu için büyük ölçekli sistemlerde tercih edilir.

vSAN ESA ile RAID-5 Şema Değişiklikleri

• vSAN ESA kullanırken, RAID-5 için küme boyutunun değişmesi, RAID şemasını da etkileyebilir.
• Kümenin büyümesi veya küçülmesi, verinin nasıl bölümlendiğini ve parite dağılımını değiştirebilir.
• Daha fazla host eklenmesi, depolama verimliliğini artırabilir ve veri koruma seviyesini güçlendirebilir.

Sonuç

VMware vSAN ESA, RAID-1, RAID-5 ve RAID-6 gibi farklı veri koruma mekanizmalarını destekleyerek, farklı ölçeklerdeki iş yükleri için yüksek performanslı ve güvenilir bir depolama altyapısı sunar.

• Küçük ölçekli sistemler için RAID-1,
• Orta ölçekli cluster’lar için RAID-5,
• Büyük ölçekli sistemler ve kritik iş yükleri için RAID-6 daha uygun bir seçenektir.

vSAN ESA’nın sunduğu erasure coding mekanizmaları, geleneksel RAID çözümlerine göre daha az depolama alanı harcayarak yüksek veri dayanıklılığı ve verimlilik sağlar.

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post vSAN ESA ve RAID-1/5/6’ya Sahip Minimum Host Sayısı Kaç Olmalı? appeared first on BURAK AKTAŞ.

vSAN Ortamı üzerinde çalışırken, iş yükünüzün iyi çalıştığı ve her şeyin çevrimiçi olduğu düşünebilirsiniz. Ancak, monitor sekmesi altındaki vSAN Health bölümüne baktığınızda vSAN kümesinde erişilemeyen nesneler olabilir.

Bu, erişilemeyen nesneler silinerek çözülebilen yaygın bir sorundur, ancak silme işlemini gerçekleştireceğiniz için çok dikkatli olmanız ve her zaman bu işlemi gerçekleştireceğiniz VM‘lerin sağlıklı bir yedeğini aldığınızdan emin olmanız gerekir.

vSAN objelerinin sağlık durumun özetini almak için aşağıdaki komutla işe başlayabilirsiniz.

# esxcli vsan debug object health summary get

Inaccessible vSAN objelerinin listesini almak için.

# esxcli vsan debug object list –health=inaccessible > tmp/inaccessible.txt

Inaccessible datanın içinden Object UUID‘yi kopyalıyoruz.

# cat inaccessible.txt | grep “Object UUID”

vSAN kümesi içindeki attribute’ları kontrol ediyoruz.

/usr/lib/vmware/osfs/bin/objtool getAttr <UUID>

Artık tüm ayrıntıya sahipsiniz, bu gördüğünüz girdinin eski mi yoksa şu anda kullanılıyor mu olduğuna karar vermek için son şansınız. Bundan sonra son komut ile girdileri sileceksiniz.

/usr/lib/vmware/osfs/bin/objtool delete -u <UUID> -f;

Herhangi bir noktada ne yaptığınızdan emin değilseniz, durmanızı ve VMware‘e support case açmanızı tavsiye ederim.

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post Deleting Inaccessible Objects from vSAN Datastore appeared first on BURAK AKTAŞ.

Hata üzerindeki KB56991‘i incelediğimizde bize pek yardımcı olmadı. Bizde biraz daha araştırma yapmak zorunda kaldık ve KB85516‘yı bulduk. Bu KB bize iki ESXi hostu üzerinde vMotion yapmaya çalıştığımızı ve bu sırada NSX-T segmentlerini de değiştirmeye çalıştığımızı anlatıyordu. Fakat bu segment taşımasında mümkün olmayan bir durummuş.

VM migration sırasında NSX-T segment’i de değiştirmek varsayılan olarak mümkün değilmiş. Bu yüzden bu vMotion‘a izin vermek için “vCenter Advanced Settings” ayarlarından aşağıdaki parametreyi girip “TRUE” olarak set etmemiz gerekiyormuş.

config.vpxd.network.allowVmotionBetweenLogicalSwitches

Bu nokta da yanılmamak adına, doğruluğu kontrol etmek için VMware’a case açtık ve onlarda bize bu parametrenin herhangi bir anormal durum yaratmadığını, parametreyi kullanabileceğimizi belirtti.

Burada dikkat edilmesi gereken bir nokta da “Advanced Setting” üzerinde yapılan işlemler html5 üzerinden silinememektedir bu yüzden parametreyi dikkatli girmenizi öneririm. Bunu ancak komut satırı üzerinden kaldırabilirsiniz. Bununla ilgili yazıya da aşağıdaki linkden ulaşabilirsiniz.

How to Delete vCenter Server Advanced Setting

Konumuza dönecek olursak parametre’mizi girdikten sonra yapmamız gereken herhangi bir reboot veya services restart bulunmamaktadır.

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post vMotioning a VM on NSX-T Data Center segment fails when moving between different segment on a different host appeared first on BURAK AKTAŞ.

vCenter Server üzerinde kullanmak istemediğimiz veya yanlış tanım yapmış olduğumuz bir parametreyi html5 üzerinden silmemiz mümkün değil. Ancak bunu komut satırı üzerinden yapabiliriz.

Komut satırı üzerinden “advanced setting” parametresini aşağıdaki adımları izleyerek kaldırabilirsiniz.

• SSH ile vCenter Server’a bağlanıyoruz.
• “shell” yazarak kök dizine düşüyoruz.
• /etc/vmware-vpx/ dizinine gidiyoruz.
• “vpxd.cfg” dosyasında vi/vim yardımı ile silmek istediğimiz parametreyi bulup siliyoruz.
• Sonrasında “service-control –restart vmware-vpxd” komutu ile vpxd servisini restart ediyoruz.

Tüm yapmamız gereken bu kadar. Kontrol ettiğimizde “advanced setting” parametresinin silindiğini göreceksiniz.

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post How to Delete vCenter Server Advanced Setting appeared first on BURAK AKTAŞ.

Başvuru sayfasına, vExpert ünvanının size getirilerine ve detaylara aşağıdaki link’den kolayca ulaşabilirsiniz.

vExpert Application 2023

The post vExpert Applications are Open – 2023 appeared first on BURAK AKTAŞ.

- Metadata and system validation failed.

- Error: Unknown system resource type log

Bu hata, eski vCenter sunucusunun 1 adet genişletilmiş diske sahip olmasından kaynaklanır. Bu nedenle bu diskin orijinal boyutu için “backup-metadata.json” yedek meta veri dosyası kontrol edilip, ilgili VMDK genişletilir. Benim örneğimde Error‘da görüldüğü üzere log diskinde problem vardı, ben bu diski genişlettim.

KB: https://kb.vmware.com/s/article/2145603

Sonrasında restore işlemine devam edebilirsiniz.

Bir sonraki yazımızda görüşmek üzere. Faydalı olması dileğiyle.

The post VCSA Restore Failed appeared first on BURAK AKTAŞ.