Windows Aware updating y SQL Server 2012 (Parte I) – Introducción a Windows Aware Updating

  • Article

Windows Server 2012 incorpora una nueva funcionalidad llamada Windows-Aware Updating (CAU) que permite la orquestación automática de la instalación de actualizaciones para el sistema operativo y otras aplicaciones que ejecuten sobre los nodos de un Clúster. Esta funcionalidad está muy bien integrada con aplicaciones como Hyper-V, sin embargo, puede ser utilizado para actualizar cualquier aplicación Microsoft e incluso aplicaciones de terceros.

Está funcionalidad, que sólo puede ser utilizada en clúster Windows Server 2012, facilita la tareas de actualización de ambientes, especialmente al tomar en cuenta que es posible crear clúster de hasta 64 nodos, ya que Windows se encarga de coordinar (orquestar) todas las acciones relacionadas con la actualización, tales como el failover de los servicios, la instalación de actualizaciones y reinicio de nodos. Esto permite al administrador concentrase exclusivamente en monitorear el proceso de actualización y de esa forma poder actualizar varios ambientes simultáneamente haciendo un uso más eficiente de su tiempo.

Una vez configurado, CAU funciona de la siguiente manera:

  • Coloca el primer nodo en modo de mantenimiento
  • Mueve los roles (anteriormente llamado “applications and services”) del nodo
  • Instala las actualizaciones
  • Reinicia el nodo si es necesario
  • Saca al nodo del modo de mantenimiento
  • Mueve al nodo actualizado los roles que estaban en ejecución en dicho nodo al inicio del proceso.
  • Repite el proceso en los nodos restantes, uno por uno de forma secuencial.

Existen dos modos para la ejecución del proceso: desde una máquina (Windows 8 o Windows Server 2012) diferente a los nodos del clúster (remote updating mode) o desde uno de los nodos del clúster (self-updating mode).

Nota: para habilitar esta herramienta en Windows 8 es necesario descargar Remote Server Administration Tools (RSAT) for Windows 8 desde https://www.microsoft.com/en-us/download/details.aspx?id=28972

Independientemente del modo utilizado, podemos especificar el plug-in que permitirá definir el origen de las actualizaciones a instalar:

Microsoft.WindowsUpdatePlugin

Este plug-in instala por defecto las actualizaciones GDR de seguridad importantes y criticas directamente desde Windows Update, Microsoft Update,y las actualizaciones aprobadas desde el servidor Windows Server Update Services (WSUS), aunque es posible instalar actualizaciones GDR adicionales configurando parámetros adicionales del plug-in.

Microsoft.HotfixPlugin

Este plug-in instala actualizaciones LDR (antiguamente QFE) desde una carpeta en un file share SMB, y puede ser configurado para instalar actualizaciones no Microsoft, tales como actualizaciones de firmware o de BIOS.

