GBase Financial Application Guide 3 | GBase 8a MPP Cluster Deployment Architecture
To help financial institutions select the right distributed analytical database products and to share best practices for deploying such databases in the financial industry, GBase compiled the GBase 8a Financial Application Guide under the guidance of the Beijing Fintech Industry Alliance. This guide walks through the full deployment lifecycle of distributed analytical databases—from selection planning and development design standards to data security, high availability, and operational optimization. It also presents representative GBase 8a MPP Cluster deployment cases at national policy banks and large state-owned banks.
We will release a series of articles to share and interpret the guide’s content to help financial users make informed database choices and to drive the efficient implementation and high-quality development of technology-driven finance.
This is the third installment, further exploring the deployment architecture of distributed analytical databases.
1. Deployment Architecture
GBase 8a offers multiple deployment forms to meet various infrastructure requirements in production environments. These address security needs such as resource isolation between workloads and active-active disaster recovery, and also satisfy the demands of IT application innovation environments that mix different software and hardware.
The technologies used in each deployment form and their applicable scenarios are summarized in the table below.
Table 1 GBase 8a MPP Cluster Deployment Modes
GBase 8a Single-VC Deployment Architecture
In a single-VC deployment, all data shares the same pool of computing resources.
Figure 1 GBase 8a Single-VC Deployment Architecture
GBase 8a Multi-VC Deployment Architecture
Based on business requirements or hardware/software conditions, resources are partitioned into multiple Virtual Clusters (VCs) with fully isolated computing. All VCs are managed centrally by the management cluster.
Figure 2 GBase 8a Multi-VC Deployment Architecture
GBase 8a Active-Active (Same Data Center) Deployment Architecture
To ensure high availability or implement read-write splitting, mirroring technology maintains real-time identical data in designated databases or tables between two VCs. If the site housing one VC experiences a full failure, the VC at the other site can continue to serve requests.
Figure 3 GBase 8a Active-Active (Same Data Center) Deployment Architecture
GBase 8a Active-Active (Remote Disaster Recovery) Deployment Architecture
Two clusters deployed in separate data centers use GBase’s synchronization tool to achieve full and incremental data synchronization for specified tables, reducing the impact of an entire data center failure.
The cross-cluster synchronization tool operates asynchronously and is typically used for scenarios with less stringent real-time requirements, with the primary cluster handling reads and writes and the standby cluster handling reads.
Figure 4 GBase 8a Active-Active (Remote Disaster Recovery) Deployment Architecture
GBase 8a Two-Site Three-Center Deployment Architecture
By combining local active-active and remote disaster recovery, a two-site three-center deployment delivers higher data protection.
• The primary data center achieves real-time active-active through mirroring;
• Between the standby and primary data centers, asynchronous synchronization tools provide near-real-time active-active disaster recovery.
Figure 5 GBase 8a Two-Site Three-Center Deployment Architecture
2. Multi-Instance Deployment
With rapid hardware advances and the push for domestic technology adoption—hard drives shifting from HDDs to SSDs, Chinese-made chips commonly using NUMA architecture, and CPUs evolving from 16 or 24 cores to 64 or 96 cores—the GBase 8a cluster adopts a new multi-instance deployment architecture to make full use of high-end domestic servers (typically NUMA-based).
The multi-instance deployment architecture is mainly applied in the following scenarios:
• When a server is NUMA-based with multiple nodes, a single database instance frequently accessing memory across NUMA nodes delivers suboptimal performance;
• A single database instance cannot fully leverage the processing power of SSDs, NVMe drives, and other new hardware.
GBase 8a MPP Cluster V9.5.3 officially supports multi-instance deployment. By deploying multiple database instances (gnode instances) on a single server, this approach overcomes the underutilization problem and boosts cluster performance.
Multi-Instance Deployment Architecture
Without multi-instance, a single server hosts one gnode instance. With multi-instance, a server hosts multiple gnode instances (typically 2 to 4 are recommended), each assigned a dedicated IP address to distinguish between instances.
Figure 6 Multi-Instance Deployment Architecture
3. Network Topology
Network Plane Types
GBase 8a MPP Cluster network planning divides into two physically isolated planes: the data plane network and the service plane network.
• The data plane network handles intra-cluster data operations and cluster management, also called the internal cluster network;
• The service plane network provides access for business applications, also called the external cluster network.
Figure 7 GBase 8a MPP Cluster Network Planning Diagram
Networking Scheme
A two-plane network scheme is generally recommended, with data exchange servers (FTP/HTTP/HDFS, etc.) deployed on the data plane network.
The intra-cluster network should use 10GE or higher Ethernet, with the internal aggregation switch using 40GE. The external cluster network's bandwidth should be planned according to business concurrency, data volumes, and other requirements; for big data platforms with modest data exchange needs, 1GE or higher Gigabit Ethernet usually suffices.