Hyperconverged setup - storage architecture - scaling
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. SCALINGRed 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-replicationBe aware of the following requirements and limitations when configuring geo-replication:One geo-replicated volume onlyRed 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 *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
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/QGZZJIT4JSLYSO...
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
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
for one node, and for clusters of 3, 6, 9, and 12 nodes. the maximum of 12 hyperconverged nodes.
2 Create new Gluster volumes using new disks on existing hyperconverged
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
------
Also in oVirtEngine UI, when I add a brick to an existing volume i get
nodes. this is usually contains the most valuable data. 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/QGZZJIT4JSLYSO...
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@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
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
for one node, and for clusters of 3, 6, 9, and 12 nodes. the maximum of 12 hyperconverged nodes.
2 Create new Gluster volumes using new disks on existing hyperconverged
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
------
Also in oVirtEngine UI, when I add a brick to an existing volume i get
nodes. this is usually contains the most valuable data. 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/QGZZJIT4JSLYSO...
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/DTOQQDE45GOTBY...
On Thu, Jan 9, 2020 at 10:22 PM C Williams <cwilliams3320@gmail.com> 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@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
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
for one node, and for clusters of 3, 6, 9, and 12 nodes. the maximum of 12 hyperconverged nodes.
2 Create new Gluster volumes using new disks on existing hyperconverged
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
------
Also in oVirtEngine UI, when I add a brick to an existing volume i get
nodes. this is usually contains the most valuable data. 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/QGZZJIT4JSLYSO...
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/DTOQQDE45GOTBY...
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 <sabose@redhat.com> wrote:
On Thu, Jan 9, 2020 at 10:22 PM C Williams <cwilliams3320@gmail.com> 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@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
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
for one node, and for clusters of 3, 6, 9, and 12 nodes. the maximum of 12 hyperconverged nodes.
2 Create new Gluster volumes using new disks on existing
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
hyperconverged nodes. 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/QGZZJIT4JSLYSO...
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/DTOQQDE45GOTBY...
participants (3)
-
C Williams -
Leo David -
Sahina Bose