I denne artikkelen vil jeg gjerne snakke om funksjonene til All Flash AccelStor-matriser som jobber med en av de mest populære virtualiseringsplattformene - VMware vSphere. Fokuser spesielt på de parametrene som vil hjelpe deg å få maksimal effekt av å bruke et så kraftig verktøy som All Flash.
AccelStor NeoSapphire™ Alle Flash-arrays er eller nodeenheter basert på SSD-stasjoner med en fundamentalt annen tilnærming til å implementere konseptet med datalagring og organisere tilgang til det ved hjelp av proprietær teknologi i stedet for de svært populære RAID-algoritmene. Arrayene gir blokktilgang til verter via Fibre Channel- eller iSCSI-grensesnitt. For å være rettferdig bemerker vi at modeller med ISCSI-grensesnitt også har filtilgang som en fin bonus. Men i denne artikkelen vil vi fokusere på bruken av blokkprotokoller som den mest produktive for All Flash.
Hele prosessen med distribusjon og påfølgende konfigurasjon av felles drift av AccelStor-arrayet og VMware vSphere-virtualiseringssystemet kan deles inn i flere stadier:
- Implementering av tilkoblingstopologi og konfigurasjon av SAN-nettverk;
- Sette opp All Flash-array;
- Konfigurere ESXi-verter;
- Sette opp virtuelle maskiner.
AccelStor NeoSapphire™ Fibre Channel-matriser og iSCSI-matriser ble brukt som prøvemaskinvare. Basisprogramvaren er VMware vSphere 6.7U1.
Før du distribuerer systemene beskrevet i denne artikkelen, anbefales det sterkt at du leser dokumentasjonen fra VMware angående ytelsesproblemer ( ) og iSCSI-innstillinger ()
Tilkoblingstopologi og SAN-nettverkskonfigurasjon
Hovedkomponentene i et SAN-nettverk er HBA-er i ESXi-verter, SAN-svitsjer og array-noder. En typisk topologi for et slikt nettverk vil se slik ut:
Begrepet Switch her refererer til både en separat fysisk bryter eller sett med brytere (Fabric), og en enhet som deles mellom ulike tjenester (VSAN for Fibre Channel og VLAN for iSCSI). Bruk av to uavhengige brytere/stoffer vil eliminere et mulig feilpunkt.
Direkte tilkobling av verter til arrayet, selv om det støttes, anbefales sterkt ikke. Ytelsen til All Flash-arrays er ganske høy. Og for maksimal hastighet må alle porter i arrayet brukes. Derfor er tilstedeværelsen av minst én svitsj mellom vertene og NeoSapphire™ obligatorisk.
Tilstedeværelsen av to porter på verts-HBA er også et obligatorisk krav for å oppnå maksimal ytelse og sikre feiltoleranse.
Når du bruker et Fibre Channel-grensesnitt, må soneinndeling konfigureres for å eliminere mulige kollisjoner mellom initiativtakere og mål. Soner er bygget på prinsippet om "én initiatorport - en eller flere array-porter."
Hvis du bruker en tilkobling via iSCSI i tilfelle du bruker en svitsj som deles med andre tjenester, er det viktig å isolere iSCSI-trafikk innenfor et separat VLAN. Det anbefales også sterkt å aktivere støtte for Jumbo Frames (MTU = 9000) for å øke størrelsen på pakker på nettverket og dermed redusere mengden overheadinformasjon under overføring. Det er imidlertid verdt å huske at for korrekt drift er det nødvendig å endre MTU-parameteren på alle nettverkskomponenter langs "initiator-switch-target"-kjeden.
Sette opp All Flash-array
Matrisen leveres til kunder med allerede dannede grupper . Det er derfor ikke nødvendig å gjøre noe for å kombinere stasjoner til en enkelt struktur. Du trenger bare å lage volumer med ønsket størrelse og mengde.
For enkelhets skyld er det funksjonalitet for batchoppretting av flere volumer av en gitt størrelse samtidig. Som standard opprettes tynne volumer, da dette muliggjør mer effektiv bruk av tilgjengelig lagringsplass (inkludert støtte for Space Reclamation). Når det gjelder ytelse, overstiger ikke forskjellen mellom "tynne" og "tykke" volumer 1 %. Men hvis du vil "presse all saften" ut av en matrise, kan du alltid konvertere et "tynt" volum til et "tykt" volum. Men det bør huskes at en slik operasjon er irreversibel.
Deretter gjenstår det å "publisere" de opprettede volumene og angi tilgangsrettigheter til dem fra vertene ved å bruke ACL-er (IP-adresser for iSCSI og WWPN for FC) og fysisk separasjon etter array-porter. For iSCSI-modeller gjøres dette ved å lage et mål.
For FC-modeller skjer publisering gjennom opprettelse av en LUN for hver port i arrayet.
For å fremskynde oppsettprosessen kan verter kombineres i grupper. Dessuten, hvis verten bruker en multiport FC HBA (som i praksis oftest skjer), så bestemmer systemet automatisk at portene til en slik HBA tilhører en enkelt vert takket være WWPN-er som er forskjellige med én. Batch-oppretting av Target/LUN støttes også for begge grensesnittene.
En viktig merknad når du bruker iSCSI-grensesnittet er å lage flere mål for volumer samtidig for å øke ytelsen, siden køen på målet ikke kan endres og effektivt vil være en flaskehals.
Konfigurere ESXi Hosts
På ESXi-vertssiden utføres grunnleggende konfigurasjon i henhold til et fullstendig forventet scenario. Prosedyre for iSCSI-tilkobling:
- Add Software iSCSI Adapter (ikke nødvendig hvis den allerede er lagt til, eller hvis du bruker Hardware iSCSI Adapter);
- Opprette en vSwitch som iSCSI-trafikk vil passere gjennom, og legge til en fysisk oppkobling og VMkernel til den;
- Legge til array-adresser til Dynamic Discovery;
- Opprettelse av datalager
Noen viktige merknader:
- I det generelle tilfellet kan du selvfølgelig bruke en eksisterende vSwitch, men i tilfelle en separat vSwitch vil det være mye enklere å administrere vertsinnstillingene.
- Det er nødvendig å skille Management- og iSCSI-trafikk på separate fysiske lenker og/eller VLAN-er for å unngå ytelsesproblemer.
- IP-adressene til VMkernel og de tilsvarende portene til All Flash-matrisen må være innenfor samme subnett, igjen på grunn av ytelsesproblemer.
- For å sikre feiltoleranse i henhold til VMware-regler, må vSwitch ha minst to fysiske oppkoblinger
- Hvis Jumbo Frames brukes, må du endre MTU for både vSwitch og VMkernel
- Det ville være nyttig å minne deg på at i henhold til VMware-anbefalingene for fysiske adaptere som skal brukes til å jobbe med iSCSI-trafikk, er det nødvendig å konfigurere Teaming og Failover. Spesielt må hver VMkerne fungere gjennom bare én opplink, den andre opplinken må byttes til ubrukt modus. For feiltoleranse må du legge til to VMkerner, som hver vil fungere gjennom sin egen oppkobling.
VMkernel Adapter (vmk#)
Fysisk nettverksadapter (vmnic#)
vmk1 (Storage01)
Aktive adaptere
vmnic2
Ubrukte adaptere
vmnic3
vmk2 (Storage02)
Aktive adaptere
vmnic3
Ubrukte adaptere
vmnic2
Ingen foreløpige trinn er nødvendig for å koble til via Fibre Channel. Du kan umiddelbart opprette et datalager.
Etter å ha opprettet datalageret, må du sørge for at Round Robin-policyen for stier til Target/LUN brukes som den mest effektive.
Som standard sørger VMware-innstillingene for bruk av denne policyen i henhold til ordningen: 1000 forespørsler gjennom den første banen, de neste 1000 forespørslene gjennom den andre banen, etc. Slik interaksjon mellom verten og to-kontroller-arrayen vil være ubalansert. Derfor anbefaler vi å sette Round Robin-policyen = 1 parameter via Esxcli/PowerCLI.
Parametere
For Esxcli:
- Liste over tilgjengelige LUN-er
esxcli lagring nmp enhetsliste
- Kopier enhetsnavn
- Endre Round Robin Policy
esxcli lagring nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=“Device_ID”
De fleste moderne applikasjoner er designet for å utveksle store datapakker for å maksimere båndbreddeutnyttelsen og redusere CPU-belastningen. Derfor sender ESXi som standard I/O-forespørsler til lagringsenheten i biter på opptil 32767KB. For noen scenarier vil imidlertid utveksling av mindre biter være mer produktivt. For AccelStor-matriser er dette følgende scenarier:
- Den virtuelle maskinen bruker UEFI i stedet for Legacy BIOS
- Bruker vSphere Replication
For slike scenarier anbefales det å endre verdien for Disk.DiskMaxIOSize-parameteren til 4096.
For iSCSI-tilkoblinger anbefales det å endre innloggingstidsavbrudd-parameteren til 30 (standard 5) for å øke tilkoblingsstabiliteten og deaktivere DelayedAck-forsinkelsen for bekreftelser av videresendte pakker. Begge alternativene er i vSphere Client: Host → Konfigurer → Lagring → Lagringsadaptere → Avanserte alternativer for iSCSI-adapter
Et ganske subtilt poeng er antall volumer som brukes til datalageret. Det er klart at for å lette administrasjonen er det et ønske om å lage ett stort volum for hele volumet av matrisen. Tilstedeværelsen av flere volumer og følgelig datalager har imidlertid en gunstig effekt på den generelle ytelsen (mer om køer nedenfor). Derfor anbefaler vi å lage minst to bind.
Inntil relativt nylig anbefalte VMware å begrense antall virtuelle maskiner på én datalager, igjen for å oppnå høyest mulig ytelse. Men nå, spesielt med spredningen av VDI, er dette problemet ikke lenger så akutt. Men dette kansellerer ikke den langvarige regelen - å distribuere virtuelle maskiner som krever intensiv IO på tvers av forskjellige datalagre. For å bestemme det optimale antallet virtuelle maskiner per volum, er det ingenting bedre enn innenfor sin infrastruktur.
Sette opp virtuelle maskiner
Det er ingen spesielle krav når du setter opp virtuelle maskiner, eller rettere sagt er de ganske vanlige:
- Bruker høyest mulig VM-versjon (kompatibilitet)
- Det er mer forsiktig å stille inn RAM-størrelsen når du plasserer virtuelle maskiner tett, for eksempel i VDI (siden som standard, ved oppstart, opprettes en sidefil med en størrelse som samsvarer med RAM-en, som bruker nyttig kapasitet og har en effekt på den siste forestillingen)
- Bruk de mest produktive adapterversjonene når det gjelder IO: nettverkstype VMXNET 3 og SCSI type PVSCSI
- Bruk Thick Provision Eager Zeroed disktype for maksimal ytelse og Thin Provisioning for maksimal utnyttelse av lagringsplass
- Hvis mulig, begrens driften av ikke-I/O-kritiske maskiner ved å bruke Virtual Disk Limit
- Sørg for å installere VMware Tools
Merknader om køer
Kø (eller utestående I/O-er) er antallet input/output-forespørsler (SCSI-kommandoer) som venter på behandling til enhver tid for en bestemt enhet/applikasjon. I tilfelle køoverflyt utstedes QFULL-feil, som til slutt resulterer i en økning i latensparameteren. Når du bruker disk (spindel) lagringssystemer, teoretisk sett, jo høyere køen er, jo høyere ytelse. Du bør imidlertid ikke misbruke det, siden det er lett å støte på QFULL. Når det gjelder All Flash-systemer, på den ene siden, er alt noe enklere: Tross alt har arrayet latenser som er størrelsesordener lavere, og derfor er det oftest ikke nødvendig å separat regulere størrelsen på køene. Men på den annen side, i noen bruksscenarier (sterk skjevhet i IO-krav for spesifikke virtuelle maskiner, tester for maksimal ytelse, etc.) er det nødvendig, om ikke å endre parametrene til køene, så i det minste å forstå hvilke indikatorer kan oppnås, og det viktigste er på hvilke måter.
På selve AccelStor All Flash-arrayet er det ingen begrensninger i forhold til volumer eller I/O-porter. Om nødvendig kan til og med et enkelt volum motta alle ressursene i arrayet. Den eneste begrensningen på køen er for iSCSI-mål. Det er av denne grunn at behovet for å lage flere (ideelt sett opptil 8 stykker) mål for hvert volum ble indikert ovenfor for å overvinne denne grensen. La oss også gjenta at AccelStor-matriser er svært produktive løsninger. Derfor bør du bruke alle grensesnittportene i systemet for å oppnå maksimal hastighet.
På ESXi-vertsiden er situasjonen en helt annen. Verten bruker selv praksisen med lik tilgang til ressurser for alle deltakere. Derfor er det separate IO-køer for gjeste-OS og HBA. Køer til gjeste-operativsystemet kombineres fra køer til den virtuelle SCSI-adapteren og den virtuelle disken:
Køen til HBA avhenger av den spesifikke typen/leverandøren:
Den endelige ytelsen til den virtuelle maskinen vil bli bestemt av den laveste kødybdegrensen blant vertskomponentene.
Takket være disse verdiene kan vi evaluere ytelsesindikatorene som vi kan få i en bestemt konfigurasjon. For eksempel ønsker vi å vite den teoretiske ytelsen til en virtuell maskin (uten blokkbinding) med en latens på 0.5 ms. Da er IOPS = (1,000/latency) * Utestående I/O-er (grense for kødybde)
Примеры
Eksempel 1
- FC Emulex HBA-adapter
- Én VM per datalager
- VMware Paravirtual SCSI-adapter
Her bestemmes kødybdegrensen av Emulex HBA. Derfor IOPS = (1000/0.5)*32 = 64K
Eksempel 2
- VMware iSCSI programvareadapter
- Én VM per datalager
- VMware Paravirtual SCSI-adapter
Her er kødybdegrensen allerede bestemt av Paravirtual SCSI-adapteren. Derfor IOPS = (1000/0.5)*64 = 128K
Toppmodeller av alle Flash AccelStor-arrayer (f.eks. ) er i stand til å levere 700K IOPS skriveytelse ved 4K blokk. Med en slik blokkstørrelse er det ganske åpenbart at en enkelt virtuell maskin ikke er i stand til å laste en slik matrise. For å gjøre dette trenger du 11 (for eksempel 1) eller 6 (for eksempel 2) virtuelle maskiner.
Som et resultat, med riktig konfigurasjon av alle de beskrevne komponentene i et virtuelt datasenter, kan du få svært imponerende resultater når det gjelder ytelse.
4K tilfeldig, 70 % lesing/30 % skriving
Faktisk er den virkelige verden mye mer kompleks enn den kan beskrives med en enkel formel. Én vert er alltid vert for flere virtuelle maskiner med forskjellige konfigurasjoner og IO-krav. Og I/O-behandling håndteres av vertsprosessoren, hvis kraft ikke er uendelig. Så, for å frigjøre det fulle potensialet til det samme i virkeligheten trenger du tre verter. I tillegg gjør applikasjoner som kjører i virtuelle maskiner sine egne justeringer. Derfor tilbyr vi for nøyaktig dimensjonering Alle Flash-arrayer inne i kundens infrastruktur på reelle aktuelle oppgaver.
Kilde: www.habr.com