ノード間で共有するテーブルと分散するテーブルの決定
レプリケーションテーブルを使用してすべてのノードでテーブルを共有するか、シャードを使用してテーブルを分散するか、システムのアクセスパターンに応じてテーブルの定義方法を決定してください。
ノードに閉じたテーブルと全ノードに跨るリレーションの決定
ノードに閉じて定義するテーブルとノードを跨って定義するテーブルを決定してください。決定した後はDDLの一元実行の機能を使用し、定義してください。
ノードに跨るテーブルデータの配置の決定
シャードを使用して分散する場合、以下の考え方をもとにして配置方法を決定してください。
業務の単位(例えば銀行単位)を基準としてテーブルを分割してください。
CPU、メモリ、ネットワーク、記憶装置の帯域や容量などのリソース、あるいはバックアップ時間などの平準化を基準として分割してください。
ノード数の決定
各ノードの冗長化と裁定サーバの設置が必須です。データノードの数はテーブルの分割数によって決定してください。
ネットワーク構成の決定
本機能では以下のネットワークを使用します。
ネットワークの種類 | 目的 |
|---|---|
業務用ネットワーク | データベースにアクセスするアプリケーションとデータベースサーバ間のネットワークです。 |
ノード間ネットワーク | 中央管理ノードとデータノード間のネットワークです。 |
裁定用ネットワーク | 裁定サーバがプライマリサーバとスタンバイサーバの状態確認やデータベースサーバのMirroring Controllerと通信するためのネットワークです。また、業務用ネットワークが外部から切り離されている場合には、裁定用ネットワークと兼用することができます。ネットワークのセキュリティについては“クラスタ運用ガイド(データベース多重化編)”の“データベース多重化におけるセキュリティ”を参照してください。 |
管理用ネットワーク | プライマリサーバおよびスタンバイサーバのMirroring Controllerによる相互監視や、他サーバのMirroring Controllerを制御するために使用するネットワークです。 |
ログ転送用ネットワーク | データベースを多重化するために、データベースのトランザクションログの転送などに使用するネットワークです。 |
裁定用ネットワークは、管理用ネットワークやログ転送用ネットワークでの回線障害や負荷の影響を受けないネットワークを利用してください。管理用ネットワークやログ転送用ネットワークの異常を正しく判断するために必要です。
ノード間ネットワークは、業務の負荷によっては業務用ネットワークと兼用することができます。しかし、ノードを跨ぐ業務の性能が求められる場合には、ノード間ネットワークを業務用ネットワークと分離し、高速なネットワークを利用することを推奨します。
ノード間通信を外部から切り離していない場合、SSL認証を使用してノード間通信を暗号化できます。SSL認証については、“3.8 スケールアウト環境におけるSSL(Secure Sockets Layer)による安全な通信の構成”を参照してください。
SLA（Service Level Agreement）を満たすためのパラメータの決定
データノードおよび中央管理ノードがダウンしたときの復旧時間を決定してください。 この復旧時間をもとにScale out Controller、Mirroring Controllerの設定が決まります。
arbitration_wait_time
以下に示す(1)、(2)および(3)のうち、最も長い時間を設定してください。
(1) Mirroring ControllerがOS/サーバの異常検知するまでの最長時間
(heartbeat_timeout(秒) + heartbeat_interval(ミリ秒) / 1000 ) × (heartbeat_retry(回数) + 1)
(2) Mirroring ControllerがConnection Managerの無応答を検知するまでの最長時間
(conmgr_check_timeout(秒) + conmgr_check_interval(ミリ秒) / 1000) × (conmgr_check_retry(回数) + 1)
(3) Mirroring Controllerがノード間ネットワークの異常を検知するまでにかかる最長時間
Connection Managerのheartbeat_timeout(秒) + (conmgr_check_timeout(秒) + conmgr_check_interval(ミリ秒) / 1000) × (conmgr_check_retry(回数) +1)
remote_call_timeout
Scale out Controllerプロセスから裁定プロセスに対して処理を呼び出した際に、指定した秒数以上の間、応答がない場合、処理に失敗したと判断します。裁定プロセスの処理にかかる最長時間を指定してください。
Mirroring Controller裁定プロセスの処理にかかる最長時間は、裁定プロセスが管理するノードの各サーバ(プライマリサーバ、スタンバイサーバ)のMirroring Controllerプロセスとの処理にかかる時間の合計です。
プライマリサーバのMirroring ControllerをMC1、スタンバイサーバのMirroring ControllerをMC2とした場合のremote_call_timeoutの算出方法は以下です。
remote_call_timeout = MC1のremote_call_timeout + MC2のremote_call_timeout + Mirroring Controller裁定-MC1間のハートビートにかかる時間 + Mirroring Controller裁定-MC2間のハートビートにかかる時間
備考)
Mirroring Controller裁定とMirroring Controllerのハートビートにかかる時間は以下のように算出します。
(arbiter_alive_timeout + arbiter_alive_interval) × (arbiter_alive_retry + 1)
conmgr_check_interval
conmgr_check_timeout
conmgr_check_retry
それぞれ、Mirroring Controllerのサーバ識別子.confファイルに設定する、heartbeat_interval、heartbeat_timeout、heartbeat_retryに相当します。
設定値の算出方法については、“クラスタ運用ガイド(データベース多重化編)”の“裁定サーバを利用して自動縮退を行う運用の異常監視のチューニング”を参照して設定してください。
ただし、実際にMirroring Controllerがノード間ネットワークの異常を検知するまでにかかる時間は、Connection Manager監視間隔の設定(Connection Managerのheartbeat_timeout、heartbeat_intervalの設定値)に影響されます。
