Test DOOR Bram Dons SSD s versnellen virtuele desktopomgevingen WhipTail zweept storage arrays op 30 Elektronische circuits en glasvezelnetwerken verwerken informatie met de snelheid van het licht. Het opslaan van die informatie, echter, gebeurt nog steeds op een mechanisch systeem: de magnetische schijf van de harddisk die afgelezen wordt door een bewegende schrijfkop. We moeten zo onderhand oppassen dat de snel draaiende platters niet door de geluidsbarrière heen knallen! Er is een alternatief nodig voor instantane dataopvraag. De XLR8r flitst ons in de hoogste versnelling naar het SSD-tijdperk. Hoewel er de laatste tijd een toenemende belangstelling is voor SAN s die gebruikmaken van solid-state drives (SSD s), verloopt de implementatie toch een stuk minder snel dan verwacht. De voornaamste reden hiervoor is de vermeende hoge prijsstelling van SSD s. Toch is de verwachting dat de traditionele harddiskstorage langzaam wordt uitgefaseerd in datacenteromgevingen waareen hoge I/O rate is vereist. De voordelen van een SSD-gebaseerd SAN zijn de afgelopen periode uitvoerig in allerlei media belicht (destijds al in Storage Magazine 3-2009). Toch sommen we ze hier nog even kort op. In vergelijking met de traditionele hard disk drives (HDD s), die zijn voorzien van een bewegende leeskop, hebben SSD s een lagere access latency, een hoger aantal input/output operations per second (IOPS), geen mechanisch slijtbare onderdelen, een lager stroomverbruik, schokbestendigheid, een lagere total cost of ownership (TCO) en een minder groot ruimtebeslag. SSD s worden vandaag de dag op een aantal manieren toegepast, bijvoorbeeld als toevoeging aan een bestaande HDD-gebaseerde storagearray, als standalone cachesysteem en als direct-attached storage voor servers. Door het toenemende verschil tussen de snelheden van de traditionele harddiskgebaseerde storagesystemen en die van de huidige generatie processoren XLR8r accelereert tot 250.000 IOPS zijn IT-beheerders genoodzaakt om hun bestaande HDD-gebaseerde storagearrays meer I/O s te bieden middels overprovisioning, wat natuurlijk een kostbare zaak is. De leveranciers kwamen met oplossingen om SSD s te implementeren binnen hun bestaande storagesystemen, meestal als optie, en om ze wel of niet op te nemen in een multitier storagemodel. De vraag is of dergelijke storagesystemen op termijn de IOPS kunnen leveren die nodig zijn om de grootschalige virtual desktop infrastructures (VDI s) van de toekomst te kunnen ondersteunen. SSD s in VDI s In virtuele omgevingen is de toegang tot de disks doorgaans overbelast. Dat komt omdat iedere gebruiker tegelijkertijd aanspraak maakt op dezelfde pool met resources. Dit is meestal geen probleem in een omgeving van gevirtualiseerde servers met een lage bezettingsgraad. Maar wanneer middelgrote en grote ondernemingen overgaan tot de virtualisatie van hun tier 1-applicaties, komen direct al de belangrijkste beperkingen van de huidige storagesystemen aan het licht. Veel systemen concurreren dan om dezelfde diskresources en dit kan problemen opleveren voor sequentiële werkbelastingen binnen een meer veeleisende random workload. Random I/O vormt de meest intense belasting voor een HDD. Bij virtualisatie krijgt elke VM echter slechts een timeslice toebedeeld van alle beschikbare resources, zoals CPU-tijd, geheugen, disk-i/o enzovoort.
Bereik de maximale writespeed op flash Figuur 1: WhipTails XLR8r (bron: Consolidate IT) Een actieve sequentiële filetransfer, zoals het ophalen van een groot ISO-image, kan daardoor om de zoveel milliseconden worden onderbroken door een andere file- of Exchangeserver. De read-write head moet dan worden verplaatst naar een andere track en dat kost tijd. Dit in tegenstelling tot een SSD, waarbij de toegang tot data in minder dan een milliseconde plaatsvindt en sequentiële en random seeks in essentie even lang duren. Ter vergelijking: op een HDD is de gemiddelde toegangstijd 6 à 9 milliseconden. Het maakt niet uit welk type VDI een onderneming gaat implementeren, de belangrijkste vraag is hoe de storage-infrastructuur deze gaat ondersteunen. Geleidelijk voltrekt zich een transitie naar VDI s en eindelijk accepteren gebruikers de virtuele desktop als een werkbare oplossing. VDI s worden in het datacenter echter nog maar mondjesmaat toegepast en staan daar nog in de kinderschoenen. Dit komt omdat de common tier 1-storage en de diskarrays daarin gebaseerd zijn op Fibre Channel HDD s, die ongeveer 200 IOPS per disk kunnen leveren. IOPS Een virtuele desktop vraagt ongeveer 20 tot 40 IOPS om goed te kunnen presteren. Dat betekent dat een virtuele omgeving met vijfduizend gebruikers ongeveer 250.000 IOPS vereist. Met een IOPS rate van ongeveer 200 IOPS per HDD zijn er dan 625 drives nodig om aan de vereiste prestaties te kunnen voldoen. Een interessante vraag is hoe softwareleveranciers straks omgaan met de licenties voor SSD-gebaseerde omgevingen, die nu nog meestal gebaseerd zijn op het aantal HDD s (zie ook het artikel over Storage Manager elders in dit nummer). VDI s hebben meer gemeen dan alleen virtualisatie. Alle vereisen ze een hoogpresterende storage-infrastructuur ter ondersteuning van een veeleisende computingarchitectuur. Zoals gezegd vraagt een virtuele desktop 20 tot 40 IOPS om op een voor de gebruiker acceptabel niveau te kunnen presteren. Meer dan 80 procent van deze IOPS bestaat uit kleine writes van 4 kb. De ondersteuning van VDI s vraagt op 31 Specificaties WhipTail XLR8r (Advertentie) Grootte: Capaciteit: IOPS: 2U 1,5, 3, 4,5, 6 of 12 TB 250.000 writes van 4 kb aan random data Latency: 0,1 milliseconde Bandbreedte: 1,9 GBps Interfaces: 2 1 gigabit-ethernet z2 10 gigabit-ethernet 2 40 Gbps InfiniBand 2 4 of 8 Gbps Fibre Channel RAID: 0, 5, 6 en 10 Stroomverbruik: <300 watt Redundante stroomtoevoer
Writebuffer flusht naar flash Figuur 2: Networkmenu 32 storagegebied dus voorzieningen voor deze random writes. De grote behoefte aan random I/O kan een probleem vormen voor de huidige multitiersystemen. De vraag is of er een storagearray bestaat die minimaal 250.000 IOPS kan leveren tegen een voordelige prijs per IOPS. De traditionele storageleveranciers bieden SSD s als optie voor de primaire tier in hun bestaande HDD-gebaseerde storagearrays. Meestal betaal je dan 35.000 dollar voor een drive die slechts 6.000 IOPS toevoegt aan de I/O-prestaties van het bestaande storagesysteem. Dat komt neer op ongeveer 6 dollar per IOPS. Het is dan ook niet zo vreemd dat de meeste gebruikers moeite hebben met een dergelijke investering. De firma Whip- Tail Tech denkt voor hen echter de juiste oplossing in huis hebben met zijn nieuwe Virtual Desktop XLR8r, een SSD-gebaseerde storagearray. XLR8r De Virtual Desktop XLR8r (spreek uit: accelerator ) is een flashgebaseerde 2U hoge storagearray. Hij bestaat niet uit een enkele SSD, maar uit een array met drives die met behulp van software gebundeld zijn tot een primaire storagedevice. RAID 0, 5, 6 en 10 worden ondersteund. De XLR8r levert 250.000 writes per seconde met een blockgrootte van 4 kb en een access latency van minder dan 0,1 milliseconde bij een bandbreedte van 1,9 Gbps. Het maakt in principe geen verschil of de werkbelasting sequentieel of random is. WhipTails proprietary softwarestack gebruikt voordelige flashchips met multilevel cells (MLC) als basis voor buffering en linearisatie. De XLR8r aggregeert alle writes in een buffer die speciaal is afgestemd op het onderliggende flashgeheugen. De buffer wordt naar de onderliggende storage geflusht wanneer de data de maximale ouderdom bereikt. Met deze bufferingtechnologie bereikt WhipTail de maximale writespeeds van de onderliggende flashchips. De XLR8r voert altijd forward writes uit over de gehele diskstructuur, waardoor dezelfde blocks nooit opnieuw worden aangesproken totdat de complete array vol zit. Dit verhoogt de prestaties en vermindert de slijtage van de flashchips. Een defragmentatieproces zorgt ervoor dat een minimumhoeveelheid aan vrije ruimte beschikbaar is voor versnelling. De storagearray is leverbaar met 1,5, 3, 6 en 12 TB. Er zijn verschillende interfaces beschikbaar: dual 1GbE, dual of quad 10GbE, quad 1GbE, dual InfiniBand van 40 Gbps en dual Fibre Channel van 4 of 8 Gbps. Er zijn ook diverse verbindingen beschikbaar op de backplane van de XLR8r om hem te laten aansluiten op de bestaande netwerkinfrastructuur; zo wordt 10GbE ondersteund met CX4- en SFP-interfaces. De stroomconsumptie is minder dan 300 watt. De kleinste unit is de WT1500, een Disktoegang raakt overbelast bij virtualisatie Datacenter XLR8r met 1,5 TB aan storage, bestaande uit twaalf keer 120 GB, en de standaard dual 1GbE-interface. De listprice daarvan is 35.000 euro Installatie De installatie van de XLR8r kan geschieden via de on-board 1GbE- of de seriële DB9- poort. De initiële configuratie van de interfaces is uit te voeren via de console of via de webinterface. De XLR8r wordt standaard verscheept met twee netwerkteams of bonds. Bond0 is samengesteld uit beide onboard 1GbE-interfaces, terwijl bond1 bestaat uit elke additionele Ethernetinterface. De console kan worden bereikt via een SSH client op de default subnets of via een straight-through Ethernetkabel. Is er eenmaal een consolesessie opgezet, dan kan de IP-configuratie van de interfaces worden uitgevoerd. Na een reboot kan de webinterface van de XLR8r via het default IP-adres worden gestart vanuit een host op het default subnet of, in plaats daarvan, op een door de administrator gedefinieerd IPadres en subnet. Na de authenticatie selecteert men de optie Network vanuit het linkermenu (zie figuur 2). Vanuit het invoerformulier Edit device kunnen IP-adres, subnetmask en maximum transmission unit (MTU) van de bond worden aangepast. De default MTU van 1.500 bytes kan worden gewijzigd voor het gebruik van jumboframes, op voorwaarde dat de switches en netwerkkaarten deze ondersteunen. Verder geeft het netwerkmenu toegang tot de instellingen aangaande virtuele interfaces voor VLAN-tagging, sta-
XLR8r schrikt niet terug voor jumboframes Figuur 3: LUNS-menu tic routing, DNS-servers en de default gateway. Nadat de veranderingen aan de netwerkconfiguratie zijn aangebracht, moet de autosupport geconfigureerd worden. Dit verschaft de supportafdeling van WhipTail op regelmatige tijden belangrijke informatie over de status en prestaties van de storageappliance. De XLR8r gebruikt daarvoor een SMTP relay op de SMTP-server. Via het veld Autosupport CC kan worden aangegeven dat niet alleen naar het supportteam van WhipTail, maar ook naar een interne beheerder autosupportmessageworden verstuurd. LUN s Nadat de initiële set-up is afgerond, kunnen de LUN s worden gecreëerd en geconfigureerd. LUN s die aangemaakt zijn met de XLR8r, kunnen worden toegewezen aan initiators van elk type, zoals Fibre Channel, iscsi of SRP. Voor de creatie van LUN s wordt de optie LUNs geselecteerd (zie figuur 3). In dit menu stel je een waarde in voor de naam (maximaal zestien karakters), de blockgrootte die het operating system te zien krijgt (uitgedrukt in het aantal GB s) en de storagepool vanwaaruit het LUN wordt gecreëerd (in de meeste gevallen is dit de default SSD-pool SSD1 ). Initiators Via het menu Initiators worden initiatorgroups gecreëerd, waaraan daarna LUN s worden gekoppeld (zie figuur 4). Nadat de initiatorgroup is aangemaakt, wordt de initiator geselecteerd uit de drop-down box. In het veld WWN/IQN wordt vervolgens de poort gedefinieerd volgens de dubbelepuntnotatie. Iets daaronder worden de invoervakken voor LUN-mapping getoond. Hier kan de beheerder het beschikbare LUN uit een drop-down box selecteren en het LUN-ID-nummer invoeren. Een druk op de knop Map brengt de koppeling tot stand. Omgekeerd kunnen LUN s via de knop Unmap weer worden ontkoppeld. Let wel: initiatorgroups hebben alle zonder uitzondering een LUN die is verbonden aan ID 0, de anonieme identiteit. NFS-exports De XLR8r ondersteunt NFS-volumes. In het menu NFS wordt het Network File System Deduplicatie en compressie De XLR8r voorziet in inline, on-the-fly deduplicatie en compressie van primaire storage zonder daarbij een dataduplicaat te hoeven opslaan. Bij de inline datadeduplicatie wordt eventuele redundante data namelijk geëlimineerd op blockniveau. Dit is een groot voordeel in virtuele omgevingen en vormt een kritieke factor voor het behalen van tier 0-prestaties. De inline datadeduplicatie is een standaardfeature van de XLR8r, die naar wens per LUN kan worden geactiveerd. De mate van datareductie in een virtuele omgeving kan oplopen tot 300 : 1. Niet alle deduplicatiefeatures zijn uit hetzelfde hout gesneden. Het uitvoeren van inline deduplicatie leidt er niet op alle storagearrays toe dat de hoeveelheid benodigde storage wordt verlaagd. Sterker nog, soms is er voor het (NFS) geactiveerd via een checkbox. Na specificatie van de gewenste capaciteit in GB kan dan een NFS-volume worden gecreëerd. Exports worden aangemaakt via het menu Export, waarbinnen op het invoerformulier New diverse waarden worden ingevuld: naam en pad van de NFS-export (bijvoorbeeld: /nfs/ssda/pathname ); het NFS-volume waarop de export wordt gecreëerd (de default is: /nfs/ssd1 ); IP en subnet voor beperkte toegang (indien van toepassing) en de toegangsopties (read only of read-write).nfs-exports en -volumes kunnen uiteraard weer worden verwijderd via de menu s Exports en Volumes. De volumes kunnen altijd nog worden vergroot deduppen juist meer storage nodig, terwijl het ook nog de prestaties verslechtert. Hier zijn twee redenen voor. Ten eerste voeren dergelijke deduplicatiealgoritmen alle writeoperaties tijdens de productie-uren direct uit op de fysieke media. Zodoende is er een hoop dure storageruimte nodig om alle gebruikersdata vast te houden, voordat deze in omvang wordt gereduceerd. Ten tweede maken dergelijke storagefilers met regelmatige tussenpozen fingerprints van alle nieuwe data, vergelijken deze met de bestaande tabel van diskfingerprints en voeren vervolgens de deduplicatie uit. Dit proces wordt als batchjob verwerkt en is zeer computerintensief, wat de prestaties tijdens het deduppen niet ten goede komt... 33
Lage kosten per IOPS, niet per MB Figuur 4: Initiatormenu 34 Figuur 5: RAID 0-set SSD1 door de waarde in het veld Size aan te passen in het menu Volumes. De prestaties van NFS-volumes zijn gebonden aan een plafond van ongeveer 50.000 IOPS, dit vanwege de beperkingen van het NFS-protocol. Om de beste prestaties te bereiken, kan het nodig zijn om gebruik te maken van multipath I/O (MPIO) via de 4GbE-verbindingen. CIFS shares De XLR8r ondersteunt ook het CIFS-protocol, dat vanuit de optie CIFS in het linkermenu kan worden geactiveerd. Er zijn diverse velden met features die kunnen worden ingevuld, waaronder de hostname waarmee de XLR8r aan een domein wordt toegevoegd, de description waaronder het computerobject bekendstaat in Active Directory, en de NetBIOS domain name en full domain name waarmee het gekoppelde domein wordt benoemd. Ten slotte worden user name en password van de domeinadministrator ingevoerd, waarmee een systeem aan het domein wordt verbonden. Net zoals bij NFS moet de omvang van het CIFSvolume worden gealloceerd. Nadat die opslagcapaciteit aan CIFS is toegekend, kunnen CIFS shares worden gecreëerd via het menu Shares. De beheerder moet daartoe specificaties opgeven omtrent de naam van de share op zowel de XLR8r als de Windows clients en omtrent de valid users van het domein. ahigh availability De XLR8r is leverbaar met synchrone of asynchrone high availability (HA). Met synchronous HA worden twee appliances verbonden via een dual 10GbE-interface: de een voor de heartbeat, de ander voor datareplicatie. Beide systemen werken dan als primaire nodes. Dat betekent dat devices die multipathing ondersteunen, op ieder moment naar elke appliance kunnen schrijven. Bij asynchronous HA vindt datareplicatie plaats tussen twee devices in geografisch gescheiden systemen. In beide remote datacenters is een kopie van de data aanwezig. In geval van een catastrofe kan de remote peer dienen als primaire storagedevice, die read en write requests accepteert. Test Om het aantal I/O s van de XLR8r te testen, maken we gebruik van Intels Iometer. Van dat programma draaien twee managers met elk acht workers. Zij voeren een test uit met diskblocks van 4 kb, 32 outstanding I/O s en aligned I/O s van 4 kb. Het testsysteem bestaat uit driemaal een Windows Server 2008 van 64 bit, waarvan elk via een 10GbEswitch van het type Netgear GSM7328S is verbonden met de XLR8r. De 10GbE-adapters en -switch worden ingesteld voor jumboframes. Voor elke server worden twee LUN s aangemaakt op de XLR8r, die worden verdeeld over de wagents van Iometer. We zien dat elke server in staat is om ruim 50.000 I/O s te genereren, waarmee de totale belasting uitkomt op ruim 150.000 I/O s bij een latency van 0,1 milliseconde. TCO s in VDI s In een whitepaper toont WhipTail een vergelijking van de TCO-kosten na drie jaar voor VDI s op basis van hun eigen SSD s en een traditioneel HDD-gebaseerd storagesysteem. Een volledig belaste virtuele desktop gebruikt ongeveer 20 tot 40 IOPS. Een standaard harddiskarray levert ongeveer 2.500 IOPS. De Virtual Desktop XLR8r levert 250.000 IOPS. Volgens opgave bedragen de TCO-kosten na drie jaar voor de SSDmachine 181.939 dollar en voor een traditioneel HDD-diskarray 1.536.662 dollar. De TCO van de XLR8r is dus ruim een factor acht lager. Benchmark WhipTail heeft een vergelijkende benchmark uitgevoerd, waarbij zijn SSD array en
WhipTail WT1500 RamSan-500 NetApp FAS3170 EqualLogic 20 PS3800XV Rackruimte 2U 4U 108U 20U Capaciteit 1,5 TB 2 TB 64 TB 40 TB IOPS 250.000 100.000 121.031 90.544 Prijs 35.000 200.000 1.416.140 660.000 Prijs per IOPS 0,23 2 7,89 7,29 Prijs voor zes jaar ondersteuning 25.200 ± 36.000 ± 50.867 ± 51.709 Latency 0,1 ms 0,25 ms 23 ms 10 ms Energieverbruik <300 W 300 W 18.082 W 12.000 W CIFS en NFS Ja Nee Nee Nee Figuur 6: WhipTails WT1500 vergeleken met HDD arrays (bron: WhipTail) 35 concurrerende diskarrays uit hetzelfde marksegment werden ingezet in een VDI (zie figuur 6). Op de VDI-desktop draaide een mix van Citrix XenDesktop, VMware View en Virtual Storm. Met gemiddeld 20 tot 40 IOPS per desktop vraagt een omgeving van vijfduizend VDI-gebruikers meer dan 100.000 IOPS. Een harddriveshelf kan ongeveer 2.000 IOPS leveren. De testomgeving bestond uit vijftig shelves in twee racks versus de enkele 2U hoge XLR8r. De gegevens over de XLR8r zijn afkomstig uit WhipTails eigen test. De gegevens over de concurrentie zijn afkomstig uit publiek toegankelijke bronnen. We zien een aantal bekende storageleveranciers die oplossingen van rond de 100.000 IOPS aanbieden. De XLR8r, daarentegen, ondersteunt 250.000 IOPS bij een stroomverbruik van minder dan 300 watt. Een vergelijkbaar HDD-gebaseerd storagesysteem zou daar 36.000 watt voor nodig hebben! Epiloog Het kenmerk waarmee WhipTail zijn SSD s aan de man wil brengen, zijn hun kosten per IOPS, en niet die per MB aan storage. De SSD-technologie ontwikkelt zich razendsnel, zodat niet alleen de opslagcapaciteit de komende jaren zal toenemen, maar (Advertentie) ook de lees- en schrijfsnelheid. WhipTail heeft een gedistribueerde controlleroplossing aangekondigd die schaalbaar is tot boven de 1.000.000 IOPS! Het bedrijf verwacht dat I/O s in de nabije toekomst door SSD s zullen worden afgehandeld, omdat transacties niet langer kunnen wachten op de bewegende delen van een HDD. p Bram Dons is onafhankelijk IT-analist bij IT-Trendwatch (info@it-trendwatch.nl)