Tag Archives: mount

Example Architectural Decision – Datastore Heartbeats for Clusters protected by SRM

Posted on by
Reply

Problem Statement

To enhance the isolation detection abilities of vSphere to minimize the chance of false positive isolation responses  Datastore Heartbeats will be used. What is the most suitable configuration of Datastore Heartbeats for an environment using SRM?

Requirements

1. SRM solution must not be impacted

2. Maximum vSphere environment availability

Assumptions

1. Site Recovery Manager 5.1 protects virtual machines in the cluster/s

2. Appropriate isolation address/es have been configured OR the default isolation address is suitable

3. As all storage is presented via Active/Active storage controllers

4. There are some datastore which are not replicated

5. Isolation response is set to “Shutdown”

Constraints

1. None

Motivation

1. Minimize the chance of a false positive isolation event

2. In the event of isolation, automate the recovery of VMs

Architectural Decision

Use Datastore Heartbeats to enhance the isolation detection capabilities of vSphere.

For each cluster where SRM is used, Configure Datastore Heartbeating to Manually select two non replicated datastores per cluster as the heartbeat datastores

Justification

1. Datastore heartbeating frequently writes to the datastore selected for heartbeating so in the event the network is down, isolation, partition or failure can be properly determained. As a result, during a SRM recovery, datastores need to be un-mounted from the failed site and the Datastore heartbeating may cause one or more datastores to fail to unmount due to I/O on the datastore

2. Datastores failing to un-mount will cause one or more of the SRM recovery steps to report as failed, selecting non replicated datastores prevents this impacting SRM

3. The environment benefits from increases resiliency as a result of datastore heartbeats being used

4. There is no negative impact to the SRM solution

Implications

1. Each cluster will need to have one or more non replicated datastores if Datastore Heartbeating is to be used

2. Additional configuration required to manually select non replicated datastores for heartbeating

Alternatives

1. Do not use Datastore heartbeating

2. Use Datastore Heartbeats and have datastores automatically selected

Relates Articles

1. Example Architectural Decision – Host Isolation Response for FC Based storage


 

Example Architectural Decision – Storage I/O Control for Clusters Protected by SRM (Example 2 – Use SIOC)

Posted on by
Reply

Problem Statement

In an environment with one or more clusters with virtual machines protected by SRM, What is the most appropriate configuration of Storage I/O control?

Requirements

1. SRM solution must not be impacted

Assumptions

1. vSphere Version 4.1 or later

2. FC (Block) Based Storage OR NFS (File) based Storage

3. Number of datastores is fairly static

Constraints

1. Storage I/O control can prevent unmounting of datastore during a Recovery which can lead to errors being reported by SRM

Motivation

1. Where possible ensure consistent storage performance for all virtual machines

Architectural Decision

Enable and Configure Storage I/O control for all datastores.

Set the congestion threshold to 20ms

Leave the shares value default

Add a Step to each SRM recovery Plan as Step 1 and Select the Step Placement of “Before selected step”.

Configure step type as “Command of SRM Server” and execute the Scheduled Task which will disable SIOC prior to executing a SRM recovery

Justification

1. The benefits of Storage I/O control can still be achieved without impact to the SRM solution

2. SIOC will not impact SRM failover as it will be disabled automatically as part of the SRM recovery plan

3. In the event the Protected site or is lost, SIOC will not prevent failover

Implications

1. Increased complexity for the SRM solution

2. An additional step to excecute a “Command of SRM Server” is required

3. A Scheduled Task will need to be setup and configured with setting “Allow task to be ran on demand”

4. A script to disable SIOC will need to be prepared and configured with all datastores

Alternatives

1. Enable Storage I/O control and leave default settings

2. Enable storage I/O control and set share values on virtual machines

3. Enable Storage I/O control and set a lower “congestion threshold”

4. Enable Storage I/O control and set a higher “congestion threshold”

5. Disable Storage I/O control

Relates Articles

1. Example Architectural Decision –  Storage I/O Control for Clusters Protected by SRM (Example 2 – Don’t Use SIOC)

 

Example Architectural Decision – Storage I/O Control for Clusters Protected by SRM (Example 1 – Don’t Use SIOC)

Posted on by
1

Problem Statement

In an environment with one or more clusters with virtual machines protected by SRM, What is the most appropriate configuration of Storage I/O control?

Requirements

1. SRM solution must not be impacted

Assumptions

1. vSphere Version 4.1 or later

2. FC (Block) Based Storage OR NFS (File) based Storage

Constraints

1. Storage I/O control can prevent unmounting of datastore during a Recovery which can lead to errors being reported by SRM

Motivation

1. Where possible ensure consistent storage performance for all virtual machines

2. Simplicity

Architectural Decision

Do not use Storage I/O control for datastores protected by SRM

Justification

1. Storage I/O control can prevent unmounting of datastore during a Recovery which can lead to errors being reported by SRM

2. Storage I/O control can prevent re-mounting of datastore/s during a failback which can lead to errors being reported by SRM and prevent failback without manual intervention

3. Solution does not require any custom steps added to SRM to facilitate a successful recovery

Implications

1. Storage I/O control cannot be used for Datastores protected by SRM

2. In the event of storage contention, SIOC will not be able to ensure fairness between virtual machines based on their share values

3. Storage Performance may degrade significantly during contention

Alternatives

1. Enable Storage I/O control and leave default settings

2. Enable storage I/O control and set share values on virtual machines

3. Enable Storage I/O control and set a lower “congestion threshold”

4. Enable Storage I/O control and set a higher “congestion threshold”

5. Enable Storage I/O control and as part of the DR runsheet, disable SIOC prior to executing a SRM recovery

Relates Articles

1. Example Architectural Decision –  Storage I/O Control for Clusters Protected by SRM (Example 2 – Use SIOC)