Bu, sunucu donanımı alanında oldukça yaygın olan bir efsanedir. Uygulamada birçok şey için hiper yakınsak çözümlere (her şeyin bir arada olduğu durumlarda) ihtiyaç duyulur. Tarihsel olarak ilk mimariler Amazon ve Google tarafından hizmetleri için geliştirildi. Daha sonra fikir, her biri kendi diskine sahip olan özdeş düğümlerden bir bilgi işlem çiftliği oluşturmaktı. Bütün bunlar bazı sistem oluşturucu yazılımlar (hipervizör) tarafından birleştirildi ve sanal makinelere bölündü. Ana amaç, bir düğüme bakım yapmak için minimum çaba ve ölçeklendirme sırasında minimum sorun yaşanmasıdır: aynı sunucudan bin veya iki tane daha satın alın ve bunları yakına bağlayın. Uygulamada bunlar izole durumlardır ve çoğunlukla daha az sayıda düğümden ve biraz farklı bir mimariden bahsediyoruz.
Ancak artısı aynı: inanılmaz ölçeklendirme ve yönetim kolaylığı. Dezavantajı, farklı görevlerin kaynakları farklı şekilde tüketmesidir ve bazı yerlerde çok sayıda yerel disk olacak, diğerlerinde çok az RAM olacak ve bu böyle devam edecek, yani farklı görev türleri için kaynak kullanımı azalacak.
Kurulum kolaylığı için %10-15 daha fazla ödediğiniz ortaya çıktı. Başlıktaki efsaneyi ateşleyen şey buydu. Teknolojinin en iyi şekilde nerede uygulanabileceğini uzun süre aradık ve bulduk. Gerçek şu ki Cisco'nun kendi depolama sistemleri yoktu ancak eksiksiz bir sunucu pazarı istiyorlardı. Ve düğümlerde yerel depolamaya sahip bir çözüm olan Cisco Hyperflex'i yaptılar.
Ve bunun aniden yedek veri merkezleri (Felaket Kurtarma) için çok iyi bir çözüm olduğu ortaya çıktı. Şimdi size nedenini ve nasılını anlatacağım. Ve size küme testlerini göstereceğim.
Gerektiğinde
Hiper yakınsama:
- Diskleri bilgi işlem düğümlerine aktarma.
- Depolama alt sisteminin sanallaştırma alt sistemiyle tam entegrasyonu.
- Ağ alt sistemiyle aktarım/entegrasyon.
Bu kombinasyon, birçok depolama sistemi özelliğini sanallaştırma düzeyinde ve tümünü tek bir kontrol penceresinden uygulamanıza olanak tanır.
Şirketimizde, yedekli veri merkezleri tasarlamaya yönelik projeler büyük talep görmektedir ve kullanıma hazır bir dizi çoğaltma seçeneği (bir metro kümesine kadar) nedeniyle sıklıkla hiper birleşik bir çözüm seçilmektedir.
Yedek veri merkezleri söz konusu olduğunda genellikle şehrin diğer ucundaki bir sitede veya tamamen başka bir şehirde bulunan uzak bir tesisten bahsediyoruz. Ana veri merkezinin kısmen veya tamamen arızalanması durumunda kritik sistemleri geri yüklemenizi sağlar. Satış verileri burada sürekli olarak çoğaltılır ve bu çoğaltma, uygulama düzeyinde veya blok cihaz (depolama) düzeyinde olabilir.
Bu nedenle, şimdi sistem tasarımı ve testlerinden bahsedeceğim, ardından tasarruf verileriyle birlikte birkaç gerçek hayattaki uygulama senaryosundan bahsedeceğim.
Testler
Örneğimiz her biri 10 GB'lık 960 adet SSD sürücüye sahip dört sunucudan oluşmaktadır. Yazma işlemlerini önbelleğe almak ve hizmet sanal makinesini depolamak için ayrılmış bir disk vardır. Çözümün kendisi dördüncü versiyondur. Birincisi açıkçası kaba (incelemelere bakılırsa), ikincisi nemli, üçüncüsü zaten oldukça kararlı ve buna genel halk için beta testinin bitiminden sonra sürüm denilebilir. Test sırasında herhangi bir sorun görmedim, her şey saat gibi çalışıyor.
V4'teki değişikliklerBir sürü hata düzeltildi.
Başlangıçta platform yalnızca VMware ESXi hipervizörüyle çalışabiliyordu ve az sayıda düğümü destekliyordu. Ayrıca dağıtım süreci her zaman başarıyla sonuçlanmıyordu, bazı adımların yeniden başlatılması gerekiyordu, eski sürümlerden güncelleme yaparken sorunlar vardı, GUI'deki veriler her zaman doğru şekilde görüntülenmiyordu (her ne kadar performans grafiklerinin görüntülenmesinden hâlâ memnun olmasam da) ), bazen sanallaştırma arayüzünde sorunlar ortaya çıktı.
Artık tüm çocukluk sorunları düzeltildi, HyperFlex hem ESXi'yi hem de Hyper-V'yi yönetebilir, ayrıca şunları yapmak da mümkündür:
- Uzatılmış bir küme oluşturma.
- Fabric Interconnect kullanmadan ofisler için iki ila dört düğümden oluşan bir küme oluşturma (yalnızca sunucuları satın alıyoruz).
- Harici depolama sistemleriyle çalışabilme.
- Konteynerler ve Kubernetes desteği.
- Kullanılabilirlik bölgelerinin oluşturulması.
- Yerleşik işlevsellik tatmin edici değilse VMware SRM ile entegrasyon.
Mimarisi ana rakiplerinin çözümlerinden pek farklı değil, bisiklet yaratmadılar. Hepsi VMware veya Hyper-V sanallaştırma platformunda çalışır. Donanım, tescilli Cisco UCS sunucularında barındırılmaktadır. İlk kurulumun göreceli karmaşıklığı, çok sayıda düğme, önemsiz bir şablon ve bağımlılık sistemi nedeniyle platformdan nefret edenler var, ancak aynı zamanda Zen'i öğrenmiş, bu fikirden ilham almış ve artık istemeyenler de var. diğer sunucularla çalışmak için.
Çözüm orijinal olarak onun için yaratıldığından ve daha fazla işlevselliğe sahip olduğundan, VMware çözümünü ele alacağız; rakiplere ayak uydurmak ve pazar beklentilerini karşılamak için Hyper-V yol boyunca eklendi.
Disklerle dolu bir sunucu kümesi var. Veri depolama için diskler vardır (zevkinize ve ihtiyaçlarınıza göre SSD veya HDD), önbellekleme için bir adet SSD diski vardır. Veri deposuna veri yazarken veriler önbellekleme katmanına (özel SSD diski ve hizmet VM'sinin RAM'i) kaydedilir. Paralel olarak kümedeki düğümlere bir veri bloğu gönderilir (düğüm sayısı küme çoğaltma faktörüne bağlıdır). Başarılı kayıt konusunda tüm düğümlerden onay alındıktan sonra, kaydın onayı hipervizöre ve ardından VM'ye gönderilir. Kaydedilen veriler tekilleştirilir, sıkıştırılır ve arka planda depolama disklerine yazılır. Aynı zamanda depolama disklerine her zaman ve sırayla büyük bir blok yazılır, bu da depolama disklerindeki yükü azaltır.
Tekilleştirme ve sıkıştırma her zaman etkindir ve devre dışı bırakılamaz. Veriler doğrudan depolama disklerinden veya RAM önbelleğinden okunur. Hibrit bir yapılandırma kullanılırsa okumalar da SSD'de önbelleğe alınır.
Veriler sanal makinenin geçerli konumuna bağlı değildir ve düğümler arasında eşit olarak dağıtılır. Bu yaklaşım, tüm diskleri ve ağ arayüzlerini eşit şekilde yüklemenize olanak tanır. Açık bir dezavantaj var: Yerel olarak veri kullanılabilirliği garantisi olmadığından okuma gecikmesini mümkün olduğu kadar azaltamıyoruz. Ancak alınan faydalarla karşılaştırıldığında bunun küçük bir fedakarlık olduğuna inanıyorum. Üstelik ağ gecikmeleri öyle değerlere ulaştı ki pratikte genel sonucu etkilemiyor.
Her depolama düğümünde oluşturulan özel bir hizmet VM Cisco HyperFlex Veri Platformu denetleyicisi, disk alt sisteminin tüm çalışma mantığından sorumludur. Hizmet VM yapılandırmamızda sekiz vCPU ve 72 GB RAM tahsis edildi ki bu çok da az değil. Ana bilgisayarın kendisinin 28 fiziksel çekirdeğe ve 512 GB RAM'e sahip olduğunu hatırlatmama izin verin.
Hizmet VM'sinin, SAS denetleyicisini VM'ye ileterek doğrudan fiziksel disklere erişimi vardır. Hipervizörle iletişim, G/Ç işlemlerini engelleyen özel bir IOVisor modülü aracılığıyla ve hipervizör API'sine komutlar göndermenize izin veren bir aracı kullanılarak gerçekleşir. Temsilci, HyperFlex anlık görüntüleri ve klonlarıyla çalışmaktan sorumludur.
Disk kaynakları hipervizöre NFS veya SMB paylaşımları olarak eklenir (hipervizörün türüne bağlı olarak hangisinin nerede olduğunu tahmin edin). Ve aslında bu, yetişkinlere yönelik tam donanımlı depolama sistemlerinin özelliklerini eklemenize olanak tanıyan dağıtılmış bir dosya sistemidir: ince birim ayırma, sıkıştırma ve veri tekilleştirme, Yazma Üzerine Yönlendirme teknolojisini kullanan anlık görüntüler, eşzamanlı/eşzamansız çoğaltma.
Hizmet VM'si, HyperFlex alt sisteminin WEB yönetim arayüzüne erişim sağlar. VCenter ile entegrasyon vardır ve günlük görevlerin çoğu buradan gerçekleştirilebilir, ancak örneğin veri depolarını, zaten hızlı bir HTML5 arayüzüne geçtiyseniz veya tam teşekküllü bir Flash istemcisi kullanıyorsanız, ayrı bir web kamerasından kesmek daha uygundur. tam entegrasyon ile. Servis web kamerasında sistemin performansını ve ayrıntılı durumunu görüntüleyebilirsiniz.
Bir kümede başka bir düğüm türü daha vardır; bilgi işlem düğümleri. Bunlar, yerleşik diskleri olmayan raf veya blade sunucular olabilir. Bu sunucular, verileri diskli sunucularda saklanan VM'leri çalıştırabilir. Veri erişimi açısından bakıldığında düğüm türleri arasında hiçbir fark yoktur çünkü mimari, verinin fiziksel konumundan soyutlamayı içerir. Bilgi işlem düğümlerinin depolama düğümlerine maksimum oranı 2:1'dir.
Bilgi işlem düğümlerinin kullanılması, küme kaynaklarını ölçeklendirirken esnekliği artırır: Yalnızca CPU/RAM'e ihtiyacımız varsa, diskli ek düğümler satın almamız gerekmez. Ayrıca blade kafesi ekleyebilir ve sunucuların raf yerleşiminden tasarruf edebiliriz.
Sonuç olarak, aşağıdaki özelliklere sahip hiper bütünleşik bir platforma sahibiz:
- Bir kümede en fazla 64 düğüm (en fazla 32 depolama düğümü).
- Bir kümedeki minimum düğüm sayısı üçtür (Edge kümesi için iki).
- Veri yedekleme mekanizması: çoğaltma faktörü 2 ve 3 ile yansıtma.
- Metro kümesi.
- Başka bir HyperFlex kümesine eşzamansız VM çoğaltma.
- VM'leri uzak bir veri merkezine geçirmenin düzenlenmesi.
- Yazma Üzerine Yönlendirme teknolojisini kullanan yerel anlık görüntüler.
- Çoğaltma faktörü 1'te ve veri tekilleştirme olmadan 3 PB'a kadar kullanılabilir alan. Çoğaltma faktörü 2'yi hesaba katmıyoruz çünkü bu ciddi satışlar için bir seçenek değil.
Bir diğer büyük artı ise yönetim ve dağıtım kolaylığıdır. UCS sunucularını kurmanın tüm karmaşıklığı, Cisco mühendisleri tarafından hazırlanan özel bir VM tarafından halledilir.
Test tezgahı konfigürasyonu:
- Yönetim kümesi ve ağ bileşenleri olarak 2 x Cisco UCS Fabric Interconnect 6248UP (Ethernet 48G/FC 10G modunda çalışan 16 bağlantı noktası).
- Dört Cisco UCS HXAF240 M4 sunucusu.
Sunucu özellikleri:
işlemci
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/çift aşamalı/x4/1.2v
ağ
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet bağlantı noktası
Depolama HBA'sı
Cisco 12G Modüler SAS Geçiş Denetleyicisi
Depolama Diskleri
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Daha fazla yapılandırma seçeneğiSeçilen donanıma ek olarak şu anda aşağıdaki seçenekler mevcuttur:
- HXAF240c M5.
- Intel Silver 4110'dan Intel Platinum I8260Y'ye kadar bir veya iki CPU. İkinci nesil mevcuttur.
- 24 bellek yuvası, 16 GB RDIMM 2600'den 128 GB LRDIMM 2933'e kadar şeritler.
- 6'dan 23'e kadar veri diski, bir önbellek diski, bir sistem diski ve bir önyükleme diski.
Kapasite Sürücüleri
- HX-SD960G61X-EV 960 GB 2.5 İnç Kurumsal Değer 6G SATA SSD (1X dayanıklılık) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 inç Kurumsal Değer 6G SATA SSD (1X dayanıklılık) SAS 3.8 TB.
- Sürücüleri Önbelleğe Alma
- HX-NVMEXPB-I375 375 GB 2.5 inç Intel Optane Sürücü, Olağanüstü Performans ve Dayanıklılık.
- HX-NVMEHW-H1600* 1.6 TB 2.5 inç Ent. Mükemmel. NVMe SSD (3 kat dayanıklılık) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 inç Ent. Mükemmel. 12G SAS SSD (10X dayanıklılık) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5 inç Ent. Mükemmel. 12G SAS SED SSD (10X dayanıklılık) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5 inç Kurumsal performans 12G SAS SSD (3X dayanıklılık).
Sistem/Günlük Sürücüleri
- HX-SD240GM1X-EV 240 GB 2.5 inç Kurumsal Değer 6G SATA SSD (Yükseltme gerektirir).
Önyükleme Sürücüleri
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Ağa 40G, 25G veya 10G Ethernet bağlantı noktaları aracılığıyla bağlanın.
FI, HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G) olabilir.
Testin kendisi
Disk alt sistemini test etmek için HCIBench 2.2.1'i kullandım. Bu, birden fazla sanal makineden yük oluşturulmasını otomatikleştirmenize olanak tanıyan ücretsiz bir yardımcı programdır. Yükün kendisi olağan fio tarafından oluşturulur.
Kümemiz dört düğümden oluşuyor, çoğaltma faktörü 3, tüm diskler Flash.
Test için dört veri deposu ve sekiz sanal makine oluşturdum. Yazma testleri için önbellek diskinin dolu olmadığı varsayılır.
Test sonuçları aşağıdaki gibidir:
%100 Okuma %100 Rastgele
%0 Okuma %100Rastgele
Blok/sıra derinliği
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36 ms 374348 IOPS
2.47 ms 414116 IOPS
4,86 ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16K
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32K
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Kalın, üretkenliğin artmadığı, hatta bazen bozulmanın görülebildiği değerleri gösterir. Bunun nedeni ağın/kontrolörlerin/disklerin performansıyla sınırlı olmamızdır.
- Sıralı okuma 4432 MB/s.
- Sıralı yazma 804 MB/s.
- Bir denetleyici arızalanırsa (sanal makine veya ana bilgisayarın arızalanması), performans düşüşü iki kat olur.
- Depolama diski arızalanırsa, düşüş 1/3'tür. Diskin yeniden oluşturulması, her denetleyicinin kaynaklarının %5'ini alır.
Küçük bir blokta, denetleyicinin (sanal makine) performansıyla sınırlıyız, CPU'su% 100 yüklü ve blok arttığında port bant genişliğiyle sınırlıyız. AllFlash sisteminin potansiyelini açığa çıkarmak için 10 Gbps yeterli değil. Ne yazık ki, sağlanan demo standının parametreleri 40 Gbit/s'de çalışmayı test etmemize izin vermiyor.
Testlerden ve mimari çalışmalarından edindiğim izlenime göre, verileri tüm ana bilgisayarlar arasına yerleştiren algoritma nedeniyle ölçeklenebilir, öngörülebilir bir performans elde ediyoruz, ancak bu aynı zamanda okuma sırasında da bir sınırlamadır çünkü yerel disklerden daha fazlasını sıkıştırmak mümkün olabilir. burada daha verimli bir ağ tasarrufu sağlanabilir, örneğin 40 Gbit/s hızında FI mevcuttur.
Ayrıca önbellekleme ve veri tekilleştirme için tek disk bir sınırlama olabilir; aslında bu test ortamında dört SSD diske yazabiliriz. Önbelleğe alma sürücülerinin sayısını artırıp farkı görebilmek harika olurdu.
Gerçek kullanım
Bir yedek veri merkezi düzenlemek için iki yaklaşım kullanabilirsiniz (uzak bir siteye yedekleme yapmayı düşünmüyoruz):
- Aktif pasif. Tüm uygulamalar ana veri merkezinde barındırılmaktadır. Çoğaltma eşzamanlı veya eşzamansız olabilir. Ana veri merkezi arızalanırsa yedek olanı etkinleştirmemiz gerekir. Bu manuel olarak/komut dosyaları/orkestrasyon uygulamalarıyla yapılabilir. Burada çoğaltma sıklığıyla orantılı bir RPO elde edeceğiz ve RTO, yöneticinin tepkisine ve becerilerine ve geçiş planının geliştirme/hata ayıklama kalitesine bağlıdır.
- Aktif-Aktif. Bu durumda, yalnızca eşzamanlı çoğaltma vardır; veri merkezlerinin kullanılabilirliği, kesinlikle üçüncü sitede bulunan bir yetersayı/hakem tarafından belirlenir. RPO = 0 ve RTO, 0'a (uygulama izin veriyorsa) ulaşabilir veya sanallaştırma kümesindeki bir düğümün yük devretme süresine eşit olabilir. Sanallaştırma düzeyinde Active-Active depolama gerektiren, uzatılmış (Metro) bir küme oluşturulur.
Genellikle müşterilerin ana veri merkezinde klasik depolama sistemine sahip bir mimariyi zaten uyguladıklarını görüyoruz, bu nedenle çoğaltma için başka bir mimari tasarlıyoruz. Bahsettiğim gibi Cisco HyperFlex, eşzamansız çoğaltma ve genişletilmiş sanallaştırma kümesi oluşturma olanağı sunuyor. Aynı zamanda, pahalı çoğaltma işlevlerine ve iki depolama sisteminde Aktif-Aktif veri erişimine sahip Orta Aralık seviyesi ve daha yüksek özel bir depolama sistemine ihtiyacımız yok.
1 betiği: VMware vSphere üzerinde birincil ve yedek veri merkezlerimiz, sanallaştırma platformumuz var. Tüm üretken sistemler ana veri merkezinde bulunur ve sanal makinelerin çoğaltılması hipervizör düzeyinde gerçekleştirilir; bu, VM'lerin yedek veri merkezinde açık kalmasını önleyecektir. Yerleşik araçları kullanarak veritabanlarını ve özel uygulamaları çoğaltıyoruz ve VM'leri açık tutuyoruz. Ana veri merkezinin arızalanması durumunda sistemleri yedek veri merkezinde devreye alıyoruz. 100’e yakın sanal makinemiz olduğunu düşünüyoruz. Birincil veri merkezi çalışır durumdayken yedek veri merkezi, birincil veri merkezinin değişmesi durumunda kapatılabilecek test ortamlarını ve diğer sistemleri çalıştırabilir. İki yönlü çoğaltma kullanmamız da mümkündür. Donanım açısından bakıldığında hiçbir şey değişmeyecek.
Klasik mimari durumunda, her veri merkezine FibreChannel üzerinden erişim, katmanlama, veri tekilleştirme ve sıkıştırma (ancak çevrimiçi değil), her site için 8 sunucu, 2 FibreChannel anahtar ve 10G Ethernet üzerinden erişime sahip bir hibrit depolama sistemi kuracağız. Klasik mimaride replikasyon ve anahtarlama yönetimi için VMware araçlarını (Replication + SRM) veya üçüncü parti araçları kullanabiliriz ki bu biraz daha ucuz ve bazen daha kullanışlı olacaktır.
Şekil diyagramı göstermektedir.
Cisco HyperFlex kullanıldığında aşağıdaki mimari elde edilir:
HyperFlex için büyük CPU/RAM kaynaklarına sahip sunucular kullandım çünkü... Kaynakların bir kısmı HyperFlex denetleyici VM'sine gidecek; hatta CPU ve bellek açısından, Cisco ile birlikte oynamamak ve geri kalan VM'ler için kaynakları garanti etmemek için HyperFlex yapılandırmasını biraz yeniden yapılandırdım. Ancak FibreChannel anahtarlarından vazgeçebiliriz ve her sunucu için Ethernet bağlantı noktalarına ihtiyacımız olmayacak; yerel trafik FI içerisinde anahtarlanır.
Sonuç, her veri merkezi için aşağıdaki konfigürasyondu:
Sunucular
8 x 1U Sunucu (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
Depolamak
FC Ön Uçlu hibrit depolama sistemi (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet anahtarı 10G 12 bağlantı noktası
-
SAN
2 x FC anahtarı 32/16Gb 24 bağlantı noktası
2 x Cisco UCS FI 6332
Lisanslar
VMware Ent Plus
VM anahtarlamanın çoğaltılması ve/veya düzenlenmesi
VMware Ent Plus
Hyperflex için çoğaltma yazılımı lisansları sağlamadım çünkü bu bizim için kutudan çıktığı gibi mevcut.
Klasik mimari için kendisini yüksek kaliteli ve ucuz bir üretici olarak kabul ettirmiş bir satıcıyı seçtim. Her iki seçenekte de belirli bir çözüm için standart indirimi uyguladım ve bunun sonucunda gerçek fiyatlar aldım.
Cisco HyperFlex çözümünün %13 daha ucuz olduğu ortaya çıktı.
2 betiği: iki aktif veri merkezinin oluşturulması. Bu senaryoda VMware üzerinde Stretched Cluster tasarlıyoruz.
Klasik mimari, sanallaştırma sunucuları, bir SAN (FC protokolü) ve aralarında uzanan birime okuma ve yazma yapabilen iki depolama sisteminden oluşur. Her depolama sistemine depolama için kullanışlı bir kapasite koyarız.
HyperFlex'te, her iki sitede de aynı sayıda düğüme sahip bir Stretch Cluster oluşturuyoruz. Bu durumda 2+2 çoğaltma faktörü kullanılır.
Sonuç aşağıdaki konfigürasyondur:
klasik mimari
HyperFlex
Sunucular
16 x 1U Sunucu (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
Depolamak
2 x AllFlash depolama sistemi (150 TB SSD)
-
LAN
4 x Ethernet anahtarı 10G 24 bağlantı noktası
-
SAN
4 x FC anahtarı 32/16Gb 24 bağlantı noktası
4 x Cisco UCS FI 6332
Lisanslar
VMware Ent Plus
VMware Ent Plus
Tüm hesaplamalarda ağ altyapısını, veri merkezi maliyetlerini vb. hesaba katmadım: bunlar klasik mimari ve HyperFlex çözümü için aynı olacaktır.
Maliyet açısından HyperFlex'in %5 daha pahalı olduğu ortaya çıktı. CPU/RAM kaynakları açısından Cisco'ya karşı bir çarpıklığım olduğunu burada belirtmekte fayda var çünkü konfigürasyonda bellek denetleyici kanallarını eşit şekilde doldurdum. Maliyet biraz daha yüksek, ancak büyüklük sırasına göre değil; bu, hiper yakınsamanın mutlaka "zenginler için bir oyuncak" olmadığını, ancak bir veri merkezi oluşturmaya yönelik standart yaklaşımla rekabet edebileceğini açıkça gösteriyor. Bu, halihazırda Cisco UCS sunucularına ve bunlara karşılık gelen altyapıya sahip olanların da ilgisini çekebilir.
Avantajları arasında, SAN ve depolama sistemlerini yönetme maliyetlerinin bulunmaması, çevrimiçi sıkıştırma ve veri tekilleştirme, destek için tek bir giriş noktası (sanallaştırma, sunucular, bunlar aynı zamanda depolama sistemleridir), yerden tasarruf (ancak her senaryoda değil), operasyonu basitleştirmek.
Desteğe gelince, burada tek bir satıcıdan, Cisco'dan alıyorsunuz. Cisco UCS sunucularındaki deneyimime bakılırsa hoşuma gitti; HyperFlex'te açmama gerek kalmadı, her şey aynı şekilde çalıştı. Mühendisler anında yanıt verir ve yalnızca tipik sorunları değil aynı zamanda karmaşık uç durumları da çözebilir. Bazen onlara şu sorularla dönüyorum: "Bunu yapmak mümkün mü, siktir et?" veya “Burada bir şey yapılandırdım ve çalışmak istemiyor. Yardım!" - orada sabırla gerekli rehberi bulup doğru eylemleri gösterecekler, “Biz sadece donanım sorunlarını çözüyoruz” diye cevap vermeyecekler.
referanslar
- Postam - [e-posta korumalı]
Kaynak: habr.com