Azure サブスクリプションから CSP への移行【10/16更新】

（この記事は 2016 年 8 月 26 日にHybrid Cloud Best Practices blog に掲載された記事  Azure Subscription Migration to CSP   の翻訳です。最新情報についてはリンク元のページをご参照ください。)

この 1 か月の間に、私の元には、従来の Azure サブスクリプションを CSP モデル (英語) に移行したいというご依頼が数多く寄せられました。CSP の普及率は日に日に高まっています。EA や従量課金モデルよりも CSP を希望されるお客様が多い理由は、何と言っても CSP の優れたメリットにあります。これまで Azure を使用していない場合、CSP モデルで Azure の利用を開始するのは簡単です。最新の Azure のサービスを使用して、一からソリューションをデプロイすることができます。では、既に Azure 内で運用環境を構築しているお客様はどうでしょうか。従来の従量課金制や Open License 経由で Azure サービスを購入済みの場合でも、CSP の柔軟な支払い方法やお近くのパートナー様によるサポートを利用できるのでしょうか。この場合はもちろん、サービスのダウンタイムを最小限に抑えつつ、既存の Azure サブスクリプションを CSP に移行する必要があります。今回の記事では、その方法についてご説明したいと思います。

この記事のポイント: サブスクリプションの種類が異なるため、従来の Azure サブスクリプションや Azure EA サブスクリプションを単純に CSP に移行することはできません。「スイッチを切り替える」ような簡単な作業ではなく、移行元のサブスクリプション (従来のサブスクリプションまたは EA) から移行先のサブスクリプション (CSP) にリソースを移動する必要があります。このプロセスは手動で行う必要があります。この記事で具体的な手順をご紹介します。

現在の Azure サブスクリプションの種類

お客様が利用できる Azure のサブスクリプションには複数の種類があります。

1. 従来の Azure サブスクリプション
   • Azure Direct – お客様が Azure.com にアカウントを作成し、クレジット カードまたはデビット カードを Azure アカウントに登録する方法。Azure サービスの使用量に応じて翌月に課金される場合 (従量課金) と、12 か月分を前払いする場合 (12 か月の前払いプラン) があります。マイクロソフトから請求書を受け取り、料金を直接支払うこともできます。支払いプロセスにパートナー様が介在せず、お客様が直接マイクロソフトに料金を支払うことから、「Azure Direct」と呼ばれています。
   • Azure.com の無償トライアル。
   • BizSpark – マイクロソフトがスタートアップ企業向けに提供する 2 年間または 3 年間の支援プログラム。
   • Open License – お客様がマイクロソフトのリセラーから Azure クレジットを購入し、Azure ポータルでライセンス認証を行う方法。
   • MPN のメンバーや Visual Studio サブスクライバー (MSDN サブスクリプション) 向けの Azure 特典。
2. Azure EA サブスクリプション – 既存の Enterprise Agreement (EA) に 3 年間の Azure 年額コミットメントを追加するか、Azure のみを対象とする EA を別途締結する方法 (「SCE」)。
3. Azure CSP サブスクリプション。

従来の Azure サブスクリプションと Azure EA サブスクリプションには、多数の共通点があります。

• 管理ポータルには旧ポータルと新ポータルの 2 種類があります。

• ASM サービスと ARM サービスの両方を利用できます (ASM と ARM の詳細についてはこちらのドキュメントを参照)。ARM サービスは新しい Azure ポータルでしか利用できません。ASM サービスは両方のポータルで利用可能で、新しい Azure ポータルでは「クラシック」と呼ばれます。通常、ASM ベースの IaaS は「IaaSv1」、ARM ベースの IaaS は「IaaSv2 (英語)」と呼ばれます。

• サブスクリプションの所有者 (ASM では「サービス管理者」) 権限はお客様に付与されます。
• テクニカル サポートはマイクロソフトが提供します。
• 請求および価格の詳細は、マイクロソフトが提供します。
• お客様は、Azure Marketplace で提供されているサード パーティ製ソリューションをデプロイできます。サード パーティのライセンスではなく既存のライセンスを使用する方法 (BYOL) またはサード パーティのライセンスを含める従量課金モデル (PAYG) を選択できます。いずれの場合も、サード パーティのライセンスは Azure サービスとは別に課金されます。サード パーティのライセンスの支払いには、EA の Azure 年額コミットメントまたは Open License の Azure クレジットを充当することができます。

ただし、従来の Azure サブスクリプションと Azure EA サブスクリプションには、いくつかの相違点もあります。

1. 従来の Azure サブスクリプションの請求および支払い情報は Azure アカウント センターで確認します。一方、Azure EA のお客様は Azure EA ポータルを使用します。
2. 従来の Azure サブスクリプションは Microsoft アカウント (旧称「LiveID」) と関連付けられます。お客様は Microsoft アカウントの資格情報を使用して Azure 管理ポータルにログインし、請求などには個人のクレジット カードを使用します。一方、Azure EA サブスクリプションは、Azure Active Directory と関連付けられるため、指定された EA マネージャーが Azure EA ポータルで Azure サブスクリプションを作成し、AD の所定のユーザー アカウントに所有者権限を割り当てます。

