Grundläggande element i Flash Virtualization Platform (FVP), del 2. Använd din egen plattform eller filsystem

Ett av ämnena jag diskuterade med Satyam och Murali Vilayannur var filsystemet som används för att lagra data på flashenheter. Följande anmärkningsvärda fakta bör komma ihåg: Satyam skapade VMFS3, Murali var den ledande utvecklaren av VMFS5. Ur denna synvinkel verkar användningen av VMFS uppenbar. Men den stora överraskningen för mig var det faktum att för flash-enheter vi inte använder VMFS, en ännu större överraskning var att vi inte använder filsystemet alls.

Varför inte VMFS?
Filsystem tillhandahåller funktioner som inte krävs och ibland till och med strider mot kraven på plattformen som bearbetar aktiv I / O på flashenheter. Ett av de största problemen med att använda ett filsystem som liknar VMFS på en flashenhet är att det är optimerat för SAN-lagringssystem och deras datahanteringsmodeller; Satyam skrev en artikel om detta för ACM när han arbetade i VMware. Tyvärr gör detta filsystemet till ett olämpligt verktyg för FVP-uppgifter.

Direktadressfilsystem överbelasta flash-enheter, minskar deras livslängd, bearbetar inte optimalt godtyckliga I / O-operationer, testar deras (ofta väldigt bräckliga) skräppassningsalgoritmer för styrka och deras objekt (filer och kataloger) är mindre lämpliga för virtuella maskinnivå och kvalitet på serviceledningen, vilket är oerhört viktigt för FVP-uppgifter. I nästa avsnitt beskrivs problemet med hantering av data på blixtenheter, men för tillfället en kort slutsats: Om din blixtenhet är dyr för dig, lägg inte ett filsystem med direkt adressering på den.

Filsystem tillhandahåller också funktioner som i hög grad överskrider FVP: s behov. Till exempel lås disk. VMFS har en avancerad distribuerad låshanterare som kontrollerar åtkomsten för olika ESXi-värdar till diskar. FVP hanterar värdens lokala skivor och kräver inte lås på andra värdar, som ett resultat blir den distribuerade låshanteraren helt överflödig. Detsamma kan sägas om POSIX-kompatibilitet och distribuerade transaktioner. Och så vidare.

Blixten på låg nivå
Här är ett exempel på hur skrivning till flashenheter skiljer sig i grunden från inspelningar på hårddiskar. Flash kan inte skriva över befintliga data. Data i flashminnet kan endast skrivas på en tom sida. En funktion i flashminnet är att inspelningen kan göras av sidor och radering kan bara göras i block. Vad är en sida och vad är ett block? Flash lagrar data i celler; celler kombineras till sidor (4 kB); sidor grupperas i block. De flesta tillverkare kombinerar 128 sidor i ett block. Om du vill radera sidan måste du radera hela blocket. All nödvändig data från andra sidor bör sparas någon annanstans. Det är allmänt känt att flashenheter har ett begränsat antal skriv- och raderingscykler.

Följaktligen kan en slumpmässig I / O-skrivning ha större inverkan än du trodde. Problemet är att de flesta filsystem utvecklades på 80- och 90-talet och har inte kommit framåt sedan dess. Filsystem tar inte hänsyn till den prestandadegradering som de orsakar för blixtanordningar som använder lågnivååtgärder utformade för hårddiskar; De flesta tillverkare av flashenheter implementerar olika mekanismer för att ta hänsyn till progressiv försämring av prestanda. Med hjälp av flera scheman överväger vi dessa mekanismer och tar reda på varför fragmentering har en sådan effekt på blixtanordningar.

Slitthantering
Observera att för enkelhetens skull bestämde jag mig för att visa 9 sidor i ett block istället för 128 sidor per block.

Låt oss börja med slitthanteringsprocessen. I det här exemplet har applikationen redan skapat data och registrerat dem på sidorna A, B och C i block 1 (steg 1). Ny data anländer (steg 2), som skrivs till sidorna D, E och F. Programmet uppdaterar tidigare data (AC) och istället för att använda de tidigare sidorna fortsätter flashenheten att använda de nya sidorna. Denna nya data är märkt A-1, B-1 och C-1. Att distribuera poster så jämnt som möjligt kallas "slitstyrning." Gamla sidor är nu markerade som löpt ut.

Avfallssamling och flera inlägg
I det här exemplet är block A fullt, vad händer om utrymmet som finns tillgängligt för användaren för inspelning har slut och ny data kommer in?

