Ok, vi skall bygga ett kluster från grunden. Vi startar med ett blankt papper, vi har INGA krav på att vi skall använda vissa fabrikat eller gör på nått speciellt sätt. De enda kraven vi har är att det skall vara redundant (felsäkert), snabbt och att vi skall kunna lagra en hel del data kostnadseffektivt (inga andra krav alltså, bara de tre stora som alla alltid haft sen IT-eran startade, verkar ju som rimliga krav 😊).
Som vi skrev tidigare är ett kluster beroende av gemensam lagring, en lagring som man kopplar flera servrar till. Nu gör vi det annorlunda, nu har vi ingen gemensam lagring utan lagringen skall ligga i själva servrarna, men speglas så att datat finns på flera ställen samtidigt. Om datat ändras i en server speglas det direkt över till de andra. Om en server totaltkraschar kan de andra ändå köra vidare.
Microsoft har utvecklat en teknik för detta som kallas Storages Spaces Direct, förkortat SSD eller S2D för att inte förväxla det med SSD-diskar. Detta kom i Windows server 2016.
För att inte gör för mycket misstag bestämmer vi oss för att göra klusterbygget i två steg. Först köper vi in några begagnade servrar som vi känner till väl, HP Proliant, och bestyckar dem med lite disk vi har liggande och några nya. Sen om allt går väl och testklustret levererar bra prestanda bygger vi helt nya servrar.
Testmiljön består att två Proliant DL 380 och en ML 380. Storagenätet som skall användas för replikering av diskarna bygger vi med 10 Gbit ethernet x2 i varje server. För att få fart använder vi vanliga SSD-diskar som cache och för att få storlek en blandning av SATA och SAS-diskar. Att köpa HP-original kostar ju en slant så vi skaffar 3:e-partsdisk och monterar i HP-slädar. Nu skall vi bygga kluster så det ryker!
I en perfekt värld är allt enkelt, men det är det inte i verkligheten. HP-servrar har Arraycontrollers för att skapa diskredundans. Dessa kan vi hantera i sömnen, men nu skall vi inte använda den funktionaliteten eftersom det är S2D-tekniken som skall hantera redundansen. Efter några dagars testande och experimenterande lyckas vi hitta ett kommando som stänger av funktionen, lite odokumenterat och kräver en viss firmware m.m. Till slut lyckas vi i alla fall se diskarna så som de skall synas och får ihop allt. Med lite tvång lyckas vi också få till SSD-diskarna så att de agerar cache som de skall. Om man inte känner sig bekväm med powershell skall man inte hålla på med servrar längre, så är det. Vissa inställningar finns inte att nå via GUI längre. Vi experimenterar vidare med nätverkskort och drivrutiner och profilinställningar. Inte helt enkelt det heller när servrarna både skall vara diskoptimerade och köra Hyper-V då man vill ha VMQ.
Vi testar fart och redundans och allt funkar faktiskt riktigt bra. I de första testarna vi gör kommer vi inte upp i mer än 60 000 IOPS (Inputs/Outputs Per Second), en besvikelse, men efter förändring av diskar och cacheinställningar når vi en liten bit över 2 miljoner IOPS. Inte illa för ett SAN med standarddiskar och servar som har några år på nacken. Sen skall väl tilläggas att vi inte bara mätte IOPS utan även dataöverföringshastighet och även det såg lovande ut. I skarp drift med ett antal virtuella servera igång samtidigt så är det lite annan typ av belastning så mätvärden i all ära, men det är verkligheten som räknas. Indikationerna på att det skall funka bra är dock tydliga!
Nu när man kör i Windowsservermiljö och är på hemmaplan har man ju koll på allt – tjena… En så simpel sak som Windows update skall ju inte vara något problem. Skeptisk som man är till automatik fixar vi detta manuellt. Vi flyttar bort last från den server vi tänker uppdatera och uppdaterar den och startar om, varpå vi totalt tappar kontakten med klustret. Det som kändes helt riskfritt var inte alls detta. Ominstallation. Det finns något som kallas kluster Aware Updating och om någon därute funderar på att bygga Microsoft-kluster så använd detta, vi återkommer till detta senare.
Ok, steg två nu då! Vi skall alltså försöka bygga billigt, det kan ju inte vara så svårt, en och annan PC har man ju byggt ihop i sina dagar. Fördelen med S2D är att man kan köra på standardkomponenter, typ SATA-diskar så detta blir ju lätt, eller … Vilket det såklart skulle visa sig att det inte blev. Man har ju följt en del poddar och bloggar där folk pratat om hur enkelt det är, det man förstår när man börjar gräva djupare i det är att de nog inte riktigt haft den verklighetsförankringen som man kan kräva. Ok, att dra igång en testmiljö, men därifrån till att rulla det i skarp drift är en bit. Eller när Microsoft sitter i sitt labb och visar prestanda på värsta hårdvaran är det heller inte helt realistiskt att jämföra med. Vi ligger ju några snäpp över testmiljön och några under Microsoft och helt plötsligt fattar vi att HÄR har inte så många varit förut, men vi ger oss inte!
Nu skall vi börja med att bygga en billig server. Tanken är ju att det är klustret som skall stå för all säkerhet, de enskilda servrarna behöver inte ha så hög säkerhet då tanken är att en eller till och med två skall kunna krascha och att allt skall fungera ändå. Vi skall bara skaffa låda, moderkort, processor och diverse hårddisk. Vi börjar med låda. Vi letar och letar, hoppar över leverantörer i Sverige och går direkt utomlands. Efter några veckors letande inser vi att det är nog inte så många som bygger servrar på komponenter längre. När man börjar summera pris på moderkort, processorer och diverse konstiga lådor blir det ganska dyrt. Utbudet är heller inte så stort som man kan tro.
Vi intar nu en ny approach, vi struntar i att bygga från grunden tänker köpa en billig server färdig istället. Vi har ju alltid jobbat med HP, men nu är vi öppna för vad som helst så länge det är billigt och nytt. Vi går igenom i princip alla servrar som finns i vårt tilltänkta segment, från HP, Dell, IBM, SuperMicro m.fl., återigen får vi klia oss i huvet. Detta trodde vi inte, men med facit i hand har faktiskt HP de billigaste servrarna för vårt ändamål.
Dags att beställa en server alltså, vi börjar med en för att se att den funkar som vi tänkt …