この 2 番目の点が非常に重要です。Azure サービスでは、Azure テナント (新しい Azure ポータルでは「ディレクトリ」とも呼ばれる) という用語が使用されます。すべての Azure サブスクリプションは Azure テナント内に作成されます。Azure テナントは *.onmicrosoft.com といった形式のドメインで、すべての Azure サブスクリプションはこのドメインに所属します。

• Microsoft アカウントに関連付けられている従来の Azure サブスクリプションの場合、Azure テナントは自動的に生成されます。たとえば、Microsoft アカウント (LiveID) が johnsmith@outlook.com である場合、Azure テナントはおそらく johnsmithoutlook.onmicrosoft.com になります。Microsoft アカウントに個人のドメイン名を使用することも可能です。Microsoft アカウントが kotlyarenko1111@gmail.com であれば、kotlyarenko1111gmail.onmicrosoft.com という Azure テナントが生成されます。
• Azure EA サブスクリプションでは、Azure のテナント名が企業の Azure Active Directory と同じになります。たとえば、Kotlyarenko LLC という企業で、サブスクリプションが kotlyarenko.onmicrosoft.com という Azure AD に関連付けられているとします (こちらの記事 (英語) でご紹介したように、Azure AD はオンプレミスの AD と接続することも可能です)。この場合、Azure EA サブスクリプションは kotlyarenko.onmicrosoft.com という Azure テナント内に作成されることになります。このしくみは Office 365 と同様で、Office 365 の場合は Office 365 テナントの名前が Azure AD と同じになります。

例を挙げてみましょう。個人の Microsoft アカウントで契約しているユーザーに対して、2 つのテナントのサブスクリプションの所有者権限が割り当てられているとします。それぞれのテナント名は、kotlyarenko1111gmail.onmicrosoft.com (Microsoft アカウント ベースの Azure テナント) と kotlyarenko.onmicrosoft.com (Azure AD ベースの Azure テナント) です。これらの 2 つのサブスクリプションを利用するには、Azure ポータルで「ディレクトリ」を切り替える必要があります。

従来の Azure サブスクリプションはテナント間で移行できます。その方法は非常に簡単になり、サポート要求を作成する必要もなくなりました。そのため、Microsoft アカウントに関連付けられた Azure テナント内の Azure Direct サブスクリプションは、お客様自身が企業の Azure Active Directory に移行することができます。この場合は、1 つの Azure テナントに従来の Azure サブスクリプションと Azure EA サブスクリプションの両方が含まれることになります。これは非常に重要なポイントです。その理由は後ほどこの記事で詳しくご説明します。

Azure CSP サブスクリプションの相違点

Azure サブスクリプションから CSP に移行する場合には、従来の Azure サブスクリプションや Azure EA サブスクリプションと Azure CSP サブスクリプションの相違点を理解する必要があります。

• CSP モデルでは、最新の ARM サービスのみを利用できます。従来の ASM (「クラシック」) サービスや「IaaSv1」は利用できません。
• 従来の Azure サブスクリプションや Azure EA サブスクリプションで提供されていた ARM サービスの一部は、CSP では利用できません。ただし、ほとんどのサービスは利用可能です。
• ASM サービスを利用しないため、旧 Azure ポータルも不要になります。

• 請求と価格設定は CSP パートナー様が担当します。お客様は Azure アカウント センターや新しい Azure ポータルの [Billing] メニューにアクセスできません。お客様は、CSP パートナー様から提供される請求ツールを使用することになります。
• Azure CSP サブスクリプションの所有者は必ず CSP パートナー様になります。パートナー様の管理者がお客様の IT 管理者に所有者権限を割り当てることはできますが、パートナー様の所有者権限をお客様が取り消すことはできません。詳細については、こちらの記事 (英語) を参照してください。
• テクニカル サポートは CSP パートナー様が提供します。そのため、お客様がマイクロソフトのサポート チャネルを通じて Azure CSP サブスクリプションに関するインシデント要求を作成しても、「CSP サブスクリプションはマイクロソフトのサポート対象外のため、CSP パートナー様にご連絡のうえ、インシデント対応を依頼してください」という主旨の回答しか得られません。
• CSP サブスクリプションは、Azure AD と関連付けられた Azure テナント内に作成されます。Azure テナントは、パートナー センター ポータルで登録された新規のお客様 (Azure AD が新たに作成される) を選択することも、パートナー センター アカウントと関連付けられた既存のお客様 (既存の Azure AD を利用する) を選択することも可能です。
• 現在、Azure Marketplace では BYOL モデルのサード パーティ製ソリューションのみが提供されています。お客様が CSP パートナー様を通じて Azure サービスと共にサード パーティ製ソリューションのライセンスの購入を希望する場合、CSP パートナー様は対象のライセンスを別途販売するか、サービス コストの一部に含めることができます。たとえば、パートナー様が Barracuda Firewall や Citrix NetScaler といった BYOL ソリューションのライセンス サブスクリプションを追加する場合、その料金は Azure CSP の請求書には含まれません。
• Azure CSP では、MySQL サービスを利用することはできません。MySQL サービスは、ClearDB が提供するサード パーティ サービスとして、従来の Azure サブスクリプションで利用できます。その代わりに、Azure CSP では先日発表された MySQL In App (英語) サービスを利用できます。CSP では既に提供が開始されており、MySQL In App を利用するには、専用の Web Apps テンプレートを利用するか、Web Apps を作成してから [Properties] メニューで [MySQL in App] を有効化します。

