Skip to end of metadata
Go to start of metadata
 



Review Meetings Recordings:

High Level Functional Overview and Design Specifications

Problem Statement

    ViPR currently creates a new port group for every new masking view created in the VMAX array. Customers would like to predefine port groups, then ViPR users could

    choose an existing port group for provisioning.

Functional Requirements

    • Provisioning with port group specified: Users could specify port group when export volumes.
    • Port group operations: create, delete, register, deregister port groups.
    • Port group discovery: discover existing port groups in the array.
    • Port group replacement : change port group for existing masking views
JIRA ID1-Line DescriptionComments, notes, etc.
COP-24770Reuse port group for VMAX provisioning



Design Approach / High Level Implementation Details

    Discovery   

        The feature will discover port groups in the array as part of the vmax array discovery. It will distinguish the port groups that are created implicitly by ViPR provisioning 

        under the cover, so that those port groups could not be reused when provisioning.

        As part of the VMAX performance data collecting/metering discovery, it will calculate portMetric for the explicitly created port groups, by averaging the port metric of the

       port members in the port group. It will calculate the volume count for the port groups too. The volume count will be calculated by the volumes exported through the port group.

    Port Group Operations

        Provide APIs to create, delete, register and deregister port groups. Only registered port groups could be used for provisioning. Only API and CLI are supported, no UI.

    Provisioning With Port Group Specified

        In order to support selecting port group for the "Create volumes for a host" catalog service, create volume API will be changed to accept the port group parameter.

        when port group is specified, it will find the right  storage pool from the same storage system as the port group for volume creation.

        When port group is specified for volume export/export mask creation, it will allocate the storage ports from the port group for zoning, and will use the

        port group when creating the masking view in the array.

        If using UI catalog services for export volumes, or Create volumes for a host, available and valid port groups will be listed in the pull down list under the Advanced tab.

        Specifically, when using the Create volumes for a host catalog service,

                   If no export group exists for the selected host and virtual array, all available port groups in the virtual array will be listed

                   If it has existing export group for the selected host and virtual array, it would only list the port group used in the export group, and all available virtual array port

                        groups not belong to the same storage array as the used port groups in the export group.

         When using the export volumes catalog service, 

                   If no export mask exists for the selected host and virtual array, it will list all available port groups in the same storage array as the selected volumes and belong

                        to the virtual array that the volumes created from.

                   If it has existing export mask for the selected host and volumes, it would only list the port group used in the export mask. 

       

         We considered Stalin's suggestion to add flag to add an additional port group / export mask when users request to, but decided that would break subsequently existing

         functionality if additional volumes were added to the host or cluster as they would not be added to all the export masks / port groups. This needs to be addressed in some

         kind of export strategy that is persisted with the Export Mask and all the requisite changes to other code would have to be made.

    Ingestion

        Import port groups along with the masking views. when ExportMask is created in ViPR, it will set port group URI in the exportMask.

    Export Path Adjustment For Port Group (Stretch goal for Skywalker)

        The new service will support

                1. Change port group for a given export group along with path parameters

                2. Path adjustment within the port group

        Port group change could be done if the new port group has no storage port overlap with the old port group, since VMAX does not support to change the associated port group in

        a masking view. The workflow will add a new masking view in the array, as well as a new corresponding export mask in ViPR, then remove the old masking view and the old

        export  mask later. It will give an option for users to wait or suspend the workflow before remove the old masking view so that they could make sure the new masking view take

        effect before the old one is removed. As part of the workflow for replacing the port group or changing paths, host rescans will be done as in export path adjustment.

        Users could use this new service to just change the path parameters (MaxPaths, MinPaths, PathPerInitiators), without changing port group for exports using existing port groups.

                Users could not use existing export path adjustment service added in Anakin to do export path adjustement for export masks using explicitly created port groups.  They have to use

        this new service. The big difference for this new service regarding to export path adjustment is that ViPR would not modify the explicitly created port group used in the masking view.

        In fact, explicitly created port groups are treated as immutable by ViPR for all operations.
          

    Configuration Setting:

           A new Controller config setting "Use Existing Port Group" is added to "VMAX Masking". By default, it is set to false. Users need to turn it on so that provision with the selected

           port group would work as expected.

           When this setting is on, ViPR will not create port group implicitly in VMAX as part of the export operation, it would expect users to specify an explicitly created port group when

           create a masking view in the VMAX array.

           

  •     API Changes

  •          
  •           added APIs
    • APIComment
      GET /vdc/storage-systems/systemURI/storage-port-groupsGet all port groups in the VMAX storage system

      GET /vdc/storage-systems/systemURI/storage-port-groups/portgroupURI


      Get storage port group details
      <storage_port_group>
        <id>urn:storageos:StoragePortGroup:db9926dc-f170-406f-af67-8457a1f57709:vdc1</id>
        <name>c1_372_PG</name>
        <tags/>
        <native_guid>SYMMETRIX+000197800372+c1_372_PG</native_guid>
        <registration_status>REGISTERED</registration_status>
        <storage_system>
          <id>urn:storageos:StorageSystem:a64d7740-36dc-4112-8897-a8dbb0bd832b:vdc1</id>
          <link rel="self" href="/vdc/storage-systems/urn:storageos:StorageSystem:a64d7740-36dc-4112-8897-a8dbb0bd832b:vdc1"/>
        </storage_system>
        <storage_ports>
          <storage_port>
            <id>urn:storageos:StoragePort:c5de682f-1ecc-481d-a30b-375829bf1b15:vdc1</id>
            <link rel="self" href="/vdc/storage-systems/urn:storageos:StorageSystem:a64d7740-36dc-4112-8897-a8dbb0bd832b:vdc1/storage-ports/urn:storageos:StoragePort:c5de682f-1ecc-481d-a30b-375829bf1b15:vdc1"/>
            <name>FA-1D:8</name>
          </storage_port>
        </storage_ports>
      </storage_port_group>
      
      
      Get details of one port group
      GET /vdc/varrys/varryURI/storage-port-groupsGet all port groups belonging to a virtual array

      POST /vdc/storage-systems/systemURI/storage-port-groups/

      Create a storage port group payload
      <storage_port_group_create>
        <name>portgroup1</name>
        <storage_ports>
          <storage_port>porturi1</storage_port>
          <storage_port>porturi2</storage_port>
          ...
        </storage_ports>
        <registered>true</registered>
      </storage_port_group_create>
      Create a port group
      POST /vdc/storage-systems/systemURI/storage-port-groups/portgroupURI/registerRegister a port group
      POST /vdc/storage-systems/systemURI/storage-port-groups/portgroupURI/deregisterDeregister a port group
      POST /vdc/storage-systems/systemURI/storage-port-groups/portgroupURI/deactivateDelete a port group


      Modified APIs

      APIComment

      POST /block/volumes
      port_group (port group URI) is added to volume_create parameters as an optional parameter

      Create volume sample payload
      <volume_create>
      <name>vmaxvolume</name> 
      <project>urn:storageos:Project:1d0ed3c2-cf02-4ca1-a707-7538dc4beff1:global</project>
      <varray>urn:storageos:VirtualArray:4debc822-d56b-48ed-a642-53ba7a004687:vdc1</varray>
      <vpool>urn:storageos:VirtualPool:d7b3b882-f446-4e6f-b877-883068c5b977:vdc1</vpool>
      <size>20000000</size>
      <port_group>urn:storageos:StoragePortGroup:d391a63c-0f7b-4ed5-a1f0-8cd6668d38d6:vdc1</port_group>
      </volume_create>
      port group is used to place the right storage pool, which should be from the same storage system as the port group

      POST /block/exports
      PUT /block/exports
      port_group (port group URI) is added to path_parameters as an optional parameter

      Create export group sample payload
      <block_export_create>
          <name>exportgroup1</name>
          <varray>urn:storageos:VirtualArray:4debc822-d56b-48ed-a642-53ba7a004687:vdc1</varray>
          <project>urn:storageos:Project:1d0ed3c2-cf02-4ca1-a707-7538dc4beff1:global</project>
          <volumes>
            <volume><id>urn:storageos:Volume:34f735f0-ff4e-4d47-a53c-116b7ce81e9d:vdc1</id></volume>
          </volumes>
          <hosts><host>urn:storageos:Host:ab07877d-451f-42d2-a74e-81cc68060dc7:vdc1</host></hosts>
          <type>Host</type>
          <path_parameters><port_group>urn:storageos:StoragePortGroup:d391a63c-0f7b-4ed5-a1f0-8cd6668d38d6:vdc1</port_group></path_parameters>
      </block_export_create>
      port group is used as the port group when creating masking view in the VMAX array.
  •     CLI Support

  •         All new APIs are supported by CLI
  •         volume create command and exportgroup add_vol command are updated with the new optional portgroup parameter
  •     DB Changes

  •         Added portGroup attribute to the ExportMask.
  •         Added portGroup attribute to the ExportPathParams
  •         Added StoragePortGroup CF

