CloudMigration基礎:移行作業編

１．はじめに

今回はいよいよ移行実作業を記載していこうと思います。

前回に続き『エージェント方式：CloudEndureMigration』『エージェントレス方式：VMImport』を例に「CloudMigration作業」実例を記載していこうと思います。

２．CloudMigration基礎の記載範囲

CloudMigration基礎については、以下の3回で投稿してまいります。

①CloudMigration基礎:手法とステップ
②CloudMigration基礎:実例-事前調査・事前準備編
③CloudMigration基礎:実例-移行作業編　：☆彡今回ここ

３．移行作業

VMImport編

作業工程

VMImportでの移行作業工程は下図の通りとなります。

では No8～No9について記載していきます。

移行作業

No8 移行ワーカーからコマンドを実行しVMImport（AMI化）する

・①移行ワーカにログインし、S3 Bucket内にファイルがあるかを確認し、containers.jsonが正しく記述されていることを確認します。

・②移行ワーカーからコマンドを実行し、OVAをAMI変換を開始します。

aws ec2 import-image --platform Linux --description "<仮想サーバ名>" --license-type BYOL --role-name vmimport --disk-containers file://containers.json

※Windowsの場合は、 --platform は　Windows、--licent-type は AWS となります。AWSはAWS払い出しのライセンスになります。

・③移行ワーカーからコマンドを実行し、変換タスクの進捗を確認します。

aws ec2 describe-import-image-tasks --import-task-ids <インポートタスクID>

※このStatusMessageが、Completedになるまで、ひたすらたたき続けます。

・④Completeになったら、AWSマネジメントコンソールから存在確認します。なので、AMI-IDを控えて検索するとよいです。

※作成日とかも照らし合わせて、確認するとよいですね。そしてすぐ名前を付けましょう。ワケワカメになる前に。。。

No8 ImportされたAMIからEC2を作成・起動する

・①上記画面にある通り、AMIを選択して「起動」をクリックします。

・想定しているインスタンスタイプを選んでください

・インスタンスの詳細設定から、VPCやサブネット、EIPの有無や、プライベートIPの設定などを実施してください。

・ストレージは、Import元のDISK構成になっていることを確認してください。

・タグは識別できるようにつけてください。

・セキュリティグループを割り当てます。セキュリティグループは事前に作成しておくことを推奨します。

・詳細確認したらインスタンス起動してください。キーペアは任意となります。

その他各工程の注意事項

No1～6 注意事項 （Exportに伴う注意事項）

• Export作業は仮想マシンの停止を伴うので、事前に調整するようにしてください。サイズにより時間が前後するのが考慮事項かと思います。停止が嫌であれば、3rdベンダのツールやSMS（ServerMigrationService）を使いましょう
• マシンの停止の仕方は各環境によりますが、注意としては、2点。

①一点切り替えでない場合は、Export後に仮想マシンの起動を忘れないようにすること。

②マシン停止前に「Import後のEC2起動時に自動起動されてしまっては困るもの」を無効化・手動起動にすること。

が重要です。Import後のトラブルなどの切り分けを容易にするためです。

No9～No16 注意事項

CloudEndureなど移行方式の違いにかかわらず大体同じことが起こるので、後段にまとめます。

No17～19 注意事項

爾後作業の注意事項です。移行後の切替にも関わりますのであまり深くは触れませんが、移行に要したリソース（移行ワーカー、Bucket内のOVA、AMI、スナップショット）は課金対象となるため放置せず削除するようにしましょう。

あわせて移行元環境を停止、削除して意図しない平行稼働にならないにしましょう。

CloudEndure編

作業工程

CloudEndureでの移行作業工程は下図の通りとなります。

ではNo1～No4、No6　および　No15～No16について記載していきます。

移行作業

No1 CloudEndureAgentをマシンにインストールする

・①CloudendureAgentのHowtoをそのままにエージェントインストールします。

※インストールキーが表示されているので確認すること

No2 初回同期の完了を確認する

・エージェントインストールすると、CloudEndureコンソールが以下のように遷移します

この段階でうまくいくとAWS上にCloudEndureインスタンスが作成されます。

時間を置くと初回同期が開始されていることが確認できます。

初回同期中にBluePrintの設定をします。

No3 CutOver時のEC2設定を定義する

・CutOver（CloudEndureで名称）でEC2の作成：起動をする際の事前定義がBluePrintです。

インスタンスタイプ、VPC・サブネット・ディスク構成・タグ・セキュリティグループなどVMImportでやる時と同様です。

No4 初回同期以降の差分同期状況を確認する

