[ceph-users] Running Jewel and Luminous mixed for a longer period
casparsmit at supernas.eu
Wed Dec 6 01:17:35 PST 2017
2017-12-05 18:39 GMT+01:00 Richard Hesketh <richard.hesketh at rd.bbc.co.uk>:
> On 05/12/17 17:10, Graham Allan wrote:
> > On 12/05/2017 07:20 AM, Wido den Hollander wrote:
> >> Hi,
> >> I haven't tried this before but I expect it to work, but I wanted to
> >> check before proceeding.
> >> I have a Ceph cluster which is running with manually formatted
> >> FileStore XFS disks, Jewel, sysvinit and Ubuntu 14.04.
> >> I would like to upgrade this system to Luminous, but since I have to
> >> re-install all servers and re-format all disks I'd like to move it to
> >> BlueStore at the same time.
> > You don't *have* to update the OS in order to update to Luminous, do
> you? Luminous is still supported on Ubuntu 14.04 AFAIK.
> > Though obviously I understand your desire to upgrade; I only ask because
> I am in the same position (Ubuntu 14.04, xfs, sysvinit), though happily
> with a smaller cluster. Personally I was planning to upgrade ours entirely
> to Luminous while still on Ubuntu 14.04, before later going through the
> same process of decommissioning one machine at a time to reinstall with
> CentOS 7 and Bluestore. I too don't see any reason the mixed Jewel/Luminous
> cluster wouldn't work, but still felt less comfortable with extending the
> upgrade duration.
> > Graham
> Yes, you can run luminous on Trusty; one of my clusters is currently
> Luminous/Bluestore/Trusty as I've not had time to sort out doing OS
> upgrades on it. I second the suggestion that it would be better to do the
> luminous upgrade first, retaining existing filestore OSDs, and then do the
> OS upgrade/OSD recreation on each node in sequence. I don't think there
> should realistically be any problems with running a mixed cluster for a
> while but doing the jewel->luminous upgrade on the existing installs first
> shouldn't be significant extra effort/time as you're already predicting at
> least two months to upgrade everything, and it does minimise the amount of
> change at any one time in case things do start going horribly wrong.
> Also, at 48 nodes, I would've thought you could get away with cycling more
> than one of them at once. Assuming they're homogenous taking out even 4 at
> a time should only raise utilisation on the rest of the cluster to a little
> over 65%, which still seems safe to me, and you'd waste way less time
> waiting for recovery. (I recognise that depending on the nature of your
> employment situation this may not actually be desirable...)
Assuming size=3 and min_size=2 and failure-domain=host:
I always thought that bringing down more then 1 host cause data
inaccessebility right away because the chance that a pg will have osd's in
these 2 hosts is there. Only if the failure-domain is higher then host
(rack or something) you can safely bring more then 1 host down (in the same
failure domain offcourse).
Am i right?
> ceph-users mailing list
> ceph-users at lists.ceph.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ceph-users