設計上の決定

設計上の決定には、ピーク負荷または通常状態負荷のどちらのためにシステムを設計するか、およびさまざまな役割にあるマシンの数とそれらのサイズが含まれます。

ピーク負荷または通常状態負荷のための設計

標準的な配備では、通常状態とピークの作業負荷の間に違いが存在します。

• システムがピーク負荷を処理するように設計されている場合は、応答時間を低下させることなく、ユーザーや要求の予測される最大の負荷に耐えることができます。これは、システムが、予測されるシステム負荷の極端な場合を処理できることを示します。ピーク負荷と通常状態負荷の違いが大きい場合は、ピーク負荷のために設計すると、アイドル状態の場合が多いリソースにお金をかけることになります。

• システムが通常状態負荷を処理するように設計されている場合は、予測されるピーク負荷を処理するために必要とされるすべてのリソースを持っているわけではありません。そのため、ピーク負荷が発生すると、システムの応答時間が低下します。

システムでピーク負荷をどれだけ頻繁に処理すると予測されるかによって、ピーク負荷または通常状態負荷のどちらのために設計するかが決定されます。

ピーク負荷が頻繁に、たとえば 1 日に数回発生する場合は、それを処理できるように容量を拡張するだけの価値があるかもしれません。システムが時間全体の 90 パーセントを通常状態で動作し、ピーク負荷での動作が 10 パーセントしかない場合は、通常状態負荷のために設計されたシステムを配備する方が望ましい可能性があります。これは、システムの応答時間が時間全体の 10 パーセントだけ低下することを示します。システムがピーク負荷で動作する頻度または所要時間によって、システムにリソースを追加する必要性が正当化されるかどうかを判断してください。

システムのサイジング

アプリケーションサーバーインスタンスへの負荷、HADB への負荷、およびフェイルオーバーの要件に基づいて、次の値を決定できます。

• 「Application Server インスタンスの数」

• 「HADB ノードの数」

• 「HADB ホストの数」

• 「HADB のストレージ容量」

Application Server インスタンスの数

必要なアプリケーションサーバーインスタンス (ホスト) の数を決定するには、各インスタンスが複数の中央処理装置 (CPU) を使用できるとしても、「Application Server インスタンスへの負荷の見積もり」で説明した各アプリケーションサーバーインスタンスに対する要因に基づいて環境を評価します。

HADB ノードの数

一般的なガイドラインとして、システム内の各 CPU に 1 つの HADB ノードを割り当てるように計画します。たとえば、2 つの CPU を備えたマシンには 2 つの HADB ノードを使用します。

---

注 –

マシンあたりに複数の HADB ノードを割り当てている (たとえば、大型のマシンを使用している) 場合は、マシン上に十分な冗長性とスケーラビリティー (たとえば、複数の無停電電源装置や独立したディスク制御装置) が必ず存在するようにしてください。

---

あるいは、次の手順を使用します。

必要な HADB ノードの数を決定するには

1. 次のパラメータを決定します。

   • 並行ユーザーの最大数、n_users。

   • 平均の BLOB サイズ、s。

   • NTPS と呼ばれる、ユーザーあたりの最大トランザクション比率。

2. 最大プライマリデータ量の G バイトのサイズ、V _data を決定します。

   次の数式を使用します。

   V_data = n_users ^. s

3. 最大 HADB データ転送速度、R _dt を決定します。

   この値には、アプリケーション側から HADB に転送されるデータ量が反映されます。次の数式を使用します。

   R_dt = n_users ^. s ^. NTPS

4. ノードの数、N _NODES を決定します。

   次の数式を使用します。

   N_NODES = V_data /5GB

   ノードはペアで動作するため、この値を偶数に丸めます。

HADB ホストの数

データ転送の要件に基づいて、HADB ホストの数を決定します。この計算では、すべてのホストが同じハードウェア構成とオペレーティングシステムを備え、かつ実行するノードを格納するために必要なリソースを含んでいることを前提にしています。

