Deploy an OceanBase cluster by using OCP
The following table describes the minimum configuration requirements of the servers.
Product |
Server quantity |
Minimum functional configuration |
Minimum performance configuration |
Disk type |
|---|---|---|---|---|
| OceanBase Admin Toolkit (OAT) | 1 You can also use the OCP server as the OAT deployment server. |
CPU: 2 cores Memory: 4 GB |
N/A | N/A |
| OceanBase Cloud Platform (OCP) | 1 | CPU: 16 cores Memory: 32 GB Disk: 1.5 TB. This configuration includes resources required for OAT. NoteA server configuration of 16 CPU cores and 32 GB of memory does not ensure the stability of OCP. We recommend that you use such configuration for verification only. |
CPU: 32 cores Memory: 128 GB Disk: 1.5 TB. NIC: 10 Gbit/s. This configuration includes resources required for OAT. |
SSD |
| OceanBase cluster | 3
NoteTo deploy a standalone OceanBase database, you need to prepare only one server. |
CPU: 4 cores Memory: 16 GB Note
|
CPU: 32 cores Memory: 256 GB NIC: 10 Gbit/s Note
|
SSD |
| (Optional) OceanBase Database Proxy (ODP) | 3 You can use the OBServer nodes as the ODP deployment servers. |
CPU: 4 cores Memory: 8 GB Disk: 200 GB |
N/A | N/A |
Note
- An OceanBase cluster consists of at least three nodes for high availability and disaster recovery, and each node corresponds to an observer process. Multiple observer processes on different nodes form a cluster to provide services to external users.
- To ensure the high availability of OCP services, you must deploy OCP on multiple servers. For more information, see Deployment of OCP.
- After you deploy an OceanBase cluster, you need to determine whether to deploy ODP based on your application scenario and requirements.
- If you need to perform high availability, load balancing, or connection pool management operations on the OceanBase cluster, you can deploy ODP. ODP can effectively resolve issues related to the number of connections and load balancing of the OceanBase cluster to improve the stability and reliability of applications.
- If you only need to connect to the OceanBase cluster for general queries and operations and do not need to perform high availability, load balancing, or connection pool management operations, you can choose not to deploy ODP. In this case, you can directly use the client library provided by OceanBase Database to connect to the cluster.
Deploy an OceanBase cluster by using the CLI
The following table describes the minimum configuration requirements of the servers.
Product |
Server quantity |
Minimum functional configuration |
Minimum performance configuration |
Disk type |
|---|---|---|---|---|
| OAT | 1 | CPU: 2 cores Memory: 4 GB |
N/A | N/A |
| OceanBase cluster | 3
NoteTo deploy a standalone OceanBase database, you need to prepare only one server. |
CPU: 4 cores Memory: 16 GB Note
|
CPU: 32 cores Memory: 256 GB NIC: 10 Gbit/s Note
|
SSD |
| (Optional) ODP | 3 You can use the OBServer nodes as the ODP deployment servers. |
CPU: 4 cores Memory: 8 GB Disk: 200 GB |
N/A | N/A |
Note
- To ensure high availability and disaster recovery, an OceanBase cluster needs at least three servers, each with an observer process. These processes across different servers work together to provide services.
- After you deploy an OceanBase cluster, you can decide whether to deploy ODP based on your application scenarios and requirements.
- If your applications require such features of the OceanBase cluster as high availability, load balancing, and connection pool management, you can deploy ODP. ODP effectively solves issues about the number of connections and load balancing in OceanBase clusters and improves the stability and reliability of applications.
- If your applications connect to the OceanBase cluster simply for queries and operations without requirements on high availability, loading balancing, or connection pool management, ODP is not necessary. You can directly connect to the OceanBase cluster by using OBClient.
Arbitration server
The following table describes the minimum configuration requirements for the arbitration server when you use three servers to deploy an OceanBase cluster with two replicas and the arbitration service.
Version |
Minimum server specifications |
Bandwidth |
Remarks |
|---|---|---|---|
| V4.1.0.0 |
|
At least 20 Mbit/s input and output data transmission | Data disks are not required, but you must reserve sufficient disk space for the log directory to store log files. |
| V4.1.0 BP1 and later |
|
At least 20 Mbit/s input and output data transmission | Data disks are not required, but you must reserve sufficient disk space for the log directory to store log files. |
Resource planning
The following CPU model is for your reference: Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz.
Observe the following rules when you plan resources for the arbitration server:
- By default, a server with the minimum specification (2 CPU cores and 4 GB memory) can support 32 user tenants and the sys tenant simultaneously with the arbitration service enabled (2F or 4F,
primary_zone=RANDOM,unit_num=1). - For every additional 32 single-unit tenants (2F or 4F,
primary_zone=RANDOM,unit_num=1), the resources of the arbitration server need to be increased accordingly by at least 1 CPU core, 1 GB memory, 2 GB log disk space, and 20 Mbit/s network bandwidth. - When
unit_num=N(N>1), you can simply take it as N single-unit tenants.
Note
- 2F indicates a cluster with two replicas.
- 4F indicates a cluster with four replicas.
primary_zone=RANDOM: You can setPRIMARY_ZONEtoRANDOM(uppercase), indicating that any zone with the top priority can be randomly taken as the primary zone.unit_num=1: The target zone has one unit in the resource pool.- A single-unit tenant has one unit in a zone.
primary_zone and unit_num, see Create a tenant.
Network latency requirements
The one-way network latency between the arbitration server and an OBServer node of the OceanBase cluster must be less than or equal to 800 ms.