Introduction and example workflow for volume mirroring Cinder Havana proposal

1. Volume Mirroring
Presenter: Avishay Traeger
avishay@il.ibm.com
IBM Research – Haifa
© 2013 IBM Corporation

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. 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. 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. 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. Single Cinder deployment: Admin setup
a
b
●
2 storage entities in a
single Cinder
deployment (e.g.,
controller, file system)
© 2013 IBM Corporation

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. 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. 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. 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. 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. 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. 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. 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. 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. 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