Software RAID の修復

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

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

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

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

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

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

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

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

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

! 重要: リソースが OSF にマーキングされる障害、特に、リソースが (sendevent により) 別のシステムに移動される障害が発生したとき、そのリソースが修復されていることを管理者が確認してから、障害の発生したリソースを in-service にすることが重要です。

その一例は、すべてのパスが失われた場合の MD kit です。ミラーへのすべてのパスが失われた場合、MD kit は、ミラーをスタンバイシステムに移動することで復旧します。キットは、スタンバイシステム上でパスを in-service にする前に、障害が発生したシステム上の階層のすべての部分をクリーンアップ (削除) します。しかし、多くの場合、これらの部分またはリソースを完全にクリーンアップすることは、障害によって不可能です。

管理者が障害を修復するとき、管理者は、その他残りの OS 項目がすべてクリーンアップされていることを確認する必要があります。障害の発生したミラーにマウントされたファイルシステムがある場合、このファイルシステムをマウント解除できない場合がほとんどです。そのため、LifeKeeper がファイルシステムをスタンバイシステムに移動しても、障害が発生したシステムではファイルシステムが (mount コマンドにより) マウントされているものとして表示されます。これは、後で管理者が LifeKeeper ファイルシステム階層を修復後のシステムに戻すときに問題になります。

管理者は、障害の発生したパスを修復するだけではなく、階層のすべての部分がクリーンアップされていること (MD デバイスが未設定で、ファイルシステムがマウントされておらず、アプリケーションが完全に停止しているなど) を確認する必要があります。クリーンな再起動は、階層のすべての側面がクリーンアップされるために必要です。