Håndfri admin = hyperkonvergens?

Dette er en myte, der er ret almindelig inden for serverhardware. I praksis er der brug for hyperkonvergerede løsninger (når alt er i ét) til mange ting. Historisk set blev de første arkitekturer udviklet af Amazon og Google til deres tjenester. Så var tanken at lave en computerfarm af identiske noder, som hver havde sine egne diske. Alt dette blev forenet af noget systemdannende software (hypervisor) og blev opdelt i virtuelle maskiner. Hovedmålet er et minimum af indsats for at servicere en node og et minimum af problemer ved skalering: bare køb yderligere tusind eller to af de samme servere og tilslut dem i nærheden. I praksis er der tale om isolerede tilfælde, og meget oftere taler vi om et mindre antal noder og en lidt anderledes arkitektur.

Men plusset forbliver det samme - utrolig nem skalering og administration. Ulempen er, at forskellige opgaver forbruger ressourcer forskelligt, og nogle steder vil der være mange lokale diske, andre vil der være lidt RAM, og så videre, det vil sige, at for forskellige typer opgaver vil ressourceudnyttelsen falde.

Det viser sig, at du betaler 10-15 % mere for at lette opsætningen. Det var det, der udløste myten i titlen. Vi brugte lang tid på at lede efter, hvor teknologien ville blive anvendt optimalt, og vi fandt det. Faktum er, at Cisco ikke havde sine egne lagringssystemer, men de ønskede et komplet servermarked. Og de lavede Cisco Hyperflex – en løsning med lokal lagring på noder.

Og det viste sig pludselig at være en rigtig god løsning til backup af datacentre (Disaster Recovery). Jeg vil fortælle dig hvorfor og hvordan nu. Og jeg vil vise dig klyngetestene.

Hvor det er nødvendigt

Hyperkonvergens er:

1. Overførsel af diske til computerknudepunkter.
2. Fuld integration af lagerundersystemet med virtualiseringsundersystemet.
3. Overførsel/integration med netværksundersystemet.

Denne kombination giver dig mulighed for at implementere mange lagersystemfunktioner på virtualiseringsniveau og alle fra ét kontrolvindue.

I vores virksomhed er projekter til at designe redundante datacentre i stor efterspørgsel, og en hyperkonvergeret løsning vælges ofte på grund af en masse replikeringsmuligheder (op til en metrocluster) ud af boksen.

I tilfælde af backup-datacentre taler vi normalt om en fjernfacilitet på et sted på den anden side af byen eller i en anden by helt. Det giver dig mulighed for at gendanne kritiske systemer i tilfælde af en delvis eller fuldstændig fejl i hoveddatacentret. Salgsdata replikeres konstant der, og denne replikering kan være på applikationsniveau eller på blokenhedsniveau (lager).

Derfor vil jeg nu tale om systemdesignet og -testene og derefter om et par virkelige applikationsscenarier med besparelsesdata.

Tests

Vores instans består af fire servere, som hver har 10 SSD-drev på 960 GB. Der er en dedikeret disk til cachelagring af skriveoperationer og lagring af tjenestens virtuelle maskine. Selve løsningen er den fjerde version. Den første er helt ærligt rå (at dømme efter anmeldelserne), den anden er fugtig, den tredje er allerede ret stabil, og denne kan kaldes en udgivelse efter afslutningen af ​​beta-testning for den brede offentlighed. Under testen så jeg ingen problemer, alt fungerer som et ur.

Ændringer i v4En masse fejl er blevet rettet.

I starten kunne platformen kun fungere med VMware ESXi hypervisor og understøttede et lille antal noder. Desuden sluttede implementeringsprocessen ikke altid med succes, nogle trin skulle genstartes, der var problemer med opdatering fra ældre versioner, data i GUI blev ikke altid vist korrekt (selvom jeg stadig ikke er tilfreds med visningen af ​​præstationsgrafer ), nogle gange opstod der problemer ved grænsefladen med virtualisering.

Nu er alle barndomsproblemer løst, HyperFlex kan håndtere både ESXi og Hyper-V, plus det er muligt at:

1. Oprettelse af en strakt klynge.
2. Oprettelse af en klynge til kontorer uden brug af Fabric Interconnect, fra to til fire noder (vi køber kun servere).
3. Evne til at arbejde med eksterne lagersystemer.
4. Support til containere og Kubernetes.
5. Oprettelse af tilgængelighedszoner.
6. Integration med VMware SRM, hvis den indbyggede funktionalitet ikke er tilfredsstillende.

Arkitekturen er ikke meget forskellig fra løsningerne fra dens vigtigste konkurrenter; de skabte ikke en cykel. Det hele kører på VMware eller Hyper-V virtualiseringsplatformen. Hardwaren hostes på proprietære Cisco UCS-servere. Der er dem, der hader platformen for den relative kompleksitet af den indledende opsætning, en masse knapper, et ikke-trivielt system af skabeloner og afhængigheder, men der er også dem, der har lært Zen, er inspireret af ideen og ikke længere ønsker at arbejde med andre servere.

Vi vil overveje løsningen til VMware, da løsningen oprindeligt blev skabt til den og har mere funktionalitet; Hyper-V blev tilføjet undervejs for at følge med konkurrenterne og leve op til markedets forventninger.

Der er en klynge af servere fuld af diske. Der er diske til datalagring (SSD eller HDD - efter din smag og behov), der er én SSD disk til caching. Når du skriver data til datalageret, gemmes dataene på cachinglaget (dedikeret SSD-disk og RAM fra tjenesten VM). Parallelt sendes en blok af data til noder i klyngen (antallet af noder afhænger af klyngereplikationsfaktoren). Efter bekræftelse fra alle noder om vellykket optagelse, sendes bekræftelse af optagelsen til hypervisoren og derefter til VM'en. De optagede data deduplikeres, komprimeres og skrives til lagerdiske i baggrunden. Samtidig skrives der altid en stor blok til lagerdiskene og sekventielt, hvilket reducerer belastningen på lagerdiskene.

Deduplikering og komprimering er altid aktiveret og kan ikke deaktiveres. Data læses direkte fra lagerdiske eller fra RAM-cachen. Hvis en hybrid konfiguration bruges, cachelagres læsningerne også på SSD'en.

Dataene er ikke bundet til den aktuelle placering af den virtuelle maskine og fordeles jævnt mellem noderne. Denne tilgang giver dig mulighed for at indlæse alle diske og netværksgrænseflader ligeligt. Der er en åbenlys ulempe: Vi kan ikke reducere læseforsinkelsen så meget som muligt, da der ikke er nogen garanti for datatilgængelighed lokalt. Men jeg mener, at det er et mindre offer i forhold til de modtagne fordele. Desuden har netværksforsinkelser nået sådanne værdier, at de praktisk talt ikke påvirker det samlede resultat.

En speciel service VM Cisco HyperFlex Data Platform-controller, som er oprettet på hver lagerknude, er ansvarlig for hele operationslogikken for diskundersystemet. I vores service VM-konfiguration blev der tildelt otte vCPU'er og 72 GB RAM, hvilket ikke er så lidt. Lad mig minde dig om, at værten selv har 28 fysiske kerner og 512 GB RAM.

Tjenesten VM har adgang til fysiske diske direkte ved at videresende SAS controlleren til VM'en. Kommunikation med hypervisoren sker gennem et særligt IOVisor-modul, som opsnapper I/O-operationer, og ved hjælp af en agent, der giver dig mulighed for at sende kommandoer til hypervisor-API'en. Agenten er ansvarlig for at arbejde med HyperFlex snapshots og kloner.

Diskressourcer er monteret i hypervisoren som NFS- eller SMB-shares (afhængigt af typen af ​​hypervisor, gæt hvilken der er hvor). Og under motorhjelmen er dette et distribueret filsystem, der giver dig mulighed for at tilføje funktioner fra fuldgyldige lagersystemer for voksne: tynd volumenallokering, komprimering og deduplikering, snapshots ved hjælp af Redirect-on-Write-teknologi, synkron/asynkron replikering.

Tjenesten VM giver adgang til WEB-administrationsgrænsefladen i HyperFlex-undersystemet. Der er integration med vCenter, og de fleste hverdagsopgaver kan udføres fra det, men datastores er for eksempel mere praktiske at klippe fra et separat webcam, hvis du allerede har skiftet til en hurtig HTML5-grænseflade, eller bruger en fuldgyldig Flash-klient med fuld integration. I tjenestewebkameraet kan du se systemets ydeevne og detaljerede status.

