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