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. 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 (HA) 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 either volumes, or volume groups, or both to the draft partition and indicates which volumes, volume groups, and hosts are added to the partition automatically. A draft partition cannot be migrated or made highly available.

Management IP address for storage partitions

Each storage partition can be assigned a static management IP address, providing management access to the partition through CLI (SSH) or REST API. When a partition is migrated, the partition management IP address stays with the partition, ensuring continuous access for automation, monitoring, and external tools.

Use the partition panel in the management GUI to configure an IP address for a partition. When the partition management IP address is created, it is bound to the same Ethernet port as the system management IP. If multiple system management IPs are configured, it attaches to the port with the lowest number.

For more information, see Management access using partition IP address.

Partition-scoped and system-scoped resources

Storage partitions contain resources that are scoped to the partition, such as volumes, volume groups, hosts, and IP addresses. These resources move with the partition when it is migrated to another system. Some resources are scoped to the system and do not migrate with the partition. These resources include system users, user groups, and ownership groups. Partition users are user accounts that are scoped to a specific partition. Partition users move with the partition during migration and ensure that access to the partition is maintained on the target system.

Certificates for storage partitions

After you configure the management IP address, you can configure a partition certificate for a storage partition by using the CLI (SSH) or the REST API.

You can assign a certificate to each storage partition through the CLI (SSH) or the REST API. When a partition is migrated, the partition management certificate migrates with the partition. This behavior ensures continuous access for automation, monitoring, and external tools.

You can use the Storage partitions panel in the management GUI to configure a certificate for a storage partition.

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. When a storage partition operates in High Availability, certificate management for that partition is performed only from the Active Management System (AMS) and is restricted from all non‑AMS interfaces. For more information about HA, 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 HA 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 HA 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.

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 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 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, 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.

Managing storage partitions

You can combine storage partitions by using the management GUI or mergepartition CLI. This command groups existing resources, such as hosts, host clusters, and volume groups, from each partition into a single partition.

You can also split a storage partition by creating a draft partition and specifying the original partition as the source. Resources from the original partition can be added to the draft partition while they remain associated with the original partition. When you publish the draft partition, the resources move from the original partition to the new partition.

Manage storage partitions by using CLI commands:
  • Use the lspartition command to generate a list with concise or detailed information on storage partitions on the system.
  • Use the mkpartition command to create a storage partition.
  • Use the chpartition command to modify a storage partition.
  • Use the rmpartition command to remove a storage partition.