Azure Arc 対応サーバーを計画およびデプロイする
IT インフラストラクチャ サービスまたはビジネス アプリケーションのデプロイは、どの企業にとっても難題です。 適切に実行し、うれしくない驚きや計画外のコストを回避するには、徹底的に計画を立てて可能な限り準備しておく必要があります。 Azure Arc 対応サーバーのデプロイを計画するには、その規模を問わず、タスクを適切に完了するために満たす必要がある、設計とデプロイの条件を網羅する必要があります。
デプロイを円滑に進めるには、計画により、以下のことが明確に理解されるようにする必要があります。
- ロールと責任。
- 物理サーバーまたは仮想マシンがネットワークとシステムの要件を満たしていることを確認するための、それらのインベントリ。
- デプロイと継続的な管理の成功を実現するために必要なスキル セットとトレーニング。
- 受け入れの基準と、その成功を追跡する方法。
- デプロイを自動化するために使用するツールまたは方法。
- 遅延や中断などを避けるために特定済みのリスクと軽減策の一覧。
- デプロイ中に中断を回避する計画。
- 重要な問題が発生したときのエスカレーション パス。
この記事の目的は、環境内の複数の運用物理サーバーまたは仮想マシンの全体にわたって Azure Arc 対応サーバーのデプロイを成功させるための準備を、確実に行うことです。
また、Microsoft の大規模なデプロイに関する推奨事項の詳細については、こちらのビデオも参照してください。
前提条件
デプロイを計画するときは、次の基本的な要件を考慮してください。
- Connected Machine Agent でサポートされているオペレーティング システムが、お使いのマシンで実行されている必要があります。
- お使いのマシンが、オンプレミスのネットワークまたはその他のクラウド環境から、直接またはプロキシ サーバーを介して Azure 内のリソースに接続できる必要があります。
- Azure Connected Machine Agent をインストールして構成するには、マシンに昇格された特権 (つまり、管理者またはルート) を持つアカウントが必要です。
- マシンをオンボードするには、Azure Connected Machine のオンボードの Azure 組み込みロールを持っている必要があります。
- マシンの読み取り、変更、削除を行うには、Azure Connected Machine リソース管理者の Azure 組み込みロールを持っている必要があります。
詳しくは、Connected Machine Agent のインストールに関する前提条件とネットワーク要件に関するページをご覧ください。
パイロット
すべての運用マシンへのデプロイを行う前に、デプロイ プロセスを評価することから開始し、その後、環境内でそのプロセスを広く採用します。 パイロットの場合は、ビジネスを遂行する会社の機能にとって重要でないマシンの代表的なサンプリングを特定します。 パイロットを実行し、その影響を評価するのに十分な時間を確保することをお勧めします。Microsoft では、少なくとも 30 日をお勧めします。
パイロットの範囲と詳細を説明する正式な計画を立てます。 作業の開始に役立つように、次のサンプルに、計画に何を含める必要があるかを示します。
- 目標 - パイロットが必要であるという決定に至った、ビジネス上、技術上の決定要因について説明します。
- 選択条件 - パイロットによって、ソリューションのどのような側面を実証するかを選択するために使用する条件を指定します。
- 範囲 - パイロットの範囲について説明します。これには、ソリューションのコンポーネント、予想スケジュール、パイロットの期間、対象とするマシンの数などが含まれます。
- 成功条件とメトリック - パイロットの成功条件と、成功のレベルを判断するために使用される具体的な基準を定義します。
- トレーニング計画 - パイロット中に、Azure とそのサービスの使用経験がないシステム エンジニアや管理者などをトレーニングするための計画について説明します。
- 移行計画 - パイロットから運用への移行をガイドするために使用される戦略と条件について説明します。
- ロールバック - パイロットをデプロイ前の状態にロールバックする手順について説明します。
- リスク - パイロットの実施と、運用のデプロイに関連する、特定されたすべてのリスクを一覧で示します。
フェーズ 1: 基盤を構築する
このフェーズでは、システム エンジニアまたは管理者が、組織の Azure サブスクリプションでコア機能を有効にして、マシンで Azure Arc 対応サーバーおよびその他の Azure サービスによる管理を有効にする前に、基盤の構築を開始します。
| タスク | Detail | 推定所要時間 |
|---|---|---|
| リソース グループを作成します | 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 | summarize arg_max(TimeGenerated, OSType, ResourceId, ComputerEnvironment) by Computer | where ComputerEnvironment == "Non-Azure" and isempty(ResourceId) | project Computer, OSType |
1 時間 |
1 Log Analytics ワークスペースの設計を評価するときは、Update Management、変更履歴とインベントリ機能のほか、Microsoft Defender for Cloud と Microsoft Sentinel をサポートする Azure Automation との統合を検討します。 組織に既に Automation アカウントがあり、Log Analytics ワークスペースにリンクされる管理機能が有効になっている場合は、重複するアカウントやワークスペースなどを作成する代わりにそれらの既存のリソースを使用することによって、管理操作を一元化して合理化できるかどうかを評価し、コストを最小限に抑えることができます。
フェーズ 2: Azure Arc 対応サーバーをデプロイする
次に、Azure Connected Machine Agent を準備してデプロイすることで、フェーズ 1 で準備した基盤に追加します。
| タスク | Detail | 推定所要時間 |
|---|---|---|
| 定義済みのインストール スクリプトをダウンロードする | 自動デプロイの要件をサポートするために、Connected Machine エージェントの大規模なデプロイ用に事前に定義されたインストール スクリプトを見直してカスタマイズします。 大規模なオンボード リソースのサンプル:
|
要件、組織のプロセス (変更およびリリース管理など)、使用されたオートメーションの方法に応じて 1 日以上。 |
| サービス プリンシパルを作成する | サービス プリンシパルを作成し、Azure PowerShell を使用して、またはポータルから、非対話形式でコンピューターを接続します。 | 1 時間 |
| ターゲットのサーバーとマシンに Connected Machine エージェントをデプロイする | オートメーション ツールを使用してスクリプトをサーバーにデプロイし、サーバーを Azure に接続します。 | リリース計画と、段階的ロールアウトを行うかどうかに応じて 1 日以上。 |
フェーズ 3: 管理して運用する
フェーズ 3 では、管理者またはシステム エンジニアが、Connected Machine エージェントとマシンをそれらのライフサイクル中に管理し、運用するための手動タスクのオートメーションを有効にできます。
| タスク | Detail | 推定所要時間 |
|---|---|---|
| Resource Health アラートを作成する | サーバーが Azure へのハートビートの送信を 15 分より長く停止する場合は、それがオフラインであるか、ネットワーク接続がブロックされているか、エージェントが実行されていないことを意味する可能性があります。 これらのインシデントに対応して調査し、Resource Health アラートを使用してその開始時に通知を受け取る方法の計画を作成します。 アラートの構成時には以下のように指定します。 リソースの種類 = Azure Arc 対応サーバー 現在のリソースの状態 = 使用不可 以前のリソースの状態 = 使用可能 |
1 時間 |
| Azure Advisor アラートを作成する | 優れたエクスペリエンスと最新のセキュリティおよびバグ修正のために、Azure Connected Machine エージェントを最新の状態に保つことをお勧めします。 古くなったエージェントは、Azure Advisor アラートで識別されます。 アラートの構成時には以下のように指定します。 推奨の種類 = 最新バージョンの Azure Connected Machine Agent にアップグレードする |
1 時間 |
| サブスクリプションまたはリソース グループのスコープに Azure ポリシーを割り当てる | Azure Monitor for VMs の有効化 ポリシー (およびニーズに合ったその他のポリシー) をサブスクリプションまたはリソース グループ スコープに割り当てます。 Azure Policy により、お使いの環境全体で VM インサイトに必要なエージェントをインストールするポリシーの定義を割り当てることができます。 | 可変 |
| Azure Arc 対応サーバーに対して Azure Update Manager を有効にする。 | Arc 対応サーバーで Azure Update Manager を構成して、Windows および Linux の仮想マシンのシステム更新プログラムを管理します。 オンデマンドで更新プログラムをデプロイするか、またはカスタム スケジュールを使用して更新プログラムを適用するかを選択できます。 | 5 分 |
次のステップ
- ハイブリッドおよびマルチクラウド向け Azure Arc ランディング ゾーン アクセラレータによるベスト プラクティスと設計パターンについて説明します。
- Connected Machine エージェントの再構成、アップグレード、および削除について学習する。
- エージェント接続問題のトラブルシューティング ガイドで、トラブルシューティング情報を確認してください。
- Azure Automation の State Configuration や、その他にサポートされている Azure VM 拡張機能のような他の Azure サービスを使用してデプロイを簡略化する方法について説明します。