Admin eskurik gabe = hiperkonbergentzia?

Admin eskurik gabe = hiperkonbergentzia?
Admin eskurik gabe = hiperkonbergentzia?

Zerbitzarien hardwarearen alorrean nahiko ohikoa den mito bat da. Praktikan, soluzio hiperkonbergetuak (dena batean dagoenean) gauza askotarako behar dira. Historikoki, lehen arkitekturak Amazonek eta Googlek garatu zituzten beren zerbitzuetarako. Orduan, nodo berdinetatik abiatuta informatika-baserri bat egitea zen, bakoitzak bere diskoak zituen. Hori guztia sistemak osatzeko software batzuek (hipervisor) batu eta makina birtualetan banatuta zegoen. Helburu nagusia nodo bati zerbitzua emateko gutxieneko esfortzua eta eskalatzean arazo minimo bat izatea da: beste mila edo bi zerbitzari berdin erosi eta gertu konektatu. Praktikan, kasu isolatuak dira, eta askoz maizago nodo kopuru txikiagoaz eta arkitektura apur bat desberdinaz ari gara.

Baina abantailak berdin jarraitzen du: eskalatzeko eta kudeatzeko erraztasun ikaragarria. Alde txarra da zeregin ezberdinek baliabideak modu ezberdinean kontsumitzen dituztela, eta toki batzuetan disko lokal asko egongo dira, beste batzuetan RAM gutxi egongo da, eta abar, hau da, zeregin mota ezberdinetarako, baliabideen erabilera gutxitu egingo da.

Konfigurazioa errazteko % 10-15 gehiago ordaintzen duzula ematen du. Hau da izenburuko mitoa piztu zuena. Denbora luzea eman genuen teknologia hobekien non aplikatuko zen bilatzen, eta aurkitu genuen. Kontua da Ciscok ez zuela biltegiratze sistema propiorik, baina zerbitzarien merkatu osoa nahi zuten. Eta Cisco Hyperflex egin zuten - nodoetan tokiko biltegiratzea duen irtenbidea.

Eta hori bat-batean oso irtenbide ona izan zen segurtasun kopiako datu-zentroetarako (Disaster Recovery). Orain zergatik eta nola esango dizut. Eta cluster probak erakutsiko dizkizut.

Behar den tokian

Hiperkonbergentzia hau da:

  1. Diskoak konputazio-nodoetara transferitzea.
  2. Biltegiratze azpisistema birtualizazio azpisistemarekin erabat integratzea.
  3. Sareko azpisistemarekin transferentzia/integrazioa.

Konbinazio honek biltegiratze-sistemaren ezaugarri asko birtualizazio mailan ezartzeko aukera ematen du eta guztiak kontrol-leiho batetik.

Gure enpresan, datu-zentro erredundanteak diseinatzeko proiektuek eskaera handia dute, eta soluzio hiperkonbergeatu bat aukeratzen da askotan erreplikazio-aukera mordoa dela eta (metrokluster bateraino) kaxatik kanpo.

Babeskopiako datu-zentroen kasuan, normalean hiriaren beste aldean dagoen gune batean edo guztiz beste hiri batean dagoen urruneko instalazio bati buruz ari gara. Datu-zentro nagusiaren hutsegite partzial edo osoa gertatuz gero sistema kritikoak leheneratzeko aukera ematen du. Salmenta-datuak etengabe errepikatzen dira bertan, eta erreplikazio hau aplikazio mailan edo bloke-gailu (biltegiratze) mailan izan daiteke.

Hori dela eta, orain sistemaren diseinuari eta probei buruz hitz egingo dut, eta, ondoren, aurrezte-datuak dituzten aplikazio-eszenatoki errealei buruz.

probak

Gure instantzia lau zerbitzariz osatuta dago, eta horietako bakoitzak 10 GB-ko 960 SSD unitate ditu. Disko dedikatu bat dago idazketa eragiketak gordetzeko eta zerbitzuaren makina birtuala gordetzeko. Irtenbidea bera laugarren bertsioa da. Lehenengoa nahiko gordina da (iritziak ikusita), bigarrena hezea da, hirugarrena nahiko egonkorra da dagoeneko, eta hau publiko orokorrarentzat beta probak amaitu ondoren kaleratze dei daiteke. Probetan ez nuen arazorik ikusi, dena erloju baten moduan funtzionatzen du.

