Denne artikel går lidt mere ind i nogle praktiske ting omkring cluster-servere.
Denne artikel er en del af en serie. Det er en fordel at starte med at læse de 5 første artikler i serien, hvor den første findes her.
Et server cluster består normalt af to servere som kan overtage nogle opgaver fra hinanden. Fra omverden optræder de to maskiner dels som selvstændige servere, men desuden har de så en eller flere virtuelle IP adresser og netværksnavne. De virtuelle IP adresser og net-navne kan så ”bo” på den maskine som kører servicen lige nu. De to maskiner skal så deles om storage, så de skal have en fælles controller og disksystem som kan håndtere at blive styret af et cluster. Setuppet ender med at blive ganske dyrt, men har så også nogle fordele som gør det velegnet til broadcast-formål. En service (fx en SQL Server) som man gerne vil have til at køre redundant kan kun køre fra én maskine af gangen. Så det er blot et system med passiv redundans. Hvis Main holder op med at virke, vil cluster servicen opdage det efter ganske kort tid, og så startes SQL Serveren på Backup.
Desuden har man mulighed for manuelt at flytte services over fra den ene til den anden maskine, og nedetiden bliver ganske kort, så kort at systemer som fx DaletPlus bare vil kunne køre videre. Det kræver bare at systmet er programmeret til at forsøge at reconnecte til SQL serveren, hvis det mister forbindelsen pga. en failover. Den passive redundans betyder at virkningsgraden (opnået ydelse/kapacitet af den indkøbte hardware) på et cluster-system bliver 50%, da der altid vil være en backup-maskine der ikke laver noget. At man på den måde spilder halvdelen af sin investering, er der ikke så meget at gøre ved, med mindre man har to forskellige services, som det giver mening at have kørende på hver sin maskine i clusteret, og som samtidig ikke belaster så meget, så hele systemet går ned, hvis de ender med at skulle køre på én maskine en dag. De services, som det giver mening at køre på denne måde kunne fx være en SQL Server på den ene maskine og noget storage til lydfiler på den anden maskine. Til hverdag vil de køre hurtigt, fordi de kører på hver sin maskine, og den dag man så har et problem og det hele ender på én maskine, så må man leve med at det går lidt langsommere, indtil at man får løst problemet. Dermed har vi fået os et passivt redundant system men med noget load-sharing.
Cluster-systemer er dog ikke løsningen på alt. Som for ethvert andet passivt redundant system, er der ”noget” som skal beslutte om vi skal køre det ene eller det andet sted, og i dette tilfælde er det cluster-servicen. Cluster-servicen er en service der kører under Windows, og den kan også selv indføre nogle fejl. Således har jeg set eksempler på at det virtuelle netværksnavn til clusteret fx kan holde op med at virke, og hvor der måtte en genstart af begge maskiner til, før det kørte igen. Serverne kunne tilgås enkeltvis ved deres egne netværksnavne, det var altså kun det virtuelle navn der ikke virkede, og dermed har vi så et eksempel på at cluster servicen har indført en fejl, som vi ikke havde haft hvis vi bare havde haft en enkeltstående maskine.
Om man skal have et clustersystem afhænger af om man har behov for at kunne skifte til en backupserver uden nedetid. Hvis der er noget galt på ens SQL server, så er det faktisk hurtigere at skifte til en backupserver end at genstarte SQL serveren på en enkeltstående maskine, så det kan betyde at servicearbejde ikke behøver at ske midt om natten. Men der er også alternativer, som fx at replikere databaser over på en anden SQL server. Så vil den anden SQL server være klar til at man kan logge på den, så det kræver så bare at klienterne får besked på, at nu skal de logge på et andet sted. Noget tilsvarende kan siges om storage. Det er jo fint nok, at man kan tilgå den samme storage via en anden server, men hvad nu hvis det er selve disksystemet der er noget galt med. Så var man måske bedre stillet ved at have uafhængigt disksystem, gerne placeret et andet sted.
Endelig skal man også huske at et cluster også kan forfalde. Hvis man i lang tid har brugt den ene server som Main, og der opstår et eller andet så cluster servicen vil skifte server, så sker det ret tit at Backup ikke kan bruges. Det kan der være alle mulige årsager til. Jeg har fx. været ude for at Backup pludselig havde fået et problem med AD’et, og måtte meldes ind i domænet igen. Eller at nogen på et tidspunkt havde slået noget ekstra debugging af en service til. Denne debugging skulle så skrive nogle filer i en folder. Det havde man bare glemt alt om og slettet folderen, med det resultat at servicen crashede. Hvis det så bare var sket på den aktive node, så var servicen crashet med det samme, og så havde man nok opdaget sagens rette sammenhæng. Men nu skete det på den node der var Backup på det tidspunkt, og derfor opdagede ingen noget, før Main havde et problem som gjorde at der blev brug for Backup. Resultatet var ikke overraskende at man stod med et cluster der ikke kunne udføre den opgave det skulle, og hvor det tog ret lang tid at finde ud af hvorfor det ikke kunne køre.
Derfor har clustre – lidt med urette – fået ry for at når der endelig er brug for dem, så leverer de ikke varen. Men det er ikke clusterets skyld at AD’et pludselig får set sig sur på en server eller at en menneskelig fejl gør at en service ikke kan starte på den anden node. Eneste måde at sikre sig at et cluster kan levere, er ved jævnligt at lave failover, så der er mulighed for at opdage og løse de problemer der måtte være, inden det er alvor. Det forudsætter så at det system som bruger clusteret kan tåle at der laves en cluster failover mens det kører. Det forudsætter så også at cluster servicen kan detektere at en failover er gået galt og straks faile tilbage igen. Som driftsansvarlig kan man enten vælge at skrive ned i sin kalender at clusteret skal have en failover på en fast ugedag og så selv holde øje med processen. Eller alternativt lade det ske automatisk. Jeg har selv implementeret nogle automatiske failovers, som er startet fra en Windows Task Scheduler, og hvor der monitoreres på processen og stedets systemovervågning får en alarm hvis failover ikke går godt, så det tilstedeværende driftspersonale kan gøre noget ved sagen. Tidspunktet til sådan en failover er naturligvis valgt så det ligger uden for prime time for det pågældende system, men ikke midt om natten – der skal jo være folk til at tage sig af systemet, hvis noget ikke starter som det skal.
