Jurassic Park-effekten
“Hvis jeg får lov… Eh, jeg skal fortelle deg hva problemet er med den vitenskapelige kraften dere bruker her: det krevde ingen disiplin å oppnå den. Dere leste hva andre hadde gjort og tok det neste steget. Dere fortjente ikke kunnskapen selv, og derfor tar dere ikke noe ansvar for den. Dere sto på skuldrene til genier for å oppnå noe så raskt dere kunne, og før dere engang visste hva dere hadde, patenterte dere det, pakket det inn og slang det på en plastlunsjboks, og nå …” – Dr. Ian Malcolm, Jurassic Park
Når man ser på å bygge en lagringsserver eller NAS, er det en vanlig oppfatning at det man trenger er et «NAS-operativsystem». Dette er en merkelig reaksjon, synes jeg, siden begrepet NAS ikke betyr noe mer enn en «filserver med et dedikert lagringsgrensesnitt». Eller, med andre ord, bare en filserver med begrenset eksponert funksjonalitet. Grunnen til at vi velger fysiske NAS-apparater er for den integrerte støtten og noen ganger for spesiell, proprietær funksjonalitet (NetApp er et nøkkeleksempel på dette med omfattende SMB og NFS-integrasjon og noen virkelig unike RAID- og filsystemalternativer, eller Exablox som tilbyr fullt administrert scale-out fillagring og RAIN-lignende beskyttelse). Å bruke NAS for å erstatte en tradisjonell filserver er, for det meste, et ganske nylig fenomen og ett jeg har funnet er ofte drevet av misforståelse eller inntrykket av at det å administrere en filserver – en av de mest grunnleggende IT-arbeidsbelastningene – er noe spesielt eller vanskelig. Filservere regnes generelt som den mest grunnleggende formen for server, og er tradisjonelt det folk mente når de brukte begrepet server med mindre ytterligere beskrivelse ble lagt til, og den eneste formen som er vanlig integrert i skrivebordet (alle Mac, Windows og Linux-skrivebord kan fungere som filserver, og det er svært vanlig å gjøre det).
Det er selvfølgelig ingenting galt med å bruke NAS i stedet for en tradisjonell filserver for å møte lagringsbehovene dine, spesielt ettersom noen moderne NAS-alternativer, som Exablox, tilbyr scale-out og lagringsalternativer som ikke er tilgjengelige i de fleste operativsystemer. Men det ser ut til at trenden med å bruke NAS i stedet for en filserver har ført til noe merkelig atferd når IT-fagfolk igjen begynner å vurdere filservere. En kaskadeeffekt, mistenker jeg, der grunnene til at NAS noen ganger foretrekkes og målnivåtenkningen er gått tapt, og den resulterende ideen om «jeg bør ha en NAS» forblir, slik at når man returnerer for å se på filserveralternativer, er det en drift mot å «ha en NAS» uavhengig av om det finnes en logisk grunn til å føle at dette er nødvendig eller ikke.
Først må vi vurdere at det generelle konseptet med en NAS er enkelt: ta en tradisjonell filserver, forenkle den ved å fjerne alternativer og pakk den med alt nødvendig maskinvare for å lage et forenklet apparat med all støtten inkludert fra grensesnittet ned til de roterende diskene og alt imellom. Lagring kan være vanskelig når brukerne trenger å bestemme RAID-nivåer, disktyper, overvåke effektivt osv. En NAS adresserer dette ved å integrere maskinvaren i plattformen. Dette gjør ting enkelt, men kan øke risikoen ettersom du har færre støttealternativer og mindre evne til å fikse eller erstatte ting selv. En overgang fra en filserver til en NAS-apparat handler nesten utelukkende om støtte og er generelt en svært sterk forpliktelse til en enkelt leverandør. Du valgte NAS-tilnærmingen fordi du ønsker å stole på en leverandør for alt.
Når vi går over til en filserver, går vi i motsatt retning. En filserver er en tradisjonell enterprise-server som alle andre. Du kjøper servermaskinvaren din fra én leverandør (HP, Dell, IBM, osv.) og operativsystemet fra en annen (Microsoft, Red Hat, Suse, osv.). Du spesifiserer delene og konfigurasjonen du trenger, og du har den vanligste datamodellen for all IT. Med denne modellen bruker du generelt standard, commodity-deler som lar deg enkelt migrere mellom maskinvareleverandører og mellom programvareleverandører. Du har «leverandørredundans»-alternativer, og generelt gjøres alt ved hjelp av åpne, standard protokoller. Du får stor fleksibilitet og kan administrere og overvåke filserveren din akkurat som ethvert annet medlem av serverflåten din, inkludert å holde den fullstendig virtualisert. Du gir opp den vertikale integrasjonen til NAS i bytte mot horisontal fleksibilitet og standardisering.
Det som er merkelig, er derfor når man returnerer til commodity-modellen men søker etter det som kollokvielt er kjent som et NAS OS. Vanlige eksempler på disse inkluderer NAS4Free, FreeNAS og OpenFiler. Denne kategorien produkter er generelt ikke noe mer enn et standard operativsystem (ofte FreeBSD siden det har ideell lisensiering, eller Linux fordi det er godt kjent) med et «lagringsgrensesnitt» lagt på toppen og ingen spesiell eller ekstra funksjonalitet som ikke ville eksistere med det normale operativsystemet. I teorien er de et «enkeltfunksjons»-operativsystem som bare gjør én ting. Men dette er ikke virkeligheten. De er generelle operativsystemer med et ekstra GUI-administrasjonslag lagt på toppen. Man kunne si det samme om de fleste fysiske NAS-produkter i seg selv, men de inkluderer vanligvis tilpasset ingeniørarbeid selv på lagringsnivå, spesielle funksjoner og, viktigst av alt, en integrert støttestack og sann isolasjon av «generellheten» i det underliggende OS. Et «NAS OS» er ikke en enklere versjon av et generelt OS, det er en mer kompleks, men mindre funksjonell versjon av det.
Det som også er merkelig, er at generelle OS-er, med sjeldne unntak, allerede kommer med svært enkle, ekstremt godt kjente og fullt støttede lagringsgrensesnitt. Nesten alle varianter av Windows eller Linux-servere, for eksempel, har inkludert enkle grafiske grensesnitt for disse funksjonene i svært lang tid. Disse inkluderte GUI-ene blir ofte avvist av systemadministratorer som for «tunge og unødvendige» for en enkel filserver. Så det er enda mer uvanlig at det å legge til et tredjeparts GUI – ett som ikke er oppdatert og testet av OS-teamet og ikke er standard kjent og støttet – da ville bli ønsket, ettersom dette går imot de vanlige idealene og praksisene ved bruk av en server.
Og dette er der Jurassic Park-effekten kommer inn – OS-leverandørene (Red Hat, Microsoft, Oracle, FreeBSD, Suse, Canonical, med videre) er giganter med fantastiske ingeniørteam, kodegjennomgang, testing, tilsyn og enterprise-støtteøkosystemer. Mens «NAS OS»-leverandørene generelt er svært små selskaper, noen med bare én deltidsperson, som står på skuldrene til disse gigantene og bygger noe de visste de kunne, men aldri stoppet for å spørre om de burde. De resulterende produktene er helt negative sammenlignet med sine rene OS-motparter: de gjør ikke systemadministrasjon enklere, og de fyller heller ikke et gap i markedets tjenestetilbud. Solid, pålitelig, brukervennlig lagring er allerede tilgjengelig – det trengs ikke flere leverandører for å fylle denne plassen i markedet.
Logikken som ofte brukes når man ser på et NAS OS, er at de er «enkle å sette opp». Dette kan være sant eller usant, ettersom enkel her må være et relasjonelt begrep. For at det skal ha noen verdi, må et NAS OS være enkelt i forhold til standardversjonen av det samme operativsystemet. Så i FreeNAS sitt tilfelle ville dette bety FreeBSD. FreeNAS måtte være merkbart enklere å sette opp enn FreeBSD for de samme, dedikerte funksjonene. Og dette er lett sant – å sette opp et NAS OS er generelt ganske enkelt. Men denne enkelheten er bare en lettvint løsning, og én som IT-fagfolk trenger å være svært klar over. Å gjøre noe enkelt å sette opp er ikke en prioritet i IT; det som er viktig, er å lage noe som er enkelt å drifte og reparere når det oppstår problemer. Enkelt å sette opp er hyggelig, men hvis det kommer på bekostning av å ikke forstå hvordan systemet er konfigurert og gjør operative reparasjoner vanskeligere, er det en svært, svært dårlig ting. NAS OS-produkter gjør det rutinemessig farlig enkelt å få et produkt i produksjon for en lagringsrolle – som nesten alltid er den mest kritiske eller nesten mest kritiske rollen til enhver server i et miljø – uten at IT har erfaring eller sannsynligvis kompetanse til å vedlikeholde, drifte eller, viktigst av alt, fikse det når noe går galt. Vi trenger nøyaktig det motsatte: et system som er enkelt å drifte og fikse. Det er det som betyr noe. Så vi har et andre tilfelle av «å stå på skuldrene til giganter» og bygge et system som vi visste vi kunne, men ikke visste om vi burde.
Det som forverrer dette problemet er at de samme menneskene som føler behov for å ty til et NAS OS for å «gjøre lagring enkelt», er – av selve naturen til NAS OS – nøyaktig de menneskene for hvem operativ støtte og reparasjon av systemet er vanskeligst. Systemadministratorer som er komfortable med det underliggende OS-et, ville naturligvis ikke se et NAS OS som en fordel og unngå det, for det meste. Det er unikt de menneskene for hvem det er farligst å kjøre en lagringsplattform de ikke fullt ut forstår, som er sannsynlige til å prøve det. Og, selvfølgelig, tjener de fleste NAS OS-leverandørene sine penger – som vi kunne forutsi – på support-anrop etter installasjon for kunder som rullet ut og satte seg fast når de var i produksjon, slik at de er på nåde hos leverandørene for formidable supportpriser. Det er i leverandørenes interesse å gjøre det enkelt å installere og vanskelig å fikse. Alt arbeider mot IT-fagmannen her.
Hvis vi tar et vanlig eksempel og ser på FreeNAS, kan vi se hvordan dette er en dårlig justering av «vanskeligheter». FreeNAS er FreeBSD med et ekstra grensesnitt på toppen. Alt FreeNAS kan gjøre, kan FreeBSD gjøre. Det er ingen tap av funksjonalitet ved å gå til FreeBSD. Når noe feiler, i begge tilfeller, må systemadministratoren ha god arbeidskunnskap om FreeBSD for å utføre reparasjoner. Det er ingen unnslippelse fra dette. FreeBSD-kunnskap er vanlig i bransjen, og det er relativt enkelt å få ekstern hjelp. Å bruke FreeNAS legger til flere komplikasjoner, der den største er at alle tilpasninger gjort av FreeNAS GUI er spesialkunnskap som trengs for feilsøking på toppen av kunnskapen som allerede trengs for å drifte FreeBSD. Så dette er et stort kunnskapssett, samt flere ting som kan feile. Det er også et relativt uvanlig kunnskapssett ettersom FreeNAS er et nisjlagringsprodukt fra en liten leverandør, og FreeBSD er en stor enterprise IT-plattform (pluss at all bruk av FreeNAS er FreeBSD-bruk, men bare en liten prosentandel av FreeBSD-bruken er FreeNAS). Så vi kan se at bruk av et NAS OS bare legger til risiko om og om igjen.
Dette samme problemet overføres til fellesskapene som vokser opp rundt disse produktene. Hvis du ser til fellesskap rundt FreeBSD, Linux eller Windows for veiledning og hjelp, har du å gjøre med et stort antall IT-fagfolk, dyktige systemadministratorer og de med forretnings- og enterprise-erfaring. Selvfølgelig deltar hobbyister, de uninformerte og andre også, men disse er enterprise IT-plattformene, og all bransjens kunnskap er tilgjengelig for deg når du implementerer disse produktene. Sammenlign dette med fellesskapet til et NAS OS. Av selve sin natur ville bare folk som sliter med administrasjonen av et standard operativsystem og/eller lagringsgrunnleggende, se på en NAS OS-pakke, og dette filtrerer naturlig medlemskapet i deres fellesskap til å inkludere bare de menneskene som vi helst bør unngå å ta råd fra. Dette skaper en isolert kultur av feilinformasjon og misforståelser rundt lagring og lagringsprodukter. Myter florerer, veiledning blir ofte hensynsløs og farlig, og bransjens beste praksis ignoreres som om tiår med akkumulert erfaring aldri hadde funnet sted.
Et NAS OS introduserer også, vanligvis, forsinkelser i oppdateringer. Et NAS OS vil nesten alltid og nesten nødvendigvis sakke etter sitt overordnede OS på sikkerhets- og stabilitetsoppdateringer og vil svært ofte følge måneder eller år bak på store funksjoner. I ett svært kjent scenario var OpenFiler bygget på en oppstrøms ikke-enterprise-basis (RPath Linux) som manglet fellesskap og leverandørstøtte, feilet og ble forlatt – noe som etterlot nedstrømsbrukere, inkludert alle på OpenFiler, uten det økosystemet som trengs for å støtte dem. Å bruke et NAS OS betyr å stole ikke bare på den store, enterprise og godt kjente primære OS-leverandøren som lager basis-OS-et, men også å stole på NAS OS-leverandøren. Og NAS OS-leverandøren er størrelsesordener mer sannsynlig til å feile hvis de baserer produktene sine på enterprise-klasse basis-OS-er.
Lagring er en kritisk funksjon og bør ikke behandles uforsiktig og bør ikke ignoreres som om kritikaliteten ikke eksisterte. NAS OS-er frister oss til å installere raskt og glemme, og håpe at ingenting noen gang går galt, eller at vi kan flytte til andre roller eller selskaper helt før de dårlige tingene skjer. Det setter oss opp for fiasko der fiaskoen er mest virkningsfull. Når en typisk applikasjonsserver feiler, kan vi alltid kopiere filene fra lagringsenheten og starte på nytt. Når lagring feiler, går data tapt og systemer kollapser.
“John Hammond: Alle store temaparker har forsinkelser. Da de åpnet Disneyland i 1956, fungerte ingenting!
Dr. Ian Malcolm: Ja, men, John, hvis Karibiens pirater bryter ned, spiser ikke piratene turistene.”
Når lagring feiler, feiler virksomheter. Å ta den enkle veien til å sette opp lagring og ignorere de langsiktige støttebehovene, og å søke råd fra fellesskap som har filtrert ut erfarne lagrings- og systemingeniører, øker risikoen dramatisk. Trist nok er naturen til et NAS OS slik at den aller grunnen til at folk vender seg til det (manglende dyp teknisk kunnskap for å bygge systemene) er den aller grunnen til at de må unngå det (enda større behov for støtte). De menneskene for hvem NAS OS-er er effektivt trygge å bruke – de med svært dyp og bred lagrings- og systemkunnskap – ville sjelden vurdere disse produktene fordi de for dem ikke tilbyr noen fordeler.
Til syvende og sist, mens konseptet med et NAS OS høres underfullt ut, er det ikke en mirakelkur, og verdien av en NAS overføres ikke fra den fysiske apparatverdenen til den installerte OS-verdenen, og verdien av standard OS-er er altfor stor for NAS OS-er til å effektivt tilføre reell verdi.
“Dr. Alan Grant: Hammond, etter nøye overveielse har jeg besluttet å ikke anbefale parken din.
John Hammond: Det har jeg også.”

