Hello,
I did not see an answer to 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 ) ?"
I have an existing oVirt datacenter with its own engine, hypervisors, etc.
Could I create hyperconverged clusters managed by my current datacenter ?
Ex. Cluster 1 -- 12 hyperconverged physical machines (storage/compute),
Cluster 2 -- 12 hyperconverged physical machines, etc.
Please let me know.
Thank You
C Williams
On Tue, Jan 29, 2019 at 4:21 AM Sahina Bose <sabose(a)redhat.com> wrote:
On Mon, Jan 28, 2019 at 6:22 PM Leo David <leoalex(a)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(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:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QGZZJIT4JSL...
_______________________________________________
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:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/DTOQQDE45GO...