Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den Computerworld d. 18. oktober 2002.
Klynger kan både anvendes til at sikre oppetiden i systemet og til at sikre, at den nødvendige cpu-kraft altid er til stede til den aktuelle opgave.
Der er flere årsager til, at det kan være interessant at sætte systemer i en klynge.
Den mest kendte er fejltolerance, hvor et enkelt fejlende system ikke påvirker funktionen af hele klyngen. Sådanne systemer anvendes ofte til e-handelssystemer eller databaser, hvor nedetid kan være fatal for en virksomhed.
Klynger kan også anvendes som udvidelsesmuligheder for et serversystem. Her kan systemer tilføjes klyngen, og forøge dens ydeevne. Det anvendes ved applikationer, hvor det maksimale antal af brugere ikke er kendt. Typisk web-servere og databaser.
Endelig kan klynger bruges til massive beregningsopgaver, hvor veldefinerede beregningsopgaver kan fordeles på et stort antal systemer. Det kan være generering af filmbilleder til en film som Starwars, eller tekniske udregninger som dem der ligger bag vejrudsigten.
Dele eller ikke dele data
Disse tre klyngetyper har yderligere en opdeling, som er baseret på klyngens tilgang til data. Alle maskiner i en klynge kan have adgang til alle data i systemet (share all) eller hver maskine kan have private data (share none).
Den sidste teknologi er langt den simpleste at opbygge, men udelukker muligheden for at systemerne kan arbejde sammen og fordele belastningen.
Dertil har bevægelsen mod øget serverkonsolidering bevirket, at man i dag ser multi-cpu-serversystemer, som kan opdeles (partitioning), så man kan danne interne klynger.
I løbet af de seneste par år er klynger gået fra rene hardwareløsninger til også at være software-løsninger. Det er specielt dotcom-eventyret, der har sat sving i softwarebaserede klyngeløsninger, idet man ønskede fejlsikre web-applikationsløsninger.
Billedtekst:
IBM's designere af Intel-servere har kigget deres store systemer efter i sømmene og er kommet med en server, der har moduler med fire cpu'er, som kan enten bruges til en opdelt server, hvor hver opdeling er et cpu-modul, eller opbygge multi-cpu systemer. Der er i øjeblikket mulighed for op til fire cpu-moduler.
Billedtekst:
Den traditionelle klynge bestående af to servere med et lagringssystem imellem. Her et HP Itanium klyngesystem.
Boks:
Fire typer klynger
Klynge med share nothing: Det betyder, at et system i klyngen har sine egne applikationer og diske samt sine egne brugere. Falder det ene system dødt om, så overtages alle aktiviteter af den overlevende server.
Det er simpelt rent teknisk at lave sådanne klyngesystemer, men alle applikationer skal være programmeret til klyngebrug, eller der skal være en mekanisme til at starte dem på den overlevende server.
Microsofts klyngeteknologi bygger på denne teknologi. Der eksisterer også flere andre software-klyngessystemer, der bygger på share none-strategien. Formålet med denne type af klynger er udelukkende at sikre systemets fejltolerance. De andre servere i en klynge skal være dimensioneret til at kunne klare den øgede belastning, sådan at belastningen fra en fejlende server ikke river den overtagende servere med ned, som derefter bliver reddet af ny servere, der heller ikke kan klare belastningen. Når systemet konfigueres, skal der bestemmes en såkaldt failover-strategi. Den skal bestemmes manuelt, idet der ikke er nogen automatik i denne form for klyngeteknologi.
På softwaresiden er der systemer som Veritas Cluster servere, der kan lime både Linux, Windows, Solaris, HP/UX og AIX sammen.
Klynge med share all: Her deler alle maskiner i klyngen alt. Brugere, diske og applikationer deles på tværs af alle maskiner. Klyngens styreprocessorer fordeler aktiviteter og brugere rundt til maskinerne i klyngen. Alle systemer kan se alle diske og dermed alle data.
Denne type af klyngesystemer har den fordel, at klyngens totale kapacitet kan forøges simpelthen ved at sætte ekstra servere ind i klyngen.
Ulempen ligger i kompleksiteten af klyngens nødvendige styreprocessor og prisen af den ekstra hardware. Styreprocessoren er typisk meget kompleks og kan være et fejlpunkt i klyngen. Til gengæld skal der ingen ændringer til i applikationerne for, at de kan udnytte klyngemulighederne fuldt ud.
HP Open VMS Clustering og IBM Parallel Sysplex er hardwaresystemer efter denne model. Styresystemet skal være specialdesignet til denne type klynger, ligesom filsystemet skal kunne håndere adgang fra flere systemer samtidigt.
På applikationssiden er der for nyligt kommet systemer som Oracle Real Application Cluster, der giver mulighed for at samle en flok database-servere til en stor server. Oracles teknologi er en simuleret hardwareløsning, hvor en virtuel klyngestyreprocessor klarer ressoucetildelingen.
Opdelte servere: En opdelt server kan enten køre flere uafhængige kopier af et styresystem i hver sin opdeling eller for eksempel Unix/Linux i en opdeling og Windows 2000 server i en anden. Dør et styresystem i en af opdelingerne, så mærker de andre det ikke.
Til hver opdeling er knyttet diske og netværkskomponenter, og styresystemet ser opdelingen som en helt separat maskine. Derved kan alle applikationer i en virksomhed konsolideres på en enkelt server. Det betyder, at der opnås alle fordele ved kun at have en fysisk server-kasse i maskinstuen, samtidig med at applikationerne er isoleret fra hinanden, som de ville være på flere separate servere. Løsningen er dermed ikke katastrofetolerant, idet en enkelt vandskade i maskinstuen vil kunne stoppe hele klyngen, og i sig selv er en opdelt server ikke fejltolerant, men den er en god basis for at kunne lave interne klyngesystemer.
Fordelene ved denne type klynger ligger i besparelsen ved hardware, mulighed for hurtig kommunikation mellem de enkelte medlemmer i klyngen via serverens interne databus og mulighed for dynamisk at kunne variere størrelsen af de enkelte opdelinger.
Har serveren for eksempel to opdelinger - en med et e-postsystem og en med et virksomhedssystem - så kan et torpederet e-postsystem ikke hive virksomhedssystemet med ned i dybet. Hvis applikationerne bare kørte på en ottevejs server, ville hele systemet dø.
En fordel ved opdelte servere er muligheden for at kunne flytte rundt på opdelingerne, så cpu'erne kan fordeles mellem de enkelte applikationer. Dynamisk opdeling er en teknologi, som er på vej. Derved kan en applikation gives ekstra ressourcer under driften, eller en død cpu kan skilles ud og skiftes under drift. Både IBM med deres xSeries x440 servere og Unisys med deres ES7000 serie af maskiner, har systemer på markedet, som har muligheder for avanceret partitionering. Også på licenssiden er der penge at spare. En ting som lurer i horisonten er muligheden for betaling efter forbug. Man kunne forestille sig, at serveren kom med for eksempel 16 cpu'er, men at man normalt kun bruger og betaler for 12 cpu'er. Under spidsbelastninger lukker man op for de sidste fire cpu'er og betaler leverandøren for den periode, hvor de ekstra ressourcer udnyttes. Det er i øvrigt en nem måde at opgradere en server på, som oprindeligt stammer fra mainframesystemer. En IBM zSeriesserver kan endda selv finde ud af at opgradere sig, når det er nødvendigt, og den sender sågar næsten selv regningen.
IP-klynger: Her er det TCP/IP-adresser, som deles i en klynge. Set fra brugerens synspunkt optræder klyngen som en stor server.
Lidt uformelt kunne man tale om level 4 switching, hvor en fysisk eller software-baseret switch styrer tilgangen til en flok servere via IP-portnummeret.
Klyngesoftwaren forbinder en bruger til den mest ledige server i klyngen og fortæller de andre servere i klyngen om det. Skulle en server dø, så snupper de andre servere i klyngen IP-klienterne fra den.
Brugerne oplever en pause i aktiviteterne, men opdager ikke, at der bag deres rygge er skiftet en server.
Der er flere hardwareløsninger til denne type klynger. Der er flere løsninger på Linux, ligesom Computer Associates og Novell har løsninger til henholdsvis Windows NT og NetWare, hvor der også flyttes data rundt i systemet alt efter klyngens tilstand. En ren IP-klynge har nemlig ingen data-replikering, da klyngen er på applikationsniveau. Derfor kræver denne klyngetype, at alle servere har lokale data, eller at der er en fælles databaseserver. JOSS
