Admin án handa = ofursamruni?

Admin án handa = ofursamruni?
Admin án handa = ofursamruni?

Þetta er goðsögn sem er nokkuð algeng á sviði vélbúnaðar netþjóna. Í reynd þarf ofsamræmdar lausnir (þegar allt er í einu) fyrir margt. Sögulega séð voru fyrstu arkitektúrarnir þróaðir af Amazon og Google fyrir þjónustu sína. Síðan var hugmyndin að búa til tölvubú úr eins hnútum, sem hver um sig hafði sína diska. Allt þetta var sameinað með einhverjum kerfismyndandi hugbúnaði (hypervisor) og var skipt í sýndarvélar. Meginmarkmiðið er lágmarks fyrirhöfn til að þjónusta einn hnút og lágmarks vandamál við skala: keyptu bara á annað þúsund eða tvo af sömu netþjónum og tengdu þá nálægt. Í reynd eru þetta einangruð tilvik og miklu oftar erum við að tala um færri hnúta og aðeins öðruvísi arkitektúr.

En plúsinn er sá sami - ótrúlega auðveld skala og stjórnun. Gallinn er sá að mismunandi verkefni neyta auðlinda á mismunandi hátt og sums staðar verður mikið af staðbundnum diskum, á öðrum verður lítið vinnsluminni og svo framvegis, það er að við mismunandi gerðir verkefna mun auðlindanýting minnka.

Það kemur í ljós að þú borgar 10–15% meira til að auðvelda uppsetningu. Þetta er það sem kveikti goðsögnina í titlinum. Við eyddum löngum tíma í að leita að því hvar tækninni væri best beitt og við fundum það. Staðreyndin er sú að Cisco var ekki með eigin geymslukerfi heldur vildu þeir fullkominn netþjónamarkað. Og þeir gerðu Cisco Hyperflex - lausn með staðbundinni geymslu á hnútum.

Og þetta reyndist allt í einu vera mjög góð lausn fyrir öryggisafrit af gagnaverum (Disaster Recovery). Ég skal segja þér hvers vegna og hvernig núna. Og ég skal sýna þér klasaprófin.

Þar sem þörf er á

Ofsamruni er:

  1. Að flytja diska yfir á tölvuhnúta.
  2. Full samþætting geymslu undirkerfisins við sýndarvæðingar undirkerfið.
  3. Flutningur/samþætting við netundirkerfið.

Þessi samsetning gerir þér kleift að innleiða marga eiginleika geymslukerfisins á sýndarvæðingarstigi og allt úr einum stjórnglugga.

Í fyrirtækinu okkar eru verkefni til að hanna óþarfa gagnaver í mikilli eftirspurn og oft er valin ofursamræmd lausn vegna fjölda afritunarvalkosta (allt að metróþyrping) úr kassanum.

Þegar um er að ræða öryggisafrit af gagnaverum er venjulega verið að tala um fjaraðstöðu á lóð hinum megin í borginni eða í allri annarri borg. Það gerir þér kleift að endurheimta mikilvæg kerfi ef bilun verður að hluta eða í heild í aðalgagnaverinu. Sölugögn eru stöðugt afrituð þar og þessi afritun getur verið á forritastigi eða á blokkunartæki (geymslu).

Þess vegna mun ég nú tala um kerfishönnun og prófanir og síðan um nokkrar raunverulegar umsóknaratburðarásir með sparnaðargögnum.

Próf

Tilvikið okkar samanstendur af fjórum netþjónum, sem hver um sig hefur 10 SSD drif á 960 GB. Það er sérstakur diskur til að vista skrifaðgerðir í skyndiminni og geyma sýndarvél þjónustunnar. Lausnin sjálf er fjórða útgáfan. Sú fyrri er hreinskilnislega gróf (miðað við umsagnirnar), sú seinni er rak, sú þriðja er nú þegar nokkuð stöðug og þetta má kalla útgáfu eftir lok betaprófunar fyrir almenning. Við prófun sá ég engin vandamál, allt virkar eins og klukka.

Breytingar á v4Búið er að laga fullt af villum.

Upphaflega gat pallurinn aðeins virkað með VMware ESXi hypervisor og styður lítinn fjölda hnúta. Einnig endaði dreifingarferlið ekki alltaf með góðum árangri, sum skref þurfti að endurræsa, það voru vandamál með uppfærslu frá eldri útgáfum, gögn í GUI voru ekki alltaf birt á réttan hátt (þó ég sé enn ekki ánægður með birtingu á frammistöðuritum ), stundum komu upp vandamál við viðmótið með sýndarvæðingu.

Nú hefur öll æskuvandamál verið lagfærð, HyperFlex ræður við bæði ESXi og Hyper-V, auk þess sem það er mögulegt að:

  1. Að búa til teygðan klasa.
  2. Að búa til þyrping fyrir skrifstofur án þess að nota Fabric Interconnect, frá tveimur til fjórum hnútum (við kaupum aðeins netþjóna).
  3. Geta til að vinna með ytri geymslukerfi.
  4. Stuðningur við gáma og Kubernetes.
  5. Stofnun framboðssvæða.
  6. Samþætting við VMware SRM ef innbyggð virkni er ekki fullnægjandi.

Arkitektúrinn er ekki mikið frábrugðinn lausnum helstu keppinauta, þeir bjuggu ekki til reiðhjól. Það keyrir allt á VMware eða Hyper-V virtualization pallinum. Vélbúnaðurinn er hýstur á eigin Cisco UCS netþjónum. Það eru þeir sem hata vettvanginn fyrir tiltölulega flókna upphafsuppsetninguna, fullt af hnöppum, óléttvægu kerfi sniðmáta og ósjálfstæðis, en það eru líka þeir sem hafa lært Zen, eru innblásnir af hugmyndinni og vilja ekki lengur til að vinna með öðrum netþjónum.

Við munum íhuga lausnina fyrir VMware, þar sem lausnin var upphaflega búin til fyrir hana og hefur meiri virkni; Hyper-V var bætt við á leiðinni til að halda í við samkeppnisaðila og uppfylla væntingar markaðarins.

Það er þyrping netþjóna fullur af diskum. Það eru diskar fyrir gagnageymslu (SSD eða HDD - eftir smekk þínum og þörfum), það er einn SSD diskur fyrir skyndiminni. Þegar gögn eru skrifuð í gagnageymsluna eru gögnin vistuð á skyndiminnislaginu (sérstakur SSD diskur og vinnsluminni þjónustu VM). Samhliða er gagnablokk sendur til hnúta í klasanum (fjöldi hnúta fer eftir afritunarstuðli klasans). Eftir staðfestingu frá öllum hnútum um árangursríka upptöku er staðfesting á upptöku send til yfirsjávarans og síðan til VM. Skráðu gögnin eru tvítekin, þjöppuð og skrifuð á geymsludiska í bakgrunni. Á sama tíma er stór blokk alltaf skrifuð á geymsludiskana og í röð, sem dregur úr álagi á geymsludiskana.

Aftvíföldun og þjöppun eru alltaf virk og ekki er hægt að slökkva á þeim. Gögn eru lesin beint af geymsludiska eða úr skyndiminni vinnsluminni. Ef blendingur stillingar er notaður eru lesin einnig í skyndiminni á SSD.

Gögnin eru ekki bundin við núverandi staðsetningu sýndarvélarinnar og dreifast jafnt á milli hnútanna. Þessi aðferð gerir þér kleift að hlaða alla diska og netviðmót jafnt. Það er augljós ókostur: við getum ekki dregið úr lestartíma eins mikið og mögulegt er, þar sem engin trygging er fyrir aðgengi að gögnum á staðnum. En ég tel að hér sé um minniháttar fórn að ræða miðað við þær bætur sem fengust. Þar að auki hafa nettafir náð slíkum gildum að þær hafa nánast ekki áhrif á heildarniðurstöðuna.

Sérstakur þjónusta VM Cisco HyperFlex Data Platform stjórnandi, sem er búinn til á hverjum geymsluhnút, er ábyrgur fyrir allri rekstrarrökfræði diska undirkerfisins. Í þjónustu VM uppsetningu okkar var átta vCPU og 72 GB af vinnsluminni úthlutað, sem er ekki svo lítið. Leyfðu mér að minna þig á að gestgjafinn sjálfur hefur 28 líkamlega kjarna og 512 GB af vinnsluminni.

