Når bør man vurdere en SAN?

Alle ser ut til å ville hoppe inn i kjøp av en SAN, noen ganger ganske lidenskapelig. SAN-er er, innrømmet, ganske kule. De er en av de morsomste og mest spennende storskala maskinvareelementene som de fleste IT-fagfolk får sjansen til å ha i sin egen bedrift. Ønsket om å ha sin egen SAN er ofte et spørsmål om “å henge med i svingene”, ettersom bruk av SAN har blitt noe av et statussymbol – en av de siste bastionene for storforetaks-IT som man bare ser i et dedikert serverrom og aldri hjemme hos noen (vel, nesten aldri). SAN-er markedsføres kraftig, annonseres og selges som fantastiske bokser med intern redundans som gjør dem ufeilbarlige, en hastighet som trosser logikken og lastet med funksjoner man aldri visste man trengte. Når man snakker med IT-fagfolk som designer nye systemer, er ett av de mest vanlige designaspektene jeg hører: “Vi vet ikke mye om det endelige designet vårt, men vi vet at vi trenger en SAN.”

I denne artikkelen bruker jeg SAN i sin vanligste betydning, det vil si å mene en “blokklagringsenhet” og ikke å referere til selve lagringsnettet. Et lagringsnett kan eksistere for NAS uten å bruke en SAN-blokklagringsenhet i det hele tatt. Så i denne artikkelen refererer SAN utelukkende til SAN som enhet, ikke SAN som nettverk. SAN er et fleksibelt begrep som brukes i flere betydninger til ulike tider og kan bli ganske forvirrende. En SAN konfigurert uten nettverk blir DAS. DAS som nettverkstilkobles blir SAN.

La oss stoppe et øyeblikk. SAN er din backend-lagring. Behovet for den vil i alle tilfeller bli bestemt av andre aspekter ved arkitekturen din. Hvis du ikke ennå har bestemt deg for mange andre komponenter, kan du rett og slett ikke vite at en SAN vil være nødvendig, eller til og med nyttig, i det endelige designet. Røde flagg. Røde flagg overalt. Tenk deg et romersk stridsvognsløp der hestene skyver stridsvognene (hvis du skjønner hva jeg mener).

Det er tydelig at drivkraften for å implementere en SAN er så sterk at hele prosjekter ofte utformes med lite annet formål enn, det ser ut til, å rettferdiggjøre kjøpet av SAN-en. Som med ethvert prosjekt er det første spørsmålet man må stille: “Hva er forretningsbehovet vi forsøker å dekke?” Og arbeid derfra, ikke “Vi vil kjøpe en SAN, hvor kan vi bruke den?” SAN-er er komplekse, og med kompleksitet følger skjørhet. Svært ofte er SAN-er kostbare. Men det skumleste aspektet ved en SAN er den utbredte mangelen på dyp bransjekunnskap om dem. SAN-er utgjør stor teknisk og forretningsmessig risiko som må overvinnes for å rettferdiggjøre bruken. SAN-er er uten tvil svært spennende og ganske nyttige, men det er sjelden godt nok til å berettige ønsket om en.

Vi omtaler SAN-er som “siste utvei for lagring.” Det betyr at når man velger lagringstyper, håper man at man kan bruke noen av de andre alternativene som lokale disker, DAS (Direct Attach Storage) eller NAS (Network Attached Storage) fremfor SAN. De fleste ganger fungerer andre alternativer utmerket. Men det er tider når forretningsmessige behov stiller krav som bare med rimelighet kan møtes med en SAN. Når slike situasjoner oppstår, har vi intet valg og må bruke en SAN. Men generelt kan det unngås til fordel for enklere og normalt rimeligere eller mindre risikofylte alternativer.

Jeg opplever at de fleste som ønsker å implementere en SAN gjør det under en rekke misoppfatninger.

