Üç haftadır SPBM, izleme ve şifreleme konularını işledim. Bu hafta Modül 4'e geçiyorum: vSAN Stretched Cluster. Önceki modüllere göre bu konu kavramsal olarak biraz daha zorlayıcı geldi; tek bir cluster'ı iki fiziksel siteye yaymak, hem ağ mimarisi hem de failure senaryoları açısından yeni bir düşünme biçimi gerektiriyor.
Şunu baştan belirtmek isterim: HOL ortamı bunu tam olarak simüle edemiyor, manuel de bunu açıkça söylüyor. İki site arası gerçek bir 10GbE bağlantısı ya da crossover kablo burada yok. Ama stretched cluster'ı hazırlama adımları ve witness trafiğini ayırma mantığı, gerçek bir direct-connect cluster'da yapılanla aynı.
Stretched Cluster Nedir, Neden Var?
Normal bir vSAN cluster'ı tek bir lokasyonda çalışır. Stretched cluster ise aynı cluster'ı iki fiziksel siteye yayıyor: veri her iki sitede de bir kopya halinde tutuluyor. Amaç, bir sitenin tamamen kaybedilmesi durumunda bile VM'lerin diğer sitede çalışmaya devam etmesi.
Bunu mümkün kılan üçüncü bir bileşen var: Witness Host. Bu, veri taşımayan, sadece quorum (çoğunluk kararı) sağlayan özel bir sanal cihaz. 1+1+1 mimarisi şöyle işliyor: Site 1'de en az bir host, Site 2'de en az bir host, ve ayrı bir yerde bir witness host.
2-Node Direct Connect Senaryosu
vSAN 6.5'ten itibaren 2-node konfigürasyonlarda doğrudan crossover kablo kullanımı destekleniyor. Bu özellikle ROBO (remote office/branch office) senaryolarında değerli: her lokasyona 10GbE switch altyapısı kurmak maliyetli ve karmaşık olabiliyor. İki host'u doğrudan birbirine bağlamak bu maliyeti ortadan kaldırıyor, aynı zamanda karmaşıklığı azaltıp güvenilirliği artırıyor.
Preferred Site Kavramı
Stretched cluster'da "preferred site" (tercih edilen site) diye bir kavram var. Bu, vSAN'a "iletişim koptuğunda hangi tarafın ayakta kalmasını istiyorum" demenin yolu. Denilebilir ki preferred site, en güvenilir olması beklenen taraf.
Mantık şöyle işliyor: Site 1 ile Site 2 arasındaki bağlantı koparsa ama her iki site de witness host'a erişebiliyorsa, preferred site çalışmaya devam ediyor ve bileşenleri aktif kalıyor. Preferred olmayan site'daki storage ise "down" olarak işaretleniyor, bileşenler "absent" durumuna geçiyor.
Bu, klasik bir split-brain önleme mekanizması. Witness, kimin "doğru" taraf olduğuna karar veren hakem rolünü oynuyor.
Read Locality: Okuma Trafiğini Yerel Tutmak
Bu kısım benim için modülün en pratik bilgisi oldu. Normal vSAN'da okuma istekleri, verinin tüm replika kopyaları arasında round-robin şeklinde dağıtılıyor. Stretched cluster'da ise bu davranış değişiyor.
Read locality algoritması, okumaların yüzde yüzünü compute'un bulunduğu site'daki yerel veri kopyasından yapıyor. Mantığı açık: VM'in compute kaynağı Site 1'deyse, okuma isteklerini Site 2'ye göndermek gereksiz bir ağ gecikmesi (latency) yaratır. Bu yeni algoritma, okuma işlemlerindeki gecikmeyi azaltmak için tasarlanmış.
Manuel'de ilginç bir eşik veriyor: Eğer siteler arası gecikme 5ms'nin altındaysa ve yeterli bant genişliği varsa, read locality kapatılabiliyor. Ama bunu kapatmak, okuma trafiğinin yarısının uzak siteye gitmesi anlamına geliyor; bu da ağ bant genişliği planlaması için ciddi bir fark yaratıyor. Manuel ayrıca bunun yalnızca VMware Global Support Services rehberliğinde ve sadece son derece düşük gecikme olan ortamlarda yapılması gerektiğini özellikle vurguluyor. Yani bu varsayılan davranışı kapatmak bir "ileri seviye ayar" değil, neredeyse bir istisna durumu.
Bununla ilgili gizli bir advanced parameter de var: VSAN.DOMOwnerForceWarmCache. Bu, vSphere Web Client'ta görünmüyor, sadece CLI üzerinden erişilebiliyor. Bunun gizli tutulması bana mantıklı geldi; yanlışlıkla değiştirildiğinde etkisi geniş olabilecek bir ayar.
Witness Host: Cluster'ın Dışında Kalan Üye
Burada altı önemle çizilen bir kural var: Stretched cluster yapılandırılırken sadece data host'lar cluster objesinin içinde olmalı. Witness host, cluster dışında kalmalı ve hiçbir aşamada cluster'a eklenmemeli.
HOL ortamında witness host önceden deploy edilmiş durumda: esx-11a.site-a.vcf.lab. Inventory görünümünde bu host'un sunucu ikonunda küçük bir işaret var; bunun normal bir ESX host değil, vSAN 2-Node ve Stretched Cluster mimarilerini desteklemek için kullanılan özel bir sanal cihaz olduğunu gösteriyor.
Witness Networking: İki Ayrı Arayüz
Witness appliance'ın iki ağ adaptörü var, iki ayrı standart switch'e bağlı:
- Management VMkernel (vmk0): vCenter ile iletişim için, appliance yönetimi amacıyla.
- secondaryPG (vmk1): vSAN ağıyla iletişim için.
Bu ayrım önerilen konfigürasyon. Bu iki arayüz farklı ya da aynı ağlara bağlanabilir, yeter ki ilgili servislere erişimleri olsun. Management arayüzü vSAN trafiğini de taşıyacak şekilde tag'lenebilir, ama bu durumda vmk0'ın hem vCenter'a hem vSAN ağına erişimi olması gerekiyor.
Manuel'de nested ortamlar için ilginç bir not var: VMware'in bu HOL için kullandığı platform gibi birçok nested ESX ortamında, promiscuous mode'u etkinleştirme önerisi var. Sebebi şu: sanal switch, tanımadığı nested vmnic'ler için paketleri düşürebiliyor; promiscuous mode bunu önlüyor. HOL'da bu zaten yapılandırılmış durumda, ama gerçek bir nested ortamda bu ayarı unutursanız witness trafiği sessizce kaybolabilir; bunu hatırlamak gerekiyor.
Witness üzerinde secondaryPg adında önceden tanımlanmış bir portgroup var, vSAN trafiği için kullanılan VMkernel port burada görünüyor. vSAN ağında DHCP sunucusu yoksa (ki genelde yok), VMkernel adaptörünün geçerli bir IP adresi olmayacaktır; bu durumda manuel IP ataması gerekiyor.
Static Route Gerekliliği
Stretched cluster yapılandırılmadan önceki son adım, her sitedeki host'lar ile witness host arasında bağlantının sağlandığından emin olmak. Bu bağlantıyı yapılandırmadan önce doğrulamak önemli.
vSAN ağı, veri siteleri arasında stretched bir L2 broadcast domain olarak öneriliyor, ama witness appliance'ın vSAN ağına ulaşmak için L3 (routing) gerekiyor. Bu yüzden veri host'ları ile witness arasında static route'lar tanımlanması gerekiyor; ama farklı sitelerdeki veri host'larının birbiriyle iletişimi için bu gerekmiyor, çünkü onlar zaten aynı L2 domain'de.
Bir static route eklemek için kullanılan esxcli komutu manuel'de örnek olarak veriliyor; route bilgisini görüntülemek için ayrı komutlar da mevcut (network komşularını listeleyen ve gateway bilgisini gösteren komutlar). Bu adımın her host için tekrarlanması gerektiği özellikle vurgulanıyor.
Bu kısmı okurken şunu düşündüm: GUI üzerinden yapılan çoğu adımın aksine, bu networking hazırlığı CLI bilgisi gerektiriyor. HOL'da bu adım atlanmış, zaten hazır geliyor, ama gerçek bir kurulumda muhtemelen en çok zaman alacak ve en çok hata yapılacak adım burası olurdu.
Mevcut Cluster'ı Stretched Cluster'a Dönüştürmek
HOL'da var olan 4-node cluster'ı (esx-05a, 06a, 07a, 08a) stretched cluster'a çeviriyoruz. İki host daha (esx-09a, esx-10a) cluster'a ekleniyor, toplam 6 node oluyor.
Host'ları Cluster'a Eklemek
Önce her iki host'ta da (esx-09a ve esx-10a) vSAN VMkernel adaptörünün doğru yapılandırıldığı, Configure > VMkernel Adapters üzerinden kontrol ediliyor.
Ardından host'lar sürükle-bırak ile cluster'a ekleniyor. Açılan onay penceresi varsayılan ayarlarla geçiliyor. Host cluster'a eklendikten sonra, eğer maintenance mode'daysa sağ tık ile Exit Maintenance Mode uygulanıyor. Bu işlem birkaç dakika sürebiliyor, Recent Tasks üzerinden takip edilebiliyor.
Fault Domain Yapılandırması
Asıl dönüşüm burada başlıyor:
cluster-esa-01a > Configure > vSAN > Fault Domains > CONFIGURE STRETCHED CLUSTER
Açılan ekranda host'lar iki domain'e ayrılıyor. Varsayılan olarak hepsi "preferred" tarafında görünüyor; esx-08a, esx-09a ve esx-10a seçilip >> ile secondary domain'e taşınıyor.
Sonraki adımda witness host seçiliyor: esx-11a. vSAN burada otomatik bir uyumluluk kontrolü çalıştırıyor; witness'ın bu cluster ile kullanılabilir olup olmadığını doğruluyor.
Review ekranında vSAN, oluşturacağı cluster konfigürasyonunun özetini gösteriyor; burada, dönüştürme işlemi tamamlanmadan önce düzeltme yapma fırsatı da veriliyor. FINISH ile cluster oluşturuluyor.
İşlem sırasında Recent Tasks panelinden ilerleme izlenebiliyor; tüm görevler "Completed" olana kadar beklemek gerekiyor.
Sonucu Doğrulamak
cluster-esa-01a > Configure > vSAN > Fault Domains ekranına dönüldüğünde:
- Failures To Tolerate (FTT) değeri 1 olarak görünüyor. Bu, cluster'ın herhangi bir site'ın (ya da witness host'un) kaybını tolere edip VM'leri çalışır tutabileceği anlamına geliyor.
- İki fault domain ve bunlara ait host'lar listede görünüyor.
Manuel'de önemli bir mimari notu var: Site Mirroring ile FTT=1 kombinasyonu, stretched cluster'lar için önerilen standart mimari. 6 node ve üzeri büyük stretched cluster'larda, site içi ek koruma katmanı da isteğe bağlı olarak yapılandırılabiliyor; bu seçimler tipik vSAN politikalarıyla (RAID-1 mirroring, RAID-5 ve RAID-6 erasure coding) uyumlu. Yani site-level koruma ile site-içi koruma birbirinden ayrı, üst üste konumlandırılabilen iki katman.
Nested Ortam Uyarıları
HOL, nested bir vSphere ortamında çalıştığı için vCenter, vSAN cluster'ının sağlığı hakkında birkaç uyarı gösteriyor. Manuel açıkça şunu söylüyor: bu lab kapsamında bu uyarıları görmezden gelmek veya susturmak sorun değil, ama gerçek workload barındıran herhangi bir "canlı" vSAN cluster'ında bu tür uyarıları Skyline Health servisi üzerinden detaylıca araştırmak gerekiyor.
Bu küçük ama önemli bir uyarı; HOL'da görülen "her şey kırmızı/sarı" görünümünün gerçek ortamda aynı ciddiyetle ele alınmaması gerektiğini hatırlatıyor, ama aynı zamanda gerçek ortamda bu uyarıların asla göz ardı edilmemesi gerektiğini de.
Skyline Health: Stretched Cluster'a Özel Kontroller
Cluster oluşturulduktan sonra Skyline Health'te yeni bulgular ortaya çıkıyor. RETEST'e basıldığında "vSAN optimal datastore default policy configuration" başlıklı bir uyarı görülüyor; üç nokta menüsünden TROUBLESHOOT seçilince detaylar açılıyor.
Datastore Default Policy'yi Güncellemek
Cluster yapısı değiştiği için (standart cluster'dan, her sitede üç host olan bir stretched cluster'a geçiş), Skyline Health iki değişiklik öneriyor:
- Standart cluster'dan stretched cluster'a (site mirroring ile) geçiş.
- Her site içinde RAID-5'ten RAID-1'e geçiş.
"UPDATE Cluster DS Policy" butonuna basılıyor.
Açılan onay penceresinde OK tıklanıyor. Default policy değiştirildiği için, orijinal policy'i kullanan VM'lerin yeni policy'e geçmesi için ayrıca reapply işlemi gerekiyor. Bu ortamdaki VM'ler varsayılan ESA RAID-5 policy'sini kullandığından, policy'yi manuel olarak yeni Optimal Storage Policy'ye değiştirmek gerekiyor.
Mevcut VM'lere Yeni Policy'i Uygulamak
Policies and Profiles menüsüne gidilip yeni oluşan cluster-esa-01a - Optimal Datastore Default Policy - stretched RAID1 policy'si seçiliyor, REAPPLY'a tıklanıyor. Bir uyarı, bu işlemin zaman alabileceğini ve birkaç VM'i etkileyeceğini bildiriyor; OK ile onaylanıyor.
Skyline Health'e dönülüp tekrar RETEST yapıldığında, policy uyarısının kaybolduğu görülüyor. Manuel'de bir not daha var: bazen bu uyarı bir kez daha görünebiliyor, RETEST ile geçiyor.
Stretched cluster'a özel diğer health check'leri görmek için filtre üzerinden "Stretched cluster" kategorisi seçilebiliyor.
vSAN health check, vSAN kurulumlarının performans ve sağlık testlerine derinlemesine inmek için değerli bir araç; vSAN ortamını izlemek için gidilecek ilk yer olmalı. Güncel durumu görmek için health check'i düzenli olarak yeniden çalıştırmak iyi bir pratik.
vSAN Site Affinity: Her VM'in Çok Site Koruması İstemediği Durumlar
Modülün ikinci yarısı farklı bir soruna eğiliyor. Bir veri merkezinde, uygulama seviyesinde zaten dahili yüksek erişilebilirlik veya yedeklilik sağlayan pek çok workload var. Ama tipik production workload'ları çoğunlukla daha iyi veri yedekliliği için çok-site koruması gerektiriyor. Peki, kopyaların farklı sitelerde tutulmasını gerektirmeyen workload'lar için ne yapılabilir?
Bu soruya cevap: Local Affinity.
Local Affinity Mantığı
Local Affinity, bir policy aracılığıyla veriyi tek bir site'da tutmayı sağlıyor. Bunun teknik karşılığı Primary Failures To Tolerate (PFTT) değerinin 0 olarak ayarlanması. PFTT=0 olduğunda nesneler ikincil siteye replike edilmiyor, bu da siteler arası gereken bant genişliğini azaltıyor. Ayrıca affinity kuralları kullanılarak VM/VMDK atamaları belirli host'lara da sabitlenebiliyor.
Manuel, test senaryosu olarak şu kombinasyonu öneriyor: PFTT=0, Secondary Failures To Tolerate (SFTT)=2, Failure Tolerance Method (FTM)=RAID-5. Bu kombinasyonla tüm I/O'nun yerel olarak yapılması, hiçbirinin ikincil siteye gitmemesi bekleniyor. Yani site koruması olmadan, host/disk seviyesinde koruma sorunsuzca elde edilmiş oluyor.
Birkaç kısıtlama da var:
- Affinity, sadece Stretched Cluster etkinleştirilmiş cluster'larda kullanılabiliyor.
- DRS/HA kuralları, data locality ile uyumlu olmalı.
- OSA'da Hybrid konfigürasyonlarda RAID-0 ve RAID-1 destekleniyor, All-Flash'te RAID-0, RAID-1, RAID-5 ve RAID-6 destekleniyor.
Bu son madde aklımda kaldı: Local Affinity kullanılırken DRS/HA kurallarının manuel olarak hizalanması gerekiyor. Bu, "policy ayarladım, iş bitti" diyemeyeceğiniz, cluster'ın diğer otomasyon katmanlarıyla da koordinasyon gerektiren bir özellik.
Single Site Storage Policy Oluşturmak
Policies and Profiles > VM Storage Policies > CREATE
İsim: Single Site Storage Policy. "Enable rules for vSAN storage" seçiliyor.
Availability sekmesinde:
- Site disaster tolerance: None - keep data on Preferred (stretched cluster)
- Failures to tolerate: 1 failure - RAID-1 (Mirroring)
Datastore uyumluluğu doğrulanıyor (vsan-esa-01a_Datastore Compatible görünmeli), FINISH ile policy tamamlanıyor.
Local Affinity Policy ile VM Oluşturmak
core-a VM'i klonlanarak Local Affinity VM adıyla yeni bir VM oluşturuluyor. Clone wizard'ında:
- Datacenter:
dc-a - Cluster:
cluster-esa-01a - Storage Policy:
Single Site Storage Policy - Datastore:
vsan-esa-01a_Datastore(compatible olarak görünüyor)
Klon tamamlandığında VM Summary'den policy'nin atandığı ve "Compliant" olduğu doğrulanıyor.
Yerleşimi Doğrulamak: Preferred Fault Domain
cluster-esa-01a > Configure > vSAN > Fault Domains ekranından preferred fault domain'in hangi host'ları içerdiği görülüyor. HOL'daki örnekte esx-05a, esx-06a ve esx-07a preferred domain'de.
Local Affinity VM > Monitor > vSAN > Physical disk placement ekranından, bileşenlerin gerçekten preferred fault domain üzerinde konumlandığı doğrulanıyor.
Bu doğrulama adımı önemli, çünkü policy'nin "doğru göründüğünü" varsaymak yerine bileşenlerin gerçekte nerede oturduğunu kontrol etmek, "compliant" etiketinin arkasındaki gerçekliği teyit ediyor.
Policy'i Değiştirip Site Geçişini Görmek
Modülün son kısmında, Single Site Storage Policy düzenlenerek Site disaster tolerance ayarı "None - keep data on Secondary" olarak değiştiriliyor. Bu, verinin artık preferred yerine secondary site'da tutulmasını söylüyor.
Policy zaten bir VM tarafından kullanıldığı için, "Reapply to VMs" seçeneği "Now" olarak ayarlanıp YES ile onaylanıyor.
Son doğrulama adımında Local Affinity VM > Monitor > vSAN > Physical disk placement tekrar kontrol ediliyor; bu sefer bileşenlerin Secondary Fault Domain'e taşındığı görülüyor.
Bu son adım, Local Affinity'nin sadece statik bir yerleşim olmadığını, policy değiştiğinde verinin gerçekten fiziksel olarak başka bir site'a taşındığını gösteriyor. vMotion gibi VM'in compute'unun taşınması değil, doğrudan storage nesnelerinin yeniden yerleştirilmesi (re-placement) söz konusu.
Genel Değerlendirme
Bu modül, önceki üçünden farklı bir karaktere sahip. SPBM, izleme ve şifreleme tek bir site içinde çalışan kavramlardı. Stretched cluster ise coğrafi/fiziksel bir boyut ekliyor; ağ topolojisi, gecikme süreleri ve "hangi taraf hayatta kalmalı" gibi sorular devreye giriyor.
Benim için en çok düşündüren üç nokta şunlardı:
Birincisi, witness host'un cluster'ın dışında tutulması gerekliliği. İlk bakışta tuhaf geliyor; quorum sağlayan bir bileşenin neden cluster üyesi olmadığını sorgulamak doğal. Ama mantığı şu: witness veri taşımıyor, sadece karar verici. Cluster üyesi olsaydı, kendisi de bir failure noktası haline gelebilirdi.
İkincisi, read locality'nin varsayılan davranış olması ve kapatılmasının neredeyse istisnai bir durum olarak tanımlanması. Bu, "ne zaman varsayılanı değiştirmemeliyim" sorusuna iyi bir örnek; bazen en iyi karar, ayarı olduğu gibi bırakmak.
Üçüncüsü, Local Affinity'nin son demosu; policy değiştiğinde verinin fiziksel olarak taşındığını göstermesi. Bu, SPBM'in sadece "uyumlu/uyumsuz" etiketlemekle kalmadığını, gerçek veri hareketini tetiklediğini somut olarak gösteriyor. Modül 1'de gördüğümüz Placement Details ekranının burada da işe yaraması, serinin kendi içinde nasıl bağlandığını da hissettirdi.
HOL'un nested ortam kısıtlamaları burada daha belirgin hissettiriyor kendini; gerçek bir stretched cluster kurulumunda WAN gecikmesi, bant genişliği sınırlamaları ve gerçek bir site kaybı senaryosu test etmek, bu modülün kapsamının çok ötesinde bir konu. Ama temel kavramları, doğru terminolojiyle ve doğru sırayla görmüş olmak, gerçek bir tasarım dokümanını okurken işe yarayacak bir zemin oluşturuyor.
Bir sonraki hafta Modül 5'e 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)