De ongecontroleerde groei van opslag behoefte, een business case..

U vraagt zich wellicht af hoe de storage zo snel kan groeien en waarom het oncontroleerbaar is. Hiervoor zijn meerdere redenen te noemen.

• We slaan steeds meer op. In ons dagelijkse leven zijn steeds meer zaken digitaal geworden. We verwachten deze – zonder afweging of het nuttig is – op te kunnen slaan. We denken dat storage goedkoop is en handelen daarnaar.
• Comsumerization. Thuis slaan we tegenwoordige foto’s, film en muziek op goedkopen storage (bijvoorbeeld USB disken) op. We verwachten hetzelfde gemak op het werk en vergeten dat er daar andere eisen aan storage gesteld worden. Bedrijfsmatige storage moet bijvoorbeeld redundant (dubbel) zijn uitgevoerd, maakt gebruik van een betere kwaliteit hardware (duurder) en wordt meegenomen in de backup (eventueel off site). Daarnaast worden er security eisen gesteld. Al deze verschillen maken dat de kosten hoger liggen.
• Steeds grotere bestanden. De devices die onze bestanden maken (zoals foto camera’s, telefoons, muziek spelers en film camera’s) maken steeds grotere bestanden. Natuurlijk neemt de kwaliteit hierdoor toe, maar de omvang ook. Sterker nog, elke nieuwe generatie devices levert 30 tot 40 keer grotere bestanden op.
• Isolatie van servers en virtualisatie. Om de complexiteit van servers te verminderen is functionaliteit vaak geïsoleerd. Virtualisatie maakte dit mogelijk, maar het gevolg is wel dat extra servers nodig zijn en er is bovenal heel veel extra storage nodig.

Essentie van deze groei is dat deze niet lineair is, maar exponentieel. En dat is precies de reden dat de standaard oplossingen niet langer gebruikt kunnen worden. We moeten “een andere bril opzetten” en naar fundamenteel andere oplossingen zoeken, doorgaan op de ingeslagen weg is geen optie.

Softwarematige storage kan de groei bijhouden

Veel internet / cloud gebaseerde bedrijven liepen eerder tegen dit vraagstuk. Google, Hyves, Facebook, SalesForge, Dropbox e.d. hadden niet kunnen bestaan wanneer zij hiervoor geen oplossing hadden bedacht. Langzamerhand worden deze oplossingen ook voor niet internet / cloud bedrijven interessant.

Het idee is storage softwarematig af te handelen, ook wel software defined storage genoemd. Op basis van standaard hardware wordt een gedistribueerd file systeem (GFS) gebouwd waarin zaken als redundantie en (geo)replicatie geregeld kunnen worden. De voordelen hiervan zijn legio,

• er kan klein gestart worden zonder vooraf de uiteindelijke totale storage omvang te moeten weten (of te betalen),
• klein starten betekend geen grote investering vooraf (CapEX) maar alleen operationele kosten (betalen voor daadwerkelijk gebruik – OpEX),
• zowel opslag capaciteit als toegang tot de data schalen lineair, ieder systeem dat toegevoegd wordt, vergroot niet alleen de opslagcapaciteit, maar ook de toegang tot deze capaciteit en verwerkingscapaciteit (parallelle verwerking)
• een zeer flexibele oplossing zowel vanwege het softwarematige karakter alsmede vanwege de schaalbaarheid
• als gevolg van het bovenstaande, veel lagere kosten

Gedistribueerde file systemen geven u de mogelijkheid om in de groei van de storage capaciteit te voorzien op een kosteneffectieve wijze. Daarnaast maakt het u minder afhankelijk van hardware leveranciers (standaard hardware kan gebruikt worden zelfs verschillende merken door elkaar) en blijft u flexibel om dat het een software defined storage betreft. Voorbeelden van GFS-en zijn:

• Het Google File Systeem (GFS) – niet te koop
• Red Hat Storage server (Gluster gebaseerd)
• Ceph
• Hadoop

