DoubleTake SQL Move

En el artículo anterior os enseñe como migrar sql usando Microsoft Data Migration. Hoy os voy a enseñar como migrar sql usando DoubleTake SQL Move, un producto que sirve para la migración y actualización de datos SQL en caliente con solo un pequeño corte de servicio para realizar el cambio de servidor. Este producto es ideal para entornos de alta criticidad donde el tiempo es oro. Comencemos…

Si no leíste el artículo sobre como preparar una migración, te recomiendo que lo leas antes de continuar.

DoubleTake SQL Move

DoubleTake SQL Move es un producto que esta integrado dentro del producto DoubleTake Availability o DoubleTake Move.

La ventaja principal de Move frente a Availability es la licencia. Tiene una duración determinada y por lo tanto es mucho más económica.

Nota: Como no es posible usar Double-Take Move en una versión trial, en mis laboratorios voy a usar Double-Take Availability.

Esta compuesto por un conjunto de scripts escritos en PowerShell que funcionan junto con DoubleTake.

Preparación del entorno

Antes de llevar a cabo la migración debemos preparar el entorno para garantizar su correcta ejecución.

Como requisito tanto en el servidor o servidores de origen y destino instalaremos la versión correspondiente de DoubleTake que vayamos a usar y nos cercioraremos que todos los servidores tengan PowerShell 3.0 como mínimo.

El servidor que ejecuta SQLMove requiere tener instaladas la características SMO y CLR Types incluidas en las SQL Server 2014 Features Pack.

A continuación deberemos descargar, descomprimir y copiar SQLMove, el conjunto de scripts que usaremos para migrar.

Servidor ORIGEN
  1. Abre una ventana de PowerShell con permisos de administrador.
  2. Navega hasta la carpeta que contenga tu SQLMove
  3. Comprueba la versión de Powershell ejecutando:
  4. Habilita la administración remota:
  5. Comprueba la versión de SQL que quieres migrar:
  6. Desbloquea el contenido de la carpeta SQLMove:
  7. Establece la política de PowerShell sin restricciones para poder ejecutar scripts nos firmados:
  8. Abre SQL Management y habilita la conexión de administración remota mediante esta consulta:

En caso de disponer un clúster repite este proceso en todos los nodos.

Servidor DESTINO

Apoyándote en los pasos anteriores sigue estas instrucciones:

  1. Abre una ventana de PowerShell con permisos de administrador.
  2. Navega hasta la carpeta que contenga tu SQLMove.
  3. Comprueba la versión de Powershell.
  4. Habilita la administración remota.
  5. Comprueba la versión de SQL que tienes instalada.
  6. Desbloquea el contenido de la carpeta SQLMove:
  7. Establece la política de PowerShell sin restricciones para poder ejecutar scripts no firmados.
  8. Comprueba la conexión remota hacia todos tus servidores origen con el siguiente comando:
  9. Abre SQL Management y habilita la conexión ad administración remota.Check_SQLMove_Target

Nota: SQL01 y SQL02 son los nombres de los nodos que conforman mi clúster. En tu caso debe ser reemplazado por el nombre de tus equipos.

Credenciales

Para poder ejecutar el script de migración necesitamos almacenar unas credenciales con permisos de Administrador de SQL.

Para este proceso tenemos que tener en cuenta si las dos instalaciones usan las mismas credenciales o no. En caso de que usen credenciales distintas deberemos generar un archivo xml que almacene las credenciales de origen y otro para las de destino usando nombres de fichero diferentes con el siguiente comando:

Nota: El archivo puede contener el nombre que queramos, pero tiene que ser copiado en todas las carpetas SQLMove, tanto en origen como en destino. En mi caso, tanto mi origen como destino usan las mismas.

Llegados a este punto tenemos que planear como queremos hacer la migración, ya que la herramienta permite varios métodos de personalización; desde el cambio de directorios en el servidor de destino, la copia de datos no SQL o la especificación de cambio de nombre de DNS para mantener las cadenas originales. Este último sólo es válido para servidores STANDALONE. En caso de tener un clúster, el cambio de nombre se debe realizar de forma manual.

