MongoDB Infrastructure
Introduction and Document Objectives
In many organizations, MongoDB is deployed locally alongside the application on the same server. While this approach may be acceptable during the development phase or in small-scale environments, it introduces several critical issues in enterprise production environments: the inability to scale the database independently, the absence of High Availability, resource contention (CPU, RAM, Disk I/O) between the application and the database, difficulties in performing Backup and Restore operations, and — most importantly — the risk of data loss in the event of server failure.
The objective of this document is to provide an architectural guideline for decoupling MongoDB from the application server and transforming it into an independent, centralized database on the PVM virtualization infrastructure. In this architecture, MongoDB is deployed on dedicated virtual machines, properly configured, and made available to the PVM server through a dedicated database network.
This document is specifically written for scenarios involving two possible conditions:
- The physical infrastructure (servers, switches, network) is provided by the client
- The physical infrastructure (servers, switches, network) is not provided by the client
In both cases, the AVID team is responsible for the design and implementation of the virtualization layer, the internal VM network, and the MongoDB infrastructure. Given that the level of client access to the physical network layer varies across different organizations, three distinct implementation scenarios have been defined for this architecture, each of which is examined separately in the sections that follow.
💡 In simple terms: When you intend to deploy MongoDB on a PVM virtual machine, the primary challenge is not how to install MongoDB — rather, it is how to isolate the database network from the management network. Depending on the level of network access provided by the client, three fundamentally different scenarios must be considered.
🔧 From a technical perspective: The primary goal of this document is to design Layer 2 and Layer 3 network topologies for MongoDB traffic in a manner that ensures:
- Database traffic does not traverse the Management network
- Complete isolation is maintained between database traffic and PVM management traffic
- Network performance (latency and throughput) is optimized for database operations
- Security of database traffic is enforced at Layer 2
Infrastructure Prerequisites
Prior to initiating deployment, the following prerequisites must be in place:
Hardware and Hypervisor (Standalone MongoDB Deployment)
-
Selecting the Database Server Deployment Location: Two options are available for deploying the database:
-
- Deployment as a virtual machine on the existing PVM server
-
- Where feasible, deployment as an independent virtual machine on a dedicated physical server within the network
The second option is preferred with respect to resource isolation, stability, and failure domain separation, as any failure of the primary PVM server will have no impact on database availability.
-
-
Minimum of 2 physical network ports per server (one for Management and one for VM traffic)
-
Sufficient RAM for the MongoDB virtual machine (minimum of 8 GB per node)
-
Sufficient disk space for the MongoDB virtual machine (minimum of 200 GB)
-
SSD/NVMe disk for MongoDB data storage
Network
The network required for MongoDB communication with other Nodes and virtual machines is determined based on the PVM deployment type and the database placement.
PVM Cluster
In cases where PVM is implemented as a Cluster and various PVM Nodes require network connectivity to MongoDB, the database network should preferably be designed as a physically and logically isolated segment, separate from other infrastructure networks.
PVM Cluster — Isolated Database Network
Trunk · 802.1Q
ACL: Only PVM → :27017
TLS Encrypted
No Internet on VLAN 20
Fully Isolated Database Network
In this scenario, the PVM cluster is connected to the database infrastructure through a fully isolated, dedicated network. The objective of this design is to establish an independent communication path for database traffic and to prevent the intermingling of MongoDB traffic with the organization's public, management, or other service networks.
In this architecture, the database network follows a dedicated path with dedicated controls, from the moment traffic exits the PVM servers until it reaches the MongoDB infrastructure.
Overall, the network architecture is illustrated as shown above.
↓ Independent Physical Connection for the Database
To achieve the highest level of isolation, each Node in the PVM cluster must possess an independent Physical Network Connection dedicated to database traffic.
This means that a specific Physical NIC or Physical Port on each PVM server is allocated exclusively to the database network.
For example:
PVM Node 1
│
├── NIC 1 → Management Network
├── NIC 2 → VM / Service Network
└── NIC 3 → Database Network
In this configuration, database traffic traverses an independent physical path and does not share a common Physical Interface with Management traffic or other PVM networks.
Accordingly, where feasible, it is recommended that the database network be segregated from other PVM networks at the Physical level from the outset.
↓ Dedicated Isolated Database Switch
The Physical Port allocated to the database must be connected to a dedicated switch, or a switch fully isolated for the database network.
Ideally, the network path should be structured as follows:
PVM Node 1 ─────┐
PVM Node 2 ─────┤
PVM Node 3 ─────┤
▼
┌─────────────────┐
│ Database Switch │
│ │
│ Isolated Network│
└────────┬────────┘
│
▼
MongoDB
This switch should not, without necessity, interconnect with the organization's public networks, Management Network, or other service networks.
The purpose of this separation is to ensure that, even in the event of a misconfiguration at higher layers, the physical path of database traffic remains isolated from other networks.
↓ Dedicated Database VLAN
In addition to physical separation, a dedicated VLAN for the database must also be defined by the client.
For example:
VLAN ID: 300
Name: DB-NET
Subnet: 10.30.0.0/24
This VLAN will be used exclusively for database-related traffic.
In this configuration:
Database VLAN
│
├── PVM Node 1
├── PVM Node 2
├── PVM Node 3
│
└── MongoDB Nodes
The use of a dedicated VLAN ensures that, in addition to Physical Isolation, the database network also benefits from Logical Isolation at the logical layer.
Consequently, two layers of separation are achieved:
Physical Isolation
+
Logical Isolation
│
▼
Database Network
↓ Access Control and ACL
Network isolation alone does not guarantee complete security.
Appropriate ACLs and Security Rules must be enforced on switches and network equipment to restrict communications within the database network.
For instance, if only specific PVM Nodes are permitted to communicate with MongoDB, access can be restricted to those Nodes:
Allowed:
PVM Node 1 ────────┐
PVM Node 2 ────────┼──────► MongoDB
PVM Node 3 ────────┘
Denied:
Other Network ───────────X──► MongoDB
User Network ────────────X──► MongoDB
Guest Network ───────────X──► MongoDB
Internet ────────────────X──► MongoDB
ACL rules must be defined based on the actual service requirements, and any unnecessary access must be blocked.
For example, if MongoDB uses its standard port, only those sources that genuinely require communication with MongoDB should be granted access to the corresponding port.
Design Principle: Access to the database network must be defined based on the Least Privilege principle; that is, each system should be granted only the level of communication required for the operation of its service.
↓ Layers of Network Isolation
In this architecture, database isolation is enforced across multiple layers:
Database Security
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Physical Layer Network Layer Security Layer
│ │ │
▼ ▼ ▼
Dedicated NIC Dedicated VLAN ACL
│ │ │
▼ ▼ ▼
Dedicated Switch DB Subnet Firewall Rules
│ │ │
└────────────────┼────────────────┘
▼
MongoDB
As a result, the database network is not merely a simple VLAN; rather, it constitutes a composite of physical separation, logical separation, and network access control.
↓ Final Architectural Outcome
In this scenario, the communication path is defined as follows:
PVM Node
│
│ Dedicated Physical NIC
▼
Database Switch
│
│ Dedicated Database VLAN
▼
Database Network
│
│ ACL / Security Rules
▼
MongoDB
Accordingly, the client-side requirements for this scenario are as follows:
- Allocation of an independent Physical Port / NIC for the database network on each required PVM Node
- Connection of these ports to a dedicated or isolated database switch
- Allocation of a dedicated database VLAN
- Specification of the Subnet and IP Range for the database
- Enforcement of ACLs and Security Rules to restrict access
- Definition of permitted sources and destinations
- Specification of the required ports and protocols
- Prevention of direct access from unrelated networks to the database network
Note: This scenario provides the highest level of network separation among the approaches described in this document, as database traffic is isolated from other infrastructure traffic at both the Physical and Logical layers.
Second Architecture in PVM Cluster
PVM Cluster — Isolated Database Network
Trunk · 802.1Q
ACL: Only PVM → :27017
TLS Encrypted
No Internet on VLAN 20
PVM Cluster — Logical Isolation via VLAN ↓
In this architecture, only a single shared physical path is provisioned for connecting the various Nodes of the PVM Cluster to MongoDB.
Specifically:
-
A single Physical Port / Physical Link connecting the PVM Cluster to the network
-
A shared Core Switch
-
A dedicated Database VLAN
-
No dedicated Database Switch
In this architecture, database network segmentation is performed at the Logical level and is based on VLANs. Unlike the Physical Isolation architecture, it is not necessarily dependent on a dedicated physical path for the database.
Nevertheless, at the physical layer, two approaches may be implemented for connecting the database to the network:
-
Using a dedicated NIC for MongoDB: An independent network interface card is assigned exclusively to MongoDB, and this Interface is used directly to access the Database Network.
-
Using a shared NIC: MongoDB traffic may traverse the same Physical NIC alongside traffic from other VMs, with traffic separation performed at the VLAN level.
Accordingly, Logical Isolation via VLAN can be implemented on either a dedicated NIC or a shared NIC. The primary difference is that, in the dedicated NIC configuration, the physical path for the database is also segregated from other traffic, whereas in the shared NIC configuration, isolation is purely logical and is enforced through VLANs, Trunks, and network control policies.
Core Components of the Architecture ↓
-
- PVM Nodes
The various PVM Nodes utilize the existing network infrastructure to establish communication with MongoDB.
For example:
PVM Node 01 → 10.10.10.11
PVM Node 02 → 10.10.10.12
PVM Node 03 → 10.10.10.13
To access MongoDB, these Nodes must be granted permission to access the Database VLAN.
-
- Physical Port / Physical Link
In this architecture, a single physical path exists for traffic transmission, and the Database Network does not utilize an independent, dedicated Physical Port or Link of its own.
Consequently, Database Traffic and other Traffic may traverse a common physical infrastructure.
For example:
Physical Link
│
▼
┌──────────────┐
│ Core Switch │
└──────┬───────┘
│
┌──────────┴──────────┐
│ │
VLAN 10 VLAN 20
Mgmt Database
│ │
▼ ▼
Management MongoDB
-
- Core Switch
The Core Switch serves as the central node of this architecture.
The same switch is responsible for transporting the various VLANs.
For example:
Core Switch
│
├── VLAN 10 → Management Network
│
└── VLAN 20 → Database Network
Thus, unlike the previous architecture, no separate Database Switch is present.
-
- Database VLAN
A dedicated VLAN is provisioned for MongoDB.
For example:
VLAN ID : 20
VLAN Name : DATABASE-NET
Subnet : 10.20.20.0/24
MongoDB : 10.20.20.100
Port : TCP/27017
VLAN 20 ensures that Database Traffic is logically segregated from other VLANs.
-
- ACL
Access to MongoDB must not be granted merely because a Host resides within the corporate network.
An ACL or Firewall Policy must be defined to ensure that only authorized sources may connect to MongoDB.
For example:
PVM Node 01 ───────┐
PVM Node 02 ───────┼── TCP/27017 ──► MongoDB
PVM Node 03 ───────┘
Other Networks ───────────────X────► MongoDB
In this example, only PVM Nodes are permitted to access the MongoDB port.
-
- TLS
In addition to Network Segmentation, MongoDB communication should, where required, be encrypted using TLS.
Accordingly:
Database VLAN
│
│ TCP/27017
│
│ TLS
▼
MongoDB
TLS is not a substitute for VLAN or ACL.
VLANs are responsible for Segmentation, ACLs manage Access Control, and TLS handles Encryption of traffic.
Key Characteristic of This Architecture ↓
The most significant characteristic of this architecture is that a single shared Physical Infrastructure is employed, upon which multiple logical networks are established.
ONE PHYSICAL NETWORK
│
▼
Core Switch
│
┌──────────┴──────────┐
│ │
VLAN 10 VLAN 20
Management Database
│ │
▼ ▼
Mgmt Traffic DB Traffic
Therefore, the database is logically separated but physically continues to utilize the same shared path and equipment.
Limitations of This Architecture ↓
-
- Absence of Physical Isolation
The most significant limitation of this architecture is that the Database Network is not physically separated.
Should the Core Switch or the shared physical path experience failure, both the public networks and the Database Network may be impacted simultaneously.
Core Switch
│
┌───────┴───────┐
│ │
VLAN 10 VLAN 20
Mgmt DB
│ │
└───────┬───────┘
│
Single Point
of Failure
-
- Greater Dependency on Configuration
The security of this architecture is heavily dependent on the correctness of its configuration.
Errors in areas such as:
VLAN
Trunk
ACL
Routing
Firewall
may result in unintended access or disruption of MongoDB communications.
-
- Shared Infrastructure
Database Traffic utilizes the same physical infrastructure as other services.
Consequently, under conditions of high network traffic, Database Traffic may also be affected by the capacity of that shared infrastructure.
Naturally, this depends on the link capacity, QoS, and overall network design of the organization, and does not imply a definitive issue.
-
- Dependency on the Core Switch
The Core Switch is of paramount importance in this architecture.
Should this switch experience failure without adequate Redundancy in place, the connections of multiple PVM Nodes to MongoDB may be severed simultaneously.
Therefore, in a Production environment, scenarios such as:
Core Switch Failure
Uplink Failure
NIC Failure
Link Failure
VLAN Misconfiguration
must be examined within the High Availability design.
-
- Risk of Misconfiguration
In VLAN-based architectures, errors in Tagging or Trunk Configuration may prevent Database traffic from reaching its intended destination or, in poorly designed implementations, may weaken the expected Segmentation.
For this reason, VLAN Configuration must be well-documented and tightly controlled.
Comparison with the Physical + Logical Isolation Architecture ↓
In the previous architecture, the database had a dedicated physical and logical path:
PVM
│
▼
Dedicated Physical Port
│
▼
Database Switch
│
▼
Database VLAN
│
▼
MongoDB
However, in this architecture:
PVM
│
▼
Shared Physical Network
│
▼
Core Switch
│
▼
Database VLAN
│
▼
MongoDB
The primary difference between these two architectures lies in the location where Isolation is enforced.
| Criterion | Physical + Logical Isolation | Logical Isolation via VLAN |
|---|---|---|
| Dedicated Physical Port | Yes | No |
| Dedicated Database Switch | Yes | No |
| Database VLAN | Yes | Yes |
| Physical Isolation | Yes | No |
| Logical Isolation | Yes | Yes |
| Shared Physical Infrastructure | Minimal | Yes |
| Dependency on VLAN/Trunk | Yes | Greater |
| Dependency on ACL | Yes | Yes |
| Dependency on Core Switch | Lower | Greater |
| Implementation Cost | Higher | Lower |
| Physical Complexity | Higher | Lower |
| Level of Separation | Higher | Lower |
| Suitable For | Sensitive and High-Security environments | Most enterprise environments with adequate Segmentation |
Security Distinction Between the Two Architectures ↓
In the Physical + Logical Isolation architecture:
Physical Isolation
+
Logical Isolation
+
ACL / Firewall
+
TLS
In the VLAN architecture:
Logical Isolation
+
ACL / Firewall
+
TLS
Thus, in the VLAN architecture, the Physical Isolation component has been omitted.
This does not necessarily imply that the VLAN architecture is insecure; rather, it indicates that its level of separation is not equivalent to that of an architecture featuring Physical Isolation, and its security is more heavily dependent on the correctness of the network design and configuration.
When Is This Architecture a Suitable Choice? ↓
This architecture is a suitable choice when:
-
The client is unable to allocate a dedicated Database Switch.
-
Allocation of an independent Physical Port for the database is not feasible.
-
The organization permits the creation of a Database VLAN on the existing network.
-
The Core Switch possesses sufficient capacity.
-
Appropriate ACLs / Firewall Policies can be implemented.
-
Access to MongoDB is restricted exclusively to specified sources.
-
Adequate Redundancy for the Core Network exists in the Production environment.
Under such conditions, Logical Isolation via VLAN may serve as a practical and acceptable architecture for connecting the PVM Cluster to MongoDB.
Summary of Limitations Compared to the Previous Architecture ↓
Physical + Logical Isolation
│
├── Physical Separation
├── Logical Separation
├── Dedicated DB Path
└── Higher Isolation
▲
│
Stronger
│
▼
Logical Isolation via VLAN
│
├── Logical Separation
├── Shared Physical Path
├── Shared Core Switch
└── Higher Dependency on Configuration
Therefore, if we were to rank these two architectures in terms of their Isolation Level:
Physical + Logical Isolation > Logical Isolation via VLAN
However, if the evaluation criteria are cost, simplicity, and utilization of existing infrastructure:
Logical Isolation via VLAN > Physical + Logical Isolation
PVM Single Node
In scenarios where PVM is implemented as a Single Node, the method of provisioning the database network depends on the deployment location of MongoDB.
MongoDB External to the PVM Server
In cases where MongoDB is running on a server external to PVM, the client must provide the dedicated Physical Network and Database VLAN to the implementation team.
In this configuration, the communication between PVM and the MongoDB server is established through the physical network and the dedicated database VLAN.
If it is not feasible to provide a dedicated Physical Port, the database network is implemented on the dedicated VLAN provided by the client.
Should the provision of a dedicated VLAN also be infeasible, VXLAN will be employed instead.
MongoDB on the Primary PVM Host
In cases where MongoDB is deployed as a Single Node on the primary PVM Host, there is no need to allocate a separate Physical Network for the database.
In this scenario, MongoDB's communication with other required services is established through the internal virtualization network, and a Host-Only Network is designated for internal communication.
Under this configuration, database traffic does not traverse an independent physical network; rather, communication is handled entirely at the PVM virtualization layer.
The Order of Database Network Provisioning is as Follows:
- Dedicated Physical Port + Database VLAN
In the ideal configuration, the client must allocate a dedicated Physical Port from the PVM servers to the database network. This port must reside within the dedicated database VLAN.
In this configuration:
- The allocated physical port for database traffic is segregated from other network traffic.
- The dedicated database VLAN is provided by the client.
- Communication between PVM Nodes and MongoDB is established through this network.
- This architecture provides both Physical Isolation and Logical Isolation.
- Database VLAN on the Existing Network Card
If allocating a dedicated Physical Port to the database network is not feasible, the client must provide the dedicated database VLAN on one of the existing network cards of the PVM servers.
In this configuration, the physical network infrastructure may be shared with other traffic, and database network segregation is enforced at the Logical level through VLANs.
The client must specify the following:
- The VLAN designated for the database.
- The Physical NIC on the PVM servers on which this VLAN is provisioned.
- That the corresponding port is capable of carrying the specified VLAN traffic.
- If Trunk configuration is used, that the database VLAN is permitted on the corresponding Trunk.
- The communication path between PVM Nodes and MongoDB for the database VLAN.
- VXLAN
If the client is unable to provide either a dedicated Physical Port or a Database VLAN, the database network must be implemented using VXLAN.
In this architecture, the database network is established as an Overlay over the existing infrastructure, and communication between PVM Nodes and MongoDB is established via VXLAN.
The detailed design and implementation of VXLAN — including the Underlay Network, VTEP, VNI, MTU, and Routing and Firewall requirements — will be presented in the subsequent sections of this document.
Note: The primary objective of this design is to establish the highest possible level of network isolation for database traffic, prevent its intermingling with Management traffic and other infrastructure networks, and ensure the security of the organization's data.
MongoDB Deployment Scenarios and PVM Communication Requirements
This document describes the various deployment scenarios for MongoDB within the PVM infrastructure, along with the network requirements necessary for establishing communication between PVM and MongoDB.
The scenario structure is defined based on three primary criteria:
- MongoDB Deployment Location: Inside or outside PVM
- PVM Deployment Type: Cluster or Single Node
- Network Provisioning Method: Dedicated NIC, dedicated VLAN, or VXLAN
Hierarchical Scenario Structure
MongoDB
│
├── MongoDB External to PVM
│ │
│ ├── PVM Cluster
│ │ │
│ │ ├── Dedicated NIC + Dedicated VLAN
│ │ ├── Shared NIC + Dedicated VLAN + Trunk
│ │ └── Shared NIC + VXLAN
│ │
│ └── PVM Single Node
│ │
│ ├── Dedicated NIC + Dedicated VLAN
│ ├── Shared NIC + Dedicated VLAN + Trunk
│ └── Shared NIC + VXLAN
│
└── MongoDB Inside PVM
│
├── PVM Cluster
│ │
│ ├── Dedicated NIC + Dedicated VLAN
│ ├── Shared NIC + Dedicated VLAN + Trunk
│ └── Shared NIC + VXLAN
│
└── PVM Single Node
│
└── Host-Only
MongoDB External to PVM
In this scenario, the MongoDB virtual machine or server resides outside the PVM infrastructure.
Consequently, regardless of whether PVM is deployed as a Cluster or as a Single Node, the existence of a network path between PVM and MongoDB is mandatory.
PVM Cluster
In the Cluster architecture, multiple PVM Nodes are present within the infrastructure, and MongoDB is deployed externally to PVM.
In this configuration, merely establishing communication between a single Node and MongoDB is insufficient; rather, all Nodes on which PVM services dependent on MongoDB are running must have access to MongoDB.
General Cluster Communication Requirements
To ensure proper communication in a Cluster architecture, the following conditions must be met:
- All PVM Nodes must have access to the MongoDB IP address.
- The network path between each PVM Node and MongoDB must be established.
- In the event that MongoDB comprises multiple Nodes, the required network communication between MongoDB Nodes must be established.
- All PVM Nodes must be able to connect to the MongoDB service port.
- If a Firewall exists between PVM and MongoDB, the necessary Rules for communication must be enforced on the Firewall.
- Routing between the PVM Subnet and the MongoDB Subnet must be established.
- If DNS is used for connecting to MongoDB, all PVM Nodes must be able to resolve the MongoDB name.
- The IP Address of the MongoDB network must be accessible on the correct Interface on each PVM Node.
- Network and MTU settings across all Nodes must be compatible with the selected architecture.
Dedicated NIC + Dedicated VLAN
In this approach, a dedicated Physical NIC is provisioned on each required PVM Node for MongoDB traffic, and this NIC is connected to the dedicated MongoDB VLAN.
As a result, MongoDB traffic is segregated from the traffic of other PVM networks.
Infrastructure Requirements
- Allocation of at least one dedicated Physical NIC on each PVM Node requiring MongoDB communication.
- Allocation of a specific, dedicated VLAN for the MongoDB network.
- Connection of the MongoDB-related NIC to the dedicated database network/VLAN.
- Allocation of a specific Subnet and IP Address for the MongoDB network.
- Creation of the MongoDB network Interface on each PVM Node.
- Ensuring the uniqueness of IP Addresses.
- Establishment of required Routing in the event of differing Subnets.
Cluster Communication Requirements
Database Network Topology
VLAN-DB • L2
3 Nodes → Switch (Access) → MongoDB
Accordingly:
PVM Node 1 ──► MongoDB
PVM Node 2 ──► MongoDB
PVM Node 3 ──► MongoDB
must be independently established.
If MongoDB comprises multiple Nodes:
MongoDB Node 1 ◄──► MongoDB Node 2
▲ ▲
│
└──── MongoDB Node 3
the required internal communication between MongoDB Nodes must also be established.
In this scenario, it is possible either to use a dedicated switch for the database or to route the connection directly from the Core Switch to the database.
Deployment Procedure
Step 1 — Preparation on the Physical Switch Side:
On the physical switch, we must configure the server ports as Access on the target VLAN (e.g., VLAN 200) and connect their network cables to, for example, the third NIC of the PVM cluster servers.
Step 2 — Creation of a Dedicated Bridge/VSwitch in PVM:
On the PVM master node, we create a new Linux Bridge/OVS (e.g., MongoDB-Traffic) and attach it to the third physical NIC (eno3). This Bridge/VSwitch has no IP address on the PVM Host itself — it is used exclusively by the virtual machines.
Step 3 — Attaching the vNIC of MongoDB Virtual Machines:
Each MongoDB virtual machine receives a vNIC on the MongoDB-Traffic interface. An IP address from the dedicated database network range (e.g., 172.16.50.0/24) is assigned to this vNIC.
Step 4 — MongoDB Bind Configuration:
MongoDB is configured to listen exclusively on the IP address associated with the database network — not on the IP address of the Management network.
🔧 From a technical perspective: In this scenario, because the switch port is Access, frames exiting the server are transmitted without a VLAN tag. The switch itself applies the VLAN 200 tag. Consequently, there is no need to configure VLAN Tagging within PVM. A simple, Untagged Bridge is sufficient.
Advantages
- Complete Physical Isolation: Database traffic traverses entirely separate cabling and ports
- No Bandwidth Contention: The database NIC does not compete with any other traffic
- Configuration Simplicity: No VLAN Tagging or Trunk configuration is required within PVM
- High Security: Even in the event of a Management network breach, direct access to the database network remains unavailable
- Optimal Performance: The lowest Latency and highest Throughput for Replication
Firewall Requirements
The Firewall must, at a minimum, address the following:
| Source | Destination | Service | Status |
|---|---|---|---|
| All PVM Nodes | MongoDB | MongoDB Port | Allow |
| MongoDB Nodes | MongoDB Nodes | MongoDB Internal Traffic | Allow, as required |
Shared NIC + Dedicated VLAN + Trunk
In this approach, due to the unavailability of a free physical NIC, MongoDB traffic traverses the existing NIC on the PVM server.
To segregate the traffic, a dedicated VLAN is created for MongoDB, and the port connected to PVM is configured as an 802.1Q Trunk.
Infrastructure Requirements
- Presence of a shared NIC on each PVM Node.
- Creation of a dedicated MongoDB VLAN.
- Configuration of the switch port as an 802.1Q Trunk.
- Passage of the MongoDB-related VLAN through the Trunk.
- Creation of a VLAN Interface on each PVM Node.
- Allocation of an IP Address to the VLAN Interface.
- Allocation of a specific Subnet for the MongoDB network.
- Ensuring the passage of the target VLAN throughout the entire network path.
- Establishment of Routing, as required.
Architecture
Trunk-Based VLAN Segmentation
Trunk Port • 802.1Q
Cluster Requirements
In the Cluster architecture, the MongoDB-related VLAN must be accessible on all Nodes requiring access to MongoDB.
In other words, VLAN presence on a single Node is not sufficient.
Node 1 ──┐
Node 2 ──┼── VLAN-DB ── MongoDB
Node 3 ──┘
All Nodes must:
- Possess a VLAN Interface for MongoDB.
- Hold a valid IP within the MongoDB Subnet.
- Be able to Ping/Reach MongoDB, provided ICMP is permitted.
- Be able to connect to the MongoDB service port.
- Resolve the MongoDB name, if DNS is used.
Deployment Procedure
Step 1 — Configuring the Trunk:
We have designated one network card for carrying virtual machine traffic on VLAN 300.
To simultaneously carry database traffic, we change the switch port connected to the server's NIC3 from Access to Trunk mode and add VLAN 200 (database traffic) to the list of Allowed VLANs. VLAN 300 will continue to serve as the general VLAN for virtual machine traffic.
Consequently, both VLAN 300 and VLAN 200 are carried through a single network card over a single Trunk link. In this manner, by leveraging logical traffic segregation over VLANs, the absence of a dedicated physical network card for MongoDB is compensated for.
Step 2 — Creating VLAN Interfaces in PVM:
On the PVM node, we must configure the Uplink-OVS in trunk mode and allow VLANs 200 and 300. We then add a separate configuration for each VLAN.
Step 3 — Assigning the Output Port to OVS: The Uplink configuration that we set as Trunk must be applied to the output network card, for example NIC3.
Step 4 — Assigning vNICs to MongoDB Virtual Machines:
The MongoDB virtual machine must receive the vNIC associated with its own VLAN's OVS configuration. Other virtual machines must receive the vNIC associated with their respective VLANs.
Critical Note: Why Not Trunk from the Management NIC?
Let us envision the scenario:
If we trunk from NIC1 (Management):
- MongoDB traffic (which may reach hundreds of megabits per second) would share a single physical link with PVM management traffic
- During peak database load periods, the link bandwidth becomes saturated
- Access to the PVM server's Web UI and SSH becomes disrupted or extremely slow
- Cluster communication between PVM nodes (Corosync) becomes disrupted, potentially triggering Fencing
- Effectively, control over the infrastructure is lost
Hence, the golden rule: Database traffic must always traverse the NIC dedicated to virtual machine traffic (NIC2 or NIC3) — never the management NIC.
Advantages and Limitations
Advantages:
- No additional physical port is required
- Logical isolation at Layer 2 through VLAN
- Relative simplicity in configuration
Limitations:
- Shared physical bandwidth of NIC2 between general VM traffic and database traffic
- In the event of link saturation, database performance is adversely affected
- Dependency on the Trunk configuration of the physical switch
Shared NIC + VXLAN
Under the network infrastructure conditions where neither a dedicated VLAN nor a separate physical port is available, the only available resources are the existing NICs of the server on the current network. In this scenario, we must construct our own Overlay network.
💡 In simple terms: Imagine you have neither a dedicated road nor a special lane. However, you can place database packets inside another wrapping (like an envelope within an envelope) and send them over the same public road. The recipient opens the outer envelope and extracts the original database packet. This is precisely what VXLAN does.
🔧 From a technical perspective: VXLAN (Virtual Extensible LAN) is a Layer 2 over Layer 3 Overlay protocol. Ethernet frames from the database network are encapsulated within UDP/IP packets and traverse the Underlay network (the VM traffic network). Each PVM node becomes a VTEP (VXLAN Tunnel Endpoint). VXLAN traffic uses UDP port 4789. Since VXLAN operates at Layer 3, there is no need for VLANs or switch modifications — it is sufficient that the PVM nodes are IP-reachable to one another.
Important Note: The VXLAN tunnel must be established from the VM traffic network IP — not from the Management network IP. The reasoning parallels the second scenario: heavy database traffic must not traverse the Management link. The VXLAN Overlay Network is established over the existing network to create a segregated logical network for MongoDB communication.
Architecture
VXLAN Overlay Architecture
L2 Over L3 • UDP 4789
VTEP (PVM) ══ Overlay Tunnel ══ VTEP (MongoDB)
Infrastructure Requirements
- Presence of a stable IP Underlay Network between VXLAN Endpoints.
- IP reachability between VXLAN Endpoints.
- Allocation of a specific VNI for the MongoDB network.
- Creation of a VXLAN Interface on the required Nodes.
- Allocation of an IP Address to the Overlay Network.
- Consistency of VXLAN settings across the relevant Endpoints.
- Ensuring MTU compatibility throughout the entire path.
- Ensuring the ability of the Underlay network to carry the required VXLAN traffic.
- Prevention of Fragmentation along the path, where possible.
- Establishment of required Routing for the Overlay network.
VXLAN Deployment Procedure
Step 1 — Ensuring Layer 3 Connectivity Between Nodes Over the VM Traffic Network:
Before proceeding, we must ensure that PVM nodes are reachable to one another via the VM Traffic network IP (e.g., 192.168.10.1 and 192.168.10.2). This IP may be configured on vmbr1 or directly on NIC2 or NIC3.
Step 2 — Creating a VXLAN Interface on Each Node:
On each PVM node, we create a VXLAN Interface with a specific VNI (e.g., 5000). This Interface must use the VM Traffic network IP as its Local VTEP, and its Remote VTEP must be the IP of the opposite node (on the VM Traffic network).
Step 3 — Creating a Dedicated Database Bridge/vSwitch:
We create a new Bridge/vSwitch and attach the VXLAN Interface to it. This Bridge/vSwitch provides the database Overlay network. At this stage, simply creating a Bridge (without OVS) is sufficient.
Step 4 — Attaching MongoDB Virtual Machines:
Each MongoDB VM is provided with a vNIC on which we configure an IP address. On the Bridge we created, the IP must be configured within the same range on each node.
Step 5 — MTU Configuration:
Since VXLAN adds additional headers (50 bytes) to each packet, the Underlay network's MTU must be set to at least 1550 (preferably 9000 for Jumbo Frames). Otherwise, large packets will be fragmented and performance will degrade.
Why Is the VTEP Established Using the VM Traffic Network IP?
The reasoning parallels that of the second scenario:
- The encapsulated VXLAN traffic contains MongoDB Replication data and can be extremely heavy
- If the VTEP is established using the Management network IP, all of this traffic will traverse NIC1
- Saturation of NIC1 means loss of access to the PVM Web UI and disruption of the Corosync Cluster
- By using the VM Traffic network IP, VXLAN traffic traverses NIC2, keeping NIC1 free exclusively for management
Advantages and Limitations of the Third Scenario
Advantages:
- No Dependency on Network Modifications: No additional VLANs or ports are required
- Complete Independence of the Database Team: No coordination with the organization's network team is required
- Scalability: Adding a new node requires only the addition of a new VTEP
- Flexibility: VXLAN operates even when nodes reside in different subnets (only Layer 3 Routing is required)
Limitations:
- Network Overhead: The VXLAN header adds approximately 50 bytes to each packet
- Troubleshooting Complexity: Network issues in the Overlay layer are more difficult to trace
- MTU Configuration Requirement: Without Jumbo Frames, fragmentation may occur
- CPU Consumption: VXLAN encapsulation and decapsulation impose some CPU overhead on the host
- Shared NIC2 Bandwidth: As with the second scenario, Overlay traffic shares a single physical link with general VM traffic
Cluster Requirements
In a Cluster, VXLAN must be established on all Nodes requiring access to MongoDB.
PVM Node 1 ── VXLAN ──┐
PVM Node 2 ── VXLAN ──┼── MongoDB
PVM Node 3 ── VXLAN ──┘
Additionally, if MongoDB comprises multiple Nodes, the required communication between MongoDB Nodes must also be established over the appropriate network.
PVM Single Node
In this architecture, only a single PVM Node exists, and MongoDB resides outside the PVM Host.
Since MongoDB is located outside the Host, network connectivity remains mandatory.
The following three methods are available:
- Dedicated NIC + Dedicated VLAN
- Shared NIC + Dedicated VLAN + Trunk
- Shared NIC + VXLAN
The implementation procedure for each scenario is identical to that of the Cluster mode; however, these configurations are presented in a single-server context. For this reason, no additional network architecture explanation is provided, as the steps mirror those outlined above.
Communication Requirements
In Single Node mode, only that single PVM Node must have access to MongoDB.
Consequently, unlike in the Cluster configuration, there is no need to establish MongoDB connectivity for multiple PVM Nodes.
Nevertheless, the following conditions must be met:
- Network path between PVM and MongoDB
- Appropriate IP Address
- Routing, as required
- Access to the MongoDB service port
- Required Firewall Rules
- DNS Resolution, if a domain name is used
- If a Replica Set is used, the required communication between MongoDB Nodes
MongoDB Inside PVM
In this scenario, the MongoDB virtual machine runs on the PVM infrastructure itself.
Depending on the PVM deployment type, two configurations exist:
- PVM Cluster
- PVM Single Node
PVM Cluster
In this configuration, MongoDB runs as a virtual machine on the PVM infrastructure, and multiple PVM Nodes exist within the Cluster.
Although MongoDB resides within the PVM infrastructure, the Cluster architecture still requires the design of an appropriate network for communication between the PVM Nodes and the MongoDB VM.
Three networking methods are available:
- Dedicated NIC + Dedicated VLAN
- Shared NIC + Dedicated VLAN + Trunk
- Shared NIC + VXLAN
Cluster Communication Requirements
Star Topology — VM Hosted on Node
Network VLAN • L2 Access
Switch → 3× NIC → PVM Nodes (MongoDB on Node 1)
Architectural Explanations
As illustrated in the depicted architecture, the MongoDB virtual machine is deployed and running on the first Node of the PVM Cluster.
The other Cluster Nodes (Node 2 and Node 3) connect to the first Node via the Cluster network and physical switch to access the MongoDB service, since the MongoDB VM is hosted on that Node.
In this architecture:
- PVM Node 1 functions as the Host serving the MongoDB virtual machine.
- PVM Node 2 and PVM Node 3 access the MongoDB VM through the network path.
- Communication between the Cluster Nodes is established through the Physical Switch and the defined network (such as a dedicated database VLAN).
- Access to MongoDB depends on the establishment of network connectivity between all Cluster Nodes and the Host Node of the MongoDB VM.
Consequently, all Cluster Nodes must have network access to PVM Node 1 and the MongoDB service running on it.
In this architecture, it must be specified that: All required PVM Nodes must have access to the MongoDB VM.
Core Requirements
- Access from all PVM Nodes to the MongoDB VM
- Assignment of an appropriate IP Address
- Establishment of Routing, as required
- Openness of the MongoDB service port
- Openness of the ports required for MongoDB internal communication
- Correct Firewall configuration
- MTU compatibility, if an Overlay Network is used
- If DNS is used, the ability to resolve names from all required Nodes
PVM Single Node
In this configuration, both PVM and the MongoDB virtual machine reside on a single physical Host.
Since both machines are located on the same Host, there is no need to establish a separate physical network for PVM–MongoDB communication.
Communication can be established through a Host-Only Network.
Communication Requirements
- Establishment of a Host-Only Network between PVM and the MongoDB VM
- Assignment of an IP Address to PVM on the Host-Only network
- Assignment of an IP Address to the MongoDB VM on the same network
- Placement of both Interfaces within the same Subnet
- Establishment of IP connectivity between PVM and the MongoDB VM
- Openness of the MongoDB service port
- No requirement for a dedicated physical NIC
- No requirement for a dedicated VLAN
- No requirement for a Trunk
- No requirement for VXLAN
Note: In this architecture, Host-Only is used exclusively for internal communication between PVM and the MongoDB VM. Any external network connectivity for MongoDB must be independently designed, as required.
Recommended Priority of Networking Methods
When multiple options are available, the following methods are recommended in order of preference:
Dedicated NIC + Dedicated VLAN The best option in terms of traffic segregation, implementation simplicity, and troubleshooting.
Shared NIC + Dedicated VLAN + Trunk A suitable option in the absence of a dedicated physical NIC.
Shared NIC + VXLAN A suitable solution when neither a dedicated NIC nor a dedicated VLAN can be provisioned, and an Overlay network must be established.
Host-Only Specific to the MongoDB Inside PVM + Single Node scenario, since PVM and MongoDB reside on the same Host.
The Golden Principle: Segregation of Management Traffic from Database Traffic
This section presents the most important rule in the network architecture for deploying MongoDB on PVM, and it applies to all three scenarios.
Decision Path — Which Scenario Should Be Selected?
Final Summary
Deploying MongoDB on PVM in an enterprise environment is, more than anything, a network architecture challenge rather than a software one. The correct selection among the three scenarios — physical port, VLAN Trunk, and VXLAN Overlay — depends on the level of client cooperation and the existing infrastructure.
Across all three scenarios, one immutable principle applies:
🔧 MongoDB database traffic must never traverse the Management network of the PVM servers. Always use the virtual machine traffic network (NIC2) — whether as VLAN, Trunk, or VXLAN.