Shared Multi-port Array Support

In this topic:

About Shared Multi-port Array Support

Shared disk pools

Dual virtual disks

Migrating virtual disks from non-shared storage resources to dual virtual disks

About Shared Multi-port Array

The Shared Multi-port Array (SMPA) feature provides support for shared multi-port arrays. A shared multi-port array contains physical disks that are "shared" by two or more DataCore Servers in the same server group. In order to share a physical disk, back-end paths must exist from the physical disk to each server that is sharing the storage. Shared Multi-port Array support is a licensed option that is required to create dual virtual disks.

When a pool is created and one or more shared physical disks are added to the pool, it becomes a "shared" disk pool.

Pass-through disks can also be "shared" by two or more servers in the same server group.

Virtual disks that are created from two servers sharing the same disk pool or pass-through disk are referred to as dual virtual disks.

Requirements for a Shared Multi-port Array

  • A storage sub-system that provides fault tolerant disks to at least two DataCore Servers in the same server group. Any number of DataCore Servers may share the array. Storage must be qualified for SMPA.

    For a list of qualified shared multi-port arrays with minimum firmware versions supported, refer to the Qualified Lists on the DataCore Technical Support Portal. (This information can be viewed by registered customers with a login to the DataCore Technical Support Portal.)

  • Support for PRES SCSI commands:
    • PERSISTENT RESERVE IN
    • PERSISTENT RESERVE OUT
  • Support for PRES types:
    • Exclusive Access (type 3h)
    • Exclusive Access Registrants Only (type 6h)
  • DataCore Servers must see back-end disks as a single device regardless of the number of back-end paths.

    If using Windows MPIO, add the Vendor and Product ID string DataCoreVirtual Disk in the MPIO Properties. This should be done before creating back-end paths.

To create a shared multi-port array:

  1. Decide which presented disks from the storage sub-system are to be shared.
  2. Use the shared multi-port array user interface to create back-end paths between those physical disks and each DataCore Server that will share the disks.
  3. Rescan ports of those DataCore Servers. The disks should appear in the DataCore Servers panel under Physical Disks for each server with a path to the shared physical disks.

Shared Disk Pools

A shared disk pool is a disk pool that contains one or more shared physical disks from a shared multi-port array. All servers that share the physical disks in the pool can participate in the pool administration. Changes to the properties of a shared disk pool on one server will be reflected on all servers sharing the pool.

The main advantage of a shared disk pool is that it maintains high availability without the need to double the provisioned storage capacity. A disadvantage is that the shared disk pool has no fault tolerance at the storage level, beyond that provided by the array.

A shared disk pool can function either as an authorized SMPA or non-SMPA (not authorized for SMPA) pool depending on licensing and the characteristics of the pool. Shared disk pools are considered non-SMPA until authorized as SMPA pools.

Characteristics of an authorized SMPA pool:

  • The pool is "actively shared".
    • All servers with storage sources in the pool are equal and active participants in the pool administration by sharing all physical disks added to the pool. This is sometimes referred to as "active/active" mode, meaning that front-end traffic can be directed to any server sharing the virtual disk.

      For example, if Server1, Server2, and Server3 have storage sources in the pool and all disks added to the pool are shared by those three servers, a dual virtual disk created from Server1 and Server2 will allow traffic from all three servers.

    • Dual virtual disks are created from the pool. (Single and mirrored virtual disks may exist in the pool, however, the creation of dual virtual disks requires an authorized SMPA pool.)
    • All back-end LUNs created from the array and served to the participating servers of a shared pool (regardless of using Windows MPIO or native drivers) must be in "failover only" mode, otherwise this could lead to an unqualified SMPA configuration and a path failure could result in loss of access.
  • The DataCore Servers sharing the pool must be licensed for Shared Multi-port Array.
  • The pool must be shared multi-port array approved, meaning that all pool disks are acknowledged by the administrator as qualified shared multi-port array disks.
    • Certain actions that require more than one server in the pool will prompt an administrator to acknowledge that all pool disks are qualified for use in an actively shared pool. For instance, creating dual virtual disks, or creating mirrored or single virtual disks from two servers, as well as partially replacing or moving storage sources to another server.
    • When acknowledged, the Shared Multi-port Array Approved check box is automatically enabled in the Disk Pool Details page>Settings tab. The check box can also be enabled manually for a shared disk pool before being prompted.

      Enabling the check box does not authorize the pool for SMPA. The check box only acknowledges that the pool consists of qualified SMPA disks.

  • Pool mirrors cannot exist in the pool. (Pool mirrors will prevent the pool from being authorized as an SMPA pool.)