Aldaketak v4Akats mordo bat konpondu dira.

Hasieran, plataformak VMware ESXi hipervisorearekin bakarrik funtziona zezakeen eta nodo kopuru txiki bat onartzen zuen. Gainera, inplementazio-prozesua ez zen beti arrakastaz amaitu, urrats batzuk berrabiarazi behar izan ziren, bertsio zaharragoetatik eguneratzeko arazoak egon ziren, GUIko datuak ez ziren beti behar bezala bistaratzen (nahiz eta oraindik ez nago pozik errendimendu grafikoen bistaratzearekin ), batzuetan arazoak sortzen ziren birtualizazioarekin interfazean.

Orain haurtzaroko arazo guztiak konpondu dira, HyperFlex-ek ESXi eta Hyper-V kudeatu ditzake, gainera posible da:

  1. Hedatutako kluster bat sortzea.
  2. Fabric Interconnect erabili gabe bulegoetarako cluster bat sortzea, bitik lau nodotik (zerbitzariak soilik erosten ditugu).
  3. Kanpoko biltegiratze sistemekin lan egiteko gaitasuna.
  4. Edukiontzietarako eta Kubernetesentzako euskarria.
  5. Eskuragarritasun guneak sortzea.
  6. VMware SRM-rekin integratzea integratutako funtzionaltasuna asegarria ez bada.

Arkitektura ez da oso desberdina lehiakide nagusien soluzioetatik; ez zuten bizikletarik sortu. Guztia VMware edo Hyper-V birtualizazio plataforman exekutatzen da. Hardwarea Cisco UCS zerbitzari jabedunetan dago ostatatuta. Badira plataforma gorroto dutenak hasierako konfigurazioaren konplexutasun erlatiboagatik, botoi askogatik, txantiloien eta menpekotasunen sistema ez hutsalagatik, baina badira Zen ikasi dutenak, ideian inspiratuta daudenak eta jada nahi ez dutenak. beste zerbitzariekin lan egiteko.

VMware-ren soluzioa kontuan hartuko dugu, hasiera batean irtenbidea horretarako sortu zen eta funtzionalitate gehiago duelako; Hyper-V gehitu zen bidean lehiakideekin jarraitzeko eta merkatuaren itxaropenak asetzeko.

Diskoz betetako zerbitzari multzo bat dago. Datuak gordetzeko diskoak daude (SSD edo HDD - zure gustu eta beharren arabera), SSD disko bat dago cachean gordetzeko. Datu-biltegian datuak idaztean, datuak cache geruzan gordetzen dira (SSD disko dedikatua eta zerbitzuaren VM-aren RAM). Paraleloan, datu-bloke bat bidaltzen da klusterreko nodoetara (nodo kopurua klusterraren erreplikazio-faktorearen araberakoa da). Grabaketa arrakastatsuari buruzko nodo guztiek baieztatu ondoren, grabazioaren berrespena hipervisorera bidaltzen da eta ondoren VMra. Grabatutako datuak desbikoiztu, konprimitu eta biltegiratze-diskoetan idazten dira atzeko planoan. Aldi berean, bloke handi bat beti idazten da biltegiratze-diskoetan eta sekuentzialki, eta horrek biltegiratze-diskoen karga murrizten du.

Desduplicazioa eta konpresioa beti gaituta daude eta ezin dira desgaitu. Datuak zuzenean irakurtzen dira biltegiratze diskoetatik edo RAM cachetik. Konfigurazio hibrido bat erabiltzen bada, irakurketak SSD-n ere gordetzen dira.

Datuak ez daude makina birtualaren uneko kokapenari lotuta eta nodoen artean uniformeki banatzen dira. Planteamendu honek disko eta sareko interfaze guztiak berdin kargatzeko aukera ematen du. Desabantaila nabaria dago: ezin dugu irakurtzeko latentzia ahalik eta gehien murriztu, ez baitago tokiko datuen erabilgarritasuna bermatzen. Baina uste dut sakrifizio txiki bat dela jasotako onurekin alderatuta. Gainera, sareko atzerapenak halako balioetara iritsi dira, non ia ez baitute emaitza orokorrari eragiten.

Biltegiratze-nodo bakoitzean sortzen den VM Cisco HyperFlex Data Platform kontrolagailu zerbitzu berezi bat da disko azpisistemaren funtzionamendu-logika osoaren arduraduna. Gure zerbitzuko VM konfigurazioan, zortzi vCPU eta 72 GB RAM esleitu ziren, hori ez da hain gutxi. Gogorarazten dizut ostalariak berak 28 nukleo fisiko eta 512 GB RAM dituela.

Zerbitzu VM-ak disko fisikoetarako sarbidea du zuzenean SAS kontrolagailua VMra birbidaltuz. Hipervisorearekin komunikazioa IOVisor modulu berezi baten bidez gertatzen da, I/O eragiketak atzematen dituena, eta hipervisorearen APIra komandoak bidaltzeko aukera ematen duen agente bat erabiliz. Agentea HyperFlex argazkiekin eta klonekin lan egiteaz arduratzen da.

Disko baliabideak hipervisorean NFS edo SMB partekatze gisa muntatzen dira (hipervisore motaren arabera, asmatu zein den non). Eta kaputxaren azpian, helduentzako biltegiratze-sistemen ezaugarriak gehitzeko aukera ematen duen fitxategi sistema banatua da: bolumen meheen esleipena, konpresioa eta desduplicazioa, Redirect-on-Write teknologia erabiliz argazkiak, erreplikazio sinkronoa/asinkronoa.

Zerbitzu VM-ak HyperFlex azpisistemaren WEB kudeaketa interfazera sarbidea ematen du. vCenter-en integrazioa dago, eta eguneroko zeregin gehienak bertatik egin daitezke, baina datu-biltegiak, adibidez, erosoagoak dira webcam bereizi batetik moztea dagoeneko HTML5 interfaze azkar batera aldatu bazara edo Flash bezero oso bat erabiltzen baduzu. integrazio osoarekin. Zerbitzuaren webcam-ean sistemaren errendimendua eta egoera zehatza ikus ditzakezu.

Admin eskurik gabe = hiperkonbergentzia?

Cluster batean beste nodo mota bat dago: informatika-nodoak. Hauek rack edo blade zerbitzariak izan daitezke disko barneraturik gabe. Zerbitzari hauek VM exekutatu ditzakete zeinen datuak diskodun zerbitzarietan gordetzen diren. Datuen sarbidearen ikuspuntutik, ez dago desberdintasunik nodo moten artean, arkitekturak datuen kokapen fisikotik abstrakzioa dakarrelako. Konputazio-nodoen eta biltegiratze-nodoen gehienezko erlazioa 2:1 da.

Konputazio-nodoak erabiltzeak malgutasuna areagotzen du kluster baliabideak eskalatzerakoan: ez dugu nodo gehigarririk erosi behar diskoekin CPU/RAM bakarrik behar badugu. Horrez gain, blade kaiola bat gehi dezakegu eta zerbitzarien rack kokatzean aurreztu.

Ondorioz, plataforma hiperkonbergatu bat dugu ezaugarri hauek dituena:

  • Gehienez 64 nodo kluster batean (gehienez 32 biltegiratze nodo).
  • Kluster bateko gutxieneko nodo kopurua hiru da (bi Edge kluster baterako).
  • Datuen erredundantzia-mekanismoa: 2 eta 3 erreplikazio-faktorearekin islatzea.
  • Metro klusterra.
  • VM asinkronoaren erreplikazioa beste HyperFlex kluster batera.
  • VM-ak urruneko datu-zentro batera aldatzeko orkestrazioa.
  • Bertako argazkiak Birbideratu-on-Write teknologia erabiliz.
  • Gehienez 1 PB espazio erabilgarri 3. erreplikazio-faktorean eta deduplicaziorik gabe. Ez dugu 2. erreplikazio-faktorea kontuan hartzen, hau ez baita salmenta serioetarako aukera bat.

Beste abantaila handi bat kudeatzeko eta hedatzeko erraztasuna da. UCS zerbitzariak konfiguratzeko konplexutasun guztiak Cisco ingeniariek prestatutako VM espezializatu batek arduratzen ditu.

Proba-bankuaren konfigurazioa:

  • 2 x Cisco UCS Fabric Interconnect 6248UP kudeaketa-kluster eta sareko osagai gisa (48 ataka Ethernet 10G/FC 16G moduan funtzionatzen dutenak).
  • Lau Cisco UCS HXAF240 M4 zerbitzari.

Zerbitzariaren ezaugarriak:

CPU