Toepassingsgebieden

Bedrijven en organisaties slaan gestructureerde data (zoals databases) op en ongestructureerde data (zoals files, mail, audio, foto’s en video). De verhouding tussen deze twee is dat gemiddeld gestructureerde data 10% van de opslagcapaciteit gebruikt en ongestructureerde data 90%. Tegenwoordig wordt hiervoor een SAN gebruikt. Hoewel dit een prima oplossing is voor gestructureerde data (zoals databases) is het voor de opslag van ongestructureerde data verhoudingsgewijs kostbaar. Daarom wordt soms het SAN ontlast door de ongestructureerde data op een (goedkoper) Network Attached Storage (NAS) te plaatsten. RHSS is een alternatief voor een (traditioneel) NAS. Het biedt daarnaast echter geavanceerde functionaliteit zoals die in SAN’s geboden worden (bijvoorbeeld geo-replicatie). Overigens is “block storage” in de maak en daarmee kan RHSS op termijn het SAN vervangen. Hiermee is storage geen apart vakgebied meer, maar kunnen Linuxbeheerders met hun eigen bekende tools de storagebehoefte invullen.

RHSS kan ingezet worden om:

• kosten te besparen door een uitbreiding van een bestaand SAN / NAS te voorkomen of uit te stellen
• kosten te besparen door de vervangingsinvestering van een nieuw SAN / NAS uit te stellen
• de performance van een bestaand SAN te reserveren voor de opslag van gestructureerde data (databases) en de ongestructureerde data op RHSS op te slaan
• (geo-)replicatie op kosten effectieve wijze te realiseren (vooralsnog voorlopig alleen voor ongestructureerde data)
• een hoog beschikbare fileserver (NFS of SMB) op meerdere geografisch gescheiden locaties te realiseren
• een hoog beschikbare cloud opslag te realiseren (“DropBox” functionaliteit)
• schaalbare opslag te realiseren (klein beginnen en het is schaalbaar tot 64 PetaByte (ge-support, maar technisch ligt deze grens veel hoger),
• de capaciteit van de storage kan worden uitgebreid zonder down time)
• een kosten effectieve backup-to-disk oplossing te realiseren
• een storage oplossing voor een OpenStack cloud omgeving te realiseren
• een storage oplossing voor Red Hat Enterprise Virtualisation (RHEV) te realiseren
• Big Data projecten faciliteren met flexibele opslag

De financiele busines case

TCO berekening

In deze TCO berekening zijn de belangrijkste kosten meegenomen. E.e.a. is gesplitst in eenmalige kosten (zoals aanschaf van hardware) en in periodieke kosten (zoals subscriptiekosten).

Dell servers

Investeringsoverzicht en periodieke kosten
De Red Hat subsripties voor RHSS worden in batches verkocht (van 2 nodes per jaar tot 64 nodes). In dit geval is uitgegaan een batch van 16, 8 en 2 nodes. Dit geeft een totaal van 26 nodes RHSS. Verder is hier uitgegaan van het support level “standard”.

Figuur 5: TCO berekening Dell servers

SuperMicro servers

Investeringsoverzicht en periodieke kosten
De Red Hat subsripties voor RHSS worden in batches verkocht (van 2 nodes per jaar tot 64 nodes). In dit geval is uitgegaan een batch van 8 en 2 nodes. Dit geeft een totaal van 10 nodes RHSS. Verder is hier uitgegaan van het support level “standard”.

Figuur 6: Berekening SuperMicro servers

De technische business case

Uitgangspunten en aannames
Deze business case beschrijft de situatie van een (fictieve) organisatie die 2 geografisch gescheiden locaties heeft. Op beide locaties is behoefte aan een redundant file systeem in de vorm van een file server die over de locaties heen gelijk gehouden wordt. Het file systeem kan op beide locaties gebruikt worden. De volgende aannames worden daarbij gedaan:

