On Tue, Nov 12, 2019 at 9:45 AM Dominik Holler <dhol...@redhat.com> wrote:
>
>
>
> On Mon, Nov 11, 2019 at 12:34 PM Christian Reiss <em...@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#explanation-of-settings-in-the-manage-networks-window
>
> 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 - em...@christian-reiss.de         /"\  ASCII Ribbon
>>                     supp...@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-le...@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/EGET3LTPKJNOURRBURS65MT76LMT6DK5/
>
> _______________________________________________
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@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/FD3BGFSA2ZVSFHIFQ67SEJN2PBRUILX6/



-- 
Didi
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@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/BD2L5DIXMRAIV5C7TUH3OXCBXXJINYHQ/

Reply via email to