2 x Intel® Xeon® E5-2690 v4

RAM

16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/maila bikoitza/x4/1.2v

Sarea

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

Biltegiratze HBA

Cisco 12G Modular SAS kontrolagailuaren bidez igarotzea

Biltegiratze Diskoak

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

Konfigurazio aukera gehiagoHautatutako hardwareaz gain, une honetan aukera hauek daude eskuragarri:

  • HXAF240c M5.
  • Intel Silver 4110 eta Intel Platinum I8260Y bitarteko CPU bat edo bi. Bigarren belaunaldia eskuragarri.
  • 24 memoria zirrikituak, 16 GB RDIMM 2600tik 128 GB LRDIMM 2933ra bitarteko zerrendak.
  • 6 eta 23 datu-disko, cacheko disko bat, sistema-disko bat eta abio-disko bat.

Edukiera unitateak

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

Sistema/Erregistro unitateak

  • HX-SD240GM1X-EV 240 GB 2.5 hazbeteko Enterprise Value 6G SATA SSD (Bertsioa behar du).

Abiarazteko unitateak

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

Konektatu sarera 40G, 25G edo 10G Ethernet ataken bidez.

FI HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G) izan daiteke.

Proba bera

Disko azpisistema probatzeko, HCIBench 2.2.1 erabili dut. Hau doako utilitate bat da, hainbat makina birtualetatik karga bat sortzea automatizatzeko aukera ematen duena. Karga bera ohiko fio-k sortzen du.

Gure klusterrak lau nodo ditu, 3. erreplikazio-faktorea, disko guztiak Flash dira.

Probak egiteko, lau datu-biltegi eta zortzi makina birtual sortu ditut. Idazketa-probetarako, cachean gordetzeko diskoa beteta ez dagoela suposatzen da.

Proben emaitzak honako hauek dira:

%100 Irakurri %100 Ausazko

% 0 Irakurri % 100 Ausazkoa

Bloke/ilararen sakonera

128

256

512

1024

2048

128

256

512

1024

2048

4K

0,59 ms 213804 IOPS

0,84 ms 303540 IOPS

1,36 ms 374348 IOPS

2.47 ms 414116 IOPS

4,86 ms 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

Lodiak balioak adierazten ditu eta ondoren ez dago produktibitatea handitzen, batzuetan degradazioa ere ikusten da. Sare/kontrolagailu/diskoen errendimenduak mugatuta gaudelako gertatzen da hori.

  • Irakurketa sekuentziala 4432 MB/s.
  • Idazketa sekuentziala 804 MB/s.
  • Kontrolagailu batek huts egiten badu (makina birtual edo ostalari baten porrota), errendimenduaren jaitsiera bikoitza da.
  • Biltegiratze diskoak huts egiten badu, beherapena 1/3 da. Diskoa berreraikitzeak kontrolagailu bakoitzaren baliabideen % 5 hartzen du.

Bloke txiki batean, kontrolagailuaren (makina birtuala) errendimenduak mugatzen gaitu, bere CPU % 100ean kargatzen da eta blokea handitzen denean, portuaren banda-zabalerak mugatzen gaitu. 10 Gbps ez da nahikoa AllFlash sistemaren potentziala desblokeatzeko. Zoritxarrez, emandako demo standaren parametroek ez digute 40 Gbit/s-ko funtzionamendua probatzen uzten.

Probetan eta arkitektura aztertzean, datuak ostalari guztien artean jartzen dituen algoritmoaren ondorioz, errendimendu eskalagarria eta aurreikusgarria lortzen dugu, baina hori ere muga bat da irakurtzerakoan, tokiko diskoetatik gehiago ateratzeko aukera izango litzatekeelako. hemen sare produktiboagoa gorde daiteke, adibidez, 40 Gbit/s-ko FI eskuragarri dago.

Gainera, cachean gordetzeko eta desduplicatzeko disko bat muga bat izan daiteke; izan ere, proba-base honetan lau SSD diskotan idatz ditzakegu. Oso ona izango litzateke caching unitateen kopurua handitu eta aldea ikustea.

Benetako erabilera

