サービスのステータス
左側のナビゲーションバーの [トラブルシュート(Troubleshoot)] メニューの下にある [サービスステータス(Service Status)] ページには、Cisco Secure Workload クラスタで使用されている全サービスの正常性と、サービスの依存関係が表示されます。
この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
表示されるメンテナンスオプションは、ユーザーロールによって異なります。
左側のナビゲーションバーの [トラブルシュート(Troubleshoot)] メニューの下にある [サービスステータス(Service Status)] ページには、Cisco Secure Workload クラスタで使用されている全サービスの正常性と、サービスの依存関係が表示されます。
アドミラルは、統合されたアラートシステムです。サービスステータスによって報告されたサービスの正常性に基づいてアラートを処理します。そのため、統一された方法でユーザーはサービス/クラスタの健全性を判断することができます。サービスステータスは、サービスの現在(特定の時点)の状態を示します。サービスステータスが赤色と報告された場合、サービスは停止していると見なされ、それ以外の場合は稼働していると見なされます。稼働時間は、サービスが稼働していると報告される時間です。アドミラルは、一定期間にわたるサービスステータスによって報告されたサービスの正常性を評価し、サービスの稼働時間の割合が特定のしきい値を下回った場合にアラートを生成します。一定期間にわたってこの評価を行うことで、誤検知を減らし、本当のサービス停止時にのみ警告を発することが保証されます。
サービスによってアラートのニーズは異なるため、この割合と時間間隔は、サービスごとに異なる方法で固定されています。
顧客は、アドミラル通知を使用して、これらのイベントの通知を受けることができます。これらのイベントは、プラットフォームタイプの
ページにも表示されます。(注) |
アドミラルアラートは、選択したサービスのサブセットのみに関連付けられます。サービスが上記のサブセットに含まれていない場合、サービスがダウンしてもアドミラルアラートは発生しません。このサービスのサブセットで設定されているアドミラルアラートとそのアラートしきい値の割合と時間間隔は固定であり、ユーザーは設定できません。 |
次のセクションでは、アドミラルアラートと通知について詳しく説明します。
アドミラルは、サービスステータスでサービスの稼働時間をチェックします。この稼働時間があらかじめ設定されたアラート用のしきい値を下回ると、アラートが発生します。
たとえば、RPminstall は、展開、アップグレード、パッチなどの際に rpm をインストールするために使用されるサービスです。1 時間以上の稼働時間が 80% 未満の場合、アドミラルアラートを生成するように設定されています。Rpminstall サービスが上で指定されたしきい値よりも長い期間ダウンした場合、RPminstall のアドミラルアラートが生成され、ステータスが ACTIVE になります。
サービスが回復すると、稼働時間の割合が増加し始めます。稼働時間がしきい値を超えると、アラートは自動的にクローズし、ステータスは CLOSED に移行します。上記の Rpminstall の例では、稼働時間が 1 時間で 80% を超えると、Rpminstall アドミラルアラートは自動的にクローズします。
(注) |
アラートのクローズにより、サービスは常に正常に戻るのが遅れます。これは、アドミラルが一定期間サービス正常性を監視するためです。上記の例では、RPminstall アラートのしきい値が 1 時間の稼働時間の 80% に設定されているため、アラートがクローズするまでに少なくとも 48 分間(1 時間の 80%)稼働している必要があります。 |
アラートをクローズするために必要なユーザーのアクションはありません。アクティブなアドミラルアラートは、注意が必要な現在の根本的な問題を示すようになります。
(注) |
アラートがクローズしても、専用の通知は生成されません。 |
アラートが CLOSED に移動すると、ACTIVE アラートの下に表示されなくなります。クローズされたアラートは、次に示すように、フィルタの Status=CLOSED を使用して、UI に引き続き表示されます。
アドミラルアラートには次の 2 種類があります。
個別のアドミラルアラート
サマリーのアドミラルアラート
上記で説明したアラート、個々のサービスに対して発生したアラートは、このカテゴリに分類されます。これらのアラートのアラートテキストには常に <Service Name> Admiral Alert が含まれています。これにより、個々のアラートをサービスまたは「Admiral Alert」サフィックスで簡単にフィルタリングできます。
このサービスのその他の属性については、_admiral_indiv_details-label で説明しています。
アドミラルは、UTC の午前 0 時に毎日サマリーアラートを生成します。サマリーアラートには、現在アクティブなアラートと、過去 1 日以内にクローズされたすべてのアラートのリストが含まれているため、ユーザーは、アドミラルによって報告された全体的なクラスタの正常性を 1 か所で確認できます。これは、専用の通知を生成しないクローズされたアラートを表示する場合にも役立ちます。クラスタが正常で、過去 1 日以内にクローズされたアラートがない場合、その日のサマリー通知は生成されません。これは、不要な通知とノイズを減らすために行われます。
この場合のアラートテキストは常に「アドミラルサマリー」なので、以下に示すように、サマリーアラートを簡単にフィルタ処理できます。
このサービスのその他の属性については、_admiral_summary_dets-label を参照してください。
個別のアドミラルアラートのアラートをクリックすると、アラートが展開され、アラートのデバッグと分析に役立つフィールドが表示されます。
以下の表で各フィールドについて説明します。
フィールド |
バージョン情報 |
---|---|
アラートID(Alert ID) |
各アラートには、アラート ID と呼ばれる一意の ID があります。この ID は、特定のサービスダウン発生を一意に把握するのに役立ちます。前述のように、アラートによってレポートされているサービスの基本的な稼働時間が正常になると、アラートは自動的に閉じます。その後、同じサービスが再びダウンすると、別のアラート ID を持つ新しいアラートが生成されます。このように、アラート ID は、発生したアラートの各インシデントを一意に把握するのに役立ちます。 |
Desc |
説明フィールドには、アラートの原因となっているサービスの問題についての追加情報が含まれています。 |
サービス |
このフィールドには、ユーザーがサービスの現在のステータスを確認できるサービスステータスページへのリンクが含まれています。ユーザーは、サービスステータスページでサービスがダウンとマークされている理由の詳細を把握することもできます。 |
トリガーの詳細情報 |
このフィールドには、サービスのトリガーしきい値に関する詳細情報が含まれます。ユーザーは、これらのしきい値を確認することで、基本的なサービスが復旧した後にアラートが閉じるタイミングを把握できます。例:Rpminstall のしきい値は、1 時間で 80% の稼働時間と記されています。したがって、アラートが自動的に閉じる前に、Rpminstall サービスは少なくとも 48 分間(1 時間の 80%)稼働している必要があります。ここには、アラートが発生した時点でサービスに表示された稼働時間の値も示されています。 |
JSON Kafka 出力の例は次のとおりです。
{
"severity": "IMMEDIATE_ACTION",
"tenant_id": 0,
"alert_time": 1595630519423,
"alert_text": "Rpminstall Admiral Alert",
"key_id": "ADMIRAL_ALERT_5",
"alert_id": "/Alerts/5efcfdf5497d4f474f1707c2/DataSource{location_type='TETRATION', location_name='platform', location_grain='MIN', root_scope_id='5efcfdf5497d4f474f1707c2'}/66eb975f5f987fe9eaefa81cee757c8b6dac5facc26554182d8112a98b35c4ab",
"root_scope_id": "5efcfdf5497d4f474f1707c2",
"type": "PLATFORM",
"event_time": 1595630511858,
"alert_details": "{\"Alert ID\":5,\"Service\":\"Rpminstall\",\"Desc\":\"Rpminstall uploads rpms into the cluster. Please look at /local/logs/tetration/rpminstall/rpm_upgrade.log on orchestrators for more details\",\"Trigger Details\":\"Alert triggered because Rpminstall uptime was less than 80.0 % in 1h. It will auto close when uptime percentage is back above this threshold. Uptime at trigger was 65.0%. \"}"
}
個別のアラートはすべて、上記の形式に従います。アドミラルモニタリングの対象となる(サービスステータスからの)サービスのリストを表に示します。
サービス |
トリガー条件 |
重大度 |
---|---|---|
KubernetesApiServer |
過去 15 分間でサービスの稼働時間が 90% を下回っている。 |
即時対応(IMMEDIATE ACTION) |
Adm |
過去 1 時間でサービスの稼働時間が 90% を下回っている。 |
即時対応(IMMEDIATE ACTION) |
DataBackup |
過去 6 時間でサービスの稼働時間が 90% を下回っている。 |
即時対応(IMMEDIATE ACTION) |
DiskUsageCritical |
過去 1 時間でサービスの稼働時間が 80% を下回っている。 |
即時対応(IMMEDIATE ACTION) |
RebootRequired |
過去 1 時間でサービスの稼働時間が 90% を下回っている。 |
即時対応(IMMEDIATE ACTION) |
Rpminstall |
過去 1 時間でサービスの稼働時間が 80% を下回っている。 |
即時対応(IMMEDIATE ACTION) |
SecondaryNN_checkpoint_status |
過去 1 時間でサービスの稼働時間が 90% を下回っている。 |
即時対応(IMMEDIATE ACTION) |
8RU/39 RU 物理クラスタの場合、次のサービスが追加でモニタリングされます。
サービス |
トリガー条件 |
重大度 |
---|---|---|
DIMMFailure |
過去 1 時間でサービスの稼働時間が 80% を下回っている。 |
即時対応(IMMEDIATE ACTION) |
DiskFailure |
過去 1 時間でサービスの稼働時間が 80% を下回っている。 |
即時対応(IMMEDIATE ACTION) |
FanSpeed |
過去 1 時間でサービスの稼働時間が 80% を下回っている。 |
即時対応(IMMEDIATE ACTION) |
ClusterSwitches |
過去 1 時間でサービスの稼働時間が 80% を下回っている。 |
即時対応(IMMEDIATE ACTION) |
(注) |
Admiral は、サービスステータスによって生成された処理メトリックに依存してアラートを生成します。メトリックの取得が長期間不可能な場合(たとえば、サービスステータスが停止している場合)、アラート(TSDBOracleConnectivity)が発生し、クラスタでサービスベースのアラート処理がオフになっていることを通知します。 |
サマリーアラートは本質的に情報提供であり、優先順位は常に LOW に設定されます。アドミラルサマリーアラートをクリックすると、アドミラルアラートに関する概要情報を含む複数のフィールドが展開されて表示されます。
フィールド |
バージョン情報 |
---|---|
Desc |
説明フィールドには、日次概要の日付が含まれています。 |
オープン(Open) |
オープンアラートは、概要が生成された時点でアクティブだったアラートを示しています 。 |
[最近閉じたアラート(Recently Closed)] |
このフィールドには、過去 24 時間以内、つまり概要が生成された日に閉じたアラートが表示されます。各アラートの ID も含まれます。アラートは自動的に閉じるため、特定のサービスがダウンしてアラートが作成された後、正常になり、アラートが自動的に閉じる場合があります。アラートが閉じるケースが 1 日に複数回発生した場合、各インシデントとその固有のアラート ID が一覧表示されます。ただし、アラートが閉じる前に各サービスがしきい値時間の間稼働状態になっている必要があることを考えると、こうした状況が頻繁に発生することは想定されていません。ユーザーは、Status = CLOSED でフィルタリングして、各インシデントに関する詳細情報を取得できます。 |
サービス |
サービスを処理し、日次概要を生成する Admiral のサービスステータスリンク。 |
[サマリーID(Summary ID)] |
サマリーアラートの ID。 |
JSON Kafka 出力の例は次のとおりです。
{
"severity": "LOW",
"tenant_id": 0,
"alert_time": 1595721914808,
"alert_text": "Admiral Summary",
"key_id": "ADMIRAL_SUMMARY_Jul-26-20-00-04",
"alert_id": "/Alerts/5efcfdf5497d4f474f1707c2/DataSource{location_type='TETRATION', location_name='platform', location_grain='MIN', root_scope_id='5efcfdf5497d4f474f1707c2'}/e95da4521012a4789048f72a791fb58ab233bbff63e6cbc421525d4272d469aa",
"root_scope_id": "5efcfdf5497d4f474f1707c2",
"type": "PLATFORM",
"event_time": 1595721856303,
"alert_details": "{\"Desc\":\"Summary of alerts for Jul-26\",\"Recently Closed\":\"None\",\"Open\":\" Service Rpminstall with Alert ID 5.\",\"Service\":\"Admiral\",\"Summary ID\":\"ADMIRAL_SUMMARY_Jul-26-20-00-04\"}"
}
1 日に複数のアラートを発生させるサービスを含むサマリーアラートの例を以下に示します。
アドミラルアラートはアラートごとに 1 回だけ個別の通知を生成するため、特定のアラートを含めたり除外したり、スヌーズしたりする必要はありません。上述のとおり、しきい値である稼働時間の間サービスが正常に動作すると、アラートが自動的に閉じます。アラートを強制的に閉じるための強制終了オプションがあります。個々のアラートは自動的に閉じるため、通常、このオプションの使用は、UI からサマリーアラートを削除する場合に限る必要があります。
警告 |
個々のアラートを強制終了しないでください。基礎となるサービスがまだダウンしているか、稼働時間が予想されるしきい値を下回っているときに強制終了すると、次のアドミラル処理の反復で同じサービスに対して別のアラートが発生します。 |
アドミラルアラートのタイプは PLATFORM です。したがって、これらのアラートは、設定ページでの設定によるプラットフォームアラートへの適切な接続によって、さまざまなパブリッシャに送信されるように設定できます。利便性を考慮し、プラットフォームアラートと内部 Kafka 間の接続はデフォルトでオンになっています。これにより、アドミラルアラートが [現在のアラート(Current Alerts)] ページ(
に移動)に表示されます。手動で設定する必要はありません。アドミラルアラートは、
で設定された電子メールアドレスにも送信されます。そのため、ユーザーは TAN エッジアプライアンスをセットアップしていなくても、アドミラル通知を受け取ることができます。この動作は、以前のリリースの Bosun の動作に似ています。
これらの電子メール通知は、[現在のアラート(Current Alerts)] ページと同じトリガーに基づいて生成されます。したがって、電子メール通知はアラートの作成時に送信され、UTC の午前 0 時に日次概要メールが送信されます。日次概要メールには、すべてのアクティブなアラートと過去 24 時間以内に閉じられたアラートが一覧表示されます。
アクティブなアラートがなく、過去 24 時間以内に閉じられたアラートもない場合、電子メールノイズを減らすために概要メールはスキップされます。
左側のナビゲーションバーの [トラブルシュート(Troubleshoot)] メニューにある [クラスタのステータス(Cluster Status)] ページには、サイト管理者ユーザーがアクセスできますが、アクションを実行できるのはカスタマーサポートユーザーのみです。Cisco Secure Workload ラック内にあるすべての物理サーバーのステータスが表示されます。テーブルの各行は、ハードウェアとファームウェアの構成、CIMC IP アドレス(割り当てられている場合)などの詳細が設定された物理ノードを表します。行をクリックすると、ノードの詳細ビューを表示できます。このページでは、ノードの CIMC パスワードを変更し、ノードへの外部アクセスを有効/無効にすることもできます。 [クラスタのステータス(Cluster Status)] ページにはオーケストレータの状態も表示され、カスタマーサポートにコンテキストを提供できます。
すべてのノードに影響するアクション
CIMC パスワードの変更と外部 CIMC アクセスの有効化/無効化は、[CIMC/TORゲストパスワード(CIMC/TOR guest password)] ボタンおよび [外部アクセスの変更(Change external access)] ボタンを使用して行うことができます。これらのアクションはクラスタ内のすべてのノードに影響します。
外部 CIMC アクセスの詳細
[外部アクセスの変更(Change external access)] ボタンをクリックするとポップアップが開き、外部 CIMC アクセスのステータスが表示され、CIMC への外部アクセスを有効化、更新、または無効化できます。
[有効化(Enable)] ボタンをクリックすると、クラスタがバックグラウンドで構成され、外部 CIMC アクセスが有効になります。これらのタスクが完了し、外部 CIMC アクセスが完全に有効になるまでに最大 60 秒かかる場合があります。外部 CIMC アクセスが有効になっており、アクセスの自動期限切が設定されている場合、ポップアップが表示され、[有効(Enable)] ボタンが [更新(Renew)] に変わり、外部 CIMC アクセスを更新できることが反映されます。外部 CIMC アクセスを更新すると、有効期限が現在の時刻から 2 時間先になります。
外部 CIMC アクセスが有効になっている場合、ノードの詳細(ノードの行をクリックして表示可能)の CIMC IP アドレスは、CIMC WebUI に直接アクセスできるクリック可能なリンクになります。このリンクを表示するには、[クラスタのステータス(Cluster Status)] ページのリロードが必要になる場合あります。
CIMC WebUI には通常、自己署名証明書があり、CIMC WebUI にアクセスすると、証明書が無効であることを示すエラーがブラウザに表示される可能性があります。Google Chrome を使用している場合、証明書チェックをバイパスして CIMC WebUI にアクセスするためには、無効な証明書エラーが Google Chrome に表示されたときに、引用符なしで「thisisunsafe」と入力する必要があります。
CIMC WebUI では、CIMC バージョンが 4.1(1g) 以降の場合にのみ、KVM アクセスが機能します。外部 CIMC アクセスが有効になると、アクセスを更新または無効にしない限り、2 時間後に自動的に無効になります。
外部 CIMC アクセスを無効にすると、クラスタがバックグラウンドで構成され、外部 CIMC アクセスが無効になります。これらのタスクが完了し、外部 CIMC アクセスが完全に無効になるまでに最大 60 秒かかる場合があります。
フィールド |
説明 |
---|---|
[Status(ステータス)] |
[ステータス(Status)] フィールドは、ノードの電源ステータスを示します。値は以下のとおりです。 - [アクティブ(Active)]:ノードの電源がオンになっています。 [非アクティブ(Inactive)]:ノードの電源が入っていないか、接続されていません。 |
[状態(State)] |
[状態(State)] フィールドは、ノードのクラスタメンバーシップの状態を示します。値は以下のとおりです。 [新規(New)]:ノードはまだクラスタの一部ではありません。 [初期化済み(Initialized)]:ノードはクラスタの一部です。ただし、Cisco Secure Workload ソフトウェアはまだ完全にはノードにインストールされていません。 [稼働済み(Commissioned)]:ノードは Cisco Secure Workload ソフトウェアを使用して稼働しています。 [SW バージョン(SW Version)] フィールドも表示され、個々のノードのバージョンがクラスタ全体と同じでない場合は赤に変わります。 [稼働停止(Decommissioned)]:ノードはクラスタから削除されています(RMA の目的で)。ノードを新しいハードウェアと交換する必要があります。ノードは、デコミッションアクションにより稼働を停止できます。下記のアクションを参照してください。 |
[スイッチポート(Switch Port)] |
物理ノードが接続されている 2 つのスイッチのスイッチポートを指します。 |
[稼働時間(Uptime)] |
ノードが再起動またはシャットダウンせずに稼働していた時間を示します。 |
[CIMCスナップショット(CIMC Snapshots)] |
CIMC テクニカルサポートデータの収集を開始して、ダウンロードするために使用できます。 |
アクション |
説明 |
---|---|
[コミッション(Commission)] |
このアクションを選択すると、新しいノードがクラスタに組み込まれます。このアクションについては、状態が [新規(New)] のノードのみを選択できます。 |
[デコミッション(Decommission)] |
現在クラスタに属しているノードを削除するには、このアクションを選択します。このアクションについては、状態が [稼働済み(Commissioned)] または [初期化済み(Initialized)] のノードのみを選択できます。 |
[再イメージ化(Reimage)] |
このアクションを選択すると、ボックス内に Secure Workload ソフトウェアが再インストールされます。これにより、ボックス内のファイルがすべて消去されます。ベアメタル オペレーティング システムを旧バージョンから新バージョンにアップグレードする際に特に便利です。この手順は、ベアメタルが稼働停止になった後に必要になります。 |
[ファームウェアのアップグレード(Firmware upgrade)] |
ファームウェア情報は、CIMC IP に到達可能なノードで利用できます。このアクションは、旧バージョンのノードのファームウェアをアップグレードするのに役立ちます。 |
[電源オフ(Power off)] |
ノードの電源を切るには、このアクションを選択します。ステータスが [非アクティブ(Inactive)] でシャットダウン中のノードの電源を切ることはできないので注意してください。 |
Secure Workload 物理アプライアンスには、ユニファイド コンピューティング システム(UCS)Cisco Integrated Management Controller(CIMC)ホスト アップグレード ユーティリティ(HUU)の ISO イメージがバンドルされています。[クラスタのステータス(Cluster Status)] ページでファームウェア アップグレード オプションを使用して、物理ベアメタルを Secure Workload RPM ファイルにバンドルされている HUU ISO に含まれる UCS ファームウェアのバージョンに更新できます。
ベアメタルホストは、ステータスが [アクティブ(Active)] または [非アクティブ(Inactive)] で、ベアメタルのステータスが [初期化(Initialized)] または [SKU不一致(SKU Mismatch)] でない場合に、ファームウェアの更新を開始できます。UCS ファームウェアを一度に更新できるベアメタルは 1 つだけです。ファームウェアの更新を開始するには、Secure Workload オーケストレータの状態が [アイドル(Idle)] である必要があります。UCS ファームウェアの更新が開始されると、Consul リーダー、アクティブなオーケストレータ、またはアクティブなファームウェアマネージャ(fwmgr)を他のホストに切り替える必要がある場合、[クラスタのステータス(Cluster Status)] ページに固有の UI 機能の一部が一時的に影響を受けることがあります。これらのスイッチオーバーは自動的に行われます。ファームウェアの更新中は、更新中のベアメタルホストのファームウェアの詳細は表示されません。更新が完了した後、[クラスタのステータス(Cluster Status)] ページにファームウェアの詳細が再度表示されるまで最大 15 分かかることがあります。ファームウェアの更新を開始する前に、[サービスのステータス(Service Status)] ページですべてのサービスが正常であることを確認してください。
ベアメタルでファームウェアの更新を開始すると、fwmgr では更新が続行できることを確認し、必要に応じてベアメタルを正常にパワーダウンし、ベアメタルの CIMC にログインして HUU ベースのファームウェアの更新を開始します。この HUU ベースのファームウェアの更新プロセスには、HUU ISO でベアメタルを起動させ、更新を実行し、CIMC を再起動して新しいファームウェアをアクティブ化し、その後 HUU ISO でベアメタルを再起動して、更新が完了したことを確認することが含まれます。全体的な更新プロセスには、G1 ベアメタルの場合は 2 時間以上、G2 ベアメタルの場合は 1 時間以上かかる場合があります。ファームウェアの更新プロセスが開始されると、ベアメタルと、そのベアメタルで実行されているすべての仮想マシンがクラスタ内でアクティブでなくなるため、[サービスのステータス(Service Status)] ページに、一部のサービスが正常でないと示される場合があります。ファームウェアの更新が完了すると、ベアメタルがクラスタ内で再びアクティブになるまでにさらに 30 分かかり、すべてのサービスが再び正常になるまでにさらに時間がかかる場合があります。ファームウェアの更新後 2 時間以内にサービスが回復しない場合は、シスコテクニカルサポートにお問い合わせください。
[クラスタのステータス(Cluster Status)] ページで、ベアメタルノードをクリックして、ベアメタルに関する詳細を展開できます。ファームウェアの更新が開始されたら、[ファームウェアのアップグレードログを表示(View Firmware Upgrade Logs)] ボタンをクリックして、ファームウェア更新のステータスを表示できます。このログには、ファームウェア更新の全体的なステータスが一番上に表示されます。内容は次のいずれかです。
[ファームウェアの更新がトリガーされました(Firmware update has been triggered)]:ファームウェアの更新が要求されましたが、まだ開始されていません。このステータス中に、fwmgr では、ファームウェアの更新に必要なサービスが機能していること、および CIMC がそれらのサービスに到達できることが確認されます。
[ファームウェアの更新を実行中です(Firmware update is running)]:ファームウェアの更新が開始されました。ファームウェアの更新がこの状態に達すると、CIMC と HUU で更新が制御され、Secure Workload クラスタでは CIMC から取得した更新に関するステータスが報告されます。
[ファームウェアの更新がタイムアウトしました(Firmware update has timed out)]:ファームウェアの更新の一部のプロセスが、完了予測時間を超えたことを示します。[ファームウェアの更新を実行中です(Firmware update is running)] のフェーズに入ると、ファームウェアの更新プロセス全体の制限時間は 240 分になります。ファームウェアの更新中に、新しいバージョンでリブートすると CIMC が到達不能になることがあります。この到達不能状態のタイムアウトは、ファームウェアの更新が「タイムアウト」と宣言されるまでの 40 分間です。ファームウェアの更新が開始されると、その更新のモニタリングは 120 分後にタイムアウトします。
[ファームウェアの更新がエラーのため失敗しました(Firmware update has failed with an error)]:エラーが発生し、ファームウェアの更新が失敗したことを示します。通常、CIMC では成功または失敗は示されません。そのため、この状態は通常、ファームウェアの更新が実際に実行される前にエラーが発生したことを示しています。
[ファームウェアの更新が終了しました(Firmware update has finished)]:ファームウェアの更新は、エラーやタイムアウトが発生することなく終了しました。通常、CIMC では成功または失敗は示されないため、[クラスタのステータス(Cluster Status)] ページでこれらの詳細が確認できるようになった後に、UCS ファームウェアバージョンが更新されているか確認することをお勧めします。詳細が確認できるようになるまで最大 15 分かかります。
[ファームウェアのアップグレードログを表示(View Firmware Upgrade Logs)] ポップアップウィンドウの全体的なステータスの下にある [更新の進行状況(Update progress)] セクションには、ファームウェア更新の進行状況を示すタイムスタンプ付きのログメッセージが含まれます。これらのログメッセージに [ホストの再起動が進行中です(Rebooting Host In Progress)] ステータスが表示されると、CIMC で更新が制御され、クラスタがその更新をモニターします。後続のほとんどのログメッセージは CIMC から直接送信され、更新のステータスが変更された場合にのみログメッセージのリストに追加されます。
CIMC で個々のコンポーネント更新ステータスの提供が開始されると、[ファームウェアのアップグレードログを表示(View Firmware Upgrade Logs)] ポップアップの [更新の進行状況(Update progress)] セクションの下に、[コンポーネントの更新ステータス(Component update status)] セクションが表示されます。このセクションでは、ベアメタル上のさまざまな UCS コンポーネントの更新のステータスがすぐに把握できます。
データのバックアップと復元は、Cisco Secure Workload クラスタ、コネクタ、および外部オーケストレータからオフサイトストレージにデータをコピーするディザスタ リカバリ メカニズムです。災害が発生した場合は、このオフサイトストレージから同じフォームファクタのクラスタにデータが復元されます。データのバックアップと復元のオプションを使用すると、災害が発生した場合に別のバックアップサイトに切り替えることができます。
データのバックアップと復元は、物理クラスタ(8RU と 39RU の両方)でサポートされています。
データは、S3V4 API と互換性のある任意の外部オブジェクトストアにバックアップできます。
Cisco Secure Workload には、データをバックアップするための十分な帯域幅とストレージが必要です。
継続的モードを使用した完全バックアップには、200 TB のストレージが推奨されます。必要な実際のストレージ容量を判断するには、[データバックアップ(Data Backup)] ページで使用可能な [キャパシティプランナー(Capacity Planner)] オプションを使用できます。詳細については、キャパシティプランナーの使用を参照してください。複数のバックアップ用のストレージが不足していると、ストレージの制限内で機能するように、古いバックアップが頻繁に削除されます。少なくとも 1 つのバックアップのために十分なストレージが必要です。
データは、プライマリと同じバージョンを実行している互換性のあるフォームファクタのクラスタにのみ復元できます。たとえば、8RU クラスタからのデータは、別の 8RU にのみ復元できます。
データバックアップのスケジュールは、UI の [データバックアップ(Data Backup)] セクションを使用して設定できます。バックアップは、設定に基づいて 1 日に 1 回スケジュールされた時刻にトリガーされるか、継続的に実行されるように設定することができます。バックアップの成功は、チェックポイントと呼ばれます。チェックポイントは、クラスタのプライマリデータストアのポイント イン タイム スナップショットです。
成功したチェックポイントを使用して、データを別のクラスタまたは同じクラスタに復元できます。
クラスタ設定データは、すべてのチェックポイントで常にバックアップされます。フローおよびその他のデータが、バックアップされるデータの大部分を占めます。そのため、適切に設定されている場合は、増分変更のみがバックアップされます。増分バックアップは、外部ストレージにプッシュされるデータの量を減らすために役立ち、ネットワークの過負荷を回避できます。増分バックアップが設定されている場合、必要に応じて、すべてのデータソースに対してスケジュールに従って完全バックアップをトリガーすることができます。完全バックアップでは、チェックポイント内のすべてのオブジェクトがコピーされます。オブジェクトが変更されていない場合でもコピーされます。これにより、クラスタ、クラスタとオブジェクトストア間のネットワーク、およびオブジェクトストア自体にかなりの負荷がかかる可能性があります。オブジェクトが破損している場合、またはオブジェクトストアに回復不能なハードウェア障害がある場合は、完全バックアップが必要になることがあります。さらに、バックアップ用に提供されているバケットが変更された場合は、完全バックアップが自動的に適用されます。これは、増分バックアップを役立てるには事前に完全バックアップが必要なためです。
Cisco Secure Workload クラスタデータ |
完全バックアップモードでデータがバックアップされるか |
リーンモードでデータがバックアップされるか |
---|---|---|
クラスタ設定 |
対応 |
対応 |
クラスタのイメージングに使用される RPM |
対応 |
対応 |
ソフトウェアエージェント展開イメージ |
対応 |
対応 |
フロー データベース |
対応 |
× |
自動ポリシー検出に必要なデータ |
対応 |
× |
適用ポリシー |
対応 |
× |
ファイルハッシュ、データリークモデルなどのフォレンジックに役立つデータ |
対応 |
× |
攻撃対象領域の分析に役立つデータ |
対応 |
× |
CVE データベース |
対応 |
× |
(注) |
セキュアコネクタ情報は、オンプレミスバージョンの Cisco Secure Workload ではバックアップまたは復元されませんが、SaaS バージョンの Cisco Secure Workload ではバックアップおよび復元されます。 |
Data Backup and Restore(DBR)機能のアクティベーションキーを取得するには、taentitlement@cisco.com に電子メールを送信して DBR アクティベーションキーを要求します。電子メールにはクラスタ ID ファイルも添付します。
(注) |
ライセンスの権限付与は、プライマリ(アクティブ)クラスタにのみ必要です。スタンバイクラスタには必要ありません。 |
オブジェクトストアのアクセスキーと秘密鍵が必要です。データのバックアップと復元のオプションは、オブジェクトストアの事前認証されたリンクでは機能しません。
Cisco Secure Workload アプライアンスがオブジェクトストアに使用する帯域幅を調整するポリシングを設定します。バックアップするデータの量が多い場合に低帯域幅でポリシングすると、バックアップが失敗する可能性があることに注意してください。
クラスタの FQDN を設定し、ソフトウェアエージェントが FQDN を解決できることを確認します。
(注) |
データのバックアップと復元を有効にすると、現在および以降のソフトウェア エージェント バージョンのみをインストールおよびアップグレードに使用できます。現在のクラスタバージョンよりも前のバージョンは、互換性がないため非表示のままです。 |
ソフトウェアエージェントまたは Kafka の FQDN の要件
ソフトウェアエージェントは、IP アドレスを使用して Cisco Secure Workload アプライアンスから制御情報を取得します。データのバックアップと復元を有効にして、災害後のシームレスなフェールオーバーを可能にするため、エージェントを FQDN の使用に切り替える必要があります。このスイッチでは、Cisco Secure Workload クラスタのアップグレードだけでは不十分です。ソフトウェアエージェントは、Cisco Secure Workload バージョン 3.3 以降で FQDN の使用をサポートしています。そのため、エージェントのフェールオーバーを有効にして、データのバックアップと復元の準備ができていることを確認するには、エージェントをバージョン 3.3 以降にアップグレードします。
FQDN が設定されていない場合、デフォルトの FQDN は次のとおりです。
IP タイプ(IP Type) |
デフォルトの FQDN |
---|---|
センサー VIP |
wss{{cluster_ui_fqdn}} |
Kafka 1 |
kafka-1-{{cluster_ui_fqdn}} |
Kafka 2 |
kafka-2-{{cluster_ui_fqdn}} |
Kafka 3 |
kafka-3-{{cluster_ui_fqdn}} |
FQDN は、
ページで変更できます。FQDN の DNS レコードを、同じページで提供される IP で更新します。次の表に、IP と FQDN のマッピングを示します。
フィールド名 |
対応する IP フィールド |
説明 |
---|---|---|
センサー VIP FQDN |
センサー VIP |
FQDN を更新してクラスタ コントロール プレーンに接続する |
Kafka 1 FQDN |
Kafka 1 IP |
Kafka ノード 1 IP |
Kafka 2 FQDN |
Kafka 2 IP |
Kafka ノード 2 IP |
Kafka 3 FQDN |
Kafka 3 IP |
Kafka ノード 3 IP |
(注) |
センサー VIP および Kafka ホストの FQDN は、データのバックアップと復元が設定される前にのみ変更できます。設定後は、FQDN は変更できません。 |
オブジェクトストアは、S3V4 準拠のインターフェイスを提供する必要があります。
所在地(Location)
オブジェクトストアの場所は、ストアからのバックアップと復元に伴う遅延にとって重要です。復元時間を短縮するには、オブジェクトストアがスタンバイクラスタの近くにあることを確認します。
Bucket
オブジェクトストアに、Cisco Secure Workload の専用の新しいバケットを作成します。クラスタのみが、このバケットへの書き込みアクセス権を持つ必要があります。このバケットに対して、クラスタがオブジェクトを書き込み、保持を管理します。バケット用に少なくとも 200 TB のストレージをプロビジョニングし、バケットのアクセスと秘密鍵を取得します。Cisco Secure Workload でのデータのバックアップと復元は、事前認証されたリンクでは機能しません。
(注) |
オブジェクトストアとして Cohesity が使用されている場合は、スケジュール時にマルチパートアップロードを無効にします。 |
HTTPS
データ バックアップ オプションは、オブジェクトストアでの HTTPS インターフェイスのみをサポートします。オブジェクトストアへ転送中のデータが暗号化され、安全であることを保証するためです。ストレージ SSL/TSL 証明書が信頼できるサードパーティ CA によって署名されている場合、クラスタはその証明書を使用してオブジェクトストアを認証します。オブジェクトストアが自己署名証明書を使用している場合は、[サーバーCA証明書を使用(Use Server CA Certificate)] オプションを選択して、公開キーまたは CA をアップロードできます。
サーバー側の暗号化
Cisco Secure Workload クラスタに割り当てられたバケットのサーバー側の暗号化をオンにすることを強く推奨します。クラスタは、HTTPS を使用してオブジェクトストアにデータを転送します。ただし、オブジェクトストアはオブジェクトを暗号化して、保存されたデータの安全性を確保する必要があります。
Cisco Secure Workload でデータバックアップを設定するには、次の手順を実行します。
計画:データバックアップのオプションでは、プランナーを使用して、オブジェクトストアへのアクセスをテストし、ストレージ要件と、各日に必要なバックアップ期間を決定することができます。これは、スケジュールを設定する前の試験に使用できます。
データのバックアップと復元の計算ツールを使用するには、
に移動します。データのバックアップと復元が設定されていない場合は、データバックアップのランディングページに移動します。(注) |
[プラットフォーム(Platform)] の下に [データバックアップ(Data Backup)] オプションが表示されない場合は、データのバックアップと復元を有効にするライセンスがあることを確認してください。 |
データバックアップの設定とスケジューリング:Cisco Secure Workload は、設定された時間枠でのみデータをオブジェクトストアにコピーします。バックアップを初めて設定するときに、事前チェックが実行され、FQDN が解決可能であり、正しい IP に解決されることを確認します。最初の検証後に、登録済みのソフトウェアエージェントに更新がプッシュされ、FQDN の使用に切り替わります。FQDN がないと、エージェントはディザスタイベント後に別のクラスタにフェールオーバーできません。FQDN の使用をサポートするには、クラスタでサポートされている最新バージョンにエージェントをアップグレードする必要があり、すべてのエージェントがセンサー VIP FQDN を解決できる必要があります。Cisco Secure Workload リリース 3.3 以降では、優れた可視性エージェントと適用エージェントのみがデータのバックアップと復元をサポートしており、FQDN の使用に切り替えます。
スケジュールを作成し、データバックアップを設定するには、データバックアップの設定を参照してください。
ストレージプランナーを使用するには、次の手順を実行します。
ステップ 1 |
ストレージに Cisco Secure Workload との互換性があることを確認するには、次のいずれかのアクションを実行します。
|
ステップ 2 |
次の詳細を入力します。
|
ステップ 3 |
(オプション)必要に応じて、HTTP プロキシを有効にできます。 |
ステップ 4 |
(オプション)バックアップされたデータのマルチパートアップロードを使用するには、[マルチパートアップロードの使用(Use Multipart Upload)] を有効にします。 |
ステップ 5 |
(オプション)ストレージサーバーの認証に CA 証明書が必要な場合は、[サーバーCA証明書の使用(Use Server CA Certificate)] を有効にして、証明書の詳細を入力します。 |
ステップ 6 |
[テスト(Test)] をクリックします。 |
ストレージの検証では、次のことがテストされます。
オブジェクトストアとバケットに対して認証およびアクセスします。
設定されたバケットにアップロードし、そのバケットからダウンロードします。
帯域幅をチェックします。
ストレージ プランニング プロセスが完了するまでに、約 5 分かかる可能性があります。
キャパシティプランナーを使用するには、次の手順を実行します。
ステップ 1 |
想定されるストレージサイズとバックアップ時間を計画するために、次のいずれかのアクションを実行します。
|
ステップ 2 |
データをバックアップするための最大帯域幅制限を入力します。 この帯域幅は、オブジェクトストアへのデータをスロットリングするポリサー設定の値以下である必要があります。 |
ステップ 3 |
登録済みソフトウェアエージェント数は自動的に入力されます。予測に基づいて、エージェント数を変更できます。 |
ステップ 4 |
(オプション)設定データ以外をバックアップから除外するには、[リーンデータモード(Lean Data Mode)] を有効にします。このオプションを使用すると、ストレージの制限が 75% 軽減されます。 |
ステップ 5 |
ストレージバケットに設定される最大ストレージ。これにより、バックアップの保持期間が自動的に設定されます。 |
必要な詳細を入力すると、[推定バックアップ期間(Estimated Backup Duration)] に 1 日のデータのバックアップに必要な時間が表示されます。この値は、一般的なエージェント負荷、推定エージェント数、および設定された最大帯域幅に基づく推定値です。[推定最大ストレージ(Estimated Maximum Storage)] には、指定された保持と推定エージェント数をサポートするために Cisco Secure Workload で必要となる最大ストレージの推定値が表示されます。
ステップ 1 |
データバックアップのランディングページで、[新しいスケジュールの作成(Create new schedule)] をクリックします。 |
||
ステップ 2 |
実行する前提条件チェックを確認するには、[承認(Approve)] ボタンをオンにして、[続行(Proceed)] をクリックします。 前提条件チェックは完了するまでに約 30 分かかり、スケジュールが初めて設定されたときにのみ実行されます。 |
||
ステップ 3 |
ストレージを設定するには、次の詳細を入力して、[テスト(Test)] をクリックします。
|
||
ステップ 4 |
ストレージ容量を設定するには、次の詳細を入力します。
|
||
ステップ 5 |
バックアップをスケジュールするには、以下を有効にします。
|
||
ステップ 6 |
設定済みのバックアップスケジュールと設定を確認し、[ジョブの開始(Initiate Job)] をクリックします。 |
データバックアップの設定後は、継続的なモードが有効になっていない限り、スケジュールされた時刻に毎日バックアップがトリガーされます。バックアップのステータスは、
に移動することで、[データバックアップ(Data Backup)] ダッシュボードで確認できます。最後に成功したチェックポイントからの経過時間は、チェックポイントにかかる時間と 24 時間を足した時間未満である必要があります。たとえば、チェックポイントとバックアップに約 6 時間かかる場合、最後に成功したチェックポイントからの経過時間は 30 時間未満である必要があります。
次のグラフでは、追加情報を提供します。
[チェックポイント期間(Checkpoint Duration)]:このグラフには、チェックポイントにかかる時間の近似曲線が表示されます。
[アップロード時間(Upload Duration)]:このグラフには、チェックポイントをバックアップにアップロードするためにかかる時間の近似曲線が表示されます。
[チェックポイントサイズ(Checkpoint Size)]:このグラフには、チェックポイントのサイズの近似曲線が表示されます。
[アップロード帯域幅(Upload Bandwidth)]:このグラフには、アップロード帯域幅の近似曲線が表示されます。
この表は、すべてのチェックポイントを示しています。チェックポイントラベルは編集可能で、スタンバイクラスタでデータを復元するためにチェックポイントを選択するときにラベルを使用できます。
チェックポイントは、複数の状態に移行します。使用される状態を以下に示します。
[作成済み/保留中(Created/Pending)]:チェックポイントは作成済みで、コピーされるのを待機しています。
[実行中(Running)]:データが、外部ストレージにアクティブにバックアップされています。
[成功(Success)]:チェックポイントが完了し、成功しました。データ復元に使用できます。
[失敗(Failed)]:チェックポイントは完了しましたが、失敗しました。データ復元には使用できません。
[削除中/削除済み(Deleting/Deleted)]:期限切れのチェックポイントが削除中であるか、削除されました。
スケジュールまたはバケットを変更するには、[スケジュールの編集(Edit Schedule)] をクリックします。ウィザードを完了するには、「データバックアップの設定」の項を参照してください。
チェックポイントの作成中のエラーをトラブルシューティングするには、トラブルシューティング:データのバックアップと復元を参照してください。
[スケジュールの非アクティブ化(Deactivate Schedule)] ボタンをクリックすることで、バックアップを非アクティブ化できます。スケジュールを変更する前に、バックアップスケジュールを非アクティブ化することをお勧めします。スケジュールを無効にするのは、進行中のチェックポイントがない場合のみにします。チェックポイントの進行中にテストを実行したり、スケジュールを無効にしたりすると、進行中のチェックポイントが失敗し、アップロードが未定義の状態になる可能性があります。
Cisco Secure Workload クラスタは、バケット内のオブジェクトのライフサイクルを管理します。バケットのオブジェクトを削除または追加してはなりません。これを行うと、不整合が発生し、正常なチェックポイントが破損する可能性があります。構成ウィザードで、使用する最大ストレージを指定する必要があります。Cisco Secure Workload は、バケットの使用量が設定された制限内に収まるようにします。オブジェクトをエージアウトしてバケットから削除するストレージ保持サービスがあります。ストレージ使用量は、設定された最大ストレージと受信データレートに基づいて計算されます。保持サービスは、使用量がしきい値(バケット容量の 80%)に達すると、使用量をしきい値未満に減らすために、保存されていないチェックポイントを削除しようとします。また、保持サービスでは、常に最低 2 つの成功したチェックポイントと、保存されたすべてのチェックポイントの、いずれか多い方が維持されます。保持サービスでチェックポイントを削除して容量を空けることができない場合、チェックポイントでエラーが発生し始めます。
新しいチェックポイントが作成されると、古いチェックポイントはエージアウトになり、削除されます。ただし、チェックポイントを保持することができ、保持設定により削除されることがなくなります。保持されたチェックポイントは削除されません。保持されたチェックポイントが複数ある場合、ある時点で新しいオブジェクト用のストレージが足りなくなりますが、エージアウトしたチェックポイントは保持されているため削除されません。ベストプラクティスとして、必要に応じてチェックポイントを保持し、参照用としてラベルにその理由と妥当性を含めてチェックポイントを更新します。チェックポイントを保持するには、必要なチェックポイントのロックアイコンをクリックします。
データの復元オプションは、左側のナビゲーションバーの [プラットフォーム(Platform)] メニューで使用できます。
バックアップデータを使用してクラスタを復元するには、クラスタが DBR スタンバイモードになっている必要があります。現在、クラスタは初期設定時にのみスタンバイモードに設定できます。
次の組み合わせが可能です。
プライマリクラスタ SKU |
スタンバイクラスタ SKU |
---|---|
8RU-PROD |
8RU-PROD、8RU-M5 |
8RU-M5 |
8RU-PROD、8RU-M5 |
39RU-GEN1 |
39RU-GEN1、39RU-M5 |
39RU-M5 |
39RU-GEN1、39RU-M5 |
データの復元を開始するには、シスコに連絡してください。
サイト情報でリカバリオプションを設定することにより、クラスタをスタンバイモードで展開できます。展開中にサイト情報を設定するときに、展開中の設定 UI の [リカバリ(Recovery)] タブで復元の詳細を設定します。
スタンバイを展開するには 3 つのモードがあり、3 つすべてのモードで次の設定を行います。
[スタンバイ設定(Standby Config)] を [オン(On)] に設定します。この設定は、一度設定するとクラスタが再展開されるまで変更できません。
プライマリクラスタ名と FQDN を設定します。この設定は、後で変更できます。
展開の残りの部分は、Cisco Secure Workload クラスタの通常の展開と同じです。
クラスタがスタンバイモードになると、Cisco Secure Workload の UI にバナーが表示されます。
展開後にプライマリクラスタ名と FQDN を再設定して、スタンバイクラスタが別のクラスタを追跡できるようにすることが可能です。この設定は、[クラスタ設定(Cluster Configuration)] ページからフェールオーバーがトリガーされる前に、後で再設定できます。
コールドスタンバイ:スタンバイクラスタはありません。ただし、プライマリクラスタはデータを S3 にバックアップします。災害時には、新しいクラスタ(またはプライマリと同じクラスタ)をプロビジョニングし、スタンバイモードで展開して復元する必要があります。
ウォームスタンバイ:スタンバイクラスタが使用可能であり、スタンバイモードで展開されています。災害発生時に使用できるように、S3 クラスタから定期的に状態を取得し、準備完了状態にします。災害時には、この新しいクラスタにログインして、フェールオーバーをトリガーします。
ルークウォームスタンバイ:複数のプライマリクラスタが、より少ないスタンバイクラスタによってバックアップされます。スタンバイクラスタはスタンバイモードで展開されます。災害発生後にのみ、ストレージバケット情報が設定され、データがプリフェッチされて、クラスタが復元されます。
クラスタを復元する前に、データをプリフェッチする必要があります。チェックポイントデータは、データのバックアップに使用されるのと同じストレージバケットからプリフェッチされます。バックアップサービスがストレージからダウンロードできるようにするには、ログイン情報を提供する必要があります。ストレージがプリフェッチ用に設定されていない場合、[データの復元(Data Restore)] タブによりセットアップウィザードが起動されます。
(注) |
スタンバイクラスタは、S3 ストレージとのみ対話します。プライマリクラスタのバックアップを更新して別のストレージまたはバケットを使用する場合、スタンバイクラスタのストレージを更新する必要があります。 |
情報が検証されると、ストレージはプリフェッチ用に自動設定されます。復元タブにプリフェッチステータスが表示されます。
ステータスページには、次の詳細が表示されます。
左上のセクションには、復元を開始するためのさまざまなコンポーネントの準備ができていることを示す図があります。データを確認するには、コンポーネントにカーソルを合わせます。関連データが右上のセクションに表示されます。
[バケット(Bucket)]:プリフェッチステータスが表示されます。最新のデータが 45 分以上前のものである場合、赤で表示されます。アクティブでのバックアップが各チェックポイントで 45 分以上かかる場合、最新のデータが 45 分以上古いことは問題ではないことに注意してください。
[DNS]:スタンバイクラスタ IP アドレスに関する Kafka および WSS FQDN 解決が表示されます。復元中に、FQDN がスタンバイクラスタ IP アドレスに更新されない場合、エージェントは接続できません。FQDN がスタンバイクラスタへの解決を開始した後に、ステータスが緑色に変わります。
[エージェント(Agents)]:スタンバイクラスタに正常に切り替えられたソフトウェアエージェントの数が表示されます。これは復元がトリガーされた後にのみ関係します。
右上のセクションには、左側のセクションで選択したグラフィックに関連する情報が表示されます。[今すぐ復元(Restore Now)] をクリックすると、復元プロセスが開始されます。
左下のセクションには、使用中のプリフェッチストレージ設定が表示されます。
右下のセクションには、プリフェッチ遅延のグラフが表示されます。
データのプリフェッチは、迅速な復元を確実にするために、いくつかの必要なコンポーネントを更新します。データのプリフェッチを完了できない場合は、失敗の理由がステータスページに表示されます。
プリフェッチの失敗原因となる一般的なエラー:
S3 アクセスエラー:この場合、ストレージからのデータを正常にダウンロードできませんでした。これは、無効なログイン情報、ストレージポリシーの変更、または一時的なネットワークの問題が原因で発生する可能性があります。
互換性のないクラスタバージョン:プライマリクラスタと同じバージョン(同じパッチバージョンを含む)の Cisco Secure Workload を実行しているクラスタにデータを復元できます。これは、アップグレード中にクラスタの 1 つだけがアップグレードされている場合に発生することがあります。または、展開中に、別のバージョンが展開に使用されている場合です。クラスタを共通バージョンに展開すると、この問題が解消されます。
互換性のない SKU バージョン:プライマリクラスタについて、スタンバイクラスタで許可されている SKU をメモします。プライマリクラスタの SKU の復元には、特定の SKU のみが許可されます。
クラスタの復元は、[復元ステータス(Restore Status)] ページの右上のセクションにある [今すぐ復元(Restore Now)] をクリックしてトリガーできます。復元アクションがトリガーされる前に、確認を求められます。
クラスタデータは、次の 2 つのフェーズで復元されます。
必須フェーズ:サービスを再開するために必要なデータが最初に復元されます。必須フェーズにかかる時間は、設定、インストールされているソフトウェアエージェントの数、バックアップされているデータの量、およびフローメタデータによって異なります。必須フェーズ中は、UI にアクセスできません。必須フェーズに UI にアクセスする必要が生じた場合、サポートを受けるにはワーキング TA ゲストキーが必要です。
レイジーフェーズ:クラスタデータ(フローデータを含む)はバックグラウンドで復元され、クラスタの使用はブロックされません。クラスタ UI にアクセスでき、復元の完了率を示すバナーが表示されます。このフェーズ中、クラスタは動作可能であり、データパイプラインは正常に機能し、フロー検索も使用できます。
この項では、データのバックアップおよび復元ソリューションの目標復旧時間(RTO)と目標復旧時点(RPO)について説明します。
プライマリクラスタで開始されたバックアップは、バックアップされるデータの量とバックアップ設定に応じて、完了するまでに時間がかかります。さまざまなバックアップモードによって、ソリューションの RPO が定義されます。
スケジュールされている場合、継続的でないバックアップが使用され、バックアップは 1 日に 1 回開始されます。災害が発生した場合、失われるデータの最大時間は、約 24 時間 + バックアップストレージにデータをコピーするためにかかる時間です。そのため、RPO は少なくとも 24 時間です。
継続的なモードのバックアップを使用する場合は、新しいバックアップが前のバックアップの 15 分後に開始されます。各バックアップで、作成のために一定の時間がかかり、その後、データをバックアップストレージにアップロードするために一定の時間がかかります。最初のバックアップは完全バックアップで、その後のバックアップは増分バックアップです。増分バックアップにはそれほど時間がかかりません。災害が発生した場合、失われるデータの量は、バックアップの作成にかかった時間と、ストレージへのバックアップのアップロードにかかった時間の合計になります。通常、この場合の RPO は約数分から 1 時間です。
クラスタを復元する場合、まず必須データがストレージからプリフェッチされ、次に必須復元フェーズがトリガーされます。必須復元フェーズ中は、UI を使用できません。必須復元が完了すると、UI を使用できるようになります。残りのデータは、遅延復元フェーズで復元されます。この場合の RTO は、必須フェーズが完了した後、UI が使用可能になるまでにかかる時間です。RTO は、スタンバイ展開モードによって異なります。
コールドスタンバイモード:このモードでは、クラスタを最初に展開する必要があります。これには約数時間かかります。次に、バックアップストレージのログイン情報を使用してクラスタを設定する必要があります。初めてバックアップがスタンバイクラスタにアップロードされるため、取得して処理する必要がある必須データが多数あります。プリフェッチにかかる時間は約数十分です(バックアップされるデータの量によって異なります)。必須復元フェーズが完了するまで約 30 分かかります。まとめると、主にクラスタの起動と展開にかかる時間が原因で、RTO 時間は約数時間になります。
ルーク ウォーム スタンバイ モード:このモードでは、クラスタはすでに展開されていますが、バックアップストレージは設定されていません。バックアップストレージのログイン情報を使用してクラスタを設定する必要があります。初めてバックアップがスタンバイクラスタにアップロードされるため、取得して処理する必要がある必須データが多数あります。プリフェッチにかかる時間は約数十分です(バックアップされるデータの量によって異なります)。必須復元フェーズが完了するまで約 30 分かかります。まとめると、バックアップされるデータの量とバックアップストレージからデータをプルするためにかかる時間に応じて、RTO 時間は約 1 ~ 2 時間になります。
ウォームスタンバイモード:このモードでは、クラスタがすでに展開され、バックアップストレージが設定されていて、プリフェッチによりストレージからデータが取得されています。クラスタはすぐに復元できるようになります。復元により必須復元フェーズがトリガーされ、完了するまで約 30 分かかります。RTO 時間は約 30 分になります。アクティブからストレージにバックアップがアップロードされてから、スタンバイによってバックアップがプルされるまでには、ある程度の遅延が生じることに注意してください。これには約数分かかります。(ディザスタイベントが発生する前に)アクティブから最新のバックアップがスタンバイにプリフェッチされていない場合は、取得されるまで数分間待つ必要があります。
クラスタでデータのバックアップと復元が有効になっている場合は、アップグレードを開始する前にスケジュールを非アクティブ化することを推奨します。「バックアップスケジュールの非アクティブ化」を参照してください。これにより、アップグレードが開始される前に正常なバックアップが存在し、新しいバックアップがアップロードされないことが保証されます。失敗したチェックポイントが作成されることを回避するため、スケジュールの非アクティブ化は、チェックポイントが進行中でないときに実行する必要があります。
ストレージテストが失敗した場合は、右側のペインに表示される障害シナリオを特定し、次のことを確認します。
S3 準拠のストレージ URL が正しい
ストレージのアクセスキーと秘密鍵が正しい
ストレージ上にバケットが存在し、正しいアクセス(読み取り/書き込み)権限が付与されている
ストレージに直接アクセスする必要がある場合は、プロキシが設定されている
Cohesity を使用している場合は、マルチパート アップロード オプションが無効になっている
次の表は、一般的なエラーシナリオと解決策を示したものであり、すべてを網羅したものではありません。
エラー メッセージ |
シナリオ |
対処法 |
---|---|---|
検索不可(Not found) |
正しくないバケット名 | ストレージに設定されているバケットの正しい名前を入力します |
SSL接続エラー(SSL connection error) |
SSL 証明書の有効期限または検証のエラー |
SSL 証明書を確認します |
無効な HTTPS URL |
|
|
接続のタイムアウト |
S3 サーバーの IP アドレスに到達できません |
クラスタと S3 サーバーの間のネットワーク接続を確認します |
URLに接続できません(Unable to connect to URL) |
正しくないバケットリージョン |
正しいバケットのリージョンを入力します |
無効な URL |
S3 ストレージエンドポイントの正しい URL を再入力します |
|
Forbidden |
無効な秘密鍵 |
ストレージの正しい秘密鍵を入力します |
無効なアクセスキー |
ストレージの正しいアクセスキーを入力します |
|
S3設定を確認できません(Unable to verify S3 configuration) |
その他の例外または一般的なエラー |
しばらくしてから S3 ストレージの設定を試みます |
次の表は、チェックポイントの一般的なエラーコードを示したものであり、すべてを網羅したものではありません。
エラー コード |
説明 |
---|---|
E101:DBのチェックポイントの失敗(E101: DB checkpoint failure) |
Mongodb oplog のスナップショットを取得できません |
E102:フローデータのチェックポイントの失敗(E102: Flow data checkpoint failure) |
Druid データベースのスナップショットを取得できません |
E103:DBスナップショットのアップロードの失敗(E103: DB snapshot upload failure) |
Mongo DB スナップショットをアップロードできません |
E201:DBのコピーの失敗(E201: DB copy failure) |
Mongo スナップショットを HDFS にアップロードできません |
E202:設定のコピーの失敗(E202: Config copy failure) |
Consul-Vault スナップショットを HDFS にアップロードできません |
E203:設定のチェックポイントの失敗(E203: Config checkpoint failure) |
consul-vault データのチェックポイントを実行できません |
E204:チェックポイント中の設定データの不一致(E204: Config data mismatch during checkpoint) |
最大再試行回数後に consul/vault チェックポイントを生成できません |
E301:バックアップデータのアップロードの失敗(E301: Backup data upload failure) |
HDFS チェックポイントの失敗 |
E302:チェックポイントのアップロードの失敗(E302: Checkpoint upload failure) |
Copydriver が S3 にデータをアップロードできませんでした |
E401:チェックポイント中のシステムアップグレード(E401: System upgrade during checkpoint) |
このチェックポイント中にクラスタがアップグレードされました。チェックポイントは使用できません |
E402:チェックポイント中のサービスの再起動(E402: Service restart during checkpoint) |
Bkpdriver が作成状態で再起動しました。チェックポイントは使用できません |
E403:前のチェックポイントの失敗(E403: Previous checkpoint failure) |
前回の実行でチェックポイントが失敗しました |
E404:別のチェックポイントが進行中(E404: Another checkpoint in progress) |
別のチェックポイントが進行中です |
E405:チェックポイントを作成できない(E405: Unable to create checkpoint) |
チェックポイントのサブプロセスでエラーが発生しました |
失敗:完了(Failed: Completed) |
先行するチェックポイントの一部が失敗しました。同時に開始する複数のチェックポイントが重複している可能性があります |
[トラブルシューティング(Troubleshoot)] メニューの [仮想マシン(Virtual Machine)] ページには、Cisco Secure Workload クラスタの一部であるすべての仮想マシンが表示されます。クラスタの起動またはアップグレード(あれば)中の展開ステータス、さらにパブリック IP も表示されます。クラスタ内のすべての VM はパブリックネットワークの一部ではないため、パブリック IP を持たない場合があることに注意してください。
アップグレードオプションにアクセスするには、左側のナビゲーションバーで [プラットフォーム(Platform)] > [アップグレード/再起動/シャットダウン(Upgrade/Reboot/Shutdown)] をクリックします。
アップグレードには 2 種類があります。ここでは、「フル」アップグレードプロセスについて説明します。このアップグレード中に、Orchestrator-VM を除くクラスタ内のすべての VM がシャットダウンされ、新しい VM が展開され、サービスが再プロビジョニングされます。クラスタ内のすべてのデータは、このアップグレード中に保持されます。ただし、このアップグレード中に発生する約 2 時間のダウンタイムを除きます。
アップグレードを開始するには、左側のナビゲーションバーで [プラットフォーム(Platform)] > [アップグレード/再起動/シャットダウン(Upgrade/Reboot/Shutdown)] をクリックします。
アップグレードページには、クラスタのアップグレード/パッチアップグレード/シャットダウン/再起動オプションがあります。
フルアップグレードを開始するには、[アップグレードリンクの送信(Send Upgrade Link)] をクリックします。フルアップグレードを実行すると、オーケストレータ VM 以外のすべての VM がシャットダウンされ、それらすべてがアップグレードおよび再展開されます。このため、2 時間以上のクラスタのダウンタイムが発生します。パッチアップグレードを実行するとダウンタイムは最小限に抑えられますが、パッチの適用が必要なサービスが更新されるだけで、VM は再起動されません。ダウンタイムは通常、数分程度です。パッチアップグレードを開始するには、[パッチアップグレードリンクの送信(Send Patch Upgrade Link)] をクリックします。電源を切った後にクラスタの再起動を開始するには、[再起動リンクの送信(Send Reboot Link)] を使用します。これらのリンクのいずれかをクリックすると、リンクを含む電子メールが生成され、アップグレードを開始したユーザーに送信されます。
オーケストレータは電子メールを送信する前に、いくつかの検証チェックを実行して、クラスタがアップグレード可能であることを確認します。検証チェックの内容は次のとおりです。
稼働停止中のノードがないことを確認します。
各ベアメタルをチェックして、ハードウェア障害がないことを確認します。ハードウェア障害には以下が含まれます。
ドライブの障害
ドライブの予測可能な障害
ドライブの欠落
StorCLI の障害
MCE ログエラー
すべての BM が稼働状態であることを確認します。39RU の場合はサーバーが 36 台以上、8RU の場合は 6 台以上であることを確認します。
いずれかの障害がある場合は、アップグレードリンクは送信されません。HW エラーやホスト欠落などの情報を含む 500 エラーが表示されるため、オーケストレータログで詳細を確認します。このシナリオでは、ホストの orchestrator.service.consul にある /local/logs/tetration/orchestrator/orchestrator.log で、最後の 100 個のエラーメッセージを確認できます。ここで、3 つのチェックポイントのどれが障害の原因であるかに関する詳細情報が提供されます。このとき、通常はハードウェアの修正とノードの再稼働が必要になります。それが完了したら、[アップグレードリンクの送信(Send Upgrade Link)] をクリックしてアップグレードを再開できます。
電子メールのリンクをクリックすると、クラスタのセットアップ UI に接続します。セットアップ UI は、クラスタの展開とアップグレードで使用する操作 UI です。最初のページには、現在クラスタにインストールされている RPM のリストが表示されます。このページは、すべての RPM をアップロードするためのアップロードページでもあります。
セットアップ UI に表示される順序で RPM をアップロードします。順序は次のとおりです。
tetration_os_rpminstall_k9
tetration_os_UcsFirmware_k9
tetration_os_adhoc_k9
tetration_os_mother_rpm_k9
tetration_os_enforcement_k9
tetration_os_base_rpm_k9
(注) |
vSphere に展開された Secure Workload 仮想クラスタの場合は、必ず tetration_os_ova_k9 RPM もアップグレードしてください。tetration_os_base_rpm_k9 はアップグレードしないでください。 |
これ以外の順序でアップロードすると、アップロードが失敗します。すべての RPM が正しい順序でアップロードされるまで、[続行(Continue)] ボタンは無効になります。
各アップロードのログは、それぞれの RPM の左側にあるログ記号をクリックして表示できます。また、失敗したアップロードは赤色でマークされます。
次のステップは、サイト情報を更新することです。すべてのサイト情報フィールドが更新可能というわけではありません。次のフィールドのみを更新できます。
SSH 公開キー
Sentinel アラート電子メール(Bosun 用)
CIMC 内部ネットワーク
CIMC 内部ネットワークゲートウェイ
外部ネットワーク。注:既存の外部ネットワークは変更しないでください。既存のネットワークに付加することで、さらにネットワークを追加できます。既存のネットワークを変更または削除すると、クラスタが使用できなくなります。
DNS リゾルバ
DNS ドメイン
NTP サーバ
SMTP サーバー(SMTP Server)
SMTP ポート(SMTP Port)
SMTP ユーザー名(オプション)
SMTP パスワード(オプション)
Syslog サーバー(オプション)
Syslog ポート(オプション)
Syslog シビラティ(重大度)(オプション)
(注) |
Syslog サーバーのシビラティ(重大度)は、クリティカルから情報提供までの範囲です。Bosun アラートのシビラティ(重大度)は、警告以上(情報提供)に設定する必要があります。 |
(注) |
バージョン 3.1 以降、セットアップ UI を介した外部 syslog はサポートされていません。ユーザーは、syslog にデータをエクスポートするように TAN アプライアンスを設定する必要があります。詳細については、「TAN に移行する外部 syslog トンネリング」を参照してください。 |
(注) |
Secure Workload は、STARTTLS コマンドを介した SSL/TLS 通信を行うメールサーバーとの安全な SMTP 通信をサポートします。安全なトラフィックをサポートするサーバーの標準ポートは、通常は 587/TCP ですが、多くのサーバーは標準の 25/TCP ポートでも安全な通信を受け入れます。 Secure Workload は、外部メールサーバーと通信するための SMTPS プロトコルをサポートしていません。 |
残りのフィールドは更新できません。変更がない場合は、[続行(Continue)] をクリックしてアップグレード前のチェックをトリガーします。変更がある場合は、フィールドを更新して [続行(Continue)] をクリックします。
アップグレードを開始する前に、クラスタでいくつかのチェックを行い、アップグレードを開始する前に問題がないことを確認します。
RPM バージョンチェック:すべての RPM がアップロードされ、バージョンが正しいことを確認します。状態が正しいかどうかを確認するのではなく、アップロードされたかどうかを確認するだけです。状態チェックは、アップロード自体の一部として実行されます。
サイトリンター:サイト情報のリンティングを行います。
スイッチ構成:リーフ/スパインスイッチを構成します。
サイトチェッカー:DNS、NTP、および SMTP サーバーのチェックを行います。最後にトークン付きの電子メールを送信します。このメールは、プライマリサイトの管理者アカウントに送信されます。DNS、NTP、または SMTP のいずれかのサービスが使用できない場合、この手順は失敗します。
トークンの検証:電子メールで送信されたトークンを入力し、[続行(Continue)] をクリックします。
アップグレード前の手順が完了したら、「トークンの確認メール」で受け取ったトークンを入力した後に、[続行(Continue)] をクリックすると、アップグレードを開始できます。[障害時に停止を無視(Ignore Stop Failures)] という追加オプションがありますが、このオプションをオンにしてはいけません。これは、特定のサービスがシャットダウンせず、アップグレードが失敗した場合の回復オプションです。このオプションを使用すると、VM が強制的にシャットダウンされ、サービスの再稼働時に障害が発生する可能性があります。このオプションは、エンジニアの監督下で使用してください。
[続行(Continue)] をクリックすると、アップグレードが開始されます。
ステップ 1 |
右上のクラスタ名をクリックすると、使用されているサイト情報が表示されます。 |
ステップ 2 |
その下には、すべての Tetration_os RPM とそのバージョンがあります。 |
ステップ 3 |
グローバル アップグレード バーには、アップグレードの進行状況が表示されます。進行中は青色、完了時は緑色、失敗時は赤色になります。進行状況バーのすぐ上に、アップグレードの現在のステータスが表示されます。 |
ステップ 4 |
また、次の 3 つのボタンがあります。
|
ステップ 5 |
次に、インスタンスビューが表示されます。個々の VM の展開ステータスがすべて追跡されます。インスタンスビューは次の列で構成されます。
|
ログには 2 つのタイプがあります。
VM 展開ログ:これらのログは、[ログの表示(View Log)] ボタンをクリックして表示できます。
オーケストレーションログ。詳細ボタンの横にある矢印をクリックすると、これらが表示されます。次のように表示されます。
各リンクはログを指します。
ステップ 1 |
[Orchestrator] - オーケストレータログ:これは進行状況を追跡する最初の場所です。エラーが発生すると、別のログを指して参照します。 |
ステップ 2 |
[Orchestrator-Upgrade] - 2.3 の NOP |
ステップ 3 |
[Orchestrator-consul]:プライマリオーケストレータで実行される consul ログ |
ステップ 4 |
[Orchestrator-Scheduler] - VM スケジューラログ:どの VM がどのベアメタルに配置されたかを示すログと、スケジューリングログ |
ステップ 5 |
[Orchestrator-server]:オーケストレータからの HTTP サーバーログ |
ステップ 6 |
[Playbooks-*]:オーケストレータで実行されるすべての playbook ログ。 |
場合によっては、アップグレードをスケジュールした後、アップグレードを開始しているときに、ハードウェア障害が発生するか、クラスタをアップグレードする準備ができていないことがあります。アップグレードを続行する前に、これを修正する必要があります。アップグレードウィンドウまで待つ代わりに、アップグレードの事前チェックをいつでも開始できます。これらのチェックは、アップグレード/パッチ/再起動の開始時を除き、いつでも何度でも実行できます。アップグレードの事前チェックを任意のタイミングで実行するには、[アップグレード(Upgrade)] ページに移動します。
[アップグレードの事前チェックの開始(Start Upgrade Precheck)] をクリックします。これにより、アップグレードの事前チェックが開始され、実行状態に移行します。
この間、オーケストレータはすべてのアップグレードの事前チェックを実行します。すべてのチェックに合格すると、チェックを開始したユーザーに、電子メールトークンが記載された電子メールが送信されます。トークンを入力して、アップグレードの事前チェックを完了します。
アップグレードの事前チェック中にエラーが発生した場合、失敗状態に移行し、失敗したタスクが表示されます。ステータスはいつでも確認でき、新しいダイアログボックスに表示されます。
クラスタで DBR が有効になっている場合は、「アップグレード(DBR あり)」も参照してください。
カスタマーサポートロールを持つユーザーは、ウィンドウの左側にあるナビゲーションバーから を選択して、スナップショットツールにアクセスできます。
スナップショットツールを使用して、クラシックスナップショットまたは Cisco Integrated Management Controller(CIMC)テクニカルサポートバンドルを作成できます。スナップショット ファイル リスト ページで [スナップショットの作成(Create Snapshot)] ボタンをクリックすると、クラシックスナップショットまたは CIMC スナップショット(テクニカルサポートバンドル)を選択するページがロードされます。CIMC スナップショットを選択するオプションは、Secure Workload ソフトウェアのみ(ESXi)および Secure Workload SaaS では無効になっています。
[クラシックスナップショット(Classic Snapshot)] ボタンをクリックすると、スナップショットツールを実行するためのユーザーインターフェイスがロードされます。
[CIMC スナップショット(CIMC Snapshot)] ボタンをクリックすると、CIMC テクニカルサポートツールを実行するためのユーザーインターフェイスがロードされます。
[スナップショットの作成(Create Snapshot)] でデフォルトのオプションを選択すると、スナップショットツールは次の情報を収集します。
ログ
Hadoop/YARN アプリケーションの状態とログ
アラート履歴
さまざまな TSDB 統計情報
デフォルトをオーバーライドして、特定のオプションを指定することができます。
ログオプション
最大ログ日数(max log days):収集するログの日数、デフォルトは 2。
最大ログサイズ(max log size ):収集するログごとの最大バイト数、デフォルトは 128 KB。
ホスト(hosts):ログ/ステータスを取得するホスト、デフォルトは [すべて(all)]。
ログファイル(logfiles): 取得するログの正規表現、デフォルトは [すべて(all)]。
yarn オプション
yarn アプリの状態(yarn app state):情報を取得するアプリケーションの状態([実行中(RUNNING)]、[失敗(FAILED)]、[強制終了(KILLED)]、[未割り当て(UNASSIGNED)] など)。デフォルトは all。
アラートオプション
アラート日数(alert days):アラートデータを収集する日数。
tsdb オプション
tsdb 日数(tsdb days):tsdb データを収集する日数。この値を増やすと、非常に大規模なスナップショットが作成される可能性があります。
fulltsdb オプション
fulltsdb:startTime、endTime fullDumpPath、localDumpFile、nameFilterIncludeRegex を指定し、収集するメトリックを制限するために使用できる JSON オブジェクト。
コメント(comments):スナップショットを収集する理由や収集するユーザーを記載するために追加できます。
[スナップショットの作成(Create Snapshot)] を選択すると、スナップショット ファイル リスト ページの上部にスナップショットの進行状況バーが表示されます。スナップショットが完了したら、スナップショット ファイル リスト ページの [ダウンロード(Download)] ボタンを使用してダウンロードできます。一度に収集できるスナップショットは 1 つだけです。
CIMC スナップショット(テクニカルサポートバンドル)ページで、CIMC テクニカルサポートバンドルを作成するノードのシリアル番号を選択し、[スナップショットの作成(Create Snapshot)] ボタンをクリックします。CIMC テクニカルサポートバンドル収集の進捗バーがスナップショット ファイル リスト ページに表示され、コメントセクションには CIMC テクニカルサポートバンドル収集がトリガーされたことが反映されます。CIMC テクニカルサポートバンドルの収集が完了すると、スナップショット ファイル リスト ページからファイルをダウンロードできます。
スナップショットを解凍すると、各マシンのログを含む ./clustername_snapshot ディレクトリが作成されます。ログは、マシンのいくつかのディレクトリのデータを含むテキストファイルとして保存されます。スナップショットは、JSON 形式でキャプチャされたすべての Hadoop/TSDB データも保存します。
パッケージ化された index.html をブラウザで開くと、次のタブが表示されます。
アラート状態の変化についての簡潔なリスト。
grafana ダッシュボードの複製。
ジョブとその状態を含む Hadoop Resource Manager のフロントエンドの複製。ジョブを選択すると、そのジョブのログが表示されます。
収集されたすべてのログのリスト
スナップショットサービスを使用してサービスコマンドを実行できますが、これにはカスタマーサポート権限が必要です。
Explore ツール (
])を使用すると、クラスタ内の任意の URI に到達できます。Explore ツールは、カスタマーサポートの権限を持つユーザーのみに表示されます。
スナップショットサービスは、すべてのノードのポート 15151 で実行されます。内部ネットワークのみでリッスンし(外部には公開されません)、さまざまなコマンド用の POST エンドポイントがあります。
到達する必要がある URI は POST http://<hostname>:15151/<cmd>?args=<args> です。ここで args はスペースで区切られ、URI はエンコードされます。この URI によってシェルでコマンドが実行されることはありません。これにより、何かが実行されることを回避できます。
スナップショットのエンドポイントは、次に対して定義されています。
snapshot 0.2.5
̶Is
̶ svstatus、svrestart - sv status、sv restart を実行 例:1.1.11.15:15151/svrestart?args=snapshot
̶ hadoopls - hadoop fs -ls <args> を実行
̶ hadoopdu - hadoop fs -du <args> を実行
̶ ps 例:1.1.11.31:15151/ps?args=eafux
̶ du
̶ ambari - ambari_service.py を実行
̶ monit
̶ MegaCli64(/usr/bin/MegaCli64)
̶ service
̶ hadoopfsck - hadoop -fsck を実行
snapshot 0.2.6
̶ makecurrent - make -C /local/deploy-ansible current を実行
̶ netstat
snapshot 0.2.7(uid “nobody” として実行)
̶ cat
̶ head
̶ tail
̶ grep
̶ ip -6 neighbor
̶ ip address
̶ ip neighbor
別のエンドポイント POST /runsigned があります。これは、Secure Workload により署名されたシェルスクリプトを実行します。これは、POST されたデータ上で gpg -d を実行します。署名に対して検証できる場合は、暗号化されたテキストをシェルで実行します。これは、Ansible セットアップの一部として各サーバーに公開鍵をインポートすること、および秘密鍵を安全に保つ必要があることを意味します。
カスタマーサポートの権限を持つユーザーは、ウィンドウの左側にあるナビゲーションバーから
を選択して、ランブックを使用できます。ドロップダウンメニューから [POST] を選択します。(そうしないと、コマンドの実行時に Page Not Found エラーが発生します。)スナップショット REST エンドポイントを使用してサービスを再起動します。
druid: 1.1.11.17:15151/service?args=supervisord%20restart
— druid ホストは、すべて .17 から .24 までの IP です。.17、.18 はコーディネータ、.19 はインデクサ、.20 ~ .24 はブローカです。
hadoop パイプラインランチャ:
̶ 1.1.11.25:15151/svrestart?args=activeflowpipeline
̶ 1.1.11.25:15151/svrestart?args=adm
̶ 1.1.11.25:15151/svrestart?args=batchmover_bidir
̶ 1.1.11.25:15151/svrestart?args=batchmover_machineinfo
̶ 1.1.11.25:15151/svrestart?args=BDPipeline
̶ 1.1.11.25:15151/svrestart?args=mongo_indexer
̶ 1.1.11.25:15151/svrestart?args=retentionPipeline
ポリシー エンジン
̶ 1.1.11.25:15151/svrestart?args=policy_server
wss
̶ 1.1.11.47:15151/svrestart?args=wss
エンドポイントを実行するには、ウィンドウの左側にあるナビゲーションバーから
ページに移動する必要があります。また、<end- point>?usage=true のように任意のホストで POST コマンドを実行して、エクスプローラページで各エンドポイントの概要を表示することもできます。
例:makecurrent?usage=true
エンドポイント |
説明 |
---|---|
bm_details |
|
endpoints |
|
メンバー |
|
port2cimc |
|
status |
|
vm_info |
|
エンドポイント |
説明 |
---|---|
bm_shutdown_or_reboot |
|
cat |
|
cimc_password_random |
|
cleancmdlogs |
|
clear_sel |
|
cluster_fw_upgrade |
|
cluster_fw_upgrade_status |
|
cluster_powerdown |
|
collector_status |
|
consul_kv_export |
|
consul_kv_recurse |
|
df |
|
dig |
|
dmesg |
|
dmidecode |
|
druid_coordinator_v1 |
|
du |
|
dusorted |
|
externalize_change_tunnel |
|
externalize_mgmt |
|
externalize_mgmt_read_only_password |
|
fsck |
|
get_cimc_techsupport |
|
syslog_endpoints |
|
grep |
|
hadoopbalancer |
|
hadoopdu |
|
hadoopfsck |
|
hadoopls |
|
hbasehbck |
|
hdfs_safe_state_recover |
|
initctl |
|
head |
|
internal_haproxy_status |
|
ip |
|
ipmifru |
|
ipmilan |
|
ipmisel |
|
ipmisensorlist |
|
jstack |
|
ls |
|
lshw |
|
lsof |
|
lvdisplay |
|
lvs |
|
lvscan |
|
makecurrent |
|
mongo_rs_status |
|
mongo_stats |
|
mongodump |
|
monit |
|
namenode_jmx |
|
ndisc6 |
|
netstat |
|
ntpq |
|
orch_reset |
|
orch_stop |
|
ping |
|
ping6 |
|
ps |
|
pv |
|
pvs |
|
pvdisplay |
|
rdisc6 |
|
rebootnode |
|
recover_rpmdb |
|
recoverhbase |
|
recovervm |
|
restartservices |
|
runsigned |
|
service |
|
smartctl |
|
storcli |
|
sudocat |
|
sudogrep |
|
sudohead |
|
sudols |
/var/log または /local/logs |
sudotail |
/var/log または /local/logs |
sudozgrep |
|
sudozcat |
|
svrestart |
|
svstatus |
|
switchinfo |
|
switch_namenode |
|
switch_secondarynamenode |
|
switch_yarn |
|
tail |
|
toggle_chassis_locator |
|
tnp_agent_logs |
|
tnp_datastream |
|
ui_haproxy_status |
|
uptime |
|
userapps_kill |
|
vgdisplay |
|
vgs |
|
vmfs |
|
vminfo |
|
vmlist |
|
vmreboot |
|
vmshutdown |
|
vmstart |
|
vmstop |
|
yarnkill |
|
yarnlogs |
|
zcat |
|
zgrep |
|
サーバーのメンテナンスには、故障したサーバーコンポーネント(ハードディスク、メモリなど)の交換、またはサーバー自体の交換が含まれます。
(注) |
クラスタ上にメンテナンスが必要なサーバーが複数ある場合は、一度に 1 つずつサーバーのメンテナンスを実行します。複数のサーバーを同時にデコミッションすると、データが失われる可能性があります。 |
[クラスタステータス(Cluster Status)] ページ(左側のナビゲーションバーの [トラブルシュート(Troubleshoot)] メニューからアクセス)を使用して、サーバーのメンテナンスに関連するすべての手順を実行します。このページにはすべてのユーザーがアクセスできますが、アクションを実行できるのはカスタマーサポートユーザーのみです。このページには、Cisco Secure Workload ラック内のすべての物理サーバーのステータスが表示されます。
サーバーまたはコンポーネントの交換に関連する手順
メンテナンスが必要なサーバーの判断:[クラスタステータス(Cluster Status)] ページで、サーバーの [シリアル(Serial)] 番号またはサーバーが接続されている [スイッチポート(Switchport)] を使用して判断します。交換するサーバーの CIMC IP を書き留めます。CIMC IP は、[クラスタステータス(Cluster Status )] ページのサーバーボックスに表示されます。
特別な VM のアクションの確認:サーバーボックスから、サーバーに存在する VM またはインスタンスを見つけ、それらの VM に対して特別なアクションを実行する必要があるか確認します。次のセクションに、サーバーメンテナンス中の VM のアクションが一覧表示されています。
サーバーのデコミッション:デコミッション前のアクションが実行されたら、[クラスタステータス(Cluster Status)] ページを使用してサーバーをデコミッションします。サーバーに障害が発生し、ページに [非アクティブ(Inactive)] と表示された場合でも、サーバーのメンテナンス手順をすべて実行する必要があります。サーバーの電源がオフの場合でも、デコミッション手順を実行できます。
サーバーのメンテナンスの実行:[クラスタステータス(Cluster Status)] ページでノードが [デコミッション済み(Decommissioned)] とマークされたら、VM に対してデコミッション後の特別なアクションを実行します。これで、コンポーネントまたはサーバーを交換できます。サーバー全体を交換する場合は、新しいサーバーの CIMC IP を、交換したサーバーと同じ CIMC IP に変更します。各サーバーの CIMC IP は、[クラスタステータス(Cluster Status)] ページで確認できます。
コンポーネント交換後の再イメージ化:[クラスタステータス(Cluster Status)] ページを使用して、コンポーネント交換後にサーバーを再イメージ化します。再イメージ化には約 30 分かかり、サーバーへの CIMC アクセスが必要です。再イメージ化が完了したサーバーは [新規(NEW)] とマークされます。
サーバー全体の交換:サーバー全体を交換した場合、そのサーバーは [クラスタステータス(Cluster Status)] ページに [新規(NEW)] 状態で表示されます。サーバーのソフトウェアバージョンは、同じページで確認できます。ソフトウェアバージョンがクラスタのソフトウェアバージョンと異なる場合は、サーバーを再イメージ化します。
サーバーのコミッション:サーバーが [新規(NEW)] とマークされたら、[クラスタステータス(Cluster Status)] ページからノードのコミッショニングを開始できます。この手順により、サーバー上に VM がプロビジョニングされます。サーバーのコミッショニングには約 45 分かかります。コミッショニングが完了すると、サーバーは [コミッション済み(Commissioned)] とマークされます。
サーバーメンテナンス中の VM のアクション
一部の VM では、サーバーのメンテナンス手順中に特別なアクションを実行する必要があります。それらのアクションは、デコミッション前、デコミッション後、またはコミッション後に実行できます。
オーケストレータのプライマリ:これはデコミッション前のアクションです。メンテナンス中のサーバーにプライマリオーケストレータがある場合は、デコミッションする前に探索ページから orchestrator.service.consul に orch_stop コマンドを POST します。これで、プライマリオーケストレータが切り替わります。
プライマリオーケストレータでサーバーをデコミッションしようとすると、次のエラーが表示されます。
オーケストレータのプライマリを特定するには、任意のホストで explore コマンド「primaryorchestrator」を実行します。
NameNode:メンテナンス中のサーバーに NameNode VM がある場合は、デコミッション後に探索ページから orchestrator.service.consul に switch_namenode を POST し、コミッション後に orchestrator.service.consul に switch_namenode を POST します。これらは、デコミッション後とコミッション後のアクションです。
セカンダリ NameNode:メンテナンス中のサーバーにセカンダリ NameNode VM がある場合、デコミッション後に探索ページから orchestrator.service.consul に switch_secondarynamenode を POST し、コミッション後に orchestrator.service.consul に switch_secondarynamenode を POST します。これらは、デコミッション後とコミッション後のアクションです。
Resource Manager プライマリ:メンテナンス中のサーバーに Resource Manager プライマリがある場合、探索ページから orchestrator.service.consul に switch_yarn を POST します。これらは、デコミッション後とコミッション後のアクションです。
DataNode:クラスタは、一度に 1 つの DataNode 障害のみを許容します。DataNode VM を持つ複数のサーバーにメンテナンスが必要な場合は、一度に 1 つずつサーバーのメンテナンスを実行します。各サーバーのメンテナンス後、[モニタリング(Monitoring)] | [hawkeye] | [hdfs-monitoring] | [健全性情報のブロック(Block Sanity Info)] の下に表示されるチャートの [欠落ブロック数(Missing blocks)] および [レプリケーション中(Under replicated)] の数が 0 になるのを待ちます。
サーバーメンテナンスのトラブルシューティング
ログ:サーバーのメンテナンスログはすべて、オーケストレータログの一部で、orchestrator.service.consul の /local/logs/tetration/orchestrator/orchestrator.log にあります。
デコミッション:
この手順により、サーバー上の VM またはインスタンスが削除されます。
次に、バックエンド consul テーブル内にある削除されたインスタンスのエントリが削除されます。
この手順は約 5 分かかります。
完了すると、サーバーは [デコミッション済み(Decommissioned)] とマークされます。
(注) |
デコミッションされても、サーバーの電源がオフになるわけではありません。デコミッションでは、サーバー上の Secure Workload コンテンツのみ削除されます。 |
電源がオフになっているサーバーは [非アクティブ(Inactive)] とマークされます。このサーバーのデコミッションは、[クラスタステータス(Cluster Status)] ページから引き続き実行できます。ただし、サーバーの電源がオフになっているため、VM の削除手順は実行されないため、このサーバーがデコミッション状態でクラスタに再び参加しないようにしてください。サーバーは再イメージ化してクラスタに追加し直す必要があります。
再イメージ化:
この手順では、サーバーに Secure Workload ベース OS またはハイパーバイザ OS をインストールします。
また、ハードドライブをフォーマットし、サーバーにいくつかの Secure Workload ライブラリをインストールします。
再イメージ化では、mjolnir というスクリプトを実行して、サーバーのイメージングが開始されます。mjolnir の実行には約 5 分かかり、その後、実際のイメージングが開始されます。イメージングには約 30 分かかります。イメージング中のログは、再イメージ化されているサーバーのコンソールでのみ確認できます。ユーザーは、ta_dev キーを使用して、再イメージ化に関する追加情報を確認できます。PXE ブート時の /var/log/nginx ログ、DHCP IP および PXE ブート構成を確認するための /var/log/messages などがあります。
再イメージ化には、オーケストレータからの CIMC 接続が必要です。CIMC の接続を確認する最も簡単な方法は、探索ページを使用するか、orchestrator.service.consul から ping?args=<cimc ip> を POST する方法です。サーバーを交換した場合は、CIMC IP を変更し、CIMC パスワードをデフォルトのパスワードに設定することを忘れないでください。
また、スイッチが正しいルートで設定されるように、クラスタの展開時に CIMC ネットワークがサイト情報に設定されている必要があります。クラスタ CIMC 接続が正しく設定されていない場合、オーケストレータログに次の結果が表示されます。
コミッション:
コミッショニングでは、サーバー上の VM がスケジュールされ、VM でプレイブックを実行して Secure Workload ソフトウェアがインストールされます。
コミッショニングが完了するまでに約 45 分かかります。
ワークフローは、展開またはアップグレードのワークフローと同様です。
ログには、コミッショニング中の障害が示されます。
[クラスタステータス(Cluster Status)] ページのサーバーは、コミッショニング中は [初期化済み(Initialized)] としてマークされ、手順完了後にのみ [コミッション済み(Commissioned)] としてマークされます。
電源シャットダウン後のクラスタの再起動時にハードウェア障害が検出された場合、現在のところ、サービスを安定させるための再起動ワークフローの実行も、コミッションワークフローの実行もできない(サービスが停止するとコミッションが失敗するため)状態でクラスタがスタックします。この機能は、このようなシナリオで役立つことが期待されており、ユーザーは障害のあるハードウェアで再起動(アップグレード)でき、その後、失敗したベアメタルの通常の RMA プロセスを実行できます。
ユーザーは、POST を使用して、除外するベアメタルのシリアルでエンドポイントを探索する必要があります。
アクション:POST
ホスト:orchestrator.service.consul
エンドポイント:exclude_bms?method=POST
本文:{“baremetal”:[“BMSERIAL”]}
オーケストレータは、除外が実行可能か判断するためにいくつかのチェックを実行します。この場合、オーケストレータはいくつかの consul キーをセットアップし、次の再起動またはアップグレードワークフローで除外されるベアメタルと VM を示す成功メッセージを返します。ベアメタルに特定の VM が含まれている場合、それらの VM は除外できません(以下の「制限事項」セクションを参照)。探索エンドポイントは、除外できない理由を示すメッセージで応答します。探索エンドポイントでの POST が成功すると、ユーザーはメイン UI から再起動またはアップグレードを開始し、通常どおり再起動を続行できます。アップグレードの最後に、除外 BM リストを削除します。BM を除外してアップグレードまたは再起動を再度実行する必要がある場合、ユーザーは bmexclude 探索エンドポイントに再度 POST する必要があります。
制限事項:現在、次の VM は除外できません。1. namenode 2. secondaryNamenode 3. mon- godb 4. mongodbArbiter
ディスクメンテナンスには、サーバーから障害のあるハードディスクを交換することが含まれます。オーケストレータは、クラスタ内のすべてのサーバーで bmmgr によって報告されるディスクの状態を監視します。障害のあるディスクが検出された場合、[クラスタステータス(Cluster Status)] ページ(左側のナビゲーションバーの [トラブルシューティング(Troubleshoot)] メニューからアクセスできます)のバナーにそれが示されます。このバナーには、異常(UNHEALTHY)状態のディスクの数が表示されます。そのバナーでこちらをクリックすると、ディスク交換ウィザードが表示され、ディスクメンテナンスのすべての手順を実行することができます。[クラスタステータス(Cluster Status)] ページと同様に、ディスク交換ページにはすべてのユーザーがアクセスできますが、アクションを実行できるのはカスタマー サポート ユーザーのみです。
ディスク交換ウィザードのランディングページには、障害が発生したディスクの詳細が表示されます。これらの詳細には、交換が必要なすべてのディスクのサイズ、タイプ、製造元、およびモデルが含まれます。また、スロット ID も表示され、これらの各ディスクを使用するすべての VM が一覧表示されます。交換プロセスを開始する前に、交換用ディスクを用意しておく必要があります。
クラスタでは、ハードディスクには次の 6 つの状態があります。正常(HEALTHY)、異常(UNHEALTHY)、未使用(UNUSED)、交換済み(REPLACED)、新規(NEW)、初期化済み(INITIALIZED)。展開/アップグレード後のクラスタ内のすべてのディスクのステータスは正常(HEALTHY)です。さまざまなエラーが検出され、1 つ以上のディスクのステータスが異常(UNHEALTHY)になることがあります。
ディスク交換プロセスの最初のステップは、デコミッションです。この手順では、これらのディスクを使用するすべての仮想マシンをクラスタから削除します。デコミッションされたディスクのステータスは未使用(UNUSED)になります。デコミッション後、交換用ディスクを適切なスロットに挿入する必要があります。ディスクが交換されたことをユーザーが確認します。これは、新しくインストールされたディスクを再設定するためのバックエンド信号になります。するとステータスが交換済み(REPLACED)に変わり、次のハードウェアスキャン後に、これらの交換されたディスクのステータスが新規(NEW)に変わります。この移行には 2 ~ 3 分かかることがあります。
すべてのディスクを交換して再設定したら、コミッショニングに進み、デコミッションプロセスの一部として削除されたすべての VM を展開します。コミッションが開始されると、ディスクのステータスが初期化済み(INITIALIZED)に変わります。コミッションが成功すると、すべてのディスクのステータスが正常(HEALTHY)になります。このステップで失敗すると、ステータスは再び異常(UNHEALTHY)になり、デコミッションからの回復を再度開始することになります。
デコミッションまたはコミッションの手順を実行する前に、要件の事前チェックを実行する必要があります。バックエンドでさまざまなチェックが実行されますが、ユーザーがデコミッションまたはコミッションのステップに進む前に、これらのチェックすべてに合格する必要があります。失敗したチェックは、失敗の詳細と推奨される修正処置とともにディスク交換ウィザードで報告されます。必要な手順を続行する前にこれらの修正処置を実行する必要があります。
こうした事前チェックの例は次のとおりです。namenode と secondaryNamenode を一緒にデコミッションすることはできません。一度にデコミッションできるデータノードは 1 つだけです。 namenode はコミッション前に正常でなければなりません。
ユーザーは、障害が発生したディスクの任意のセットをまとめてデコミッションするために選択し、デコミッションの事前チェックを開始できます。障害が発生したディスクのセットを変更するには、事前チェックを再実行する必要があります。タスク(デコミッション/コミッション)を開始する前に、同じ事前チェックを再度行って、最後の事前チェックの実行からデコミッションタスクの開始までの間に新しい事前チェックの失敗がないことを確認します。
事前チェックが失敗した場合、失敗メッセージをクリックすると詳細メッセージが表示され、ポインターを赤い十字ボタンの上に置くと、推奨される処置がポップオーバーに表示されます。
事前チェックに合格すると、ユーザーはディスクのデコミッションに進むことができます。デコミッションの進行状況は、ディスク交換ウィザードに表示されます。デコミッションの進行状況が 100% に達すると、デコミッションされたすべてのディスクのステータスが未使用(UNUSED)に変わります。
ディスクのデコミッション後、ユーザーはディスクを物理的に交換する必要があります。このプロセスを支援するために、交換ページにディスクとサーバーのロケーター LED へのアクセス機能を追加しました。サーバーとディスクのロケーター LED をすべてオフにするボタンがあるので、他のプロセスでロケーターがオンのままになっている可能性に対処することができます。
ディスクの物理的な交換は任意の順序で行えますが、再設定は特定のサーバーの最小スロット番号から最大スロット番号の順序で行う必要があります。この順序は、UI とバックエンドの両方に適用されます。UI では、ステータスが未使用(UNUSED)で、スロット番号が最も小さいディスクの交換ボタンがアクティブになります。
すべてのディスクを交換したら、コミッションに進みます。デコミッションと同様に、コミッション転を続行する前に一連の事前チェックを実行する必要があります。
コミッションの進行状況は、ディスクコミッションページで監視します。コミッションが正常に終了すると、すべてのディスクのステータスが正常(HEALTHY)に変わります。
コミッション中の障害からの復旧
VM が再展開された後に障害が発生した場合は、再開(Resume)機能で回復できます。このようなエラーが発生した場合、[コミッションの再開(Resume Commission)] ボタンがディスクコミッションページに表示されます。このボタンをクリックすると、展開後のプレイブックを再起動してコミッションを続行できます。
VM が再展開される前に障害が発生した場合、コミッション中だったディスクのステータスは異常(UNHEALTHY)に変更されます。そのため、交換プロセスは異常(UNHEALTHY)ディスクのデコミッションから再開する必要があります。
コミッション中の追加のディスク障害
ディスクのコミッションの進行中に交換対象のディスク以外のディスクに障害が発生した場合、進行中のコミッションプロセスが成功または失敗した後に、ディスク交換ウィザードにこの障害に関する通知が表示されます。
再開可能な障害が発生した場合、ユーザーは次のステップについて 2 つのオプションから選択することができます。
現在のコミッションを再開および完了してから、新しい障害に対するディスク交換プロセスの実行を試みます。
または、新しく故障したディスクのデコミッションを開始し、すべてのディスクのコミッションをまとめて実行します。
この 2 番目の方法は、再開不可能な障害が発生した場合に使用できる唯一の方法です。新しく障害が発生したディスクが原因で展開後に障害が発生した場合、再開ボタンは使用できますが、その場合でも 2 番目の方法が唯一の対処方法になります。
ログ
すべてのディスクコミッション/デコミッションログは、オーケストレータログの一部です。デバッグの開始ポイントは、orchestrator.service.consul の /local/logs/tetration/orchestrator/orchestrator.log である必要があります。
ディスクの交換/再設定アクション中に発生した障害の詳細は、対象のサーバーの bmmgr ログで探すことができます。サーバー上のログの場所は、/local/logs/tetration/bmmgr/bmmgr.log になります。
制限事項
サーバーのルートボリュームを含むディスクは、この手順では交換できません。このようなディスク障害は、サーバー メンテナンス プロセスを使用して修正する必要があります。
ディスクのコミッションは、すべてのサーバーがアクティブで、コミッション済みの状態にある場合にのみ実行できます。ディスクとサーバーの交換を組み合わせることが必要な場合の対応方法については、以下の特別な対処方法のセクションを参照してください。
ディスクとサーバーをまとめて交換する
ディスクとサーバーを同時にコミッションする必要がある障害シナリオでは、ユーザーは、デコミッション可能なすべてのディスクをデコミッションして交換する必要があります。事前チェックで以下ことが確認されるため、これらのディスクをコミッションすることはできません。
すべての正常でないディスクのステータスが新規(NEW)であること。
すべてのサーバーのステータスがアクティブで、コミッション済みの状態であること。
すべての異常(UNHEALTHY)ディスクが新規(NEW)状態になると、障害の発生したサーバーは、サーバーメンテナンス手順を使用してデコミッション/再イメージ化/再コミッションさせることが期待されます。
これで、ステータスが正常(HEALTHY)または新規(NEW)でないディスクがある場合、サーバーのコミッションが防止されます。サーバーのコミッションが成功すると、すべてのディスクのステータスも正常(HEALTHY)になります。
このセクションでは、クラスタ全体に影響を及ぼす 2 つのメンテナンス操作について説明します。
クラスターのシャットダウン
クラスターの再起動
クラスタのシャットダウンでは、実行中のすべての Secure Workload プロセスを停止させ、個々のノードの電源をすべてダウンさせます。以下の手順でシャットダウンを実行してください。
ステップ 1 |
ウィンドウの左側にあるナビゲーションバーから、 をクリックします。 |
ステップ 2 |
[再起動/シャットダウン(Reboot/Shutdown)] タブをクリックします。 |
ステップ 3 |
[シャットダウン(Shutdown)] オプションボタンを選択し、[シャットダウンリンクの送信(Send Shutdown Link)] をクリックします。クリックすると、以下に示すように、電子メールでシャットダウンリンクが送信されます。シャットダウンリンクは、リンクを要求しているユーザーの電子メールアドレスに配信されます。 |
ステップ 4 |
[クラスタシャットダウン(Cluster Shutdown)] ページの赤い [シャットダウン(Shutdown)] ボタンをクリックして、シャットダウンを開始します。重要:このボタンをクリックした後にシャットダウンをキャンセルすることはできません。 |
シャットダウンが開始されると、シャットダウンの進行状況を追跡する進行状況バーがページに表示されます。
最初のシャットダウンの事前チェックでエラーが発生した場合、進行状況バーが赤くなり、エラーの修正後にクリックしてシャットダウンを再開できる再開ボタンが表示されます。
事前チェックが完了すると、VM が停止します。VM が徐々に停止する間、その進行状況がページの下部に表示されます。このページは、アップグレード中の VM 停止のページに似ています。表示されている各フィールドの詳細については、アップグレードのセクションを参照してください。VM の停止には最大 30 分かかる場合があることに注意してください。
最終的に、クラスタを完全にシャットダウンする準備が整うと、進行状況バーが 100% になり、クラスタの電源の安全な切断が可能になる時刻が示されます。その時刻は、以下のスクリーンショットで強調表示されています。
(注) |
進行状況バーに表示される時刻を過ぎるまで、クラスタの電源を切らないでください。 |
シャットダウン後にクラスタを回復するには、ベアメタルの電源をオンにします。個々のベアメタルがすべて起動すると、UI に再びアクセスできるようになります。クラスタにログインした後、クラスタを再起動して、クラスタを再び完全に動作可能な状態にする必要があります。
(注) |
クラスタを再び完全に動作可能な状態にするには、シャットダウン後にクラスタを再起動する必要があります。 |
ステップ 1 |
ウィンドウの左側にあるナビゲーションバーから、 をクリックします。 |
ステップ 2 |
[再起動/シャットダウン(Reboot/Shutdown)] タブをクリックします。 |
ステップ 3 |
[再起動(Reboot)] ラジオボタンを選択し、[再起動リンクを送信(Send Reboot Link)] をクリックします。 再起動リンクは、リンクを要求しているユーザーの電子メールアドレスに送信されます。 Secure Workload サービスの再起動は、制限付きのアップグレード操作を実行します。電子メールの再起動リンクをクリックすると、再起動を開始できるセットアップ UI に移動します。 ここから先の手順はアップグレードと同じです。詳細については、アップグレードセクションを参照してください。 |
シャットダウンと再起動の履歴は、[アップグレード(Upgrade)] ページの [履歴(History)] タブに表示されます(左側のナビゲーションバーから
からアクセスします)。データタップ
管理対象データタップ
(注) |
Cisco Secure Workload は現在、データタップ用に Kafka Broker 0.9.x、0.10.x、1.0.x、1.1.x への書き込みをサポートしています。 |
Secure Workload クラスタからアラートをプッシュするには、ユーザーは設定済みのデータタップを使用する必要があります。データタップ管理ユーザーは、新規または既存のデータタップを設定およびアクティブ化できる唯一のユーザーです。ユーザーは、自分の [テナント(Tenant)] に属するデータタップのみを表示できます。
データタップを管理するには、ウィンドウの左側にあるナビゲーションバーで
をクリックします。推奨される Kafka 設定
Kafka クラスタを設定する際は、Secure Workload では 9092、9093 または 9094 以降のポートの使用が推奨されます。これらのポートは Secure Workload が Kafka の発信トラフィック用に開くポートであるためです。Kafka Broker の推奨設定は次のとおりです。
broker.id=<incremental number based on the size of the cluster>
auto.create.topics.enable=true
delete.topic.enable=true
listeners=PLAINTEXT://:9092
port=9092
default.replication.factor=2
host.name=<your_host_name>
advertised.host.name=<your_adversited_hostname>
num.network.threads=12
num.io.threads=12
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=<directory where logs can be written, ensure that there is sufficient space to hold the kafka journal logs>
num.partitions=72
num.recovery.threads.per.data.dir=1
log.retention.hours=24
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
log.cleaner.enable=false
zookeeper.connect=<address of zookeeper ensemble>
zookeeper.connection.timeout.ms=18000
データタップ管理セクション
[データタップ管理者(Data Tap Admins)] は、
ページに移動して、利用可能なすべてのデータタップを表示および設定できます。データタップは [テナント(Tenant)] ごとに設定されます。新しいデータタップの追加
データタップ管理者は、 をクリックして新しいデータタップを追加できます
(注) |
データタップの値を変更するには、設定を検証する必要があります。 |
データタップの非アクティブ化
データ管理者は、一時的に Secure Workload からメッセージが送信されないように、データタップを非アクティブ化できます。そのデータタップへのメッセージは送信されません。データタップはいつでも再開できます。
データタップの削除
データタップを削除すると、そのアプリケーションに依存するすべての Secure Workload アプリケーション インスタンスが削除されます。たとえば、ユーザーがコンプライアンスアラートを(Secure Workload アプリケーションアラートで)データタップ A に送信するように指定し、管理者がデータタップ A を削除した場合、アラートアプリケーションはデータタップ A をアラート出力対象にしなくなります。
管理対象データタップ(MDT)は、Secure Workload クラスタ内でホストされるデータタップです。認証、暗号化、承認に関しては十分に安全です。MDT との間でメッセージを送受信するには、クライアントを認証する必要があり、ネットワーク経由で送信されるデータは暗号化され、承認されたユーザーのみが Secure Workload MDT との間でメッセージを読み書きできます。 Secure Workload は、UI からダウンロードされるクライアント証明書を提供します。 Secure Workload は Apache Kafka 1.1.0 をメッセージブローカとして使用し、クライアントに同じバージョンと互換性のある安全なクライアントの使用を推奨します。
MDT はルート範囲の作成時に自動的に作成されます。すべてのルート範囲には、作成されたアラート MDT があります。ユーザーは Secure Workload クラスタからアラートを引き出すためにアラート MDT を使用する必要があります。証明書をダウンロードできるのはデータタップ管理ユーザーのみです。ユーザーは、[ルート範囲(root scope)] に属する MDT のみを表示できます。
すべての Secure Workload アプリケーションアラートはデフォルトで MDT に送信されますが、別のデータタップに変更できます。証明書をダウンロードするには、2 つの選択肢があります。
JKS(Jave キーストア形式)。JKS 形式は Java クライアント向きです。
Certs。通常の証明書は、Go クライアントで簡単に使用できます。
Alerts.jks.tar.gz をダウンロードすると、Secure Workload MDT に接続してメッセージを受信するための情報を含む次のファイルが表示されます。
kafkaBrokerIps.txt:このファイルには、Kafka クライアントが Secure Workload MDT への接続に使用する必要がある IP アドレス文字列が含まれています。
topic.txt:このファイルには、このクライアントによるメッセージの読み取りが可能なトピックが含まれています。トピックは <root_scope_id> のトピック形式です。この root_scope_id は、後で Java クライアントで他のプロパティを設定するときに使用できます。
keystore.jks:Kafka クライアントが以下に示す接続設定で使用するキーストアです。
truststore.jks:Kafka クライアントが以下に示す接続設定で使用するトラストストアです。
passphrase.txt:このファイルには、#3 と #4 で使用するパスワードが含まれています。
キーストアとトラストストアを使用する Consumer.properties(Java クライアント)を設定する際には、次の Kafka 設定を使用する必要があります。
security.protocol=SSL
ssl.truststore.location=<location_of_truststore_downloaded>
ssl.truststore.password=<passphrase_mentioned_in_passphrase.txt>
ssl.keystore.location=<location_of_truststore_downloaded>
ssl.keystore.password=<passphrase_mentioned_in_passphrase.txt>
ssl.key.password=<passphrase_mentioned_in_passphrase.txt>
Java コードで Kafka コンシューマを設定する際には、次の一連のプロパティを使用する必要があります。
Properties props = new Properties();
props.put("bootstrap.servers", brokerList);
props.put("group.id", ConsumerGroup-<root_scope_id>); // root_scope_id is same as mentioned above
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("enable.auto.commit", "true");
props.put("auto.commit.interval.ms", "1000");
props.put("session.timeout.ms", "30000");
props.put("security.protocol", "SSL");
props.put("ssl.truststore.location", "<filepath_to_truststore.jks>");
props.put("ssl.truststore.password", passphrase);
props.put("ssl.keystore.location", <filepath_to_keystore.jks>);
props.put("ssl.keystore.password", passphrase);
props.put("ssl.key.password", passphrase);
props.put("zookeeper.session.timeout.ms", "500");
props.put("zookeeper.sync.time.ms", "250");
props.put("auto.offset.reset", "earliest");
エンドユーザーが証明書を使用する場合は、Sarama Kafka ライブラリを使用している Go クライアントを使用して Secure Workload MDT に接続できます。Alerts.cert.tar.gz をダウンロードすると、次のファイルが表示されます。
kafkaBrokerIps.txt:このファイルには、Kafka クライアントが Secure Workload MDT への接続に使用する必要がある IP アドレス文字列が含まれています。
topic:このファイルには、このクライアントによるメッセージの読み取りが可能なトピックが含まれています。トピックは <root_scope_id> のトピック形式です。この root_scope_id は、後で Java クライアントで他のプロパティを設定するときに使用できます。
KafkaConsumerCA.cert:このファイルには、Kafka コンシューマの証明書が含まれています。
KafkaConsumerPrivateKey.key:このファイルには、Kafka コンシューマの秘密鍵が含まれています。
KafkaCA.cert:このファイルは、Go クライアントの root CA 証明書リストで使用する必要があります。
Secure Workload MDT に接続する Go クライアントの次の例を参照してください。(サンプル Go コードを添付)MDT からのアラートを使用するサンプル Go クライアント