Jump to: navigation, search

Difference between revisions of "Manila/Replication API Design"

(Created page with "== 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 heavi...")
 
(Replication Styles)
Line 6: Line 6:
  
 
There are 3 styles of DR that we would like to support in the long run:
 
There are 3 styles of DR that we would like to support in the long run:
# "replicated_writable" Amazon EFS-style synchronously replicated shares where all replicas are writable. Failover it not supported and not needed.
+
# "replicated_writable" - Amazon EFS-style synchronously replicated shares where all replicas are writable. Failover it not supported and not needed.
# "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.
+
# "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.
# "replicated_dr" Generalized replication with secondary copies that are inaccessible until after a failover.
+
# "replicated_dr" - Generalized replication with secondary copies that are inaccessible until after a failover.
  
 
== New APIs ==
 
== New APIs ==

Revision as of 20:46, 21 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.

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 (primary, in_sync, out_of_sync) and export locations.
  • Add share replica - Takes a share ID, an AZ, and a replica type. The share must be a type that support the requested replica type. The share must not already have a replica in the specified AZ. Replica type may be: writable, readable, or dr. 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 primary replica.
  • Resync share replica - Takes a replica UUID. Changes the state to Resyncing. Share replica must be Out of Sync.
  • Set primary 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.