Azure CSP への移行シナリオ

ここまで、従来の Azure サブスクリプション、Azure EA サブスクリプション、Azure CSP サブスクリプションの相違点についてご説明しました。従来の Azure サブスクリプションや Azure EA サブスクリプションから Azure CSP への移行を計画する際には、サブスクリプション間の違いがきわめて重要になります。以下の点にご留意ください。

1. サブスクリプションの種類が異なるため、従来の Azure サブスクリプションや Azure EA サブスクリプションを単純に CSP に移行することはできません。「スイッチを切り替える」ような簡単な作業ではなく、移行元のサブスクリプション (従来のサブスクリプションまたは EA) から移行先のサブスクリプション (CSP) にリソースを移動する必要があります。このプロセスは手動で行う必要があります。このセクションで具体的な手順をご紹介します。
2. IaaSv1 (ASM ベース) は CSP では利用できないため、この機会にお客様を IaaSv1 から IaaSv2 に移行することができます (ただし、簡単ではありません)。移行時には、一定時間のサービスのダウンタイムが発生する場合があります。
3. Cloud Services や Mobile Services は ARM で提供されていないため、CSP でも利用できません。そのため、お客様には IaaSv2 および Azure App Service への切り替えを先に検討することをお勧めします。
4. 現時点では、CSP で Azure Mobile Engagement および Azure Cognitive Services はサポートされていません。これらのサービスを運用環境でご利用のお客様はほとんどいらっしゃらないため、大きな問題はないと思われます。
5. Azure Marketplace で提供されている PAYG モデルのサード パーティ製ソリューションをお客様が利用している場合は、BYOL モデルに切り替え、Azure サービスとは別にサード パーティ製ソリューションのライセンスを購入する必要があります。
6. CSP への移行作業はパートナー様が実施するか、少なくとも移行プロセス中にお客様をサポートするようにします。お客様に任せきりにはしないでください。

お客様の運用環境用のワークロードを移動する前に、サンドボックス環境で移行プロセスをテストすることをお勧めします。このテストに最適なのが、パートナー センターの統合サンドボックス (英語) です。CSP Direct のパートナー様 (または CSP Indirect のディストリビューター) は、お客様のサンドボックス用アカウントを最大 25 件作成し、各アカウントに最大 25 件の Azure CSP サブスクリプションを追加できます。サンドボックス内の各 Azure CSP サブスクリプションの価格の上限は月額 200 ドルです。つまり、200 x 25 x 25 = 125,000 ドル分の Azure サービスを毎月無料で利用できます (英語)。ただし、Azure CSP サンドボックスのサブスクリプションを運用環境のサブスクリプションに移行することできません。移行プロセスの最終段階では、通常の Azure CSP サブスクリプションが必要になります。

ここでは、従来の Azure サブスクリプションまたは Azure EA サブスクリプションから Azure CSP サブスクリプションへの移行について、最も一般的な移行シナリオを 3 種類ご紹介します。

1. IaaSv1 -> Azure CSP の IaaSv2
2. IaaSv2 -> Azure CSP の IaaSv2
3. PaaS -> Azure CSP の PaaS

IaaSv1 から Azure CSP の IaaSv2 への移行

パートナー様による移行のご依頼が最も多いのがこのシナリオです。旧 Azure ポータルを使用して VM を作成しているお客様は、現在も多数いらっしゃいます。また、既に新ポータルに切り替えていても、以前に旧ポータルで作成した VM を統合するために「クラシック」デプロイ モデルを使用しているお客様もいらっしゃいます。この場合、お客様は依然として ASM ベースの IaaSv1 を使用していますが、IaaSv1 は CSP では利用できません。

典型的な状況としては、お客様の EA の満了を 3 か月後に控え、より柔軟性が高く、地域のパートナー様によるテクニカル サポートを受けられる CSP への切り替えを希望されるといったケースが挙げられます。また、3 年前に BizSpark に参加したスタートアップ企業も同様です。商用の Azure サブスクリプションに切り替える必要が生じたため、移行先として CSP を選択するお客様が増えています。こうした企業は 2 ～ 3 年前に Azure の利用を開始しましたが、当時は IaaSv2 を利用できませんでした (IaaSv2 は 2014 年にリリースされ、2015 年に既定のデプロイ オプションになりました)。

