When deploying GBase Database(GBase 8a), network design is more than an infrastructure detail. It directly affects how reliably an MPP cluster exchanges data, executes distributed queries, and serves client requests.
The reason for separating the data plane from the business plane becomes clearer when you look at how the database works.
1. Understand the Two Network Planes
GBase Database(GBase 8a) uses a Shared-Nothing MPP architecture with columnar storage. Data is distributed across nodes, each with its own local storage and computing resources.
When a query involves a large cross-node JOIN, the database may need to exchange substantial amounts of intermediate data between nodes. This traffic travels over the data plane, which must provide connectivity for all participating cluster nodes.
The business plane serves a different purpose: client access.
GCluster acts as the SQL entry point, handling SQL parsing, optimization, and distributed execution planning. Clients typically connect through GCluster rather than connecting directly to every GNode.
Separating these traffic paths makes the network architecture easier to manage and helps isolate internal cluster communication from external application traffic.
2. What Happens When Both Planes Share One Network?
Combining data-plane and business-plane traffic may appear to reduce deployment complexity. However, both traffic types then compete for network resources.
During a busy reporting period, large query results and client requests can consume bandwidth that internal cluster communication also needs. Depending on the workload and network configuration, this contention can increase latency and reduce overall query throughput.
The resulting symptom is familiar: the busier the system becomes, the less predictable its performance feels.
The problem may not be attributable to one SQL statement. Network congestion can affect multiple distributed operations simultaneously.
For GBase Database deployment planning, separating the two planes helps establish clearer traffic boundaries and simplifies troubleshooting.
3. Size Network Bandwidth for the Actual Workload
Network capacity should be based on expected traffic, concurrency, query patterns, and cluster scale—not a single universal number.
For example, a deployment design might consider:
- Internal network: 10GbE connectivity as an initial design point, subject to workload and node count.
- Aggregation layer: 40GbE links or higher where traffic modeling indicates that multiple nodes may saturate shared uplinks.
- Business network: 1GbE or higher, depending on client concurrency, result-set sizes, and application throughput requirements.
These are planning examples, not universal minimum requirements for every GBase Database(GBase 8a) deployment. Benchmarking and traffic estimation should determine the final design.
Analytical queries can return large result sets, so business-plane capacity matters as much as internal data exchange. If client-facing links become saturated, users may perceive the database as slow even when the underlying query execution is performing well.
4. Improve Link Resilience with NIC Bonding
Physical network separation can be combined with NIC bonding to improve link availability.
On Linux systems that use the traditional network-scripts configuration, an active/backup bond may resemble the following example.
# /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
TYPE=Bond
BONDING_OPTS="mode=1 miimon=100"
IPADDR=192.168.10.11
NETMASK=255.255.255.0
The physical interfaces are configured as bond members. A simplified example for each member is:
# Example settings for each physical interface
MASTER=bond0
SLAVE=yes
The complete interface files also require the appropriate device names and settings for the operating system and network configuration tool in use.
In this example:
-
mode=1configures active/backup bonding. -
miimon=100checks link status at 100-millisecond intervals.
Active/backup bonding provides link redundancy; it does not combine the bandwidth of both links. Also, link monitoring alone may not detect every upstream switch or end-to-end connectivity failure.
For stronger resilience, connect the two bond members to separate switches and verify that the switch topology, VLANs, and failover behavior are configured correctly. Where possible, consider independent power feeds and avoid sharing a single failure domain across critical network paths.
Note that network-scripts configuration is not supported by every modern Linux distribution. Use the networking tools supported by your target operating system.
5. Make Network Separation Part of Deployment Planning
Before installing GBase Database(GBase 8a), document:
- Which interfaces and IP addresses belong to each network plane.
- Which nodes require data-plane and business-plane connectivity.
- Expected bandwidth and aggregation requirements.
- Bonding configuration and switch redundancy.
- Firewall rules, routing, and connectivity validation procedures.
This information should be reviewed before hardware installation, not improvised after the cluster is running.
Final Takeaway
For GBase Database(GBase 8a), network plane separation is an architectural decision that influences scalability, resilience, and distributed query performance.
The data plane supports communication across the cluster. The business plane provides controlled client access. Designing them separately makes traffic behavior easier to reason about and failure boundaries easier to manage.
A reliable MPP deployment starts with a network topology designed for the workload—not simply one that allows every node to connect.
