Admin bez rokām = hiperkonverģence?

Admin bez rokām = hiperkonverģence?
Admin bez rokām = hiperkonverģence?

Tas ir diezgan izplatÄ«ts mÄ«ts serveru aparatÅ«ras jomā. Praksē hiperkonverģēti risinājumi (kad viss ir vienā) ir nepiecieÅ”ami daudzām lietām. Vēsturiski pirmās arhitektÅ«ras saviem pakalpojumiem izstrādāja Amazon un Google. Tad radās doma izveidot skaitļoÅ”anas fermu no identiskiem mezgliem, kuriem katram bija savi diski. To visu apvienoja kāda sistēmu veidojoÅ”a programmatÅ«ra (hipervizors) un sadalÄ«ja virtuālajās maŔīnās. Galvenais mērÄ·is ir minimālas pÅ«les viena mezgla apkalpoÅ”anai un minimālas problēmas mērogoÅ”anas laikā: vienkārÅ”i iegādājieties vēl tÅ«kstoti vai divus tādus paÅ”us serverus un pievienojiet tos tuvumā. Praksē tie ir atseviŔķi gadÄ«jumi, un daudz biežāk mēs runājam par mazāku mezglu skaitu un nedaudz atŔķirÄ«gu arhitektÅ«ru.

Taču pluss paliek nemainÄ«gs ā€“ neticami viegla mērogoÅ”ana un pārvaldÄ«ba. MÄ«nuss ir tāds, ka dažādi uzdevumi dažādi patērē resursus, un vietām bÅ«s daudz lokālo disku, citās maz RAM un tā tālāk, proti, dažāda veida uzdevumiem resursu izmantoÅ”ana samazināsies.

Izrādās, ka par iestatÄ«Å”anas vienkārŔību jÅ«s maksājat par 10ā€“15% vairāk. Tas ir tas, kas izraisÄ«ja nosaukumā ietverto mÄ«tu. Mēs ilgi meklējām, kur tehnoloÄ£ija bÅ«tu optimāli pielietojama, un mēs to atradām. Fakts ir tāds, ka Cisco nebija savas uzglabāŔanas sistēmas, bet viņi gribēja pilnÄ«gu serveru tirgu. Un viņi izveidoja Cisco Hyperflex ā€” risinājumu ar lokālo krātuvi mezglos.

Un tas pēkŔņi izrādÄ«jās ļoti labs risinājums rezerves datu centriem (Disaster Recovery). Es jums pastāstÄ«Å”u, kāpēc un kā tagad. Un es jums parādÄ«Å”u kopu testus.

Kur vajag

Hiperkonverģence ir:

  1. Disku pārsūtīŔana uz skaitļoŔanas mezgliem.
  2. Krātuves apakÅ”sistēmas pilnÄ«ga integrācija ar virtualizācijas apakÅ”sistēmu.
  3. PārsÅ«tÄ«Å”ana/integrācija ar tÄ«kla apakÅ”sistēmu.

Å Ä« kombinācija ļauj ieviest daudzas uzglabāŔanas sistēmas funkcijas virtualizācijas lÄ«menÄ« un visas no viena vadÄ«bas loga.

MÅ«su uzņēmumā ir liels pieprasÄ«jums pēc lieku datu centru projektÄ“Å”anas projektiem, un bieži tiek izvēlēts hiperkonverģēts risinājums, jo ir pieejamas daudzas replikācijas iespējas (lÄ«dz pat metroklasterim).

Rezerves datu centru gadÄ«jumā mēs parasti runājam par attālu objektu, kas atrodas citā pilsētas pusē vai pavisam citā pilsētā. Tas ļauj atjaunot kritiskās sistēmas galvenā datu centra daļējas vai pilnÄ«gas atteices gadÄ«jumā. Tur pastāvÄ«gi tiek replicēti pārdoÅ”anas dati, un Ŕī replikācija var bÅ«t lietojumprogrammas lÄ«menÄ« vai blokierÄ«ces (krātuves) lÄ«menÄ«.

Tāpēc tagad es runāŔu par sistēmas dizainu un testiem, un pēc tam par pāris reāliem lietojumprogrammu scenārijiem ar ietaupÄ«juma datiem.

Testi

MÅ«su instance sastāv no četriem serveriem, no kuriem katram ir 10 SSD diskdziņi ar 960 GB. Ir paredzēts disks rakstÄ«Å”anas darbÄ«bu saglabāŔanai keÅ”atmiņā un pakalpojuma virtuālās maŔīnas glabāŔanai. Pats risinājums ir ceturtā versija. Pirmais ir atklāti sakot neapstrādāts (spriežot pēc atsauksmēm), otrais ir mitrs, treÅ”ais jau ir diezgan stabils, un Å”o var saukt par izlaidumu pēc beta testÄ“Å”anas beigām plaÅ”ai sabiedrÄ«bai. Pārbaudes laikā neredzēju nekādas problēmas, viss darbojas kā pulkstenis.

Izmaiņas v4Ir novērsta virkne kļūdu.

Sākotnēji platforma varēja darboties tikai ar VMware ESXi hipervizoru un atbalstÄ«ja nelielu skaitu mezglu. ArÄ« izvietoÅ”anas process ne vienmēr beidzās veiksmÄ«gi, dažas darbÄ«bas bija jārestartē, radās problēmas ar atjaunināŔanu no vecākām versijām, dati GUI ne vienmēr tika parādÄ«ti pareizi (lai gan joprojām neesmu apmierināts ar veiktspējas grafiku parādÄ«Å”anu ), dažreiz problēmas radās saskarnē ar virtualizāciju.

Tagad visas bērnības problēmas ir novērstas, HyperFlex var apstrādāt gan ESXi, gan Hyper-V, kā arī ir iespējams:

  1. Izstiepta klastera izveide.
  2. Klastera izveide birojiem, neizmantojot Fabric Interconnect, no diviem līdz četriem mezgliem (pērkam tikai serverus).
  3. Spēja strādāt ar ārējām uzglabāŔanas sistēmām.
  4. Atbalsts konteineriem un Kubernetes.
  5. Pieejamības zonu izveide.
  6. Integrācija ar VMware SRM, ja iebÅ«vētā funkcionalitāte nav apmierinoÅ”a.

ArhitektÅ«ra daudz neatŔķiras no galveno konkurentu risinājumiem, viņi neradÄ«ja velosipēdu. Tas viss darbojas VMware vai Hyper-V virtualizācijas platformā. AparatÅ«ra tiek mitināta patentētajos Cisco UCS serveros. Ir tādi, kas ienÄ«st platformu sākotnējās iestatÄ«Å”anas relatÄ«vās sarežģītÄ«bas dēļ, daudz pogu, netriviālas veidņu un atkarÄ«bu sistēmas, taču ir arÄ« tādi, kuri ir apguvuÅ”i Zen, iedvesmojas no idejas un vairs nevēlas. strādāt ar citiem serveriem.

Mēs apsvērsim risinājumu VMware, jo risinājums sākotnēji tika izveidots tam un tam ir vairāk funkcionalitātes; Hyper-V tika pievienots pa ceļam, lai neatpaliktu no konkurentiem un atbilstu tirgus prasībām.

Ir pilns serveru kopums ar diskiem. Ir diski datu uzglabāŔanai (SSD vai HDD - pēc jÅ«su gaumes un vajadzÄ«bām), ir viens SSD disks keÅ”atmiņai. Ierakstot datus datu krātuvē, dati tiek saglabāti keÅ”atmiņas slānÄ« (pakalpojuma VM Ä«paÅ”ajā SSD diskā un RAM). Paralēli klastera mezgliem tiek nosÅ«tÄ«ts datu bloks (mezglu skaits ir atkarÄ«gs no klastera replikācijas koeficienta). Pēc apstiprinājuma no visiem mezgliem par veiksmÄ«gu ierakstÄ«Å”anu, ieraksta apstiprinājums tiek nosÅ«tÄ«ts uz hipervizoru un pēc tam uz virtuālo maŔīnu. IerakstÄ«tie dati tiek dedublēti, saspiesti un ierakstÄ«ti atmiņas diskos fonā. Tajā paŔā laikā liels bloks vienmēr tiek ierakstÄ«ts uzglabāŔanas diskos un secÄ«gi, kas samazina uzglabāŔanas disku slodzi.

Deduplikācija un saspieÅ”ana vienmēr ir iespējota, un tos nevar atspējot. Dati tiek nolasÄ«ti tieÅ”i no atmiņas diskiem vai no RAM keÅ”atmiņas. Ja tiek izmantota hibrÄ«da konfigurācija, nolasÄ«jumi tiek saglabāti arÄ« SSD keÅ”atmiņā.

