Dört haftadır Site A üzerinde çalışıyordum: SPBM, izleme, şifreleme, stretched cluster. Modül 5 ile birlikte ilk kez Site B'ye geçiyorum ve konu da farklı bir yöne kırılıyor: vSAN Storage Cluster.
Bu modül, önceki dördünden kavramsal olarak ayrı bir yerde duruyor. Şimdiye kadar gördüğümüz her şey HCI (Hyper-Converged Infrastructure) mantığıyla çalışıyordu; yani her host hem compute hem storage sağlıyordu. Storage Cluster ise bu ikisini birbirinden ayırıyor. Bunun neden var olduğunu ve HOL'da nasıl göründüğünü aktarayım.
vSAN Storage Cluster Nedir?
vSAN Storage Cluster, eski adıyla vSAN Max, vSphere cluster'ları için dağıtık, scale-out bir depolama sistemi. vSAN ESA tarafından güç alıyor, yani ESA'nın sunduğu tüm yeteneklere sahip, ama sadece depolama sağlayan bir cluster olarak çalışıyor.
Buradaki kritik ayrım şu: Normal vSAN'da (HCI modelinde) bir host hem VM'leri çalıştırır hem de kendi diskini vSAN datastore'a katkı verir. Storage Cluster modelinde ise bazı cluster'lar sadece depolama sağlıyor (compute çalıştırmıyor), bazı cluster'lar ise sadece compute sağlayıp bu depolamayı uzaktan tüketiyor.
Bu, disaggregation (ayrıştırma) dediğimiz bir mimari yaklaşım. Compute ve storage kaynaklarını ayrı ayrı ölçeklendirebiliyorsunuz; storage ihtiyacınız artınca sadece storage cluster'ı büyütüyorsunuz, compute cluster'a dokunmadan.
Cross-cluster iletişim için vSAN'ın kendi native protokolü ve data path'i kullanılıyor. Bu, yönetim deneyimini koruyor ve dağıtık bir depolama sistemi için mümkün olan en yüksek performans ve esnekliği sağlıyor iddiasında.
HOL Ortamındaki İki Cluster
Site B'de iki cluster önceden hazır geliyor:
-
vsan-storage-cluster-01b: Depolama sağlayan cluster. -
vsan-client-cluster-01b: Bu depolamayı tüketen compute cluster.
Bu ayrımı doğrulamak için ilk yapılan şey, her iki cluster'ın Configure sekmesinden vSAN > Services altındaki "Cluster type" alanına bakmak.
vsan-storage-cluster-01b için Cluster type "vSAN Storage Cluster" olarak görünüyor; bu cluster diğer compute cluster'lara depolama sağlamaya adanmış.
vsan-client-cluster-01b için ise Cluster type "vSAN Compute Cluster" olarak görünüyor; bu cluster diğer vSAN storage cluster'ların depolamasını tüketmeye adanmış.
Bu iki etiketin ayrı ayrı görünmesi bana önemli geldi. Sistem, bir cluster'ın rolünü GUI seviyesinde açıkça belirtiyor; "bu cluster ne için var" sorusuna dolaşmadan cevap veriyor.
Mount Edilmiş Datastore'u Görmek
Compute cluster'ın, storage cluster'daki datastore'u gerçekten kullandığını doğrulamak için:
vsan-client-cluster-01b > Configure > vSAN > Datastore Management
Burada vsan_SC_Datastore adlı datastore'un, vsan-storage-cluster-01b cluster'ında bulunduğu ve compute cluster tarafından mount edildiği görülüyor.
Bu ekran, HCI modelindeki "VM burada, disk de burada" basitliğinden farklı bir gerçekliği gösteriyor: VM'in compute'u bir cluster'da, verinin fiziksel olarak bulunduğu yer başka bir cluster'da.
Ağ Trafiği Ayrımı: Front-End ve Back-End
Bu modülün bence en önemli teknik detayı burada. VCF 9.0 ile vSAN Storage Cluster'lara yeni bir yapılandırma seçeneği geldi: depolama performansını artıran, ağ trafiği izolasyonunu ve güvenliği iyileştiren bir ayrım.
İki tür trafik tanımlanıyor:
Guest VM I/O (front-end trafik): Guest VM'e giden/gelen, vSAN datastore'a erişen trafik.
vSAN I/O (back-end trafik): vSAN datastore'daki node'lar arasında akan trafik; yani vSAN'ın kendi iç senkronizasyon ve replikasyon trafiği.
VCF 9.0 için vSAN, bu iki trafiği ayrı VMkernel portları üzerinden ayırma yeteneği getiriyor. Bu ayrım, Modül 2'de gördüğümüz cluster seviyesindeki front-end/back-end trafik ayrımıyla kavramsal olarak aynı fikri paylaşıyor, ama burada fiziksel port seviyesinde uygulanıyor.
Storage Cluster Node'unun VMkernel Arayüzleri
esx-05b.site-b.vcf.lab üzerinde iki vSAN'a özgü VMkernel portu inceleniyor:
vmk2: vSAN servisi için etkin. Storage Cluster bağlamında bu port, storage cluster node'ları arasındaki vSAN I/O'dan (back-end trafik) sorumlu.
vmk3: vSAN Storage Cluster Client servisi için etkin. Bu port, storage cluster node'larının, client cluster'daki vSAN VMkernel portlarıyla iletişim kurup Guest VM I/O'yu (front-end trafik) taşımasından sorumlu.
Compute Cluster Node'unun VMkernel Arayüzü
esx-09b.site-b.vcf.lab üzerinde ise tek bir vSAN'a özgü VMkernel portu var:
vmk2: vSAN servisi için etkin. Compute Cluster bağlamında bu port, storage cluster node'larındaki vSAN Storage Cluster Client portlarıyla iletişim kurup Guest VM I/O'yu (front-end trafik) taşıyor.
Burada dikkatimi çeken şey, storage cluster node'unda iki ayrı port varken (biri back-end, biri front-end için), compute cluster node'unda sadece bir port olması. Mantıklı: compute cluster kendi verisini tutmuyor, sadece storage cluster'a Guest VM I/O gönderiyor; kendi içinde bir back-end senkronizasyon trafiğine ihtiyacı yok.
Bu ayrım, gerçek bir ortamda ağ tasarımı yaparken önemli bir referans noktası. Storage cluster tarafında iki ayrı VMkernel portu (ve muhtemelen iki ayrı fiziksel NIC veya VLAN) planlamak, front-end ve back-end trafiğinin birbirini etkilememesi için gerekli.
Compute Cluster'a VM Deploy Etmek
Bu bölümde core-b VM'i klonlanarak vsan-client-cluster-01b compute cluster'ına deploy ediliyor. Manuel'de vurgulanan önemli nokta şu: bu süreç, normal bir vSAN HCI cluster'ına VM deploy etmekle aynı. Tek fark, compute resource olarak compute cluster'ı, datastore olarak da storage cluster'daki vSAN datastore'unu seçmeniz.
Adımlar
-
core-büzerine sağ tık → Clone → Clone to Virtual Machine - İsim:
clone-vm-b - Compute resource:
vsan-client-cluster-01b - VM Storage Policy:
cluster-esa-01b - Optimal Datastore Default Policy - RAID1 - Datastore:
vsan_SC_Datastore
Bu akış, Modül 1'de core-a VM'ini klonlarken gördüğümüz sürecin neredeyse birebir aynısı. Aradaki fark sadece hangi cluster'ın compute, hangi datastore'un hedef olarak seçildiği; SPBM mekanizması, wizard akışı, hepsi tanıdık.
Sonucu Doğrulamak
Klon tamamlandıktan sonra clone-vm-b > Summary > Related Objects bölümünde şunlar görülüyor:
- VM,
vsan-client-cluster-01bcompute cluster'ında bulunuyor. - VM'in verisi ise
vsan_SC_Datastoredatastore'unda duruyor.
Bu iki bilginin ayrı ayrı, ayrı nesneler olarak görünmesi, disaggregated mimarinin özünü gösteriyor: VM'in "nerede çalıştığı" ile verisinin "nerede durduğu" artık aynı host'a bağlı değil.
Genel Değerlendirme
Bu modül kısa ama kavramsal olarak önceki dördünden farklı bir zihniyet gerektiriyor. HCI modelinde "compute ve storage aynı host'ta" varsayımı o kadar yerleşik ki, bunu ayırmanın ne gibi bir esneklik getirdiğini görmek için ayrı bir cluster çiftini incelemek gerekiyordu.
Benim için en dikkat çekici iki nokta şunlardı:
Birincisi, front-end/back-end trafik ayrımının VMkernel port seviyesinde somutlaşması. Modül 2'de bu ayrımı sadece bir monitoring sekmesi (Backend vs VM sekmeleri) olarak görmüştüm; burada aynı ayrımın fiziksel ağ tasarımına nasıl yansıdığını görmek, kavramı daha somut hale getirdi. Storage cluster node'unda iki ayrı port, compute cluster node'unda tek port olması, hangi tarafın hangi trafiği taşıdığını networking seviyesinde de ayırt edilebilir kılıyor.
İkincisi, VM deploy etme sürecinin HCI'dakiyle neredeyse aynı olması. Bu bana şunu gösterdi: vSAN Storage Cluster, kullanıcı deneyimi açısından büyük bir öğrenme eğrisi getirmiyor; asıl fark mimari seviyede, admin'in cluster'ları nasıl tasarladığında. Bir VM deploy eden birisi için "bu storage cluster'dan mı geliyor, yoksa HCI'dan mı" ayrımı büyük ölçüde görünmez kalıyor, ki bu da tasarımın amaçladığı şey.
Gerçek sahada bu mimariyi ne zaman tercih edeceğim sorusunu düşününce, akla gelen ilk senaryo şu: storage ve compute ihtiyaçlarının farklı oranlarda büyüdüğü ortamlar. Compute-yoğun ama storage-hafif workload'lar için (ya da tam tersi) ayrı ayrı ölçeklendirme yapabilmek, her host'a hem compute hem storage eklemek zorunda kalmaktan daha esnek bir yaklaşım olabilir. Ama bunun getirdiği ek ağ tasarımı karmaşıklığını (front-end/back-end ayrımı, ek VMkernel portları) da hesaba katmak gerekiyor.
Bir sonraki hafta Modül 6'ya geçiyorum.
Bu seri VMware HOL ortamı (HOL-2634-01-VCF-L) üzerinden yürütülmektedir. Buradaki gözlemler lab bağlamında değerlendirilmeli, production ortamı kararları için mutlaka resmi VMware dokümantasyonu ve deneyimli mühendisler referans alınmalıdır.
Top comments (0)