Azure Cloud Services (クラシック) を Azure Cloud Services (延長サポート) に移行する

[アーティクル]
07/24/2024

このドキュメントでは、Cloud Services (クラシック) を Cloud Services (延長サポート) に移行するための概要について説明します。

Cloud Services (延長サポート) には、Azure Service Manager を使用してデプロイされた Azure Cloud Services との機能パリティと共に、リージョンの回復性を提供するという主な利点があります。また、ロールベースのアクセス制御 (RBAC)、タグ、ポリシーなどのいくつかの Azure Resource Manager 機能も提供され、デプロイテンプレート、プライベートリンクがサポートされています。デプロイモデル (延長サポートとクラシック) はどちらも、同様の価格構造で利用できます。

Cloud Services (延長サポート) では、お客様が Azure Service Manager から Azure Resource Manager に移行するためのパスとして、再デプロイとインプレース移行の 2 つがサポートされています。

次の表は、これら 2 つのオプションを比べたものです。

Redeploy	インプレース移行
顧客は、新しいクラウドサービスを Azure Resource Manager に直接デプロイした後、検証後に Azure Service Manager で古いクラウドサービスを削除できます。	インプレース移行ツールを使用すると、既存のクラウドサービス (クラシック) のデプロイを Cloud Services (延長サポート) にシームレスにプラットフォームで調整して移行できます。
再デプロイすると、顧客は次の操作を行えるようになります。 - リソース名を定義する。 - リソースを優先として整理または再利用する。 - 最小限の変更でサービス構成ファイルと定義ファイルを再利用する。	インプレース移行の場合、プラットフォームでは次の操作を行います。 - リソース名を定義する。 - 各デプロイと関連リソースを個々のリソースグループに整理する。 - Azure Resource Manager の既存の構成および定義ファイルを変更する。
顧客は、新しいデプロイへのトラフィックを調整する必要があります。	移行では IP アドレスが保持され、データパスは変わりません。
顧客は、Azure Resource Manager で古いクラウドサービスを削除する必要があります。	プラットフォームは、移行後に Cloud Services (クラシック) リソースを削除します。
この移行はリフトアンドシフトシナリオであり、柔軟性は増しますが、移行に要する時間が長くなります。	このシナリオは自動移行であり、移行は速くなりますが、柔軟性は低下します。

Cloud Services (クラシック) から Cloud Services (延長サポート) への移行計画を評価する場合は、Virtual Machine Scale Sets、App Service、Azure Kubernetes Service、Azure Service Fabric などのその他の Azure サービスを調査してください。これらのサービスには引き続き他の機能が含まれますが、Cloud Services (延長サポート) では Cloud Services (クラシック) との機能パリティが保たれます。

アプリケーションによっては、Cloud Services (延長サポート) では、Azure Resource Manager に移行するために必要な労力が他のオプションより大幅に少なくなる場合があります。アプリケーションが進化中でない場合、Cloud Services (延長サポート) は迅速な移行パスを提供するため、考慮すべき実行可能なオプションになります。逆に、アプリケーションが継続的に進化しており、より最新の機能セットを必要としている場合は、現在および将来の要件により適切に対処するために他の Azure サービスを調査してください。

再デプロイの概要

Cloud Services (拡張サポート) を使用してサービスを再デプロイすることには、次の利点があります。

