Hvornår bør man overveje en SAN?

Alle ser ud til at ville kaste sig ud i at købe en SAN, nogle gange med stor iver. SAN'er er, indrømmet, ret fede. De er en af de sjovere og mere spændende, storskalerede hardwarekomponenter, som de fleste IT-fagfolk får chancen for at have i deres eget miljø. Ofte er ønsket om at have sin egen SAN et spørgsmål om at “følge med naboerne”, da brugen af en SAN er blevet noget af et statussymbol – et af de sidste bastioner af stor-virksomheds-IT, som man kun ser i et dedikeret serverrum og aldrig hjemme hos nogen (ja, næsten aldrig). SAN'er markedsføres kraftigt, reklameres for og sælges som fantastiske bokse med intern redundans, der gør dem ufejlbarlige, med hastigheder der trodser logik og fyldt med funktioner, man aldrig vidste man havde brug for. Når jeg taler med IT-fagfolk, der designer nye systemer, er et af de mest almindelige designaspekter, jeg hører: “Vi ved ikke meget om vores endelige design, men vi ved, at vi har brug for en SAN.”

I sammenhæng med denne artikel bruger jeg SAN i den mest almindelige betydning, det vil sige som en “blok-lagerenhed” og ikke som reference til selve lagernetværket. Et lagernetværk kan eksistere til NAS uden at anvende en SAN-blokenhed overhovedet. I denne artikel refererer SAN derfor udelukkende til SAN som en enhed, ikke SAN som et netværk. SAN er et løst begreb, der bruges til at betyde flere ting på forskellige tidspunkter og kan blive ret forvirrende. En SAN konfigureret uden netværk bliver DAS. DAS der sættes i netværk bliver SAN.

Lad os stoppe et øjeblik. SAN er din backend-lagring. Behovet for den ville i alle tilfælde være bestemt af andre aspekter af din arkitektur. Hvis du endnu ikke har besluttet dig om mange andre elementer, kan du simpelthen ikke vide, at en SAN kommer til at være nødvendig, eller endog nyttig, i det endelige design. Røde flag. Røde flag overalt. Forestil dig et romersk væddeløb med heste, der skubber stridsvognene (hvis du forstår, hvad jeg mener).

Det er tydeligt, at drivkraften bag at implementere en SAN er så stærk, at hele projekter ofte udtænkes med ringe andet formål end, det ser ud til, at retfærdiggøre købet af SAN'en. Som med ethvert projekt er det første spørgsmål, man skal stille sig selv: “Hvad er det forretningsbehov, vi forsøger at opfylde?” Og arbejde derfra, ikke: “Vi vil købe en SAN, hvor kan vi bruge den?” SAN'er er komplekse, og med kompleksitet følger skrøbelighed. SAN'er medfører meget ofte høje omkostninger. Men det mest skræmmende aspekt af en SAN er den udbredte mangel på dyb brancheviden om dem. SAN'er udgør enorm teknisk og forretningsmæssig risiko, der skal overvindes for at retfærdiggøre deres brug. SAN'er er, uden tvivl, meget spændende og ganske nyttige, men det er sjældent godt nok til at berettige ønsket om en.

Vi omtaler SAN'er som “lagringsvalget som sidste udvej.” Det betyder, at man ved valg af lagringstyper håber, at man kan bruge et af de andre alternativer som lokale drev, DAS (Direct Attach Storage) eller NAS (Network Attached Storage) frem for SAN. De fleste gange fungerer andre muligheder fremragende. Men der er tidspunkter, hvor forretningsbehovene stiller krav, der kun med rimelighed kan imødekommes med en SAN. Når de opstår, har man intet valg og må bruge en SAN. Men generelt kan det undgås til fordel for enklere og normalt mindre kostbare eller risikable muligheder.

Jeg finder, at de fleste, der ønsker at implementere en SAN, gør det på baggrund af en række misforståelser.

