När bör man överväga ett SAN?

Alla verkar vilja kasta sig in i att köpa ett SAN, ibland ganska passionerat. SAN:er är, måste man medge, ganska häftiga. De är ett av de roligare och mer spännande storskaliga hårdvaruföremålen som de flesta IT-proffs får chansen att ha i sin egen verkstad. Ofta är önskan att ha ett eget SAN en fråga om att “hänga med grannarna” eftersom det att använda ett SAN har blivit lite av en statussymbol – en av de sista bastionerna inom storföretags-IT som man bara ser i ett dedikerat serverskåp och aldrig i någons hem (nåja, nästan aldrig.) SAN:er marknadsförs hårt, annonseras och säljs som fantastiska lådor med intern redundans som gör dem ofelbara, med hastighet som trotsar logiken och fullmatade med funktioner som du aldrig visste att du behövde. När jag talar med IT-proffs som designar nya system är en av de vanligaste designaspekterna jag hör “ja, vi vet inte så mycket om vår slutgiltiga design, men vi vet att vi behöver ett SAN.”

I kontexten av denna artikel använder jag SAN i dess vanligaste betydelse, det vill säga för att avse en “blocklagringsenhet” och inte för att syfta på hela lagringsnätverket i sig. Ett lagringsnätverk kan finnas för NAS men över huvud taget inte använda en SAN-blocklagringsenhet. Så i denna artikel syftar SAN uteslutande på SAN som en enhet, inte SAN som ett nätverk. SAN är en luddig term som används för att betyda flera olika saker vid olika tillfällen och kan bli ganska förvirrande. Ett SAN konfigurerat utan ett nätverk blir DAS. DAS som nätverksansluts blir SAN.

Låt oss stanna upp ett ögonblick. SAN är din backend-lagring. Behovet av den skulle i samtliga fall avgöras av andra aspekter av din arkitektur. Om du ännu inte har beslutat om många andra delar kan du helt enkelt inte veta att ett SAN kommer att behövas, eller ens vara användbart, i den slutgiltiga designen. Varningsflaggor. Varningsflaggor överallt. Föreställ dig en romersk vagnkapplöpning där hästarna skjuter på vagnarna (om du förstår vad jag menar.)

Det står klart att drivkraften att implementera ett SAN är så stark att hela projekt ofta tas fram med föga syfte annat än, tycks det, att rättfärdiga köpet av SAN:et. Som med vilket projekt som helst är den första frågan man måste ställa “Vilket affärsbehov är det vi försöker tillgodose?” Och arbeta utifrån det, inte “Vi vill köpa ett SAN, var kan vi använda det?” SAN:er är komplexa, och med komplexitet kommer ömtålighet. Mycket ofta medför SAN:er hög kostnad. Men den skrämmande aspekten av ett SAN är den utbredda bristen på djup branschkunskap om dem. SAN:er innebär enorma tekniska och affärsmässiga risker som måste övervinnas för att rättfärdiga deras användning. SAN:er är utan tvekan mycket spännande och tämligen användbara, men det är sällan tillräckligt gott nog för att motivera önskan om ett.

Vi kallar SAN:er för “lagringen i sista hand.” Vad detta innebär är att när man väljer typer av lagring hoppas man att man kan använda något av de andra alternativen såsom lokala diskar, DAS (Direct Attach Storage) eller NAS (Network Attached Storage) snarare än SAN. För det mesta fungerar andra alternativ utmärkt. Men det finns tillfällen då affärsbehoven ställer krav som rimligen endast kan tillgodoses med ett SAN. När sådana uppstår har vi inget val och måste använda ett SAN. Men i allmänhet kan det undvikas till förmån för enklare och normalt mindre kostsamma eller riskfyllda alternativ.

Jag finner att de flesta som vill implementera ett SAN gör det under ett antal missuppfattningar.

Den första är att SAN:er, till sin natur, är mycket tillförlitliga. Även om det förvisso finns många SAN-leverantörer och specifika SAN-produkter som är häpnadsväckande tillförlitliga, kan samma sägas om vilken IT-produkt som helst. Avancerade servrar i samma prisklass som avancerade SAN:er är minst lika tillförlitliga som SAN:er. Eftersom SAN:er är tillverkade av samma hårdvarukomponenter som vanliga servrar finns det ingen magi i att göra dem mer tillförlitliga. Allt som kan användas för att göra ett SAN tillförlitligt är ett nedsippringseffekt av server-RAS-tekniker (Reliability, Availability and Serviceability). Precis som SAN kan NAS och DAS, liksom lokala diskar, göras otroligt tillförlitliga. SAN syftar endast på att enheten används för att tillhandahålla blocklagring snarare än att utföra någon annan uppgift. Ett SAN är bara en mycket enkel server. SAN:er omfattar hela tillförlitlighetsspektrumet med stordator-liknande tillförlitlighet i den övre änden och enheter som inte är något annat än externa hårddiskar – de minst tillförlitliga nätverksenheterna i ditt nätverk – i den nedre änden. Så snarare än att SAN betyder tillförlitlighet erbjuder det faktiskt några specialfall av att vara den lägsta tillförlitlighet man kan föreställa sig. Men i praktiken delar alla servrar ungefär likvärdiga tillförlitlighetsbekymmer. SAN:er får ett rykte om tillförlitlighet eftersom verksamheter ofta lägger extrema budgetar på sina SAN:er som de inte lägger på sina servrar, så att jämförelsen blir mellan ett relativt avancerat SAN och en relativt budgetserver.

Den andra är att SAN betyder “stor” och NAS betyder “liten.” Det finns inget sådant samband. Både SAN:er och NAS:er kan vara av nästan vilken skala eller kvalitet som helst. De täcker båda hela skalan och det finns inte den minsta antydan från den valda tekniken om huruvida en enhet är stor eller inte. Återigen, som ovan, kan SAN faktiskt tekniskt sett bli “mindre” än en NAS-lösning på grund av sin möjliga enkelhet, men detta är ett specialfall och mestadels endast teoretiskt, även om det finns SAN-produkter på marknaden som tillhör denna kategori, men de är mycket sällsynta att finna i användning.

Den tredje är att SAN och NAS är dramatiskt olika inuti chassit. Detta är förvisso inte fallet, eftersom majoriteten av SAN- och NAS-enheter idag är vad som kallas “unified storage” (enhetlig lagring), vilket innebär en lagringsappliance som samtidigt fungerar som både SAN och NAS. Detta belyser att den huvudsakliga skillnaden mellan de två inte ligger i backend-teknik eller hårdvara eller storlek eller tillförlitlighet, utan att den avgörande skillnaden är de protokoll som används för att överföra lagring. SAN:er är blocklagring som exponerar råa blockenheter på nätverket med hjälp av protokoll som fibre channel, iSCSI, SAS, ZSAN, ATA over Ethernet (AoE) eller Fibre Channel over Ethernet (FCoE.) NAS, å andra sidan, använder ett nätverksfilsystem och exponerar filer på nätverket med hjälp av applikationslagerprotokoll som NFS, SMB, AFP, HTTP och FTP, vilka sedan färdas över TCP/IP.

Den fjärde är att SAN:er till sin natur är en fildelningsteknik. Detta är NAS. SAN tar helt enkelt din blocklagring (hårddisksubsystem) och gör den fjärrtillgänglig över ett nätverk. Nätverkens natur antyder att vi kan ansluta den lagringen till flera enheter samtidigt och det kan vi förvisso, fysiskt sett. Precis som vi förr kunde fysiskt ansluta flera styrenheter till motsatta ändar av en SCSI-bandkabel med hårddiskar hängande i mitten. Detta kommer, under normala omständigheter, att förstöra all data på diskarna eftersom styrenheterna, som inte vet något om varandra, skriver över varandras data och orsakar nästintill omedelbar korruption. Det finns mekanismer tillgängliga i särskilda klustrade filsystem och deras drivrutiner som möjliggör detta, men detta kräver särskild kunskap och förståelse som är långt mer teknisk än vad många som skaffar SAN:er är medvetna om att de behöver för vad de ofta tror är själva syftet med SAN:et – en katastrof så vanlig att jag förmodligen talar med någon som har gjort just detta nästan varje vecka. Att SAN:et utsätter just det användningsfall som de flesta tror att det är designat för att hantera för risk, och inte bara misslyckas med att leverera det nästan magiska skydd man söker utan tvärtom är själva orsaken till dataförlusten, blottlägger den nivå av risk som implementerad missförstådd lagringsteknik bär med sig.

Den femte är att SAN:er är snabba. SAN:er kan vara snabba; de kan också vara fasansfullt långsamma. Det finns ingen inneboende hastighetsökning från användningen av SAN-teknik i sig. Det är faktiskt ganska svårt för SAN:er att övervinna de inneboende flaskhalsar som introduceras av nätverket de sitter på. Eftersom vissa andra lagringsalternativ såsom DAS använder alla samma tekniker som SAN men saknar flaskhalsen och latensen hos det faktiska nätverket, kommer en motsvarande DAS också att vara en aning snabbare än sin SAN-motsvarighet. SAN:er är i allmänhet en aning snabbare än en hårdvaruidentisk NAS-motsvarighet, men inte ens detta är garanterat. SAN och NAS beter sig olika och i olika användningsfall kan endera vara den med bättre prestanda. SAN skulle sällan väljas som en lösning baserat på prestandabehov.

Den sjätte är att i och med att vara ett SAN gäller inte längre de inneboende problem som är förknippade med lagringsval. Ett bra exempel är användningen av RAID 5. Detta skulle anses vara dålig praxis att göra i en server, men när man arbetar med ett SAN (som i teorin är långt mer kritiskt än en fristående server) frångås ofta noggrann planering av lagringssubsystemet baserat på en tro att SAN:et på något sätt har åtgärdat de problemen eller att de inte gäller. Det är sant att vissa avancerade SAN:er har en viss mängd riskreducerande funktioner som sannolikt inte återfinns någon annanstans, men dessa är sällsynta och uteslutande förpassade till mycket avancerade enheter där användningen av ömtåliga designer redan skulle vara ovanlig. Det är en farlig, men mycket vanlig praxis att lägga stor omsorg och eftertanke vid planering av lagring för en fysisk server, men att när ett SAN används samma planering och översyn ofta hoppas över baserat på antagandet att SAN:et hanterar allt det internt eller att det helt enkelt inte längre behövs.

Efter att ha avfärdat många missuppfattningar om SAN kanske man undrar om SAN:er någonsin är lämpliga. De är naturligtvis mycket viktiga och otroligt värdefulla när de används korrekt. SAN:ernas starkaste sidor kommer från konsolidering och särskilda typer av delad lagring.

Konsolidering var den historiska drivkraften som förde kunder till SAN-lösningar. Ett SAN låter oss kombinera många filsystem till en enda diskarray vilket möjliggör en långt effektivare användning av lagringsresurser. Eftersom SAN är på blocknivå kan det göra detta närhelst ett traditionellt, lokalt disksubsystem skulle kunna användas. I många servrar, och även många stationära datorer, slösas lagringsutrymme bort på grund av nödvändigheterna kring tillväxt, planering och diskkapacitetens granularitet. Om vi har tjugo servrar var och en med diskarrayer på 300 GB men där var och en endast använder 80 GB av den kapaciteten har vi stort slöseri. Med ett SAN skulle vi kunna konsolidera till endast 1,6 TB plus en liten mängd nödvändig för overhead och spendera långt mindre på fysiska diskar än om varje server upprätthöll sin egen lagring.

När vi väl börjar konsolidera lagring börjar vi söka efter avancerade konsolideringsmöjligheter. Efter att ha konsoliderat många serverfilsystem på ett enda SAN har vi möjligheten, om vår SAN-implementation stöder det, att deduplicera och komprimera den datan, vilket i många fall såsom serverfilsystem potentiellt kan resultera i betydande minskning av utnyttjandet. Så våra 1,6 TB i vårt exempel ovan skulle faktiskt kunna sluta som endast 800 GB eller mindre. Plötsligt blir våra konsolideringssiffror bättre och bättre.

