Storage Foundation for Oracle® RAC 7.3.1 管理者ガイド - Solaris
- 第 I 部 SF Oracle RAC の概念と管理
- Storage Foundation for Oracle RAC の概要
- Storage Foundation for Oracle RAC について
- SF Oracle RAC のしくみ(概要)
- SF Oracle RAC のコンポーネント製品とプロセス
- SF Oracle RAC クラスタの状態の定期的評価
- Virtual Business Service について
- Veritas InfoScale Operations Manager について
- Veritas SORT (Services and Operations Readiness Tools) について
- SF Oracle RAC とそのコンポーネントの管理
- SF Oracle RAC の管理
- SF Oracle RAC の環境変数設定
- 各ノードの SF Oracle RAC の起動または停止
- SF Oracle RAC ノードへの Oracle パッチの適用
- コンテナデータベース (CDB) 間でのプラグ可能データベース (PDB) の移行
- Veritas Volume Manager、Veritas File System、または ODM のパッチの SF Oracle RAC ノードへのインストール
- SF Oracle RAC ノードへのオペレーティングシステムの更新の適用
- SF Oracle RAC クラスタへのストレージの追加
- ストレージ障害からのリカバリ
- Veritas NetBackup を使った Oracle データベースのバックアップとリストア
- SF Oracle RAC クラスタの処理効率の向上
- SmartIO の管理
- オフホスト処理のスナップショットの作成
- SmartTier による効率的なデータベースストレージ管理
- シンプロビジョニングと SmartMove によるデータベースストレージの最適化
- SF Oracle RAC クラスタの定期的診断のスケジュール設定
- VCSMM モジュールを起動および停止するための環境変数の使用
- SF Oracle RAC クラスタのノードの検証
- Solaris 11 システムでのプライマリ BE への復帰
- VCS の管理
- I/O フェンシングの管理
- CP サーバーの管理
- CFS の管理
- CVM の管理
- Flexible Storage Sharing の管理
- SF Oracle RAC のグローバルクラスタの管理
- SF Oracle RAC の管理
- Storage Foundation for Oracle RAC の概要
- 第 II 部 処理速度とトラブルシューティング
- SF Oracle RAC のトラブルシューティング
- SF Oracle RAC のトラブルシューティングについて
- ネットワーク接続に失敗した後のインストーラの再起動
- インストーラでクラスタの UUID を作成できない
- SF Oracle RAC インストール前検査の失敗のトラブルシューティング
- LLT 診断時のトラブルシューティングに対する警告メッセージ
- SF Oracle RAC クラスタの LMX と VCSMM 診断時の警告メッセージのトラブルシューティング
- I/O フェンシングのトラブルシューティング
- 起動時の SCSI 予約エラー
- SCSI TEST UNIT READY コマンドが失敗すると、vxfentsthdw ユーティリティが失敗する
- 他のノードが除外されている間、ノードはクラスタを参加させられない
- システムパニックによって潜在的なデータ破損が防止される
- コーディネータディスクの I/O フェンシングキーのクラスタ ID がローカルクラスタの ID と一致しない
- フェンシングの起動時にすでに発生しているスプリットブレイン状態が報告される
- 登録済みのキーがコーディネータディスクから失われている
- クラスタがオフラインになっているときに不具合のあるディスクの置換
- I/O フェンシング診断時のトラブルシューティングに対する警告メッセージ
- CP サーバーのトラブルシューティング
- SF Oracle RAC クラスタノードでのサーバーベースのフェンシングのトラブルシューティング
- コーディネーションポイントのオンライン移行中の問題
- SF Oracle RAC クラスタの Cluster Volume Manager のトラブルシューティング
- CFS のトラブルシューティング
- VCSIPC のトラブルシューティング
- Oracle のトラブルシューティング
- Oracle ログファイル
- Oracle Note
- Oracle Universal Installer が、Oracle Grid Infrastructure 11.2.0.4 のインストール中に突然終了する
- Oracle Clusterware のインストール中に OUI でクラスタ設定画面にノード名が表示されない
- SF Oracle RAC での Oracle インスタンスの起動時のエラー
- Oracle グループの障害のクリア
- 手動でシャットダウンしていないときでも Oracle ログファイルにシャットダウンの呼び出しがある
- Oracle Clusterware プロセスが起動に失敗する
- 再起動後に Oracle Clusterware が失敗
- SF Oracle RAC クラスタにおける VIP 設定のトラブルシューティング
- SF Oracle RAC クラスタ内の Oracle Clusterware 診断時の警告メッセージのトラブルシューティング
- SF Oracle RAC クラスタの ODM のトラブルシューティング
- SF Oracle RAC クラスタの Flex ASM のトラブルシューティング
- 防止と修復の戦略
- チューニングパラメータ
- SF Oracle RAC のトラブルシューティング
- 第 III 部 参照
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ファイル内にノード名のエントリが含まれていないノードから応答を受信した。