En esta publicación, se mostrará cómo disminuir de la versión Enterprise de SQL Server a la versión estándar en instancias de Amazon Elastic Compute Cloud (EC2), ayudando así a reducir costos. Esto es necesario cuando no se está utilizando ninguna de las funciones de la versión Enterprise. Para identificar qué características, de dicha versión, se están usando en su entorno, se puede basar en el siguiente diagrama de flujo.
Diagrama de flujo para identificar las funciones de edición Enterprise más utilizadas
También puede determinar si la instancia de SQL Service está utilizando funciones de la versión Enterprise con ayuda de este script.
Proceso de manual de cambio de versiones desde SQL Server Enterprise Edition:
Puede disminuir la versión de SQL Server de forma manual siguiendo estos pasos. Hay que alertar que esta es una operación que hace que la instancia queda fuera de funcionamiento por un momento.
- Debe verificar que se tenga una copia de seguridad completa de todas las bases de datos de usuarios y sistemas relacionados.
- Debe tomar nota de las características de la versión menor actual de SQL Server, incluyendo Service Pack, Actualizaciones Acumulativas (CU) y la versión de distribución general (GDR).
- Debe desacoplar todas las bases de datos de usuarios.
- Detenga SQL Server, posterior a esto copie los archivos de datos y de registro de la base de datos del sistema (master, model, msdb) en la carpeta de backup local.
- Desinstale SQL Server versiónEnterprise incluyendo todos los componentes.
- Reinicie el Servidor.
- Instale ahora la versión apropiada a su caso de uso de SQL Server. Los cuales pueden ser SQL Server estándar o SQL Server Developer.
- Instale los mismos Service Packs y Actualizaciones acumulativas (CU) que se tenían antes de la operación de desinstalación.
- Debe detener el servicio SQL Server y reemplazar las bases de datos master, model y msdb con las copias de seguridad que se realizaron en el paso 4.
- Inicie el servicio SQL Server y adjunte de nuevo los archivos mdf y ldf de la base de datos de usuarios a la instancia de SQL Server que fueron desacoplado en el paso 3.
Proceso automatizado de cambio de versioón desde SQL Server Enterprise Edition:
En esta sección, se explicara como tomar ventaja del servicio de AWS Systems Manager (SSM) para cambiar la versión de SQL Server Enterprise Edition a una más básica. Esto porque SSM Document proporciona una forma sencilla y segura de ejecutar comandos de forma remota o ejecutar scripts sobre instancias EC2 o servidores locales.
Hay que aclarar que esto solo aplica para casos de uso donde se pueda traer una licencia propia (BYOL).
Figura 1: Cambio de versión SQL Enterprise mediante SSM
Prerrequisitos
- Una instancia de Windows de Amazon EC2 con la edición SQL Server Enterprise instalada.
- Un bucket de Amazon Simple Storage Service (S3) para almacenar los medios de instalación, la actualización acumulativa (CU) a la fecha y el archivo de configuración para instalar SQL Server estándar.
- Las instancias EC2 dónde va a hacer el proceso de cambio de versión deben tener acceso al bucket S3 para descargar los medios de instalación.
- Asi mismo, el agente de AWS Systems Manager debe instalarse en dicha(s) instancia(s).
- Accseso a SQL Server Management Studio con conexión a instancia EC2 de SQL Server que está degradando.
- Recuerde verificar la versión actual de SQL Server, ejecutando el comando select @@version para cargar las actualizaciones acumulativas (CU) y Service Pack al bucket S3.
- Un rol de IAM asociado a la instancia de Amazon EC2 con una política que permita la acción de lectura sobre AWS Secrets Manager.
Para utilizar el servicio de AWS Systems Manager con instancias de EC2, se deben tener en cuenta los requisitos previos. El más importante de ellos, es tener el agente de AWS Systems Manager (agente SSM) instalado en las instancias. Este agente se instala de forma predeterminada en las instancias EC2 de Windows Server 2016, las creadas a partir de Windows Server 2003-2012 R2 y las que tengan Imagénes (AMI) publicadas en noviembre de 2016 o posterior.
Otro de los requisitos es asignar un rol de AWS Identity and Access Management (IAM). El rol de IAM se utiliza para declarar los permisos necesarios para comunicarse con la API de Systems Manager. Hay que destacar que el rol de IAM se puede asignar a EC2 en el momento de su creación o también ,se pueden agregar roles a las instancias existentes mediante AWS Console o AWS CLI.
Pequeña guía
En AWS es posible tener instancias que ejecutan las siguientes versiones y/o ediciones de Microsoft SQL Server.
Estándar: Esta edición permite la administración de bases de datos con recursos de TI mínimos, con una oferta limitada de funciones y falta de algunas características de alta disponibilidad y operaciones DDL en línea, en comparación con la edición Enterprise. La edición estándar tiene una limitación en 24 núcleos y 128GB de memoria.
Enterprise: Esta es la edición más completa de todas. Con esta edición, tiene todas las características sin limitación de CPU y memoria y se utiliza para cargas de trabajo de misión crítica.
Desarrollador: SQL Server Developer edition incluye todas las funcionalidades de Enterprise Edition pero solo es para ser utilizada para entornos que no son de producción.
Los siguientes pasos muestran cómo cambiar desde la edición de SQL Server Enterprise a otras versiones más básicas, mientras se mantienen los objetos del sistema como inicios de sesión y servidores vinculados en la base de datos maestra. Hay que tener en cuenta que se debe planificar el tiempo de inactividad, ya que este proceso deja la instancia fuera de servicio.
Aquí están los pasos realizados por el Documento SSM.
- Este genera copias de seguridad completas de los sistemas y bases de datos de usuarios de la edición existente de SQL Server Enterprise.
- Detiene los servicios de SQL Server.
- Copia archivos de base de datos físicos master, model y msdb a la carpeta de Backup.
- Desinstala el software Enterprise Edition.
- Instala la versión SQL Server Standard o SQL Server Developer.
- Instala la actualización acumulativa (CU) o el Service Pack basado en los archivos de parches proporcionados en la ubicación S3.
- Adjunta las bases de datos de usuarios de SQL Server de Enterprise Edition a las nuevas, que pueden estar en versión Standard o Developer.
- Detiene los servicios de SQL Server.
- Reemplaza los nuevos archivos de base de datos master, model y msdb con la copia de seguridad de estos, que fueron tomados en el paso 3.
- Inicia los servicios de SQL Server.
Para este ejercicio, utilizaremos un documento SSM personalizado para realizar la degradación de la edición Enterprise.
Crear un documento SSM personalizado:
Por favor, encuentre instrucciones detalladas para crear un documento SSM personalizado.
Primeri, debe descargar SQLServerEditionDowngrade.ps este sirve como código fuente para el documento personalizado que se puede implementar mediante la característica de Run Command de SSM. El script de PowerShell mediante el documento personalizado tomará una copia de seguridad de todas las bases de datos de usuarios, desinstalará Enterprise edition, luego instalará la nueva edición de SQL Server, también adjuntará todas las bases de datos de usuarios, por último, reemplazará la base de datos master y msdb usando los archivos de base de datos de los que se hizo una copia de seguridad anteriormente.
Figura 2: Contenido del documento de AWS SSM
Para instalar SQL Server, Systems Manager se necesita acceso a SQL Server Media y ConfigurationFile.Ini el que se recomienda almacenar en un bucket de S3. En este ejemplo, el archivo ConfigurationFile.ini se carga en el bucket S3 para su posterior invocación. Se pueden editar las cuentas de servicio, las contraseñas en el archivo de configuración de este ejemplo en función de su entorno y se puede cargar el archivo en el mismo bucket S3.
Se inicia sesión en la consola de administración de AWS. Se debe confirmar que las instancias tienen el estado para ser administradas, se pueden enumerar en la consola de Systems Manager en el Panel de control de EC2 o en la opción de Instancias administradas. En la Figura 3 se puede ver un ejemplo de cómo se presentan los nodos gestionados de Systems Manager.
Figura 3: Nodos administrados de AWS SSM
Se requieren 7 parámetros de entrada, como se muestra en la Figura 4.
InstanceID: instancia EC2 de destino en la que se requiere cambiar la versión desde SQL Server Enterprise. Se puede seleccionar usando un sistema que selecciona instancias de forma interactiva de la lista de todas las instancias administradas por Systems Manager.
BackupLocation: Esta es la ubicación donde residen las copias de seguridad de bases de datos, por ejemplo D:\MSSQL\Backup.
EditionDowngradeUser: Hace referencia a un secreto de AWS Secrets Manager que almacena el usuario y la contraseña de Windows AD. Este tiene permisos de administrador en la instancia EC2 y el rol de administrador del sistema para SQL Server. Por ejemplo, dominio\ sqladmin.
S3bucketName: Es el nombre del bucket S3 donde se almancena el medio de instalación SQL Standard y ConfigurationFile.Ini que instalará el SQL Server. e.g. sqlbackup.
S3CUNName: Nombre del archivo de Actualización Acumulativa (CU).
SaPwdSecret: Contraseña de cuenta “sa” de SQL Server si se trata de instalación en modo de Autenticación Mixta, esta permite la autenticación mediante Windows y SQL Server.
Figura 4: Parámetros del documento AWS SSM
SSM document parameters are stored in AWS Secrets Manager and AWS Param
Los parámetros del documento de SSM se almacenan en AWS Secrets Manager y AWS Parameter Store.
Como se muestra en la Figura 5, la contraseña de usuario de Windows AD y la contraseña SA se almacenan en AWS Secrets Manager. Para mayor detalle, puede leer en AWS Secrets Manager como crear un secretos.
Figura 5: Secretos almacenados en AWS Secrets Manager
Como se muestra en la Figura 6, los parámetros restantes del documento se almacenan en AWS Systems Manager Parameter Store. Obtenga mayor información en Parameter Store.
Figura 6: Parámetros almacenados en el almacén de parámetros de AWS Systems Manager
En el bucket S3, debe almacenarse la información siguiendo la estructura de carpetas como se muestra en la Figura 7. En la primera CU/ se almacenan las actualizaciones acumulativas o Service Packs , en la segunda, SQLInstall/ se almacena el formato montado de los binarios de la edición estándar de SQL Server.
Figura 7: Estructura de carpeta de cubeta S3
Podemos ejecutar el documento SSM desde AWS Management Console o a través de CLI.
Figura 8: Ejecutar documento SSM
La automatización creará 3 archivos de registro en la carpeta C:\Windows\temp en la instancia EC2 de SQL Server. Se puede ver la salida del proceso en cada paso.
Aquí está la lista de comprobación que el Documento de SSM debe validar antes de la desinstalación, si uno de los ítems falla, se reportará un error. Esta prueba debe ser exitosa.
- SQL Server debe estár instalado.
- Sólo se debe instalar una instancia de SQL Server. Si hay varias instancias de SQL Server instaladas en la instancia EC2, no continuará.
- Verifica si la edición de SQL Server es Enterprise.
- Si SQL Server se está ejecutando.
- No deben haber un proceso de reinicio u operación de cambio de nombre de archivo en plena ejecución.
- SQL Server, en este caso, debe ser independiente. Si SQL Server forma parte de la agrupación en clústeres o parte de los grupos Always on Availability, o si también hace parte de un SQL Server Clustering o configuración de HADR, el script arrojará un error.
Una vez que se termina de validar, de forma completa, los puntos de la anterior lista de verificación se da luz verde para que la automatización comience a realizar copias de seguridad de todas las bases de datos de usuarios y sistemas en BackupLocation en función del parámetro de entrada. Se debe tener espacio disponible tal que abarque todas las copias de seguridad completas de la base de datos. Esto es, tener espacio libre equivalente al tamaño total de todas las bases de datos. Si falla la copia de seguridad para alguna base de datos, el Documento SSM dejará de ejecutarse, dará un aviso de error y no será posible el cambio de versión de SQL Server.
Una vez que se complete la copia de seguridad de todas las bases de datos, se generará un archivo de script que tiene comandos TSQL para adjuntar las bases de datos de usuario después de la finalización del cambio de versión. Este almacenará este archivo en la misma ubicación donde se almacenaron las copias de seguridad. Como siguiente paso, el script detendrá el servicio SQL Server, copiará los archivos master físico y msdb a la carpeta de respaldo.
Como se muestra en la Figura 9, la carpeta almacena copias de seguridad de bases de datos de usuarios, archivos de base de datos del sistema y scripts adjuntos.
Figura 9: Contenido de la carpeta de respaldo
El siguiente paso, el script de automatización comenzará a desinstalar SQL Server, incluyendo otros componentes de SQL Server que están instalados en el servidor como SSIS, SSAS, SSRS, etc. Una vez completada la desinstalación, el siguiente paso es instalar la versión de SQL Server estándar o de desarrollador.
Para instalar la versión de SQL Server estándar, se necesita acceso a los medios de instalación de SQL Server. Para esta demostración los medios de instalación de SQL se almacenan en el bucket S3 desde el cual la instancia EC2 tiene acceso para descargar dichos medios. La instalación de SQL se realizará usando el ConfigurationFile.ini, este archivo tiene la información sobre los parámetros y características requeridas para la instalación de SQL Server.
El script descarga automáticamente los archivos desde S3 e inicia la instalación de SQL Server. Una vez que SQL Server se haya instalado correctamente, buscará Actualizaciones Acumulativas para instalar. Al finalizar la actualización acumulativa, el script continúa adjuntando bases de datos de usuario, master y msdb. Como se muestra en la Figura 10, podemos encontrar el estado de esta automatización en AWS Systems Manager >Automatización.
Figura 10: Estado de ejecución de documentos SSM
Active un escritorio remoto en la instancia EC2 de SQL Server para verificar la edición de SQL Server y los archivos de registro. Los archivos de registro se pueden encontrar en C:\Windows\Temp.
La Figura 11 muestra un ejemplo de archivo de registro.
Figura 11: Registro de automatización de degradación de SQL
A continuación, se valida que los servicios SQL se están ejecutando y que es posible conectarse a la instancia de SQL Server a través de SQL Server Management Studio, aquí debe escribir el comando @ @version para verificar si la edición esta actualizada, en este caso se observa que la versión es SQL Server estándar, como se muestra en la Figura 12,.
Figura 12: Validación de la versión de SQL Server
Una vez que haya comprobado la versión, se pueden eliminar los archivos descargados de S3, los archivos de registro generados por SSM Documents y los archivos de bases de datos del sistema SQL Server que ahora son obsoletos, como se muestra en la Figura 13.
Figura 13: Archivos obsoletos de bases de datos del sistema
Conclusión
En esta publicación, se presentó cómo usar el servicio de AWS SSM para cambiar de versión desde SQL Server Enterprise a versión estándar. A muchos de nuestros clientes les gustaría cambiar entre versiones para ahorrar costos. Puede usar el mismo documento de SSM para cambiar versiones desde SQL Server Enterprise Edition a cualquier edición inferior proporcionando los medios de instalación de SQL Server adecuados en el bucket S3.
Para las instancias incluidas con licencia de AWS, cambiar la edición de SQL Server en la instancia no cambiará la facturación asociada a la AMI. Debe migrar sus bases de datos a una nueva instancia EC2 con una AMI que ejecute la nueva edición de SQL Server y hacer una actualización lado a lado.
Para obtener más información, consulte Prácticas recomendadas para implementar Microsoft SQL Server en Amazon EC2.