Als je tegen een probleem aanloopt met opslag, word je bijna gedwongen om een ‘quick fix’ uit te voeren. “Dat los ik later wel beter op”, zeg je dan tegen jezelf. Maar jammer genoeg leef je dan wellicht nog jarenlang met de consequenties van je foute snelle beslissing. Ik kan het weten, want het is mij overkomen.

In deze tijden van data-explosie kan het zomaar gebeuren dat je opslagcapaciteit tijdens werktijd plotseling tegen zijn limieten aanloopt. Soms gebeurt het omdat er geen goede monitoring van de opslagcapaciteit plaatsvindt en soms komt het door een onvoorziene plotselinge groei in opslagconsumptie. Maar wat de oorzaak ook is, alle ogen zijn op IT gericht om zo snel mogelijk meer opslag mogelijk te maken.

De truc om een ‘quick fix’ te vermijden is discipline. Het management zal waarschijnlijk aandringen op een snelle oplossing, maar wees standvastig. Maak tijd in je werkschema en los het probleem op de juiste manier op. Dat is echt de enige manier om irritatie op de lange termijn te voorkomen.

De juiste manier hoeft trouwens niet eens altijd langer te duren. Hier volgen twee voorbeelden van capaciteitsproblemen en hulpmiddelen om ze op te lossen zonder dat je er tijden lang door achtervolgd wordt.

Opslagcapaciteitcrisis nummer 1: De volle fileserver

Het is maandagmorgen half 10. De helpdesklijn is net geëxplodeerd met klachten over opslagproblemen op het netwerk. Een snelle check onthult dat de fileserver zo vol zit als een blikje ansjovis. De server in kwestie heeft geen vrij slot om een extra harde schijf in kwijt te kunnen, dus even een schijfje bestellen is er niet bij.

De gehele server moet geüpgrade worden en wie weet wanneer dat eindelijk zal gaan gebeuren. Maar omdat de kritieke bestanden van het bedrijf allemaal op dit volume staan, moet er wel snel iets gebeuren.

De meest logische actie, is om data te zoeken op de server die eraf kan. Daarmee win je even tijd. Misschien staat er een kopietje van een software-installatie of een service pack die je niet meteen nodig zult hebben. Maar goed, het kan best zijn dat dit maar een paar honderd MB oplevert en die vrije ruimte is waarschijnlijk weer verdwenen op het moment dat je het bestand hebt weggehaald.

Mijn ervaring leert dat je nu het beste één groot en niet vaak gebruikt bestand kunt pakken, om dat op een andere server te zetten (vaak een applicatieserver). De beste kandidaten zijn meestal gedeelde bestanden van kleinere afdelingen, zoals marketing of boekhouding, die weinig gebruikers hebben maar wel grote hoeveelheden data.

Met een klein aantal gebruikers hoef je slechts een paar drive mappings te wijzigen. Natuurlijk nog steeds een lelijke oplossing, maar gelukkig hoef je maar één ding te doen om de oplossing pijnloos te maken wanneer je fileserver een paar weken later arriveert en dat is een DFS (distributed file system) opzetten.

Als je DFS nog niet regelmatig gebruikt; het kan je redding zijn. De essentie van DFS is dat het je in staat stelt om een virtuele file sharing name space (DFS root) te creëren die doorzichtige file share mappings (DFS links) bevatten.

Vanuit een gebruikersperspectief lijkt een DFS root op een normale file share met normale mappen. Maar die mappen zijn eigenlijk links naar de file shares waar de data werkelijk staat. Een gebruiker kan dus naar ‘\\example.com\network\departments\marketing’ gaan en in werkelijkheid naar ‘\\appserver1\marketing$ ‘ gestuurd worden zonder dat hij of zij het doorheeft.

Dit kan van grote waarde zijn voor admins, omdat ze op een eenvoudige manier veranderingen kunnen aanbrengen in waar de DFS links heen verwijzen, zonder dat ze de gebruikers hoeven in te lichten.

Dus, als de nieuwe file server er is en je bent er klaar voor om je data er naartoe te verhuizen, hoef je dit alleen maar te doen buiten werktijd en de DFS link te updaten naar de nieuwe share. Het hebben van DFS maakt de rest van de servermigratie makkelijker en met een minimale gebruikersonderbreking.

Opslagcapaciteitcrisis nummer 2: De toewijzing van te veel ruimte per volume op de SAN

Om half 10 vanmorgen (dat is de tijd waarop de meest verschrikkelijke dingen gebeuren) werd je geconfronteerd met een afdelingshoofd en een technicus van een softwarebedrijf dat een voor jouw bedrijf onmisbare applicatie wilde upgraden. Blijkbaar gebruikt de nieuwe versie alleen bijna twee keer zoveel opslag, wat neerkomt op een netto vermeerdering van 500 GB.

Daarnaast hebben ze die ruimte vanmiddag nog nodig. Het feit dat niemand je gewaarschuwd heeft voor deze gebeurtenis maakt niet uit, de directeur van het softwarebedrijf speelt namelijk wel eens een potje golf met je baas zijn baas.

Twee jaar geleden, toen je je gloednieuwe SAN kreeg, dacht je zeker te weten dat jouw bedrijf nooit 8TB aan opslag nodig zou hebben. Wat zou er in vredesnaam zo groot kunnen worden? Nu weet je het antwoord: Een heleboel zooi.

De SAN was oorspronkelijk aangeschaft om een nieuw document imaging system op te slaan, maar sindsdien heb je er een virtualisatie omgeving op gebouwd en een aantal van je fysieke servers erop gedumpt. Nu is er te weinig ruimte over om ook maar een paar screenshots te maken, veel minder dan de extra 500GB die je nodig hebt. Een nieuwe schijf zit in het budget, maar dit acute probleem moet nu opgelost worden.

De beste optie die je kunt verzinnen, is het verhuizen van een virtuele utility server terug naar een afgedankte fysieke server met genoeg opslagcapaciteit. Je kunt die oude server ook aan de softwaremaker ter beschikking stellen. Maar geen van deze opties is echt aangenaam.

In eerste instantie moet je dan namelijk een server gaan verhuizen die je later toch terug gaat zetten wanneer je weer ruimte op de SAN hebt. Ten tweede manoeuvreer je jezelf in een situatie waarbij een belangrijke server op verouderde hardware draait.

Maar er is misschien een andere manier. Wanneer men een centraal opslagmedium in handen krijgt, heeft men de neiging om veel te veel ruimte aan de eerste paar volumes toe te wijzen. Twee jaar geleden, toen de SAN arriveerde, was de gedachte immers dat het nieuwe document management system gigantisch zou worden. Daardoor zou 2TB toewijzen een logische keuze zijn.

Tot de dag van vandaag heeft het ding echter 600GB gebruikt en daardoor is er nog meer dan 1TB over. Helaas is het verkleinen van een NTFS-station een riskante zaak. Nog erger is dat je ook niet genoeg ruimte hebt om een vervangend volume te creëren waarin je de applicatie-data kunt opslaan om de ruimte vrij te maken.

Of toch? Als je SAN een knip voor de neus waard is, ondersteunt hij waarschijnlijk thin provisioning. Dat maakt het mogelijk om vrije ruimte van een bestaand volume vrij te maken, zodat je het ergens anders voor kunt gebruiken.

Dat kan erg gevaarlijk zijn. Als je uiteindelijk probeert om de ruimte die je vrij hebt gemaakt in gebruik te nemen, zal de SAN pas écht vol zitten en ben je in de aap gelogeerd. Maar thin provisioning van een groot volume waar te veel ruimte aan toegewezen is, kan je de flexibiliteit bieden om bestanden heen en weer te schuiven en je daarmee uit de problemen helpen.

Zolang je opslag toevoegt na de thin provisioning, of achteraf de extra data weer migreert van het volume naar een volume met de correcte grootte en de thin provisioning stopzet, is dit trucje onmisbaar.

Concluderend

Het moge duidelijk zijn dat een goede monitoring van de opslagcapaciteit nog altijd de beste manier is om deze problemen te voorkomen. Maar zelfs de meest visionaire planners kunnen niet alle incidenten zien aankomen.

Dus als je met een opslagcapaciteitcrisis zit, neem dan even de tijd om al je opties onder de loep te nemen en laat je niet verleiden om het eerste idee dat er in je hoofd opkomt direct te gaan uitvoeren. Grote kans dat je dan een oplossing vindt die betere resultaten oplevert, zonder dat je jezelf gigantische hoofdpijn bezorgt.

Bron: Techworld