Characteristics of a non-SMPA pool:

  • The pool operates in "active/passive" mode, meaning that front-end traffic can only be directed to one server with a storage source in the virtual disk.
    • The pool may consist of shared and non-shared physical disks.
    • Limitations are imposed on any non-shared storage. Pool administration and virtual disk creation will be limited to certain servers:
      • A non-shared disk can only be added to a shared disk pool on the server the pool was created on. Attempts to add non-shared physical disks to the pool on any other server will fail.
      • If virtual disks exist in the pool, new virtual disks can only be created from the server that the pool was created on. Virtual disks cannot be created from any other server.
      • If no virtual disks exist in the pool, virtual disks can be created on any server, but consequently, that server will be the only server authorized to create virtual disks and receive I/O.
      • The pool cannot be approved as a shared multi-port array and therefore, dual virtual disks cannot be created from it.
  • Pool mirrors can be added to the pool, however adding pool mirrors will prevent the pool from functioning as an actively shared disk pool with dual virtual disks.
    • Virtual disks created from a non-SMPA pool containing pool mirrors, can be evacuated provided that all virtual disks are evacuated. See Maintenance Mode for more information.

Important Notes About Shared Pools

  • Failure of the same disk on any of the servers sharing a pool will cause the entire pool to fail. Access to data is lost if the shared disk pool is failed. Shared physical disks added to the disk pool must have some level of RAID protection.
  • It is highly recommended to use separate pools for shared and non-shared physical disks. In order to take advantage of the flexibility of a shared disk pool, the best practice is to ensure that all servers which may be participating in the pool administration should share ALL physical disks added to the pool.
    • When this practice is followed, all servers can add physical disks and create virtual disks from the shared disk pool.
    • When this practice is not followed, the pool will be non-SMPA and behave as an "active/passive" shared pool. Limitations are imposed on any non-shared storage in it and pool administration and creating virtual disks will be limited to certain servers.
  • Servers must have access to all physical disks in the pool in order to create a virtual disk from that pool.
  • Once virtual disks are created from the pool, all physical disks added to the pool must be shared by all servers that have created virtual disks from that pool.
  • To prevent uncoordinated access to shared physical disks, join DataCore Servers in a server group before configuring disk pools.

To create a shared disk pool:

Three different virtual disk types can be created from a shared disk pool:

  • Dual virtual disks - Created from a shared disk pool by two DataCore Servers. In order to create a dual virtual disk, the Dual type must be selected when the virtual disk is created or a single virtual disk may be converted to a dual virtual disk. The creation of dual virtual disks requires an authorized SMPA pool.
  • Single virtual disks - Created from a shared disk pool by one DataCore Server.
  • Mirrored virtual disks - Created from a shared disk pool on one DataCore Server and any kind of storage source (unshared disk pool, shared disk pool, unshared pass-through disk, or shared pass-through disk) from another DataCore Server. This virtual disk type can be used to facilitate data migrations. (Mirrored virtual disks cannot be created from the same shared disk pool.)

Dual Virtual Disks

A dual virtual disk is created from the same storage source shared by two DataCore Servers. The storage source can be either a shared disk pool or shared pass-through disk. Dual virtual disks provide fault tolerance at the server level.