Den første er, at SAN'er i sagens natur er meget pålidelige. Selvom der bestemt er mange SAN-leverandører og specifikke SAN-produkter, der er forbløffende pålidelige, kan det samme siges om ethvert IT-produkt. High-end servere i prisklassen for high-end SAN'er er mindst lige så pålidelige som SAN'er. Da SAN'er er lavet af de samme hardwarekomponenter som normale servere, er der ingen magi i at gøre dem mere pålidelige. Alt, der kan bruges til at gøre en SAN pålidelig, er en nedsivning af server-RAS (Reliability, Availability and Serviceability)-teknologier. Ligesom SAN kan NAS og DAS samt lokale diske gøres utroligt pålidelige. SAN refererer blot til den enhed, der bruges til at levere bloklager frem for at udføre en anden opgave. En SAN er blot en meget simpel server. SAN'er dækker hele spektret af pålidelighed – fra mainframe-lignende pålidelighed i den høje ende til enheder, der ikke er andet end eksterne harddiske – de mest upålidelige netværksenheder på dit netværk – i den lave ende. Så i stedet for at SAN betyder pålidelighed, tilbyder den faktisk et par særlige tilfælde af at være den laveste pålidelighed, man kan forestille sig. Men for alle praktiske formål deler alle servere nogenlunde ens pålideligheds-bekymringer. SAN'er får et ry for pålidelighed, fordi virksomheder ofte lægger ekstreme budgetter i deres SAN'er, som de ikke lægger i deres servere, så sammenligningen er en relativt high-end SAN over for en relativt budgetvenlig server.

Den anden er, at SAN betyder “stor” og NAS betyder “lille.” Der er ingen sådan sammenhæng. Både SAN'er og NAS'er kan have næsten enhver skala eller kvalitet. De spænder begge over hele spektret, og der er ikke den mindste antydning fra den valgte teknologi om, hvorvidt en enhed er stor eller ej. Igen, som ovenfor, kan SAN faktisk teknisk set komme “mindre” end en NAS-løsning på grund af dens mulige enkelhed, men dette er et specialtilfælde og mest kun teoretisk, selvom der er SAN-produkter på markedet i denne kategori – bare meget sjældne at finde i brug.

Den tredje er, at SAN og NAS er dramatisk forskellige indeni chassiset. Dette er bestemt ikke tilfældet, da størstedelen af SAN- og NAS-enheder i dag er det, der kaldes “unified storage”, hvilket betyder en lagerapplikation, der fungerer som både SAN og NAS på samme tid. Dette understreger, at den vigtigste forskel mellem de to ikke ligger i backend-teknologi, hardware, størrelse eller pålidelighed, men at den definerende forskel er de protokoller, der bruges til at overføre lagring. SAN'er er bloklager, der eksponerer rå blokenheder på netværket ved hjælp af protokoller som fibre channel, iSCSI, SAS, ZSAN, ATA over Ethernet (AoE) eller Fibre Channel over Ethernet (FCoE). NAS bruger derimod et netværksfilsystem og eksponerer filer på netværket ved hjælp af applikationslag-protokoller som NFS, SMB, AFP, HTTP og FTP, som så kører over TCP/IP.

Den fjerde er, at SAN'er i sagens natur er en fildeling-teknologi. Dette er NAS. SAN er blot at tage din bloklager (harddisk-undersystem) og gøre den tilgængelig eksternt over et netværk. Netværkets natur antyder, at vi kan tilslutte denne lagring til flere enheder på én gang, og faktisk kan vi fysisk gøre det. Ligesom vi engang var i stand til fysisk at tilslutte flere controllere til modstående ender af et SCSI-ribbon-kabel med harddiske hængende i midten. Dette vil under normale omstændigheder ødelægge alle data på drevene, da controllerne, der intet ved om hinanden, overskriver hinandens data og forårsager næsten øjeblikkelig korruption. Der er mekanismer tilgængelige i specielle klyngede filsystemer og deres drivere til at tillade dette, men det kræver speciel viden og forståelse, som er langt mere teknisk, end mange der anskaffer SAN'er er klar over, at de har brug for, hvad de ofte tror er selve formålet med SAN'en – en katastrofe så almindelig, at jeg sandsynligvis taler med nogen, der har gjort præcis dette næsten ugentligt. At SAN'en sætter i fare netop den anvendelse, som de fleste tror, den er designet til at håndtere, og ikke blot svigter med at levere den næsten magiske beskyttelse, der efterspørges, men tværtimod er selve årsagen til datatabet, afslører det risikoniveau, som implementering af misforstået lagringsteknologi medfører.

