9:06 a.m.
On Wed, Oct 16, 2019 at 2:16 PM Stefano Stagnaro <
stefanos(a)prismatelecomtesting.com> wrote:
Hi,
I've deployed an oVirt HC starting with latest oVirt Node 4.3.6; this is
my simple network plan (FQDNs only resolves the front-end addresses):
front-end back-end
engine.ovirt 192.168.110.10
node1.ovirt 192.168.110.11 192.168.210.11
node2.ovirt 192.168.110.12 192.168.210.12
node3.ovirt 192.168.110.13 192.168.210.13
The storage traffic allocation over multiple subnets is implicitly set by
name resolution and routing rules.
Please use two distinct hostnames for each host: the first one should
resolve only as an address on the management network and the second one as
an address on the storage network.
In the cockpit wizard for the hyperconverged deployment you will be
prompted twice about the name of the three hosts: on the first tab (named
'Hosts') use the three host-names that resolves on the storage network.
On the second tab ('Additional Hosts') please use the hostnames that are
going to be resolved over the management network.
at the end I followed the RHHI-V 1.6 Deployment Guide where, at chapter 9
[1], it suggests to create a logical network for Gluster traffic. Now
I can
see, indeed, back-end addresses added in the address pool:
[root@node1 ~]# gluster peer status
Number of Peers: 2
Hostname: node3.ovirt
Uuid: 3fe33e8b-d073-4d7a-8bda-441c42317c92
State: Peer in Cluster (Connected)
Other names:
192.168.210.13
Hostname: node2.ovirt
Uuid: a95a9233-203d-4280-92b9-04217fa338d8
State: Peer in Cluster (Connected)
Other names:
192.168.210.12
The problem is that the Gluster traffic seems still to flow on the
management interfaces:
[root@node1 ~]# tcpdump -i ovirtmgmt portrange 49152-49664
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovirtmgmt, link-type EN10MB (Ethernet), capture size 262144
bytes
14:04:58.746574 IP node2.ovirt.49129 > node1.ovirt.49153: Flags [.], ack
484303246, win 18338, options [nop,nop,TS val 6760049 ecr 6760932], length 0
14:04:58.753050 IP node2.ovirt.49131 > node1.ovirt.49152: Flags [P.], seq
2507489191:2507489347, ack 2889633200, win 20874, options [nop,nop,TS val
6760055 ecr 6757892], length 156
14:04:58.753131 IP node2.ovirt.49131 > node1.ovirt.49152: Flags [P.], seq
156:312, ack 1, win 20874, options [nop,nop,TS val 6760055 ecr 6757892],
length 156
14:04:58.753142 IP node2.ovirt.49131 > node1.ovirt.49152: Flags [P.], seq
312:468, ack 1, win 20874, options [nop,nop,TS val 6760055 ecr 6757892],
length 156
14:04:58.753148 IP node2.ovirt.49131 > node1.ovirt.49152: Flags [P.], seq
468:624, ack 1, win 20874, options [nop,nop,TS val 6760055 ecr 6757892],
length 156
14:04:58.753203 IP node2.ovirt.49131 > node1.ovirt.49152: Flags [P.], seq
624:780, ack 1, win 20874, options [nop,nop,TS val 6760055 ecr 6757892],
length 156
14:04:58.753216 IP node2.ovirt.49131 > node1.ovirt.49152: Flags [P.], seq
780:936, ack 1, win 20874, options [nop,nop,TS val 6760055 ecr 6757892],
length 156
14:04:58.753231 IP node1.ovirt.49152 > node2.ovirt.49131: Flags [.], ack
936, win 15566, options [nop,nop,TS val 6760978 ecr 6760055], length 0
...
and no yet to the eth1 I dedicated to gluster:
[root@node1 ~]# tcpdump -i eth1 portrange 49152-49664
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
What am I missing here? What can I do to force the Gluster traffic to
really flow on dedicated Gluster network?
Thank you,
Stefano.
[1] https://red.ht/2MiZ4Ge
_______________________________________________
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/U3ZAM3DGE3E...