Blog de Amazon Web Services (AWS)

Migrando una base de datos SQL Server de varios TB a Amazon RDS Custom para SQL Server mediante Amazon S3 y Amazon EBS

Por Jose Amado-Blanco, Priya Nair, e Suprith Krishnappa C

Esta es la primera de una serie de publicaciones de dos partes sobre cómo migrar una base de datos de varios Terabytes (TB) a Amazon Relational Database Services (Amazon RDS) Custom for SQL Server.

Amazon RDS Custom para SQL Server es un servicio gestionado de base de datos que automatiza la configuración, el funcionamiento, las copias de seguridad, la alta disponibilidad y el escalado de las bases de datos, al mismo tiempo que otorga acceso a la base de datos y al sistema operativo (SO) subyacente. El administrador de la base de datos puede usar este acceso para habilitar funciones nativas, como SQL Common Language Runtime (CLR), configurar los ajustes del SO e instalar los drivers, a fin de migrar aplicaciones antiguas, personalizadas y empaquetadas.

Visión general

Amazon RDS Custom para SQL Server tiene una unidad de datos predeterminada (D:) que permite hasta 16 TB de almacenamiento. Para obtener información sobre las restricciones de almacenamiento de Amazon RDS Custom para SQL Server y sobre cómo ajustar el almacenamiento, consulte Modificación del almacenamiento de una instancia de base de datos personalizada de RDS para SQL Server.

Un desafío habitual a los que se enfrentan los clientes al migrar a Amazon RDS Custom para SQL Server es cuando el tamaño de la base de datos más los archivos de respaldo (backup) superan los 16 TB. En esta publicación, le mostramos cómo migrar correctamente una base de datos de varios TB mediante Amazon Simple Storage Service (Amazon S3) y Amazon Elastic Block Store (Amazon EBS).

Evite el sobreaprovisionamiento del almacenamiento

Usted también puede utilizar este enfoque para migrar una base de datos de varios TB, incluso si la suma de la base de datos y sus archivos de respaldo es inferior a 16 TB. Esto evita el sobreaprovisionamiento del almacenamiento y reduce los costes, ya que puede recuperar el espacio de los archivos de respaldo después de la restauración de la base de datos.

Por ejemplo, si tiene una base de datos de 10 TB y los archivos de respaldo suman 5 TB, es posible aprovisionar un Amazon RDS Custom para SQL Server con 15 TB asignados. A continuación, puede copiar los archivos de respaldo a la unidad D: y restaurar la base de datos. Sin embargo, elegir ese enfoque implicaría un coste mayor, ya que no puede recuperar los 5 TB de almacenamiento asignados a los archivos de  respaldo. Esto implica que usted pagará por 5 TB que no se estén utilizando. El importe de esos costes se puede calcular con la calculadora de precios de AWS.

La siguiente tabla muestra la diferencia actual en el costo de almacenamiento de un Amazon RDS Custom para SQL Server en la región us-east-1:

Costo de almacenamiento personalizado de SQL Server en RDS (Single-AZ)
SSD IOPS aprovisionado (io1)
IOPS de aprovisionamiento: 1000
Cantidad de almacenamiento Coste mensual
10 TB 1.277,60$
15 TB 1.866,40$

Descripción general de la solución

Uno de los métodos para migrar una base de datos local de SQL Server de varios TB a Amazon RDS Custom para SQL Server consiste en utilizar Amazon S3 File Gateway y un volumen de EBS opcional. Amazon S3 File Gateway ofrece una forma sencilla de almacenar datos y realizar copias de seguridad en la nube. Una vez configurado, los usuarios pueden acceder a los datos almacenados en Amazon S3 desde su sistema de archivos local. Usamos un bucket de S3 para almacenar los archivos de respaldo locales y un volumen de EBS como almacenamiento provisional para Amazon RDS Custom para SQL Server.

