Birkaç haftadır "VMware vSAN - Getting Started and Advanced Topics" başlıklı HOL (Hands-on Lab) üzerinde çalışıyorum. Bu yazı, o serinin ilk modülünden çıkardığım notların ve gözlemlerin bir dökümü. Baştan söyleyeyim: burada anlatılanlar gerçek bir üretim ortamından değil, tamamen HOL ortamından geliyor. Kendi adıma bu ayrımı net tutmak önemliydi çünkü sahadaki dinamikler ile simüle bir ortam arasında her zaman fark var. Ama bu fark, HOL'u değersiz kılmıyor; tam tersine, kavramları karşılıklı test edip yanılma maliyeti sıfır olarak görmek için iyi bir zemin.
Şimdi Modül 1'de neyle karşılaştığımı aktarayım.
Ortam Hakkında Kısa Bir Not
Lab iki siteden oluşuyor: Site A ve Site B. İlk dört modül tamamen Site A üzerinde ilerliyor. Yönetim cluster'larına dokunulmaksızın sadece workload cluster'larında çalışıyoruz. Bu ayrım, özellikle VCF (VMware Cloud Foundation) bağlamında düşününce mantıklı: yönetim katmanına gereksiz yandan temas, gerçek ortamlarda da kaçınılan bir şey.
vSAN Nedir, Neden Var?
vSAN 2014'te hayatımıza girdi. Temel fikir şu: birden fazla ESXi host'unun yerel disklerini bir araya getirip tek, merkezi olarak yönetilen bir depolama havuzu oluşturmak. Ayrı bir storage donanımına gerek kalmıyor, en azından teoride.
Bunun anlamı şu: vSAN doğrudan vSphere hypervisor'ına gömülü. Yani bir storage OS yönetmiyorsunuz, ayrı bir SAN fabric kurmuyor değilsiniz. Compute ve storage, vSphere Client üzerinden tek elden yönetiliyor. TCO açısından geleneksel storage'a kıyasla yüzde elliye varan maliyet düşüşü iddiası var. Bunu elbette ortam büyüklüğüne, lisans yapısına ve mevcut altyapıya göre ayrı değerlendirmek gerek, ama kavramsal olarak mantığı oturuyor.
Data resilience tarafında erasure coding (silme kodlaması) kullanılıyor. RAID-5 ve RAID-6 burada saf disk mirroring'e göre daha verimli kapasite kullanımı sağlıyor.
vSAN 9'da Neler Değişti?
Bu HOL, vSAN 9 üzerine kurulu. vSAN 9'da öne çıkan başlıklara bakmak istedim çünkü önceki sürümlerle karşılaştırma yapmadan nelerin "yeni" olduğunu anlamak zor.
Gerçek hayatta şunu sormak gerekir: mevcut donanımınız ESA'yı destekliyor mu? ESA'nın VMware HCL gereksinimleri daha kısıtlayıcı. Bu, HOL'da görmediğiniz ama sahaya geçince sizi ilk duraksatan şeylerden biri olabilir.
VMware Live Recovery ile DR
vSAN cluster'ları artık VMware Live Recovery entegrasyonuyla korunabiliyor. RPO 1 dakikaya kadar inebiliyormuş. Bu özellik Modül 7'de işleniyor, burada sadece genel bir bilgi olarak geçiyor.
File Services ve Kubernetes
vSAN artık Kubernetes pod'ları için file-based persistent volume destekliyor. Aynı zamanda cluster başına 500 adet file share'e kadar çıkılabiliyor (vSAN 9 ile gelen bir iyileştirme). Bu konu Modül 6'da detaylandırılıyor.
Dying Disk Handling (DDH)
ESA'da disk latency değerlerini izleyip önceden belirlenen eşik aşılırsa otomatik müdahale edebiliyor. Cache drive arızalarını da proaktif olarak yakalıyor. Bu tür şeyler production ortamında görünmez çalışmasını beklediğiniz mekanizmalar; genelde var olduğunu ancak bir sorun çıktığında fark ediyorsunuz.
Global Deduplication (Sınırlı Yayın)
OSA'da deduplikasyon alanı disk grubuyla sınırlıydı. ESA ile bu kapsam tüm cluster'a genişliyor; tekrar eden bloklar cluster genelinde tek depolama ihtiyacına düşüyor. Veri azaltma oranları teorik olarak daha iyi. VCF 9.0 P01 ile TQR programı kapsamında geliyor.
Storage Policy Based Management (SPBM)
Bu modülün asıl konusu SPBM. Burada anlatmak istediğim şeyin "politika" kısmına takılmamak lazım; bu bir kurumsal yazılım sloganı değil, gerçekten işe yarayan bir mekanizma.
Temel mantık şu: VM'e "şu datastore'a yerleştir" demiyorsunuz. Onun yerine bir politika tanımlıyorsunuz, "bu VM en az 1 arıza tolere edebilmeli, RAID-5 ile" gibi. vSAN bu politikaya uyan yerleşimi kendisi buluyor. VM o politikaya uymakta zorlanırsa bunu da raporluyor: "Compliant" ya da "Non-compliant."
Bu yaklaşım, özellikle büyük ortamlarda her VM için ayrı ayrı storage konfigürasyonu yapmak yerine politika bazlı bir standart getiriyor. Dezavantajı şu olabilir: politika sayısı artınca bunları kim/ne zaman güncelleyecek, eski politikalara kim sahip çıkacak sorularına önceden cevap vermek gerekiyor.
Default Policy ve Optimal Datastore Default Policy
vSAN'ın bir "default storage policy"si var. Bu, herhangi bir politika atanmadan oluşturulan VM'lere otomatik atanıyor. Bunu silemiyorsunuz, ama kopyalayıp üzerine kendi politikanızı kurabiliyorsunuz.
vSAN 8.0 U1 ile gelen "Auto-Policy Management" özelliği ise bunu bir adım öteye taşıyor. Cluster'daki host sayısına ve konfigürasyonuna bakarak size özel bir "cluster-esa-01a - Optimal Datastore Default Policy - RAID5" gibi bir politika oluşturuyor. Bu otomatik politika RAID seviyesini cluster büyüklüğüne göre belirliyor. HOL'da bu özellik zaten etkin hale getirilmiş.
İlk Uygulama: VM Deploy Etmek
Bu bölümde mevcut bir VM'i (core-a) vSAN datastore'a klonluyoruz. Adımlar gayet açık:
- vSphere Client'tan VM'e sağ tık → Clone → Clone to Virtual Machine
- İsim:
clone-vm-a - Cluster:
cluster-esa-01a - Datastore:
vsan-esa-01a_Datastore - Storage Policy:
cluster-esa-01a - Optimal Datastore Default Policy - RAID 5
Klon işlemi tamamlanınca VM Summary ekranından politikanın atanmış ve "Compliant" olduğunu doğrulamak mümkün.
VM vSAN Üzerinde Nasıl Depolanıyor?
Bu kısım bence modülün en ilginç parçası. vSAN ESA'nın log-structured file system mimarisine bakınca şunu görüyorsunuz:
Yazma işlemi iki aşamada gerçekleşiyor:
Performance Leg (RAID-1): Gelen yazma önce RAID-1 olarak iki host arasında mirroring ile saklanıyor. Hızlı write acknowledgement için. Veri henüz kalıcı konumuna geçmedi.
Capacity Leg (RAID-5 veya RAID-6): Küçük yazmaların yeterince birikmesiyle vSAN bunları full-stripe write olarak RAID-5/6 formatında kalıcı kapasiteye indiriyor (destage). Bu, IO amplifikasyonunu azaltmak için tasarlanmış.
HOL'da bunu "Monitor > vSAN > Virtual Objects" üzerinden görebiliyorsunuz. VM'in hard diskini seçip "View Placement Details"e tıklayınca bileşenlerin hangi host üzerinde bulunduğunu görüyorsunuz.
Bu dağılımı görmek, "storage siyah bir kutu" algısını kırıyor. Veriyi görünür kılıyor.
Cluster'ı Büyütmek: Scale Out
RAID-5 ve RAID-6 için host sayısı gereksinimleri önemli:
| Mimari | RAID-5 Minimum | RAID-6 Minimum |
|---|---|---|
| OSA | 4 host | 6 host |
| ESA | 3 host (2+1 şeması, 1.5x kapasite) | 6 host |
ESA'da 6 veya daha fazla host varsa RAID-5 şeması 4+1'e geçiyor ve kapasite verimliliği artıyor (1.25x). Bu geçiş host sayısı değiştikten 24 saat sonra otomatik.
Yeni Host Eklemek
HOL'da cluster başlangıçta 4 host ile geliyor. İki ek host (esx-09a ve esx-10a) dışarıda bekliyor. Bu host'ları sürükle-bırak ile cluster'a ekliyorsunuz.
ESA'da artık "disk group" kavramı yok. Onun yerine "disk pool" var; host üzerindeki tüm uyumlu sürücüler havuza dahil oluyor. "vSAN Managed Disk Claim" etkinse eklenen host'un uyumlu sürücüleri otomatik olarak algılanıp vSAN datastore'a dahil ediliyor. HOL'da bu özellik etkin.
Skyline Health ve Otomatik Policy Önerisi
İki host eklendikten sonra Skyline Health'i açtığımızda bir uyarı görüyoruz: cluster 6 host'a çıktığı için Auto Policy Management yeni bir politika öneriyor.
"TROUBLESHOOT" dediğinizde mevcut politika (RAID-5) ile önerilen politika (RAID-6) yan yana görünüyor. Mantıklı: 6 host ile RAID-6 hem mümkün hem daha resilient.
"UPDATE CLUSTER DS POLICY" diyebilirsiniz; bu noktadan sonra oluşturulan VM'ler RAID-6 politikası alıyor. Mevcut VM'leri de Policies and Profiles > REAPPLY ile güncelleyebiliyorsunuz. HOL'da bu adım zaman kazanmak için atlanıyor.
İleri Düzey Policy: Compression'ı Kapatmak
ESA'da sıkıştırma (compression) artık storage policy seviyesinde yönetiliyor. Varsayılan olarak açık, çünkü replica trafiği de compressed olarak taşınıyor. Ama bazı durumlarda kapatmak gerekebilir: kendi sıkıştırmasını yapan uygulamalar (veritabanları gibi) için ekstra sıkıştırma hem CPU israfı hem de veri azaltma oranlarını yanıltabilir.
Bu bölümde şunu yapıyoruz:
- Mevcut
vSAN ESA Default Policy - RAID5politikasını klonla. - Yeni politikaya isim ver:
vSAN ESA No Compression - RAID 5 - Storage rules > Storage tier: "No space efficiency" seç (sıkıştırma bu şekilde devre dışı kalıyor)
- Uyumluluk kontrolü:
vsan-esa-01a_Datastorecompatible göründüğünü doğrula - Finish
Ardından mevcut clone-vm-a VM'ine bu yeni politikayı atıyoruz: VM > Configure > Policies > EDIT VM STORAGE POLICIES. Dropdown'dan yeni politikayı seçince bir süre sonra VM "Compliant" statüsüne geçiyor.
Reserved Capacity
vSAN'ın tüm kapasitesi varsayılan olarak workload'lara açık. Ama cluster'da bir rebuild veya rebalancing operasyonu başladığında o an doluysa ne olacak? İşte "Reserved Capacity" tam buna yönelik.
İki tür rezervasyon var:
Operations Reserve: Cluster içi operasyonlar (policy reconfig, vb.) için ayrılan alan.
Host Rebuild Reserve: Bir host arızalandığında veri yeniden inşası için ayrılan alan. Bu rezervasyon, cluster'daki en büyük host'un kapasitesine göre belirleniyor. Minimum 4 host gereksinimi var.
HOL'da bu özelliği etkinleştirme ekranını görüyoruz: uyarı eşikleri %70, hata eşikleri %90 olarak ayarlanmış. Sonra iptal ediliyor çünkü iç içe geçmiş (nested) lab ortamında gerçek anlamda reserve etmek için yeterli kapasite yok.
Bu noktada şunu düşünmeden geçemedim: gerçek ortamlarda bu rezervasyonu kurmak ne zaman anlam taşıyor? Disk kapasitesi kısıtlıysa reserve etmek kısa vadede sizi zorlar. Ama o buffer olmadan bir host çöktüğünde rebuild yetersiz kapasiteye çarpar, bu daha büyük bir risk. Denge kurmak gerekiyor.
Bir kısıtlama notu: Stretched cluster, fault domain kullanılan cluster'lar, ROBO cluster ve 4'ten az host içeren cluster'larda bu özellik desteklenmiyor.
Scale In: Node Çıkarmak
Scale out kadar konuşulmayan ama production'da bir o kadar önemli olan şey: cluster'ı küçültmek. vSAN cluster'ı minimum 3 host ile çalışır. Host çıkarmadan önce şunlara bakmak gerekiyor:
- Kalan compute ve storage kapasitesi yeterli mi?
- Mevcut VM storage policy'leri compliant kalmaya devam edecek mi?
Data Migration Pre-Check
Bu araç, "şu host'u çıkarsam ne etkilenir?" sorusunun cevabını veriyor. HOL'da esx-10a seçilip "Full data migration" tercih edildiğinde hiçbir nesnenin etkilenmeyeceği görülüyor. Ardından direkt "ENTER MAINTENANCE MODE" adımına geçilebiliyor.
Maintenance Mode ve Host Kaldırma
Maintenance mode'a alınan host sonra drag & drop ile cluster dışına (datacenter seviyesine) taşınıyor. Aynı adımlar esx-09a için de tekrarlanıyor. Cluster böylece 4'e iniyor.
Genel Değerlendirme
HOL formatı bu konu için iyi çalışıyor. Her adım ekran yönlendirmesiyle geldiği için "nerede tıklamalıyım" sancısı yaşamıyorsunuz; odağınız tamamen mantığı anlamaya kayıyor. Ama şunu da söylemeliyim: HOL sizi hiçbir şeyin bozulmadığı, kapasitesinin üstünde çalışmayan bir ortamda karşılıyor. Gerçek sahada bu adımların her birinin yanına "peki bunu değişken bir ortamda nasıl yapacaksın, işler ters giderse ne olur" soruları ekleniyor.
Modülün beni en çok düşündüren kısmı RAID şeması geçişleri ve bunların kapasite verimliliğine yansımaları oldu. ESA'nın adaptif RAID-5'i (3-5 host için 1.5x, 6+ host için 1.25x) storage planlaması açısından gerçekten önemli bir ayrıntı. Host ekledikten 24 saat sonra otomatik geçiş yapması şık, ama o 24 saatte neler olabileceğini de takip etmek gerekir.
Bir sonraki haftada Modül 2'ye; sağlık izleme, kapasite takibi ve performans raporlaması konularına geçeceğim.
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)