oVirt 3.6 on CentOS 6.7 based HyperConverged DC : Upgradable?
[Please ignore the previous msg] Hello, One of our DC is a very small one, though quite critical. It's almost hyper converged : hosts are compute+storage, but the engine is standalone. It's made of : Hardware : - one physical engine : CentOS 6.7 - 3 physical hosts : CentOS 7.2 Software : - oVirt 3.6.5 - glusterFS 3.7.16 in replica-3, sharded. The goal is to upgrade all this to oVirt 4.1.1, and also upgrade the OSes. (oV 4.x only available on cOS 7.x) At present, only 3 VMs here are critical, and I have backups for them. Though, I'm quite nervous with the path I have to follow and the hazards. Especially about the gluster parts. At first glance, I would go this way (feel free to comment) : - upgrade the OS of the engine : 6.7 -> 7.3 - upgrade the OS of the hosts : 7.2 -> 7.3 - upgrade and manage the upgrade of gluster, check the volumes... - upgrade oVirt (engine then hosts) But when upgrading the OSes, I guess it will also upgrade the gluster layer. During this upgrade, I have no constraint to keep everything running, total shutdown is acceptable. Is the above procedure seems OK, or may am I missing some essential points? Thank you. -- Nicolas ECARNOT _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Wed, Mar 29, 2017 at 4:35 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
[Please ignore the previous msg]
Hello,
One of our DC is a very small one, though quite critical. It's almost hyper converged : hosts are compute+storage, but the engine is standalone.
And you intend to keep it that way? You didn't mention below.
It's made of :
Hardware : - one physical engine : CentOS 6.7 - 3 physical hosts : CentOS 7.2
Software : - oVirt 3.6.5 - glusterFS 3.7.16 in replica-3, sharded.
The goal is to upgrade all this to oVirt 4.1.1, and also upgrade the OSes. (oV 4.x only available on cOS 7.x)
At present, only 3 VMs here are critical, and I have backups for them. Though, I'm quite nervous with the path I have to follow and the hazards. Especially about the gluster parts.
At first glance, I would go this way (feel free to comment) : - upgrade the OS of the engine : 6.7 -> 7.3
How? This isn't supported, in principle, although it might work. The "official" way is using engine-backup to backup and restore it. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1332463
- upgrade the OS of the hosts : 7.2 -> 7.3 - upgrade and manage the upgrade of gluster, check the volumes... - upgrade oVirt (engine then hosts)
But when upgrading the OSes, I guess it will also upgrade the gluster layer.
I know nothing about gluster, so won't comment.
During this upgrade, I have no constraint to keep everything running, total shutdown is acceptable.
So you can also do a full backup and restore. Create an NFS export domain somewhere, export all your VMs there, recreate everything from scratch, import the VMs. Will take much longer, but then you don't need to risk/ test/prepare for problems in upgrading gluster.
Is the above procedure seems OK, or may am I missing some essential points?
Thank you.
-- Nicolas ECARNOT _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Didi
Le 29/03/2017 à 15:54, Yedidyah Bar David a écrit :
On Wed, Mar 29, 2017 at 4:35 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
[Please ignore the previous msg]
Hello,
Hello Didi,
One of our DC is a very small one, though quite critical. It's almost hyper converged : hosts are compute+storage, but the engine is standalone.
And you intend to keep it that way? You didn't mention below.
I intend to keep it this way.
At first glance, I would go this way (feel free to comment) : - upgrade the OS of the engine : 6.7 -> 7.3
How? This isn't supported, in principle, although it might work.
Mmmm, yep, you're right. Many people documented it. I'm not very fond of playing for such a critical part.
The "official" way is using engine-backup to backup and restore it. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1332463
Ok, Sent you a question there.
During this upgrade, I have no constraint to keep everything running, total shutdown is acceptable.
So you can also do a full backup and restore.
I could. But I may run out of hosts at present.
Create an NFS export domain somewhere, export all your VMs there, recreate everything from scratch, import the VMs. Will take much longer, but then you don't need to risk/ test/prepare for problems in upgrading gluster.
Well, so your overall opinion is that I should stick to KISS, correct? -- Nicolas ECARNOT
On Wed, Mar 29, 2017 at 5:16 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
Le 29/03/2017 à 15:54, Yedidyah Bar David a écrit :
On Wed, Mar 29, 2017 at 4:35 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
[Please ignore the previous msg]
Hello,
Hello Didi,
One of our DC is a very small one, though quite critical. It's almost hyper converged : hosts are compute+storage, but the engine is standalone.
And you intend to keep it that way? You didn't mention below.
I intend to keep it this way.
At first glance, I would go this way (feel free to comment) : - upgrade the OS of the engine : 6.7 -> 7.3
How? This isn't supported, in principle, although it might work.
Mmmm, yep, you're right. Many people documented it. I'm not very fond of playing for such a critical part.
The "official" way is using engine-backup to backup and restore it. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1332463
Ok, Sent you a question there.
Replied.
During this upgrade, I have no constraint to keep everything running, total shutdown is acceptable.
So you can also do a full backup and restore.
I could. But I may run out of hosts at present.
Create an NFS export domain somewhere, export all your VMs there, recreate everything from scratch, import the VMs. Will take much longer, but then you don't need to risk/ test/prepare for problems in upgrading gluster.
Well, so your overall opinion is that I should stick to KISS, correct?
I didn't say that. I don't know gluster. I just said that there *is* an option to KISS, if you want to. Some people prefer to take the "smarter" path (upgrade in-place), and it might work for them. If you want that, I simply suggest to spend some more time both reading and testing gluster upgrades. Personally I did both, and preferred backup/restore on more critical systems, at least when I had the option. If you do your math, test, and reach a conclusion that full backup/restore (with an export domain) will simply take more time than your downtime window, this is simply not an option... OTOH if you know that gluster upgrade is bullet-proof, from both testing and reading other people's reports, then go with it. Personally I'd still backup everything beforehand, if I have the option :-) -- Didi
On Wed, Mar 29, 2017 at 4:35 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
[Please ignore the previous msg]
Hello,
One of our DC is a very small one, though quite critical. It's almost hyper converged : hosts are compute+storage, but the engine is standalone.
It's made of :
Hardware : - one physical engine : CentOS 6.7 - 3 physical hosts : CentOS 7.2
Software : - oVirt 3.6.5 - glusterFS 3.7.16 in replica-3, sharded.
The goal is to upgrade all this to oVirt 4.1.1, and also upgrade the OSes. (oV 4.x only available on cOS 7.x)
At present, only 3 VMs here are critical, and I have backups for them. Though, I'm quite nervous with the path I have to follow and the hazards. Especially about the gluster parts.
At first glance, I would go this way (feel free to comment) : - upgrade the OS of the engine : 6.7 -> 7.3 - upgrade the OS of the hosts : 7.2 -> 7.3 - upgrade and manage the upgrade of gluster, check the volumes... - upgrade oVirt (engine then hosts)
Hi Nicolas, Regards the gluster update - have your tried to ask in the gluster ml? I'm adding Sahina to share her opinion on that flow. Export domain as Didi suggested is indeed the easy way from oVirt perspective - but it'll take a long time to copy/restore, Gluster backup should perform faster if there's a solution that fit your needs.
But when upgrading the OSes, I guess it will also upgrade the gluster layer.
During this upgrade, I have no constraint to keep everything running, total shutdown is acceptable.
Is the above procedure seems OK, or may am I missing some essential points?
Thank you.
-- Nicolas ECARNOT _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Wed, Mar 29, 2017 at 10:36 PM, Liron Aravot <laravot@redhat.com> wrote:
On Wed, Mar 29, 2017 at 4:35 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
[Please ignore the previous msg]
Hello,
One of our DC is a very small one, though quite critical. It's almost hyper converged : hosts are compute+storage, but the engine is standalone.
It's made of :
Hardware : - one physical engine : CentOS 6.7 - 3 physical hosts : CentOS 7.2
Software : - oVirt 3.6.5 - glusterFS 3.7.16 in replica-3, sharded.
The goal is to upgrade all this to oVirt 4.1.1, and also upgrade the OSes. (oV 4.x only available on cOS 7.x)
At present, only 3 VMs here are critical, and I have backups for them. Though, I'm quite nervous with the path I have to follow and the hazards. Especially about the gluster parts.
At first glance, I would go this way (feel free to comment) : - upgrade the OS of the engine : 6.7 -> 7.3 - upgrade the OS of the hosts : 7.2 -> 7.3 - upgrade and manage the upgrade of gluster, check the volumes... - upgrade oVirt (engine then hosts)
Hi Nicolas, Regards the gluster update - have your tried to ask in the gluster ml? I'm adding Sahina to share her opinion on that flow. Export domain as Didi suggested is indeed the easy way from oVirt perspective - but it'll take a long time to copy/restore, Gluster backup should perform faster if there's a solution that fit your needs.
Gluster does work with rolling upgrades - so there's no need to bring your system offline. Which glusterfs version are you on? Are you planning to update to gluster 3.10
But when upgrading the OSes, I guess it will also upgrade the gluster layer.
During this upgrade, I have no constraint to keep everything running, total shutdown is acceptable.
Is the above procedure seems OK, or may am I missing some essential points?
Thank you.
-- Nicolas ECARNOT _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Thu, Mar 30, 2017 at 4:39 PM, Sahina Bose <sabose@redhat.com> wrote:
On Wed, Mar 29, 2017 at 10:36 PM, Liron Aravot <laravot@redhat.com> wrote:
On Wed, Mar 29, 2017 at 4:35 PM, Nicolas Ecarnot <nicolas@ecarnot.net> wrote:
[Please ignore the previous msg]
Hello,
One of our DC is a very small one, though quite critical. It's almost hyper converged : hosts are compute+storage, but the engine is standalone.
It's made of :
Hardware : - one physical engine : CentOS 6.7 - 3 physical hosts : CentOS 7.2
Software : - oVirt 3.6.5 - glusterFS 3.7.16 in replica-3, sharded.
The goal is to upgrade all this to oVirt 4.1.1, and also upgrade the OSes. (oV 4.x only available on cOS 7.x)
At present, only 3 VMs here are critical, and I have backups for them. Though, I'm quite nervous with the path I have to follow and the hazards. Especially about the gluster parts.
At first glance, I would go this way (feel free to comment) : - upgrade the OS of the engine : 6.7 -> 7.3 - upgrade the OS of the hosts : 7.2 -> 7.3 - upgrade and manage the upgrade of gluster, check the volumes... - upgrade oVirt (engine then hosts)
Hi Nicolas, Regards the gluster update - have your tried to ask in the gluster ml? I'm adding Sahina to share her opinion on that flow. Export domain as Didi suggested is indeed the easy way from oVirt perspective - but it'll take a long time to copy/restore, Gluster backup should perform faster if there's a solution that fit your needs.
Gluster does work with rolling upgrades - so there's no need to bring your system offline. Which glusterfs version are you on? Are you planning to update to gluster 3.10
Sorry, missed that in your previous email. So you'll be upgrading from 3.7.6 to 3.8.x. If you do have the option of an offline upgrade - that's the safest, though rolling upgrade is also possible from 3.7
But when upgrading the OSes, I guess it will also upgrade the gluster layer.
During this upgrade, I have no constraint to keep everything running, total shutdown is acceptable.
Is the above procedure seems OK, or may am I missing some essential points?
Thank you.
-- Nicolas ECARNOT _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (4)
-
Liron Aravot -
Nicolas Ecarnot -
Sahina Bose -
Yedidyah Bar David