En ambos modos e independientemente del plug-in a utilizar, CAU puede ser invocado usando una herramienta gráfica o a través de comandos PowerShell (https://technet.microsoft.com/en-us/library/hh847221.aspx)

NOTA: Para esta explicación utilizaré la herramienta gráfica que permite una visualización más sencilla del proceso. Para este ejemplo usaremos un Clúster Windows Server 2012 de tres nodos y ejecutaremos el modo self-updating.

Para iniciar la herramienta gráfica, hacemos click derecho sobre el nombre del clúster -> More Actions -> Cluster-Aware updating, tal y como se observa en la siguiente imagen.

 

 

Para visualizar las actualizaciones que serán instaladas en cada uno de los nodos, podemos hacer click sobre “Preview updates for this cluster”, seleccionar el plug-in deseado y hacer click sobre “Generate Preview update list”. En el siguiente ejemplo, se utilizó plug-in Microsoft.WindowsUpdatePlugin para obtener la lista de actualizaciones no instaladas desde Windows Update.

 

En este caso, no es posible seleccionar cuales actualizaciones se desea instalar, ni en cuales nodos. Si se desea aplicar actualizaciones sobre nodos puntuales o sobre instancias específicas, es necesario utilizar el Microsoft.HotfixPlugin.

Para utilizar Microsoft.HotfixPlugin, la primera acción a ejecutar es crear una estructura de directorios que indicará cuales actualizaciones serán instaladas en cada nodo. Para esto se crea un fileshare con la siguiente estructura 

\\<networkshare>\hotfixroot

        DefaultHotfixConfig.xml

         \CAUHotfix_All

                Update1.msu

                Update2.msi

                Update3.msp           

\<nodo 1 name>

Update4.exe

        \<nodo 2 name>

               Update 5

        ….

        \<nodo x name>

               UpdateY.exe

Donde:

  • El directorio CAUHotfix_All contendrá las actualizaciones que serán instaladas en todos los nodos del clúster
  • El directorio <nodo 1 name> contendrá las actualizaciones a instalar en el nodo con dicho nombre, y así sucesivamente hasta el nodo <nodo x name>
  • Si no existe la carpeta CAUHotfix_All sólo se instalarán las actualizaciones especificadas para cada nodo.
  • Si no existe una carpeta con el nombre de un nodo sólo se instalarán las actualizaciones en CAUHotfix_All, si es que es este último directorio existe.

NOTA: el archivo DefaultHotfixConfig.xml puede ser copiado desde la ruta C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ClusterAwareUpdating desde cualquiera de los nodos. Este archivo, sin modificaciones, permite la instalación de la mayoría de las actualizaciones no SQL Server. Para mayor información ver https://technet.microsoft.com/en-us/library/jj134213.aspx

Cuando estamos instalando actualizaciones para SQL Server, es necesario definir una estructura diferente y modificar el archivo de configuración, con el objetivo de especificar los parámetros de ejecución, tales como la instancia sobre la que se instalará la actualización. Supongamos que deseamos instalar el Service Pack en una o todas las instancias y en todos los nodos la estructura debe ser similar a la siguiente:

\\<networkshare>\hotfixroot

        DefaultHotfixConfig.xml

         \CAUHotfix_All

                \SQL2012SP1

                        \<SQLServer2012SP1Package>.exe

Si quisiéramos instalar el Service Pack en una instancia que ejecuta sólo sobre los nodos 2 y 4 del clúster, la estructura sería similar a la siguiente

\\<networkshare>\hotfixroot

        DefaultHotfixConfig.xml

         \<nodo 2 name>

                \SQL2012SP1

                        \<SQLServer2012SP1Package>.exe

\<nodo 4 name>

                \SQL2012SP1

                        \<SQLServer2012SP1Package>.exe

Donde SQL2012SP1 es el nombre de la regla que será utilizada para definir los parámetros de ejecución de la actualización y es definida por el usuario.

NOTA: El directorio \CAUHotfix_All puede existir y estar vacío, pero en este caso se elimina para evitar instalar por error alguna actualización en todos los nodos.

En ambos casos, se debe modificar el archivo DefaultHotfixConfig.xml para agregar la regla (la sección en rojo del ejemplo) que permite especificar los parámetros de ejecución del paquete de actualización. Adicionalmente permite especificar las condiciones de éxito de instalación de la actualización.

<root>

<DefaultRules>

…

</DefaultRules>

  <FolderRules>

    <Folder name="SQL2012SP1">     

      <Template path="$update$" parameters=" /ACTION=PATCH <INSTANCIA A ACTUALIZAR>      

               /QUIET /IAcceptSQLServerLicenseTerms"/>

      <ExitConditions>

        <Success>

          <ExitCode code="0"/>

        </Success>

        <Success_RebootRequired>

          <ExitCode code="3010"/>

        </Success_RebootRequired>

          <NotApplicable>

            <ExitCode code=" -2068578302"/>        <!-- ERROR_PATCH_TARGET_NOT_FOUND -->

        </NotApplicable>

          <AlreadyInstalled>

            <ExitCode code=" -2068643838"/>        <!-- ERROR_PATCH_ALREADY_APPLIED -->

        </ AlreadyInstalled >

      </ExitConditions>

    </Folder>

  </FolderRules>

</root>

Donde <INSTANCIA A ACTUALIZAR> puede:

  • Especificar el nombre la instancia a actualizar en la forma /INSTANCENAME=Inst1 para actualizar la instancia de nombre Inst1.
  • /allinstances para actualizar todas las instancias instaladas en el nodo.

NOTA: los parámetros a especificar corresponden a los parámetros de instalación de SQL Server desde el command prompt (https://msdn.microsoft.com/en-us/library/ms144259.aspx)

En cuanto a las condiciones de éxito para el CAU, existen sólo cuatro para SQL Server:

  • Success, código de salida 0
  • Success_RebootRequired, código de salida 3010
  • NotApplicable, código de salida -2068578302, cuando la instancia especificada no existe en el nodo.
  • AlreadyInstalled, código de salida 2068643838, cuando la actualización ya estaba instalada en la instancia indicada.

En algunos escenarios se omiten los últimos dos códigos del archivo de configuración con el objetivo de determinar ejecuciones no válidas resultado de una estructura de directorios errada, la configuración incorrecta del nombre de la(s) instancia(s) a actualizar o el intento de instalar una actualización que no aplica al ambiente, ya que la ejecución de CAU retorna un estado fallido para los nodos configurados incorrectamente.

NOTA: Cuando la estructura de directorios especifica nombres de nodos y/o se especifiquen instancias en el archivo de configuración, se debe tener especial cuidado para evitar que alguna instancia quede sin actualizar en alguno de los nodos sobre el que ella pueda ejecutar, ya que un failover a dicho nodo generará un downgrade de la instancia.

Una vez creada la estructura de directorios, y para validar que CAU instalará las actualizaciones deseadas en los nodos indicados, podemos hacer click sobre “Preview updates for this cluster”, seleccionar el plug-in Microsoft.Hotfix, establecer los parámetros del plug-in (lo cual se describe en la segunda parte de post) y hacer click sobre “Generate Preview update list”. Veremos el ejemplo particular de dos actualizaciones de Windows con la siguiente estructura de directorios:

\\WIN-0M99J4ILA2E\UpdatesDemo\Root3

DefaultHotfixConfig.xml

  \CAUHotfix_All

 \windows8-RT-KB2792100-x64.msu

  \Win20121> 

 \windows8-RT-KB2737084-x64.msu

\Win20122

 \windows8-RT-KB2737084-x64.msu

\Win20123

Se observa que windows8-RT-KB2792100-x64.msu será instalado en todos los nodos, mientras que windows8-RT-KB2737084-x64.msu sólo será instalado en Win20121 y win20122 de acuerdo a lo especificado en la estructura de directorios.

En la segunda parte del post ( Windows Aware updating y SQL Server (Parte II) – Paso a Paso) se explicará cómo configurar y ejecutar CAU para instalar un Service Pack de SQL Server 2012.