Storage Hardware Guidelines to Use with DataCore Servers
Overview
Any Storage Array that is capable of providing SCSI-based disk devices to Microsoft Windows (on which SANsymphony runs), formatted with a 512 byte block size (any version) or 4k block size (versions 10.0.5 and later) can be used in the DataCore pools.
Storage that uses Disk Devices that are marked as "Removable" within Windows' Disk Management cannot be used.
Which specific Storage Arrays are 'qualified' for use with SANsymphony?
DataCore do not qualify specific Storage Arrays, as long as the criteria mentioned above in the previous section are met, all Storage Arrays are considered 'qualified'. However, not all Storage Arrays can be used with the SANsymphony Shared Multi-Port Array (SMPA) function; see the appropriate section on SMPA configurations below.
Some Storage Arrays do have specific configuration requirements to make them function correctly with SANsymphony. See
FAQ 1277: Known Issues for Third Party Components to see if your specific Array is mentioned.
Also some DataCore Vendors have their own Storage Solutions that they have tested and qualified as 'DataCore-Ready'. See DataCore Ready Partners for those Vendors.
Using the DataCore Fibre Channel Back-end Driver
A Storage Array that is connected to a DataCore Server using the DataCore Fibre Channel Back-end driver can also use DataCore's inbuilt back-end failover function as long as the LUNs from the Storage Array are connected to different back-end paths and/or different controllers on the Storage Array and the controllers are in an Active/Active configuration.
For a complete list of all Fibre Channel Host Bus Adapters that can use the DataCore Fibre Channel Driver Back End, see
FAQ 1529: Qualified Hardware Components.
Storage Arrays Connected without using the DataCore Fibre Channel Back-end Driver
A Storage Array that is connected to a DataCore Server but without using the DataCore Fibre Channel back-end driver can still be used. This includes SAS or SATA-attached, all types of SSD, iSCSI connections and any Fibre Channel connection using the Vendor's own driver.
Any storage that is connected in this way will appear to the SANsymphony software as if it were an 'Internal' or 'direct-attached' Storage Array and some SANsymphony functionality will be unavailable to the user including not being able to make use of SANsymphony's performance tools to get some of the available performance counters related to Storage attached to DataCore Servers. Also some potentially useful logging information regarding connections between the DataCore Server and the Storage Array is lost (i.e. not being able to monitor any SCSI connection alerts or errors directly) and may hinder some kinds of troubleshooting, should any be needed. Since there is no DataCore driver communicating with the storage, refer to the vendor's documentation on configuring the storage with a Windows Server (the operating system that DataCore SANsymphony resides on) for instructions. If the Windows operating system can access the LUN, SANsymphony should be able to use it in a pool provided it meets the disk requirements.
Storage Arrays Connected by ISCSI
SANsymphony does not have an iSCSI initiator driver; see the section Storage Arrays Connected without using the DataCore Fibre Channel Back-end Driver above.
Storage Arrays that are 'ALUA-capable'
The DataCore Fibre Channel back-end driver is not ALUA-aware so will ignore any ALUA-specific settings sent to it by the Storage Array. However SANsymphony can still provide ALUA-capable Virtual Disks to Hosts regardless if the Storage Array attached to the DataCore Server is ALUA-capable or not.
Using a Third-Party Failover Product
Third-Party Failover product (For Example: Branded MPIO) can be used directly on the DataCore Server. In the case where Storage Arrays are attached by Fibre Channel connections, do notuse the DataCore Fibre Channel back-end driver when using any Third-Party Failover product - use the Third-Party's preferred Fibre Channel Driver instead.
512b, 512(e)b, and 4Kbyte Sector Support
SANsymphony 10.0 PSP 5 and later included native support for Advanced Format Disks (AFD) on 4KByte sector format. See: DataCore Help > 4 KB Sector Support.
Earlier versions of SANsymphony did not support 4Kbyte sectors but Advanced Format 512e (also known as '512 emulation') could be used instead. Refer to your disk manufacturer for more details.
NVMe Storage
NVMe storage is supported on SANsymphony 10.0 PSP 2 or later.
RAID Stripe and Striped-set Sizing
SANsymphony's I/O size for any given request to the Storage Array can be anywhere between 4 Kilobytes to 1 Megabyte.
SANsymphony will always try to aggregate and coalesce as many I/Os for each Virtual Disk to send 'at once' to the Storage Array (up to a maximum of 1Mbyte), but it is still impossible to be able to predict the size of an I/O at any moment. However, it is possible to make a good, general recommendation for RAID stripe sizes based on this knowledge using the following method:
- Calculate the total number of Disks used in the RAIDset minus the number of Disks used for Parity.
For example:- A 3 Disk RAID5 set would use 2 Disks for the data and 1 Disk for the Parity.
- A 4 Disk RAID6 set would use 2 Disks for the data and 2 Disks for the Parity
- A 3 Disk RAID5 set would use 2 Disks for the data and 1 Disk for the Parity.
- Divide 1 MByte by the number of Disks used for the data to give the maximum stripe size to handle the 1MByte I/O size that SANsymphony can issue to the Storage Array.
For example: A 3 Disk RAID5 set would use 2 Disks for the data so the stripe size for the RAID5 set should be set to 1Mbyte / 2 = 512Kbyte each.
This is a general recommendation and is based on the maximum I/O size that a DataCore Server will issue and it is not guaranteed that all I/O sizes will be 1Mbyte.
Limit the number of individual partitions/logical volumes that are created from each RAID set from within the Storage Array.
SANsymphony distributes I/Os across all disk devices it discovers within a Disk Pool, if those individual disk devices (LUNs) are from the same RAID set it may lead to 'disk thrashing'; where a physical disk within the Storage Array's RAID set has to process I/O from many logical volumes at the same time. Disk thrashing in this case is especially likely for those Arrays that have high seek times (time to position the head) and may result in overall poor performance.
DataCore recommends not creating multiple disk devices (LUNs) from a single RAID set whenpresenting storage to a DataCore Server.
This does not apply to SSD disk devices.
Total LUN counts
Each LUN is seen by the operating system as one disk and has one I/O queue. The I/O queue is the "pipe" that transports I/Os between host and disk. The more I/O queues (disks) are seen by the host, the more I/Os can be transported in parallel. This is another reason for having more, smaller RAID sets instead of one large one.
Storage Arrays and SANsymphony Shared Multi-Port Array Configurations
While the preferred Storage Array solution for SANsymphony is to have each LUN from each Storage Arrays presented to each DataCore Server individually (for maximum redundancy), it is possible to 'share' the same LUN from the same Storage Array on all DataCore Servers in the same Server Group at the same time. This can be useful when using the Maintenance Mode feature of the software.
This type of configuration is known as a Shared Multi-Port Array (SMPA) configuration. This configuration though is less redundant - as the Storage Array itself becomes the Single Point of Failure. If dual type virtual disk are created these do not use SANsymphony's own Write Back caching for Write IO (Read IO is still cached). Not every Storage Array is supported for use in this type of configuration. Otherwise all of the storage guidelines listed above apply to SMPA storage as well.
For a complete list of all Storage Arrays that can be configured for use with the SANsymphony SMPA function, see FAQ 1485: Shared Multi-Port Array Tested Configurations.