Multi-tenancy

Multi-tenancy in a FlashSystem grid enables service providers and teams with delegated administration to manage defined sets of resources independently. Multiple tenants, such as teams, customers, or logical groups, can share infrastructure with clear isolation, controlled access, and simple administration.

FlashSystem grid administrators define each tenant scope by grouping and assigning systems, storage partitions, and pools to that tenant. Tenant administrators then define and manage volume groups on their assigned pools and manage only the resources in their scope, without involvement at the grid level.

Multi-tenancy works with policy-based replication, policy-based high availability (HA), and other FlashSystem grid functions.

The system provides role‑based views that separate FlashSystem grid administration from tenant‑scoped operations. FlashSystem grid administrators see all systems and shared resources across the FlashSystem grid. Tenant administrators see only the systems and partitions that are assigned to their tenant.
FlashSystem grid administrator
Roles and responsibilities

FlashSystem grid administrators configure and maintain shared, cross‑system resources.

Scope and visibility
  • Systems: All storage systems in the FlashSystem grid, including product name, code level, hardware health, connectivity health, and pool availability.
  • Partitions: All partitions associated with all tenants, including replication topology, high availability status, disaster recovery status, migration status, placement evaluation, and volume group counts.
  • User groups: All tenant‑scoped user groups defined across the FlashSystem grid.
  • Pools: All child pools across systems, which are mapped to parent pools.
Typical tasks
  • Plan capacity and resource governance.
  • Configure high availability and disaster recovery.
  • Create and manage tenants and partitioning.
  • Maintain system health and perform system‑level maintenance.
Tenant administrator
Tenant administrators work within assigned systems and partitions.
Scope and visibility
  • Storage systems: Only systems assigned to the tenant, with health indicators and pool counts.
  • Storage partitions: Only partitions allocated to the tenant, with replication topology, HA/DR status, and volume group usage.
  • Tenant pools and user groups: Only tenant‑scoped pools and user groups.
Typical tasks
  • Create volume groups and volumes.
  • Add hosts and mappings.
  • Assign and manage protection policies within tenant scope.

Key concepts

Stable identity
Each tenant is represented on every system by an Ownership Group and identified consistently across the FlashSystem grid by a Tenant UUID derived from replication_link_uuid. This stable identifier supports cross‑system aggregation and conflict detection.
Separation of duties
  • Grid administrator: Owns partitions, HA pairings, DR topology, and cross‑system governance.
  • Tenant administrator: Owns volumes, hosts, mappings, and protection policy assignments within the tenant.
Pool model without quotas
The system creates child pools per tenant per system without fixed capacity reservations. Partitions in the FlashSystem grid determine the usable capacity that administrators control. This approach reduces capacity fragmentation and supports growth.

Before you begin (prerequisites)

Before configuring multitenancy on any system or adding any system into an existing tenant.
Ownership group capacity
Each system must have a free slot to create a tenant ownership group. For details, see Ownership groups. A system supports a defined maximum number of ownership groups. For more information, see Configuration limits.
Pool availability
Each system must have at least one parent pool. Tenant child pools are created from the parent pool. For details, see Pools.
System reachability
Each system must be reachable and responsive to complete tenant operations (create ownership groups, child pools, and user groups). If a system becomes unreachable, the configuration state shows pending, and the UI displays an error. Restore connectivity and retry.