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 <w...@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 > w...@wesdillingham.com > LinkedIn > _______________________________________________ > ceph-users mailing list -- ceph-users@ceph.io > To unsubscribe send an email to ceph-users-le...@ceph.io -- Jason _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
