Enkelt punkt af fejl henvises til en komponent i et system, hvor det mislykkes, producerer en afbrydelse af hele systemet. I sektoren Informationsteknologi er en Cluster giver mulighed for at forberede systemet for at undgå risikoen for denne slags situationer, der består af mindst 2 synkroniserede noder, der tillader, at når en af ​​noden fejler, tager den anden ansvaret for at tage sig af tjenesterne.

Hvorfor en Cluster

Lastbalancering er en opgave at levere en enkelt netværkstjeneste fra flere servere, nogle gange kendt som en server farm.

Lastbalanceren er som regel et softwareprogram, der er indlejret i en virtuel eller fysisk hardware, der lytter på porten, hvor eksterne klienter forbinder til adgangstjenester. Lastbalanceren videresender anmodninger til en af ​​backend-serverne, som normalt svarer til belastningsbalanceren. Dette gør det muligt for load balancer at svare på klienten uden at kunden nogensinde har kendskab til den interne adskillelse af funktioner. Det kan automatisk give den nødvendige kapacitet til at reagere på enhver stigning eller nedsættelse af applikationstrafik. I det næste diagram kan vi se en typisk netværkskonfiguration til visning af en webapplikation.

Det forhindrer også klienter i at kontakte direkte med bagenden, hvilket kan have sikkerhedsfordele ved at skjule strukturen i det interne netværk og forhindre angreb på kernenetværksstakken eller ikke-relaterede tjenester, der kører på andre porte, men ... Hvad sker der, hvis belastningsbalancen fejler?

Lastbalancering giver IT-teamet en chance for at opnå en signifikant højere fejltolerance. Det er grunden til, at belastningsbalanceren i sig selv ikke bliver et eneste punkt i fiasko. Lastbalancere skal implementeres i høj tilgængelighedsklynge, dvs. et par apparater. Det samme eksempel med en HA-klynge til belastningsbalancering kan være:

Vi har set betydningen af ​​at etablere en HA-klynge. Nu skal vi se, hvordan du konfigurerer det med Zevenet Load Balancer.

Klyngekrav

Når du konfigurerer en ny kluster, skal du sikre dig, at begge noder bruger den samme kerneversion (dvs. samme model af apparat).

1. Sørg for, at ntp-tjenesten er konfigureret og fungerer fint i begge fremtidige noder i klyngen.
2. Sørg for, at DNS'en er konfigureret og fungerer fint i begge fremtidige noder i klyngen.
3. Sørg for, at der er ping mellem de fremtidige klyngemedlemmer gennem den anvendte grænseflade for klyngen (dvs.: IP af eth0 i node1 og IP for eth0 i node2).
4. Det anbefales at tildele en grænseflade til cluster-tjenesten.
5. Cluster-tjenesten bruger multicast-kommunikation og VRRP-pakker i unicast-tilstand, så sørg for, at denne slags pakker er tilladt i dine kontakter.
6. Når klyngetjenesten er aktiveret, slettes gårdene og de virtuelle grænseflader på slaveknuden, og nodemesterens konfiguration vil blive replikeret til slaven.

Cluster Configuration for Zevenet Community Edition

For at gøre en korrekt klynge konfiguration for community udgave v5 eller højere skal du følge denne procedure:

Sådan konfigureres en klynge i Zevenet Community Edition v.5.0

Cluster Configuration til Zevenet Enterprise Edition

Zevenet Enterprise Edition Cluster-tjenesten er fuldt integreret i Zevenet Core, den kan administreres og konfigureres let som følger:

1. Gå til webgui-grænsefladen, gå til sidemenuen “SYSTEM> Klynge”.
2. Tryk i markeret felt "Klynge lokal IP", og vælg dedikeret grænseflade til cluster service
3. Indtast den sekundære nodes IP i samme netværksinterface, du har valgt i første node
4. Indtast slave rod adgangskoden i feltet "Cluster Remote Root Password" og skriv den samme adgangskode igen i feltet "Cluster Remote Root Password"
5. Klik nu på "Skab" og klusterkonfigurationsprocessen starter

.

Hvis du har brug for yderligere oplysninger, kan du besøge artiklen Konfigurer klyngetjenesten