Important Notes:In this topic:
Physical disks managed by SANsymphony software are used to create virtual disks. A virtual disk is a storage resource made to look and behave like a complete disk volume when presented or "served" to a host. The host will discover and use the virtual disks in the same manner as locally-attached physical disks. Virtual disks can range in size from 8 MB to 1024 TB (or 1 PB). Virtual disks are created from "storage sources" on either one or two DataCore Servers, depending on the type of virtual disk created. A storage source is the internal software representation of a virtual disk in a disk pool on a server.
Virtual disks can be created from two types of storage sources:
o Disk pools - Virtual disks from pools can be created in sizes ranging from the size of one storage allocation unit (SAU) to a maximum of 1024 TB (or 1 PB). See Disk Pools.
o Pass-through disks - This is the term we use to identify a disk that contains existing operating systems and data that must be preserved. A pass-through disk is used as a means of migrating existing data into or through the SANsymphony configuration. See Pass-through Disks.
Four types of virtual disks can be created:
o A single virtual disk is created from a single storage source on one DataCore Server (one data copy). The storage source can be a pass-through disk or disk pool. The single virtual disk has no fault tolerance in the event of a server or pool failure.
o A mirrored virtual disk is created from storage sources (disk pool or pass-through disk) from two DataCore Servers in the same server group (two data copies). Data is "synchronously” mirrored between the storage sources, meaning that the write acknowledgement is not returned to the requesting host until the data has been written to both DataCore Servers. Mirroring is the process of keeping the virtual disk data identical on the servers. A mirrored virtual disk is highly available and can remain operational if a server or pool fails or a path to the disk is disrupted.*
o A 3-copy virtual disk is created from storage sources (disk pool or pass-through disk) from three DataCore Servers in the same server group (three data copies). Data is "synchronously” mirrored between the storage sources, meaning that the write acknowledgement is not returned to the requesting host until the data has been written to all DataCore Servers. Mirroring is the process of keeping the virtual disk data identical on the servers. A 3-copy virtual disk is has extended data redundancy and can remain highly available to a host in the case of a server or storage source failure. See Dynamic Data Resiliency for more information about 3-copy virtual disks and automatic self-healing.*
o A dual virtual disk is created from the same storage source shared by two DataCore Servers and is comprised of one data copy. The storage source can be a shared disk pool or shared pass-through disk. A dual virtual disk can remain operational if one server fails or a path to the disk is disrupted, but has no fault tolerance at the storage level beyond that provided by the array. See Shared Multi-port Array Support for more information.
*Virtual disks with more than one data copy are collectively referred to as multi-copy virtual disks in the Help.
The virtual disk status reflects the health and availability of the data on the storage sources that compromise a virtual disk. In the case of mirrored virtual disks, it also reflects the comparison between the copies of data on each server and the mirror recovery (if any) needed to synchronize the data. See Virtual Disk Status.
To further identify special types of virtual disks used by the DataCore VASA Provider, subtypes are used:
· VVOL - Virtual disks created for use as virtual volumes in VMware. Snapshots created in VMware from VVOL virtual disks will also have the subtype VVOL.
· Protocol Endpoint (PE) - Virtual disks created for use as protocol endpoints in VMware.
Virtual disk types and subtypes are identified in the Virtual Disks List.
Write caching causes write operations to be recorded in the cache first and an acknowledgement is immediately sent back to the operating system confirming the operation before the write operation is written to physical disk. Write operations can be recorded in the cache much faster than to a physical disk. Because of this, write caching is enabled by default for single and mirrored virtual disks.
Cache memory is volatile. When a DataCore Server is stopped, cleanly shutdown or restarted, SANsymphony software will temporarily block the stop or shutdown until the cache is flushed. In a highly-available configuration, write operations failover to the other DataCore Server and the system puts the mirrored virtual disks into a forced write-through mode as long as one server is stopped or down. When the server is restarted, the software determines which server has the last known status and virtual disk mirror recovery occurs to resynchronize the data.
In the event of a "dirty" shutdown when the cache cannot be flushed and SANsymphony software cannot determine which server has the last known status, when the server is available again, the system will perform a full recovery to resynchronize all blocks of the virtual disk. See Mirror Recovery for more information.
Write caching is not supported for dual virtual disks, which are always in cache write-through mode. In write-through mode, all write operations to the virtual disk are written directly to the back-end storage and then acknowledged. Enabling write-through will affect performance, but is recommended for destination virtual disks used in replication.
Write caching for single or mirrored virtual disks can be disabled, in which case the virtual disk is put in "write-though" mode. Write-through mode is a virtual disk setting.
Important Notes:
o Although it may be possible to change write-through settings on a host in MPIO or the operating system, always change the write-through setting for a virtual disk using the Virtual Disk settings in SANsymphony software, see Changing Virtual Disk Settings for more information.
o Write caching may also be enabled or disabled for the server by using the cmdlets Enable-DcsServerWriteCache or Disable-DcsServerWriteCache, and using Set-DcsVirtualDiskProperties for virtual disks.
o Also see: UPS Support and DataCore Server and Server Group States.
Virtual disks improve on the flexibility, performance, reliability, and availability of standard physical disk storage resources.
o The Witness feature provides an additional layer of fault tolerance in the event that virtual disks lose all mirror paths and management paths and DataCore Servers are unable to communicate. This feature is particularly useful in clustered environments or when mirrored virtual disks exist in different site locations and inter-site communication fails. See Witness Feature.
o System Managed Mirroring addresses the complexity of managing multiple mirror paths for numerous virtual disks. Mirror paths can be automatically and silently managed by the software. The creation and management of mirror connections are based on the mirror role assigned to server ports. This is a server group setting. See System Managed Mirroring.
o The Dynamic Data Resiliency feature provides extended protection against failure scenarios by increasing availability and reducing periods without redundancy by adding an additional data copy to mirrored virtual disks. The advanced mirror capabilities of the Dynamic Data Resiliency feature can self-heal the 3-copy virtual disk manually or automatically without intervention and reduce recovery time by maintaining data redundancy in order to avoid full recoveries. See Dynamic Data Resiliency.
o The storage profile setting of a virtual disk specifies the importance of the data and determines the tier affinity, sets the replication transfer priority and the mirror recovery priority. Custom storage profiles can enable a setting, Write-aware auto tiering, to allow auto-tiering to take write operations into account in addition to read operations to determine data temperature. See Storage Profiles.
o Virtual disk groups allow virtual disks to be grouped in order to perform the same operations on all members of the group simultaneously. See Virtual Disk Groups.
o Dual virtual disks can be created using one storage source (disk pool or pass-through disk) shared by two servers. See Shared Multi-port Array Support.
o Redundant paths can be established or removed as needed. The number of possible paths is only limited by the number of FC and iSCSI ports available in your machines. See Port Connections and Paths and Modifying Paths.
o Preferred mirror paths and preferred paths to back-end physical disks can be assigned when multiple paths exist. See Modifying Paths.
o Mirror recoveries can be paused/resumed or disabled for mirrored or dual virtual disks to mitigate the traffic caused by recovery I/O. See Mirror Recovery.
o The logstore can optimize mirror recovery by eliminating full mirror recoveries when data changes have been saved to the logstore. See Mirror Recovery.
o Quality of Service (QoS) is the management of I/O traffic in order to meet the demands of different applications or to limit utilization by restricting the amount of I/O operations and data transferred for virtual disk groups. QoS settings include limits for the number of I/O operations and the amount of data transferred. See Quality of Service.
o Virtual disk templates are used to duplicate properties and settings in order to create virtual disks in a standardized fashion. The template contains all basic properties of a virtual disk, including storage sources to use, as well as settings for features and System Health thresholds. Templates can be used to create virtual disks that uniformly fulfill the requirements of applications they are intended to support. See Virtual Disk Templates.
o Virtual disks can be created with a sector size of 4 KB in order to take advantage of the benefits of Advanced Format Drives (AFDs). See 4 KB Sector Support.
o Snapshots (point in time image of virtual disks) can be created when data is known to be good and used for a variety of applications including testing and to recover data. A preferred snapshot pool can be selected per virtual disk. See Snapshot and Snapshot Operations.
o Virtual disks can be protected by preserving data changes in a history log for a period of time. When logical data errors occur, rollbacks (copies of virtual disks at specific times saved in the history log) can be created to recover data. See Continuous Data Protection (CDP) and Continuous Data Protection Operations.
o Virtual disks can be asynchronously mirrored to DataCore Servers at remote locations for off-site data backup, archiving over long distances, and disaster recovery. See Replication and Replication Operations.
o Mirrored virtual disks can be split and replaced by another storage source. Storage sources can also be moved to another pool. See Converting Virtual Disks to Another Type and Replacing or Moving a Storage Source in a Virtual Disk.
o The Maintenance Mode feature provides a way to move or evacuate virtual disk storage sources created from shared pools from one server to another in order to perform maintenance on a server without loss of high availability. After maintenance is performed, the virtual disk storage sources can be moved back or redistributed among other servers that share the same pool. See Maintenance Mode.
o Space can be reserved in pools for exclusive use by virtual disks when they are created or after creation in the virtual disk settings. See Disk Pools.
o Write caching can be disabled or enabled in the virtual disk settings. See Changing Virtual Disk Settings.
o The Sequential Storage feature stores write operations for a virtual disk sequentially instead of randomly which may improve performance for certain storage configurations. See Sequential Storage.
o Multipathing and ALUA support can be enabled at the host level. See Multipath Support.
o The Create Another feature will duplicate the properties and settings of an existing virtual disk to create new virtual disks. See Creating Virtual Disks.
o System health thresholds can be set for virtual disks. See System Health Thresholds.
o With the Encryption feature, virtual disk data can be encrypted at the backend level. See Encryption for more information.