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.

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

2. If only one geo-replicated volume can be configured, how should I deal with 2nd and 3rd volume replication for disaster recovery

On Mon, Jan 28, 2019 at 6:22 PM Leo David <leoalex(a)gmail.com&gt; 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...

On Thu, Jan 9, 2020 at 10:22 PM C Williams <cwilliams3320(a)gmail.com&gt; 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 <sabose(a)redhat.com&gt; wrote: > >> On Mon, Jan 28, 2019 at 6:22 PM Leo David <leoalex(a)gmail.com&gt; 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... >> >