On Mon, Jan 28, 2019 at 6:22 PM Leo David <leoalex(a)gmail.com> wrote:
Reading through the document:
"Red Hat Hyperconverged Infrastructure for Virtualization 1.5
Automating RHHI for Virtualization deployment"
Regarding storage scaling, i see the following statements:
Red Hat Hyperconverged Infrastructure for Virtualization is supported for one node, and
for clusters of 3, 6, 9, and 12 nodes.
The initial deployment is either 1 or 3 nodes.
There are two supported methods of horizontally scaling Red Hat Hyperconverged
Infrastructure for Virtualization:
1 Add new hyperconverged nodes to the cluster, in sets of three, up to the maximum of 12
2 Create new Gluster volumes using new disks on existing hyperconverged nodes.
You cannot create a volume that spans more than 3 nodes, or expand an existing volume so
that it spans across more than 3 nodes at a time
2.9.1. Prerequisites for geo-replication
Be aware of the following requirements and limitations when configuring geo-replication:
One geo-replicated volume only
Red Hat Hyperconverged Infrastructure for Virtualization (RHHI for Virtualization)
supports only one geo-replicated volume. Red Hat recommends backing up the volume that
stores the data of your virtual machines, as this is usually contains the most valuable
Also in oVirtEngine UI, when I add a brick to an existing volume i get the following
"Expanding gluster volume in a hyper-converged setup is not recommended as it could
lead to degraded performance. To expand storage for cluster, it is advised to add
additional gluster volumes."
Those things are raising a couple of questions that maybe for some for you guys are easy
to answer, but for me it creates a bit of confusion...
I am also referring to RedHat product documentation, because I treat oVirt as
production-ready as RHHI is.
oVirt and RHHI though as close to each other as possible do differ in
the versions used of the various components and the support
1. Is there any reason for not going to distributed-replicated volumes ( ie: spread one
volume across 6,9, or 12 nodes ) ?
- ie: is recomanded that in a 9 nodes scenario I should have 3 separated volumes, but
how should I deal with the folowing question
The reason for this limitation was a bug encountered when scaling a
replica 3 volume to distribute-replica. This has since been fixed in
the latest release of glusterfs.
2. If only one geo-replicated volume can be configured, how should I deal with 2nd and
3rd volume replication for disaster recovery
It is possible to have more than 1 geo-replicated volume as long as
your network and CPU resources support this.
> 3. If the limit of hosts per datacenter is 250, then (in theory ) the recomended way
in reaching this treshold would be to create 20 separated oVirt logical clusters with 12
nodes per each ( and datacenter managed from one ha-engine ) ?
> 4. In present, I have the folowing one 9 nodes cluster , all hosts contributing with
2 disks each to a single replica 3 distributed replicated volume. They where added to the
volume in the following order:
> node1 - disk1
> node2 - disk1
> node9 - disk1
> node1 - disk2
> node2 - disk2
> node9 - disk2
> At the moment, the volume is arbitrated, but I intend to go for full distributed
> Is this a bad setup ? Why ?
> It oviously brakes the redhat recommended rules...
> Is there anyone so kind to discuss on these things ?
> Thank you very much !
> Best regards, Leo David
> Best regards, Leo David
> Users mailing list -- users(a)ovirt.org
> To unsubscribe send an email to users-leave(a)ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
> List Archives: