【手順詳細】Azureサブスクリプションを移行してみた

 2016.05.21  リアルテックジャパン

Azure を利用する際にサブスクリプションをどう設定するかは重要という話をずいぶん前に本Blogでもシリーズで取り上げておりました。今回は滅多にやることはないと思われる(=情報がない)、既存サブスクリプションを新しいサブスクリプションへ移行する際の手順について、実際に弊社で行なう機会がありましたので、その際の手順について説明します。

弊社がやりたかったこと

EA契約(Enterprise Agreement、年額一括前払い)ベースで作成した環境を、従量課金ベースしたい

(サブスクリプションを移行したかったわではありません。)

今回なぜサブスクリプション移行することになったのか

Azureアカウントの新規登録時に、「従量課金」という名前でサブスクリプションがデフォルトで作成されて、それを使ってクレジット精算するというのが最も一般的な精算方法です。しかし企業ユーザさんではいよいよ本格的に使うとなると、EA契約が締結して使われることがが多いかと思います。EA契約時にAzureアカウントを紐付けた時点で既存の従量課金サブスクリプションが強制的にEAに紐付けられてしまいます。

それを確認するためにはAzure ポータル上の左下のサブスクリプションを選ぶと、既存サブスクリプションの一覧を見ます。

EA契約にアカウントが紐付くと、従量課金の横に(convert to EA)という表記が自動で追記され、かつエントリの先頭にEAのアイコンがつきます。

Azure-convert-ea.png

単純に従量課金のサブスクリプションを新しく作って、そこに移行すればよいのではと思いますが、一旦EAに紐付いたAzureアカウントはEA契約期間中は一般的な従量課金のサブスクリプションを追加することがAzureの仕様上できないということがわかりました。よって今回は、新しくMicrosoft IDを作成してAzureアカウントの新規登録を行い(=当然EA契約との紐付なし)、それで通常の従量課金サブスクリプションを作成し、そこに移行する(=単純に紐付ける感じ)ことになりました。このように書くと単純なのですが、費用精算の話ですし、ID管理も絡みますので要注意です。

前提条件、手続きの確認

前提条件の確認及び全体の流れは、Microsoft Azure サポート チーム サイトにある「サブスクリプション間のデータ移行手順について」に纏められており、これに従います。(この情報がサブスクリプション移行手続きに関する唯一の情報源です。)

ポイントとしては移行の前提を理解した上で既存環境を整理、新環境を準備し、必要な情報をまとめる。それを元にMicrosoftさんに作業をお願いして、移行自体はMicrosoftさんにて移行を実施するということです。

なお、上記の手順では事前チェック:データ移行できるサービス・できないサービスをまず見極めてた上で既存環境を整理して、その後に移行の手続きが続きますが、本記事上での以降の説明では前後が逆、つまり移行の手続きの話が先、既存環境の整理が後になっています。

<あえて逆にした理由>

移行の手続きをするための前提を整えるために、一般的な企業だとそれに付随する事務手続きが必ずあると思います。時間のかかる環境の整理をなんとかやり終えた後に、手続き準備及び再調整をやり始めるのは、実際にやってみた感想としては結構面倒だった経験から、これは先にやりましょうというという思いです。

移行先のサブスクリプション作成する

先に述べた理由から今回はAzureアカウントを新規登録し、そこに新しいサブスクリプションを作成しそれに移行します。

Azureアカウントを新たに振り出すためには、Microsoft IDの登録が前提となり、その際には新たにユニークなメールアドレスが必要になります。従量課金ベースの請求時には、クレジットカード精算ではなく請求書払いにしたかったのと、クレジットカード登録をしない方法として、Azureの支払いに請求書を使用するする方法にある手続きにのっとって、事前に与信審査を受けるといった手続きの一環で新しいAzureアカウントを作成してもらいました。早速 Azure Account Portal にサインインしてみましょう。https://account.windowsazure.com/にアクセスして、アカウントセンターに新しいアカウントでサインインします。