No debe alojar los archivos de bases de datos en el volumen adicional de EBS para evitar que RDS Custom para SQL Server pase a un estado de configuración no compatible. Para obtener más información sobre el perímetro de soporte personalizado de RDS y la supervisión de la configuración no compatible, consulte el enlace del perímetro de soporte personalizado de RDS y las configuraciones no compatibles.

El siguiente es un diagrama de arquitectura a alto nivel de la migración.

El flujo de trabajo a alto nivel es:

  1. Realice una copia de seguridad de la base de datos local de SQL Server directamente en el recurso compartido de archivos de S3 File Gateway.
  2. Añada un volumen de EBS opcional a Amazon RDS Custom para SQL Server.
  3. Descargue los archivos de respaldo de S3 File Gateway al volumen de EBS.
  4. Restaure el archivo de copia de seguridad en Amazon RDS Custom para SQL Server.
  5. Extraiga el volumen de EBS.

Prerrequisitos

Suponemos que tiene los siguientes pre-requisitos:

Como esta solución implica la configuración y el uso de los recursos de AWS, generará costes en su cuenta. Consulte los precios de AWS para obtener más información. Le recomendamos encarecidamente que lo configure en una instancia que no sea de producción y que ejecute validaciones de principio a fin antes de implementar esta solución en un entorno de producción.

Realice una copia de seguridad de la base de datos local de SQL Server en el recurso compartido de archivos de S3 File Gateway

Hacemos copias de seguridad de nuestra enorme base de datos local en varios archivos de respaldo para aumentar el rendimiento y mantener cada archivo con un tamaño inferior a 5 TB debido a las limitaciones de tamaño de los objetos de S3.

En nuestro ejemplo, hacemos una copia de seguridad en los siguientes archivos:

  • SampleTest_FullBackupCompressed01.bak
  • SampleTest_FullBackupCompressed02.bak
  • SampleTest_FullBackupCompressed03.bak
  • SampleTest_FullBackupCompressed04.bak

Añada un volumen de EBS opcional a Amazon RDS Custom para SQL Server

Cree un volumen de almacenamiento lo suficientemente grande como para contener los archivos de respaldo y asegúrese de que esté en la misma zona de disponibilidad (AZ) que la base de datos RDS Custom para SQL Server.

Si su RDS Custom para SQL Server se desplegó en un Single-AZ, cree el volumen de EBS en la misma zona de disponibilidad que el RDS Custom.

Si su RDS Custom para SQL Server se desplegó en multiples zonas de disponibilidad (Multi-AZ), siga estos pasos para determinar en qué zona de disponibilidad se ejecuta el RDS Custom, (también se puede utilizar para implementaciones Single-AZ):

  1. Recupere el endpoint de RDS Custom para SQL Server mediante el CLI de AWS. El endpoint aparecerá en “Endpoint”/”Address”, como se muestra a continuación:
aws rds describe-db-instances --db-instance-identifier <INSTANCE_NAME> --region <REGION>

En nuestro ejemplo:

aws rds describe-db-instances --db-instance-identifier rdscustommultitb --region us-east-1

El endpoint también se encuentra en la consola de AWS RDS, en la pestaña “Connectivity & security» tras seleccionar la instancia de base de datos.

  1. Recupere la dirección IP de RDS Custom para SQL Server. Desde un servidor que tenga acceso a RDS Custom (puede que necesite un servidor bastión si el RDS se creó en una subred privada, tal como se sugiere en las prácticas recomendadas), ejecute el siguiente comando:
nslookup <RDSEndpoint>

En nuestro ejemplo:

nslookup rdscustommultitb.<address>.us-east-1.rds.amazonaws.com

  1. Compare la dirección IP recuperada con la dirección de los 2 intancias EC2 creadas para el RDS Custom para SQL Server para determinar cuál es el EC2 activo y, por lo tanto, poder determinar la zona de disponibilidad en la que se ejecuta. En esta publicación se asume que la base de datos RDS Custom para SQL Server se creó en la Zona de Disponibilidad us-east-1a.

