Ir más lejos

1. En caso de catástrofe

Figura 1: Cuando ocurre lo peor

Cuando hablamos de alta disponibilidad, solemos hablar también de recuperación ante desastres, de ahí el término HA-DR (High Availability-Disaster Recovery). 

Aunque el objetivo de la alta disponibilidad es garantizar la disponibilidad de las aplicaciones en el mayor número posible de escenarios, también es necesario planificar lo que a veces parece improbable: un fallo importante que provoque la no disponibilidad parcial o total del servicio o, incluso, su destrucción total.

Suele ser una lección que se aprende demasiado tarde: nunca se confíe demasiado. Recuerde la Ley de Murphy: todo lo que puede salir mal, saldrá peor. Y el corolario de Finagle (que es un personaje de ficción): todo lo que pueda salir mal saldrá el peor momento posible. Recordemos también que hay dos tipos de ingenieros de sistemas: los que han cometido un grave error y los que van a volver a cometerlo.

Los autores han tenido la oportunidad de probar varios escenarios en producción real. Los trabajos de producción informática pueden ser angustiosos. ¿Cómo reaccionar cuando se pierde la interconexión entre dos centros de datos?  ¿Cómo reaccionar cuando alguien desconecta todos los repartidores de carga al mismo tiempo, cortando así por completo el acceso a todos los servidores?

Cualquier sistema creado por un ser humano está abocado a ser imperfecto. De hecho, la mayoría de los incidentes y accidentes son el resultado de la intervención humana, ya sea involuntaria o no.

Cuando todo va mal, cuando todo se pierde, hay que pensar en el plan B o incluso en el plan C. ¿Cómo se vuelve a la normalidad? Anticipándose a la catástrofe y poniendo en marcha un plan para reanudar los servicios.

1. Redundancia frente a copia de seguridad

Es muy importante señalar este hecho evidente. Los sucesos de marzo de 2021, que provocaron la pérdida permanente de miles de sitios web y servicios, e incluso la pérdida de todos los datos de algunas empresas, son otra llamada de atención.

Figura 3: Sin copia de seguridad... La desesperación tras la pérdida de un centro de datos

Ya sea en la nube o en su propio centro de datos, las copias de seguridad son necesarias y vitales. En el mundo digital actual, los datos son un componente vital de cualquier organización, pero no el único. ¿Cuántas tragedias están relacionadas con la pérdida de fotos familiares tras la caída de una aplicación o el fallo de una llave USB, tarjeta de memoria o disco duro?

Las copias de seguridad se deben externalizar: no deben estar ubicadas en el mismo centro de datos que los servidores. Si es posible, deben estar disponibles por duplicado. En la nube, se pueden duplicar volúmenes específicos en varias zonas y regiones para garantizar la disponibilidad. En AWS, por ejemplo, los buckets S3 se pueden replicar entre varias regiones e incluso entre buckets.

Lo mismo ocurre en Azure, por supuesto, donde los datos y las copias de seguridad se pueden replicar en varios modelos, dentro de una sola región, en varias zonas y en varias regiones. Las copias de seguridad se deben probar: comprobamos periódicamente que son accesibles y están disponibles y que los datos se pueden restaurar...

1. Contenedor y root

$ docker run --name some-nginx -d nginx 
... 
11a90c92c2c3b3507fa5068198a780bf9be39a74df5f427f8a601945c9d15a54 

$ docker exec -ti 11a90c92c2c3 bash 
root@11a90c92c2c3:/# id 
uid=0(root) gid=0(root) groups=0(root) 

seb@infra01:~$ docker run --name some-nginx -v /etc:/mnt/etc -d 
9f4d178c388e3df5e8e0f68137054339e7b0a0fbd8562245ddf4263fd7685cbd 
seb@infra01:~$ docker exec -ti 9f4d178c388e3 bash 
root@9f4d178c388e:/# echo "seb ALL=(ALL) NOPASSWD: ALL" > 
/mnt/etc/sudoers.d/seb 
root@9f4d178c388e:/# exit 
exit 
seb@infra01:~$ sudo -l 
User seb may run the following commands on infra01: 
    (ALL) NOPASSWD: ALL 

1. Métrica

Las métricas son esencialmente la recopilación de información sobre los procesadores, la memoria, los discos y la red con el fin de comprobar su rendimiento. Gracias a estos valores y a su seguimiento, es posible analizar el consumo de los distintos recursos y actuar en consecuencia:

Las métricas se suelen controlar mediante herramientas de supervisión y sondas como Nagios y Centreon, que son gratuitas y protocolos como SNMP. Las herramientas de línea de comandos del sistema como sar, iostat, mpstat, etc. proporcionan información útil.

Kubernetes ofrece un API dedicado a las métricas, que requiere el uso de un controlador complementario opcional. Este API proporciona acceso a nuevas funciones, como el autoescaling (adición y eliminación dinámica de pods en función de la carga).

Para probar esta funcionalidad, es necesario instalar un pipeline de recogida de métricas. Existen dos tipos, en función de si se basan en la recopilación de métricas vinculadas únicamente al clúster, como metrics-server, o en la recopilación de métricas vinculadas a todo el entorno, como Prometheus.

El servidor de métricas está disponible en https://github.com/kubernetes-sigs/metrics-server.

Prometheus es más completo, pero también más complejo, está disponible en https://prometheus.io/.

Puede instalar rápidamente metrics-server de la siguiente manera:

$ kubectl apply -f https://github.com/kubernetes-sigs/ 
metrics-server/releases/latest/download/components.yaml 
serviceaccount/metrics-server created 
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics- 
reader created 
clusterrole.rbac.authorization.k8s.io/system:metrics-server created 
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created 
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system: 
auth-delegator...