Dati nav piesaistÄ«ti paÅ”reizējai virtuālās maŔīnas atraÅ”anās vietai un ir vienmērÄ«gi sadalÄ«ti starp mezgliem. Å Ä« pieeja ļauj vienādi ielādēt visus diskus un tÄ«kla saskarnes. Ir acÄ«mredzams trÅ«kums: mēs nevaram pēc iespējas samazināt lasÄ«Å”anas latentumu, jo nav garantijas par datu pieejamÄ«bu lokāli. Bet es uzskatu, ka tas ir niecÄ«gs upuris, salÄ«dzinot ar saņemtajiem labumiem. Turklāt tÄ«kla aizkaves ir sasnieguÅ”as tādas vērtÄ«bas, ka tās praktiski neietekmē kopējo rezultātu.

Par visu diska apakÅ”sistēmas darbÄ«bas loÄ£iku atbild Ä«paÅ”s servisa VM Cisco HyperFlex Data Platform kontrolleris, kas tiek izveidots katrā krātuves mezglā. MÅ«su servisa VM konfigurācijā tika atvēlēti astoņi vCPU un 72 GB RAM, kas nav nemaz tik maz. AtgādināŔu, ka paÅ”am saimniekdatoram ir 28 fiziskie kodoli un 512 GB RAM.

Pakalpojuma VM var tieÅ”i piekļūt fiziskajiem diskiem, pārsÅ«tot SAS kontrolleri uz virtuālo maŔīnu. Saziņa ar hipervizoru notiek, izmantojot Ä«paÅ”u moduli IOVisor, kas pārtver I/O darbÄ«bas, un izmantojot aÄ£entu, kas ļauj nosÅ«tÄ«t komandas uz hipervizora API. AÄ£ents ir atbildÄ«gs par darbu ar HyperFlex momentuzņēmumiem un kloniem.

Diska resursi tiek montēti hipervizorā kā NFS vai SMB koplietojumi (atkarÄ«bā no hipervizora veida, uzminiet, kurÅ” no tiem atrodas). Un zem pārsega Ŕī ir izplatÄ«ta failu sistēma, kas ļauj pievienot pieauguÅ”o pilnvērtÄ«gu uzglabāŔanas sistēmu funkcijas: plāna apjoma pieŔķirÅ”anu, saspieÅ”anu un dublÄ“Å”anu, momentuzņēmumus, izmantojot Redirect-on-Write tehnoloÄ£iju, sinhrono/asinhrono replikāciju.

Pakalpojums VM nodroÅ”ina piekļuvi HyperFlex apakÅ”sistēmas WEB pārvaldÄ«bas saskarnei. Ir integrācija ar vCenter, un no tā var veikt lielāko daļu ikdienas uzdevumu, taču, piemēram, datu krātuves ir ērtāk izgriezt no atseviŔķas tÄ«mekļa kameras, ja jau esat pārgājuÅ”i uz ātro HTML5 saskarni vai izmantojat pilnvērtÄ«gu Flash klientu. ar pilnÄ«gu integrāciju. Pakalpojuma tÄ«mekļa kamerā varat apskatÄ«t sistēmas veiktspēju un detalizētu statusu.

Admin bez rokām = hiperkonverģence?

KlasterÄ« ir cita veida mezgli - skaitļoÅ”anas mezgli. Tie var bÅ«t plaukta vai asmens serveri bez iebÅ«vētiem diskiem. Å ajos serveros var darbināt virtuālās maŔīnas, kuru dati tiek glabāti serveros ar diskiem. No datu piekļuves viedokļa nav atŔķirÄ«bas starp mezglu veidiem, jo ā€‹ā€‹arhitektÅ«ra ietver abstrakciju no datu fiziskās atraÅ”anās vietas. Maksimālā skaitļoÅ”anas mezglu attiecÄ«ba pret krātuves mezgliem ir 2:1.

Aprēķinu mezglu izmantoÅ”ana palielina elastÄ«bu, mērogojot klastera resursus: mums nav jāpērk papildu mezgli ar diskiem, ja mums ir nepiecieÅ”ams tikai CPU/RAM. Turklāt mēs varam pievienot lāpstiņu bÅ«ri un ietaupÄ«t uz serveru statÄ«va izvietojumu.

Rezultātā mums ir hiperkonverģēta platforma ar Ŕādām funkcijām:

  • LÄ«dz 64 mezgliem klasterÄ« (lÄ«dz 32 krātuves mezgliem).
  • Minimālais mezglu skaits klasterÄ« ir trÄ«s (divi Edge klasterim).
  • Datu dublÄ“Å”anas mehānisms: spoguļoÅ”ana ar replikācijas koeficientu 2 un 3.
  • Metro klasteris.
  • Asinhronā VM replikācija citā HyperFlex klasterÄ«.
  • VM pārslēgÅ”anās uz attālo datu centru organizÄ“Å”ana.
  • Vietējie momentuzņēmumi, izmantojot tehnoloÄ£iju Redirect-on-Write.
  • LÄ«dz 1 PB izmantojamās vietas ar replikācijas koeficientu 3 un bez dublÄ“Å”anas. Mēs neņemam vērā replikācijas koeficientu 2, jo tas nav piemērots nopietniem pārdoÅ”anas darÄ«jumiem.

Vēl viens milzÄ«gs pluss ir vienkārÅ”a pārvaldÄ«ba un izvietoÅ”ana. Par visām UCS serveru iestatÄ«Å”anas sarežģītÄ«bām rÅ«pējas specializēta VM, ko sagatavojuÅ”i Cisco inženieri.

Testa stenda konfigurācija:

  • 2 x Cisco UCS Fabric Interconnect 6248UP kā pārvaldÄ«bas klasteris un tÄ«kla komponenti (48 porti, kas darbojas Ethernet 10G/FC 16G režīmā).
  • Četri Cisco UCS HXAF240 M4 serveri.

Servera īpaŔības:

CPU

2 x IntelĀ® XeonĀ® E5-2690 v4

RAM

16 x 32 GB DDR4-2400 MHz RDIMM/PC4-19200/duālā ranga/x4/1.2 v

tīkls

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

UzglabāŔana HBA

Cisco 12G Modular SAS caurlaide kontroliera

UzglabāŔanas diski

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

Vairāk konfigurācijas iespējuPapildus atlasÄ«tajai aparatÅ«rai paÅ”laik ir pieejamas Ŕādas opcijas:

  • HXAF240c M5.
  • Viens vai divi CPU, sākot no Intel Silver 4110 lÄ«dz Intel Platinum I8260Y. Pieejama otrā paaudze.
  • 24 atmiņas sloti, sloksnes no 16 GB RDIMM 2600 lÄ«dz 128 GB LRDIMM 2933.
  • No 6 lÄ«dz 23 datu diskiem, viens keÅ”atmiņas disks, viens sistēmas disks un viens sāknÄ“Å”anas disks.

Jaudas diskdziņi

  • HX-SD960G61X-EV 960GB 2.5 collu Enterprise Value 6G SATA SSD (1X izturÄ«ba) SAS 960 GB.
  • HX-SD38T61X-EV 3.8TB 2.5 collu Enterprise Value 6G SATA SSD (1X izturÄ«ba) SAS 3.8 TB.
  • Disku saglabāŔana keÅ”atmiņā
  • HX-NVMEXPB-I375 375 GB 2.5 collu Intel Optane Drive, Extreme Perf & Endurance.
  • HX-NVMEHW-H1600* 1.6 TB 2.5 collas Ent. Perf. NVMe SSD (3X izturÄ«ba) NVMe 1.6 TB.
  • HX-SD400G12TX-EP 400 GB 2.5 collu Ent. Perf. 12G SAS SSD (10X izturÄ«ba) SAS 400 GB.
  • HX-SD800GBENK9** 800 GB 2.5 collas Ent. Perf. 12G SAS SED SSD (10X izturÄ«ba) SAS 800 GB.
  • HX-SD16T123X-EP 1.6 TB 2.5 collu uzņēmuma veiktspējas 12G SAS SSD (3 izturÄ«ba).

Sistēmas/reģistrācijas diskdziņi

  • HX-SD240GM1X-EV 240GB 2.5 collu Enterprise Value 6G SATA SSD (nepiecieÅ”ams jauninājums).

SāknÄ“Å”anas diskdziņi

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

