OVN Scale Testing for Improved Performance
OVN DBs HA with scale test
Aliasgar Ginwala (
aginwala@ebay.com
)
I
RC: aginwala
What components can be improved with scale test?
●
OVN-Controller on computes/GWs – ongoing discussions and WIP upstream
●
OVS-vSwitchd on computes/GWs – performance improved with help of community.
●
OVN-Northd on central nodes – ongoing discussions and WIP upstream
Why scale test?
●
To see how OVN behaves when deployed at scale.
●
Ensure an entire availability zone is simulated fine in big cloud deployments.
●
Find out bugs as early as possible to improvise OVN.
What to use for scale test?
●
O
V
N
S
c
a
l
e
t
e
s
t
○
When something fails, performs slowly or doesn't scale, it's really hard to answer different questions on "what", "why" and "where" without a solid
scalability testing framework.
○
Since OpenStack rally is very convenient benchmarking tool, OVN scale test leverages the same.
○
It is a plugin of OpenStack Rally.
○
It’s open sourced and maintained under same base project OpenvSwitch.
○
I
n
t
e
n
d
e
d
t
o
p
r
o
v
i
d
e
t
h
e
c
o
m
m
u
n
i
t
y
w
i
t
h
a
O
V
N
c
o
n
t
r
o
l
p
l
a
n
e
s
c
a
l
a
b
i
l
i
t
y
t
e
s
t
t
o
o
l
t
h
a
t
i
s
c
a
p
a
b
l
e
o
f
p
e
r
f
o
r
m
i
n
g
s
p
e
c
i
f
i
c
,
c
o
m
p
l
i
c
a
t
e
d
a
n
d
r
e
p
r
o
d
u
c
i
b
l
e
t
e
s
t
c
a
s
e
s
o
n
s
i
m
u
l
a
t
e
d
s
c
e
n
a
r
i
o
s
.
○
Need to have a
Rally
installed, as workflow is also similar to Rally’s.
○
Upstream scale test repo @
https://github.com/openvswitch/ovn-scale-test
○
User guide @
http://ovn-scale-test.readthedocs.org/en/latest/
Rally OVS
●
To run OVN scale test, you don’t need OpenStack installed - instead you just need rally installed.
●
Main keywords :
○
D
e
p
l
o
y
m
e
n
t
=
a
n
y
c
l
o
u
d
d
e
p
l
o
y
m
e
n
t
c
o
n
s
i
s
t
i
n
g
o
f
a
l
l
n
e
t
w
o
r
k
a
n
d
c
o
m
p
u
t
e
c
o
m
p
o
n
e
n
t
s
.
○
T
a
s
k
=
A
n
y
C
R
U
D
o
p
e
r
a
t
i
o
n
s
o
n
c
o
m
p
u
t
e
,
f
a
r
m
a
n
d
n
e
t
w
o
r
k
c
o
m
p
o
n
e
n
t
s
l
i
k
e
l
p
o
r
t
s
,
l
s
w
i
t
c
h
e
s
,
l
r
o
u
t
e
r
s
,
e
t
c
.
○
F
a
r
m
=
c
o
l
l
e
c
t
i
o
n
o
f
s
a
n
d
b
o
x
e
s
○
S
a
n
d
b
o
x
=
a
c
h
a
s
s
i
s
(
h
y
p
e
r
v
i
s
o
r
/
c
o
m
p
u
t
e
n
o
d
e
/
o
v
s
s
a
n
d
b
o
x
)
Base counters considered for an availability zone
●
8 lrouters
●
5 lswitches per router
●
250 lports per lswitches
●
Total 10k lports
●
Total Chassis: 1k
●
Total BMs that hosts chassis: 20
●
Total control plane nodes: 3
●
10 lports(VM) per chassis
●
OS: Ubuntu 16.04 with 4.4 kernel
OVSdb service models
●
OVSDB supports three service models for databases:
○
S
t
a
n
d
a
l
o
n
e
○
A
c
t
i
v
e
-
B
a
c
k
u
p
○
C
l
u
s
t
e
r
e
d
●
The service models provide different compromises among consistency, availability, and partition tolerance.
●
They also differ in the number of servers required and in terms of performance.
●
The standalone and active-backup database service models share one on-disk format, and clustered databases use a different format [1]
1.
https://github.com/openvswitch/ovs/blob/80c42f7f218fedd5841aa62d7e9774fc1f9e9b32/Documentation/ref/ovsdb.7.rst
OVN DBs Active-standby using pacemaker
NB
Northd
SB
NB
Northd
SB
NB
Northd
SB
Node1
Node2
Node3
CMS
LB VIP
LB VIP
Neutron
CMS
HV
HV
HV
...
Active
Standby
Pacemaker Cluster
Alternatively, this LB VIP can be replaced by:
●
Option 2: BGP advertising the VIP
on each node
●
Option 3: put all 3 nodes on same
rack and use pacemaker to
manage the VIP too.
Start OVN DBs using pacemaker
●
Let pacemaker manage the VIP resource.
●
Using LB VIP:
○
set
listen_on_master_ip_only=no
○
Active node will listen on
0.0.0.0
so that LB VIP IP can connect on respective sb and nb db ports
OVN DBs – Raft Clustering
NB
Northd
SB
NB
Northd
SB
NB
Northd
SB
Node1
Node2
Node3
CMS
LB VIP
LB VIP
Neutron
CMS
HV
HV
HV
...
Cluster Leader
Active
Standby
Northd uses OVSDB
named lock to ensure
only one is active
Starting OVN DBs using clustering
●
For LB VIP:
○
Set connection table to listen on 0.0.0.0 on all nodes
●
For chassis:
○
Point it to either VIP IP e.g.
tcp:<vip_ip>:6642
○
Or all central node IPs e.g.
“tcp:
192.168.220.101:6642
,tcp:
192.168.220.102:6642
,tcp:
192.168.220.103:6642
”
How to set up scale test env ?
•
Create deployment which is installing necessary packages/binaries on a BM
–
rally-ovs deployment create --file ovn-multihost.json --name ovn-overlay
Rally-ovs
TOR
switch
OVN Farm1
OVN central node
ssh
ssh
OVN Farm20
.
.
ssh
How to set up scale test env ?
•
Rally task start create_sandbox is equivalent to convert the BM into a compute node with ovs installed.
•
rally-ovs task start create_sandbox.farm1.json
Rally-ovs
OVN Farm1
OVN central node
ssh
ssh
TOR
switch
HV1
HV2
HV50
How to set up scale test env ?
•
Finally create lrouters, lswitches and lports and also bind the lports to the chassis
•
rally-ovs task start create_routers_bind_ports.json
Rally-ovs
OVN Farm1
OVN central node
ssh
ssh
TOR
switch
HV1
HV2
HV50
lport1
lport20
lport500
..
OVN scale test with HA
●
OVN scale test by default sets up one active standalone OVN DB.
●
Hence, we need to separately setup an HA cluster
○
TODO
: (support to deploy HA cluster to be added in OVN-scale-test to avoid manual setup)
●
For testing HA, we need to point the chassis to HA nodes setup which can be set to respective OVN DB HA VIP IP
in the create_sandbox.json using below param
○
"controller_cidr": "192.168.10.10/16",
Scenarios – Active-standby using pacemaker
•
*Entire NB db data got flushed/lost causing both control and data plane impact
•
*Discussion @
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-August/047161.html
•
*Fixed rolled out with help of upstream and no issues reported so far.
•
*Commit ecf44dd3b26904edf480ada1c72a22fadb6b1825
OVN DBs HA – Active-backup with pacemaker
●
Current status
○
Basic functionality tested
○
Scale testing always ongoing with findings reported and some major issues fixed with help of upstream.
○
Detailed scale test scenarios reported and also updated on mail chain to the community
https://mail.openvswitch.org/pipermail/ovs-
discuss/2018-September/047405.html
○
Consent and improvements asked to upstream folks
Scenarios – Clustered DBs
Raft with scale test summary
●
Current status
○
Basic functionality tested.
○
Scale testing ongoing and problems found when using rally-ovs (ovn scale test) with around
2k+ lports
○
d
b
=
\
"
t
c
p
:
1
9
2
.
1
6
8
.
2
2
0
.
1
0
1
:
6
6
4
1
,
t
c
p
:
1
9
2
.
1
6
8
.
2
2
0
.
1
0
2
:
6
6
4
1
,
t
c
p
:
1
9
2
.
1
6
8
.
2
2
0
.
1
0
3
:
6
6
4
1
\
"
-
-
w
a
i
t
-
u
n
t
i
l
L
o
g
i
c
a
l
_
S
w
i
t
c
h
_
P
o
r
t
l
p
o
r
t
_
0
6
1
6
5
5
_
S
K
b
D
H
z
u
p
=
t
r
u
e
-
-
w
a
i
t
-
u
n
t
i
l
L
o
g
i
c
a
l
_
S
w
i
t
c
h
_
P
o
r
t
l
p
o
r
t
_
0
6
1
6
5
5
_
z
x
9
L
X
e
u
p
=
t
r
u
e
-
-
w
a
i
t
-
u
n
t
i
l
L
o
g
i
c
a
l
_
S
w
i
t
c
h
_
P
o
r
t
L
a
s
t
s
t
d
e
r
r
d
a
t
a
:
'
o
v
n
-
n
b
c
t
l
:
t
c
p
:
1
9
2
.
1
6
8
.
2
2
0
.
1
0
1
:
6
6
4
1
,
t
c
p
:
1
9
2
.
1
6
8
.
2
2
0
.
1
0
2
:
6
6
4
1
,
t
c
p
:
1
9
2
.
1
6
8
.
2
2
0
.
1
0
3
:
6
6
4
1
:
d
a
t
a
b
a
s
e
c
o
n
n
e
c
t
i
o
n
f
a
i
l
e
d
(
E
n
d
o
f
f
i
l
e
)
\
n
'
.
"
,
"
t
r
a
c
e
b
a
c
k
"
:
"
T
r
a
c
e
b
a
c
k
(
m
o
s
t
r
e
c
e
n
t
c
a
l
l
l
a
s
t
)
:
\
n
F
i
l
e
\
"
/
e
b
a
y
/
h
o
m
e
/
a
g
i
n
w
a
l
a
/
r
a
l
l
y
-
r
e
p
o
/
r
a
l
l
y
/
r
a
l
l
y
/
t
a
s
k
/
r
u
n
n
e
r
.
p
y
\
"
,
l
i
n
e
6
6
,
i
n
_
r
u
n
_
s
c
e
n
a
r
i
o
_
o
n
c
e
\
n
○
Following up with community to get it fixed soon with discussions @
https://mail.openvswitch.org/pipermail/ovs-dev/2018-
May/347260.html
○
U
p
s
t
r
e
a
m
a
l
s
o
h
a
v
e
r
a
f
t
t
o
r
t
u
r
e
t
e
s
t
i
n
t
e
s
t
c
a
s
e
s
i
n
o
v
s
r
e
p
o
f
o
r
t
e
s
t
i
n
g
l
o
c
a
l
l
y
.
Some tunings for both clustered and non clustered setup
•
N
e
t
f
i
l
t
e
r
T
C
P
p
a
r
a
m
s
o
n
a
l
l
c
e
n
t
r
a
l
n
o
d
e
s
:
–
Since tcp_max_syn_backlog and net.core.somaxconn values are too small, we need to increase the value to avoid getting TCP sync flood
messages in syslog:
•
net.ipv4.tcp_max_syn_backlog = 4096
•
net.core.somaxconn = 4096
•
P
a
c
e
m
a
k
e
r
c
o
n
f
i
g
u
r
a
t
i
o
n
s
–
When the SB DB starts on the new active node, it will be very busy on syncing data to all HVs.
–
During this time, pacemaker monitoring can get timed out. Because of this, the timeout value for "op monitor" needs to be set big enough to
avoid timeout to avoid restart/failover forever.
–
Hence, configure pacemaker monitor for resource
ovndb-servers: op monitor interval=60s timeout=50s
•
I
n
a
c
t
i
v
i
t
y
p
r
o
b
e
s
e
t
t
i
n
g
s
o
n
a
l
l
c
h
a
s
s
i
s
–
Set
inactivity probe to 3min
, so that central SB DB won't get overloaded for probe handling and also if failover happens, chassis will be able
to notice the changes
•
U
p
s
t
a
r
t
s
e
t
t
i
n
g
s
o
n
a
l
l
c
e
n
t
r
a
l
n
o
d
e
s
w
h
e
n
u
s
i
n
g
p
a
c
e
m
a
k
e
r
:
–
Disable ovn-central and openvswitch-switch upstart
to avoid confusing pacemaker when node reboots because pacemaker thinks there is
already an active pid and all the nodes will act as standalone nodes. Also LB gets confused sending traffic to this standby node.
Promising outcome and more to go
•
OVS-vswitchd CPU utilization was running super high on chassis.
•
P
e
r
f
o
r
m
a
n
c
e
i
m
p
r
o
v
e
d
b
y
m
a
k
i
n
g
o
f
p
r
o
t
o
f
a
s
t
e
r
a
n
d
r
e
s
u
l
t
s
a
r
e
a
m
a
z
i
n
g
;
t
e
s
t
c
o
m
p
l
e
t
e
d
i
n
3
+
h
o
u
r
s
v
s
8
+
h
o
u
r
s
:
•
Discussion @
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-February/046140.html
•
Commit c381bca52f629f3d35f00471dcd10cba1a9a3d99
CPU/Mem stats for active-standby
•
Active Central node
•
Chassis
Note:
•
M
e
m
:
R
E
S
m
e
m
i
n
b
y
t
e
s
w
h
e
t
h
e
r
i
t
s
m
b
,
g
b
o
r
t
b
.
•
C
P
U
:
t
o
t
a
l
C
P
U
t
i
m
e
,
t
h
e
t
a
s
k
h
a
s
u
s
e
d
s
i
n
c
e
i
t
s
t
a
r
t
e
d
.
e
.
g
.
i
f
t
h
e
t
o
t
a
l
c
p
u
t
i
m
e
i
n
s
e
c
o
n
d
s
f
o
r
a
c
u
r
r
e
n
t
o
v
n
-
c
o
n
t
r
o
l
l
e
r
p
r
o
c
e
s
s
i
s
6
:
2
6
.
9
0
,
w
e
c
o
n
v
e
r
t
t
h
e
s
a
m
e
i
n
t
o
i
n
t
e
g
e
r
s
e
c
o
n
d
s
b
y
f
o
l
l
o
w
i
n
g
t
i
m
e
c
o
n
v
e
r
s
i
o
n
f
o
r
m
u
l
a
:
6
*
6
0
0
0
+
2
6
*
1
0
0
+
9
0
=
3
8
6
9
0
•
Converted in Delta (speed per second)
Stuck?
•
Reach out to OVS community as it’s super interactive and responsive.
•
For any generic OVS queries/tech discussions use
ovs-discuss@openvswitch.org
so that wide variety of engineers can respond for the same.
Thank You
Explore the significance of scale testing for OVN components, including OVN-Controller, OVS-vSwitchd, and OVN-Northd, to enhance performance and identify bugs early on. Learn about the purpose, benefits, and tools like OVN Scale Test and Rally OVS for conducting scalability tests effectively in cloud deployments.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
OVN DBs HA with scale test Aliasgar Ginwala (aginwala@ebay.com) IRC: aginwala
What components can be improved with scale test? OVN-Controller on computes/GWs ongoing discussions and WIP upstream OVS-vSwitchd on computes/GWs performance improved with help of community. OVN-Northd on central nodes ongoing discussions and WIP upstream
Why scale test? To see how OVN behaves when deployed at scale. Ensure an entire availability zone is simulated fine in big cloud deployments. Find out bugs as early as possible to improvise OVN.
What to use for scale test? OVN Scale test When something fails, performs slowly or doesn't scale, it's really hard to answer different questions on "what", "why" and "where" without a solid scalability testing framework. Since OpenStack rally is very convenient benchmarking tool, OVN scale test leverages the same. It is a plugin of OpenStack Rally. It s open sourced and maintained under same base project OpenvSwitch. Intended to provide the community with a OVN control plane scalability test tool that is capable of performing specific, complicated and reproducible test cases on simulated scenarios. Need to have a Rally installed, as workflow is also similar to Rally s. Upstream scale test repo @ https://github.com/openvswitch/ovn-scale-test User guide @ http://ovn-scale-test.readthedocs.org/en/latest/
Rally OVS To run OVN scale test, you don t need OpenStack installed - instead you just need rally installed. Main keywords : Deployment = any cloud deployment consisting of all network and compute components. Task = Any CRUD operations on compute, farm and network components like lports, lswitches, lrouters, etc. Farm = collection of sandboxes Sandbox = a chassis (hypervisor/compute node/ovs sandbox)
Base counters considered for an availability zone 8 lrouters 5 lswitches per router 250 lports per lswitches Total 10k lports Total Chassis: 1k Total BMs that hosts chassis: 20 Total control plane nodes: 3 10 lports(VM) per chassis OS: Ubuntu 16.04 with 4.4 kernel
OVSdb service models OVSDB supports three service models for databases: Standalone Active-Backup Clustered The service models provide different compromises among consistency, availability, and partition tolerance. They also differ in the number of servers required and in terms of performance. The standalone and active-backup database service models share one on-disk format, and clustered databases use a different format [1] 1.https://github.com/openvswitch/ovs/blob/80c42f7f218fedd5841aa62d7e9774fc1f9e9b32/Documentation/ref/ovsdb.7.rst
OVN DBs Active-standby using pacemaker CMS Neutron CMS Option 2: BGP advertising the VIP on each node Option 3: put all 3 nodes on same rack and use pacemaker to manage the VIP too. Alternatively, this LB VIP can be replaced by: Active LB VIP Standby Node1 Node2 Node3 NB NB NB Pacemaker Cluster Northd Northd Northd SB SB SB LB VIP HV HV HV ...
Start OVN DBs using pacemaker Let pacemaker manage the VIP resource. pcs resource create ip-192.168.220.108 ocf:heartbeat:IPaddr2 ip=192.168.220.108 op monitor interval=30s pcs resource create ovndb_servers ocf:ovn:ovndb-servers manage_northd=yes master_ip=192.168.220.108 nb_master_port=6641 sb_master_port=6640 --master pcs resource meta ovndb_servers-master notify=true pcs constraint order start ip-192.168.220.108 then promote ovndb_servers-master pcs constraint colocation add ip-192.168.220.108 with master ovndb_servers-master Using LB VIP: set listen_on_master_ip_only=no Active node will listen on 0.0.0.0 so that LB VIP IP can connect on respective sb and nb db ports
OVN DBs Raft Clustering Cluster Leader CMS Neutron CMS Active LB VIP Standby Node1 Node2 Node3 NB NB NB Northd uses OVSDB named lock to ensure only one is active Northd Northd Northd SB SB SB LB VIP HV HV HV ...
Starting OVN DBs using clustering For LB VIP: Set connection table to listen on 0.0.0.0 on all nodes For chassis: Point it to either VIP IP e.g. tcp:<vip_ip>:6642 Or all central node IPs e.g. tcp:192.168.220.101:6642,tcp:192.168.220.102:6642,tcp:192.168.220.103:6642
How to set up scale test env ? Create deployment which is installing necessary packages/binaries on a BM rally-ovs deployment create --file ovn-multihost.json --name ovn-overlay TOR switch { "type": "OvnMultihostEngine", "controller": { "type": "OvnSandboxControllerEngine", "deployment_name": "ovn-new-controller-node", "ovs_repo": "https://github.com/openvswitch/ovs.git", "ovs_branch": "branch-2.9", "ovs_user": "root", "net_dev": "eth0", "controller_cidr": "192.168.10.10/16", "provider": { "type": "OvsSandboxProvider", "credentials": [ { "host": "10.x.x.x", "user": "root"} ] } }, "nodes": [ { "type": "OvnSandboxFarmEngine", "deployment_name": "ovn-farm-node-31", "ovs_repo" : "https://github.com/ openvswitch /ovs.git", "ovs_branch" : "branch-2.9", "ovs_user" : "root", "provider": { "type": "OvsSandboxProvider", "credentials": [ { "host": "10.x.x.x", "user": "root"} ] } } ] } ssh ssh Rally-ovs OVN Farm1 OVN central node . . ssh OVN Farm20
How to set up scale test env ? Rally task start create_sandbox is equivalent to convert the BM into a compute node with ovs installed. rally-ovs task start create_sandbox.farm1.json { "version": 2, "title": "Create sandbox", "description": "Creates 50 sandboxes on each farm", "tags": ["ovn", "sandbox"], "subtasks": [ { "title": "Create sandbox on farm 1", "group": "ovn", "description": "", "tags": ["ovn", "sandbox"], "run_in_parallel": false, "workloads": [ { "name": "OvnSandbox.create_sandbox", "args": { "sandbox_create_args": { "farm": "ovn-farm-node-1", "amount": 50, "batch": 10, "start_cidr": "192.230.64.0/16", "net_dev": "eth0", "tag": "TOR1" } }, "runner": { "type": "constant", "concurrency": 4, "times": 1, "max_cpu_count": 4 }, "context": { "ovn_multihost" : { "controller": "ovn-new-controller-node" } } } ] } ] } TOR switch ssh ssh Rally-ovs OVN central node HV1 HV2 OVN Farm1 HV50
How to set up scale test env ? Finally create lrouters, lswitches and lports and also bind the lports to the chassis rally-ovs task start create_routers_bind_ports.json { "OvnNetwork.create_routers_bind_ports": [ { "runner": { "type": "serial", "times": 1 }, "args": { "port_create_args": { "batch": 100 }, "router_create_args": { "amount": 8, "batch": 1 }, "network_create_args": { "start_cidr": "172.145.1.0/24", "batch": 1 }, "networks_per_router": 5, "ports_per_network": 250, "port_bind_args": { "wait_up": true, "wait_sync": "none" } }, "context": { "sandbox": {}, "ovn_multihost": { "controller": "ovn-new-controller-node" } } } ] } TOR switch ssh ssh Rally-ovs HV1 HV2 OVN central node .. lport20 lport1 OVN Farm1 lport500 HV50
OVN scale test with HA OVN scale test by default sets up one active standalone OVN DB. Hence, we need to separately setup an HA cluster TODO: (support to deploy HA cluster to be added in OVN-scale-test to avoid manual setup) For testing HA, we need to point the chassis to HA nodes setup which can be set to respective OVN DB HA VIP IP in the create_sandbox.json using below param "controller_cidr": "192.168.10.10/16",
Scenarios Active-standby using pacemaker Scenarios Impact on Control plane Impact on Data plane Standby node reboot No No Active node reboot Yes (~5+ minutes as SB DB is running super hot resyncing the data) Only newly created VMs/lports till SB DB cools down. All active and standby nodes reboot Yes (few minutes depending on how soon is new node up and data sync is finished) No* *Entire NB db data got flushed/lost causing both control and data plane impact *Discussion @ https://mail.openvswitch.org/pipermail/ovs-discuss/2018-August/047161.html *Fixed rolled out with help of upstream and no issues reported so far. *Commit ecf44dd3b26904edf480ada1c72a22fadb6b1825
OVN DBs HA Active-backup with pacemaker Current status Basic functionality tested Scale testing always ongoing with findings reported and some major issues fixed with help of upstream. Detailed scale test scenarios reported and also updated on mail chain to the community https://mail.openvswitch.org/pipermail/ovs- discuss/2018-September/047405.html Consent and improvements asked to upstream folks
Scenarios Clustered DBs Scenarios Impact on Control plane Impact on Data plane Any active node reboot No No All active nodes reboot Yes (few minutes depending on how soon is new node up along with leader selection and data sync completion) Not fully verified
Raft with scale test summary Current status Basic functionality tested. Scale testing ongoing and problems found when using rally-ovs (ovn scale test) with around 2k+ lports db=\"tcp:192.168.220.101:6641,tcp:192.168.220.102:6641,tcp:192.168.220.103:6641\" -- wait-until Logical_Switch_Port lport_061655_SKbDHz up=true -- wait-until Logical_Switch_Port lport_061655_zx9LXe up=true -- wait-until Logical_Switch_Port Last stderr data: 'ovn-nbctl: tcp:192.168.220.101:6641,tcp:192.168.220.102:6641,tcp:192.168.220.103:6641: database connection failed (End of file)\n'.", "traceback": "Traceback (most recent call last):\n File \"/ebay/home/aginwala/rally-repo/rally/rally/task/runner.py\", line 66, in _run_scenario_once\n Following up with community to get it fixed soon with discussions @ https://mail.openvswitch.org/pipermail/ovs-dev/2018- May/347260.html Upstream also have raft torture test in test cases in ovs repo for testing locally.
Some tunings for both clustered and non clustered setup Netfilter TCP params on all central nodes: Since tcp_max_syn_backlog and net.core.somaxconn values are too small, we need to increase the value to avoid getting TCP sync flood messages in syslog: net.ipv4.tcp_max_syn_backlog = 4096 net.core.somaxconn = 4096 Pacemaker configurations When the SB DB starts on the new active node, it will be very busy on syncing data to all HVs. During this time, pacemaker monitoring can get timed out. Because of this, the timeout value for "op monitor" needs to be set big enough to avoid timeout to avoid restart/failover forever. Hence, configure pacemaker monitor for resource ovndb-servers: op monitor interval=60s timeout=50s Inactivity probe settings on all chassis Set inactivity probe to 3min, so that central SB DB won't get overloaded for probe handling and also if failover happens, chassis will be able to notice the changes Upstart settings on all central nodes when using pacemaker: Disable ovn-central and openvswitch-switch upstart to avoid confusing pacemaker when node reboots because pacemaker thinks there is already an active pid and all the nodes will act as standalone nodes. Also LB gets confused sending traffic to this standby node.
Promising outcome and more to go OVS-vswitchd CPU utilization was running super high on chassis. Performance improved by making ofproto faster and results are amazing; test completed in 3+ hours vs 8+ hours: Discussion @ https://mail.openvswitch.org/pipermail/ovs-discuss/2018-February/046140.html Commit c381bca52f629f3d35f00471dcd10cba1a9a3d99
CPU/Mem stats for active-standby Active Central node Components CPU Mem OVN NB DB 0.12 97392000 OVN SB DB 0.92 777028000 OVN Northd 6.78 825836000 Chassis Note: Mem: RES mem in bytes whether its mb, gb or tb. CPU: total CPU time, the task has used since it started. e.g. if the total cpu time in seconds for a current ovn-controller process is 6:26.90, we convert the same into integer seconds by following time conversion formula: 6 * 6000 + 26 * 100 + 90 = 38690 Converted in Delta (speed per second) Components CPU Mem OVSDB server 0.02 11672000 OVS-vSwitchd 3.75 152812000 OVN-controller 0.94 839188000
Stuck? Reach out to OVS community as it s super interactive and responsive. For any generic OVS queries/tech discussions use ovs-discuss@openvswitch.org so that wide variety of engineers can respond for the same.
