¿Qué es el AWS Well-Architected Framework?

AWS Well-Architected Framework es una herramienta para evaluar y mejorar las arquitecturas de la nube. Se basa en seis pilares: excelencia operativa, seguridad, fiabilidad, eficiencia en el desempeño, optimización de costes y sostenibilidad. El marco proporciona las mejores prácticas y pautas para diseñar y operar entornos seguros, eficientes y rentables en la nube de AWS.

¿Cómo migrar a AWS?

Los desafíos de migrar a la nube de AWS varían desde detalles técnicos hasta requisitos regulatorios. El marco de buena arquitectura de AWS permite identificar obstáculos de forma temprana y abordarlos de manera eficaz. Más allá de una simple tarea técnica, el uso de la nube se considera no solo como una tarea técnica, sino también como parte de la estrategia corporativa. 

Por esta razón, las organizaciones que adoptan una visión holística de la implementación y operación de sus servicios en la nube están mejor posicionadas para afrontar con éxito tanto los desafíos inmediatos como los objetivos comerciales a largo plazo.

Los seis pilares de un marco de buena arquitectura AWS  

El AWS Well-Architected Framework se estructura en seis pilares centrales, cada uno de los cuales aborda aspectos específicos de la arquitectura en la nube. Gracias a esta división, las empresas pueden crear un entorno robusto y eficiente.

• Excelencia operativa: apoyar y optimizar las operaciones para lograr mejores procesos de negocio a través de la automatización y flujos de trabajo optimizados.
• Seguridad: garantizar la protección de los datos y sistemas, con especial atención a la evaluación de riesgos, la integridad de los datos, la confidencialidad y la disponibilidad.
• Fiabilidad: sistemas robustos que permanecen estables incluso ante eventos inesperados y pueden recuperarse rápidamente.
• Eficiencia en el rendimiento: seleccionar los recursos y tecnologías adecuados y adaptar el rendimiento del sistema a los requisitos cambiantes.
• Optimización de costes: controlar el consumo de recursos y los costes para garantizar que las inversiones creen valor.
• Sostenibilidad: minimizar el impacto ambiental de las cargas de trabajo en la nube, reduciendo el consumo de energía y las emisiones de carbono.

Al aplicar estos principios, AWS Well-Architected Framework ayuda a las organizaciones a crear un entorno de nube de última generación.

¿Cómo debe ser el marco de buena arquitectura de AWS? 

El marco de buena arquitectura de AWS y el modelo de responsabilidad compartida son dos caras de la misma moneda. Mientras que el primero proporciona los principios y mejores prácticas para diseñar y operar una arquitectura de nube eficiente, el segundo define claramente las responsabilidades de AWS y sus clientes. 

Responsabilidad de AWS:

• Seguridad física de los centros de datos.
• Integridad de los dispositivos de red.
• Fiabilidad del hardware del host.
• Seguridad de la infraestructura global que respalda la disponibilidad de los servicios de AWS.

Responsabilidad del cliente:

• Implementación de la gestión del control de acceso.
• Cifrado de datos.
• Funcionamiento seguro de las aplicaciones.
• Gestión eficaz de parches y configuraciones de sistemas operativos y aplicaciones.

Si se malinterpreta el modelo de responsabilidad compartida, pueden generarse brechas en el cumplimiento y la seguridad. Por el contrario, los clientes que implementan este enfoque reducen los riesgos y logran un alto nivel de seguridad. 

El marco Well-Architected complementa este modelo proporcionando pautas claramente definidas para diseñar las tareas del cliente.

El marco Well-Architected para optimizar el rendimiento, la seguridad y los costes

El AWS Well-Architected Framework ha demostrado su eficacia para muchas empresas. Es el punto de partida para conceptos de seguridad mejorados y permite un importante ahorro de costes. Los siguientes ejemplos muestran cómo las empresas optimizan su infraestructura en la nube utilizando el marco.

Ejemplos de excelencia operacional:

• Las empresas pueden implementar pruebas de carga automatizadas para verificar el rendimiento de su arquitectura de nube en diferentes escenarios. Esto ayuda a identificar cuellos de botella de forma temprana y optimizar toda la infraestructura para lograr un rendimiento óptimo bajo alta carga.
• Al establecer KPI detallados, las empresas pueden monitorear continuamente el rendimiento de su arquitectura en la nube. Analizar estos datos ayuda a identificar tendencias y realizar optimizaciones proactivas para mejorar continuamente la eficiencia.

Ejemplos de mejoras de seguridad:

• La automatización de pruebas garantiza el cumplimiento de las políticas de seguridad. Los scripts proporcionados por el marco comprueban automáticamente las configuraciones durante las actualizaciones. Las vulnerabilidades se identifican y resuelven rápidamente antes de que lleguen a producción.
• Las pruebas de penetración ayudan a las empresas a evaluar la seguridad de su nube. Las pruebas identifican riesgos de seguridad ocultos a través de ataques simulados. De esta forma se mejoran continuamente los mecanismos de protección para hacer frente a las ciberamenazas.

Ejemplos de ahorro de costes:

• Dirigir la asignación de recursos a áreas críticas para el negocio aumenta la eficiencia de los costos operativos y mejora el ROI (retorno de la inversión).
• Las directrices marco para la gestión de recursos permiten a las empresas hacer un uso óptimo de sus recursos. Al escalar hacia arriba o hacia abajo según la carga de trabajo, se pueden optimizar los costos y gestionar los picos de carga.

Los escenarios ilustran cómo el  Well-Architected Framework ayuda a desarrollar enfoques personalizados que se adaptan a las necesidades específicas de las empresas.

Los partners de AWS como clave del éxito

Al adoptar el AWS Well-Architected Framework, existen obstáculos que pueden obstaculizar el progreso. A pesar de los beneficios del AWS Well-Architected Framework, las empresas pueden enfrentar obstáculos que dificultan su implementación. Por ello, colaborar con un partner de AWS resulta clave para maximizar su aprovechamiento. Además, esto les permite acceder a conocimientos especializados y una serie de otras ventajas:

• Conocimiento experto profundo: los partners de AWS tienen un conocimiento integral de los servicios y arquitecturas de AWS. Están familiarizados con los últimos avances y le ayudarán a crear un entorno de nube preparado para el futuro.
• Estrategias de implementación a medida: la implementación no es una solución única para todos, sino que requiere un enfoque individual. Los partners de AWS comprenden los desafíos específicos de cada negocio y ofrecen estrategias personalizadas.
• Acceso a los recursos de AWS: los partners de AWS tienen acceso privilegiado a sus recursos, herramientas y opciones de soporte. Esto abarca desde soporte técnico hasta materiales de capacitación y documentación de mejores prácticas.
• Aumenta la eficiencia y reduce los costes: con sus muchos años de experiencia en proyectos, los partners de AWS pueden ayudar a aumentar el rendimiento del entorno. Ayudan a identificar y eliminar costos innecesarios.
• Mitigación de riesgos: los partners de AWS están familiarizados con los errores comunes al implementar el marco. Ayudan a identificar problemas antes de que tengan un impacto en el negocio.

Como partners de AWS desde hace tiempo, Claranet y Geko combinamos experiencia y conocimientos en tecnologías de la nube con un profundo entendimiento del ecosistema de AWS. Esto garantiza una optimización eficiente del entorno y una migración sin problemas a la infraestructura existente.

¿Quieres aprovechar al máximo las oportunidades del AWS Well-Architected Framework? Contacta con nuestro equipo de expertos. 

La entrada Cómo migrar a la nube con AWS Well-Architected Framework se publicó primero en Geko Cloud.

Logs de AWS SES a Opensearch mediante AWS Kinesis.
Por defecto, el servicio de AWS Simple Email Service (SES) no nos ofrece poder visualizar logs de sus acciones/eventos, tan solo podemos ver algunas métricas en Cloudwatch. Desde Geko nos hemos encontrado más de una vez con la necesidad de ver logs de SES, ya sea para diagnosticar incidencias o para conocer mejor el estado del servicio. Pues bien, para que esto sea posible, hacemos uso de AWS Kinesis. Vamos a explicar como lo montamos. Empecemos!

Configuración en Kinesis

Kinesis es un recolector, procesador y transmisor de datos. El primer paso es crear un Delivery Stream. Accedemos al servicio de Kinesis, Delivery Streams y creamos un Delivery Stream

En «Source» eleccionamos «Direct PUT» y en Destination «Amazon OpenSearch Service». Existen otras opciones de destino como Redshift, S3, Dynatrace.. En el desplegable aparecen todas las disponibles.

Añadimos un nombre al objeto «Delivery Stream» y añadimos nuestro OpenSearch. En nuestro caso, al ya tener un OpenSearch creado y operativo simplemente accediendo a «Browse» nos ha aparecido para seleccionarlo.

