Failover-kluster

Failover-kluster ( engelska  High-Availability cluster , HA-kluster  - hög tillgänglighetskluster ) - ett kluster (grupp av servrar ), designat i enlighet med hög tillgänglighetsteknik och garanterar minimal driftstopp på grund av hårdvaruredundans. Utan klustring gör ett serverfel att de applikationer eller nätverkstjänster som den stöder är otillgängliga förrän de har säkerhetskopierats. Failover-klustring korrigerar denna situation genom att starta om program på andra noder i klustret utan administratörsingripande om maskinvaru- eller programvarufel upptäcks. Omstartsprocessen är känd som failover . Som en del av denna process kan klustringsmjukvaran ytterligare konfigurera noden innan applikationen körs på den (till exempel importera och montera lämpliga filsystem, konfigurera om nätverkshårdvaran eller köra några verktygsprogram).

Failover-kluster används ofta för att stödja kritiska databaser , lagring av nätverksfiler, affärsapplikationer och kundtjänstsystem som e- handelssajter .

Implementeringar av HA-kluster är försök att uppnå feltolerans för klustret som helhet genom att eliminera kritiska felpunkter, inklusive genom redundans av datorkraft, nätverksanslutningar och datalagring, kombinerat till ett redundant SAN .

Applikationsarkitekturkrav

Inte alla program kan köras i en högtillgänglig klustrad miljö. Lämpliga beslut bör fattas i ett tidigt skede av mjukvaruutvecklingen. För att köras i ett HA-kluster måste en applikation uppfylla minst följande tekniska krav, varav de två sista är avgörande för dess tillförlitliga drift i ett kluster, och som är svårast att till fullo uppfylla:

• Det bör finnas ett relativt enkelt sätt att starta, stoppa, tvinga fram stopp och kontrollera status för en applikation. I praktiken innebär detta att applikationen måste ha ett kommandoradsgränssnitt eller skript för att hantera det, inklusive för att arbeta med flera körande instanser av applikationen.
• Applikationen måste kunna använda delad datalagring ( NAS / SAN ).
• Det är mycket viktigt att applikationen lagrar så mycket data som möjligt om dess nuvarande tillstånd i oförstörbar delad lagring. På motsvarande sätt är möjligheten för en applikation att startas om på en annan nod i ett förfelstillstånd med tillståndsdata från det delade minnet lika viktigt.
• Applikationen får inte korrumpera data när den kraschar eller återställs från ett sparat läge.

Konstruktionsscheman

De vanligaste HA-klustren med två noder är den minsta konfiguration som krävs för att ge feltolerans. Men ofta innehåller kluster mycket mer, ibland dussintals noder. Alla dessa konfigurationer kan generellt beskrivas av en av följande modeller:

• Aktiv / aktiv - En del av trafiken som bearbetas av den misslyckade noden omdirigeras till någon fungerande nod eller fördelas på flera arbetsnoder. Detta schema används när noderna har en homogen mjukvarukonfiguration och utför samma uppgift.
• Aktiv / passiv - Har en full redundans (hälsosam kopia) av varje nod. Reserven träder i drift endast när motsvarande huvudnod misslyckas. Denna konfiguration kräver betydande redundant hårdvara.
• N + 1 - Har en fullfjädrad backupnod, till vilken rollen för den misslyckade noden övergår vid tidpunkten för felet. I fallet med en heterogen mjukvarukonfiguration av de primära noderna, måste den sekundära noden kunna ta på sig rollen som vilken som helst av de primära noderna som den är ansvarig för redundant. Detta schema används i kluster som betjänar flera heterogena tjänster som körs samtidigt; i fallet med en enda tjänst degenererar en sådan konfiguration till Aktiv / passiv.
• N + M - Om ett enda kluster betjänar flera tjänster, kanske en enda redundant nod inte är tillräcklig för en adekvat nivå av redundans. I sådana fall innehåller klustret flera redundanta servrar, vars antal är en kompromiss mellan priset på lösningen och den tillförlitlighet som krävs.
• N-till-1 - Tillåter standby-noden att komma online tillfälligt tills den misslyckade noden återställs, varefter den ursprungliga belastningen återförs till den primära noden för att bibehålla den ursprungliga nivån av systemtillgänglighet.
• N-till-N är en kombination av aktiva/aktiva och N+M-kluster. I ett N-till-N-kluster omfördelas tjänster, systeminstanser eller anslutningar från en misslyckad nod till de återstående aktiva noderna. Detta eliminerar (som i det aktiva/aktiva schemat) behovet av en separat standbynod, men samtidigt måste alla klusternoder ha en viss överkapacitet över det minimum som krävs.