Puede utilizar la consola de AWS o el CLI de AWS para crear el volumen de EBS. Para obtener instrucciones paso a paso, consulte Crear un volumen vacío.

  1. En la consola de Amazon EBS, cree su volumen. Para esta publicación, agregamos la etiqueta con el nombre rdscustombackupstorage a nuestro volumen de EBS.

Para crear un volumen de EBS mediante el CLI de AWS, ejecute un comando en PowerShell similar al siguiente:

aws ec2 create-volume --volume-type gp3 --size 6000 --iops 3000 --throughput 125 --availability-zone us-east-1a --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=rdscustombackupstorage}]'

Cuando el volumen de almacenamiento esté disponible, deberá adjuntarlo a la instancia de RDS Custom para SQL Server.

  1. Seleccione el volumen de EBS que ha creado y, en el menú Actions, elija Attach volume.

  1. Elija la instancia de RDS Custom for SQL Server.
  2. Seleccione adjuntar volumen con la opción Attach volumen.

Para adjuntar un volumen de EBS a la instancia mediante el CLI de AWS, ejecute un comando en PowerShell similar al siguiente:

aws ec2 attach-volume --volume-id vol-<volumeid> --instance-id i-<instanceid> --device /dev/sdf

Tras adjuntar un volumen EBS a la instancia, se expone como un dispositivo de bloque y aparece como un disco extraíble en Windows.

  1. Puede formatear el volumen con cualquier sistema de ficheros y, a continuación, montarlo.

Como el volumen de EBS es superior a 2 TiB, debe utilizar un esquema de particionamiento GPT para acceder a todo el volumen. Consulte Acerca de los estilos de partición: GPT y MBR para obtener información sobre las particiones GPT y MBR.

  1. Para que el volumen de EBS esté disponible para su uso, debe iniciar una conexion RDP en la instancia de RDS Custom. Consulte Conectarse a su instancia de base de datos personalizada de RDS mediante RDP para ver los pasos detallados.
  2. Tras realizar la conexión con RDP a su instancia de RDS Custom para SQL Server, puede conectar el disco mediante PowerShell, la herramienta de línea de comandos DiskPart o la utilidad de administración de discos. Para obtener más información, consulte Hacer que un volumen de Amazon EBS esté disponible para su uso en Windows.

En nuestro ejemplo, utilizamos la utilidad Administración de discos.

Después de inicializar el disco, debe crear un volumen y asignarle una letra de unidad.

  1. Haga clic con el botón derecho en el espacio no asignado y seleccione Nuevo volumen simple (New Simple Volume en inglés).

  1. Seleccione Siguiente (Next) en la página de bienvenida.
  2. Defina el nuevo tamaño del volumen y, a continuación, seleccione Siguiente (Next).

  1. Asigne una letra de unidad y, a continuación, seleccione Siguiente (Next).

  1. Formatee la partición y, a continuación, seleccione Siguiente (Next).

  1. Revisa la configuración y selecciona Finalizar (Finish).

Asegúrese de que la unidad E: esté disponible a través del explorador de archivos o mediante la utilidad de administración de discos.

Para que un volumen EBS con particiones raw esté disponible para su uso con Windows mediante PowerShell, ejecute un comando similar al siguiente:

Stop-Service -Name ShellHWDetection

Get-Disk | Where PartitionStyle -eq 'raw' | Initialize-Disk -PartitionStyle GPT -PassThru | New-Partition -AssignDriveLetter  -UseMaximumSize | Format-Volume -FileSystem NTFS -NewFileSystemLabel "E" -Confirm:$false

Start-Service -Name ShellHWDetection

Descargue los archivos de respaldo de S3 File Gateway al volumen de EBS

Cuando el disco esté en línea (online) y disponible para su uso, transfiera las copias de seguridad del bucket de S3 al nuevo volumen EBS tras instalar el CLI de AWS. Consulte Migrar SQL Server local a Amazon RDS Custom para SQL Server mediante copias de seguridad y restauración nativas y Amazon S3 para conocer los permisos necesarios para descargar los archivos de respaldo de Amazon S3 a Amazon RDS Custom para SQL Server.

