Dette er en myte som er ganske vanlig innen servermaskinvare. I praksis trengs hyperkonvergerte løsninger (når alt er i ett) til mange ting. Historisk sett ble de første arkitekturene utviklet av Amazon og Google for deres tjenester. Da var tanken å lage en datafarm fra identiske noder, som hver hadde sine egne disker. Alt dette ble forent av noe systemdannende programvare (hypervisor) og ble delt inn i virtuelle maskiner. Hovedmålet er et minimum av innsats for å betjene en node og et minimum av problemer ved skalering: bare kjøp ytterligere tusen eller to av de samme serverne og koble dem til i nærheten. I praksis er dette isolerte tilfeller, og mye oftere snakker vi om et mindre antall noder og en litt annen arkitektur.
Men plusset forblir det samme - utrolig enkel skalering og administrasjon. Ulempen er at ulike oppgaver bruker ressurser ulikt, og noen steder vil det være mange lokale disker, andre vil det være lite RAM og så videre, det vil si at for ulike typer oppgaver vil ressursutnyttelsen avta.
Det viser seg at du betaler 10–15 % mer for enkelt oppsett. Det var dette som utløste myten i tittelen. Vi brukte lang tid på å lete etter hvor teknologien ville bli optimalt brukt, og vi fant det. Faktum er at Cisco ikke hadde egne lagringssystemer, men de ønsket et komplett servermarked. Og de laget Cisco Hyperflex – en løsning med lokal lagring på noder.
Og dette viste seg plutselig å være en veldig god løsning for backup av datasentre (Disaster Recovery). Jeg skal fortelle deg hvorfor og hvordan nå. Og jeg skal vise deg klyngetestene.
Der det trengs
Hyperkonvergens er:
- Overføring av disker til beregningsnoder.
- Full integrasjon av lagringsundersystemet med virtualiseringsundersystemet.
- Overføring/integrasjon med nettverksdelsystemet.
Denne kombinasjonen lar deg implementere mange lagringssystemfunksjoner på virtualiseringsnivå og alt fra ett kontrollvindu.
I vårt selskap er prosjekter for å designe redundante datasentre etterspurt, og en hyperkonvergert løsning velges ofte på grunn av en haug med replikeringsalternativer (opp til en metrocluster) ut av esken.
Når det gjelder backup-datasentre, snakker vi vanligvis om et eksternt anlegg på et sted på den andre siden av byen eller i en annen by helt. Den lar deg gjenopprette kritiske systemer i tilfelle en delvis eller fullstendig svikt i hoveddatasenteret. Salgsdata blir stadig replikert der, og denne replikeringen kan være på applikasjonsnivå eller på blokkenhetsnivå (lagring).
Derfor vil jeg nå snakke om systemdesign og tester, og deretter om et par virkelige applikasjonsscenarier med sparedata.
Tester
Vår instans består av fire servere, som hver har 10 SSD-stasjoner på 960 GB. Det er en dedikert disk for caching av skriveoperasjoner og lagring av tjenestens virtuelle maskin. Selve løsningen er den fjerde versjonen. Den første er ærlig grovt (bedømt etter anmeldelser), den andre er fuktig, den tredje er allerede ganske stabil, og denne kan kalles en utgivelse etter slutten av betatesten for allmennheten. Under testing så jeg ingen problemer, alt fungerer som en klokke.
Endringer i v4En haug med feil har blitt fikset.
I utgangspunktet kunne plattformen bare fungere med VMware ESXi hypervisor og støttet et lite antall noder. Dessuten ble ikke distribusjonsprosessen alltid vellykket, noen trinn måtte startes på nytt, det var problemer med oppdatering fra eldre versjoner, data i GUI ble ikke alltid vist riktig (selv om jeg fortsatt ikke er fornøyd med visningen av ytelsesgrafer ), noen ganger oppsto det problemer i grensesnittet med virtualisering .
Nå er alle barndomsproblemer fikset, HyperFlex kan håndtere både ESXi og Hyper-V, pluss at det er mulig å:
- Opprette en strukket klynge.
- Opprette en klynge for kontorer uten å bruke Fabric Interconnect, fra to til fire noder (vi kjøper kun servere).
- Evne til å jobbe med eksterne lagringssystemer.
- Støtte for containere og Kubernetes.
- Oppretting av tilgjengelighetssoner.
- Integrasjon med VMware SRM dersom den innebygde funksjonaliteten ikke er tilfredsstillende.
Arkitekturen er ikke mye forskjellig fra løsningene til hovedkonkurrentene; de skapte ikke en sykkel. Det hele kjører på VMware- eller Hyper-V-virtualiseringsplattformen. Maskinvaren er vert på proprietære Cisco UCS-servere. Det er de som hater plattformen for den relative kompleksiteten til det første oppsettet, mange knapper, et ikke-trivielt system av maler og avhengigheter, men det er også de som har lært Zen, er inspirert av ideen og ikke lenger ønsker å jobbe med andre servere.
Vi vil vurdere løsningen for VMware, siden løsningen opprinnelig ble laget for den og har mer funksjonalitet; Hyper-V ble lagt til underveis for å holde tritt med konkurrentene og møte markedets forventninger.
Det er en klynge med servere full av disker. Det finnes disker for datalagring (SSD eller HDD - etter smak og behov), det er én SSD-disk for caching. Når du skriver data til datalageret, lagres dataene på caching-laget (dedikert SSD-disk og RAM til tjenesten VM). Parallelt sendes en blokk med data til noder i klyngen (antall noder avhenger av klyngreplikasjonsfaktoren). Etter bekreftelse fra alle noder om vellykket opptak, sendes bekreftelse på opptak til hypervisor og deretter til VM. De registrerte dataene dedupliseres, komprimeres og skrives til lagringsdisker i bakgrunnen. Samtidig skrives det alltid en stor blokk til lagringsdiskene og sekvensielt, noe som reduserer belastningen på lagringsdiskene.
Deduplisering og komprimering er alltid aktivert og kan ikke deaktiveres. Data leses direkte fra lagringsdisker eller fra RAM-cachen. Hvis en hybridkonfigurasjon brukes, blir avlesningene også bufret på SSD-en.
Dataene er ikke knyttet til den aktuelle plasseringen til den virtuelle maskinen og fordeles jevnt mellom nodene. Denne tilnærmingen lar deg laste alle disker og nettverksgrensesnitt likt. Det er en åpenbar ulempe: vi kan ikke redusere leseforsinkelsen så mye som mulig, siden det ikke er noen garanti for datatilgjengelighet lokalt. Men jeg mener at dette er et mindre offer sammenlignet med de mottatte fordelene. Dessuten har nettverksforsinkelser nådd slike verdier at de praktisk talt ikke påvirker det samlede resultatet.
En spesialtjeneste VM Cisco HyperFlex Data Platform-kontroller, som opprettes på hver lagringsnode, er ansvarlig for hele operasjonslogikken til diskundersystemet. I vår tjeneste-VM-konfigurasjon ble åtte vCPUer og 72 GB RAM tildelt, noe som ikke er så lite. La meg minne deg på at selve verten har 28 fysiske kjerner og 512 GB RAM.
Tjenesten VM har tilgang til fysiske disker direkte ved å videresende SAS-kontrolleren til VM. Kommunikasjon med hypervisoren skjer gjennom en spesiell IOVisor-modul, som fanger opp I/O-operasjoner, og ved hjelp av en agent som lar deg sende kommandoer til hypervisor-API. Agenten er ansvarlig for å jobbe med HyperFlex øyeblikksbilder og kloner.
Diskressurser er montert i hypervisoren som NFS- eller SMB-andeler (avhengig av typen hypervisor, gjett hvilken som er hvor). Og under panseret er dette et distribuert filsystem som lar deg legge til funksjoner for fullverdige lagringssystemer for voksne: tynn volumallokering, komprimering og deduplisering, øyeblikksbilder ved hjelp av Redirect-on-Write-teknologi, synkron/asynkron replikering.
Tjenesten VM gir tilgang til WEB-administrasjonsgrensesnittet til HyperFlex-delsystemet. Det er integrasjon med vCenter, og de fleste hverdagsoppgaver kan utføres fra det, men datalagre er for eksempel mer praktisk å klippe fra et eget webkamera hvis du allerede har byttet til et raskt HTML5-grensesnitt, eller bruker en fullverdig Flash-klient med full integrasjon. I tjenestewebkameraet kan du se ytelsen og detaljert status til systemet.
Det er en annen type node i en klynge - databehandlingsnoder. Disse kan være rack- eller bladservere uten innebygde disker. Disse serverne kan kjøre VM-er hvis data er lagret på servere med disker. Fra et synspunkt om datatilgang er det ingen forskjell mellom typene noder, fordi arkitekturen innebærer abstraksjon fra den fysiske plasseringen av dataene. Det maksimale forholdet mellom databehandlingsnoder og lagringsnoder er 2:1.
Bruk av beregningsnoder øker fleksibiliteten ved skalering av klyngeressurser: vi trenger ikke kjøpe flere noder med disker hvis vi bare trenger CPU/RAM. I tillegg kan vi legge til et bladebur og spare på rackplassering av servere.
Som et resultat har vi en hyperkonvergert plattform med følgende funksjoner:
- Opptil 64 noder i en klynge (opptil 32 lagringsnoder).
- Minimum antall noder i en klynge er tre (to for en Edge-klynge).
- Dataredundansmekanisme: speiling med replikeringsfaktor 2 og 3.
- Metro klynge.
- Asynkron VM-replikering til en annen HyperFlex-klynge.
- Orkestrering av å bytte VM-er til et eksternt datasenter.
- Innfødte øyeblikksbilder ved hjelp av Redirect-on-Write-teknologi.
- Opptil 1 PB med brukbar plass ved replikeringsfaktor 3 og uten deduplisering. Vi tar ikke hensyn til replikeringsfaktor 2, fordi dette ikke er et alternativ for seriøse salg.
Et annet stort pluss er enkel administrasjon og distribusjon. All kompleksiteten ved å sette opp UCS-servere ivaretas av en spesialisert VM utarbeidet av Cisco-ingeniører.
Testbenkkonfigurasjon:
- 2 x Cisco UCS Fabric Interconnect 6248UP som en administrasjonsklynge og nettverkskomponenter (48 porter som opererer i Ethernet 10G/FC 16G-modus).
- Fire Cisco UCS HXAF240 M4-servere.
Serveregenskaper:
prosessor
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/dobbel rangering/x4/1.2v
Network
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet-porter
Lagring HBA
Cisco 12G Modular SAS Pass through Controller
Lagringsdisker
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Flere konfigurasjonsalternativerI tillegg til den valgte maskinvaren er følgende alternativer tilgjengelige for øyeblikket:
- HXAF240c M5.
- En eller to prosessorer fra Intel Silver 4110 til Intel Platinum I8260Y. Andre generasjon tilgjengelig.
- 24 minnespor, strimler fra 16 GB RDIMM 2600 til 128 GB LRDIMM 2933.
- Fra 6 til 23 datadisker, én caching-disk, én systemdisk og én oppstartsdisk.
Kapasitet Drives
- HX-SD960G61X-EV 960GB 2.5 Tommer Enterprise Value 6G SATA SSD (1X utholdenhet) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 tommer Enterprise Value 6G SATA SSD (1X utholdenhet) SAS 3.8 TB.
- Bufre stasjoner
- 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 utholdenhet) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 tommer Ent. Perf. 12G SAS SSD (10X utholdenhet) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 tommer Ent. Perf. 12G SAS SED SSD (10X utholdenhet) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 tommer Enterprise ytelse 12G SAS SSD (3X utholdenhet).
System/loggstasjoner
- HX-SD240GM1X-EV 240GB 2.5 tommer Enterprise Value 6G SATA SSD (Krever oppgradering).
Boot-stasjoner
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.
Koble til nettverket via 40G, 25G eller 10G Ethernet-porter.
FI kan være HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Selve testen
For å teste diskundersystemet brukte jeg HCIBench 2.2.1. Dette er et gratis verktøy som lar deg automatisere opprettelsen av en last fra flere virtuelle maskiner. Selve lasten genereres av den vanlige fio.
Vår klynge består av fire noder, replikeringsfaktor 3, alle disker er Flash.
For testing laget jeg fire databutikker og åtte virtuelle maskiner. For skrivetester antas det at caching-disken ikke er full.
Testresultatene er som følger:
100 % lest 100 % tilfeldig
0 % lest 100 % tilfeldig
Blokk/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
Fet skrift indikerer verdier hvoretter det ikke er noen økning i produktivitet, noen ganger er til og med nedbrytning synlig. Dette er på grunn av at vi er begrenset av ytelsen til nettverket/kontrollerne/diskene.
- Sekvensiell lesing 4432 MB/s.
- Sekvensiell skriving 804 MB/s.
- Hvis en kontroller svikter (feil på en virtuell maskin eller vert), er ytelsesfallet todelt.
- Hvis lagringsdisken feiler, er nedtrekket 1/3. Gjenoppbygging av disk tar 5 % av ressursene til hver kontroller.
På en liten blokk er vi begrenset av ytelsen til kontrolleren (virtuell maskin), CPU-en er lastet med 100 %, og når blokken øker, begrenses vi av portbåndbredden. 10 Gbps er ikke nok til å låse opp potensialet til AllFlash-systemet. Dessverre tillater ikke parametrene til det medfølgende demostativet oss å teste driften ved 40 Gbit/s.
Etter mitt inntrykk fra tester og studering av arkitekturen, på grunn av algoritmen som plasserer data mellom alle verter, får vi skalerbar, forutsigbar ytelse, men dette er også en begrensning ved lesing, fordi det ville være mulig å presse ut mer fra lokale disker, her kan det spare et mer produktivt nettverk, for eksempel er FI på 40 Gbit/s tilgjengelig.
En disk for caching og deduplisering kan også være en begrensning; faktisk kan vi i denne testbeden skrive til fire SSD-disker. Det ville vært flott å kunne øke antallet caching-stasjoner og se forskjellen.
Virkelig bruk
For å organisere et sikkerhetskopieringsdatasenter kan du bruke to tilnærminger (vi vurderer ikke å plassere en sikkerhetskopi på et eksternt nettsted):
- Aktiv passiv. Alle applikasjoner er vert i hoveddatasenteret. Replikering er synkron eller asynkron. Hvis hoveddatasenteret svikter, må vi aktivere backup-en. Dette kan gjøres manuelt/manus/orkestreringsapplikasjoner. Her vil vi få en RPO som står i forhold til replikeringsfrekvensen, og RTO avhenger av reaksjonen og ferdighetene til administratoren og kvaliteten på utvikling/feilsøking av bytteplanen.
- Aktiv-aktiv. I dette tilfellet er det bare synkron replikering; tilgjengeligheten til datasentre bestemmes av et quorum/arbiter som ligger strengt tatt på det tredje nettstedet. RPO = 0, og RTO kan nå 0 (hvis applikasjonen tillater det) eller lik failover-tiden til en node i en virtualiseringsklynge. På virtualiseringsnivået opprettes en strukket (Metro)-klynge som krever Active-Active-lagring.
Vanligvis ser vi at klienter allerede har implementert en arkitektur med et klassisk lagringssystem i hoveddatasenteret, så vi designer en annen for replikering. Som jeg nevnte, tilbyr Cisco HyperFlex asynkron replikering og strukket virtualiseringsklyngeoppretting. Samtidig trenger vi ikke et dedikert lagringssystem på mellomnivå og høyere med dyre replikeringsfunksjoner og Active-Active datatilgang på to lagringssystemer.
Scenario 1: Vi har et primært og backup datasenter, en virtualiseringsplattform på VMware vSphere. Alle produktive systemer er plassert i hoveddatasenteret, og replikering av virtuelle maskiner utføres på hypervisornivå, dette vil unngå å holde VM-er slått på i backup-datasenteret. Vi replikerer databaser og spesialapplikasjoner ved hjelp av innebygde verktøy og holder VM-ene slått på. Hvis hoveddatasenteret svikter, starter vi systemer i backupdatasenteret. Vi tror at vi har rundt 100 virtuelle maskiner. Mens primærdatasenteret er i drift, kan standby-datasenteret kjøre testmiljøer og andre systemer som kan stenges hvis primærdatasenteret bytter. Det er også mulig at vi bruker toveis replikering. Fra et maskinvaresynspunkt vil ingenting endre seg.
Når det gjelder klassisk arkitektur, vil vi i hvert datasenter installere et hybrid lagringssystem med tilgang via FibreChannel, tiering, deduplisering og komprimering (men ikke online), 8 servere for hver side, 2 FibreChannel-svitsjer og 10G Ethernet. For replikering og svitsjhåndtering i en klassisk arkitektur kan vi bruke VMware-verktøy (replikering + SRM) eller tredjepartsverktøy, som vil være litt billigere og noen ganger mer praktisk.
Figuren viser diagrammet.
Når du bruker Cisco HyperFlex, oppnås følgende arkitektur:
For HyperFlex brukte jeg servere med store CPU/RAM-ressurser, fordi... Noen av ressursene vil gå til HyperFlex-kontrolleren VM; når det gjelder CPU og minne, har jeg til og med rekonfigurert HyperFlex-konfigurasjonen litt for ikke å spille sammen med Cisco og garantere ressurser for de gjenværende VM-ene. Men vi kan forlate FibreChannel-svitsjer, og vi trenger ikke Ethernet-porter for hver server; lokal trafikk byttes innenfor FI.
Resultatet var følgende konfigurasjon for hvert datasenter:
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-svitsj 10G 12 porter
-
SAN
2 x FC-svitsj 32/16Gb 24 porter
2 x Cisco UCS FI 6332
av lisensen
VMware Ent Plus
Replikering og/eller orkestrering av VM-svitsjing
VMware Ent Plus
Jeg ga ikke replikeringsprogramvarelisenser for Hyperflex, siden dette er tilgjengelig direkte for oss.
For klassisk arkitektur valgte jeg en leverandør som har etablert seg som en høykvalitets og rimelig produsent. For begge alternativene brukte jeg standardrabatten for en spesifikk løsning, og som et resultat fikk jeg reelle priser.
Cisco HyperFlex-løsningen viste seg å være 13 % billigere.
Scenario 2: opprettelse av to aktive datasentre. I dette scenariet designer vi en strukket klynge på VMware.
Den klassiske arkitekturen består av virtualiseringsservere, en SAN (FC-protokoll) og to lagringssystemer som kan lese og skrive til volumet som er strukket mellom dem. På hvert lagringssystem legger vi en nyttig kapasitet for lagring.
Hos HyperFlex lager vi ganske enkelt en Stretch Cluster med samme antall noder på begge nettstedene. I dette tilfellet brukes en replikasjonsfaktor på 2+2.
Resultatet er følgende konfigurasjon:
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-svitsj 10G 24 porter
-
SAN
4 x FC-svitsj 32/16Gb 24 porter
4 x Cisco UCS FI 6332
av lisensen
VMware Ent Plus
VMware Ent Plus
I alle beregninger tok jeg ikke hensyn til nettverksinfrastruktur, datasenterkostnader osv.: de vil være de samme for den klassiske arkitekturen og for HyperFlex-løsningen.
Kostnadsmessig viste HyperFlex seg å være 5 % dyrere. Det er verdt å merke seg her at når det gjelder CPU/RAM-ressurser hadde jeg en skjevhet for Cisco, fordi i konfigurasjonen fylte jeg minnekontrollerkanalene jevnt. Kostnaden er litt høyere, men ikke i en størrelsesorden, noe som tydelig indikerer at hyperkonvergens ikke nødvendigvis er et "leketøy for de rike", men kan konkurrere med standardtilnærmingen til å bygge et datasenter. Dette kan også være av interesse for de som allerede har Cisco UCS-servere og tilhørende infrastruktur for dem.
Blant fordelene får vi fraværet av kostnader for å administrere SAN og lagringssystemer, online komprimering og deduplisering, et enkelt inngangspunkt for støtte (virtualisering, servere, de er også lagringssystemer), sparer plass (men ikke i alle scenarier), forenkle driften.
Når det gjelder støtte, her får du det fra én leverandør - Cisco. Etter min erfaring med Cisco UCS-servere, liker jeg det; jeg trengte ikke å åpne det på HyperFlex, alt fungerte akkurat det samme. Ingeniører reagerer raskt og kan løse ikke bare typiske problemer, men også komplekse kantsaker. Noen ganger henvender jeg meg til dem med spørsmål: "Er det mulig å gjøre dette, skru på det?" eller "Jeg konfigurerte noe her, og det vil ikke fungere. Hjelp!" - de vil tålmodig finne den nødvendige veiledningen der og påpeke de riktige handlingene; de vil ikke svare: "Vi løser bare maskinvareproblemer."
referanser
- Min mail - [e-postbeskyttet]
Kilde: www.habr.com