Dual Virtual Disks

  • The creation of dual virtual disks requires an authorized SMPA pool which operates in Active-active mode, meaning that front-end traffic can be directed to any server sharing the virtual disk.
  • To create a dual virtual disk, select the Dual virtual disk type in the wizard.
  • The following operations are supported:
    • Replication is supported, but replication test mode is not supported if the standby virtual disk is a dual virtual disk.
    • Full snapshots are supported; differential snapshots are not supported.
    • The Split and Unserve command is supported. When this operation is performed on a dual virtual disk, the result is a single virtual disk on one server. The virtual disk will be removed from the server that is selected in the Split and Unserve command. If the virtual disk is a snapshot source, it cannot be split.
    • A dual virtual disk can be converted to a mirrored virtual disk by first splitting the dual, which results in a single virtual disk, and then adding a mirror. See Converting Virtual Disks to Another Type.
    • A single virtual disk created from a shared disk pool or shared pass-through disk can be converted to a dual virtual disk. See Converting Virtual Disks to Another Type.
    • A mirrored virtual disk can be converted to a dual virtual disk. See Converting Virtual Disks to Another Type.
  • The following features and operations are not supported:
    • Differential snapshots (snapshots must be full snapshots)
    • Continuous Data Protection (CDP) and Sequential Storage (These features are supported for single or mirrored virtual disks created from a shared disk pool, but not for dual virtual disks.)
    • Write caching (dual virtual disks operate in cache write-through mode- write operations to the virtual disk are written directly to the back-end storage and then acknowledged.)
    • The Replace command is not supported since the dual virtual disk is created from one storage source.
  • Automatic reclamation may not occur for dual virtual disks in a shared pool. Manual reclamation may be required.
  • See the following section when migrating virtual disks created from non-shared storage sources to dual virtual disks from shared storage sources.

To create a dual virtual disk:

Migrating Virtual Disks from Non-shared Storage Sources to Dual Virtual Disks

This section provides instructions to migrate mirrored virtual disks created from non-shared storage sources to dual virtual disks created from shared storage sources. If migrating single virtual disks from non-shared storage sources, only perform steps 6 - 9 below. Instructions include adding back-end paths to storage to create shared physical disks. Dual virtual disks can only be created from shared disk pools or shared pass-through disks.

Before beginning, the Shared Multi-port Array license must be activated on all applicable servers in the group.

To migrate virtual disks:

  1. Ensure that mirrored virtual disks to be migrated are healthy and data is up-to-date. Verify that hosts are seeing all paths to the virtual disks.
  2. For each mirrored virtual disk to be migrated:

    In the Virtual Disk List or DataCore Servers panel, right-click on the virtual disk, point to Split and Unserve, then select the server with the virtual disk source to split off and unserve from the host.

    If the virtual disk is served to a host, all front-end paths from the selected server will be removed and that side of the virtual disk will be unserved from the host. (Front-end paths from the server that is not selected will be retained and that side of the virtual disk will remain served to the host. This is the storage source which will become "shared" in this process.)

  3. Click Yes on the confirmation message to continue. Each mirrored virtual disk will become two single virtual disks.
  4. Rescan ports of those DataCore Servers and verify that hosts have access to the served single virtual disks.
  5. Keep the unnecessary single virtual disks that were split and unserved until the migration process has been successfully completed, at which time they may be deleted.
  6. Use the shared multi-port array user interface to create additional back-end paths between the virtual disk storage and each DataCore Server that will share the physical LUNs.
  7. Rescan ports of those DataCore Servers to discover the new paths.
  8. Ensure that shared disk pools are healthy and seen as "shared" disk pools on all servers (see disk pool details page).
  9. For each single virtual disk:

    In the Virtual Disk List or DataCore Servers panel, right-click on the single virtual disk created from a shared storage source, point to Convert to Dual and select the server from the list that will share the virtual disk. (Virtual disks can also be multi-selected for this operation.)

  10. Rescan the hosts.
  11. Verify that hosts have access to the dual virtual disks from both paths. Verify that there are no I/O failures.