The December AIX Virtual User Group webinar featured Nigel Griffiths' discussion of phase 2 of shared storage pools. If you didn't tune in, download the presentation materials and listen to the replay.
The new shared storage pool functionality is enabled with the latest PowerVM 2.2 service pack, and is a feature of PowerVM Standard and Enterprise. If you already have PowerVM, simply download the VIO server fixpack to obtain these new features. (Note: Because this TL is based on AIX 6.1 TL7, your NIM server must be at AIX 6.1 TL7 or AIX 7.1 TL1 to use your NIM server with your VIO server.)
One thing to note, as Nigel points out in the presentation, is that the most common VIOS storage options have been around for some time:
1) Logical volumes, created from a volume group and presented to client LPARs
2) Whole local disks
3) SAN LUNs
4) File-backed storage, either from a file system on local disk or a file system on SAN disks
5) NPIV LUNs from SAN
Nigel then discusses the newest option: using SAN LUN disks that are placed into a shared storage pool. This new option, he emphasizes, doesn't eliminate any of the other options. It does not portend the death of NPIV. It's just an additional VIOS storage choice we now have.
Listen to the replay or look over the slides to gather Nigel's thoughts on the benefits of shared storage pools. He explains that fibre channel LUNs and NPIV can be complex. They require knowledge of the SAN switch and the SAN disk subsystem. If you need to make changes, it might take your SAN guys awhile to implement them. This can slow overall responsiveness. That's to say nothing of smaller organizations that don't have dedicated SAN guys. Live partition mobility can be tough work if your disks aren't pre-zoned to the different frames.
With a shared storage pool you pre allocate the disk to the VIO servers. Then it's under your control. You can more easily allocate the space to your virtual machines.
POWER6 and POWER7 servers (including blades) are needed to use shared storage pools. At minimum you should allocate a 1 GB of LUN for your repository and another 1 GB of LUN for data, but in order to be useful, in most cases you'll need much larger LUN(s) – think terabytes of disk -- if you plan to do much with it.
Your VIOS must have the hostname set correctly to resolve the other hostnames. In Nigel's experience he couldn't use short hostnames -- they had to be changed to their fully qualified names.
He also recommends giving your VIOS a CPU and at least 4 GB of memory. "Skinny" VIOS servers aren't advisable with shared storage pools. Currently, the maximum number of nodes is four, the maximum physical disks in a pool is 256, the maximum virtual disks in a cluster is 1,024, and the number of clients is 40. A pool can have 5 GB to 4 TB of individual disks, and storage pool totals can range from 20 GB to 128 TB. Virtual disk capacity (LU) can be from 1 GB to 4 TB, with only one repository disk.
If you played around with phase one, you'll find that many of your limits have been removed. Now you can use shared storage pools for live partition mobility, perform non-disruptive cluster upgrades and use third party multi-pathing software.
You cannot have active memory sharing paging disks on shared storage pool disks.
Nigel covers the relevant terminology (clusters, pools, logical units, etc.). He also demonstrates how to actually prepare and set up your disks. In a nutshell you must get your LUNs online and zoned to your VIO servers, and you need to set your reserve policy to no_reserve on your LUNs.
After covering the commands for managing clusters -- cluster –create, cluster –list, cluster –status, cluster –addnode, cluster –rmnode and cluster –delete -- he recommends creating the cluster on one of the VIO servers and then adding additional VIO servers to the shared storage pool cluster. From there, you can allocate space to the VM clients.
Next week I'll have more information from Nigel’s presentation, including scripts and cheat sheets. In the meantime, why not upgrade your test machine's VIO servers to the latest level so you can try this functionality?





Hi,
here are the few updates on SSP
Shared storage pool
----------------------------
Advantage:-
* simply the aggregation of larg number of disk accress multiple VIO server
* Improve the utilization of the available storage
* using the thin-provisioned, even after mapped a size of logical unit to the client, it will use only when the disk is start filling
Disadvantage:-
* client partition which used this SSP is not supports the live partition mobility
* The number of max client partition per VIOS in the cluster is 20
* The number of max physical volume in SSP is 128
* The number of maximum logical unit in the cluster is 200
* This will support only IP version 4
* minum LUN that mapped to the SSP should be 20GB
* Fiber channel over etnernet (FCoE) adapter not supported
* It will not support non-MIO, SDD, powerpath, legacy HDLM & so on)
* The client server in cluster will not support AMS & suspend/Resume
* The server does not supports SEA interrupt mode
* The logical volume that mapped to the client can't exceed 1TB
Important point:-
* At the time of creating the cluster, only single node per cluster & one single SP per clsuter supported
* The mapping will be the logical usit resides behind the SSP
* Clsuter ip address must be the first entry on /etc/hosts
* changing the hostname is not supported after the VIO is added as the part of clsuter
* Repository disk & SSP should have the redundany at the storage level
* At the time of writing, physical disk in SSP can't be replaced or removed
* only VIOS will be the part of this clsuter
* This clsuter using CAA( clsuter Aware AIX) & RSCT technology, So a network connection is must in between the nodes.
* "poold" daemon handle group services & "vio_daemon" is responsilbe for montior the clsuter & SSP health
prerequest:-
* Power6 & above
* Powervm standar or enterprise edition
* VIO 2.2.0.11 Fix pack 24 sp 1 or later
* Atleast 4GB memory
* client partition should be 5.3 or later
* The physcial drive in SSP should have the default PCM, SDDPCM, Powerpath PCM , HDLM PCM & so on)
* At the time of writing, the SSP supports a sinlge node in the cluster & it will work only when 'poold' & 'vio_daemon' is running
* Each VIOS in cluster requires at least one PV for CAA
Posted by: ramkumar | January 29, 2012 at 04:05 AM