Ponemos el nombre de índice que queremos que nos cree

Y por defecto nos selecciona VPC, Subnet y Security Group en base a nuestro OpenSearch.

Finalmente creamos el objeto «Delivery Stream»

Configuración SES

Ahora accedemos al servicio SES, accedemos a «Configuration Sets» y «Create Set»

Ponemos un nombre al «Configuration Set» y lo creamos.

Una vez creado el «Configuration Set» vamos a «Event Destionation» y «Add Destination» para crear uno.

Seleccionamos el tipo de evento que queremos y vamos al siguiente paso

Seleccionamos «Amazon Kinesis Data Firehose», ponemos un nombre y seleccionamos el «Delivery Stream» que hemos creado anteriormente.

Cuidado! Ahora hay que crear un «IAM Role» para que SES pueda escribir en Firehose, nosotros lo hemos creado así:

Con esta Policy

Y esta Trust Relationship

Finalmente creamos la «Configuration Set»

Ahora, para testearlo, se puede enviar un email de test desde SES asignando a nuestro test la «Configuration Set» que hemos creado. Esta «Configuration Set» se puede aplicar a cualquier Identity que tengamos en SES. De hecho vamos a hacer una prueba enviado un email de test. Vemos el log de test que hemos generado en nuestro OpenSearch:

Y en el monitoring de Delivery de Kinesis:

Desde Geko esperamos que si has llegado hasta aquí, esta entrada sea justo lo que andabas buscando! Te invitamos también a que leas otros de nuestros posts de labs.

La entrada Logs de AWS SES a Opensearch mediante AWS Kinesis se publicó primero en Geko Cloud.

• 13.10.3
• 13.9.6
• 13.8.8

Nos puede suceder que tengamos algún Gitlab aún mas viejo a estas versiones, entonces tendremos que actualizarlo a la versión más reciente pasando por varias versiones intermedias.

A continuación, mostraremos los pasos para actualizar Gitlab en Ubuntu 18. Partiremos en el ejemplo de gitlab-ee 12.7.5-ee y lo llevaremos hasta la versión 14.4.2-ee.

Consideramos que Gitlab está instalado previamente desde el repositorio oficial con sus servicios postgresql y redis embebidos.

Pasos previos

Si estamos trabajando en el Cloud y tenemos nuestro Gitlab instalado en una instancia EC2<, se recomienda crear una imagen de la instancia y clonarla en una nueva para realizar los pasos de migración.

También necesitaremos acceso a la consola de Linux de dicha instancia y tener permisos de root.

Updates + snapshots

Ejecutamos en secuencia los siguientes comandos <apt install> esperando en cada caso que no nos dan ningún error y finalizan correctamente.

sudo apt install gitlab-ee=12.10.14-ee.0
sudo apt install gitlab-ee=13.0.14-ee.0
sudo apt install gitlab-ee=13.1.11-ee.0
sudo apt install gitlab-ee=13.8.8-ee.0
sudo apt install gitlab-ee=13.12.10-ee.0
sudo apt install gitlab-ee=13.12.12-ee.0

Una vez finalizados estos pasos, tendremos que ejecutar en consola el siguiente comando, ya que gitlab necesita migrar sus proyectos existentes al nuevo sistema de hashed_storage que utilizan las versiones siguientes.

sudo gitlab-rake gitlab:storage:migrate_to_hashed

Al finalizar el comando anterior, debemos reiniciar la instancia y volver a conectarnos a ella.

En este punto contamos con Gitlab 13.12.12

Continuemos con las actualizaciones

sudo apt install gitlab-ee=14.0.11-ee.0

Al terminar este paso, deberemos comprobar que todas las migraciones han finalizado correctamente.

A partir de esta versión Gitlab nos proporciona una nueva herramienta que nos permite ver si se están ejecutando migraciones. Debemos comprobar que no haya ninguna en cola y que todas hayan finalizado sin errores.

Encontramos esta herramienta en: administration>monitoring>Background Migrations.

Además, también comprobaremos en  administration>monitoring>healthCheck que Gitlab se encuentra en estado “Healthy”.

Al finalizar este paso, se recomienda hacer un snapshot

Seguiremos con la siguiente secuencia de updates

Al final de cada una, repetiremos el ejercicio de comprobar por cada finalización, Background Migrations

