Wanneer een SAN overwegen?

Iedereen lijkt zich, soms behoorlijk hartstochtelijk, in de aanschaf van een SAN te willen storten. SAN's zijn, dat geef ik toe, behoorlijk gaaf. Ze behoren tot de leukere en spannendere, grootschalige hardware-items die de meeste IT-professionals de kans krijgen in hun eigen omgeving te hebben. Vaak is de wens om een eigen SAN te bezitten een kwestie van “de buren bijhouden”, aangezien het gebruik van een SAN enigszins een statussymbool is geworden – een van die laatste bolwerken van grootzakelijke IT die je alleen in een speciale serverkast aantreft en nooit bij iemand thuis (nou ja, bijna nooit). SAN's worden zwaar gepusht, geadverteerd en verkocht als verbazingwekkende kasten met interne redundantie die ze onfeilbaar maakt, met een snelheid die de logica tart en boordevol functies waarvan je nooit wist dat je ze nodig had. Wanneer ik spreek met IT-professionals die nieuwe systemen ontwerpen, is een van de meest voorkomende ontwerpaspecten die ik hoor: “tja, we weten nog niet veel over ons uiteindelijke ontwerp, maar we weten dat we een SAN nodig hebben.”

In de context van dit artikel gebruik ik SAN in de meest gangbare betekenis, namelijk om een “blokopslagapparaat” aan te duiden en niet om te verwijzen naar het volledige opslagnetwerk zelf. Een opslagnetwerk kan bestaan voor NAS zonder überhaupt een SAN-blokopslagapparaat te gebruiken. Voor dit artikel verwijst SAN dus uitsluitend naar SAN als apparaat, niet naar SAN als netwerk. SAN is een vage term die op verschillende momenten meerdere dingen kan betekenen en behoorlijk verwarrend kan worden. Een SAN die zonder netwerk is geconfigureerd, wordt DAS. DAS die in een netwerk is opgenomen, wordt SAN.

Laten we even stoppen. Een SAN is je backend-opslag. De noodzaak ervan zou in alle gevallen bepaald worden door andere aspecten van je architectuur. Als je nog niet over veel andere onderdelen hebt beslist, kun je simpelweg niet weten of een SAN in het uiteindelijke ontwerp nodig, of zelfs maar nuttig, gaat zijn. Alarmsignalen. Overal alarmsignalen. Stel je een Romeinse strijdwagenrace voor waarbij de paarden de strijdwagens duwen (als je begrijpt wat ik bedoel).

Het is duidelijk dat de drang om een SAN te implementeren zo sterk is dat er vaak hele projecten worden bedacht met weinig ander doel dan, zo lijkt het, de aanschaf van de SAN te rechtvaardigen. Zoals bij elk project is de eerste vraag die men moet stellen: “Welke bedrijfsbehoefte proberen we te vervullen?” En van daaruit verder werken, niet “We willen een SAN kopen, waar kunnen we hem gebruiken?” SAN's zijn complex, en met complexiteit komt kwetsbaarheid. Heel vaak brengen SAN's hoge kosten met zich mee. Maar het beangstigendste aspect van een SAN is het wijdverbreide gebrek aan diepgaande kennis in de sector over deze apparaten. SAN's brengen enorme technische en zakelijke risico's met zich mee die overwonnen moeten worden om het gebruik ervan te rechtvaardigen. SAN's zijn zonder twijfel zeer spannend en bijzonder nuttig, maar dat is zelden goed genoeg om de wens ernaar te rechtvaardigen.

We noemen SAN's “de opslag van het laatste redmiddel”. Wat dit betekent, is dat je bij het kiezen van opslagtypen hoopt dat je een van de andere alternatieven kunt gebruiken, zoals lokale schijven, DAS (Direct Attached Storage) of NAS (Network Attached Storage), in plaats van een SAN. Meestal werken de andere opties prachtig. Maar er zijn momenten waarop de bedrijfsbehoeften eisen stellen waaraan redelijkerwijs alleen met een SAN kan worden voldaan. Wanneer die zich voordoen, hebben we geen keuze en moeten we een SAN gebruiken. Maar over het algemeen kan het worden vermeden ten gunste van eenvoudigere en doorgaans minder kostbare of risicovolle opties.

Ik merk dat de meeste mensen die een SAN willen implementeren, dat doen onder invloed van een aantal misvattingen.

De eerste is dat SAN's vanwege hun aard zeer betrouwbaar zijn. Hoewel er zeker veel SAN-leveranciers en specifieke SAN-producten zijn die verbazingwekkend betrouwbaar zijn, geldt hetzelfde voor elk willekeurig IT-product. Hoogwaardige servers in de prijsklasse van hoogwaardige SAN's zijn precies even betrouwbaar als SAN's. Aangezien SAN's gemaakt zijn van dezelfde hardwarecomponenten als gewone servers, is er geen toverkunst om ze betrouwbaarder te maken. Alles wat gebruikt kan worden om een SAN betrouwbaar te maken, is een doorsijpeling van RAS-technologieën (Reliability, Availability and Serviceability) van servers. Net als SAN kunnen NAS en DAS, evenals lokale schijven, ongelooflijk betrouwbaar worden gemaakt. SAN verwijst alleen naar het apparaat dat wordt gebruikt om blokopslag te bedienen in plaats van een andere taak uit te voeren. Een SAN is gewoon een heel eenvoudige server. SAN's beslaan het volledige spectrum van betrouwbaarheid, met mainframe-achtige betrouwbaarheid aan de bovenkant tot apparaten die niets meer zijn dan externe harde schijven – de meest onbetrouwbare netwerkapparaten op je netwerk – aan de onderkant. Dus in plaats van dat SAN betrouwbaarheid betekent, biedt het juist een paar bijzondere gevallen van de laagste betrouwbaarheid die je je kunt voorstellen. Maar in wezen delen alle servers ongeveer gelijke betrouwbaarheidsoverwegingen. SAN's krijgen een reputatie van betrouwbaarheid omdat bedrijven vaak extreme budgetten in hun SAN's steken die ze niet in hun servers steken, zodat de vergelijking er een is van een relatief hoogwaardige SAN met een relatief goedkope server.

De tweede is dat SAN “groot” betekent en NAS “klein”. Een dergelijk verband bestaat niet. Zowel SAN's als NAS'en kunnen van vrijwel elke schaal of kwaliteit zijn. Ze beslaan beide het hele spectrum en uit de gekozen technologie valt niet in het minst af te leiden of een apparaat groot is of niet. Nogmaals, zoals hierboven, kan een SAN technisch gezien zelfs “kleiner” uitvallen dan een NAS-oplossing vanwege de mogelijke eenvoud ervan, maar dit is een specialistisch geval en grotendeels alleen theoretisch, hoewel er SAN-producten op de markt zijn die in deze categorie vallen; alleen kom je ze in de praktijk zeer zelden tegen.

De derde is dat SAN en NAS van binnen, in het chassis, dramatisch van elkaar verschillen. Dit is zeker niet het geval, aangezien het merendeel van de SAN- en NAS-apparaten tegenwoordig wat “unified storage” wordt genoemd zijn, wat een opslagappliance betekent die tegelijkertijd zowel als SAN als als NAS fungeert. Dit onderstreept dat het belangrijkste verschil tussen de twee niet in de backendtechnologie, hardware, omvang of betrouwbaarheid zit, maar dat het bepalende verschil de protocollen zijn die worden gebruikt om opslag over te dragen. SAN's zijn blokopslag en stellen ruwe blokapparaten op het netwerk beschikbaar met protocollen als Fibre Channel, iSCSI, SAS, ZSAN, ATA over Ethernet (AoE) of Fibre Channel over Ethernet (FCoE). NAS daarentegen gebruikt een netwerkbestandssysteem en stelt bestanden op het netwerk beschikbaar via applicatielaagprotocollen als NFS, SMB, AFP, HTTP en FTP, die vervolgens over TCP/IP lopen.

De vierde is dat SAN's van nature een technologie voor bestandsdeling zijn. Dit is NAS. Een SAN neemt simpelweg je blokopslag (het subsysteem van de harde schijven) en stelt die op afstand beschikbaar over een netwerk. De aard van netwerken suggereert dat we die opslag aan meerdere apparaten tegelijk kunnen koppelen, en dat kunnen we fysiek inderdaad. Net zoals we vroeger fysiek meerdere controllers aan tegenovergestelde uiteinden van een SCSI-lintkabel konden koppelen met harde schijven die in het midden bungelden. Dit zal onder normale omstandigheden alle gegevens op de schijven vernietigen, omdat de controllers, die niets van elkaar weten, elkaars gegevens overschrijven, wat vrijwel onmiddellijke corruptie veroorzaakt. Er zijn mechanismen beschikbaar in speciale clusterbestandssystemen en de bijbehorende stuurprogramma's om dit mogelijk te maken, maar dit vereist speciale kennis en begrip die veel technischer zijn dan veel mensen die SAN's aanschaffen beseffen dat ze nodig hebben voor wat zij vaak menen dat juist het doel van de SAN is – een ramp die zo vaak voorkomt dat ik waarschijnlijk vrijwel wekelijks spreek met iemand die precies dit heeft gedaan. Dat de SAN juist de use case in gevaar brengt waarvan de meeste mensen denken dat hij ervoor ontworpen is, en niet alleen de bijna magische bescherming die men zoekt niet weet te leveren, maar integendeel juist de oorzaak is van het gegevensverlies, illustreert het risiconiveau dat een verkeerd begrepen, geïmplementeerde opslagtechnologie met zich meedraagt.

