A storage connectivity group is set of connectivity rules plus a hierarchical set of connectivity resources (including Virtual I/O Servers (VIOSs), Fibre Channel fabrics, and ports) that are allowed to access the same storage providers on behalf of deployed VMs. Storage connectivity groups are powerful tools that are used when deploying and migrating VMs to help determine where the VM can be placed. Storage connectivity groups check your host environment to ensure that the required connectivity can be achieved and select the physical ports used for connectivity during the initial volume attachment to a virtual machine.
The VIOSs facilitate sharing physical I/O resources between deployed virtual machines, own the physical Fibre Channel ports, and can belong to shared storage pool clusters. You can use storage connectivity groups to create custom distributions when deploying virtual machines.
For example, you could define a production storage connectivity group that would use a different set of VIOSs than a development storage connectivity group, even though both sets of VIOSs are connected to the same SAN Fibre Channel fabrics. The following illustration, which uses a PowerVM Shared Storage Pool for test and development workloads, shows how storage connectivity groups can be used to help arrange your environment:
With PowerVC 1.3, even more capability was added to storage connectivity groups. The new settings allow you to:
- Support independent sets of redundant FC fabrics in a managed environment.
- Connect to up to 27 fabrics.
- Specify how many ports to connect per fabric on each VIOS.
These settings apply at a fabric level. Consider this simplified connectivity resource hierarchy:
Host -> VIOS -> Fabric -> Port
This is a logical hierarchy since the physical fabric derives its identity from the switch fabric, not the VIOS. Think of the fabric as being a special â€śtagâ€ť on the port. Ports with the same tag fall into a logical fabric grouping.
As a general example, further assume that a fabric requirement is not met for fabric A. That situation eliminates all physical ports that are connected to fabric A from consideration for the VIOS being checked. If eliminating the fabric violates the fabric connectivity requirement of the VIOS, then that eliminates the entire VIOS from consideration. If removing the VIOS further violates the VIOS redundancy requirement of the storage connectivity group, then the host is removed from consideration and cannot support NPIV attachment by using this storage connectivity group.
Now we’re ready to review the actual new settings. Here is a storage connectivity group with new fields highlighted:
We’ll zoom in on the available for the NPIV Fabric Access Requirement. These settings control the fabric redundancy:
Every fabric per VIOS (Tries to ensure the most fabric redundancy)
Each VIOS in this group must have a valid port connection to every fabric in the fabric set.
Every fabric per Host
A member host must connect to every fabric in the fabric set through its VIOSs that are members of this storage connectivity group. If your fabric set has more than one fabric, then this setting tries to ensure fabric redundancy at a host level. However, not every VIOS needs to connect through redundant fabrics.
At least one fabric per VIOS (Easiest requirement to fulfil)
A VIOS member must own ports that are connected to at least one fabric in the fabric set to be considered valid. Otherwise, the VIOS is eliminated from consideration. This setting does not guarantee fabric redundancy, but it results in redundancy if your environment configuration supports it and if other storage connectivity group settings do not preclude it. For example, if a VIOS has connections to redundant fabrics A, B, and C, then volumes attach with triple redundancy. If only one fabric is connected, then only that one is used.
Exactly one fabric per VIOS (Same as the previous setting â€śAt least one fabricâ€ť)
The VIOS must own ports that are connected to at least one fabric in the fabric set. However, when volumes are attached by using this storage connectivity group, the physical port or ports that are connected to a single fabric in the fabric set are chosen. If you select this option, you do not get fabric redundancy for volume connections for a single VIOS and it does not guarantee fabric redundancy between VIOSes. It is useful for development workloads where redundancy considerations are secondary to consuming fewer connectivity resources, such as the NPIV connections on a port.
The fabric that is selected for connectivity is the one that has the most available NPIV connections when considering all of the ports that are connected to that fabric. If you want the attachments to always use a specific fabric, restrict the fabric set to contain only that specific fabric.
PowerVC 1.3 introduces the concept of a fabric set for storage connectivity groups. If you want the storage connectivity group to apply to just certain fabrics, instead of every fabric, deselect the â€śAssociate all fabricsâ€¦â€ť box and add specific fabrics. These fabrics become your fabric set.
The final new setting (refer to the first image of the new storage connectivity group settings) is â€śFor each VIOS, number of ports to connect per fabricâ€ť. This lets you specify the number of ports that must be connected per fabric in the fabric set for the member VIOS. These redundant ports are then chosen for hosting volume attachment connectivity. If the specified number of fabric-redundant ports cannot be used, NPIV connectivity is not allowed for that fabric and VIOS. In prior releases of PowerVC, only a single port per fabric on a given VIOS was ever selected. So this setting allows greater port redundancy required by certain enterprise workloads.
The default value is 1, which means that redundant ports per fabric per VIOS are not required, just like in past releases. In other words, no further restriction is placed on the NPIV Fabric Access Requirement setting. If you specify a value of 2, for example, then the NPIV Fabric Access Requirement must be met for two ports, per required fabric.
- If your environment has a significant number of cabled Fibre Channel port resources, you might use this setting to specify port redundancy per fabric and per VIOS while restricting connectivity from using all the physical ports that are cabled.
For example, assume that you have two 2-port adapters with all four ports cabled to fabric A. If you specify a value of 2 for this setting, it maps virtual client adapters through only two of those physical ports. The most under-utilized port is selected from Fibre Channel adapter 1 and the most under-utilized port is selected from adapter 2. That is, if a port on one physical adapter has been selected, then an available port on a second physical adapter is selected, even if there is a less used port available on the first adapter.
- You can use this setting in combination with other storage connectivity group settings to compute how many virtual client adapters (also known as virtual FC adapter mappings for NPIV) are used for volume connectivity. It is a one-to-one mapping for virtual client adapters to host physical ports.
For example, assume that you have dual VIOS redundancy, dual fabrics A and B in the fabric set, a fabric access requirement of Per VIOS, and a value of 2 for For each VIOS, number of ports to connect per fabric. On the virtual machine, a volume will be attached to eight virtual client adapters: 2 (VIOS) * 2 (fabrics) * 2 (ports) = 8.
As you can see, PowerVC 1.3 continues to deliver major capabilities for an already powerful facility, the PowerVC Storage Connectivity Group.
If you want to read more about storage connectivity groups, be sure to visit our knowledge center. If you have any questions about this or anything else, please post them in the comments, on our LinkedIn group, our facebook page, or our twitter account. Weâ€™d love to hear from you!