Prestandaöverväganden för Azure VMware Solution-datalager för Azure NetApp Files

Artikel
03/25/2024

Den här artikeln innehåller prestandaöverväganden för azure VMware Solution-datalagerdesign och storleksändring när den används med Azure NetApp Files. Det här innehållet gäller för en virtualiseringsadministratör, molnarkitekt eller lagringsarkitekt.

De överväganden som beskrivs i den här artikeln hjälper dig att uppnå de högsta prestandanivåerna från dina program med optimerad kostnadseffektivitet.

Azure NetApp Files ger en omedelbart skalbar, högpresterande och mycket tillförlitlig lagringstjänst för Azure VMware Solution. Testerna innehöll olika konfigurationer mellan Azure VMware Solution och Azure NetApp Files. Testerna kunde köra över 10 500 MiB/s och över 585 000 in- och utdataåtgärder per sekund (IOPS) med endast fyra Azure VMware Solution/ESXi-värdar och en enda Azure NetApp Files-kapacitetspool.

Uppnå högre lagringsprestanda för Azure VMware Solution med hjälp av Azure NetApp Files

Etablering av flera, potentiellt större, datalager på en tjänstnivå kan kosta mindre samtidigt som prestandan ökar. Orsaken beror på fördelningen av belastningen över flera TCP-strömmar från Azure VMware Solution-värdar till flera datalager. Du kan använda Azure NetApp Files-datalager för Azure VMware Solution TCO Estimator för att beräkna potentiella kostnadsbesparingar genom att ladda upp en RVTools-rapport eller ange manuell genomsnittlig storlek på virtuella datorer.

När du bestämmer hur du konfigurerar datalager är den enklaste lösningen ur ett hanteringsperspektiv att skapa ett enda Azure NetApp Files-datalager, montera det och placera alla dina virtuella datorer i. Den här strategin fungerar bra i många situationer tills mer dataflöde eller IOPS krävs. För att identifiera de olika gränserna använde testerna en syntetisk arbetsbelastningsgenerator, programmet fio , för att utvärdera ett antal arbetsbelastningar för vart och ett av dessa scenarier. Den här analysen kan hjälpa dig att avgöra hur du etablerar Azure NetApp Files-volymer som datalager för att maximera prestanda och optimera kostnaderna.

Innan du börjar

Prestandadata för Azure NetApp Files finns i:

Azure NetApp Files: Få ut mesta möjliga av din molnlagring

På en Azure VMware Solution-värd upprättas en enda nätverksanslutning per NFS-datalager som liknar användning i nconnect=1 De Linux-tester som refereras i avsnitt 6 (Justeringsalternativen). Det här är viktigt för att förstå hur Azure VMware Solution skalar prestanda så bra över flera datalager.
Prestandamått för Azure NetApp Files-datalager för Azure VMware Solution

Testmetod

I det här avsnittet beskrivs den metod som används för testerna.

Testscenarier och iterationer

Den här testningen följer metoden "fyra hörn", som omfattar både läsåtgärder och skrivåtgärder för varje sekventiell och slumpmässig indata/utdata (I/O). Variablerna i testerna omfattar azure VMware Solution-värdar med en-till-många,Azure NetApp Files-datalager, virtuella datorer (per värd) och VMDK:er (VMDK:er) per virtuell dator. Följande skalningsdatapunkter har valts för att hitta maximalt dataflöde och IOPS för de angivna scenarierna:

Skala VMDK:er, var och en i sitt eget datalager för en enskild virtuell dator.
Skala antalet virtuella datorer per värd på ett enda Azure NetApp Files-datalager.
Skala antalet Azure VMware Solution-värdar, var och en med en virtuell dator som delar ett enda Azure NetApp Files-datalager.
Skala antalet Azure NetApp Files-datalager, var och en med en VMDK lika fördelad över Azure VMware Solution-värdar.

Genom att testa både små och stora blockåtgärder och iterera genom sekventiella och slumpmässiga arbetsbelastningar säkerställs testningen av alla komponenter i beräknings-, lagrings- och nätverksstackarna till "gränsen". För att täcka de fyra hörnen med blockstorlek och slumpmässighet används följande vanliga kombinationer:

Sekventiella tester på 64 KB
- Stora filströmningsarbetsbelastningar läser och skriver ofta i stora blockstorlekar, samt är standardstorleken för MSSQL-omfattningen.
- Stora blocktester ger vanligtvis det högsta dataflödet (i MiB/s).
8 KB slumpmässiga tester
- Den här inställningen är den vanliga blockstorleken för databasprogramvara, inklusive programvara från Microsoft, Oracle och PostgreSQL.
- Små blocktester ger vanligtvis det högsta antalet IOPS.

Kommentar

Den här artikeln behandlar endast testning av Azure NetApp Files. Den omfattar inte den vSAN-lagring som ingår i Azure VMware Solution.

Miljöinformation

Resultatet i den här artikeln uppnåddes med hjälp av följande miljökonfiguration:

Azure VMware Solution-värdar:
- Storlek: AV36
- Antal värdar: 4
- VMware ESXi version 7u3
Privat molnanslutning i Azure VMware Solution: UltraPerformance-gateway med FastPath
Virtuella gästdatorer:
- Operativsystem: Ubuntu 20.04
- Processorer/minne: 16 vCPU/64 GB minne
- Virtuell LSI SAS SCSI-styrenhet med 16 GB OS-disk på Azure VMware Solution vSAN-datalager
- Paravirtuell SCSI-styrenhet för test-VMDK:er
- LVM/Disk-konfigurationer:
  - En fysisk volym per disk
  - En volymgrupp per fysisk volym
  - En logisk partition per volymgrupp
  - Ett XFS-filsystem per logisk partition
Azure VMware Solution to Azure NetApp Files protocol: NFS version 3
Arbetsbelastningsgenerator: fio version 3.16
Fio-skript: fio-parser

Testresultat

I det här avsnittet beskrivs resultatet av de utförda testerna.

Skalning med en virtuell dator

När du konfigurerar datalager-presenterad lagring på en virtuell Azure VMware Solution-dator bör du överväga effekten av filsystemlayouten. Om du konfigurerar flera VMDK:er spridda över flera datalager får du högst tillgänglig bandbredd. Att konfigurera en-till-många-VMDK:er som placeras på ett enda datalager garanterar största enkelhet när det gäller säkerhetskopieringar och DR-åtgärder, men på bekostnad av ett lägre prestandatak. De empiriska data som tillhandahålls i den här artikeln hjälper dig med besluten.

För att maximera prestanda är det vanligt att skala en enskild virtuell dator över flera VMDK:er och placera dessa VMDK:er i flera datalager. En enskild virtuell dator med bara en eller två VMDK:er kan begränsas av ett NFS-datalager eftersom det monteras via en enda TCP-anslutning till en viss Azure VMware Solution-värd.

Tekniker etablerar till exempel ofta en VMDK för en databaslogg och etablerar sedan en-till-många-VMDK:er för databasfiler. Med flera VMDK:er finns det två alternativ. Det första alternativet är att använda varje VDMK som ett enskilt filsystem. Det andra alternativet är att använda ett verktyg för lagringshantering, till exempel LVM, MSSQL-filgrupper eller Oracle ASM för att balansera I/O genom att skala över VMDK:er. När VMDK:er används som enskilda filsystem är det en manuell ansträngning att distribuera arbetsbelastningar över flera datalager och kan vara besvärligt. Genom att använda verktyg för lagringshantering för att sprida filerna mellan VMDK:er kan du skala arbetsbelastningen.

Om du streckar volymer över flera diskar kontrollerar du att programvaran för säkerhetskopiering eller haveriberedskap stöder säkerhetskopiering av flera virtuella diskar samtidigt. Eftersom enskilda skrivningar är randiga över flera diskar måste filsystemet se till att diskarna "fryses" under ögonblicksbilder eller säkerhetskopieringsåtgärder. De flesta moderna filsystem innehåller en frysnings- eller ögonblicksbildsåtgärd som xfs (xfs_freeze) och NTFS (volymskuggkopior), som säkerhetskopieringsprogramvaran kan dra nytta av.

För att förstå hur väl en enskild virtuell Azure VMware Solution-dator skalar när fler virtuella diskar läggs till, utfördes tester med ett, två, fyra och åtta datalager (var och en innehåller en enda VMDK). Följande diagram visar en enskild disk i genomsnitt cirka 73 040 IOPS (skalning från 100 % skrivning/0 % läsning till 0 % skrivning/100 % läsning). När det här testet ökade till två enheter ökade prestandan med 75,8 % till 128 420 IOPS. Att öka till fyra enheter började visa minskande avkastning för vad en enskild virtuell dator, storleksanpassad som testad, kunde push-överföra. Den högsta IOPS som observerades var 147 000 IOPS med 100 % slumpmässiga läsningar.

Skalning med en värd – enskilt datalager

Den skalar dåligt för att öka antalet virtuella datorer som kör I/O till ett enda datalager från en enda värd. Detta beror på det enskilda nätverksflödet. När maximal prestanda uppnås för en viss arbetsbelastning är det ofta resultatet av en enda kö som används längs vägen till värdens enda NFS-datalager via en enda TCP-anslutning. Med en blockstorlek på 8 KB ökade den totala IOPS mellan 3 % och 16 % vid skalning från en virtuell dator med en enda VMDK till fyra virtuella datorer med totalt 16 VMDK:er (fyra per virtuell dator, alla i ett enda datalager).

Att öka blockstorleken (till 64 KB) för stora blockarbetsbelastningar hade jämförbara resultat och nådde en topp på 2 148 MiB/s (enskild virtuell dator, enskild VMDK) och 2 138 MiB/s (4 virtuella datorer, 16 VMDK:er).

Skalning med en värd – flera datalager

Från kontexten för en enda Azure VMware Solution-värd, medan ett enda datalager tillät de virtuella datorerna att köra cirka 76 000 IOPS, ökade arbetsbelastningarna över två datalager det totala dataflödet med 76 % i genomsnitt. Om du går längre än två datalager till fyra resulterade det i en ökning på 163 % (över ett datalager, en ökning med 49 % från två till fyra) enligt följande diagram. Även om det fortfarande fanns prestandavinster visade en ökning utöver åtta datalager minskande avkastning.

Skalning med flera värdar – enskilt datalager

Ett enda datalager från en enda värd producerade över 2 000 MiB/s sekventiellt dataflöde på 64 KB. När samma arbetsbelastning fördelas mellan alla fyra värdarna fick du en toppvinst på 135 % över 5 000 MiB/s. Det här resultatet representerar sannolikt det övre taket för en enda Azure NetApp Files-volymgenomflödesprestanda.

Att minska blockstorleken från 64 KB till 8 KB och köra samma iterationer på nytt resulterade i att fyra virtuella datorer producerade 195 000 IOPS, vilket visas i följande diagram. Prestandan skalas när både antalet värdar och antalet datalager ökar, eftersom antalet nätverksflöden ökar. Prestandan ökar genom att skala antalet värdar multiplicerat med antalet datalager, eftersom antalet nätverksflöden är en faktor för värdars tidsdatalager.

Skalning av flera värdar – flera datalager

Ett enda datalager med fyra virtuella datorer spridda över fyra värdar som produceras över 5 000 MiB/s sekventiell 64 KB I/O. För mer krävande arbetsbelastningar flyttas varje virtuell dator till ett dedikerat datalager, vilket ger över 10 500 MiB/s totalt, enligt följande diagram.

För små block, slumpmässiga arbetsbelastningar producerade ett enda datalager 195 000 slumpmässiga 8 KB IOPS. Skalning till fyra datalager som produceras över 530 000 slumpmässiga 8K IOPS.

Konsekvenser och rekommendationer

I det här avsnittet beskrivs varför spridning av dina virtuella datorer över flera datalager har betydande prestandafördelar.

Som du ser i testresultaten är prestandafunktionerna i Azure NetApp Files rikliga:

Testning visar att ett datalager kan köra i genomsnitt ~148 980 8 KB IOPS eller ~4 147 MiB/s med 64 KB IOPS (genomsnitt av alla skriv-%/läs%-tester) från en konfiguration med fyra värdar.
En virtuell dator på ett datalager –
- Om du har enskilda virtuella datorer som kan behöva mer än ~75 000 IOPS eller mer än ~1 700 MiB/s kan du sprida filsystemen över flera VMDK:er för att skala de virtuella datorernas lagringsprestanda.
En virtuell dator på flera datalager – en enskild virtuell dator i 8 datalager uppnådde upp till ~147 000 8 KB IOPS eller ~2 786 MiB/s med en blockstorlek på 64 KB.
En värd – Varje värd kunde stödja i genomsnitt ~198 060 8 KB IOPS eller ~2351 MiB/s om du använder minst 4 virtuella datorer per värd med minst 4 Azure NetApp Files-datalager. Så du har möjlighet att balansera etablering av tillräckligt många datalager för maximal, potentiellt bursting, prestanda jämfört med komplikation av hantering och kostnad.

Rekommendationer

När prestandafunktionerna i ett enda datalager är otillräckliga sprider du dina virtuella datorer över flera datalager för att skala ännu mer. Enkelhet är ofta bäst, men prestanda och skalbarhet kan motivera den tillagda men begränsade komplexiteten.

Fyra Azure NetApp Files-datalager ger upp till 10 Gbit/s användbar bandbredd för stor sekventiell I/O eller möjligheten att köra upp till 500 000 8K slumpmässig IOPS. Ett datalager kan vara tillräckligt för många prestandabehov, men för bästa prestanda börjar du med minst fyra datalager.

För detaljerad prestandajustering möjliggör både Windows- och Linux-gästoperativsystem striping över flera diskar. Därför bör du strecka filsystem över flera VMDK:er spridda över flera datalager. Men om konsekvens för programögonblicksbilder är ett problem och inte kan övervinnas med LVM eller lagringsutrymmen kan du överväga att montera Azure NetApp Files från gästoperativsystemet eller undersöka skalning på programnivå, där Azure har många bra alternativ.

Om du streckar volymer över flera diskar kontrollerar du att programvaran för säkerhetskopiering eller haveriberedskap stöder säkerhetskopiering av flera virtuella diskar samtidigt. Eftersom enskilda skrivningar är randiga över flera diskar måste filsystemet se till att diskarna "fryses" under ögonblicksbilden eller säkerhetskopieringsåtgärderna. De flesta moderna filsystem innehåller en frysnings- eller ögonblicksbildåtgärd som xfs (xfs_freeze) och NTFS (volymskuggkopior), som säkerhetskopieringsprogramvaran kan dra nytta av.

Eftersom Azure NetApp Files fakturerar för etablerad kapacitet i kapacitetspoolen i stället för allokerad kapacitet (datalager), betalar du till exempel samma för 4x20TB-datalager eller 20x4 TB-datalager. Om du behöver kan du justera kapacitet och prestanda för datalager på begäran dynamiskt via Azure API/-konsolen.

När du till exempel närmar dig slutet av ett räkenskapsår upptäcker du att du behöver mer lagringsprestanda på Standard-datalager. Du kan öka datalagertjänstnivån i en månad så att alla virtuella datorer på dessa datalager kan ha mer prestanda tillgängliga för dem, samtidigt som andra datalager bibehålls på en lägre servicenivå. Du sparar inte bara kostnader utan får mer prestanda genom att arbetsbelastningar sprids mellan fler TCP-anslutningar mellan varje datalager till varje AVS-värd.

Du kan övervaka dina datalagermått via vCenter Server eller via Azure API/Console. Från vCenter Server kan du övervaka ett datalagers aggregerade genomsnittliga IOPS i prestanda-/avancerade diagram , så länge du aktiverar insamling av lagrings-I/O-kontrollmått i datalagringen. Azure API och -konsolen innehåller mått för WriteIopsbland annat , ReadThroughputReadIops, och WriteThroughputför att mäta dina arbetsbelastningar på datalagernivå. Med Azure-mått kan du ange aviseringsregler med åtgärder för att automatiskt ändra storlek på ett datalager via en Azure-funktion, en webhook eller andra åtgärder.

Dela via