IT インフラストラクチャ サービスまたはビジネス アプリケーションのデプロイは、どの企業にとっても難題です。 適切に実行し、うれしくない驚きや計画外のコストを回避するには、徹底的に計画を立てて可能な限り準備しておく必要があります。 Azure Arc 対応サーバーを任意の規模でデプロイする計画を立てるには、タスクを正常に完了するために満たす必要がある設計とデプロイの基準をカバーする必要があります。
デプロイを円滑に進めるには、計画により、以下のことが明確に理解されるようにする必要があります。
- ロールと責任。
- 物理サーバーまたは仮想マシンがネットワークとシステムの要件を満たしていることを確認するための、それらのインベントリ。
- デプロイと継続的な管理を成功させるために必要なスキル セットとトレーニング。
- 受け入れの基準と、その成功を追跡する方法。
- デプロイを自動化するために使用するツールまたは方法。
- 遅延や中断などを避けるために特定済みのリスクと軽減策の一覧。
- デプロイ中に中断を回避する計画。
- 重要な問題が発生したときのエスカレーション パス。
この記事は、環境内の複数の実稼働物理サーバーまたは仮想マシンに Azure Arc 対応サーバーを正常にデプロイするための準備を行う際に役立ちます。
また、Microsoft の大規模なデプロイに関する推奨事項の詳細については、こちらのビデオも参照してください。
前提条件
デプロイを計画するときは、次の基本的な要件を考慮してください。
- Connected Machine Agent でサポートされているオペレーティング システムが、お使いのマシンで実行されている必要があります。
- お使いのマシンが、オンプレミスのネットワークまたはその他のクラウド環境から、直接またはプロキシ サーバーを介して Azure 内のリソースに接続できる必要があります。
- Azure Connected Machine Agent をインストールして構成するには、マシンに昇格された特権 (つまり、管理者またはルート) を持つアカウントが必要です。
- マシンをオンボードするには、Azure Connected Machine Onboardingという Azure 組み込みロールを持っている必要があります。
- マシンの読み取り、変更、削除を行うには、Azure Connected Machine リソース管理者の Azure 組み込みロールを持っている必要があります。
詳細については、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 ワークスペースを使用するか、または別の Log Analytics ワークスペースを実装すべきかを決定します。 | 1 日 |
| Azure Policy ガバナンス計画を作成する | Azure Policy を使用して、サブスクリプションまたはリソース グループのスコープでハイブリッド サーバーとマシンのガバナンスを実装する方法を決定します。 | 1 日 |
| ロールベースのアクセス制御 (RBAC) を構成する | Azure Arc 対応サーバーを管理するためのアクセスと、他の Azure サービスやソリューションからのデータを表示する機能を、誰が持つかを制御するアクセス計画を作成します。 | 1 日 |
| Azure Monitor エージェント エージェントが既にインストールされているマシンを特定する | Log Analytics で次のログ クエリを実行して、既存の Azure Monitor エージェント のデプロイから拡張機能マネージド エージェントへの変換をサポートします。 心拍 | summarize arg_max(TimeGenerated, OSType, ResourceId, ComputerEnvironment) by Computer | where ComputerEnvironment == "Non-Azure" and isempty(ResourceId) | project Computer, OSType |
1 時間 |
フェーズ 2: Azure Arc 対応サーバーをデプロイする
次に、Azure Connected Machine Agent を準備してデプロイすることで、フェーズ 1 で準備した基盤に追加します。
| タスク | 詳細 | 推定所要時間 |
|---|---|---|
| 定義済みのインストール スクリプトをダウンロードする | 自動デプロイ要件をサポートするために、Connected Machine エージェントの大規模なデプロイ用の定義済みインストール スクリプトを確認してカスタマイズします。 大規模なオンボーディングリソースの例:
|
要件、組織のプロセス (変更およびリリース管理など)、使用されたオートメーションの方法に応じて 1 日以上。 |
| サービス プリンシパルを作成する | サービス プリンシパルを作成し、Azure PowerShell を使用して、またはポータルから、非対話形式でコンピューターを接続します。 | 1 時間 |
| ターゲットのサーバーとマシンに Connected Machine エージェントをデプロイする | オートメーション ツールを使用してスクリプトをサーバーにデプロイし、サーバーを Azure に接続します。 | リリース計画と、段階的ロールアウトを行うかどうかに応じて 1 日以上。 |
フェーズ 3: 管理して運用する
フェーズ 3 では、管理者またはシステム エンジニアが、Connected Machine エージェントとマシンをそれらのライフサイクル中に管理し、運用するための手動タスクのオートメーションを有効にできます。
| タスク | 詳細 | 推定所要時間 |
|---|---|---|
| Resource Health アラートを作成する | サーバーが 15 分を超えて Azure へのハートビートの送信を停止した場合、サーバーがオフラインであるか、ネットワーク接続がブロックされているか、エージェントが実行されていないことを意味する可能性があります。 これらのインシデントに対応して調査し、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 サービスを使用してデプロイを簡略化する方法について説明します。