Strålkastarljus på SMB-lagring

Lagring är en svår nöt att knäcka. För företag är lagring svårt eftersom det ofta inbegriper stora prislappar för vad som framstår som diffusa vinster. De flesta chefer förstår behovet av att “lagra” saker och fler av dem, men de förstår mycket lite om prestanda, åtkomstmetoder, redundans och riskberäkningar, säkerhetskopiering och katastrofåterställning. Detta gör IT:s arbete svårt, eftersom vi behöver förklara varför budgetar ofta behöver vara ytterst stora för vad som framstår som ett osynligt system för verksamhetens intressenter.

För IT är lagring svårt eftersom lagringssystem är komplexa – ofta det enskilt mest komplexa systemet inom ett SMB – och ofta, på grund av sin kostnad och centralisering, existerar de i mycket små antal inom en verksamhet. Detta innebär att de flesta SMB:er, om de överhuvudtaget har några lagringssystem, har endast ett och behåller det under mycket lång tid. Denna brist på bred exponering för lagringssystem, i kombination med det relativt sällsynta behovet av att interagera med lagringssystem, lämnar SMB-IT-avdelningarna att hantera en stor budgetpost av otrolig kritikalitet för verksamheten, som är en liten andel av deras “uppgifts”-spektrum och över vilken de i själva verket har mycket lite erfarenhet av själva odjurets natur. Andra områden inom IT är långt mer tillgängliga för experiment-, test- och utbildningssyften.

Mellan dessa två stora utmaningar står vi kvar med en produkt som är dåligt förstådd, i allmänhet, av både ledning och IT. Lagring är så missförstådd att IT-avdelningarna ofta inte ens är medvetna om vad de behöver överhuvudtaget och ofta gör föga mer än att kasta pil mot lagringspiltavlan och börjar från där pilarna än landar – och ofta börjar med att ringa leverantörer snarare än konsulter, vilket leder dem ner på en stig av “beslutet är redan fattat” samtidigt som de till synes får rådgivning.

Lagringsleverantörer, som känner till allt detta, gör föga för att bistå situationen, eftersom det, när väl kontakt mellan ett SMB och en leverantör har upprättats, ligger i leverantörens bästa intresse att inte utbilda kunden, eftersom kunden redan fattade beslutet att vända sig till den leverantören i första hand innan hen hade den nödvändiga informationen till hands. Så leverantören vill helt enkelt sälja vad de än har tillgängligt. Sällan har en enskild lagringsleverantör ett brett utbud av produkter i sina egna serier, så att gå direkt till en leverantör innan man vet exakt vad som behövs kan föra kunden mycket, mycket längre mot att i praktiken redan ha bestämt sig för vad som ska köpas än inom andra arenor av teknik, och detta kan orsaka att kostnaderna ligger fel med storleksordningar jämfört med vad som behövs.

Exempel: De flesta serverleverantörer erbjuder ett brett utbud av servrar både inom x64-familjen samt storskaliga RISC-maskiner och andra, nischade produkter. De flesta lagringsleverantörer erbjuder en liten delmängd av lagringsprodukter som enbart erbjuder SAN eller enbart NAS eller enbart lagring av “mainframe”-klass eller enbart liten, icke-replikerad lagring och så vidare. Endast ett fåtal leverantörer har ett brett sortiment av lagringsprodukter för att möta de flesta behov, och även de bästa av dessa saknar full marknadsskala som träffar den mindre SMB-marknaden såväl som mellanmarknaden och företagsmarknaden.

Så vart går vi härifrån? Detta är uppenbarligen en allvarlig utmaning att övervinna.

Det uppenbara alternativet, och ett som verksamheter inte bör utesluta, är att vända sig till en lagringskonsult. Någon som inte vidareförsäljer en lösning eller, åtminstone, inte vidareförsäljer en enskild lösning utan har en komplett lösningsuppsättning att välja från och som kommer att kunna tillhandahålla en lågkostnadslösning på 1 000 dollar såväl som en lösning på 1 000 000 dollar – någon som förstår NAS, SAN, scale-out-lagring, replikering, failover och så vidare. När du går till din konsult, gör inte antagandet att du vet vad dina kostnader kommer att bli – det finns många, många faktorer, och genom att överväga dem noggrant kanske du kan spendera långt mindre än du hade förväntat dig. Men ha budgetar i åtanke, riskaversion väl dokumenterad, kostnader för driftstopp och en mycket komplett uppsättning av förväntade användningsscenarier för lagring.

Men att vända sig till en konsult är förvisso inte den enda vägen. Att göra din egen efterforskning, lära dig grunderna och följa en strukturerad beslutsprocess kan föra dig, om inte till den rätta lösningen, så åtminstone en bra bit ner på den rätta stigen. Det finns fyra stora överväganden när man tittar på lagring: funktion (hur lagring används och nås), kapacitet, hastighet och tillförlitlighet.

Den första faktorn, funktion, är den mest förbisedda och den minst förstådda. Faktum är att även om detta är den mest grundläggande av farhågor sopas detta ofta helt enkelt under mattan och glöms bort. Vi kan besvara denna fråga genom att fråga oss själva “Varför köper vi lagring?”

Låt oss ta itu med detta systematiskt. Det finns många skäl till att vi kommer att köpa lagring. Här är några populära: att sänka kostnader jämfört med att ha stora mängder lagring lokalt på enskilda servrar eller skrivbord, att centralisera hanteringen av data, att öka prestandan och att göra data mer tillgänglig i händelse av systemhaveri.

Att veta vilken av dessa faktorer, eller om det finns en annan faktor som inte listas här, som driver dig mot delad lagring är viktigt, eftersom den sannolikt kommer att tillhandahålla en utgångspunkt i din beslutsprocess. Tills vi vet varför vi behöver delad lagring kommer vi att vara oförmögna att titta på den lagringens funktion, vilken, som vi redan vet, är den mest fundamentala beslutsfaktorn. Om du inte kan fastställa lagringens funktion är det säkert att anta att delad lagring inte behövs alls. Var inte rädd för att fatta detta beslut, den stora majoriteten av småföretag har föga eller inget behov av delad lagring.

När vi väl fastställer funktionen för vår delade lagring kan vi nu, relativt enkelt, fastställa behoven av kapacitet och prestanda. Kapacitet är den enklaste och mest uppenbara funktionen hos lagring. Prestanda, eller hastighet, är enkel att ange och förklara men mycket svårare att kvantifiera, eftersom IOPS i bästa fall är ett diffust begrepp och i värsta fall fullständigt missförstått. IOPS kommer i olika varianter, och det finns farhågor kring slumpmässig åtkomst, sekventiell åtkomst, bursthastigheter, latens och uthålliga hastigheter, och sedan kommer skillnaderna mellan läsning och skrivning! Det är svårt att ens fastställa den behövda prestandan, för att inte tala om den förväntade prestandan hos en enhet. Men med noggrann efterforskning är detta uppnåeligt och mätbart.

Vår sista faktor är tillförlitlighet. Denna tycks, liksom funktionalitet, vara en återkommande stötesten för IT-proffs som vill ge sig in i delad lagring. Det är viktigt, nej, absolut avgörande, att idén om att lagring är “bara ännu en server” hålls i åtanke och att de begrepp om redundans och tillförlitlighet som gäller för normala servrar gäller i lika hög grad för dedikerade delade lagringssystem. I nästan alla fall är företagslagringssystem byggda på företagsservrar – samma chassi, samma diskar, samma komponenter. Vad som ofta är förvirrande är att även SMB:er vänder sig till lagringssystem i mellan- eller toppskiktet för att stödja servrar i ett mycket lägre skikt, vilket ibland kan få lagringssystem att framstå som mystiska på samma sätt som tunga järnservrar kan framstå för någon som endast är van vid serverhårdvara av handelsvaruklass. Men låt dig inte vilseledas, samma principer om tillförlitlighet gäller, och du kommer att behöva bedöma risk på exakt samma sätt som du alltid har gjort (eller borde ha gjort) för att fastställa vilken utrustning som är rätt för dig.

Att ta sig tid att bedöma, efterforska och förstå lagringsbehov är mycket viktigt, eftersom ditt lagringssystem sannolikt kommer att förbli som en ryggradskomponent i ditt nätverk under mycket lång tid på grund av sin ytterst höga kostnad och komplexiteten i att byta ut det. Till skillnad från den senaste versionen av Microsoft Office kommer inköpet av ett nytt delat lagringssystem inte att orsaka någon direkt inverkan på en chefs skrivbord och saknar därmed den glans som krävs för att driva “funktionsuppdateringar” likaledes.

Nu när vi har våra alternativ framför oss kan vi börja titta på verkliga produkter. Baserat på vår funktionalitetsefterforskning bör vi nu kunna fastställa om vi är i behov av SAN, NAS eller ingetdera. I många fall – långt fler än folk inser – är ingetdera det rätta valet. Ofta är det mer kostnadseffektivt och tillförlitligt att lägga till diskar i befintliga servrar eller ansluta ett DAS-diskchassi där det behövs än att göra något mer komplext. Detta bör inte förbises. Faktum är att om DAS passar det aktuella behovet skulle det vara sällsynt att något annat överhuvudtaget skulle vara vettigt. Enkelhet är IT-chefens vän.

Det finns gott om tillfällen då DAS inte kommer att möta det aktuella behovet. Delad lagring har förvisso sin plats, om så bara för att dela filer mellan skrivbordsanvändare. Med dagens moderna virtualiseringssystem blir delad lagring alltmer populär – även om DAS även där alltför sannolikt undviks även när det kanske skulle passa de befintliga behoven väl.