sudo apt install gitlab-ee=14.1.6-ee.0
sudo apt install gitlab-ee=14.2.0-ee.0
sudo apt install gitlab-ee=14.2.6-ee.0
sudo apt install gitlab-ee=14.3.0-ee.0
sudo apt install gitlab-ee=14.3.4-ee.0
sudo apt install gitlab-ee=14.4.0-ee.0
sudo apt install gitlab-ee=14.4.2-ee.0

Otro tip importante a saber es que en algunas versiones, previas a la 14, veremos que el comando apt ha terminado, pero al intentar acceder a Gitlab obtenemos un error 502. Esto sucede porque existen los ya mencionados Background Migrations, pero para estas versiones no existía la herramienta que nos permitía observar su estado. Pero no desesperemos porque podemos ver el log! y observar cuando hayan acabado.

Podemos ver las últimas entradas del log así y comprobar que no se encuentren transacciones en ejecución:

sudo tail -f /varlog/gitlab/gitlab-rails/production.log

Y ya está, lo hemos logrado! Enhorabuena

Espero que este artículo te haya servido de ayuda para aprender algo nuevo y seguir ampliando tus conocimientos.

Te invito a que si necesitas información sobre el mundo DevOps , nos contactes y sigas revisando nuestro blog para encontrar otras publicaciones útiles.

¡Hasta la próxima!

→ Post escrito por Christian Tagliapietra y Álvaro Abad.

La entrada Cómo actualizar Gitlab se publicó primero en Geko Cloud.

En este artículo hablaremos de una de las herramientas del momento cuando se habla de procesos de integración y despliegue continuo CICD en Kubernetes, ArgoCD. Y es que, en los últimos meses, son muchas las empresas punteras del sector de internet que han declarado públicamente el uso de ArgoCD para desplegar aplicaciones en sus clústers. Puedes ver una lista aquí.

Para empezar, vamos a repasar para qué sirve y hasta dónde llegan las funcionalidades de ArgoCD. Seguidamente, veremos un caso de uso típico de despliegue de aplicaciones usando ArgoCD y las ventajas que nos aporta su implementación. Finalmente, comentaremos las conclusiones que hemos sacado en cuanto a pros y contras, y analizaremos que otras herramientas complementan ArgoCD para optimizar aún más el proceso de integración y despliegue continuo de aplicaciones.

¿Que es ArgoCD?

ArgoCD es una herramienta que nos permite adoptar metodologías GitOps para el despliegue continuo de aplicaciones en clústers de kubernetes.

La principal característica es que ArgoCD sincroniza el estado de las aplicaciones desplegadas con sus respectivos manifiestos declarados en git. Permitiendo así a los desarrolladores realizar cambios en la aplicación con solo modificar el contenido de git, ya sea con commits a ramas de desarrollo o modificando main.
Una vez modificado el código en git, ArgoCD detecta, mediante webhook o comprobación periódica cada 3 minutos, que ha habido cambios en los manifiestos de las aplicaciones. Seguidamente, compara los manifiestos declarados en git con los que hay aplicados en los clústers y actualiza estos últimos hasta sincronizarlos.

Su refinada interfaz de usuario permite visualizar muy bien el contenido, estructura y estado de los clústers ademas que deja manipular los recursos.

¿Permite ArgoCD automatizar todo el proceso de CI/CD de una aplicación?

No, ArgoCD se encarga de desplegar la aplicación una vez ya existe el artefacto en un registro de contenedores, como Dockerhub o ECR.  Esto implica que previamente el código de la aplicación ya ha sido testado y «containerizado» en una imagen. Al final de este artículo vamos a hablar sobre qué opciones existen actualmente para llevar a cabo esta tarea.

Como ya hemos explicado, ArgoCD sincroniza el estado de las aplicaciones desplegadas con sus respectivos manifiestos declarados en git. Pero no se refiere al repositorio git del código de la aplicación en sí, sino a otro repositorio separado, como indican las buenas prácticas, que contiene el código de la infraestructura en kubernetes de la aplicación, que puede ser en forma de helm charts, aplicación kustomize, ksonnet… 

Para explicar mejor los principales beneficios que ofrece ArgoCD veamos un ejemplo de uso.

Usando ArgoCD

En este ejemplo vamos a ver cómo ArgoCD puede desplegar ya sea aplicaciones desarrolladas por terceros, que tiene su propio helm chart mantenido por otra organización, o una propia donde hemos definido el chart nosotros mismos.

Para el ejemplo desplegaremos un stack de monitoring compuesto de Prometheus, Grafana y Thanos mediante sus helm charts.

