Ola a todos! O curso comeza hoxe , en relación co cal realizamos un webinar temático correspondente dedicado á revisión ELB. Analizamos os tipos de equilibradores e creamos varias instancias EC2 cun equilibrador. Tamén estudamos outros exemplos de uso.
, Vai:
- comprender o que é AWS Load Balancing;
- coñecer os tipos de Elastic Load Balancer e os seus compoñentes;
- use AWS ELB na súa práctica.
Por que necesitas saber isto?
- útil se está a planear realizar exames de certificación de AWS;
- esta é unha forma sinxela de distribuír a carga entre servidores;
- Esta é unha forma sinxela de engadir Lambda ao teu servizo (ALB).
Realizou unha lección aberta , enxeñeiro de sistemas nunha empresa de mercadotecnia para o desenvolvemento e soporte de sitios web.
Introdución
O que é un Elastic Load Balancer pódese ver no seguinte diagrama, que mostra un exemplo sinxelo:
Load Balancer acepta solicitudes e distribúeas entre instancias. Temos unha instancia separada, hai funcións Lambda e hai un grupo AutoScaling (un grupo de servidores).
Tipos AWS ELB
1. Vexamos os principais tipos:
Balanceador de carga clásico. O primeiro equilibrador de AWS, funciona en ambas as capas OSI 4 e 7, admite HTTP, HTTPS, TCP e SSL. Ofrece equilibrio de carga básico en varias instancias de Amazon EC2 e funciona tanto a nivel de solicitude como de conexión. Abrimos (resaltado en gris):
Este equilibrador considérase obsoleto, polo que só se recomenda o seu uso en determinados casos. Por exemplo, para aplicacións que se crearon na rede EC2-Classic. En principio, ninguén nos impide crealo:
2. Balanceador de carga de rede. Adecuado para cargas de traballo pesadas, opera na capa OSI 4 (pódese usar en EKS e ECS), admite TCP, UDP e TLS.
Network Load Balancer encamiña o tráfico a obxectivos nun Amazon VPC e é capaz de procesar millóns de solicitudes por segundo cunha latencia ultra baixa. Ademais, está optimizado para manexar patróns de tráfico con cargas repentinas e cambiantes.
3. Balanceador de carga da aplicación. Funciona na capa 7, ten compatibilidade con Lambda, admite regras de nivel de cabeceira e ruta, admite HTTP e HTTPS.
Ofrece enrutamento de solicitudes avanzado centrado na entrega de aplicacións construídas en arquitecturas modernas, incluídos microservizos e contedores. Dirixe o tráfico aos obxectivos en Amazon VPC en función do contido da solicitude.
Para moitos usuarios, Application Load Balancer foi a primeira opción para substituír Classic Load Balancer, porque TCP non é tan común como HTTP.
Creémolo tamén, polo que xa teremos dous equilibradores de carga:
Compoñentes de balance de carga
Compoñentes comúns de balance de carga (común a todos os equilibradores):
- Política de rexistro de acceso
— os teus rexistros de acceso ELB. Para facer a configuración, pode ir a Descrición e seleccionar o botón "Editar atributos":
Despois especificamos S3Bucket - Almacenamento de obxectos de Amazon:
- Esquema
- equilibrador interno ou externo. A cuestión é se o teu LoadBalancer debe recibir enderezos externos para poder acceder desde fóra, ou pode ser o teu equilibrador de carga interno;
- Grupos de seguridade
- control de acceso ao equilibrador. Esencialmente, este é un firewall de alto nivel.
- Subredes
— subredes dentro da túa VPC (e, en consecuencia, zona de dispoñibilidade). As subredes especifícanse durante a creación. Se as VPC están limitadas por rexión, entón as subredes están limitadas polas zonas de dispoñibilidade. Ao crear un Load Balancer, é mellor crealo en polo menos dúas subredes (axuda se xorden problemas cunha zona de dispoñibilidade);
- Escoitadores
- os seus protocolos de balance. Como se mencionou anteriormente, para Classic Load Balancer pode ser HTTP, HTTPS, TCP e SSL, para Network Load Balancer - TCP, UDP e TLS, para Application Load Balancer - HTTP e HTTPS.
Exemplo de Classic Load Balancer:
Pero no equilibrador de carga de aplicacións vemos unha interface lixeiramente diferente e unha lóxica xeralmente diferente:
Compoñentes de Load Balancer v2 (ALB e NLB)
Agora vexamos máis de cerca os equilibradores da versión 2 Application Load Balancer e Network Load Balancer. Estes equilibradores teñen as súas propias características de compoñentes. Por exemplo, apareceu un concepto como Target Groups: instancias (e funcións). Grazas a este compoñente, temos a oportunidade de especificar a cal dos Grupos Obxectivos queremos dirixir o tráfico.
En termos sinxelos, en Grupos obxectivo especificamos as instancias onde chegará o tráfico. Se no mesmo equilibrador de carga clásico simplemente conectas inmediatamente a intensidade ao equilibrador, entón no equilibrador de carga da aplicación primeiro:
- crear un equilibrador de carga;
- crear un grupo obxectivo;
- dirixir a través dos portos necesarios ou das regras de Load Balancer aos grupos obxectivo necesarios;
- en Grupos obxectivo asigna instancias.
Esta lóxica de funcionamento pode parecer máis complicada, pero en realidade é máis conveniente.
O seguinte compoñente é Regras do oínte (normas de enrutamento). Isto só se aplica ao equilibrador de carga de aplicacións. Se en Network Load Balancer simplemente creas un listener e envía tráfico a un grupo de destino específico, en Application Load Balancer todo .
Agora digamos algunhas palabras sobre o seguinte compoñente: IP elástica (enderezos estáticos para NLB). Se as regras de enrutamento das regras de escoita afectaban só ao equilibrador de carga da aplicación, entón Elastic IP só afectaba ao equilibrador de carga de rede.
Imos crear un equilibrador de carga de rede:
E xusto durante o proceso de creación veremos que se nos dá a oportunidade de seleccionar IP elástica:
Elastic IP proporciona un único enderezo IP que se pode asociar con diferentes instancias EC2 ao longo do tempo. Se unha instancia EC2 ten un enderezo IP Elastic e esa instancia finaliza ou se detén, pode asociar inmediatamente unha nova instancia EC2 cun enderezo IP Elastic. Non obstante, a túa aplicación actual non deixará de funcionar, xa que as aplicacións seguen vendo o mesmo enderezo IP, aínda que o EC2 real cambiou.
Aquí sobre o tema de por que se necesita Elastic IP. Mira, vemos 3 enderezos IP, pero non quedarán aquí para sempre:
Amazon cámbiaos co paso do tempo, quizais cada 60 segundos (pero na práctica, por suposto, con menos frecuencia). Isto significa que os enderezos IP poden cambiar. E no caso de Network Load Balancer, só podes vincular un enderezo IP e indicalo nas túas regras, políticas, etc.
Tira conclusións
ELB ofrece distribución automática do tráfico entrante en varios obxectivos (contedores, instancias de Amazon EC2, enderezos IP e funcións Lambda). ELB é capaz de distribuír o tráfico con diferentes cargas tanto dentro dunha única Zona de Dispoñibilidade como en varias Zonas de Dispoñibilidade. O usuario pode escoller entre tres tipos de equilibradores que proporcionan alta dispoñibilidade, escalado automático e unha boa protección. Todo isto é importante para garantir a tolerancia a fallos das súas aplicacións.
Principais vantaxes:
- alta dispoñibilidade. O acordo de servizo supón unha dispoñibilidade do 99,99 % para o equilibrador de carga. Por exemplo, varias zonas de dispoñibilidade garanten que o tráfico sexa procesado só por obxectos saudables. De feito, pode equilibrar a carga en toda a rexión, redirixindo o tráfico a obxectivos saudables en diferentes zonas de dispoñibilidade;
- seguridade. ELB traballa con Amazon VPC, proporcionando varias capacidades de seguridade: xestión integrada de certificados, autenticación de usuarios e descifrado SSL/TLS. Todos xuntos proporcionan unha xestión centralizada e flexible da configuración de TLS;
- elasticidade. O ELB pode xestionar cambios bruscos no tráfico da rede. E a integración profunda con Auto Scaling dálle á aplicación recursos suficientes se a carga cambia, sen necesidade de intervención manual;
- flexibilidade. Podes usar enderezos IP para dirixir solicitudes aos destinos das túas aplicacións. Isto proporciona flexibilidade á hora de virtualizar aplicacións de destino, dando así a posibilidade de hospedar varias aplicacións nunha única instancia. Dado que as aplicacións poden usar un único porto de rede e ter grupos de seguridade separados, a comunicación entre aplicacións simplifícase cando temos, por exemplo, unha arquitectura baseada en microservizos;
- seguimento e auditoría. Podes supervisar as aplicacións en tempo real usando as funcións de Amazon CloudWatch. Estamos a falar de métricas, rexistros, seguimento de solicitudes. En termos sinxelos, poderás identificar problemas e identificar os pescozos de botella de rendemento con bastante precisión;
- equilibrio de carga híbrido. A capacidade de equilibrar a carga entre os recursos locais e AWS usando o mesmo equilibrador de carga fai que sexa fácil migrar ou expandir aplicacións locais á nube. O manexo de fallos tamén se simplifica usando a nube.
Se estás interesado nos detalles, aquí tes un par de ligazóns máis útiles do sitio web oficial de Amazon:
- .
Fonte: www.habr.com