PDF de programación - Nube híbrida: Autoescalado horizontal hacia AWS

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