Disclaimer : All the postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.


Shared Storage Pool(SSP) is a valuable ‘server based storage virtualization’ offering of PowerVM.
There are multiple use-cases where SSP fits better into the requirements of your data-center than any other solution. It is gaining popularity year-on-year with each announced release. With the enhancements implemented in PowerVM 2.2.4 there are multiple more tempting reasons on why it could become a valuable asset in your data-center. This blog on IBM developerWorks (https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power%20Systems/page/PowerVM%20Shared%20Storage%20Pool%20Enhancements) provides an overview of the key SSP enhancements in PowerVM 2.2.4.

There are a multitude of publications/blogs/videos available in Internet which talk at length on the features of Shared Storage Pool. In this article I am picking on some of the key SSP offerings in this release : SSP Tiers, Move LU, Resize LU; and showcase their usefulness.
Please Note : There is much more being offered in this release of SSP than meets the eyes.


1. SSP Tiers


With the introduction of Tiers, Administrators get the ability to segregate user data/storage based on their desired requirement/criteria( aka service-level agreement(SLA) ). For e.g. one very basic requirement could be to create a separate tier for each department : a) Based on the backed storage disk type and b) performance requirements of each department. Apart from the ability to choose a separate storage class for each tier; this functionality also provides the flexibility to selectively enable mirroring on required tiers.

Tiering provides administrators the ability to define different service-level agreements in the same Shared Storage Pool.

The figure below is a sample ‘Tiered SSP’ based virtualized storage implementation.
1. A separate mirrored SYSTEM TIER named SYSTEM_TIER has been created to provide space to store the metadata and other bookkeeping information of SSP. In this example the SYSTEM_TIER is mirrored and the failure groups are named as FG_1 and FG_2.
2. Other USER TIERs named MGMT_TIER, TIER_CLOUD(mirrored) and HR_TIER are created for different departments.
NOTE : There is a mix and match of different storage boxes across the tiers as per the requirements of each tier.

Shared Storage Pool Tiers

SSP Tiers

Tier creation command usage :
tier -create [-clustername ClusterName] [-sp StoragePool] -tier TierName: PhysicalVolume …

Failure Group ( Mirroring ) creation command usage :
failgrp -create [-clustername ClusterName] [-sp StoragePool] [-tier TierName] -fg FGName: PhysicalVolume …


Next figure shows Logical Units(LU) created in some of the tiers.
The sizes and type(thin/thick) of these LUs are as per the storage requirements of each of the Logical Partitions(LPARs). The VIOSes that serve these LPARs need to be part of the SSP cluster. SSP can span across multiple server boxes and requirements for LPARs across all these servers needs to be considered.

Shared Storage Pool LU created in Tier

SSP LU created in Tier

LU creation command usage :
lu -create [-clustername ClusterName] [-sp StoragePool] [-tier TierName] -lu LuName -size LuSize [-vadapter VadapterName [-vtd TargetDeviceName]] [-thick]


Next figure shows the LU-to-VHOST mapping on one of the VIOS’s which is part of the SSP cluster.
SSP LUs are assigned to client LPARs by mapping them to their corresponding vhost adapter’s. SSP LUs are seen as vSCSI disks in the LPAR.
Linux LPARs have been assigned 2 SSP LUs each, from Tier TIER_CLOUD.
AIX LPAR 1 has been assigned 2 SSP LU and AIX LPAR 2 has been assigned 4 SSP LU from Tier HR_TIER.

Shared Storage Pool LU mapped to LPAR vhost

SSP LU mapped to LPAR vhost

LU-to-VHOST mapping command :
lu -map [-clustername ClusterName] [-sp StoragePool] {-lu LuName | -luudid LuUDID} -vadapter vAdapterName [-vtd TargetDeviceName]


2. SSP Move LU


Due to changing business requirements it might be required to modify the service-level agreement for certain LUs. This release of SSP takes this requirement into consideration and provides the capability to move a LU from one tier to another. The LUs could be moved from one tier to another while it is being used by the client partition (aka Live Storage Mobility). Once move operation is complete, the moved LU is served from new tier(read new SLA).
In this example, there was a higher I/O throughput requirement for AIX LPAR 2 ( i.e. served from a faster tier ). A new tier named HR_TIER_FAST backed with faster storage disks was created in the SSP. Then the operation to move all the four LUs of AIX LPAR 2 to new tier HR_TIER_FAST was initiated.
NOTE : Oblivious of the LU movement, AIX LPAR 2 continues to use its disks.

Shared Storage Pool LU moved to a different tier

SSP LU moved to a different tier

Command to move a  LU to a different tier :
lu -move [-clustername ClusterName] [-sp StoragePool] {-lu LuName | -luudid LuUDID} -dsttier DestinationTierName [-nonrecursive]


SSP LU movement takes care of moving all the snapshots(rollback) of the moved LU.
If SSP is used by PowerVC for LPAR capture and deploy it creates a parent-child relationship between the captured(parent) and deployed(child) LU. ‘lu move‘ command on the parent LU moves the LU and all of it’s descendants. Option(-nonrecursive) could be used with the ‘lu move‘ command to move the parent LU alone.

The next figure shows the state of SSP once the LU movement is complete. Same LUs of AIX LPAR 2 are now being served from the faster tier HR_TIER_FAST.

Shared Storage Pool LU after movement to new tier

SSP LU after movement to new tier

The best part is that you could move the LU’s(one or multiple) back to the same tier or any other tier ( as deemed necessary ) later.


3. SSP Resize(Grow) LU


It is quite natural for the storage requirements of client LPAR to increase with time. With the flexibility of ‘Grow LU’ feature, the existing mapped disks of a client LPAR could be dynamically increased in size. This changed(increased) size would immediately reflect in the client partition and help meet the workload requirements.
As shown in the figure below one of the SSP LU mapped to AIX LPAR 1 is resized to a bigger size; and the change is immediately reflected in the client partition.

Shared Storage Pool LU resized(grown) in size

SSP LU resized(grown) in size

Command to increase the size of a LU :
lu -resize [-clustername ClusterName] [-sp StoragePool] {-lu LuName | -luudid LuUDID} -size NewLuSize


If you like a detailed explanation about these features, there is also a YouTube video in the IBM Power VUG channel which talks about the Shared Storage Pool version 5 update at great length : https://www.youtube.com/watch?v=7ef9He_0m-A.


There is hardly any reason on why you should ignore this key technological innovation in your data-center that would help you manage your own cloud storage(SSP) in a zifffyyyyy..



What do you think ?

Set your Twitter account name in your settings to use the TwitterBar Section.
%d bloggers like this: