Blog de Amazon Web Services (AWS)

Consideraciones fundamentales al migrar hacia Graviton 2 para Bases de Datos Amazon RDS y Amazon Aurora.

Por Reagan Rosario y Tyler Lynch Arquitectos de Soluciones enfocados en Educación

 

Amazon Relational Database Service (Amazon RDS) y Amazon Aurora admiten una multitud de tipos de instancias que le permitirán escalar las cargas de trabajo de su base de datos según sus necesidades (consulte Clases de instancia de Base de Datos de Amazon RDS  y clases de instancia de base de datos Aurora, respectivamente).

En 2020, AWS anunció los tipos de instancia Amazon M6g y R6g para Amazon RDS y recientemente anunció la disponibilidad general del tipo de instancia R6g para Aurora con tecnología de procesadores AWS Graviton2, que ofrece una mejor relación costo-rendimiento en comparación con sus contrapartes x86.

Los procesadores Graviton2 son personalizados por AWS utilizando núcleos Arm Neoverse de 64 bits y ofrecen varias optimizaciones sobre los procesadores AWS Graviton de primera generación. Es posible lanzar nuevas instancias de base de datos Graviton2 M6g y R6g a través de la consola de Amazon RDS o la interfaz de línea de comandos de AWS (AWS CLI). interfaz de línea de comandos de AWS (AWS CLI). Es posible mover bases de datos Multi-AZ a Graviton2 con un tiempo de inactividad mínimo, suspendiendo las entradas y salidas mientras dure la conmutación por error.

En esta publicación, analizamos las consideraciones clave al modificar las instancias de base de datos RDS y Aurora existentes a tipos de instancias basadas en Graviton2. Discutimos los requisitos previos y las diferentes estrategias que puede tomar para reducir el tiempo de inactividad.

 

¿Por qué cambiar a Graviton2?

Las siguientes son algunas de las razones para cambiar a Graviton2 para Amazon RDS y Amazon Aurora:

  • Las instancias de Graviton2 proporcionan hasta un 52% de mejora de precio / rendimiento  para bases de datos de código abierto RDS según el motor de la base de datos, la versión y la carga de trabajo. También proporcionan hasta un 35% de mejora de precio / rendimiento para Aurora según el tamaño de la base de datos.
  • Las instancias de Graviton2 brindan siete veces el rendimiento, cuatro veces la cantidad de núcleos de cómputo, cachés privados dos veces más grandes por núcleo, memoria cinco veces más rápida y un rendimiento de punto flotante por núcleo dos veces más rápido que los procesadores AWS Graviton de primera generación.
  • Los procesadores Graviton2 cuentan con memoria DDR4 totalmente encriptada y siempre activa y un rendimiento de encriptación por núcleo un 50% más rápido.
  • No se requieren cambios de código ni portabilidad al migrar de instancias de Intel a Graviton2 en Amazon RDS y Aurora.

 

Visión General de la Solución

Los pasos que se deben seguir para modificar el tipo de instancia son similares para Amazon RDS para MySQL, Amazon RDS para PostgreSQL  Amazon RDS para MariaDB  y Aurora MySQL  y Aurora PostgreSQL.

Para esta publicación, se considera el caso de uso de un clúster de base de datos Aurora Multi-AZ en PostgreSQL versión 9.6.16 con tres instancias: un escritor y dos lectores.

Como práctica  general, se recomienda probar el proceso en un entorno que no sea productivo. Es apropiado comenzar utilizando un Snapshot de la base de datos de producción, y restaurarla en una instancia  del entorno  no productivo, que tenga una configuración similar (clase de instancia, configuración de parámetros, cifrado) como la instancia de producción actual. Luego, modificar la instancia no productiva a Graviton2, seguido de pruebas de validación para asegurar que todo esté configurado y funcionando según las expectativas.

Los pasos de alto nivel en el proceso son los siguientes:

1. Actualizar la base de datos (si es necesario):

a. Determinar si la versión actual de la base de datos cumple con la versión mínima requerida para pasar a Graviton2.

b. Actualizar el motor de la base de datos a la versión mínima requerida.

2. Modificar los tipos de instancia:

a. Determinar la estrategia y el orden de modificación de las instancias.

b. Modificar la clase de la instancia apropiada de Graviton2.

3. Validar y confirmar que la aplicación funciona correctamente.

4. Revertir a la versión anterior (en caso de ser necesario).

 

Actualizar la base de datos

Este es un paso opcional y solo se requiere si la versión actual de la base de datos no cumple con la versión mínima requerida para pasar a Graviton2, por lo que inicia con la determinación de la versión de la base de datos.

 

Determinar la versión de la base de datos

