Journalistiek

Onpartijdig, onafhankelijk nieuws, uitsluitend in dienst van het branchebelang.

Storage Stories: PernixData FVP

  • Door
  • dr. Serge Gielkens
  • geplaatst op
  • 9 februari 2016 08:00 uur

In de rubriek Storage Stories hebben we meerdere malen gezien dat caching-technieken gebruikt worden om de performance te verhogen. Deze caching kan zowel op de storage zelf aanwezig zijn als ook op de servers van de hypervisors. PernixData is in 2012 opgericht en richt zich volledig op de caching aan de serverkant. PernixData ontwikkelt alleen software en levert zelf geen hardware-oplossingen. Het product PernixData FVP is in essentie software defined cache. Niet alleen flash wordt gevirtualiseerd maar ook RAM-geheugen. Deze cache gebruikt PernixData om zowel reads als writes te versnellen.

Cache cluster

FVP werkt op basis van een cluster van servers. Van dit cluster wordt het lokale geheugen van elke host samengevoegd tot één enkele pool. Hoewel FVP zowel flash als RAM-geheugen kan clusteren, wordt per machine maar één type geheugen gebruikt. Als van een host het flashgeheugen aan het cluster wordt toegevoegd, kan niet ook nog eens diens RAM eraan toegevoegd worden. De enterprise editie van FVP staat wel toe dat binnen een cluster zowel hosts met RAM als hosts met flash participeren. In de praktijk is het echter verstandiger om het bij één type resource per cluster te houden. Voor migraties van het ene naar het andere type geheugen biedt de hybride oplossing natuurlijk wel uitkomst.

PernixData ondersteunt alle PCIe flash devices en SSD’s die in de VMware Compatibility Guide staan. FVP zorgt alleen voor versnelling van het lezen en schrijven van data en gebruikt voor de persistente opslag het storage array. Toegang hiertoe kan FVP uitvoeren op bestandsniveau via NFS. Op block niveau worden FC, FCoE en iSCSI ondersteund. Ook DAS (direct attached storage) is mogelijk.

FVP kan in zowel write-through als write-back modus werken. In write-through modus is er alleen sprake van read-versnelling. In write-back modus worden zowel read als write versneld. FVP bepaalt ook zelf aan de hand van het I/O profiel welke modus het meest geschikt is. Grote seriële doorvoer zoals een database dump bijvoorbeeld wordt in write-through modus afgehandeld omdat write-back modus in zo’n geval weinig tot geen performance verbetering biedt.

Als een host problemen ondervindt, mogen gebufferde writes natuurlijk niet verloren gaan. Om dataverlies te voorkomen schrijft FVP daarom kopieën van de cache data weg naar verschillende hosts in het cluster. Het maximaal aantal replica’s is twee. Door in FVP fault domains te definiëren, bepaalt de beheerder waar die moeten staan. Op deze manier kan hij bijvoorbeeld rack awareness inregelen.

VMware

PernixData FVP ondersteunt momenteel alleen de hypervisor van VMware. Minimaal versie 5 van vSphere is vereist. De core-functionaliteit wordt geïnstalleerd als een VMkernel module op de ESXi hosts. Voor de VM is FVP transparant waardoor geen aanpassingen in het vmx configuratiebestand nodig zijn. Om het cache cluster te beheren dient de FVP Management Server. Deze heeft een database op MS SQL Server nodig.

Per vSphere cluster kunnen meerdere FVP clusters gedefinieerd worden. Een VM kan echter maar deel uitmaken van één FVP cluster. Elke VM heeft wel toegang tot de volledige cache pool van zijn FVP cluster. Voor een VM maakt het dus niet uit op welke host in het cluster zijn cache staat. Daardoor werkt FVP probleemloos met zaken als vMotion, DRS en HA.

Als een VM middels vMotion naar een andere host wordt gemigreerd, kopieert FVP niet bij voorbaat de cache data van de oude naar de nieuwe host. Om onnodige I/O te voorkomen, blijft in eerste instantie de cache op de oude host staan. Bij data access controleert FVP of de cache lokaal staat. Is dat niet het geval, dan pas maakt FVP een kopie van de oude naar de nieuwe host. Door de integratie met vSphere is FVP op de hoogte van de host waar de VM stond voordat vMotion werd uitgevoerd.

Tot slot

PernixData verplaatst een deel van de I/O load van het storage array naar de host servers. De snelheidswinst zit hem deels in het gebruik van flash en RAM als cache en deels in het feit dat het I/O pad tussen VM en cache korter is geworden. In plaats van een upgrade of vervanging van het storage array kan dit een aantrekkelijk alternatief zijn om de performance te verhogen.

Nog geen reacties

Feedback!
Fill out my online form.
Laatste reacties

Bedankt voor het succes van ISPam.nl
Koen Stegeman, Editor-in-Chief & founder Hostingjournalist.com: Jammer Arnout, maar je hebt een mooie bijdrage aan de hosting industrie geleverd, en dat jaren lang....

Bedankt voor het succes van ISPam.nl
Dillard Blom: Jammer dat een 'instituut' verdwijnt, en daarmee een bron van informatie over actuele zaken (en opin...

Bedankt voor het succes van ISPam.nl
L.: Uit automatisme kijk ik toch nog steeds elke dag naar ispam.nl, toch de hoop dat er nog een berichtj...

Bedankt voor het succes van ISPam.nl
Toni Donkers: Arnout bedankt! ik ga het missen dat is een feit!

Bedankt voor het succes van ISPam.nl
Marcel Stegeman: Ik zie het nu pas. Inderdaad jammer maar ik kijk nu al uit naar het volgende project.