HCI mı Klasik SAN mı? S2D, vSAN ve Üç Katmanlı Mimari

Depolama dizisinin destek süresi bitmek üzere, hostlar da eskidi: üç katmanlı mimariyi yenileyecek misiniz, yoksa depolamayı sunuculara gömen hiper-yakınsamış altyapıya (HCI) mı geçeceksiniz? Bu soru satıcı sunumlarında genellikle tek cümleyle cevaplanır. Sahada cevap; büyüme profiline, düğüm sayısına, ağa ve ekibin neyi işletebildiğine bağlıdır. Bu rehber iki yaklaşımı ölçekleme, kapasite verimliliği, arıza alanı, iş yükü uygunluğu ve yaşam döngüsü üzerinden karşılaştırıyor ve bir karar ağacıyla bitiyor.

İki mimarinin temel farkı

Üç katmanlı mimaride hesaplama (hipervizör hostları), ağ (iSCSI/FC/SMB) ve depolama (SAN veya NAS dizisi) ayrı katmanlardır. Dizi kendi denetleyicileri, RAID yapısı, önbelleği ve yazılımıyla bağımsız bir sistemdir; hostlar ona ağ üzerinden erişir.

HCI’de her sunucu kendi yerel disklerini taşır. Yazılım tanımlı depolama katmanı bu diskleri küme genelinde tek havuz olarak sunar ve veriyi düğümler arasında kopyalayarak korur. Ayrı dizi yoktur; “denetleyici” işini hipervizör hostlarında çalışan yazılım görür. Başlıca örnekler:

• Storage Spaces Direct (S2D) — Windows Server Datacenter ve Azure Local’ın depolama katmanı
• VMware vSAN — ESXi çekirdeğine entegre
• Ceph — Proxmox VE’ye entegre veya bağımsız kullanılan dağıtık depolama
• Nutanix AOS — Nutanix platformunun dağıtık depolama katmanı

Bu farkın pratik sonucu: depolama ağının yerini düğümler arası ağ alır. HCI’de her yazma en az bir başka düğüme kopyalanır; 25 GbE ve RDMA gereksinimleri bu yüzden daha sık karşımıza çıkar. Ağ zayıfsa depolama da zayıftır.

Ölçekleme ve kapasite verimliliği

Üç katmanlı mimaride hesaplama ve depolama bağımsız ölçeklenir: kapasite gerekince diziye disk rafı, işlemci gerekince host eklenir. HCI’de ölçekleme birimi düğümdür; her yeni düğüm hem işlemci ve bellek hem disk getirir. Disk ağırlıklı büyüyen bir ortamda (arşiv veya dosya sunucusu verisi gibi) bu, gereksiz işlemci ve çekirdek bazlı lisans maliyeti demektir. Bazı HCI çözümleri yalnız depolama düğümü veya disk ekleme seçeneği sunar; değerlendirmede bunu sorun.

Kapasite verimliliği dayanıklılık yöntemine bağlıdır. S2D için Microsoft dokümantasyonundaki değerler:

Klasik bir dizide RAID 6 veya üreticinin dağıtık RAID yapısı genellikle daha yüksek net/ham oranı verir; veri azaltma (deduplikasyon, sıkıştırma) çoğu dizide denetleyici yazılımına yerleşiktir. Örnek hesap: 100 TB net kapasite gereken bir ortamda üç yönlü yansıtmalı HCI, önbellek diskleri hariç yaklaşık 300 TB ham kapasite ister; aynı ihtiyaç 10+2 RAID 6 gruplarıyla çalışan bir dizide yedek diskler hariç yaklaşık 120 TB ham kapasiteyle karşılanır (100 × 12/10). HCI’de parite kullanmak verimliliği artırır, ama yazma performansını düşürür ve daha fazla düğüm ister. Teklifleri ham TB üzerinden değil, aynı net kapasite ve aynı dayanıklılık hedefiyle karşılaştırın.

Arıza alanları ve düğüm sayısına göre dayanıklılık

