A última vez falamos das capacidades de NSX Edge en termos de enrutamento estático e dinámico, e hoxe trataremos o equilibrador de carga.
Antes de comezar a configurar, gustaríame lembrarche brevemente os principais tipos de equilibrio.
Teoría
Todas as solucións actuais de equilibrio de carga útil divídense a maioría das veces en dúas categorías: equilibrio no cuarto (transporte) e sétimo (aplicación) do modelo. . O modelo OSI non é o mellor punto de referencia á hora de describir métodos de equilibrio. Por exemplo, se un equilibrador L4 tamén admite a terminación TLS, convértese entón nun equilibrador L7? Pero é o que é.
- Equilibrador L4 a maioría das veces é un proxy intermedio entre o cliente e un conxunto de backends dispoñibles, que finaliza as conexións TCP (é dicir, responde independentemente a SYN), selecciona un backend e inicia unha nova sesión TCP na súa dirección, enviando SYN de forma independente. Este tipo é un dos básicos, outras opcións son posibles.
- Equilibrador L7 distribúe o tráfico entre os backend dispoñibles "máis sofisticados" que o equilibrador L4. Pode decidir que backend escoller en función, por exemplo, do contido da mensaxe HTTP (URL, cookie, etc.).
Independentemente do tipo, o equilibrador pode soportar as seguintes funcións:
- O descubrimento de servizos é o proceso de determinación do conxunto de backends dispoñibles (estático, DNS, Consul, Etcd, etc.).
- Comprobación da funcionalidade dos backends detectados (“ping” activo do backend mediante unha solicitude HTTP, detección pasiva de problemas nas conexións TCP, presenza de varios códigos HTTP 503 nas respostas, etc.).
- O propio equilibrio (round robin, selección aleatoria, hash IP de orixe, URI).
- Terminación de TLS e verificación do certificado.
- Opcións relacionadas coa seguridade (autenticación, prevención de ataques DoS, limitación de velocidade) e moito máis.
NSX Edge ofrece soporte para dous modos de implementación do equilibrador de carga:
Modo proxy ou un brazo. Neste modo, NSX Edge usa o seu enderezo IP como enderezo de orixe ao enviar unha solicitude a un dos backends. Así, o equilibrador realiza simultaneamente as funcións de NAT de orixe e de destino. O backend ve todo o tráfico enviado desde o equilibrador e responde directamente a el. Neste esquema, o equilibrador debe estar no mesmo segmento de rede cos servidores internos.
Así é como vai:
1. O usuario envía unha solicitude ao enderezo VIP (enderezo equilibrador) que está configurado no Edge.
2. Edge selecciona un dos backends e realiza o NAT de destino, substituíndo o enderezo VIP polo enderezo do backend seleccionado.
3. Edge realiza a NAT de orixe, substituíndo o enderezo do usuario que enviou a solicitude polo seu propio.
4. O paquete envíase ao backend seleccionado.
5. O backend non responde directamente ao usuario, senón ao Edge, xa que o enderezo orixinal do usuario cambiou ao enderezo do equilibrador.
6. Edge transmite a resposta do servidor ao usuario.
O diagrama está a continuación.
Modo transparente ou en liña. Neste escenario, o equilibrador ten interfaces nas redes internas e externas. Ao mesmo tempo, non hai acceso directo á rede interna desde a externa. O equilibrador de carga integrado actúa como unha pasarela NAT para as máquinas virtuais da rede interna.
O mecanismo é o seguinte:
1. O usuario envía unha solicitude ao enderezo VIP (enderezo equilibrador) que está configurado no Edge.
2. Edge selecciona un dos backends e realiza o NAT de destino, substituíndo o enderezo VIP polo enderezo do backend seleccionado.
3. O paquete envíase ao backend seleccionado.
4. O backend recibe unha solicitude co enderezo orixinal do usuario (non se realizou a NAT fonte) e responde directamente a ela.
5. O tráfico volve ser aceptado polo equilibrador de carga, xa que nun esquema en liña adoita actuar como pasarela predeterminada para a granxa de servidores.
6. Edge realiza a NAT de orixe para enviar tráfico ao usuario, utilizando o seu VIP como enderezo IP de orixe.
O diagrama está a continuación.
Práctica
O meu banco de probas ten 3 servidores que executan Apache, que está configurado para funcionar a través de HTTPS. Edge realizará un balance round robin das solicitudes HTTPS, enviando cada nova solicitude a un novo servidor.
Comecemos.
Xerando un certificado SSL que será usado por NSX Edge
Pode importar un certificado de CA válido ou usar un autoasinado. Para esta proba usarei auto-asinado.
- Na interface de vCloud Director, vai á configuración dos servizos Edge.
- Vaia á pestana Certificados. Na lista de accións, seleccione engadir un novo CSR.
- Encha os campos obrigatorios e fai clic en Manter.
- Seleccione o CSR recén creado e seleccione a opción de autoasinar CSR.
- Seleccione o período de validez do certificado e prema en Manter
- O certificado autoasinado aparece na lista dos dispoñibles.
Configurando o perfil da aplicación
Os perfís das aplicacións ofrécenche un control máis completo sobre o tráfico da rede e fan que a súa xestión sexa sinxela e efectiva. Pódense usar para definir o comportamento para tipos específicos de tráfico.
- Vaia á pestana Load Balancer e active o equilibrador. A opción Aceleración activada aquí permite que o equilibrador use un equilibrio L4 máis rápido en lugar de L7.
- Vaia á pestana Perfil da aplicación para configurar o perfil da aplicación. Fai clic en +.
- Establece o nome do perfil e selecciona o tipo de tráfico para o que se aplicará o perfil. Déixame explicar algúns parámetros.
Persistencia – almacena e rastrexa os datos da sesión, por exemplo: que servidor específico do grupo está atendendo a solicitude do usuario. Isto garante que as solicitudes dos usuarios se encamiñan ao mesmo membro do grupo durante toda a vida da sesión ou as sesións posteriores.
Activar o paso SSL – Cando se selecciona esta opción, NSX Edge deixa de finalizar SSL. Pola contra, a terminación ocorre directamente nos servidores que se están equilibrando.
Insira a cabeceira HTTP X-Forwarded-For – permítelle determinar o enderezo IP de orixe do cliente que se conecta ao servidor web a través do equilibrador de carga.
Activar SSL do lado da piscina – permítelle especificar que o grupo seleccionado está formado por servidores HTTPS.
- Dado que vou equilibrar o tráfico HTTPS, teño que activar o SSL do lado da piscina e seleccionar o certificado xerado anteriormente na pestana Certificados do servidor virtual -> Certificado de servizo.
- Do mesmo xeito para Certificados de grupo -> Certificado de servizo.
Creamos un grupo de servidores, cuxo tráfico será equilibrado Pools
- Vaia á pestana Piscinas. Fai clic en +.
- Establecemos o nome do pool, seleccionamos o algoritmo (utilizarei round robin) e o tipo de vixilancia para o backend da comprobación de saúde.A opción Transparente indica se as IP de orixe iniciais dos clientes son visibles para os servidores internos.
- Se a opción está desactivada, o tráfico dos servidores internos procede da IP de orixe do equilibrador.
- Se a opción está activada, os servidores internos verán a IP de orixe dos clientes. Nesta configuración, NSX Edge debe actuar como pasarela predeterminada para garantir que os paquetes devoltos pasen por NSX Edge.
NSX admite os seguintes algoritmos de equilibrio:
- IP_HASH – selección do servidor baseada nos resultados dunha función hash para a IP de orixe e destino de cada paquete.
- LASTCONN – equilibrado de conexións entrantes, dependendo do número xa dispoñible nun servidor en particular. As novas conexións dirixiranse ao servidor con menos conexións.
- ROUND_ROBIN – envíanse novas conexións a cada servidor por turnos, de acordo co peso que se lle atribúa.
- URI – a parte esquerda do URI (antes do signo de interrogación) divídese polo hash e divídese polo peso total dos servidores do grupo. O resultado indica que servidor recibe a solicitude, garantindo que a solicitude se encamiña sempre ao mesmo servidor, sempre que todos os servidores sigan dispoñibles.
- HTTPHEADER – equilibrio baseado nunha cabeceira HTTP específica, que se pode especificar como parámetro. Se falta a cabeceira ou non ten ningún valor, aplícase o algoritmo ROUND_ROBIN.
- URL – Cada solicitude HTTP GET busca o parámetro URL especificado como argumento. Se o parámetro vai seguido dun signo de igual e dun valor, entón o valor divídese polo hash e divídese polo peso total dos servidores en execución. O resultado indica que servidor recibe a solicitude. Este proceso úsase para facer un seguimento dos ID de usuario nas solicitudes e garantir que o mesmo ID de usuario se envíe sempre ao mesmo servidor, sempre que todos os servidores sigan dispoñibles.
- No bloque Membros, fai clic en + para engadir servidores ao grupo.
Aquí cómpre indicar:- nome do servidor;
- enderezo IP do servidor;
- o porto no que o servidor recibirá tráfico;
- porto para a comprobación de saúde (Monitor healthcheck);
- peso: usando este parámetro pode axustar a cantidade proporcional de tráfico recibido para un membro específico do grupo;
- Max Connections: número máximo de conexións ao servidor;
- Conexións mínimas: o número mínimo de conexións que debe procesar o servidor antes de que o tráfico se reenvíe ao seguinte membro do grupo.
Así é o conxunto final de tres servidores.
Engadindo servidor virtual
- Vaia á pestana Servidores virtuais. Fai clic en +.
- Activamos o servidor virtual mediante Habilitar servidor virtual.
Dámoslle un nome, seleccionamos o Perfil de Aplicación creado previamente, Pool e indicamos o enderezo IP ao que o Servidor Virtual recibirá solicitudes de fóra. Especificamos o protocolo HTTPS e o porto 443.
Parámetros opcionais aquí:
Límite de conexión – o número máximo de conexións simultáneas que pode procesar o servidor virtual;
Límite de taxa de conexión (CPS) – o número máximo de novas solicitudes entrantes por segundo.
Isto completa a configuración do equilibrador; pode comprobar a súa funcionalidade. Os servidores teñen unha configuración sinxela que permite comprender que servidor do grupo procesou a solicitude. Durante a configuración, escollemos o algoritmo de equilibrio Round Robin e o parámetro Peso para cada servidor é igual a un, polo que cada solicitude posterior será procesada polo servidor seguinte do grupo.
Introducimos o enderezo externo do equilibrador no navegador e vemos:
Despois de actualizar a páxina, a solicitude será procesada polo seguinte servidor:
E de novo, para comprobar o terceiro servidor do grupo:
Ao comprobar, podes ver que o certificado que nos envía Edge é o mesmo que xeramos ao principio.
Comprobando o estado do equilibrador desde a consola da pasarela Edge. Para iso, introduza mostrar o grupo de balance de carga do servizo.
Configurando Service Monitor para comprobar o estado dos servidores do grupo
Usando Service Monitor podemos supervisar o estado dos servidores do grupo de backend. Se a resposta a unha solicitude non é a esperada, pódese sacar o servidor do grupo para que non reciba novas solicitudes.
Por defecto, están configurados tres métodos de verificación:
- monitor TCP,
- monitor HTTP,
- Monitor HTTPS.
Imos crear un novo.
- Vaia á pestana Supervisión do servizo, fai clic en +.
- Escolla:
- nome para o novo método;
- o intervalo no que se enviarán as solicitudes,
- tempo de espera esperando unha resposta,
- tipo de seguimento: solicitude HTTPS mediante o método GET, código de estado esperado: 200 (OK) e URL da solicitude.
- Deste xeito complétase a configuración do novo Service Monitor; agora podemos utilizalo ao crear un pool.
Establecemento de regras de aplicación
As regras de aplicación son unha forma de manipular o tráfico en función de determinados disparadores. Con esta ferramenta podemos crear regras de balance de carga avanzadas que poden non ser posibles a través dos perfís de aplicacións ou doutros servizos dispoñibles no Edge Gateway.
- Para crear unha regra, vai á pestana Regras de aplicación do equilibrador.
- Selecciona un nome, un script que utilizará a regra e fai clic en Manter.
- Despois de creada a regra, necesitamos editar o Servidor Virtual xa configurado.
- Na pestana Avanzado, engade a regra que creamos.
No exemplo anterior activamos o soporte tlsv1.
Un par de exemplos máis:
Redirixe o tráfico a outro grupo.
Con este script podemos redirixir o tráfico a outro grupo de equilibrio se o grupo principal está caído. Para que a regra funcione, hai que configurar varias agrupacións no equilibrador e todos os membros da agrupación principal deben estar en estado inactivo. Debes especificar o nome da piscina, non o seu ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Redirixe o tráfico a un recurso externo.
Aquí rediriximos o tráfico ao sitio web externo se todos os membros do grupo principal están caídos.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Aínda máis exemplos .
Iso é todo para min sobre o equilibrador. Se tes algunha dúbida, pregunta, estou preparado para responder.
Fonte: www.habr.com