Thank you very much, Sahina.
This is making the things a bit more clear to me.



On Tue, Jan 29, 2019, 11:20 Sahina Bose <sabose@redhat.com wrote:
On Mon, Jan 28, 2019 at 6:22 PM Leo David <leoalex@gmail.com> wrote:
>
> Hello Everyone,
> 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:
>
> 2.7. SCALING
> 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 hyperconverged nodes.
>
> 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 data.
> ------
>
> Also  in oVirtEngine UI, when I add a brick to an existing volume i get the following warning:
>
> "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
limitations imposed.
>
> 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 replica 3.
>
> 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 !
>
> Leo
>
>
> --
> Best regards, Leo David
>
>
>
>
> --
> Best regards, Leo David
> _______________________________________________
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-leave@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: https://lists.ovirt.org/archives/list/users@ovirt.org/message/QGZZJIT4JSLYSOVLVYZADXJTWVEM42KY/