Segregating storage traffic using Multus
By default, Fusion 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 Fusion Data Foundation
-
Fusion Data Foundation internal replication and rebalancing traffic, known as cluster network traffic
There are three ways to segregate Fusion Data Foundation from Red Hat OpenShift default network:
-
Reserve a network interface on the host for the public network of Fusion 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 Fusion Data Foundation cluster is healthy.
-
When the Fusion 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 Fusion 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 Fusion Data Foundation cluster.
-
Pod-to-pod and pod-to-storage Fusion 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 Fusion 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.
-
