Cluster Server 7.3.1 管理者ガイド - Linux
- 第 I 部 クラスタ化の概念と用語
- Cluster Server の概要
- Cluster Server について
- クラスタ制御のガイドラインについて
- VCS の物理コンポーネントについて
- VCS の論理コンポーネント
- クラスタトポロジーについて
- VCS 設定の概念
- Cluster Server の概要
- 第 II 部 管理 - VCS の利用方法
- VCS ユーザー権限モデルについて
- コマンドラインによるクラスタの管理
- コマンドラインでの VCS の管理について
- VCS ライセンスのインストールについて
- LLT の管理
- VCS の起動
- VCS エンジンと関連プロセスの停止
- VCS へのログイン
- VCS 設定ファイルの管理について
- コマンドラインによる VCS ユーザーの管理について
- VCS のクエリーについて
- サービスグループの管理について
- リソースの管理について
- リソースタイプの管理について
- クラスタの管理について
- VCS でのアプリケーションとリソースの設定
- UNIX の VCS 付属エージェント
- NFS サービスグループの設定
- RemoteGroup エージェントの設定について
- Samba サービスグループの設定について
- HA ファイアドリルを使ったリソースフェールオーバーのテストについて
- InfoScale Enterprise を AWS で使用した HA および DR の設定
- Azure 環境での HA および DR の設定
- VCS Simulator を使った VCS の動作の予測
- 第 III 部 VCS 通信と操作
- クラスタの通信、メンバーシップ、データ保護について
- クラスタ通信について
- クラスタメンバーシップについて
- メンバーシップアービトレーションについて
- データ保護について
- I/O フェンシングを使う VCS 操作の例
- I/O フェンシングを使わない、クラスタメンバーシップとデータ保護について
- I/O フェンシングを使わない VCS 動作の例
- I/O フェンシングの管理
- vxfentsthdw ユーティリティについて
- vxfentsthdw の -c オプションを使ったコーディネータディスクグループのテスト
- vxfenadm ユーティリティについて
- vxfenclearpre ユーティリティについて
- vxfenswap ユーティリティについて
- コーディネーションポイントサーバーの管理について
- ディスクベースとサーバーベースのフェンシング設定間の移行について
- VCS の動作の制御
- リソース障害時の VCS の動作
- サービスグループレベルでの VCS 動作の制御について
- リソースレベルでの VCS 動作の制御について
- ストレージ接続消失時の VCS 動作
- サービスグループワークロード管理
- ワークロード管理を示した設定例
- サービスグループの依存関係のロール
- クラスタの通信、メンバーシップ、データ保護について
- 第 IV 部 管理 - 高度な操作
- VCS イベント通知
- VCS イベントトリガ
- イベントトリガの使用
- イベントトリガの一覧
- Virtual Business Services
- 第 V 部 Veritas High Availability 設定ウィザード
- 第 VI 部 ディザスタリカバリ用のクラスタ設定
- クラスタの相互接続 - グローバルクラスタの作成
- コマンドラインによるグローバルクラスタの管理
- RDC(Replicated Data Cluster)の設定
- キャンパスクラスタの設定
- 第 VII 部 トラブルシューティングおよび処理速度
- 処理速度に関する注意事項
- クラスタコンポーネントの処理速度に対する影響
- クラスタ操作の処理速度に対する影響
- システムパニックのときの VCS の処理速度に関する注意事項
- スケジュールクラスと優先度の設定について
- VCS エージェントの統計機能
- VCS のチューニングパラメータについて
- VCS のトラブルシューティングおよびリカバリ
- VCS メッセージログ
- VCS エンジンのトラブルシューティング
- LLT(Low Latency Transport)のトラブルシューティング
- GAB(Group Membership Services/Atomic Broadcast)のトラブルシューティング
- VCS の起動に関するトラブルシューティング
- systemd ユニットサービスファイルの問題のトラブルシューティング
- サービスグループに関するトラブルシューティング
- リソースに関するトラブルシューティング
- トラブルシューティングのサイト
- I/O フェンシングのトラブルシューティング
- フェンシングの起動時にすでに発生しているスプリットブレイン状態が報告される
- CP サーバーのトラブルシューティング
- VCS クラスタノードでのサーバーベースのフェンシングのトラブルシューティング
- コーディネーションポイントのオンライン移行中の問題
- 通知に関するトラブルシューティング
- グローバルクラスタのトラブルシューティングとリカバリ
- ライセンスに関するトラブルシューティング
- ライセンスのエラーメッセージ
- セキュア設定のトラブルシューティング
- ウィザードベースの設定に関する問題のトラブルシューティング
- [Veritas High Availability]ビューの問題のトラブルシューティング
- 処理速度に関する注意事項
- 第 VIII 部 付録
LLT(Low Latency Transport)について
LLT プロトコルは、高パフォーマンスと低遅延を実現する、IP スタックに代わるものとしてすべてのクラスタ通信で使われます。
LLT には、次に示す 2 つの主要機能があります。
トラフィック分散
LLT は GAB の通信バックボーンを提供します。LLT は、システム間の通信を、設定済みのすべてのネットワークリンク全体に分散します(負荷分散)。この分散により、すべてのクラスタ通信はすべてのネットワークリンクに均等に分散され、パフォーマンスの確保と障害に対する耐性が実現されます。あるリンクに障害が発生した場合、トラフィックは残りのリンクに切り替えられます。最大で 8 個のネットワークリンクがサポートされます。
ハートビート
LLT は、設定済みの各ネットワークリンク上でハートビート信号の送受信を行います。ハートビートのトラフィックは 2 地点間ユニキャストです。LLT はイーサネットブロードキャストを使ってクラスタ内のノードのアドレスを認識します。すべての状態や設定のトラフィックを含む他のすべてのクラスタ通信は 2 地点間ユニキャストです。ハートビートは、Group Membership Services がクラスタメンバーシップを確認するために使います。
ハートビート信号は次のように定義されます。
クラスタ内の各システムの LLT は、設定済みのすべての LLT インターフェースで 0.5 秒おきにハートビートパケットを送出する。
各システムの LLT は、設定済みの各 LLT インターフェースで各ピアからのハートビートの状態を追跡する。
各システムの LLT は、クラスタ内の各システムのハートビート状態を、ローカルの GAB の Group Membership Services 機能に転送する。
GAB は LLT からすべてのクラスタシステムのハートビート状態を受信し、この情報に基づいてメンバーシップを決定する。
図: クラスタ内のハートビート は、クラスタ内のハートビートを示しています。
LLT は、特定のクラスタの相互接続リンクを高優先度または低優先度として指定するように設定できます。高優先度リンクは、GAB とのクラスタ通信およびハートビート信号で使われます。通常の運用では、低優先度リンクはハートビートとリンク状態の保守のみで使われます。このとき、ハートビートの頻度は、ネットワークのオーバーヘッドを軽減するために通常の 50% に縮小されます。
設定済みのすべての高優先度リンクで障害が発生した場合、LLT はすべてのクラスタ通信トラフィックを最初に使用可能な低優先度リンクに切り替えます。高優先度リンクが利用可能になると、通信トラフィックはその高優先度リンクに直ちに復帰します。
必須ではありませんがベストプラクティスとして推奨されることは、少なくとも 1 つの低優先度リンクを設定し、2 つの高優先度リンクを専用のクラスタ相互接続上に設定して、通信パスの冗長性を確保することです。通常、低優先度リンクはパブリックネットワークまたは管理ネットワーク上に設定します。
プライベート NIC のメディア速度を変更する場合は、LLT パフォーマンスを向上させるために低速度の低優先度リンクとして NIC を設定することをお勧めします。この設定により、LLT は、プライベートリンク間でアクティブ/パッシブ負荷分散を実行します。 設定とフェールオーバーの時点で、LLT は優先度の高いリンクをアクティブなリンクとして自動的に選択し、優先度の高いリンクに障害が起きた場合にのみ優先度の低いリンクを使います。
LLT は、重み付けされたラウンドロビンの方法で、設定されたすべてのリンク上でパケットを送信します。 LLT は、リンクバーストパラメータを使います。これは、次のリンクが選択される前に LLT がリンク上で送信するバックツーバックパケットの数を表します。 デフォルトの重み付けされたラウンドロビンベースの負荷分散に加えて、LLT では宛先ベースの負荷分散も提供されます。 LLT では、宛先ベースの負荷分散が実装され、宛先のノード ID とポートに基づいて LLT リンクが選択されます。 宛先ベースの負荷分散では、LLT は、特定の宛先のすべてのパケットを 1 つのリンク上で送信します。 ただし、宛先ベースの負荷分散のアプローチでは、ポートに異種のトラフィックが存在する場合に LLT が利用可能なリンクを完全に活用できないという問題が起きる可能性があります。 分散先ベースの負荷分散は、セットアップに 3 つ以上のクラスタノードと、さらに多くのアクティブな LLT ポートが存在する場合にお勧めします。クラスタでポートに LLT リンクのマッピングを設定するには、宛先ベースの負荷分散を手動で設定する必要があります。
LLT の宛先ベースの負荷分散の設定を参照してください。
LLT は起動時に、同じノード ID とクラスタ ID のペアを持つネットワーク内のノードを検出するために、LLT のノード ID とクラスタ ID の情報を含むブロードキャストパケットを LAN に送信します。ネットワーク内の各ノードは、このブロードキャストメッセージに自身のクラスタ ID、ノード ID、ノード名で応答します。
次の場合は、元のノード上の LLT が起動せず、適切なエラーが表示されます。
同じネットワーク内の他の任意のノード上の LLT が、自身と同じノード ID とクラスタ ID のペアで動作している。
元のノード上の LLT が、
/etc/llthosts
ファイル内にノード名のエントリが含まれていないノードから応答を受信した。