ArgoCD despliega las aplicaciones mediante un objeto custom llamado Application. Este objeto tiene como atributos un origen y una destinación. El origen puede tener varios formatos, como por ejemplo un helm chart de un repositorio de charts, o un repositorio git que contiene helm charts. La destinación es el cluster al cual será desplegado el contenido del origen. En la configuración del application podemos indicar que ArgoCD mantenga automáticamente sincronizado el estado de los objetos de kubernetes desplegados con la configuración indicada en el origen (charts/git). Esta opción es muy interesante, ya que nos asegura que ArgoCD va a estar pendiente cada pocos minutos de que todo siga en su sitio, por contra, desplegando las aplicaciones directamente con comandos de helm únicamente nos aseguramos la sincronización en el momento de un despliegue.

Ahora que ya hemos explicado que es el objeto Application, para nuestro monitoring-stack, vamos a crear cuatro. ¿Por qué cuatro Applications si solo habrá 3 servicios en el stack? (Prometheus, Grafana y Thanos)

ArgoCD también nos ofrece la posibilidad de generar grupos de aplicaciones que siguen el concepto de «app of apps pattern» . Se trata de una ArgoCD application que despliega otras aplicaciones y así recursivamente. En el caso de nuestro monitoring stack, vamos a crear una cuarta aplicación que va a desplegar las otras 3 restantes, la aplicación padre la vamos a llamar «monitoring-stack».

Para crear una aplicación podemos definir un manifiesto ArgoCD Application, como se indica en esta página de la documentación. También podemos mediante línea de comandos. Pero ArgoCD tiene una genial UI que permite crear aplicaciones manualmente también, puede ver cómo aquí.

La aplicación «monitoring-stack» apuntará su origen a un repositorio git con un Helm chart. Este chart contendrá los manifiestos de las otras tres aplicaciones en el directorio «templates» en formato yaml. Estos archivos son definiciones de objetos Application que apuntan al pertinente Helm chart oficial de cada servicio. Mediante los «values files», podremos desplegar diferentes versiones en entornos distintos.

Una vez definidas las templates del chart «monitoring-stack», vamos a crear la ArgoCD Application, y en source vamos a apuntar hacia el repositorio que lo contiene. ArgoCD va a detectar que se trata de un helm chart y podremos indicar el path del values file concreto, por ejemplo «prod-values.yaml».

Al finalizar la configuración manual de la aplicación, en la interfaz de usuario veremos como se representan todos los objetos generados, organizados de forma jerárquica.

Al estar las aplicaciones sincronizadas con nuestro repositorio, y los charts parametrizados con templates y values. Para desplegar una nueva versión de cualquiera de nuestras aplicaciones solo tendremos que modificar el archivo values mediante commits de git.
ArgoCD se encargará de detectar los cambios en el repositorio y aplicarlos en el clúster de kubernetes mediante un despliegue rolling update.

Como apunte, usando ArgoCD Image Updater nos podemos ahorrar hacer este último paso manualmente, o incluso tener que desarrollar una pipeline compleja para actualizar el fichero values.yaml en git cuando queremos desplegar la nueva imagen.
Esta herramienta consulta periódicamente los últimos tags en nuestro repositorio de imágenes buscando nuevos artefactos para desplegar. De esta forma, una vez ha encontrado uno nuevo, se encarga de automatizar el proceso de despliegue editando la configuración de git con el nombre del nuevo tag.
Hace falta mencionar que aún no hay una versión estable de ArgoCD Image Updater, pero se la espera pronto.

En este ejemplo hemos creado una aplicación que apunta a un repositorio que crea aplicaciones las cuales apuntan a helm charts oficiales, sin embargo este bucle jerárquico se puede extender mucho mas, siguiendo el «app of apps pattern».

Otra característica interesante de ArgoCD es que nos permite desplegar aplicaciones en distintos clústers. Hay varias maneras de hacerlo, no obstante la más directa es mediante el recurso Application Set.
En su manifiesto podemos especificar una lista de clusters donde desplegar simultáneamente con distintos paths del repositorio. Ya que en nuestro repositorio podemos especificar diferentes versiones para cada clúster.

La relativa facilidad de instalación que tiene ArgoCD supone otro punto positivo a tener en cuenta, aquí puedes consultar los pasos.

Automatización de todo el proceso CICD con Argo

En el caso de querer ir un paso más allá y automatizar todo el proceso de CICD en kubernetes, podemos complementar ArgoCD con el resto de herramientas que presenta el proyecto Argo.
Combinando Argo Events, Argo Workflows, ArgoCD y Argo Rollouts es posible una mayor automatización siguiendo las mejores prácticas en los estándares actuales de integración continua.
Victor Farcic lo explica de manera muy coherente en este video.