Ejecute los siguientes comandos en la instancia de RDS Custom para SQL Server de destino para descargar todos los archivos de respaldo a la carpeta Backup creada en la unidad E::

aws s3 cp s3://multitbrdscustom/SampleTest_FullBackupCompressed01.bak E:\BACKUP 
aws s3 cp s3://multitbrdscustom/SampleTest_FullBackupCompressed02.bak E:\BACKUP 
aws s3 cp s3://multitbrdscustom/SampleTest_FullBackupCompressed03.bak E:\BACKUP 
aws s3 cp s3://multitbrdscustom/SampleTest_FullBackupCompressed04.bak E:\BACKUP

Restaure el archivo de copia de seguridad en Amazon RDS Custom para SQL Server

Tras descargar todos los archivos de respaldo, utilice el siguiente comando nativo de SQL Server para restaurar la base de datos, apuntando al volumen de EBS agregado y a la ubicación de los archivos de respaldo (en nuestro caso, E:\Backup). Los archivos de la base de datos deben estar en D:\rdsdbdata\DATA

UTILICE [master]  RESTORE DATABASE [SampleTest] FROM  DISK = N' E:\Backup\SampleTest_FullBackupCompressed01.bak ', DISK = N' E:\Backup\SampleTest_FullBackupCompressed02.bak',  DISK = N' E:\Backup\SampleTest_FullBackupCompressed03.bak ',  DISK = N''  CON FILE = 1,  MUEVA N' sampleTest_data001' A N' sampleTest_Data002',  MUEVA N' SampleTest_Data003' A N   E:\Backup\SampleTest_FullBackupCompressed04.bak D:\rdsdbdata\DATA\SampleTest_Data001.mdf D:\rdsdbdata\DATA\SampleTest_Data002.ndf 'D:\rdsdbdata\DATA\SampleTest_Data003.ndf',  MOVER N' SampleTest_Data004' A N' D:\rdsdbdata\DATA\SampleTest_Data004.ndf ', MOVER N' SampleTest_Data005' A N' D:\rdsdbdata\DATA\SampleTest_Data005.ndf', MOVER N' SampleTest_Data006' A N ',  MOVER N' SampleTest_Data008' A N' D:\rdsdbdata\DATA\SampleTest_Data008.ndf', MOVER N' SampleTest_Data008' A N' ',  MOVER N' SampleTest_Data008' _data009' A' N ', MOVER     D:\rdsdbdata\DATA\SampleTest_Data006.ndf D:\rdsdbdata\DATA\SampleTest_Data007.ndf D:\rdsdbdata\DATA\SampleTest_Data009.ndf N'sampleTest_Data010' A N' D:\rdsdbdata\DATA\SampleTest_Data010.ndf ', MOVER N' SampleTest_Data011' A N' D:\rdsdbdata\DATA\SampleTest_Data011.ndf', MOVER N' SampleTest_Data012' A N' D:\rdsdbdata\DATA\SampleTest_Data012.ndf ',  MOVER N'SampleTest_data013' A N' SampleTest_Data014', MOVER N' SampleTest_Data014' A N' 286',  MOVER N'sampleTest_Data014' PARA N' D:\rdsdbdata\DATA\SampleTest_Data015.ndf ', MUEVA N' SampleTest_Data016' A N' 1234     D:\rdsdbdata\DATA\SampleTest_Data013.ndf D:\rdsdbdata\DATA\SampleTest_Data014.ndf D:\rdsdbdata\DATA\SampleTest_ Data016.ndf',  MUEVA 'SampleTest_log01' A N' D:\rdsdbdata\DATA\SampleTest_Log01.ldf ', NOUNLOAD, STATS = 5 GB