Þjónustan VM hefur aðgang að líkamlegum diskum beint með því að senda SAS stjórnandi til VM. Samskipti við hypervisor eiga sér stað í gegnum sérstaka IOVisor einingu, sem stöðva I/O aðgerðir, og með því að nota umboðsmann sem gerir þér kleift að senda skipanir til hypervisor API. Umboðsmaðurinn ber ábyrgð á því að vinna með HyperFlex skyndimyndir og klóna.

Diskarauðlindir eru settar upp í yfirsýnarinn sem NFS eða SMB deilingar (fer eftir tegund yfirsýnar, giska á hver er hvar). Og undir hettunni er þetta dreift skráarkerfi sem gerir þér kleift að bæta við eiginleikum fullorðinna geymslukerfa fyrir fullorðna: þunnt hljóðstyrksúthlutun, þjöppun og afföldun, skyndimyndir með Redirect-on-Write tækni, samstillt/ósamstillt afritun.

Þjónustan VM veitir aðgang að vefstjórnunarviðmóti HyperFlex undirkerfisins. Það er samþætting við vCenter og flest hversdagsleg verkefni er hægt að framkvæma úr því, en gagnaverslanir, til dæmis, er þægilegra að klippa úr sérstakri vefmyndavél ef þú hefur þegar skipt yfir í hraðvirkt HTML5 viðmót, eða notar fullgildan Flash biðlara með fullri samþættingu. Í þjónustuvefmyndavélinni er hægt að skoða frammistöðu og nákvæma stöðu kerfisins.

Admin án handa = ofursamruni?

Það er önnur tegund af hnút í klasa - tölvuhnútar. Þetta geta verið rekki eða blaðþjónar án innbyggðra diska. Þessir netþjónar geta keyrt VM þar sem gögn eru geymd á netþjónum með diskum. Frá sjónarhóli gagnaaðgangs er enginn munur á tegundum hnúta, vegna þess að arkitektúrinn felur í sér abstrakt frá líkamlegri staðsetningu gagnanna. Hámarkshlutfall tölvuhnúta og geymsluhnúta er 2:1.

Notkun reiknihnúta eykur sveigjanleika við að skala klasaauðlindir: við þurfum ekki að kaupa fleiri hnúta með diskum ef við þurfum aðeins CPU/RAM. Að auki getum við bætt við blaðabúri og sparað rekki staðsetningu netþjóna.

Fyrir vikið höfum við ofsaman vettvang með eftirfarandi eiginleikum:

  • Allt að 64 hnútar í klasa (allt að 32 geymsluhnútar).
  • Lágmarksfjöldi hnúta í klasa er þrír (tveir fyrir Edge klasa).
  • Gagnaofframkvæmd: speglun með afritunarstuðli 2 og 3.
  • Metro þyrping.
  • Ósamstilltur VM afritun í annan HyperFlex þyrping.
  • Skipulagning á að skipta um VM í fjarlæga gagnaver.
  • Innfæddar skyndimyndir með Redirect-on-Write tækni.
  • Allt að 1 PB af nothæfu plássi við afritunarstuðul 3 og án tvítekningar. Við tökum ekki tillit til afritunarþáttar 2, því þetta er ekki valkostur fyrir alvarlega sölu.

Annar stór plús er auðveld stjórnun og dreifing. Öll flókin við að setja upp UCS netþjóna er séð um af sérhæfðum VM sem útbúinn er af Cisco verkfræðingum.

Uppsetning prófunarbekks:

  • 2 x Cisco UCS Fabric Interconnect 6248UP sem stjórnunarklasa og nethlutar (48 tengi sem starfa í Ethernet 10G/FC 16G ham).
  • Fjórir Cisco UCS HXAF240 M4 netþjónar.

Eiginleikar netþjóns:

CPU

2 x Intel® Xeon® E5-2690 v4

RAM

16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/tvískipuð röð/x4/1.2v

Net

UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet tengi

Geymsla HBA

Cisco 12G Modular SAS Pass through Controller

Geymsludiskar

1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB

Fleiri stillingarvalkostirTil viðbótar við valinn vélbúnað eru eftirfarandi valkostir í boði eins og er:

  • HXAF240c M5.
  • Einn eða tveir örgjörvar, allt frá Intel Silver 4110 til Intel Platinum I8260Y. Önnur kynslóð í boði.
  • 24 minnisrauf, ræmur frá 16 GB RDIMM 2600 til 128 GB LRDIMM 2933.
  • Frá 6 til 23 gagnadiska, einn skyndiminnisdiskur, einn kerfisdiskur og einn ræsidiskur.

