[ovirt-users] Add nodes to single-node hyperconverged cluster

[Joe DiTommasso]

Thanks! I realized yesterday that I've got a few hosts I was in the process
of decommissioning that I can temporarily use for this. So my new plan is
to build a 3-node cluster with junk hosts and cycle in the good ones.

On Tue, Apr 17, 2018 at 9:49 AM, Denis Chaplygin <dchaplyg at redhat.com>
wrote:

> Hello!
>
> On Fri, Apr 13, 2018 at 7:02 PM, Joe DiTommasso <jdito at domeyard.com>
> wrote:
>
>> Hi, I'm currently running an out-of-date (3.6) 3-node oVirt cluster,
>> using NFS storage. I'd like to upgrade to the latest release and move to a
>> hyperconverged setup, but I've only got the three hosts to play with. I'm
>> currently thinking of pulling one node from my current cluster, rebuilding
>> it to start a new cluster, and then migrating VMs/physical hosts over to
>> the new cluster. Is that something that would seem feasible? I've read the
>> documentation on setting up a hyperconverged cluster, but didn't see
>> anything about adding new hosts after cluster deployment.Thanks!
>>
>>
>
> Well, first of all - it is very tricky and risky. We have a good reason to
> require 3 hosts in HC cluster - data redundancy and service reliability. If
> you have luxury of turning everything down and upgrading using
> backup/restore or something similar - please, go this way.
>
>
> But in case you really really really need to upgrade your deployment in
> your way, you can try following:
>
> * Backup first :-)
> * Upgrade your OS to the maximum version supported by 3.6 and any of the
> next ovirt releases. You can also try to upgrade ovirt first.
> * Remove one of the nodes from your cluster
> * Manually install gluster servers on all 3 nodes and create a replicated
> volumes for your future engine and vms
> * Deploy HE on the free node, using existing gluster volumes
> * Migrate VMs to that engine.
> * One by one remove hosts from your old cluster and add them to your new
> cluster
> * When you will finish that, backup again :) and try to continue your
> upgrade.
>
> The whole idea of the process, described above, is to provide you with
> gluster replica 3 volume from the very beginning. Technically you can use a
> single brick distributed volume to install new engine and migrate VMs to
> your new cluster, but problems with that single brick distributed volume
> will affect all your VMs.
>
>
> Another one option for you is to make replicated volume in a single host.
> If you have enough space for keeping data thee times, you can:
>
> * Backup (!)
> * Remove one of the hosts from service, upgrade it
> * And after that create replica 3 volumes for the engine and VMs, using 6
> _local_ bricks
> * Migrate VMs from one of your hosts
> * Upgrade that second hosts, add it to your new cluster and manually
> migrate two bricks (one brick per volume) from the first host to the second
> host.
> * Repeat for remaining host
>
> Both approaches are VERY risky and highly THEORETICAL. I don't think
> anyone ever did that, so think twice before doing that. Following any of
> those scenario requires you to deeply understand, what are you doing and
> involves a lot of work in console. Seriously, thnk one more time before
> following them.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180417/294832f9/attachment.html>