Como solución a la complejidad añadida que supone instalar y manejar todas estas herramientas de Argo project, ya han salido al mercado algunas aplicaciones que engloban todo este stack y nos permiten configurar los pipelines para la integración y despliegue des de una capa de mas alto nivel mas simplificada. A continuación mencionamos un par de ellas, aun que en este post no vamos a analizar las funcionalidades particulares.

Devtron es una herramienta open source que instala por debajo todo este paquete de Argo y otras herramientas y promete permitirnos automatizar todo el proceso CICD por completo des de la interfaz gráfica. Devtron simplifica bastante la configuración, ya que interactuamos con las herramientas internas des de una capa de alto nivel. Aunque después de probarlo, no creemos que la herramienta tenga la suficiente madurez como para ser implementada en un entorno productivo, de momento.

Similar al approach de Devtron, Codefresh engloba todas las aplicaciones del stack de Argo para automatizar toda la integración y despliegue. Pero aparte de que la herramienta aún se encuentra en early-access, una gran diferencia es que el acceso a la herramienta será en formato SaaS. Como podemos ver en el apartado de pricing, la opción de automatización completa será de pago y el precio no se menciona en la web.

Conclusiones

ArgoCD es una herramienta muy útil para automatizar el proceso de deploy mediante buenas prácticas GitOps. Gracias a su implementación, los developers pueden probar las nuevas versiones de las aplicaciones más rápidamente y desplegar en producción de forma segura una vez finalizados las pruebas. Además, gracias a la función de auto-sync y su bonita interfaz, ArgoCD nos permite tener controlado en todo momento el estado de las aplicaciones y sus recursos desplegados en Kubernetes. Combinado con las demás herramientas del proyecto Argo podemos automatizar todo el proceso de CICD (y otras muchas utilidades fuera del scope de este post)  siguiendo buenas prácticas para los estándares actuales.

Como punto negativo, usar ArgoCD introducirá una capa extra de complejidad a nuestra configuración, ya que dispone de muchas opciones distintas, introduce «custom objects» y conceptos a los cuales no estamos familiarizados aún. Puede ser «overkill» si tenemos un clúster muy pequeño con solo un puñado de aplicaciones.

La entrada Primeros pasos con ArgoCD se publicó primero en Geko Cloud.

En Geko hemos tenido la (mala) fortuna de pasar por nuestra buena cantidad de respuestas de incidentes de operaciones, sistemas y seguridad. Es algo que pasa de forma inevitable por unas razones que son omnipresentes (en las que entraremos más adelante), y como respuesta proactiva a esto hemos adoptado unas prácticas y hábitos que nos permiten detectar, localizar y resolver incidentes de todo tipo de manera eficiente. Se vuelve una práctica mucho más manejable una vez asumes que van a ocurrir y te preparas para ello. Nunca se puede ser demasiado cuidadoso cuando estás hablando de la infraestructura crítica que tu equipo y tú usáis para trabajar, o el producto al que acceden tus clientes. Es un escenario de “No podemos permitirnos un desastre” y debes estar preparado para ello.

Hay unas contramedidas y comprobaciones que necesitas introducir en tu infraestructura y ecosistema que hace este escenario mucho más fácil de gestionar:

• Una plataforma de monitorización robusta
• Un plan bien diseñado de alertas
• failover de servicios
• snapshots y backups de los datos importantes
• un plan de disaster recovery

Vayamos de uno en uno para definir qué son y por qué son imprescindibles.

¿Cómo sé cuándo falla algo?

El primer paso hacia saber que tu infraestructura está fallando, es saber cómo se ve cuando no está fallando. Necesitas construir un sistema que compruebe constantemente el estado de todas las partes críticas de tu infraestructura, así sabrás cual es su estado normal, y podrás ver cuando se desvía de este estado de funcionamiento correcto. El status drift, si no se vigila, será tu primer paso hacia un estado de fallo: todo funciona bien, luego va fallando poco a poco. Al final llega un día donde tu estado se habrá desviado tanto de su funcionamiento original que tendrás que reconstruirlo todo desde cero. No quieres acabar aquí. Así que para evitarlo, se debe monitorizar anomalías de estado. Si algo se mueve, necesita monitorización. Si algo no se mueve, necesita monitorización por si se mueve.

¿Siento a alguien a mirar métricas?

No sirve de mucho un stack de monitorización si éste no te grita cuando algo va mal. Por lo tanto, a medida que se configura la infraestructura de monitorización, se añaden al mismo tiempo las alertas. La forma de hacerlo depende de la urgencia de la tarea. ¿Es un servidor que tiene el 70% de su disco lleno? quizás vale con que envíe un mensaje de Slack sobre ello a su equipo de TI. ¿Producción no responde a los pings? Probablemente quieras que llame a alguien inmediatamente para que empiece a hacer debugging cuanto antes. Depende de la urgencia del sistema y de lo grande que sea el indicador del problema. Tu entorno, tus prioridades.

¿Pero eso no mantiene el servicio como tal, no?

¿Necesitas una forma de mantener el servicio incluso en caso de fallo? Mantén un sistema de conmutación por error. Tal vez puedas omitir la llamada sobre el servidor que falla, o puedes mover ese ticket de «cambiar el disco duro fallido» hacia abajo en la lista de prioridades porque de momento tienes otra en el RAID. Dos es uno, uno es ninguno. Implementa una conmutación por error en básicamente cualquier cosa importante, incluso si es un sistema de conmutación por error manual. Ten algo preparado para cambiar rápidamente y mantener el servicio.

¿Qué hago cuando me llega una alarma de fallo?

Pongámonos en un escenario de desastre por un momento. Supongamos que has ignorado la alerta S.M.A.R.T. un día más de lo que debías. Tu máquina principal ha caído, no puedes simplemente pulsar el botón de encender para que vuelva a funcionar y olvidarte de ella, y de alguna manera también tenías tu failover en esa misma máquina, por ejemplo un escenario en el que tu máquina proxmox pasa a conocer al creador. Enhorabuena, estás ante un incidente. Así que, para este caso, que sabías que podía ocurrir, has preparado copias de seguridad (espero) y puedes intercambiar esa unidad y restaurarla. Puede que pierdas un día de trabajo, pero no es nada comparado con perderlo todo y pasar cientos de horas reconstruyendo tu empresa desde cero. Es especialmente importante recordar la regla básica de las copias de seguridad, conocida generalmente como la regla 3-2-1:

• 3 copias de tus datos
• En al menos 2 dispositivos diferentes
• 1 de ellos en una localización remota

De este modo, incluso en caso de un incidente especialmente grave, como un incendio, puedes simplemente restaurar a partir de la copia de seguridad externa (aunque eso puede llevar bastante más tiempo dependiendo de tu solución). Además, comprueba que tus copias de seguridad funcionan. Por favor. Una copia de seguridad no es una copia de seguridad hasta que la pruebas.

Como extra, no te marques un Michael Scott con tu equipo.

¿No podemos prepararnos para todo, cierto?

Pueden ocurrir muchas cosas y, por desgracia, no se pueden predecir todas. Puede pasar cualquier cosa y cuanto más compleja sea la configuración de tu infraestructura, más puntos de fallo habrá en ella, así que tienes que prepararte todo lo posible. Tal vez no puedas tener todos los incidentes posibles previstos, pero cuantos más planifiques, mejor, de modo que si ocurre algo, tu personal de guardia pueda simplemente repasar un runbook en tu documentación y solucionar el problema sin mucho escalado. Este plan suele incluir ejemplos de escenarios que consideras posibles en función de la configuración de tu infraestructura, los elementos que se ven afectados y la forma de solucionar el problema.

Suena a que necesito uno de esos planes.

Si un elemento importante de su infraestructura falla, ¿recibirías una llamada, un correo electrónico o una notificación de Slack? ¿Está seguro de que sus copias de seguridad funcionan? ¿Cómo de resistente es tu plataforma a un fallo de disco? Si estos escenarios suenan como un problema en tu caso, tal vez te resulte útil ponerte en contacto con nosotros y hablaremos de cómo ponerlo todo en orden. Sólo tiene que tomar una decisión: ¿lo haces ahora o espera a que se produzca su próximo incidente? Recuerda las palabras de Picard sobre la gestión de incidentes:

La entrada Disaster Recovery: espera lo inesperado se publicó primero en Geko Cloud.

Introducción

En este post vamos a ver cómo solucionar el siguiente error que nos encontramos al trabajar con bases de datos MySQL utilizando el servicio EFS de AWS para el almacenamiento:

ERROR 1030 (HY000) at line 1744: Got error 168 from storage engine

Situación de partida

Nuestro caso de uso consistía en un cluster de Kubernetes EKS, en el que necesitábamos crear y destruir nuevos entornos para desarrollo lo más rápido posible. Cada uno de estos entornos debían contener varias bases de datos MySQL, además de otras herramientas como Redis, RabbitMQ, etc.

Para ello decidimos utilizar Charts de Helm que levantasen estas herramientas como StatefulSets. En un primer momento, no especificamos ningún StorageClass, por lo que se utilizaba la de por defecto de EKS, que levanta volúmenes EBS gp2 (General Purpose SSD) al crear los PersistentVolumeClaims.

El problema de usar volúmenes EBS, es que cada volumen se encuentra disponible en una zona de disponibilidad concreta, por lo que si el cluster de Kubernetes necesita mover un pod de, por ejemplo, MySQL, no podrá levantarlo a no ser que encuentre recursos disponibles en otro nodo worker que este en la misma zona de disponibilidad que dicho volumen EBS.

Por este motivo, decidimos utilizar un nuevo StorageClass que utilizase EFS en lugar de EBS. De esta forma, teniendo el EFS montado en cada nodo worker del cluster de Kubernetes, los pods podían moverse sin ningún problema entre nodos, aunque estos estuviesen en distintas zonas de disponibilidad.

Error con EFS

Dado que nuestro caso de uso requería crear nuevos entornos de la forma mas rápida posible, al levantar una nueva base de datos MySQL, también ejecutábamos un importado de datos a partir de ficheros sql para disponer de un set de datos inicial por defecto.

Fue en este momento en el que empezamos a detectar el error, ya que al importar estos datos iniciales, empezamos a ver de forma continuada el siguiente error en los logs:

ERROR 1030 (HY000) at line 1744: Got error 168 from storage engine
ERROR 1030 (HY000) at line 1744: Got error 168 from storage engine
ERROR 1030 (HY000) at line 1744: Got error 168 from storage engine
...

Este error comenzaba a aparecer a partir de un determinado número de instrucciones sql ejecutadas, y a partir de ese momento, se repetía hasta terminar de leer el fichero sql.

Resolución

Tras realizar una investigación, descubrimos que el problema residía en un límite del servicio EFS. Concretamente era el límite de 256 ficheros únicos bloqueados. Podemos ver este límite en las cuotas descritas en la documentación de AWS:

https://docs.aws.amazon.com/efs/latest/ug/limits.html#limits-client-specific

Debido a que nuestro importado de datos intentaba crear más de 256 tablas, este límite se alcanzaba y comenzaba a aparecer el error. Este límite no puede modificarse, pero pudimos evitarlo modificando los parámetros de MySQL para, en la medida de lo posible, no alcanzar esos 256 ficheros bloqueados.

El parámetro MySQL a modificar es innodb_file_per_table. En nuestras bases de datos MySQL, este parámetro venía activado por defecto. Esto hace que se cree un fichero de datos .idb por cada tabla de la base de datos en lugar de crear un solo fichero de datos. Podemos modificar este parámetro en el fichero de configuración de MySQL de la siguiente forma:

[mysqld]
innodb_file_per_table=OFF

https://dev.mysql.com/doc/refman/5.7/en/innodb-file-per-table-tablespaces.html

Tras desactivar este parámetro, no volvimos a encontrarnos con el error.

Queremos agradecer al blog ops.tips su trabajo realizando el post que os enlazamos, ya que nos ayudó mucho a entender este error, de forma que pudimos encontrar esta solución.

https://ops.tips/blog/limits-aws-efs-nfs-locks/

Conclusión

Al trabajar con bases de datos MySQL usando EFS para el almacenamiento, podemos encontrarnos errores al alcanzar el límite de 256 ficheros bloqueados siempre que tengamos esquemas con gran cantidad de tablas o en definitiva cualquier sistema que requiera bloquear simultáneamente grandes cantidades de ficheros como por ejemplo seria el caso de MongoDB, Oracle, etc.

Para evitar alcanzar ese límite, podemos desactivar el parámetro de MySQL innodb_file_per_table para que no se cree un fichero de datos por cada tabla.

Espero que hayas disfrutado de este post y te animo a que revises nuestro blog para leer otros posts que puedan ser de tu interés. No dudes en contactarnos si deseas que te ayudemos en tus proyectos.

¡Nos vemos en la próxima entrada!

La entrada Error al utilizar AWS EFS para MySQL se publicó primero en Geko Cloud.