IaaSv1 を CSP の IaaSv2 に移行するには、2 種類の方法があります。

1. プラットフォームでサポートされる移行方法: Azure プラットフォームのサポート対象の移行方法を使用して、同一サブスクリプション内で IaaSv1 から IaaSv2 にリソースを移行します。その後、移行元サブスクリプションの IaaSv2 を CSP サブスクリプションの IaaSv2 に移行します (後半の手順については、後ほどこの記事でご説明します)。
2. MigAz の使用: Paulo Ramos (Microsoft Azure のエキスパート) が開発したオープン ソース ツールの MigAz (英語) を使用します。このツールを使用すると、ARM に類似の IaaS 環境を作成し、ストレージ アカウントのデータを CSP サブスクリプション (または他のテナント) に移行できます。

1 番目の方法では、通常はダウンタイムが発生せず、マイクロソフトによる完全なサポートを受けられますが、2 段階の移行作業が必要になります。2 番目の方法はマイクロソフトのサポート対象外で (MigAz はコミュニティによってサポートされるオープン ソース ツールであるため)、多少のダウンタイムが発生しますが、移行作業は 1 段階で完了します。

Azure プラットフォームのサポート対象の移行方法については、Azure のサイトで詳しく解説されているため、ここで改めてご説明することは控えようと思います。MigAz による移行のしくみは以下のとおりです。

1. 移行元の環境 (IaaSv1) に接続します。
2. VM、ネットワーク、ストレージに関する情報を収集し、ARM サービス テンプレート (JSON ファイル) を作成します。
3. この ARM サービス テンプレートを使用して、IaaSv2 に環境のコピーを作成します。
4. 移行先の環境 (CSP の IaaSv2) を作成したら、スナップショットを使用して仮想ディスクを移行し、VM を起動します。

MigAz では、あるテナントの IaaSv1 を、別のテナントの IaaSv2 に移行することができます。ダウンタイムは最短で 30 秒ですが、最長時間は移行元の環境のアーキテクチャによって異なります。また、以下の点にご留意ください。

1. データの書き込み先を把握します。データ サイズによって、移行には 5 分～数日かかります。移行に長時間かかる場合には、データを同期できない可能性があります。ステートレス システムは簡単に移行できます。また、Azure SQL Database などの Azure PaaS サービスにデータを格納する場合も問題ありません。移行プロセスの次の段階において、ARM で IaaS が実行された際に、CSP に切り替えることができます。
2. ただし、SQL Server や MySQL といった VM 内の DBMS にデータを格納し、アプリケーション サーバーがデータベースに頻繁にデータを書き込む場合は、移行がはるかに困難になります。この場合、移行先の環境 (IaaSv2) に別のサブネットを用意して、VNet ピアリングを構成することにより、移行元の環境と移行先の環境の VM は直接通信できます。ステートレスな VM をコピーしてから、セカンダリ SQL Server を新しい環境にコピーし、データが同期されるまで待ちます。同期が完了したら、このセカンダリ SQL Server をプライマリ サーバーに変更し、残りの SQL Server を移動します。
3. MigAz を使用する場合、BLOB データのコピーにはスナップショットが使用されるため、VM をシャットダウンする必要はありません。ただし、複数のデータ ディスクを使用して VM 内に単一の大容量ストライプ ボリューム (Windows Server VM の記憶域スペースや Linux の LVM など) を作成する場合は、この VM をシャットダウンし、VM が実行されていない状態でデータを新しい環境にコピーする必要があります。
4. 外部 IP アドレスは変更されます。外部 IP アドレスの変更に伴うダウンタイムを最小限に抑えるためには、Traffic Manager の使用を検討してください。
5. ASM ベースのストレージ アカウントから新しい ARM ベースのストレージ アカウントにブロック BLOB データを移行する必要がある場合は、PowerShell コマンドレット (英語) を使用できます。
6. すべてを事前に計画し、サンドボックス環境へのテスト移行を実施してから、運用環境の移行を実施するようにしてください。

では、具体的な説明に入りましょう。現在、従来の Azure サブスクリプション内で実行している環境を CSP に切り替える場合について考えます。現在の環境は 2 層の Web ポータルで、IIS ベースのフロントエンド サーバー 2 台と、SQL Server ベースのバックエンド サーバー 2 台で構成されています。

