Detta är en myt som är ganska vanlig inom serverhårdvara. I praktiken behövs hyperkonvergerade lösningar (när allt är i ett) för många saker. Historiskt sett utvecklades de första arkitekturerna av Amazon och Google för deras tjänster. Sedan var tanken att göra en datorfarm från identiska noder, som var och en hade sina egna diskar. Allt detta förenades av någon systembildande programvara (hypervisor) och delades upp i virtuella maskiner. Huvudmålet är ett minimum av ansträngning för att serva en nod och ett minimum av problem vid skalning: köp bara ytterligare tusen eller två av samma servrar och anslut dem i närheten. I praktiken är det enstaka fall och mycket oftare talar vi om ett mindre antal noder och en lite annorlunda arkitektur.
Men pluset förblir detsamma - otrolig enkel skalning och hantering. Nackdelen är att olika uppgifter förbrukar resurser olika, och på vissa ställen kommer det att finnas många lokala diskar, på andra blir det lite RAM och så vidare, det vill säga för olika typer av uppgifter kommer resursutnyttjandet att minska.
Det visar sig att du betalar 10–15 % mer för enkel installation. Det var detta som väckte myten i titeln. Vi letade länge efter var tekniken skulle tillämpas optimalt och vi hittade det. Faktum är att Cisco inte hade några egna lagringssystem, men de ville ha en komplett servermarknad. Och de gjorde Cisco Hyperflex – en lösning med lokal lagring på noder.
Och detta visade sig plötsligt vara en mycket bra lösning för säkerhetskopiering av datacenter (Disaster Recovery). Jag ska berätta varför och hur nu. Och jag ska visa dig klustertesterna.
Där det behövs
Hyperkonvergens är:
- Överföra diskar till beräkningsnoder.
- Full integration av lagringsundersystemet med virtualiseringsundersystemet.
- Överföring/integration med nätverkets delsystem.
Denna kombination låter dig implementera många lagringssystemfunktioner på virtualiseringsnivå och allt från ett kontrollfönster.
I vårt företag är projekt för att designa redundanta datacenter mycket efterfrågade, och en hyperkonvergerad lösning väljs ofta på grund av ett gäng replikeringsalternativ (upp till ett metrokluster) ur lådan.
När det gäller backup-datacenter talar vi vanligtvis om en avlägsen anläggning på en plats på andra sidan staden eller i en annan stad helt och hållet. Det låter dig återställa kritiska system i händelse av ett partiellt eller fullständigt fel på huvuddatacentret. Försäljningsdata replikeras ständigt där, och denna replikering kan vara på applikationsnivå eller på blockenhetsnivå (lagring).
Därför kommer jag nu att prata om systemdesign och tester, och sedan om ett par verkliga tillämpningsscenarier med besparingsdata.
Tester
Vår instans består av fyra servrar, som var och en har 10 SSD-enheter på 960 GB. Det finns en dedikerad disk för cachelagring av skrivoperationer och lagring av tjänstens virtuella maskin. Själva lösningen är den fjärde versionen. Den första är uppriktigt sagt grov (att döma av recensionerna), den andra är fuktig, den tredje är redan ganska stabil, och den här kan kallas en release efter betatestningens slut för allmänheten. Under testet såg jag inga problem, allt fungerar som en klocka.
Ändringar i v4Ett gäng buggar har åtgärdats.
Till en början kunde plattformen bara fungera med VMware ESXi hypervisor och stödde ett litet antal noder. Dessutom slutade inte distributionsprocessen alltid framgångsrikt, vissa steg måste startas om, det fanns problem med uppdatering från äldre versioner, data i GUI visades inte alltid korrekt (även om jag fortfarande inte är nöjd med visningen av prestandagrafer ), ibland uppstod problem i gränssnittet med virtualisering.
Nu har alla barndomsproblem åtgärdats, HyperFlex kan hantera både ESXi och Hyper-V, plus att det är möjligt att:
- Skapa ett sträckt kluster.
- Skapa ett kluster för kontor utan att använda Fabric Interconnect, från två till fyra noder (vi köper bara servrar).
- Förmåga att arbeta med externa lagringssystem.
- Stöd för containrar och Kubernetes.
- Skapande av tillgänglighetszoner.
- Integration med VMware SRM om den inbyggda funktionaliteten inte är tillfredsställande.
Arkitekturen skiljer sig inte mycket från lösningarna från sina huvudkonkurrenter, de skapade inte en cykel. Det hela körs på VMware eller Hyper-V virtualiseringsplattformen. Hårdvaran finns på egenutvecklade Cisco UCS-servrar. Det finns de som hatar plattformen för den relativa komplexiteten i den initiala installationen, många knappar, ett icke-trivialt system av mallar och beroenden, men det finns också de som har lärt sig Zen, är inspirerade av idén och inte längre vill att arbeta med andra servrar.
Vi kommer att överväga lösningen för VMware, eftersom lösningen ursprungligen skapades för den och har mer funktionalitet; Hyper-V lades till längs vägen för att hålla jämna steg med konkurrenterna och möta marknadens förväntningar.
Det finns ett kluster av servrar fulla av diskar. Det finns diskar för datalagring (SSD eller HDD - efter din smak och behov), det finns en SSD-disk för cachning. När du skriver data till datalagringen sparas data på cachinglagret (dedikerad SSD-disk och RAM för tjänsten VM). Parallellt skickas ett datablock till noder i klustret (antalet noder beror på klusterreplikeringsfaktorn). Efter bekräftelse från alla noder om lyckad inspelning skickas bekräftelse på inspelningen till hypervisorn och sedan till den virtuella datorn. Den inspelade datan dedupliceras, komprimeras och skrivs till lagringsdiskar i bakgrunden. Samtidigt skrivs alltid ett stort block till lagringsdiskarna och sekventiellt, vilket minskar belastningen på lagringsdiskarna.
Deduplicering och komprimering är alltid aktiverade och kan inte inaktiveras. Data läses direkt från lagringsdiskar eller från RAM-cachen. Om en hybridkonfiguration används, cachelagras läsningarna också på SSD:n.
Datan är inte knuten till den virtuella maskinens aktuella plats och fördelas jämnt mellan noderna. Detta tillvägagångssätt låter dig ladda alla diskar och nätverksgränssnitt lika. Det finns en uppenbar nackdel: vi kan inte minska läslatensen så mycket som möjligt, eftersom det inte finns någon garanti för datatillgänglighet lokalt. Men jag tror att detta är en mindre uppoffring jämfört med de erhållna förmånerna. Dessutom har nätverksförseningar nått sådana värden att de praktiskt taget inte påverkar det totala resultatet.
En specialtjänst VM Cisco HyperFlex Data Platform-kontroller, som skapas på varje lagringsnod, ansvarar för hela operationslogiken för diskdelsystemet. I vår tjänst VM-konfiguration tilldelades åtta vCPU: er och 72 GB RAM, vilket inte är så lite. Låt mig påminna dig om att själva värden har 28 fysiska kärnor och 512 GB RAM.
Tjänsten VM har tillgång till fysiska diskar direkt genom att vidarebefordra SAS-kontrollern till VM:n. Kommunikation med hypervisorn sker genom en speciell modul IOVisor, som fångar upp I/O-operationer, och med hjälp av en agent som låter dig skicka kommandon till hypervisor API. Agenten ansvarar för att arbeta med HyperFlex ögonblicksbilder och kloner.
Diskresurser är monterade i hypervisorn som NFS- eller SMB-resurser (beroende på typen av hypervisor, gissa vilken som är var). Och under huven är detta ett distribuerat filsystem som låter dig lägga till funktioner i fullfjädrade lagringssystem för vuxna: tunn volymallokering, komprimering och deduplicering, ögonblicksbilder med Redirect-on-Write-teknik, synkron/asynkron replikering.
Tjänsten VM ger åtkomst till WEB-hanteringsgränssnittet för HyperFlex-delsystemet. Det finns integration med vCenter, och de flesta vardagliga uppgifter kan utföras från det, men databutiker är till exempel bekvämare att klippa från en separat webbkamera om du redan har bytt till ett snabbt HTML5-gränssnitt, eller använder en fullfjädrad Flash-klient med full integration. I tjänstewebbkameran kan du se prestanda och detaljerad status för systemet.
Det finns en annan typ av nod i ett kluster - datornoder. Dessa kan vara rack- eller bladservrar utan inbyggda diskar. Dessa servrar kan köra virtuella datorer vars data lagras på servrar med diskar. Ur dataåtkomstsynpunkt finns det ingen skillnad mellan typerna av noder, eftersom arkitekturen innebär abstraktion från den fysiska platsen för datan. Det maximala förhållandet mellan beräkningsnoder och lagringsnoder är 2:1.
Att använda beräkningsnoder ökar flexibiliteten vid skalning av klusterresurser: vi behöver inte köpa ytterligare noder med diskar om vi bara behöver CPU/RAM. Dessutom kan vi lägga till en bladbur och spara på rackplacering av servrar.
Som ett resultat har vi en hyperkonvergerad plattform med följande funktioner:
- Upp till 64 noder i ett kluster (upp till 32 lagringsnoder).
- Minsta antalet noder i ett kluster är tre (två för ett Edge-kluster).
- Dataredundansmekanism: spegling med replikeringsfaktor 2 och 3.
- Metro kluster.
- Asynkron VM-replikering till ett annat HyperFlex-kluster.
- Orkesterering av att byta virtuella datorer till ett fjärrdatacenter.
- Inbyggda ögonblicksbilder med Redirect-on-Write-teknik.
- Upp till 1 PB användbart utrymme vid replikeringsfaktor 3 och utan deduplicering. Vi tar inte hänsyn till replikeringsfaktor 2, eftersom detta inte är ett alternativ för seriös försäljning.
Ett annat stort plus är enkel hantering och distribution. All komplexitet med att installera UCS-servrar tas om hand av en specialiserad virtuell dator som utarbetats av Ciscos ingenjörer.
Testbänkkonfiguration:
- 2 x Cisco UCS Fabric Interconnect 6248UP som ett hanteringskluster och nätverkskomponenter (48 portar som fungerar i Ethernet 10G/FC 16G-läge).
- Fyra Cisco UCS HXAF240 M4-servrar.
Serveregenskaper:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
nätverks
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet-portar
Förvaring HBA
Cisco 12G Modular SAS Pass through Controller
Lagringsdiskar
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Fler konfigurationsalternativUtöver den valda hårdvaran finns för närvarande följande alternativ tillgängliga:
- HXAF240c M5.
- En eller två processorer från Intel Silver 4110 till Intel Platinum I8260Y. Andra generationen tillgänglig.
- 24 minneskortplatser, remsor från 16 GB RDIMM 2600 till 128 GB LRDIMM 2933.
- Från 6 till 23 datadiskar, en cachningsdisk, en systemdisk och en startdiskett.
Kapacitetsdrifter
- HX-SD960G61X-EV 960GB 2.5 tum Enterprise Value 6G SATA SSD (1X uthållighet) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 tum Enterprise Value 6G SATA SSD (1X uthållighet) SAS 3.8 TB.
- Cacha enheter
- HX-NVMEXPB-I375 375GB 2.5 tum Intel Optane Drive, Extreme Perf & Endurance.
- HX-NVMEHW-H1600* 1.6TB 2.5 tum Ent. Perfekt. NVMe SSD (3X uthållighet) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 tum Ent. Perfekt. 12G SAS SSD (10X uthållighet) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 tum Ent. Perfekt. 12G SAS SED SSD (10X uthållighet) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 tum Enterprise prestanda 12G SAS SSD (3X uthållighet).
System/loggenheter
- HX-SD240GM1X-EV 240GB 2.5 tum Enterprise Value 6G SATA SSD (kräver uppgradering).
Starta enheter
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.
Anslut till nätverket via 40G, 25G eller 10G Ethernet-portar.
FI kan vara HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Själva testet
För att testa diskundersystemet använde jag HCIBench 2.2.1. Detta är ett gratis verktyg som låter dig automatisera skapandet av en laddning från flera virtuella maskiner. Själva lasten genereras av den vanliga fio.
Vårt kluster består av fyra noder, replikeringsfaktor 3, alla diskar är Flash.
För att testa skapade jag fyra databutiker och åtta virtuella maskiner. För skrivtester antas det att cachingskivan inte är full.
Testresultaten är följande:
100 % läst 100 % slumpmässigt
0 % läst 100 % slumpmässigt
Block/ködjup
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 anger värden efter vilka det inte finns någon ökning i produktivitet, ibland är till och med försämring synlig. Detta beror på att vi är begränsade av prestanda hos nätverket/kontrollerna/diskarna.
- Sekventiell läsning 4432 MB/s.
- Sekventiell skrivning 804 MB/s.
- Om en kontroller misslyckas (fel på en virtuell maskin eller värd), är prestandaminskningen dubbel.
- Om lagringsdisken misslyckas är neddragningen 1/3. Diskåterbyggnad tar 5 % av resurserna för varje kontrollenhet.
På ett litet block begränsas vi av styrenhetens prestanda (virtuell maskin), dess CPU laddas med 100 %, och när blocket ökar begränsas vi av portens bandbredd. 10 Gbps är inte tillräckligt för att låsa upp potentialen i AllFlash-systemet. Tyvärr tillåter inte parametrarna för det medföljande demostället oss att testa driften med 40 Gbit/s.
Enligt mitt intryck från tester och studier av arkitekturen, på grund av algoritmen som placerar data mellan alla värdar, får vi skalbar, förutsägbar prestanda, men detta är också en begränsning vid läsning, eftersom det skulle vara möjligt att klämma ut mer från lokala diskar, här kan det rädda ett mer produktivt nätverk, till exempel finns FI på 40 Gbit/s tillgängligt.
En disk för cachning och deduplicering kan också vara en begränsning; i denna testbädd kan vi faktiskt skriva till fyra SSD-diskar. Det skulle vara fantastiskt att kunna öka antalet cachningsenheter och se skillnaden.
Verklig användning
För att organisera ett säkerhetskopieringsdatacenter kan du använda två metoder (vi överväger inte att placera en säkerhetskopia på en fjärrplats):
- Aktiv passiv. Alla applikationer finns i huvuddatacentret. Replikering är synkron eller asynkron. Om huvuddatacentret misslyckas måste vi aktivera backupen. Detta kan göras manuellt/manus/orkestreringsapplikationer. Här kommer vi att få en RPO som motsvarar replikeringsfrekvensen, och RTO:n beror på administratörens reaktion och kompetens och kvaliteten på utvecklingen/felsökningen av växlingsplanen.
- Aktiv-Aktiv. I det här fallet finns det bara synkron replikering; tillgängligheten för datacenter bestäms av ett beslutfört/arbiter som finns enbart på den tredje platsen. RPO = 0, och RTO kan nå 0 (om applikationen tillåter) eller lika med failover-tiden för en nod i ett virtualiseringskluster. På virtualiseringsnivån skapas ett sträckt (Metro)-kluster som kräver Active-Active-lagring.
Vanligtvis ser vi att kunder redan har implementerat en arkitektur med ett klassiskt lagringssystem i huvuddatacentret, så vi designar ytterligare ett för replikering. Som jag nämnde erbjuder Cisco HyperFlex asynkron replikering och skapande av utökade virtualiseringskluster. Samtidigt behöver vi inte ett dedikerat lagringssystem på mellannivå och högre med dyra replikeringsfunktioner och Active-Active dataåtkomst på två lagringssystem.
Scenario 1: Vi har ett primärt och backup-datacenter, en virtualiseringsplattform på VMware vSphere. Alla produktiva system finns i huvuddatacentret och replikering av virtuella maskiner utförs på hypervisornivå, detta kommer att undvika att hålla virtuella datorer påslagna i backupdatacentret. Vi replikerar databaser och specialapplikationer med hjälp av inbyggda verktyg och håller de virtuella datorerna påslagna. Om huvuddatacentret misslyckas startar vi system i backupdatacentret. Vi tror att vi har cirka 100 virtuella maskiner. Medan det primära datacentret är i drift kan standby-datacentret köra testmiljöer och andra system som kan stängas av om det primära datacentret växlar över. Det är också möjligt att vi använder tvåvägsreplikering. Ur hårdvarusynpunkt kommer ingenting att förändras.
När det gäller klassisk arkitektur kommer vi i varje datacenter att installera ett hybridlagringssystem med åtkomst via FibreChannel, nivådelning, deduplicering och komprimering (men inte online), 8 servrar för varje plats, 2 FibreChannel-switchar och 10G Ethernet. För replikering och växlingshantering i en klassisk arkitektur kan vi använda VMware-verktyg (replikering + SRM) eller tredjepartsverktyg, vilket blir lite billigare och ibland mer bekvämt.
Figuren visar diagrammet.
När du använder Cisco HyperFlex erhålls följande arkitektur:
För HyperFlex använde jag servrar med stora CPU/RAM-resurser, eftersom... En del av resurserna kommer att gå till HyperFlex-kontrollern VM; när det gäller CPU och minne har jag till och med konfigurerat om HyperFlex-konfigurationen lite för att inte spela tillsammans med Cisco och garantera resurser för de återstående virtuella datorerna. Men vi kan överge FibreChannel-switchar och vi kommer inte att behöva Ethernet-portar för varje server, lokal trafik växlas inom FI.
Resultatet blev följande konfiguration för varje datacenter:
Servrar
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
Hybridlagringssystem med FC Front-End (20TB SSD, 130TB NL-SAS)
-
LAN
2 x Ethernet-switch 10G 12 portar
-
SAN
2 x FC switch 32/16Gb 24 portar
2 x Cisco UCS FI 6332
av licensen
VMware Ent Plus
Replikering och/eller orkestrering av VM-växling
VMware Ent Plus
Jag tillhandahöll inte replikeringsmjukvarulicenser för Hyperflex, eftersom detta är tillgängligt direkt för oss.
För klassisk arkitektur valde jag en leverantör som har etablerat sig som en högkvalitativ och billig tillverkare. För båda alternativen använde jag standardrabatten för en specifik lösning, och som ett resultat fick jag riktiga priser.
Cisco HyperFlex-lösningen visade sig vara 13 % billigare.
Scenario 2: skapandet av två aktiva datacenter. I det här scenariot designar vi ett sträckt kluster på VMware.
Den klassiska arkitekturen består av virtualiseringsservrar, ett SAN (FC-protokoll) och två lagringssystem som kan läsa och skriva till den volym som sträcks mellan dem. På varje lagringssystem lägger vi en användbar kapacitet för lagring.
På HyperFlex skapar vi helt enkelt ett Stretch Cluster med samma antal noder på båda platserna. I detta fall används en replikationsfaktor på 2+2.
Resultatet är följande konfiguration:
klassisk arkitektur
HyperFlex
Servrar
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-lagringssystem (150 TB SSD)
-
LAN
4 x Ethernet-switch 10G 24 portar
-
SAN
4 x FC switch 32/16Gb 24 portar
4 x Cisco UCS FI 6332
av licensen
VMware Ent Plus
VMware Ent Plus
I alla beräkningar tog jag inte hänsyn till nätverksinfrastrukturen, datacenterkostnader etc.: de kommer att vara desamma för den klassiska arkitekturen och för HyperFlex-lösningen.
Kostnadsmässigt visade sig HyperFlex vara 5% dyrare. Det är värt att notera här att när det gäller CPU/RAM-resurser hade jag en skevhet för Cisco, eftersom jag i konfigurationen fyllde minneskontrollerkanalerna jämnt. Kostnaden är något högre, men inte i en storleksordning, vilket tydligt indikerar att hyperkonvergens inte nödvändigtvis är en "leksak för de rika", utan kan konkurrera med standardmetoden för att bygga ett datacenter. Detta kan också vara av intresse för de som redan har Cisco UCS-servrar och motsvarande infrastruktur för dem.
Bland fördelarna får vi frånvaron av kostnader för att administrera SAN och lagringssystem, onlinekomprimering och deduplicering, en enda ingångspunkt för support (virtualisering, servrar, de är också lagringssystem), sparar utrymme (men inte i alla scenarier), förenkla driften.
När det gäller support, här får du det från en leverantör - Cisco. Att döma av min erfarenhet av Cisco UCS-servrar gillar jag det; jag behövde inte öppna det på HyperFlex, allt fungerade precis likadant. Ingenjörer svarar snabbt och kan lösa inte bara typiska problem utan även komplexa kantfall. Ibland vänder jag mig till dem med frågor: "Är det möjligt att göra det här, skruva på det?" eller "Jag konfigurerade något här, och det vill inte fungera. Hjälp!" - de kommer tålmodigt att hitta den nödvändiga guiden där och peka ut de korrekta åtgärderna; de kommer inte att svara: "Vi löser bara hårdvaruproblem."
referenser
- Min post - [e-postskyddad]
Källa: will.com