다음을 통해 공유

Windows Aware Updating and SQL Server 2012 (Part I) – Introduction to Windows Aware Updating

  • 아티클

Windows Server 2012 has incorporated a new functionality called Windows-Aware Updating (CAU) that allows the automatic orchestration of the installation of updates for the operating system and other applications that are executed on the Cluster nodes. This functionality is really well integrated with applications like Hyper-V, however, can be used to update any Microsoft Application or third party applications.

This functionality, that can only be used on Windows Server 2012 Clusters, eases the task of updating environments, especially when we consider that is possible to create a 64 nodes cluster, Windows will take charge to coordinate (orchestrate) all the actions related with the updates, like the services failover, updates installation and node restart. This allows the administrator to concentrate exclusively in monitoring the process of update and in this manner updating many environments simultaneously using time more efficiently.

Once configured, CUA functions as follow:

  • Puts the first node on maintenance mode
  • Move the roles (Previously know as applications and services or Groups) from the node
  • Install the updates
  • Restart the server if necessary
  • Puts the node out of the maintenance mode
  • Move to the update node the roles previously on execution at the beginning of the process
  • Repeats the steps on all the remaining nodes, un a sequential mode

 

There are 2 modes for the execution of the process: from a machine (Windows 8 or Windows Server 2012) outside of the cluster (remote updating mode) or from one of the nodes in the cluster (self-updating mode)

NOTE: to enable this tool on Windows 8 is necessary to download Remote Server Administration Tools (RSAT) for Windows 8 from https://www.microsoft.com/en-us/download/details.aspx?id=28972

Regardless the mode you are using, we can specify the plug-in that allows to define the origin of the updates to install:

Microsoft.WindowsUpdatePlugin

This plug-in install by default the GDR security important and critical updates, directly from Windows Update, Microsoft Update, and approve updates from the Windows Server Update Services (WSUS) Server, although is possible to install additional GDR Updates configuring additional parameters in the plug-in

Microsoft.HotfixPlugin

This plug-in install LDR Updates (previously QFE) from a folder on a file share SMB, and can be configured to install non-Microsoft updates, like updates for firmware or BIOS.

On both modes and indifferently of the plug-in you are going to use, CAU can be invoke using a graphic tool or using Power Shell (https://technet.microsoft.com/en-us/library/hh847221.aspx)

Note: for this post I will use the graphic tool, this allows a simpler visualization of the process. This example will use a Windows Server 2012 Cluster with 3 nodes and execute the Self-updating mode.

To start the graphic tool, right click on the cluster name -> More Actions -> Cluster-Aware updating, like you can see on the figure

 

 

To visualize the updates that will be install on each node, we can click on “Preview updates for this cluster”, select the desired plug-in and click on “Generate Preview update list”. In this example, we used the Microsoft.WindowsUpdatePlugin plug-in to obtain the list of updates not installed from Windows Update.

 

In this case, is not possible to select which updates to install, or in which nodes. If you’ll like to apply updates on a specific node or specific SQL Instances, is necessary to use the Microsoft.HotfixPlugin. 

To use the Microsoft.HotfixPlugin, the first action to execute is create the structure of directories that indicates which updates are installed on each node. For this you’ll create a file share with the following structure.

\\<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

Where:

  • The folder CAUHotfix_All will contain all the updates that fill be installed on all nodes of the cluster
  • The folder <node 1 name> will contain all that updates to install on that specific node with that name, and this will be the same process for the other nodes <node X name>
  • If the folder CAUHotfix_All doesn’t exist only the specific updates for each node will be installed.
  • If the folder for each specific node doesn’t exist, only the updates on CAUHotfix_all will be installed, if this folder exist

NOTE: the file DefaultHotfixConfig.xml can be copied from the path C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ClusterAwareUpdating from any node. This file, without any change, allows the installation of most of the non-SQL Server updates. For more information https://technet.microsoft.com/en-us/library/jj134213.aspx

If you are installing updates to SQL Server, is necessary to define a different folder structure, and modify the configuration file, with the objective to specify the parameters of execution, like the SQL Instance where the updates it’s going to be applied. Let’s suppose we will like to install the Service Pack on one or all the instances, in all the nodes, the structure should be similar to:

\\<networkshare>\hotfixroot

        DefaultHotfixConfig.xml

         \CAUHotfix_All

                \SQL2012SP1

                        \<SQLServer2012SP1Package>.exe

If we’ll like to install the Service Pack on one instance that only executes on the nodes 2 and 4 of the cluster, the structur should be similar to:

\\<networkshare>\hotfixroot

        DefaultHotfixConfig.xml

         \<nodo 2 name>

                \SQL2012SP1

                        \<SQLServer2012SP1Package>.exe

\<nodo 4 name>

                \SQL2012SP1

                        \<SQLServer2012SP1Package>.exe

Where SQL2012SP1 is the name of the rule that will be used to define the parameters of execution for the update and is defined by the user.

 NOTE: the directory \CAUHotfix_All can exist and be empty, but in this case was erase to avoid the installation of any update on all the nodes by mistake.

In both cases, you need to modify the file DefaultHotfixConfig.xml to add the rule (Red section of the example) that allows the specification of the execution parameters of the update package. It also allows to specify the success conditions of the update.

<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>

Where <INSTANCIA A ACTUALIZAR> can:

  • Specify the name of the instance in the form /INSTANCENAME=Inst1 to update the SQL Instance of name Inst1.
  • /allinstances to update all the instances install on the node.

NOTE: the parameters to specify match the parameters of a SQL Server installation form the command prompt (https://msdn.microsoft.com/en-us/library/ms144259.aspx)

On the success condition for CAU, there are only 4 for SQL Server:

  • Success, output code 0
  • Success_RebootRequired, output code 3010
  • NotApplicable, output code -2068578302, when the specify instance doesn’t exist on the node.
  • AlreadyInstalled, output code -2068643838, when the update is already installed on the specified Instance.

On some scenarios you can omit the last 2 codes from the configuration file, with the objective of determine not valid executions, result of a bad folder structure, and incorrect name of the SQL Instances to update or the intent to apply an update that doesn’t apply to the environment. The CUA will return a failed state for the misconfigured nodes.

NOTE: When specifying on the folder structure and /or the name of the instances on the configuration file, you should be really careful to avoid that one of the SQL instance been outdated on a node where it can be stated, because this will cause a downgrade of the instance.

Once you have created the folder structure, and to validate that CUA will install the desired updates on all the indicated nodes, we can click on “Preview updates for this cluster”, select the plug-in Microsoft.Hotfix, establish the plug-in parameters (this is described on the second part of this post) and click on “Generate Preview update list”. Let’s see a particular example of 2 Windows Updates with the following folder structure:

\\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

 

As you can see the windows8-RT-KB2792100-x64.msu will be installed on all the nodes, while the windows8-RT-KB2737084-x64.msu will be installed on Win20121 and Win20122 only, as specified on the folder structure.

On the second part of the post (Windows Aware updating and SQL Server 2021 (Part II) – Step by Step) we will explain how to configure and execute CAU to install a Service Pack for SQL Server 2012.