Admin sûnder hannen = hyperkonverginsje?

Admin sûnder hannen = hyperkonverginsje?
Admin sûnder hannen = hyperkonverginsje?

Dit is in myte dy't frij gewoan is op it mêd fan serverhardware. Yn 'e praktyk binne hyperkonvergearre oplossingen (as alles yn ien is) nedich foar in protte dingen. Histoarysk waarden de earste arsjitektueren ûntwikkele troch Amazon en Google foar har tsjinsten. Doe wie it idee om in komputerbuorkerij te meitsjen fan identike knopen, dy't elk syn eigen skiven hiene. Dit alles waard ferienige troch guon systeemfoarmjende software (hypervisor) en waard ferdield yn firtuele masines. It haaddoel is in minimum fan ynspannings foar it betsjinjen fan ien knooppunt en in minimum fan problemen by skaalfergrutting: keapje gewoan noch tûzen of twa fan deselde tsjinners en ferbine se tichtby. Yn 'e praktyk binne dit isolearre gefallen, en folle faker hawwe wy it oer in lytser oantal knopen en in wat oare arsjitektuer.

Mar de plus bliuwt itselde - ongelooflijk gemak fan skaalfergrutting en behear. It neidiel is dat ferskillende taken konsumearje boarnen oars, en op guon plakken sille d'r in protte lokale skiven wêze, yn oaren sil der in bytsje RAM wêze, ensfh.

It docht bliken dat jo 10–15% mear betelje foar maklike opset. Dit is wat de myte yn 'e titel feroarsake. Wy hawwe in lange tiid socht wêr't de technology optimaal tapast wurde soe, en wy fûnen it. It feit is dat Cisco gjin eigen opslachsystemen hie, mar se woene in folsleine servermerk. En se makken Cisco Hyperflex - in oplossing mei lokale opslach op knopen.

En dit blykte ynienen in heul goede oplossing te wêzen foar backup-datasintra (Disaster Recovery). Ik sil jo no fertelle wêrom en hoe. En ik sil jo de klustertests sjen litte.

Wêr nedich

Hyperkonverginsje is:

  1. It oerdragen fan skiven nei komputerknooppunten.
  2. Folsleine yntegraasje fan it opslachsubsysteem mei it virtualisaasjesubsysteem.
  3. Oerdracht / yntegraasje mei it netwurk subsysteem.

Dizze kombinaasje lit jo in protte opslachsysteemfunksjes ymplementearje op it virtualisaasjenivo en allegear út ien kontrôlefinster.

Yn ús bedriuw binne projekten foar it ûntwerpen fan oerstallige datasintra yn grutte fraach, en in hyperconverged oplossing wurdt faak keazen fanwegen in boskje replikaasje-opsjes (oant in metrocluster) út 'e doaze.

Yn it gefal fan backup-datasintra hawwe wy it meast oer in foarsjenning op ôfstân op in side oan 'e oare kant fan' e stêd of yn in oare stêd hielendal. It lit jo krityske systemen weromsette yn it gefal fan in foar in part of folsleine mislearring fan it haaddatasintrum. Ferkeapgegevens wurde dêr konstant replikearre, en dizze replikaasje kin wêze op it tapassingsnivo of op it nivo fan blokapparaat (opslach).

Dêrom, no sil ik prate oer it systeemûntwerp en tests, en dan oer in pear echte applikaasjescenario's mei besparringsgegevens.

Tests

Us eksimplaar bestiet út fjouwer servers, elk fan dy hat 10 SSD-skiven fan 960 GB. D'r is in tawijd skiif foar it cachen fan skriuwoperaasjes en it bewarjen fan de tsjinst firtuele masine. De oplossing sels is de fjirde ferzje. De earste is earlik rûch (beoardielje troch de resinsjes), de twadde is fochtich, de tredde is al frij stabyl, en dizze kin in release neamd wurde nei it ein fan beta-testen foar it algemien publyk. Tidens testen seach ik gjin problemen, alles wurket as in klok.

De wiziging yn' e V4In boskje bugs binne reparearre.

Yn earste ynstânsje koe it platfoarm allinich wurkje mei de VMware ESXi hypervisor en stipe in lyts oantal knopen. Ek it ynsetproses einige net altyd mei súkses, guon stappen moasten opnij starte, d'r wiene problemen mei it bywurkjen fan âldere ferzjes, gegevens yn 'e GUI waarden net altyd goed werjûn (hoewol't ik noch altyd net bliid bin mei it werjaan fan prestaasjesgrafiken ), soms ûntstiene problemen by de ynterface mei virtualisaasje.

No binne alle jeugdproblemen reparearre, HyperFlex kin sawol ESXi as Hyper-V omgean, plus it is mooglik om:

  1. It meitsjen fan in útwreide kluster.
  2. In kluster meitsje foar kantoaren sûnder Fabric Interconnect te brûken, fan twa oant fjouwer knopen (wy keapje allinich servers).
  3. Mooglikheid om te wurkjen mei eksterne opslachsystemen.
  4. Stipe foar konteners en Kubernetes.
  5. Oanmeitsjen fan beskikberens sônes.
  6. Yntegraasje mei VMware SRM as de ynboude funksjonaliteit net befredigjend is.

De arsjitektuer is net folle oars as de oplossingen fan har wichtichste konkurrinten; se makken gjin fyts. It rint allegear op it VMware- as Hyper-V-virtualisaasjeplatfoarm. De hardware wurdt hosted op eigen Cisco UCS-tsjinners. D'r binne dejingen dy't it platfoarm haatsje foar de relative kompleksiteit fan 'e earste opset, in protte knoppen, in net-trivial systeem fan sjabloanen en ôfhinklikens, mar d'r binne ek dyjingen dy't Zen leard hawwe, binne ynspireare troch it idee en wolle net mear om te wurkjen mei oare servers.

Wy sille de oplossing foar VMware beskôgje, om't de oplossing oarspronklik foar it is makke en mear funksjonaliteit hat; Hyper-V waard ûnderweis tafoege om by te hâlden mei konkurrinten en te foldwaan oan merkferwachtingen.

D'r is in kluster fan servers fol mei skiven. D'r binne skiven foar gegevensopslach (SSD of HDD - neffens jo smaak en behoeften), d'r is ien SSD-skiif foar caching. By it skriuwen fan gegevens nei de datastore, wurde de gegevens bewarre op 'e cachinglaach (tawijd SSD-skiif en RAM fan' e tsjinst VM). Parallel wurdt in blok gegevens stjoerd nei knooppunten yn it kluster (it oantal knooppunten hinget ôf fan 'e klusterreplikaasjefaktor). Nei befêstiging fan alle knopen oer suksesfolle opname, wurdt befêstiging fan 'e opname stjoerd nei de hypervisor en dan nei de VM. De opnommen gegevens wurde deduplicated, komprimearre en skreaun nei opslachskiven op 'e eftergrûn. Tagelyk wurdt altyd in grut blok skreaun oan 'e opslachskiven en sequentially, wat de lading op' e opslachskiven fermindert.

Deduplikaasje en kompresje binne altyd ynskeakele en kinne net útskeakele wurde. Gegevens wurde direkt lêzen fan opslachskiven of fan 'e RAM-cache. As in hybride konfiguraasje wurdt brûkt, wurde de lêzings ek op 'e SSD bewarre.

De gegevens binne net bûn oan 'e hjoeddeistige lokaasje fan' e firtuele masine en wurde gelyk ferdield tusken de knopen. Dizze oanpak lit jo alle skiven en netwurkynterfaces gelyk laden. D'r is in dúdlik neidiel: wy kinne de lêslatinsje net safolle mooglik ferminderje, om't d'r gjin garânsje is foar lokaal beskikberens fan gegevens. Mar ik leau dat dit in lyts offer is yn ferliking mei de ûntfongen foardielen. Boppedat hawwe netwurkfertragingen sokke wearden berikt dat se praktysk gjin ynfloed hawwe op it totale resultaat.

In spesjale tsjinst VM Cisco HyperFlex Data Platform controller, dat wurdt makke op elke opslach node, is ferantwurdlik foar de hiele operaasje logika fan de skiif subsysteem. Yn ús tsjinst VM-konfiguraasje waarden acht vCPU's en 72 GB RAM tawiisd, wat net sa min is. Lit my jo herinnerje dat de host sels 28 fysike kearnen en 512 GB RAM hat.

De tsjinst VM hat tagong ta fysike skiven direkt troch de SAS-controller troch te stjoeren nei de VM. Kommunikaasje mei de hypervisor bart troch in spesjale module IOVisor, dy't ûnderskept I / O operaasjes, en mei help fan in agint wêrmei jo te stjoeren kommando's nei de hypervisor API. De agint is ferantwurdlik foar it wurkjen mei HyperFlex-snapshots en klonen.

Skiifboarnen wurde yn 'e hypervisor monteard as NFS- of SMB-oandielen (ôfhinklik fan it type hypervisor, riede hokker ien is wêr). En ûnder de motorkap is dit in ferspraat bestânsysteem wêrmei jo funksjes kinne tafoegje fan folweardige opslachsystemen foar folwoeksenen: tawizing fan tinne folume, kompresje en deduplikaasje, snapshots mei Redirect-on-Write technology, syngroane / asynchrone replikaasje.

De tsjinst VM jout tagong ta de WEB-behearynterface fan it HyperFlex-subsysteem. D'r is yntegraasje mei vCenter, en de measte deistige taken kinne derút wurde útfierd, mar datastores, bygelyks, binne handiger om te snijen fan in aparte webcam as jo al oerstapt binne nei in rappe HTML5-ynterface, of in folsleine Flash-kliïnt brûke mei folsleine yntegraasje. Yn 'e tsjinstwebcam kinne jo de prestaasjes en detaillearre status fan it systeem besjen.

Admin sûnder hannen = hyperkonverginsje?

D'r is in oar type knooppunt yn in kluster - komputerknooppunten. Dizze kinne rack- of blade-tsjinners wêze sûnder ynboude skiven. Dizze servers kinne VM's útfiere wêrfan de gegevens wurde opslein op servers mei skiven. Ut it eachpunt fan tagong ta gegevens is d'r gjin ferskil tusken de soarten knooppunten, om't de arsjitektuer abstraksje fan 'e fysike lokaasje fan' e gegevens omfettet. De maksimale ferhâlding fan komputerknooppunten oant opslachknooppunten is 2:1.

It brûken fan komputerknooppunten fergruttet de fleksibiliteit by it skaaljen fan klusterboarnen: wy hoege gjin ekstra knopen te keapjen mei skiven as wy allinich CPU / RAM nedich binne. Dêrneist kinne wy ​​tafoegje in blêd koai en besparje op rack pleatsing fan tsjinners.

As gefolch hawwe wy in hyperkonvergearre platfoarm mei de folgjende funksjes:

  • Oant 64 knopen yn in kluster (oant 32 opslachknooppunten).
  • It minimum oantal knopen yn in kluster is trije (twa foar in Edge-kluster).
  • Data-redundânsjemeganisme: spegeljen mei replikaasjefaktor 2 en 3.
  • Metro kluster.
  • Asynchronous VM-replikaasje nei in oare HyperFlex-kluster.
  • Orkestraasje fan it wikseljen fan VM's nei in datasintrum op ôfstân.
  • Native snapshots mei Redirect-on-Write technology.
  • Oant 1 PB brûkbere romte by replikaasjefaktor 3 en sûnder deduplikaasje. Wy nimme gjin rekken mei replikaasjefaktor 2, om't dit gjin opsje is foar serieuze ferkeap.

In oare grutte plus is it gemak fan behear en ynset. Alle kompleksiteiten fan it ynstellen fan UCS-tsjinners wurde fersoarge troch in spesjalisearre VM taret troch Cisco-yngenieurs.

Testbankkonfiguraasje:

  • 2 x Cisco UCS Fabric Interconnect 6248UP as in behear kluster en netwurk komponinten (48 havens operearje yn Ethernet 10G / FC 16G modus).
  • Fjouwer Cisco UCS HXAF240 M4 tsjinners.

Server eigenskippen:

CPU

2 x Intel® Xeon® E5-2690 v4

RAAM

16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v

netwurk

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

Opslach HBA

Cisco 12G Modular SAS Pass troch Controller

Storage Disks

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

Mear konfiguraasje opsjesNeist de selektearre hardware binne de folgjende opsjes op it stuit beskikber:

  • HXAF240c M5.
  • Ien of twa CPU's fariearjend fan Intel Silver 4110 oant Intel Platinum I8260Y. Twadde generaasje beskikber.
  • 24 ûnthâld slots, strips út 16 GB RDIMM 2600 oan 128 GB LRDIMM 2933.
  • Fan 6 oant 23 data skiven, ien caching skiif, ien systeem skiif en ien boot skiif.

Kapasiteit Drives

  • HX-SD960G61X-EV 960GB 2.5 Inch Enterprise Wearde 6G SATA SSD (1X úthâldingsfermogen) SAS 960 GB.
  • HX-SD38T61X-EV 3.8TB 2.5 inch Enterprise Wearde 6G SATA SSD (1X úthâldingsfermogen) SAS 3.8 TB.
  • Caching Drives
  • HX-NVMEXPB-I375 375GB 2.5 inch Intel Optane Drive, Extreme Perf & Endurance.
  • HX-NVMEHW-H1600* 1.6TB 2.5 inch Ent. Perf. NVMe SSD (3X úthâldingsfermogen) NVMe 1.6 TB.
  • HX-SD400G12TX-EP 400GB 2.5 inch Ent. Perf. 12G SAS SSD (10X úthâldingsfermogen) SAS 400 GB.
  • HX-SD800GBENK9** 800GB 2.5 inch Ent. Perf. 12G SAS SED SSD (10X úthâldingsfermogen) SAS 800 GB.
  • HX-SD16T123X-EP 1.6TB 2.5 inch Enterprise prestaasjes 12G SAS SSD (3X úthâldingsfermogen).

Systeem / Log Drives

  • HX-SD240GM1X-EV 240GB 2.5 inch Enterprise Value 6G SATA SSD (fereasket upgrade).

Boot Drives

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

Ferbine mei it netwurk fia 40G, 25G of 10G Ethernet havens.

De FI kin wêze HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).