Además, el uso de opciones de copia de seguridad avanzadas como BLOCKSIZE, MAXTRANSFERSIZE y BUFFERCOUNT puede aumentar considerablemente el rendimiento de las copias de seguridad y la restauración

Elimine el volumen de EBS

Una vez restaurada la base de datos, si ya no piensa utilizar el volumen, asegúrese primero de desmontar y separar el volumen de la instancia de EC2 y, a continuación, de eliminarlo para evitar costes adicionales.

Para desmontar el volumen:

  1. Inicie la utilidad de administración de discos.
    • (Windows Server 2012 y versiones posteriores) En la barra de tareas, haga clic con el botón derecho en el logotipo de Windows y seleccione Administración de discos.
    • Windows Server 2008) Elija Inicio, Herramientas administrativas, Administración de equipos, Administración de discos.
  2. Haga clic con el botón secundario en el disco y, a continuación, seleccione Offline. Espere a que el estado del disco cambie a offline antes de abrir la consola de Amazon EC2.

Separe el volumen

Puede utilizar la consola de AWS para separar el volumen. Seleccione el volumen, haga clic en Acciones (Actions) y seleccione Separar volumen (Detach volumen).

Para separar un volumen EBS mediante el CLI de AWS, ejecute un comando similar al siguiente en Powershell:

aws ec2 detach-volume --volume-id vol-<volumeid>

Eliminar el volumen

Puede utilizar la consola de AWS para eliminar el volumen. Seleccione el volumen, haga clic en Acciones y seleccione Eliminar volumen.

Para eliminar un volumen de EBS mediante la CLI de AWS, ejecute un comando similar al siguiente en Powershell:

aws ec2 delete-volume --volume-id vol-<volumeid>

Resumen

En esta publicación, mostramos cómo migrar correctamente una base de datos cuando el tamaño total de la base de datos y la copia de seguridad superan los 16 TB. Este método también le permite evitar el aprovisionamiento excesivo del almacenamiento para Amazon RDS Custom para SQL Server y, al mismo tiempo, transferir bases de datos muy grandes, lo que reduce los costes.

En la segunda parte de esta serie, le mostraremos cómo migrar una base de datos de SQL Server de varios TB a Amazon RDS Custom para SQL Server mediante Amazon FSX para Windows File Server para almacenar los archivos de respaldo.

 

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

 


Acerca de los autores

Jose Amado-Blanco es Consultor Senior en migración de bases de datos con más de 25 años de experiencia trabajando con AWS Professional Services. Jose ayuda a nuestros clientes en su proceso de migración y modernización de sus soluciones de bases de datos locales a AWS.

 

 

 

 

Priya Nair es consultora de bases de datos en AWS. Tiene más de 18 años de experiencia trabajando con diferentes tecnologías de bases de datos. Priya trabaja como especialista en migración de bases de datos para ayudar a los clientes de Amazon a trasladar su entorno de bases de datos locales a las soluciones de bases de datos en la nube de AWS.

 

 

 

 

Suprith Krishnappa C es consultor de bases de datos del equipo de Servicios Profesionales de Amazon Web Services. Suprith trabaja con clientes empresariales, ofreciendo soporte técnico y diseñando soluciones para clientes en proyectos de bases de datos, además de ayudarlos a migrar y modernizar sus bases de datos existentes a la nube de AWS.

 

 

 

 

Revisores

Borja Prado es Senior Solutions Architect en AWS, especializado en modernización de aplicaciones y tecnologías Microsoft. Trabaja ayudando a nuestros clientes en la migración, despliegue y modernización de cargas de trabajo Windows en AWS. Además, está especializado en el diseño e implementación de soluciones escalables con .NET.

 

 

 

 

Marcos Freccia es arquitecto sénior de bases de datos en migraciones de bases de datos para el equipo de AWS ProServe. Ha apoyado y capacitado a clientes en su viaje para migrar y modernizar sus soluciones de bases de datos de centros de datos on-premise a AWS.