Volume Mirroring

Presenter: Avishay Traeger
avishay@il.ibm.com
IBM Research – Haifa

© 2013 IBM Corporation
Agenda
●

Goal

●

Definitions

●

Example flow 1: Single Cinder deployment
–

●

HA, shorter-distance DR

Example flow 2:...
Goal
●

●

Multiple consistent copies of selected volumes to mitigate
failures of varying degrees
Flexible framework for e...
Recovery Point Objective (RPO)
Recovery Time Objective (RTO)

Recovery Point Objective

How far back in time a
disaster ta...
Main technologies
●

Synchronous
–
–

●

Write to both copies before returning ACK
Always consistent

Asynchronous
–

●

W...
Single Cinder deployment: Admin setup

a

b

●

2 storage entities in a
single Cinder
deployment (e.g.,
controller, file s...
Single Cinder deployment: Admin setup

a

●

●

b

2 storage entities in a
single Cinder
deployment (e.g.,
controller, fil...
Single Cinder deployment: Admin setup

a

●

●

●

b

2 storage entities in a
single Cinder
deployment (e.g.,
controller, ...
Single Cinder deployment: Admin setup

a

●

volume_backend_name=pool1

●

●

volume_backend_name=pool2

●

2 storage enti...
Single Cinder deployment: Admin setup

a

●

volume_backend_name=pool1
mirroring_unit_id=a
●

●

volume_backend_name=pool2...
Single Cinder deployment: Admin setup

a
volume_backend_name=pool1
mirroring_unit_id=a

●

Admin creates
partnerships –
st...
Single Cinder deployment: Admin setup

a

●

volume_backend_name=pool1
mirroring_unit_id=a
mirroring_capabilities=[b, [syn...
Single Cinder deployment: User actions

a
volume_backend_name=pool1
mirroring_unit_id=a
mirroring_capabilities=[b, [sync,a...
Single Cinder deployment: User actions

a

●

2 volume_backend_name=pool1

mirroring_unit_id=a
mirroring_capabilities=[b, ...
Single Cinder deployment: User actions

a

●

2 volume_backend_name=pool1

mirroring_unit_id=a
mirroring_capabilities=[b, ...
Multi-Cinder deployment
Local cloud_id = primary
a
volume_backend_name=pool1
mirroring_unit_id=a
mirroring_capabilities=[b...
Upcoming SlideShare
Loading in …5
×

Volume Mirroring (Havana Summit)

663 views

Published on

Introduction and example workflow for volume mirroring Cinder Havana proposal

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
663
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
29
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Volume Mirroring (Havana Summit)

  1. 1. Volume Mirroring Presenter: Avishay Traeger avishay@il.ibm.com IBM Research – Haifa © 2013 IBM Corporation
  2. 2. Agenda ● Goal ● Definitions ● Example flow 1: Single Cinder deployment – ● HA, shorter-distance DR Example flow 2: Multiple Cinder deployments – Longer-distance DR © 2013 IBM Corporation
  3. 3. Goal ● ● Multiple consistent copies of selected volumes to mitigate failures of varying degrees Flexible framework for enabling mirroring technologies – Where? – Back-end: driver/storage ● Front-end: OS-level, hypervisor How? ● ● ● Several techniques for volume mirroring Biggest difference is RPO and RTO © 2013 IBM Corporation
  4. 4. Recovery Point Objective (RPO) Recovery Time Objective (RTO) Recovery Point Objective How far back in time a disaster takes one RPO=0  synchronous copy Recovery Time Objective How long until operational after a disaster RTO=0  hot backup site © 2013 IBM Corporation
  5. 5. Main technologies ● Synchronous – – ● Write to both copies before returning ACK Always consistent Asynchronous – ● Write to primary, ACK, forward to secondary ASAP Periodic – Accumulate changes and send to secondary periodically © 2013 IBM Corporation
  6. 6. Single Cinder deployment: Admin setup a b ● 2 storage entities in a single Cinder deployment (e.g., controller, file system) © 2013 IBM Corporation
  7. 7. Single Cinder deployment: Admin setup a ● ● b 2 storage entities in a single Cinder deployment (e.g., controller, file system) Mirroring is set up at a certain level (e.g., controller, file set) © 2013 IBM Corporation
  8. 8. Single Cinder deployment: Admin setup a ● ● ● b 2 storage entities in a single Cinder deployment (e.g., controller, file system) Mirroring is set up at a certain level (e.g., controller, file set) Admin must ensure network connectivity between mirror participants (e.g., a-b) © 2013 IBM Corporation
  9. 9. Single Cinder deployment: Admin setup a ● volume_backend_name=pool1 ● ● volume_backend_name=pool2 ● 2 storage entities in a single Cinder deployment (e.g., controller, file system) Mirroring is set up at a certain level (e.g., controller, file set) Admin must ensure network connectivity between mirror participants (e.g., a-b) Each may have one or more pools managed by Cinder which store volumes volume_backend_name=pool3 b © 2013 IBM Corporation
  10. 10. Single Cinder deployment: Admin setup a ● volume_backend_name=pool1 mirroring_unit_id=a ● ● volume_backend_name=pool2 mirroring_unit_id=b volume_backend_name=pool3 mirroring_unit_id=b b ● ● 2 storage entities in a single Cinder deployment (e.g., controller, file system) Mirroring is set up at a certain level (e.g., controller, file set) Admin must ensure network connectivity between mirror participants (e.g., a-b) Each may have one or more pools managed by Cinder which store volumes Drivers report id of mirroring participant (e.g., controller, file set) © 2013 IBM Corporation
  11. 11. Single Cinder deployment: Admin setup a volume_backend_name=pool1 mirroring_unit_id=a ● Admin creates partnerships – storage pairs with the potential to mirror between them volume_backend_name=pool2 mirroring_unit_id=b volume_backend_name=pool3 mirroring_unit_id=b b © 2013 IBM Corporation
  12. 12. Single Cinder deployment: Admin setup a ● volume_backend_name=pool1 mirroring_unit_id=a mirroring_capabilities=[b, [sync,async], active-passive] ● Admin creates partnerships – storage pairs with the potential to mirror between them Drivers report mirroring capabilities with each partner volume_backend_name=pool2 mirroring_unit_id=b mirroring_capabilities=[a, [sync,async], active-passive] volume_backend_name=pool3 mirroring_unit_id=b mirroring_capabilities=[a, [sync,async], active-passive] b © 2013 IBM Corporation
  13. 13. Single Cinder deployment: User actions a volume_backend_name=pool1 mirroring_unit_id=a mirroring_capabilities=[b, [sync,async], active-passive] ● User creates a volume, specifying mirror requirements in volume type: sync, active-passive. Candidates: any in a/b 1 volume_backend_name=pool2 mirroring_unit_id=b mirroring_capabilities=[a, [sync,async], active-passive] volume_backend_name=pool3 mirroring_unit_id=b mirroring_capabilities=[a, [sync,async], active-passive] b © 2013 IBM Corporation
  14. 14. Single Cinder deployment: User actions a ● 2 volume_backend_name=pool1 mirroring_unit_id=a mirroring_capabilities=[b, [sync,async], active-passive] ● 1 volume_backend_name=pool2 mirroring_unit_id=b mirroring_capabilities=[a, [sync,async], active-passive] User creates a volume, specifying mirror requirements in volume type: sync, active-passive. Candidates: any in a/b User creates second volume, passes requirements in volume type, and first volume's id as scheduler hint. Candidates: any in a volume_backend_name=pool3 mirroring_unit_id=b mirroring_capabilities=[a, [sync,async], active-passive] b © 2013 IBM Corporation
  15. 15. Single Cinder deployment: User actions a ● 2 volume_backend_name=pool1 mirroring_unit_id=a mirroring_capabilities=[b, [sync,async], active-passive] ● 1 volume_backend_name=pool2 mirroring_unit_id=b mirroring_capabilities=[a, [sync,async], active-passive] volume_backend_name=pool3 mirroring_unit_id=b mirroring_capabilities=[a, [sync,async], active-passive] b ● User creates a volume, specifying mirror requirements in volume type: sync, active-passive. Candidates: any in a/b User creates second volume, passes requirements in volume type, and first volume's id as scheduler hint. Candidates: any in a User creates a mirror relationship between the two volumes and optionally starts the copy © 2013 IBM Corporation
  16. 16. Multi-Cinder deployment Local cloud_id = primary a volume_backend_name=pool1 mirroring_unit_id=a mirroring_capabilities=[b, [sync,async], active-passive] volume_backend_name=pool2 mirroring_unit_id=b mirroring_capabilities=[a, [sync,async], active-passive] volume_backend_name=pool3 mirroring_unit_id=b mirroring_capabilities=[a, [sync,async], active-passive] b Remote cloud_id = DRsite1 Consider two or more Cinder deployments Problem The mirror I/O is unchanged, but we can't control placement on the remote cloud and don't want the local driver calling the remote driver directly Solution Local Cinder communicates with a gateway, and the gateway calls public Cinder APIs on the other sites © 2013 IBM Corporation

×