#1.仕組み図
#2.移行前の準備
-
1 まずCloudEndureアカウント取得
- ユーザー:xxx＠xxxx
- パスワード:xxxxxxxx
-
2 CloudEndureアカウント登録
- リンクアクセス
- リンク: https://console.cloudendure.com/#/signIn
- 登録
-
3 CloudEndureプロンプト作成「重要」
- 1.新しいプロジェクト作成
- 2.AWSアカウントIDとCloudEndureが関連されるため、アクセスキーとシークレットキー入力する。
- 1.新しいプロジェクト作成
アクセスキーとシークレットキー取得方法について,下記のリンク参考する。
- 4 AWS Cli v2のセットアップ及びパソコン紐づけ
AWS CLi v2インストール方法について、下記のリンク参考する。
https://dev.classmethod.jp/articles/how-to-install-aws-cli-v2-on-windows/
#3.レプリケーションサーバー設定
画面上の「REPLICATION SETTINGS」タブを選択すると以下の画面になりますので、以下項目を設定します。
- Migration Souce:ソースの場所です。オンプレミス未対応しているのでその場合には「Other Infrastructure」を選択します。
- Migration Target:移行先の場所です。今回は「AWS Asia Pacific(Tokyo)」を選択します。
- Replication Servers:レプリカサーバーの詳細です。
インスタンスタイプ、VPC、サブネット、セキュリティーグループを選択できます。
こればレプリカする際に自動的に起動するサーバなので、適当に「t3.large」と、レプリカ先のサブネットを選択しました。最後に右下の「SAVE REPLICATION SETTINGS」をクリックして設定項目を保存します。
#4.レプリカ準備を開始する
この手順を実施すると、レプリカサーバが自動帝に起動して、移行元サーバのイメージ転送が始まります。
そして初回の転送が終わると、それ以降ずっと差分を転送し続けます。
初めにCloudEndureのWeb画面で右メニューから「Machines」を選択します。
すると、以下の画面になりますので、「Download・・・」を右クリックして「リンクのアドレスをコピー」します。
#5.レプリカはインストールが終わったら自動開始
CloudEndureのWebのリンクの下の行にあるコマンドをコピーして、サーバのコマンドラインにペーストして実行します。
インストールが成功すると以下のようになります。
このように成功すると、この瞬間から自動的にレプリカが始まります.
まずはこのグラフが100%に達するまで待ちましょう。
WindowsServer2008にAD機能を追加しただけのサーバはおよそ10分で完了しました。
#6.デプロイのテスト実施
デプロイ前にパラメーターを確認しよう
ここまでくればあと一息です。
ワンタッチで目的のサーバをデプロイしましょう。
デプロイはCloudEndureのWebコンソールで右メニューのMachinesから目的のサーバを選択し、画面下の「LAUNCH TARGET MACHENE」から「TEST MODE」を選択するだけです。
が、その前にどのようにデプロイするのか設定を確認しましょう。
以下のように「BLUE PRINT」タブに多くの設定項目が並びます。
特に留意する必要があるのが、以下になります。
Machine Type
インスタンスタイプを選択します
「Copy Source」で同じようなスペックも自動選択できますが、なぜかより大きなインスタンスタイプとなりました
Subnet
事前に作成しておいたサブネットを選択します
Security Group
事前に作成しておいたセキュリティグループを選択します
Private IP
「Custom」を選択して新しいVPC・サブネットに適切なものを設定します
Disks
ディフォルトで「Provisioned IOPS SSD」が選択されるため、「汎用SSD」で十分な場合には要変更です
ここまで確認出来たら、実際にデプロイしてみましょう。
#7.デプロイはワンタッチ
テストを選択すると以下のように確認が求められるので「CONTINUE」をクリックするとすぐにデプロイが始まります。
画面右上に下のような表示が出たら、デプロイが始まりました。
CloudEndureのWebコンソールで進捗を見てみましょう。
右メニューの「Job Progress」をクリックすると現在進行中の進捗を確認することができます。
まずはレプリカされたディスクから仮想マシンへコンバートするジョブが走ります。
ちなみにこの画面は開きっぱなしてしていても自動で更新されます。
このフェーズでAWSコンソールを見てみるとコンバーターが1台新規で出来あがります。
コンバートが終わって、新サーバの作成が始まると「Starting Creating…」に表示が変わります。
Job finishedと記録されました。
AWSコンソールを見てみると・・・
できました！
しかし、なぜかインスタンスタイプが「C4.large」になっています。
「Copy Source」を選択せずに指定したほうが良いかもしれません。後で変えられますが。
#8.テストのデプロイが完了したので接続します
早速接続してみましょう。
「パブリックIP」をコピーして…
お！RDPは有効になっていますね！
おっ！これも来た！いけるかっ？！
ここ、ドキドキしますね～
来ました～～～！
電源ONし続けている間にレプリカし続けるという仕様上、突然電源をぶち切られたような状況になるため、この表示が出ることは仕方ありませんが、逆にきちんとレプリカで来ていたことがわかると思います。
#8.テストデプロイされたサーバーの状況は？
判明しているところとしては、IPアドレスやDNSサーバはDHCPに強制的に変更されます。
AWSはそれを推奨しているので当然ですね。
そのため、IPアドレスの固定はレプリカ時に、DNSの指定はDHCPオプションセットで行いましょう。
以上、テストのデプロイまででした
ちなみに、テストのデプロイを繰り返した場合、既存のデプロイされたインスタンスは自動的に削除され、最新のものだけが残るような動きとなりますので、無駄なゴミが残ることはないようです。
#カットオーバーでデプロイする
テストのデプロイで問題がなかった場合には、本番のデプロイとして「Cutover」を実施します。
Cutoverの場合には、サブネットからインターネットGWからセキュリティグループなどをクリーンアップしているログが出ています。
時間的にはテストとほぼ同じで、18-19分程度で出来上がりました。
#9.カットオーバーされたサーバーの状況は？
早速リモートデスクトップしてみます。
コピーして…接続！と。
来ました！
よし！成功！