I denne artikel vil jeg gerne tale om funktionerne i All Flash AccelStor-arrays, der arbejder med en af de mest populære virtualiseringsplatforme - VMware vSphere. Fokuser især på de parametre, der vil hjælpe dig med at få den maksimale effekt af at bruge et så kraftfuldt værktøj som All Flash.
AccelStor NeoSapphire™ Alle Flash-arrays er eller node-enheder baseret på SSD-drev med en fundamentalt anderledes tilgang til implementering af konceptet datalagring og organisering af adgang til det ved hjælp af proprietær teknologi i stedet for de meget populære RAID-algoritmer. Arrays giver blokadgang til værter via Fibre Channel- eller iSCSI-grænseflader. For at være retfærdig bemærker vi, at modeller med en ISCSI-grænseflade også har filadgang som en god bonus. Men i denne artikel vil vi fokusere på brugen af blokprotokoller som den mest produktive for All Flash.
Hele processen med implementering og efterfølgende konfiguration af fælles drift af AccelStor-arrayet og VMware vSphere-virtualiseringssystemet kan opdeles i flere faser:
- Implementering af forbindelsestopologi og konfiguration af SAN-netværk;
- Opsætning af All Flash-array;
- Konfiguration af ESXi-værter;
- Opsætning af virtuelle maskiner.
AccelStor NeoSapphire™ Fibre Channel-arrays og iSCSI-arrays blev brugt som prøvehardware. Basissoftwaren er VMware vSphere 6.7U1.
Før du implementerer de systemer, der er beskrevet i denne artikel, anbefales det stærkt, at du læser dokumentationen fra VMware vedrørende ydeevneproblemer ( ) og iSCSI-indstillinger ()
Forbindelsestopologi og SAN-netværkskonfiguration
Hovedkomponenterne i et SAN-netværk er HBA'er i ESXi-værter, SAN-switche og array-noder. En typisk topologi for et sådant netværk ville se sådan ud:
Udtrykket Switch refererer her til både en separat fysisk switch eller et sæt switches (Fabric) og en enhed, der deles mellem forskellige tjenester (VSAN i tilfælde af Fibre Channel og VLAN i tilfælde af iSCSI). Brug af to uafhængige kontakter/stoffer vil eliminere et muligt fejlpunkt.
Direkte tilslutning af værter til arrayet, selvom det understøttes, anbefales stærkt ikke. Ydeevnen for All Flash-arrays er ret høj. Og for maksimal hastighed skal alle porte i arrayet bruges. Derfor er tilstedeværelsen af mindst én switch mellem værterne og NeoSapphire™ obligatorisk.
Tilstedeværelsen af to porte på værtens HBA er også et obligatorisk krav for at opnå maksimal ydeevne og sikre fejltolerance.
Når du bruger en Fibre Channel-grænseflade, skal zoneinddeling konfigureres for at eliminere mulige kollisioner mellem initiatorer og mål. Zoner er bygget efter princippet om "én initiatorport - en eller flere arrayporte."
Hvis du bruger en forbindelse via iSCSI i tilfælde af at bruge en switch, der deles med andre tjenester, så er det bydende nødvendigt at isolere iSCSI-trafik i et separat VLAN. Det anbefales også stærkt at aktivere understøttelse af Jumbo Frames (MTU = 9000) for at øge størrelsen af pakker på netværket og derved reducere mængden af overheadinformation under transmission. Det er dog værd at huske, at for korrekt drift er det nødvendigt at ændre MTU-parameteren på alle netværkskomponenter langs "initiator-switch-target"-kæden.
Opsætning af All Flash-array
Arrayet leveres til kunder med allerede dannede grupper . Derfor skal der ikke foretages handlinger for at kombinere drev i en enkelt struktur. Du skal blot oprette mængder af den nødvendige størrelse og mængde.
For nemheds skyld er der funktionalitet til batchoprettelse af flere volumener af en given størrelse på én gang. Som standard oprettes tynde volumener, da dette giver mulighed for mere effektiv udnyttelse af tilgængelig lagerplads (inklusive understøttelse af Space Reclamation). Med hensyn til ydeevne overstiger forskellen mellem "tynde" og "tykke" volumener ikke 1 %. Men hvis du vil "presse al saften" ud af et array, kan du altid konvertere enhver "tynd" volumen til en "tyk". Men det skal huskes, at en sådan operation er irreversibel.
Dernæst er det tilbage at "publicere" de oprettede volumener og indstille adgangsrettigheder til dem fra værterne ved hjælp af ACL'er (IP-adresser for iSCSI og WWPN for FC) og fysisk adskillelse af array-porte. For iSCSI-modeller gøres dette ved at oprette et mål.
For FC-modeller sker publicering gennem oprettelse af et LUN for hver port i arrayet.
For at fremskynde opsætningsprocessen kan værter kombineres i grupper. Desuden, hvis værten bruger en multiport FC HBA (hvilket i praksis oftest sker), så bestemmer systemet automatisk, at portene på en sådan HBA tilhører en enkelt vært takket være WWPN'er, der adskiller sig med én. Batch-oprettelse af Target/LUN understøttes også for begge grænseflader.
En vigtig bemærkning, når du bruger iSCSI-grænsefladen, er at oprette flere mål for volumener på én gang for at øge ydeevnen, da køen på målet ikke kan ændres og effektivt vil være en flaskehals.
Konfiguration af ESXi-værter
På ESXi-værtssiden udføres den grundlæggende konfiguration i overensstemmelse med et fuldstændigt forventet scenarie. Procedure for iSCSI-forbindelse:
- Tilføj Software iSCSI Adapter (ikke påkrævet, hvis den allerede er tilføjet, eller hvis du bruger Hardware iSCSI Adapter);
- Oprettelse af en vSwitch, som iSCSI-trafik vil passere igennem, og tilføjelse af et fysisk uplink og VMkernel til det;
- Tilføjelse af array-adresser til Dynamic Discovery;
- Oprettelse af datalager
Nogle vigtige bemærkninger:
- I det generelle tilfælde kan du selvfølgelig bruge en eksisterende vSwitch, men i tilfælde af en separat vSwitch vil det være meget nemmere at administrere værtsindstillingerne.
- Det er nødvendigt at adskille Management- og iSCSI-trafik på separate fysiske links og/eller VLAN'er for at undgå ydeevneproblemer.
- IP-adresserne på VMkernel og de tilsvarende porte i All Flash-arrayet skal være inden for det samme undernet, igen på grund af ydeevneproblemer.
- For at sikre fejltolerance i henhold til VMware-reglerne skal vSwitch have mindst to fysiske uplinks
- Hvis der bruges Jumbo Frames, skal du ændre MTU'en for både vSwitch og VMkernel
- Det ville være nyttigt at minde dig om, at ifølge VMware-anbefalinger for fysiske adaptere, der vil blive brugt til at arbejde med iSCSI-trafik, er det nødvendigt at konfigurere Teaming og Failover. Især skal hver VMkerne kun arbejde gennem én uplink, den anden uplink skal skiftes til ubrugt tilstand. For fejltolerance skal du tilføje to VMkerner, som hver vil arbejde gennem sit eget uplink.
VMkernel Adapter (vmk#)
Fysisk netværksadapter (vmnic#)
vmk1 (Storage01)
Aktive adaptere
vmnic2
Ubrugte adaptere
vmnic3
vmk2 (Storage02)
Aktive adaptere
vmnic3
Ubrugte adaptere
vmnic2
Der kræves ingen indledende trin for at oprette forbindelse via Fibre Channel. Du kan straks oprette en Datastore.
Efter oprettelse af datalageret skal du sikre dig, at Round Robin-politikken for stier til Target/LUN bruges som den mest effektive.
Som standard giver VMware-indstillingerne mulighed for brug af denne politik i henhold til skemaet: 1000 anmodninger gennem den første sti, de næste 1000 anmodninger gennem den anden sti, osv. En sådan interaktion mellem værten og to-controller-arrayet vil være ubalanceret. Derfor anbefaler vi at indstille Round Robin-politikken = 1 parameter via Esxcli/PowerCLI.
Parametre
Til Esccli:
- Liste over tilgængelige LUN'er
esxcli lager nmp enhedsliste
- Kopiér enhedsnavn
- Skift Round Robin-politik
esxcli storage nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=“Device_ID”
De fleste moderne applikationer er designet til at udveksle store datapakker for at maksimere båndbreddeudnyttelsen og reducere CPU-belastningen. Derfor sender ESXi som standard I/O-anmodninger til lagerenheden i bidder på op til 32767KB. Men for nogle scenarier vil udveksling af mindre bidder være mere produktivt. For AccelStor-arrays er disse følgende scenarier:
- Den virtuelle maskine bruger UEFI i stedet for Legacy BIOS
- Bruger vSphere Replication
For sådanne scenarier anbefales det at ændre værdien af parameteren Disk.DiskMaxIOSize til 4096.
For iSCSI-forbindelser anbefales det at ændre login-timeout-parameteren til 30 (standard 5) for at øge forbindelsesstabiliteten og deaktivere DelayedAck-forsinkelsen for bekræftelser af videresendte pakker. Begge muligheder er i vSphere Client: Host → Konfigurer → Lager → Lageradaptere → Avancerede indstillinger for iSCSI-adapter
Et ret subtilt punkt er antallet af bind, der bruges til datalageret. Det er klart, at for at lette administrationen er der et ønske om at skabe én stor volumen for hele arrayets volumen. Tilstedeværelsen af flere volumener og dermed datalager har dog en gavnlig effekt på den samlede ydeevne (mere om køer nedenfor). Derfor anbefaler vi at oprette mindst to bind.
Indtil relativt for nylig rådede VMware til at begrænse antallet af virtuelle maskiner på et datalager, igen for at opnå den højest mulige ydeevne. Men nu, især med spredningen af VDI, er dette problem ikke længere så akut. Men dette annullerer ikke den langvarige regel - at distribuere virtuelle maskiner, der kræver intensiv IO på tværs af forskellige datalagre. For at bestemme det optimale antal virtuelle maskiner pr. volumen er der intet bedre end inden for sin infrastruktur.
Opsætning af virtuelle maskiner
Der er ingen særlige krav ved opsætning af virtuelle maskiner, eller rettere sagt, de er ganske almindelige:
- Brug af den højest mulige VM-version (kompatibilitet)
- Det er mere omhyggeligt at indstille RAM-størrelsen, når du placerer virtuelle maskiner tæt, for eksempel i VDI (da der som standard ved opstart oprettes en sidefil af en størrelse, der svarer til RAM'en, som forbruger nyttig kapacitet og har en effekt på den sidste forestilling)
- Brug de mest produktive adapterversioner med hensyn til IO: netværkstype VMXNET 3 og SCSI type PVSCSI
- Brug Thick Provision Eager Zeroed disktype for maksimal ydeevne og Thin Provisioning for maksimal udnyttelse af lagerplads
- Hvis det er muligt, skal du begrænse driften af ikke-I/O-kritiske maskiner ved hjælp af Virtual Disk Limit
- Sørg for at installere VMware Tools
Bemærkninger om køer
Kø (eller udestående I/O'er) er antallet af input/output-anmodninger (SCSI-kommandoer), der venter på behandling på et givet tidspunkt for en specifik enhed/applikation. I tilfælde af køoverløb udsendes QFULL-fejl, hvilket i sidste ende resulterer i en stigning i latensparameteren. Når du bruger disk (spindel) lagringssystemer, er det teoretisk set, at jo højere køen er, jo højere ydeevne. Du bør dog ikke misbruge det, da det er nemt at løbe ind i QFULL. I tilfældet med All Flash-systemer er alt på den ene side noget enklere: Når alt kommer til alt, har arrayet latenser, der er størrelsesordener lavere, og derfor er det oftest ikke nødvendigt at særskilt regulere størrelsen af køerne. Men på den anden side, i nogle brugsscenarier (stærk skævhed i IO-krav til specifikke virtuelle maskiner, test for maksimal ydeevne osv.) er det nødvendigt, hvis ikke at ændre parametrene for køerne, så i det mindste at forstå hvilke indikatorer kan opnås, og det vigtigste er på hvilke måder.
På selve AccelStor All Flash-arrayet er der ingen begrænsninger i forhold til volumener eller I/O-porte. Om nødvendigt kan selv et enkelt volumen modtage alle arrayets ressourcer. Den eneste begrænsning på køen er for iSCSI-mål. Det er af denne grund, at behovet for at skabe flere (ideelt set op til 8 stykker) mål for hvert volumen for at overvinde denne grænse blev angivet ovenfor. Lad os også gentage, at AccelStor-arrays er meget produktive løsninger. Derfor bør du bruge alle interfaceporte i systemet for at opnå maksimal hastighed.
På ESXi værtssiden er situationen en helt anden. Værten anvender selv praksis med lige adgang til ressourcer for alle deltagere. Derfor er der separate IO-køer til gæste-OS og HBA. Køer til gæsteoperativsystemet kombineres fra køer til den virtuelle SCSI-adapter og virtuelle disk:
Køen til HBA afhænger af den specifikke type/leverandør:
Den endelige ydeevne af den virtuelle maskine vil blive bestemt af den laveste kødybdegrænse blandt værtskomponenterne.
Takket være disse værdier kan vi evaluere de præstationsindikatorer, som vi kan få i en bestemt konfiguration. For eksempel vil vi kende den teoretiske ydeevne af en virtuel maskine (uden blokbinding) med en latenstid på 0.5 ms. Så er dens IOPS = (1,000/latency) * Udestående I/O'er (grænse for kødybde)
Примеры
Eksempel 1
- FC Emulex HBA adapter
- Én VM pr. datalager
- VMware Paravirtual SCSI Adapter
Her bestemmes kødybdegrænsen af Emulex HBA. Derfor IOPS = (1000/0.5)*32 = 64K
Eksempel 2
- VMware iSCSI-softwareadapter
- Én VM pr. datalager
- VMware Paravirtual SCSI Adapter
Her er kødybdegrænsen allerede bestemt af Paravirtual SCSI-adapteren. Derfor IOPS = (1000/0.5)*64 = 128K
Topmodeller af alle Flash AccelStor-arrays (f.eks. ) er i stand til at levere 700K IOPS skriveydeevne ved 4K blok. Med sådan en blokstørrelse er det helt indlysende, at en enkelt virtuel maskine ikke er i stand til at indlæse et sådant array. For at gøre dette skal du bruge 11 (for eksempel 1) eller 6 (for eksempel 2) virtuelle maskiner.
Som et resultat, med den korrekte konfiguration af alle de beskrevne komponenter i et virtuelt datacenter, kan du få meget imponerende resultater med hensyn til ydeevne.
4K Tilfældig, 70% Læs/30% Skriv
Faktisk er den virkelige verden meget mere kompleks, end den kan beskrives med en simpel formel. Én vært er altid vært for flere virtuelle maskiner med forskellige konfigurationer og IO-krav. Og I/O-behandling håndteres af værtsprocessoren, hvis kraft ikke er uendelig. Så for at frigøre det fulde potentiale af det samme i virkeligheden skal du bruge tre værter. Plus, applikationer, der kører inde i virtuelle maskiner, foretager deres egne justeringer. Derfor tilbyder vi præcis dimensionering Alle Flash-arrays inde i kundens infrastruktur på reelle aktuelle opgaver.
Kilde: www.habr.com