Babeskopiako datu-zentro bat antolatzeko, bi ikuspegi erabil ditzakezu (ez dugu kontuan hartzen babeskopia bat urruneko gune batean jartzea):

  1. Aktibo-Pasiboa. Aplikazio guztiak datu-zentro nagusian daude ostatatuta. Erreplikazioa sinkronoa edo asinkronoa da. Datu-zentro nagusiak huts egiten badu, babeskopia aktibatu behar dugu. Hau eskuz/gidoiak/orkestrazio aplikazioak egin daiteke. Hemen erreplika maiztasunaren araberako RPO bat lortuko dugu, eta RTO administratzailearen erreakzio eta trebetasunen eta aldaketa-planaren garapen/arazketa kalitatearen araberakoa da.
  2. Aktibo-Aktibo. Kasu honetan, erreplikazio sinkronikoa baino ez dago; datu-zentroen erabilgarritasuna hirugarren gunean zorrozki kokatutako quorum/arbitru batek zehazten du. RPO = 0, eta RTO 0 izatera irits daiteke (aplikazioak baimentzen badu) edo birtualizazio kluster bateko nodo baten hutsegiteko denboraren berdina. Birtualizazio mailan, biltegiratze aktibo-aktiboa behar duen kluster hedatua (Metro) sortzen da.

Normalean bezeroek datu-zentro nagusian biltegiratze sistema klasikoa duen arkitektura bat ezarri dutela ikusten dugu, beraz, beste bat diseinatzen dugu erreplikatzeko. Esan dudan bezala, Cisco HyperFlex-ek erreplikazio asinkronoa eta birtualizazio kluster hedatua sortzea eskaintzen du. Aldi berean, ez dugu erdi mailako eta goi mailako biltegiratze-sistema dedikaturik behar erreplikazio-funtzio garestiekin eta bi biltegiratze-sistemetan datu aktibo-aktiboen sarbidearekin.

1. eszenatokia: Datu-zentro nagusiak eta babeskopia ditugu, birtualizazio plataforma bat VMware vSphere-n. Sistema produktibo guztiak datu-zentro nagusian kokatuta daude, eta makina birtualen erreplika hipervisore mailan egiten da, honek VMak babeskopiko datu-zentroan aktibatuta mantentzea saihestuko du. Datu-baseak eta aplikazio bereziak erreplikatzen ditugu tresna integratuak erabiliz eta VM-ak aktibatuta mantentzen ditugu. Datu-zentro nagusiak huts egiten badu, babeskopiko datu-zentroan sistemak abiarazten ditugu. 100 makina birtual inguru ditugula uste dugu. Datu-zentro nagusia funtzionatzen ari den bitartean, egonean dagoen datu-zentroak proba-inguruneak eta beste sistema batzuk exekutatu ditzake, datu-zentro nagusia aldatzen bada itzal daitezkeen beste sistema batzuk. Baliteke ere bi norabideko erreplikazioa erabiltzea. Hardwarearen ikuspuntutik, ez da ezer aldatuko.

Arkitektura klasikoaren kasuan, datu-zentro bakoitzean FibreChannel bidezko sarbidea duen biltegiratze sistema hibrido bat instalatuko dugu, mailaketa, desduplicazioa eta konpresioa (baina ez online), gune bakoitzeko 8 zerbitzari, 2 FibreChannel switch eta 10G Ethernet. Arkitektura klasiko batean erreplika eta aldaketa kudeatzeko, VMware tresnak (Replication + SRM) edo hirugarrenen tresnak erabil ditzakegu, apur bat merkeagoak eta batzuetan erosoagoak izango direnak.

Irudiak diagrama erakusten du.

Admin eskurik gabe = hiperkonbergentzia?

Cisco HyperFlex erabiltzean, arkitektura hau lortzen da:

Admin eskurik gabe = hiperkonbergentzia?

HyperFlex-erako, CPU/RAM baliabide handiak dituzten zerbitzariak erabili ditut, zeren... Baliabideetako batzuk HyperFlex kontrolagailu VMra joango dira; CPU eta memoriari dagokionez, HyperFlex konfigurazioa apur bat berriro konfiguratu dut, Ciscorekin batera ez jolasteko eta gainerako VMetarako baliabideak bermatzeko. Baina FibreChannel etengailuak alde batera utzi ditzakegu, eta ez dugu Ethernet atakarik beharko zerbitzari bakoitzeko; tokiko trafikoa FIren barruan aldatzen da.

Emaitza datu-zentro bakoitzeko konfigurazio hau izan da:

Zerbitzariak

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

