Blog de Amazon Web Services (AWS)
Anuncio: Amazon RDS para SQL Server finaliza el soporte para Microsoft SQL Server 2012
Por Bruno Lopes, Sr. Solutions Architect Specialist, Microsoft Workloads en AWS
Lucas Henrique Garcia, Arquiteto de Soluções de SMB en AWS
Luciano Bernardes, Sr. Solutions Architect Specialist, Microsoft Workloads en AWS
Microsoft anunció que terminó el soporte para SQL Server 2012 el 12 de julio de este año (2022). En esa fecha, Microsoft detuvo las actualizaciones críticas de parches para SQL Server 2012. Por lo tanto, le recomendamos fuertemente que actualice sus instancias de base de datos que aún están ejecutando SQL Server 2012 a una versión más reciente lo antes posible para garantizar que sus bases de datos sean más seguras y seguras. Con el fin de minimizar los impactos para nuestros clientes que utilizan SQL Server 2012 en instancias de Amazon RDS, AWS les ha comunicado sobre la terminación del soporte y los horarios de actualización organizados, que están ocurriendo automáticamente y de manera administrada. Si tiene alguna pregunta sobre este proceso, las fechas de actualización enviadas o cualquier otra situación relacionada, comuníquese con el equipo de soporte de AWS a través del enlace al que se hace referencia aquí.
Anuncio del fabricante sobre EOS (Fin de soporte)
Desde el 1 de septiembre de 2021, habíamos desactivado la creación de nuevas instancias de base de datos de Amazon RDS para SQL Server usando Microsoft SQL Server 2012. El 1 de junio de este año (2022), AWS finalizó el soporte para Microsoft SQL Server 2012 en Amazon RDS para SQL Server. A partir de este día, se ha programado que todas las instancias se migren automáticamente a SQL Server 2014 (la última versión menor disponible), como se describe a continuación:
En general, para una instancia de base de datos de SQL Server, hay dos tipos de actualizaciones posibles:
- Actualización de versiones principales (por ejemplo, actualización de SQL Server 2012 a SQL Server 2014)
- Actualización de versión menor (por ejemplo, actualización de SQL Server 2016 RTM a SQL Server 2016 SP1)
Cuando se realizan actualizaciones de este puerto en Amazon RDS, puede programarlas para una versión diferente yendo a la página de modificación de instancias en la consola de administración de AWS y cambiando la versión de la base de datos a la versión deseada. Si elige la opción “Aplicar inmediatamente”, la actualización comenzará inmediatamente después de salir de la página de modificación. Si elige no aplicar el cambio inmediatamente, la actualización se programará durante la siguiente ventana de mantenimiento.
SQL Server 2012 EOS (End of Support)
El fin del soporte para SQL Server 2012 ocurrió el 12 de julio de 2022. Cuando esto sucede, Microsoft deja de proporcionar actualizaciones de seguridad y otros parches, lo que puede dejar a los entornos fuera de los riesgos de cumplimiento y seguridad.
Los clientes que utilicen sus propias licencias de SQL Server, importadas mediante el proceso conocido como Bring Your Own License (BYOL) y que hayan activado Software Assurance (SA) pueden contratar a través de Microsoft para la extensión de actualizaciones de seguridad (ESU). De manera similar, los clientes que utilizan SQL Server 2012 en un modelo con licencia incluida también pueden adquirir esta extensión para obtener los beneficios del soporte extendido en sus instancias EC2 en AWS.
Cabe mencionar que la contratación de la ESU está limitada a tres años, por lo que eventualmente será necesario realizar la actualización para seguir siendo compatible y apoyada por el fabricante.
- El costo de contratar ESU es aproximadamente 75% del valor de la licencia del producto, por año. Para evitar este costo adicional, AWS recomienda las estrategias: Actualizar a alguna versión aún soportada y evitar el costo de contratar ESU;
- Trabajar en la planificación para la modernización y el traslado de estructuras de bases de datos elegibles a soluciones nativas de la nube y/o de código abierto (como Amazon Aurora para PostgreSQL o MySQL), evitando el soporte y los ciclos de bloqueo con el fabricante.
Si opta por la segunda opción, sugerimos leer la solución proporcionada por AWS, conocida como DMA – Amazon Database Migration Accelerator, enfocada en opciones programadas para migraciones de bases de datos con herramientas y expertos en el tema.
Una vez que SQL Server 2012 llegó al fin del soporte, las AMI con licencia incluida para esta versión se han eliminado de la consola de AWS. Sin embargo, los clientes que ya tienen AMIs personalizadas con esta versión aún pueden crear nuevas instancias EC2 si es necesario. Reiteramos la importancia, sin embargo, de que estos ambientes estén aislados, de ser posible, y que se tomen medidas adicionales de seguridad para proteger sus ambientes.
Opciones de upgrade/actualización
En una plataforma autogestionada, la actualización a la última versión de la base de datos tiene asociados riesgos, a menudo relacionados con la falta de documentación del entorno y las complejidades de los prerrequisitos de migración, que a menudo son realizados por equipos alejados de DBA y SysAdmins. Sabemos que, por diversas razones, varias empresas viven de acuerdo con la frase “Si no se rompe, no le muevan”. Afortunadamente, muchos de los desafíos que normalmente enfrenta en una plataforma autogestionada se mitigan mediante automatizaciones como las ofertas de Amazon RDS.
Apoyamos varias combinaciones diferentes de versión principal/menor de SQL Server. Estas instancias de base de datos se pueden actualizar directamente a la última versión menor de SQL Server 2014, 2016, 2017 y 2019. Para obtener más información sobre la actualización, consulte el documento en este enlace.
Aún puede restaurar una instantánea de una base de datos de SQL Server 2012 en cualquier instancia compatible con la versión mayor en Amazon RDS SQL Server, incluso después de que se haya retirado la versión 2012. Para obtener más información sobre cómo restaurar una base de datos en RDS, consulte la documentación aquí. Para problemas de migración técnica y ayudas puntuales, así como cualquier pregunta o inquietud sobre este proceso, puede obtener ayuda con el equipo experto de AWS Premium Support.
Como probar y actualizar una instancia en Amazon RDS for SQL Server
En primer lugar, independientemente de la plataforma o garantías que ofrezca cualquier servicio, recomendamos planificar los cambios de acuerdo a las políticas de su empresa; y que las pruebas se realicen en entornos no productivos antes de que los cambios se ejecuten en sus datos de producción. El proceso de prueba se puede simplificar enormemente en entornos de Amazon RDS gracias a las automatizaciones disponibles, lo que refuerza aún más nuestras recomendaciones. Con Amazon RDS, puede realizar sus pruebas a través de la consola de administración de AWS, la CLI de AWS o la API de RDS. Por simplicidad, usaremos la consola para actualizar nuestra base de datos en el siguiente ejemplo.
- Primero, debemos crear un snapshot
-
- En la consola, escoja la instancia que desee actualizar y enseguida seleccione Take a DB Snapshot en el área de acciones.
- Restaurar un snapshot:
-
-
-
-
- Cuando la instantánea esté completa, elija la instantánea y vaya a Restaurar instantánea en Acciones
- Para fines de prueba, recomendamos mantener todas las especificaciones de las instancias iguales. Si es necesario, puede modificarlos cuando actualice su instancia.
-
-
-
3. Ejecute una actualización en su snapshot:
-
-
- Cuando la instantánea esté completa, elija la instantánea y vaya a Restaurar instantánea en Acciones
- Para fines de prueba, recomendamos mantener todas las especificaciones de las instancias iguales. Si es necesario, puede modificarlos cuando actualice su instancia.
- En Instancias, elija la instantánea restaurada y elija Modificar en Acciones. Al modificar una instancia de base de datos, puede realizar algunas actualizaciones diferentes más allá de la versión del motor de base de datos, incluidas las siguientes:
- Clase de instancia de BBDD: cambia la clase de instancia para cumplir con los requisitos de computación o memoria.
- Tipo de almacenamiento: puede cambiar el tipo de almacenamiento de IOPS aprovisionadas o de uso general, según sus necesidades.
- Monitoreo mejorado: se recomienda habilitar el monitoreo avanzado para instancias de producción.
-
4. Elija la versión del motor de base de datos a la que desea actualizar. En este caso, elegimos SQL Server 2016.
Asegúrese de elegir Aplicar inmediatamente. De lo contrario, su instancia no se actualizará hasta la ventana de mantenimiento especificada.
Antes de actualizar tu instancia, es importante tener en cuenta algunos elementos. Mencionemos a continuación una lista con elementos importantes a considerar:
Trabajando con instancias Multi-AZ
Cuando actualiza una instancia Multi-AZ, RDS realiza primero la actualización en la instancia secundaria. Una vez finalizado el proceso, se ejecutará un failover y se realizarán actualizaciones en el nodo primario. Debido a que la actualización de su base de datos puede restablecerla a su configuración predeterminada, algunas personalizaciones pueden perderse.
La mejor práctica para ayudar a reducir el riesgo de estas configuraciones personalizadas es degradar primero su instancia Multi-AZ a Single-AZ. Luego vuelve a aplicar Multi-AZ para asegurarse de que el secundario tenga la configuración más reciente de la primaria.
Cabe destacar que al realizar este cambio, el nodo secundario necesitará un cierto periodo de tiempo para copiar completamente los datos a sus volúmenes de EBS. Aunque los volúmenes están disponibles de inmediato, para que su instancia se desempeñe como se esperaba, deberá esperar hasta que el volumen se “caliente” por completo. Por esta razón, al realizar el proceso de conversión entre Single-AZ y Multi-AZ, recomendamos que este cambio se realice de tres a cuatro días antes de la actualización de la versión de SQL Server. Esta vez le dará al nodo secundario más tiempo para sincronizar los datos antes de que ocurra la conmutación por error y se haga cargo del rol de la instancia primaria.
Otro punto importante a considerar es que no se puede replicar la base de datos Tempdb en instancias Multi-AZ. Todos los datos que almacenas en tus instancias primarias en Tempdb no están disponibles en tus instancias secundarias. Durante una actualización, esta característica puede causar problemas a las aplicaciones porque Tempbb intenta registrarse automáticamente en función de la actividad de la aplicación.
Para mitigar este impacto, usted tiene 2 opciones:
-
- Utilice el método mencionado anteriormente para modificar su instancia de base de datos y desactivar Multi-AZ. Después modifique Tempdb y finalmente vuelva a habilitar Multi-AZ nuevamente. Este método no requiere tiempo de inactividad.
- Modificar Tempdb en la instancia primaria original, luego la conmutación por error manualmente y modificar Tempdb en la nueva instancia primaria. Este método implica tiempo de inactividad.
Otros temas relevantes durante el proceso de actualización son los siguientes:
IOPS aprovisionadas – Supongamos que su instancia está en Single-AZ y que planea cambiar a Multi-AZ para un tiempo de inactividad mínimo antes de actualizar. En este caso, si está utilizando IOPS aprovisionadas en Single-AZ y ya está cerca del máximo de E/S, le recomendamos duplicar su capacidad de E/S en el escenario Multi-AZ. Recomendamos esto porque tu instancia secundaria necesita recursos adicionales para no afectar el rendimiento de la primaria. Debido a que las actualizaciones a Multi-AZ requieren conmutación por error, una cantidad inadecuada de E/S puede prolongar los tiempos de conmutación por error. La recuperación de bases de datos requiere mayores tasas de E/S
Compatibilidad con bases de datos de SQL Server – Mantener la compatibilidad con versiones anteriores de SQL Server durante la actualización, establezca el nivel de compatibilidad para la versión de SQL Server que usa actualmente. Para obtener comandos y una descripción general de la compatibilidad, consulte ALTER BASE DE DATOS (Transact-SQL) Compatibility Level en la documentación de SQL Server. Si no cambia la compatibilidad de la base de datos, no podrá utilizar nuevas funciones en la versión actualizada. Al realizar una actualización, el propio RDS no cambia el nivel de compatibilidad de la base de datos.
Options Group – Si su instancia de base de datos utiliza un Options Group personalizado, en algunos casos Amazon RDS no podrá asignar automáticamente a su instancia de base de datos nuevos Options Group. Por ejemplo, este es el caso cuando actualiza a una nueva versión principal. En este caso, debe especificar un nuevo Options Group al actualizar. Le recomendamos que cree un Options Group y le agregue las mismas opciones que en sus Options Group personalizados existentes. Para obtener más información, consulte Creación de Options Group o Creación de una copia de Options Group en la documentación de Amazon RDS.
Parameter Groups — Si su instancia de base de datos utiliza un grupo de parámetros personalizado, en algunos casos Amazon RDS no puede asignar automáticamente a su instancia de base de datos un nuevo grupo de parámetros. Por ejemplo, este es el caso cuando actualiza a una nueva versión principal. En este caso, debe especificar un nuevo grupo de parámetros al actualizar. Le recomendamos que cree un nuevo grupo de parámetros y configure los parámetros como en el grupo de parámetros personalizados existente. Para obtener más información, consulte Crear un grupo de parámetros de base de datos o Copiar un grupo de parámetros de base de datos en la documentación de RDS
Migrando hacia SQL Server — Ofrecemos una variedad de diferentes métodos de migración a Amazon RDS para SQL Server que se pueden encontrar en la documentación. Además, se pueden encontrar guías específicas en otras publicaciones del blog de AWS, como restauraciones de backup nativas, replicación continua con AWS DMS y replicación transaccional. También tenemos documentación completa sobre migraciones de bases de datos SQL Server en nuestra sección titulada AWS Prescriptive Guidance — SQL Database Migrations.
Incluso si SQL Server 2012 ya no es compatible, aún puede migrar su base de datos local y levantar y cambiar a RDS. Nosotros manejamos la actualización en base a la instancia de SQL Server que aprovisionamos, como se describe en la documentación de RDS
Conclusión
La información contenida en este blog fue organizada para promover el conocimiento sobre el fin del soporte para SQL Server 2012 por parte del fabricante, y recomendar acciones que ayuden a eludir escenarios de incumplimiento y brechas de seguridad por falta de actualizaciones. Reiteramos la importancia de actualizar SQL Server 2012 a una versión superior y comenzar a planificar escenarios de modernización.
Acerca de los autores
Bruno Lopes es arquitecto de soluciones sénior en el equipo de AWS LATAM. Lleva más de 14 años trabajando con soluciones de TI, teniendo en su cartera numerosas experiencias en cargas de trabajo de Microsoft, entornos híbridos y capacitación técnica de clientes como Technical Trainer y Evangelista. Ahora actúa como arquitecto de soluciones, combinando todas las capacidades para reducir la burocracia en la adopción de las mejores tecnologías con el fin de ayudar a los clientes en sus desafíos diarios.
Lucas Henrique Garcia es arquitecto de soluciones para el equipo de pequeñas y medianas empresas y anteriormente trabajó en el equipo de AWS Premium Support en Dublín. Se centra en ayudar a los clientes de AWS a resolver sus problemas y diseñar arquitecturas para su empresa.
Luciano Bernardes trabaja actualmente como Sr. Arquitecto de Soluciones en AWS y se especializa en cargas de trabajo de Microsoft. Con 15 años de experiencia en el mercado, trabajó principalmente en consultoría técnica especializada en Microsoft, en clientes de varios mercados verticales, con demandas centradas en la infraestructura local y en la nube. Como PSA, trabaja en estrecha colaboración con clientes y socios consultores en LATAM para apoyarlos en la toma de decisiones y la revisión de la arquitectura de las cargas de trabajo de Microsoft en la nube de AWS.
Revisor
JuanMa Silva quien es arquitecto de soluciones con especialidad en Microsoft para México y MCO. Cuenta con 15 años de experiencia en la industria de IT, en posiciones de Sysadmin, consultor para ayudar a migrar clientes a la nube y modernización de aplicaciones, soporte aplicaciones de misión critica basados en tecnologia Microsoft.