vtricks.

com

http://vtricks.com/?p=101

DataCores SANsymphony-V Part 2 Mirrored Virtual Disk

December 1,
2012

In part 1 Ive explained the basics of disk pools, virtual disks and how data gets distributed across physical disks.
This time I want to dive deeper into synchronously mirrored virtual disks.
As mention in the introduction post as well, SANsymphony-V always consist of two (or more) nodes to setup a
storage grid. In a grid solution each node manages its own physical storage and is also able to run completely
independent. Of course to run a highly available SAN at least two node to create a mirror relationship are
required.
At this point I want to emphasize that it is highly recommended to treat both nodes equal! That the
slowest member will determine the resulting overall performance, so you should always configure them
identically. This affects all components like CPUs, RAM and especially the type of disks and RAID
configurations.
To set up a highly available storage grid its required to create a Server Group first.

This of course introduces some requirements:

Management Network
Its recommended to configure an out of band network to separate management traffic from the production
network. This network will be used to exchange configuration changes and more important this connection is
required to determine which node should provide access to the application hosts in case all mirror paths are
down.
Mirror Connections/Paths
Each write I/O issued to one of the storage servers will be sent over the mirror paths to the second node and only
if this succeeds the write I/O will be acknowledged back to the application host. This mirror connection can be an
iSCSI or a Fibre Channel connection however it should be able to keep up with the front end ports in terms of
bandwidth.

It is possible to set up multiple mirror paths between two nodes to enable a failover in case a connection fails but
only two paths will be able to transport mirror traffic simultaneously. Each node will login to its partners target
ports so there will always see twice as many paths as physical connections.

If all mirror paths fail for whatever reason and SANsymphony-V still can communicate via its management
network it will stop access on one side to prevent data corruption. More about that will follow in a post about
possible failure scenarios.
Disk Pool
As explained each side got its own disk pool and as long as only mirrored virtual disks will be used (and no
snapshots, etc.) the pool utilization will be equal. Snapshots or single vDisks will lead to an uneven utilization.
As long as Auto-Tiering isnt being used. which will be covered in part 5, its recommended to pool physical disks
with identical performance characteristics. When creating a vDisks then the same pool/type of disk should be

used as source on both nodes.

Virtual Disk
The actual mirror and vaiable is achieved on a per vDisk level so every virtual disk should be created as mirrored
disk. the process is the same as for single virtual disks except the fact that a disk pool needs to selected on both
storage nodes. SANsymphony-V then will create a virtual disk on each node, basically independent copies. One
vDisk will be the preferred/primary one where as the other will be the alternate/secondary one. This is only to tell
the application hosts on which side/node where to access storage primarily. As soon the wizards completes SSV
will create the vDisks, automatically add the mirror paths and after a short recovery to sync the bitmap which is
kept in RAM and the SAUs the vDisk is ready to go.

Note: SANsymphony-V will only create up to 2 mirror paths automatically as depicted in the screenshot above. If

more are required those need to be added manually.

And this is how it will look like once the vDisk has been created.

To wrap up this post allow me to quote some state out of the SSV Webhelp documentation to provide an overview
of possible virtual disk states:
Up-to-date Data on both servers is identical (synchronized) and the virtual disk is capable of I/O operations.
Log recovery needed The data on one server is not up-to-date and has to be recovered from the other server
using a log recovery. This is a temporary status until a mirror path is available so that synchronization can take
place.
Full recovery needed The data on one server is not up-to-date and has to be recovered from the other server
using a full recovery. This is a temporary status until a mirror path is available so that synchronization can take
place.
Log recovery pending The data on one server is not up-to-date and has to be recovered from the other server
using a log recovery. The mirror path has been found and the recovery will begin momentarily.
Dual log recovery pending - The data on one server is not up-to-date and a log recovery is in process. I/O
operations from the host are being logged on the other server, which must also be recovered after the first log
recovery is complete. The mirror path has been found and the recovery will begin momentarily.
Dual full recovery pending - The data on one server is not up-to-date and a full recovery is in process. During
I/O operations on the other server, an event occurred which caused the second server to require a full recovery
that will begin after the first recovery completes. The mirror path has been found and the recovery will begin
momentarily.
Full recovery pending The data on one server is not up-to-date and has to be recovered from the other server
using a full recovery. The mirror path has been found and the recovery will begin momentarily.
In log recovery The data on one server is currently in log recovery. This is a temporary state. Please wait for
recovery to complete.*
In full recovery The data on one server is currently in full recovery. This is a temporary state. Please wait for
recovery to complete.*
Status not defined Information is unknown because the server is down, or unreachable and the server cannot
communicate. Ensure servers are started and verify network connectivity.
Action may have to be taken, see Forcing On-line in this topic for important information.
Unknown The DataCore Server is up, but does not know what the status is because the status from the other
DataCore Server is not defined. Action may have to be taken, see Forcing On-line in this topic for important
information.
Double failure Both servers have failed and the source of the failure should be determined and corrected. The
data on both servers should be evaluated and the most valid side should be forced up in order to recover. Action

will have to be taken, see Forcing On-line in this topic for important information.
Source: http://www.datacore.com/SSV-Webhelp/mirroring_and_mirror_recovery.htm