Flash kommer att kopiera aktuell information till tomma celler. Faktiska data i blocket läses och skrivs till ett annat block. Förfallen information kommer att finnas kvar på dess sidor och raderas tillsammans med resten av blocksidorna. Denna process kallas "soporinsamling."

Avfallsuppsamlingen är bra, men den flera posten som inträffar under dess drift orsakar betydande skador på blixtanordningarna. För att spela in 3 sidor måste flashenheten läsa 6 sidor och skriva de 6 sidorna till en annan plats innan den kan skriva ny data. Och glöm inte bort raderingscykeln. Anta att ett scenario där disken är full, var ska vi (tillfälligt) flytta data innan vi registrerar nya data? I mitt diagram har jag lagt till block B för det här alternativet. För att göra detta i en verklig situation (när du använder filsystemet) måste du tilldela överskott av utrymme reserverat av kontrollblixten.

För att göra detta i en verklig situation (när du använder filsystemet) måste du tilldela överskott av utrymme reserverat av kontrollblixten

Överskott av utrymme
Flash-kapacitet kan reserveras för processer som hanteras av en flash-controller. Detta kan göras både av tillverkaren av blixtenheten och av användaren. Till exempel när du köper en 160 GB flash PCIe-accelerator får du faktiskt ett 192 GB-kort. 160 GB är tillgängliga för användaren och 32 GB reserveras dessutom för blixtnivåstyrenhetsnivåoperationer, till exempel skräpuppsamling, felkorrigering och firmwarefix. När du köper en icke-industriell SSD-enhet får du vanligtvis lite reserverat överskott. När du formaterar denna flashenhet i något filsystem bör du vara medveten om dessa funktioner och eventuellt reservera ytterligare utrymme utanför den tillgängliga kapaciteten. Det finns för närvarande inga standardiserade skalningsrekommendationer, så du måste göra val baserat på din egen erfarenhet. I värsta fall kommer du att hitta dig själv med en fragmenterad disk och SSD måste ständigt överföra data för att skriva nya. Föreställ dig barnen som spelar tagg, bara rörelsemönstret är lite mer komplicerat.

Överväga datahantering på flashenheter
PernixData-ingenjörer har utvecklat ett nytt format för att hantera data på flashenheter för FVP. Detaljer kommer att avslöjas i följande artiklar, och nu några grundläggande punkter.

Optimerad för blixt
Formatet är utformat för att lagra tillfälliga I / O-data med minsta möjliga uppsättning metadata och arbeta med en blixtanordning med maximalt tillgängligt resultat för det. Den konverterar slumpmässiga poster till på varandra följande poster för att dra fördel av högre blixtprestanda i sekventiellt skrivläge. Detta minskar antalet redundanta dataöverskridanden och raderar cykler. Och algoritmen innehåller inte de ärvda begränsningarna för filsystem, såsom stora blockstorlekar, kataloger, filer, långa transaktioner, låshanterare, etc.

Dynamiskt delad kapacitet mellan virtuella maskiner
tack djup integration Med VMkernel kan FVP spåra datablock och bestämma om deras virtuella maskin läser eller skriver. Oberoende spårning av sådana operationer kan plattformen skala läs- och skrivbuffertar i utrymme som tilldelats för den virtuella maskinen. FVP kan cache eller ta bort en godtycklig uppsättning virtuella maskindata från cachen. Däremot kommer dataförändringspolicyn för det traditionella filsystemet för en blixtenhet att vara suboptimal och resultera i flera omskrivningar, eftersom filsystemet kan bara skriva data till slutet av filen eller ta bort block från slutet också.

Det betyder också att du inte behöver tilldela en statisk cacheutrymme för varje virtuell maskin, som det skulle vara om du använder ett filsystem med direkt adressering. Det var ett bra beslut för oss; användarupplevelsen från produkten ska vara så intuitiv som möjligt.

Jag citerar vår produktchef Bala: "Produktens elegans är enligt min åsikt att den utför grundläggande uppgifter, INTE kräver nya eller ovanliga åtgärder från användaren."

När det gäller det dagliga arbetet är detta utmärkt: du behöver inte förskala cachen för varje virtuell maskin. Detta betyder att du inte behöver veta och förutsäga den framtida användningen av blixt - FVP kommer att göra allt åt dig. Avsaknaden av en hård resursallokering innebär bristen på underutnyttjande av blixt av oladdade virtuella maskiner och uppkomsten av redundanta blockrengöringscykler för aktiva virtuella maskiner med otillräcklig flashcache-storlek. Detta minimerar problemet med flera inspelningar och garanterar maximal prestanda och tillförlitlighet för flashenheter.

Originalartikel .

Sedan 2016 drog FVP sig från försäljning.