オンプレWindowsファイルサーバの移行の話
需要の有無、最適解であるか、は気にしない。アウトプットすることこそが大事。よって記述します。
今回はAD環境下のオンプレのWindowsのファイルサーバの移行について。
2つのファイルサーバを1つに統合した話。
環境
Windows Server 2008とWindows Serve 2012 R2の2つのサーバからWindows Server 2016に移行。
当初の導入した2008が運用中に容量が足りなくなったので、2012を追加導入することで容量不足を解消した。双方が老朽化しているため、大容量の2016サーバ1台にまとめる。
FS01＝2008
FS02=2012R2
新FS=2016
サーバの準備
各サーバのNICが2つあったので以下のように設定した。
・業務用ネットワークの仮IP（192.168.0.100/24と仮にする）
・移行用のネットワークのIP（172.16.0.100/24と仮にする）
移行用ネットワークはひとつのHUBで繋いでしまうので、既存とは
全然違うIPにする。
ファイル移行のネットワークトラフィックで業務ネットワークに負荷をかけないために上記の構成にする。
移行コマンドの準備
移行コマンドはRobocopyで行うこととした。
２つの旧サーバのファイルを新サーバで統合するためにフォルダ単位でのミラーリングコピーを行うこととした。
移行コマンドの実施
初回の移行コマンドを新サーバで実行。今回行った環境では数十TBが存在したため、移行を実行した後に1週間程放置し、その後、ログを確認した。
※ログは新サーバのC:\logフォルダにフォルダ名毎に作成
ログを確認した上で、エラーが発生するものに対処して対応する。
・階層が深すぎてコピーができないもの
→使用者と相談し、整理。
・Macにより特殊なフォルダ名がつけられているもの
→以下の記事で対応
フォルダ名、ファイル名にスペースがあるファイルをなんとか消した話
・ファイルを開いていてコピーができないもの
→別の時間に再度コピーコマンドを実行。それでもダメな場合は使用者に閉じてもらうように連絡。
→以下の記事で対応
Windowsファイルサーバで誰がどのファイルを開いているか確認する話
・実際のコマンドは以下（AD環境下の権限もコピー可能）
rem 日付別ログ格納用作成
set yyyy=%date:~0,4%
set mm=%date:~5,2%
set dd=%date:~8,2%
set filename=%yyyy%%mm%%dd%
md c:\log\%filename%
rem セキュリティ設定をまるごと引き継ぐため旧ファイルサーバの管理共有から
rem 新サーバの管理共有にミラーリングコピーを行う。
rem 複数のサーバを1つのサーバに集約するためフォルダ毎にミラーリングコピーを実施
set FolderName=Folder1
robocopy \\FS01\d$\ShareDoc\%FolderName% \\新FS01\d$\ShareDoc\%FolderName% /MIR /COPYALL /DCOPY:DAT /R:2 /NP /log:c:\log\%filename%\%FolderName%.LOG
set FolderName=Folder2
rem 下のコマンドは前回のコマンドと変わらず
robocopy \\FS01\d$\ShareDoc\%FolderName% \\新FS01\d$\ShareDoc\%FolderName% /MIR /COPYALL /DCOPY:DAT /R:2 /NP /log:c:\log\%filename%\%FolderName%.LOG
set FolderName=Folder3
rem 下のコマンドはFS02に変わっていることに注意
robocopy \\FS02\d$\ShareDoc\%FolderName% \\新FS01\d$\ShareDoc\%FolderName% /MIR /COPYALL /DCOPY:DAT /R:2 /NP /log:c:\log\%filename%\%FolderName%.LOG定期的な移行コマンドの実施
初回の移行とエラーへの対応が終わったら、実際に切り替える日まで、毎日移行コマンドを実行する。
実行にかかる時間を計測し、移行時間の目安を確認する。
移行当日
ファイルサーバ上のファイルを誰も開いていない状態を確認し、最後の移行コマンドを実行し、エラーがはないことを確認する。
必要に応じて以下を行う。
・新旧のサーバのIPアドレスの変更
→ユーザがIPアドレスベースでアクセスしていた場合での対応
この場合は旧サーバどちらかに寄せないといけない
・新旧のサーバのサーバ名の変更
→ユーザがサーバ名でアクセスしていた場合での対応
新サーバはどちらかの旧サーバの名前に設定し、DNSサーバ上で設定
しなかった方のサーバ名を静的に設定することで、ユーザは違和感なく
使用することが可能となる。
移行したその後
移行後は万が一の移行漏れに備えて、暫くは旧サーバは稼働させたままにしておくこととした。ユーザ側に移行漏れの確認期間を依頼し、その期間を過ぎたら停止させる。
また、しばらくの間移行コマンドの宛先を逆にしバックアップとして利用することも可能となる。
気を付けた点
・移行用ネットワークを用意し、業務負荷を軽減した。
・ミラーリングコピーをある程度の期間行うことで、最終の移行作業の
かなり精度の高いタイムスケジュールをたてることができた。
・DNSを使うことで、2つのサーバを1つに統合してもユーザには違和感なく
使用させることを可能とした。
最後に
Windowsのファイルサーバを使っている限りこれで問題ないと考える。
robocopyのコピー元とコピー先の順番を間違えるとえらいことになるので注意。
移行直前にユーザの操作ミスで大事なフォルダを消してしまったという事態がだいぶたってから発覚したが、ギリギリ旧サーバのバックアップがあったため事なきを得た。そろそろ移行の不具合報告がないので旧サーバをおさらばする直前だったので、ほっとしました。