みなさん、こんにちは。クラウドアーキテクトの椎熊です。
前回のブログでは、Azure Lighthouse の概要およびデプロイ方法についてご紹介しました。
今回は、Lighthouse の活用シナリオということで、Azure Monitor などでどのような使い方ができるか、実際の画面と一緒にご紹介します。
Azure Lighthouse を使うと、Azure リソースの管理を委任することができます。
委任された側では、サブスクリプション切り替えることなく、委任元のテナントのリソースを一元管理することができるようになりますので、マルチテナント環境における操作性が向上します。
Lighthouse と連携できるサービスは限られていますが、徐々に増えてきています。
最新の情報は以下を参照ください。
[強化されたサービスとシナリオ]
https://docs.microsoft.com/ja-jp/azure/lighthouse/concepts/cross-tenant-management-experience#enhanced-services-and-scenarios
多くの企業様では、運用を委任するケースが多いかと思いますので、本ブログでは、バックアップと監視の 2つのシナリオについてご紹介します。
Lighthouse を利用して Azure Backup (Recovery Services コンテナー) の画面を確認してみると、サブスクリプション列があり、対象のサブスクリプションを確認することができます。
自社テナントのサブスクリプション：sbt-cag-azure
委任されたテナントのサブスクリプション：sbt-cag-azure2
一覧画面では、テナント名を確認することができませんが、サブスクリプションのフィルターを選択するとテナントとサブスクリプションの紐づけを確認することができます。
効率的な管理を行うために、Azure Backup では以下の 2つのツールが提供されています。
どちらのツールも Lighthouse を使っていないシングルテナント環境においても利用可能ですが、Lighthouse と連携することで、マルチテナント環境に対応することができ、自社テナントおよび委任されたテナントの Azure Backup の管理に使用することができます。
実際の画面と一緒にご紹介します。
VM のバックアップの状態や、バックアップジョブのステータスなどを確認することができます。
任意の Recovery Services コンテナーを選択し、[概要] - [バックアップ エクスプローラー] を選択し、バックアップ エクスプローラーを開きます。
この画面では、下記の項目をサマリーとして表示することができます。
項目は各タブと対応しており、対応するタブを選択することで詳細な情報を確認することができます。
例えば、以下の画面では、バックアップが有効になっている VM が 3台あり、バックアップジョブが 3つ、過去 24時間以内にバックアップのアラートが発生していないということが確認できます。
すべての VM のバックアップの状態をこの画面 1つで把握することができます。
[Subscriptions] を選択すると、対象サブスクリプションを選択することができます。
既定では [すべて] となっているので、自社テナントおよび委任されたテナントのサブスクリプションすべての Azure Backup が表示されています。
対象のサブスクリプションを選択することで、任意のサブスクリプションのリソースを確認することができます。
[バックアップ項目] を選択すると、バックアップが有効になっている VM の一覧が表示されます。
一覧表示では、サブスクリプションを識別する列はありませんので、まとめ画面と同様に [Subscriptions] のフィルターで絞り込む、または、[コンテナー] に表示された値を選択すると、対象の Recovery Services コンテナーに移動することができます。
[ジョブ] を選択すると、バックアップジョブの一覧が表示されます。
既定では、[Status] フィルターが [Failed] になっていますので、[All] を選択するとすべてのバックアップジョブの状態を確認することができます。
[警告] を選択すると、バックアップ アラートが表示されます。
この環境では特にアラートが発生していないため、何も表示されませんでした。
[ポリシー] を選択すると、バックアップポリシーが表示されます。 [保護された項目] にバックアップポリシーを利用している VM の台数が表示されます。表示がないものは利用されていないバックアップ ポリシーということになります。
[有効になっていないバックアップ] を選択すると、バックアップが有効なっていない VM が表示されます。
バックアップ レポートでは、主にバックアップで使っているストレージの使用量が確認できます。
バックアップ レポートを使用するには、Azure Backup の診断ログを Log Analytics ワークスペースに送信するよう設定する必要があります。
設定方法については、以下のドキュメントを参照ください。
[Azure Backup のレポートを構成する]
https://docs.microsoft.com/ja-jp/azure/backup/configure-reports
任意の Recovery Services コンテナーを選択し、[概要] - [バックアップ レポート] を選択し、バックアップ レポートを開きます。
[Workspaces] で対象のワークスペースを選択します。
[まとめ] を選択すると、選択されたサブスクリプションのバックアップアイテム数およびバックアップで使用しているストレージの総容量などが確認できます。
[バックアップ項目] を選択すると、バックアップが有効な VM 数が確認できます。
下にスクロールすると、バックアップ項目数とストレージ使用容量の推移が確認できます。
更にスクロールしますと、VM ごとのストレージ使用容量が確認できます。
Azure Monitor では、委任されたテナントの Log Analytics に接続し、アクティビティログ、アラート、メトリック、ログなどを確認することができます。
[アクティビティログ] を選択すると、すべてのサブスクリプションのアクティビティログが表示されます。
サブスクリプション列があり、対象のサブスクリプションを確認することができます。
[アラート] を選択すると、すべてのサブスクリプションのアラートのサマリーが表示され、重要度ごとのアラート合計数が確認できます。
重要度 [Sev 3] を選択します。
Sev 3 のアラートが一覧表示され、一番右の列にサブスクリプション名で、どこのサブスクリプションでアラートが発生したか確認することができます。
[メトリック] を選択すると、スコープを選ぶ画面が表示されます。
単一のリソースを選択する必要があり、複数のサブスクリプションを選択することができませんでした。
いまのところ、すべてのサブスクリプションの VM のメトリックを 1 画面で確認するということはできません。
メトリックについては、対象のサブスクリプションおよびリソースを選択して、確認する必要がありますが、委任されたテナントのサブスクリプションに切り替えて Azure Monitor を表示するほどの手間ではないかと思います。
[ログ] を選択すると、クエリエディタが表示されます。
委任されたテナントのログを検索するためには、[ログ] – [スコープを選択する] を選択します。
すべてのサブスクリプションを選択し、[適用] を選択します。
スコープとしてすべてのサブスクリプションを選択しているため、閲覧権限を持っている Log Analytics のログがすべて表示されます。 一例として、アクティビティログを検索してみます。 以下のクエリでは、サブスクリプションごとのログ数を表示しています。
委任されたテナントのログが表示されていることが確認できます。
アクティビティログについては、サブスクリプション ID で検索することができますが、パフォーマンス (Pef) などの一部のテーブルでは、サブスクリプション ID が含まれない場合がありますので、特定のサブスクリプションを絞って検索する場合は、スコープで特定のサブスクリプションを選択して検索する形が良いかと思います。
[アプリケーション] を選択すると、すべてのサブスクリプションの Application Insight の一覧が表示されます。
[名前] を選択すると対象の Application Insight に移動することができます。
[仮想マシン] を選択すると、Azure Monitor for VMs が有効になっている仮想マシンが表示されます。
[パフォーマンス] を選択すると、選択されたサブスクリプション内にある、VM の CPU や使用可能なメモリ容量などを確認することができます。
すべてのサブスクリプションの VM は表示することはできないので、サブスクリプションのフィルターで対象のサブスクリプションを選択し、切り替える必要があります。
Lighthouse で委任をするだけで、他に追加の設定は必要なく、マルチテナント環境にまたがるリソースを確認できることがわかりました。
実際の画面を見てみることで、なんとなく使用イメージを掴んでいただけたかと思います。
日々の監視や管理、また、あるイベントが発生した際、特定のテナント固有の問題なのか、それとも Azure 全体の問題なのかという切り分けが楽になりそうですね。
今後、マルチテナント管理において、Lighthouse は必須とも言えるのではないでしょうか。
マルチテナント管理に課題を持たれている方の参考となれば幸いです。
関連ページ |
