Failover klynge

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 4. august 2016; checks kræver 9 redigeringer .

Failover cluster ( engelsk  High-Availability cluster , HA cluster  - high available cluster ) - en klynge (gruppe af servere ), designet i overensstemmelse med høj tilgængelighedsteknikker og garanterer minimal nedetid på grund af hardwareredundans. Uden klyngedannelse bevirker en serverfejl, at de applikationer eller netværkstjenester, den understøtter, er utilgængelige, indtil de er sikkerhedskopieret. Failover-klynger retter denne situation ved at genstarte applikationer på andre noder i klyngen uden administratorindgriben, hvis der opdages hardware- eller softwarefejl. Genstartsprocessen er kendt som failover . Som en del af denne proces kan klyngesoftwaren yderligere konfigurere noden, før applikationen køres på den (f.eks. importere og montere de relevante filsystemer, omkonfigurere netværkshardwaren eller køre eventuelle hjælpeprogrammer).

Failover-klynger bruges i vid udstrækning til at understøtte kritiske databaser , netværksfillagring, forretningsapplikationer og kundeservicesystemer såsom e- handelswebsteder .

Implementeringer af HA-klynger er forsøg på at opnå fejltolerance for klyngen som helhed ved at eliminere kritiske fejlpunkter, herunder gennem redundans af computerkraft, netværksforbindelser og datalagring, kombineret til et redundant SAN .

Krav til applikationsarkitektur

Ikke alle applikationer kan køre i et meget tilgængeligt klyngemiljø. Der bør træffes passende beslutninger på et tidligt stadium af softwareudviklingen. For at køre i en HA-klynge skal en applikation mindst opfylde følgende tekniske krav, hvoraf de to sidste er afgørende for dens pålidelige drift i en klynge, og som er de sværeste at opfylde fuldt ud:

• Der burde være en forholdsvis enkel måde at starte, stoppe, tvinge stop og kontrollere status for en applikation. I praksis betyder det, at applikationen skal have en kommandolinjegrænseflade eller scripts for at administrere den, herunder til at arbejde med flere kørende forekomster af applikationen.
• Applikationen skal kunne bruge delt datalagring ( NAS / SAN ).
• Det er meget vigtigt, at applikationen skal gemme så mange data som muligt om dens nuværende tilstand i ikke-nedbrydeligt delt lager. Tilsvarende er muligheden for en applikation til at blive genstartet på en anden node i en præ-fejltilstand ved hjælp af tilstandsdata fra det delte lager lige så vigtig.
• Applikationen må ikke ødelægge data, når den går ned eller gendannes fra en gemt tilstand.

Byggeplaner

De mest almindelige to-node HA-klynger er den mindste konfiguration, der kræves for at give fejltolerance. Men ofte indeholder klynger meget mere, nogle gange snesevis af noder. Alle disse konfigurationer kan generelt beskrives af en af ​​følgende modeller:

• Aktiv / aktiv - En del af den trafik, der behandles af den fejlslagne knude, omdirigeres til en arbejdsknude eller fordelt på flere arbejdsknudepunkter. Dette skema bruges, når noderne har en homogen softwarekonfiguration og udfører den samme opgave.
• Aktiv / passiv - Har en fuld redundans (sund kopi) af hver node. Reserven træder kun i drift, når den tilsvarende hovedknude svigter. Denne konfiguration kræver betydelig redundant hardware.
• N + 1 - Har en fuldgyldig backup-knude, hvortil rollen som den mislykkede knude går over på tidspunktet for fejlen. I tilfælde af en heterogen softwarekonfiguration af de primære noder, skal den sekundære node være i stand til at påtage sig rollen som enhver af de primære noder, den er ansvarlig for redundant. Dette skema bruges i klynger, der betjener flere heterogene tjenester, der kører samtidigt; i tilfælde af en enkelt tjeneste degenererer en sådan konfiguration til Aktiv / passiv.
• N + M - Hvis en enkelt klynge betjener flere tjenester, er inklusiv en enkelt redundant node muligvis ikke tilstrækkelig til et passende niveau af redundans. I sådanne tilfælde inkluderer klyngen flere redundante servere, hvis antal er et kompromis mellem prisen på løsningen og den nødvendige pålidelighed.
• N-til-1 - Tillader, at standby-knuden kommer online midlertidigt, indtil den fejlbehæftede knude er gendannet, hvorefter den oprindelige belastning returneres til den primære knude for at opretholde det oprindelige niveau af systemtilgængelighed.
• N-til-N er en kombination af aktive/aktive og N+M-klynger. I en N-til-N-klynge omfordeles tjenester, systemforekomster eller forbindelser fra en mislykket node til de resterende aktive noder. Dette eliminerer (som i det aktive / aktive skema) behovet for en separat standby node, men samtidig skal alle klynge noder have en vis overskydende kapacitet over det minimum, der kræves.