• Het file systeem is op beide locaties tegelijkertijd benaderbaar (bruikbaar).
• Er vindt geen database opslag plaats (hiervoor is een bestaand SAN in gebruik).
• Informatie wordt op beide locaties opgeslagen en gelijk gehouden (dit wordt replicatie genoemd en vindt synchroon* plaats waarmee beide locaties actief gebruikt kunnen worden (dit in tegenstelling tot a-synchrone replicatie waarbij er een actieve en een passieve locatie ontstaat).
• Bij uitval van één locatie blijft het file systeem op de andere locatie bruikbaar.
• Het file systeem kan benaderd worden middels het Server Message Block protocol (SMB).
• Totaal is er ongeveer 500 TB netto opslagruimte beschikbaar (maar wel aan beide zijden).
• De TCO berekening is gemaakt van twee type servers. De reden hiervoor is aan te tonen dat de oplossing merk onafhankelijk is. Tevens is gekozen in het ene geval performance de nadruk te geven en in het andere geval opslag capaciteit voorrang te geven.
• Tussen de locaties is een 1Gb/s verbinding beschikbaar die een latency heeft < 1 miliseconde heeft**.
• De opslag systemen maken gebruik van SATA / SAS disks.
• De opslag systemen hebben een RAID controller en redundante voeding zodat down time van individuele systemen zoveel mogelijk wordt voorkomen.
• De opslag systemen gebruiken RAID-6 voor de opslag van gegevens (***recommendation Red Hat).
• Er wordt gebruik gemaakt van SMB ontsluiting die RHSS standaard biedt, m.a.w. het is niet nodig een aparte fileserver te gebruiken (overigens wordt CTTDB gebruikt zodat de “fileserver functie” niet tot een Single Point Of Failure (SPOF) leidt).

*De keuze tussen synchroon en a-synchroon heeft te maken met de bandbreedte en de latency van de verbinding tussen de locaties. Is de round trip latency < 5 miliseconde dan kan er van synchrone replicatie gebruik gemaakt worden. In de praktijk is het handiger 1 miliseconde als grens te hanteren.
**Bij een latency > 5 miliseconde is synchrone replicatie geen optie meer. Er zal dan gebruik gemaakt moeten worden van a-synchrone replicatie. Nog steeds blijven beide locaties gelijk, alleen zijn ze niet langer actief aan beide kanten te gebruiken. Overigens wordt deze latency voor een belangrijk deel bepaald door de afstand tussen de twee locaties.
***Er kunnen ook meerder RAID-6 set ingezet worden, waarbij 12 disks per RAID-6 set de voorkeur geniet.

Berekening van benodigde servers
In deze business case is gekozen van twee type servers een berekening te maken. De configuratie is voor beide servers feitelijk gelijk. Er worden 2 disks gebruik voor het systeem (RAID-1). De overige disks worden in een RAID-6* set geplaatst en gebruikt voor de daadwerkelijke RHSS.

*De ideale setup is 12 disks per RAID-6 set, minder kan ook.

Dell
In de hier gekozen opzet is behoefte aan een server type dat zoveel mogelijk storage biedt. Hiermee worden de Red Hat subscriptie kosten laag gehouden en gezien het aantal nodes zal de performance voldoende zijn. Bij Dell is dan de PowerEdge R720xd rackserver het meest voor de hand liggende model. Deze server biedt de mogelijkheid om naast twee interne 2,5” disks (te gebruiken voor het systeem – in RAID-1), 12 maal een 3,5” disks (4 TB) te gebruiken. In het ontwerp zoals beschreven in deze business case is gekozen voor de 3,5” (SATA) disks omdat deze de grootste opslag capaciteit per server bieden. Dus in overzicht:

Figuur 3: Disk capaciteit van de Dell systemen

 Het bovenstaande overzicht bepaalt dat we 500 TB / 40 TB = 12,5 servers nodig hebben per locatie. Dit leidt tot een totaal van 26 servers (namelijk 13 per locatie).

• De overige specificaties van het hier gebruikte model betreffen:
• Dual, hot plug, redundant, power supply.
• Op basis van 3,5” 4 TB near line SAS disks voor de RAID-6 set (storage ruimte).
• Op basis van 2,5” 146 GB SAS disks t.b.v. de RAID-1 set (systeem).
• Intel Xeon ES-2640v2 2.0 GHz processor.
• 32 GB intern geheugen.
• Intel 4 poort 1Gbit/s netwerk adapters.
• iDRAC7 Enterprise remote management kaart.
• 3 jaar basis garantie – Next Business Day

SuperMicro
Gezien het uitgangspunt dat in deze opzet gekozen wordt voor servers met zo’n groot mogelijk opslag capaciteit, valt de keuze op de SuperMicro 6047R server. In deze server kunnen 36 3,5” 4 TB disks geplaatst worden. De onderstaande configuratie wordt aangehouden:

Figuur 4: Disk capaciteit SuperMicro systemen

De bovenstaande configuratie leidt tot de volgende berekening van het totaal aantal benodigde servers: 500 TB / 120 TB = 4,1 server, dus 10 servers (5 per locatie). Middels LVM (Logical Volume Management) worden de 2 RAID-6 sets samengevoegd in een logisch volume.

• De overige specificaties van deze SuperMicro server zijn:
• Intel Xeon processor
• 32 GB intern geheugen
• 36 3,5” 4 TB disks
• Intel 4 poort 1Gbit netwerkkaart
• Redundante voeding
• Support

Ontwerp
Het ontwerp gaat uit van 2 locaties waarop zich een vergelijkbare configuratie bevindt. De volgende (technische) design keuzes zijn gemaakt:

• Beschrijf (en bereken) twee hardware opties, te weten een ontwerp gebaseerd op SuperMicro storage servers en een op basis van Dell servers.
• Hardware RAID wordt gebruikt om storage server te voorzien van disk redundantie (RAID-1 voor de systeem disks en RAID-6 voor de data disks). Feitelijk zijn de servers zo geconfigureerd dat uitval daarvan tot een minimum wordt beperkt (dubbele voeding, RAID-6). Uitval van een server leidt tot down time van een locatie. De data op het file systeem staat altijd nog op de andere locatie. Er is dus gekozen om per locatie data niet redundant op te slaan (anders dan de redundantie die RAID-6 ons verschaft).
• Er wordt gebruik gemaakt van RHSS.
• Over de servers op een locaties worden files gedistribueerd.
• Iedere locatie heeft een fileserver die de data ontsluit middels NFS en SMB.
• Tussen de locaties worden files gerepliceerd.

Afbeelding 1: Geo-replicatie

Beide locaties beschikken over (bestaande) Microsoft Active Directory servers die gebruikt worden om gebruikers autorisatie te regelen. De SMB ontsluiting van RHSS wordt gebruikt om “een fileserver” op elke locatie beschikbaar te stellen. De CTDB optie van SAMBA maakt het mogelijk dat alle RHSS nodes gebruikt kunnen worden als fileserver. Hiermee is de fileserver zelf ook geen SPOF meer.
RHSS maakt het mogelijk file systemen op verschillende wijze te combineren. In dit ontwerp is een Red Hat recommended setup gevolgd. Deze kan als volgt voorgesteld worden.

Figuur 2: Opbouw van de filesystems

In deze figuur zijn drie nodes afgebeeld. Afhankelijk van de opzet zullen de totale hoeveelheid storage die gewenst is, de RHSS inrichting en de fysieke configuratie van de servers bepalend zijn voor het aantal servers dat nodig is. In deze setup heeft iedere node een aantal disks in RAID-6 (RAID-6 is vergelijkbaar met RAID-5 met dat verschil dat het twee disks gebruikt voor parity). Dat betekent dat er 3 disks binnen één enkele node moeten falen om het file systeem op één locatie down time te geven.
Deze RAID-6 disk wordt voorzien van LVM als eerste abstractie laag. Op dit logical volume wordt een XFS file systeem aangelegd. Er wordt gebruik gemaakt van XFS omdat RHSS metadata verwerkt in de extended file system attributes van het XFS file system. Hierdoor vervalt de noodzaak voor een separate metadata server zoals dat gebruikelijk is bij reguliere scale-out storage systemen. Door het ontbreken van deze component is er geen sprake meer van een performance bottleneck op langere termijn, tevens is er geen SPOF voor het gehele storagesysteem.
Op de XFS disk kunnen nu directories worden aangelegd die binnen RHSS gebruikt kunnen worden. Het voordeel van de hier beschreven constructie is dat “dir A” en “dir B” onafhankelijk van elkaar kunnen “groeien”. Dit maakt het feitelijk mogelijk thin provsioning toe te kunnen passen op de verschillende RHSS storage volumes. Met andere woorden, de vrije diskruimte is zowel voor “dir A” als “dir B” beschikbaar. Deze ruimte kan natuurlijk maar een keer worden gebruikt, maar het is niet nodig hier vooraf al een keuze in te maken.

Analyse en conclusie

In deze business case is een alternatief voor een NAS beschreven op basis van RHSS. Indien de ondersteuning voor block devices in RHSS komt (en dat is een kwestie van tijd), kan het ook een alternatief voor een SAN zijn.

Deze business case stelt zware eisen aan de storage. Om te beginnen de grote capaciteit (500 TB). Daarnaast wordt deze capaciteit over 2 locaties gelijk gehouden en op elk van deze locaties bruikbaar gemaakt. Ook is er een hoge mate van zekerheid (redundantie) ingebouwd. De servers zijn voorzien van redundante voedingen en er is RAID gebruikt om disk falen op servers op te vangen. Additioneel wordt alle data op twee locaties opgeslagen. De beschikbaar van deze data is dus buitengewoon hoog.
Er zijn twee voorbeelden berekend op basis van verschillende merken hardware (Dell en SuperMicro). Hiermee wordt aangetoond dat de oplossing hardware onafhankelijk is. De SuperMicro server biedt veel meer diskcapaciteit waardoor het aantal servers kleiner is. Bijkomend voordeel is dat er minder RHSS subscripties nodig zijn. Het gevolg hiervan is dat de kosten lager zijn. In het voorbeeld met de Dell servers zijn er weliswaar meer servers nodig (en meer RHSS subscripties), maar daar tegenover staat dat er een grotere mate van disk redundantie is (namelijk 2 spares / parity disk op 12 disks, tegenover 2 spare / parity disks op 17 disks in het geval van SuperMicro). Bovendien mag vanwege het groter aantal nodes in het ontwerp verwacht worden dat de performance hoger is (dit geldt zowel voor de disk configuratie als de netwerk performance vanwege een groter aantal netwerk interfaces).

Deze business case laat duidelijk de voordelen van RHSS zien. De goede schaalbaarheid zijn te combineren met de beschikbaarheid van de data op 2 locaties en dat op basis van standaard hardware. Ook laat de business case zien dat zelf de balans gezocht kan worden tussen performance en opslag capaciteit. In deze business case is gekozen voor een capaciteit van 500 TB, maar er kan natuurlijk klein begonnen worden, dat is een van de grote voordelen van software defined storage. De kosten (zoals beheeruren, switches en rackspace) betreffen veelal een inschatting en kunnen naar gelang de situatie en het beschikbaar zijn van (beter) onderbouwde kosten aangepast worden. Of RHSS een goede oplossing is voor specifieke toepassingen kan het beste middels een PoC (Proof of Concept) aangetoond worden.

Deze business case is tot stand gekomen in samenwerking met Red Hat, Dupaco, Dell en SuperMicro. De business case is ook als white paper te down loaden vanaf de site van de Computable.

Indien u geïnteresseerd bent in de achterliggende rekensheet, dan kan u die van mij ontvangen (jvdtorn@xs4all.nl).