Biltegiratze sistema hibridoa FC Front-end-arekin (20TB SSD, 130TB NL-SAS)

-

LAN

2 x Ethernet switch 10G 12 ataka

-

SAN

2 x FC switch 32/16Gb 24 ataka

2 x Cisco UCS FI 6332

Lizentziak

VMware Ent Plus

VM aldatzearen erreplika eta/edo orkestrazioa

VMware Ent Plus

Ez nion erreplika-softwarearen lizentziarik eman Hyperflex-i, hau guretzat eskuragarri baitago.

Arkitektura klasikorako, kalitate handiko eta merke fabrikatzaile gisa ezarri den saltzaile bat aukeratu nuen. Bi aukeretarako, irtenbide zehatz baterako deskontu estandarra aplikatu nuen, eta, ondorioz, benetako prezioak jaso nituen.

Cisco HyperFlex irtenbidea % 13 merkeagoa izan da.

2. eszenatokia: bi datu-zentro aktibo sortzea. Eszenatoki honetan, VMware-n kluster luzatu bat diseinatzen ari gara.

Arkitektura klasikoa birtualizazio zerbitzariek, SAN batek (FC protokoloa) eta haien artean luzatutako bolumenean irakurri eta idatzi dezaketen bi biltegiratze sistemak osatzen dute. Biltegiratze-sistema bakoitzean biltegiratzeko ahalmen erabilgarria jarri dugu.

Admin eskurik gabe = hiperkonbergentzia?

HyperFlex-en, besterik gabe, Stretch Cluster bat sortzen dugu bi guneetan nodo kopuru berdinarekin. Kasu honetan, 2+2ko erreplikazio-faktorea erabiltzen da.

Admin eskurik gabe = hiperkonbergentzia?

Emaitza honako konfigurazio hau da:

arkitektura klasikoa

HyperFlex

Zerbitzariak

16 x 1U zerbitzari (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 biltegiratze sistema (150 TB SSD)

-

LAN

4 x Ethernet switch 10G 24 ataka

-

SAN

4 x FC switch 32/16Gb 24 ataka

4 x Cisco UCS FI 6332

Lizentziak

VMware Ent Plus

VMware Ent Plus

Kalkulu guztietan, ez ditut kontuan hartu sarearen azpiegitura, datu zentroen kostuak, etab.: berdinak izango dira arkitektura klasikorako eta HyperFlex soluziorako.

Kostuari dagokionez, HyperFlex % 5 garestiagoa izan da. Aipatzekoa da hemen CPU/RAM baliabideei dagokienez, Ciscorentzat oker bat izan nuela, konfigurazioan memoria kontroladorearen kanalak berdin bete nituelako. Kostua apur bat handiagoa da, baina ez magnitude baten arabera, eta horrek argi adierazten du hiperkonbergentzia ez dela zertan "aberatsentzako jostailua" izan, baina datu-zentro bat eraikitzeko ikuspegi estandarrekin lehiatu daitekeela. Hori ere interesgarria izan daiteke dagoeneko Cisco UCS zerbitzariak eta haiei dagozkien azpiegiturak dituztenentzat.

Abantailen artean, SAN eta biltegiratze sistemak administratzeko kosturik eza, lineako konpresioa eta desduplicazioa, laguntzarako sarrera puntu bakarra (birtualizazioa, zerbitzariak, biltegiratze sistemak ere badira), espazioa aurreztea (baina ez eszenatoki guztietan), lortzen dugu. funtzionamendua erraztuz.

Laguntzari dagokionez, hemen saltzaile batengandik eskuratzen duzu - Cisco. Cisco UCS zerbitzariekin dudan esperientzia ikusita, gustatzen zait; Ez nuen HyperFlex-en ireki behar izan, dena berdin funtzionatu zuen. Ingeniariek berehala erantzuten dute eta arazo tipikoak ez ezik, ertz-kasu konplexuak ere ebatzi ditzakete. Batzuetan, haiengana jotzen dut galderekin: "Posible al da hau egin, izorratu?" edo “Hemen zerbait konfiguratu dut, eta ez du funtzionatu nahi. Lagundu!" - pazientziaz aurkituko dute beharrezko gida bertan eta ekintza zuzenak adieraziko dituzte; ez dute erantzungo: "Hardware arazoak bakarrik konpontzen ditugu".

Erreferentziak

Iturria: www.habr.com

Gehitu iruzkin berria