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 <sab...@redhat.com wrote: > On Mon, Jan 28, 2019 at 6:22 PM Leo David <leoa...@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-le...@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/ >
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/A6K3U4AU2RTRYTC3KKCIB6TKXXUJB4O7/
