LoginSignup
5
3

More than 1 year has passed since last update.

AWS移行 - CloudEndure MigrationでのEC2移行検証

Last updated at Posted at 2021-07-30

 本資料は、初めてCloudEndureを使ってオンプレミスまたはAWS以外のクラウドサービスからAWSへサーバを移行する人が、移行時間が実際に何分くらいかかるのかを検討する際の参考資料として作成しました。

 この検証はAWS内で実際にCloudEndure Migrationを使って、仮想マシンを移行し、その際の時間を測定しています。最大1TBのデータを移行していますので、移行時間の見積もりの参考になれば幸いです。
 また、この資料では移行を検討する際のポイントに絞って紹介しています。具体的な移行手順、前提条件、制限事項等についてはAWS社が公開しているドキュメントを参照下さい。 → https://docs.cloudendure.com/

 (参考情報)
 2021年5月から東京リージョンにて「AWS Application Migration Service」が利用可能です。このサービスはCloudEndure Migration と同様の機能を提供しますが、違いはAWS マネジメントコンソールで利用できます。さらに、AWS CloudTrail、Amazon CloudWatch、AWS Identity and Access Management (IAM) などの他の AWS のサービスとのシームレスな統合が可能になっているそうです。
 また、実際に「AWS Application Migration Service」を使って検証していないためあくまで推測になりますが、移行時間についてはCloudEndureと同等になると想定されます。

1.CloudEndureの特徴

 主な特徴をあげます。

  • 切替直前までデータ同期を行うため、切り替え時のダウンタイムを短く出来る(最小数分)
  • 元々は有償ツールだったが、AWSが買収し2019年1月から無償(※1)利用が可能。
  • 従来AWSのサーバ移行ツールとして提供されていた「VM Import」「Server Migration Service(SMS)」による移行と比較し、少ない手順にて簡単に移行が可能。
  • 日本国内(他社事例)において「CloudEndure」を使って数百台の移行事例あり。(海外では数万台の実績があるそうです)

(※1)CloudEndure Migration自体は無償にて利用可能ですが、移行の為に利用するAWSリソース (例:後述のReplicationサーバ)や、移行後の仮想マシン(EC2)につきましては、従来通り課金されます。

2.対象者

  • 対象読者: AWSへのサーバ移行にかかわるエンジニア
  • 前提知識: オンプレミスでの物理サーバ移行、仮想サーバ移行の経験またはAWS認定クラウドプラクティショナー(初級レベル) 程度の知識を有していること

3.CloudEndure概要

 CloudEndureとは、AWSが提供するエージェント導入型の移行 / DR支援ソリューションです。

  • ソリューション概要
    • 2018年末にAWS社がCloudEndure社を買収
    • エージェント導入型の移行、DRを実現(※1)
    • 高速な切り替えを実現
    • 移行ソリューション自体は無償利用が可能
    • インターネット接続が必須(可否判断要(※2))

​ (※1) DRは別途有償ライセンスが必要となります
​ (※2) 認証付きプロキシが未サポート。ホワイトリスト登録にて対応必要。

 詳しくは次のドキュメントに詳しく解説されています。ご参照下さい。
  Amazon Web Services ブログ
  [AWS Black Belt Online Seminar] CloudEndure 資料及び QA 公開
  https://aws.amazon.com/jp/blogs/news/webinar-bb-cloudendure-2020/

 また、具体的な操作手順はAWS社のハンズオンが参考になります。
 https://application-migration-with-aws.workshop.aws/ja/server-migration.html

  • CloudEndure Migrationの処理の特徴
    • 仮想マシン全体を移行します。
    • CloudEndure エージェントが常駐し、データをReplicationサーバへ随時転送します。
    • 移行先サーバは、仮想マシン全体の同期後、任意のタイミングで作成します。
      image-20210728160037980.png

4.検証概要

 CloudEndureを使って移行するための手順をまとめると次のようになります。詳細は公式ドキュメントを参照下さい。
