HOL-2701-01 serisinin son yazısı. İlk modülde arayüz ve VCF Operations'ı, ikinci modülde VCF Automation'ı gezdim. Bu yazıda vSphere tarafında Memory Tiering, vSAN tarafında Auto RAID, Global Deduplication ve clustered uygulamalar için Hot Extend'i ele alıyoruz.
Her zamanki gibi bunları sahadan değil, HOL ortamından yazıyorum. Production'da Memory Tiering ya da vSAN ESA işletmedim. Lab'ı "bunu gerçek bir ortamda açmadan önce ne sorardım" gözüyle okumaya çalıştım. Yanlış anladığım yer olursa yorumlarda düzeltirseniz sevinirim.
Memory Tiering
Kılavuzun anlattığı problem
Kılavuzun bu bölümü, bir okuma kısmıyla başlıyor ve çıkış noktası şu: pratikte bellek kullanımı genelde CPU kullanımından yüksek oluyor. Bellek neredeyse dolarken CPU düşük kalıyor ve o CPU'yu kullanamıyorsunuz, çünkü ona bağlı bellek yok. Host ya da koca bir küme memory-bound hale geliyor. Kılavuza göre bunun sonucu verimsiz kaynak kullanımı, güç ve soğutma israfı ve bellek maliyetinin TCO içindeki büyük payı yüzünden artan maliyet.
Çözüm olarak ESX host'una takılı yerel NVMe cihazlarını "tiered memory" olarak kullanıp belleği iki katmana ayırıyorlar:
- Tier 0: DRAM.
- Tier 1: NVMe. Yalnızca host üzerinde çalışan VM'ler için kullanılıyor.
Mantık sayfaların ne kadar kullanıldığına göre sınıflandırılması:
- Hot: Zamanın %50'sinden fazlasında aktif.
- Warm: Zamanın %50'sinden azında kullanılıyor.
- Cold: Zamanın %20'sinden azında kullanılıyor.
- Very cold: Neredeyse hiç kullanılmayan sayfalar. Kılavuz bunu aşırı provisioning'e bağlıyor.
Cold ve very cold sayfalar NVMe'ye iniyor, DRAM boşalıyor. Böylece aynı CPU kapasitesiyle daha fazla VM çalıştırabiliyorsunuz.
Kılavuzun listelediği hedefler arasında şunlar var: uygulamalara şeffaf, DRAM ve NVMe üzerinde tek bir tüketim modeli, ortak bir yönetim modeli ve VM bazında Memory Tiering'i kapatabilme. HA, DRS, vMotion, Fast Suspend/Resume ve RAID desteği de kılavuzda açıkça sayılmış.
VCF Operations'ta "ya eklesem" simülasyonu
Bu bölümün en pratik cümlesi bence şu: VCF Operations, NVMe eklemeden önce bunu simüle etmenizi sağlıyor. Mevcut CPU ve bellek kullanım örüntülerine bakarak potansiyel maliyet tasarrufunu, olası VM sayısı artışını, projeksiyonla bellek durumunu ve CPU kullanımındaki beklenen iyileşmeyi gösteriyor. Maliyet tahminleri VCF Operations'taki cost driver'lara dayanıyor ve güncel piyasa fiyatlarına göre güncellenebiliyor. Aktif bellek kullanımı %50'nin altında ve boş CPU kapasitesi %50'nin üstünde olan kümeler güçlü aday olarak işaretleniyor.
Donanım satın almadan önce "bu bana ne kazandırır" sorusuna veri ile cevap verebilmek hoşuma gitti. Bir bütçe konuşmasında bu tür bir çıktı iş görür. Ama bu simülasyonun ekranını lab'da görmedik, sadece okuma kısmında anlatılıyor. Tahminin ne kadar doğru çıktığı, ya da hangi metriklerle ne kadar süreyle toplanan veriye dayandığı da bilgi olarak verilmiyor.
Lab'da gördüğüm: ayarlar
Lab'da Memory Tiering açılmıyor, sadece ayarlar inceleniyor. Kılavuz, ayrıntılı kurulum için HOL-2703-01-VCF-L adlı ayrı lab'ı öneriyor. Orada tiering'in gerçekten yapılandırıldığı ve vCenter ile VCF Operations'taki yeni gözlemlenebilirlik raporlarının ve dashboard'ların gezildiği anlatılıyor.
Yol şöyle:
- vCenter'da (
vc-wld01-a) Hosts and Clusters >cluster-wld01-01a> Configure. - Soldaki menüde Desired State > Configuration.
- Önceden bir draft varsa Discard Draft, sonra Draft sekmesinde CREATE DRAFT.
- esx kategorisi altında memtier > nvme ayarı > CONFIGURE SETTINGS.
Memory Tiering ayarı küme genelinde Desired State yapılandırmasının bir parçası. Yani ayarı tek tek host'larda yapmıyorsunuz, draft üzerinden küme için tanımlıyorsunuz.
Ayar ekranında şunlar var:
- Enabled: TRUE yapınca Memory Tiering açılıyor. Varsayılan olarak kapalı.
- device: Her host için birincil NVMe cihazı.
- mirror_device: İkincil ya da mirror NVMe cihazı. Birincil NVMe'de sorun olursa yedeklilik için.
- encryption: NVMe'de tutulan bellek sayfalarının şifrelenmesi.
- Yüzde değeri: Memory Tiering için kullanılacak NVMe miktarı, fiziksel belleğin yüzdesi olarak. Varsayılan 100, yani fiziksel belleğin %100'ü.
Sonra CANCEL diyorsunuz, hiçbir şey kaydedilmiyor.
Gerçek ortamda soracağım sorular
Kılavuzun anlattığı faydalar (daha fazla VM yoğunluğu, daha iyi CPU kullanımı, düşen TCO) mantıklı geliyor. Ama lab hiçbirini ölçmüyor. Bende kalan sorular şunlar:
- Cold sayfaya erişim gerekirse ne olur? NVMe, DRAM'den yavaş. Kılavuz "şeffaf" diyor, ama gecikmeye duyarlı iş yüklerinde bunun etkisini bilmek isterim. VM bazında kapatabilmek tam bu yüzden değerli bir seçenek olabilir.
- Hangi NVMe cihazları destekleniyor? Dayanıklılık (yazma ömrü) ve performans gereksinimleri nelerdir, kılavuz değinmiyor.
- Mirror cihaz zorunlu mu, tavsiye mi? Birincil cihaz arızalanırsa o host'taki VM'lere ne olacağını lab'da denemedik.
- %100 varsayılanı ne anlama geliyor? Fiziksel belleğin yüzde yüzü kadar NVMe kullanmak, toplam belleği iki katına çıkarmak gibi okunabilir, ama kılavuz bunu açıkça yazmıyor. Kendi yorumum, o yüzden emin değilim.
vSAN
Bu modül üç özellik üzerine kurulu: Auto RAID, Global Deduplication ve clustered uygulamalar için Hot Extend.
Auto RAID
vSAN ESA'da Auto-RAID storage policy'si, site disaster tolerance ve failures to tolerate değerlerini küme yapılandırmasına göre kendisi belirliyor. Yeni storage policy oluştururken bu varsayılan ayar. Kılavuza göre:
- 3-5 host'luk kümelerde: RAID-5 erasure coding, 1,5x RAID overhead.
- 6 ve üzeri host'ta: RAID-6 erasure coding, aynı 1,5x overhead.
Küme yapılandırması değişirse (örneğin host eklerseniz) nesneler otomatik olarak yeni optimal ayara göre yeniden yapılandırılıyor. Kılavuz bunun performansı etkilemeden daha iyi veri koruması sağladığını söylüyor.
Bu bölüm tamamen okuma. Lab'da Auto-RAID policy'si oluşturmuyoruz. İşletme gözüyle sorum şu: host sayısı 5'ten 6'ya çıkınca RAID-5'ten RAID-6'ya geçiş sırasında yeniden yapılandırma (resync) trafiği ne kadar olur, bunu bakım penceresine nasıl yerleştiririm? Lab bunu göstermiyor. Auto-RAID ayrıca bir sonraki bölümdeki effective capacity görünümünü de açıyor.
Global Deduplication ve Effective Capacity Reporting
vSAN ESA artık küme seviyesinde global deduplication yapabiliyor. Kılavuza göre sıkıştırma 9.1'de varsayılan olarak açık. Global dedup ise ESA kümesini yapılandırdıktan sonra açılabiliyor ve vSAN nesne seviyesinde uygulanıyor. Çalışma biçimi: kümedeki tekrarlanan veri bloklarını kaldırıp yerine tek bir örneğe işaret eden pointer'lar koyuyor. Modül girişinde bunun küme geneli ve post-processing bir ayar olduğu, şifreleme desteğiyle geldiği ve dedup etkinliğini düşürmeden data-at-rest güvenliği sağladığı belirtiliyor.
vSAN serisinde (Modül 3) şifrelemeye bakmıştık. Dedup ile şifrelemenin birlikte çalışması bu yüzden dikkatimi çekti, çünkü bunlar genelde birbirini köreltir. Kılavuz bunun mekanizmasını anlatmıyor, sadece "etkinliği düşürmeden" diyor.
Dedup'un getirdiği kısıtlar
Kılavuz bunları açıkça sayıyor ve bence bu bölümün en değerli kısmı bu:
- Thick-provisioned VM'ler dedup edilmiyor. Global dedup açıldıktan sonra kümedeki thick VM'ler dedup dışı kalıyor. Thin'den thick'e çevrilen bir VM için de dedup duruyor.
- Stretched cluster'a dönüşüm yok. Standart bir vSAN kümesinde global dedup açıldıysa, o küme sonradan stretched cluster'a çevrilemiyor.
İkincisini tasarım aşamasında bilmezseniz ileride pahalıya patlayabilir: "şimdilik standart kuralım, sonra stretched'a geçeriz" planı varsa dedup'u açmadan önce iki kere düşünmek gerekir.
Lab'da gördüğüm
- vCenter'da
cluster-wld01-01a> Configure > vSAN > Services. Lab'da deduplication zaten açık görünüyor. Kapalı olsaydı EDIT ile açabilirdik, ama gerek yok.
Aynı kümede Monitor > vSAN > Capacity. Space Efficiency bölümünde kullanılan kapasite 83,82 GB, data reduction tasarrufu 57,55 GB görünüyor. Kılavuz sizin ortamınızda rakamların biraz farklı çıkabileceğini söylüyor.
Data reduction ratio altında SHOW DETAILS diyince dedup oranı ve sıkıştırma oranı ayrı ayrı görünüyor. 9.1'de sıkıştırma varsayılan açık olduğu için ikisini birbirinden ayırabilmek güzel.
Burada dürüst olmam gereken şey şu: lab'ın küçük bir veri setiyle çalıştığını rakamlardan görüyorsunuz (83 GB civarı). Bu oranlar production'daki gerçek veri için bir fikir vermez. Dedup'un gerçek faydası iş yükünün tipine (çok sayıda aynı OS imajı mı, veritabanı mı) bağlı ve bunu lab'da test etme şansımız yok. Ayrıca post-processing olduğunu düşününce, dedup'un ne zaman ve ne kadar sürede etki edeceğini, arka planda ne kadar kaynak tükettiğini de bilmek isterim.
Clustered uygulamalar için Hot Extend: Oracle RAC ve WSFC
VCF 9.1, clustered uygulamaların disklerini, o uygulamayı barındıran VM'leri kapatmadan genişletmenize izin veriyor. Kılavuza göre hem Oracle RAC multi-writer hem de Windows Server Failover Cluster (WSFC)'taki shared VMDK destekleniyor. Multi-writer attribute'unu kaldırmanız da gerekmiyor.
Lab'da bunun demosu, Oracle RAC yerine OCFS2 (Oracle Cluster File System v2) kullanan üç VM üzerinden yapılıyor. Yani Oracle RAC'in kendisini değil, aynı multi-writer VMDK'yı paylaşan bir OCFS2 kümesini görüyoruz. WSFC tarafı lab'da hiç gösterilmiyor, sadece kılavuz "destekleniyor" diyor.
Adımlar:
1. Multi-writer VMDK'yı görmek. ub1 VM'ine sağ tık > Edit Settings, Hard disk 2'yi genişlet, Sharing altında Multi-writer seçili görünüyor. ub2 ve ub3 için de aynı VMDK'ya bağlı olduğunu (Disk File yolu aynı) doğrulayabiliyorsunuz.
2. OCFS2 kümesine bakmak. ub1'in web console'unda sırasıyla:
sudo o2cb list-clusters
sudo o2cb cluster-status ocfs2
sudo o2cb list-nodes ocfs2
Birincisi ocfs2 adında tek bir küme olduğunu, ikincisi kümenin online olduğunu, üçüncüsü de üç node'u (ub1, ub2, ub3) gösteriyor.
3. Volume'u görmek.
sudo df -h /dev/sdb
ls /mnt/ocfs2
cat /mnt/ocfs2/test_file.txt
/dev/sdb cihazı /mnt/ocfs2 altına mount edilmiş ve boyutu 25 GB. Klasörde test_file.txt var ve içinde dosyanın ub1 üzerinde oluşturulduğu yazıyor.
4. VMDK'yı büyütmek. vCenter'da ub1'in Edit Settings'inde Hard disk 2'yi 25 GB'dan 30 GB'a çıkarıp OK diyorsunuz. VM'ler açık, multi-writer attribute'u olduğu gibi duruyor.
5. Volume'u genişletmek. ub2'nin console'unda lab'ın hazırladığı bir script var:
./expand_volume.sh
Kılavuz bu script'in tunefs.ocfs2 komutuyla /dev/sdb volume'unu genişlettiğini söylüyor. Çıktıda volume'un önce 25 GB, script'ten sonra 30 GB olduğu görünüyor.
6. Doğrulamak. ub2'de test_file.txt aynı dosya olarak açılıyor. Sonra ub1'in console'unda sudo df -h /dev/sdb çalıştırınca yeni boyutun (30 GB) orada da göründüğünü teyit ediyorsunuz. ub3 için de aynısı yapılabilir. Ben ikinci kez çalıştırdığım için Confirming Current Volume Size da 30GB görünüyor.
Bu, sistem tarafı için en somut kazanım gibi duruyor. Kılavuz bunu 9.1'in yeni bir yeteneği olarak sunuyor, yani öncesinde bu işi kesintisiz yapmak mümkün değildi ya da desteklenmiyordu, ama önceki sürümlerde tam olarak ne olduğunu kılavuz anlatmıyor. Burada üç VM çalışırken disk büyüyor. Ama burada iki şeye dikkat edilmeli. Birincisi, volume genişletme adımını bir script yapıyor ve kılavuz script'in içini göstermiyor. Yani tunefs.ocfs2 ile ne yapıldığını ve gerçek bir Oracle RAC kurulumunda (ASM gibi) bu adımların nasıl olacağını lab'dan çıkaramıyorum. İkincisi, VMDK'yı vSphere tarafında büyütmek bu özelliğin kolay kısmı, asıl iş guest OS tarafında yürüyor.
Genel olarak neler dikkatimi çekti
Birkaç şey kafamda kaldı.
İlk olarak, bu modüllerin ikisi de "donanım ya da yazılım maliyetini düşür" mesajı veriyor. Memory Tiering DRAM maliyetini, global dedup disk kapasitesini hedefliyor. Mantıklı. Ama ikisinin de "faydası" iş yükünüze bağlı ve lab'ın küçük, temiz ortamında bu faydayı ölçemiyoruz.
İkincisi, kısıtlar kılavuzda açıkça yazılıyor ve asıl okunması gereken yer orası. Thick VM'lerin dedup dışı kalması, global dedup sonrası stretched cluster'a geçilememesi, Memory Tiering'in varsayılan kapalı olması. Bunları okumadan "9.1'e geçince hepsini açarım" demek yanlış olur.
Üçüncüsü, bu iki modül de aslında tanıtım. Memory Tiering'i açmadık, Auto-RAID policy'si oluşturmadık, dedup'u kendimiz açmadık (zaten açık geldi). Gerçekten uygulamalı olan tek kısım Hot Extend'di. Kılavuz Memory Tiering için ayrı bir lab'a (HOL-2703-01-VCF-L) yönlendiriyor, bu da konunun bir tur kadarıyla anlaşılmayacağını kabul ediyor gibi.
Son olarak, her zamanki gibi: bu yazıdaki her şey lab ortamında, küçük ve temiz bir kurulumda gördüklerime dayanıyor. Production'da ölçek, iş yükü ve alışkanlıklar işi değiştirir. Memory Tiering, vSAN ESA ya da clustered uygulama işletenler "şu aslında böyle olmuyor" derse öğrenmek isterim.
Seri hakkında
HOL-2701-01 ile üç yazıda HOL'ın ilk laboratuvarını bitirmiş oldum: arayüz ve VCF Operations, VCF Automation, sonra Memory Tiering ve vSAN. Genel izlenimim, 9.1'in "her şeyi tek platformdan yönet" fikrini sertleştirdiği yönünde. Log, güvenlik, sertifika, namespace, policy, hepsi VCF Operations ve Automation etrafında toplanıyor. Bir sistemci olarak bunun getireceği kolaylığı da, getireceği bağımlılığı da görebiliyorum.
Katalogda daha ayrıntılı lab'lar var, kılavuzun kendisi bile Memory Tiering için başka bir lab öneriyor. Onlara bakarsam yine buradan yazarım.
Bu seri VMware HOL ortamı (HOL-2701-01-VCF-L) üzerinden yürütülmektedir. Buradaki gözlemler lab bağlamında değerlendirilmeli, production kararları için resmi VMware dokümantasyonu ve deneyimli mühendisler referans alınmalıdır.
Top comments (0)