OCPを使用したOceanBaseクラスタのデプロイ
サーバーが満たすべき最小構成要件は以下の表のとおりです。
デプロイ製品 |
サーバー数 |
機能の最低構成 |
性能の最低構成 |
ディスクタイプ |
|---|---|---|---|---|
| OAT | 1台、OCPサーバーと共用可能 | CPU：2コア メモリ：4GB |
N/A | N/A |
| OCPおよびMetaDB | 1台 | CPU：16コア メモリ：32GB ディスク：1.5TBストレージ（OATが必要とするリソースを含む） 説明16C32Gの構成ではOCPの安定性を保証できません。検証用途にのみ使用することを推奨します。 |
CPU：32コア メモリ：128GB ディスク：1.5TB、10ギガビットNIC（OATが必要とするリソースを含む） |
SSDストレージ |
| OceanBaseクラスタ | 3台
説明単一マシン版OceanBaseデータベースをデプロイする場合は、1台のサーバーのみを準備する必要があります。 |
CPU：4コア メモリ：16GB 説明
|
CPU：32コア メモリ：256GB、10ギガビットNIC 説明
|
SSDストレージ |
| （オプション）ODP | 3台、OBServerノードサーバーと共用可能 | CPU：4コア メモリ：8GB ディスク：200GB |
N/A | N/A |
説明
- OceanBaseデータベースクラスタの高可用性とディザスタリカバリには、少なくとも3つのノードが必要です。各ノードは1つのobserverプロセスに対応し、異なるノード上の複数のobserverプロセスが1つのクラスタを形成して外部にサービスを提供します。
- OCP管理サービスに高可用性機能を提供させる場合は、複数の管理サーバーを用いた高可用性デプロイが必要です。詳細については、OCPデプロイの概要を参照してください。
- OceanBaseクラスタのデプロイ後、ODPをデプロイするかは、主にアプリケーションのシナリオとニーズによって決まります：
- アプリケーションでOceanBaseクラスタに対して高可用性、ロードバランシング、接続プール管理などの操作が必要な場合は、ODPのデプロイを検討できます。ODPはOceanBaseクラスタの接続数やロードバランシングなどの問題を効果的に解決し、アプリケーションの安定性と信頼性を向上させます。
- アプリケーションが単純にOceanBaseクラスタに接続してクエリや操作を実行するだけであり、高可用性、ロードバランシング、接続プール管理などの操作が不要な場合は、ODPをデプロイせずに、OceanBaseが提供するクライアントライブラリを使用してクラスタに直接接続することで、アプリケーションの要件を満たせます。
- カラムストアレプリカを使用する場合は、独立したODPをデプロイする必要があります。カラムストアレプリカの詳細については、カラムストアレプリカを参照してください。
コマンドラインを使用したOceanBaseクラスタのデプロイ
サーバーが満たすべき最低構成要件は以下の表のとおりです。
デプロイ製品 |
サーバー数 |
機能の最小構成 |
性能の最小構成 |
ディスクタイプ |
|---|---|---|---|---|
| OAT | 1台 | CPU：2コア メモリ：4GB |
N/A | N/A |
| OceanBaseクラスタ | 3台
説明Standalone EditionのOceanBaseデータベースをデプロイする場合は、サーバーを1台のみ準備する必要があります。 |
CPU：4コア メモリ：16GB 説明
|
CPU：32コア メモリ：256GB、10ギガビットNIC 説明
|
SSDストレージ |
| （オプション）ODP | 3台、OBServerノードサーバーと共用可能 | CPU：4コア メモリ：8GB ディスク：200GB |
N/A | N/A |
説明
- OceanBaseデータベースクラスタの高可用性とディザスタリカバリでは、少なくとも3つのノードで構成されます。各ノードには1つのobserverプロセスが対応し、各ノード上の複数のobserverプロセスが1つのクラスタを形成して外部にサービスを提供します。
- OceanBaseクラスタのデプロイ後、ODPをデプロイするかは、主にアプリケーションのシナリオと要件によって決まります：
- アプリケーションでOceanBaseクラスタに対して高可用性、ロードバランシング、接続プール管理などの操作が必要な場合は、ODPのデプロイも選択肢の一つです。ODPはOceanBaseクラスタの接続数やロードバランシングなどの問題を効果的に解決し、アプリケーションの安定性と信頼性を向上させることができます。
- アプリケーションが単純にOceanBaseクラスタに接続してクエリや操作を実行するだけでよく、高可用性、ロードバランシング、接続プール管理などの操作が不要な場合は、ODPをデプロイせずに、OceanBaseが提供するクライアントライブラリを使用してクラスタに直接接続することで、アプリケーションの要件を満たせます。
- カラムストアレプリカを使用する場合は、独立したODPをデプロイする必要があります。カラムストアレプリカの詳細については、カラムストアレプリカを参照してください。
アービトレーションサーバー
3台のサーバーを使用して2レプリカのOceanBaseクラスタとアービトレーションサービスをデプロイする場合、アービトレーションサーバーは以下に示す最低マシン仕様を満たしている必要があります：
バージョン |
サポートされる最小構成 |
帯域幅 |
備考 |
|---|---|---|---|
| V4.1.0.0 |
|
入出力データの転送レートは、いずれも少なくとも20Mbpsである必要があります。 | データ保存用のディスク容量(dataディスク)の設定は不要です。ログファイルを格納するlogディレクトリには、別途空き容量を確保する必要があります。 |
| V4.1.0 BP1以降のバージョン |
|
入出力データの転送レートは、いずれも少なくとも20Mbpsである必要があります。 | データ保存用のディスク容量(dataディスク)の設定は不要です。ログファイルを格納するlogディレクトリには、別途空き容量を確保する必要があります。 |
リソース計画
CPU型番の参考：Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
アービトレーションサーバーのリソース計画は、以下のルールを参考にしてください：
- 最小構成マシン(2C4G)は、デフォルトで32個のユーザーテナントと
sysテナントが同時にアービトレーションを有効にできます(2Fまたは4F、primary_zone=RANDOM、unit_num=1)。 - 単一Unitテナント(2Fまたは4F、
primary_zone=RANDOM、unit_num=1)が32個増えるごとに、アービトレーションサーバーのリソースは少なくとも以下のように増やす必要があります：1C1G、ログディスク2GB、ネットワーク帯域幅20Mbps。 unit_num=N(N>1)の場合、単純にN個の単一Unitテナントとして扱うことができます。
説明
- 2F：2レプリカクラスタ。
- 4F：4レプリカクラスタ。
primary_zone=RANDOM：PRIMARY_ZONEを指定する場合、その値をRANDOM(必ず大文字)に設定できます。これは、最も高い優先順位を持つゾーンの中からランダムに1つを選択してPrimary Zoneとすることを意味します。unit_num=1：リソースプールの対象ZoneにおけるUnit数が1であることを示します。- 単一Unitテナント：あるZone内のUnit数が1のテナントです。
primary_zoneとunit_numの詳細については、テナントの作成を参照してください。
ネットワーク遅延要件
アービトレーションサーバーとOceanBaseクラスタノード間の往復ネットワーク遅延は800ms以下である必要があります。