Udtrykkene logisk vært eller clustered logical host bruges til at henvise til den netværksadresse, der bruges til at få adgang til de tjenester, der leveres af klyngen. Det logiske værts-id er ikke bundet til en enkelt klynge node. Det er faktisk en netværksadresse/navn, der er knyttet til den eller de tjenester, der leveres af klyngen. Hvis en klynge node med fx en kørende database går ned, vil databasen blive genstartet på en anden klynge node, og netværksadressen, hvor brugerne får adgang til databasen, vil blive bevaret for enhver ny node, så brugerne vil stadig have adgang til databasen.

Pålidelighed af en enkelt node

HA-klynger, ud over de beskrevne inter-node redundansskemaer, bruger alle de metoder, der normalt bruges i separate (ikke-klynge) systemer og netværksinfrastruktur for at maksimere pålideligheden. Disse omfatter:

• Diskredundans og replikering: Fejl på nogle af de interne diske fører ikke til systemfejl. DRBD er et eksempel.
• Redundans af eksterne netværksforbindelser : kabelfejl, switch eller netværksgrænsefladefejl fører ikke til fuldstændig afbrydelse af netværket.
• Redundante SAN- forbindelser ( Storage Area Network ) : kabelfejl, switch- eller netværksinterfacefejl vil ikke få serverne til at miste forbindelsen til lageret (dette ville bryde den ikke-delte arkitektur).
• Redundante strømforsyningsordninger for forskelligt udstyr, normalt beskyttet af uafbrydelige strømforsyninger , og redundante strømforsyninger : svigt af en enkelt indgang , kabel, UPS eller PSU fører ikke til et kritisk strømsvigt i systemet.

Individuelle node-oppetidsmål hjælper med at minimere chancerne for at ty til native failover-klyngemekanismer. Hvis sidstnævnte er aktiveret, kan adgangen til tjenesten blive afbrudt, selv om det kun er i kort tid, og det er mere hensigtsmæssigt at forhindre kritiske udstyrsfejl.

Fejlgendannelsesalgoritmer

Systemer, der håndterer fejl i distribuerede computersystemer, bruger forskellige strategier til at håndtere konsekvenserne af en fejl. For eksempel giver Apache Cassandra API Hector (API) tre muligheder for fejlhåndtering:

• Fail Fast , i scriptet - "FAIL_FAST", returnerer blot en fejl til klienten, når noden ikke er tilgængelig.
• Ved mislykket, prøv en - næste tilgængelig , i scriptet - "ON_FAIL_TRY_ONE_NEXT_AVAILABLE", betyder, at når en node fejler, forsøger systemet at overføre anmodningen til en anden node, den mest ledige, og returnerer en fejl efter det første mislykkede forsøg.
• Ved mislykket, prøv alle , i scriptet - "ON_FAIL_TRY_ALL_AVAILABLE", betyder, at systemet, efter det første mislykkede forsøg, sekventielt prøver alle tilgængelige noder, og først derefter returnerer en fejl.

For at kontrollere sundheden for knuder i en klynge transmitteres et kontinuerligt periodisk signal ("puls", engelsk  hjerteslag ) normalt i klyngens interne netværk fra hver af knudepunkterne, ved hvis tilstedeværelse kontrolsoftwaren bedømmer den normale drift af naboknuder. Et ikke-oplagt, men alvorligt problem med "split-brain_(computing)" er forbundet med dette -  i tilfælde af samtidig afbrydelse af mange forbindelser i klyngens interne netværk på grund af strømsvigt, netværksudstyrsfejl mv. , vil noden ikke være i stand til at håndtere denne situation korrekt, begynder at opføre sig, som om alle andre klynge noder har fejlet, og starter duplikerede tjenester, der allerede kører i klyngen, hvilket kan føre til datakorruption i det delte lager.

Se også

• Klynge (gruppe af computere)
• Server (hardware)
• Mainframe
• Serverrum

Noter

Links