Quick question regarding FQDN
Hey folks, for production use quality it is recommended to have backend (storage) and front end seperated. Let' assume: - 85.0.0.0/24 public IP block - 10.100.0.0/24 private IPs for DC internal usage - 10.200.0.0/24 private IPs for storage only LAN and running, as per recommendation 3 nodes: - node01: - fqdn: node01.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.1 primary IP - 10.200.0.1 storage IP - node02: - fqdn: node02.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.2 primary IP - 10.200.0.2 storage IP - node03: - fqdn: node03.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.3 primary IP - 10.200.0.3 storage IP The storage network is its own physical network with 10gig that only connects those three servers. How can I specify which IP to use for storage, which for frontend traffic? I am assuming this as the controller and all admins should be able to reach the nodes via frontend, which is not the storage one. Okay, I am lost. Whats the real solution here? Or is "frontend" no-ip, just VM traffic and "backend" is the 10gig storage "Only" where all the FQDN reside? Thanks for clarification, -Chris. -- Christian Reiss - email@christian-reiss.de /"\ ASCII Ribbon support@alpha-labs.net \ / Campaign X against HTML WEB alpha-labs.net / \ in eMails GPG Retrieval https://gpg.christian-reiss.de GPG ID ABCD43C5, 0x44E29126ABCD43C5 GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5 "It's better to reign in hell than to serve in heaven.", John Milton, Paradise lost.
Hello Christian, That recommendation is for the hyper-converged installation as the nodes are also the storage servers so you would choose the storage addresses when setting up the gluster network. The other thing is you may have to setup a display network proxy if your clients can't reach nodes. Regards, Paul S. ________________________________ From: Christian Reiss <email@christian-reiss.de> Sent: 11 November 2019 11:31 To: users <users@ovirt.org> Subject: [ovirt-users] Quick question regarding FQDN Hey folks, for production use quality it is recommended to have backend (storage) and front end seperated. Let' assume: - 85.0.0.0/24 public IP block - 10.100.0.0/24 private IPs for DC internal usage - 10.200.0.0/24 private IPs for storage only LAN and running, as per recommendation 3 nodes: - node01: - fqdn: node01.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.1 primary IP - 10.200.0.1 storage IP - node02: - fqdn: node02.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.2 primary IP - 10.200.0.2 storage IP - node03: - fqdn: node03.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.3 primary IP - 10.200.0.3 storage IP The storage network is its own physical network with 10gig that only connects those three servers. How can I specify which IP to use for storage, which for frontend traffic? I am assuming this as the controller and all admins should be able to reach the nodes via frontend, which is not the storage one. Okay, I am lost. Whats the real solution here? Or is "frontend" no-ip, just VM traffic and "backend" is the 10gig storage "Only" where all the FQDN reside? Thanks for clarification, -Chris. -- Christian Reiss - email@christian-reiss.de /"\ ASCII Ribbon support@alpha-labs.net \ / Campaign X against HTML WEB alpha-labs.net / \ in eMails GPG Retrieval https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgpg.christ... GPG ID ABCD43C5, 0x44E29126ABCD43C5 GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5 "It's better to reign in hell than to serve in heaven.", John Milton, Paradise lost. _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.... oVirt Code of Conduct: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.... List Archives: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovir... To view the terms under which this email is distributed, please go to:- http://leedsbeckett.ac.uk/disclaimer/email/
On Mon, Nov 11, 2019 at 12:34 PM Christian Reiss <email@christian-reiss.de> wrote:
Hey folks,
for production use quality it is recommended to have backend (storage) and front end seperated. Let' assume:
- 85.0.0.0/24 public IP block - 10.100.0.0/24 private IPs for DC internal usage - 10.200.0.0/24 private IPs for storage only LAN
and running, as per recommendation 3 nodes:
- node01: - fqdn: node01.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.1 primary IP - 10.200.0.1 storage IP
- node02: - fqdn: node02.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.2 primary IP - 10.200.0.2 storage IP
- node03: - fqdn: node03.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.3 primary IP - 10.200.0.3 storage IP
The storage network is its own physical network with 10gig that only connects those three servers. How can I specify which IP to use for storage, which for frontend traffic?
I am assuming this as the controller and all admins should be able to reach the nodes via frontend, which is not the storage one.
Okay, I am lost. Whats the real solution here? Or is "frontend" no-ip, just VM traffic and "backend" is the 10gig storage "Only" where all the FQDN reside?
I am unsure about the meaning of "frontend" and "backend" in this context. In oVirt there is the concept of network roles, please find details in https://www.ovirt.org/documentation/admin-guide/chap-Logical_Networks.html#e... I recommend to configure only a single interface each host with 10.100.0.0/24 private IPs for DC internal usage before adding the host to oVirt, and keep this as management network. If hosted engine is used, the network connection for storage has to be configured already on the first host, before the hosted engine deployment is started. After the hosts are added to oVirt, I recommend to create a logical network without VM usage in oVirt, attach this network to the 10gig NIC on each host, and configure an IP address from 10.200.0.0/24 private IPs for storage only LAN If you storage is gluster, the related network role should be assigned to this logical network. The Engine's VM (or the Engine host, if not using hosted Engine) should have a network interface on 85.0.0.0/24 public IP block If you want to enable users from outside 10.100.0.0/24 private IPs for DC internal usage to access spice or VNC consoles of the VMs, each host requires to be attached to a new logical network with the role "Display" and an IP address from 85.0.0.0/24 public IP block Does this answer your question?
Thanks for clarification, -Chris.
-- Christian Reiss - email@christian-reiss.de /"\ ASCII Ribbon support@alpha-labs.net \ / Campaign X against HTML WEB alpha-labs.net / \ in eMails
GPG Retrieval https://gpg.christian-reiss.de GPG ID ABCD43C5, 0x44E29126ABCD43C5 GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5
"It's better to reign in hell than to serve in heaven.", John Milton, Paradise lost. _______________________________________________ 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/EGET3LTPKJNOUR...
On Tue, Nov 12, 2019 at 9:45 AM Dominik Holler <dholler@redhat.com> wrote:
On Mon, Nov 11, 2019 at 12:34 PM Christian Reiss <email@christian-reiss.de> wrote:
Hey folks,
for production use quality it is recommended to have backend (storage) and front end seperated. Let' assume:
- 85.0.0.0/24 public IP block - 10.100.0.0/24 private IPs for DC internal usage - 10.200.0.0/24 private IPs for storage only LAN
and running, as per recommendation 3 nodes:
- node01: - fqdn: node01.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.1 primary IP - 10.200.0.1 storage IP
- node02: - fqdn: node02.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.2 primary IP - 10.200.0.2 storage IP
- node03: - fqdn: node03.dc-example.com - fqdn storage: node02.storage.example.com - no public IP - 10.100.0.3 primary IP - 10.200.0.3 storage IP
The storage network is its own physical network with 10gig that only connects those three servers. How can I specify which IP to use for storage, which for frontend traffic?
I am assuming this as the controller and all admins should be able to reach the nodes via frontend, which is not the storage one.
Okay, I am lost. Whats the real solution here? Or is "frontend" no-ip, just VM traffic and "backend" is the 10gig storage "Only" where all the FQDN reside?
I am unsure about the meaning of "frontend" and "backend" in this context. In oVirt there is the concept of network roles, please find details in https://www.ovirt.org/documentation/admin-guide/chap-Logical_Networks.html#e...
I recommend to configure only a single interface each host with 10.100.0.0/24 private IPs for DC internal usage before adding the host to oVirt, and keep this as management network. If hosted engine is used, the network connection for storage has to be configured already on the first host, before the hosted engine deployment is started. After the hosts are added to oVirt, I recommend to create a logical network without VM usage in oVirt, attach this network to the 10gig NIC on each host, and configure an IP address from 10.200.0.0/24 private IPs for storage only LAN If you storage is gluster, the related network role should be assigned to this logical network.
The Engine's VM (or the Engine host, if not using hosted Engine) should have a network interface on 85.0.0.0/24 public IP block
If you want to enable users from outside 10.100.0.0/24 private IPs for DC internal usage to access spice or VNC consoles of the VMs, each host requires to be attached to a new logical network with the role "Display" and an IP address from 85.0.0.0/24 public IP block
Does this answer your question?
Just a short addition: You should create DNS records (A+PTR, perhaps AAAA as applicable) for each IP address separately, and use these names everywhere. E.g.:
- node01: - fqdn: node01.dc-example.com - fqdn storage: node02.storage.example.com
This name ^^^,
- no public IP - 10.100.0.1 primary IP - 10.200.0.1 storage IP
Should point at this address ^^^, and used wherever you should provide the name to access the storage interface of this host (e.g. in gluster conf and elsewhere). This way, if one day you need to change your IP addresses for any reason, you just need to update the DNS, and all the rest should be automatically updated. In practice I never played with gluster, no idea if indeed it's automatic (and might require a restart) or it's more involved. Best regards,
Thanks for clarification, -Chris.
-- Christian Reiss - email@christian-reiss.de /"\ ASCII Ribbon support@alpha-labs.net \ / Campaign X against HTML WEB alpha-labs.net / \ in eMails
GPG Retrieval https://gpg.christian-reiss.de GPG ID ABCD43C5, 0x44E29126ABCD43C5 GPG fingerprint = 9549 F537 2596 86BA 733C A4ED 44E2 9126 ABCD 43C5
"It's better to reign in hell than to serve in heaven.", John Milton, Paradise lost. _______________________________________________ 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/EGET3LTPKJNOUR...
_______________________________________________ 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/FD3BGFSA2ZVSFH...
-- Didi
participants (4)
-
Christian Reiss -
Dominik Holler -
Staniforth, Paul -
Yedidyah Bar David