HCI’de arıza alanı varsayılan olarak düğümdür. Bir sunucuyu bakım için yeniden başlatmak, o düğümdeki bütün disklerin geçici olarak devre dışı kalması demektir. İki yönlü yansıtmalı bir küme, bir düğüm bakımdayken ikinci bir disk arızasına karşı korumasızdır. Planlı bakım da risktir.

vSAN’da yansıtmayla n arızayı tolere etmek için 2n+1 host gerekir. vSAN ESA mimarisinde RAID-5 için gereken host sayısı OSA’dan farklıdır (ESA, küme boyutuna göre 2+1 veya 4+1 şema kullanır); sürüme özgü ayrıntıları Broadcom dokümantasyonundan kontrol edin. İki düğümlü HCI kümelerinde S2D için dosya paylaşımı, bulut veya USB witness; vSAN için ayrı witness host gerekir. Witness’ı aynı kümenin içine koymak sahada hâlâ görülen bir tasarım hatasıdır.

Üç katmanlı sistem altyapısında arıza alanları ayrıdır: bir hostu yeniden başlatmak depolamanın dayanıklılığını etkilemez. Buna karşılık dizi tek bir sistemdir; çift denetleyicili olsa da denetleyici yazılımı (firmware) hatası veya hatalı bir yükseltme bütün kümeyi etkileyebilir. İki denetleyici, tek yazılım.

S2D/Azure Local, vSAN ve Ceph karşılaştırması

S2D ve vSAN, üretici tarafından kurgulanmış ve yönetim aracına entegre ürünlerdir. Ceph çok esnektir, ama işletimi daha fazla bilgi ister. Ekipte placement group, CRUSH haritası ve yeniden dengeleme davranışını anlayan biri yoksa, bir disk veya düğüm arızasından sonraki toparlanma uzun ve stresli geçer. Ceph’te tüketici sınıfı SSD kullanmak da sık görülen bir hatadır; güç kaybı koruması (PLP) olmayan disklerde senkron yazma performansı çöker. Proxmox üzerinde Ceph kurulumu ve ağ ayrımı için Proxmox VE cluster kurulumu yazısına bakın.

İş yükü uygunluğu

• Genel sunucu sanallaştırması (AD, uygulama, dosya, orta ölçekli SQL): İki mimari de uygundur; karar operasyon modeli ve maliyetle verilir.
• Şube ve uzak lokasyonlar: İki–üç düğümlü HCI, ayrı dizi ve SAN switch ihtiyacını kaldırdığı için güçlü adaydır.
• VDI: Kullanıcı sayısıyla doğrusal büyüyen hesaplama ve depolama ihtiyacı, HCI’nin düğüm bazlı ölçeklemesine iyi uyar.
• Kapasite ağırlıklı veri (arşiv, büyük dosya sunucuları, video): Bağımsız ölçeklenen dizi veya ayrı bir dosya/nesne depolama genellikle daha ekonomiktir.
• Fiziksel sunucuların da paylaşması gereken depolama: Sanal olmayan veritabanı kümeleri veya başka sistemler aynı depolamayı kullanacaksa dizi doğal seçimdir.
• Çok düşük gecikme isteyen veritabanları: İki mimaride de mümkündür. NVMe tabanlı HCI ile all-flash dizi arasında belirleyici olan ölçülmüş gecikmedir, mimari etiketi değil.

Yaşam döngüsü ve yükseltme

HCI’de işletim sistemi, hipervizör, depolama yazılımı, disk ve NIC firmware’i ile sürücüler birlikte doğrulanmalıdır. Uyumsuz bir NIC sürücüsü yalnız ağ sorunu değil, depolama yeniden senkronizasyonu sorunu da çıkarır. HCI ürünlerinin onaylı donanım listeleri ve toplu güncelleme araçlarıyla (Cluster-Aware Updating, vSphere Lifecycle Manager, Azure Local güncelleme düzeni) gelmesinin sebebi budur. Her düğüm güncellemesinden sonra verinin yeniden senkronize olmasını beklemek gerekir; bunu atlayıp sıradaki düğüme geçmek, iki düğümü aynı anda eksik bırakmak demektir. Büyük kümelerde güncelleme penceresi uzar.

