InfoScale™ 9.0 Storage Foundation and High Availability Solutions Microsoft Clustering Solutions Guide for Microsoft SQL Server - Windows

Last Published:
Product(s): InfoScale & Storage Foundation (9.0)
Platform: Windows
  1. Introducing SFW solutions for a Microsoft cluster
    1.  
      About Microsoft clustering solutions with SFW
    2.  
      Advantages of using SFW in a Microsoft cluster
    3.  
      About high availability clusters
    4.  
      About campus clusters
    5.  
      About disaster recovery clusters
  2. Planning for deploying SQL Server with SFW in a Microsoft cluster
    1.  
      InfoScale requirements for Microsoft clustering solutions
    2. Planning your SQL Server high availability configuration
      1.  
        Sample high availability configuration for SQL Server with SFW
      2.  
        Configuring the quorum device for high availability
    3. Planning your campus cluster configuration
      1.  
        Microsoft campus cluster failure scenarios
      2. Microsoft cluster quorum and quorum arbitration
        1.  
          Quorum
        2.  
          Cluster ownership of the quorum resource
        3.  
          The vxclus utility
    4. Planning your disaster recovery configuration
      1.  
        Sample disaster recovery configuration for SQL Server with SFW and Volume Replicator
  3. Workflows for deploying SQL Server with SFW in a Microsoft cluster
    1.  
      Workflow for a high availability (HA) configuration
    2. Workflow for a campus cluster configuration
      1.  
        Campus cluster: Connecting the two nodes
    3.  
      Workflow for a disaster recovery configuration
    4.  
      Using the Solutions Configuration Center workflow
    5.  
      Configuring the storage hardware and network
  4. Configuring SFW storage
    1.  
      Tasks for configuring InfoScale Storage
    2. Planning for SFW cluster disk groups and volumes
      1.  
        Sample SQL Server high-availability cluster storage configuration
      2.  
        Sample campus cluster storage configuration
      3.  
        Sample SQL Server disaster recovery storage configuration
    3.  
      Considerations when creating disk groups and volumes for a campus cluster
    4.  
      Considerations when creating volumes for a DR configuration using Volume Replicator replication
    5.  
      Viewing the available disk storage
    6.  
      Creating dynamic cluster disk groups
    7.  
      Adding disks to campus cluster sites
    8.  
      Creating dynamic volumes for high availability clusters
    9.  
      Creating dynamic volumes for campus clusters
  5. Implementing a dynamic mirrored quorum resource
    1.  
      Tasks for implementing a dynamic mirrored quorum resource
    2.  
      Creating a dynamic cluster disk group and a mirrored volume for the quorum resource
    3.  
      Adding a Volume Manager Disk Group resource for the quorum
    4.  
      Changing the quorum resource to a dynamic mirrored quorum resource
  6. Installing SQL Server and configuring resources
    1.  
      Tasks for installing and configuring SQL Server
    2.  
      Creating the resource group for the SQL Server instance
    3.  
      Prerequisites for installing SQL Server
    4.  
      Installing SQL Server in an InfoScale Storage environment
    5.  
      Dependency graph for SQL Server
    6.  
      Verifying the SQL Server group in the Microsoft cluster
  7. Configuring disaster recovery
    1.  
      Tasks for configuring the secondary site for disaster recovery for SQL Server
    2.  
      Verifying the primary site configuration
    3.  
      Creating a parallel environment for SQL Server on the secondary site
    4.  
      Volume Replicator components overview
    5.  
      Setting up security for Volume Replicator
    6.  
      Creating resources for Volume Replicator
    7. Configuring Volume Replicator: Setting up an RDS
      1.  
        Prerequisites for setting up the RDS
      2.  
        Creating a Replicated Data Set (RDS)
    8.  
      Creating the RVG resource
    9.  
      Setting the SQL server resource dependency on the RVG resource
    10. Normal Volume Replicator operations and recovery procedures
      1.  
        Monitoring the status of the replication
      2.  
        Performing planned migration
      3. Replication recovery procedures
        1.  
          Bringing up the application on the secondary host
        2.  
          Restoring the primary host
  8. Appendix A. Configure InfoScale Storage in an existing Microsoft Failover Cluster
    1.  
      Configuring InfoScale Storage in an existing Microsoft Failover Cluster

Volume Replicator components overview

The following table describes the Volume Replicator components you must configure.

Table: Volume Replicator components

Component

Description

Replicated Volume Group (RVG)

An RVG is made up of one or more volumes in an SFW disk group. The updates made on the RVG on the primary host are sent to a configured secondary host. Thus, on the secondary host there is a corresponding RVG with a disk group of the same name and volumes with the same names. The data volumes should be the same size. Optionally, to add more redundancy, you can have multiple secondary hosts, all with the same corresponding copy of the RVG.

An RVG within a disk group is the container for replication, so if you have multiple disk groups, you will need to create a separate RVG for each disk group. It is possible to have more than one RVG in a disk group; however, the RVG cannot span across disk groups.

Replicated Data Set (RDS)

An RVG on the primary host and any corresponding RVGs on the secondary host or hosts make up a Replicated Data Set (RDS).

Replicator Log volume

Each RVG must have a Replicator Log associated with it. The Replicator Log volume at the primary site holds a copy of any RVG updates that are sent to the secondary site. The Replicator Log on the secondary site is held in reserve so that it can be used if the primary site becomes nonfunctional and the secondary site needs to become the new primary site. The log volumes at the two sites must have the same name. Arctera recommends having Replicator Log volumes of the same size at the primary site and the secondary site.