De test sels

Om it skiifsubsysteem te testen, haw ik HCIBench 2.2.1 brûkt. Dit is in fergese hulpprogramma wêrmei jo it oanmeitsjen fan in lading fan meardere firtuele masines kinne automatisearje. De lading sels wurdt generearre troch de gewoane fio.

Us kluster bestiet út fjouwer knopen, replikaasjefaktor 3, alle skiven binne Flash.

Foar testen makke ik fjouwer datastores en acht firtuele masines. Foar skriuwtests wurdt oannommen dat de caching-skiif net fol is.

De testresultaten binne as folget:

100% lêzen 100% willekeurich

0% Lêze 100% willekeurich

Blok / wachtrige djipte

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

Fet jout wearden wêrnei't d'r gjin ferheging fan produktiviteit is, soms is sels degradaasje sichtber. Dit komt troch it feit dat wy binne beheind troch de prestaasjes fan it netwurk / controllers / skiven.

  • Sekwinsjele lêzen 4432 MB / s.
  • Sekwinsjele skriuwe 804 MB / s.
  • As ien kontrôler mislearret (mislearjen fan in firtuele masine of host), is de prestaasjesfal twafold.
  • As de opslachskiif mislearret, is de drawdown 1/3. Skiif werbou nimt 5% fan 'e boarnen fan elke controller.