・CloudEndureでは初回同期後、自動的に差分同期されます。Windowsで1時間に1回、Linuxで20分に1回で同期されます。

・この同期にあたってCloudEndureインスタンスが持つ同期先DISKごとにEBSスナップショットが事前に取得されます。EBSスナップショットは5世代保管が維持されます。

・CloudEndureコンソールで同期失敗やら同期成功継続中は確認できますが、AWSコンソールからも確認できます。

No6 CloudEndureからCutOverを行い、EC2を作成・起動する

・①CloudEndureコンソールから「Cutover」もしくは「TestMode」をクリックすると、EC2が作成・起動されます。2つの違いは以下です

・「Cutover」：本番リリース。同期頻度・時間に関係なく、最新のスナップショット取得・同期を行い、EC2を作成・起動する

・「TestMode」：試験リリース。最新のスナップショットからEC２作成・起動する

※いずれで実行しても同期は止まりません。

※AWSとしては、まず「TestMode」を推奨しています。

No15 CloudEndureからマシンを削除する

・①CloudEndureコンソールから「Remove from this Console」で登録解除します。

ここで「Delete」するとEC2が消えますので間違えないようにします。

ここまで実施すると、CloudEndureエージェントもアンインストールされます。

No16 CloudEndureからProjectを削除する

・全ての移行が完了したら「Delete Current Project」します。この操作により、CloudEndureインスタンスも削除されます。

その他各工程の注意事項

No5およびNo17 ,No18注意事項

CloudEndure（ならびにAgent型の移行ツール）においてはマシン停止（およびCloudEndureエージェントの停止）を行うとデータ同期も停止し、移行ができなくなりますのでマシン停止はしないのですが、VMImport同様「Import後のEC2起動時に動かれてしまっては困るもの」を無効化・起動しないようにしておくことが重要です。データベースなど、静止状態でないとならないソフトウェアも停止するとよいでしょう。

No7～No14 注意事項

移行方式の違いにかかわらず大体同じことが起こるので、後段にまとめます。

共通の注意事項

１．EC2起動後のOSログイン

・特に注意事項はありませんが、事前にセキュリティグループの作成は忘れないようにします。また通常のインスタンス構築と異なりキーペア作成しないことが多いので元のパスワードを確認しておきます。

２．Hostnameの確認・設定

・RHEL6など旧世代OSをAWSに移行すると、ネットワークドライバの関係からHostnameがAWS払い出しのホスト名（ip-xx-xx-xx-xxのような）にされるケースがあります。基本的には確認の上、元に戻すなり対応してください

３．NW設定

・AWSでは手動でIPを割り当てたとしても実態としてはAWS-DHCPからのIPアドレス払い出しとなります。確認するとともに、Hosts等に記載がある場合は手動での修正もお願いします。

４．DNS設定・ドメイン再参加

・AWSでは、上記の通りAWS-DHCPからのIPアドレス払い出しになる関係上、新規構築、移行にかかわらず、初期時点ではAWS内部のDNSを参照するように修正されます。また、/etc/resolv.confに旧環境と比較して正しいと思われる記載・設定を行っても、EC2再起動時にAWS内部のDNSを参照するよう元に戻されることになっています。

・移行・切替方式にもよりますがドメイン参加する場合は移行直後は「Outboundは一切通信不可」とするセキュリティグループを割り当てHostname、NW設定、DNS設定が完全に完了した後に、改めて正規のセキュリティグループをアタッチし再度ドメイン参加からやり直すのを推奨します。

５．時刻同期設定

・対象サーバがADドメインに参加しているなど、諸々の条件がサーバによりあるかと思いますが、時刻同期先はAWS移行後は、AWSのNTPを参照するよう修正するのを推奨します。

６．不要物削除

・物理サーバや異なるプラットフォームの仮想環境間の移行の場合は移行後にHWベースの管理ツールやVMwareToolsのような仮想ドライバ等の不要なものが発生します。トラブルの原因となるので削除を推奨します。

７．単体確認

・疎通確認、稼働確認（サービス、プロセス）、ログ（イベントログやシステムログ）確認など、実施してください。

８．引渡

・アプリ担当者など次工程の方に引き渡ししてください。もし仮に各種自動で起動する設定を停止・無効化していた場合は、そのままにし、アプリ担当者など責任のある方に有効としていただくよう申し伝えることを忘れないでください。

４．まとめ

ここまでいかがでしたでしょうか。

サーバの移行・移設だけに注目すると事前調査、事前準備をしておけば、そんなに難しくはありません。

トラブルの原因は大抵は調査漏れ・準備漏れが多いです。移行PRJという観点からも調整不足などがスケジュール上の遅延原因となることが多くなります。