Ĉi tio estas mito sufiĉe ofta en la kampo de servila aparataro. En praktiko, hiperkonverĝaj solvoj (kiam ĉio estas en unu) estas necesaj por multaj aferoj. Historie, la unuaj arkitekturoj estis evoluigitaj de Amazon kaj Google por siaj servoj. Tiam la ideo estis fari komputikan bienon el identaj nodoj, el kiuj ĉiu havis siajn proprajn diskojn. Ĉio ĉi estis kunigita per iu sistemforma programaro (hipervisor) kaj estis dividita en virtualajn maŝinojn. La ĉefa celo estas minimumo de penado por priservado de unu nodo kaj minimumo de problemoj dum grimpado: simple aĉetu pliajn mil aŭ du el la samaj serviloj kaj konekti ilin proksime. En la praktiko, ĉi tiuj estas izolitaj kazoj, kaj multe pli ofte ni parolas pri pli malgranda nombro da nodoj kaj iomete malsama arkitekturo.
Sed la pluso restas la sama - nekredebla facileco de skalado kaj administrado. La malavantaĝo estas, ke malsamaj taskoj konsumas rimedojn malsame, kaj en kelkaj lokoj estos multaj lokaj diskoj, en aliaj estos malmulte da RAM, kaj tiel plu, tio estas, por malsamaj specoj de taskoj, resursa utiligo malpliiĝos.
Montriĝas, ke vi pagas 10–15% pli por facileco de aranĝo. Jen kio ekfunkciigis la miton en la titolo. Ni pasigis longan tempon serĉante kie la teknologio estus optimume aplikata, kaj ni trovis ĝin. Fakte, Cisco ne havis siajn proprajn stokadsistemojn, sed ili volis kompletan servilan merkaton. Kaj ili faris Cisco Hyperflex - solvo kun loka stokado sur nodoj.
Kaj ĉi tio subite montriĝis tre bona solvo por rezervaj datumcentroj (Disaster Recovery). Mi diros al vi kial kaj kiel nun. Kaj mi montros al vi la grapoltestojn.
Kie bezonate
Hiperkonverĝo estas:
- Transdono de diskoj al komputaj nodoj.
- Plena integriĝo de la stokadsubsistemo kun la virtualigsubsistemo.
- Transdono/integriĝo kun la reto-subsistemo.
Ĉi tiu kombinaĵo ebligas al vi efektivigi multajn stokadsistemojn ĉe la virtualiga nivelo kaj ĉio de unu kontrolfenestro.
En nia firmao, projektoj por desegni redundajn datumcentrojn estas tre postulataj, kaj hiperkonverĝa solvo ofte estas elektita pro amaso da replikaj elektoj (ĝis metrogrupo) el la skatolo.
En la kazo de rezervaj datumcentroj, ni kutime parolas pri fora instalaĵo sur loko aliflanke de la urbo aŭ en alia urbo entute. Ĝi permesas restarigi kritikajn sistemojn en la okazo de parta aŭ kompleta fiasko de la ĉefa datumcentro. Vendaj datumoj estas konstante reproduktitaj tie, kaj ĉi tiu reproduktado povas esti ĉe la aplika nivelo aŭ ĉe la bloka aparato (stokado).
Tial nun mi parolos pri la sistemo-dezajno kaj testoj, kaj poste pri kelkaj realvivaj aplikaĵscenaroj kun ŝpardatumoj.
Provoj
Nia ekzemplo konsistas el kvar serviloj, ĉiu el kiuj havas 10 SSD-diskojn de 960 GB. Estas diligenta disko por konservado de skribaj operacioj kaj stokado de la servo virtuala maŝino. La solvo mem estas la kvara versio. La unua estas sincere kruda (se juĝante laŭ la recenzoj), la dua estas malseka, la tria jam estas sufiĉe stabila, kaj ĉi tiu povas esti nomita eldono post la fino de beta-testado por la ĝenerala publiko. Dum testado mi ne vidis problemojn, ĉio funkcias kiel horloĝo.
Ŝanĝoj en v4Aro da eraroj estis korektitaj.
Komence, la platformo povis funkcii nur kun la hiperviziero VMware ESXi kaj subtenis malgrandan nombron da nodoj. Ankaŭ, la deplojprocezo ne ĉiam finiĝis sukcese, kelkaj paŝoj devis esti rekomencitaj, estis problemoj kun ĝisdatigo de pli malnovaj versioj, datumoj en la GUI ne ĉiam estis montritaj ĝuste (kvankam mi ankoraŭ ne estas kontenta pri la montrado de agado-grafikoj. ), foje problemoj ekestis ĉe la interfaco kun virtualigo .
Nun ĉiuj infanaj problemoj estas solvitaj, HyperFlex povas trakti ambaŭ ESXi kaj Hyper-V, krome eblas:
- Kreante streĉitan areton.
- Krei areton por oficejoj sen uzi Fabric Interconnect, de du ĝis kvar nodoj (ni aĉetas nur servilojn).
- Kapablo labori kun eksteraj stokaj sistemoj.
- Subteno por ujoj kaj Kubernetes.
- Kreado de haveblecaj zonoj.
- Integriĝo kun VMware SRM se la enkonstruita funkcieco ne estas kontentiga.
La arkitekturo ne multe diferencas de la solvoj de siaj ĉefaj konkurantoj; ili ne kreis biciklon. Ĉio funkcias sur la platformo de virtualigo VMware aŭ Hyper-V. La aparataro estas gastigita sur proprietaj Cisco UCS-serviloj. Estas tiuj, kiuj malamas la platformon pro la relativa komplekseco de la komenca agordo, multaj butonoj, ne-triviala sistemo de ŝablonoj kaj dependecoj, sed ankaŭ estas tiuj, kiuj lernis Zen, estas inspiritaj de la ideo kaj ne plu volas. labori kun aliaj serviloj.
Ni konsideros la solvon por VMware, ĉar la solvo estis origine kreita por ĝi kaj havas pli da funkcieco; Hyper-V estis aldonita survoje por daŭrigi kun konkurantoj kaj renkonti merkatajn atendojn.
Estas aro da serviloj plenaj de diskoj. Estas diskoj por konservado de datumoj (SSD aŭ HDD - laŭ via gusto kaj bezonoj), ekzistas unu SSD-disko por kaŝmemoro. Skribante datumojn al la datumbutiko, la datumoj estas konservitaj sur la kaŝmemortavolo (diligenta SSD-disko kaj RAM de la servo VM). Paralele, bloko de datenoj estas sendita al nodoj en la areto (la nombro da nodoj dependas de la cluster-reproduktadfaktoro). Post konfirmo de ĉiuj nodoj pri sukcesa registrado, konfirmo de la registrado estas sendita al la hiperviziero kaj poste al la VM. La registritaj datumoj estas deduplikataj, kunpremitaj kaj skribitaj al stokaj diskoj en la fono. Samtempe, granda bloko estas ĉiam skribita al la stokaj diskoj kaj sinsekve, kio reduktas la ŝarĝon sur la stokaj diskoj.
Maldupliko kaj kunpremado estas ĉiam ebligitaj kaj ne povas esti malŝaltitaj. Datenoj estas legitaj rekte el stokaj diskoj aŭ el la RAM-kaŝmemoro. Se hibrida agordo estas uzata, la legaĵoj ankaŭ estas konservitaj en kaŝmemoro sur la SSD.
La datumoj ne estas ligitaj al la nuna loko de la virtuala maŝino kaj estas distribuitaj egale inter la nodoj. Ĉi tiu aliro permesas al vi ŝargi ĉiujn diskojn kaj retajn interfacojn egale. Estas evidenta malavantaĝo: ni ne povas redukti la legan latencian kiel eble plej multe, ĉar ne ekzistas garantio pri la havebleco de datumoj loke. Sed mi kredas, ke tio estas negrava ofero kompare kun la profitoj ricevitaj. Krome, retaj prokrastoj atingis tiajn valorojn, ke ili preskaŭ ne influas la ĝeneralan rezulton.
Speciala servo VM Cisco HyperFlex Data Platform-regilo, kiu estas kreita sur ĉiu stoka nodo, respondecas pri la tuta operacia logiko de la disksubsistemo. En nia servo VM-agordo, ok vCPU-oj kaj 72 GB da RAM estis asignitaj, kio ne estas tiom malmulte. Mi memorigu vin, ke la gastiganto mem havas 28 fizikajn kernojn kaj 512 GB da RAM.
La servo VM havas aliron al fizikaj diskoj rekte plusendante la SAS-regilon al la VM. Komunikado kun la hiperviziero okazas per speciala modulo IOVisor, kiu kaptas I/O-operaciojn, kaj uzante agenton, kiu ebligas al vi sendi komandojn al la hiperviziero API. La agento respondecas pri laboro kun HyperFlex-fotoj kaj klonoj.
Diskaj rimedoj estas muntitaj en la hiperviziero kiel NFS aŭ SMB-akcioj (depende de la speco de hiperviziero, divenu kiu estas kie). Kaj sub la kapuĉo, ĉi tio estas distribuita dosiersistemo, kiu ebligas al vi aldoni funkciojn de plenkreskaj stokadsistemoj: maldika voluma atribuo, kunpremado kaj deduplikado, momentfotoj per Redirect-on-Write teknologio, sinkrona/nesinkrona reproduktado.
La servo VM disponigas aliron al la WEB-administra interfaco de la subsistemo HyperFlex. Estas integriĝo kun vCenter, kaj la plej multaj ĉiutagaj taskoj povas esti faritaj de ĝi, sed datumvendejoj, ekzemple, estas pli oportune tranĉi de aparta retkamerao se vi jam ŝanĝis al rapida HTML5-interfaco, aŭ uzi plentaŭgan Flash-klienton. kun plena integriĝo. En la serva retkamerao vi povas vidi la agadon kaj detalan staton de la sistemo.
Estas alia speco de nodo en areto - komputaj nodoj. Tiuj povas esti rako aŭ klingoserviloj sen enkonstruitaj diskoj. Ĉi tiuj serviloj povas ruli VMs kies datumoj estas stokitaj sur serviloj kun diskoj. De la perspektivo de datenaliro, ekzistas neniu diferenco inter la specoj de nodoj, ĉar la arkitekturo implikas abstraktadon de la fizika loko de la datenoj. La maksimuma rilatumo de komputiknodoj al stokadnodoj estas 2:1.
Uzado de komputaj nodoj pliigas flekseblecon dum skalado de clusterresursoj: ni ne devas aĉeti pliajn nodojn kun diskoj se ni bezonas nur CPU/RAM. Krome, ni povas aldoni klingokaĝon kaj ŝpari sur raka lokigo de serviloj.
Kiel rezulto, ni havas hiperkonverĝan platformon kun la sekvaj funkcioj:
- Ĝis 64 nodoj en areto (ĝis 32 stokaj nodoj).
- La minimuma nombro da nodoj en areto estas tri (du por Edge-areto).
- Datenredunda mekanismo: spegulado kun reproduktadfaktoro 2 kaj 3.
- Metroa areto.
- Nesinkrona VM-reproduktado al alia HyperFlex-areto.
- Orkestrado de ŝanĝado de VM-oj al fora datumcentro.
- Indiĝenaj momentfotoj uzante Redirect-on-Write teknologion.
- Ĝis 1 PB de uzebla spaco ĉe kopifaktoro 3 kaj sen dedupliko. Ni ne konsideras reproduktan faktoron 2, ĉar ĉi tio ne estas eblo por seriozaj vendoj.
Alia grandega pluso estas facileco de administrado kaj deplojo. Ĉiuj kompleksaĵoj de agordo de UCS-serviloj estas prizorgataj de speciala VM preparita de Cisco-inĝenieroj.
Agordo de testbenko:
- 2 x Cisco UCS Fabric Interconnect 6248UP kiel administra areto kaj retaj komponentoj (48 havenoj funkcianta en Ethernet 10G/FC 16G reĝimo).
- Kvar Cisco UCS HXAF240 M4-serviloj.
Karakterizaĵoj de la servilo:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/duobla rango/x4/1.2v
reto
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet-havenoj
Stokado HBA
Cisco 12G Modular SAS Pass tra Regilo
Stokaj Diskoj
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Pli da agordaj elektojKrom la elektita aparataro, la sekvaj opcioj estas nuntempe disponeblaj:
- HXAF240c M5.
- Unu aŭ du CPUoj de Intel Silver 4110 ĝis Intel Platinum I8260Y. Dua generacio disponebla.
- 24 memorfendoj, strioj de 16 GB RDIMM 2600 ĝis 128 GB LRDIMM 2933.
- De 6 ĝis 23 datumdiskoj, unu kaŝmemordisko, unu sistema disko kaj unu startdisko.
Kapacaj Veturadoj
- HX-SD960G61X-EV 960GB 2.5 Coloj Enterprise Value 6G SATA SSD (1X eltenivo) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5 coloj Enterprise Value 6G SATA SSD (1X eltenivo) SAS 3.8 TB.
- Caching Drives
- HX-NVMEXPB-I375 375GB 2.5 coloj Intel Optane Drive, Ekstrema Perf & Endurance.
- HX-NVMEHW-H1600* 1.6TB 2.5 coloj Ent. Perf. NVMe SSD (3X eltenivo) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 coloj Ent. Perf. 12G SAS SSD (10X eltenivo) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 coloj Ent. Perf. 12G SAS SED SSD (10X eltenivo) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 coloj Enterprise rendimento 12G SAS SSD (3X eltenivo).
Sistemo/Protokoloj
- HX-SD240GM1X-EV 240GB 2.5 coloj Enterprise Value 6G SATA SSD (postulas ĝisdatigon).
Boot Drives
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.
Konektu al la reto per 40G, 25G aŭ 10G Ethernet-havenoj.
La FI povas esti HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
La provo mem
Por testi la disksubsistemon, mi uzis HCIBench 2.2.1. Ĉi tio estas senpaga ilo, kiu permesas vin aŭtomatigi la kreadon de ŝarĝo de pluraj virtualaj maŝinoj. La ŝarĝo mem estas generita de la kutima fio.
Nia areto konsistas el kvar nodoj, replika faktoro 3, ĉiuj diskoj estas Flash.
Por testado, mi kreis kvar datumvendejojn kaj ok virtualajn maŝinojn. Por skribaj testoj, oni supozas, ke la kaŝmemordisko ne estas plena.
La testrezultoj estas kiel sekvas:
100% Legita 100% Hazarda
0% Legita 100% Hazarda
Bloko/vico-profundo
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
Grada indikas valorojn post kiuj ne estas pliiĝo de produktiveco, foje eĉ degenero estas videbla. Ĉi tio estas pro la fakto, ke ni estas limigitaj de la agado de la reto/regiloj/diskoj.
- Sinsekva legado 4432 MB/s.
- Sinsekva skribo 804 MB/s.
- Se unu regilo malsukcesas (fiasko de virtuala maŝino aŭ gastiganto), la rendimentofalo estas duobla.
- Se la stoka disko malsukcesas, la malaltiĝo estas 1/3. Diskorekonstruado prenas 5% de la rimedoj de ĉiu regilo.
Sur malgranda bloko, ni estas limigitaj de la agado de la regilo (virtuala maŝino), ĝia CPU estas ŝarĝita je 100%, kaj kiam la bloko pliiĝas, ni estas limigitaj de la havena bendolarĝo. 10 Gbps ne sufiĉas por malŝlosi la potencialon de la AllFlash-sistemo. Bedaŭrinde, la parametroj de la provizita demonstra stando ne permesas al ni testi funkciadon je 40 Gbit/s.
Laŭ mia impreso de testoj kaj studado de la arkitekturo, pro la algoritmo, kiu metas datumojn inter ĉiuj gastigantoj, ni ricevas skaleblan, antaŭvideblan agadon, sed ĉi tio ankaŭ estas limigo dum legado, ĉar eblus elpremi pli el lokaj diskoj, ĉi tie ĝi povas ŝpari pli produktivan reton, ekzemple, FI je 40 Gbit/s estas disponebla.
Ankaŭ, unu disko por kaŝmemoro kaj deduplikado povas esti limigo; fakte, en ĉi tiu provo ni povas skribi al kvar SSD-diskoj. Estus bonege povi pliigi la nombron da kaŝmemoroj kaj vidi la diferencon.
Reala uzo
Por organizi rezervan datumcentron, vi povas uzi du alirojn (ni ne pripensas meti sekurkopion en fora retejo):
- Aktiva-Pasiva. Ĉiuj aplikoj estas gastigitaj en la ĉefa datumcentro. Reproduktado estas sinkrona aŭ nesinkrona. Se la ĉefa datumcentro malsukcesas, ni devas aktivigi la rezervan. Ĉi tio povas esti farita permane/manuskriptoj/instrumentaj aplikaĵoj. Ĉi tie ni ricevos RPO konforman al la reproduktadfrekvenco, kaj la RTO dependas de la reago kaj kapabloj de la administranto kaj la kvalito de evoluo/sencimigado de la ŝanĝplano.
- Aktiva-Aktiva. En ĉi tiu kazo, ekzistas nur sinkrona reproduktado; la havebleco de datumcentroj estas determinita fare de kvorumo/arbitraciisto situanta strikte sur la tria retejo. RPO = 0, kaj RTO povas atingi 0 (se la aplikiĝo permesas) aŭ egala al la malsukcesa tempo de nodo en virtualiga areto. Je la virtualiga nivelo, streĉita (Metro) areto estas kreita, kiu postulas Aktivan-Aktivan stokadon.
Kutime ni vidas, ke klientoj jam efektivigis arkitekturon kun klasika stokado en la ĉefa datumcentro, do ni desegnas alian por reproduktado. Kiel mi menciis, Cisco HyperFlex ofertas nesinkronan reproduktadon kaj streĉitan virtualigan kreadon de clusteroj. Samtempe, ni ne bezonas dediĉitan stoksistemon de la Meznivela nivelo kaj pli alta kun multekostaj reproduktaj funkcioj kaj Aktiva-aktiva datuma aliro sur du stokadsistemoj.
Scenaro 1: Ni havas ĉefan kaj rezervan datumcentrojn, virtualigan platformon sur VMware vSphere. Ĉiuj produktivaj sistemoj situas en la ĉefa datumcentro, kaj reproduktado de virtualaj maŝinoj estas farata ĉe la hipervizora nivelo, ĉi tio evitos teni VMs ŝaltitaj en la rezerva datumcentro. Ni reproduktas datumbazojn kaj specialajn aplikojn uzante enkonstruitajn ilojn kaj tenas la VM-ojn ŝaltitaj. Se la ĉefa datumcentro malsukcesas, ni lanĉas sistemojn en la rezerva datumcentro. Ni kredas, ke ni havas ĉirkaŭ 100 virtualajn maŝinojn. Dum la primara datumcentro funkcias, la ŝancatenda datumcentro povas funkciigi testajn mediojn kaj aliajn sistemojn kiuj povas esti fermitaj se la primara datumcentro ŝanĝas. Ankaŭ eblas, ke ni uzas dudirektan reproduktadon. De aparatara vidpunkto, nenio ŝanĝiĝos.
En la kazo de klasika arkitekturo, ni instalos en ĉiu datumcentro hibridan stoksistemon kun aliro per FibreChannel, tiering, dedupliko kaj kunpremado (sed ne rete), 8 serviloj por ĉiu retejo, 2 FibreChannel-ŝaltiloj kaj 10G Ethernet. Por reproduktado kaj ŝanĝa administrado en klasika arkitekturo, ni povas uzi VMware-iloj (Replication + SRM) aŭ triaj iloj, kiuj estos iom pli malmultekostaj kaj foje pli oportunaj.
La figuro montras la diagramon.
Kiam vi uzas Cisco HyperFlex, la sekva arkitekturo estas akirita:
Por HyperFlex, mi uzis servilojn kun grandaj CPU/RAM-resursoj, ĉar... Iuj el la rimedoj iros al la VM-regilo de HyperFlex; rilate CPU kaj memoro, mi eĉ iomete re-agordis la agordon de HyperFlex por ne ludi kune kun Cisco kaj garantii rimedojn por la ceteraj VM-oj. Sed ni povas forlasi FibreChannel-ŝaltilojn, kaj ni ne bezonos Ethernet-havenojn por ĉiu servilo; loka trafiko estas ŝanĝita ene de FI.
La rezulto estis la sekva agordo por ĉiu datencentro:
Serviloj
8 x 1U Servilo (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
Hibrida stokadosistemo kun FC Front-End (20TB SSD, 130TB NL-SAS)
-
LAN
2 x Ethernet-ŝaltilo 10G 12 havenoj
-
SAN
2 x FC-ŝaltilo 32/16Gb 24 havenoj
2 x Cisco UCS FI 6332
Licencoj
VMware Ent Plus
Reproduktado kaj/aŭ instrumentado de VM-ŝanĝado
VMware Ent Plus
Mi ne disponigis reproduktajn programajn licencojn por Hyperflex, ĉar ĉi tio disponeblas el la skatolo por ni.
Por klasika arkitekturo, mi elektis vendiston kiu establis sin kiel altkvalita kaj malmultekosta fabrikisto. Por ambaŭ opcioj, mi aplikis la norman rabaton por specifa solvo, kaj kiel rezulto mi ricevis realajn prezojn.
La Cisco HyperFlex solvo montriĝis 13% pli malmultekosta.
Scenaro 2: kreado de du aktivaj datumcentroj. En ĉi tiu scenaro, ni desegnas streĉitan areton sur VMware.
La klasika arkitekturo konsistas el virtualigserviloj, SAN (FC-protokolo) kaj du stoksistemoj, kiuj povas legi kaj skribi al la volumo etendita inter ili. Sur ĉiu stoksistemo ni metas utilan kapablon por stokado.
Ĉe HyperFlex ni simple kreas Stretch Cluster kun la sama nombro da nodoj sur ambaŭ retejoj. En ĉi tiu kazo, replika faktoro de 2+2 estas uzata.
La rezulto estas la sekva agordo:
klasika arkitekturo
HyperFlex
Serviloj
16 x 1U Servilo (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 stokadsistemoj (150 TB SSD)
-
LAN
4 x Ethernet-ŝaltilo 10G 24 havenoj
-
SAN
4 x FC-ŝaltilo 32/16Gb 24 havenoj
4 x Cisco UCS FI 6332
Licencoj
VMware Ent Plus
VMware Ent Plus
En ĉiuj kalkuloj, mi ne konsideris la retan infrastrukturon, la kostojn de datumcentroj ktp.: ili estos la samaj por la klasika arkitekturo kaj por la solvo HyperFlex.
Laŭ kosto, HyperFlex montriĝis 5% pli multekosta. Indas rimarki ĉi tie, ke rilate al CPU/RAM-resursoj mi havis svingon por Cisco, ĉar en la agordo mi plenigis la memorregilkanalojn egale. La kosto estas iomete pli alta, sed ne laŭ grandeco, kio klare indikas, ke hiperkonverĝo ne nepre estas "ludilo por riĉuloj", sed povas konkuri kun la norma aliro al konstruado de datumcentro. Ĉi tio ankaŭ povas interesi tiujn, kiuj jam havas Cisco UCS-servilojn kaj la respondan infrastrukturon por ili.
Inter la avantaĝoj, ni ricevas la mankon de kostoj por administrado de SAN kaj stokadosistemoj, interreta kunpremado kaj deduplikado, ununura enirpunkto por subteno (virtualigo, serviloj, ili ankaŭ estas stokaj sistemoj), ŝparante spacon (sed ne en ĉiuj scenaroj), simpligante operacion.
Koncerne subtenon, ĉi tie vi ricevas ĝin de unu vendisto - Cisco. Juĝante laŭ mia sperto kun Cisco UCS-serviloj, mi ŝatas ĝin; mi ne devis malfermi ĝin sur HyperFlex, ĉio funkciis same. Inĝenieroj respondas rapide kaj povas solvi ne nur tipajn problemojn, sed ankaŭ kompleksajn randajn kazojn. Foje mi turnas min al ili kun demandoj: "Ĉu eblas fari tion, ŝraŭbi ĝin?" aŭ "Mi agordis ion ĉi tie, kaj ĝi ne volas funkcii. Helpu!" - ili pacience trovos tie la necesan gvidilon kaj montros la ĝustajn agojn; ili ne respondos: "Ni solvas nur aparatajn problemojn."
referencoj
- Mia poŝto - [retpoŝte protektita]
fonto: www.habr.com