Op in lyts blok binne wy ​​​​beheind troch de prestaasjes fan 'e controller (firtuele masine), syn CPU wurdt laden op 100%, en as it blok ferheget, wurde wy beheind troch de poartebânbreedte. 10 Gbps is net genôch om it potensjeel fan it AllFlash-systeem te ûntsluten. Spitigernôch litte de parameters fan 'e levere demo-stand ús net tastean om operaasje te testen op 40 Gbit / s.

Yn myn yndruk fan testen en it bestudearjen fan 'e arsjitektuer, troch it algoritme dat gegevens pleatst tusken alle hosts, krije wy skalberbere, foarsisbere prestaasjes, mar dit is ek in beheining by it lêzen, om't it mooglik wêze soe om mear út lokale skiven te squeeze, hjir kin it bewarje in mear produktive netwurk, Bygelyks, FI op 40 Gbit / s is beskikber.

Ek kin ien skiif foar caching en deduplikaasje in beheining wêze; yn feite kinne wy ​​yn dit testbêd skriuwe nei fjouwer SSD-skiven. It soe geweldich wêze om it oantal caching-skiven te ferheegjen en it ferskil te sjen.

Echt gebrûk

Om in reservekopydatasintrum te organisearjen, kinne jo twa oanpakken brûke (wy beskôgje net it pleatsen fan in reservekopy op in side op ôfstân):

  1. Aktyf-passyf. Alle applikaasjes wurde host yn it haaddatasintrum. Replikaasje is syngroane of asynchrone. As it haadgegevenssintrum mislearret, moatte wy de reservekopy aktivearje. Dit kin mei de hân dien wurde / skripts / orkestraasjeapplikaasjes. Hjir sille wy in RPO krije dy't oerienkomt mei de replikaasjefrekwinsje, en de RTO hinget ôf fan 'e reaksje en feardichheden fan' e behearder en de kwaliteit fan ûntwikkeling / debuggen fan it wikselplan.
  2. Aktyf-aktyf. Yn dit gefal is d'r allinich syngroane replikaasje; de ​​beskikberens fan datasintra wurdt bepaald troch in quorum / arbiter dy't strikt op 'e tredde side leit. RPO = 0, en RTO kin berikke 0 (as de applikaasje it talit) of gelyk oan de failover tiid fan in knooppunt yn in virtualization kluster. Op it virtualisaasjenivo wurdt in útwreide (Metro) kluster makke dy't Active-Active opslach fereasket.