Üç katmanlı mimaride sunucu ve dizi yaşam döngüleri ayrıdır: dizi beş–yedi yıl kullanılırken sunucular arada yenilenebilir veya tersi. Yine de dizi firmware’i, HBA/NIC sürücüleri ve hipervizör sürümü arasındaki uyumluluk matrisini ayrıca takip etmeniz gerekir. Dizi değişimi ise çoğunlukla bütün VM’lerin depolama taşımasını gerektiren büyük bir projedir.

Karar ağacı

1. Mevcut dizinin destek süresi 3 yıldan uzun mu? Evet ise üç katmanlı mimariyi sürdürüp hostları yenilemek çoğunlukla en düşük riskli yoldur.
2. Depolamayı fiziksel sunucular veya başka platformlar da kullanıyor mu? Evet ise dizi gerekir; HCI yalnız sanal iş yüklerini kapsar.
3. Kapasite ihtiyacı işlemci ihtiyacından çok daha hızlı mı büyüyor? Evet ise dizi veya ayrı depolama katmanı daha ekonomiktir.
4. Ekip ayrı bir depolama sistemi işletmek istemiyor, tek konsol mu tercih ediliyor? Evet ise HCI öne çıkar.
5. Düğüm sayısı ve ağ HCI’nin dayanıklılık gereksinimini karşılıyor mu? En az üç düğüm (iki düğümde witness), 25 GbE ve gerekiyorsa RDMA bütçelenemiyorsa HCI’nin avantajı azalır.
6. Hipervizör kararı netleşti mi? HCI ürünü hipervizörü belirler (S2D → Hyper-V, vSAN → ESXi). Platform kararı için VMware sonrası platform seçimi yazısına bakın.

Üç katmanlı mimaride kalmaya karar verdiyseniz protokol seçimi için Hyper-V paylaşımlı depolama: iSCSI, SMB3 ve FC yazısıyla devam edin. Mevcut kapasite ve performans verisinin analizi ile donanım seçiminde donanım danışmanlığı ve sanallaştırma ve veri yönetimi hizmetlerimiz kapsamında birlikte çalışabiliriz.

Sık sorulan sorular

HCI her zaman SAN’dan daha ucuz mudur?

Hayır. HCI ayrı dizi ve depolama ağı maliyetini kaldırır, ama yansıtma tabanlı dayanıklılık daha fazla ham disk ister; düğüm bazlı ölçekleme de kapasite ağırlıklı büyümede gereksiz işlemci ve lisans maliyeti doğurabilir. Karşılaştırmayı aynı net kapasite ve dayanıklılık hedefiyle yapın.

İki düğümlü HCI kümesi üretimde güvenli mi?

Doğru witness yapılandırmasıyla desteklenir ve şube gibi küçük ortamlarda yaygındır. Ancak bir düğüm bakımdayken veri tek kopyaya düşer; S2D’deki iç içe (nested) dayanıklılık gibi seçenekler bu riski azaltır, karşılığında kapasite verimliliği düşer.

Mevcut SAN’ı HCI kümesine bağlayabilir miyim?

Birçok hipervizör aynı anda hem HCI hem harici depolama kullanabilir, ancak S2D ve Azure Local gibi çözümler harici depolamayı sınırlı destekler. Geçiş döneminde SAN’ı ayrı bir kümede veya yalnız taşıma amacıyla kullanmak daha net bir yaklaşımdır.

HCI için 10 GbE ağ yeterli mi?

Küçük ve yazma yükü düşük kümelerde yeterli olabilir. Her yazma diğer düğümlere kopyalandığı ve disk arızasında yeniden senkronizasyon ağ üzerinden yapıldığı için 25 GbE ve uygunsa RDMA önerilir. Üreticinin ilgili ürün için minimum ağ gereksinimini esas alın.