Hi,
Em qua., 4 de dez. de 2019 às 00:31, Mike Christie <mchristi@xxxxxxxxxx> escreveu:
On 12/03/2019 04:19 PM, Wesley Dillingham wrote:
> Thanks. If I am reading this correctly the ability to remove an iSCSI
> gateway would allow the remaining iSCSI gateways to take over for the
> removed gateway's LUN's as of > 3.0. Thats good, we run 3.2. However,
> because the actual update of the central config object happens from the
> to-be-deleted iSCSI gateway, despite where the gwcli command is issued,
> it will fail to actually remove said gateway from the object if that
> gateway is not functioning.
Yes.
>
> I guess this leaves the question still of how to proceed when one of the
> iSCSI gateways fails permanently? Is that possible, or is it
> potentially possible other than manually intervening on the config
You could edit the gateway.cfg manually, but I would not do it, because
it's error prone.
It's probably safest to run in degraded mode and wait for an updated
ceph-iscsi package with a fix. If you are running into the problem right
now, I can bump the priority.
I permanently lost a gateway. I can not leave running "degraded" because I need to add another redundancy gateway, and it does not allow with the gateway "offline".
In this case, what can I do? If I create a new gateway with the same name and IP as the lost one, and then try to use "delete" in gwcli, will it work?
In this case, what can I do? If I create a new gateway with the same name and IP as the lost one, and then try to use "delete" in gwcli, will it work?
> object? If its not possible would the best course of action be to have
> standby hardware and quickly recreate the node or perhaps run the
> gateways more ephemerally, from a VM or container?
>
> Thanks again.
>
> Respectfully,
>
> *Wes Dillingham*
> wes@xxxxxxxxxxxxxxxxx <mailto:wes@xxxxxxxxxxxxxxxxx>
> LinkedIn <http://www.linkedin.com/in/wesleydillingham>
>
>
> On Tue, Dec 3, 2019 at 2:45 PM Mike Christie <mchristi@xxxxxxxxxx
> <mailto:mchristi@xxxxxxxxxx>> wrote:
>
> I do not think it's going to do what you want when the node you want to
> delete is down.
>
> It looks like we only temporarily stop the gw from being exported. It
> does not update the gateway.cfg, because we do the config removal call
> on the node we want to delete.
>
> So gwcli would report success and the ls command will show it as no
> longer running/exported, but if you restart the rbd-target-api service
> then it will show up again.
>
> There is an internal command to do what you want. I will post a PR for
> gwlci and so it can be used by dashboard.
>
>
> On 12/03/2019 01:19 PM, Jason Dillaman 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@xxxxxxxxxxxxxxxxx <mailto:wes@xxxxxxxxxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxx <mailto:wes@xxxxxxxxxxxxxxxxx>
> >> _______________________________________________
> >> ceph-users mailing list -- ceph-users@xxxxxxx
> <mailto:ceph-users@xxxxxxx>
> >> To unsubscribe send an email to ceph-users-leave@xxxxxxx
> <mailto:ceph-users-leave@xxxxxxx>
> >
> >
> >
>
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
_______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
