Intro

A proxyserver kan beskrives som et serverapparat eller en applikation, der formidler formidling af anmodninger fra kunder eller klienter, der forsøger at søge ressourcer fra flere servere, der leverer dem. Når det er forklaret, betyder det, at en proxyserver fungerer på vegne af kunden eller klienten, når tjenesten bliver anmodet om, og muligvis skjuler den reelle oprindelse eller kilde til anmodningen til serveren.

Processen er, 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 webs, og derefter evaluerer proxyserveren denne anmodning og udvikler det relevante og nødvendige netværk transaktioner. Dette er en måde at gøre forenkling eller mere kontrolleret anmodningens kompleksitet, og desuden giver den andre fordele såsom sikkerhed, indholdsacceleration eller privatliv. Fuldmagter er udtænkt 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 styre antallet af samtidige brugere, eller selve proxyen er en enkelt mislykkelsespunkt der skal løses, så er det, når en ADC er fuldstændig påkrævet.

Den følgende artikel beskriver en måde at skabe høj tilgængelighed og skalerbarhed på for en navigationsproxytjeneste, hvis en af ​​proxyserverne mislykkes, vil belastningsbalanceren, implementeret med ZEVENET Application Delivery Controller, opdage fejlen og proxyen deaktiveres af tilgængelig pool, derudover omdirigeres klienten til en anden tilgængelig navigationsproxy uden at påvirke trafikforbindelserne.

Proxy-netværksarkitektur

Med ideen om at få læseren til at forstå konfigurationen bedre, vil vi nå det følgende diagram, der beskriver arkitekturen.

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

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

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

Konfiguration af webnavigationsproxy med høj tilgængelighed

I det følgende afsnit beskrives konfigurationsproceduren for at oprette en korrekt konfiguration for belastningsbalance Navigation proxies i ZEVENET load balancer.

Webnavigation proxy sundhedstjek

For det første skal du oprette en sundhedskontrol for brug i den belastningsafbalancerende gård, som vi skal oprette i de følgende linjer. Målet med denne nye sundhedstjek er at verificere, at TCP-porten i backend-proxies er aktiveret.

Gå til sektion OVERVÅGNING> Gårdens værge, opret en ny bondevagt med navn check_tcp_navigation_proxy og kopiere fra check_tcp og foretag nogle små ændringer i timeouts som vist nedenfor:

I boksen Kommando felt tilføj flag -t 5, dette er timeout pr. backend for at svare på TCP-forbindelsen fra load balancer. Det Interval felt 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 for at indstille det optimale Interval værdi.

(number of backends * timeout seconds per backend (-t) ) + 1

Webnavigation proxy virtuel service

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

Gå til fanen for at konfigurere den virtuelle serviceadfærd Services og konfigurer algoritmen til belastningsbalancering i Vægt (som standard). Tilpas denne værdi til det mest passende for dit miljø og ønsket opførsel.

Gå derefter til bordet i samme afsnit underliggende programmer og tilføj de rigtige webnavigations-proxyservere, der styrer brugerens forbindelser.

Endelig skal du vælge den sundhedstjek, der allerede er oprettet i det forrige trin, der hedder check_tcp_navigation_proxy for at kontrollere, at TCP backend-porten er allerede åbnet.

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

Klients konfiguration

Sidste trin er at konfigurere proxyindstillingerne i klientens webbrowser, der peger på Virtual IP Virtual Port bruges i load balancer, eller introducer Virtual IP i andelsselskabet DNS og brug en Navn i stedet for klienterne, i vores eksempel proxy.example.com peges på den virtuelle IP 192.168.103.34).

Endelig nyd din belastningsafbalancerede webnavigationsproxy med høj tilgængelighed!