Software Defined Storage – Deel I

No comments »
AUTHOR:
Redactie Dell EMC
CATEGORIES:

* Dit artikel verscheen eerder in CloudWorks.

Na virtuele servers en een eerste begin met de virtualisatie van netwerken, zien we nu software defined storage op ons afkomen. Analisten zijn opmerkelijk positief over deze ontwikkeling, omdat we daarmee in hun ogen eindelijk grip krijgen op een van de lastigste (en kostbaarste) problemen van de IT-afdeling: de wildgroei aan storage-systemen die vaak 1-op-1 gekoppeld zijn aan applicaties. Maar hoe werkt het nu precies en hoe kijken analisten aan tegen SDS-oplossingen als EMC’s ViPR?

Nu steeds meer business managers ervaring hebben opgedaan met public cloud-diensten als Amazon, Dropbox of Salesforce, neemt de druk op IT-afdelingen sterk toe om een vergelijkbare dienstverlening te bieden. Dan blijkt echter wat een grote voorsprong dit soort cloud providers hebben kunnen nemen, doordat zij geen last hebben van legacy.

Software Defined Storage
Veel IT-managers, zo stelt onderzoeksbureau Enterprise Management Associates in een eerder dit jaar verschenen rapport, hebben inmiddels al grote stappen gezet als het om de modernisering van hun IT-infrastructuur gaat. Het aantal IT-afdelingen dat géén server-virtualisatie toepast, is inmiddels op één hand te tellen. Software defined networking is ook aan een opmars bezig, al heeft de grote doorbraak nog niet plaatsgevonden. Desondanks is het concept voor veel IT-managers inmiddels duidelijk en wordt in veel gevallen hard gewerkt aan het aanpassen van de migratieplannen richting SDN.

Hoe anders ziet de wereld van de storage er uit. Om tegemoet te komen aan de druk van enerzijds de business en anderzijds applicatieontwikkelaars hebben IT-afdelingen er in het verleden een gewoonte van gemaakt om storage aan te schaffen op maat van specifieke toepassingen. Per project bekeken is dat wellicht nog wel slim te noemen, maar het gevolg is wel dat menig datacenter vol staat met een wonderlijke reeks van storage-systemen, met ieder hun eigen protocollen, feature sets en ondersteunde data-types. Per applicatie klopt het vaak allemaal wel min of meer, maar als we het over de gehele IT-afdeling heen bekijken, is vooral sprake van een chaotische situatie vol met stevig van elkaar afwijkende prestatieniveaus, capaciteiten, kostenstructuren, security-methoden, beschikbaarheidskarateristieken, robuustheid en dergelijke. Al die proprietary storage-systemen kennen eigen API’s die onderling grote en vaak onoverbrugbare verschillen kennen. Het toewijzen en beheren van storage per applicatie is dan ook nog opmerkelijk vaak een grotendeels handmatige operatie. Dat is tijdrovend, kostbaar en zeker niet per definitie foutvrij.

Dit probleem bestaat natuurlijk al veel langer, maar dreigt de afgelopen jaren flink uit de hand te lopen doordat het aantal applicaties dat behoefte heeft aan storage explosief is gegroeid. Zouden we door willen gaan op de oude weg, dan zouden we als IT-afdelingen dus nog meer storage moeten kopen op maat van al die individuele applicaties. Helaas (gelukkig?) is er een dusdanige druk op het IT-budget dat dit niet langer kan. Het moet dus anders. Maar hoe?

Lees binnenkort het tweede deel van dit artikel op deze blog.

Leave a Reply

Your email address will not be published. Required fields are marked *