Review: Tintri’s Storage Quality of Service

Het garanderen van goede storage prestaties in een omgeving met honderden virtual machines vormde vanaf de introductie van servervirtualisatie al een groot probleem. Dit omdat traditionele storage arrays technologie gebruiken die stamt uit de tijd van vóór de virtualisatie. De daarbij toegepaste storage architectuur was altijd gebaseerd op een 1-op-1 relatie tussen server/applicatie/storage.

Een ander probleem is de toegenomen complexiteit en beheerbaarheid van een grootschalige virtuele omgeving. In de hedendaagse omgeving met duizenden Virtual Machines (VMs) is het performance- en beheerbaarheid probleem juist vanwege de pre-virtualisatie technologie alleen nog maar toegenomen. De vraag is welke oplossingen er voor handen zijn en welke storage oplossing(en) het meest geschikt zijn voor een virtuele omgeving? Om een juiste keuze te kunnen maken uit de diverse nieuwe storage oplossingen is het verstandig om kennis te nemen welke oorzaak ten grondslag ligt aan de storage problemen binnen de virtuele omgeving.

Het I/O-blender effect

Het bleek vanaf het begin dat bij de toepassing van serversystemen in een virtuele omgeving er bottleneck problemen in het IO-systeem ontstonden. Dit staat bekend als het I/O-blender effect en is het gevolg van de wijze waarop hypervisors bij virtuele platformen opereren. Het I/O-blender effect kwam al eerder aan het licht bij servervirtualisatie waarbij nog slechts een tiental VMs door de hypervisor werden gemultiplext. Echter, met de komst van desktop virtualisatie waarbij vele honderden, zo niet duizenden, virtuele desktops op meerdere servers kunnen draaien, nam dit verschijnsel exponentieel toe; voornamelijk bij gemixte workloads waarbij databases een heel ander I/O profiel (en block size) hebben dan VDI, Exchange, SAP of Sharepoint.

Naast de traditionele VMs, werd dus ook de virtuele desktop omgeving geconfronteerd met een slechte I/O performance. Belangrijke oorzaken zijn onder meer het random karakter van VMs met zijn sterk wisselende read/write werkbelastingen, optredende boot storms en antivirus scans. Ernstige ‘storage contention’ is daarvan het gevolg omdat de talrijke virtuele systemen voor hun IOPs vanuit een en dezelfde storage pool moeten gaan meedingen. Het aantal beschikbare IOPS per virtueel systeem neemt dan af en daardoor ook de response time tussen het operating- en het storage systeem. Voor sommige applicaties en virtuele systemen vormen de verminderde IOPs geen probleem maar voor andere veel eisende applicaties wel. Helaas bieden de traditionele storage systemen met hun LUN/Volume-gebaseerde indeling van de storage capaciteit geen methode om onderscheid te kunnen maken tussen de diverse virtuele systemen en de toebedeling van IOPs aan VMs.

Sommige nieuwe type storage controllers bieden wel de mogelijkheid om een bepaald percentage van de cpu controller aan een volume of LUN toe te wijzen. Met de komst van flash-gebaseerde storage arrays en met behulp van storage tiering software kunnen nu ook VMs, automatisch of handmatig, naar de verschillende LUN-gebaseerde storage lagen (flash, fixed disks en tape) worden gemigreerd. Op die manier is het storage systeem in staat om specifieke VMs van de benodigde hoeveelheid IOPs te voorzien.

Het fundamentele probleem met storage-gebaseerde QoS, of dat nu all-flash, hybride of traditionele storage arrays zijn, is dat ze nog steeds een vaste controller architectuur nodig hebben voor het beheer en priorisatie van de inbound read/write I/O requests die afkomstig zijn van meerdere VMs.

Storage QoS, meestal uitgedrukt in gegarandeerde IOPs, zorgt er voor dat applicaties altijd over een bepaald aantal IOPs de beschikking kunnen hebben. De verschillende type storage media bieden echter een ‘schijn’ Quality of Service (QoS) op basis waarvan Service Level Agreements (SLAs) worden gedefinieerd die in de praktijk vaak niet kunnen worden nagekomen. Dit komt hoofdzakelijk doordat QoS op LUN/Volume niveau worden toegepast. Dat biedt nog steeds geen garantie dat elke VM binnen de LUN/Volume ook daadwerkelijk de IOPS krijgt die gewenst zijn voor het halen van een optimale performance. Fundamenteel zijn het allemaal ‘bottom up’ benaderingen bij de ondersteuning van QoS. Met andere woorden, ze priorisen de storage I/O nádat ze door de host of VM zijn ontvangen. Wat nodig is, is een end-to-end technologie waarbij de storage I/O-eisen op de host of op VM-niveau kunnen worden geregeld. Sommige leveranciers zijn de mening toegedaan dat storage QoS op VM-niveau beter kan worden geïntegreerd via de host of de hypervisor. De firma Tintri daarentegen heeft een storage architectuur ontworpen waarbij dit op de storage controller op basis van virtuele disks, in plaats van op LUN/Volume-niveau, wordt geregeld.

Tintri All-Flash en Hybrid-Flash Array