Den femte er, at SAN'er er hurtige. SAN'er kan være hurtige; de kan også være forfærdeligt langsomme. Der er ingen iboende hastighedsforøgelse ved brug af SAN-teknologi i sig selv. Det er faktisk ret vanskeligt for SAN'er at overvinde de iboende flaskehalse, som det netværk, de befinder sig på, introducerer. Da nogle andre lagringsmuligheder som DAS bruger alle de samme teknologier som SAN men mangler flaskehalsen og latensen fra det faktiske netværk, vil en tilsvarende DAS også være en smule hurtigere end sin SAN-pendant. SAN'er er generelt en smule hurtigere end en hardwaremæssigt identisk NAS-pendant, men selv dette er ikke garanteret. SAN og NAS opfører sig forskelligt, og i forskellige anvendelsestilfælde kan den ene eller den anden præstere bedre. SAN ville sjældent blive valgt som løsning baseret på ydeevnebehov.

Den sjette er, at ved at være en SAN gælder de iboende problemer forbundet med lagringsvalg ikke længere. Et godt eksempel er brugen af RAID 5. Dette ville betragtes som dårlig praksis i en server, men når man arbejder med en SAN (som teoretisk set er langt mere kritisk end en standalone-server), bliver omhyggelig planlægning af lagr-undersystemet ofte tilsidesat baseret på en tro om, at det at være en SAN på en eller anden måde har løst disse problemer, eller at de ikke gælder. Det er sandt, at nogle high-end SAN'er har en vis mængde risikobegrænsende funktioner, der sandsynligvis ikke vil blive fundet andre steder, men disse er sjældne og udelukkende forbeholdt meget high-end enheder, hvor brug af skrøbelige designs allerede ville være usædvanligt. Det er en farlig, men meget almindelig praksis at tage stor omhu og hensyn ved planlægning af lagring til en fysisk server, men når man bruger en SAN, springes den samme planlægning og tilsyn ofte over baseret på antagelsen om, at SAN'en håndterer alt det internt, eller at det simpelthen ikke længere er nødvendigt.

Efter at have aflivet mange misforståelser om SAN undrer man sig måske over, om SAN'er nogensinde er hensigtsmæssige. De er selvfølgelig ganske vigtige og utroligt værdifulde, når de bruges korrekt. De stærkeste fordele ved SAN'er stammer fra konsolidering og særlige typer af delt lagring.

Konsolidering var den historiske drivkraft, der bragte kunder til SAN-løsninger. En SAN giver os mulighed for at kombinere mange filsystemer i et enkelt diskarray, hvilket muliggør langt mere effektiv udnyttelse af lagerressourcer. Fordi SAN er på blokniveau, er den i stand til at gøre dette, når som helst et traditionelt, lokalt disk-undersystem kunne anvendes. I mange servere, og endda mange desktops, spildes lagerplads på grund af nødvendigheder for vækst, planlægning og diskkapacitets-granularitet. Hvis vi har tyve servere, hver med 300 GB diskarray, men hver kun bruger 80 GB af den kapacitet, har vi et stort spild. Med en SAN kunne vi konsolidere til blot 1,6 TB plus en lille mængde nødvendig til overhead og bruge langt mindre på fysiske diske, end hvis hver server opretholdt sin egen lagring.

Når vi begynder at konsolidere lagring, begynder vi at lede efter avancerede konsolideringsmuligheder. Efter at have konsolideret mange serverfilsystemer på en enkelt SAN har vi chancen, hvis vores SAN-implementering understøtter det, for at deduplikere og komprimere disse data, hvilket i mange tilfælde, som serverfilsystemer, potentielt kan resultere i betydelig reduktion af udnyttelsen. Så vores 1,6 TB i eksemplet ovenfor kan måske faktisk ende med at være kun 800 GB eller mindre. Pludselig bliver vores konsolideringstal bedre og bedre.

For effektivt at udnytte konsolidering er det nødvendigt at have skala, og det er her, SAN'er virkelig skinner – når skala, men i kapacitet og, endnu vigtigere, i antallet af tilsluttede noder, bliver meget stort. SAN'er er bedst egnet til storskaleret lagerkonsolidering. Det er deres sweet spot og det, der gør dem næsten allestedsnærværende i store virksomheder og meget sjældne i små.

SAN'er er også meget vigtige for visse typer af klyngning og delt lagring, der kræver adgang til et enkelt delt filsystem. Dette er faktisk et ret sjældent behov uden for én særlig omstændighed – databaser. De fleste applikationer er glade for at bruge enhver type lagring, der leveres til dem, men databaser kræver ofte lavniveau-blokadgang for at kunne manipulere deres data mest effektivt. På grund af dette kan de sjældent bruges, eller bruges effektivt, på NAS eller filservere. At levere lageringsmiljøer med høj tilgængelighed til databaseklynger har længe været et centralt anvendelsestilfælde for SAN-lagring.

Ud over disse to primære anvendelsestilfælde, som retfærdiggør den store majoritet af SAN-installationer, giver SAN også mulighed for høje niveauer af lagerfleksibilitet ved at gøre det potentielt meget enkelt at flytte, udvide og ændre lagring i et stort miljø uden at skulle beskæftige sig med fysiske flytninger eller kompliceret anskaffelse og klargøring. Igen, ligesom konsolidering, er dette et artefakt af stor skala.

I meget store miljøer kan brugen af SAN også bruges til at skabe et demarkationspunkt mellem lager- og systemteknikerteams, hvilket giver mulighed for en overdragelse på netværkslaget, generelt af fibre channel eller iSCSI. Denne klare adskillelse af ansvarsområder kan være afgørende for at give teams mulighed for at være stærkt adskilte i virksomheder, der ønsker meget diskrete lager-, netværks- og systemteams. Dette giver lagerteamet mulighed for udelukkende at fokusere på lagring og systemteamet for udelukkende at fokusere på systemerne uden behov for viden om det andet teams implementeringer.

I lang tid præsenterede SAN'er sig også som et praktisk middel til at forbedre lagerydelsen. Dette er ikke en iboende komponent i SAN, men en udløber af deres almindelige brug til konsolidering. På samme måde som virtualisering, når den bruges til konsolidering, vil delte SAN'er naturligt have en fordel ved at have bedre udnyttelse af tilgængelige spindler, centraliserede caches og større hardware end den tilsvarende lagring spredt ud på mange individuelle servere. Ligesom delte CPU-ressourcer, når SAN'en ikke modtager anmodninger fra flere klienter, har den mulighed for at dedikere al sin kapacitet til at betjene anmodningerne fra en enkelt klient, hvilket giver en gennemsnitlig ydeevneoplevelse, der potentielt er langt højere, end hvad en individuel server ville være i stand til at opnå overkommeligt på egen hånd.

Brugen af SAN til ydeevne mister hurtigt popularitet, imidlertid, på grund af fremkomsten af SSD-lagring, der er blevet meget almindelig. Efterhånden som SSD'er med utrolig lav latens og høj IOPS-ydeevne falder i pris til det punkt, hvor de tilføjes til standalone-servere som lokal cache eller potentielt endda bruges som primær lagring, bliver flaskehalsen fra SAN'ernes netværk en større og større faktor, der gør det stadig sværere for konsolideringsfordelene ved en SAN at opveje ydeevnefordelene ved lokale SSD'er. SSD'er er potentielt meget forstyrrende for markedet for delt lagring, da de bringer ydeevnefordelen tilbage mod lokal lagring – blot det seneste i ebb og flow i lagerarkitekturdesign.

Det vigtigste aspekt ved brug af SAN at huske er, at SAN ikke bør være et standardstartpunkt i lagerplanlægning. Det er et af mange teknologivalg og et, der ofte ikke passer til regningen som tilsigtet, eller gør det, men til en unødigt høj pris enten i monetære eller kompleksitetsmæssige termer. Start med at definere forretningsmål og -behov. Vælg SAN, når det løser disse behov mest effektivt, men hold et åbent sind og overvej de overordnede lagringsbehov i miljøet.