De vijfde is dat SAN's snel zijn. SAN's kunnen snel zijn; ze kunnen ook afschuwelijk traag zijn. Er is geen intrinsieke snelheidswinst door het gebruik van SAN-technologie op zichzelf. Het is voor SAN's eigenlijk vrij moeilijk om de inherente knelpunten te overwinnen die worden geïntroduceerd door het netwerk waarop ze zich bevinden. Aangezien sommige andere opslagopties zoals DAS allemaal dezelfde technologieën als SAN gebruiken maar het knelpunt en de latentie van het feitelijke netwerk missen, zal een gelijkwaardige DAS ook net iets sneller zijn dan zijn SAN-tegenhanger. SAN's zijn over het algemeen iets sneller dan een qua hardware identieke NAS-equivalent, maar zelfs dit is niet gegarandeerd. SAN en NAS gedragen zich verschillend, en in verschillende use cases kan elk van beide de betere presteerder zijn. Een SAN zou zelden als oplossing worden gekozen op basis van prestatiebehoeften.

De zesde is dat de inherente problemen die met opslagkeuzes samenhangen niet meer van toepassing zijn doordat het om een SAN gaat. Een goed voorbeeld is het gebruik van RAID 5. Dit zou als slechte praktijk worden beschouwd in een server, maar bij het werken met een SAN (die in theorie veel kritischer is dan een op zichzelf staande server) wordt zorgvuldige planning van het opslagsubsysteem vaak achterwege gelaten op basis van de overtuiging dat de SAN die problemen op de een of andere manier heeft opgelost of dat ze niet van toepassing zijn. Het is waar dat sommige hoogwaardige SAN's wel degelijk een zekere mate van risicobeperkende functies hebben die elders waarschijnlijk niet te vinden zijn, maar deze zijn zeldzaam en uitsluitend voorbehouden aan zeer hoogwaardige units waar het gebruik van broze ontwerpen toch al ongebruikelijk zou zijn. Het is een gevaarlijke, maar zeer gangbare praktijk om grote zorg en aandacht te besteden aan de planning van opslag voor een fysieke server, maar bij het gebruik van een SAN diezelfde planning en controle vaak over te slaan op basis van de aanname dat de SAN dit alles intern afhandelt of dat het simpelweg niet langer nodig is.

Nu ik veel misvattingen over SAN's heb weerlegd, vraagt men zich wellicht af of SAN's ooit wel passend zijn. Dat zijn ze natuurlijk; ze zijn zeer belangrijk en ongelooflijk waardevol wanneer ze correct worden gebruikt. De sterkste punten van SAN's komen voort uit consolidatie en bijzondere typen gedeelde opslag.

Consolidatie was de historische drijfveer die klanten naar SAN-oplossingen bracht. Een SAN stelt ons in staat om vele bestandssystemen te combineren in één enkele schijfarray, waardoor opslagbronnen veel efficiënter benut kunnen worden. Omdat SAN op blokniveau werkt, kan het dit doen op elk moment dat een traditioneel, lokaal schijfsubsysteem ingezet zou kunnen worden. In veel servers, en zelfs veel desktops, gaat opslagruimte verloren door de noodzaken van groei, planning en de granulariteit van schijfcapaciteit. Als we twintig servers hebben, elk met schijfarrays van 300 GB, maar die elk slechts 80 GB van die capaciteit gebruiken, hebben we grote verspilling. Met een SAN zouden we kunnen consolideren tot slechts 1,6 TB plus een kleine hoeveelheid die nodig is voor overhead, en veel minder uitgeven aan fysieke schijven dan wanneer elke server zijn eigen opslag zou beheren.

Zodra we beginnen met het consolideren van opslag, gaan we op zoek naar geavanceerde consolidatiemogelijkheden. Nu we veel serverbestandssystemen op één enkele SAN hebben geconsolideerd, hebben we de kans, mits onze SAN-implementatie dit ondersteunt, om die gegevens te dedupliceren en te comprimeren, wat in veel gevallen, zoals bij serverbestandssystemen, mogelijk kan resulteren in een aanzienlijke vermindering van het gebruik. Dus onze 1,6 TB in het bovenstaande voorbeeld zou uiteindelijk weleens slechts 800 GB of minder kunnen blijken te zijn. Plotseling worden onze consolidatiecijfers steeds beter.