La siguiente tabla muestra las versiones compatibles para Graviton2 a partir de esta publicación; son las versiones de la base de datos que fueron compiladas o desarrolladas y probadas para ser compatibles con Graviton2.

 

A MySQL PostgreSQL MariaDB
1 Amazon RDS 8.0.17 & superior 13, 12.3 y superior 10.5, 10.4.13 y superior
2 Amazon Aurora 2.09.2 y superior 12.4 y superior y versiones 11.9 y superior —-

 

Para el Caso de Uso de esta publicación, se usa Aurora PostgreSQL versión 9.6.16, que es menor que la versión requerida para pasar a Graviton2.

Las últimas actualizaciones de esta información, se pueden obtener en Motores de base de datos admitidos para clases de instancia de base de datos (Amazon RDS) y motores de base de datos compatibles para clases de instancia de base de datos (Aurora).

Si la base de datos no tiene una versión compatible con Graviton2, se debe actualizar a una versión compatible. Para obtener una lista de todos los destinos de actualización válidos para una versión de origen actual, se debe usar el comando  describe-db-engine-versions en el CLI.

Para el caso de Linux, macOS o Unix, se debe usar el siguiente comando:

aws rds describe-db-engine-versions --engine aurora-
postgresql --engine-version 9.6.16 --query 
'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`]'

Para Windows, se debe usar el siguiente comando:

aws rds describe-db-engine-versions --engine aurora-
postgresql --engine-version 9.6.16 --query 
"DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgra
de == `true`]"

La siguiente captura de pantalla muestra el resultado del comando anterior en un sistema operativo basado en Linux, y muestra el valor de la matriz ValidUpgradeTarget que contiene las versiones de destino.

 

Si el valor de IsMajorVersionUpgrade es verdadero, se puede realizar una actualización principal de la versión EngineVersion asociada. Si la matriz está vacía, no es posible realizar una actualización mayor de la versión. Primero se debe actualizar a una versión secundaria que tenga una ruta de actualización de la versión principal.

 

Actualizar la base de datos a la versión mínima requerida

En algunos casos, no existe una ruta de actualización directa de la versión actual de la base de datos a una versión mínima de la base de datos compatible con Graviton2. Para el Caso de Uso en de esta publicación, se cuenta con la versión 9.6.16 de Aurora PostgreSQL, y la versión mínima admitida para Graviton2 es 11.9. No hay una ruta de actualización directa de 9.6 a 11.9, por lo que primero se debe actualizar de 9.6.16 a 10.14 y sólo luego a 11.9. Así que este es un proceso de actualización de dos pasos.

Para Amazon RDS, se puede seguir los pasos siguientes para actualizar la versión del motor de la base de datos:

Para Aurora, se puede seguir los pasos siguientes para actualizar la versión del motor de la su base de datos:

Durante la actualización, es posible realizar una actualización directamente sobre la base de datos, lo que requiere tiempo de inactividad. Si se desea minimizar el tiempo de inactividad, se puede seguir un enfoque alternativo de usar AWS Database Migration Service (AWS DMS). Para obtener más información,  sobre cómo lograr un tiempo de inactividad mínimo para las principales actualizaciones de versiones en Amazon Aurora para PostgreSQL puede consultar AWS DMS.

 

Modificar las instancias

Para modificar las instancias, se deben seguir los siguientes pasos de alto nivel:

  • Determinar la estrategia y el orden de modificación de las instancias.
  • Modificar la clase de apropiada de Graviton2.

Determinar la estrategia

La estrategia para modificar los tipos de instancias depende de la configuración que se tenga, como Multi-AZ o réplicas de lectura.

Para Amazon RDS con Multi-AZ, toda la modificación de la instancia se realiza en la instancia secundaria, después de lo cual se realiza la conmutación por error. Luego, los pasos de modificación se repiten en la nueva instancia secundaria (anterior primaria). La duración del tiempo de inactividad planificado se limita solo al tiempo de conmutación por error. Los tiempos de conmutación por error suelen ser de 60 a 120 segundos. Una instancia Single-AZ no está disponible durante la modificación del tipo de instancia.

Para Aurora con una o más réplicas, cuando se modifica la instancia de escritura, una réplica de Aurora se promueve a la instancia principal mientras continúa la modificación en la nueva réplica de Aurora. Hay una breve interrupción que normalmente dura menos de 120 segundos. Para minimizar el riesgo y el tiempo de inactividad, primero se puede modificar la instancia en la réplica de Aurora, validar que funcione según las expectativas y luego conmutar por error al lector Graviton2 actual. Dentro del clúster de Aurora, es posible modificar sus instancias a Graviton2 en cualquier orden que sea adecuado para el Caso de Uso.