En mi ejemplo voy a usar el archivo de opciones que permite cambiar la ruta de destino JobOptions_Sample___Change_Target_Path.xml para mis únicas dos bbdd, aunque depende de como se configure se puede hacer para toda una instancia entera. Recomiendo leerse la guía de usuario o bien los ejemplo que vienen en la misma carpeta SQLMove.

Configuración de JobOptions

En este fichero de opciones se pueden copiar datos desde el contenido de todo un directorio hasta de bbdd específicas. Lo único que se tiene que tener en cuenta es añadir un path de transformación con su etiqueta de origen y final <d4p1:PathTransformation> </d4p1:PathTransformation> tal y como muestra el ejemplo.

En este caso, el ejemplo copia los archivos mdf de las bbdd especificadas y contenidas en la unidad K a otro directorio y unidad E en el nuevo servidor. Con los archivos ldf ocurre lo mismos. Si no quisiéramos especificar todas las bbdd tendríamos que especificar solo la ruta origen que contiene los datos y la ruta destino donde se almacenarán.

Una vez tengamos el archivo preparado, tenemos que renombrarlo a jobOptions.xml y copiarlo en todos nuestros servidores origen y destino dentro de su carpeta SQLMove.

Replicación de datos

En esta sección voy a explicar como realizar la replicación de nuestras bbdd, las cuales podremos seguir usando sin perder ni un solo dato en nuestros servidores actuales. Sino lo tienes abierto ya, en el servidor de destino, abre una consola de PowerShell, navega hasta el directorio de SQLMove y ejecuta:

A continuación explico los modificadores del cmdlet, en los que debes especificar los valores de tu entorno:

  • -Source: Nombre de tu SQL o Rol SQL en caso de ser un clúster de tu servidor origen.
  • -Target: Nombre de tu SQL o Rol SQL en caso de ser un clúster de tu servidor destino.
  • -SourceDtCredsFile: Especifica el archivo de credenciales para tu servidor origen.
  • -TargetDtCredsFile: Especifica el archivo de credenciales para tu servidor destino.
  • -DatabasesOnly: Especifica que solo quieres migrar bbdd, en caso de instancias completas consulta la documentación.
  • -IncludeDatabases: Especifica las bbdd de datos que se quieren migrar. Sino se especifican se migran todas.
  • -SourceInstance: Nombre de la instancia SQL del servidor origen.
  • -TargetInstance: Nombre de la instancia SQL del servidor destino.
  • -JobOptionsFile: Ruta donde se encuentra el fichero JobOptions.xml.

Cuando ejecutes el comando te saldrá una casilla para especificar los DNS, si como yo, tienes un clúster tendrás que cancelarla para proseguir con la ejecución. Normalmente tras un rato suele preguntarte si quieres seguir con la creación del job porque te avisa de que se han encontrado unas advertencias. Revisa la documentación para ver si es algo grave (a mi normalmente siempre me sale “RegQueryValueEx() returned error 2” que no es nada grave, más bien informativo). Pulsa la tecla Y para continuar con la creación del job hasta que se complete el trabajo.

Creacion_Job_SQLMove

Comprobación del trabajo

Para comprobar si se ha creado el trabajo y cual es su estado tenemos que seguir estos pasos:

  1. Importa los cmdlets de DoubleTake en PowerShell:
  2. Ejecuta una consulta para conocer el ID del trabajo que hay en ejecución. SQL, es el nombre del host de destino.

     

    Consulta_Job_SQLMove

  3. Abre Double-Take Console
  4. Agrega tu servidor origen y destino pulsando sobre el enlace Add servers to your consoleAdd_Servers_DoubleTake_Console
  5. Rellena el campo Server con el nombre de tu host, username con tu usuario y password con tu contraseña y pulsa Add. Repite estos pasos con todos tus servidores origen y destino.Pulsa OK cuando termines.Insert_Servers_DoubleTake_Console
  6. Selecciona tu servidor origen, pulsa botón derecho y selecciona View Replication Service Details.Vista_replicacion_SQLMove
  7. En el submenú Connections, selecciona el trabajo Files and Folders. Desde este menú podrás consultar el estado de la replica.Estado_Replica_SQLMove
Failover Test

El Failover Test sirve para levantar las bbdd en el nuevo servidor de producción sin alterar el estado de la original. De esta forma podemos comprobar si las bbdd funcionan en el nuevo entorno sin perder conexión con las originales. Para realizar un failover test sigue estos pasos:

Desde la misma consola PowerShell que has ejecutado la replicación, ejecuta:

 

  • -Cutover: Es el parametro que se usar para levantar las bbdd en destino, cuidado con el porque depende de como se usa migra o hace un failover.
  • -DeleteJobAfterCutover: Elimina el trabajo de replicación una vez ejecuta el comando que lo contenga. En caso de continuar con la migración después del Failover Test deberíamos ejecutar otra vez la replicación.
  • -KeepSourceOnline: Este es el más importante. Si este parámetro no está se hace una migración, no un Failover.

TestFailover_SQLMove

En la consola SQL Management Studio del servidor destino puedes ver las bbdd migradas y en funcionamiento.

Resultado_FailoverTest_SQLMove

En este punto te recomiendo hacer test con una aplicación de prueba a la que puedas cambiarle la cadena de conexión o por ejemplo probar tu herramienta de backup y restore si el entorno es nuevo.

Cuando termines las pruebas, tienes que seguir estos pasos para dejarlo listo para la migración:

  1. Realizar un Deattach de todas las bbdd.
  2. Lanzar otra vez la replicación.
Migrar con DoubleTake SQLMove

Esta parte varia un poco a la del Failover. Como diferencia principal, la ejecución del cutover pone en estado offline las bbdd de tu servidor origen y las levanta en tu servidor destino. Para realizar la migración ejecuta:

Como puedes ver los parametros son los mismos al Failover Test pero sin el parametro -KeepSourceOnline.

SQL migrado con DoubleTake SQLMove

Si la cosa va correctamente, las bbdd de origen se quedarán en modo offline. Si no se diera el caso, cortad la conexión de vuestras aplicaciones para que no puedan conectar a la bbdd antigua.

Ya solo nos faltaría el cambio de nombre de los servidores origen y destino para que la migración se diera por concluida. En el artículo anterior expliqué como hacer el cambio de nombre en un servidor Standalone.

Cambio de nombre Role SQL en cluster

El cambio de nombre de un role SQL en cluster es bastante sencillo de realizar si se tienen los permisos correctos.

Yo estoy ejecutando todo como administrador de dominio, pero si no tienes permisos de administrador de dominio, tendrías que aplicar permisos de Control Total al usuario con el que administras el cluster en la OU (Unidad Organizativa) donde almacenas las cuentas de equipo que conforman el clúster. Para más detalle consulta este artículo de la Technet.

Pasos para el cambio de nombre del role:

  1. Abre la consola Failover Cluster Manager.
  2. Selecciona Role.
  3. Escoge el nombre de tu role SQL.
  4. Marca la pestaña Resources que hay abajo.
  5. Despliega el área Server Name
  6. Pulsa botón derecho sobre Name y selecciona Properties.
  7. En el campo DNS, escribe un nuevo nombre y pulsa OK.cambio_DNS_cluster
  8. Cuando pregunte la confirmación, selecciona Yes.
  9. Pulsa botón derecho sobre Name y selecciona Take offline. Cuando todo esté en OFF prosigue.Take_Offline_Cluster
  10. Pulsa botón derecho sobre Name y selecciona Bring Online.
  11. Comprueba en tu Active Directory y tu DNS que tienes un equipo con el nuevo nombre.Cambio_nombre_ADCambio_nombre_DNS
  12. Con DoubleTake SQLMove solo hace falta cambiar el nombre de equipo. Ya que los scripts se encargan de cambiar el nombre en SQL. Si fuera un cluster, habría que realizar el procedimiento anterior el clúster destino.Comprobacion_SQL_Nuevo

Hasta aquí el artículo de hoy. Espero que os haya resultado interesante.

escrito por Javier Peral