Dit is 'n mite wat redelik algemeen op die gebied van bedienerhardeware voorkom. In die praktyk is hipergekonvergeerde oplossings (wanneer alles in een is) vir baie dinge nodig. Histories is die eerste argitekture ontwikkel deur Amazon en Google vir hul dienste. Toe was die idee om 'n rekenaarplaas van dieselfde nodusse te maak, wat elkeen sy eie skywe het. Dit alles is gekombineer deur een of ander stelselvormende sagteware (hipervisor) en is reeds in virtuele masjiene verdeel. Die hooftaak is 'n minimum poging om een nodus in stand te hou en 'n minimum van probleme tydens skaal: hulle het eenvoudig nog duisend of twee van dieselfde bedieners gekoop en hulle langs mekaar gekoppel. In die praktyk is dit geïsoleerde gevalle, en baie meer dikwels praat ons van 'n kleiner aantal nodusse en 'n effens ander argitektuur.
Maar die pluspunt bly dieselfde - die ongelooflike gemak van skaal en beheer. Minus - verskillende take verbruik hulpbronne op verskillende maniere, en iewers sal daar baie plaaslike skywe wees, iewers sal daar min RAM wees, ensovoorts, dit wil sê, met verskillende soorte take, sal hulpbronbenutting daal.
Dit het geblyk dat jy 10-15% meer betaal vir die gerief van die opstel. Dit is wat die mite uit die opskrif laat ontstaan het. Ons soek al lank waar die tegnologie optimaal toegepas gaan word, en ons het dit gevind. Die feit is dat Tsiska nie hul eie stoorstelsels gehad het nie, maar hulle wou 'n volledige bedienermark hê. En hulle het Cisco Hyperflex gemaak - 'n oplossing met plaaslike berging op nodusse.
En dit blyk skielik 'n baie goeie oplossing te wees vir rugsteundatasentrums (Disaster Recovery). Hoekom en hoe - nou sal ek vertel. En ek sal die groeptoetse wys.
Waar nodig
Hiperkonvergensie is:
- Die oordrag van skywe na rekenaarnodusse.
- Volledige integrasie van die bergingsubstelsel met die virtualisasiesubstelsel.
- Oordrag / integrasie met die netwerk substelsel.
So 'n bondel laat jou toe om baie bergingskenmerke op die virtualisasievlak en alles vanuit een bestuursvenster te implementeer.
In ons maatskappy is projekte vir die ontwerp van rugsteundatasentrums in groot aanvraag, en die hipergekonvergeerde oplossing word dikwels gekies as gevolg van die hoop replikasie-opsies (tot by die metro-groepering) uit die boks.
In die geval van rugsteundatasentrums praat ons gewoonlik van 'n afgeleë fasiliteit op 'n perseel aan die ander kant van die stad of heeltemal in 'n ander stad. Dit laat jou toe om kritieke stelsels te herstel in die geval van 'n gedeeltelike of volledige mislukking van die hoofdatasentrum. Data van die verkoper word voortdurend daar gerepliseer, en hierdie replikasie kan op die toepassingsvlak of op die bloktoestelvlak (SHD) wees.
Daarom sal ek nou praat oor die ontwerp van die stelsel en toetse, en dan oor 'n paar werklike scenario's met spaardata.
toetse
Ons instansie bestaan uit vier bedieners, wat elkeen 10 960 GB SSD-aandrywers het. Daar is 'n toegewyde skyf vir die kas skryf en berging van die diens virtuele masjien. Die oplossing self is die vierde weergawe. Die eerste is eerlikwaar rou (te oordeel aan die resensies), die tweede is rou, die derde is reeds redelik stabiel, en hierdie een kan 'n vrystelling genoem word na die einde van beta-toetsing vir die algemene publiek. Tydens die toets het ek geen probleme gesien nie, alles werk soos klokslag.
Veranderinge in v4Het baie foute reggemaak.
Aanvanklik kon die platform net met die VMware ESXi-hipervisor werk en het 'n klein aantal nodusse ondersteun. Die ontplooiingsproses het ook nie altyd suksesvol geëindig nie, sommige stappe moes herbegin word, daar was probleme met die opdatering van ouer weergawes, die data in die GUI is nie altyd korrek vertoon nie (alhoewel ek steeds nie entoesiasties is om prestasiegrafieke te vertoon nie), soms daar was probleme by die aansluiting met virtualisering.
Nou is alle kinders se sere reggemaak, HyperFlex kan beide ESXi en Hyper-V doen, plus dit is moontlik om:
- Skepping van 'n uitgerekte tros.
- Skep 'n groepering vir kantore sonder om Fabric Interconnect te gebruik, van twee tot vier nodusse (ons koop slegs bedieners).
- Vermoë om met eksterne bergingstelsels te werk.
- Ondersteuning vir houers en Kubernetes.
- Skep beskikbaarheidsones.
- Integrasie met VMware SRM, as die ingeboude funksionaliteit jou nie pas nie.
Die argitektuur verskil nie veel van die oplossings van die belangrikste mededingers nie, hulle het nie 'n fiets geskep nie. Dit werk alles op die VMware- of Hyper-V-virtualiseringsplatform. Hardeware gehuisves op Cisco UCS eie bedieners. Daar is diegene wat die platform haat vir die relatiewe kompleksiteit van die aanvanklike opstelling, baie knoppies, 'n nie-triviale stelsel van sjablone en afhanklikhede, maar daar is diegene wat die zen ken, deurdrenk van die idee en nie meer wil werk nie met ander bedieners.
Ons sal die oplossing vir VMware oorweeg, aangesien die oplossing oorspronklik daarvoor geskep is en meer funksionaliteit het, is Hyper-V langs die pad voltooi om tred te hou met mededingers en aan markverwagtinge te voldoen.
Daar is 'n groepie vanaf die bedieners wat met skywe gevul is. Daar is skywe vir databerging (SSD of HDD - volgens jou smaak en behoeftes), daar is een SSD-skyf vir kas. Wanneer data na die datastoor geskryf word, word die data op die kaslaag (toegewyde SSD-skyf en RAM van die diens-VM) gestoor. In parallel word die datablok na die nodusse in die groep gestuur (die aantal nodusse hang af van die groepreplikasiefaktor). Na bevestiging van alle nodusse oor 'n suksesvolle skryf, word die skryfbevestiging na die hipervisor gestuur en dan na die VM. Opgeneemde data word gededupliseer, saamgepers en na stoorskywe in die agtergrond geskryf. Terselfdertyd word 'n groot blok altyd na die stoorskywe en opeenvolgend geskryf, wat die las op die stoorskywe verminder.
Deduplisering en kompressie word deurentyd geaktiveer en kan nie gedeaktiveer word nie. Data word direk vanaf stoorskywe of vanaf die RAM-kas gelees. As 'n hibriede konfigurasie gebruik word, word die lees ook op die SSD gekas.
Die data is nie gekoppel aan die huidige ligging van die virtuele masjien nie en word eweredig tussen die nodusse versprei. Hierdie benadering laat jou toe om alle skywe en netwerkkoppelvlakke ewe veel te laai. 'n Voor die hand liggende minus ontstaan: ons kan nie die leesvertraging verminder nie, aangesien daar geen waarborg is dat die data plaaslik beskikbaar is nie. Maar ek dink dit is 'n onbeduidende opoffering in vergelyking met die pluspunte wat ontvang word. Boonop het netwerkvertragings sulke waardes bereik dat dit feitlik nie die algehele resultaat beïnvloed nie.
'n Spesiale diens VM Cisco HyperFlex Data Platform kontroleerder, wat op elke stoor nodus geskep word, is verantwoordelik vir die hele logika van die skyf substelsel. In ons konfigurasie is aan die diens-VM agt vCPU's en 72 GB RAM toegeken, wat nie so min is nie. Laat ek jou daaraan herinner dat die gasheer self 28 fisiese kerne en 512 GB RAM het.
Die diens-VM het direk toegang tot fisiese skywe deur die SAS-beheerder na die VM aan te stuur. Kommunikasie met die hipervisor vind plaas deur 'n spesiale IOVisor-module wat I / O-operasies onderskep, en met die hulp van 'n agent wat jou toelaat om opdragte na die hipervisor-API te stuur. Die agent is verantwoordelik om met HyperFlex-kiekies en klone te werk.
In die hiperviser word skyfhulpbronne as NFS- of SMB-aandele gemonteer (afhangende van die tipe hipervisor, raai watter een). En onder die enjinkap is dit 'n verspreide lêerstelsel waarmee u kenmerke van volwaardige bergingstelsels vir volwassenes kan byvoeg: dun toewysing van volumes, kompressie en deduplisering, momentopnames met behulp van Redirect-on-Write-tegnologie, sinchroniese / asinchrone replikasie.
Die diens-VM bied toegang tot die HyperFlex-substelselbestuur-webkoppelvlak. Daar is integrasie met vCenter, en die meeste van die daaglikse take kan daaruit uitgevoer word, maar datawinkels, byvoorbeeld, is geriefliker om van 'n aparte webkamera af te sny as jy reeds na 'n vinnige HTML5-koppelvlak oorgeskakel het, of 'n volwaardige Flash-kliënt met volle integrasie. In die dienswebkamera kan u die werkverrigting en gedetailleerde status van die stelsel sien.
Daar is 'n ander tipe nodusse in die groepering - rekenaarnodusse. Dit kan rek- of lembedieners wees sonder ingeboude aandrywers. Op hierdie bedieners kan u VM's laat loop waarvan die data op bedieners met skywe gestoor word. Uit die oogpunt van datatoegang is daar geen verskil tussen die tipes nodusse nie, want die argitektuur veronderstel 'n abstraksie van die fisiese ligging van die data. Die maksimum verhouding van bereken nodusse tot stoor nodusse is 2:1.
Die gebruik van rekenaarnodusse verhoog die buigsaamheid wanneer groephulpbronne skaal: ons hoef nie bykomende nodusse met skywe te koop as ons net SVE / RAM benodig nie. Daarbenewens kan ons 'n lemmandjie byvoeg en besparings kry om bedieners in 'n rek te plaas.
As gevolg hiervan het ons 'n hipergekonvergeerde platform met die volgende kenmerke:
- Tot 64 nodusse per groep (tot 32 stoor nodusse).
- Die minimum aantal nodusse in 'n kluster is drie (twee vir 'n Edge-kluster).
- Data-oortolligheidsmeganisme: weerspieëling met replikasiefaktor 2 en 3.
- Metro-kluster.
- Asynchrone VM-replikasie na 'n ander HyperFlex-kluster.
- Orkestrasie van oorskakeling van VM's na 'n afgeleë datasentrum.
- Inheemse foto's met behulp van Herlei-op-skryf-tegnologie.
- Tot 1 PB bruikbare spasie met 'n replikasiefaktor van 3 en geen deduplisering nie. Replikasiefaktor 2 word nie in ag geneem nie, want dit is nie 'n opsie vir 'n ernstige verkoper nie.
Nog 'n groot pluspunt is die gemak van bestuur en ontplooiing. Al die kompleksiteite van die opstel van UCS-bedieners word hanteer deur 'n gespesialiseerde VM wat deur Cisco-ingenieurs voorberei is.
Toetsbankkonfigurasie:
- 2 x Cisco UCS Fabric Interconnect 6248UP as bestuursgroepering en netwerkkomponente (48 poorte wat in 10G/FC 16G Ethernet-modus werk).
- Vier Cisco UCS HXAF240 M4-bedieners.
Bediener eienskappe:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/dubbele rang/x4/1.2v
Netwerk
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet-poorte
Berging HBA
Cisco 12G Modulêre SAS Deurbeheerder
Bergingsskywe
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Meer konfigurasie opsiesBenewens die geselekteerde hardeware, is die volgende opsies tans beskikbaar:
- HXAF240c M5.
- Een of twee SVE's wat wissel van Intel Silver 4110 tot Intel Platinum I8260Y. Tweede generasie beskikbaar.
- 24 geheuegleuwe, hakies van 16 GB RDIMM 2600 tot 128 GB LRDIMM 2933.
- 6 tot 23 data-aandrywers, een kasaandrywer, een stelselaandrywer en een selflaaistasie.
Kapasiteit dryf
- HX-SD960G61X-EV 960GB 2.5 Duim Enterprise Value 6G SATA SSD (1X uithouvermoë) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5 duim Enterprise Value 6G SATA SSD (1X uithouvermoë) SAS 3.8 TB.
- Kas aandrywers
- HX-NVMEXPB-I375 375 GB 2.5 duim Intel Optane Drive, uiterste prestasie en uithouvermoë.
- HX-NVMEHW-H1600* 1.6TB 2.5 duim Ent. Perf. NVMe SSD (3X uithouvermoë) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 duim Ent. Perf. 12G SAS SSD (10X uithouvermoë) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 duim Ent. Perf. 12G SAS SED SSD (10X uithouvermoë) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 duim Ondernemingsprestasie 12G SAS SSD (3X uithouvermoë).
Stelsel / Log Drives
- HX-SD240GM1X-EV 240GB 2.5 duim Enterprise Value 6G SATA SSD (Vereis opgradering).
selflaai-aandrywers
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.
Netwerkverbinding via 40G, 25G of 10G Ethernet-poorte.
FI kan HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G) wees.
Die toets self
Om die skyfsubstelsel te toets, het ek HCIBench 2.2.1 gebruik. Dit is 'n gratis program waarmee u die skep van 'n vrag vanaf verskeie virtuele masjiene kan outomatiseer. Die las self word gegenereer deur die gewone fio.
Ons groep bestaan uit vier nodusse, replikasiefaktor 3, almal Flash-skywe.
Vir toetsing het ek vier datawinkels en agt virtuele masjiene geskep. Vir skryftoetse word aanvaar dat die kasskyf nie vol is nie.
Die toetsuitslae is soos volg:
100% Lees 100% Willekeurig
0% Lees 100% Willekeurig
Blok/Wou Diepte
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
Vetdruk dui waardes aan waarna daar geen toename in prestasie is nie, soms is selfs agteruitgang sigbaar. Dit hou verband met die feit dat ons berus op die werkverrigting van die netwerk / beheerders / skywe.
- Opeenvolgende lees 4432 MB/s.
- Opeenvolgende skryf 804 MB/s.
- As een kontroleerder misluk (mislukking van 'n virtuele masjien of gasheer), word die prestasievermindering verdubbel.
- As die stoorskyf misluk, is daar 'n onttrekking van 1/3. Skyfherbou neem 5% van die hulpbronne van elke beheerder in beslag.
Op 'n klein blok rus ons op die werkverrigting van die kontroleerder (virtuele masjien), sy SVE is 100% gelaai, met 'n toename in die blok, rus ons op die poortbandwydte. 10 Gb / s is nie genoeg om die potensiaal van die AllFlash-stelsel te ontsluit nie. Ongelukkig laat die parameters van die verskafde demo-stand dit nie toe om die operasie teen 40 Gbps na te gaan nie.
In my indruk van die toetse en die bestudering van die argitektuur, as gevolg van die algoritme wat data tussen alle gashere plaas, kry ons skaalbare voorspelbare werkverrigting, maar dit is ook 'n beperking tydens lees, want meer kan uit plaaslike skywe uitgedruk word, hier kan dit om byvoorbeeld 'n meer produktiewe netwerk te bespaar, is 40 Gbps FI beskikbaar.
Ook, een skyf vir kas en deduplisering kan 'n beperking wees, in werklikheid kan ons in hierdie stand na vier SSD-skywe skryf. Dit sal wonderlik wees om die aantal kasskywe te kan verhoog en die verskil te sien.
Werklike gebruik
Om 'n rugsteundatasentrum te organiseer, kan u twee benaderings gebruik (ons oorweeg dit nie om 'n rugsteun op 'n afgeleë webwerf te plaas nie):
- Aktief-passief. Alle toepassings word in die hoofdatasentrum gehuisves. Replikasie is sinchronies of asinchronies. In die geval van 'n val in die hoofdatasentrum, moet ons die rugsteun aktiveer. Jy kan dit met die hand doen / skrifte / orkestrasie toepassings. Hier sal ons 'n RPO kry wat ooreenstem met die frekwensie van replikasie, en RTO hang af van die reaksie en vaardighede van die administrateur en die kwaliteit van die ontwikkeling / ontfouting van die skakelplan.
- Aktief Aktief. In hierdie geval is daar slegs sinchroniese replikasie, die beskikbaarheid van datasentrums word bepaal deur die kworum / arbiter, wat streng op die derde webwerf geleë is. RPO = 0, en RTO kan so hoog as 0 wees (indien die toepassing dit toelaat) of gelyk aan die tyd om 'n nodus in 'n virtualisasiekluster te oorskakel. Op die virtualisasievlak word 'n uitgerekte (Metro)-kluster geskep wat aktief-aktiewe berging vereis.
Gewoonlik sien ons kliënte met 'n reeds geïmplementeerde argitektuur met klassieke berging in die hoofdatasentrum, so ons ontwerp nog een vir replikasie. Soos ek genoem het, bied Cisco HyperFlex asinchrone replikasie en die skepping van 'n uitgerekte virtualisasie-kluster. Terselfdertyd het ons nie 'n toegewyde bergingstelsel van die Midrange-vlak en hoër nodig met duur replikasiefunksies en aktief-aktiewe datatoegang op twee bergingstelsels nie.
Scenario 1: Ons het 'n primêre en rugsteundatasentrum, 'n virtualiseringsplatform gebaseer op VMware vSphere. Alle produktiewe stelsels is in die hoofdatasentrum geleë, en virtuele masjienreplikasie word op die hipervisorvlak uitgevoer, dit sal jou toelaat om nie VM's in die rugsteundatasentrum aangeskakel te hou nie. Ons repliseer databasisse en spesiale toepassings deur ingeboude gereedskap te gebruik en hou die VM's aangeskakel. As die hoofdatasentrum misluk, begin ons die stelsels in die rugsteundatasentrum. Ons dink dat ons ongeveer 100 virtuele masjiene het. Terwyl die primêre datasentrum in werking is, kan toetsomgewings en ander stelsels in die sekondêre datasentrum loop, wat gedeaktiveer kan word in die geval van 'n primêre datasentrum-omskakeling. Dit is ook moontlik dat ons tweerigting-replikasie gebruik. Wat toerusting betref, sal niks verander nie.
In die geval van 'n klassieke argitektuur, sal ons in elke datasentrum 'n hibriede bergingstelsel installeer met toegang via FibreChannel, vlakke, deduplisering en kompressie (maar nie aanlyn nie), 8 bedieners per webwerf, 2 FibreChannel-skakelaars en Ethernet 10G. Vir replikasie- en failover-bestuur in die klassieke argitektuur, kan ons VMware-gereedskap (Replication + SRM) of derdeparty-instrumente gebruik wat 'n bietjie goedkoper en soms geriefliker sal wees.
Die figuur toon 'n diagram.
In die geval van die gebruik van Cisco HyperFlex, word die volgende argitektuur verkry:
Vir HyperFlex het ek bedieners met groot SVE / RAM-bronne gebruik, want 'n deel van die hulpbronne sal na die VM van die HyperFlex-beheerder gaan, in terme van SVE en geheue, ek het selfs die HyperFlex-konfigurasie 'n bietjie herlaai om nie saam met Cisco te speel nie en hulpbronne vir die res van die VM's te waarborg. Maar ons kan FibreChannel-skakelaars weier, en ons het nie Ethernet-poorte vir elke bediener nodig nie, plaaslike verkeer word binne FI oorgeskakel.
Die resultaat is die volgende konfigurasie vir elke datasentrum:
Bedieners
8 x 1U-bediener (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
Hibriedberging met FC Front-End (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet skakelaars 10G 12 poorte
-
SAN
2 x FC skakelaar 32/16Gb 24 poorte
2 x Cisco UCS FI 6332
Lisensies
VMware Ent Plus
Replikasie en/of orkestrasie van VM failover
VMware Ent Plus
Vir Hyperflex het ek nie replikasie sagteware lisensies belowe nie, aangesien ons dit uit die boks beskikbaar het.
Vir klassieke argitektuur het ek 'n verkoper geneem wat homself gevestig het as 'n hoë-gehalte en goedkoop vervaardiger. Vir albei opsies het ek die standaardafslag vir 'n spesifieke oplossing toegepas, en by die uitset het ek regte pryse gekry.
Die Cisco HyperFlex-oplossing blyk 13% goedkoper te wees.
Scenario 2: skepping van twee aktiewe datasentrums. In hierdie scenario ontwerp ons 'n rekgroep op VMware.
Die klassieke argitektuur bestaan uit virtualisasiebedieners, SAN (FC-protokol) en twee stoorstelsels wat kan lees en skryf op die volume wat tussen hulle gestrek word. Op elke stoorstelsel lê ons 'n nuttige kapasiteit vir 'n slot.
Met HyperFlex skep ons eenvoudig 'n Stretch Cluster met dieselfde aantal nodusse op beide werwe. In hierdie geval word 'n 2+2 replikasiefaktor gebruik.
Die resultaat is die volgende konfigurasie:
klassieke argitektuur
hiperfleks
Bedieners
16 x 1U-bediener (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-berging (150 TB SSD)
-
LAN
4 x Ethernet skakelaars 10G 24 poorte
-
SAN
4 x FC skakelaar 32/16Gb 24 poorte
4 x Cisco UCS FI 6332
Lisensies
VMware Ent Plus
VMware Ent Plus
In alle berekeninge het ek nie die netwerkinfrastruktuur, datasentrumkoste, ens. in ag geneem nie: dit sal dieselfde wees vir die klassieke argitektuur en vir die HyperFlex-oplossing.
HyperFlex blyk teen 'n prys 5% duurder te wees. Dit is opmerklik hier dat ek in terme van SVE / RAM-hulpbronne 'n skeefheid vir Cisco gekry het, want in die konfigurasie het ek die kanale van die geheuebeheerders eweredig gevul. Die koste is effens hoër, maar nie 'n orde van grootte nie, wat duidelik aandui dat hiperkonvergensie nie noodwendig 'n "speelding vir die rykes" is nie, maar kan meeding met die standaardbenadering om 'n datasentrum te bou. Dit kan ook van belang wees vir diegene wat reeds Cisco UCS-bedieners en die ooreenstemmende infrastruktuur daarvoor het.
Van die pluspunte kry ons die afwesigheid van koste vir die administrasie van SAN en bergingstelsels, aanlyn kompressie en deduplisering, 'n enkele toegangspunt vir ondersteuning (virtualisering, bedieners, dit is ook bergingstelsels), ruimtebesparing (maar nie in alle scenario's nie), vereenvoudiging van operasie.
Wat ondersteuning betref, hier kry jy dit van een verkoper - Cisco. Te oordeel aan die ervaring om met Cisco UCS-bedieners te werk, hou ek daarvan, ek hoef dit nie op HyperFlex oop te maak nie, alles het in elk geval gewerk. Ingenieurs reageer vinnig en kan nie net tipiese probleme oplos nie, maar ook komplekse randgevalle. Soms wend ek my na hulle met vrae: "Is dit moontlik om dit te doen, dit te vermors?" of “Ek het iets hier gekonfigureer, en dit wil nie werk nie. Help!" - hulle sal geduldig die nodige gids daar vind en die korrekte aksies uitwys, hulle sal nie antwoord nie: "Ons los net hardeware probleme op".
verwysings
- My pos - [e-pos beskerm]
Bron: will.com