Termerna logisk värd eller klustrad logisk värd används för att hänvisa till nätverksadressen som används för att komma åt tjänsterna som tillhandahålls av klustret. Det logiska värd-ID:t är inte bundet till en enda klusternod. Det är faktiskt en nätverksadress/namn som är associerat med tjänsten/tjänsterna som tillhandahålls av klustret. Om en klusternod med till exempel en körande databas går ner, kommer databasen att startas om på en annan klusternod, och nätverksadressen där användarna kommer åt databasen kommer att bevaras för alla nya noder, så användare kommer fortfarande att ha tillgång till databasen.

Tillförlitlighet för en enda nod

HA-kluster, förutom de beskrivna inter-nod-redundansscheman, använder alla metoder som vanligtvis används i separata (icke-kluster) system och nätverksinfrastruktur för att maximera tillförlitligheten. Dessa inkluderar:

• Diskredundans och replikering: Fel på några av de interna diskarna leder inte till systemfel. DRBD är ett exempel.
• Redundans för externa nätverksanslutningar : kabelfel, switch eller nätverksgränssnittsfel leder inte till en fullständig frånkoppling från nätverket.
• Redundanta SAN - anslutningar : kabelfel, switch- eller nätverksgränssnittsfel kommer inte att leda till att servrarna tappar anslutningen till lagringen (detta skulle bryta den icke-delade arkitekturen).
• Redundanta strömförsörjningsscheman för olika utrustningar, vanligtvis skyddade av avbrottsfri strömförsörjning , och redundant strömförsörjning : fel på en enda ingång , kabel, UPS eller PSU leder inte till ett kritiskt strömavbrott i systemet.

Individuella nodupptidsmått hjälper till att minimera chanserna att tillgripa inbyggda failover-klustringsmekanismer. Om de senare är aktiverade kan tillgången till tjänsten avbrytas, även om det bara är för en kort tid, och det är mer ändamålsenligt att förhindra kritiska utrustningsfel.

Felåterställningsalgoritmer

System som hanterar fel i distribuerade datorsystem använder olika strategier för att hantera konsekvenserna av ett fel. Till exempel erbjuder Apache Cassandra API Hector (API) tre alternativ för felhantering:

• Fail Fast , i skriptet - "FAIL_FAST", returnerar helt enkelt ett fel till klienten när noden är otillgänglig.
• Vid misslyckande, prova en - nästa tillgänglig , i skriptet - "ON_FAIL_TRY_ONE_NEXT_AVAILABLE", betyder att när en nod misslyckas, försöker systemet överföra begäran till en annan nod, den mest lediga, och returnerar ett fel efter det första misslyckade försöket.
• Vid misslyckande, försök alla , i skriptet - "ON_FAIL_TRY_ALL_AVAILABLE", betyder att systemet, efter det första misslyckade försöket, sekventiellt försöker alla tillgängliga noder, och först då returnerar ett fel.

För att kontrollera tillståndet hos noderna i ett kluster sänds vanligtvis en kontinuerlig periodisk signal ("puls", engelska  hjärtslag ) i klustrets interna nätverk från var och en av noderna, genom vilken kontrollprogramvaran bedömer den normala driften. av angränsande noder. Ett icke-uppenbart, men allvarligt problem med "split-brain_(computing)" är kopplat till detta -  i händelse av ett samtidigt avbrott i många anslutningar i klustrets interna nätverk på grund av ett strömavbrott, nätverksutrustningsfel, etc. , noden kommer inte att kunna hantera denna situation korrekt, börjar bete sig som om alla andra klusternoder har misslyckats och startar dubbla tjänster som redan körs i klustret, vilket kan leda till datakorruption i den delade lagringen.

Se även

• Kluster (grupp av datorer)
• Server (hårdvara)
• Stordator
• Server rum

Anteckningar

Länkar