Azure-Account-portal01.png

デフォルトで作成された従量課金のサブスクリプションがあります。

Azure-Account-portal02.png

今回はせっかくなので、新しく従量課金サブスクリプションを追加します。

Azure-Account-portal03.png

EAと紐付いていないので、一般的な従量課金プランを選択することが可能になっています。

Azure-Account-portal04.png

通貨を円建てにして有効化します。

Azure-Account-portal05.png

事前に与信審査をうけていたので、請求書払いが選択可能です。住所等も登録済みなので住所等も入っていましたので、受信者として請求書上の宛先担当者を入力し、購入ボタンをクリック。

Azure-Account-portal06.png

サブスクリプション名:従量課金が作成されました。

Azure-Account-portal07.png

無事完了したので、最初の画面に戻るとこんな感じになります。サブスクリプション自体はIDで管理されており、名称はただの属性ということで、デフォルトで作成されたサブスクリプションと見分けが付きません。なので、これだと後で困るので早速修正しましょう、作成したサブスクリプションをクリックします。

Azure-Account-portal08.png

サブスクリプション詳細の編集というメニューがありますので、それを選択します。なお、右下にサブスクリプションIDが標示されているので、これは後で申請する際に必要なので控えておきます。

Azure-Account-portal09.png

ここから要注意ポイントです。

サービス管理者は、デフォルトでは新しく作成したアカウントのメールアドレスがサービス管理者に入っていましたが、それを移行元の「サービス管理者の」メールアドレスに変更する必要があります。これは先に紹介したMicrosoftさんの正式手順「サブスクリプション間のデータ移行手順について」に明記されていますが、これは移行作業時の必須要件となります。(移行先のサービス管理者は移行完了後にオンライン変更可能ですので、あくまで移行時のみの条件ということです、安心して下さい。)

Azure-Account-portal10.png

参考)移行元サブスクリプションのサービス管理者を調べる方法

アカウントポータルで移行元のサブスクリプションの概要を見ると、それが明記されています。

(先の手順で新しく作成したユーザでポータルにサインインしたまま、下記の画面を見るために従来のユーザで同時にサインインするとうまく画面が開かなかったので要注意)

ついでに移行元のサブスクリプションIDも申請時に必要になるので、これも控えておきます。

Azure-Account-portal11.png

これで移行先のサブスクリプション作成は終了となります。

移行元の環境の整理

一番最初で述べたとおり、これ現場は大変です。

Microsoftさんの正式手順「サブスクリプション間のデータ移行手順について」に最初に明記されているように、移行できないものが存在するためです。

弊社の場合、最終的には下記まで絞り込みました。

Azure-Account-portal13.png

本ブログをご覧になるであろう多くのSAP関係者様だと容易に想像つくと思いますが、SAP Routerはそのままにしたい。さらにVPNでP2S,S2S周りもオンプレ側のルータはいじりたくないのでそのままにしたい。とある意味とてもわかりやすい状況です。

SAP Router環境は、2014年に作成したこともあり、いわゆる仮想マシンV1ベースでした。当時のAzure仮想マシンはPaaSの延長線がある中で仮想マシンを入れてきた感じがあり、クラウドサービスを使っています。今だと仮想マシンはV2で、考え方自体が変わってしまっており、仮想マシンにPublic IPリソースを割り当てますので、当時と今は状況が異なります。

この辺りは、状態マシーン (id:StateMachine)さんが仮想マシンV1とV2という記事でまとめられていましたので、参考までにご紹介させて頂きます。昔からの経緯もあり、どんどん技術的に深くなってしまっておりますけれど。 なお、V1の場合はサブスクリプション移行の対象になりますので、そのまま残しています。

残るVMマシンは、検証環境なので最低限必要な分だけDBバックアップを待避して全消しです(笑)、ディスク用とで一つだけストレージアカウントが残っています。残るはVPNだけ。数十台の環境が動いていたこともあり、大変でした。

