VMware vSAN ESA/MAX Mimarisi ile Altyapı ve Kaynak Planlama (Deep Dive)
Merhaba, VMware vSphere 8 ile vSAN mimarisinde pek çok major değişiklik yapıldı vSphere v8 ile gelen ESA mimarisine ek olarak v8 U2 ile vSAN MAX mimarisi de kullanıma sunularak SDS/HCI platformları üzerinde oldukça güzel gelişmeler sağlandı.
Diğer bir yenilikse VMware Core Subscription lisanslama ile artık oldukça esnek fonksiyonel bile hale gelerek daha modüler bir platform dizayn etmenize olanak sağladı. Şahsen ben Core tabanlı subscription lisanslamayı beğendim. Bunu aylar önce kullanmaya başlayan biri olarak maliyet olarak önceki soket tabanlı Per-CPU lisanslamaya göre daha uygun buldum. VMware burada bir çok ürününü bundle hale getirerek aslında daha entegre ve fonksiyonel ortamlar kullanmanıza olanak sağlamış durumda. Add-On lisanslama ile de isterseniz ek özellikler edinerek oldukça esnek şekilde büyüyebiliyorsunuz.
vSAN diğer HCI çözümlerine göre oldukça esnek ve native bir servis olarak çalıştığından oldukça düşük overhead’a sahip. vSAN en güzel olduğu noktalardan biride kurulum, bakım, upgrade, yönetim ve izlenmesi oldukça kolay. Öğrenmek için 1 gün bile yeterli bu da OpenSource SDS çözümleri ile kıyaslandığında operasyon ekipleri için oldukça kolaylık sağlıyor. Yapı olarak herhangi bir Storage Control VM ya da Container tabanlı servis ve operasyon ihtiyacı bulunmuyor. Bu da onu oldukça cazip kılıyor. Diğer türlü hem troubleshooting zorluğu hem de compute overhead ortaya çıkabiliyor.
vSAN ESA Mimarisi
vSAN OSA mimarisinden farklı olan neler var dersek tamamen yeni bir Log-structured Filesystem (vSAN LFS) yapısı ile geliyor.
vSAN ESA oldukça esnek Metadata yönetimi sağlıyor. Daha verimli bir eşleşme için veri ağacı yapısını kullanıyor.
Aşağıdaki şekilde görüldüğü gibi metadata sayfaları bellekte tutularak performans odaklı ölçeklenebilir bir yapı kullanabiliyoruz. Diskten alınmak istenen aktif erişilen blokları memory üzerinden sağlayarak daha yüksek performans sağlayabiliyor.
vSAN ESA gelen I/O isteğine göre en uygun veri yolundan birini seçerek uyarlanabilir yazma yöntemini kullanabilir. Varsayılan veri yolu ufak bir I/O işlerken daha büyük ikinci veri yolu, gelen daha büyük I/O isteklerini işlemek için öncelik sahibidir. Bu da farklı iş yükleri için aynı yazma operasyonunu yerine iş yükünün tipine ve boyutuna göre yazma performansının ölçeklendirilebilmesini sağlamaktadır.
Özelikle Write-Instensive iş yüklerinde bu sayede yüksek IOPS, yüksek bant genişliği ve düşük gecikme sağlanır.
ESA, LFS dosya sistemi ile gelen RAID6 yazma isteği RAID1 yazma isteği ile hemen hemen aynı performansı sağlar. Bu sayede RAID1 performansına yakın bir şekilde yazabilir ve %50 veri tasarrufu sağlayabilirsiniz.
Okuma isteklerinde ise gelen istek ilk olarak Distributed Object Manager (DOM) istemcisine işlenir. DOM istemcisi yakın zamanda kullanılan blokları önbellek üzerinden kontrol eder kullanılabilir blok önbellekteyse okuma işlemi hemen gerçekleşir. Eğer blok önbellekte değilse bu sefer ikinci adıma geçer. LFS in-memory buffer olarak istenen verinin tutulup tutulmadığını kontrol eder eğer yoksa bu sefer üçüncü adıma geçer. Metadata üzerinde bir arama gerçekleşir veriler B-Tree olarak bilinen metadata üzerinde bulunur. Buradaki istek DOM istemcisine geri gönderilip checksum kontrol edilir. Eğer veride sıkıştırma varsa decompress uygulanır ve okuma isteği tamamlanır.
ESA, Native Key Provider ile harici KMS kullanmadan kendi cluster şifrelemesini yerleşik olarak yapabilirsiniz. Data Encryption Key (DEK) cluster üzerindeki tüm node’lar tarafından paylaşılır. Böylece şifrenin çözülmesine gerek kalmadan tüm node’lar arasında taşınabilir veya okunabilir. OSA mimarisi ile kıyaslandığında her I/O işlemi için gerekli şifreleme kaynak gereksinimi büyük ölçüde azalmış olacaktır. Ek olarak sıkıştırma işlemi şifrelemeden etkilenmeyecektir.
ESA vSAN Cluster üzerinde Native Snapshot desteği de sağlamaktadır. ESA Snapshot aynı yazma ve okuma isteğinde olduğu gibi geleneksel chain snapshot yerine B-Tree tablosunu kullanır. LFS dosya sistemi hangi verinin hangi anlık görüntüye yazılacağını metadata üzerinden sağlar. Snapshot silme işlemi neredeyse 100 kat daha hızlıdır. ESA üzerinde snapshot silindiğinde snapshot silme işlemi büyük ölçüde metadata veri silme işlemi olarak gerçekleşir. Silme işlemi mantıksal olarak gerçekleşir daha sonra uygun bir zamanda metadata ve veriler kaldırılır. Versiyon 8 ile şuan obje başına maksimum 32 snapshot alınabilmektedir.
ESA mimari olarak her diski birbirinden bağımsız olarak claim eder. OSA mimarisindeki Disk Group başına bir Cache disk arızalandığında o cache diske bağlı olan tüm kapasite diskleri işlem dışı kalır. Aşağıdaki örnekteki görüldüğü gibi 2 farklı disk grup ve toplamda 12 adet 8TB kapasite diski mevcut. %50 doluluk varsaydığımızda ikinci disk gruba bağlı Cache disk arızalandığında 24TB data için rebuild işlemi başlıyor ve host kapasitesine %50 etkisi oluyor. Benzer senaryoyu ESA üzerinde gözlemlediğimizde cache tier olmadığından disklerden herhangi biri arızalandığında etkisi sadece o diskin doluluk oranı kadar oluyor.
ESA, LFS dosya sistemi ile gelen RAID6 yazma isteği RAID1 yazma isteği ile hemen hemen aynı performansı sağladığından bahsetmiştim. ESA mimarisi ile Erasure Coding için gerekli olan node sayılarında da güncellemeler oldu. vSAN ESA ile RAID-1 policy için artık Dedicated Witness Node gereksinimi bulunmuyor. OSA mimaride RAID1 storage policy için Witness Node gereksinimiz vardı. Bu sayede minimum 3 node ile ESA mimaride hem RAID1 hem de RAID 5 storage policy oluşturabiliyoruz. RAID5 kullandığımız takdirde %50 bir capacity overhead tasarrufumuz olmuş oluyor. Eğer burada 5 node kullanırsak bu durumda RAID5 ile %75 capacity overhead tasarrufumuz olmuş olacaktır.
vSAN ESA ile compression varsayılan olarak açık gelmektedir. Ama isterseniz vCenter Storage Policy Based Management (SPBM) üzerinden sıkıştırma opsiyonu farklı bir Storage policy üzerinden kapalı olarak oluşturabilirsiniz. Buna neden gerek olabilir derseniz PostgreSQL, Video gibi işi yükü ve dosyaların kendi sıkıştırma özelliklerini kullanmanız daha doğru olacaktır. Bu durumda zaten sıkıştırılmış bir veri için tekrar sıkıştırma eforu ortadan kalkacak ve CPU üzerinde compute ihtiyacını daha efektif kullanacaksınız.
vSAN ESA, OSA mimariye göre 4x daha fazla sıkıştırma performansına sahiptir. OSA teorik sıkıştırma oranı 1:2 iken ESA ile kullanılan iş yüküne göre bu oran 1:8 oranına kadar çıkabilir. Bu yazımızda sizing yaparken ben bunu en garanti olan 1:2 oranına göre hesapladım.
NOT: ESA mimaride cluster seviyesinde deduplication kullanılmamaktadır. Bunun yerine granüler olarak compression kullanabilirsiniz. (cluster seviyesinde compression artık yok) bu nedenle artık oldukça esnek Storage policy uygulayabilirsiniz.
Minimum Disk ve Node gereksinimleri
vSAN ESA için node üzerindeki tüm disklerin NVMe olması gerekiyor. OSA ile kıyaslandığından vSAN ESA üzerinde Cache Tier ve Capacity Tier disk grupları kullanılmıyor. Mimari Cache Tier katmanının aradan kaldırdığında Cache disk ihtiyacı da doğal olarak bulunmuyor. Bu nedenle node üzerinde tüm diskleri artık NVMe olarak aynı tip ve kapasitede kullanıyoruz. Bir bakıma ESA ile Mixed Use disk kullandığımızda zaten tüm disklerimizde Cache Tier katmanında çalışıyormuş gibi oluyor. Zaten mimarinin yüksek sıkıştırma ve I/O sağlanmasının en büyük nedenlerinden biri de bu.
vSAN ESA mimarisinde artık Read Intensive diskler destekleniyor. Ama burada her Read Intensive diski kullanamıyoruz. Bunun için High Performance sınıfı gibi belli gereksinimler olması gerekiyor. Bunun dışına DWPD (Endurance değeri) en az 1 olmalı. Mixed Use NVMe göre maliyet avantajı olur mu derseniz liste fiyatlarına bakıldığında çok fark etmediğini göreceksiniz. Bu nedenle kendi oluşturmuş olduğum BOM listesinde ben Mixed-Use diskler kullandım. Burada disk tipi sizin cluster üzerindeki okuma/yazma ihtiyacınıza göre değişir. Eğer yüksek okuma ihtiyacınız olacaksa bu sefer Read Intensive NVMe kullanmak performans açısından fark yaratabilir.
- Type: NVMe TLC
- Performance Class:Class F (100000–349999) or higher
- Endurance Class:1 DWPD or higher
- Capacity:1.6TB or higher
- vSAN ESA ReadyNode Minimum # Device/Host:2
- vSAN Max ReadyNode Minimum # Device/Host:8
ESA mimarisinde aynı host üzerinde farklı kapasitelerde NVMe disk kullanabilir miyiz? Cevabı EVET
Ama benim tercihim yine simetrik disk kullanımı olur. Asimetrik vSAN cluster içerisinde farklı kapasite disklerin kullanılmasının güzel yanı ileride farklı bir ESA clsuter üzerinde farklı kapasite diskler boşa çıkarsa onları da farklı cluster node’lar üzerinde değerlendiriyor olabilirsiniz. (Ready Node Vendor ve sunucular eşlenik olmalı!)
vSAN ESA ile cluster seviyesindeki obje kapasitesi 9000’den 27.000 yükseldi. vSAN 8 U2 ile ESA cluster üzerinde node başına 500 VM’e kadar çıkabiliyorsunuz. OSA tarafında bu limit halen 200 VM olarak sınırlı.
ESA için örnek sizing ve BOM
Örnek olarak aşağıda üç farklı üretici için bir kit-list hazırladım.
DELL PowerEdge R750 BOM
HPE ProLiant DL380 Gen11 BOM
Lenovo ThinkSystem SR650 V3 BOM
Yukarıdaki konfigürasyona göre ESA Cluster üzerindeki toplam Compute ve Storage kaynağı aşağıdaki gibi olacak.
Yeni lisanslama paketlerinde sunucu başına en az 16 core kullanmak en mantıklı seçim oluyor. Core tabanlı abonelikten dolayı da artık soket başına core limitimiz ortadan kalkmış bulunuyor. (Soket başına 32 Core limitine artık takılmıyoruz) Soket başına core adetleri bu derece artmışken artık yüksek compute gereksinimi bulunan cluster üzerinde soket başına yüksek core kullanmak daha avantajlı oluyor.
Bir örnek vermek gerekirse 2 x 64 Core CPU maliyeti ile 4 x 32 Core CPU maliyeti hemen hemen aynı oluyor. Aynı 2 adet 32GB RDIMM ile 1 adet 64GB RDIMM maliyetinin birbirine yakın olması gibi.
Bu sayede beyaz alan, sunucu ve altyapı gereksinimlerinizi oldukça düşürmüş oluyorsunuz. Sunucu maliyetinde ne kadar bir kazanç olur derseniz %20 gibi bir kazancınız olabilir. Ama büyük bir Cloud Provider olarak hizmet veriyorsanız beyaz alan ve altyapıda oldukça kazançlı olabilirsiniz (%50 gibi)
Enerji ve BTU olarak ise çok bir farkı olmuyor bunun nedeni ise yüksek core CPU’ların çok fazla TDP değerine sahil olması.
Yeni çıkan 5. Nesil Intel Xeon Platinum 8592+ (350W) ya da 4. Nesil AMD EPYC 9654 (360W) gibi CPU modellerinde oldukça yüksek enerji gereksinimi bulunuyor. Eğer node’lar üzerinde AI Ready de olacaksa yaklaşık olarak GPU başına 350W ek gereksinim bile çıkacaktır. Bu durumda node başına 2 soket ve 2 GPU kullanıldığında yaklaşık 1.4kW’lık bir gereksinim olacak. Disk ve Fiber NIC’leri de hesaba katarsak node başına en az 1.8–2.4 kW PSU ihtiyacı ortaya çıkmış olacaktır. Bu sunucuyu BTU cinsinden soğutacağımızı da hesaba katarsak bu durumda beyaz alan, altyapı tarafındaki avantaj ile enerji, soğutma tarafındaki maliyet neredeyse eşitlenmiş olacak.
Hatta günümüzde bazı sunucu modellerinde Air Cooling yerine Liquid Cooling soğutma neredeyse bir gereklilik haline gelmiş durumda.
BT dünyası her zaman, birimleri birbirine bir şekilde eşitliyor değil mi? 😊
Lisanslama
Örnek BOM listemiz için lisanslamayı aşağıdaki gibi hesaplıyoruz.
Yeni VVF subscription lisanslamada (vSphere Foundation: Subscription capacity is the total number of cores × number of CPUs × number of ESXi hosts) formülünü kullanıyoruz.
Örnek HCI senaryosunda CPU başına 56 Core, sunucu başına 2 soket, Cluster başına 10 node olarak hesaplarsak.
56 x 2 x 10 = 1120 core subscription sonucuna ulaşıyoruz.
HCI için vSAN Enterprise Add-On TiB olarak (vSAN: Subscription capacity is the total number of TiBs x number of ESXi hosts in each vSAN cluster) formülünü kullanıyoruz.
Örnek HCI senaryosunda Node başına 8 adet 6.4TB NVMe disk ve Cluster başına 10 adet node olarak hesaplarsak.
51.2TB x 10 = 512 TB RAW ile 466 TiB subscription capacity sonucuna ulaşıyoruz.
NOT: Eğer VCF with vSAN Add-on subscription lisanslama kullanacaksanız her bir VCF Core Subscription capacity başına 1 TiB ücretsiz olarak sahip olmuş oluyorsunuz.
Örnek HCI senaryosunu eğer VCF göre uyarlarsak bu sefer hesaplamayı aşağıdaki gibi yapıyoruz.
VCF senaryosunda CPU başına 56 Core, sunucu başına 2 soket, Cluster başına 10 node olarak hesaplarsak.
56 x 2 x 10 = 1120 adet VCF core subscription sonucuna ulaşıyoruz.
51.2TB x 10 = 512 TB RAW ile 466 TiB RAW vSAN Enterprise Add-On subscription kullandığımızı farz edersek bu durumda ekstradan 654 TiB daha vSAN Enterprise Add-On subscription capacity kullanma opsiyonumuz oluyor. 466 TiB için kapasite lisanslamayı bedavaya getirmişken bonus olarak kalan 654 TiB kadar da ücretsiz büyüme opsiyonumuz oluyor. VCF Core lisanslamanın ucuz olmadığını da unutmayın 😊 ama Private Cloud ortamlar içinde gerçekten güzel bir opsiyon.
NOT: Eğer VCF senaryosunda her node üzerinde 24 adet 6.4TB NVMe disk kullansaydık (ya da Scale-Up olarak node başına +16 adet daha 6.4TB NVMe disk ekleseydik) bu durumda;
153.6TB x 10 = 1536 TB RAW ile 1397 TiB RAW vSAN Enterprise Add-On subscription ihtiyacımız olacaktı.
VCF için lisansladığımız 1120 Core subscription lisansı 1397 TiB vSAN RAW kapasiteden çıkartırsak bu durumda 10 Node VCF Cluster için ek olarak 277 TiB vSAN Enterprise Add-On subscription lisanslama yapmamız gerekecekti.
Referans: Counting Cores for vSphere Foundation and VMware Cloud Foundation and TiBs for vSAN Add-on (95927)
ESA Mimarisi Network Gereksinimleri
ALL-Flash OSA mimarisinde minimum 10G network yeterli oluyordu. Ama ben genellikle vSAN VMkernel için 25G network tercih ediyorum. 3/4/6 node gibi ufak bir OSA cluster yönetiyorsanız vSAN network için 10G fiber yeterli olabilir ama 6 node üstünde yüksek kapasite ihtiyacınız oluyorsa 25G kullanmak daha mantıklı oluyor.
10G/25G Switch ve SFP+/SFP28 modül maliyetleri birbirine çok yakın. Bu nedenle yeni bir cluster yatırımı yapıyorsanız mutlaka Dual Rate 10/25G Switch tercih etmek sizin açınızdan faydalı olabilir.
Ek olarak OSA mimarisinde bile bazı iş yükleri çok yüksek okuma/yazma talebinde bulunabiliyor. Bu tarz uygulamalarınız varsa ve bunları vSAN üzerinde kullanmak istiyorsanız 25G network sizi ileride rahat ettirecektir.
Gelelim ESA tarafına bununla ilgili VMware yorumu gayet açık ESA mimarisinde kullandığınız NVMe disk adeti ve kapasitesi yüksek ise 25G network bile riskli olacaktır. Eğer ufak bir ESA Cluster yönetiyorsanız en az 25G network kullanmanız gerekiyor. Cluster daha büyükse ya 25G+25G LACP/LAG yapacaksınız ya da 100G Active/Passive network kullanacaksınız.
Özellikle büyük ortamlarda yüksek adet ve 15TB NVMe disk kullanıyorsanız vSAN VMkernel networkün 100G olması oldukça önemli!
vSAN MAX kullanacaksanız zaten en az 50G network ihtiyacınız olacak dolayısıyla burada 100G switch tercih etmeniz daha uygun olabilir. Böylece LACP/LAG kullanmak zorunda da kalmazsınız.
vSAN MAX Mimarisi
vSAN MAX mimarisinin basit halini aslında vSAN 7 U1 de HCI Mesh olarak deneyimledik. vSAN 8 U2 versiyonuna kadar geliştirilerek sonunda tamamen olgunlaştı ve vSAN 8 U2 ile artık kullanılabilir hale geldi. HCI Mesh ile hali hazırda farklı vSAN kümeleri arasında kapasite paylaşımı yapabiliyorduk. vSAN MAX ile artık tamamen bir ayrıştırma yapabiliyoruz ve standard vSphere kümelerine de depolama kaynağı sağlayabiliyoruz. Bir bakıma VMware ortamlarını SAN Storage ve SAN Switch mimarisinden tamamen ayrıştırabiliyoruz. Ya da hybrid datastore’lar kullanarak HCI olmayan vSphere kümeleri için hem SAN hem de HCI kaynağı sağlayabiliyoruz. (SAN Datastore için duruma göre SAN HBA gerekebilir)
vSAN MAX yalnızca ESA mimarisi ile çalışıyor ve vSphere kümeleriniz için birinci depolama kaynağı olarak ölçeklendirilebiliyor.
Her bir vSAN Max Cluster 8.6 petabyte’a kadar ölçeklendirilebiliyor.
Kullanım Senaryoları
Altyapılar için maliyet optimizasyonu; Lisanslama maliyetlerini düşürmek için vSAN Max kaynakların doğru boyutlandırılmasına olanak sağlar.
Unified depolama; HCI için ideal olmayan sunucu kaynaklarını (Gen1 Blade ya da eski donanımlar gibi) vSAN Max ile kullanabilirsiniz. vSAN’dan yaralanmak istiyor ve kaynakları birbirinden bağımsız tutmak istiyorsanız o zaman uygun bir çözüm olarak kullanabilirsiniz. Veri merkezinde kolayca paylaşılabilen depolama platformu sağlayabilirsiniz.
Cloud Native uygulamalar için hızlı ölçeklendirme; vSAN Max Cloud Native uygulamalar için ideal bir depolama kaynağı olabilir.
vSAN Max kümesi için minimum gereksinim aşağıdaki gibidir.
vSAN Max için desteklenen/desteklenmeyen diğer vSphere ya da HCI cluster tipleri aşağıdaki gibidir.
vSAN Max Cluster ile istemci vSphere Cluster aynı CPU üreticisini mi kullanmalı?
HAYIR, vSAN Max cluster ile istemci vSphere cluster üzerinde farklı üreticilere ait işlemciler kullanılabilir. Örneğin AMD kullanan bir istemci vSphere kümesi, AMD kullanan bir vSAN Max kümesine bağlanabilir. (Ya da tam tersi) Önemli olan vSAN Max kümesinin ESA mimari ile uyumlu donanımları kullanmasıdır. (Disk, NVMe Controller, NIC gibi)
vSAN Max kümesine maksimum 128 host bağlanabilir.
vSAN Max Mimarisi Network Gereksinimleri
vSAN Max mimarisi gereği yüksek network kapasitesine ihtiyaç duymaktadır.
- Datacenter Class yedekli switch
- vSAN Max kümesi VMkernel için 100Gb uplink (istemci vSphere kümeleri için minimum 10Gb yeterlidir ama iş yüküne göre bunun en az 25Gb olması tavsiye edilir.
- vSphere Distributed Switch için NIOC (vSphere Network I/O Control) kullanılması tavsiye edilir.
- 10G ya da 25G network altyapıları için LACP kullanılabilir ama operasyonel karmaşıklıklarından ötürü Active/Passive bağlantı en uygun alternatiftir.
Örnek Switch konfigürasyonu
vSAN Max üzerinde tüm vSphere kümeleri için Storage Policy Based Management (SPBM) dahildir.
Client vSphere kümeleri için Cross-Cluster vMotion desteklenmektedir. vSAN Max kümesine bağlı istemci vSphere kümeleri arasında VM’ler taşınabilir.
vSAN Max için örnek sizing ve BOM
Örnek olarak aşağıda üç farklı üretici için bir kit-list hazırladım.
DELL PowerEdge R760 Server BOM
HPE ProLiant DL380 Gen11 BOM
Lenovo ThinkSystem SR650 V3 BOM
Yukarıdaki konfigürasyona göre vSAN Max Cluster üzerindeki toplam Compute ve Storage kaynağı aşağıdaki gibi olacak.
Lisanlama
Lisanslama vSAN ESA mimarisinde olduğu gibi aynı şekilde yapılmaktadır. vSAN Max Cluster’ın RAW kapasiteni TiB olarak hesaplayarak hem VCF hem de VVF için Add-On olarak alabilirsiniz.
Örnek hesaplama olarak
vSAN Advanced/Enterprise Add-On TiB olarak (vSAN: Subscription capacity is the total number of TiBs x number of ESXi hosts in each vSAN cluster) formülünü kullanıyoruz.
Örnek vSAN Max senaryosunda Node başına 16 adet 6.4TB NVMe disk ve Cluster başına 10 adet node olarak hesaplarsak.
102.4 TB x 10 = 1024TB RAW ile 932 TiB subscription capacity sonucuna ulaşıyoruz.
vSAN Max erişimi olacak vSphere Cluster’ın içinde kullanılan node’ların vSphere versiyonu minimum 8 ve üzeri olmalıdır. vSAN Max Datastore üzerine bağlanacak olan vSphere kümesi sunucular için ek bir lisanlama ihtiyacı gerekmemektedir. (Temel vSphere lisanslaması tabi ki olmalı!)
vSAN ESA ya da vSAN Max her işi yükü için uygun mudur?
Deneyimlerime göre HCI mimarisinde yapılan en büyük hatalardan bir her iş yükünün konumlandırılması eğer Microsoft SQL AAG, Hadoop, File Server gibi iş yüklerini HCI üzerinde kullanacaksanız bunun için çok iyi analiz ve planlama yapmalısınız yoksa attınız taş ürküttüğünüz kurbağaya değmez :)
Eğer HCI üzerinde Microsoft SQL AAG ve Hadoop gibi iş yüklerini kullanıyorsanız bu çok mantıklı değil. Çünkü bu tarz sistemlerin kendi içinde bir yedeklilik yapısı mevcut. İllaki ben bunu HCI üzerinde kullanacağım derseniz de bu tarz iş yükleri için RAID0 Storage Policy kullanmanızı tavsiye ederim. Böylece HCI üzerinde kapasiteyi daha efektif kullanabilirsiniz. Kendi içinde Node-to-Node yedeklik olan bir sistem için vSAN tarafında RAID1/5/6 storage policy kullanmanız çok doğru değil.
Özellikle SIEM gibi bir servis için arşiv diski olarak vSAN ESA disklerini kullanırsanız çok büyük bir hata yapmış olursunuz. Yine yüksek kapasiteli File Server kullanmak HCI ya da ESA gibi mimari üzerinde oldukça gereksiz.
Bu önerim sadece vSAN ya da diğer HCI üreticileri için değil Legacy All-NVMe SAN Storage kullanımı içinde geçerli.
Unstructured yapılar bana göre HCI ve NVMe SAN için tam bir ziyanlık onları bırakın bildikleri gibi çalışsın. Böylece sermayeyi kediye yüklememiş olursunuz.
Diğer bir tavsiyem network altyapınız büyük cluster kullanacaksanız mutlaka buna göre bir switch yatırımı yapın. Özellikle Telco sektöründe altyapı olarak HCI yönetecekseniz mutlaka minimum gereksinimin bir kademe üstünü kullanmalısınız.
vSAN ESA hangi iş yükleri için uygundur?
İlk olarak VDI bence HCI için biçilmiş kaftan.
İkinci olarak standart VM iş yükleri (örneğin Application Server, Web Server, Standalone DB Server gibi)
Üçüncü olarak şuan Telco 5G RAN için çok uygun bir çözüm (5G RAN için çok güzel rugged sunucular var bunlarla ilgili bir inceleme daha sonra mutlaka yapacağım)
Dördüncü olarak RO-BO gibi küçük şubeleri merkeze bağlayacaksanız hem merkez hem de şubeler için uygun bir çözüm.
Beşinci olarak Cloud Native altyapılar. VMware özelinde konuşursak Tanzu ve vSAN çok iyi bir ikili ve birbirleri ile oldukça entegre çalışıyorlar.
Altıncı olarak eğer bir servis sağlayıcıysanız Private Cloud ve Public Cloud hizmeti için oldukça ideal sadece doğru bir analiz ve planlama yapmanız gerekiyor.
Sona doğru değinmek istediğim bir başka eğer vSAN OSA üzerinde SSD disk kullanarak sunucu maliyetinin düşeceğini düşünüyorsanız yanılıyorsunuz. İster Mixed-Use ister Read-Intensive SSD kullanın NVMe diskler ile hemen hemen aynı maliyete geleceksiniz. Ama eğer ESA ve NVMe disk kullanırsanız burada oldukça kazançlı çıkacaksınız. Bu hem performans hem de maliyet açısından geçerli bir analiz. Bunu size aşağıda ispatlayacağım.
Aşağıda aynı sınıf SSD ve NVMe diskler liste maliyeti olarak hemen hemen aynı hatta NVMe bazı projelerde çok daha uyguna bile gelebilir. Ama performans olarak incelediğiniz arada çok ciddi bir fark olduğunu göreceksiniz.
Bu nedenle eğer yeni bir sunucu yatırımı yapacaksanız ve bunu vSAN ile yapmayı düşünüyorsanız size tavsiyem ESA mimarisini kullanmanız.
Sıkıştırma oranlarını da dikkate alırsanız efektif kapasite ile maliyeti oldukça düşürebilirsiniz. NVMe Back-End kullandığınız için burada bir performans sorunu yaşama olasılığınız oldukça düşük.
Aynı şey vSAN ESA ve Max tarafıdaki Mixed-Use ve Read-Intensive diskler içinde geçerli. Yine aşağıda örneğini görmüş olduğunuz disklerin maliyeti hemen hemen aynı ama dayanıklılık ve performans açısından değerlendirirsek arada önemsenecek kadar ufak farklılıklar var.
Son olarak diğer önemli bir nokta vSAN ESA mimarisi yeni çıkan Tri-Mode RAID denetleyicileri NVMe diskler için desteklememektedir. Burada sunucunun üzerinde mutlaka NVMe Back-end için PCIe NVMe Controller bulunmalıdır.
Görüşmek üzere.
