Skip to main content
Solved

OpenShift Backup Network Architecture Using Access Node and Network Topology

  • July 22, 2026
  • 1 reply
  • 48 views

Forum|alt.badge.img

Hello Commvault Team,

We are designing a Commvault backup architecture for an OpenShift GPU environment and would like to confirm the supported network architecture.

Our environment has the following network connectivity:

  • The CommServe and MediaAgent can communicate with the Access Node.

  • The Access Node can communicate with the CommServe/MediaAgent, OpenShift API Server, and OpenShift Worker Nodes.

  • The OpenShift Worker Nodes cannot directly communicate with the CommServe or MediaAgent.

  • The Worker Nodes are connected only to the OpenShift Service Network and do not have connectivity to the Backup Network.

  • The Access Node has connectivity to both the OpenShift Service Network and the Backup Network.

We are considering using the Commvault Command Center Network Topology feature to control the backup communication path.

Our desired backup data flow is:

OpenShift Worker Node / Backup Pod → Access Node → MediaAgent → Backup Storage

In this architecture, we would like to avoid requiring direct network connectivity between the OpenShift Worker Nodes and the MediaAgent.

Could you please confirm the following?

  1. Can the Access Node act as an intermediate data path or gateway for OpenShift backup data between the Worker Nodes and the MediaAgent?

  2. Can the OpenShift backup data generated from namespaces/PVCs on the Worker Nodes be transferred through the Access Node to the MediaAgent?

  3. Can the Network Topology feature be used to enforce or control this communication path?

  4. If the Worker Nodes do not have direct connectivity to the MediaAgent or Backup Network, are there any additional network or configuration requirements?

  5. Does this architecture work for both CSI-based PV backups and file-system-based PV backups?

Our goal is to keep the OpenShift Worker Nodes isolated from the Backup Network while using the Access Node as the communication point between the OpenShift environment and the MediaAgent.

Thank you in advance for your guidance.

Best answer by Jace Ross

Hi Sangho,

Fundamentally an access node functions as a proxy between Commvault and Openshift. So it pretty much does what you’re looking for out of the box. There is network-optimized backups that do change things a little but first.

To address your queries directly:
1) Yes, that is its default behaviour.
2) It always is. The access node handles communication with the API server and all read operations.
3) Network topology can be used to define how each piece of Commvault infrastructure can initiate communication. Looking at your requirements this is not needed though.
4) No, the access node handles the transferring of data from workers/API to MediaAgents.
5) CSI and File-level behave the same.

Network-optimized is a method of having the cvworker communicate directly with the Control Plane and MediaAgents. This would require either worker nodes having access to backup infrastructure or you can configure it as per this document: https://documentation.commvault.com/11.44/software/network_optimized_backups_and_restores_for_kubernetes.html

For your use-case I would just recommend not enabling network-optimized backups as that would change your preferred behaviour to your unwanted behaviour.

Hopefully this has cleared up any confusion.

Cheers,
Jace

1 reply

Forum|alt.badge.img+9
  • Vaulter
  • Answer
  • July 22, 2026

Hi Sangho,

Fundamentally an access node functions as a proxy between Commvault and Openshift. So it pretty much does what you’re looking for out of the box. There is network-optimized backups that do change things a little but first.

To address your queries directly:
1) Yes, that is its default behaviour.
2) It always is. The access node handles communication with the API server and all read operations.
3) Network topology can be used to define how each piece of Commvault infrastructure can initiate communication. Looking at your requirements this is not needed though.
4) No, the access node handles the transferring of data from workers/API to MediaAgents.
5) CSI and File-level behave the same.

Network-optimized is a method of having the cvworker communicate directly with the Control Plane and MediaAgents. This would require either worker nodes having access to backup infrastructure or you can configure it as per this document: https://documentation.commvault.com/11.44/software/network_optimized_backups_and_restores_for_kubernetes.html

For your use-case I would just recommend not enabling network-optimized backups as that would change your preferred behaviour to your unwanted behaviour.

Hopefully this has cleared up any confusion.

Cheers,
Jace