Storage partitions

A storage partition groups the configuration for one or more applications that need to be managed together.

A storage partition allows for simplified and scoped management of the resources within the storage system or a larger FlashSystem grid environment. A storage partition acts as a virtual storage system with a focus on the logical resources that are used by an application.

Within a storage partition, all volumes must be in volume groups, and hosts can be mapped to volumes in the same storage partition only. Host clusters can contain hosts only in the same storage partition. Only SCSI hosts connected by using Fibre Channel or iSCSI are supported in storage partitions. vVols are not supported for NVMe-TCP and NVMe-FC hosts. Volumes in a storage partition cannot be mapped to other IBM Storage Virtualize systems. These rules ensure that storage partitions can be nondisruptively migrated to another system in the FlashSystem grid, or be configured for high availability without conflicting with other resources that exist on either of the systems.

New hosts, host clusters, volumes, and volume groups can be created in a storage partition. However, existing storage resources within the system cannot be added directly to a partition. A draft partition can be used to construct a partition with existing objects that meets the requirements of a partition. Some of the requirements of partitions are not enforced while constructing a draft partition. This allows the addition of resources to the partition iteratively as the dependencies between application are identified and resolved. A draft partition can be published only when all the requirements of a partition are met. The GUI helps to add volume groups to the draft and indicate which volumes and hosts are added automatically. A draft partition cannot be migrated or made highly available.

Storage partitions and replication

Storage partitions can be configured to be highly available between two independent storage systems by associating a replication policy to the partition. Systems automatically ensure that the logical configuration, data, and management access are configured to be highly available by managing all provisioning activities and configuring the replication. You can assign a management IP address to a highly available partition, ensuring seamless failover for automation, monitoring and external tools. For more information about high availability, see High availability.

Two storage partitions in different systems can be linked together to allow replication for disaster recovery for one or more volume groups within the partition. Volume groups within the partition can be configured with different replication policies, allowing for different recovery point objectives, or selective replication of a subset of the volume groups. For more information about disaster recovery replication, see Disaster recovery.

The high availability and disaster recovery features can be configured simultaneously allowing for disaster recovery replication to be configured on volume groups within a highly available storage partition. This configuration allows for high availability between two production systems, with replication to a third system for disaster recovery. For more information, see High availability and disaster recovery (3-site replication).

Storage partitions can be migrated nondisruptively between systems. Highly available storage partitions cannot be migrated as data access is only permitted between two systems at any time. For more information about migrating storage partitions, see Migrating storage partitions between systems.

You can assign a static IP address to a partition to enable management access by using the command-line interface (SSH) and REST API. This can be used to manage the resources in the partition, even if the partition is migrated between systems. Use the partition panel in the management GUI to configure an IP address for a partition.
Note: The partition management IP address is always bound to the same Ethernet port as the system management IP address. When two system management IP addresses are configured, it is bound to the one with the lowest port number.

You can configure a second system IP. An Ethernet port cannot be selected for management IP and it is configured on the first system IP. In some scenarios, you can remove the first system IP and configure it on a different port. In that case, the management IP might be present on a different port and not on the current system IP.

vCenter partitions

You can register multiple vCenters from VMware vSphere servers with IBM® Storage FlashSystem or IBM Storage Virtualize, which helps VMware environments to achieve multitenancy. Each of these vCenters acts as a separate system and shares the resources on the storage system. Each vCenter is a self-contained unit (unaware of each other’s resources) that belongs to an ownership group.

A vSphere deployment can use both vVols and Virtual Machine File System (VMFS) datastores from the same storage system.

You can use a storage partition to manage the entire storage workload for a vSphere deployment. A common storage partition includes:
  • All VMFS datastore volumes as well as vVols managed by a single vCenter server.
  • The ESX server host-objects in that vSphere deployment.
All related storage resources corresponding to the vSphere deployment can be included in a single partition.
Deployment scenarios
VMFS-only deployment
If the deployment uses only VMFS datastores (no vVols), then the following lightweight approach is used:
  • Legacy mode: In this mode, storage partitions are not used for VMFS datastores and ESX hosts. However, features like policy-based high availability and partition migration are not available.
  • vCenter partition mode: A partition is used for managing VMFS datastores and ESX server host-objects. The VMFS datastore does not require a child pool or an ownership group.
vVol-only deployment
If the deployment uses only vVols, additional configuration is needed for managing the vVols. An ownership group, a dedicated user, and a child pool are required. All these resources are managed by using the vCenter server for the partition.
VMFS and vVol deployment
If the configuration uses both VMFS and vVols, then a single partition includes both of them. However, in such configurations, a common ownership group is required along with a separate child pool for vVols and VMFS.