The most expensive mistakes in database deployment often happen before anyone runs the installation command.
For GBase Database(GBase 8a), a Shared-Nothing MPP analytical database with columnar storage, node roles, network topology, hardware specifications, and port allocation all affect deployment readiness. If these decisions are left until installation, problems can emerge together when workloads and data volumes grow.
My approach is simple: complete four planning tables before requesting hardware.
1. Network Plane Planning
GBase Database(GBase 8a) uses two network planes for different purposes:
- Data plane: Connects cluster nodes and carries internal data exchange and cluster communication.
- Business plane: Handles client access, typically through GCluster nodes.
Separating these traffic paths helps reduce contention and makes network troubleshooting easier.
A deployment might consider 10GbE for internal connectivity, 40GbE aggregation, and 1GbE or higher for external access. These are planning reference points, not universal requirements; actual bandwidth depends on node count, query patterns, concurrency, and workload.
For resilience, dual-NIC active/standby bonding across separate switches can reduce the impact of a single link or switch failure, provided the network and failover configuration are designed correctly.
Document the interface assignments, IP addresses, switch connections, bandwidth requirements, and firewall rules before installation.
2. Cluster Sizing: Plan Around Data Node Count
GBase Database cluster sizing should account for the number of Data nodes, coordinator capacity, management requirements, and expected workload.
The following table illustrates one proposed sizing plan. Confirm these values against the deployment guide for your specific GBase Database(GBase 8a) release before procurement.
| Data nodes (D) | GCluster nodes | GCware nodes |
|---|---|---|
| D less than 10 | 3 | 3 |
| 10 ≤ D less than 30 | 5 | 3 |
| 30 ≤ D less than 100 | 7 or 9 | 3 |
| D ≥ 100 | 9 or 11 | 3 |
The key benefit of a sizing table is consistency. Instead of choosing node counts by intuition, the team can document its assumptions and review the proposed architecture before ordering machines.
The final configuration should also account for query concurrency, availability requirements, and the capacity of each coordinator.
3. Hardware and RAID Configuration
Hardware planning should distinguish minimum installation requirements from production capacity.
The initial specification may include CPU, memory, system disks, data disks, RAID configuration, and network interfaces. For example, 256GB of memory might be a production planning target, while 32GB could be considered a lower reference point for a particular deployment. Neither figure should be treated as a universal requirement without checking the target release and workload.
Likewise, RAID1 for system disks and RAID5 for data disks are possible design choices, not mandatory configurations for every environment.
Before procurement, document:
- CPU count, core count, and frequency.
- Memory capacity and expected workload.
- System and data disk layout.
- RAID level, usable capacity, and redundancy.
- Storage growth and backup requirements.
Avoid sizing production systems around the minimum needed to start a service. Query concurrency, memory-intensive operations, and intermediate results can create very different resource demands under load.
4. Port Inventory and Pre-Installation Checks
Port conflicts can delay deployment or prevent services from starting. Record the required ports for each component and validate them against the documentation for your GBase Database version.
The following is an example port inventory to verify for the target environment:
| Component or service | Port |
|---|---|
| GCluster | 5258 |
| GNode | 5050 |
| GCware | 5918, 5919 |
| syncServer | 5288 |
| GCRecover | 6268 |
| Remote management | 16066–16166 |
Run a basic check on every node before installation:
#!/bin/bash
for p in 5258 5050 5918 5919 5288 6268; do
if ss -H -lnt 2>/dev/null |
awk -v port="$p" '
{
addr = $4
sub(/^.*:/, "", addr)
if (addr == port) found = 1
}
END { exit !found }
'; then
echo "LISTENING: $p"
else
echo "No TCP listener found: $p"
fi
done
free -h
nproc
df -h /data
This script checks for TCP listeners on the listed ports and reports basic system resources. A port with no listener is not necessarily available under every configuration, so also verify firewall rules, service requirements, and other protocol usage where relevant.
Save the results with the machine inventory. Repeat the checks after replacing, reinstalling, or cloning nodes.
Understand the Cluster Roles
A clear deployment plan also identifies what each component does:
- GCware: Provides cluster consistency services and cluster metadata management.
- GCluster: Handles SQL parsing, optimization, and distributed execution planning.
- GNode: Handles data storage and computation.
GCluster and GCware may be colocated in a combined Coordinator node, depending on the deployment architecture.
Symmetric and asymmetric deployment designs offer different trade-offs. Symmetric designs can reduce machine count and simplify infrastructure. Asymmetric designs separate management and data roles, which may improve isolation but require additional resources and operational planning.
Choose based on cluster scale, workload, availability requirements, and the intended failure domains—not simply a preference for one topology.
Verify Operating System Compatibility Early
Operating system compatibility is another procurement prerequisite.
All nodes within a Virtual Cluster must meet the version-consistency requirements of the target GBase Database release. Python dependencies and supported operating system versions can also vary by release.
Before provisioning, confirm the supported distribution, exact OS version, required packages, and Python configuration against the official deployment documentation. Do not assume that a prerequisite documented for one CentOS, RHEL, Kylin, or UOS release automatically applies to another.
These checks are much easier to complete before machines are installed and configured.
A Repeatable GBase Database Deployment Workflow
A practical workflow is:
- Complete the network plane design.
- Confirm cluster topology and node sizing.
- Finalize hardware and RAID specifications.
- Validate port allocation and operating system compatibility.
- Provision machines and configure networking.
- Run pre-installation checks on every node.
- Archive the approved tables and check results for future expansion.
This turns deployment planning into a repeatable engineering process rather than a collection of individual experiences.
The takeaway: GBase Database deployment quality is heavily influenced by decisions made before installation. Four well-maintained planning tables can align hardware procurement, network configuration, cluster sizing, and operational readiness.
Which causes more rework in your projects: network design or cluster sizing?
Top comments (0)