Uno de los problemas con los que nos encontramos en ocasiones durante los upgrades de versión de SQL Server es que se solapan con upgrades de sistema operativo. Si a esto sumamos que estas instancias y operativos pueden estar trabajando en cluster la situación se complica siendo preciso seguir cuidadosos pasos para poder llevar a cabo la migración en un modo digamos “pseudo in-place”.En este post vamos a mostrar una de las formas en las que podríamos migrar una instancia SQL Server 2005 SP3 Enterprise Edition, que se encuentra sobre un nodo de un cluster Windows Server 2003 x64 R2 SP2 , a una instancia SQL Server 2008 x64 R2 SP1 Enterprise Edition. Durante la migración no se utilizará hardware adicional por lo que aunque no se trata de una migración “in-place” tradicional sí podemos verla como tal desde el punto de vista de los recursos necesarios.
Vamos a familiarizarnos con el entorno inicial con el que contamos y que está compuesto por 4 máquinas virtuales (un controlador de dominio, un servidor que nos proporciona los discos compartidos por iSCSI y dos nodos Windows 2003 en cluster donde está instalada una instancia de SQL Server 2005):
Los dos nodos tendrán acceso directo a los mismos discos (Quorum + Disco Datos Instancia):
La configuración del cluster es una de las más típicas en estos escenarios, un cluster de 2 nodos activo/pasivo con un Quorum basado en disco compartido:
Debido a que el sistema operativo actual, Windows Server 2003 R2 SP2, está soportado por SQL Server 2008 R2 hemos elegido comenzar actualizando la actual instancia de SQL Server 2005 a SQL Server 2008 R2. Para ello comenzaremos instalando los requisitos en cada uno de los nodos y que no se encuentren previamente instalados en nuestro servidor. Por ejemplo deberemos tener instalado el .NET Framework 3.5 SP1 y una versión de Windows Installer superior a la 4.5:
Instalaremos el Windows Installer 4.5 y el .NET 3.5 SP1:
Una vez tenemos estos prerequisitos instalados el siguiente pasó será lanzar el setup desde los medios de instalación de SQL Server 2008 R2. Normalmente para minimizar el downtime comenzaremos con los prerequisitos y con la actualización de los componentes compartidos en el nodo que actúa como pasivo (en nuestro caso será el Nodo 2) y lo reiniciaremos tantas veces como sea necesario durante el proceso. La actualización de los componentes compartidos se realizará desde el Setup de SQL Server 2008 R2, seleccionando la opción de upgrade:
Continuaremos con el asistente y elegiremos únicamente actualizar los componentes compartidos:
Seguimos las instrucciones del asistente y después de unos minutos tendremos dichos componentes actualizados:
El siguiente paso será realizar un failover del Nodo 1 al Nodo 2 y realizar la instalación de los prerrequisitos y los componentes compartidos en el Nodo 1. Cuando terminemos, el nodo 1 seguirá siendo el nodo secundario en ese momento por lo que procederemos a la actualización de la instancia en dicho nodo.
El upgrade a SQL Server 2008 R2 se ejecuta primero en todos los nodos pasivos y finalmente en el nodo activo. Lanzaremos el Setup de nuevo en el Nodo 1, seleccionaremos realizar un upgrade y seleccionaremos nuestra instancia:
Se nos solicitarán aquellos datos que sean necesarios para el proceso. Por ejemplo se nos solicita la cuenta para levantar el servicio de full text:
Finalmente comenzará el upgrade en el nodo pasivo:
Una vez terminamos de actualizar el nodo pasivo comenzaremos con el upgrade del nodo activo:
Se nos advertirá que el propio setup realizará un failover de la instancia a uno de los nodos que ya ha sido actualizado. De esta forma minimizamos el downtime al tiempo necesario para realizar el failover más un periodo de tiempo breve para la ejecución de los scripts de upgrade:
Una vez terminemos la instalación en el Nodo 2 tendremos ya ambos nodos instalados con SQL Server 2008 R2 RTM:
El siguiente paso es instalar el SP1 para SQL Server 2008 R2 SP1. Esta instalación la podremos realizar realizando rolling upgrades, es decir, al igual que realizamos el upgrade comenzaremos instalando el SP1 en el nodo pasivo, realizaremos el failover y finalmente actualizaremos el nodo que queda pendiente.
Una vez llegamos a este punto tenemos ya SQL Server en la versión a la que deseábamos actualizar por lo que llega el momento de actualizar el sistema operativo en cluster de Windows Server 2003 R2 SP2 x64 Enterprise Edition a Windows Server 2008 R2 SP1 x64 Enterprise Edition.
El primer paso para esta migración es sacar uno de los nodos del actual cluster. En nuestro caso decidiremos comenzar por el Nodo 1. Lo primero que debemos hacer es desinstalar SQL Server en dicho nodo. Para ello ejecutaremos el Installation Center de SQL Server 2008 R2 y utilizaremos la opción “Remove a Node from a SQL Server failover cluster”:
Seguiremos paso a paso el wizard para quitar el nodo 1 del cluster de SQL Server. Una vez tengamos este paso finalizado procederemos a eliminar el nodo en si mismo del cluster 2003 actual. Para ello desde el cluster administrator primero detendremos el servicio de cluster y una vez detenido lo expulsaremos del cluster con el comando “evict” :
Quedaremos pues con un cluster de un único nodo:
Esta es obviamente una situación subóptima desde el punto de vista de alta disponibilidad. Sería interesante el no optar por esta alternativa o complementarla añadiendo al cluster algún otro nodo, aunque sea de forma temporal, para asegurarnos que seguimos teniendo alta disponibilidad durante todo el proceso. Incluso sería posible añadir un nodo virtual, aunque no se trate de una solución soportada, sin tener que recurrir a hardware físico. Ya que en este ejemplo vamos a realizar la migración sin hardware adicional, deberemos asumir este riesgo temporalmente.
Una vez tenemos el nodo 1 ya fuera del cluster reiniciaremos la máquina y procederemos al upgrade del sistema operativo introduciendo el medio de instalación correspondiente, en nuestro caso el de Windows Server 2008 R2 con el SP1 ya incluido en la instalación:
Una vez finalizado el proceso comprobamos que la máquina está actualizada y dentro del dominio tal y como estaba la anterior:
El siguiente paso será crear un nuevo cluster sobre 2008 y para ello añadiremos la característica de Cluster Failover:
Una vez configurada desde el Cluster Administrator crearemos un nuevo cluster ya sobre un nodo Windows Server 2008 R2:
Definiremos un nuevo nombre para el cluster, por ejemplo cluster2008, y le asignaremos una IP dentro de la misma subred que manejábamos:
Una vez finalice el proceso de creación del cluster podemos ver cómo aparece en el cluster administrator el nuevo cluster compuesto por nuestro nodo:
El siguiente paso será instalar una nueva instancia SQL Server 2008 R2 SP1 en este cluster para lo que lanzaremos el Setup desde el medio de instalación:
Durante las validaciones nos encontraremos que tenemos un error debido a que no disponemos de discos compartidos disponibles.
En este momento deberemos apagar la instancia del cluster 2003 y así poner el disco offline para levantarlo en el cluster 2008 sin corrupción. Deberemos hacer este proceso de forma manual ya que los dos nodos ahora mismo pertenecen a clusters distintos. También deberemos asegurarnos que disponemos de backups de todas aquellas bases de datos para evitar problemas y para poder sustituir las bases de datos de sistema. Una vez apagado el nodo del cluster 2003, con el administrador de discos del nodo del cluster 2008 levantaremos los discos:
Una vez que estén online, los añadiremos al almacenamiento compartido de nuestro cluster:
Reejecutamos los tests y vemos como ya pasamos con éxito la prueba del disco compartido:
Continuaremos con el asistente de instalación hasta que el proceso esté completo, asegurándonos de utilizar las mismas rutas para la instalación que teníamos en el cluster anterior. También debemos fijarnos en respetar el nombre de la instancia y que el nombre de red sea distinto, por ahora, al que teníamos en el cluster 2003 para evitar conflictos temporalmente:
Indicamos el disco de datos como disco por defecto:
Asignamos una nueva IP para la instancia:
Los grupos para las cuentas de los servicios:
Elegiremos el mismo collation que veníamos utilizando en nuestra instancia en el cluster 2003:
Configuraremos los directorios para bases de datos, tempdb, etc. tal y como los tuviéramos configurados en nuestra instancia anterior:
Seguimos avanzando y completamos la instalación:
El siguiente paso será instalar el Service Pack 1 en este nodo para que esta forma tengamos exactamente la misma revisión que teníamos en el anterior cluster. Una vez completada la instalación reemplazaremos las bases de datos de sistema, levantaremos la instancia y comprobaremos que todas nuestras bases de datos están online correctamente.
Para volver a disponer de alta disponibilidad repetiremos todos estos mismos pasos en el nodo 2, desinstalando la instancia de SQL Server, destruyendo el anterior cluster, instalando Windows Server y posteriormente añadiendo una instancia de SQL Server al cluster ya existente en 2008.
Una vez realizado este proceso comprobamos que el servername de nuestra instancia en 2008 ya corresponde a la que queremos modificar debido a que hemos preservado las bases de datos de sistema. Una vez que no quede resto alguno del cluster sobre 2003 nos quedaría pendiente modificar el network name del cluster para que coincida con el anterior y que de esta forma la migración resulte más transparente.
En resumen, en este post hemos visto como poder afrontar una migración que no se encuentra soportada nativamente in-place. Migrar de versión de SQL Server y de sistema operativo teniendo una instancia clusterizada y reutilizando el hardware existente es posible aunque el proceso puede ser bastante tedioso. Además, será fundamental poder realizar una prueba del proceso, simulándolo en un entorno alternativo, para evitar tener sorpresas durante su ejecución en producción.
2 comments
hi ruben,
We want to make a similar migration to you comment on this post but the difference is that Winsows Winsows server 2008 R2 server 2012 and SQL server 2008 to SQL Server 2012 R2.
Additional we want these servers will have the same call 2012 to 2008 would be possible to do this I mean:
add these two nodes with OS 2012 and SQL 2012 to the current cluster in 2008 because they are new irons and then delete nodes with SO 2008?
or you have a better way to perform this migration in which to keep the name of the cluster of SQL option.
We do this:
Download SQL Server services on clusters
* Disconnect all Ethernet interfaces of servers and disconnecting power supplies to servers A and B.
* Reset the accounts of the servers A and B in Active Directory
* Elimination of the cluster account, the account for the virtual instance and the corresponding account in Active Directory MSDTC
* Assign names and IP addresses (LAN) nodes A and B with SO 2012 new cluster
* Connection LUNs on each node and add the service account as the administrator of each server
* Create new cluster of windows and create clustered MSDTC service
* Make tests Windows failover cluster
* Installing SQL Server 2012 R2 cluster and Installing SQL Server 2012 SP2
* Create SQL Cluster
* Make tests SQL failover cluster
What I want is to create this cluster in 2012 without destroying the previous order to have a rollback in the event of a problem with the new cluster in 2012,
can this be done?
If after trying to create the new cluster and if any event occurs can reimburse the cluster in 2008 by simply connecting the network interfaces and place the storage Luns.
regards…
Hi Niltom,
Rolling back to the old servers directly reattaching the disks will not work. As soon as you attach the databases to the upgraded SQL Server instance they will be upgraded to the new version so they can’t be connected to the old instance again.
In your scenario, where you have new hardware, I think that the easiest way will be to install the new nodes and instances in a new cluster. The name of the cluster and the nodes will not be the same but that will not be a problem for your applications to connect to the new SQL Server clustered instances.
Before moving the disks you should preserve the current state of the databases in 2008 (SAN snapshot, database backup,…). After that, you can shutdown the old SQL clustered instance and reuse the IP and Virtual Name in the new SQL Server clustered instance. If after all tests the new environment is not working, you can rollback shutting down the new instance, restoring the previously preserved state of the databases in the 2008 environment, and starting the old instance again.
Regards,
Ruben