También es posible mezclar y combinar instancias de Graviton2 R6g e Intel R5 dentro del mismo clúster para su la instancia principal o para la réplica de lectura, lo que permite maximizar las mejoras de precio / rendimiento según los requisitos de la carga de trabajo.

Un cambio de tipo de instancia significa una reubicación de la instancia a otro host de hardware, lo que significa que no se mantiene el caché del búfer. Por lo tanto, cuando se reinicia la base de datos de la instancia modificada, el caché del búfer está frío y las consultas iniciales pueden demorar más.

Como práctica recomendada general, se puede tomar un Snapshot manual antes de la modificación para garantizar una restitución fácil. Para Amazon RDS en una configuración Single-AZ, esto da como resultado la suspensión de la E/S durante el tiempo del Snapshot, desde unos pocos segundos hasta unos minutos, según el tamaño. En una configuración Multi-AZ, no hay suspensión de E/S durante el Snapshot. Para Aurora, no se produce ningún impacto en el rendimiento ni interrupción del servicio de la base de datos.

Es una buena idea planificar el cambio durante el período de mantenimiento de Amazon RDS según la programación. Esta ventana de mantenimiento semanal permite aplicar los cambios del sistema. Se puede pensar en la ventana de mantenimiento como una oportunidad para controlar el momento de modificaciones y parches de software, en caso de que se soliciten o requieran.

Para el Caso de Uso en esta publicación, se empieza por mover una instancia de lector Aurora a Graviton2 y luego se ejecutan validaciones en ella para asegurar que funcione correctamente. Se modifica el tipo de instancia de lector a Graviton2, para luego conmutar a este nuevo lector de Graviton2 y se promueve a la instancia de escritor. El proceso de conmutación por error tarda unos segundos en completarse.

Modificar el tipo de instancias

Se debe iniciar una sesión en la consola de Amazon RDS. Primero se modifica la clase de instancia en una réplica de lectura.

1. Dentro de la consola de Amazon RDS, en el panel de navegación, elegir Bases de Datos.
2. Seleccionar la instancia del lector (para esta publicación, se usa auroralab-pgsql-node-3) y elija * Modificar 

 

 

  1. Para Tamaño de clase de instancia de base de datos (DB instance class size), seleccionar Clases de memoria optimizada (Memory Optimized classes).
  2. Elegir la clase de instancia; para esta publicación, se ha elegido r6g.large(la «g» significa Graviton2).

 

 

5. Elegir Continuar.

6. En la página de resumen, revisar los cambios.

7. Para aplicar el cambio inmediatamente, seleccionar Aplicar inmediatamente (Apply immediately). Si no se aplica el cambio de inmediato, el cambio queda programado para que ocurra durante el período de mantenimiento preferido que se definió. Elegir Aplicar inmediatamente puede provocar una interrupción en algunos casos.

8.Elegir Modificar instancia de base de datos (Modify DB Instance).

 

 

La instancia comenzará a modificarse.

 

 

Para el Caso de Uso de esta publicación, el tiempo de modificación de la instancia de réplica de lectura tomó unos minutos. Mientras se modifica esta instancia, la instancia de escritura y otra instancia de lectura están abiertas para atender las solicitudes de la aplicación. No se ha demostrado que el tamaño del conjunto de datos o el estado de cifrado de la base de datos afecte el tiempo necesario para la modificación de la clase de instancia.

La siguiente captura de pantalla muestra que un escritor y un lector están en db.r5 large (x86) y un lector está en una instancia db.r6g.large (Graviton2).

 

 

Ahora se cambia el escritor al nuevo lector db.r6g.large. Cada réplica de lectura está asociada a un nivel de prioridad. En el caso de una conmutación por error, Amazon RDS promueve la réplica de lectura que tiene la prioridad más alta (el nivel con el número más bajo). Si dos o más réplicas tienen la misma prioridad, Amazon RDS promociona la que tiene el mismo tamaño que la instancia principal anterior. Antes de fallar, debemos asegurarnos de que la prioridad de conmutación por error del lector db.r6g.large sea mayor que la del otro lector. De forma predeterminada, ambos están en el tier-1, por lo que debemos elegir el lector auroralab-pgsql-node-2 y cambiar la configuración a tier-2.

9. Seleccionar la instancia auroralab-pgsql-node-2y Modificar.

10. Para la Prioridad de conmutación por falla (Failover priority), elegir tier-2.

 

 

11. Elegir Continuar.

12. Elegir Modificar la Instancia de Base de Datos (Modify DB Instance).

 

 Realizar la Conmutación por falla.

Elegir la instancia de escritura auroralab-pgsql-node-1 y en el menú de Acción elegir Conmutación por falla (Failover).

 

 

