Blogg

Här skriver vi om sånt som är av intresse för våra kunder. IT-säkerhetsfrågor som rör svenska företag, viktigt och intressant, och även om sådant som händer på Optinet!
Rune Wallgren
07 Nov 2018

Resan mot Hyperconverged – del 2

Storage Area Network, smaka på det ordet, det låter lite coolt. I vardagligt tal förkortas det som SAN, icke att förväxla med NAS, Network Attached Storage. Vad är då skillnaden? NAS är kort och gott en hårddisk som kopplas på nätverket, typisk användningsområde är hemmabruk för att lagra bilder och filmer, brukar även vara populärt som backup, men om ni frågar mig en ganska dålig backuplösing. Eftersom man varit i branschen sedan 1990 har man hunnit samla på sig lite erfarenhet och den vanligaste orsaken på senare tid till att data försvinner är krypteringsvirus. Problemet med ett NAS är då att viruset kommer åt även detta och innehållet på NAS:et också blir krypterat och så blir backupen tyvärr värdelös. Nu argumenterar någon kanske att det kan finnas versionshantering i NAS:et och man kan plocka tillbaka gamla versioner och visst, det kanske det finns i vissa system, men problemet är att de flesta inte kan hantera detta så då är det ändå mycket bättre att skaffa en riktig backup. (De som undrar vad en riktig backup är kan läsa vidare på vår hemsida under tjänster eller är välkomna att höra av sig till oss.)

Ett SAN däremot är till för att köra servrar mot, man kopplar ihop det med servrarna genom ett snabbt nätverk med tekniker som t.ex. Fibrechannel eller iSCSI och nu snackar vi lösningar från några 100-tusen och uppåt.Varför vill man ha ett SAN? Ja, det är väl främst två orsaker: 1. Det är mer flexibelt att sätta i mer disk, en vanlig server kan snabbt bli för liten. 2. Om man vill bygga kluster (cluster) så är man beroende av detta.

Vad är då ett kluster. Jo, som vi pratade om i förra blogginlägget började vi virtualisera servrar, men vad händer om man lägger 10 servrar i samma server (host) och så går hosten sönder. Jo, då stannar alla 10 såklart. Poängen med kluster är att detta inte skall kunna hända. Men om man då kliar sig i huvudet lite och funderar på lagringen, om man lagrar 10 servrars data i hosten och den går sönder hur kommer man då åt datat? Exakt, man får lägga det någon annan stans, i SAN.et. Så om en host med 10 servar går sönder flyttas dessa servar över till en annan som fungerar och kör vidare. Smart va?

Ja, det är smart, men det finns såklart risker ändå, bla att SAN:et går sönder (som jag också skrev om i förra inlägget) och att det är dyra produkter som krävs. Det är inte heller en barnlek att få detta att fungera perfekt och återigen vill man inte gärna testa fel och provocera systemet för mycket.

När Windows server 2012 lanserades introducerade Microsoft en funktion som heter SOFS, Scale Out File Server. Detta var en funktion som skulle göra det lättare att bygga SAN med standardiserade komponenter. I stället för Fibrechannel kunde man använda vanligt Ethernet, eller helst 10Gbit Ethernet (som i och för sig inte är så vanligt), men i alla fall mer standardiserat och billigare. Sagt och gjort, vi köpte in prylarna och en massa disk, disklåda och två servrar. Det två servrarna är de som kommunicerar med hostarna så egentligen är de en del i SAN:et, om man jämför med dyrare SAN så kan man säga att de två servrarna redan sitter inbyggda i ett sådant. Fördelen med detta är att eftersom det är Windows-server och vanliga diskar så är det inget hokus pokus utan man känner sig hemma i miljön, man kan uppdatera den ena servern och SAN:et kör vidare på den andra, diskarna har såklart spegling så om en går sönder(eller flera) så fungerar det ändå. En ganska bra lösning och ett steg åt rätt håll, dock ändå inte helt billig och det det inte supersnabbt heller, tyvärr. Vi använder fortfarande detta idag, men inte till våra mest krävande system. Sen går det åt minst två servrar extra samt att servrarna måste ha plast för diskcontrollerkort och de måste sitta intill disklådan, en hårddiskkabel kan inte vara längre än någon meter. Tänk om man kunde sprida ut diskarna och slippa de extra servrarna vore inte det bra?

Andra lösningar vi testat är olika typer av billigare SAN som vi då kört iSCSI mot. Detta innebär att man har ett SAN, fyller det med disk och sedan kopplar det till ett vanligt nätverk. Fungerar oftast ganska bra men är inte det snabbaste. Rättare sagt, det blir oftast superlångsamt, speciellt om man bara kör över ett vanligt gigabitnät och inte 10 Gigabit. Denna typ av lösning brukar duga bra för att lagra backupdata, men för att köra skarpa servrar i drift eller för att bygga kluster duger det helt enkelt inte, det blir för långsamt. Och som vanligt, det finns säker någon där ute som inte håller med, men med vår måttstock duger det inte i alla fall. En helt vanligt server t.ex. en HP DL 380p med någorlunda snabba snurrande diskar i ett RAID 5 t.ex. är hur mycket snabbare som helst. Problemet är ju bara att då är vi tillbaka i en ensam server igen och det vill man ju inte, man vill ju verkligen ha ett kluster.

Så frågan är då, finns det ingen lösning där man kan skapa ett kluster, på standardkomponenter och med tillräcklig snabbhet, jo det kanske finns det, svaret skulle kunna stavas Hyperconverged.

I del tre kommer alla frågor att besvaras, flop eller flip det är frågan…

Lämna en kommentar