Grundlæggende elementer i Flash Virtualization Platform (FVP), del 2. Brug af din egen platform eller filsystem

Et af de emner, jeg diskuterede med Satyam og Murali Vilayannur, var filsystemet, der bruges til at gemme data på flashenheder. Følgende bemærkelsesværdige fakta skal huskes: Satyam oprettede VMFS3, Murali var den førende udvikler af VMFS5. Fra dette synspunkt synes brugen af ​​VMFS åbenlyst. Den store overraskelse for mig var imidlertid det faktum, at vi til flash-enheder ikke bruger VMFS, en endnu større overraskelse var, at vi overhovedet ikke bruger filsystemet.

Hvorfor ikke VMFS?
Filsystemer indeholder funktioner, der ikke er påkrævet, og nogle gange endda i konflikt med kravene på den platform, der behandler aktiv I / O på flashenheder. Et af de største problemer med at bruge et filsystem, der ligner VMFS på en flashenhed, er, at det er optimeret til SAN-lagringssystemer og deres datastyringsmodeller; Satyam skrev en artikel om dette til ACM, mens han arbejdede i VMware. Desværre gør dette filsystemet til et upassende værktøj til FVP-opgaver.

Filadministrationssystemer med direkte adresse overbelaster flashenheder, reducerer deres levetid, behandler ikke optimale vilkårlige I / O-operationer, tester deres (ofte meget skrøbelige) affaldsopsamlingsalgoritmer for styrke, og deres objekter (filer og mapper) er mindre velegnede til virtuelt maskiniveau og kvalitet af servicestyring, hvilket er ekstremt vigtigt for FVP-opgaver. I det næste afsnit beskrives problemet med administration af data på flashenheder, men for nu en kort konklusion: Hvis din flashenhed er dyr for dig, skal du ikke lægge et filsystem med direkte adressering på det.

Filsystemer leverer også muligheder, der i høj grad overstiger FVP's behov. For eksempel disklåse. VMFS har en avanceret distribueret låsemanager, der kontrollerer adgangen til forskellige ESXi-værter til diske. FVP administrerer de lokale diske for værten og kræver ikke låse på andre værter, som et resultat bliver den distribuerede låsemanager helt overflødig. Det samme kan siges om POSIX-kompatibilitet og distribuerede transaktioner. Og så videre.

Flash-operationer på lavt niveau
Her er et eksempel på, hvordan skrivning til flash-enheder grundlæggende er forskellig fra optagelser på harddiske. Flash kan ikke overskrive eksisterende data. Data i flashhukommelsen kan kun skrives på en tom side. En funktion af flashhukommelsen er, at optagelse kan udføres af sider, og sletning kan kun udføres i blokke. Hvad er en side, og hvad er en blok? Flash gemmer data i celler; celler kombineres til sider (4 KB); sider er grupperet i blokke. De fleste producenter kombinerer 128 sider i en blok. Hvis du vil slette siden, skal du slette hele blokken. Alle nødvendige data fra andre sider skal gemmes et andet sted. Det er almindeligt kendt, at flashenheder har et begrænset antal skrive- og sletecyklusser.

Følgelig kan en tilfældig I / O-skrivning have større indflydelse, end du troede. Problemet er, at de fleste filsystemer blev udviklet i 80'erne og 90'erne og ikke er sket siden dengang. Filsystemer tager ikke højde for den ydelsesnedbrydning, de forårsager for flashenheder ved hjælp af operationer på lavt niveau designet til harddiske; De fleste producenter af flashenheder implementerer forskellige mekanismer til at tage højde for gradvis nedbrydning af ydelsen. Ved hjælp af flere skemaer overvejer vi disse mekanismer og finder ud af, hvorfor fragmentering har en sådan effekt på flashenheder.

Slidstyring
Bemærk, for nemheds skyld besluttede jeg at vise 9 sider i en blok i stedet for 128 sider pr. Blok.

Lad os starte med slidstyringsprocessen. I dette eksempel har applikationen allerede oprettet dataene og registreret dem på side A, B og C i blok 1 (trin 1). Nye data ankommer (trin 2), som er skrevet til side D, E og F. Programmet opdaterer de forrige data (AC), og i stedet for at bruge de forrige sider fortsætter flashenheden med at bruge de nye sider. Disse nye data er mærket A-1, B-1 og C-1. Distribution af poster så jævnt som muligt kaldes "slidstyring." Gamle sider er nu markeret som udløbet.

Affaldsopsamling og flere indgange
I dette eksempel er blok A fuld, hvad sker der, hvis den plads, der er tilgængelig for brugeren til optagelse, er løbet tør og nye data ankommer?

Flash kopierer aktuelle data til tomme celler. Faktiske data i blokken læses og skrives til en anden blok. Forfaldne data forbliver på dets sider og slettes sammen med resten af ​​bloksiderne. Denne proces kaldes "indsamling af skrald."

Affaldsopsamling er fint, men den flere indtastning, der opstår under dens drift, forårsager betydelig skade på flashenheder. For at optage 3 sider skal flashenheden læse 6 sider og skrive de 6 sider til et andet sted, før den kan skrive nye data. Og glem ikke sletningscyklussen. Antag et scenarie, hvor disken er fuld, hvor skal vi (midlertidigt) flytte dataene, før vi registrerer nye data? I mit diagram tilføjede jeg blok B til denne mulighed. For at gøre dette i en reel situation (når du bruger filsystemet), skal du allokere overskydende plads reserveret af controllerblitz.

For at gøre dette i en reel situation (når du bruger filsystemet), skal du allokere overskydende plads reserveret af controllerblitz

Overskydende plads
Flash-kapacitet kan reserveres til processer, der administreres af en flash-controller. Dette kan gøres både af producenten af ​​flashenheden og af brugeren. For eksempel, når du køber en 160 GB flash PCIe-accelerator, får du faktisk et 192 GB-kort. 160 GB er tilgængelige for brugeren, og 32 GB er desuden reserveret til betjening på flashniveau-controller-niveau, f.eks. Indsamling af affald, fejlkorrektion og firmwarecontroller. Når du køber et ikke-industrielt SSD-drev, får du normalt lidt reserveret overskydende plads. Når du formaterer denne flashenhed i ethvert filsystem, skal du være opmærksom på disse funktioner og muligvis reservere ekstra plads uden for den tilgængelige kapacitet. Der er i øjeblikket ingen standardiserede skaleringsanbefalinger, så du er nødt til at træffe valg baseret på din egen oplevelse. I værste fald finder du dig selv med en fragmenteret disk, og SSD'en skal konstant overføre data for at skrive nye. Forestil dig børnene, der spiller etiketten, kun bevægelsesmønsteret er lidt mere kompliceret.

Genoverveje datahåndtering på flashenheder
PernixData-ingeniører har udviklet et nyt format til styring af data på flashenheder til FVP. Detaljer vil blive beskrevet i de følgende artikler og nu et par grundlæggende punkter.

Optimeret til flash
Formatet er designet til at gemme midlertidige I / O-data med det mindst mulige sæt metadata og arbejde med en flashenhed med den maksimale tilgængelige ydelse til det. Det konverterer tilfældige poster til fortløbende poster for at drage fordel af højere flash-ydeevne i sekventiel skrivetilstand. Dette reducerer antallet af overflødige dataoverskrivelser og sletningscyklusser. Og algoritmen indeholder ikke de arvelige begrænsninger af filsystemer, såsom store blokstørrelser, mapper, filer, lange transaktioner, låseadministratorer osv.

Dynamisk delt kapacitet mellem virtuelle maskiner
tak dyb integration Med VMkernel kan FVP spore datablokke og bestemme, om deres virtuelle maskine læser eller skriver. Uafhængigt sporing af sådanne operationer kan platformen skalere læse- og skrivebuffere i den plads, der er tildelt til den virtuelle maskine. FVP kan cache eller slette et vilkårligt sæt virtuelle maskindata fra cachen. I modsætning hertil vil dataevakueringspolitikken på det traditionelle filsystem for en flashenhed være suboptimal og resultere i flere omskrivninger, da filsystemet kan kun skrive data til slutningen af ​​filen eller slette blokke fra slutningen også.

Det betyder også, at du ikke behøver at tildele en statisk cache-pladskonfiguration til hver virtuel maskine, som det ville være, hvis du bruger et filsystem med direkte adressering. Det var en stor beslutning for os; brugeroplevelse fra produktet skal være så intuitivt som muligt.

Jeg citerer vores produktchef Bala: "Produktets elegance er efter min mening, at det udfører basale opgaver, IKKE kræver nye eller usædvanlige handlinger fra brugeren."

Hvad det daglige arbejde angår, er dette fremragende: du behøver ikke at forhåndsskala cachen til hver virtuel maskine. Dette betyder, at du ikke behøver at vide og forudsige den fremtidige brug af flash - FVP vil gøre alt for dig. Manglen på en allokering af hård ressource betyder manglen på underudnyttelse af flash ved ubelastede virtuelle maskiner og udseendet af overflødige blokrengøringscyklusser for aktive virtuelle maskiner med utilstrækkelig flashcache-størrelse. Dette minimerer problemet med flere optagelser og sikrer maksimal ydeevne og pålidelighed af flashenheder.

Original artikel .

Siden 2016 trak FVP sig fra salg.

Hvorfor ikke VMFS?
Hvad er en side, og hvad er en blok?
Antag et scenarie, hvor disken er fuld, hvor skal vi (midlertidigt) flytte dataene, før vi registrerer nye data?