はじめに
ここ最近、MGNを使ったWindows Serverの移行を行ったのですが、Windows Server特有の注意点がいくつかあることに気がつきました。
公式ドキュメントの「トラブルシュート」に記載されている内容と一部重複しますが、実際に遭遇し対応したものについて詳しく記載していきます。
お決まりの免責事項ではありますが、Microsoftのライセンスに関する内容については、必ずMicrosoftへの問い合わせを行なって裏付けをとってください。
AD参加しているWindows Serverを移行する場合は、同一コンピュータ名のサーバーが2つ以上存在しないような移行計画を作成する
これはよく考えれば当たり前な観点なのですが、重要な観点なので記載します。
前提として、同一ADドメイン配下でコンピュータ名が重複するとトラブルの元になります。
もしやってしまった場合、ADの情報を上書きするような挙動になるので、既存サーバーとADとの間の連携に問題が生じます。
MGNエージェントを使って移行した場合、カットオーバーは既存サーバーが起動したままの状態で実行できます。そうすると、既存サーバーと新サーバーでコンピューター名が重複したタイミングが発生します。
なので、新サーバーをADに参加させる前に、あらかじめ既存サーバーを停止しておく必要があります。
商用環境のサーバー移行を行う場合は、このタイミングでアプリケーションの動作確認やサービス切り替えも実施することになると思います。
どのタイミングで新サーバーをADに参加させるのか、段取りをよく考えた上で移行計画を作っておきましょう。
sysprepの実行について
コンピューター名と同じような観点で気をつけたいのは、Windows ServerのSIDです。
MGNを使って移行すると普通はSIDも引き継がれますが、SIDを書き換えたい場合にはsysprepを実行する必要があります。
ただし、sysprepを実行してしまうとSIDを元に戻すことはできなくなり、移行前のサーバーとは異なる属性を持ったサーバーがAWS上に移行されてきます。
sysprepを実行すべきかどうかは場合によって判断が異なるのですが、以下のような場合はsysprepの実行を検討した方が良いです。（あくまでも一例です）
- 新サーバーの起動時にステータスエラーが発生する、新サーバーがAD参加できない、などの不具合が発生した場合
- 既存サーバーと新サーバー、どちらもADに参加した状態で並行稼働させる場合
なお、sysprepエラーが発生する可能性もあるので、事前に検証した上で移行を行うことを推奨します。
MGNを使う場合であれば、テストインスタンスでsysprepを実行してみて動作検証を行いましょう。
ちなみに、実際に既存サーバーと新サーバーが並行稼働するというパターンの移行を行ったことがありますが、その際はsysprepを実行しなかったです。
sysprepを実行してしまうとアプリケーションが正常に動かなくなるという過去事例がある、一時的な並行稼働であるためSIDの重複を許容する、などの理由によりsysprepを実行しませんでした。
事前の検証を十分行った上で、必要に応じてsysprepの実行も移行計画に組み込むことをお勧めします。
Dynamic Diskを利用している場合はインスタンスの起動に失敗する
まず前提として、Windows ServerのディスクにはBasic DiskとDynamic Diskの2種類が存在します。
すごくざっくり違いを説明すると、Basicの場合は直感的にパーティションを区切るのに対して、Dynamicの場合は複数ディスクを跨いぐなどの高度なパーティション設定ができるという違いがあります。
一般的にはBasic Diskを使うことが多いと思いますが、要件によってはDynamic Diskを利用している場合もあります。
このDynamic Diskを利用しているWindows Serverをそのまま移行しようとすると、移行の途中でエラーが発生します。
私が実際に対応したケースだと、インスタンスを起動する前のConversion Serverによる変換処理で失敗してしまい、それ以降の移行ステップに進めなくなるという事象が発生しました。
この事象については公式ドキュメントにも記載があり、移行が失敗する可能性があると書かれています。
Windows Dynamic Disk troubleshooting
Moving a Windows Dynamic Disk from a local computer to another computer may change the disk status to "Foreign", resulting in a disruption in replication. The solution is to import the foreign disk, as discussed in this Microsoft troubleshooting article.
（和訳）
Windows ダイナミック ディスクのトラブルシューティングWindows ダイナミック ディスクをローカル コンピューターから別のコンピューターに移動すると、ディスクの状態が「外部」に変化し、レプリケーションが中断される場合があります。解決策は、この Microsoft のトラブルシューティング記事で説明されているように、外部ディスクをインポートすることです。
参照されているMicrosoftのページを見ると、「コンピューターの管理」の画面で対応するように書かれています。
解決策：ディスク上のデータにアクセスできるように、ディスクをコンピュータのシステム構成に追加してください。ディスクをコンピュータのシステム構成に追加するには、外部ディスクをインポートします。ディスクを選択して長押し（または右クリック）し、「外部ディスクのインポート」を選択します。ディスクをインポートすると、外部ディスク上の既存のボリュームが表示され、アクセスできるようになります。
ただし、インスタンスを起動することができないとOSへのログインもできないので、この対応すらできなくなってしまいます。
そのため、可能であればあらかじめベーシックディスクに変換しておくなどの対応が求められます。
なお、私の前任者が対応したケースでは、AWSサポート担当者に診断プロセスを実行してもらい、移行できる状態にしていただいたという事象がありました。
移行後にLisence Managerによるライセンス変換処理を行う
これは私がSQL Serverが搭載されているWindows Serverを移行する際に遭遇した事象です。
BYOLではなくAWS提供のライセンスを利用する形で移行したのですが、普通のWindows ServerであればMGNがライセンス変換をよしなにやってくれます。
ただし、ライセンスが必要なSQL Sreverを利用している際には、Windows ServerだけではなくSQL Serverのライセンスも意識する必要があります。
一般的に、EC2のOSライセンスの詳細は「使用オペレーション」というパラメータで確認することができます。
このパラメータの値とライセンスの実態の整合性が取れていないと、ライセンスが正しく適用されない可能性があるので注意が必要です。
実際に私が対応したケースでは、使用オペレーションに「Windows with SQL Server Standard（RunInstances:0006）」が適用されていて欲しかったのですが、実際に移行してみると「Windows（RunInstances:0002）」となっていました。
そのため、MGNでの移行が完了した後に、License Managerを使ってライセンス変換処理を行う必要がありました。
なお、MGNの起動後アクションでSQL Serverのライセンス変換処理を行うことも可能です。
起動後アクションでライセンス変換ができることに後で気がついたので使いませんでしたが、作業ミスを防ぐためにもなるべく起動後アクションで完結させてしまった方が良いでしょう。
まとめ
MGNでWindows Serverを移行する際に気をつけるべき点について、自分の体験をベースにまとめてみました。
今後知見が増えたら、適宜追記などしていこうと思います。
また、私の理解が間違えている点や「こんな方法もあるよ」などの意見があればコメントいただけると嬉しいです。
この記事が誰かの役に立てば幸いです！