Klynge
Fra Wikipedia, den frie encyklopedi.
En klynge (engelsk: cluster) er to eller flere datamaskiner som er konfigurert til å avlaste hverandre på en eller flere måter. Klynger finner vi der oppetid eller lastfordeling anses som viktig.
Man deler gjerne inn klynger i flere kategorier som dekkes nærmere under. Det er viktig å være oppmerksom på at disse klynge-typene bare i prinsippet er ulike. I praksis kan en bygge klynger som en blanding av flere av disse typene for å oppnå både 100% oppetid, lastfordeling og dynamisk ressursfordeling.
Hver datamaskin i en klynge kalles en node i klyngen.
| Innholdsfortegnelse |
HA (High Availability)-klynger
Denne klyngekonfigurasjonen baserer seg på at (minst) ett system står klar til å overta om primært system skulle oppleve en feilsituasjon. I Linux benyttes gjerne heartbeat til dette. HA-klynger er veldig lett å bygge med Linux, men både SUSE og Red Hat har kommersielle produkter -- begge er basert på heartbeat-programvaren.
De fleste HA-klynger er rene «failover»-klynger. En klynge har (minst) to noder, hvorav den ene er aktiv («hot») og kjører den klyngede applikasjonen. De(n) andre noden(e) er passiv(e) («hot standby»). Dersom HA-programvaren (f. eks. den allerede nevnte heartbeat-programvaren) oppdager at den aktive maskinen har et eller annet problem, iverksettes failover: Den aktive noden stenges ned og den passive noden tar over. De to maskinene har gjerne hver sin private IP-adresse og den aktive noden har en virtuell IP-adresse som overtas av den andre noden når failover skjer. Dermed merker kanskje brukerne et avbrudd i tjenestene - men etter at failover-prosedyren er ferdig, kan de igjen få tak i tjenesten fra samme IP-adresse som før. Med andre ord er det ikke nødvendig med noe rekonfigurering av klientprogramvaren i forbindelse med failover-prosedyren.
Det fins også HA-klynger hvor man fordeler to eller flere tjenester på to eller flere maskiner, slik at en tjeneste har gravitet til en node. Hvis noden er utilgjengelig, flytter tjenesten til en annen node.
Regneklynger
Oftest kalt HPC (se High Performance Computing (http://linuxhpc.org)). Trikset med denne typen klynge er at du må dele opp jobben i flere små jobber og så fordele disse jobbene til de tilgjengelige nodene.
I Linuxsammenheng nevnes ofte Beowulf [1] (http://www.beowulf.org/). Det er ingen streng definisjon på hva en Beowulf er -- det kan ansees som et klynge-konsept eller en programvare og kjerne-patch samling. En Beowulf-klynge består helt sikkert av et antall billige datamaskiner og et nettverk mellom dem.
Beowulf-klynger benytter ofte APIene PVM eller MPI. Dette er programvarebiblioteker for å kommunisere mellom klyngenoder. Men de kan like godt bruke hjemmelagde shell- eller Perl-skript til å fordele jobber. Det finnes også programvare for jobb-kø som er i stand til å distribuere oppgavene til nodene. Distcc er et spesialisert eksempel på dette, men det finnes minst en fri (Condor (http://www.cs.wisc.edu/condor/)) og flere kommersielle jobbfordelingsapplikasjoner, f.eks. Scali og Platform software LFS. Denne type applikasjoner kalles ofte «job schedulers» eller «queue managers».
Dersom du skriver beregningsprogramvaren sin selv er det oftest veldig lett for deg å se hvordan jobbene kan deles opp og hvordan jobbene best kan fordeles mellom noder.
Lastfordelingsklynger
Denne typen klynge har prosessfordeling implementert i operativsystemkjernen, slik at lastbalanseringen og/eller jobbfordelingen skjer på kjernenivå. Her brukes som regel OpenMOSIX. MOSIX sender krevende jobber fra maskin til maskin i klyngen uten at programmet merker noe til det eller brukeren trenger å gjøre noe.
Lastfordeling kan også gjøres på mange andre måter. For nettverkstjenester kan brannveggliknende nettverkskomponenter overvåke lasten på de tilgjengelige nodene og bruke NATing til å sende nettverkstrafikken til en lite belastet node.
GRID-klynger
GRID-klynging har lenge vært et buzzword. En GRID-klynge bygger en ved å ta en haug datamaskiner og så putte et program for ressursforvaltning (jobbfordeling) på toppen for å fordele jobber til dem. Dette likner på mange måter på en Beowulf-klynge. Hovedpoenget med en GRID-klynge synes å være at hvis en oppgave trenger flere ressurser, kan en ta en ledig node og bruke den i tillegg - altså dynamisk node-alokkering. Tidligere nevnte Condor (http://www.cs.wisc.edu/condor/) er fri ressursforvaltningsprogramvare som er laget for GRID-klynger.
