Publicado el 17 de Abril del 2019
1.236 visualizaciones desde el 17 de Abril del 2019
1,2 MB
36 paginas
Creado hace 8a (01/01/2017)
Nube híbrida: Autoescalado horizontal
hacia AWS
Josué Álvarez Moreno
Índice
Prefacio.
Escenario tipo sobre el cual trabajaremos.
Estado inicial.
Contexto semi-ficticio.
El problema.
Objetivo de este documento.
Solución.
Ventajas.
Inconvenientes y detalles a considerar.
Detalles preliminares.
Nagios.
Instalación y configuración del servidor.
Configuración de notificaciones por email.
Reaccionar a eventos de carga de CPU en los nodos.
nagios-cpu-handler.sh
Plantilla de monitorización para los nodos.
Configuración de los nodos
Instalación del agente de monitorización
Habilitamos la ejecución de comandos de forma remota.
Definición del comando de chequeo de carga de CPU.
Añadir al servidor de Nagios a la lista de hosts permitidos.
HAProxy.
Terraform.
Qué es
Instalación.
Primeros pasos: Desplegar una instancia en AWS
Provisionamiento de instancias.
Descripción del servidor maestro en la nube.
Plantilla que usaremos para los nodos.
Otros scripts importantes.
Prueba de funcionamiento
Preguntas que te estás haciendo ahora mismo, y posibles mejoras.
Prefacio.
Todos los scripts de provisionamiento y de transición de local-a-cloud están disponibles en
https://github.com/icebergonfire/proyecto-2ASIR bajo licencia GPL 3.0 para cualquier uso que
quieras darle. Este documento incluye sólo el código de los más relevantes conceptualmente.
Este repositorio no es un programa plug and play que puedas aplicar a tu infraestructura y ya
tienes autoescalado horizontal, pero puede servirte de punto de partida para adaptarlo a tus
necesidades.
Dicho esto, comencemos.
Escenario tipo sobre el cual trabajaremos.
Estado inicial.
Nuestra empresa hipotética, JosuéOnSecurity, tiene un blog en el que escribimos artículos
semi-técnicos con el objetivo de captar clientes. Hasta ahora, este blog ha sido servido desde
nuestro centro de datos. Conforme hemos ido recibiendo más visitantes únicos a lo largo del
tiempo, la estrategia de escalado ha consistido simplemente en añadir más RAM y CPU a la
máquina. No disponemos de failover de ningún tipo, ya que el resultado de un análisis
coste/beneficio muestra que se requiere gran inversión inicial y un retorno económico
difícilmente cuantificable: nuestro blog puede generar buenas sensaciones sobre nuestra
efectividad como proveedor de soluciones de seguridad, pero la buena imagen no aparece en
la lista de generadores de tráfico hacia la sección de ventas.
Contexto semi-ficticio.
El 12 de Mayo de 2017 se inició un ataque de ransomware a gran escala que paralizó a
instituciones como Telefónica, el equivalente británico a la sanidad española (NHS), FedEx y el
homónimo alemán de Renfe (Deutsche Bahn). Explicado brevemente, el cryptogusano
conocido como WannaCry cifra los datos del disco duro y solicita un rescate abonado a través
de BitCoin.
JosueOnSecurity dispone de un producto que protege contra las infecciones de ransomware,
así que rápidamente lanzamos una campaña de PR sobre lo fácil que hubiese sido para estas
grandes organizaciones evitar esta catástrofe. Esta campaña consiste en varias entradas en el
blog cuidadosamente creadas para incrementar nuestro SEO y contacto personalizado con
clientes que tenemos en el punto de mira.
El problema.
¡Éxito! Nuestros posts empiezan a recibir cientos de visitas de usuarios únicos por segundo.
Nos llaman de El País, quieren sacarnos en un árticulo como expertos y lo quieren ya. Google
Analytics nos indica que alguien ha posteado nuestro artículo en Hacker News, Reddit y
Xataka. Está ganando tracción a gran velocidad, y algunos usuarios de nuestro software hablan
de lo bien que les ha funcionado y que de como ellos don’t wannacry.
Nuestro CEO desciende al subsótano de IT con una botella de whiskey de casi cuatro cifras
para felicitarnos personalmente por cómo hemos podido aprovechar esta oportunidad gracias a
nuestra maravilloso equipo de IT y, mientras nos cuenta todas las enormes posibilidades que
esta atención nos ha otorgado…
...oh.
Objetivo de este documento.
¿Cómo podemos planear capacidad para picos de popularidad imprevisibles, sin desperdiciar
dinero y hardware el resto del año? Simple y sencillo, aplicamos la nube a nuestra arquitectura
de forma que podemos escalar de forma horizontal bajo demanda cuando sea necesario y
reducir de nuevo nuestro hardware al volumen habitual tras el pico de demanda.
disponibilidad tiene que tener tantos nueves como sea posible.
- Debe ser un proceso automatizado que no requiera de intervención manual: Nuestra
- Debe ser fiable: Funcionará hoy, mañana y el año que viene independientemente del
- Debe ser flexible: Queremos poder añadir más poder de computación o reducirlo en
contenido de la web.
tiempo real, ajustándonos a la demanda.
Solución.
- Monitorizar el uso de recursos, e iniciar el proceso de escalado hacia la nube de
Amazon cuando se supere un criterio definido. Para esto usaremos Nagios.
- El despliegue de la infraestructura en la nube debe ser 100% automatizado, y debe ser
suficientemente flexible para reflejar nuestra arquitectura actual y futura en la nube. De
esta forma, no tendremos que tener en cuenta donde se van a desplegar los recursos y
podremos considerarlo un segundo centro de datos desplegable bajo demanda en
breves minutos. Usaremos Terraform.
- Añadir y eliminar nodos en la nube debe ser un proceso totalmente
automatizado, incluyendo su registro en Nagios y Haproxy.
- Servir recursos web es un tipo de problema fácilmente paralelizable: Cada usuario único
que visite nuestra web tiene su propio contexto, y puede residir en su propio “nodo” sin
compartir estado con otros usuarios. Para balancear la carga entre estos nodos
usaremos Haproxy.
- Un caso no contemplado en esta implementación es el uso de base de datos.
Este apartado lo estudiaremos de forma teórica en el anexo dedicado a mejoras
de esta solución.
Ventajas.
-
-
Infraestructura como código (IaC): Podremos versionar/revertir/expandir nuestra
infraestructura de forma no destructiva.
Inversión inicial requerida: Despreciable, podemos hacer las pruebas en instancias
t2.micro y pagaremos unos 2 dólares al día por levantar varios nodos.
- El tiempo de despliegue es literalmente cinco minutos en total. Terraform genera
nuestra infraestructura de forma paralela, así que no importa si estamos añadiendo dos
nodos o cuarenta.
Terraform es agnóstico: Al contrario que CloudFormation o Heat, Terraform soporte
diferentes proveedores otorgándonos la flexibilidad de usar el que más nos convenga
en cada momento.
-
Inconvenientes y detalles a considerar.
- General
- No existe una herramienta plug and play para esta situación, sino múltiples
componentes de software que podemos unir programáticamente de forma que
obtenemos el resultado deseado. Gran parte de nuestro trabajo es escribir
scripts muy adaptados a nuestro entorno específico.
- Dicho esto, hay varios puntos lógicos en el diseño para inyectar
componentes adicionales como bases de datos en HA o aplicaciones.
-
Terraform
- Su fiabilidad depende enteramente de la API de cada proveedor: Aunque la
herramienta intenta mitigar posibles fallos mediante reintentos, timeouts y el uso
de una caché local que contiene el estado de la infraestructura, está a merced
de la fiabilidad de la API. Con AWS me he encontrado con situaciones en las
que Terraform es incapaz de generar o destruir una instancia porque la id no
existe, a pesar de que dicha id aparece en la consola de AWS asociada a la
instancia deseada.
- AWS es conocida por la fiabilidad de su dashboard de salud de la API:
Tick verde significa todo correcto, tick verde con una pequeña
interrogación significa caída generalizada.
La caché local (“terraform.state”) es el punto de referencia autoritario y absoluto
para Terraform. Si se corrompe o la nube se modifica desde fuera de Terraform,
podemos encontrarnos en una situación en la que Terraform destruya y regenere
recursos de forma innecesaria y en ocasiones causando caídas.
La flexibilidad de proveedores tiene un precio: Aunque Terraform es
agnóstico, la sintáxis declarativa de los ficheros no lo es. Por tanto,
debemos mantener diferentes versiones de nuestra infraestructura según dónde
vayamos a desplegarla.
-
-
A continuación explicaremos el uso de Terraform, Nagios y Haproxy; describiendo la
configuración que utilizaremos para implementar esta solución y cómo adaptaremos cada uno
de estos componentes para que encajen en el puzzle final.
Detalles preliminares.
Todas las máquinas contienen un usuario puppet, sin contraseña, que permitirá conexiones con
nuestra clave privada. Este usuario tendrá privilegios de sudo sin requerir contraseña, y será
nuestro punto de entrada para automatizar las tareas.
Esta parte del provisionamiento está recogida en base-provisioning.sh.
El control del dns del dominio lo realizaremos a través de ddclient, tanto en el centro de
datos local como en el remoto.
Dado que mi entorno de pruebas local está basado en Vagrant, durante el provisionamiento
almaceno los recursos en /vagrant/ para poder usar los mismos scripts y fingir que Vagrant es
mi centro de datos con ajustes mínimos.
Nagios.
Nagios es una aplicación open-source que monitoriza sistemas y redes, y es capaz de enviar
alertas y ejecutar acciones cuando cambia la disponibilidad de los componentes monitorizados.
Vamos a implementarlo utilizando un servidor central, y desplegaremos el agente de Nagios en
cada uno de los nodos para monitorizar el uso de CPU. Cuando el uso supere el nivel que
consideremos adecuado, utilizaremos Nagios para iniciar las tareas de escalado hacia la nube.
Aunque aquí vamos a detallar el proceso paso a paso, esto estará automatizado en el
escenari
Comentarios de: Nube híbrida: Autoescalado horizontal hacia AWS (0)
No hay comentarios