image-20210714162428654.png

 また、CloudEndureを使って移行する際には、次の点にご注意下さい。詳細は公式ドキュメントを参照下さい。

  • 1.移行元サーバからAWSへのアウトバウンド通信必須(httpsと1500番ポート
     (1500番ポートはDirect Connect またはVPN経由に変更は可能)
     補足:実際の環境では、1500番ポートを既存FireWallにて通すことは困難と想定。
      詳しいネットワーク要件は、”付録.CloudEndureに関するFAQ”のQ:6を参照。

  • 2.認証付きのプロキシが現段階 (2021年3月)では使えません
    (インターネット直接続、認証無しプロキシまたはプロキシへホワイトリスト登録が必須条件)
    補足:今回の検証ではプロキシを使用していないため問題になりませんでした。
    しかし、実際のオンプレミス環境ではプロキシを経由することが一般的です。

  • 3.移行元サーバへエージェントインストールが必須
    (CPU負荷や業務影響を心配しインストールが許可されないケースが想定されます)

 次に、今回の検証における構成の概要図を以下にしまします。
image-20210728160112320.png

 今回の検証では、処理時間の傾向を把握するために3パターンのDISKサイズのVMを移行しました。
image-20210721175617842.png

検証環境の構成

  • 検証環境は、AWS 東京リージョン
  • 移行元サーバは、ap-northeast-1aに配置
  • Replicationサーバ、移行先サーバは、ap-northeast-1cに配置
  • 移行元サーバのインスタンスタイプは、  t3.large(2コア、メモリ8GB)、 OSはWindows Server 2019
  • Replicationサーバのインスタンスタイプは、t3.small(デフォルト値)
  • 各サーバのEBSは、汎用SSD(gp2)を使用
  • 検証パターン別のEBSの割当とDISKの使用量は以下を参照。
検証パターン DISK1(使用/割当) DISK2(使用/割当) DISK3(使用/割当)
30GB 15GB/30GB なし なし
580GB 15GB/30GB 500GB/550GB なし
1130GB 15GB/30GB 500GB/550GB 500GB/550GB
  • テストデータは、次のPowerShellスクリプトにて1GBのランダムテキストのファイルを作成し、このファイルを必要な容量分だけコピーしました。
$random_bin = new-object byte[] (1024*1024*1024); 
(new-object Random).NextBytes($random_bin); 
[IO.File]::WriteAllBytes("c:\temp\test.txt", $random_bin)
  • テストデータ内容 image-20210714161840484.png

5.検証結果

 CloudEndureを使って移行した場合の処理時間の測定結果は以下のようになりました。

  • 起動時間は、10分以内(DISKサイズが増えても変わらなかった)
  • 初期同期時間は、DISK容量に比例
  • 転送性能は、1.0GB/分以上 image-20210714162505519.png

6.注意事項

 検証結果を参照する際には、次の点にご注意下さい。

  • 1.初期同期の速度は、進捗率が進むほど悪化していました。今回の環境では16MB/秒~43MB/秒と差がありました。ただし43MB/秒のパターンは、途中までの初期同期時間しか測定出来なかったため、例外と判断下さい。傾向として同期開始から約150GBの転送までは、約50MB/秒の性能が出ていましたが、それ以降は徐々に性能劣化の傾向が見られました。

  • 2.今回使用したEBSは、移行元、移行先ともに汎用SSD(gp2)です。
      (550GBのEBSをDISK Read性能を測定した結果、200MB/秒以上出ていました)

  • 3.移行元と移行先間のAZ間の通信性能は、実測60MB/秒以上出ていたため、 ネットワークがボトルネックではないと考えられます。

  • 4.これとは別に2パターンテストを実施した結果では、約16MB/秒の初期同期の処理性能でした。

  • 5.起動時間はインスタンス起動までの時間です。アプリ起動は別途必要です。

7.付録 CloudEndureに関するFAQ

Q1: CloudEndureの実績はどれくらいありますか?メーカーはどこか?サポート体制は大丈夫か?
A: 2020年1月時点で、数万以上のサーバの移行実績があるときいています。メーカーのCloudEndure は、2018年末にAWSに買収され現在は AWS グループ企業。サポート体制は、EC2などと同様にAWSコンソールからAWS Supportへ問い合わせ可能です。問い合わせ時に日本語または英語かを選べます。

Q2: なぜCloudEndureを選択するのか?他の移行ツールは何があり、違いはなにか?
A: 1番の理由は切替時のダウンタイムを短くすることができるためです。(目安は5分~10数分)90日間は無償にて利用可能です。他のツールに対する優位性は、移行が高速(S3へのコピーが不要。データ転送時の圧縮。ブロックレベル複製)仮想サーバと物理サーバの両方に対応。操作がシンプルかつ少ない手順。他のツールとしては、Server Migration Service(SMS)、VM ImportがAWS社としてあります。また、AWS社以外からも移行ツールやサービスが出ています。

Q3: 価格は?前提条件や制限は?
A: CloudEndure Migration の各無料ライセンスは、エージェントのインストール後 90 日間使用できます。 CloudEndure Migration の使用は無料ですが、移行中と移行期間後にプロビジョニングされる、 コンピューティング(EC2)やストレージ(EBS)のリソースなどの AWS インフラストラクチャに対して料金が発生します。前提としては、対象サーバにエージェントがインストールされます。そのため、対象サーバに負荷が生じます。また、CloudEndure DRは有償です。

Q4: サポートOSは?
A:サポート対象の Windows Linux OS のバージョンで実行されているすべてのアプリケーションとデータベースを移行できます。これには、Windows Server 2003/2008/2012/2016/2019 バージョン、および CentOSRHELOELSUSEUbuntuDebian といった Linux ディストリビューションが含まれます。

Q5: どのような移行方式なのか?
A: エージェント導入型の移行サービス。制御はCloudEndure 専用ポータルから行います。AWS側にReplicationServerが少なくとも1台構成されます。ここに移行元のデータが複製されます。データの複製後もリアルタイムで非同期で、データの同期を継続します。テストや本番時に、EC2を展開します。展開の際にAWS用に変換処理が実行されます。

Q6: インターネット接続は必須か? 必要な場合の具体的な要件は?
A: 必須です。CloudEndureポータルはインターネット上にあり、そこへのOutBound通信が必要です。また、移行元からReplicationサーバーへのデータ伝送にインターネットを選択した場合には、ReplicationサーバーへのInbound通信も発生します。VPNやDirect ConnectでAWSへ接続する場合には、データ伝送時にインターネット接続は不要ですが、制御のためにCloudEndureポータルとの通信は必須です。具体的には、下図の破線円で示した①②③④がインターネット接続部分になります。
image-20210715113752435.png

インターネットと接続する3か所(①②③)については次の通信要件があります。④についてはAWSのAPIを呼ぶためのユーザと権限等の設定が必要です。
image-20210715120440304.png

ネットワーク要件の詳細は次の“CloudEndure Documentation”の“Network Requirements”を参照下さい。

Q7: エージェントの負荷による業務影響はどの程度か?
A: システムのパフォーマンスに目立った影響を与えることもありません(以前存在していたAWS社のHPより抜粋)

Q8: エージェントのインストール後にOS再起動が必要か?
A: 不要です。

Q9: 切り替え時のダウンタイムはどの程度の時間が必要か?
A: Q2にも記載したが、5~10 数分が目安です。

Q10: 移行が出来ないような事例はありましたか?
A: 今回の検証ではありませんでした。ただ、EC2の制限により1台のインスタンスに20個程度までしかEBSを接続出来ません。そのためEC2の制限以上のDISKを1サーバに接続している場合は移行できません。移行元でDISK数を集約出来ればCloudEndureでの移行が可能になります。

  参照 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/volume_limits.html

Q11: ユーザ側でする作業は何がありますか?
A: 主に以下の作業があります。

  • 環境準備:インターネット接続のためのネットワーク変更、無償ライセンスの取得、AWSアクセスキー準備
  • 移行対象の準備:移行対象の決定、エージェントのインストール、移行後の各種ライセンス準備
  • データ同期中: 進捗の確認
  • 切り替え時: 移行対象の停止、移行に伴う各種設定変更、動作確認

Q12: どれくらいの移行期間が必要でしょうか?
A: 1台のサーバを移行するための時間は、主に次の要素で決まります。

  • 移行元のDISK読み取り性能
  • 移行元からReplicationサーバまでのネットワーク転送性能
  • ReplicationサーバのDISK書き込み性能
  • 移行準備、テスト、本番までの待機時間

 CloudeEndureは、300台程度(※1)までは同時移行が管理可能なツールです。
 ネットワーク帯域の確保のうえ、複数サーバを並行移行することで、短期間で移行が可能です。
(※1)300台程度:CloudEndure内のプロジェクトを分けることでそれ以上の管理は可能

Q13: CloudEndureの利用期間(エージェントのインストール後90日間)は、サーバ単位か? また、90日が過ぎた場合、移行は可能か?
A: 90 日の無料期間後、ユーザーのマシンではレプリケートが停止し、新しいターゲットマシンは起動できなくなります。90 日の無料期間内に移行を完了させることができなかった場合でも、新しい CloudEndure Migration アカウントを使用して該当するマシンに CloudEndure エージェントを再インストールすることにより、引き続き無料で移行できます。そうすることで追加の 90 日の無料期間中、レプリケーション、テスト、移行を実行できるようになります。

Q14: データの転送性能は?帯域制御等の機能がありますか?
A: データの転送性能は、16MB/秒~43MB/秒と検証結果はばらつきがありました。(例:1.1TBが19時間)また、ネットワーク帯域幅調整オプションを使用すると、ネットワークトラフィックを調整し、帯域幅の輻輳を最小限に抑えることができます。ソースマシンから TCP ポート1500のステージング領域に送信されるデータの転送速度を制御する場合は、このオプションを有効にします。データ転送速度は Mbps 単位で設定できます。設定は、 Setup & Info > REPLICATION SETTINGS. ページにて行います。詳しくは、次を参照下さい。
  https://docs.cloudendure.com/#Defining_Your_Replication_Settings/Defining_Replication_Settings_for_AWS/Defining_Replication_Settings_for_AWS.htm
image-20210712151853675.png

Q15: データ転送が途中で中断した場合、途中から再開可能か?
A: ソースマシンのコンテンツのブロックレプリケーションが開始され、コンテンツがステージング領域にコピーされます。レプリケーション中は復旧ポイントが作成されるため、切断時に最後のポイントからレプリケーションを続行できます。
    参照資料:https://docs.cloudendure.com/#FAQ/FAQ/Replication_Related.htm

Q16: 物理サーバからAWSへ移行する場合、デバイスドライバーなどは自動調整されますか?
A: 本番用マシンの起動準備ができると、マシンは CloudEndure Migration によって自動的にソースインフラストラクチャから AWS インフラストラクチャへと変換され、AWS でネイティブに起動し、実行できるようになります。

Q17: 複数サーバの同時移行が監視可能とのことだが、どのような監視項目がありますか?

A:複製対象マシン名毎のDISK容量、DISK*複製進捗率、DISK複製完了までの残り時間*、STATUS((!)エラー有無、🏴注意必要/否、🚀データ複製完/未、🏢ターゲットコンピュータの起動完/未)と、Test mode/Cutover modeの状況が一覧で確認可能です。また、詳細画面ではターゲットコンピュータ作成後のインスタンスID、IPアドレス等が確認可能です。
image-20210712152113238.png

image-20210712152122220.png

image-20210712152132907.png

Q18: CloudEndure MigrationとDisaster Recoveryとの違いは?
A: Migrationは90日の期間内でAWSへ移行するための一時的なツールです。一方のDisaster Recoveryでは、対象マシンをAWSにあるステージング領域にレプリケートし続けます災害発生時には、数十分のうちに、完全にプロビジョニングされた状態の、数百台のマシンを自動で起動するように、CloudEndure Disaster Recovery を設定できます。また、DRサイトからメインサイトへのFailBackにも対応

Q19: 移行がサポートされないアプリケーションやファイルシステム等、既知の制限がありますか?
A: CloudEndure Migration は、ERPパッケージや、一般的なデータベースもサポートしています。 既知の制限については、例えば次のような条件があります。

  • WindowsのGPT パーティションとDynamic ディスクをサポートしていません。
  • XFS5 ルートまたはブートファイルシステムを使用する Linux マシンはサポートされていません。
  • EC2の制限以上のDISKを接続している(通常は20個程度が上限)場合はサポートされません。

 サポートOSの詳細については、次を参照下さい。
   https://docs.cloudendure.com/#Getting_Started_with_CloudEndure/Supported_Operating_Systems/Supported_Operating_Systems.htm

Q20: ツールの利用手順書やマニュアルが日本語でありますか?また、どこにありますか?
A: マニュアルは英語のみが現在提供されています(2021年2月時点)。
  マニュアルは次のURLを参照下さい。
     https://docs.cloudendure.com/

  2021年7月現在、CloudEndureを使う前に、AWS Application Migration Service (AWS MGN) の利用が推奨されています。詳しくは次のURLを参照下さい。
     https://aws.amazon.com/jp/application-migration-service/

Q21: ツールの使い方やエラー時の問い合わせ先はAWS Supportか?それとも他にありますか?無償か?
A: AWS Supportへ問い合わせ可能です。AWS Supportのプランに応じて費用が変わります(有償)。(CloudEndureのための追加費用はかかりません

以上です。移行の参考になれば幸いです。

5
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
3