Veritas InfoScale™ 7.4 トラブルシューティングガイド - Solaris
- 概要
- 第 I 部 Veritas File System のトラブルシューティング
- 第 II 部 Veritas Volume Manager のトラブルシューティング
- ハードウェア障害からのリカバリ
- ハードウェア障害からのリカバリについて
- 起動不能なボリュームの一覧表示
- ボリュームとプレックスの状態の表示
- プレックスの状態遷移
- 起動不能なミラーボリュームのリカバリ
- RECOVER 状態の無効にされたプレックスが存在する起動不能なボリュームのリカバリ
- 起動不能なボリュームの強制的な再起動
- ディスクでの failing フラグのクリア
- 障害が発生したディスクの再接続
- 失敗したプレックスの接続操作または同期操作のリカバリ
- RAID 5 ボリュームの障害
- ディスクグループの不完全な移動のリカバリ
- クラスタ内の一部のノードが使用できない場合のリカバリ後のボリュームの再起動
- DCO ボリュームの障害からのリカバリ
- インスタントスナップショット障害からのリカバリ
- vxsnap prepare の障害からのリカバリ
- フルサイズインスタントスナップショット作成時の vxsnap make の失敗からのリカバリ
- ブレークオフインスタントスナップショット作成時の vxsnap make の失敗からのリカバリ
- 領域最適化インスタントスナップショット作成時の vxsnap make の失敗からのリカバリ
- vxsnap restore の障害からのリカバリ
- vxsnap refresh の障害からのリカバリ
- コピーオンライトの失敗からのリカバリ
- 再同期中に発生する I/O エラーからのリカバリ
- DCO ボリュームでの I/O エラーからのリカバリ
- インスタントスナップのデータ変更オブジェクト(DCO)の vxsnap アップグレードの障害からのリカバリ
- 失敗した vxresize 操作のリカバリ
- ブートディスク障害からのリカバリ
- コマンド、タスク、トランザクションの管理
- ディスクグループ設定のバックアップと復元
- ディスクグループのインポートを使った問題のトラブルシューティング
- CDS エラーからの回復
- ログおよびエラーメッセージ
- Veritas Volume Replicator のトラブルシューティング
- RLINK 接続問題のリカバリ
- 設定エラーのリカバリ
- プライマリまたはセカンダリでのリカバリ
- クラウド配備の問題のトラブルシューティング
- ハードウェア障害からのリカバリ
- 第 III 部 Dynamic Multi-Pathing のトラブルシューティング
- 第 IV 部 Storage Foundation Cluster File System High Availability のトラブルシューティング
- 第 V 部 Cluster Server のトラブルシューティング
- VCS のトラブルシューティングおよびリカバリ
- VCS メッセージログ
- VCS エンジンのトラブルシューティング
- LLT(Low Latency Transport)のトラブルシューティング
- GAB(Group Membership Services/Atomic Broadcast)のトラブルシューティング
- VCS の起動に関するトラブルシューティング
- IMF(Intelligent Monitoring Framework)のトラブルシューティング
- サービスグループに関するトラブルシューティング
- VCS はサービスグループを自動的に起動しない
- システムが RUNNING 状態にならない
- あるシステムでサービスグループがオンラインにならない
- サービスグループが自動起動しない
- サービスグループがフリーズしている
- フェールオーバーサービスグループが、別のシステムでオンラインになっている
- 重大なリソース障害が発生した
- サービスグループが自動無効化の状態になっている
- リソースがオンラインまたはオフラインになるまでサービスグループが待機している
- 依存関係が満たされるまでサービスグループが待機している
- サービスグループのプローブが完了していない
- サービスグループが予想されたシステムにフェールオーバーしない
- FailOverPolicy が BiggestAvailable に設定されているのに、サービスグループが BiggestAvailable システムにフェールオーバーしない
- VCS で作成されるバックアップからの測定データベースの復元
- 測定データベースの初期化の失敗
- リソースに関するトラブルシューティング
- I/O フェンシングのトラブルシューティング
- 他のノードが除外されている間、ノードはクラスタを参加させられない
- SCSI TEST UNIT READY コマンドが失敗すると、vxfentsthdw ユーティリティが失敗する
- SCSI-3 ディスクから手動で既存のキーを削除する
- システムパニックによって潜在的なデータ破損が防止される
- コーディネータディスクの I/O フェンシングキーのクラスタ ID がローカルクラスタの ID と一致しない
- フェンシングの起動時にすでに発生しているスプリットブレイン状態が報告される
- 登録済みのキーがコーディネータディスクから失われている
- クラスタがオフラインになっているときに不具合のあるディスクの置換
- rcp または scp コマンドが機能していないと vxfenswap ユーティリティが終了する
- CP サーバーのトラブルシューティング
- Veritas InfoScale products クラスタノードでのサーバーベースのフェンシングのトラブルシューティング
- コーディネーションポイントのオンライン移行中の問題
- 通知に関するトラブルシューティング
- グローバルクラスタのトラブルシューティングとリカバリ
- Steward プロセスのトラブルシューティング
- ライセンスに関するトラブルシューティング
- ライセンスキーの検証
- ライセンスのエラーメッセージ
- [Licensing] Insufficient memory to perform operation
- [Licensing] No valid VCS license keys were found
- [Licensing] Unable to find a valid base VCS license key
- [Licensing] License key can not be used on this OS platform
- [Licensing] VCS evaluation period has expired
- [Licensing] License key can not be used on this system
- [Licensing] Unable to initialize the licensing framework
- [Licensing] QuickStart is not supported in this release
- [Licensing] Your evaluation period for the feature has expired.This feature will not be enabled the next time VCS starts
- CPU、メモリ、スワップの計測または予測された値の確認
- VCS のトラブルシューティングおよびリカバリ
- 第 VI 部 SFDB のトラブルシューティング
RLINK 接続問題のリカバリ
この項では、RLINK に関して発生する可能性があるエラーについて説明します。RLINK 接続問題のトラブルシューティングを行うには、RLINK 接続プロセスを理解しておくことが重要です。
プライマリ側とセカンダリ側の RLINK の接続は、2 段階の操作で行われます。最初の段階は RLINK の設定で、vradmin startrep コマンドで実行します。次の段階は、RLINK の接続で、プライマリホストとセカンダリホスト上のカーネルで実行します。
vradmin startrep コマンドを実行するとき、VVR は、操作が成功するかどうかを確認するためのさまざまなチェックを実行します。操作が成功した場合は、このコマンドによって RLINK の状態が DETACHED/STALE から ENABLED/ACTIVE に遷移します。その後、コマンドは操作が成功したことを示すメッセージを返します。
コマンドが成功した場合、プライマリ上のカーネルには RLINK が有効になったことが通知され、接続を要求しているセカンダリへメッセージの送信を開始します。通常は、セカンダリはこのメッセージを受信して、プライマリと接続されます。接続されると、RLINK の状態は ENABLED/ACTIVE から CONNECT/ACTIVE に遷移します。
RLINK が短時間のうちに CONNECT/ACTIVE 状態に遷移しない場合は、何か問題が存在していて、接続を妨げています。この章では、可能性として考えられるさまざまな原因について説明します。問題を示すエラーメッセージが、コンソールに表示されることもあります。
コンソールに次のエラーメッセージが表示されている場合
VxVM VVR vxrlink INFO V-5-1-5298 Unable to establish connection with remote host <remote_host>, retrying
vradmind デーモンがプライマリホストとセカンダリホスト上で実行されていることを確認してください。実行されていない場合は、次のコマンドを実行して vradmind デーモンを起動してください。
# /usr/sbin/vxstart_vvr
共有ディスクグループ内の RLINK について、RLINK の仮想 IP アドレスがログ所有者上で有効になっていることを確認してください。
エラーメッセージで原因が明らかにされていない場合は、次のコマンドをプライマリホストとセカンダリホストの両方で実行します。
# vxprint -g diskgroup -l rlink_name
表示された出力で、次の点を確認します。
各ホストの remote_host が他のホストの local_host と同じであること。
各ホストの remote_dg が他のホスト上の RVG のディスクグループと同じであること。
各ホストの remote_dg_dgid が vxprint -l diskgroup コマンドで出力される他のホスト上の RVG の dgid(ディスクグループ ID)と同じであること。
各ホストの remote_rlink が他のホスト上の対応する RLINK の名前と同じであること。
各ホストの remote_rlink_rid が他のホスト上の対応する RLINK の rid と同じであること。
ネットワークが正常に機能していることを確認します。 ネットワークに問題が発生すると、RLINK の接続を妨げたり、処理効率を低下させるなど、VVR に影響を与える可能性があります。可能性として考えられる問題は、過大なネットワーク遅延、帯域幅の不足、コリジョンの多発および過度のパケット破棄です。
専用ディスクグループ内の RLINK に対して、各ホストで次のコマンドを実行します。
共有ディスクグループ内の RLINK に対して、vxprint -Vl | grep logowner を使用して logowner ノードを探し、プライマリおよびセカンダリの logowner に対して次のコマンドを発行します。
# ping -s remote_host
メモ:
このコマンドは、ICMP ping が VVR プライマリと VVR セカンダリの間で許可されている場合にのみ有効です。
10 回繰り返した後、Ctrl+C を押します。パケットロスは全くない、またはごくわずかであるべきです。ネットワークが大きいパケットを確実に転送できるようにするには、専用ディスクグループ内の RLINK に対して、各ホストで次のコマンドを実行します。
共有ディスクグループ内の RLINK に対して、プライマリとセカンダリのログ所有者で次のコマンドを実行します。
# ping -I 2 remote_host 8192
パケット損失については、先に実行した ping コマンドと同様である必要があります。
各ホスト上で vxiod コマンドを実行して、アクティブな I/O デーモンが存在することを確認します。戻り値が、「0 個のボリューム入出力デーモンが実施中です。(0 volume I/O daemons running)」であった場合、次のコマンドを実行して I/O デーモンをアクティブにします。
# vxiod set 10
VVR は、特定のポートを使って他のホストとの通信を確立します。
ポート番号を表示するには、次のコマンドを実行します。
# vxprint -g diskgroup -l rlink_name
次のコマンドを実行して、出力されたハートビートのポート番号が vxprint コマンドによって表示されたポートと一致することを確認します。
# vrport
次のコマンドを実行して、ハートビートポートの状態が Idle であることを確認します。
# netstat -an -P udp
次のような結果が出力されます。
UDP: IPv4 Local Address Remote Address State -------------------- -------------------- ------- *.port-number Idleプライマリサイトとセカンダリサイトの VVR ポートを調べます。
vrport ユーティリティを実行し、両方のサイトでポートが同じであることを検証します。
必要な VVR ポートが開いているかどうかを調べます。UDP 4145、TCP 4145、TCP 8199、Anonymous ポートを調べます。次のコマンドを入力します。
# netstat -an -P udp | grep 4145 *.4145 Idle *.4145 Idle # netstat -an -P tcp | grep 4145 *.4145 *.* 0 0 49152 0 LISTEN *.4145 *.* 0 0 49152 0 LISTEN # netstat -an -P tcp | grep 8199 *.8199 *.* 0 0 49152 0 LISTEN 10.180.162.41.32990 10.180.162.42.8199 49640 0 49640 0 ESTABLISHED *.8199 *.* 0 0 49152 0 LISTEN
telnet によるテストを実行して、開いているポートを調べます。たとえば、ポート 4145 が開いているかどうかを判断するには、次のコマンドを入力します。
# telnet <remote> 4145
vradmind デーモンがプライマリサイトとセカンダリサイトとの間で接続を確立できるかどうかを調べるには、netstat コマンドを使います。
# netstat -an -P tcp | grep 8199 | grep ESTABLISHED 10.180.162.41.32990 10.180.162.42.8199 49640 0 49640 0 ESTABLISHED
確立された接続がない場合は、
/etc/hostsファイルにプライマリサイトとセカンダリサイトのエントリがあるかどうかを調べます。関係するすべてのシステム名と IP アドレスを各システムの/etc/hostsファイルに追加するか、使っているネームサービスのネームサーバーデータベースに情報を追加します。Solaris 11 で、手動で
/etc/hostsファイルを編集してループバックアドレスの行からホスト名を削除する必要があります。次に例を示します。
::1 seattle localhost
127.0.0.1 seattle loghost localhost
次のように変更する必要があります。
::1 localhost
127.0.0.1 loghost localhost
129.148.174.232 seattle