【AWS】MGNを使ったWindowsサーバーの移行に苦労したお話
オンプレミス→AWS関連の連携は原因がAWS側なのか、オンプレ側なのかの切り分けが難しくて毎回時間を使っているよーめいです。
MGNとは
MGNとは「AWS Application Migration Service」の略で、オンプレミスのサーバーをAWSに移行するためのマネジメントサービスです
移行とモダナイゼーション - AWS Application Migration Service - Amazon Web Services
AMSって略なんじゃないの？って思うかもしれませんが、AMSは「AWS Managed Service」があるため、こうなっていると思われます
AWS Managed Services (お客様に代わりAWSを運用) | AWS
今回は急遽オンプレのWindows2008サーバーをMGNを使って移行する際に苦労した話ですが、Googleで調べても同エラーにぶつからず、非常に苦労したので備忘録兼ねて書くことにします。
MGN利用のきっかけ
当初は移行実績のあるCloudEndureを利用してサーバー移行を検討していました。12末でサービス終了するけど、ギリ間に合うやろって
が…
エージェントをインストールしようとしたら、エラーが出てエラーのメッセージ見たら、なんと2022/9/30を最後にエージェントの新規インストールが出来ないじゃないですか……
このため、急遽MGNを利用したサーバー移行に切り替えることになりました。まあCloudEndureとMGNは類似サービスだし、割と使いまわしでいけるやろって高を括っていました。この時までは…
ちなみにCloudEndureとMGNとの比較はいつもお世話になっているクラメソさんのページが分かりやすいです。
MGNの構成図
MGNではこのような構成で動いています。
そのため、ネットワークの穴あけが正しく出来ていないとエラーを吐きまくります。
めっちゃ余談だけど、MGNはサポートページも管理画面も全部英語がデフォなので、読み解くのに若干苦労するのが辛い
ハンズオンではインターネットの環境を使って各種連携を行っていますが、顧客環境にはDirectConnectという専用線が引いてあるので、プライベートネットワークにてサーバー移行を行おうとしていました。
またもクラメソのページを参考に手順を確認していました
手順も作るものも分かるので、記載の通りエンドポイント作って、S3のGateway型エンドポイントは既にあるから良いとして、残りもシンプルだし、さほど苦労しないだろうと思っていたのですが、ここから地獄の始まり……
苦労1：エージェントがインストールできない
初っ端のエージェントインストールで苦労します。エラーログには
botocore.exceptions.SSLError:SSL validation failed for https://mgn.ap-northeast-1.amazonaws.com/VerifyClientRoleForMgn?clientType=source-server EOF occeredin violation of protocol(_ssl.c:1131)
このエラー、ググってもピンポイントでヒットするものが何もなく初っ端で詰まります。VerifyClientRoleForMgnがクライアントロールを確認する許可を付与するってのは分かりますが、それ以上何も分かりません。
どこの原因か分かりませんが、とりあえずオンプレとMGNを結ぶ443の通信でエラーになっているのは分かります。
この原因がオンプレ側のFWが空いていないのか、AWS側で塞いでいるのか、はたまたIAMユーザー周りの権限がイケていないのか、割と多岐に渡っていて暗礁に乗りかけましたが、この前に一つ別のエラーが出て解消したものがあり
最初以下のエラーが出て
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1131)
ルート証明書を入れて解決したのですが、これを共有した先輩に
「よーめいさん、ここにあるルート証明書全部入れましたか？ルート証明書周りが怪しいかもしれませんよ？」
Amazon Trust Services Repository
これ全部入れたら無事同エラーが出なくなりました。今回のサーバーはWindows2008サーバーだったので、当然にAWS関連の証明書は入っていなかったですね……
苦労2：またもエージェントのインストールに失敗する
エラーログを見ると、CloudEndure関連のサービスが競合している的なメッセージが出てきていました。
Troubleshooting Agent Issues - Application Migration Service
調べると「Installation Cannot be completed - CloudEndure Agent」の箇所にCloudEndureとサービス競合しているとあかんよ的なことが書いてあるので、ここに記載のコマンド実行したけど解決せず。
エラーログに記載というかCloudEndure関連のサービスを全て削除したら、ようやくMGNの画面に該当サーバーが連携されるようになり、レプリケーションの準備が整った訳です。
苦労3：またも通らない認証
レプリケーションを開始する処理で、「Failed to authentiacate with service.」というエラーが一向に解消されません。
ここが本当に苦労しまくって色んな人巻き込んで多角的に調査しても解決せず。
こうなったら一つ一つポートが通るのか分解して確かめようとなり、調べていく中でオンプレミスサーバー⇒レプリケーションサーバのTCP1500が通るか確かめるために、同VPC・サブネットの中にEC2を立ててhttpdを入れてTCP1500ポートをListen状態にして、通信テストコマンドから疎通確認をしようとしました。
同サブネットはプライベートサブネット内なので、当然にyumを利用したhttpdのインストールができず以下のサイトを参考にしました。
いやーーここにある通り、既にGateway型のS3のVPCエンドポイントあるよなぁ。経路の紐づけも既に行われているよなぁ。何かポリシーで制御でもしているんかなぁ？
と、VPCエンドポイントのポリシー設定を見て気づきました。
"Resource":["特定のバケット指定"]
なんだーー特定のバケットにだけ疎通が許可されているじゃーん。これじゃあyum通らないよねー
あ……
おまえかあああああああああああああああああ！！！！！
上記サイトを参考にVPCエンドポイントを作る際、同VPC配下に他の人が作ったS3_Gateway型のエンドポイントが既にあったので、それを使いまわせばいい（と言うより同VPCに同じものは作れない）と思って大して見ませんでした。
ここの設定を幅広くした瞬間、秒で認証が通りレプリケーションは完了しましたとさ。ちゃんちゃん。
まとめ
色々な原因はありますが、元々他の人が設定しているありものも原因なことが多いですよってことで、ググっても同じポカや見落とししている人がいなかったので、備忘録として投下しました。
悪い事だけじゃなくてネットワークの設定等やサブネット等、VPC周りの理解がぐっと深まったのはアドだったと捉えることにします。
願わくば他の人が立てたエンドポイントの設定を見落として余計な残業や後れを取り戻すための休日のサビ残をする人が一人でも減れば、僕は幸せです。
ではでは。
