Users Guide
1. バックアップ リード シャーシでの「昇格」タスクの実行前:
a. 「昇格」タスクは破壊的な動作であり、アクセスできないリード シャーシを復元する手段がない場合にのみ使用する必要があ
ります。たとえばリード シャーシの部分的な障害で、応答しないのは管理モジュールのみでコンピュートは機能している場
合に昇格タスクを実行すると、リード シャーシ コンピュートでまだ実行されているワークロードが中断されます。機能して
いるコンポーネント、つまり障害が発生したリードのコンピュートやネットワーク スイッチの場所を変える方法の詳細につ
いては、このリストの項目 3. c「実働環境に移行する前に、障害が発生したリードを復元するために必要な手順」を参照して
ください。
b. リード シャーシに障害が発生してアクセスできないことを確認した後、リモートでリード シャーシの電源をシャット ダウン
するか、またはシャーシをスタックから物理的に取り外してから、バックアップの「昇格」タスクを実行する必要がありま
す。昇格タスクの前に、リード シャーシの電源をオフにしなかった場合、またはスタックから取り外さなかった場合は、バ
ックアップを昇格した後で、障害または部分的な障害が発生したリード シャーシが再活性化され、複数のリードが存在する
状態になることがあります。リードが複数存在することにより、グループの管理における混乱や干渉を生じる可能性があり
ます。
2. バックアップ リード シャーシでの「昇格」タスクの実行:
a. リード シャーシが稼働している場合、バックアップ シャーシの Web インターフェイスは「昇格」タスクをブロックします。
バックアップで昇格タスクを開始する前に、リードで障害が発生していてアクセス不可能であることを確認します。パブリ
ック ユーザー管理ネットワークでは到達できなくてもプライベート ネットワーク経由ではリードにアクセスできる場合、バ
ックアップは誤って「昇格」をブロックすることがあります。このような場合、OME-Modular RESTful API を使用して、昇格
タスクを強制的に実行することができます。詳細に関しては、RESTful API のガイドを参照してください。
b. 「昇格」動作が開始されるとジョブが作成されます。グループ内のシャーシ数と復元される設定のサイズによって、このジョ
ブの完了には 10~45 分かかる可能性があります。
c. リード シャーシがアラートを外部の送信先に転送するように設定されている場合(E メール、トラップ、システム ログ)、
リードのダウン中にグループ内のコンポーネントが生成するアラートは、それぞれのハードウェアまたはアラート ログでロー
カルにのみ確認できます。リードの停止中は、設定された外部の送信先にリードを転送することはできません。停止とは、
リードの障害が発生した時点からバックアップの昇格が成功するまでの期間です。
3. 「昇格」タスク後の予期される動作:
a. バックアップ シャーシがリードになり、すべてのメンバー シャーシが、以前のリード シャーシ上にあったときと同じように
アクセスできるようになります。「昇格」タスクの後、古いリード シャーシへの参照が同じグループのメンバーとして存在し
ます。これらの参照が作成されるのは、リード シャーシの MM 障害時にも、古いリードで機能しているコンピュートが中断
されないようにするためです。
「昇格」タスクによってグループ内のすべてのメンバーが再検出されます。アクセスできないメンバー シャーシがあった場
合、そのメンバーもリード ホーム ページのリストに表示され、接続が切断されていることと、使用可能な修復オプションが
示されます。修復オプションを使用して、メンバー シャーシを再度追加するか、グループからシャーシを削除することがで
きます。
b. すべてのファームウェア ベースラインやカタログ、アラート ポリシー、テンプレートまたは ID プール、およびファブリック
の設定は、障害が発生したリード シャーシと同じになるように復元されます。ただし、次のような例外と制限事項がありま
す。
i. バックアップのコピーに必要な 90 分の時間内に障害が発生したリードで設定が変更された場合、これらの設定はバック
アップに完全にコピーされない可能性があり、「昇格」タスクの後に完全には復元されません。
ii. テンプレート/ID プールに関連付けられている進行中のジョブと部分的にコピーされたジョブは、実行を続けます。以下
のいずれかのタスクを実行できます。
i. 実行中のジョブを停止します。
ii. ID プールの割り当てを回収します。
iii. ジョブを再起動して、テンプレートを再導入します。
iii. バックアップが新しいリードとして引き継ぐ前にリードの占有スロットに添付されていたテンプレートは、既存のスレッ
ドが取り外されたり再挿入されたりしても導入されません。導入させるには、管理者がテンプレートをスロットから分
離し、そのテンプレートをスロットに再添付して、既存のスレッドを取り外すか再挿入する必要があります。または、
新しいスレッドを挿入します。
iv. スケジュールに基づいて自動アップデート カタログを使用して作成されたファームウェア カタログは、手動アップデー
トとして復元されます。カタログを編集して自動アップデートの方法を設定し、アップデートの頻度を指定します。
v. 古いリードのデバイスへの参照が古い、または参照がないアラート ポリシーは、新しいリードでは復元されません。
c. 実働環境に移行する前に、障害が発生したリードを復元するために必要な手順:
i. バックアップの「昇格」タスクを実行する前に、新しいリード シャーシの電源をリモートでオフにします。シャーシの電源
をオフにしなかった場合は、部分的な障害が発生したリードがオンラインになり、複数のリードが存在する状態になるこ
とがあります。この状況では、完全な自動検出とリカバリーは行えません。以前のリードがオンラインになったときに自
動リカバリーが可能な場合、以前のリードは強制的にメンバーとしてグループに参加させられます。
ii. 新しいリードで、グループから以前のリード シャーシを削除して、参照を削除します。
iii. 古いリードで、障害が発生したリード シャーシをできるだけ早くグループのスタックから物理的に取り外します。古い
リードのコンピュートに導入された ID プールの割り当てを含むテンプレートがあった場合は、コンピュートから ID プール
112 使用事例シナリオ