Exclusions and Limitations

    • The port group feature is only supported for VMAX

Implementation Strategy

Implementation Timeframe

    • Skywalker

Virtual Team

    • Angry Nerds Scrum team

Testing Strategy

    • Sanity test will be added for new port group operations and provisioning.
    • QE will will create a test plan for this feature and provide test automation.
  • Here is a high level pictorial representation of the use cases 


Documentation Strategy

       Documentation needs to be updated to include the port group functionality.

Impact Evaluation

Public APIs and public functionality (end-user impact)

    • We are adding new APIs, no impact to existing APIs if do not use port group

Persistence model

    • There are DB changes, but no schema migration are needed.
    • It discovers port groups for VMAX, and saves them to DB.

Upgrades

    • No impact on upgrade.

Performance

    •  Not known issues

Deployment and serviceability

    • Will make sure to give clear error messages.

Developer impact, dependencies and conditional inclusion

    • No impact

Reviewed and Approved By

NameDateVoteComments, remarks, etc.
17 May 2017+1Approved
4/25/2017+1Approved






5/22/2017+1Approved
5/23/2017+1

Had a discussion with Tong and I agree with the approach.

I had recommended few suggestions which Tong is going to take care.

  1. User export mask userAddedVolumes() to determine port Group mutable.
  2. Port Group switches are definitely not a one time process ,and on every switch do we really want to create a new masking view? Tong will discuss with Julian and we can decide the best approach to handle this case.