Den første er at SAN-er, av sin natur, er svært pålitelige. Selv om det absolutt finnes mange SAN-leverandører og spesifikke SAN-produkter som er utrolig pålitelige, kan det samme sies om ethvert IT-produkt. Høyendeservere i prisklassen til høyende SAN-er er like pålitelige som SAN-er. Siden SAN-er er laget av de samme maskinvarekomponentene som vanlige servere, er det ingen magi involvert for å gjøre dem mer pålitelige. Alt som kan brukes for å gjøre en SAN pålitelig er en videreformidling av server RAS-teknologier (Reliability, Availability and Serviceability). På samme måte som SAN kan NAS og DAS, samt lokale disker, gjøres utrolig pålitelige. SAN refererer kun til enheten som brukes til å levere blokklagring fremfor å utføre en annen oppgave. En SAN er bare en svært enkel server. SAN-er spenner over hele spekteret av pålitelighet, med mainframe-lignende pålitelighet i toppen til enheter som ikke er annet enn eksterne harddisker – de minst pålitelige nettverksenhetene på nettverket ditt – i bunnen. Så snarere enn at SAN betyr pålitelighet, tilbyr det faktisk noen spesielle tilfeller av å være den laveste påliteligheten man kan tenke seg. Men for alle praktiske formål deler alle servere omtrent like pålitelighetshensyn. SAN-er får et rykte for pålitelighet fordi bedrifter ofte legger enorme budsjetter inn i SAN-ene sine som de ikke legger inn i serverne sine, slik at sammenligningen er en relativt høyende SAN mot en relativt budsjettserver.

Den andre er at SAN betyr “stort” og NAS betyr “lite.” Det finnes ingen slik sammenheng. Både SAN-er og NAS-er kan ha nesten hvilken som helst skala eller kvalitet. De dekker begge hele spekteret, og det er ikke det minste antydning fra den valgte teknologien om en enhet er stor eller ikke. Igjen, som nevnt ovenfor, kan SAN faktisk teknisk sett komme “mindre” enn en NAS-løsning på grunn av sin mulige enkelhet, men dette er et spesialtilfelle og stort sett bare teoretisk, selv om det finnes SAN-produkter på markedet i denne kategorien – det er bare svært sjeldent å finne dem i bruk.

Den tredje er at SAN og NAS er dramatisk forskjellige inni kabinettet. Dette er absolutt ikke tilfelle, ettersom flertallet av SAN- og NAS-enheter i dag er det som kalles “unified storage”, det vil si et lagringsapparat som fungerer simultant som både SAN og NAS. Dette understreker at den viktigste forskjellen mellom de to ikke er i backend-teknologi, maskinvare, størrelse eller pålitelighet, men at den definerende forskjellen er protokollene som brukes til å overføre lagring. SAN-er er blokklagring som eksponerer rå blokkenheter på nettverket ved hjelp av protokoller som fibre channel, iSCSI, SAS, ZSAN, ATA over Ethernet (AoE) eller Fibre Channel over Ethernet (FCoE). NAS, derimot, bruker et nettverksfilsystem og eksponerer filer på nettverket ved hjelp av applikasjonslag-protokoller som NFS, SMB, AFP, HTTP og FTP, som deretter kjøres over TCP/IP.

Den fjerde er at SAN-er i seg selv er en fildelingsteknologi. Dette er NAS. SAN er rett og slett å ta blokklagringen din (harddiskdelsystemet) og gjøre den tilgjengelig eksternt over et nettverk. Nettverkets natur antyder at vi kan koble den lagringen til flere enheter samtidig, og faktisk kan vi fysisk gjøre det. Akkurat som vi en gang var i stand til å fysisk koble flere kontrollere til motsatte ender av en SCSI-ribbonkabel med harddisker hengende i midten. Under normale omstendigheter vil dette ødelegge alle dataene på diskene siden kontrollerne, som ikke vet noe om hverandre, overskriver hverandres data og forårsaker nesten øyeblikkelig korrupsjon. Det finnes mekanismer tilgjengelig i spesielle klyngede filsystemer og deres drivere for å tillate dette, men dette krever spesiell kunnskap og forståelse som er langt mer teknisk enn hva mange som anskaffer SAN-er er klar over at de trenger for det de ofte tror er selve formålet med SAN-en – en katastrofe så vanlig at jeg sannsynligvis snakker med noen som har gjort nettopp dette nesten ukentlig. At SAN-en setter i fare nettopp det bruksområdet som de fleste tror den er designet for å håndtere, og ikke bare ikke klarer å levere den nesten magiske beskyttelsen man søkte, men tvert imot er selve årsaken til tap av data, avslører risikonivået som implementering av misforstått lagringsteknologi medfører.

Den femte er at SAN-er er raske. SAN-er kan være raske; de kan også være skremmende trege. Det er ingen iboende hastighetsøkning fra bruk av SAN-teknologi alene. Det er faktisk ganske vanskelig for SAN-er å overvinne de iboende flaskehalsene som introduseres av nettverket de sitter på. Ettersom noen andre lagringsalternativer som DAS bruker alle de samme teknologiene som SAN, men mangler flaskehalsen og forsinkelsen fra selve nettverket, vil en tilsvarende DAS også være litt raskere enn sin SAN-motpart. SAN-er er generelt litt raskere enn en maskinvaremessig identisk NAS-tilsvarende, men selv dette er ikke garantert. SAN og NAS oppfører seg forskjellig, og i ulike bruksscenarier kan enten den ene eller den andre yte bedre. SAN ville sjelden velges som løsning basert på ytelsesbehov.

Den sjette er at ved å være en SAN gjelder ikke lenger de iboende problemene knyttet til lagringsvalg. Et godt eksempel er bruken av RAID 5. Dette ville anses som dårlig praksis i en server, men når man arbeider med en SAN (som i teorien er langt mer kritisk enn en frittstående server) blir nøye planlegging av lagringsdelsystemet ofte forkastet basert på en tro om at det å være en SAN på en eller annen måte har løst disse problemene eller at de ikke gjelder. Det er sant at noen høyende SAN-er har visse risikoreduserende funksjoner som sjelden finnes andre steder, men disse er sjeldne og utelukkende forbeholdt svært høyende enheter der bruk av skjøre design allerede ville vært uvanlig. Det er en farlig, men svært vanlig praksis å ta stor omsorg og hensyn ved planlegging av lagring for en fysisk server, men når man bruker en SAN blir den samme planleggingen og tilsynet ofte hoppet over basert på antagelsen om at SAN-en håndterer alt internt eller at det rett og slett ikke lenger er nødvendig.

Etter å ha avlivet mange misoppfatninger om SAN, lurer man kanskje på om SAN-er noen gang er passende. De er selvsagt ganske viktige og utrolig verdifulle når de brukes riktig. SAN-enes sterkeste sider kommer fra konsolidering og spesielle typer delt lagring.

Konsolidering var den historiske drivkraften som brakte kunder til SAN-løsninger. En SAN lar oss kombinere mange filsystemer i en enkelt diskarraye, noe som muliggjør langt mer effektiv bruk av lagringsressurser. Fordi SAN er på blokknivå, er den i stand til å gjøre dette når som helst et tradisjonelt, lokalt diskdelsystem kunne vært brukt. I mange servere, og til og med mange datamaskiner, blir lagringsplass bortkastet på grunn av nødvendighetene av vekst, planlegging og diskkapasitetsgranularitet. Hvis vi har tjue servere med hver 300 GB diskarrayer, men hver bare bruker 80 GB av den kapasiteten, har vi stort sløseri. Med en SAN kunne vi konsolidere til bare 1,6 TB pluss en liten mengde nødvendig for overhead og bruke langt mindre på fysiske disker enn om hver server opprettholdt sin egen lagring.

Når vi begynner å konsolidere lagring, begynner vi å se etter avanserte konsolideringsmuligheter. Etter å ha konsolidert mange serverfilsystemer på en enkelt SAN har vi sjansen, hvis vår SAN-implementering støtter det, til å deduplisere og komprimere disse dataene, noe som i mange tilfeller – som serverfilsystemer – potensielt kan resultere i betydelig reduksjon i utnyttelse. Så våre 1,6 TB i eksempelet ovenfor kan faktisk ende opp med å være bare 800 GB eller mindre. Plutselig blir konsolideringstallene bedre og bedre.

