Veritas InfoScale 7.3.1 Installation and Upgrade Guide - Windows

Last Published:
Product(s): InfoScale & Storage Foundation (7.3.1)
Platform: Windows
  1. Preinstallation and planning
    1.  
      About the Veritas InfoScale product suite
    2.  
      Supported hardware and software
    3.  
      Disk space requirements
    4.  
      Installation requirements
    5.  
      Requirements for installing InfoScale Storage in a Microsoft Failover Cluster
    6.  
      Recommendations and best practices
    7. About InfoScale licenses
      1.  
        Licensing notes
      2.  
        vxlicrep command
  2. Installing the Veritas InfoScale products
    1.  
      About installing the InfoScale products
    2.  
      About the co-existence of InfoScale products
    3.  
      Installing the server components using the installation wizard
    4.  
      Applying the selected installation and product options to multiple systems
    5.  
      Installing the server components using the command-line installer
    6.  
      Parameters for Setup.exe
    7.  
      Available product options and supported DMP DSMs
    8.  
      Registering the InfoScale Storage resource DLLs
    9.  
      Installing the client components
  3. Upgrading to InfoScale products
    1. Preparing the systems for an upgrade
      1.  
        About the supported upgrade paths and the supported minimum product versions
      2.  
        General preparations
      3.  
        Recommendations and considerations for product upgrade
    2. Performing the product upgrade
      1. Upgrading SFW or SFW Basic in a non-clustered environment
        1.  
          Preparing the primary site for upgrade in a non-clustered SFW environment
      2. Upgrading SFW or SFW Basic in a Windows Server Failover Cluster environment
        1.  
          Preparing the secondary site for upgrade in a Windows Server Failover Cluster environment
        2.  
          Failing over application to secondary site
        3.  
          Preparing the primary site for upgrade in a Windows Server Failover Cluster environment
      3.  
        Upgrading VCS
      4. Upgrading SFW HA
        1.  
          Preparing the primary and secondary sites for upgrade in a Volume Replicator environment
        2.  
          Associating the replication logs and starting the replication
        3.  
          Re-enabling Volume Replicator in a VCS cluster
      5.  
        Upgrading DMP
    3.  
      About transitioning between the InfoScale products
  4. Performing the post upgrade tasks
    1.  
      Deployment scenarios and applicable post upgrade tasks
    2.  
      Re-enabling Volume Replicator in a non-clustered environment
    3.  
      Re-enabling Volume Replicator in a Microsoft failover cluster environment
    4.  
      Reconnecting DMP DSM paths after the upgrade
    5.  
      Reconfiguring the Veritas InfoScale Messaging Service
    6.  
      Importing the configured rules
    7.  
      Upgrading clusters for stronger security
    8.  
      Reinstalling the custom agents
    9.  
      Including custom resources
  5. Administering the InfoScale product installation
    1.  
      Adding or removing product options
    2.  
      Managing InfoScale licenses
    3.  
      Repairing an InfoScale product installation
    4.  
      About reinstalling InfoScale products
  6. Uninstalling the InfoScale products
    1.  
      About uninstalling the InfoScale products
    2.  
      Uninstalling the InfoScale products using the installation wizard
  7. Performing application upgrades in an InfoScale environment
    1. Upgrading Microsoft SQL Server
      1. Upgrading to later versions of SQL Server
        1.  
          Upgrading SQL Server on the first cluster node
        2.  
          Upgrading SQL Server on additional failover nodes
        3.  
          Creating the new SQL Server service group
    2. Upgrading Oracle
      1.  
        Performing the post upgrade tasks
      2.  
        Associating the updated Oracle database with the listener
      3. Configuring the Oracle database and listener to use the virtual IP address
        1.  
          Setting the dispatchers parameter in PFILE
        2.  
          Setting the dispatchers parameter in SPFILE
      4.  
        Configuring Oracle and listener services
      5.  
        Modifying the ServiceName attribute for the netlsnr resource
    3. Upgrading application service packs in an InfoScale environment
      1. Upgrading the Exchange Server service packs
        1.  
          Upgrading Exchange Server 2010 to a service pack
      2. Upgrading the SQL Server service packs
        1.  
          Upgrading SQL Server 2012 or SQL Server 2014 or SQL Server 2016 to a service pack
      3.  
        Upgrading SharePoint Server 2010 to a service pack
  8. Appendix A. Services and ports
    1.  
      InfoScale ports and services
  9. Appendix B. Migrating from a third-party multi-pathing solution to DMP
    1.  
      Migrating from EMC PowerPath
    2. Migrating from Hitachi Dynamic Link Manager (HDLM)
      1.  
        Uninstalling HDLM in a non-clustered environment
      2.  
        Uninstalling HDLM in a clustered (MSCS or VCS) environment
    3.  
      Configuring DMP for Active/Active load balancing in a cluster

Upgrading SQL Server 2012 or SQL Server 2014 or SQL Server 2016 to a service pack

This section describes the tasks to upgrade SQL Server 2012 or SQL Server 2014 or SQL Server 2016 in a InfoScale disaster recovery environment.

Before upgrading SQL Server

Consider the following points before you proceed with the upgrade:

  • Ensure that you have installed and configured SQL Server.

  • Ensure that the logged on user has administrative privileges to the SQL instance that you want to upgrade.

  • Ensure that you have taken a recent backup of your system, user databases, and the SQL Server directories, from the shared storage.

  • Refer to the Microsoft documentation for prerequisites related to SQL Server Service Pack installation.

Upgrading SQL Server to a service pack

Consider a three-node disaster recovery cluster setup; Node A, Node B and Node C. Node A and Node B are on the primary site and Node C is on the secondary site. The SQL service group is online on Node A.

You can upgrade SQL Server 2012 or SQL Server 2014 or SQL Server 2016 to a service pack in any of the following ways:

Upgrading SQL Server to a service pack one node at a time

In this procedure you upgrade SQL Server on the nodes at the primary site first and then on the nodes at the secondary site. This process involves moderate service group downtime, because you upgrade one cluster node at a time.

To upgrade SQL Server to a service pack, perform the following steps:

  1. Stop the replication between the primary and the secondary site.

    If using Volume Replicator for replication, from the VEA Console, right-click the Secondary RVG and select Stop Replication from the menu that appears.

  2. On Node A where the SQL Server service group is online, take the SQLServer, MSOlap, and SQLServer-Agent resources offline.

    Run the following command from the command prompt:

    hares -offline [-parentprop] resource -sys system

    Here, resource is the name of the SQL resource and system is the name of node where the SQL Server service group is online.

  3. From Services.msc, ensure that all the SQL services and the SQL services for which VCS resources are configured are stopped.
  4. Perform the following steps on the SQL Server service group on Node A (active node):
    • Bring the RegRep resource offline.

      Type the following on the command prompt:

      hares -offline [-parentprop] resource -sys system

    • Disable the RegRep resource.

      Type the following on the command prompt:

      hares -modify resource_name Enabled 0

    • Except the storage resources (MountV and VMDg), take all the resources offline.

    • Freeze the service group.

      Type the following on the command prompt:

      hagrp -freeze service_group [-persistent]

  5. Install the Microsoft SQL Server Service Pack on Node A.
  6. If a FILESTREAM resource is configured in the SQL Server service group, verify if a FILESTREAM share exists on the node and then delete it.

    Run the following commands from the command prompt:

    • net share

      This command lists all the shares on the node.

    • net share share_name /delete

      Here, share_name is the name of the FILESTREAM share.

  7. Unfreeze the SQL Server service group.

    Type the following on the command prompt:

    hagrp -unfreeze service_group [-persistent]

  8. Fail over the service group to Node B and perform the following steps on Node B, in the given order:
    • Except the storage resources (MountV and VMDg), take all the resources offline.

    • From Services.msc, ensure that all the SQL services and the SQL services for which VCS resources are configured are stopped.

    • Freeze the service group.

  9. Rename the SQL folders on the shared storage and copy the backed up SQL Server directories to the shared storage.

    The SQL Server data files available on the shared storage are upgraded during the SQL upgrade on Node A. Before you begin to upgrade SQL on Node B, you must rename the folders containing the upgraded SQL data files and restore the initially backed up SQL Server directories. If you do not restore the initially backed up SQL Server directories, then the SQL upgrade on Node B may fail indicating that the SQL Server data files are already upgraded.

  10. Install the Microsoft SQL Server Service Pack on Node B.
  11. If a FILESTREAM resource is configured in the SQL Server service group, verify if a FILESTREAM share exists on the node and then delete it.

    Run the following commands from the command prompt:

    • net share

    • net share share_name /delete

      Here, share_name is the name of the FILESTREAM share.

  12. Unfreeze the service group on Node B and enable the RegRep resource.

    Run the following commands from the command prompt:

    • hagrp -unfreeze service_group [-persistent]

    • hares -modify resource_name Enabled 1

  13. Bring the service group online on Node B.
  14. Start the replication between the primary and the secondary site.
  15. Switch the service group to a node on the DR site (Node C).

    Type the following on the command prompt:

    hagrp -switch service_group -site site_name

  16. Stop the replication between the primary and the secondary site again.
  17. Perform the following steps on Node C, in the given order:
    • Except the storage resources (MountV and VMDg), take all the resources offline.

    • Disable the RegRep resource and freeze the service group.

    • Rename the SQL folders on the shared storage and copy the backed up directories to the shared storage.

    • Install the Microsoft SQL Server Service Pack on Node C.

    • If a FILESTREAM resource is configured in the SQL Server service group, verify if a FILESTREAM share exists on the node and then delete it using the following commands:

      net share

      net share share_name /delete

    • Unfreeze the service group and enable the RegRep resource.

  18. Start replication between the primary and secondary site.
  19. Switch the service group back to Node B (last upgraded node) on the primary site.

    Note:

    You must bring the SQL service group online on Node B first. This is because the replication service group is online on Node B. You can then switch the SQL service group on any node on the primary site.