Afkastagetu drif

  • HX-SD960G61X-EV 960GB 2.5 tommu Enterprise Value 6G SATA SSD (1X þol) SAS 960 GB.
  • HX-SD38T61X-EV 3.8TB 2.5 tommu Enterprise Value 6G SATA SSD (1X þol) SAS 3.8 TB.
  • Skyndiminni drif
  • HX-NVMEXPB-I375 375GB 2.5 tommu Intel Optane Drive, Extreme Perf & Endurance.
  • HX-NVMEHW-H1600* 1.6TB 2.5 tommu Ent. Perf. NVMe SSD (3X þol) NVMe 1.6 TB.
  • HX-SD400G12TX-EP 400GB 2.5 tommu Ent. Perf. 12G SAS SSD (10X þol) SAS 400 GB.
  • HX-SD800GBENK9** 800GB 2.5 tommu Ent. Perf. 12G SAS SED SSD (10X þol) SAS 800 GB.
  • HX-SD16T123X-EP 1.6TB 2.5 tommu Enterprise performance 12G SAS SSD (3X þol).

Kerfi/Log drif

  • HX-SD240GM1X-EV 240GB 2.5 tommu Enterprise Value 6G SATA SSD (Karfst uppfærslu).

Ræstu drif

  • HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.

Tengstu við netið í gegnum 40G, 25G eða 10G Ethernet tengi.

FI getur verið HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).

Prófið sjálft

Til að prófa diskundirkerfið notaði ég HCIBench 2.2.1. Þetta er ókeypis tól sem gerir þér kleift að gera sjálfvirkan stofnun álags frá mörgum sýndarvélum. Álagið sjálft er myndað af venjulegu fio.

Þyrpingin okkar samanstendur af fjórum hnútum, afritunarstuðull 3, allir diskar eru Flash.

Til að prófa bjó ég til fjórar gagnaverslanir og átta sýndarvélar. Fyrir skrifpróf er gert ráð fyrir að skyndiminnisdiskurinn sé ekki fullur.

Niðurstöður prófsins eru sem hér segir:

100% lesið 100% af handahófi

0% Lesið 100% af handahófi

Blokk/röð dýpt

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

Feitletrun gefur til kynna gildi eftir sem engin aukning er í framleiðni, stundum er jafnvel hnignun sýnileg. Þetta er vegna þess að við erum takmörkuð af frammistöðu netsins/stýringanna/diskanna.

  • Raðlestur 4432 MB/s.
  • Röð skrif 804 MB/s.
  • Ef einn stjórnandi bilar (bilun í sýndarvél eða hýsil) er árangursfallið tvíþætt.
  • Ef geymsludiskurinn bilar er niðurfellingin 1/3. Endurbygging diska tekur 5% af auðlindum hvers stjórnanda.

Á lítilli blokk erum við takmörkuð af frammistöðu stjórnandans (sýndarvél), örgjörvi hans er hlaðinn 100% og þegar blokkin stækkar erum við takmörkuð af bandbreidd portsins. 10 Gbps er ekki nóg til að opna möguleika AllFlash kerfisins. Því miður leyfa færibreytur meðfylgjandi kynningarstands okkur ekki að prófa notkun á 40 Gbit/s.

Að mínu mati frá prófunum og námi í arkitektúr, vegna reikniritsins sem setur gögn á milli allra véla, fáum við stigstærð, fyrirsjáanleg frammistöðu, en þetta er líka takmörkun við lestur, því það væri hægt að kreista meira út af staðbundnum diskum, hér gæti það bjargað afkastameiri neti, til dæmis er FI á 40 Gbit/s í boði.

Einnig getur einn diskur fyrir skyndiminni og aftvíföldun verið takmörkun; í raun getum við skrifað á fjóra SSD diska í þessu prófunarbeði. Það væri frábært að geta fjölgað skyndiminnisdrifum og séð muninn.

Raunveruleg notkun