We zien op welke wijze met de T880 Hybrid Flash array de gewenste QoS is te configureren en of deze QoS bij een zware belasting kan worden gegarandeerd. In onze proefopstelling draaiden we op de Tintri T880 een tiental VMs onder VMware vCenter, waaronder: Windows 2008/2012, CentOS, XenDesktop, VMware Virtual Center, Composer, Connection en Windows 7/8.

Architectuur Tintri Array

Het op Linux gebaseerde Tintri Operating System ondersteunt talrijke storage features, waaronder: replicatie, encryptie en synchronisatie. De storage array bezit twee controllers (active-standby) ter ondersteuning van failover. Elke controller bezit twee 10 GbE (RJ-45) poorten voor datatransport en twee 1GbE voor replicatie. De ondersteunde hypervisors zijn: VMware vSphere 5.x en 6.x (NFS), Red Hat Enterprise Virtualization 3.4 (NFS), Microsoft Hyper-V 2012 (SMB3), XenServer 6.5 (NFS) en OpenStack 2014 2.x (Juno) en desktopvirtualisatie voor VMware Horizon en Citrix Desktop.

Tintri Analytics

Tintri Analytics is een SaaS voorziening, gebouwd op basis van Tintri’s VM-aware storage (VAS). Het voorspelt de storage- en prestatie behoeften op basis van historische data van gevirtualiseerde applicaties. Het maakt gebruik van big data technologieën als Apache Stark en Elastic Search om grote hoeveelheden data, afkomstig van maximaal 160,000 VMs, binnen een seconde te verwerken. Op basis daarvan zijn exact de capaciteit, prestaties en doorvoer te voorspellen. Maximaal drie jaar aan historische data kan per VMstore worden bewaard. Hiermee kunnen what-If scenario’s worden uitgevoerd waarbij men op basis van real life workloads allerlei groeiscenario’s op basis van bestaande VMstores kunnen worden gemodelleerd.

Het Tintri Global Center (TGC) menu laat de drie kern prestatiemeetwaarden zien van alle actieve VMs: IOPs, Throughput en Latency. Het laat het percentage IO zien uit flash van maximaal 32 VMstores. Van elke VM is de tijd ze zien die een VM er over doet om een data request van het storage systeem af te handelen. Daarnaast laat TGC ook de hoeveelheid performance zien die er nog beschikbaar is op basis van IOPS/Throughput van de totale hoeveelheid VMstores.

• Figuur 1: VMstore User Interface
• Figuur 2: Tintri Global Center menu

Tintri Quality of Service

Het doel van elke QoS voorziening is de verzekering dat een bepaalde VM of applicatie toegang krijgt tot bepaalde resources, onafhankelijk of andere VMs die daar ook een beroep op doen. QoS is beschikbaar op basis van cpu, netwerkbandbreedte en storage performance.

IOPs betekent echter voor de verschillende operating systems wat anders. Het aantal IOPs is mede afhankelijk van de block-grootte van het gebruikte file system. Binnen TGC worden IOPs genormaliseerd tot 8KB per IO. Bij niet genormaliseerde IOPs kunnen VM resources verschillende block-groottes voor reads en writes hebben waardoor het onmogelijk wordt om een objectieve vergelijking te maken tussen de prestaties van VMs. Bovendien bieden genormaliseerde IOPs een accurate en voorspelbare methode voor chargeback-gebaseerde resources in een gevirtualiseerde data center.

Met Tintri VMstores zijn, in plaats van op LUN niveau, op VM-niveau QoS en SLAs te definiëren. Met Tintri Storage QoS, uitgedrukt in IOPs, kunnen zowel een minimum als maximum waarde worden ingesteld. Beheerders kunnen daarmee effectief hun VM bronnen voor een bepaald serviceniveau en chargeback definiëren. Met de TGC management software is de complete storage omgeving, variërend in grootte van 17 TB tot meer dan 10 PB, te beheren. Daarbij kunnen maximaal 32 VMstores in een enkele federated storage pool worden opgenomen. De storage management software biedt data protectie en QoS per Service Group (SG) van VMs. Deze SG-gebaseerde policies worden voor zowel data protectie als QoS per VM aan een VM gekoppeld. Bij verplaatsing van een VM naar een andere VMstore verhuizen de SG policies dan gewoon mee.

Minimum en Maximum IOPs instelling

De default QoS policies voldoen voor het merendeel van de applicaties. Maar voor bepaalde kritische applicaties kan het nodig zijn om de maximum- en minimum QoS instellingen aan te passen om bepaalde SLAs te kunnen garanderen. De maximale instelling specificeert de maximaal genormaliseerde IOPs die een VM mag halen. Om een aantal redenen kan de maximale instelling worden aangepast, bijvoorbeeld VMs die meer IOPs vragen dan dat ze in feite nodig hebben. Let wel, de maximum waarde kent een limiet want bij een te hoge waarde kunnen VMs hiervan extra throttle latency ervaren; bijvoorbeeld wanneer de VM gelimiteerd is tot 1000 IOPs maar de VM eigenlijk 1500 IOPs wil. De minimum instelling specificeert het deel van de VMs resources bij een overbelast systeem. Deze instelling biedt een extra garantie bij overbelasting van het systeem en ook de garantie dat de betreffende VM de minimaal benodigde QoS krijgt.