4-12-2017+1Approved, see comments below please.
















  • The members of the CoprHD Technical Steering Committee (TSC) have been automatically added to your reviewer list
    • A majority of them must approve this document before the feature can be merged to a project integration branch (e.g. integration-*, release-*, master)
    • Please un-check the boxes next to their names when your document is ready for their review
  • Please refer to Design Approval Guidance for information on additional reviewers who should be added and the approval process
  • No labels

23 Comments

  1. Port Group Operations

            Provide APIs to create, delete, register and deregister port groups. Only registered port groups could be used for provisioning. Only API and CLI are supported, no UI.


    Will the API include ability to add/remove ports to the PG?  

    And what would the add/remove behavior be, in cases when something has been exported through the port group?

    And what about pre-existing port groups, will there be some awareness of unmanaged masking views that haven't been ingested but rely on a particular port group?

    1. No. we are not going to support modify (add/remove ports) the pre-existing PGs.

  2. "If using UI catalog services for export volumes, or Create volumes for a host, Available port groups for the virtual array will be listed in the pull down list under the Advanced tab"


    Please make sure you are listing array serial number next to group name.

    In a large and normalized environment, group names will be the same in all storage frames and will follow convention , something like a combination of all participating port names. It will be assumed that you are looking at some specific VMAX at the point when you are looking at port groups. So ViPR UI needs to reflect awareness of Symmetrix ID combined with the PG name 

    1. yes, it would be the format as VMAX ID + PG name, for exmaple: SYMMETRIX+000196801612+TestCluster1_PG

  3. A new Controller config setting VMAXUsePortGroupEnabled is added.


    thats a confusing parameter name. What do you mean "use port group enabled"? How else does it provision. That would be a normal question from customers.

    please change the name to "VMAXUsePreExistingPortGroup".  It can be true or false. It doesn't need to have the word "enabled". 

    1. The configuration name shows as "Use Existing Port Group" under the VMAX masking tab


  4. GET /vdc/storage-systems/systemURI/storage-port-groups/portgroupURI

    Can this API reflect, in addition to WWN of each participating port, also the actual name of the port?   No human can deal in WWNs, and not having them would cause initial POCs to require additional query. 

    If it is trivial to add another line into output of this API, could you please do it?

    Same for "storage system", could name of system be included? Something that would provide either label in UI or ID# of VMAX.

    1. I will add the native_guid attribute to the output, it includes the system name, for example SYMMETRIX+000196801612+TestCluster1_PG

      I would like to have this new API consistent with other existing APIs.


  5. About volume create API requiring PortGroup URI - I must say that it is a bit confusing, at volume creation level, to talk about port groups. If user knows the port group URI, then they know StorageSystem URI. We should add an optional StorageSystem URI parameter instead.  And then optional PortGroup URI parameter to the Export. That would make more sense, in context of each operation. 

    1. portgroup URI is not a required parameter for create volume, but an optional one. If user knows which host this volume is created for, and which port group would be used for export. it would be convenient for UI too, so that it does not have to another call to find which storage system the port group resides in.

  6. cust0040 wants to be able to guarantee that ViPR will not create any new port groups, or modify any existing port groups. 

    cust0040 would rather ViPR fails the provisioning that make changes to existing port groups landscape. 


    Please add another parameter, or make it explicit, that if VMAXUsePreExistingPortGroup is turned ON, ViPR will not alter existing port groups nor create new ones during provisioned, except if the specific PG APIs are called.

    1. ViPR will not modify pre-existing port groups for all operations (like addInitiators, remove Initiators for a host, export paths adjustment, etc)

      If the feature/setting is on, ViPR would not create new port groups as part of the provisioning. users have to specify which port group to be used.




  7. cust0040 voiced additional request to me, which I do not see reflected so far, and uncertain how it would work here - 


    If there is a performance need to provision via 2+ PGs, then there needs to be corresponding number of Masking Views, 1 per PG. 

    If there is an additional device/s provisioned, they need to be made visible on all Masking Views for the host. 


    Please let me know if above will be able to get satisfied with the plan as is.

    1. This will not be supported in Skywalker

  8. How will this work when tenant admins do the provisioning? Port groups are physical resources, and only users with system admin privileges should have access to these resources. How do we expect a tenant admin to be able to specify the port group URI?


    Do we expect that we need to have super users (like root) who have both tenant admin and system admin rights?

    1. actually port group is just a VMAX symaccess group of physical ports, in the same league as initiator groups and storage groups. 

      I think Tong is trying to combine feature to circumvent creating of them in normal provisioning (replacing create with reuse) and minimizing UI changes related to showing them. 

    2. As Stanislav mentioned, port group is logical group of storage ports. Tenant admins should be able to see the list of port groups available to the virtual array, and specify one of them for provisioning.

  9. In a large setup it is possible that a virtual array has several storage arrays underneath it. Even if a tenant admin can see the list of port groups available in a virtual array, they would find it difficult to correctly map a LUN to the proper port group, unless they have a clear physical picture of where the LUN is situated. The LUN may get placed in different arrays based on ViPR's placement logic. This will work fine in a single array setup but will get complicated in a large data center.


    Tenant admins only have a 'virtual' picture available to them – a volume belongs to a project and has a virtual pool and virtual array associated with it in their mind.


    In any case, I urge you to do some experiments by logging in as a tenant admin (and not root) to see the difficulties associated with this mode of selection.

    1. This feature is not for all ViPR customers for sure, but would fulfill the request by those customers who would like to manually select port groups by users, instead of ViPR creates them implicitly. 

  10. Reviewing this on 4/12/2017:

    1. I've always been a little uncomfortable with the "internal" designation for port groups. To me more descriptive would be "explicitly created" or "implicitly created". Explicitly created port groups would indicate port groups explicitly created by a human user. Implicitly created would be port groups vipr created as a side effect of doing an export operation.
    2. "will calculate port group metrics"... I assume only for explicitly created? Or also implicitly?
    3. "If using UI catalog services for export volumes, or Create volumes for a host, Available port groups for the virtual array will be listed in the pull down list under the Advanced tab" I think I know how this works, but it may be confusing to others. If you supply on a composite volume create/export request, the port group selected will limit the possible pool selections via a pool matcher to the storage system containing the port group. If this is done via the GUI, the list of available port groups will include all in the varray. Alternately, if the port group is is supplied as part of an export request for existing volume(s), the port group must be on the storage system containing (all) the volumes. If this is done via the GUI, the list of available port groups would be limited to the appropriate storage system.
    4. Under Export Path Adjustment section, please state that a) the existing adjustPaths order will return error if invoked on a export mask(s) using explicitly created port groups, and b) as part of the workflow for replacing the port group or changing paths, host rescans will be done as in export path adjustment.
    5. Please explicitly state that we considered Stalin's flag to add an additional port group / export mask, but decided that would break subsequently existing functionality if additional volumes were added to the host or cluster as they would not be added to all the export masks / port groups. This needs to be addressed in some kind of export strategy that is persisted with the Export Mask and all the requisite changes to other code would have to be made.
    6. Looking at test mind meld - how is the port group determined on the R2 side of a SRDF provisioning? This seems problematic in the current design. If supported, add SRDF test case to ingestion.
    7. Please explicitly state the explicitly created PGs are treated as immutable by Vipr.
    8. Please add link to review recording if available.

    Approving contingent on addressing my comments. Thanks. Tom

    1. Addressed all. for 6,  We are going to support SRDF provision, when export SRDF volumes, it will export R1 side of SRDF volume, so port group should belong to the same storage system as the R1 volume.

  11. Just a few questions:

    1. why do we need to distinguish between explicitly and implicitly create port groups? 
    2. Are port groups created with the new create port group API considered implicit or explicit? Maybe a better definition would be good – include created by vipr during provisioning under the covers, created by ViPR via the new API, ingested into ViPR... Any other way a port group can get created?
    3. Can we handle a mixed environment with both implicit and explicit port group creation? What about customers that have upgraded and as a result have implicit port groups and wish to use this new feature? Can customers flip the configuration option back and forth without issues?
    4. You mention that there are no upgrade considerations but you have a few new fields. Can you elaborate on how and when these fields are used and how the code will handle the possibility that they may be null? The test section mentions something about checking port group on existing event markers after upgrade. That doesn't seem to jive with there being no upgrade considerations.
    5. Are implicitly and explicitly created port groups represented differently with regards to the new fields? If so, this may become a maintenance issue going forward – always having to test two paths.
    1. Implicitly created port group is the port group created by ViPR provision under the covers, and ingested into ViPR when "use existing port group" is off.

      we want to distinguish implicitly created port group and explicitly created port group, because ViPR treat them differently when ViPR needs to modify the port group memberships, like add initiators, remove initiators, and export path adjustment. for explicitly created port groups, ViPR would not modify the port group memberships in all those operations. for implicitly port groups, it would work as of now.

      yes, we can handle a mixed environment, and users could flip the configuration. that's another reason we want to distinguish the implicit port group and explicit port group.

      The new field is optional. say for  ExportMask portgroup field. if portgroup field is null, then the exportMask uses implicit port group, which is true for all existing export mask.  After upgrade, those ExportMask port gorup field is null. it works the same way as the configuration setting is false. so we have the code to handle this case.

      implicit port group would not be set in ExportMask port group field. and it could not be used in ExportPathParam either