Dette afsnit giver dig mulighed for at administrere klyngetjenesten, som sikrer høj tilgængelighed til belastningsbalancering via to samarbejdsnoder i aktiv-passiv tilstand.

Hvordan gør RELIANOID klyngearbejder #

Oversigt #

Stateful Cluster funktion i RELIANOID sikrer kontinuerlig tjenestetilgængelighed og fejltolerance ved at kombinere to noder, der fungerer sammen som en enkelt logisk enhed.

Det primære mål med denne opsætning er at forhindre afbrydelser i tjenesten og opretholde problemfri forbindelse fra klientens perspektiv, selv i tilfælde af en nodefejl.

En klynge består af to noder der arbejder i aktiv-passiv tilstand, hvor man fungerer som masternode og den anden som backup-node.

• masternode administrerer aktivt al klienttrafik, balancerer forbindelser til backend-servere og vedligeholder sessionsoplysninger i realtid.
• backup-node bliver i standbytilstand, der løbende synkroniserer dens konfigurations-, tilstands- og sessionsdata fra masteren, så den er klar til at overtage når som helst.

Hvis masternoden ikke reagerer eller ikke kan nås, overtager backupnoden automatisk kontrollen og sikrer uafbrudt levering af tjenester.

Valg af master- og backuprolle #

Bestemmelsen af ​​hvilken node der fungerer som Master og som fungerer som backup administreres af Keepalived, ved hjælp af VRRP (Virtual Router Redundancy Protocol) og grænsefladesporing mekanismer.

Hver klyngenode tildeles en prioritetsværdi, som påvirker mastervalgprocessen:

• Noden med den højeste prioritet vælges som master.
• Hvis begge noder har samme prioritet, bliver den med den laveste IP-adresse som standard master.

Keepalived overvåger løbende sporede grænseflader (netværksgrænseflader konfigureret til failover-detektion). Hvis en af ​​disse sporede grænseflader fejler eller bliver utilgængelig, vil nodens effektiv prioritet falder, hvilket tillader den anden node at overtage som master.

Dette sikrer, at trafikken altid dirigeres gennem den mest stabile og fuldt operationelle node.

Stateful Synchronization #

RELIANOID klynger opererer i tilstandsfuld tilstand, hvilket betyder, at sessionsdata og forbindelsestabeller synkroniseres mellem master- og backupnoderne i realtid.
Denne synkronisering gør det muligt for aktive klientsessioner at fortsætte, selv efter en failover – klienter oplever ikke afbrydelser eller behøver at genoprette forbindelsen, hvilket opretholder en problemfri brugeroplevelse.

Konfigurationsændringer, IPDS-indstillinger, SSL-certifikater og farmtilstande replikeres også automatisk, hvilket sikrer, at begge noder forbliver fuldt justeret til enhver tid.

Vedligeholdelsesadfærd #

Når der udføres vedligeholdelsesoperationer (f.eks. softwareopdateringer, konfigurationsændringer eller hardwareindgreb), kan klyngen midlertidigt justere master-backup-rollerne:

• Hvis vedligeholdelsestilstand er aktiveret på nuværende mester, backup-node forfremmer automatisk sig selv til herre og overtager aktive tjenester.
• Når vedligeholdelsen er fuldført, og noden er genaktiveret, tilslutter den sig klyngen igen som backup medmindre det er konfigureret som foretrukken master.

Denne mekanisme sikrer, at vedligeholdelsesaktiviteter kan udføres uden at forstyrre aktive klientforbindelser eller tilgængelighed.

Foretrukken masternode #

Administratorer kan konfigurere en foretrukken masternode inden for klyngen.

Denne indstilling sikrer, at når begge noder er online og stabile, vil den angivne foretrukne node automatisk genvinde hovedrolle, selvom den anden node midlertidigt overtog under en failover.

Fordele #

• Forudsigelig trafikruteføringKonsekvent mastervalg forenkler overvågning, logføring og trafikanalyse.
• KonfigurationskonsistensSikrer, at en kendt, stabil node forbliver standardkontrolpunktet.

Ulemper #

• Korte tjenesteskift: Når den foretrukne node vender tilbage og genvinder masterrollen, kan der forekomme en kort failover-hændelse, som potentielt nulstiller nogle sessioner.
• Mindre fleksibilitet i failover-kontrol: I visse tilfælde kan klyngen vende tilbage til den foretrukne master, selvom begge noder er sunde, hvilket kan medføre unødvendige overgange.