ホストの数を計算するには

1. 最大ホストデータ転送速度、R _max を決定します。

   この値はネットワークやホストのハードウェアによって異なるため、経験に基づいて決定します。この値は、前の節で決定した最大 HADB データ転送速度、R _dt とは異なることに注意してください。

2. このデータを格納するために必要なホストの数を決定します。

   ホストの数 N _HOSTS に分散されるデータ量 V を更新すると、各ホストは約 4V/N _HOSTS のデータを受信するようになります。次の数式を使用して、このデータ量を格納するために必要なホストの数を決定します。

   N_HOSTS = 4 ^. R_dt / R_max

   各 DRU に対するホストの数を同じにするために、この値をもっとも近い偶数に丸めます。

3. スペアノードとして、各 DRU に 1 台のホストを追加します。

   ほかの各ホストが N データノードを実行する場合は、このホストで N スペアノードを実行するようにします。これにより、単一のマシン障害で N データノードがダウンするようになります。

   各ホストは少なくとも 1 つのノードを実行する必要があるため、ノードの数がホストの数より小さい場合 (N_NODES < N_HOSTS) は、N_NODES を N_HOSTS に等しくなるように調整します。ノードの数がホストの数より大きい場合 (N_NODES \> N_HOSTS) は、同じホスト上でいくつかのノードを実行できます。

HADB のストレージ容量

HADB では、ネットワークの容量を超えるまで、ノードの追加によってほぼリニアなスケーリングが得られます。各ノードでは、専用のディスク (1 台または複数台) 上にストレージデバイスが設定されている必要があります。すべてのノードで、ストレージデバイスに等しい容量が割り当てられている必要があります。ストレージデバイスは必ずローカルディスクに割り当ててください。

予測されるセッションデータサイズが x M バイトであるとします。HADB はミラーノード上のデータをレプリケートするため、2x M バイトのストレージが必要です。さらに、HADB は、データへの高速アクセスを可能にするためにインデックスを使用しています。2 つのノードにはインデックス用に追加の 2x M バイトが必要であり、必要な合計ストレージ容量は 4x となります。したがって、HADB の予測されるストレージ容量の要件は、予測されるデータ量の 4 倍です。

新しいノードを追加したあとにデータの再断片化が必要になる可能性があるため、HADB からデータが失われることなく将来も拡張できるようにするには、オンラインアップグレードのための追加のストレージ容量を用意してください。この場合は、データデバイス上に同じ量 (4x) の追加の領域が必要です。そのため、予測されるストレージ容量は、予測されるデータ量の 8 倍になります。

さらに、HADB はディスク容量を次のように使用します。

• ログバッファーの一時記憶域のための領域。この領域は、ログバッファーサイズの 4 倍です。ログバッファーは、データに関連する操作を常時監視します。ログバッファーサイズのデフォルト値は 48M バイトです。

• 内部の管理のための領域。この領域は、ストレージデバイスサイズの 1 パーセントです。

次の表は、x M バイトのセッションデータサイズのための HADB ストレージ領域の要件を要約しています。

表 2–3 x M バイトのセッションサイズのための HADB ストレージ領域の要件

条件	必要な HADB ストレージ領域
オンラインが必須でない場合の HADB ノードの追加または削除。	4x M バイト + (4 ×ログバッファーサイズ) + デバイスサイズの 1%
オンラインが必須な場合の HADB ノードの追加または削除。	8x M バイト + (4 ×ログバッファーサイズ) + デバイスサイズの 1%

HADB のデバイス領域が不足すると、HADB は、データを挿入または更新するクライアント要求を受け付けません。ただし、削除操作は受け付けます。HADB のデバイス領域が不足した場合は、エラーコード 4593 または 4592 を返し、対応するエラーメッセージを履歴ファイルに書き込みます。