[Cloud Services (クラシック) と同様に、Web ロールと worker ロールがサポートされます。
Web および worker ロールの設計、アーキテクチャ、またはコンポーネントに変更はありません。
データプレーンはクラウドサービスと同じであるため、ランタイムコードへの変更は必要ありません。
Azure GuestOS のリリースとそれに関連する更新プログラムは Cloud Services (クラシック) と整合されます。
更新ドメインに関する基になる更新プロセス、アップグレードの処理方法、ロールバック、更新中に許可されるサービスの変更については、変更はありません。

新しい Cloud Service (延長サポート) は、次のクライアントツールを使用して Azure Resource Manager に直接デプロイできます。

移行ツールの概要

プラットフォームによってサポートされた移行には、次のような主な利点があります。

ほとんどのシナリオで、ダウンタイムがなくシームレスな、プラットフォームで調整された移行が可能です。サポートされるシナリオに関する詳細情報を参照してください。
既存のクラウドサービスを、検証、準備、コミット (または中止) の 3 つの簡単な手順で移行します。移行ツールのしくみの詳細を確認してください。
正しく準備した後で移行されるデプロイをテストする機能を提供します。中止によって移行がロールバックされる間に、移行をコミットして仕上げます。

移行ツールで利用される API とそのエクスペリエンスは、仮想マシン (クラシック) の移行と同じです。

移行のアクセスを設定する

この移行を実行するには、自分をサブスクリプションの共同管理者として追加し、プロバイダーに登録する必要があります。

Azure portal にサインインします。
[ハブ] メニューで、 [サブスクリプション] を選択します。表示されない場合は、 [すべてのサービス] を選択します。
適切なサブスクリプションのエントリを探し、 [自分のロール] フィールドを確認します。共同管理者の場合、値はアカウント管理者である必要があります。共同管理者を追加できない場合は、サービス管理者またはサブスクリプションの共同管理者に連絡して、追加してもらってください。
ポータル、PowerShell、または CLI を使って、サブスクリプションを Microsoft.ClassicInfrastructureMigrate 名前空間に登録します
```
Register-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate 
```
登録の状態を確認します。登録は完了するまでに数分かかることがあります。
```
Get-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate 
```

Cloud Services (クラシック) の移行と Virtual Machines (クラシック) の違い

Azure Service Manager により、2 つの異なるコンピューティング製品がサポートされています。Azure Virtual Machines (クラシック) と Azure Cloud Services (クラシック) (Web と worker ロール) です。 2 つの製品は、クラウドサービス内でデプロイの種類が異なります。 Azure Cloud Services (クラシック) には、Web と worker ロールでのデプロイを含むクラウドサービスが使用されます。 Azure Virtual Machines (クラシック) には、IaaS VM でのデプロイを含むクラウドサービスが使用されます。

デプロイの種類が違うため、サポートされているシナリオの一覧は Cloud Services (クラシック) と Virtual Machines (クラシック) で異なります。

移行の手順

お客様は、Virtual Machines (クラシック) の移行に使用されるのと同じ 4 つの操作を使用して、Cloud Services (クラシック) のデプロイを移行できます。

移行を検証する - よくあるサポートされないシナリオによって移行が妨げられないことを検証します。
移行を準備する - Azure Resource Manager でリソースのメタデータを複製します。 Azure サーバーマネージャーと Azure Resource Manager の間でリソースメタデータが同期されるように、すべてのリソースは作成、更新、削除操作に関してロックされています。すべての読み取り操作は、Cloud Services (クラシック) と Cloud Services (延長サポート) 両方の API を使って行われます。
移行を中止する - Azure Resource Manager からリソースメタデータを削除します。すべてのリソースの作成、更新、削除操作のロックを解除します。
移行をコミットする - Azure Service Manager からリソースメタデータを削除します。リソースの作成、更新、削除操作のロックを解除します。コミットを試みた後では、中止は許可されません。

Note

準備、中止、コミットはべき等であるため、失敗した場合は、再試行することで問題が解決されるはずです。

移行に関連する手順の図を示す画像。

詳細については、クラシックから Azure Resource Manager への、プラットフォームでサポートされた IaaS リソースの移行の概要に関する記事を参照してください

Cloud Services (クラシック) に関連する移行に使用できるサポートされたリソースと機能

ストレージアカウント
仮想ネットワーク (Azure Batch はサポートされていません)
ネットワークセキュリティグループ
予約済みパブリック IP アドレス
エンドポイントアクセス制御リスト
ユーザー定義のルート
内部ロードバランサー
キーコンテナーへの証明書の移行
プラグインと拡張機能 (XML および Json ベース)
開始時または停止時のタスク
高速ネットワークでのデプロイ
1 つまたは複数のロールを使用したデプロイ
Basic ロードバランサー
入力、インスタンス入力、内部エンドポイント
動的パブリック IP アドレス
DNS 名
ネットワークトラフィック規則

サポートされる構成と移行シナリオ

次の一覧には、リソース、機能、Cloud Services の組み合わせに関係する上位のシナリオが含まれています。このリストは、包括的ではありません。

サービス	構成	説明
Microsoft Entra Domain Services	Microsoft Entra Domain Services を含む仮想ネットワーク。	クラウドサービスのデプロイと Microsoft Entra Domain Services の両方が含まれる仮想ネットワークがサポートされています。お客様は、最初に Microsoft Entra Domain Services を個別に移行してから、クラウドサービスのデプロイのみが含まれる残りの仮想ネットワークを移行する必要があります
クラウドサービス	1 つのスロットにだけデプロイされたクラウドサービス。	運用スロットのデプロイを含む Cloud Services を移行できます。サービス FQDN の維持に関する問題が発生する可能性があるため、ステージングスロットの移行はお勧めしません。ステージングスロットを移行するには、最初にステージングのデプロイを運用環境にレベル上げしてから、Azure Resource Manager に移行します。
クラウドサービス	公開された仮想ネットワーク内にないデプロイ (既定の仮想ネットワークのデプロイ)	クラウドサービスは、公開された仮想ネットワークまたは非公開の仮想ネットワークに配置するか、仮想ネットワークに配置しないことができます。非公開の仮想ネットワーク内と公開された仮想ネットワーク内の Cloud Services は、移行がサポートされています。お客様は Validate API を使用して、デプロイが既定の仮想ネットワーク内にあるかどうか、したがって移行できるかどうかを判断できます。
クラウドサービス	XML 拡張機能 (BGInfo、Visual Studio デバッガー、Web 配置、リモートデバッグ)。	すべての xml 拡張機能は、移行がサポートされています
Virtual Network	複数のクラウドサービスを含む仮想ネットワーク。	複数のクラウドサービスが含まれる仮想ネットワークは、移行がサポートされています。仮想ネットワークとその中のすべての Cloud Services が、Azure Resource Manager にまとめて移行されます。
Virtual Network	ポータルで作成された仮想ネットワークの移行 (.cscfg ファイルで "Group Resource-group-name VNet-Name" を使用する必要があります)	移行の一環として、cscfg 内の仮想ネットワーク名が、仮想ネットワークの Azure Resource Manager ID を使うように変更されます。 (サブスクリプション/サブスクリプション ID/リソースグループ/リソースグループ名/リソース/VNet 名) 移行後にデプロイを管理するには、.cscfg ファイルのローカルコピーを更新して、仮想ネットワーク名ではなく Azure Resource Manager ID の使用を開始します。以前の名前付けスキームを使っている .cscfg ファイルは、検証が不合格になります。
Virtual Network	異なるサブネット内にロールのあるデプロイの移行。	異なるサブネット内に異なるロールがあるクラウドサービスは、移行がサポートされています。

次のステップ

クラシックから Azure Resource Manager への IaaS リソースのプラットフォームでサポートされる移行の概要
Azure portal を使用して Cloud Services (延長サポート) に移行する
PowerShell を使用して Cloud Services (延長サポート) に移行する

次の方法で共有