Upgrading SQL Server to a service pack on passive nodes and then on the active node

In this procedure you upgrade SQL Server on the passive nodes at both the sites first and then on the active node. This process involves less complexity and service group downtime.

Note:

This procedure is applicable only if the SQL Server database and the SQL Server analysis (OLAP) files are installed on shared storage on the active node and at the default location (on the C: drive) on the passive nodes.

To upgrade SQL Server to a service pack

  1. Freeze the SQL Server service group on Node A using the VCS Cluster Manager (Java Console).

    On the Service Groups tab, right-click the service group and then click Freeze > Persistent. Save the configuration and leave the group frozen until all the nodes are updated.

    Alternatively, run the following command on the command prompt:

    hagrp -freeze service_group [-persistent]

  2. Back up the registry of the SQL Server database instance on the passive nodes, by following these steps sequentially:
    • Access the registry by using your preferred method to execute regedit.exe.

    • Locate the SQL Server instance registry key:

      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL11.instance

    • Right-click on the registry key and click Export.

    • Save the registry key.

    Note:

    While upgrading SQL Server 2014 or SQL Server 2016 to a service pack, the MSSQL11 value in the registry key changes to MSSQL12 or MSSQL13 respectively.

  3. Stop the replication between the primary and the secondary sites.

    If VVR is used for replication, from the VEA Console right-click the Secondary RVG and select Stop Replication from the context menu.

  4. If you find any registry keys from the following list on nodes B and C, update them to point to the root directory. Note that instance represents the SQL Server instance that you are trying to upgrade.
    • HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL11.instance\MSSQLServer\BackupDirectory

    • HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL11.instance\MSSQLServer\DefaultLog

    • HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL11.instance\MSSQLServer\Parameters\SQLArg0

    • HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL11.instance\MSSQLServer\Parameters\SQLArg1

    • HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL11.instance\MSSQLServer\Parameters\SQLArg2

    • HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSAS11. instance\CPE\ErrorDumpDir

    • HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSAS11. instance\Setup\DataDir

    • HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL11.instance\MSSQLServer\DefaultData

    • HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL11.instance\SQLServerAgent\ErrorLogFile

    • HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL11.instance\SQLServerAgent\WorkingDirectory

    • HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL11.instance\Setup\SQLDataRoot

    For example, if the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL11.instance\MSSQLServer\BackupDirectory contains the value F:\Test\MSSQL11.MSSQLSERVER\MSSQL\Backup, change this value to point to the root directory C:\Program Files\Microsoft SQL Server.

    Therefore, updated value becomes C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup.

  5. Complete the SQL Server service pack upgrade on nodes B and C, and reboot the server.

    Do not fail over until the service pack installation on Node A is complete.

  6. On Node A, run the command hastop -local -force to stop the VCS services.

    Doing so stops VCS, but leaves the storage and the SQL Server online. It also prevents VCS from taking any action on the resources when the installer restarts the service.

  7. Complete the SQL Server service pack upgrade on Node A, and verify that the services are back in the Started state.
  8. Run command hastart to start VCS services on Node A.
  9. Start the replication between the primary and secondary sites.
  10. Unfreeze the service group and test failover to nodes B and C.

    Run the following command on the command prompt:

    hagrp -unfreeze service_group [-persistent]

This completes the SQL Server upgrade to a service pack.