VMware har nyligen lagts till NVMe över tyg (NVMe-oF) som ett lagringsnätverksprotokollalternativ i vSphere 7.0. Det faktum att den snabbaste delade lagringslösningen nu kan användas av världens mest populära virtualiseringsprogram är en spelförändring, vilket öppnar en helt ny uppsättning användningsfall för ett virtualiserat datacenter. Detta betyder också att det nu finns bare-metal-applikationer som kan köras på NVMe-oF-aktiverade virtuella maskiner (VM) på vSphere. Dessa inkluderar artificiell intelligens (AI), maskininlärning (ML), minnesdatabaser, högpresterande beräkningar (HPC), högfrekvent handel (HFT), onlinetransaktionsbearbetning (OLTP) samt alla andra applikationer som kräver extremt låg latens och lagring med hög kapacitet.
VMware har nyligen lagts till NVMe över tyg (NVMe-oF) som ett lagringsnätverksprotokollalternativ i vSphere 7.0. Det faktum att den snabbaste delade lagringslösningen nu kan användas av världens mest populära virtualiseringsprogram är en spelförändring, vilket öppnar en helt ny uppsättning användningsfall för ett virtualiserat datacenter. Detta betyder också att det nu finns bare-metal-applikationer som kan köras på NVMe-oF-aktiverade virtuella maskiner (VM) på vSphere. Dessa inkluderar artificiell intelligens (AI), maskininlärning (ML), minnesdatabaser, högpresterande beräkningar (HPC), högfrekvent handel (HFT), onlinetransaktionsbearbetning (OLTP) samt alla andra applikationer som kräver extremt låg latens och lagring med hög kapacitet.
På StorageReview.com är vi alltid intresserade av att testa den senaste tekniken för att se hur de fungerar i den verkliga världen. Med tanke på vår tidigare erfarenhet av NVMe-oF förväntar vi oss att det kommer att avsevärt förbättra applikationsprestanda för vSphere. För att få en faktisk uppfattning om hur NVMe-oF kommer att påverka prestandan kommer vi att jämföra det med iSCSI, som är den nuvarande standardbäraren för blocklagring i ett vSphere-datacenter. Men våra tester kommer att ha en unik twist, eftersom vi inte kommer att använda högspecialiserad nischteknik. Istället kommer vi att använda produkter som är vanliga i datacentret idag. Våra tester kommer att ske på en Dell R720XD-server ansluten med NVIDIAs ConnectX-5-adaptrar med dubbla portar som körs på 25 GbE till en Pure Storage FlashArray//X som stöder NVMe-oF.
Innan vi kommer till resultaten av våra tester kommer vi först att ge dig en översikt över vad VMware stöder i NVMe-oF-väg, och sedan ge dig lite bakgrund om NVMe och NVMe-oF och förklara varför de är mer presterande än iSCSI. Vi kommer också att täcka några av stegen vi tog för att konfigurera NVMe på vSphere.
VMware aktiverade nyligen NVMe-oF-stöd (april 2020), även om NVMe-oF-standarden släpptes 2016. Linux har kunnat använda den sedan 2018, och NVMe-oF-stöd i lagringsarrayer har också varit tillgängligt i några år . NVMe-oF anses vara en framväxande, men ändå stabil teknologi. I april 2020 släppte VMware vSphere 7.0 och denna utgåva inkluderade stöd för NVMe-oF, vilket möjliggör anslutning till NVMe-arrayer med antingen NVMe over Fibre Channel (NVMe/FC) eller NVMe over RDMA Converged Ethernet (NVMe-RoCE, även kallad NVMe/RDMA).
Översikt över NVMe och NVMe-oF
Tills nyligen var SSD-enheter de facto standardmedia för ansluten lagring. Men de har också en kritisk flaskhals. SSD-enheter använder SATA- eller SAS-kontakter, som designades för att användas med hårddiskar och detta begränsar kraftigt en SSD:s prestanda. För att lösa detta problem slogs ett konsortium av över 90 företag samman 2011 och släppte en ny specifikation för att ansluta SSD:er till datorer som inte skulle ha denna SATA-flaskhals. Denna lösning blev så småningom känd som NVMe.
NVMe-enheter är snabba. Medan SATA/SAS SSD:er radikalt förändrade lagringsindustrin förra decenniet, förändrar NVMe lagringsindustrin radikalt detta århundrade. Till exempel, i våra senaste tester med en 4K Read-arbetsbelastning, fann vi att en SATA-enhet (Kingston DC500M) kunde leverera strax under 80,000 1000 IOPS, men en NVMe-enhet (Kingston DC580,000M) kunde leverera 7.25 XNUMX IOPS, en enorm skillnad på XNUMX gånger. Det finns många tekniska skäl att förklara varför NVMe är så mycket mer prestanda än SATA-enheter, men en av de viktigaste är att den har en kortare dataväg. Diagrammet nedan visar en förenklad illustration av hur datavägen är betydligt kortare för NVMe jämfört med senaste generationens lagring som SAS.
Dess prestandaförbättringar, tillsammans med den kraftiga prissänkningen, har gjort NVMe till det moderna datacentrets älskling.
Kort efter att NVMe-enheter blev allmänt använda i datacentret insåg folk att enheterna inte användes till sin fulla potential, och deras begränsning från att vara direktansluten lagring blev mer uppenbar. NVMe-enheter behövde kopplas bort från servern, därför gick en annan grupp företag samman och utvecklade en specifikation för hur man levererar NVMe över ett nätverk. När transportmekanismen för NVMe-lagring väl var tillgänglig kunde vi aggregera, abstrahera och dela NVMe-enheter i ett lagringssystem till många olika system, inklusive ESXi-värdar. NVMe-oF använder mål-/initiatorterminologi.
RoCE tillåter fjärrstyrd direktminnesåtkomst (RDMA) över ett Ethernet-nätverk. Det finns två versioner av RoCE: RoCE v1 och RoCE v2. Medan RoCE v1 tillåter kommunikation mellan två värdar i samma Ethernet-sändningsdomän (lager 2), körs RoCE v2 ovanpå TCP (lager 3) och är därför routbar, vilket gör att den kan ansluta till värdar utanför en Ethernet-sändningsdomän. På grund av dess inneboende fördelar och popularitet i datacentret, stöder VMware endast v2. Under hela den här artikeln kommer vi att referera till RoCE v2 som helt enkelt RoCE.
RoCE kräver RDMA-nätverksgränssnittskontroller (rNIC) istället för standard-NIC. RoCE-nätverk kräver vanligtvis konfigurering av Priority Flow Control, men Spectrum-switchar är optimerade för överbelastningskontroll när de används med ConnectX-adaptrar, vilket möjliggör nollkonfiguration. RoCE är mycket populärt och har ett blomstrande ekosystem som försörjer både rNICs och NVMe-oF-delsystem. Den används för närvarande av några av världens största hyperskala datacenter, och detta har drivit ned priset på rNICs avsevärt sedan de introducerades.
Genom att använda RDMA kan data överföras direkt till en värd från NVMe-oF-enheterna utan att behöva kopieras till minnesbuffertar, vilket skulle vara fallet om man använder en standard Transmission Control Protocol/Internet Protocol (TCP/IP) stack. Genom att kringgå buffertarna minskar RDMA CPU-användningen på värden och minskar latensen för att komma åt data på den fjärranslutna NVMe-enheten. Det finns många tekniska skäl till varför NVMe-oF är mer prestanda än senaste generationens nätverkslagringstekniker. Att notera är det enorma antalet eller köerna (64K) som NVMe-oF stöder, men det kanske mest talande är NVMe-oF-datavägen. Diagrammet nedan visar en förenklad illustration av hur datavägen är betydligt kortare för NVMe-oF jämfört med iSCSI-lagring.
RoCE använder UDP, vilket påverkar prestandan eftersom UDP kräver mindre omkostnader. Men RoCE förlitar sig på end-to-end-kompatibilitet för att ge fullständig förlustfri anslutning. Även om moderna nätverksväxlar stöder förlustfri anslutning, måste man se till att en äldre switch som inte stöder förlustfri anslutning inte är i nätverksvägen för NVMe-oF.
Resultatet av allt detta är att NVMe-oF möjliggör åtkomst till ett nätverks NVMe-enheter som om de vore lokala för åtkomstservern. Tidiga rapporter har visat att latensen för den poolade lagringen är cirka 100 μs, istället för 500 μs eller mer för en iSCSI all-flash-lagringsuppsättning.
NVMe-oF med vSphere
Kraven för NVMe-oF med vSphere är enkla:
- NVMe-array som stöder RDMA (RoCE)-transport
- Kompatibel ESXi-värd
- Ethernet-switchar som stöder ett förlustfritt nätverk
- Nätverksadapter som stöder RoCE
- Programvara NVMe över RDMA-adapter
- NVMe-kontroller
- Ett förlustfritt nätverk på både lager 2 och lager 3 eller förlustfritt nätverk med NVIDIAs ZTR (Zero Touch RoCE)-lösning
- Dedikerade länkar, VMkernels och RDMA-adaptrar till NVMe-mål
- Dedikerad lager 3 VLAN eller lager 2 anslutning
Eftersom NVMe-oF är nytt för VMware är inte alla vSphere-funktioner tillgängliga för det. Några funktioner som vi märkte saknades är stöd för delade VMDK, Raw Device Maps (RDM), vVols och möjligheten att starta från NVMe-oF.
Implementering av NVMe-oF
Vi använde NVIDIAs ConnectX-5 rNIC, ett av de vanligaste korten i datacentret. Dessa kort är RDMA-aktiverade nätverkskort med en eller två portar. De är tillgängliga för PCIe Gen 3.0- och Gen 4.0-servrar och ger stöd för 1, 10, 25, 40, 50 och 100 Gb. De har 750ns latens och kan skicka upp till 200 miljoner meddelanden per sekund. När de används med lagringsbelastningar stöder de ett brett utbud av accelerationstekniker.
För våra tester körde vi PCIe Gen 3.0 ConnectX-5-kort på 25 GbE i ett par Dell R720-servrar över ett nätverk anslutet via ett par av NVIDIAs Spectrum SN2010-switchar till Pure Storage-flasharrayen.
Vi verifierade först att vi körde drivrutinen nmlx5_core genom att ange esxcfg-nics -l |grep -E 'Namn|NVIDIA'.
Om vi körde nmlx4_core-drivrutinen kunde vi ha aktiverat RoCE för den från ESXi CLI.
Processen för att aktivera NVMe-oF (liknande den för att ställa in och aktivera iSCSI) involverade konfigurering av vSwitches, portgrupper och vmkernel-portar på ESXi-värdarna. Den stora skillnaden var att vi behövde lägga till minst två mjukvaru-NVMe över RDMA-adaptrar till varje ESXi-värd.
Det sista steget vi behövde slutföra var att identifiera NVMe Qualified Name (NQN) för ESXi-värden genom att ange esxcli nvme info get.
På Pure Storage-arrayen liknade det att sätta upp en iSCSI-array, med ett stort undantag. Vi behövde välja Konfigurera NQN.
Testresultat av NVMe-oF med vSphere
För detta test höll vi allt konstant med undantag för tyget. Det vi vill utvärdera är effekten av att gå från mer traditionell iSCSI till RoCE. För att vara tydlig, detta är inte en benchmarkingövning för lagring; detta är en undersökning för att titta på fördelarna med NVMe-oF i en VMware-miljö som kräver väldigt lite förändring. Vi använde två Dell EMC PowerEdge-servrar samt en Pure FlashArray//X R2 för lagringsbackend.
Vår testplan inkluderade att mäta den sammanlagda prestandan för 8 virtuella datorer (4 på varje ESXi-värd) och att använda vdBench för att mäta traditionella fyra hörn och blandade arbetsbelastningar. Varje virtuell dator förbrukade 64 GB lagringsutrymme, med ett totalt utrymme på 512 GB per arbetsbelastning tillgängligt för att jämföra prestandaförändringarna när protokollet ändrades.
För att tolka dessa resultat, observera att för genomströmning är en förbättring bättre, medan en minskning är bättre i latens.
I vår första arbetsbelastning som mätte 4K slumpmässig läsprestanda vid 80 % belastning, mätte vi en ökning av genomströmningen på 14.6 % och en minskning av läsfördröjningen med 21.4 %.
När vi sedan tittade på läsbandbredden i en 64K sekventiell läsarbetsbelastning såg vi en enorm ökning på 81.3 % i genomströmning, såväl som en 36.8 % minskning i latens – återigen vid 80 % belastning.
Medan de största uppmätta vinsterna fanns i de avlästa arbetsbelastningarna, tittade vi också på några vanliga blandade arbetsbelastningar, varav den första var SQL 90/10. I den här arbetsbelastningen mätte vi att latensen minskade med upp till 78.2 % vid 100 % belastning och en 43.4 % minskning i latens vid 80 % belastning.
Slutligen, i vår Oracle 90/10-arbetsbelastning, såg vi en 13.2 % minskning i latens vid 100 % belastning och en 35.7 % minskning i latens vid 80 % belastning.
I denna testning hade RoCE helt klart stora förbättringar över ett brett spektrum av arbetsbelastningar som är vanliga i företaget.
Slutsats
Våra tester visade att NVMe-oF i den verkliga världen är mer än bara ett koncept. NVMe-oF kan leverera enastående prestanda med hjälp av ditt datacenters nuvarande hårdvara, såsom servrar med Gen 3.0 PCI-platser, NVIDIAs ConnectX-5 NIC och en Pure Storage FlashArray//X R2 (Pure levererar nu //X R3 med ännu bättre prestanda förbättringar).
I våra tester såg vi betydande vinster i läsarbetsbelastningar för små och stora block. För att titta på verkliga effekter fokuserade vi på mindre än 100 % arbetsbelastningsmättnad, eftersom de flesta arbetsbelastningar inte helt mättar den underliggande lagringsplattformen. I vårt test som mätte slumpmässig läsprestanda i 4K sjönk latensen med 21.4 % vid en arbetsbelastning på 80 %. Sekventiell läsprestanda med en arbetsbelastning på 64K såg en enorm ökning på 81.3 % i genomströmning vid en belastning på 80 %. Vi såg också 43.4 % och 35.7 % minskningar i latens i våra SQL 90/10 respektive Oracle 90/10 arbetsbelastningar, återigen vid 80 % belastning. Dessa siffror indikerar att det finns en ytterligare möjlighet att överföra krävande bar-metal-arbetsbelastningar till VMware.
Vi är övertygade om att NVMe-oF kommer att bli nästa stora grej inom lagringsteknik, och vi förväntar oss att dess popularitet i datacentret snabbt kommer att öka. Vi kommer att ligga i framkant av denna kategori när den utvecklas under de närmaste åren, och ser fram emot att undersöka andra och närliggande NVMe-teknologier när de släpps.
För ytterligare information:
Den här rapporten är sponsrad av NVIDIA. Alla åsikter och åsikter som uttrycks i denna rapport är baserade på vår opartiska syn på produkten/de produkter som övervägs.
