basic infra and glusterfs sizing question
Hello, I am just curious if basic gluster HCI layout which is suggested in cockpit has some deeper meaning. There are suggested 3 volumes * engine - it is clear, it is the volume where engine vm is running. When this vm is 51GB big how small could this volume be? I have 1TB SSD storage and I would like utilize it as much as possible. Could I create this volume as small as this vm is? Is it safe for example for future upgrades? * vmstore - it make sense it is a space for all other vms running in oVirt. Right? * data - which purpose has this volume? other data like for example ISOs? Direct disks? Another infra question... or maybe request for comment I have small amount of public ipv4 addresses in my housing (but I have own switches there so I can create vlans and separate internal traffic). I can access only these public ipv4 addresses directly. I would like to conserve these addressess as much as possible so what is the best approach in your opinion? * Install all hosts and HE with management network on private addressess * have small router (hw appliance with for example LEDE) which will utilize one ipv4 address and will do NAT and vpn for accessing my internals vlans. + looks like simple approach to me - single point of failure in this router (not really - just in case oVirt is badly broken and I need to access internal vlans to recover it) * have this router as virtual appliance inside oVirt (something like pfSense for example) + no need hw router + not sure but I could probably configure vrrp redundancy - still single point of failure like in first case * any other approach? Could ovn help here somehow? * Install all hosts and HE with public addresses :-) + access to all hosts directly - 3 node HCI cluster uses 4 public ip addressess Thanks for your opinions Cheers, Jiri
Regarding Gluster question. The volumes would be provisioned with LVM on the same block device. I believe 100Gb is recommended for the engine volume. The other volumes such as data would be created on another logical volume and you can use up the rest of the available space there. Ex. 100gb engine, 500Gb data and 400Gb vmstore. Data domains are basically the same now, in the past there used to be different domain types such as ISO domains which are deprecated. You don't really need any more than engine volume and data volume. You could have a volume for storing ISOs if you wanted to. You could have a separate volume for OS disks and another volume for data disks which would give you more flexibility for backups (so that you could backup data disks but not OS for example). On Fri, May 29, 2020 at 10:29 AM Jiří Sléžka <jiri.slezka@slu.cz> wrote:
Hello,
I am just curious if basic gluster HCI layout which is suggested in cockpit has some deeper meaning.
There are suggested 3 volumes
* engine - it is clear, it is the volume where engine vm is running. When this vm is 51GB big how small could this volume be? I have 1TB SSD storage and I would like utilize it as much as possible. Could I create this volume as small as this vm is? Is it safe for example for future upgrades?
* vmstore - it make sense it is a space for all other vms running in oVirt. Right?
* data - which purpose has this volume? other data like for example ISOs? Direct disks?
Another infra question... or maybe request for comment
I have small amount of public ipv4 addresses in my housing (but I have own switches there so I can create vlans and separate internal traffic). I can access only these public ipv4 addresses directly. I would like to conserve these addressess as much as possible so what is the best approach in your opinion?
* Install all hosts and HE with management network on private addressess
* have small router (hw appliance with for example LEDE) which will utilize one ipv4 address and will do NAT and vpn for accessing my internals vlans. + looks like simple approach to me - single point of failure in this router (not really - just in case oVirt is badly broken and I need to access internal vlans to recover it)
* have this router as virtual appliance inside oVirt (something like pfSense for example) + no need hw router + not sure but I could probably configure vrrp redundancy - still single point of failure like in first case
* any other approach? Could ovn help here somehow?
* Install all hosts and HE with public addresses :-) + access to all hosts directly - 3 node HCI cluster uses 4 public ip addressess
Thanks for your opinions
Cheers,
Jiri
_______________________________________________ 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/LIFQQHTFVTS6KI...
Also, I can't think of the limit off the top of my head. I believe it's either 75 or 100Gb. If the engine volume is set any lower the installation will fail. There is a minimum size requirement. On Fri, May 29, 2020 at 12:09 PM Jayme <jaymef@gmail.com> wrote:
Regarding Gluster question. The volumes would be provisioned with LVM on the same block device. I believe 100Gb is recommended for the engine volume. The other volumes such as data would be created on another logical volume and you can use up the rest of the available space there. Ex. 100gb engine, 500Gb data and 400Gb vmstore.
Data domains are basically the same now, in the past there used to be different domain types such as ISO domains which are deprecated. You don't really need any more than engine volume and data volume. You could have a volume for storing ISOs if you wanted to. You could have a separate volume for OS disks and another volume for data disks which would give you more flexibility for backups (so that you could backup data disks but not OS for example).
On Fri, May 29, 2020 at 10:29 AM Jiří Sléžka <jiri.slezka@slu.cz> wrote:
Hello,
I am just curious if basic gluster HCI layout which is suggested in cockpit has some deeper meaning.
There are suggested 3 volumes
* engine - it is clear, it is the volume where engine vm is running. When this vm is 51GB big how small could this volume be? I have 1TB SSD storage and I would like utilize it as much as possible. Could I create this volume as small as this vm is? Is it safe for example for future upgrades?
* vmstore - it make sense it is a space for all other vms running in oVirt. Right?
* data - which purpose has this volume? other data like for example ISOs? Direct disks?
Another infra question... or maybe request for comment
I have small amount of public ipv4 addresses in my housing (but I have own switches there so I can create vlans and separate internal traffic). I can access only these public ipv4 addresses directly. I would like to conserve these addressess as much as possible so what is the best approach in your opinion?
* Install all hosts and HE with management network on private addressess
* have small router (hw appliance with for example LEDE) which will utilize one ipv4 address and will do NAT and vpn for accessing my internals vlans. + looks like simple approach to me - single point of failure in this router (not really - just in case oVirt is badly broken and I need to access internal vlans to recover it)
* have this router as virtual appliance inside oVirt (something like pfSense for example) + no need hw router + not sure but I could probably configure vrrp redundancy - still single point of failure like in first case
* any other approach? Could ovn help here somehow?
* Install all hosts and HE with public addresses :-) + access to all hosts directly - 3 node HCI cluster uses 4 public ip addressess
Thanks for your opinions
Cheers,
Jiri
_______________________________________________ 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/LIFQQHTFVTS6KI...
Last time I used oVirt to deploy my gluster, cockpit was using thick LVs instead of thin LVM. I think that thin LVM is way more suitable for the task. Then you can set the size to anything needed. Best Regards, Strahil Nikolov На 29 май 2020 г. 18:27:59 GMT+03:00, Jayme <jaymef@gmail.com> написа:
Also, I can't think of the limit off the top of my head. I believe it's either 75 or 100Gb. If the engine volume is set any lower the installation will fail. There is a minimum size requirement.
On Fri, May 29, 2020 at 12:09 PM Jayme <jaymef@gmail.com> wrote:
Regarding Gluster question. The volumes would be provisioned with LVM on the same block device. I believe 100Gb is recommended for the engine volume. The other volumes such as data would be created on another logical volume and you can use up the rest of the available space there. Ex. 100gb engine, 500Gb data and 400Gb vmstore.
Data domains are basically the same now, in the past there used to be different domain types such as ISO domains which are deprecated. You don't really need any more than engine volume and data volume. You could have a volume for storing ISOs if you wanted to. You could have a separate volume for OS disks and another volume for data disks which would give you more flexibility for backups (so that you could backup data disks but not OS for example).
On Fri, May 29, 2020 at 10:29 AM Jiří Sléžka <jiri.slezka@slu.cz> wrote:
Hello,
I am just curious if basic gluster HCI layout which is suggested in cockpit has some deeper meaning.
There are suggested 3 volumes
* engine - it is clear, it is the volume where engine vm is running. When this vm is 51GB big how small could this volume be? I have 1TB SSD storage and I would like utilize it as much as possible. Could I create this volume as small as this vm is? Is it safe for example for future upgrades?
* vmstore - it make sense it is a space for all other vms running in oVirt. Right?
* data - which purpose has this volume? other data like for example ISOs? Direct disks?
Another infra question... or maybe request for comment
I have small amount of public ipv4 addresses in my housing (but I have own switches there so I can create vlans and separate internal traffic). I can access only these public ipv4 addresses directly. I would like to conserve these addressess as much as possible so what is the best approach in your opinion?
* Install all hosts and HE with management network on private addressess
* have small router (hw appliance with for example LEDE) which will utilize one ipv4 address and will do NAT and vpn for accessing my internals vlans. + looks like simple approach to me - single point of failure in this router (not really - just in case oVirt is badly broken and I need to access internal vlans to recover it)
* have this router as virtual appliance inside oVirt (something like pfSense for example) + no need hw router + not sure but I could probably configure vrrp redundancy - still single point of failure like in first case
* any other approach? Could ovn help here somehow?
* Install all hosts and HE with public addresses :-) + access to all hosts directly - 3 node HCI cluster uses 4 public ip addressess
Thanks for your opinions
Cheers,
Jiri
_______________________________________________ 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/LIFQQHTFVTS6KI...
I'm running oVirt + Gluster in HCI config and had similar questions as you when building it out.
- single point of failure in this router (not really - just in case oVirt is badly broken and I need to access internal vlans to recover it)
There is no SPOF if you're doing 3x HCI nodes. I regularly put 1 of my 3 Nodes into Maintenance or shutdown Gluster and have had no SPOFs. Are you only doing a single Node? If so, the point of failure is ... that 1 node :)
* have this router as virtual appliance inside oVirt (something like pfSense for example)
I'm running pfSense in hardware still (a Netgate ARM device). There's plenty of opinions on Reddit, StackOverflow, etc. about running any router in VM. There's several steps you'd need to take when I looked into it, and if you setup pfSense's interfaces as virtio / vhost I'd imagine you'd bump into limitations b/c those para devices weren't intended to do things like hardware offload, advanced routing, etc.; so you may have to setup PCI passthru / SR-IOV to get all of pfSense's routing capabilities. So I'm keeping pfSense in hardware ... though I've thought of creating a backup pfSense instance in VM encase of hardware disaster to keep my Internet up in "limp mode" ... but creating a cellular Hotspot is my current backup plan :)
Install all hosts and HE with public addresses
Why? The HE is a manager to the cluster and sits on the management network (ovirtmgmt), so giving it public IPs would be adding a security risk to the setup. I keep my HE accessible only via local VLAN and that's how most folks lock it down. Are you thinking the HE or HCI includes a load balancer? Eitherway, oVirt doesn't, but putting a load balancer in front of VM's and giving it your public IP would make more sense for exposing things to the Internet ... but I'm assuming too much and don't know what your cluster will be running.
On 5/29/20 5:27 PM, Jayme wrote:
Also, I can't think of the limit off the top of my head. I believe it's either 75 or 100Gb. If the engine volume is set any lower the installation will fail. There is a minimum size requirement.
thanks for reply. Meantime I was looking into RHV 4.4 beta docs and the limit is mentioned there Minimum Total - 55 GB https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4-bet... but oVirt HE vm is created with 51GB disk as Strahil mentioned in other post in this thread cockpit/ansible deploys engine lv for gluster brick as thick volume. Data and vmstore is deployed as thin volume. I will probably use default 100GB thick volume... (and only one other volume for vms on ssd disk) Cheers, Jiri
On Fri, May 29, 2020 at 12:09 PM Jayme <jaymef@gmail.com <mailto:jaymef@gmail.com>> wrote:
Regarding Gluster question. The volumes would be provisioned with LVM on the same block device. I believe 100Gb is recommended for the engine volume. The other volumes such as data would be created on another logical volume and you can use up the rest of the available space there. Ex. 100gb engine, 500Gb data and 400Gb vmstore.
Data domains are basically the same now, in the past there used to be different domain types such as ISO domains which are deprecated. You don't really need any more than engine volume and data volume. You could have a volume for storing ISOs if you wanted to. You could have a separate volume for OS disks and another volume for data disks which would give you more flexibility for backups (so that you could backup data disks but not OS for example).
On Fri, May 29, 2020 at 10:29 AM Jiří Sléžka <jiri.slezka@slu.cz <mailto:jiri.slezka@slu.cz>> wrote:
Hello,
I am just curious if basic gluster HCI layout which is suggested in cockpit has some deeper meaning.
There are suggested 3 volumes
* engine - it is clear, it is the volume where engine vm is running. When this vm is 51GB big how small could this volume be? I have 1TB SSD storage and I would like utilize it as much as possible. Could I create this volume as small as this vm is? Is it safe for example for future upgrades?
* vmstore - it make sense it is a space for all other vms running in oVirt. Right?
* data - which purpose has this volume? other data like for example ISOs? Direct disks?
Another infra question... or maybe request for comment
I have small amount of public ipv4 addresses in my housing (but I have own switches there so I can create vlans and separate internal traffic). I can access only these public ipv4 addresses directly. I would like to conserve these addressess as much as possible so what is the best approach in your opinion?
* Install all hosts and HE with management network on private addressess
* have small router (hw appliance with for example LEDE) which will utilize one ipv4 address and will do NAT and vpn for accessing my internals vlans. + looks like simple approach to me - single point of failure in this router (not really - just in case oVirt is badly broken and I need to access internal vlans to recover it)
* have this router as virtual appliance inside oVirt (something like pfSense for example) + no need hw router + not sure but I could probably configure vrrp redundancy - still single point of failure like in first case
* any other approach? Could ovn help here somehow?
* Install all hosts and HE with public addresses :-) + access to all hosts directly - 3 node HCI cluster uses 4 public ip addressess
Thanks for your opinions
Cheers,
Jiri
_______________________________________________ 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/LIFQQHTFVTS6KI...
On 5/30/20 3:48 PM, Jp wrote:
I'm running oVirt + Gluster in HCI config and had similar questions as you when building it out.
I think it would be nice to have some (best practice) design guides... but there are so many possibilities how to build a oVirt cluster... This time I try to build very cheap solution with as much redundancy as is feasible. But of course what is chep cannot be rock-solid...
- single point of failure in this router (not really - just in case oVirt is badly broken and I need to access internal vlans to recover it)
There is no SPOF if you're doing 3x HCI nodes. I regularly put 1 of my 3 Nodes into Maintenance or shutdown Gluster and have had no SPOFs. Are you only doing a single Node? If so, the point of failure is ... that 1 node :)
you are righ, I ment hypotetical situation with non functional HE vm, broken gluster etc...
* have this router as virtual appliance inside oVirt (something like pfSense for example)
I'm running pfSense in hardware still (a Netgate ARM device). There's plenty of opinions on Reddit, StackOverflow, etc. about running any router in VM. There's several steps you'd need to take when I looked into it, and if you setup pfSense's interfaces as virtio / vhost I'd imagine you'd bump into limitations b/c those para devices weren't intended to do things like hardware offload, advanced routing, etc.; so you may have to setup PCI passthru / SR-IOV to get all of pfSense's routing capabilities. So I'm keeping pfSense in hardware ... though I've thought of creating a backup pfSense instance in VM encase of hardware disaster to keep my Internet up in "limp mode" ... but creating a cellular Hotspot is my current backup plan :)
thanks for sharing your experience. I will try to keep my topology as simple as possible in the start. pfSense appliance is something I can add later.
Install all hosts and HE with public addresses
Why? The HE is a manager to the cluster and sits on the management network (ovirtmgmt), so giving it public IPs would be adding a security risk to the setup. I keep my HE accessible only via local VLAN and that's how most folks lock it down. Are you thinking the HE or HCI includes a load balancer? Eitherway, oVirt doesn't, but putting a load balancer in front of VM's and giving it your public IP would make more sense for exposing things to the Internet ... but I'm assuming too much and don't know what your cluster will be running.
just for sure I can access it in case of disaster recovery. But it is overkill and of course security risk. My problem is that I have no other access to my housing other then through public ips. No problem, I will add dedicated router which will act as gw for local vlans, NAT and vpn gw and will keep oVirt hosts inside on private space. Once more thanks for brainstorming :-) Cheers, Jiri
_______________________________________________ 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/BCV75LWZ6KTBTP...
participants (4)
-
Jayme -
Jiří Sléžka -
Jp -
Strahil Nikolov