ミラーのいずれかのレッグに障害が発生した場合、そのレッグを修復できます。

問題が発生した場合、そのリソースは OSF とマーキングされます。(注記: 有効な場合、E メール通知 が行われます。)

図 16: 障害が発生したコンポーネントを含む LifeKeeper 階層

 

mdComponent は、ディスクが正常なときに OSF とマーキングされることがありますが、そのコンポーネントはミラーでは 「faulty」 とマーキングされます。これは、デバイスがオンラインになった際に mdadm によって検知された何らかの問題 (詳細についてはエラーログを参照) や、mdadm ユーティリティを使用してミラーを「中断」した手動動作などによって発生することがあります。

mdComponent と配下のディスク / デバイスは、in-service 動作中にエラーが発生した場合、 OSF とマーキングすることができます。たとえば、仮想デバイスを起動した際にディスクが「壊れていた」場合や、物理的に接続されていなかった場合です。

以下のスクリーンショットは、あるアレイ障害について、アレイに障害が発生する前の状態と、障害の 1 次処置によって状態が「failed」になり、それを in service に戻すまでを示しています。(これらのスクリーンショットには、「ターミナルリソース」を使用して各階層の最下部を単一のリソースに接続する例が含まれています。)

図 17 - アレイ障害前

図 18 - アレイ障害後

アレイ障害の 1 次処置後、すべてのリソースは OSF とマーキングされます。この障害の間、IO は正常なコンポーネントまたはミラーのレッグを引き続き使用します。

図 19 - 障害の発生したディスクアレイ

図 20 - 障害の発生したコンポーネントをスタンバイに更新

エラー処置中に、障害の発生したコンポーネントがミラー設定から正しく削除されると、リソースは OSU に移行します。これは、障害発生後に MD quickCheck が実行されるときに行われます。障害が発生したコンポーネントを処置中にミラー設定から削除できない場合、リソースは OSF 状態のままになります。

図 21 - リストアされたストレージリソース

ストレージの障害を修復するためなど、障害が発生した状態でサーバを再起動する必要がある場合、障害が発生したコンポーネント配下のストレージリソースは (正常に修復された場合) リストアされますが、障害が発生したコンポーネントはミラーに自動的には再追加されません。障害の発生したコンポーネントを (GUI または perform_action(1M) を使用して) in-service にすることで、そのコンポーネントを再追加できます。これにより、IO がレッグに再接続されます。その後、内部ビットマップが設定されている場合はミラーにより部分的な再同期を実行され、設定されていない場合はミラーにより完全な再同期が実行されます。

図 22: Software RAID の In-Service 状態

 

障害の発生したレッグが仮想デバイス内で手作業で修復された場合、LifeKeeper はその変更内容を quickCheck の実行時に自動的に検出します。リソースの状態は、その新しい状態を反映して変化します。しかし、コンポーネント配下のリソース (すなわちデバイスやディスク) に障害が発生した場合、それらの状態は更新されません。 これらの状態を更新するには、GUI または perform_action(1M) を使用してリソースを in-service にする必要があります。

図 23: Software RAID In-Service に成功した状態

フィードバック

フィードバックありがとうございました

このトピックへフィードバック

送信