Til að skipuleggja öryggisafrit af gagnaveri geturðu notað tvær aðferðir (við íhugum ekki að setja öryggisafrit á ytri síðu):

  1. Virkur-aðgerðalaus. Öll forrit eru hýst í aðalgagnaverinu. Afritun er samstillt eða ósamstillt. Ef aðalgagnaverið bilar þurfum við að virkja öryggisafritið. Þetta er hægt að gera handvirkt/forskriftir/hljómsveitarforrit. Hér munum við fá RPO í réttu hlutfalli við afritunartíðni og RTO fer eftir viðbrögðum og færni stjórnandans og gæðum þróunar/kembiforrita skiptaáætlunarinnar.
  2. Virkur-virkur. Í þessu tilviki er aðeins um samstillta afritun að ræða; framboð gagnavera er ákvörðuð af ályktun/dómara sem staðsett er stranglega á þriðju síðunni. RPO = 0, og RTO getur náð 0 (ef forritið leyfir) eða jafnt og bilunartíma hnúts í sýndarvæðingarklasa. Á sýndarvæðingarstigi er teygður (Metro) þyrping búinn til sem krefst Active-Active geymslu.

Venjulega sjáum við að viðskiptavinir hafa þegar innleitt arkitektúr með klassísku geymslukerfi í aðalgagnaverinu, þannig að við hönnum annað til afritunar. Eins og ég nefndi býður Cisco HyperFlex upp á ósamstillta afritun og teygjanlegan sýndarþyrpingu. Á sama tíma þurfum við ekki sérstakt geymslukerfi af Midrange stigi og hærra með dýrum afritunaraðgerðum og Active-Active gagnaaðgangi á tveimur geymslukerfum.

Sviðsmynd 1: Við erum með aðal- og varagagnaver, sýndarvæðingarvettvang á VMware vSphere. Öll afkastamikil kerfi eru staðsett í aðalgagnaverinu og afritun sýndarvéla er framkvæmd á yfirsýnarstigi, þetta mun koma í veg fyrir að kveikt sé á VM í öryggisafritunargagnaverinu. Við endurtökum gagnagrunna og sérstök forrit með innbyggðum verkfærum og höldum kveiktum á VM-tækjunum. Ef aðalgagnaverið bilar ræsum við kerfi í varagagnaverinu. Við teljum að við séum með um 100 sýndarvélar. Á meðan aðalgagnaverið er starfrækt getur biðgagnaverið keyrt prófunarumhverfi og önnur kerfi sem hægt er að loka ef aðalgagnaverið skiptir yfir. Það er líka mögulegt að við notum tvíhliða afritun. Frá sjónarhóli vélbúnaðar mun ekkert breytast.

Þegar um klassískan arkitektúr er að ræða munum við setja upp blendingsgeymslukerfi í hverju gagnaveri með aðgangi í gegnum FibreChannel, þrepaskiptingu, deduplication og þjöppun (en ekki á netinu), 8 netþjóna fyrir hverja síðu, 2 FibreChannel rofa og 10G Ethernet. Fyrir afritunar- og skiptistjórnun í klassískum arkitektúr getum við notað VMware verkfæri (Replication + SRM) eða þriðja aðila verkfæri, sem verða aðeins ódýrari og stundum þægilegri.

Myndin sýnir skýringarmyndina.

Admin án handa = ofursamruni?

Þegar Cisco HyperFlex er notað fæst eftirfarandi arkitektúr:

Admin án handa = ofursamruni?

Fyrir HyperFlex notaði ég netþjóna með stórum örgjörva/vinnsluminni vegna þess að... Sum auðlindanna munu fara í HyperFlex stjórnandi VM; hvað varðar örgjörva og minni, endurstillti ég jafnvel HyperFlex stillinguna aðeins til að spila ekki með Cisco og tryggja auðlindir fyrir þær VM sem eftir eru. En við getum yfirgefið FibreChannel rofa og við munum ekki þurfa Ethernet tengi fyrir hvern netþjón; staðbundin umferð er skipt innan FI.

Niðurstaðan var eftirfarandi uppsetning fyrir hverja gagnaver:

Servers

8 x 1U þjónn (384 GB vinnsluminni, 2 x Intel Gold 6132, FC HBA)

8 x HX240C-M5L (512 GB vinnsluminni, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)

SHD