Der er en anden type node i en klynge - computing noder. Disse kan være rack- eller bladeservere uden indbyggede diske. Disse servere kan køre VM'er, hvis data er gemt på servere med diske. Fra et synspunkt om dataadgang er der ingen forskel mellem typerne af noder, fordi arkitekturen involverer abstraktion fra den fysiske placering af dataene. Det maksimale forhold mellem computernoder og lagernoder er 2:1.

Brug af compute noder øger fleksibiliteten ved skalering af klyngresourcer: vi behøver ikke købe yderligere noder med diske, hvis vi kun har brug for CPU/RAM. Derudover kan vi tilføje et blade cage og spare på rackplacering af servere.

Som et resultat har vi en hyperkonvergeret platform med følgende funktioner:

• Op til 64 noder i en klynge (op til 32 lagernoder).
• Minimumsantallet af noder i en klynge er tre (to for en Edge-klynge).
• Dataredundansmekanisme: spejling med replikeringsfaktor 2 og 3.
• Metro klynge.
• Asynkron VM-replikering til en anden HyperFlex-klynge.
• Orkestrering af skift af VM'er til et fjerndatacenter.
• Native snapshots ved hjælp af Redirect-on-Write-teknologi.
• Op til 1 PB brugbar plads ved replikationsfaktor 3 og uden deduplikering. Vi tager ikke højde for replikeringsfaktor 2, fordi dette ikke er en mulighed for seriøse salg.

Et andet stort plus er nem administration og implementering. Al kompleksiteten ved opsætning af UCS-servere varetages af en specialiseret VM udarbejdet af Cisco-ingeniører.

Test bænk konfiguration:

• 2 x Cisco UCS Fabric Interconnect 6248UP som en administrationsklynge og netværkskomponenter (48 porte, der fungerer i Ethernet 10G/FC 16G-tilstand).
• Fire Cisco UCS HXAF240 M4-servere.

Serveregenskaber:

CPU

2 x Intel® Xeon® E5-2690 v4

RAM

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

Netværk

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

Opbevaring HBA

Cisco 12G Modular SAS Pass through Controller

Lagerdiske

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

Flere konfigurationsmulighederUd over den valgte hardware er følgende muligheder i øjeblikket tilgængelige:

• HXAF240c M5.
• En eller to CPU'er lige fra Intel Silver 4110 til Intel Platinum I8260Y. Anden generation tilgængelig.
• 24 hukommelsespladser, strimler fra 16 GB RDIMM 2600 til 128 GB LRDIMM 2933.
• Fra 6 til 23 datadiske, en caching disk, en system disk og en boot disk.

Kapacitetsdrev

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

System/log-drev

• HX-SD240GM1X-EV 240GB 2.5 tommer Enterprise Value 6G SATA SSD (Kræver opgradering).

Boot-drev

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

Tilslut til netværket via 40G, 25G eller 10G Ethernet-porte.

FI kan være HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).

Selve testen

For at teste diskundersystemet brugte jeg HCIBench 2.2.1. Dette er et gratis værktøj, der giver dig mulighed for at automatisere oprettelsen af ​​en belastning fra flere virtuelle maskiner. Selve belastningen genereres af den sædvanlige fio.

Vores klynge består af fire noder, replikeringsfaktor 3, alle diske er Flash.

Til test oprettede jeg fire databutikker og otte virtuelle maskiner. For skrivetests antages det, at caching-disken ikke er fuld.

Testresultaterne er som følger:

100 % læst 100 % tilfældigt

0 % læst 100 % tilfældigt

Blok/kø dybde

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

Fed angiver værdier, hvorefter der ikke er nogen stigning i produktiviteten, nogle gange er endda nedbrydning synlig. Dette skyldes, at vi er begrænset af ydeevnen af ​​netværket/controllere/diske.

• Sekventiel læsning 4432 MB/s.
• Sekventiel skrivning 804 MB/s.
• Hvis en controller fejler (fejl på en virtuel maskine eller vært), er ydeevnefaldet dobbelt.
• Hvis lagerdisken fejler, er nedtrækningen 1/3. Diskgenopbygning tager 5 % af ressourcerne for hver controller.

