Oversigt #

Formålet med den følgende artikel er at give et arkitektonisk overblik over RELIANOID Load Balancer intern software målrettet systemadministratorer og softwareudviklere med interesser for at vide mere om hvordan RELIANOID ADC-software virker. Alle disse oplysninger kan også bruges til at hjælpe med konfigurationen af ​​produktionssystemer eller fejlfindingsformål.

RELIANOID arkitektur #

RELIANOID styrer processer fra både bruger- og kerneplads, hvilket gør det muligt at samle den største ydeevne, men med den største fleksibilitet også til at udføre alle de opgaver, der er delegeret til applikationsleveringscontrolleren, såsom belastningsbalancering, sikkerhed og høj tilgængelighed.

Diagrammet nedenfor giver et globalt overblik over de forskellige komponenter, der udgør RELIANOID system internt. Yderligere stykker af mindre betydning er blevet savnet for at give et enklere og klart overblik.

De følgende afsnit vil blive beskrevet de forskellige stykker, og hvordan de er forbundet med hinanden.

RELIANOID Load Balancer i brugerrummet #

De undersystemer, der bruges i User Space er:

Web GUI: webgrafisk brugergrænseflade, der bruges af brugere til at styre konfigurationen og administrationen af ​​hele systemet, den administreres af en HTTPS-webserver, som bruger RELIANOID API for alle de handlinger, der udføres på belastningsbalanceren.

RELIANOID API'er: or RELIANOID Applikationsprogramgrænseflade, designet efter REST og JSON grænseflader, forbrugt gennem HTTPS, bruges den af ​​andre forskellige brugergrænseflader fra brugerens synspunkt, som f.eks. web GUI interface eller ZCLI (RELIANOID kommandolinjegrænseflade). Dette værktøj kontrollerer enhver handling mod RBAC-delsystemet, og hvis det er tilladt, foretages handlingen i RELIANOID Apparat. API'en er i stand til at forbinde og administrere et hvilket som helst andet brugerområde-undersystem, der er beskrevet i diagrammet.

RBAC: Rollebaseret adgangskontrol er en adgangs- og kontrolmekanisme defineret omkring brugere, grupper og roller. Dette modul definerer, hvilke handlinger en bruger må udføre med et højt niveau af konfiguration mellem grupper, brugere og roller. Det er fuldstændig integreret i web-GUI-grænsefladen, der tillader at indlæse webvisningerne baseret på brugerrollen. Derudover forbruges dette delsystem gennem API eller ethvert andet værktøj, der bruger API.

LSLB – HTTP(S): LSLB-modulet (Local Service Load Balancer), der er sammensat af HTTP(S)-profilen, udføres i brugerrummet af en omvendt proxy kaldet Zproxy, som er i stand til at håndtere højgennemstrømningsapplikationer meget effektivt. Dette undersystem er konfigureret af API'en og kan beskyttes af IPDS-undersystemet (ved hjælp af BlackLists, DoS-regler, RBL- og WAF-regelsæt).

GSLB: GSLB-modulet (Global Service Load Balancer) implementeret med en GSLB-profilinstans udføres i brugerrummet af en DNS-serverproces kaldet Gdnsd, der er i stand til at fungere som en avanceret DNS-navneserver med belastningsbalanceringsfunktioner. Dette undersystem er konfigureret af API'en og kan beskyttes af IPDS-undersystemet (ved hjælp af BlackLists, DoS og RBL).

Sundhedstjek: Dette undersystem er konfigureret af API'en og bruges af alle load balancer-modulerne (LSLB, GSLB og DSLB) til at kontrollere backends' tilstand. Simple og avancerede checks udføres mod backend, og hvis checken mislykkes, markeres backend for den givne farm som nede, og der videresendes ikke mere trafik, før checken igen virker mod backend. Farm Guardian er ansvarlig for disse kontroller, og den er designet med et højt niveau af fleksibilitet og konfigurerbarhed.

Konfigurationsfilsystem: Denne mappe bruges til at gemme konfigurationen, enhver ændring i denne mappe vil blive replikeret til klyngen, hvis en sådan tjeneste er aktiveret.

Nftlb: Denne brugerrumsproces administreres af API-undersystemet og bruges til to hovedformål: LSLB – L4XNAT styring og konfiguration af IPDS delsystem modul.

RELIANOID Load Balancer i Kernel Space #

De undersystemer, der bruges i Kernel Space er:

Netfiltersystem LSLB L4xNAT: Netfilter-undersystemet bruges af Nftlb til belastningsbalancering. Netfilter-regler indlæses i kernen af ​​denne Nftlb-proces for at byg en højtydende L4 load balancer. Nftlb indlæser load balancer-reglerne i kernen på en effektiv måde for at styre trafikpakkerne så optimalt som muligt. Derudover vil Nftlb indlæse Netfilter-regler til forebyggelse og beskyttelse af indtrængen (BlackLists, RBL og DoS).

IPDS sortlister: Dette undersystem er integreret i Netfilter-systemet og administreres af Nftlb. Den er sammensat af en gruppe regler, der er konfigureret før belastningsbalancer-reglerne for at droppe forbindelser for de givne oprindelses-IP'er. Internt opretter det et sæt regler sorteret efter kategori, land, typer af angriber osv. og opdateret dagligt.

IPDS RBL: Analogt med det forrige er dette undersystem også integreret i Netfilter og administreres af Nftlb. Oprindelses-IP'en fanges før forbindelsesetableringen, og klient-IP'en valideres imod en ekstern DNS-tjeneste. Hvis IP'en er løst, markeres IP'en som ondsindet, og forbindelsen vil blive afbrudt.

IPDS DoS: Det samme konfigurationssystem som de to foregående moduler, integreret i Netfilter og administreret af Nftlb. Det er et sæt regler konfigureret før belastningsbalancereglerne, der kontrollerer om pakkerne er en del af en Denial of Service-angreb. Nogle regler anvendes på pakkestrømmen for at opsnappe angrebet, før det skal udføres.

Forbindelsessporingssystem: Dette system bruges af Netfilter-undersystemet til forbindelsesstyringsformål, netværksoversættelse og til statistik modul, Samt sundhedstjek subsystem for at tvinge forbindelseshandlinger i det øjeblik, et problem opdages i backend. Forbindelsessporingssystemet bruges også af Klyngeservice for at videresende forbindelsesstatus til klyngens anden knude, hvis en klyngemasterknude svigter, er den anden knude i stand til at styre trafikken i samme forbindelsesstatus som den forrige master.

Routing System og DSLB: Disse undersystemer administreres af API'en og konfigureres i Kernel-rummet. Routing-undersystemet er bygget med iproute2 hvilket giver os mulighed for at administrere flere routingtabeller i rækkefølge for at undgå at opretholde et komplekst regelsæt for statisk routing, desuden, takket være iproute2 er DSLB-modulet (Datalink Service Load Balancer) skabt for at give belastningsbalancering af uplinks med flere gateways.

I skrivende stund skriver denne artikel, RELIANOID 6 er i produktion, så disse undersystemer kan udvikle sig i fremtidige versioner for at tilbyde bedre ydeevne eller flere funktioner.

Yderligere dokumentation #

RELIANOID zproxy benchmarks, LSLB -HTTP(S) profil
RELIANOID nftlb benchmarks, LSLB – L4xNAT profil