Hybrid geymslukerfi með FC Front-End (20TB SSD, 130TB NL-SAS)

-

LAN

2 x Ethernet rofi 10G 12 tengi

-

SAN

2 x FC rofi 32/16Gb 24 tengi

2 x Cisco UCS FI 6332

Leyfi

VMware Ent Plus

Afritun og/eða skipun VM skipta

VMware Ent Plus

Ég útvegaði ekki afritunarhugbúnaðarleyfi fyrir Hyperflex, þar sem þetta er fáanlegt beint úr kassanum fyrir okkur.

Fyrir klassískan arkitektúr valdi ég söluaðila sem hefur fest sig í sessi sem hágæða og ódýr framleiðandi. Fyrir báða valkostina notaði ég staðalafsláttinn fyrir tiltekna lausn og fékk þar af leiðandi raunverð.

Cisco HyperFlex lausnin reyndist 13% ódýrari.

Sviðsmynd 2: stofnun tveggja virkra gagnavera. Í þessari atburðarás erum við að hanna teygðan þyrping á VMware.

Klassíski arkitektúrinn samanstendur af sýndarvæðingarþjónum, SAN (FC protocol) og tveimur geymslukerfum sem geta lesið og skrifað í rúmmálið sem strekkt er á milli þeirra. Á hvert geymslukerfi setjum við gagnlega geymslupláss.

Admin án handa = ofursamruni?

Hjá HyperFlex búum við einfaldlega til teygjuklasa með sama fjölda hnúta á báðum stöðum. Í þessu tilviki er afritunarstuðullinn 2+2 notaður.

Admin án handa = ofursamruni?

Niðurstaðan er eftirfarandi uppsetning:

klassískum byggingarlist

HyperFlex

Servers

16 x 1U þjónn (384 GB vinnsluminni, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)

16 x HX240C-M5L (512 GB vinnsluminni, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)

SHD

2 x AllFlash geymslukerfi (150 TB SSD)

-

LAN

4 x Ethernet rofi 10G 24 tengi

-

SAN

4 x FC rofi 32/16Gb 24 tengi

4 x Cisco UCS FI 6332

Leyfi

VMware Ent Plus

VMware Ent Plus

Í öllum útreikningum tók ég ekki tillit til netinnviða, gagnaverakostnaðar o.s.frv.: þeir verða þeir sömu fyrir klassískan arkitektúr og fyrir HyperFlex lausnina.

Hvað kostnað varðar reyndist HyperFlex vera 5% dýrari. Það er athyglisvert hér að hvað varðar CPU / vinnsluminni tilföng var ég með skekkju fyrir Cisco, vegna þess að í uppsetningunni fyllti ég minnisstýringarrásirnar jafnt. Kostnaðurinn er örlítið hærri, en ekki í stærðargráðu, sem gefur skýrt til kynna að ofsamruni sé ekki endilega „leikfang fyrir þá ríku“, heldur getur keppt við staðlaða nálgun við að byggja upp gagnaver. Þetta gæti líka verið áhugavert fyrir þá sem þegar hafa Cisco UCS netþjóna og samsvarandi innviði fyrir þá.

Meðal kostanna fáum við skortur á kostnaði við að stjórna SAN og geymslukerfum, þjöppun á netinu og aftvítekningu, einn aðgangsstað fyrir stuðning (sýndarvæðing, netþjónar, þetta eru líka geymslukerfi), spara pláss (en ekki í öllum tilfellum), einfalda rekstur.

Hvað stuðning varðar, hér færðu hann frá einum söluaðila - Cisco. Miðað við reynslu mína af Cisco UCS netþjónum líkar mér það; ég þurfti ekki að opna það á HyperFlex, allt virkaði eins. Verkfræðingar bregðast skjótt við og geta ekki aðeins leyst dæmigerð vandamál heldur einnig flókin jaðarmál. Stundum leita ég til þeirra með spurningum: "Er hægt að gera þetta, skrúfa það á?" eða „Ég stillti eitthvað hérna og það vill ekki virka. Hjálp!" - þeir munu þolinmóðir finna nauðsynlega leiðbeiningar þar og benda á réttar aðgerðir; þeir munu ekki svara: "Við leysum aðeins vélbúnaðarvandamál."

tilvísanir

Heimild: www.habr.com

Bæta við athugasemd