Thank You Sahina ! That is great news ! Might be asking more questions as we work through this .
Thanks Again C Williams On Fri, Jan 10, 2020 at 12:15 AM Sahina Bose <[email protected]> wrote: > > > On Thu, Jan 9, 2020 at 10:22 PM C Williams <[email protected]> > wrote: > >> 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. >> > > Yes, you can add multiple clusters to be managed by your existing engine. > The deployment flow would be different though, as the installation via > cockpit also deploys the engine for the servers selected. > You would need to create a custom ansible playbook that sets up the > gluster volumes and add the hosts to the existing engine. (or do the > creation of cluster and gluster volumes via the engine UI) > > >> Please let me know. >> >> Thank You >> >> C Williams >> >> On Tue, Jan 29, 2019 at 4:21 AM Sahina Bose <[email protected]> wrote: >> >>> On Mon, Jan 28, 2019 at 6:22 PM Leo David <[email protected]> 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 -- [email protected] >>> > To unsubscribe send an email to [email protected] >>> > 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/[email protected]/message/QGZZJIT4JSLYSOVLVYZADXJTWVEM42KY/ >>> _______________________________________________ >>> Users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> 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/[email protected]/message/DTOQQDE45GOTBYDVYWSFEJOHQR3DX4J2/ >>> >>
_______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/33JT3JHLLLMS6QNHNHQUQT4WLB3JNLFG/
