InfoScale™ 9.0 Storage Foundation and High Availability Solutions HA and DR Solutions Guide for Microsoft SQL Server - Windows
- Section I. Getting started with Storage Foundation and High Availability Solutions for SQL Server
- Introducing SFW HA and the VCS agents for SQL Server
- How is application availability achieved in a VMware virtual environment
- How VCS monitors storage components
- Deployment scenarios for SQL Server
- Reviewing the active-passive HA configuration
- Reviewing a standalone SQL Server configuration
- Reviewing the campus cluster configuration
- Reviewing the Replicated Data Cluster configuration
- About setting up a Replicated Data Cluster configuration
- Disaster recovery configuration
- Reviewing the disaster recovery configuration
- Notes and recommendations for cluster and application configuration
- Configuring disk groups and volumes for SQL Server
- About managing disk groups and volumes
- Configuring the cluster using the Cluster Configuration Wizard
- Installing SQL Server
- Completing configuration steps in SQL Server
- Introducing SFW HA and the VCS agents for SQL Server
- Section II. Configuring SQL Server in a physical environment
- Configuring SQL Server for failover
- About configuring the SQL Server service group
- Configuring the service group in a non-shared storage environment
- Configuring an MSDTC Server service group
- Configuring campus clusters for SQL Server
- Configuring Replicated Data Clusters for SQL Server
- Setting up the Replicated Data Sets (RDS)
- Configuring a RVG service group for replication
- Configuring the resources in the RVG service group for RDC replication
- Configuring the VMDg or VMNSDg resources for the disk groups
- Configuring the RVG Primary resources
- Adding the nodes from the secondary zone to the RDC
- Verifying the RDC configuration
- Configuring disaster recovery for SQL Server
- Setting up your replication environment
- About configuring disaster recovery with the DR wizard
- Configuring replication and global clustering
- Configuring the global cluster option for wide-area failover
- Testing fault readiness by running a fire drill
- About the Fire Drill Wizard
- Prerequisites for a fire drill
- Preparing the fire drill configuration
- Deleting the fire drill configuration
- Configuring SQL Server for failover
How the VMwareDisks agent communicates with the vCenter Server instead of the ESX/ESXi host
In addition to the ESX hosts the VMwareDisks agent can also communicate the disk deatch and attach operations with the vCenter Server to which the virtual machines belong.
In this scenario, in event of a failure, the VMwareDisks agent sends the disk detach and attach requests to the vCenter Server (instead of the ESX hosts). The vCenter Server then notifies the ESX host for these operations. Since the communication is directed through the vCenter Server, the agent successfully detaches and attaches the disks even if the ESX host and the virtual machines reside in a different network.
In a scenario where the host ESX/ESXi itself faults, the VMareDisks agent from the target virtual machine sends a request to the vCenter Server to detach the disks from the failed virtual machine. However, since the host ESX has faulted, the request to detach the disks fails. The VMwareDisks agent from the target virtual machine now sends the disk attach request. The vCenter Server then processes this request and disks are attached to the target virtual machine. The application availability is thus not affected.
See Modifying the ESXDetails attribute.
The configuration of VMwareDisks agent to communicate with the vCenter Server has the following limitation:
If VMHA is not enabled and the host ESX faults, then even after the disks are attached to the target virtual machine they remain attached to the failed virtual machine. This issue occurs because the request to detach the disks fails since the host ESX itself has faulted. The agent then sends the disk attach request to the vCenter Server and attaches the disks to the target virtual machine.
Even though the application availability is not impacted, the subsequent power ON of the faulted virtual machine fails. This issue occurs because of the stale link between the virtual machine and the disks attached. Even though the disks are now attached to the target virtual machine the stale link with the failed virtual machine still exists.
As a workaround, you must manually detach the disks from the failed virtual machine and then power ON the machine.
You must have the administrative privileges or must be a root user to communicate the disk detach and attach operations through the vCenter Server. If the vCenter Server user account fails to have the administrative privileges or is not a root user, then the disk detach and attach operation may fail, in event of a failure.
If you do not want to use the administrator user account or the root user, then you must create a role and add the following privileges to the created role:
"Low level file operations" on datastore
"Add existing disk" on virtual machine
"Change resource" on virtual machine
"Remove disk" on virtual machine
After you create a role and add the required privileges, you must add a local user to the created role. You can choose to add an existing user or create a new user.
Refer to the VMware product documentation for details on creating a role and adding a user to the created role.