Volume Mirroring (Havana Summit)

© 2013 IBM Corporation

Volume Mirroring

Presenter: Avishay Traeger

[email protected]

IBM Research – Haifa


Agenda

● Goal

● Definitions

● Example flow 1: Single Cinder deployment

– HA, shorter-distance DR● Example flow 2: Multiple Cinder deployments

– Longer-distance DR


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


Recovery Point Objective (RPO)Recovery Time Objective (RTO)

Recovery Point Objective Recovery Time Objective

How far back in time a disaster takes one

How long until operational after a disaster

RPO=0 synchronous copy RTO=0 hot backup site


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


Single Cinder deployment: Admin setup

● 2 storage entities in a single Cinder deployment (e.g., controller, file system)

a

b© 2013 IBM Corporation




● Mirroring is set up at a certain level (e.g., controller, file set)

a






● Admin must ensure network connectivity between mirror participants (e.g., a-b)

a







● Each may have one or more pools managed by Cinder which store volumes

a

b

volume_backend_name=pool1









● Each may have one or more pools managed by Cinder which store volumes

● Drivers report id of mirroring participant (e.g., controller, file set)

a

b

volume_backend_name=pool1mirroring_unit_id=a

volume_backend_name=pool2mirroring_unit_id=b





● Admin creates partnerships – storage pairs with the potential to mirror between them

a

b







● Admin creates partnerships – storage pairs with the potential to mirror between them

● Drivers report mirroring capabilities with each partner

a

b


mirroring_capabilities=[b, [sync,async], active-passive]


mirroring_capabilities=[a, [sync,async], active-passive]





Single Cinder deployment: User actions

● User creates a volume, specifying mirror requirements in volume type:sync, active-passive.Candidates: any in a/b

a

b







1





● User creates second volume, passes requirements in volume type, and first volume's id as scheduler hint.Candidates: any in a

a

b







1

2





● 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

a

b







1

2



Multi-Cinder deployment

Consider two or more Cinder deployments

ProblemThe 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

SolutionLocal Cinder communicates with a gateway, and the gateway calls public Cinder APIs on the other sites

a

b







Local cloud_id = primary

Remote cloud_id = DRsite1© 2013 IBM Corporation

Technology

Volume Mirroring (Havana Summit)