Context
Attaching one managed disk to several virtual machines can look like an easy route to high availability. It is only the storage attachment capability. The guest operating systems and clustered application still need to coordinate who may write and how a failed owner is excluded. Without that coordination, a second attachment can create a data-corruption problem rather than a resilient service.
Separate shared storage from shared ownership
Microsoft documents Azure shared disks for supported clustered applications and describes SCSI persistent reservations or NVMe reservations used by compatible clustering software, according to the disk controller. Support depends on disk characteristics and the intended deployment. Review the current limitations, supported configurations, and guest requirements before designing around a shared attachment.
A normal filesystem is not automatically safe for simultaneous independent writers merely because the platform permits multiple attachments. Decide whether the application uses a cluster-aware filesystem, an active-passive ownership model, or another supported architecture. The storage team and application team must agree on the same ownership contract.
An illustrative failed failover
Imagine a database active on VM A with VM B waiting to take over. VM A loses cluster-network connectivity but continues running and accessing storage. VM B interprets the loss as failure and starts the database. If neither side can exclude the other, both may believe they own the data.
This is why failure detection and fencing are different functions. Detection decides that the owner appears unavailable. Fencing prevents the former owner from continuing a conflicting operation. Review the cluster's actual mechanism and test it under a network partition rather than assuming a heartbeat timeout guarantees exclusive access.
Verify the supported architecture
Record the disk type, sharing configuration, VM placement, operating system, cluster software, and application version. Check the support statement for the complete combination. A configuration that allows attachment is not necessarily supported by the database vendor or clustering product.
List every disk required by the application and how ownership moves. Data, logs, configuration, and quorum-related resources may have different roles. Document which volumes are shared and which remain local. A failover that moves the main data volume while leaving a required dependency on the old node is incomplete.
Design quorum and fencing together
Quorum determines which portion of a cluster may continue operating under defined failure conditions. Fencing enforces exclusion of a competing or failed owner. Review both mechanisms, their dependencies, and their behaviour when the platform control plane or a network path is unavailable.
Avoid a design where the same failure disables both decision-making and enforcement. Ask what happens when cluster communication fails but storage remains available, when storage access fails on one node, and when a node pauses long enough to be declared failed before resuming. Write expected outcomes before executing tests.
Make startup conditional on ownership
The database or application should start through the supported cluster control path. A generic operating system service that starts automatically after reboot can conflict with cluster ownership. Inspect boot settings, recovery actions, and any external automation that may start the process independently.
Review maintenance scripts as well. An administrator restarting the database directly may bypass the same control that protects failover. Give operators a documented command or management action for planned relocation, stop, and restart. The safest architecture becomes fragile when routine procedures ignore its ownership model.
Rehearse distinct failure classes
Begin with a planned role move and verify that one node stops writing before the replacement takes ownership. Then test an abrupt node failure and a controlled cluster-network partition in an approved test environment. Capture cluster events, reservation behaviour, application startup, and storage errors.
Check the application result after failover. Validate representative data and a controlled transaction, not just the cluster's green status. Record the time to detect failure separately from time to establish ownership and time to restore useful service. These components explain the observed recovery time more clearly than a single headline figure.
Back up independently of availability
A shared disk is still one data set. A corrupt write, accidental deletion, or application defect can affect what every node sees. High availability does not replace a recoverable backup with independent retention.
Test restoring the database without relying on the currently healthy cluster. Confirm access to encryption dependencies and compatible software. Keep recovery instructions clear about whether restored storage may be attached to an existing cluster or should be brought up in a separate recovery environment to avoid conflicting ownership.
Quick diagnostic map
| Evidence | Interpretation | Next check |
|---|---|---|
| Both nodes attempt writes | Fencing ineffective | Inspect reservation enforcement |
| Standby cannot start | Recovery dependency missing | Check complete resource set |
| Healthy VMs; service down | Cluster ownership unresolved | Inspect active owner |
A focused operator exercise
Use an isolated supported cluster configuration and document the active owner, shared disk identifiers, reservation mechanism, quorum, and fencing dependencies. Include both the controller interface and guest application support in the record. Verify that the application cannot start independently on the standby through an ordinary boot or service-recovery action.
Perform a planned role move, then a controlled node failure and a cluster-network partition while storage remains reachable. Observe ownership decisions and reservation enforcement separately. Confirm the previous owner cannot continue a conflicting write after the replacement starts. Keep platform, cluster, storage, and application events on one timeline so a successful VM restart cannot conceal an ownership gap.
Validate representative data and a controlled transaction after each exercise. Then rehearse recovery from an independent backup in an isolated environment. The result should state which failures the cluster handled, how long useful service took to recover, and which dependencies remain external to availability. Retain the tested configuration and stop conditions before allowing the design to protect live business data.
Give operations an ownership view
Monitor the active owner, cluster membership, storage access, fencing events, and failed role transitions. A dashboard showing only VM availability hides the important question: which node is allowed to write the business data right now?
Clouvenix can help review Azure shared storage against the application's supported cluster model and rehearse the important failure cases. The result should make ownership, exclusion, and recovery understandable before the second virtual machine is allowed to touch production data.
Frequently asked questions
Can two ordinary Linux mounts safely write the same disk?
Do not assume they can. The filesystem and application need a supported coordination model. Confirm whether the design requires a cluster-aware filesystem or exclusive active-passive mounting, and test the documented ownership mechanism before enabling concurrent access.
Does a healthy standby prove that failover will work?
A standby can be running while lacking storage permissions, required configuration, or effective fencing. A controlled role move and failure exercise provide stronger evidence because they test the actual path from failed ownership to accepted application transactions.
Explore Clouvenix storage infrastructure for implementation and operational handover.