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 プ
ールの割り当てを回収します。ID プールの割り当てを回収する必要があるのは、古いシャーシが実働環境に復帰したと
きにネットワーク ID が競合するのを防ぐためです。
使用事例シナリオ 137