On Mon, Mar 5, 2018 at 2:07 PM, Brady Deetz <bdeetz@xxxxxxxxx> wrote: > While preparing a risk assessment for a DR solution involving RBD, I'm > increasingly unsure of a few things. > > 1) Does the failover from primary to secondary cluster occur automatically > in the case that the primary backing rados pool becomes inaccessible? There is no automatic failover since any clients to the RBD images would be at a higher level of integration that librbd would have no way to know about / interact with (i.e. how would RBD know how to kill a VM on DC1 and somehow restart the VM in DC2?). > 1.a) If the primary backing rados pool is unintentionally deleted, can the > client still failover to the secondary? Yes, the storage admin can force promote non-primary images on the DR cluster to primary. > 2) When an RBD image that is mirrored is deleted from the primary cluster, > is it automatically deleted from the secondary cluster? Yes, the deletion is replicated to the DR cluster without delay. The Mimic release offers a new "rbd mirroring delete delay = <delay in seconds>" configuration setting to keep a deleted image within the RBD trash bucket until the delay expires. > 2.a) If the primary RBD image is unintentionally deleted, can the client > still failover to the secondary? Yes, assuming deferred deletion is enabled and you discover the unintentional deletion prior to the expiration of the deletion delay. > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > -- Jason _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |