Difference between revisions of "Manila/Replication API Design"

Revision as of 01:47, 22 July 2015

Intro

The Manila DR API will be implemented as an extension to the Manila API (not part of core) initially, because we want to prove the concept without investing heavily in support in reference implementation (generic driver) or automated testing/CI.

Replication Styles

There are 3 styles of DR that we would like to support in the long run:

1. "replicated_writable" - Amazon EFS-style synchronously replicated shares where all replicas are writable. Failover it not supported and not needed.
2. "replicated_readable" - Mirror-style replication with a primary (writable) copy and one or more secondary (read-only) copies which can become writable after a failover.
3. "replicated_dr" - Generalized replication with secondary copies that are inaccessible until after a failover.

Replica States

Each replica has a state which has 3 possible values:

1. Active - All writable replicas are active
2. In Sync - Passive replica which is up to date with the active replica, and can be promoted to active
3. Out Of Sync - Passive replica which has gone out of date, or new replica that is not yet up to date

New APIs

We will implement a Manila extension that includes several new APIs needed to support replicated shares.

• List share replicas - Takes a share ID. Returns a table of replicas with details. Must be a replicated share. Details include AZ, replica state (active, in_sync, out_of_sync) and export locations.
• Add share replica - Takes a share ID, and an AZ. The share must not already have a replica in the specified AZ. Returns replica UUID (actually share instance UUID).
• Remove share replica - Takes a replica UUID. Deletes the replica, regardless of state. Must not be the only active replica.
• Set active replica - Takes a replica UUID. Make that replica writable. Must be a non-writable replica and the state must be In Sync.

Changes to existing APIs

• Share type APIs will have 3 new user-visible extra specs - replicated_writable, replicated_readable, and replicated. These indicate to the user that replication is supported, and what style of replicas may be created.
• Share list/details APIs will return the replication style (writable, readable, dr) and a flag if more than one replica exists.
• Create snapshot - creates snapshots of all the replicas
• Delete share/snapshot - deletes ALL replicas of the share/snapshot
• Migrate/retype/etc - only the primary replica is considered as the source

Network issues with multi-SVM and replication

!!OPTIONAL!!

If we choose to make replication a single-svm-only feature, the share-network API doesn't need to change. In order to support replication with share-networks, we also need to modify the share-network create API which allows creation of share networks with a table of AZ-to-subnet mappings. This approach allows us to keep a single share-network per share (with associated security service) while allowing the tenant to specify enough information that each share instance can be attached to the appropriate network in each AZ. Multi-AZ share networks would also be useful for non-replicated use cases.