Pievienojieties tīklam, izmantojot 40G, 25G vai 10G Ethernet portus.

FI var būt HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).

Pats tests

Lai pārbaudÄ«tu diska apakÅ”sistēmu, es izmantoju HCIBench 2.2.1. Å Ä« ir bezmaksas utilÄ«ta, kas ļauj automatizēt slodzes izveidi no vairākām virtuālajām maŔīnām. PaÅ”u slodzi Ä£enerē parastais fio.

Mūsu klasteris sastāv no četriem mezgliem, replikācijas koeficients 3, visi diski ir Flash.

TestÄ“Å”anai es izveidoju četrus datu krātuves un astoņas virtuālās maŔīnas. RakstÄ«Å”anas testiem tiek pieņemts, ka keÅ”atmiņas disks nav pilns.

Pārbaudes rezultāti ir Ŕādi:

100% lasīt 100% nejauŔi

0% Lasīt 100% nejauŔi

Bloku/rindas dziļums

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

Treknrakstā norādītas vērtības, pēc kurām produktivitāte nepalielinās, dažreiz ir redzama pat degradācija. Tas ir saistīts ar faktu, ka mūs ierobežo tīkla / kontrolleru / disku veiktspēja.

  • SecÄ«gā lasÄ«Å”ana 4432 MB/s.
  • SecÄ«gā rakstÄ«Å”ana 804 MB/s.
  • Ja viens kontrolleris atteicas (virtuālās maŔīnas vai resursdatora kļūme), veiktspējas kritums ir divkārÅ”s.
  • Ja atmiņas disks neizdodas, izņemÅ”ana ir 1/3. Diska atjaunoÅ”ana aizņem 5% no katra kontrollera resursiem.

Nelielā blokā mÅ«s ierobežo kontrollera (virtuālās maŔīnas) veiktspēja, tā centrālais procesors ir noslogots par 100%, un, kad bloks palielinās, mÅ«s ierobežo porta joslas platums. Ar 10 Gb/s nepietiek, lai atraisÄ«tu AllFlash sistēmas potenciālu. Diemžēl piedāvātā demo stenda parametri neļauj pārbaudÄ«t darbÄ«bu pie 40 Gbit/s.

Manā iespaidā no testiem un pētot arhitektÅ«ru, pateicoties algoritmam, kas ievieto datus starp visiem resursdatoriem, mēs iegÅ«stam mērogojamu, prognozējamu veiktspēju, taču tas ir arÄ« ierobežojums lasot, jo bÅ«tu iespējams izspiest vairāk no lokālajiem diskiem, Å”eit tas var ietaupÄ«t produktÄ«vāku tÄ«klu, piemēram, ir pieejams FI ar ātrumu 40 Gbit/s.

Ierobežojums var bÅ«t arÄ« viens disks keÅ”atmiņas saglabāŔanai un dublÄ“Å”anas atcelÅ”anai; patiesÄ«bā Å”ajā testa laukā mēs varam rakstÄ«t uz četriem SSD diskiem. BÅ«tu lieliski, ja varētu palielināt keÅ”atmiņas disku skaitu un redzēt atŔķirÄ«bu.

Reāla izmantoŔana

Lai organizētu dublējuma datu centru, varat izmantot divas pieejas (mēs neapsveram dublējuma ievietoÅ”anu attālā vietnē):

  1. AktÄ«vs-pasÄ«vs. Visas lietojumprogrammas tiek mitinātas galvenajā datu centrā. Replikācija ir sinhrona vai asinhrona. Ja galvenais datu centrs neizdodas, mums ir jāaktivizē rezerves centrs. To var izdarÄ«t manuāli / skripti / orÄ·estrÄ“Å”anas lietojumprogrammas. Å eit mēs iegÅ«sim RPO, kas atbilst replikācijas biežumam, un RTO ir atkarÄ«gs no administratora reakcijas un prasmēm un pārslēgÅ”anas plāna izstrādes/atkļūdoÅ”anas kvalitātes.
  2. AktÄ«vs-AktÄ«vs. Å ajā gadÄ«jumā ir tikai sinhrona replikācija; datu centru pieejamÄ«bu nosaka kvorums/Ŕķīrējtiesnesis, kas atrodas tikai treÅ”ajā vietā. RPO = 0, un RTO var sasniegt 0 (ja lietojumprogramma atļauj) vai vienādu ar virtualizācijas klastera mezgla kļūmjpārlēces laiku. Virtualizācijas lÄ«menÄ« tiek izveidots izstiepts (Metro) klasteris, kam nepiecieÅ”ama aktÄ«vā-aktÄ«va krātuve.

Parasti mēs redzam, ka klienti galvenajā datu centrā jau ir ieviesuÅ”i arhitektÅ«ru ar klasisko krātuves sistēmu, tāpēc mēs izstrādājam citu, lai veiktu replikāciju. Kā jau minēju, Cisco HyperFlex piedāvā asinhronu replikāciju un izstieptu virtualizācijas klasteru izveidi. Tajā paŔā laikā mums nav nepiecieÅ”ama Ä«paÅ”a vidēja un augstāka lÄ«meņa uzglabāŔanas sistēma ar dārgām replikācijas funkcijām un aktÄ«vās-aktÄ«vas datu piekļuvi divās uzglabāŔanas sistēmās.

1. scenārijs: Mums ir primārie un rezerves datu centri, virtualizācijas platforma VMware vSphere. Visas produktÄ«vās sistēmas atrodas galvenajā datu centrā, un virtuālo maŔīnu replikācija tiek veikta hipervizora lÄ«menÄ«, tādējādi izvairoties no virtuālās maŔīnas palikÅ”anas ieslēgtas rezerves datu centrā. Mēs replicējam datu bāzes un Ä«paÅ”as lietojumprogrammas, izmantojot iebÅ«vētos rÄ«kus, un turam ieslēgtas virtuālās maŔīnas. Ja galvenais datu centrs neizdodas, mēs palaižam sistēmas rezerves datu centrā. Mēs uzskatām, ka mums ir aptuveni 100 virtuālo maŔīnu. Kamēr primārais datu centrs darbojas, gaidstāves datu centrs var darbināt testa vides un citas sistēmas, kuras var izslēgt, ja primārais datu centrs pārslēdzas. Ir arÄ« iespējams, ka mēs izmantojam divvirzienu replikāciju. No aparatÅ«ras viedokļa nekas nemainÄ«sies.

Klasiskās arhitektÅ«ras gadÄ«jumā mēs katrā datu centrā uzstādÄ«sim hibrÄ«da krātuves sistēmu ar piekļuvi, izmantojot FibreChannel, lÄ«meņu, dublÄ“Å”anas un saspieÅ”anas (bet ne tieÅ”saistē), 8 serverus katrai vietnei, 2 FibreChannel slēdžus un 10G Ethernet. Replikācijas un komutācijas pārvaldÄ«bai klasiskajā arhitektÅ«rā varam izmantot VMware rÄ«kus (Replication + SRM) vai treÅ”o puÅ”u rÄ«kus, kas bÅ«s nedaudz lētāki un reizēm ērtāki.

Attēlā parādīta diagramma.

Admin bez rokām = hiperkonverģence?

Izmantojot Cisco HyperFlex, tiek iegūta Ŕāda arhitektūra:

Admin bez rokām = hiperkonverģence?

HyperFlex izmantoju serverus ar lieliem CPU/RAM resursiem, jo... Daļa resursu nonāks HyperFlex kontrollera virtuālajā maŔīnā; CPU un atmiņas ziņā es pat nedaudz pārkonfigurēju HyperFlex konfigurāciju, lai nespēlētu kopā ar Cisco un garantētu resursus atlikuÅ”ajām virtuālajām maŔīnām. Bet mēs varam atteikties no FibreChannel slēdžiem, un mums nebÅ«s nepiecieÅ”ami Ethernet porti katram serverim; vietējā trafika tiek pārslēgta FI ietvaros.

Rezultāts bija Ŕāda konfigurācija katram datu centram:

Serveri

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

HibrÄ«da uzglabāŔanas sistēma ar FC Front-End (20 TB SSD, 130 TB NL-SAS)

Sākot no

LAN

2 x Ethernet slēdzis 10G 12 porti

Sākot no

SAN

2 x FC slēdzis 32/16Gb 24 porti

2 x Cisco UCS FI 6332

Licences

VMware Ent Plus

VM pārslēgÅ”anās replikācija un/vai orÄ·estrÄ“Å”ana

VMware Ent Plus

