2:54 a.m.
On Tue, Nov 12, 2019 at 9:45 AM Dominik Holler <dholler(a)redhat.com> wrote:
On Mon, Nov 11, 2019 at 12:34 PM Christian Reiss <email(a)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.htm...
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(a)christian-reiss.de /"\ ASCII Ribbon
> support(a)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(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/EGET3LTPKJN...
_______________________________________________
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/FD3BGFSA2ZV...
--
Didi