Skip to content

Commit cd69192

Browse files
committed
Add MTU configuration change for installed clusters
- https://issues.redhat.com/browse/OSDOCS-1810
1 parent e182d78 commit cd69192

File tree

5 files changed

+617
-2
lines changed

5 files changed

+617
-2
lines changed

_topic_maps/_topic_map.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -949,6 +949,8 @@ Topics:
949949
Distros: openshift-enterprise,openshift-origin
950950
- Name: Verifying connectivity to an endpoint
951951
File: verifying-connectivity-endpoint
952+
- Name: Changing the cluster network MTU
953+
File: changing-cluster-network-mtu
952954
- Name: Configuring the node port service range
953955
File: configuring-node-port-service-range
954956
- Name: Configuring IP failover
Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,81 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * networking/changing-cluster-network-mtu.adoc
4+
5+
:_content-type: CONCEPT
6+
[id="nw-cluster-mtu-change-about_{context}"]
7+
= About the cluster MTU
8+
9+
During installation the maximum transmission unit (MTU) for the cluster network is detected automatically based on the MTU of the primary network interface of nodes in the cluster. You do not normally need to override the detected MTU.
10+
11+
You might want to change the MTU of the cluster network for several reasons:
12+
13+
* The MTU detected during cluster installation is not correct for your infrastructure
14+
* Your cluster infrastructure now requires a different MTU, such as from the addition of nodes that need a different MTU for optimal performance
15+
16+
You can change the cluster MTU for only the OVN-Kubernetes and OpenShift SDN cluster network providers.
17+
18+
// https://github.com/openshift/enhancements/blob/master/enhancements/network/allow-mtu-changes.md
19+
[id="service-interruption-considerations_{context}"]
20+
== Service interruption considerations
21+
22+
When you initiate an MTU change on your cluster the following effects might impact service availability:
23+
24+
* At least two rolling reboots are required to complete the migration to a new MTU. During this time, some nodes are not available as they restart.
25+
26+
* Specific applications deployed to the cluster with shorter timeout intervals than the absolute TCP timeout interval might experience disruption during the MTU change.
27+
28+
[id="mtu-value-selection_{context}"]
29+
== MTU value selection
30+
31+
When planning your MTU migration there are two related but distinct MTU values to consider.
32+
33+
* *Hardware MTU*: This MTU value is set based on the specifics of your network infrastructure.
34+
* *Cluster network MTU*: This MTU value is always less than your hardware MTU to account for the cluster network overlay overhead. The specific overhead is determined by your cluster network provider:
35+
** *OVN-Kubernetes*: `100` bytes
36+
** *OpenShift SDN*: `50` bytes
37+
38+
If your cluster requires different MTU values for different nodes, you must subtract the overhead value for your cluster network provider from the lowest MTU value that is used by any node in your cluster. For example, if some nodes in your cluster have an MTU of `9001`, and some have an MTU of `1500`, you must set this value to `1400`.
39+
40+
[id="how-the-migration-process-works_{context}"]
41+
== How the migration process works
42+
43+
The following table summarizes the migration process by segmenting between the user-initiated steps in the process and the actions that the migration performs in response.
44+
45+
.Live migration of the cluster MTU
46+
[cols="1a,1a",options="header"]
47+
|===
48+
49+
|User-initiated steps|{product-title} activity
50+
51+
|
52+
Set the following values in the Cluster Network Operator configuration:
53+
54+
- `spec.migration.mtu.machine.to`
55+
- `spec.migration.mtu.network.from`
56+
- `spec.migration.mtu.network.to`
57+
58+
|
59+
*Cluster Network Operator (CNO)*: Confirms that each field is set to a valid value.
60+
61+
- The `mtu.machine.to` must be set to either the new hardware MTU or to the current hardware MTU if the MTU for the hardware is not changing. This value is transient and is used as part of the migration process. Separately, if you specify a hardware MTU that is different from your existing hardware MTU value, you must manually configure the MTU to persist by other means, such as with a machine config, DHCP setting, or a Linux kernel command line.
62+
- The `mtu.network.from` field must equal the `network.status.clusterNetworkMTU` field, which is the current MTU of the cluster network.
63+
- The `mtu.network.to` field must be set to the target cluster network MTU and must be lower than the hardware MTU to allow for the overlay overhead of the cluster network provider. For OVN-Kubernetes, the overhead is `100` bytes and for OpenShift SDN the overhead is `50` bytes.
64+
65+
If the values provided are valid, the CNO writes out a new temporary configuration with the MTU for the cluster network set to the value of the `mtu.network.to` field.
66+
67+
*Machine Config Operator (MCO)*: Performs a rolling reboot of each node in the cluster.
68+
69+
|Reconfigure the MTU of the primary network interface for the nodes on the cluster. You can use a variety of methods to accomplish this, including:
70+
71+
- Deploying a new NetworkManager connection profile with the MTU change
72+
- Changing the MTU through a DHCP server setting
73+
- Changing the MTU through boot parameters
74+
|N/A
75+
76+
|Set the `mtu` value in the CNO configuration for the cluster network provider and set `spec.migration` to `null`.
77+
78+
|
79+
*Machine Config Operator (MCO)*: Performs a rolling reboot of each node in the cluster with the new MTU configuration.
80+
81+
|===

0 commit comments

Comments
 (0)