På en lille blok er vi begrænset af ydelsen af ​​controlleren (virtuel maskine), dens CPU er indlæst med 100%, og når blokken øges, er vi begrænset af portens båndbredde. 10 Gbps er ikke nok til at frigøre potentialet i AllFlash-systemet. Desværre tillader parametrene for den medfølgende demostand os ikke at teste driften ved 40 Gbit/s.

Efter mit indtryk fra test og undersøgelse af arkitekturen, på grund af den algoritme, der placerer data mellem alle værter, får vi skalerbar, forudsigelig ydeevne, men dette er også en begrænsning ved læsning, fordi det ville være muligt at presse mere ud fra lokale diske, her kan det spare et mere produktivt netværk, for eksempel er FI på 40 Gbit/s tilgængelig.

En disk til caching og deduplikering kan også være en begrænsning; faktisk i denne testbed kan vi skrive til fire SSD-diske. Det ville være fantastisk at kunne øge antallet af caching-drev og se forskellen.

Virkelig brug

For at organisere et backup-datacenter kan du bruge to metoder (vi overvejer ikke at placere en backup på et eksternt websted):

1. Aktiv-Passiv. Alle applikationer hostes i hoveddatacentret. Replikering er synkron eller asynkron. Hvis hoveddatacentret svigter, skal vi aktivere backup-en. Dette kan gøres manuelt/scripts/orkestreringsapplikationer. Her vil vi få en RPO, der står mål med replikeringsfrekvensen, og RTO'en afhænger af administratorens reaktion og færdigheder og kvaliteten af ​​udvikling/fejlretning af omstillingsplanen.
2. Aktiv-aktiv. I dette tilfælde er der kun synkron replikering; tilgængeligheden af ​​datacentre bestemmes af et quorum/arbiter placeret udelukkende på det tredje sted. RPO = 0, og RTO kan nå 0 (hvis applikationen tillader det) eller lig med failover-tiden for en node i en virtualiseringsklynge. På virtualiseringsniveauet oprettes en strakt (Metro) klynge, der kræver Active-Active storage.

Normalt ser vi, at kunder allerede har implementeret en arkitektur med et klassisk lagersystem i hoveddatacentret, så vi designer endnu et til replikering. Som jeg nævnte, tilbyder Cisco HyperFlex asynkron replikering og strakt virtualiseringsklyngeoprettelse. Samtidig har vi ikke brug for et dedikeret lagersystem på mellemniveau og højere med dyre replikeringsfunktioner og Active-Active dataadgang på to lagersystemer.

Scenarie 1: Vi har et primært og backup datacenter, en virtualiseringsplatform på VMware vSphere. Alle produktive systemer er placeret i hoveddatacentret, og replikering af virtuelle maskiner udføres på hypervisorniveau, dette vil undgå at holde VM'er tændt i backupdatacentret. Vi replikerer databaser og specielle applikationer ved hjælp af indbyggede værktøjer og holder VM'erne tændt. Hvis hoveddatacentret svigter, starter vi systemer i backupdatacentret. Vi mener, at vi har omkring 100 virtuelle maskiner. Mens det primære datacenter er i drift, kan standby-datacentret køre testmiljøer og andre systemer, der kan lukkes ned, hvis det primære datacenter skifter. Det er også muligt, at vi bruger to-vejs replikering. Fra et hardwaresynspunkt vil intet ændre sig.

I tilfælde af klassisk arkitektur vil vi i hvert datacenter installere et hybridt lagringssystem med adgang via FibreChannel, tiering, deduplikering og komprimering (men ikke online), 8 servere til hver side, 2 FibreChannel-switche og 10G Ethernet. Til replikering og switching management i en klassisk arkitektur kan vi bruge VMware værktøjer (replikering + SRM) eller tredjeparts værktøjer, som vil være lidt billigere og nogle gange mere praktiske.

Figuren viser diagrammet.

Når du bruger Cisco HyperFlex, opnås følgende arkitektur:

Til HyperFlex brugte jeg servere med store CPU/RAM-ressourcer, fordi... Nogle af ressourcerne vil gå til HyperFlex-controlleren VM; med hensyn til CPU og hukommelse har jeg endda omkonfigureret HyperFlex-konfigurationen lidt for ikke at spille sammen med Cisco og garantere ressourcer for de resterende VM'er. Men vi kan opgive FibreChannel-switche, og vi har ikke brug for Ethernet-porte til hver server; lokal trafik skiftes inden for FI.

Resultatet var følgende konfiguration for hvert datacenter:

Servere

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

Hybrid lagringssystem med FC Front-End (20 TB SSD, 130 TB NL-SAS)

—

LAN

2 x Ethernet switch 10G 12 porte

—

SAN

2 x FC switch 32/16Gb 24 porte

2 x Cisco UCS FI 6332

Licenser

VMware Ent Plus

Replikering og/eller orkestrering af VM-switch

VMware Ent Plus

Jeg leverede ikke replikeringssoftwarelicenser til Hyperflex, da dette er tilgængeligt direkte for os.

Til klassisk arkitektur valgte jeg en leverandør, der har etableret sig som en højkvalitets og billig producent. For begge muligheder anvendte jeg standardrabatten for en specifik løsning, og som et resultat fik jeg rigtige priser.

Cisco HyperFlex-løsningen viste sig at være 13 % billigere.

Scenarie 2: oprettelse af to aktive datacentre. I dette scenarie designer vi en strakt klynge på VMware.

Den klassiske arkitektur består af virtualiseringsservere, et SAN (FC-protokol) og to lagersystemer, der kan læse og skrive til volumen, der er strakt mellem dem. På hvert lagersystem sætter vi en nyttig kapacitet til opbevaring.

Hos HyperFlex opretter vi simpelthen en Stretch Cluster med det samme antal noder på begge steder. I dette tilfælde anvendes en replikationsfaktor på 2+2.

Resultatet er følgende konfiguration:

klassisk arkitektur

HyperFlex

Servere

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

—

LAN

4 x Ethernet switch 10G 24 porte

—

SAN

4 x FC switch 32/16Gb 24 porte

4 x Cisco UCS FI 6332

Licenser

VMware Ent Plus

VMware Ent Plus

I alle beregninger har jeg ikke taget højde for netværksinfrastrukturen, datacenteromkostninger osv.: De vil være de samme for den klassiske arkitektur og for HyperFlex-løsningen.

Med hensyn til omkostninger viste HyperFlex sig at være 5% dyrere. Det er værd at bemærke her, at med hensyn til CPU/RAM-ressourcer havde jeg en skævhed for Cisco, fordi jeg i konfigurationen fyldte hukommelsescontrollerkanalerne jævnt. Omkostningerne er lidt højere, men ikke i en størrelsesorden, hvilket klart indikerer, at hyperkonvergens ikke nødvendigvis er et "legetøj for de rige", men kan konkurrere med standardtilgangen til at bygge et datacenter. Dette kan også være interessant for dem, der allerede har Cisco UCS-servere og den tilsvarende infrastruktur til dem.

Blandt fordelene får vi fraværet af omkostninger til administration af SAN og lagersystemer, online komprimering og deduplikering, et enkelt indgangspunkt for support (virtualisering, servere, de er også lagersystemer), sparer plads (men ikke i alle scenarier), forenkling af driften.

Med hensyn til support, her får du det fra én leverandør - Cisco. At dømme efter min erfaring med Cisco UCS-servere, kan jeg lide det; Jeg behøvede ikke at åbne det på HyperFlex, alt fungerede på samme måde. Ingeniører reagerer hurtigt og kan løse ikke kun typiske problemer, men også komplekse kantsager. Nogle gange henvender jeg mig til dem med spørgsmål: "Er det muligt at gøre dette, skrue det på?" eller "Jeg har konfigureret noget her, og det vil ikke fungere. Hjælp!" - de vil tålmodigt finde den nødvendige vejledning der og påpege de korrekte handlinger; de vil ikke svare: "Vi løser kun hardwareproblemer."

RЎSЃS <P "RєRё

• Specifikationer
• Virtuelt datacenter
• Datacenter i en skrivebordsskuffe
• Min mail - [e-mail beskyttet]

Kilde: www.habr.com