1. Windows Server 2012 R2 と IIS を実行する D1 VM が 2 台 (WEB01 と WEB02)。ステートレスなフロントエンド サーバーで、「WEB」という可用性セットを構成しています。HTTPS エンドポイント (https://cspmigration.kotlyarenko.com) は負荷分散されており、Azure Load Balancer によってトラフィックがこの 2 つの Web サーバーに分配されます。
2. Windows Server 2012 R2 および SQL Server 2016 Standard を実行し、AlwaysOn 可用性グループが設定されている A5 VM が 2 台 (SQL01 と SQL02)。フロントエンドからのすべてのデータが書き込まれます。
3. 2 つのストレージ アカウント。1 つは WEB01 および WEB02 用で、もう 1 つは SQL01 および SQL02 用です。
4. VNet が 1 つ。4 台の VM はすべて、この VNet に接続されています。
5. Web ポータルは、https://cspmigration.kotlyarenko.com というパブリック URL を使用して内部に公開されています。この FQDN は myapp2408.cloudapp.net という Cloud Services の CNAME で、IP アドレス 52.178.215.175 に解決されます。
6. kotlyarenko.com ドメインは Infobox (ロシア語) の DNS 管理パネルを使用して管理され、HTTPS の SSL 証明書は DigiCert (英語) から発行されています。
7. すべての VM は 127 Gb の仮想ディスク (既定サイズ) を使用します。
8. すべてのリソースは北ヨーロッパ リージョンで実行されています。

では、具体的な手順をご説明しましょう。

最初に、パートナー センター ポータルで新しい Azure CSP サブスクリプションを作成し、サブスクリプション ID を保存します。ここでは、既存の kotlyarenko.onmicrosoft.com テナントを使用することにします。

従来の Azure サブスクリプションを移行元として使用するため、アクセスには Microsoft アカウントを使用します。CSP パートナー様の管理者として Azure 管理ポータルを開き、新しい CSP サブスクリプションの所有者として Microsoft アカウントを招待します。これにより、お客様は 1 つの Microsoft アカウントを使用して、移行後の環境と移行前の環境の両方にログインできるようになります。

お客様が新しい Azure 管理ポータルにログインすると、2 つの Azure テナント (ディレクトリ) が表示されます。1 つは、従来の Azure サブスクリプションにサインアップしたときに生成された古いテナントで、もう 1 つは、パートナー センターで作成された Azure AD ベースの新しいテナントです。

旧 Azure ポータルでは、移行元の環境が以下のように表示されます。

このような移行作業で特に問題になるのが、外部 IP アドレスの変更です。DNS レコードに新しい外部 IP アドレスを指定すると、変更がレプリケートされるまでに数時間かかる場合があります。この間、一部のエンドユーザーは移行前の環境に転送され、他のエンドユーザーは移行後の環境に転送されます。この問題を最小限に抑えるためには、Traffic Manager を使用します。新しい Azure CSP サブスクリプションを選択して、Traffic Manager のプロファイルを新たに作成し、ルーティング方法として「Priority (優先度)」を指定します。

[Configuration] をクリックし、TTL を 30 秒に変更します。これは指定可能な最小の値です。この場合、30 秒が経過すると、クライアントは Traffic Manager を通じてパブリック DNS 名の解決を再び試行します。移行の完了後、Traffic Manager で新しい環境に設定を切り替えると、30 秒後にクライアントは移行前の環境ではなく、移行後の環境に転送されます。数時間と 30 秒では格段の差です。さらに、エンドポイントの監視ポートを変更します。この例では HTTPS 443 を指定します。

新しいエンドポイントを作成して、優先順位を 1 に設定し、移行前の環境内の Cloud Services の DNS 名を指定します。この例では myapp2408.cloudapp.net です。この設定では、IP アドレスはサポートされていません。

次に、エンドユーザーを自社の Web ポータルに転送する外部 DNS レコードを変更します。この例では、エンドユーザーは https://cspmigration.kotlyarenko.com という URL を使用して Web ポータルにアクセスします。そこで、kotlyarenko.com ドメイン内の cspmigration DNS レコードを変更し、これまでの A レコードの代わりに、Traffic Manager の FQDN (asm2armtest.trafficmanager.net) を CNAME として指定します。Traffic Manager によって Cloud Services の DNS 名 (myapp2408.cloudapp.net) が解決され、クライアント マシンで HTTPS Web エンドポイントの外部 IP アドレス (52.178.215.175) に解決されます。これらの DNS の変更がレプリケートされるまで、数時間待ちます。後で新しい環境を作成する際に、クライアントを移行前の環境ではなく、IaaSv2 環境に転送する 2 番目のエンドポイントを Traffic Manager のプロファイルに追加します。

外部 DNS レコードが Traffic Manager の FQDN に解決されることを確認します。

次に、MigAz (英語) をダウンロードして起動します。移行元の Azure サブスクリプションにサインインします。サブスクリプション内にある IaaSv1 リソースが表示されるので、移行する要素を選択します。

MigAz によって 2 つのファイルが生成されます。export.json (ARM サービス テンプレート) と copyblobdetails.json (MigAz フォルダー内にある BlobCopy.ps1 スクリプトの構成ファイル) です。

新しい Azure PowerShell セッションを開始し、まだ実行していない場合は Azure Resource Manager をインポート (管理者特権で Install-Module AzureRM を実行) してから、Azure CSP サブスクリプションに接続します。さらに、新しいリソース グループを作成します。

Login-AzureRmAccount
$TenantID=”kotlyarenko.onmicrosoft.com”
$SubscriptionID=”07bb8a2b-bb31-6d1f-a49e-5daa0f086ebf“
Select-AzureRmSubscription -SubscriptionID $SubscriptionID -TenantId $TenantID
$ResourceGroupName=”CSPRG1“
$Location = “North Europe“
New-AzureRmResourceGroup -Name $ResourceGroupName -Location $Location

Resource Manager サービスのデプロイを開始します。エラーが表示されて失敗しますが、問題ありません。これは、まだ VM ディスクが移行元の環境からコピーされていないためです。ただし、スクリプトを実行することで、移行前の ASM 環境と同様の完全な ARM 環境が構築されます。

New-AzureRmResourceGroupDeployment -Name “DeploymentCSP” -ResourceGroupName $ResourceGroupName -TemplateFile “C:CSPexport.json” -Verbose

SQL Database 内のデータが移行中に失われないように、データベースを読み取り専用モード (英語) に切り替えます。これにより、移行作業が完了するまで、エンドユーザーはこのソリューションを読み取り専用モードで利用できます。

移行元のストレージ アカウントから移行先のストレージ アカウントへの仮想マシン ディスクのコピーを開始し、処理が完了するまで待機します。この例では、127 Gb の VM ディスク 4 つが 3 分でコピーされました。

.BlobCopy.ps1 -ResourcegroupName $ResourceGroupName -DetailsFilePath “C:CSPcopyblobdetails.json” -StartType StartBlobCopy
.BlobCopy.ps1 -ResourcegroupName $ResourceGroupName -DetailsFilePath “C:CSPcopyblobdetails.json” -StartType MonitorBlobCopy

次に、JSON テンプレートからの Resource Manager のデプロイを再実行します。今回は、エラーなしで処理が完了します。

New-AzureRmResourceGroupDeployment -Name “DeploymentCSP” -ResourceGroupName $ResourceGroupName -TemplateFile “C:CSPexport.json” -Verbose

新しい Azure ポータルにアクセスします。移行元の環境と同様の環境が ARM モデルで作成されていることを確認できます。さらに、すべての VM が既にオンラインで実行されています。

ただし、ご覧のとおり、外部 IP アドレスが 52.169.226.32 に変更されています。

Traffic Manager の [Endpoints] ページに戻ります。新しいエンドポイントを作成して、WEB 可用性セットに関連付けられたロード バランサーの外部 IP アドレスにエンドユーザーを転送するように指定します。

古いエンドポイントを無効化すると、すべてのエンドユーザーが 30 秒以内に新しい環境に転送されます。

新しい環境の SQL Server を読み取り/書き込みモード (英語) に切り替え、動作に問題がないことを確認します。新しい Azure CSP 環境に問題がなければ、外部 DNS レコードを変更します。CNAME を使用して、Traffic Manager の FQDN の代わりに、新しい環境内のフロントエンドのロード バランサーの FQDN を指定します。これで作業は完了です。

この場合、お客様は引き続き、個人の Microsoft アカウントを使用して Azure CSP サブスクリプションにアクセスします。ただし、大規模な組織であれば、オンプレミスの AD と統合された Azure AD アカウントに切り替える方が適切です。Azure EA サブスクリプションからの移行は、ここまで説明した手順とほぼ同じですが、移行元のサブスクリプションへのアクセスには、Microsoft アカウントではなく Azure AD アカウントを使用する必要があります。

ご説明したように、移行作業中は常にエンドユーザーが Web ポータルを利用できましたが、途中で数分間だけ読み取り専用モードになりました。お客様にとって読み取り専用モードが不都合である場合は、既にご紹介したように、2 つのサブネット、VNet ピアリング、SQL Server (MySQL、PostgreSQL など) のデータベース レベルでのデータ レプリケーションを使用する移行方法を選択できます。

IaaSv2 から Azure CSP の IaaSv2 への移行

従来の Azure サブスクリプションや Azure EA サブスクリプションの IaaSv2 から Azure CSP サブスクリプションの IaaSv2 への移行作業ははるかに簡単です。通常、必要な作業はサブスクリプション間での ARM リソースの移動だけです。重要な制限事項として、両方のサブスクリプションが同じテナント内にある必要があります。

Azure EA から Azure CSP に移行する場合、Azure CSP サブスクリプションは Azure EA で使用されていた既存のテナント内に作成されている可能性が高いため、この制限事項が問題になることはないでしょう。パートナー センターの [Request a Reseller Relationship] ボタンを使用すると、CSP パートナー様はお客様のテナント (*.onmicrosoft.com) を自社のパートナー アカウントに関連付けることが可能で、Azure サブスクリプションが同じテナント内に作成されます。

ただし、Microsoft アカウント ベースの Azure テナント内にある従来の Azure サブスクリプションから移行する場合は、先に Azure AD ベースのテナントにサブスクリプションを移行する必要があります。この作業も非常に簡単になりました。Azure アカウント センターにアクセスして移行元のサブスクリプションを選択し、[Transfer Subscription] をクリックします。新しい Azure AD ユーザーの資格情報を入力すると、指定した Azure AD ユーザーが所属する Azure AD テナントにサブスクリプションが移行されます。

先ほどの例と同様の環境を使用してご説明しましょう。唯一の違いは、既にこの環境が ARM ベースの IaaSv2 上で実行されている点です。この例では、Azure MSDN サブスクリプション内に 2 台の VM を作成してから、そのサブスクリプションを kotlyarenko.onmicrosoft.com テナントに譲渡しました。VM の名前は VM01 と VM02 で、この 2 台の VM は同じストレージ アカウントと同じ VNet 内にあります (移行作業中、2 台の VM 間のネットワーク通信が途切れないことをお見せします)。すべてのリソースは北ヨーロッパ リージョンの MyVMs リソース グループに格納されています。

まず、移行に使用するユーザー アカウントに対して、両方のサブスクリプションの所有者権限を割り当てます。両方のサブスクリプションが同じテナントに所属しているため、Microsoft アカウントと Azure AD アカウントのどちらでも使用できます。従来の Azure サブスクリプションから Azure CSP サブスクリプションに移行する VM を選択します。[Properties]、[Change subscription] の順にクリックします。表示されたすべてのリソースを選択してから、リストから Azure CSP サブスクリプションを選択し、そのサブスクリプション内の空のリソース グループを指定します。

この例では、別の Azure サブスクリプションへの移行作業にかかった時間は全体で約 5 分でした。

 

この間、ダウンタイムは発生しませんでした。移行作業中は常に VM 間での通信が可能で、パブリック IP アドレスも利用できました。本当にダウンタイムはゼロです。

移行前の Azure サブスクリプションのリソース グループからリソースを消去します。

これで、すべての IaaSv2 リソースが新しい Azure CSP サブスクリプションに移行されました。パブリック IP アドレスにも変更はありません。

現在、IaaSv2 リソースの一部は別のサブスクリプションに移動できませんが、この状況は間もなく改善されます。Application Gateway と VPN Gateway は移動できないため、新しいサブスクリプションに作成し直す必要があります。また、仮想マシン スケール セットも移動できないため、Azure CSP サブスクリプション内にスケール セット定義を再度デプロイする必要があります。最も簡単な方法は、現在のリソースを JSON ファイルとしてエクスポートし、新しいサブスクリプションにデプロイすることです。目的のリソースを含むリソース グループを選択し、[Last Deployment] をクリックしてデプロイのリストを表示します。最新のデプロイを開き、[View Template]、[Deploy] の順にクリックします。

PaaS から Azure CSP の PaaS への移行

従来の Azure サブスクリプションや Azure EA サブスクリプションの PaaS サービスを CSP に移行したいというお客様は非常にたくさんいらっしゃいます。IaaS のセクションで、ストレージ アカウント、仮想ネットワーク、VM (他の PaaS サービスでも使用可能) の移行方法は既にご説明しました。最も多いご要望は、Azure App Service (Web Apps) や Azure SQL Database を Azure CSP に移行したいというものです。

この場合の大まかな手順は次のようになります。

1. 従来の Azure サブスクリプションの場合: パートナー センターで作成された Azure AD ベースのテナントに Azure サブスクリプションを譲渡します。
   Azure EA サブスクリプションの場合: パートナー センターでリセラー関係の契約依頼を行い、お客様の既存のテナントを CSP パートナー様のアカウントに追加します。
2. パートナー センターで新しい Azure CSP サブスクリプションを作成します。
3. このサブスクリプションに移動するリソースに対応するリソース プロバイダーを登録します。
4. 移行前のサブスクリプションから移行後のサブスクリプションにリソースを移動します。両方の Azure サブスクリプションの所有者権限を持つ Azure AD ユーザーまたは Microsoft アカウントの資格情報を使用します。

この移行作業中、リソースのダウンタイムは発生しません。また、Azure サービスが新旧のどちらの Azure ポータルで作成されていても違いはありません。最近の PaaS サービスのほとんどは、内部で ARM を使用しているためです。旧ポータルで作成された Azure SQL Database や Azure Web Apps は、リソース グループ内にリソースとして追加され、新ポータルからも利用できるようになります。

次の制限事項にご注意ください。

1. 前述のとおり、現時点では CSP で Mobile Engagement および Cognitive Services はサポートされていません。
2. Application Insights ではリソースの移動がサポートされていません。リソース テンプレート (JSON ファイル) をエクスポートして、新しい Azure サブスクリプションで再度デプロイする必要があります。
3. 一部のリソース (Web Apps など) のサブスクリプション間の移行は PowerShell でのみ実行可能で、Azure ポータルは使用できません。
4. サブスクリプション間でリソース グループ全体を移行することはできません。リソースを個別に移動する必要があります。
5. ClearDB が提供するサード パーティ サービスの MySQL は、CSP では利用できません。その代わりに、CSP ではネイティブの MySQL In App (英語) を使用できますが、ClearDB サービスではなく MySQL In App を使用するように Web Apps を再構成する必要が生じる場合があります。

例 1 – Azure App Service

旧ポータルを使用して、従来の Azure サブスクリプション (Azure MSDN サブスクリプション) 内に Web Apps を作成しました。新旧のポータルでは、次のように表示されます

最初に、このサブスクリプションを kotlyarenko.onmicrosoft.com テナントに譲渡する必要があります。次に、新しい Azure CSP サブスクリプションを作成して、次の PowerShell スクリプトを実行します。

$OldSubscriptionID = “82fcfabd-df0c-4ea6-9d27-2dfe5879778a“
$OldRGName = “Default-Web-NorthEurope”  //this is the default RG name if you create Web App on the old portal.
$NewSubscriptionID = “0d8f7263-62cf-49f3-8578-ddde56305e77“
$NewRGName = “CSPResourceGroup“
Select-AzureRmSubscription -SubscriptionID $NewSubscriptionID
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Web  //you need to register Microsoft.Web resource provider in the new subscription before moving Web App resources.
Select-AzureRmSubscription -SubscriptionID $OldSubscriptionID
$webapp = Get-AzureRmResource -ResourceGroupName $OldRGName -ResourceName “App2408“
$plan = Get-AzureRmResource -ResourceGroupName $OldRGName -ResourceName “Default1“
Move-AzureRmResource -DestinationSubscriptionId $NewSubscriptionID -DestinationResourceGroupName $NewRGName -ResourceId $webapp.ResourceId, $plan.ResourceId

ダウンタイムを発生させることなく、1 分も経たないうちに Azure App Service を Azure CSP サブスクリプションに移行することができました。外部 URL および IP アドレスに変更はありません。

例 2 – Azure SQL Database

旧ポータルを使用して、従来の Azure サブスクリプション (Azure MSDN サブスクリプション) 内に Azure SQL サーバーおよび Azure SQL Database を作成しました。新旧のポータルでは、次のように表示されます。

最初に、このサブスクリプションを kotlyarenko.onmicrosoft.com テナントに譲渡する必要があります。次に、新しい Azure CSP サブスクリプションを作成して、次の PowerShell スクリプトを実行します。

$OldSubscriptionID = “82fcfabd-df0c-4ea6-9d27-2dfe5879778a“
$OldRGName = “Default-SQL-NorthEurope”  //this is the default RG name if you create SQL Database on the old portal.
$NewSubscriptionID = “0d8f7263-62cf-49f3-8578-ddde56305e77“
$NewRGName = “CSPResourceGroup“
Select-AzureRmSubscription -SubscriptionID $NewSubscriptionID
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.SQL  //you need to register Microsoft.SQL resource provider in the new subscription before moving SQL Database resources.
Select-AzureRmSubscription -SubscriptionID $OldSubscriptionID
$sqlserver = Get-AzureRmResource -ResourceGroupName $OldRGName -ResourceName “xzc647tfiy”
Move-AzureRmResource -DestinationSubscriptionId $NewSubscriptionID -DestinationResourceGroupName $NewRGName -ResourceId $sqlserver.ResourceId

ダウンタイムを発生させることなく、1 分も経たないうちに Azure SQL Database を Azure CSP サブスクリプションに移行することができました。

CSP パートナー様間での Azure CSP サブスクリプションの移行

お客様が現在の CSP パートナー様から別の CSP パートナー様への切り替えを希望される場合にも、リソースを移行する必要はありません。パートナー様が違っても Azure CSP サブスクリプションはほぼ同じであるため、お客様はサービスを中断することなく、現在のパートナー様のサブスクリプションから別の CSP パートナー様のサブスクリプションに切り替えることができます。マイクロソフトのテクニカル サポート宛てに移行申請を送信する方法と、お客様および移行先のパートナー様がそれぞれ実施する必要のある作業については、こちらのガイドをご覧ください。

 

今回は、Azure IaaS (IaaSv1 または IaaSv2) を CSP に移行する方法と、PaaS サービスを移行する方法をご紹介しました。この情報が、パートナー様やお客様のお役に立てば幸いです。また、お客様のソリューションを CSP に移行した成功事例をご紹介いただけると嬉しく思います。今後も、このブログでご紹介する最新情報にご注目ください。