For prioritering af implementeringer maksimal oppetid og minimal afbrydelse, kan administratorer vælge at deaktivere den foretrukne masterindstilling.

Til miljøer hvor rollekonsistens og operationel forudsigelighed er kritiske, anbefales det at aktivere den foretrukne masternode.

Krav til oprettelse af en klynge #

Begge noder skal køre den samme Relianoid-version (dvs. samme apparatmodel).
Hver node skal have et unikt værtsnavn.
Ursynkroniseringen i hypervisoren bør deaktiveres. Brug af NTP-server anbefales i begge noder (mere information om konfiguration af NTP).
Begge noder skal have identiske NIC-navne (netværksgrænseflader) med forskellige IP-adresser i de samme undernet.
Begge noder skal have forbindelse til den anden node via port 22/TCP og tillade VRRP-pakker.
Begge noder skal have de samme sikkerhedspolitikker (adgang til tjenester og netværk).
Konfigurationsændringer må kun foretages på masternoden, aldrig på backupnoden.
Mellemliggende switching- og routing-enheder skal muligvis konfigureres for at forhindre konflikter med klyngeskift. Der kræves ingen promiskuøs tilstand, ændringer af MAC-adresse eller forfalskede transmissioner. Men klyngen vil være i stand til at sende uønskede ARP-pakker.
Det anbefales at indstille en flydende IP-adresse for at undgå nedetid på tjenesten under et klyngeskift. Mere information om flydende IP-adresser.

Når load balancing-tjenester skifter fra én node til en anden, administrerer backup-noden aktuelle forbindelser og tjenestestatus for at forhindre klientafbrydelser.

Klyngetjenestekomponenter #

Dette er hovedsiden til konfiguration af klyngen. Klyngetjenesten indeholder flere komponenter:

SynkroniseringSynkroniserer automatisk konfigurationer fra masteren til backupnoden ved hjælp af inotify og rsync ved SSHEnhver ændring, der anvendes i filsystemet i masternoden, som er relateret til de virtuelle tjenester eller den fælles konfiguration for de virtuelle tjenester, replikeres automatisk til backupnoden.
HjerteslagOvervåger klyngenodernes tilstand ved hjælp af VRRP protokol over multicast, muliggjort af holde i live.
Connection TrackingReplikerer forbindelsestilstande i realtid for at muliggøre problemfri failover uden at afbryde klient- eller backend-forbindelser ved hjælp af kontaktsporet service.
KommandoreplikeringSender og aktiverer konfigurationer fra masteren til backup-noden via zclustermanager via SSH.

Knuden hvor Cluster er konfigureret bliver masternoden. AdvarselEnhver tidligere konfiguration på backup-noden vil blive slettet, hvilket resulterer i tab af enhver Gårde (inklusive certifikater) Virtuelle grænseflader, IPDS-reglerOsv

Data replikeret i en klynge #

I et klyngemiljø sikrer datareplikering, at konfigurationen og tilstanden af ​​tjenesterne er ensartede mellem master- og backupnoderne. Nedenfor er de specifikke elementer, der replikeres på tværs af noderne:

• LSLB (Local Server Load Balancer), GSLB (Global Server Load Balancer), DSLB (Data Server Load Balancer) tjenester. Disse tjenester er afgørende for load balancing og replikeres for at sikre, at failover ikke forstyrrer trafikfordelingen, herunder konfiguration, sessioner og trafiktilstande.
• Statisk routing. Ruter defineret statisk replikeres for at opretholde ensartede netværksstier.
• RBAC-indstillinger (rollebaseret adgangskontrol). Brugerroller, tilladelser og relaterede indstillinger replikeres for at sikre, at sikkerhedspolitikker er ensartede på tværs af noder.
• Brugere, grupper og tilladelser. Brugerkonti, gruppemedlemskaber og tilhørende tilladelser synkroniseres.
• SSL-certifikater og Let's Encrypt-konfiguration. SSL-certifikater, inklusive dem der administreres af Let's Encrypt, replikeres for at sikre kommunikation og tjenester.
• Virtuelle, VLAN'er, bonding og flydende grænseflader. Netværksgrænsefladekonfigurationer såsom virtuelle grænseflader, VLAN'er, bonded grænseflader og flydende IP'er replikeres.
• VPN-tjenester. VPN-konfigurationer og -tilstande synkroniseres for at opretholde sikre forbindelser.
• IPDS-regler og -filer (Intrusion Prevention and Detection System). IPDS-regler og tilhørende filer replikeres for ensartet sikkerhedsovervågning.
• Farmguardians-konfiguration. Overvågnings- og sundhedstjekkonfigurationer for gårde (grupper af servere) replikeres.
• Meddelelsesindstillinger. Indstillinger for systemmeddelelser synkroniseres for at sikre, at alarmer er ensartede.

Ikke-replikerede data i en klynge #

• Fysiske NIC-grænseflader. Konfigurationer af fysiske netværkskort (NIC'er) replikeres ikke, fordi de er hardwarespecifikke.
• Standardgateways. Standardgatewayindstillinger er lokale for hver node og replikeres ikke.
• Konfiguration af lokale og eksterne tjenester. Tjenester som DNS, NTP (Network Time Protocol) og SNMP (Simple Network Management Protocol) konfigureres lokalt og replikeres ikke.
• API-nøgler. API-nøgler, der bruges til at få adgang til tjenester, replikeres ikke af sikkerhedsmæssige årsager.
• Aktiveringscertifikater. Aktiveringscertifikater for softwarelicenser replikeres ikke.
• Installerede pakker. Softwarepakker, der er installeret på noderne, synkroniseres ikke, da de kan variere mellem noder.
• Sikkerhedskopier. Genererede sikkerhedskopier er specifikke for hver node og replikeres derfor ikke på tværs af noder.

Konfigurer klyngetjeneste #

Lokal IPVælg mellem tilgængelige netværksgrænseflader til klyngeadministration (ingen virtuelle grænseflader tilladt).
Fjern IPIP-adressen på den fremtidige backup-node.
Adgangskode til fjernnodeRoot-adgangskode til den eksterne node (fremtidig sikkerhedskopiering).
Bekræft adgangskode til fjernnodeRoot-adgangskode til den eksterne node (fremtidig sikkerhedskopiering).

Når du har indtastet de nødvendige parametre, skal du klikke på Ansøg .

Vis klyngetjeneste #

Hvis klyngeservice er konfigureret og aktiv, viser den følgende oplysninger om tjenester, backends og handlinger:

grænsefladeNetværksgrænseflade, hvor klyngetjenester konfigureres.
failbackMulighed for at returnere load balancing-tjenester til masteren, når de bliver tilgængelige igen.
KontrolintervalTidsinterval for pulsmålinger mellem noder.
Sporede grænsefladerAktive netværksgrænseflader overvåges i realtid.

Klyngehandlinger #

Vis noderViser status for noder.
RedigereRediger konfigurationsindstillinger.
ØdelægFjern konfigurationsindstillinger og en node.

Vis noder handlingen viser en tabel med:

NodeAngiver, om noden er lokal eller fjern, afhængigt af den node, hvor du har været forbundet til web-GUI'en. Lokale vil være den node, som du i øjeblikket er forbundet til, og fjern er den fjerne node.
rollerViser om noden er Master (leverer i øjeblikket load balancing-tjenester), backup eller vedligeholdelse hvis det er en midlertidigt deaktiveret node.
IPIP-adressen for hver node.
hostnameVærtsnavn for hver node.
StatusNodestatus, angivet med:

• Rød. Fiasko.
• GråUopnåelig.
• OrangeVedligeholdelsestilstand.
• GrønOperationel.

BeskedFejlfindingsmeddelelser fra hver node.
handlingerValgmuligheder for hver node inkluderer.

• Aktiver vedligeholdelseDeaktiverer midlertidigt en node for vedligeholdelse for at undgå failover.
• Deaktiver vedligeholdelseAktiverer noden igen.

Klyngeindstillinger #

Globale indstillingsmuligheder tilgængelige:

failbackVælg hvilken load balancer der foretrækkes som master.
Sporgrænseflader, der skal overvågesOvervåg specifikke grænseflader (f.eks. LAN eller VLAN).
KontrolintervalTid mellem sundhedstjek fra backupnoden til masteren.

Klik på knappen Ansøg knappen for at gemme ændringerne.

Vedligeholdelse og opdateringer af klynger #

For at udføre vedligeholdelse eller opdatere en Relianoid-klynge med minimal nedetid, henvises til den detaljerede vejledning Opdatering RELIANOID Klynge med minimal nedetid.