Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 8. Network requirements
Use this section to understand the different network considerations when planning deployments.
8.1. IPv6 support
Red Hat OpenShift Data Foundation version 4.12 introduced the support of IPv6. IPv6 is supported in single stack only, and cannot be used simultaneously with IPv4. IPv6 is the default behavior in OpenShift Data Foundation when IPv6 is turned on in Openshift Container Platform.
Red Hat OpenShift Data Foundation version 4.14 introduces IPv6 auto detection and configuration. Clusters using IPv6 will automatically be configured accordingly.
OpenShift Container Platform dual stack with Red Hat OpenShift Data Foundation IPv4 is supported from version 4.13 and later. Dual stack on Red Hat OpenShift Data Foundation IPv6 is not supported.
8.2. Multi network plug-in (Multus) support
OpenShift Data Foundation supports the ability to use multi-network plug-in Multus on bare metal infrastructures to improve security and performance by isolating the different types of network traffic. By using Multus, one or more network interfaces on hosts can be reserved for exclusive use of OpenShift Data Foundation.
To use Multus, first run the Multus prerequisite validation tool. For instructions to use the tool, see OpenShift Data Foundation - Multus prerequisite validation tool. For more information about Multus networks, see Multiple networks
8.2.1. Segregating storage traffic using Multus
By default, Red Hat OpenShift Data Foundation is configured to use the Red Hat OpenShift Software Defined Network (SDN). The default SDN carries the following types of traffic:
- Pod-to-pod traffic
- Pod-to-storage traffic, known as public network traffic when the storage is OpenShift Data Foundation
- OpenShift Data Foundation internal replication and rebalancing traffic, known as cluster network traffic
There are three ways to segregate OpenShift Data Foundation from OpenShift default network:
Reserve a network interface on the host for the public network of OpenShift Data Foundation
- Pod-to-storage and internal storage replication traffic coexist on a network that is isolated from pod-to-pod network traffic.
- Application pods have access to the maximum public network storage bandwidth when the OpenShift Data Foundation cluster is healthy.
- When the OpenShift Data Foundation cluster is recovering from failure, the application pods will have reduced bandwidth due to ongoing replication and rebalancing traffic.
Reserve a network interface on the host for OpenShift Data Foundation’s cluster network
- Pod-to-pod and pod-to-storage traffic both continue to use OpenShift’s default network.
- Pod-to-storage bandwidth is less affected by the health of the OpenShift Data Foundation cluster.
- Pod-to-pod and pod-to-storage OpenShift Data Foundation traffic might contend for network bandwidth in busy OpenShift clusters.
- The storage internal network often has an overabundance of bandwidth that is unused, reserved for use during failures.
Reserve two network interfaces on the host for OpenShift Data Foundation: one for the public network and one for the cluster network
- Pod-to-pod, pod-to-storage, and storage internal traffic are all isolated, and none of the traffic types will contend for resources.
- Service level agreements for all traffic types are more able to be ensured.
- During healthy runtime, more network bandwidth is reserved but unused across all three networks.
Dual network interface segregated configuration schematic example:
Triple network interface full segregated configuration schematic example:
8.2.2. When to use Multus
Use Multus for OpenShift Data Foundation when you need the following:
Improved latency - Multus with ODF always improves latency. Use host interfaces at near-host network speeds and bypass OpenShift’s software-defined Pod network. You can also perform Linux per interface level tuning for each interface.
Improved bandwidth - Dedicated interfaces for OpenShift Data Foundation client data traffic and internal data traffic. These dedicated interfaces reserve full bandwidth.
Improved security - Multus isolates storage network traffic from application network traffic for added security. Bandwidth or performance might not be isolated when networks share an interface, however, you can use QoS or traffic shaping to prioritize bandwidth on shared interfaces.
8.2.3. Multus configuration
To use Multus, you must create network attachment definitions (NADs) before deploying the OpenShift Data Foundation cluster, which is later attached to the cluster. For more information, see Creating network attachment definitions.
To attach additional network interfaces to a pod, you must create configurations that define how the interfaces are attached. You specify each interface by using a NetworkAttachmentDefinition custom resource (CR). A Container Network Interface (CNI) configuration inside each of these CRs defines how that interface is created.
OpenShift Data Foundation supports two types of drivers. The following tables describes the drivers and their features:
|
|
|
| Each connection gets a sub-interface of the parent interface with its own MAC address and is isolated from the host network. | Each connection gets its own IP address and shares the same MAC address. |
|
Uses less CPU and provides better throughput than Linux bridge or |
|
| Almost always require bridge mode. |
|
| Near-host performance when network interface card (NIC) supports virtual ports/virtual local area networks (VLANs) in hardware. |
If NIC does not support VLANs in hardware, performance might be better than |
OpenShift Data Foundation supports the following two types IP address management:
|
| DHCP |
|
Uses OpenShift/Kubernetes |
Does not require |
| Does not require a DHCP server to provide IPs for Pods. | Network DHCP server can give out the same range to Multus Pods as well as any other hosts on the same network. |
If there is a DHCP server, ensure Multus configured IPAM does not give out the same range so that multiple MAC addresses on the network cannot have the same IP.
8.2.4. Requirements for Multus configuration
Prerequisites
- The interface used for the public network must have the same interface name on each OpenShift storage and worker node, and the interfaces must all be connected to the same underlying network.
- The interface used for the cluster network must have the same interface name on each OpenShift storage node, and the interfaces must all be connected to the same underlying network. Cluster network interfaces do not have to be present on the OpenShift worker nodes.
- Each network interface used for the public or cluster network must be capable of at least 10 gigabit network speeds.
- Each network requires a separate virtual local area network (VLAN) or subnet.
See Creating Multus networks for the necessary steps to configure a Multus based configuration on bare metal.