Het aantal VMs met een minimum IOPs instelling moet wel in overeenstemming zijn met het aantal ondersteunde genormaliseerde IOPs van elk type Tintri model. Minimale QoS zal in de praktijk alleen relevant zijn voor een kleine hoeveelheid VM’s. Dynamisch zorgt Tintri’s filesysteem ervoor dat elke VM de hoeveelheid resources krijgt wanneer ze nodig zijn.

Figuur 3: Maximum en Minimum QoS instelling

Epiloog

Tintri’s VMstore storage arrays, VMstores genaamd, vormen de nieuwe generatie storage systemen die speciaal ontwikkeld zijn voor toepassing in virtuele omgevingen. De directe verbinding tussen de VM en een virtuele disk op het Tintri storage systeem, in plaats van een LUN, voorkomt de bekende I/O-blender. De fijnmazige regeling van het gewenste aantal IOPs per VM biedt een garantie dat de vereiste SLA in de praktijk kan worden waargemaakt. Daarnaast ondersteunt VMstore de gebruikelijke storage features als synchronisatie, replicatie, encryptie, space reduction en een snelle VM cloning op een per VM basis.

Tintri Scale-Out

Tintri’s VAS biedt een storage scale-out mogelijkheid voor de uitbreiding van een enkele 17 TeraByte all-flash VMstore array tot meerdere arrays die maximaal 10 PB storage capaciteit bieden en ondersteuning van 160,000 VMs. All-flash en hybride storage array’s kunnen beide in een gemeenschappelijke storage pool worden opgenomen. VAS is een loosely coupled ontwerp met een gescheiden control- en data flow wat garant staat voor low latency bij toepassing van een groot aantal storage nodes. Op basis van een dertig dagen historie geeft een ingebouwd intelligent monitoring systeem adviezen over de groei en optimale plaatsing van elke VM.

LUNs versus virtuele disken

Traditionele LUN-gebaseerde (Logical Unit Number) storage arrays zijn destijds niet ontworpen voor virtuele toepassingen. In de traditionele storage omgeving heeft elke applicatie of database zijn eigen LUN van een bepaald type RAID (op basis van snelheid, betrouwbaarheid en kosten). Zo zal bijvoorbeeld een Oracle database zijn geconfigureerd met RAID 5 voor data- en temp-bestanden, redo files met RAID1 en een SQL server met VMs zal weer van RAID 10 gebruik maken. Naarmate de gevirtualiseerd omgeving in omvang groeit, zal het vinden van de gewenste type LUN met een bepaalde type RAID voor elke verschillende applicatie en database steeds lastiger worden. Het bijhouden van welk type VM op welke LUN en de voortdurende overweging welke RAID type, de gewenste responste tijd en lage latency, maken het beheer tijdrovend; de zogenaamde ‘spreadsheet hell’ ontstaat in het bijhouden van alle veranderingen.

Elke LUN heeft één I/O queue naar de controller waarbij de I/O op basis van FIFO (First In First Out) wordt afgehandeld. Door meerdere workloads op een LUN te installeren zal bij een hogere controller belasting de I/O queue eerder vollopen. Gevoelige workloads hebben dan niet genoeg tijd voor de afhandeling waardoor op die VM’s een hogere storage latency waar te nemen is.

Bij de op traditionele LUNs geïnstalleerde VMs krijgt elke VM resource dezelfde LUN en dus dezelfde storage QoS; VMs met dezelfde QoS-eisen kunnen natuurlijk wel in één LUN worden opgenomen. Maar bij een toenemend aantal VMs zullen de prestaties afnemen omdat QoS op LUN-niveau is bepaald en niet op VM-niveau. Tintri verdeelt, ongeacht de toegepaste hypervisor, de VMs op virtueel disk niveau. Dat biedt de garantie dat voor elke VM de gewenste storage QoS kan worden gehaald.

Figuur 4: Storage I/O-blender

Latency

Latency bestaat uit host-, netwerk- en storage latency. Host latency is de tijd die een VM IO op de hypervisor host spendeert, netwerk latency de tijd van VMs IO op het netwerk. Storage latency is de tijd die een VMs IO op de Tintri VMstore besteed. Die kan nog verder worden opgesplitst in contention, flash en disk latency. Contention latency ontstaat wanneer een gebruiker systeemprestaties overvraagt (overprovisioning). Een manier om dit te voorkomen is de minimale genormaliseerde IOPs voor de betreffende VM te verhogen. Flash latency is de vertraging die VMs ondervinden bij read/write IOs op de VMstore. Disk latency bij Hybrid array’s ontstaat bij een flash miss. Die treedt op wanneer data niet meer in flash aanwezig is en vanaf een hard disk moet worden opgehaald. De instelling van een maximum IOPs voegt latency toe en vertraagd een VM.

Figuur 5: End-to-end latency per VM

Bram Dons, IT-Trendwatch