Gewoanlik sjogge wy dat kliïnten al in arsjitektuer hawwe ymplementearre mei in klassyk opslachsysteem yn it haaddatasintrum, dus ûntwerpe wy in oare foar replikaasje. Lykas ik neamde, biedt Cisco HyperFlex asynchrone replikaasje en oanmeitsjen fan útwreide virtualisaasjekluster. Tagelyk hawwe wy gjin tawijd opslachsysteem fan it Midrange-nivo en heger nedich mei djoere replikaasjefunksjes en Active-Active gegevenstagong op twa opslachsystemen.

Senario 1: Wy hawwe in primêre en reservekopy data sintra, in virtualization platfoarm op VMware vSphere. Alle produktive systemen lizze yn it haaddatasintrum, en replikaasje fan firtuele masines wurdt útfierd op it hypervisornivo, dit sil foarkomme dat VM's ynskeakele wurde yn it backupdatasintrum. Wy replikearje databases en spesjale applikaasjes mei ynboude ark en hâlde de VM's ynskeakele. As it haaddatasintrum mislearret, lansearje wy systemen yn it backupdatasintrum. Wy leauwe dat wy sawat 100 firtuele masines hawwe. Wylst it primêre datasintrum operasjoneel is, kin it standby-datasintrum testomjouwings en oare systemen útfiere dy't kinne wurde ôfsletten as it primêre datasintrum oerskeakelt. It is ek mooglik dat wy twa-wei replikaasje brûke. Ut in hardware eachpunt sil neat feroarje.

Yn it gefal fan klassike arsjitektuer sille wy yn elk datasintrum in hybride opslachsysteem ynstalleare mei tagong fia FibreChannel, tier, deduplication en kompresje (mar net online), 8 servers foar elke side, 2 FibreChannel-skeakels en 10G Ethernet. Foar replikaasje- en wikselbehear yn in klassike arsjitektuer kinne wy ​​​​VMware-ark brûke (Replication + SRM) as ark fan tredden, dy't in bytsje goedkeaper en soms handiger sille wêze.

De figuer toant it diagram.

Admin sûnder hannen = hyperkonverginsje?

By it brûken fan Cisco HyperFlex wurdt de folgjende arsjitektuer krigen:

Admin sûnder hannen = hyperkonverginsje?

Foar HyperFlex brûkte ik servers mei grutte CPU / RAM-boarnen, om't ... Guon fan 'e boarnen sille nei de HyperFlex-controller VM gean; yn termen fan CPU en ûnthâld, haw ik sels de HyperFlex-konfiguraasje in bytsje opnij konfigureare om net tegearre mei Cisco te spyljen en boarnen te garandearjen foar de oerbleaune VM's. Mar wy kinne FibreChannel-skeakels ferlitte, en wy sille gjin Ethernet-poarten nedich hawwe foar elke tsjinner; lokaal ferkear wurdt oerskeakele binnen FI.

