Storage Design Question - GlusterFS
Hello, we are designing a new production cluster, and I have to questsions about GlusterFS please: 1- this quote from the documentation os not clear to me " Creating additional data domains in the same data center as the self-hosted engine storage domain is highly recommended. If you deploy the self-hosted engine in a data center with only one active data storage domain, and that storage domain is corrupted, you will not be able to add new storage domains or remove the corrupted storage domain; you will have to redeploy the self-hosted engine." Does this mean that we should have more than one "Data" domain? or here this paragraph is talking about sharing a single domain for both the hosted-engine and VMs? 2- the documentation mentioned that Replica 1 or Replica 3 are only supported, but is this only for the hosted-engine volume? or also for Data volumes? so the max is only 3? and waht if I wanted to expand capacity later? Thank you,
1 - use 100 GB for the HostedEngine VM, separate storage domain for the other VMs 2 - Replica 3 means that each VM disk will have 3 identical copies ( split into tiny pieces) and usually you don't need more copies.When you decide to add more storage -> you can add 3 more bricks (term for server+mountpoint) , expand the volume and then rebalance (necessary in order to twll gluster about the new storage location and to balance the usage among subvolumes) Best Regards,Strahil Nikolov On Tue, Apr 5, 2022 at 12:18, mohamedroushdy@peopleintouch.com<mohamedroushdy@peopleintouch.com> wrote: Hello, we are designing a new production cluster, and I have to questsions about GlusterFS please: 1- this quote from the documentation os not clear to me " Creating additional data domains in the same data center as the self-hosted engine storage domain is highly recommended. If you deploy the self-hosted engine in a data center with only one active data storage domain, and that storage domain is corrupted, you will not be able to add new storage domains or remove the corrupted storage domain; you will have to redeploy the self-hosted engine." Does this mean that we should have more than one "Data" domain? or here this paragraph is talking about sharing a single domain for both the hosted-engine and VMs? 2- the documentation mentioned that Replica 1 or Replica 3 are only supported, but is this only for the hosted-engine volume? or also for Data volumes? so the max is only 3? and waht if I wanted to expand capacity later? Thank you, _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7VKXYCFLK73ADH...
Thanks a lot for your answer. The thing is, we had data lose disaster last month, and that's why we've decided to deploy a cmmpletely new environment for taht pirpose, and let me tell you what happened. We are using Ovirt 4.1 with Gluster 3.8 for our production, and the cluster contains five hosts, three of them are storage servers. I've added two more hosts, and manually via CLI (as I couldn't do this via GUI) created a new brick on one of the newely added nodes,and expanded the volume with the parameter "replica = 4 as it was refused to expand without setting the replica count. The action was successful for both the engine vol, and the data vol, however, few minutes later we've found that the disk sizes (images) of the existing VMs got shrunk and lost all of the data, and we had to recover from backup.. We can't afford another downtime (another disaster I mean), that's why I'm so maticulous about what to do next, so, is there a good guide around for the architecure and sizing? Thank you,
Can you check of the volume had 'cluster.lookup-optimize' enabled (on)?Most probably it caused your problems . For details check [1] [2] Best Regards,Strahil Nikolov[1] https://access.redhat.com/solutions/5896761 [2] https://lists.ovirt.org/archives/list/users@ovirt.org/thread/BEYIM56H2Q3PVFO... On Wed, Apr 6, 2022 at 10:42, mohamedroushdy@peopleintouch.com<mohamedroushdy@peopleintouch.com> wrote: Thanks a lot for your answer. The thing is, we had data lose disaster last month, and that's why we've decided to deploy a cmmpletely new environment for taht pirpose, and let me tell you what happened. We are using Ovirt 4.1 with Gluster 3.8 for our production, and the cluster contains five hosts, three of them are storage servers. I've added two more hosts, and manually via CLI (as I couldn't do this via GUI) created a new brick on one of the newely added nodes,and expanded the volume with the parameter "replica = 4 as it was refused to expand without setting the replica count. The action was successful for both the engine vol, and the data vol, however, few minutes later we've found that the disk sizes (images) of the existing VMs got shrunk and lost all of the data, and we had to recover from backup.. We can't afford another downtime (another disaster I mean), that's why I'm so maticulous about what to do next, so, is there a good guide around for the architecure and sizing? Thank you, _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/G4LS3BEUHYFS2B...
Well, I think it’s not configured. Here’s the config: Volume Name: data Type: Replicate Volume ID: 06cac4b9-3d6a-410b-93e6-4f876bbfcdd1 Status: Started Snapshot Count: 0 Number of Bricks: 1 x 3 = 3 Transport-type: tcp Bricks: Brick1: server1:/gluster/data/brick1 Brick2: server2:/gluster/data/brick1 Brick3: server3:/gluster/data/brick1 Options Reconfigured: features.shard-block-size: 512MB storage.owner-gid: 36 storage.owner-uid: 36 user.cifs: off features.shard: on cluster.shd-wait-qlength: 10000 cluster.shd-max-threads: 8 cluster.locking-scheme: granular cluster.data-self-heal-algorithm: full cluster.server-quorum-type: server cluster.quorum-type: auto cluster.eager-lock: enable network.remote-dio: enable performance.low-prio-threads: 32 performance.stat-prefetch: off performance.io-cache: off performance.read-ahead: off performance.quick-read: off transport.address-family: inet performance.readdir-ahead: on nfs.disable: on From: Strahil Nikolov <hunter86_bg@yahoo.com> Sent: Wednesday, April 6, 2022 1:42 PM To: Mohamed Roushdy <mohamedroushdy@peopleintouch.com>; users@ovirt.org Subject: [Ext.] Re: [ovirt-users] Re: Storage Design Question - GlusterFS [CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe] Can you check of the volume had 'cluster.lookup-optimize' enabled (on)? Most probably it caused your problems . For details check [1] [2] Best Regards, Strahil Nikolov [1] https://access.redhat.com/solutions/5896761 [2] https://lists.ovirt.org/archives/list/users@ovirt.org/thread/BEYIM56H2Q3PVFO... On Wed, Apr 6, 2022 at 10:42, mohamedroushdy@peopleintouch.com<mailto:mohamedroushdy@peopleintouch.com> <mohamedroushdy@peopleintouch.com<mailto:mohamedroushdy@peopleintouch.com>> wrote: Thanks a lot for your answer. The thing is, we had data lose disaster last month, and that's why we've decided to deploy a cmmpletely new environment for taht pirpose, and let me tell you what happened. We are using Ovirt 4.1 with Gluster 3.8 for our production, and the cluster contains five hosts, three of them are storage servers. I've added two more hosts, and manually via CLI (as I couldn't do this via GUI) created a new brick on one of the newely added nodes,and expanded the volume with the parameter "replica = 4 as it was refused to expand without setting the replica count. The action was successful for both the engine vol, and the data vol, however, few minutes later we've found that the disk sizes (images) of the existing VMs got shrunk and lost all of the data, and we had to recover from backup.. We can't afford another downtime (another disaster I mean), that's why I'm so maticulous about what to do next, so, is there a good guide around for the architecure and sizing? Thank you, _______________________________________________ Users mailing list -- users@ovirt.org<mailto:users@ovirt.org> To unsubscribe send an email to users-leave@ovirt.org<mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/G4LS3BEUHYFS2B...
participants (3)
-
Mohamed Roushdy -
mohamedroushdy＠peopleintouch.com
-
Strahil Nikolov