Om consolidatie efficiënt te benutten is schaal noodzakelijk, en dit is waar SAN's echt schitteren – wanneer de schaal, zowel in capaciteit als, belangrijker nog, in het aantal aangesloten nodes, zeer groot wordt. SAN's zijn het meest geschikt voor grootschalige opslagconsolidatie. Dit is hun specialiteit en wat ze vrijwel alomtegenwoordig maakt in grote ondernemingen en zeer zeldzaam in kleine.

SAN's zijn ook zeer belangrijk voor bepaalde typen clustering en gedeelde opslag die toegang tot één enkel gedeeld bestandssysteem vereisen. Dit is eigenlijk een vrij zeldzame behoefte buiten één bijzondere omstandigheid – databases. De meeste applicaties zijn tevreden met elk type opslag dat hun wordt geboden, maar databases vereisen vaak bloktoegang op laag niveau om hun gegevens zo effectief mogelijk te kunnen manipuleren. Hierdoor kunnen ze zelden, of zelden effectief, op NAS of bestandsservers worden gebruikt. Het bieden van highavailability-opslagomgevingen voor databaseclusters is al lange tijd een belangrijke use case van SAN-opslag.

Buiten deze twee primaire use cases, die het overgrote deel van de SAN-installaties rechtvaardigen, biedt een SAN ook een hoge mate van opslagflexibiliteit door het potentieel zeer eenvoudig te maken om opslag in een grote omgeving te verplaatsen, uit te breiden en aan te passen zonder fysieke verplaatsingen of ingewikkelde aanschaf en provisioning. Net als bij consolidatie is dit, nogmaals, een gevolg van grote schaal.

In zeer grote omgevingen kan het gebruik van een SAN ook worden ingezet om een scheidslijn aan te brengen tussen de opslag- en de systeemengineeringteams, waardoor er een overdracht op de netwerklaag kan plaatsvinden, doorgaans van Fibre Channel of iSCSI. Deze duidelijke scheiding van taken kan cruciaal zijn om teams sterk gescheiden te houden in bedrijven die zeer afgescheiden opslag-, netwerk- en systeemteams willen. Hierdoor kan het opslagteam zich uitsluitend op opslag richten en het systeemteam zich uitsluitend op de systemen, zonder dat enige kennis van de implementaties van het andere team nodig is.

Lange tijd presenteerden SAN's zich ook als een handig middel om de opslagprestaties te verbeteren. Dit is geen intrinsieke eigenschap van een SAN, maar een uitvloeisel van hun gangbare gebruik voor consolidatie. Net als bij virtualisatie wanneer die voor consolidatie wordt gebruikt, hebben gedeelde SAN's van nature het voordeel van een betere benutting van de beschikbare spindels, gecentraliseerde caches en grotere hardware dan de equivalente opslag die over veel afzonderlijke servers is verspreid. Net als bij gedeelde CPU-bronnen heeft de SAN, wanneer hij geen aanvragen van meerdere clients ontvangt, de mogelijkheid om al zijn capaciteit te wijden aan het bedienen van de aanvragen van één enkele client, wat een gemiddelde prestatie-ervaring oplevert die mogelijk veel hoger ligt dan wat een afzonderlijke server op betaalbare wijze zelf zou kunnen bereiken.

Het gebruik van een SAN voor prestaties raakt echter snel uit de gratie, vanwege de opkomst van SSD-opslag die zeer gangbaar wordt. Naarmate SSD's met een ongelooflijk lage latentie en hoge IOPS-prestaties in prijs dalen tot het punt waarop ze aan op zichzelf staande servers worden toegevoegd als lokale cache of mogelijk zelfs als hoofdopslag worden gebruikt, wordt het knelpunt van de netwerkverbinding van de SAN een steeds grotere factor, waardoor het steeds moeilijker wordt voor de consolidatievoordelen van een SAN om de prestatievoordelen van lokale SSD's te compenseren. SSD's zijn potentieel zeer disruptief voor de markt van gedeelde opslag, omdat ze het prestatievoordeel terugbrengen naar lokale opslag – gewoon de nieuwste beweging in de eb en vloed van het ontwerp van opslagarchitectuur.

Het belangrijkste aspect van SAN-gebruik om te onthouden is dat een SAN geen standaard uitgangspunt zou moeten zijn bij opslagplanning. Het is een van de vele technologiekeuzes, en een die vaak niet aan de verwachtingen voldoet zoals bedoeld, of dat wel doet maar tegen een onnodig hoog prijspunt, hetzij in geldelijke termen, hetzij in termen van complexiteit. Begin met het definiëren van de bedrijfsdoelen en -behoeften. Kies een SAN wanneer die deze behoeften het meest effectief oplost, maar houd een open blik en overweeg de algehele opslagbehoeften van de omgeving.