EndpointGroups and Endpoints in Swordfish

Hi, we are planning to add more info to the documentation and mockups. Here is my current understanding of how this all works.

Please let us know if this helps and with any suggestions for improvement.

Storage Groups
Storage Group: A management element that defines a set of volumes for purposes of mapping to hosts, replicating, and managing consistency. [Note: Remove references on FileSystem, Object, File… from descriptions in StorageGroup.]
Structural features
The storage group has three primary collections:
1) Each volume in the storage group is represented as an entry in a MappedVolumes array property.
- MappedVolumes []: Each entry that describes a volume referenced by this storage group.
o LogicalUnitNumber: a string that represents the address of the volume when accessed from hosts attached to endpoints defined by a ClientEndpointGroup.
o Volume: a reference to a Volume that belongs to this storage group.
2) Each the hosts are represented by entries in the ClientEndpointGroups collection. Each entry is itself a collection of EndpointGroups. Each entry in these EndpointGroups represents an endpoint of a host that will have access to the volumes of the storage group.
- EndpointGroup
o Identifier
o GroupType: Indicates that this group represents storage client or storage server endpoints: Client, Server.
o AccessState: All endpoints referenced by this endpoint group share the same accessibility . The states are Optimized, NonOptimized, Standby, Unavailable, and Transitioning.
o TargetEndpointGroupIdentifier: If this endpoint group represents a SCSI target group, the value of this property shall contain a SCSI defined identifier for this group, which corresponds to the TARGET PORT GROUP field in the REPORT TARGET PORT GROUPS response and the TARGET PORT GROUP field in an INQUIRY VPD page 85 response, type 5h identifier. See the INCITS SAM-5 specification.
o Preferred: Access via this group of endpoints is preferred.
o Endpoints: A collection of endpoints
3) Each the hosts are represented by entries in the ServerEndpointGroups collection. Each entry is itself a collection of EndpointGroups (see above). Each entry in these EndpointGroups represents an endpoint of a storage server or network component that provides access to the volumes of the storage group.

Additionally, each storage group has the following attributes:
- Identifier: A unique identifier in the context of the managed ecosystem that is persistent across instantiations of the manager (i.e. redfish service).
Note: This is separate from the id property that represents the managed representation of the modeled StorageGroup.
- AccessState: All volumes referenced by this storage group share the same accessibility to attached hosts. The states are Optimized, NonOptimized, Standby, Unavailable, and Transitioning. Different storage groups should be used to define alternate paths that have different access states to the same set of volumes.
- MembersAreConsistent
- VolumesAreExposed
- Status: Health and state of the storage group
o State: This value represents lifecycle state of the storage group.
o Health: This value represents the health of the storage group related to delivering expected service to its clients.
o HealthRollup: If this is a parent storage group, then this value represents health issues across any of the child storage groups.
- Links:
o ParentStorageGroups[]: Each storage group may be aggregated into other (parent) storage groups. This should be set by the implementation when a StorageGroup is added to a ChildStorageGroups collection in the parent.
o ChildStorageGroups[]: A storage group may be an aggregate of one or more other (child) storage groups.
o ClassOfService: A definition the service levels that must be provided by all volumes and over each of the connections of the storage group
- ReplicaInfo: Describes this storage group in its role as a replication target.
o ReplicaPriority: Governs the priority given to a background copy engine relative to IO from the host: Low, Same, High, Urgent.
o ReplicaReadOnlyAccess: Governs who has read only access from the host: SourceElement, ReplicaElement, Both.
o UndiscoveredElement: Describes whether the source or target is not modeled: SourceElement, TargetElement. (Note: Given model changes, this may be obsolete and if so, deprecated.)
o SyncMaintained: If true, Synchronization shall be maintained
o ReplicaRecoveryMode: Specifies when copy restarts after a broken link is restored: Automatic, Manual.
o ReplicaUpdateMode: Specifies when target is updated: Automatic, Manual.
o PercentSynced: Percent of work towards completing synchronization
o FailedCopyStopsHostIO: If true, the storage array shall stop receiving data to the source element if copying to a remote element fails.
o WhenSynced: Time
o WhenActivated: Time
o WhenDeactivated: Time
o WhenEstablished: Time
o WhenSuspended: Time
o WhenSynchronized: Time
o ReplicaSkewBytes: Maximum number of bytes that the target can be out of sync before switching to synchronous
o ReplicaType: The kind of replica: Mirror, Snapshot, Clone, TokenizedClone.
o ReplicaProgressStatus: Replication session status: Completed, Dormant, Initializing, Preparing, Synchronizing, Resyncing, Restoring, Fracturing, Splitting, FailingOver, FailingBack, Detaching, Aborting, Mixed, Suspending, RequiresFracture, RequiresResync, RequiresActivate, Pending, RequiresDetach, Terminating, RequiresSplit, RequiresResume.
o ReplicaState: State of the replication relationship: Initialized, Unsynchronized, Synchronized, Broken, Fractured, Split, Inactive, Suspended, FailedOver, Prepared, Aborted, Skewed, Mixed, Partitioned, Invalid, Restored.
o RequestedReplicaState: The requested state of the replica relationship, see ReplicaState.
o ConsistencyEnabled: Indicates that consistency is enabled for this replica. (Note: with updated design, this property may be obsolete.)
o ConsistencyType: A value of SequentiallyConsistent indicates that the source and target shall be sequentially consistent.
o ConsistencyState: Indicates the consistency requirements of the source: Consistent, Inconsistent.
o ConsistencyStatus: Current status: Consistent, InProgress, Disabled, InError.
o ReplicaRole: (Note: This is obsolete and should be deprecated.)
o Replica: A reference to the source of this replica
o DataProtectionLineOfService: Defines desired level of service for protection
 RecoveryGeographicObjectives: Size of the fault domain
 Recovery PointObjectiveTime: Time Interval defining how much source data can be lost on failure
 ReplicaType: The kind of replica: Mirror, Snapshot, Clone, TokenizedClone.
 MinLifetime: Minimum life of the replica
 IsIsolated: True asserts that the replica is in different fault domain.
 Schedule: Applies to periodic replicas.
 ReplicaClassOfService: The class of service for replicas related to this StorageGroup.
 ReplicaAccessLocation: Where the Replica will be accessed from. This may be different from either the source or target location.

