Intro #

A proxyserver kan beskrives som en serverenhed eller -applikation, der formidler anmodninger fra kunder eller klienter, der forsøger at søge efter ressourcer fra flere servere, der leverer disse. Når det er forklaret, betyder det, at en proxyserver arbejder på vegne af kunden eller klienten, når tjenesten anmodes om, og muligvis skjuler den virkelige oprindelse eller kilde til anmodningen til serveren.

Processen går ud på, at klienten foretager anmodningen direkte til proxyserveren i stedet for kun at oprette forbindelse til en konkret server, der kan levere en anmodet ressource, såsom filer eller websteder, og derefter evaluerer proxyserveren anmodningen og udvikler de passende og nødvendige netværkstransaktioner. Dette er en måde at forenkle eller mere kontrollere kompleksiteten af ​​anmodningen, og desuden giver det andre fordele såsom sikkerhed, indholdsacceleration eller privatliv. Proxyer er designet til at indkapsle og strukturere de eksisterende distribuerede systemer. Nogle af de mest anvendte webnavigationsproxyer er Blæksprutte, privoxy eller SwiperProxy.

Nogle gange er en proxyserver ikke nok til at administrere antallet af samtidige brugere, eller selve proxyen er en enkelt mislykkelsespunkt der skal løses, er det, når en ADC er absolut påkrævet.

Den følgende artikel beskriver en metode til at skabe høj tilgængelighed og skalerbarhed for en navigationsproxytjeneste. Hvis en af ​​proxyserverne fejler, vil load balancer, implementeret med Relianoid Application Delivery Controller, registrere fejlen, og proxyen vil blive deaktiveret for den tilgængelige pulje. Derudover vil klienten blive omdirigeret til en anden tilgængelig navigationsproxy uden at påvirke trafikforbindelserne.

Proxy-netværksarkitektur #

Med ideen om at give læseren bedre forståelse af konfigurationen, ønsker vi at nå frem til følgende diagram, der beskriver arkitekturen.

Forskellige klienter (bærbare computere, mobiltelefoner og tablets) konfigurerer navigationsbrowseren, så den peger på den virksomhedsproxy, f.eks. https://proxy.company.com:3128Alle forbindelser fra klienterne til webnavigationsproxyen er almindelige HTTP or SSL vil være TCP baseret, så dette vil blive brugt til at bygge vores load balancing farm.

IP-opløsningen for proxy.company.com er en Virtual IP allerede konfigureret i load balancer. I Relianoid Application Delivery Controller er der en farm over en sådan virtuel IP, f.eks. 192.168.103.34 og virtuel port 3128 in NAT tilstand til TCP protokol.

Farmen er konfigureret med alle de backends, der bygger navigationsproxypuljen, i vores eksempel 192.168.103.253 og 192.168.103.254 via TCP-porten 3128Så snart klienten forsøger at oprette forbindelse til den konfigurerede proxy, modtager ADC'en forbindelsen, og den omdirigeres til en af ​​de tilgængelige navigationsproxyer i puljen, der deler brugerne mellem alle tilgængelige backend-proxyservere.

Konfiguration af webnavigationsproxy med høj tilgængelighed #

Det følgende afsnit beskriver konfigurationsproceduren for at oprette en korrekt konfiguration af load balance-navigationsproxyer i Relianoid load balancer.

Webnavigationsproxy-tilstandstjek #

Først skal du oprette et sundhedstjek, der skal bruges i den load balancing farm, som vi skal oprette i de følgende linjer. Målet med dette nye sundhedstjek er at verificere, at TCP-porten i backend-proxyerne er aktiveret.

Gå til sektion OVERVÅGNING > Landmand, opret en ny farmguardian med navnet check_tcp_navigation_proxy og kopier fra check_tcp og foretag nogle små ændringer i timeouts som vist nedenfor:

I Kommando feltet tilføj flaget -t 5, dette er timeout'en pr. backend for at kunne reagere på TCP-forbindelsen fra load balancer. Interval Feltet er konfigureret til en værdi på 11, 5 sekunder pr. backend + 1 ekstra sekund for at undgå rekursion. Vi anbefaler at bruge følgende formel til at indstille den optimale Interval værdi.

(antal backends * timeout sekunder pr. backend (-t)) + 1

Virtuel webnavigationsproxytjeneste #

Opret derefter en LSLB > L4xNAT gård, f.eks. med navnet navigation_proxy, Herunder Virtual IP og Virtuel port som vist i det foregående diagram. Når det er oprettet, skal du gå til redigering i Avanceret tilstand og sørg for, at Protokol Type er konfigureret i TCP og NAT Type er konfigureret i NAT mode.

For at konfigurere den virtuelle tjenestes funktionsmåde skal du gå til fanen Det vi er gode til og konfigurer load balancing-algoritmen i Vægt (som standard). Tilpas venligst denne værdi til den mest passende værdi for dit miljø og den ønskede adfærd.

Gå derefter til tabellen i samme afsnit underliggende programmer og tilføj de rigtige webnavigationsproxyservere, der administrerer brugerens forbindelser.

Til sidst skal du vælge det sundhedstjek, der allerede er oprettet i det forrige trin, med navnet check_tcp_navigation_proxy for at verificere, at TCP Backend-porten er allerede åben.

Nu kan den belastningsafbalancerede virtuelle tjeneste testes, før klienterne konfigureres.

Klientkonfiguration #

Det sidste trin er at konfigurere proxyindstillingerne i klientens webbrowser, så de peger på Virtual IP og Virtuel port bruges i load balancer, eller introducer Virtual IP i kooperativet DNS og brug en Navn i stedet hos klienterne, i vores eksempel proxy.example.com peger på den virtuelle IP-adresse 192.168.103.34).

Endelig kan du nyde din belastningsbalancerede webnavigationsproxy med høj tilgængelighed!