I den här artikeln skulle jag vilja prata om funktionerna i Alla Flash AccelStor-arrayer som arbetar med en av de mest populära virtualiseringsplattformarna - VMware vSphere. Fokusera särskilt på de parametrar som hjälper dig att få maximal effekt av att använda ett så kraftfullt verktyg som All Flash.
AccelStor NeoSapphire™ Alla Flash-arrayer är eller nodenheter baserade på SSD-enheter med ett fundamentalt annorlunda tillvägagångssätt för att implementera konceptet med datalagring och organisera åtkomst till det med hjälp av proprietär teknologi istället för de mycket populära RAID-algoritmerna. Arrayerna ger blockåtkomst till värdar via Fibre Channel- eller iSCSI-gränssnitt. För att vara rättvis noterar vi att modeller med ett ISCSI-gränssnitt också har filåtkomst som en trevlig bonus. Men i den här artikeln kommer vi att fokusera på användningen av blockprotokoll som det mest produktiva för All Flash.
Hela processen för distribution och efterföljande konfiguration av gemensam drift av AccelStor-arrayen och VMware vSphere-virtualiseringssystemet kan delas in i flera steg:
- Implementering av anslutningstopologi och konfiguration av SAN-nätverk;
- Ställa in All Flash-array;
- Konfigurera ESXi-värdar;
- Konfigurera virtuella maskiner.
AccelStor NeoSapphire™ Fibre Channel-matriser och iSCSI-arrayer användes som exempel på hårdvara. Basprogramvaran är VMware vSphere 6.7U1.
Innan du distribuerar systemen som beskrivs i den här artikeln rekommenderar vi starkt att du läser dokumentationen från VMware angående prestandaproblem ( ) och iSCSI-inställningar ()
Anslutningstopologi och SAN-nätverkskonfiguration
Huvudkomponenterna i ett SAN-nätverk är HBA i ESXi-värdar, SAN-switchar och arraynoder. En typisk topologi för ett sådant nätverk skulle se ut så här:
Termen Switch syftar här på både en separat fysisk switch eller uppsättning switchar (Fabric), och en enhet som delas mellan olika tjänster (VSAN i fallet med Fibre Channel och VLAN i fallet med iSCSI). Användning av två oberoende switchar/tyger kommer att eliminera en möjlig felpunkt.
Direktanslutning av värdar till arrayen, även om den stöds, rekommenderas starkt inte. Prestandan för All Flash-arrayer är ganska hög. Och för maximal hastighet måste alla portar i arrayen användas. Därför är närvaron av minst en switch mellan värdarna och NeoSapphire™ obligatorisk.
Närvaron av två portar på värd-HBA är också ett obligatoriskt krav för att uppnå maximal prestanda och säkerställa feltolerans.
När du använder ett Fibre Channel-gränssnitt måste zonindelning konfigureras för att eliminera möjliga kollisioner mellan initiatorer och mål. Zoner är byggda på principen om "en initiatorport - en eller flera arrayportar."
Om du använder en anslutning via iSCSI när du använder en switch som delas med andra tjänster, är det absolut nödvändigt att isolera iSCSI-trafik inom ett separat VLAN. Det rekommenderas också starkt att aktivera stöd för Jumbo Frames (MTU = 9000) för att öka storleken på paket i nätverket och därigenom minska mängden overheadinformation under överföring. Det är dock värt att komma ihåg att för korrekt drift är det nödvändigt att ändra MTU-parametern på alla nätverkskomponenter längs kedjan "initiator-switch-target".
Konfigurera All Flash-array
Arrayen levereras till kunder med redan bildade grupper . Därför behöver inga åtgärder vidtas för att kombinera enheter till en enda struktur. Du behöver bara skapa volymer av önskad storlek och kvantitet.
För enkelhetens skull finns det funktionalitet för batchskapande av flera volymer av en given storlek samtidigt. Som standard skapas tunna volymer, eftersom detta möjliggör mer effektiv användning av tillgängligt lagringsutrymme (inklusive stöd för Space Reclamation). När det gäller prestanda överstiger inte skillnaden mellan "tunna" och "tjocka" volymer 1 %. Men om du vill "pressa ut all juice" ur en array kan du alltid konvertera vilken "tunn" volym som helst till en "tjock". Men man bör komma ihåg att en sådan operation är irreversibel.
Därefter återstår det att "publicera" de skapade volymerna och ställa in åtkomsträttigheter till dem från värdarna med hjälp av ACL:er (IP-adresser för iSCSI och WWPN för FC) och fysisk separation av arrayportar. För iSCSI-modeller görs detta genom att skapa ett mål.
För FC-modeller sker publicering genom att ett LUN skapas för varje port i arrayen.
För att påskynda installationsprocessen kan värdar kombineras i grupper. Dessutom, om värden använder en multiport FC HBA (vilket i praktiken oftast händer), så avgör systemet automatiskt att portarna på en sådan HBA tillhör en enda värd tack vare WWPN:er som skiljer sig åt med en. Batchskapande av Target/LUN stöds också för båda gränssnitten.
En viktig anmärkning när du använder iSCSI-gränssnittet är att skapa flera mål för volymer samtidigt för att öka prestandan, eftersom kön på målet inte kan ändras och i praktiken kommer att vara en flaskhals.
Konfigurera ESXi Hosts
På ESXi-värdsidan utförs grundläggande konfiguration enligt ett helt förväntat scenario. Procedur för iSCSI-anslutning:
- Lägg till programvara iSCSI-adapter (krävs inte om den redan har lagts till, eller om du använder hårdvara iSCSI-adapter);
- Skapa en vSwitch genom vilken iSCSI-trafik kommer att passera, och lägga till en fysisk upplänk och VMkernel till den;
- Lägga till matrisadresser till Dynamic Discovery;
- Skapande av datalager
Några viktiga anmärkningar:
- I det allmänna fallet kan du naturligtvis använda en befintlig vSwitch, men i fallet med en separat vSwitch blir det mycket lättare att hantera värdinställningarna.
- Det är nödvändigt att separera Management- och iSCSI-trafik på separata fysiska länkar och/eller VLAN för att undvika prestandaproblem.
- IP-adresserna för VMkernel och motsvarande portar i All Flash-arrayen måste finnas inom samma subnät, återigen på grund av prestandaproblem.
- För att säkerställa feltolerans enligt VMware-regler måste vSwitch ha minst två fysiska upplänkar
- Om Jumbo Frames används måste du ändra MTU för både vSwitch och VMkernel
- Det skulle vara användbart att påminna dig om att enligt VMwares rekommendationer för fysiska adaptrar som kommer att användas för att arbeta med iSCSI-trafik, är det nödvändigt att konfigurera Teaming och Failover. I synnerhet måste varje VMkernel fungera genom endast en upplänk, den andra upplänken måste växlas till oanvänt läge. För feltolerans måste du lägga till två VMkernel, som var och en fungerar via sin egen upplänk.
VMkernel Adapter (vmk#)
Fysisk nätverksadapter (vmnic#)
vmk1 (Storage01)
Aktiva adaptrar
vmnic2
Oanvända adaptrar
vmnic3
vmk2 (Storage02)
Aktiva adaptrar
vmnic3
Oanvända adaptrar
vmnic2
Inga preliminära steg krävs för att ansluta via Fibre Channel. Du kan omedelbart skapa en Datastore.
Efter att ha skapat dataarkivet måste du se till att Round Robin-policyn för sökvägar till Target/LUN används som den mest presterande.
Som standard tillhandahåller VMware-inställningarna användningen av denna policy enligt schemat: 1000 förfrågningar genom den första sökvägen, nästa 1000 förfrågningar genom den andra sökvägen, etc. Sådan växelverkan mellan värden och arrayen med två kontroller kommer att vara obalanserad. Därför rekommenderar vi att ställa in Round Robin-policyn = 1 parameter via Esxcli/PowerCLI.
Parametrar
För Esxcli:
- Lista tillgängliga LUN:er
esxcli lagring nmp enhetslista
- Kopiera enhetsnamn
- Ändra Round Robin Policy
esxcli lagring nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=“Device_ID”
De flesta moderna applikationer är designade för att utbyta stora datapaket för att maximera bandbreddsutnyttjandet och minska CPU-belastningen. Därför skickar ESXi som standard I/O-förfrågningar till lagringsenheten i bitar på upp till 32767KB. Men för vissa scenarier kommer utbyte av mindre bitar att vara mer produktivt. För AccelStor-matriser är dessa scenarier:
- Den virtuella maskinen använder UEFI istället för Legacy BIOS
- Använder vSphere Replication
För sådana scenarier rekommenderas det att ändra värdet på parametern Disk.DiskMaxIOSize till 4096.
För iSCSI-anslutningar rekommenderas det att ändra parametern Inloggning Timeout till 30 (standard 5) för att öka anslutningsstabiliteten och inaktivera DelayedAck-fördröjningen för bekräftelser av vidarebefordrade paket. Båda alternativen finns i vSphere Client: Host → Konfigurera → Lagring → Lagringsadaptrar → Avancerade alternativ för iSCSI-adapter
En ganska subtil punkt är antalet volymer som används för datalagret. Det är tydligt att för att underlätta hanteringen finns det en önskan att skapa en stor volym för hela arrayens volym. Men närvaron av flera volymer och följaktligen datalagring har en gynnsam effekt på den övergripande prestandan (mer om köer nedan). Därför rekommenderar vi att du skapar minst två volymer.
Tills relativt nyligen rekommenderade VMware att begränsa antalet virtuella maskiner på en databutik, igen för att få högsta möjliga prestanda. Men nu, särskilt med spridningen av VDI, är detta problem inte längre så akut. Men detta upphäver inte den långvariga regeln - att distribuera virtuella maskiner som kräver intensiv IO över olika databutiker. För att bestämma det optimala antalet virtuella maskiner per volym finns det inget bättre än inom sin infrastruktur.
Konfigurera virtuella maskiner
Det finns inga speciella krav när du ställer in virtuella maskiner, eller snarare är de ganska vanliga:
- Använder högsta möjliga VM-version (kompatibilitet)
- Det är mer noggrant att ställa in RAM-storleken när du placerar virtuella maskiner tätt, till exempel i VDI (eftersom som standard, vid uppstart, skapas en sidfil med en storlek som motsvarar RAM-minnet, vilket förbrukar användbar kapacitet och har en effekt på sista föreställningen)
- Använd de mest produktiva adapterversionerna när det gäller IO: nätverkstyp VMXNET 3 och SCSI typ PVSCSI
- Använd Thick Provision Eager Zeroed disktyp för maximal prestanda och Thin Provisioning för maximalt utnyttjande av lagringsutrymme
- Om möjligt, begränsa driften av icke-I/O-kritiska maskiner med Virtual Disk Limit
- Se till att installera VMware Tools
Anteckningar om köer
Kö (eller utestående I/O) är antalet in-/utgångsbegäranden (SCSI-kommandon) som väntar på bearbetning vid varje given tidpunkt för en specifik enhet/applikation. Vid köspill, utfärdas QFULL-fel, vilket i slutändan resulterar i en ökning av latensparametern. När du använder disk (spindel) lagringssystem, teoretiskt sett, ju högre kö, desto högre prestanda. Du bör dock inte missbruka det, eftersom det är lätt att stöta på QFULL. I fallet med Alla Flash-system, å ena sidan, är allt något enklare: trots allt har arrayen latenser som är storleksordningar lägre och därför finns det oftast inget behov av att separat reglera storleken på köerna. Men å andra sidan, i vissa användningsscenarier (stark skevhet i IO-krav för specifika virtuella maskiner, tester för maximal prestanda, etc.) är det nödvändigt, om inte att ändra parametrarna för köerna, så åtminstone att förstå vilka indikatorer kan uppnås, och det viktigaste är på vilka sätt.
På själva AccelStor All Flash-arrayen finns det inga begränsningar i förhållande till volymer eller I/O-portar. Om det behövs kan även en enda volym ta emot alla resurser i arrayen. Den enda begränsningen för kön är för iSCSI-mål. Det är av denna anledning som behovet av att skapa flera (helst upp till 8 stycken) mål för varje volym indikerades ovan för att övervinna denna gräns. Låt oss också upprepa att AccelStor-arrayer är mycket produktiva lösningar. Därför bör du använda alla gränssnittsportar i systemet för att uppnå maximal hastighet.
På ESXi-värdsidan är situationen en helt annan. Värden själv tillämpar praxis med lika tillgång till resurser för alla deltagare. Därför finns det separata IO-köer för gäst-OS och HBA. Köer till gästoperativsystemet kombineras från köer till den virtuella SCSI-adaptern och den virtuella disken:
Kön till HBA beror på den specifika typen/leverantören:
Den slutliga prestandan för den virtuella maskinen kommer att bestämmas av den lägsta ködjupsgränsen bland värdkomponenterna.
Tack vare dessa värden kan vi utvärdera de resultatindikatorer som vi kan få i en viss konfiguration. Till exempel vill vi veta den teoretiska prestandan för en virtuell maskin (utan blockbindning) med en latens på 0.5 ms. Då är dess IOPS = (1,000 XNUMX/latency) * Utestående I/O (gräns för ködjup)
Примеры
exempel 1
- FC Emulex HBA Adapter
- En virtuell dator per datalager
- VMware Paravirtual SCSI-adapter
Här bestäms ködjupsgränsen av Emulex HBA. Därför IOPS = (1000/0.5)*32 = 64K
exempel 2
- VMware iSCSI Software Adapter
- En virtuell dator per datalager
- VMware Paravirtual SCSI-adapter
Här bestäms ködjupsgränsen redan av Paravirtual SCSI-adaptern. Därför IOPS = (1000/0.5)*64 = 128K
Toppmodeller av alla Flash AccelStor-arrayer (t.ex. ) kan leverera 700K IOPS-skrivprestanda vid 4K-block. Med en sådan blockstorlek är det ganska uppenbart att en enda virtuell maskin inte kan ladda en sådan array. För att göra detta behöver du 11 (till exempel 1) eller 6 (till exempel 2) virtuella maskiner.
Som ett resultat, med korrekt konfiguration av alla beskrivna komponenter i ett virtuellt datacenter, kan du få mycket imponerande resultat när det gäller prestanda.
4K Random, 70% Läs/30% Skriv
Faktum är att den verkliga världen är mycket mer komplex än den kan beskrivas med en enkel formel. En värd är alltid värd för flera virtuella maskiner med olika konfigurationer och IO-krav. Och I/O-behandling hanteras av värdprocessorn, vars kraft inte är oändlig. Så, för att låsa upp den fulla potentialen av detsamma i verkligheten behöver du tre värdar. Dessutom gör applikationer som körs i virtuella maskiner sina egna justeringar. Därför erbjuder vi för exakta dimensioner Alla Flash-arrayer inne i kundens infrastruktur på verkliga aktuella uppgifter.
Källa: will.com