On Thu, Oct 29, 2020 at 1:10 AM Madhu Rajanna <mrajanna@xxxxxxxxxx> wrote: > > A couple of scenarios we may need to consider for fencing. > > * Fencing the workload of a namespace, when we want to move workload only for a namespace, not for > all namespace (the non-critical workload won't be moved to the secondary site but they need to be started again once the primary cluster is recovered). Couldn't each Ceph namespace utilize a different CephX user? In the case of sync (metro) DR or isolating multiple k8s clusters are independent tenants sharing the same Ceph cluster resources, it seems like this would just be different CephX users. > * Few applications which are critical in a namespace may need to be fenced(applications may be running on the different nodes) when they moved to the secondary site. > * We also need to revert back to the same state(unblocklist) once the primary cluster is recovered. That was why I was proposing the revocation list idea since there would be no need to blocklist / unblocklist. The revocation list would force a client to obtain a new ticket -- but by that time the caps should have been updated to revoke its privileges as needed. > * Do we need to consider anything In the case of Async DR? if the primary cluster control plane is dead? For RBD, this would be a forced-failover so there actually would be no need for fencing since it's handled as a split-brain event. Plus, the nature of async DR implies that you have two separate Ceph clusters. > Or do we need to fence all the clients in the primary cluster in case of DR? > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx > -- Jason _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