Med sällsynta undantag, när delad lagring behövs, är NAS platsen att vända sig till. NAS står för Network Attached Storage. NAS efterliknar beteendet hos en filserver (NAS är helt enkelt en filserver paketerad som en applians), vilket gör den lätt att hantera och lätt att förstå. NAS tenderar att vara mycket mångsidig och ersätter traditionella filservrar och används ofta som den delade backend för virtualisering. NAS kännetecknas av protokollen NFS och CIFS, men vi kommer inte sällan att se HTTP, FTP, SFTP, AFS och andra tillgängliga på NAS-enheter likaledes. NAS fungerar väl som en sammankopplare som låter Windows- och UNIX-system enkelt dela filer med varandra samtidigt som de endast behöver arbeta med sina egna inhemska protokoll. NAS används vanligen som delad lagring för VMWares vSphere, Citrix XenServer, Xen och KVM. Med NAS är det enkelt att använda din delade lagring i många olika roller och enkelt att uppnå ett gott utnyttjande från ditt delade lagringssystem.

NAS möter inte alltid våra behov. Vissa specialapplikationer behöver fortfarande delad lagring men kan inte utnyttja NAS-protokoll. De mest anmärkningsvärda produkter som påverkas av detta är Microsofts HyperV, databaser och serverkluster. Svaret för dessa produkter är SAN. SAN, eller Storage Area Networking, är ett svårt begrepp och är även i bästa fall svårt att kategorisera. Liksom NAS, som helt enkelt är ett annat sätt att presentera traditionella filservrar, är SAN i sanning bara ett annat sätt att presentera direktanslutna diskar. Även om skillnaderna mellan SAN och DAS kan tyckas uppenbara är det i bästa fall diffust och i värsta fall omöjligt att faktiskt särskilja dem. SAN och DAS delar typiskt protokoll, chassi, begränsningar och media. Många SAN-enheter kan anslutas och användas som en DAS. Och de flesta DAS-enheter kan anslutas till en switch och användas som SAN. I verkligheten använder vi typiskt termerna för att hänvisa till deras användningsscenario mer än något annat.

SAN är svårt att utnyttja effektivt av många skäl. Det första är att det är dåligt förstått. SAN är i själva verket enkelt – så enkelt att det är mycket svårt att greppa, vilket gör det förvånansvärt komplext. SAN är i praktiken bara DAS som abstraheras, ompartitioneras och presenteras tillbaka ut till värdar som DAS igen. Termen “delad lagring” är förvirrande eftersom även om SAN-teknik, liksom NAS, kan tillåta flera värdar att ansluta till ett enda lagringssystem tillhandahåller den ingen form av medling för värdar som är anslutna till samma filsystem. NAS är intelligent och hanterar detta, vilket gör det enkelt att “dela” delad lagring. SAN gör det inte, den är alltför enkel. SAN är så enkel att vad som i praktiken händer helt enkelt är att en enda hårddisk (hur abstraherad den än må vara) kopplas in i styrenheter på flera värdar. På den tiden då delad lagring innebar att ansluta två servrar till en enda SCSI-kabel var detta lätt att föreställa sig. I dag, med SAN:s abstraktioner och NAS allmängiltighet, kommer de flesta IT-verksamheter att glömma vad SAN gör, och katastrof kan slå till.

SAN har sin plats, helt visst, men SAN är komplex att använda och att administrera och mycket begränsande. Ofta är den mycket dyr också. Tumregeln med SAN är denna: om du inte behöver SAN, använd något annat. Så enkelt är det. SAN bör undvikas tills det är det enda alternativet, och när det är det, är det det rätta alternativet. Det väljs sällan, om någonsin, av prestanda- eller kostnadsskäl, eftersom det normalt underpresterar och överkostar andra alternativ. Men när du backar HyperV eller bygger ett databaskluster kommer inget annat att vara ett alternativ för dig. För de flesta användningsfall i ett SMB kommer effektiv användning av SAN att kräva att ett NAS placeras framför det för att dela ut lagringen.

NAS utgör den stora majoriteten av användningsscenarier för delad lagring. Den är enkel, väl förstådd och flexibel.

Många, om inte de flesta, applianser för delad lagring i dag kommer att hantera både SAN och NAS, och skillnaden mellan de två ligger i deras användning, protokoll och ideologi mer än något annat. Ofta är de fysiska enheterna likartade om inte desamma, liksom anslutningsteknikerna i dag.

Mer än något annat är det viktigt att ha specifika mål i åtanke när man söker efter delad lagring. Skriv ner dessa mål och titta på varje teknik och produkt för att se hur eller om de möter dessa mål. Använd inte instinktivt beslutsfattande eller utgå från marknadsföringsmaterial eller vad som framstår som marknadsmomentum. Börja med att fastställa om delad lagring överhuvudtaget är ett behov. Om så är fallet, fastställ om NAS möter dina behov. Om inte, vänd dig till SAN. Lagring är en enorm investering, ta dig tid att titta på alternativ, gör mycket efterforskning och först efter att ha snävat in fältet till ett fåtal, specifika konkurrerande produkter – vänd dig till leverantörer för slutgiltiga detaljer och prissättning.