For å utnytte konsolidering effektivt er det nødvendig å ha skala, og det er her SAN-er virkelig skinner – når skala, både i kapasitet og, viktigere, i antall tilkoblede noder, blir svært stort. SAN-er er best egnet for storskala lagringskonsolidering. Dette er deres sterke side og det som gjør dem nesten allestedsnærværende i store virksomheter og svært sjeldne i små.

SAN-er er også svært viktige for visse typer klynging og delt lagring som krever tilgang til et enkelt delt filsystem. Dette er faktisk et ganske sjeldent behov utenfor én spesiell omstendighet – databaser. De fleste applikasjoner er fornøyde med å bruke hvilken som helst type lagring som tilbys dem, men databaser krever ofte lavnivå blokktilgang for å kunne manipulere dataene sine mest effektivt. På grunn av dette kan de sjelden brukes, eller brukes effektivt, på NAS eller filservere. Tilby høytilgjengelighetslagringsmiljøer for databaseklynger har lenge vært et sentralt bruksscenario for SAN-lagring.

Utenfor disse to primære bruksscenarioene, som rettferdiggjør det store flertallet av SAN-installasjoner, gir SAN også høye nivåer av lagringsfleksibilitet ved å gjøre det potensielt svært enkelt å flytte, vokse og endre lagring i et stort miljø uten å måtte håndtere fysiske flyttinger eller komplisert anskaffelse og klargjøring. Igjen, som konsolidering, er dette et resultat av stor skala.

I svært store miljøer kan bruk av SAN også brukes til å tilby et avskjæringspunkt mellom lager- og systemingeniørteam, noe som muliggjør en overlevering på nettverkslaget, generelt fibre channel eller iSCSI. Denne klare arbeidsdelingen kan være avgjørende for å la team være svært segregerte i selskaper som ønsker svært diskrete lager-, nettverks- og systemteam. Dette lar lagringsteamet fokusere utelukkende på lagring og systemteamet fokusere utelukkende på systemene uten behov for kunnskap om det andre teamets implementeringer.

I lang tid presenterte SAN-er seg også som et praktisk middel for å forbedre lagringsytelse. Dette er ikke en iboende komponent i SAN, men en utløper av deres vanlige bruk til konsolidering. I likhet med virtualisering når det brukes til konsolidering, vil delte SAN-er ha en naturlig fordel av å ha bedre utnyttelse av tilgjengelige spindler, sentraliserte hurtigbuffere og større maskinvare enn tilsvarende lagring spredt over mange individuelle servere. Som delte CPU-ressurser, når SAN-en ikke mottar forespørsler fra flere klienter, har den muligheten til å dedikere all sin kapasitet til å betjene forespørslene til én enkelt klient, noe som gir en gjennomsnittlig ytelsesopplevelse som potensielt er langt høyere enn hva en individuell server kunne oppnå til en overkommelig pris alene.

Bruken av SAN for ytelse er imidlertid raskt i ferd med å miste gunst på grunn av SSD-lagringens inntreden og dens stadig mer utbredte bruk. Ettersom SSD-er med utrolig lav forsinkelse og høy IOPS-ytelse faller i pris til det punktet der de legges til frittstående servere som lokal hurtigbuffer eller potensielt til og med brukes som primær lagring, blir flaskehalsen i SAN-ens nettverk en stadig større faktor som gjør det stadig vanskeligere for konsolideringsfordelene til en SAN å oppveie ytelsesfordelene til lokale SSD-er. SSD-er er potensielt svært forstyrrende for markedet for delt lagring ettersom de bringer ytelsesfordelen tilbake mot lokal lagring – bare det siste i tidevannsbølgen av lagringsarkitekturdesign.

Det viktigste aspektet ved SAN-bruk å huske er at SAN ikke bør være et standard utgangspunkt i lagringsplanlegging. Det er ett av mange teknologivalg og ett som ofte ikke passer til hensikten som tenkt, eller gjør det men til en unødvendig høy pris enten i monetære eller kompleksitetsmessige termer. Start med å definere forretningsmål og behov. Velg SAN når det løser disse behovene mest effektivt, men hold et åpent sinn og vurder de overordnede lagringsbehovene i miljøet.