- ReplicaTargets []: An array of references to other resources (likely other storage groups), that are target resources that are replicas sourced from this storage group
- AuthenticationMethod: with options of None, CHAP, MutualCHAP, and DHCHAP.
- ChapInfo []: An array of entries used to authenticate the endpoints of this storage group
o InitiatorCHAPUser: The username for CHAP authentication
o InitiatorCHAPPassword: A write-only credential used as the shared secret for CHAP authentication
o TargetCHAPUser: The CHAP username for 2-way CHAP authentication.
o TargetPassword: A write-only credential used as a CHAP secrete for 2-way CHAP authentication.
Behavioral Features
Creating a StorageGroup
POST /redfish/v1/StorageServices/<storagServiceId>/StorageGroups
Request body:
{
Prototype storage group with as much filled out as possible.
}
Response:
Location=/redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId>

Changing the set of mapped volumes
Replace MappedVolumes array as a whole.
PATCH /redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId>
{
"Id": "SG_abc_005",
“MappedVolumes”:[
(“LogicalUnitNumber”: “0”, “Volume”: {“@id”: "/redfish/v1/StorageServices/1/Volumes/3"}),
(“LogicalUnitNumber”: “1”, “Volume”: {“@id”: "/redfish/v1/StorageServices/1/Volumes/12341234"}),
…
]
]

Creating an EndpointCollection
POST /redfish/v1/StorageServices/<storagServiceId>/Endpoints
Request body:
{
Prototype EndpointCollection with Members filled out with Endpoints that belong to this collection.
}
Response:
Location=/redfish/v1/StorageServices/<storagServiceId>/Endpoints/<EndpointCollectionId>

Creating an EndpointGroup
POST /redfish/v1/StorageServices/<storagServiceId>/EndpointGroups
Request body:
{
Prototype Endpoint group with as much filled out as possible.
}
Response:
Location=/redfish/v1/StorageServices/<storagServiceId>/EndpointGroups/<EndpointGroupId>

Adding a client endpoint group --- can be combined with other updates. ---
PUT /redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId>
Request body:
{
"Id": "SG_abc_005",
"ClientEndpointGroups”:[
One or more EndpointGroups, can be by reference, ( or I think this can be an upsert where the EndpointGroup is created here.)
]
}
Response:

Adding a server endpoint group --- can be combined with other updates. ---
PUT /redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId>
Request body:
{
"Id": "SG_abc_005",
"ServerEndpointGroups”:[
One or more EndpointGroups, can be by reference, ( or I think this can be an upsert where the EndpointGroup is created here.)
]
}

Expose or Hide Volumes --- can be combined with other updates. ---
PUT /redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId>
Request body:
{
"Id": "SG_abc_005",
"VolumesAreExposed ”: true to expose and false to hide. This is an aggregate operation that includes all child storagegroups
}

Replication
The client must first select a DataProtectionLineOfService that specifies the service level requirements for the replication. Then the CreateReplica action is invoked to create a replica.
Assume this is the selected DataProtectionLineOfService /redfish/v1/StorageServices(1)/DataProtectionLoSCapabilities/SupportedLinesOfService/OnDemandSnapshot

POST /redfish/v1/StorageServices(1)/DataProtectionLoSCapabilities/SupportedLinesOfService/OnDemandSnapshot/CreateReplicas()
Request body:
{
"ReplicaRequests": [{
"ReplicaSource": {"@odata.id": "/redfish/v1/StorageServices/<storagServiceId>/StorageGroups/<storageGroupId> "},
"ReplicaName": "MySnapshot"
}]
}

This will create a snapshot relationship between the current storage group and a new storage group named MySnapshot (details are specified in the OnDemandSnapshot entry).