La darrera vegada vam parlar de les capacitats de NSX Edge en termes d'encaminament estàtic i dinàmic, i avui tractarem l'equilibrador de càrrega.
Abans de començar a configurar, m'agradaria recordar-vos breument els principals tipus d'equilibri.
Теория
Totes les solucions d'equilibri de càrrega útil actuals es divideixen més sovint en dues categories: equilibri al quart (transport) i setè (aplicació) nivells del model. . El model OSI no és el millor punt de referència a l'hora de descriure mètodes d'equilibri. Per exemple, si un equilibrador L4 també admet la terminació TLS, es converteix llavors en un equilibrador L7? Però és el que és.
- Equilibrador L4 la majoria de les vegades és un servidor intermediari que es troba entre el client i un conjunt de backends disponibles, que finalitza les connexions TCP (és a dir, respon de manera independent a SYN), selecciona un backend i inicia una nova sessió TCP en la seva direcció, enviant SYN de manera independent. Aquest tipus és un dels bàsics, hi ha altres opcions possibles.
- Equilibrador L7 distribueix el trànsit entre els backends disponibles "més sofisticats" que l'equilibrador L4. Pot decidir quin backend triar en funció, per exemple, del contingut del missatge HTTP (URL, galeta, etc.).
Independentment del tipus, l'equilibrador pot suportar les funcions següents:
- El descobriment de serveis és el procés de determinar el conjunt de backends disponibles (estàtica, DNS, cònsol, etc.).
- Comprovació de la funcionalitat dels backends detectats (“ping” actiu del backend mitjançant una sol·licitud HTTP, detecció passiva de problemes en connexions TCP, presència de diversos codis HTTP 503 a les respostes, etc.).
- El propi equilibri (round robin, selecció aleatòria, hash IP d'origen, URI).
- Terminació TLS i verificació del certificat.
- Opcions relacionades amb la seguretat (autenticació, prevenció d'atacs DoS, limitació de velocitat) i molt més.
NSX Edge ofereix suport per a dos modes de desplegament de l'equilibri de càrrega:
Mode proxy o d'un sol braç. En aquest mode, NSX Edge utilitza la seva adreça IP com a adreça d'origen quan envia una sol·licitud a un dels backends. Així, l'equilibrador realitza simultàniament les funcions de NAT d'origen i de destinació. El backend veu tot el trànsit enviat des de l'equilibrador i hi respon directament. En aquest esquema, l'equilibrador ha d'estar al mateix segment de xarxa que els servidors interns.
Així és com va:
1. L'usuari envia una sol·licitud a l'adreça VIP (adreça de l'equilibrador) que està configurada a Edge.
2. Edge selecciona un dels backends i realitza el NAT de destinació, substituint l'adreça VIP per l'adreça del backend seleccionat.
3. Edge realitza la NAT font, substituint l'adreça de l'usuari que ha enviat la sol·licitud per la seva.
4. El paquet s'envia al backend seleccionat.
5. El backend no respon directament a l'usuari, sinó a l'Edge, ja que l'adreça original de l'usuari s'ha canviat a l'adreça de l'equilibrador.
6. Edge transmet la resposta del servidor a l'usuari.
El diagrama és a continuació.
Mode transparent o en línia. En aquest escenari, l'equilibrador té interfícies a les xarxes internes i externes. Al mateix temps, no hi ha accés directe a la xarxa interna des de l'externa. L'equilibrador de càrrega integrat actua com a passarel·la NAT per a les màquines virtuals de la xarxa interna.
El mecanisme és el següent:
1. L'usuari envia una sol·licitud a l'adreça VIP (adreça de l'equilibrador) que està configurada a Edge.
2. Edge selecciona un dels backends i realitza el NAT de destinació, substituint l'adreça VIP per l'adreça del backend seleccionat.
3. El paquet s'envia al backend seleccionat.
4. El backend rep una sol·licitud amb l'adreça original de l'usuari (no s'ha realitzat el NAT d'origen) i hi respon directament.
5. El trànsit torna a ser acceptat per l'equilibrador de càrrega, ja que en un esquema en línia sol actuar com a passarel·la per defecte per a la granja de servidors.
6. Edge realitza la NAT d'origen per enviar trànsit a l'usuari, utilitzant el seu VIP com a adreça IP d'origen.
El diagrama és a continuació.
Pràctica
El meu banc de proves té 3 servidors amb Apache, que està configurat per funcionar amb HTTPS. Edge realitzarà l'equilibri de les sol·licituds HTTPS, enviant cada nova sol·licitud a un nou servidor.
Comencem
Generació d'un certificat SSL que utilitzarà NSX Edge
Podeu importar un certificat CA vàlid o utilitzar-ne un de signat per vosaltres mateixos. Per a aquesta prova faré servir la signatura pròpia.
- A la interfície de vCloud Director, aneu a la configuració dels serveis Edge.
- Aneu a la pestanya Certificats. A la llista d'accions, seleccioneu afegir un nou CSR.
- Ompliu els camps obligatoris i feu clic a Mantenir.
- Seleccioneu el CSR acabat de crear i seleccioneu l'opció CSR d'autofirma.
- Seleccioneu el període de validesa del certificat i feu clic a Mantenir
- El certificat autofirmat apareix a la llista de disponibles.
Configuració del perfil d'aplicació
Els perfils d'aplicació us ofereixen un control més complet sobre el trànsit de la xarxa i fan que la seva gestió sigui senzilla i eficaç. Es poden utilitzar per definir el comportament de tipus específics de trànsit.
- Aneu a la pestanya Load Balancer i activeu l'equilibrador. L'opció d'acceleració activada aquí permet que l'equilibrador utilitzi un equilibri L4 més ràpid en lloc de l'L7.
- Aneu a la pestanya Perfil de l'aplicació per definir el perfil de l'aplicació. Feu clic a +.
- Establiu el nom del perfil i seleccioneu el tipus de trànsit al qual s'aplicarà el perfil. Permeteu-me explicar alguns paràmetres.
Persistència – emmagatzema i fa un seguiment de les dades de la sessió, per exemple: quin servidor específic del grup està atenent la sol·licitud de l'usuari. Això garanteix que les sol·licituds dels usuaris s'enviïn al mateix membre del grup durant tota la vida de la sessió o les sessions posteriors.
Activa el pas de SSL – Quan se selecciona aquesta opció, NSX Edge deixa de finalitzar SSL. En canvi, la terminació es produeix directament als servidors que s'estan equilibrant.
Insereix la capçalera HTTP X-Forwarded-For – us permet determinar l'adreça IP d'origen del client que es connecta al servidor web mitjançant l'equilibrador de càrrega.
Activa SSL del costat de la piscina – us permet especificar que el grup seleccionat consta de servidors HTTPS.
- Com que equilibraré el trànsit HTTPS, he d'habilitar SSL del costat del grup i seleccionar el certificat generat anteriorment a la pestanya Certificats de servidor virtual -> Certificat de servei.
- De la mateixa manera per als certificats de grup -> Certificat de servei.
Creem un conjunt de servidors, el trànsit al qual serà equilibrat Pools
- Aneu a la pestanya Piscines. Feu clic a +.
- Establim el nom del pool, seleccionem l'algoritme (utilitzaré round robin) i el tipus de monitorització per al backend de la comprovació de salut.L'opció Transparent indica si les IP d'origen inicial dels clients són visibles per als servidors interns.
- Si l'opció està desactivada, el trànsit dels servidors interns prové de la IP d'origen de l'equilibrador.
- Si l'opció està activada, els servidors interns veuen la IP d'origen dels clients. En aquesta configuració, NSX Edge ha d'actuar com a passarel·la predeterminada per garantir que els paquets retornats passen per NSX Edge.
NSX admet els algorismes d'equilibri següents:
- IP_HASH – selecció de servidor basada en els resultats d'una funció hash per a la IP d'origen i destinació de cada paquet.
- LASTCONN – equilibri de connexions entrants, en funció del nombre ja disponible en un servidor concret. Les connexions noves es dirigiran al servidor amb menys connexions.
- ROUND_ROBIN – s'envien noves connexions a cada servidor per torn, d'acord amb el pes que se li assigni.
- URI – la part esquerra de l'URI (abans del signe d'interrogació) es divideix pel pes total dels servidors del grup. El resultat indica quin servidor rep la sol·licitud, assegurant que la sol·licitud s'encamina sempre al mateix servidor, sempre que tots els servidors estiguin disponibles.
- HTTPHEADER – equilibri basat en una capçalera HTTP específica, que es pot especificar com a paràmetre. Si falta la capçalera o no té cap valor, s'aplica l'algorisme ROUND_ROBIN.
- URL – Cada sol·licitud HTTP GET cerca el paràmetre URL especificat com a argument. Si el paràmetre va seguit d'un signe d'igualtat i d'un valor, el valor s'esborra i es divideix pel pes total dels servidors en execució. El resultat indica quin servidor rep la sol·licitud. Aquest procés s'utilitza per fer un seguiment dels identificadors d'usuari a les sol·licituds i garantir que el mateix identificador d'usuari s'enviï sempre al mateix servidor, sempre que tots els servidors estiguin disponibles.
- Al bloc Membres, feu clic a + per afegir servidors al grup.
Aquí cal indicar:- nom del servidor;
- Adreça IP del servidor;
- el port on el servidor rebrà trànsit;
- port per a la comprovació de l'estat (Monitoritzar la comprovació de l'estat);
- pes: amb aquest paràmetre podeu ajustar la quantitat proporcional de trànsit rebut per a un membre específic del grup;
- Connexions màximes: nombre màxim de connexions al servidor;
- Connexions mínimes: el nombre mínim de connexions que el servidor ha de processar abans que el trànsit es reenviï al següent membre del grup.
Així és el conjunt final de tres servidors.
Afegir servidor virtual
- Aneu a la pestanya Servidors virtuals. Feu clic a +.
- Activem el servidor virtual mitjançant Habilita el servidor virtual.
Li donem un nom, seleccionem el Perfil d'Aplicació creat prèviament, Pool i indiquem l'adreça IP a la qual el Servidor Virtual rebrà les peticions de fora. Especifiquem el protocol HTTPS i el port 443.
Paràmetres opcionals aquí:
Límit de connexió – el nombre màxim de connexions simultànies que el servidor virtual pot processar;
Límit de velocitat de connexió (CPS) – el nombre màxim de noves sol·licituds entrants per segon.
Això completa la configuració de l'equilibrador; podeu comprovar la seva funcionalitat. Els servidors tenen una configuració senzilla que permet entendre quin servidor del grup ha processat la sol·licitud. Durant la configuració, vam triar l'algoritme d'equilibri Round Robin i el paràmetre Weight per a cada servidor és igual a un, de manera que cada sol·licitud posterior serà processada pel servidor següent del grup.
Introduïm l'adreça externa de l'equilibrador al navegador i veiem:
Després d'actualitzar la pàgina, la sol·licitud serà processada pel servidor següent:
I de nou, per comprovar el tercer servidor de la piscina:
Quan comproveu, podeu veure que el certificat que ens envia Edge és el mateix que vam generar al principi.
Comprovació de l'estat de l'equilibrador des de la consola de la passarel·la Edge. Per fer-ho, introduïu mostra el grup d'equilibrador de càrrega del servei.
Configuració del Monitor de servei per comprovar l'estat dels servidors del grup
Amb Service Monitor podem controlar l'estat dels servidors del grup de fons. Si la resposta a una sol·licitud no és l'esperada, el servidor es pot treure del grup perquè no rebi cap sol·licitud nova.
Per defecte, es configuren tres mètodes de verificació:
- monitor TCP,
- monitor HTTP,
- Monitor HTTPS.
Creem-ne un de nou.
- Aneu a la pestanya Supervisió del servei, feu clic a +.
- Trieu:
- nom per al nou mètode;
- l'interval en què s'enviaran les sol·licituds,
- temps d'espera esperant una resposta,
- tipus de monitorització: sol·licitud HTTPS mitjançant el mètode GET, codi d'estat esperat: 200 (OK) i URL de sol·licitud.
- D'aquesta manera es completa la configuració del nou Monitor de servei; ara el podem utilitzar per crear un grup.
Configuració de normes d'aplicació
Les regles d'aplicació són una manera de manipular el trànsit en funció de determinats activadors. Amb aquesta eina podem crear regles avançades d'equilibri de càrrega que potser no siguin possibles mitjançant perfils d'aplicació o altres serveis disponibles a Edge Gateway.
- Per crear una regla, aneu a la pestanya Regles d'aplicació de l'equilibrador.
- Seleccioneu un nom, un script que utilitzarà la regla i feu clic a Mantenir.
- Un cop creada la regla, hem d'editar el servidor virtual ja configurat.
- A la pestanya Avançat, afegiu la regla que hem creat.
A l'exemple anterior hem habilitat el suport tlsv1.
Un parell d'exemples més:
Redirigeix el trànsit a un altre grup.
Amb aquest script podem redirigir el trànsit a un altre grup d'equilibri si el grup principal està caigut. Perquè la regla funcioni, s'han de configurar diverses agrupacions a l'equilibrador i tots els membres de l'agrupació principal han d'estar en estat de baixa. Heu d'especificar el nom de la piscina, no el seu identificador.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Redirigeix el trànsit a un recurs extern.
Aquí redirigim el trànsit al lloc web extern si tots els membres del grup principal estan caient.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Encara més exemples .
Això és tot per a mi sobre l'equilibrador. Si tens alguna pregunta, pregunta, estic preparat per respondre.
Font: www.habr.com