Gateway removal is indeed supported since ceph-iscsi 3.0 (or was it
2.7?) and it works while it is offline :)
Paul
--
Paul Emmerich
Looking for help with your Ceph cluster? Contact us at
https://croit.io
croit GmbH
Freseniusstr. 31h
81247 München
www.croit.io
Tel: +49 89 1896585 90
On Tue, Dec 3, 2019 at 8:21 PM Jason Dillaman <jdillama(a)redhat.com> wrote:
>
> 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
> _______________________________________________
> ceph-users mailing list -- ceph-users(a)ceph.io
> To unsubscribe send an email to ceph-users-leave(a)ceph.io