🚴🏻‍♀️

【CloudEndure】AWSの基礎を学ぼう特別編

2021/09/03に公開

AWS

感想

tech

概要

「AWSの基礎を学ぼう特別編」で”AWS Application Migration Service / CloudEndure”のハンズオンイベントに参加した感想ページです。

「AWS エバンジェリストシリーズ　AWSの基礎を学ぼう」とは

AWS エバンジェリストシリーズ　AWSの基礎を学ぼう

以下、Connpassページより引用

Amazon Web Services (AWS)は現在200を超えるサービスを提供し、日々サービスの拡充を続けています。
このAWS エバンンジェリストシリーズでは週次でAWSのサービスをひとつづつ取り上げながらその基礎を説明していく初心者、中級者をターゲットとした講座です。午後の仕事前にスキルアップを一緒にしませんか？
注意点登壇者による発表内容はアマゾンウェブサービスジャパンとして主催しているものではなく、コミュニティ活動の一環として勉強会の主催を行っているものです。

毎週ありがとうございます！

FAQ

Q: AWS Application Migration Service とは何ですか?

AWS Application Migration Service (AWS MGN) は、AWS へのリフトアンドシフト移行に推奨される主要な移行サービスです。AWS Application Migration Service は、ソースサーバーを物理、仮想、またはクラウドのインフラストラクチャから AWS でネイティブに実行するように自動的に変換することにより、AWS への移行を簡素化および迅速化します。アプリケーション、そのアーキテクチャ、または移行されたサーバーを変更することなく、同じ自動化されたプロセスを幅広いアプリケーションに使用できるようにすることで、移行をさらに簡素化し、コストを削減します。AWS Application Migration Service を使用して、カットオーバーの前に無停止のテストを実行できます。テスト後、AWS Application Migration Service を使用して、通常は数分で測定される短いカットオーバーウィンドウ中に、アプリケーションをクラウドにすばやくリフトアンドシフトできます。

Q: AWS Application Migration Service と CloudEndure Migration の主な違いは何ですか?

AWS Application Migration Service は、次世代の CloudEndure Migration であり、CloudEndure Migration では利用できない主要な機能と運用上の利点を提供します。例えば、AWS Application Migration Service を使用すると、次のことができます。

AWS マネジメントコンソールからサービスを運用します。
CLI と SDK だけでなく、移行固有のワークフローにより適した新しい API を使用します。
Amazon CloudWatch と AWS CloudTrail を使用して、AWS Application Migration Service をモニタリングします。
AWS Identity and Access Management (IAM) を使用して許可とアクセスを制御します。
タグを使用してソースサーバーを整理し、アクセス許可を制御します。
公共インターネットに接続せずにサービスを運用します。
移行メタデータは、移行されたインスタンスと同じ AWS リージョンに保存します。
(Blueprints ではなく) Amazon EC2 起動テンプレートを使用して、テストインスタンスとカットオーバーインスタンスを起動する方法をより適切に制御します。
AWS Application Migration Service は、まだすべての AWS リージョンでサポートされているわけではなく、現在、CloudEndure Migration でサポートされているレガシーオペレーティングシステムをサポートしていません。ご希望の AWS リージョンまたはオペレーティングシステムが現在 AWS Application Migration Service でサポートされていない場合は、CloudEndure Migration の使用を検討してください。

言葉の確認

カットオーバー

新たに導入したコンピューターシステムや通信システムが稼働し始めること。また、ウェブサイトが新規に公開されること。サービスイン

今回やりたいこと

AWSさんのハンズオン資料をベースに整理する。

構成図１

VPCを３つ作る。

VPC作成後

サブネットも作っていますが、省略

構成図２

SourceVPCにWordPressを立てる。

WordPress確認

起動したよ。

構成図３

CloudEndureの設定&USER作成

CloudEndureでのプロジェクト作成

左上の

プロジェクト名を入れる

AWSのクレデンシャル情報を求められるので「The Project must have these permissions」に記載されているユーザーを作る

IAM USER作成

CloudEndureでREPLICATION SETTINGS

Migration Source: Other Infrastructure
Migration Target: Tokyo
Choose the subnet where the Replication Servers will be launched: StagingVPC

構成図4

Agentのインストール

SoruceEC2に対して指定されたコマンドでAgentをインストール

Linux machinesの２個のコマンドを実施。

実行結果

[ec2-user@ip-10-0-0-36 ~]$ sudo python ./installer_linux.py -t 208D-F2B0-2539-27EB-A5DD-DBFF-6F38-9EDB-2DCA-796E-9B1E-1A1A-F8E2-A4B0-F91E-F64B --no-prompt
The installation of the CloudEndure Agent has started.
Running the Agent Installer for a 64 bit system...
Connecting to CloudEndure Console... Finished.
Identifying disks for replication.
Disk to replicate identified: /dev/xvda of size 8.0 GiB
All disks for replication were successfully identified. Auto disk detection is on.
Downloading CloudEndure Agent... Finished.
Installing CloudEndure Agent... Finished.
Adding the Source machine to CloudEndure Console... Finished.
Instance ID: i-07f0782ffc876af2f.
Installation finished successfully.
[ec2-user@ip-10-0-0-36 ~]$

レプリケーションが動き始めます。

構成図５（レプリケーション完了後）

レプリケーションサーバーのセキュリティグループについて

以下SG設定となっています。

TCP：1500
SourceEC2からのデータ同期として利用
TCP：443
CloudEndureのサイトと連携
UDP：53
DNS問い合わせかな？

ボリュームについて

SourceEC2
SourceEC2にアタッチされているボリューム
名無し
ReplicationServerにアタッチされているボリューム
CloudEndure Volume con17
ReplicationServerにアタッチされているボリューム
多分こっちに同期されたデータが入っている。
CloudEndure Base Snapshot
ReplicationServerの元ネタになるSnapshot？　なおスクショには入ってないけど削除中のステータス

カットオーバー実施

構成図６（カットオーバー完了後）

妄想や想定ありあり

EC2（カットオーバー完了後）

作成された時系列順（妄想や想定ありあり）

SourceEC2
Sourceサーバー　移行元のサーバー
CloudEndure Replication Server con17
Replicationサーバー　移行元と同期を取るサーバー
CloudEndure Machine Converter con17
Converterサーバー Targetサーバーの移行元のスナップショットを作るサーバー
ip-10-0-0-36.ap-northeast-1.compute.internal
Targetサーバー　移行元のサーバー

EBS（カットオーバー完了後）