Es nenodroÅ”ināju Hyperflex replikācijas programmatÅ«ras licences, jo tā mums ir pieejama jau sākotnēji.

Klasiskajai arhitektÅ«rai es izvēlējos pārdevēju, kurÅ” ir sevi pierādÄ«jis kā kvalitatÄ«vu un lētu ražotāju. Abiem variantiem piemēroju standarta atlaidi konkrētam risinājumam, un rezultātā saņēmu reālas cenas.

Cisco HyperFlex risinājums izrādījās par 13% lētāks.

2. scenārijs: divu aktÄ«vu datu centru izveide. Å ajā scenārijā mēs VMware veidojam izstieptu kopu.

Klasiskā arhitektÅ«ra sastāv no virtualizācijas serveriem, SAN (FC protokols) un divām uzglabāŔanas sistēmām, kas var lasÄ«t un rakstÄ«t starp tiem izstieptā sējumā. Katrai uzglabāŔanas sistēmai mēs ievietojam noderÄ«gu uzglabāŔanas ietilpÄ«bu.

Admin bez rokām = hiperkonverģence?

Uzņēmums HyperFlex mēs vienkārÅ”i izveidojam stiepÅ”anās kopu ar vienādu mezglu skaitu abās vietnēs. Å ajā gadÄ«jumā tiek izmantots replikācijas koeficients 2+2.

Admin bez rokām = hiperkonverģence?

Rezultāts ir Ŕāda konfigurācija:

klasiskā arhitektūra

HyperFlex

Serveri

16 x 1 U serveris (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10 G 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 atmiņas sistēmas (150 TB SSD)

Sākot no

LAN

4 x Ethernet slēdzis 10G 24 porti

Sākot no

SAN

4 x FC slēdzis 32/16Gb 24 porti

4 x Cisco UCS FI 6332

Licences

VMware Ent Plus

VMware Ent Plus

Visos aprēķinos neņēmu vērā tīkla infrastruktūru, datu centra izmaksas utt.: klasiskajai arhitektūrai un HyperFlex risinājumam tās būs vienādas.

Izmaksu ziņā HyperFlex izrādÄ«jās par 5% dārgāks. Å eit ir vērts atzÄ«mēt, ka CPU/RAM resursu ziņā man bija Ŕķība Cisco, jo konfigurācijā es vienmērÄ«gi aizpildÄ«ju atmiņas kontroliera kanālus. Izmaksas ir nedaudz augstākas, taču ne par lielumu, kas skaidri norāda, ka hiperkonverÄ£ence ne vienmēr ir ā€œrotaļlieta bagātajiemā€, bet var konkurēt ar standarta pieeju datu centra izveidei. Tas var interesēt arÄ« tos, kuriem jau ir Cisco UCS serveri un tiem atbilstoŔā infrastruktÅ«ra.

Starp priekÅ”rocÄ«bām mēs iegÅ«stam izmaksu neesamÄ«bu par SAN un uzglabāŔanas sistēmu administrÄ“Å”anu, tieÅ”saistes saspieÅ”anu un dublÄ“Å”anu, vienotu atbalsta ieejas punktu (virtualizācija, serveri, tie ir arÄ« uzglabāŔanas sistēmas), vietas ietaupÄ«jumu (bet ne visos scenārijos), darbÄ«bas vienkārÅ”oÅ”ana.

Kas attiecas uz atbalstu, Å”eit jÅ«s to saņemat no viena pārdevēja - Cisco. Spriežot pēc manas pieredzes ar Cisco UCS serveriem, man tas patÄ«k; man tas nebija jāatver HyperFlex, viss darbojās tāpat. Inženieri reaģē ātri un var atrisināt ne tikai tipiskas problēmas, bet arÄ« sarežģītus malu gadÄ«jumus. Dažreiz es vērÅ”os pie viņiem ar jautājumiem: "Vai to var izdarÄ«t, pieskrÅ«vēt?" vai ā€œEs Å”eit kaut ko konfigurēju, un tas nevēlas darboties. PalÄ«dziet!" - tur pacietÄ«gi atradÄ«s vajadzÄ«go ceļvedi un norādÄ«s uz pareizām darbÄ«bām; neatbildēs: "Mēs risinām tikai aparatÅ«ras problēmas."

atsauces

Avots: www.habr.com

Pievieno komentāru