För att effektivt utnyttja konsolidering är det nödvändigt att ha skala och det är här SAN:er verkligen briljerar – när skalan, både i kapacitet och, ännu viktigare, i antalet anslutande noder, blir mycket stor. SAN:er lämpar sig bäst för storskalig lagringskonsolidering. Detta är deras paradgren och det som gör dem nästan allestädes närvarande i stora företag och mycket sällsynta i små.

SAN:er är också mycket viktiga för vissa typer av klustring och delad lagring som kräver åtkomst till ett enda delat filsystem. Detta är faktiskt ett ganska sällsynt behov utanför en särskild omständighet – databaser. De flesta applikationer är nöjda med att utnyttja vilken typ av lagring som helst som tillhandahålls dem, men databaser kräver ofta lågnivå-blocktillgång för att kunna manipulera sin data korrekt och mest effektivt. På grund av detta kan de sällan användas, eller användas effektivt, på NAS eller filservrar. Att tillhandahålla högtillgängliga lagringsmiljöer för databaskluster har länge varit ett centralt användningsfall för SAN-lagring.

Utöver dessa två primära användningsfall, som rättfärdigar den stora majoriteten av SAN-installationer, ger SAN också höga nivåer av lagringsflexibilitet genom att potentiellt göra det mycket enkelt att flytta, utöka och modifiera lagring i en stor miljö utan att behöva hantera fysiska flyttar eller komplicerad anskaffning och tillhandahållande. Återigen, liksom konsolidering, är detta en artefakt av stor skala.

I mycket stora miljöer kan användningen av SAN också användas för att tillhandahålla en demarkationspunkt mellan lagrings- och systemingenjörsteam vilket möjliggör en överlämning på nätverkslagret, i allmänhet fibre channel eller iSCSI. Denna tydliga uppdelning av ansvar kan vara avgörande för att möjliggöra att team är starkt åtskilda i företag som vill ha mycket separata lagrings-, nätverks- och systemteam. Detta gör att lagringsteamet kan göra ingenting annat än att fokusera på lagring och systemteamet ingenting annat än att fokusera på systemen utan något behov av kunskap om det andra teamets implementationer.

Under lång tid framställde sig SAN:er också som ett bekvämt sätt att förbättra lagringsprestanda. Detta är inte en inneboende komponent i SAN utan en följd av deras vanliga användning för konsolidering. På liknande sätt som virtualisering när den används som konsolidering, kommer delade SAN:er att ha en naturlig fördel av att ha bättre utnyttjande av tillgängliga spindlar, centraliserade cachar och större hårdvara än motsvarande lagring utspridd bland många enskilda servrar. Liksom delade CPU-resurser har SAN:et, när det inte tar emot förfrågningar från flera klienter, möjligheten att ägna hela sin kapacitet åt att betjäna en enda klients förfrågningar, vilket ger en genomsnittlig prestandaupplevelse som potentiellt är långt högre än vad en enskild server skulle kunna uppnå på ett ekonomiskt försvarbart sätt på egen hand.

Att använda SAN för prestanda håller emellertid snabbt på att falla ur favör på grund av att SSD-lagring har blivit mycket vanligt. I takt med att SSD:er med otroligt låg latens och hög IOPS-prestanda sjunker i pris till den punkt där de läggs till i fristående servrar som lokal cache eller potentiellt till och med används som huvudsaklig lagring, blir flaskhalsen i SAN:ets nätverk en allt större faktor vilket gör det allt svårare för konsolideringsfördelarna med ett SAN att uppväga prestandafördelarna med lokala SSD:er. SSD:er är potentiellt mycket omstörtande för marknaden för delad lagring eftersom de för tillbaka prestandafördelen mot lokal lagring – bara det senaste i lagringsarkitekturdesignens ständiga ebb och flod.

Den viktigaste aspekten av SAN-användning att komma ihåg är att SAN inte bör vara en standardutgångspunkt i lagringsplanering. Det är ett av många teknikval och ett som ofta inte motsvarar förväntningarna som avsett, eller gör det men till en onödigt hög prisnivå antingen i monetära termer eller i termer av komplexitet. Börja med att definiera affärsmål och behov. Välj SAN när det löser dessa behov mest effektivt, men håll ett öppet sinne och beakta miljöns övergripande lagringsbehov.