Azure Arc 対応サーバーを計画およびデプロイする

IT インフラストラクチャ サービスまたはビジネス アプリケーションのデプロイは、どの企業にとっても難題です。 適切に実行し、うれしくない驚きや計画外のコストを回避するには、徹底的に計画を立てて可能な限り準備しておく必要があります。 Azure Arc 対応サーバーのデプロイを計画するには、その規模を問わず、タスクを適切に完了するために満たす必要がある、設計とデプロイの条件を網羅する必要があります。

デプロイを円滑に進めるには、計画により、以下のことが明確に理解されるようにする必要があります。

  • ロールと責任。
  • 物理サーバーまたは仮想マシンがネットワークとシステムの要件を満たしていることを確認するための、それらのインベントリ。
  • デプロイと継続的な管理の成功を実現するために必要なスキル セットとトレーニング。
  • 受け入れの基準と、その成功を追跡する方法。
  • デプロイを自動化するために使用するツールまたは方法。
  • 遅延や中断などを避けるために特定済みのリスクと軽減策。
  • デプロイ中に中断を回避する方法。
  • 重要な問題が発生したときにどのようなエスカレーション パスがあるか。

この記事の目的は、環境内の複数の運用物理サーバーまたは仮想マシンの全体にわたって Azure Arc 対応サーバーのデプロイを成功させるための準備を、確実に行うことです。

また、Microsoft の大規模なデプロイに関する推奨事項の詳細については、こちらのビデオも参照してください。

前提条件

  • お使いのマシンで、Connected Machine エージェントでサポートされているオペレーティング システムが実行されていること。
  • お使いのマシンが、オンプレミスのネットワークまたはその他のクラウド環境から、直接またはプロキシ サーバーを介して Azure 内のリソースに接続できること。
  • Azure Arc 対応サーバーの Connected Machine エージェントをインストールして構成するための、マシンでの昇格された (つまり、管理者またはルートとしての) 特権を持つアカウント。
  • マシンをオンボードするには、Azure Connected Machine のオンボード ロールのメンバーである必要があります。
  • マシンの読み取り、変更、および削除を行うには、Azure Connected Machine のリソース管理者 ロールのメンバーである必要があります。

パイロット

すべての運用マシンへのデプロイを行う前に、このデプロイ プロセスを評価することから開始し、その後、環境内でそのプロセスを広く採用します。 パイロットの場合は、ビジネスを遂行する会社の機能にとって重要でないマシンの代表的なサンプリングを特定します。 パイロットを実行し、その影響を評価するのに十分な時間を確保することをお勧めします。Microsoft では、少なくとも 30 日をお勧めします。

パイロットの範囲と詳細を説明する正式な計画を立てます。 作業の開始に役立つように、次のサンプルに、計画に何を含める必要があるかを示します。

  • 目標 - パイロットが必要であるという決定に至った、ビジネス上、技術上の決定要因について説明します。
  • 選択条件 - パイロットによって、ソリューションのどのような側面を実証するかを選択するために使用する条件を指定します。
  • 範囲 - パイロットの範囲について説明します。これには、ソリューションのコンポーネント、予想スケジュール、パイロットの期間、対象とするマシンの数などが含まれます。
  • 成功条件とメトリック - パイロットの成功条件と、成功のレベルを判断するために使用される具体的な基準を定義します。
  • トレーニング計画 - パイロット中に、Azure とそのサービスの使用経験がないシステム エンジニアや管理者などをトレーニングするための計画について説明します。
  • 移行計画 - パイロットから運用への移行をガイドするために使用される戦略と条件について説明します。
  • ロールバック - パイロットをデプロイ前の状態にロールバックする手順について説明します。
  • リスク - パイロットの実施と、運用のデプロイに関連する、特定されたすべてのリスクを一覧で示します。

フェーズ 1: 基盤を構築する

このフェーズでは、システム エンジニアまたは管理者が、組織の Azure サブスクリプションでコア機能を有効にして、お使いのマシンで Azure Arc 対応サーバーおよびその他の Azure サービスによる管理を有効にする前に、基盤の構築を開始します。

