Dedicated Backup Networks in OpenShift Virtualization

Overview

When deploying Trilio for Kubernetes in OpenShift Virtualization environments, you may want to isolate backup traffic to a dedicated network to improve performance, security, and bandwidth management. This document outlines the configuration options and best practices for implementing dedicated backup networks using Network Attachment Definitions (NADs).

Background

In OpenShift environments, OVN (Open Virtual Network) is the default Software Defined Networking (SDN) solution. By default, OVN uses its own routing table and may not follow the standard kernel routing table. To enable pods to use secondary networks and follow kernel routing paths, specific configurations are required.

Key Concepts

• Network Attachment Definitions (NADs): Custom resources that define additional network interfaces for pods

• OVN Routing: OpenShift's default SDN routing behavior

• Kernel Routing Table: The host's standard routing table that can be leveraged with proper configuration

Configuration Methods

Method 1: Using Network Attachment Definitions with Pod Annotations

This is the recommended approach for configuring dedicated backup networks.

Step 1: Create a Network Attachment Definition

Create a NAD resource in the trilio-system namespace:

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: backup-network
  namespace: trilio-system
  annotations:
    k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/br1
spec:
  config: |
    {
      "name": "backup-network",
      "type": "bridge",
      "cniVersion": "0.3.1",
      "bridge": "br1",
      "macspoofchk": false,
      "ipam": {},
      "preserveDefaultVlan": false
    }

Step 2: Configure TrilioVaultManager (TVM) Custom Resource

Add the network annotation to your TVM configuration:

apiVersion: triliovault.trilio.io/v1
kind: TrilioVaultManager
metadata:
  name: triliovault-manager
spec:
  applicationScope: Cluster
  componentConfiguration:
    ingress-controller:
      enabled: false
  dataJobResources:
    requests:
      cpu: 100m
      memory: 900Mi
  helmValues:
    podAnnotations:
      k8s.v1.cni.cncf.io/networks: backup-network
    pollingIntervals:
      manager: 60s
      watcher: 60s
      webSessionAccessTTL: 160h
      webSessionMaxInactivityTTL: 24
  logLevel: Info
  metadataJobResources:
    requests:
      cpu: 10m
      memory: 10Mi
  tvkInstanceName: dc2-754f2

Note: To ensure Trilio pods use the secondary network, pass the Multus networks annotation under spec.helmValues.podAnnotations in the TrilioVaultManager CR, for example: k8s.v1.cni.cncf.io/networks: backup-network.

Step 3: Verify Configuration

To verify secondary network attachment for data transfer, start a backup and wait for the data upload phase to begin. Then check the datamover pod:

# Find the datamover pod for the running backup
oc get pods -n <backup-namespace> | grep datamover

# Verify the secondary network on the datamover pod
oc get pod <datamover-pod-name> -n <backup-namespace> -o jsonpath='{.metadata.annotations.k8s\.v1\.cni\.cncf\.io/network-status}' | jq

Expected output should show both the default ovn-kubernetes network and your backup network:

[
  {
    "name": "ovn-kubernetes",
    "interface": "eth0",
    "ips": ["10.131.0.8"],
    "mac": "0a:58:0a:83:00:08",
    "default": true,
    "dns": {}
  },
  {
    "name": "trilio-system/backup-network",
    "interface": "net1",
    "ips": ["192.168.100.10"],
    "mac": "52:54:00:01:33:0a",
    "dns": {}
  }
]

Method 2: Enabling Host Routing via Cluster Network Operator

For environments where you want pods to follow the kernel routing table instead of OVN's routing table:

Configure the Cluster Network Operator

Set the routingViaHost parameter to true in the Cluster Network Operator configuration:

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  serviceNetwork:
  - 172.30.0.0/16
  networkType: OVNKubernetes
  defaultNetwork:
    type: OVNKubernetes
    ovnKubernetesConfig:
      routingViaHost: true

Note: This configuration affects all pods in the cluster and should be carefully considered in production environments.

For detailed information about this parameter, refer to the OpenShift Container Platform Networking Documentation.

References

• OpenShift Container Platform Networking Documentation

• Multus CNI Documentation

• OpenShift Virtualization Networking

Example Working Configuration

Below is a complete working example that was successfully tested:

Network Attachment Definition

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: backup-network
  namespace: trilio-system
  annotations:
    k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/br1
spec:
  config: |
    {
      "name": "backup-network",
      "type": "bridge",
      "cniVersion": "0.3.1",
      "bridge": "br1",
      "macspoofchk": false,
      "ipam": {},
      "preserveDefaultVlan": false
    }

TrilioVaultManager Configuration

apiVersion: triliovault.trilio.io/v1
kind: TrilioVaultManager
metadata:
  name: triliovault-manager
spec:
  helmValues:
    podAnnotations:
      k8s.v1.cni.cncf.io/networks: backup-network
    logLevel: Info
    pollingIntervals:
      manager: 60s
      watcher: 60s
      webSessionAccessTTL: 160h
      webSessionMaxInactivityTTL: 24
  logLevel: Info

This configuration successfully attached the secondary network to Trilio pods and enabled dedicated backup network connectivity.