Dëst ass e Mythos deen zimlech heefeg ass am Beräich vun der Serverhardware. An der Praxis gi hyperkonvergéiert Léisungen (wann alles an engem ass) fir vill Saachen gebraucht. Historesch goufen déi éischt Architekturen vun Amazon a Google fir hir Servicer entwéckelt. Duerno war d'Iddi fir e Rechenbauerenhaff aus identesche Wirbelen ze maachen, déi jidderee seng eegen Disken haten. All dëst gouf vun e puer System-Formatioun Software (Hypervisor) vereenegt a war an virtuell Maschinnen opgedeelt. D'Haaptziel ass e Minimum vun Effort fir een Node ze servéieren an e Minimum vu Probleemer beim Skaléieren: kaaft just nach eng dausend oder zwee vun de selwechte Serveren a verbënnt se an der Géigend. An der Praxis sinn dës isoléiert Fäll, a vill méi dacks schwätze mer vun enger méi klenger Zuel vu Wirbelen an eng liicht aner Architektur.
Awer de Plus bleift d'selwecht - onheemlech Liichtegkeet vu Skalen a Gestioun. De Nodeel ass datt verschidden Aufgaben Ressourcen anescht verbrauchen, an op e puer Plazen gëtt et vill lokal Disken, an anerer gëtt et wéineg RAM, a sou weider, dat ass, fir verschidden Aarte vun Aufgaben, wäert d'Ressourcenotzung erofgoen.
Et stellt sech eraus datt Dir 10-15% méi bezuelt fir einfach ze konfiguréieren. Dëst ass wat de Mythos am Titel ausgeléist huet. Mir hunn laang gesicht no wou d'Technologie optimal géif applizéiert ginn, a mir hunn et fonnt. D'Tatsaach ass, datt Cisco net seng eege Stockage Systemer hunn, mä si wollten eng komplett Server Maart. A si hunn Cisco Hyperflex gemaach - eng Léisung mat lokalen Späicheren op Noden.
An dëst huet sech op eemol eng ganz gutt Léisung fir Backupdatenzentren (Disaster Recovery) erausgestallt. Ech wäert Iech elo soen firwat a wéi. An ech weisen Iech d'Cluster Tester.
Wou néideg
Hyperkonvergenz ass:
- Iwwerdroung vun Disken op Computernoden.
- Voll Integratioun vum Späichersubsystem mam Virtualiséierungssubsystem.
- Transfert / Integratioun mam Reseau Subsystem.
Dës Kombinatioun erlaabt Iech vill Späichersystemfeatures um Virtualiséierungsniveau ëmzesetzen an alles aus enger Kontrollfenster.
An eiser Gesellschaft si Projete fir redundante Rechenzentren ze designen grouss Nofro, an eng hyperkonvergéiert Léisung gëtt dacks gewielt wéinst enger Rëtsch Replikatiounsoptiounen (bis zu engem Metrocluster) aus der Këscht.
Am Fall vu Backup-Datenzentren schwätze mir normalerweis vun enger Fernsanlag op engem Site op der anerer Säit vun der Stad oder an enger anerer Stad ganz. Et erlaabt Iech kritesch Systemer am Fall vun engem deelweis oder kompletten Ausfall vum Haaptrechenzentrum ze restauréieren. Verkafsdaten ginn dauernd do replizéiert, an dës Replikatioun kann um Applikatiounsniveau oder um Blockapparat (Späichere) Niveau sinn.
Dofir wäert ech elo iwwer de Systemdesign an Tester schwätzen, an dann iwwer e puer real-Liewen Applikatiounsszenarie mat Spuerdaten.
Tester
Eis Instanz besteet aus véier Serveren, jidderee vun deenen 10 SSD Drive vun 960 GB huet. Et gëtt eng dedizéierten Disk fir Schreifoperatiounen ze cachen an de Service virtuelle Maschinn ze späicheren. D'Léisung selwer ass déi véiert Versioun. Déi éischt ass éierlech gesot rau (vu Rezensiounen beuerteelen), déi zweet ass fiicht, déi drëtt ass scho relativ stabil, an dëst kann e Verëffentlechung nom Enn vum Beta-Test fir d'Allgemengheet genannt ginn. Wärend dem Test hunn ech keng Probleemer gesinn, alles funktionnéiert wéi eng Auer.
D'Ännerung am V4Eng Rëtsch Käfere goufen fixéiert.
Am Ufank konnt d'Plattform nëmme mam VMware ESXi Hypervisor schaffen an eng kleng Zuel vu Wirbelen ënnerstëtzt hunn. Och den Deploymentprozess ass net ëmmer erfollegräich ofgeschloss, e puer Schrëtt hu missen nei gestart ginn, et goufe Probleemer mat der Aktualiséierung vun eelere Versiounen, Daten an der GUI goufen net ëmmer richteg ugewisen (obwuel ech nach ëmmer net zefridden sinn mat der Affichage vun de Leeschtungsgrafiken ), heiansdo Problemer op der Interface mat Virtualiséierung entstanen.
Elo sinn all Kandheetsproblemer fixéiert, HyperFlex ka souwuel ESXi wéi och Hyper-V handhaben, plus et ass méiglech:
- Schafen vun engem gestreckt Cluster.
- E Cluster fir Büroen erstellen ouni Fabric Interconnect ze benotzen, vun zwee bis véier Noden (mir kafen nëmmen Serveren).
- Fäegkeet fir mat externe Späichersystemer ze schaffen.
- Ënnerstëtzung fir Container a Kubernetes.
- Schafung vun Disponibilitéit Zonen.
- Integratioun mat VMware SRM wann déi agebaute Funktionalitéit net zefriddestellend ass.
D'Architektur ass net vill anescht wéi d'Léisunge vu sengen Haaptkonkurrenten, si hunn kee Vëlo erstallt. Et leeft alles op der VMware oder Hyper-V Virtualiséierungsplattform. D'Hardware gëtt op propriétaire Cisco UCS Server gehost. Et ginn déi, déi d'Plattform haassen fir d'relativ Komplexitéit vum initialen Setup, vill Knäppercher, en net-triviale System vu Templates an Ofhängegkeeten, awer et ginn och déi, déi Zen geléiert hunn, vun der Iddi inspiréiert sinn an net méi wëllen fir mat anere Serveren ze schaffen.
Mir wäerten d'Léisung fir VMware berücksichtegen, well d'Léisung ursprénglech dofir erstallt gouf a méi Funktionalitéit huet; Hyper-V gouf laanscht de Wee bäigefüügt fir mat Konkurrenten ze halen an Maart Erwaardungen z'erreechen.
Et gëtt e Stärekoup vu Servere voller Disken. Et gi Disken fir Datelagerung (SSD oder HDD - no Ärem Goût a Bedierfnesser), et gëtt eng SSD Disk fir Cache. Wann Dir Daten an den Datastore schreift, ginn d'Donnéeën op der Cachingschicht gespäichert (eng SSD Disk an RAM vum Service VM). Parallel gëtt e Block vun Daten un Noden am Cluster geschéckt (d'Zuel vun den Noden hänkt vum Cluster Replikatiounsfaktor of). No Bestätegung vun all Wirbelen iwwer erfollegräich Opnahmen, Bestätegung vun der Opnam gëtt un den Hypervisor geschéckt an dann un de VM. Déi opgeholl Daten ginn deduplizéiert, kompriméiert a geschriwwe op Späicherdisken am Hannergrond. Zur selwechter Zäit gëtt e grousse Block ëmmer op d'Späicherplacke geschriwwe a sequentiell, wat d'Laascht op d'Späicherplacke reduzéiert.
Deduplication a Kompressioun sinn ëmmer aktivéiert a kënnen net behënnert ginn. D'Donnéeë ginn direkt vu Späicherdisken oder vum RAM Cache gelies. Wann eng Hybridkonfiguratioun benotzt gëtt, ginn d'Liesen och op der SSD cache.
D'Donnéeën sinn net un déi aktuell Positioun vun der virtueller Maschinn gebonnen a si gläichméisseg tëscht den Noden verdeelt. Dës Approche erlaabt Iech all Disken an Netzwierkschnëttplazen gläich ze lueden. Et gëtt en offensichtlechen Nodeel: mir kënnen d'Lieslatenz net sou vill wéi méiglech reduzéieren, well et keng Garantie fir Datenverfügbarkeet lokal ass. Awer ech gleewen datt dëst e klengt Opfer ass am Verglach zu de Virdeeler déi kritt ginn. Ausserdeem hunn d'Netzverzögerungen esou Wäerter erreecht datt se praktesch net d'Gesamtresultat beaflossen.
E spezielle Service VM Cisco HyperFlex Data Plattform Controller, deen op all Späicherknuet erstallt gëtt, ass verantwortlech fir déi ganz Operatiounslogik vum Disk Subsystem. An eiser Service VM Konfiguratioun goufen aacht vCPUs an 72 GB RAM zougewisen, wat net sou wéineg ass. Loosst mech Iech drun erënneren datt de Host selwer 28 kierperlech Kären an 512 GB RAM huet.
De Service VM huet Zougang zu kierperlechen Disken direkt andeems de SAS Controller op de VM weidergeleet gëtt. D'Kommunikatioun mam Hypervisor geschitt duerch e spezielle Modul IOVisor, deen ech / O Operatiounen offënnt, a benotzt en Agent deen Iech erlaabt Kommandoen op den Hypervisor API ze schécken. Den Agent ass verantwortlech fir mat HyperFlex Snapshots a Klonen ze schaffen.
Disk Ressourcen sinn am Hypervisor als NFS oder SMB Shares montéiert (je no der Art vum Hypervisor, roden wéi een ass wou). An ënner der Hood ass dëst e verdeelt Dateiesystem deen Iech erlaabt Features vun erwuessene vollwäertege Späichersystemer ze addéieren: dënn Volumenallokatioun, Kompressioun an Deduplikatioun, Snapshots mat Redirect-on-Write Technologie, Synchron / Asynchron Replikatioun.
De Service VM bitt Zougang zu der WEB Management Interface vum HyperFlex Subsystem. Et gëtt Integratioun mat vCenter, an déi meescht alldeeglech Aufgaben kënnen dovun ausgefouert ginn, awer Datastores, zum Beispill, si méi praktesch aus enger separater Webcam ze schneiden wann Dir schonn op eng séier HTML5 Interface gewiesselt sidd oder e vollwäertege Flash Client benotzt mat voller Integratioun. Am Service Webcam kënnt Dir d'Performance an den detailléierte Status vum System kucken.
Et gëtt eng aner Zort Node an engem Cluster - Rechenknäppchen. Dës kënne Rack- oder Bladeserver sinn ouni agebaute Disken. Dës Servere kënnen VMs lafen, deenen hir Donnéeën op Servere mat Disken gespäichert ginn. Aus der Siicht vum Datezougang ass et keen Ënnerscheed tëscht den Aarte vu Wirbelen, well d'Architektur Abstraktioun aus der kierperlecher Lag vun den Daten involvéiert. De maximale Verhältnis vu Rechenknäppchen a Späicherknäppchen ass 2:1.
D'Benotzung vun Rechenknäppchen erhéicht d'Flexibilitéit beim Skaléieren vun de Clusterressourcen: mir mussen keng zousätzlech Node mat Disken kafen wa mir nëmmen CPU / RAM brauchen. Zousätzlech, kënne mir e Blade Cage dobäi a retten op Rack Placement vun Serveren.
Als Resultat hu mir eng hyperkonvergéiert Plattform mat de folgende Funktiounen:
- Bis zu 64 Wirbelen an engem Cluster (bis zu 32 Späichernoden).
- D'Mindestzuel un Noden an engem Cluster ass dräi (zwee fir en Edge Cluster).
- Date Redundanzmechanismus: Spigelen mam Replikatiounsfaktor 2 an 3.
- Metro Cluster.
- Asynchron VM Replikatioun op en aneren HyperFlex Cluster.
- Orchesteréierung fir VMs op e Fern-Datenzentrum ze wiesselen.
- Native Schnappschëss mat Redirect-on-Write Technologie.
- Bis zu 1 PB vum benotzbare Raum um Replikatiounsfaktor 3 an ouni Deduplikatioun. Mir huelen net Rechnung Replikatioun Faktor 2, well dëst ass keng Optioun fir sérieux Ofsaz.
En anere grousse Plus ass Einfachheet vu Gestioun an Deployment. All d'Komplexitéite vun der Ariichten vun UCS Server gi vun engem spezialiséierte VM gesuergt, dee vu Cisco Ingenieuren virbereet ass.
Testbänk Konfiguratioun:
- 2 x Cisco UCS Stoffer Interconnect 6248UP als Gestioun Stärekoup an Reseau Komponente (48 Häfen Betribssystemer an Ethernet 10G / FC 16G Modus).
- Véier Cisco UCS HXAF240 M4 Serveren.
Server Charakteristiken:
cpu
2 x Intel® Xeon® E5-2690 v4
Ram
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
Network
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet Häfen
Stockage HBA
Cisco 12G Modular SAS Duerchgäng Controller
Stockage Disken
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Méi Configuratioun OptiounenZousätzlech zu der gewielter Hardware sinn déi folgend Optiounen am Moment verfügbar:
- HXAF240c M5.
- Een oder zwee CPUs rangéiert vun Intel Silver 4110 bis Intel Platin I8260Y. Zweet Generatioun verfügbar.
- 24 Erënnerung Plaze, Läischte vun 16 GB RDIMM 2600 ze 128 GB LRDIMM 2933.
- Vu 6 bis 23 Datendisken, eng Cachedisk, eng Systemdisk an eng Bootdisk.
Kapazitéit Drive
- HX-SD960G61X-EV 960GB 2.5 Zoll Enterprise Wäert 6G SATA SSD (1X Ausdauer) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5 Zoll Enterprise Wäert 6G SATA SSD (1X Ausdauer) SAS 3.8 TB.
- Cache Drive
- HX-NVMEXPB-I375 375GB 2.5 Zoll Intel Optane Drive, Extrem Perf & Ausdauer.
- HX-NVMEHW-H1600* 1.6TB 2.5 Zoll Ent. Perf. NVMe SSD (3X Ausdauer) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 Zoll Ent. Perf. 12G SAS SSD (10X Ausdauer) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 Zoll Ent. Perf. 12G SAS SED SSD (10X Ausdauer) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 Zoll Enterprise Leeschtung 12G SAS SSD (3X Ausdauer).
System / Log Fuert
- HX-SD240GM1X-EV 240GB 2.5 Zoll Enterprise Value 6G SATA SSD (Verlaangt Upgrade).
Boot Fuert
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Connect op d'Netz iwwer 40G, 25G oder 10G Ethernet Häfen.
De FI kann HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G) sinn.
Den Test selwer
Fir den Disk Subsystem ze testen, hunn ech HCIBench 2.2.1 benotzt. Dëst ass e gratis Utility dat Iech erlaabt d'Schafung vun enger Laascht vu ville virtuelle Maschinnen ze automatiséieren. D'Laascht selwer gëtt vun der üblecher Fio generéiert.
Eise Stärekoup besteet aus véier Wirbelen, Replikatiounsfaktor 3, all Disken sinn Flash.
Fir Testen hunn ech véier Datastores an aacht virtuelle Maschinnen erstallt. Fir Schreiftester gëtt ugeholl datt de Cachedisk net voll ass.
D'Testresultater si wéi follegt:
100% liesen 100% Zoufall
0% Liesen 100% Zoufälleg
Block / Schlaang Déift
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36ms 374348 IOPS
2.47 ms 414116 IOPS
4,86ms 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
Fett weist Wäerter un, no deenen et keng Erhéijung vun der Produktivitéit ass, heiansdo souguer Verschlechterung sichtbar. Dëst ass wéinst der Tatsaach datt mir limitéiert sinn duerch d'Leeschtung vum Netzwierk / Controller / Disken.
- Sequentiell liesen 4432 MB / s.
- Sequentiell Schreiwen 804 MB / s.
- Wann ee Controller feelt (Feele vun enger virtueller Maschinn oder Host), ass d'Leeschtungsfall zweefalt.
- Wann d'Späicherplack klappt, ass d'Downdown 1/3. Disk Rebuild hëlt 5% vun de Ressourcen vun all Controller.
Op engem klenge Block si mir limitéiert duerch d'Performance vum Controller (virtuell Maschinn), seng CPU gëtt op 100% gelueden, a wann de Block eropgeet, gi mir limitéiert duerch d'Portbandbreedung. 10 Gbps ass net genuch fir d'Potenzial vum AllFlash System ze spären. Leider erlaben d'Parameteren vum zur Verfügung gestallt Demo Stand eis net d'Operatioun bei 40 Gbit / s ze testen.
A mengem Androck vun Tester an d'Architektur studéieren, wéinst dem Algorithmus deen Daten tëscht all Hosten placéiert, kréie mir skalierbar, prévisibel Leeschtung, awer dëst ass och eng Begrenzung beim Liesen, well et méiglech wier méi aus lokalen Disken erauszekréien, hei kann et e méi produktivt Netzwierk spueren, zum Beispill, FI bei 40 Gbit / s ass verfügbar.
Och eng Disk fir Caching an Deduplikatioun kann eng Begrenzung sinn; Tatsächlech, an dësem Testbed kënne mir op véier SSD Disks schreiwen. Et wier super fir d'Zuel vun de Caching Drive ze erhéijen an den Ënnerscheed ze gesinn.
Real Notzung
Fir e Backup-Datenzentrum z'organiséieren, kënnt Dir zwou Approche benotzen (mir betruechten net e Backup op enger Remote Site ze placéieren):
- Aktiv-Passiv. All Uwendunge ginn am Haaptrechenzentrum gehost. Replikatioun ass synchron oder asynchron. Wann den Haaptdatenzentrum klappt, musse mir de Backup aktivéieren. Dëst kann manuell gemaach ginn / Scripten / Orchestratioun Uwendungen. Hei kréie mir e RPO entspriechend der Replikatiounsfrequenz, an d'RTO hänkt vun der Reaktioun a Fäegkeeten vum Administrator an der Qualitéit vun der Entwécklung / Debugging vum Schaltplang of.
- Aktiv-Aktiv. An dësem Fall gëtt et nëmmen eng synchron Replikatioun; d'Disponibilitéit vun den Datenzenter gëtt vun engem Quorum / Arbiter festgeluecht strikt um drëtte Site. RPO = 0, an RTO kann 0 erreechen (wann d'Applikatioun erlaabt) oder gläich wéi d'Failoverzäit vun engem Node an engem Virtualiséierungscluster. Um Virtualiséierungsniveau gëtt e gestreckte (Metro) Cluster erstallt deen Active-Active Späichere erfuerdert.
Normalerweis gesi mir datt d'Clienten schonn eng Architektur mat engem klassesche Späichersystem am Haaptrechenzentrum implementéiert hunn, sou datt mir eng aner fir Replikatioun designen. Wéi ech erwähnt, bitt Cisco HyperFlex asynchrone Replikatioun a gestreckt Virtualiséierungscluster Kreatioun. Zur selwechter Zäit brauche mir keen dedizéierten Späichersystem vum Midrange-Niveau a méi héich mat deier Replikatiounsfunktiounen an Active-Active Datenzougang op zwee Späichersystemer.
Szenario 1: Mir hunn eng Primär- a Backup-Datenzentren, eng Virtualiséierungsplattform op VMware vSphere. All produktiv Systemer sinn am Haaptrechenzentrum lokaliséiert, a Replikatioun vu virtuelle Maschinnen gëtt um Hypervisorniveau gemaach, dëst wäert vermeiden datt VMs am Backup-Datenzentrum ageschalt ginn. Mir replizéieren Datenbanken a speziell Uwendungen mat agebaute Tools an halen d'VMs ageschalt. Wann den Haaptdatenzentrum klappt, starten mir Systemer am Backup-Datenzentrum. Mir gleewen datt mir ongeféier 100 virtuell Maschinnen hunn. Wärend de primäre Rechenzentrum operationell ass, kann de Standby-Datenzentrum Testëmfeld an aner Systemer lafen, déi ausgeschalt kënne ginn, wann de primäre Rechenzentrum ëmschalt. Et ass och méiglech datt mir zwee-Wee Replikatioun benotzen. Vun engem Hardware Siicht wäert näischt änneren.
Am Fall vun der klassescher Architektur wäerte mir an all Datenzenter en Hybridspeichersystem mat Zougang iwwer FibreChannel, Tiering, Deduplication a Kompressioun (awer net online), 8 Server fir all Site, 2 FibreChannel Schalter an 10G Ethernet installéieren. Fir Replikatioun a Schaltmanagement an enger klassescher Architektur kënne mir VMware Tools (Replikatioun + SRM) oder Drëtt Partei Tools benotzen, déi e bësse méi bëlleg an heiansdo méi praktesch sinn.
D'Figur weist d'Diagramm.
Wann Dir Cisco HyperFlex benotzt, gëtt déi folgend Architektur kritt:
Fir HyperFlex hunn ech Server mat grousse CPU / RAM Ressourcen benotzt, well ... E puer vun de Ressourcen ginn op den HyperFlex Controller VM; wat CPU an Erënnerung ugeet, hunn ech souguer d'HyperFlex Konfiguratioun e bëssen nei konfiguréiert fir net mat Cisco ze spillen a Ressourcen fir déi verbleiwen VMs ze garantéieren. Awer mir kënnen FibreChannel Schalter opginn, a mir brauche keng Ethernet Ports fir all Server; lokalen Traffic gëtt bannent FI gewiesselt.
D'Resultat war déi folgend Konfiguratioun fir all Datenzenter:
Serveren
8 x 1U Server (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)
SHD
Hybrid Späichersystem mat FC Front-End (20TB SSD, 130TB NL-SAS)
-
Lan
2 x Ethernet schalt 10G 12 Häfen
-
SAN
2 x FC Schalter 32/16Gb 24 Häfen
2 x Cisco UCS FI 6332
Lizenzen
VMware Ent Plus
Replikatioun an / oder Orchestratioun vum VM-Schalten
VMware Ent Plus
Ech hunn keng Replikatiounssoftwarelizenzen fir Hyperflex geliwwert, well dëst aus der Këscht fir eis verfügbar ass.
Fir klassesch Architektur hunn ech e Verkeefer gewielt, dee sech als qualitativ héichwäerteg a preiswert Hiersteller etabléiert huet. Fir béid Optiounen hunn ech d'Standard Rabatt fir eng spezifesch Léisung applizéiert, an als Resultat hunn ech real Präisser kritt.
D'Cisco HyperFlex Léisung huet sech 13% méi bëlleg erausgestallt.
Szenario 2: Schafung vun zwee aktive Datenzenteren. An dësem Szenario designe mir e gestreckte Cluster op VMware.
Déi klassesch Architektur besteet aus Virtualiséierungsserver, e SAN (FC Protokoll) an zwee Späichersystemer déi de Volume tëscht hinnen liesen a schreiwen kënnen. Op all Späichersystem setzen mir eng nëtzlech Kapazitéit fir d'Lagerung.
Bei HyperFlex kreéiere mir einfach e Stretch Cluster mat der selwechter Unzuel vun Noden op béide Site. An dësem Fall gëtt e Replikatiounsfaktor vun 2+2 benotzt.
D'Resultat ass déi folgend Konfiguratioun:
klassesch Architektur
HyperFlex
Serveren
16 x 1U Server (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)
SHD
2 x AllFlash Späichersystemer (150 TB SSD)
-
Lan
4 x Ethernet schalt 10G 24 Häfen
-
SAN
4 x FC Schalter 32/16Gb 24 Häfen
4 x Cisco UCS FI 6332
Lizenzen
VMware Ent Plus
VMware Ent Plus
An all Berechnungen hunn ech net d'Netzinfrastruktur, d'Käschte vum Datenzenter, asw.
Wat d'Käschte ugeet, huet HyperFlex 5% méi deier erausgestallt. Et ass derwäert ze notéieren datt ech a punkto CPU / RAM Ressourcen e Schief fir Cisco haten, well an der Konfiguratioun hunn ech d'Erënnerungskontrollerkanäl gläichméisseg gefëllt. D'Käschte si liicht méi héich, awer net duerch eng Uerdnung vun der Gréisst, wat kloer beweist datt d'Hyperkonvergenz net onbedéngt e "Spillsaach fir déi Räich" ass, awer mat der Standard Approche fir en Rechenzentrum ze bauen. Dëst kann och interessant sinn fir déi, déi scho Cisco UCS Server an déi entspriechend Infrastruktur fir si hunn.
Ënnert de Virdeeler kréien mir d'Feele vu Käschten fir d'Verwaltung vu SAN a Späichersystemer, Online Kompressioun an Deduplikatioun, een eenzegen Entrée fir Ënnerstëtzung (Virtualiséierung, Server, si sinn och Späichersystemer), Plaz spueren (awer net an all Szenarie), Vereinfachung Operatioun.
Wéi fir Ënnerstëtzung, hei kritt Dir et vun engem Verkeefer - Cisco. No menger Erfahrung mat Cisco UCS Server beurteelen, hunn ech et gär; Ech hunn et net missen op HyperFlex opmaachen, alles huet just d'selwecht geschafft. Ingenieuren reagéieren prompt a kënnen net nëmmen typesch Probleemer léisen, awer och komplex Randfäll. Heiansdo wenden ech mech mat Froen un hinnen: "Ass et méiglech dat ze maachen, schrauwen et?" oder "Ech hunn eppes hei konfiguréiert, an et wëll net schaffen. Hëllef!" - si wäerte gedëlleg den néidege Guide do fannen a weisen op déi richteg Aktiounen; si äntweren net: "Mir léisen nëmmen Hardwareproblemer."
Referenze
- Meng Mail - [Email geschützt]
Source: will.com