De meeste storageoplossingen zijn gebouwd voor snelle toegang en veel en regelmatige updates. Die formule werkt prima voor applicaties waarvoor veel gegevens moeten worden uitgewisseld, maar het is niet geheel geschikt voor gevallen dat gegevens niet veranderd kunnen of moeten worden.

Om het even kort door de bocht te zeggen: Statische content zoals juridische geschriften, uitreksels van financiële documenten, technische tekeningen, medische beelden en geluids- en videobestanden zijn klaar om te archiveren op het moment dat ze geproduceerd zijn. Het heeft dan weinig zin om een gelaagd opslagsysteem te gebruiken. Bovendien krijg u met dit soort bestanden een enorm archief die voor lange tijd moet worden onderhouden. Tapeopslag, de conventionele vorm om dit soort data op te slaan, is dan duur en moeilijk toe te passen.

Storagefabrikanten zijn om die reden producten gaan bouwen, speciaal voor de archivering van statische content. Daarbij leggen ze de nadruk op betrouwbaarheid en eenvoudig beheer.

HoneyComb

Een daarvan is de StorageTek 5800, codenaam Honeycomb, van Sun. Deze biedt een robuuste, op cellen gebaseerde oplossing die geschaald kan worden van acht tot zestien nodes per cel, wat een halve rack wordt genoemd. In een enkele rack zitten dus tot de 32 nodes, en dat kan worden uitgebreid door er meer cellen in te hangen.

Qua software pakt Sun het iets anders aan dan concurrenten als EMC, Hitachi en HP. Die bieden standaard complianceapplicaties bij hun archiveringsoplossingen voor statische content. Sun heeft geen enkele applicatie gekoppeld aan Honeycomb, en laat dat over aan partners en klanten zelf. Het voordeel van die openheid is dat de mogelijkheden vrijwel eindeloos zijn. Sterker nog, de ingebouwde beheersoftware wordt geleverd met een SDK waarmee Java- en C-ontwikkelaars hun eigen schema's voor metadata kunnen definiëren en afstemmen op hun specifieke applicatie. De software van Honeycomb is door Sun beschikbaar gemaakt op OpenSolaris.org onder de BSD-licentie, onder de naam StorageTek 5800 Open Edition. Ook heeft het bedrijf een software-emulator van de ST 5800 online gezet om applicaties die met de SDK zijn gebouwd te draaien.

De Test

Ik heb mijn test van de ST 5800 uitgevoerd in een van de laboratoria van Sun in Colorado, om logistieke redenen. Het is een geheel uitgeruste cel met zestien nodes die gekoppeld is drie cliëntsystemen, die respectievelijk draaien op Solaris, Red Hat Enterprise Linux en Windows Server 2003. Elke node is eigenlijk een server die draait op Solaris 10 en de applicatiesoftware voor de Honeycomb. Elke draagt vier SATA-schijven van 500 GB ieders, en is via redundante verbindingen gekoppeld aan twee GbE-switches.

Van de zestien nodes is eentje gekozen als master die de activiteit van de overige nodes stuurt. Mocht die uitvallen dan komt het systeem met een van de backupmechanismem op de proppen die de masterrol direct toewijst aan een andere node. Meer hierover later.

De beheerinterface is eenvoudig, en kan worden bediend via bijvoorbeeld een SSH-verbinding. De command line interface heeft minder dan 20 commando's (ik geloof dat het er 19 waren) in zijn arsenaal waarmee de configuratie van een cel kan worden ingesteld, het systeem in de gaten kan worden gehouden, die de I/O-statistieken toont en uiteraard de basiscommando's behelst als reboot, instellen van wachtwoorden en tijd/datuminstellingen.

Vergeleken met andere beheersoftware voor storage waarmee ik heb gewerkt zijn deze commando's erg intuïtief en robuust. Door bijvoorbeeld 'sysstat' in te tikken krijg ik een beknopte samenvatting van de stand van zaken die niet meer dan een paar regels inneemt. In dit geval weet ik dat alle 16 nodes, en alle 64 drives, van de cel werken en klaar zijn voor actie. Er is ook een grafische interface, maar ik verwacht niet dat beheerders die verkiest boven de command line.

Mogelijkheden

Even aangeven wat mogelijk is met de ST 5800. Eigenlijk hebt u een begrensde set van I/O-operaties die u in staat stellen om gegevens op te slaan, op te vragen of te verwijderen. U kunt ze niet aanpassen. Het systeem kan zelfgemaakte metadata automatisch indexeren, wat zoekopdrachten versnelt.

Ik heb vooral voorgebouwde schema's gebruikt die gericht zijn op de snelheid, robuustheid en beheereigenschappen van het systeem. De eerder genoemde SDK en emulator maken het niet alleen mogelijk om van tevoren te kijken hoe het systeem gebruikt kan worden, maar kunnen ook het aantal ondersteunde objecten flink uitbreiden.

Het geheim van Honeycomb zit hem in de manier waarop het gegevens opslaat. Of het nou een röntgenfoto of een zakelijk contract is, het wordt automatisch gefragmenteerd en het systeem berekend twee parityfragmenten als eikpunt. Elk fragment komt terecht in een andere node, wat de gegevens enorm goed weert tegen zelfs meerder hardwaredefecten. Verder scant Honeycomb constant naar rottige bits en dat soort zaken.

Uiteraard wilde ik de gemaakte beloften onderwerpen aan een test. Het was niet mijn plan om nieuwe schema's te maken, maar om de bestaande structuren te gebruiken in het testsysteem. Hier heb ik een voorbeeldschema voor Honeycomb.

Met de opdrachtset van Honeycomb kunnen schema's gebouwd en getoond worden, al blijkt de GUI hier handiger te zijn dan de command line.

Scripts

Om het testen te vereenvoudigen gebruik ik een serie scripts, waarmee ik verschillende parameters (aantal clients, operaties als opslag, teruglezen, weghalen) kan instellen. Een van de parameters is de objectgrootte, waarmee ik het aantal operaties per seconde kan vergroten als ik kleinere objecten gebruik, of het systeem aan zijn limiet in transfersnelheid kan helpen door juist grote objecten in te stellen. De veranderingen in snelheid waren voorspelbaar toen ik de omstandigheden veranderde, van een enkele machine en een enkele thread naar meerdere clients die meerdere threads draaiden. De transfersnelheid haalde bijvoorbeeld bijna het limiet van GbE toen ik grote objecten terughaalde in tests 2 en 4. In tests 6 en 8 is het andere koek, als het systeem heel snel kleine objecten opslaat en terughaalt met meerdere operaties.

De gebruikelijke mitsen en maren zijn hier echter ook van toepassing: deze resultaten geven alleen een ruwe weergave van de werklast die de ST 5800 aankan wanneer het met drie clients te maken heeft. Andere configuraties zullen ongetwijfeld andere resultaten geven.

Wat denk ik wel consistent blijft is de robuustheid. In het plan haalde ik plotseling schijven eruit, schakelde ik twee nodes uit en liet ik een switch uitvallen om zo een fail-over uit te lokken op de reservedoos. Elke keer bleef de ST 5800 doorgaan met waar het mee bezig was en schakelde het snel terug naar zijn normale doen als het probleem was verholpen.

Dus probeer ik de grens op te zoeken, en nadat ik twee nodes uitschakelde (en ik controleerde of mijn testscript nog draaide) haalde ik er nog een schijf uit. Sun waarschuwde mij dat als er nog een fout optreedt nadat acht van de 64 schijven uitgevallen zijn, dat het systeem dan in een slaapstand zou raken. Dat gebeurde ook, maar hij sloeg direct weer aan toen ik de schijf weer terugplaatste. Met het weer bijschakelen van de twee nodes was Honeycomb weer in volledige operatie.

Conclusie

Een gewone NAS is niet bedoeld voor archivering op de lange termijn: hij zou zich verhangen aan de werklast van meerdere grote objecten tegelijk, en een derde schijfstoring zou de boel op zijn gat laten gaan. Honeycomb is daar juist tegen gewapend.

Ik was erg onder de indruk van Honeycomb, al moet worden gezegd dat dit niet een volledige versie te noemen valt. Sun is bezig met nieuwe functies, zoals replicatie op afstand tussen verschillende cellen. De meest veelbelovende nieuwe functie is het gebruik van Storage Beans: kleine programmaatjes die het mogelijk maken voor elke cel om objecthandelingen te verrichten op basis van de inhoud. Maar de ST 5800 is nu al een erg aanlokkelijk systeem, voor een hoge prijs, dat wel, maar die zit niet boven die van de concurrenten.

Bron: Techworld