It resultaat wie de folgjende konfiguraasje foar elk datasintrum:

Tsjinners

8 x 1U-tsjinner (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

Hybride opslachsysteem mei FC Front-End (20TB SSD, 130TB NL-SAS)

-

LAN

2 x Ethernet switch 10G 12 havens

-

SAN

2 x FC switch 32/16Gb 24 havens

2 x Cisco UCS FI 6332

Lisinsjes

VMware Ent Plus

Replikaasje en / of orkestraasje fan VM-skeakeljen

VMware Ent Plus

Ik haw gjin lisinsjes foar replikaasjesoftware foar Hyperflex levere, om't dit foar ús út 'e doaze beskikber is.

Foar klassike arsjitektuer keas ik in ferkeaper dy't har fêstige hat as in hege kwaliteit en goedkeape fabrikant. Foar beide opsjes haw ik de standertkoarting tapast foar in spesifike oplossing, en as gefolch krige ik echte prizen.

De Cisco HyperFlex-oplossing die bliken 13% goedkeaper te wêzen.

Senario 2: skepping fan twa aktive datasintra. Yn dit senario ûntwerpe wy in útwreide kluster op VMware.

De klassike arsjitektuer bestiet út virtualisaasjetsjinners, in SAN (FC-protokol) en twa opslachsystemen dy't lêze en skriuwe kinne nei it folume dat tusken har útspand is. Op elk opslachsysteem sette wy in nuttige kapasiteit foar opslach.

Admin sûnder hannen = hyperkonverginsje?

By HyperFlex meitsje wy gewoan in Stretch Cluster mei itselde oantal knopen op beide siden. Yn dit gefal wurdt in replikaasjefaktor fan 2+2 brûkt.

Admin sûnder hannen = hyperkonverginsje?

It resultaat is de folgjende konfiguraasje:

klassike arsjitektuer

HyperFlex

Tsjinners

16 x 1U-tsjinner (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 opslachsystemen (150 TB SSD)

-

LAN

4 x Ethernet switch 10G 24 havens

-

SAN

4 x FC switch 32/16Gb 24 havens

4 x Cisco UCS FI 6332

Lisinsjes

VMware Ent Plus

VMware Ent Plus

Yn alle berekkeningen haw ik net rekken holden mei de netwurkynfrastruktuer, kosten fan datasintrum, ensfh.: se sille itselde wêze foar de klassike arsjitektuer en foar de HyperFlex-oplossing.

Yn termen fan kosten die HyperFlex 5% djoerder te wêzen. It is de muoite wurdich opskriuwen dat yn termen fan CPU / RAM boarnen ik hie in skew foar Cisco, want yn 'e konfiguraasje ik fol it ûnthâld controller kanalen gelyk. De kosten binne wat heger, mar net troch in folchoarder fan grutte, wat dúdlik oanjout dat hyperkonverginsje net needsaaklik is in "boartersguod foar de rike", mar kin konkurrearje mei de standert oanpak foar it bouwen fan in datasintrum. Dit kin ek fan belang wêze foar dyjingen dy't al Cisco UCS-tsjinners hawwe en de oerienkommende ynfrastruktuer foar har.

Under de foardielen krije wy it ûntbrekken fan kosten foar it administrearjen fan SAN en opslachsystemen, online kompresje en deduplikaasje, ien yngongspunt foar stipe (virtualisaasje, servers, se binne ek opslachsystemen), romte besparje (mar net yn alle senario's), ferienfâldigjen operaasje.

As foar stipe, hjir krije jo it fan ien ferkeaper - Cisco. Te oardieljen nei myn ûnderfining mei Cisco UCS-tsjinners, fyn ik it leuk; Ik moast it net iepenje op HyperFlex, alles wurke krekt itselde. Yngenieurs reagearje prompt en kinne net allinich typyske problemen oplosse, mar ek komplekse rânegefallen. Soms draai ik my mei fragen: "Is it mooglik om dit te dwaan, skroef it op?" of "Ik konfigurearre wat hjir, en it wol net wurkje. Help!" - se sille dêr geduldich de nedige gids fine en de juste aksjes oanwize; se sille net antwurdzje: "Wy losse allinich hardwareproblemen op."

referinsjes

Boarne: www.habr.com

Add a comment