NDB Cluster の強みの 1 つは、すべてのライブデータストレージがメモリー内で実行されるため、コモディティーハードウェア上で実行でき、大量の RAM 以外はこの点で異常な要件がないことです。 (ディスクデータテーブルを使用してこの要件を削減することもできます。詳細は、セクション23.5.10「NDB Cluster ディスクデータテーブル」を参照してください。) 当然ながら、複数の高速な CPU を使用すればパフォーマンスは向上します。 ほかの NDB Cluster プロセスのメモリー要件は比較的小さくなります。
NDB Cluster のソフトウェア要件も最新です。 ホストオペレーティングシステムで NDB Cluster をサポートするために、異常なモジュール、サービス、アプリケーション、または構成は必要ありません。 サポートされるオペレーティングシステムについては、標準のインストールで十分のはずです。 MySQL のソフトウェア要件は単純です: 必要なのは NDB Cluster の本番リリースだけです。 NDB Cluster を使用できるようにするためにのみ、MySQL を自分でコンパイルする必要はありません。 使用しているプラットフォームに適したバイナリを使用していることを前提としています。このバイナリは、https://dev.mysql.com/downloads/cluster/ の NDB Cluster ソフトウェアのダウンロードページから入手できます。
ノード間の通信の場合、NDB Cluster は任意の標準トポロジで TCP/IP ネットワークをサポートし、各ホストに必要な最小値は、標準の 100 Mbps Ethernet カードと、クラスタ全体にネットワーク接続を提供するためのスイッチ、ハブ、またはルーターです。 NDB Cluster は、次の理由により、クラスタの一部を形成していないマシンと共有されていない独自のサブネット上で実行することを強くお勧めします:
-
セキュリティー. NDB Cluster ノード間の通信は暗号化またはシールドされません。 NDB Cluster 内の転送を保護する唯一の方法は、保護されたネットワーク上で NDB Cluster を実行することです。 NDB Cluster を Web アプリケーションに使用する場合、クラスタはネットワークの非武装地帯 (DMZ) またはほかの場所ではなく、ファイアウォールの内側に確実に配置するようにしてください。
詳細は、セクション23.5.17.1「NDB Cluster のセキュリティーおよびネットワークの問題」を参照してください。
効率. プライベートネットワークまたは保護されたネットワークで NDB Cluster を設定すると、クラスタはクラスタホスト間の帯域幅を排他的に使用できます。 NDB Cluster に別のスイッチを使用すると、NDB Cluster データへの不正アクセスから保護できるだけでなく、NDB Cluster ノードがネットワーク上のほかのコンピュータ間の転送によって発生する干渉から遮断されることも保証されます。 信頼性を高めるため、デュアルスイッチとデュアルカードを使用して、単一障害点になったネットワークを除去できます。多くのデバイスドライバがこのような通信リンクのフェイルオーバーをサポートしています。
ネットワーク通信と待機時間. NDB Cluster でクエリーおよび更新を実行するには、データノードと API ノード (SQL ノードを含む) の間、およびデータノードとほかのデータノードの間の通信が必要です。 これらのプロセス間通信の待機時間は、ユーザークエリーの観測されるパフォーマンスと待機時間に直接影響を与える可能性があります。 さらに、ノードのサイレント障害にもかかわらず一貫性とサービスを維持するために、NDB Cluster は、ノードからの通信の拡張損失をノード障害として処理するハートビートおよびタイムアウトメカニズムを使用します。 これは、冗長性の低下につながる可能性があります。 データの整合性を維持するために、NDB Cluster はノードグループ内の最後のノードで障害が発生したときにシャットダウンすることを思い出してください。 したがって、強制的なシャットダウンのリスクを増やさないようにするため、ノード間通信の中断はできるかぎり回避すべきです。
データノードまたは API ノードに障害が発生すると、障害が発生したノードに関係するコミットされていないすべてのトランザクションが中止されます。 データノードをリカバリするには、データノードのサービスを再開する前に、障害が発生したノードのデータを残存するデータノードのデータと同期し、ディスクベースの redo ログとチェックポイントログを再構築する必要があります。 このリカバリには時間がかかる場合があり、その間、クラスタは冗長性が低下した状態で動作します。
ハートビートは、すべてのノードでハートビート信号が遅延なく生成されるかどうかに依存しています。 ノードに過大な負荷がかかったり、マシンの CPU がほかのプログラムと共有されるために不十分だったり、スワッピングによる遅延が発生したりすると、これは不可能になります。 ハートビート生成の遅延が十分に大きくなると、ほかのノードは応答が遅いノードを障害発生ノードとして扱います。
このように遅いノードを障害発生ノードとして扱うことは、ノードの遅い動作がクラスタの残りの部分にどの程度影響するかによって、望ましい場合とそうでない場合があります。 NDB Cluster 用の HeartbeatIntervalDbDb や HeartbeatIntervalDbApi などのタイムアウト値を設定する場合は、迅速な検出、フェイルオーバー、およびサービスへの復帰を実現しながら、費用のかかる誤検出を回避するよう注意する必要があります。
データノード間の通信待機時間が LAN 環境での予想値 (およそ 100 マイクロ秒) より大きくなると予想される場合は、タイムアウトのパラメータを増やして、許容する待機時間が構成したタイムアウトの範囲に十分に収まるようにする必要があります。 このようにタイムアウトを増やすと、最大の障害検出時間および (その結果としての) サービスリカバリ時間にも類似の効果があります。
LAN 環境は、通常、安定した小さい待機時間で構成できるため、高速フェイルオーバーによる冗長性を提供できます。 個々のリンク障害は、最小および制御された待機時間を TCP レベルで表示して回復できます (NDB Cluster は通常動作します)。 WAN 環境では、待機時間に幅があり、冗長性についてもフェイルオーバーに時間がかかる可能性があります。 個々のリンク障害では、エンドツーエンドの接続をリストアする前に、ルート変更を伝播する必要があります。 これは、TCP レベルでは個々のチャネルの大きな待機時間として現れます。 これらのシナリオで最悪の場合に観測される TCP 待機時間は、IP 層で障害を回避するために行われる再ルーティングの最大時間に関連しています。