タスク Detail Duration
リソース グループの作成 Azure Arc 対応サーバーだけを含み、これらのリソースの管理と監視を一元化する専用リソース グループ。 1 時間
マシンの整理に役立つタグを適用する。 Azure Arc 対応サーバーの管理の複雑さを軽減し、管理上の意思決定を簡略化するのに役立つ、IT 面で調整されたタグ付け戦略の評価と作成を行います。 1 日
Azure Monitor ログを設計してデプロイする 設計とデプロイに関する考慮事項を評価して、ハイブリッド サーバーとマシンから収集したログ データを格納するために、組織が既存の Log Analytics ワークスペースを使用するか、別の Log Analytics ワークスペースを実装するかを決定します。1 1 日
Azure Policy ガバナンス計画を作成する Azure Policy を使用して、サブスクリプションまたはリソース グループのスコープでハイブリッド サーバーとマシンのガバナンスを実装する方法を決定します。 1 日
ロールベースのアクセス制御 (RBAC) を構成する Azure Arc 対応サーバーを管理するためのアクセスと、他の Azure サービスやソリューションからのデータを表示する機能を、誰が持つかを制御するアクセス計画を作成します。 1 日
Log Analytics エージェントが既にインストールされているマシンを特定する 既存の Log Analytics エージェントのデプロイから、拡張機能で管理されるエージェントへの変換をサポートするため、Log Analytics で次のログクエリを実行します。
Heartbeat
| where TimeGenerated > ago(30d)
| where ResourceType == "machines" and (ComputerEnvironment == "Non-Azure")
| summarize by Computer, ResourceProvider, ResourceType, ComputerEnvironment
1 時間

1 Log Analytics ワークスペースの設計評価の一部としての重要な考慮事項は、Update Management、変更履歴とインベントリ機能のほか、Azure Security Center と Azure Sentinel をサポートする Azure Automation との統合です。 組織に既に Automation アカウントがあり、Log Analytics ワークスペースにリンクされる管理機能が有効になっている場合は、重複するアカウントやワークスペースなどを作成する代わりにそれらの既存のリソースを使用することによって、管理操作を一元化して合理化できるかどうかを評価し、コストを最小限に抑えることができます。

フェーズ 2: Azure Arc 対応サーバーをデプロイする

次に、Azure Arc 対応サーバーの Connected Machine エージェントを準備してデプロイすることで、フェーズ 1 で準備した基盤に追加します。

タスク Detail Duration
定義済みのインストール スクリプトをダウンロードする 自動デプロイの要件をサポートするために、Connected Machine エージェントの大規模なデプロイ用に事前に定義されたインストール スクリプトを見直してカスタマイズします。

大規模なオンボード リソースのサンプル:

要件、組織のプロセス (変更およびリリース管理など)、使用されたオートメーションの方法に応じて 1 日以上。
サービス プリンシパルを作成する サービス プリンシパルを作成し、Azure PowerShell を使用して、またはポータルから、非対話形式でコンピューターを接続します。 1 時間
ターゲットのサーバーとマシンに Connected Machine エージェントをデプロイする オートメーション ツールを使用してスクリプトをサーバーにデプロイし、サーバーを Azure に接続します。 リリース計画と、段階的ロールアウトを行うかどうかに応じて 1 日以上。

フェーズ 3: 管理して運用する

フェーズ 3 では、管理者またはシステム エンジニアが、Connected Machine エージェントとマシンをそれらのライフサイクル中に管理し、運用するための手動タスクのオートメーションを有効にします。

タスク Detail Duration
Resource Health アラートを作成する サーバーが Azure へのハートビートの送信を 15 分より長く停止する場合は、それがオフラインであるか、ネットワーク接続がブロックされているか、エージェントが実行されていないことを意味する可能性があります。 これらのインシデントに対応して調査し、Resource Health アラートを使用してその開始時に通知を受け取る方法の計画を作成します。

アラートの構成時には以下のように指定します。
リソースの種類 = Azure Arc 対応サーバー
現在のリソースの状態 = 使用不可
以前のリソースの状態 = 使用可能
1 時間
Azure Advisor アラートを作成する 優れたエクスペリエンスと最新のセキュリティおよびバグの修正プログラムについては、Azure Arc 対応サーバー エージェントを最新の状態に保つことをお勧めします。 古くなったエージェントは、Azure Advisor アラートで識別されます。

アラートの構成時には以下のように指定します。
推奨の種類 = 最新バージョンの Azure Connected Machine Agent にアップグレードする
1 時間
サブスクリプションまたはリソース グループのスコープに Azure ポリシーを割り当てる Azure Monitor for VMs の有効化 ポリシー (およびニーズに合ったその他のポリシー) をサブスクリプションまたはリソース グループ スコープに割り当てます。 Azure Policy により、お使いの環境全体で VM インサイトに必要なエージェントをインストールするポリシーの定義を割り当てることができます。 場合により異なる
Azure Arc 対応サーバーに対して Update Management を有効にする Azure Automation で Update Management を構成して、Azure Arc 対応サーバーに登録されている Windows と Linux の仮想マシンのオペレーティング システム更新プログラムを管理します。 約 15 分

次のステップ