VMイメージでExport して、オンプレ側に持ってくるときはOSのエディションは要注意です。なぜならAzure上でWindows 2012 で稼働させると、ExportされたVMは Datacenter Edition になったので、ライセンス関係が気になります。

整理が終わったら、下記の赤枠にある名前と管理について、手元に控えます。(後ほど申請時に必要な情報です。)

Microsoftさんにサブスクリプション移行を依頼する

移行元のAzure 管理ポータルにサインインして、右上にある「ヘルプとサポート」をクリックします。

Azure-Account-portal15.png新しいサポート要求を選ぶと、インシデント作成画面が表示されます。

問題の種類:サブスクリプションの管理

サブスクリプション:移行元のサブスクリプションを選択

サポートプラン:サブスクリプションの管理 サポートを含む

Azure-Account-portal16.png重大度:どれか選んで設定(弊社的にはお金に直接絡むので真ん中を選択しています。)

問題の種類:サービスを別のサブスクリプションに移動する

ここからポイントです。

詳細のところには、Microsoftさんの手順にある通り、必要な情報を明記します。

依頼事項:契約移行に伴うサブスクリプション間のサービス移行

[1] 移行元サブスクリプションの 32 桁のサブスクリプション ID

[2] 移行先の新規サブスクリプションの 32 桁のサブスクリプション ID 

[3] 利用している各サービスの利用状況

名前      種類

xxxxxクラウド サービス (クラシック)

xxxxx 仮想マシン (クラシック)

xxxxx 予約済み IP アドレス (クラシック)

xxxxxxxxxxストレージ アカウント (クラシック)

xxxxxxxxxx 仮想ネットワーク (クラシック)

弊社の場合はいったん上記の状態で申請しましたが、事後下記情報に関する提供依頼が追加でありましたので、この時点で念のために添付ファイルとしてつけておいた方が、お互い一手間減らせるかもしれません。

1. 移行元サブスクリプションのクラシックポータル (https://manage.windowsazure.com/) の [すべての項目] 画面

2. 移行元サブスクリプションの Azure ポータル (https://portal.azure.com/) の [すべてのリソース] 画面

上記の画面スクリーンショットの提供

「次へ」をクリック

Azure-Account-portal17.png

次は連絡先情報を入力します。(画面ショットは割愛)

その際には、Microsoft社からのコンタクト方法で「電話」と「メール」どちらかを選ぶことができます。

弊社はメールを選択し、かつ連絡メールアドレスを依頼者以外にもう一つ設定できましたので、そこに現場のIT担当者を入力して、随時進捗状況を把握することにしました。

Microsoftさんのサポートから連絡があり、移行準備が整った旨連絡があり、今後の作業実施の見通しと合わせて下記の2点について説明がありました。

1.移行元はかなりのサーバが稼働させていたので、クオータ追加していたのですが、移行先のサブスクリプションでは

それがないため、別途申請が必要なこと(参考:Microsoft Azure のクォータ増加について

2.移行元に設定されていた共同管理者は移行されないので、移行後にマニュアルにて追加が必要であること

また、こちらからも移行先サブスクリプションのサービス管理者を手続き上、移行元サブスクリプションのサービス管理者に変更したが、これは移行後に通常通りオンラインで変更可能である旨再確認しました。(参考:アカウント管理者・サービス管理者・共同管理者の変更方法について

以上で申請は終了となり、作業が実施されます。

その後、Microsoftさんから、作業完了の報告と結果確認依頼がありました。(電話でのこちらからの質問に対する回答が追記されていたり、サポート担当者さんがいつもながら懇切丁寧な対応をされるのには本当に感心します。)

MSさんのガイドには10営業日と書いてあったので、いつ終わるのかなと思っていたのですが、それよりも早めに対応頂くことができました。

これで全ての移行作業は終了となります。

長文最後までお読み頂きありがとうございました。

SAPユーザのための『S/4HANA』データ移行

RECENT POST「技術情報」の最新記事


この記事が気に入ったらいいねしよう!