If I recall correctly, the recent ceph-iscsi release supports the
removal of a gateway via the "gwcli". I think the Ceph dashboard can
do that as well.
On Tue, Dec 3, 2019 at 1:59 PM Wesley Dillingham <wes(a)wesdillingham.com> wrote:
We utilize 4 iSCSI gateways in a cluster and have noticed the following during patching
cycles when we sequentially reboot single iSCSI-gateways:
"gwcli" often hangs on the still-up iSCSI GWs but sometimes still functions and
gives the message:
"1 gateway is inaccessible - updates will be disabled"
This got me thinking about what the course of action would be should an iSCSI gateway
fail permanently or semi-permanently, say a hardware issue. What would be the best course
of action to instruct the remaining iSCSI gateways that one of them is no longer available
and that they should allow updates again and take ownership of the now-defunct-node's
LUNS?
I'm guessing pulling down the RADOS config object and rewriting it and re-put'ing
it followed by a rbd-target-api restart might do the trick but am hoping there is a more
"in-band" and less potentially devastating way to do this.
Thanks for any insights.
Respectfully,
Wes Dillingham
wes(a)wesdillingham.com
LinkedIn
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io
--
Jason