Las aplicaciones experimentan una interrupción mínima del servicio si se conectan mediante el endpoint del Clúster (recomendado) en lugar de los endpoints de la base de datos, y si se implementa la lógica de reintento de conexión. Durante la conmutación por error, AWS modifica el DNS del punto de enlace del clúster para señalar la instancia de base de datos recién creada o promovida. Después del cambio, tendrá una instancia habilitada para escritura ejecutándose en Graviton2.

 

 

Para minimizar las interrupciones del servicio y hacer que las aplicaciones sean más resistentes, también se puede utilizar el proxy de Amazon RDS. Para reducir aún más el tiempo de conmutación por error, se puede configurar una configuración activa de TCP agresiva y una configuración de conexión JDBC o la clase PGConn en el nivel de la aplicación. Para obtener más información, consultar Prácticas recomendadas con Amazon Aurora PostgreSQL.

 

Validar y confirmar que la aplicación funciona correctamente

Ahora se puede validar que su la aplicación funciona correctamente con las bases de datos RDS o Aurora basadas en Graviton2. Si se tiene Performance Insights habilitado, se puede usar el panel de Performance Insights para visualizar la carga de la base de datos y filtrar la carga por esperas, comandos SQL, hosts o usuarios. Después de un período de prueba (probablemente un par de días o según su nivel de comodidad), se puede cambiar el resto de las instancias de lectura a Graviton2 y eliminar el Snapshot creado antes del cambio.

 

Revertir a la versión anterior

Con cualquier cambio, es importante tener una estrategia de retroceso (o de alternativa) en caso de que los cambios no funcionen como se esperaba. A un alto nivel, se tienen algunas opciones:

  • Siel clúster tiene un lector x86, se puede conmutar por error a una instancia x86 en el clúster cambiando la prioridad de la conmutación por error.
  • También se tiene la opción de volver a cambiar el tipo de instancia a un tipo de instancia x86 siguiendo un proceso similar al que se presentó anteriormente en la publicación.

 

Resumen

Esta publicación proporcionó instrucciones paso a paso para modificar sus instancias de Aurora PostgreSQL a Graviton2, junto con algunas de las consideraciones clave para minimizar el tiempo de inactividad.  Es posible seguir pasos similares para modificar instancias de RDS a Graviton2. También se presentó brevemente el proceso de actualización de la base de datos en caso de no contarse con la versión mínima requerida para Graviton2.

Como práctica recomendada, se deben probar siempre los cambios en entornos de Prueba, o Control de Calidad incluyendo las extensiones de base de datos existentes, y que los ambientes sean similares al  entorno de producción en términos de configuración y volumen.

 

Recursos adicionales

 

Este artículo fue traducido del Blog de AWS en Inglés

 

Sobre los Autores:

Reagan Rosario es un Arquitecto de Soluciones enfocado en educación. Le gusta ayudar a sus clientes construir soluciones escalables, disponibles y seguras en la nube de AWS.

 

 

 

 

Tyler Lynch es un Arquitecto Sr. de Soluciones enfocado en Educación en AWS; su pasión es el aprendizaje continuo.

 

 

 

 

Revisores:

Miriam Alonso es actualmente Technical Program Manager en el equipo de Envision Engineering para América Latina, en donde es responsable por la generación de pipeline de prototipos para las regiones de Mexico y MCO norte. Miriam cuenta con más de 16 años de experiencia lidereando proyectos de tecnología e innovación y forma parte de AWS desde agosto de 2019. Miriam es parte del Cost Optimization Squad en México (Escuadrón de Optimización de Costos) desde 2019.

 

 

 

Javier Huerta es Arquitecto de Soluciones especializado en Mejores Prácticas (Well-Architected) para Latinoamérica. Está enfocado en habilitar a nuestros socios de negocio y clientes a realizar revisiones sobre sus cargas de trabajo, priorizar hallazgos de alto impacto, y llevar a cabo remediaciones sobre los 5 pilares de la metodología. Es también miembro de la Comunidad Técnica de Campo (TFC) de Media y Entretenimiento. Por el momento, está en cuarentena en la Ciudad de México, planeando lo primero que hará en cuanto pueda salir nuevamente.

 

 

 

Javier Vallejo es Senior Manager para el area de Arquitectura de Soluciones de AWS México, con más de 20 años de experiencia en la industria de TI liderando equipos por mas de 12 años en la entrega de soluciones para diversas industrias y clientes.

 

 

 

Enrique Valladares Es Senior Manager para el área de Arquitectura de Soluciones para el sector Enterprise de México en AWS. Actualmente soporta con su equipo más de 500 clientes en su jornada de adopción de la nube. Tiene 20 años de experiencia en diseño, implementación y auditoría de sistemas distribuidos de software y ha trabajado con implementaciones de Cómputo en la nube desde 2005.