ファイルサーバ データ移行 （準備・概要）

ファイルサーバのデータ移行作業は通常の構築作業に比べて負荷が高く、トラブルが発生しやすい作業です。初めて移行作業を任されたら、何から着手をしたら良いか途方に暮れてしまう人も多いのではないでしょうか？

トラブルを完全に排除することは出来ませんが、事前に注意事項を洗い出し、しっかり計画することでトラブルの数を減らし、想定外の事象が発生した際にも迅速に対応することが可能です。

本記事ではファイルサーバの移行を進める際に必要な準備や注意点について紹介します。

進め方はそれぞれのプロジェクトの要件・スケジュールに依存しますが、以下が一般的なデータ移行計画の例となります。

1. 移行元環境の事前調査
2. 移行計画の作成
3. 移行先環境の構築・データ移行開始
4. 移行先環境での切替リハーサル　*要件・環境の制約によっては実施しない場合あり
5. 移行先環境への最終切替

冒頭に記載した通り、データ移行作業は構築作業に比べて想定外の事象や問題が発生しやすい作業です。トラブルをゼロにすることは出来ませんが、事前調査・計画によってリスクを未然に防ぐことが可能です。移行プロジェクトが成功するか否かはこのフェーズにかかっているとも言えます。

主に以下の項目について確認・情報取集・事前合意を行う必要があります。

1. 想定の移行スケジュール
2. 作業の役割分担
3. 不測事態発生時の切り戻し判断基準
4. 移行元・先ファイルサーバの構成
5. 移行元ファイルサーバの使用状況
6. 移行元ファイルサーバで利用している機能
7. 移行時に発生し得る問題の事前調査・説明

1、2、3については主にプロジェクトマネージメント的な要素、残りは主に技術的な要素となります。

1. 想定の移行スケジュール

採用する移行方式やその他の要因で移行に要する期間は異なりますが、いつまでに移行を完了させるのか、明確にする必要があります。そこから逆算して各フェーズの開始・完了のマイルストーンを決めていきます。もちろんプロジェクトを進めていく中で発生する課題やその他要因でスケジュールの修正検討は必要になります。

2. 作業の役割分担

全ての作業を１人（１社）で実施することは出来ません。各作業について誰が担当するのか（権限があるのか）を事前に明確にしておく必要があります。参考までに以下に主な作業の例を挙げます。

• 移行元ファイルサーバの構成情報・運用ドキュメントの取得
• 移行設計書・スケジュールの作成
• 移行先ファイルサーバの設計・構築
• 移行元ファイルサーバへの設定変更（移行作業に必要な場合）
• データ移行作業・作業環境の準備（移行方式による）
• AD/DNSサーバの登録情報の追加/更新/削除作業
• 運用・監視等のソフトウェア設定変更/スクリプト修正（必要な場合のみ）
• その他・・・

3. 不測事態発生時の切り戻し判断基準

最終切替時に問題が発生する可能性があります。事前に起こりえる問題を全て把握することは出来ませんが、問題発生時の切り戻し対応・判断基準について予め決めておく必要があります。主なポイントは以下になります。

• 万が一に備えて、切り戻し作業を担保するスケジュールを検討するか否か
• 切り戻し作業を想定する場合は、チェックポイントを設定する
• 切り戻しを実施する条件をある程度明確化する

（例えば、ファイルアクセスは可能だが、監視ツールで想定通りの動作をしない場合は切り戻しを実施せずに前進対応とする等）

4. 移行元・先ファイルサーバの構成

移行先ファイルサーバで同一のフォルダ構成を引き継ぐのか、移行先でフォルダの統合を行う想定なのか確認する必要があります。統合を行う場合は、移行方式・計画に制約が発生する可能性があります。また、複数台の移行元ファイルサーバを一つの移行先ファイルサーバにまとめる場合も同様です。

5. 移行元ファイルサーバの使用状況

移行元ファイルサーバの負荷状況やバックアップ運用状況を確認してデータ移行による業務の影響を最小限にする計画を立てる必要があります（例えばデータ転送時のネットワーク帯域を絞るなど）

6. 移行元ファイルサーバで利用している機能

移行元・先ファイルサーバでOSもしくはストレージベンダーが異なる場合、既存運用の中でOS・ベンダー固有の機能を利用していないか、洗い出しておく必要があります。要件によっては運用の変更も検討する必要があります。

逆に同じOSまたは、ストレージベンダーの場合は、運用をそのまま引き継ぎことが出来る可能性が高いです。また、OS・ベンダー固有の移行機能・ツールを利用してより効率の良い移行方式を選択出来る可能性もあります。

7. 発生し得る技術的問題の事前調査・説明

6にも関連しますが、特に移行元・先ファイルサーバのOSが異なる場合は、エンドユーザからの利用方法に制約が発生したり、運用方法に差異が発生する可能性があります。例えば、以下のような環境では、問題や制約が発生するケースがあります。

• ファイル・フォルダ名に環境依存文字（サロゲートペア文字等）を使用している
• アクセス権の設定にローカルユーザ・グループを利用している

詳しくはまた後ほど、触れたいと思います。

このように実際のデータ移行作業を実施する前までに様々な調査・調整が必要になることが理解頂けたかと思います。プロジェクトの早い段階でデータ移行作業による影響（時間・影響範囲）について業務担当者に事前説明・了承を得た上で、エンドユーザに周知する必要があります。※各プロジェクトで異なりますが、各担当者との擦り合わせを完了し、最低でも1か月前くらいにはエンドユーザへの周知を完了しておくことが望ましいです。

移行方式には大きく分けて上抜きコピーとストレージの複製機能（ネットアップの場合はSnapMirror）の2種類があります。移行対象の環境・データに応じて選択します。

注意点は環境によって多岐に渡りますが、主に注意しなくてはいけない点を紹介します。

• サロゲートペア¹

ファイル・フォルダ名に絵文字や旧漢字などのサロゲートペア文字が使用されている場合、対象データを移行先のファイルサーバにコピー出来ない、または、移行先ファイルサーバで利用する際に制限がある場合があります。ネットアップの場合、旧OSである7-modeが稼働している移行元ファイルサーバを新OSであるONTAP 9が稼働する移行先ファイルサーバに移行する際、サロゲートペア文字が使用されているか注意がする必要があります。使用されている場合は、以下の移行方式・対応を検討する必要があります。

• ローカルユーザ・グループの使用の有無

ローカルユーザ・グループは、基本的に移行することが出来ません。ファイルやフォルダのアクセス権（ACL）にローカルユーザ・グループを利用している場合は、仮に移行先ファイルサーバで同じ名前のユーザ・グループを作成してもSID²は同じにはなりませんので、移行先ファイルサーバでファイルにアクセスが出来なくなります。移行前にドメインユーザ・グループでの管理に変更しましょう。既存のファイル・フォルダに付与されているアクセス権をローカルユーザ・グループからドメインユーザ・グループに付け替える作業は環境によって、かなり工数のかかる作業となりますが、この機会にドメインユーザ・グループで管理するように変更することをお勧めします。

移行元と移行先が同じOSもしくは、同じストレージベンダーの場合は、ローカルユーザ・グループを移行する手段・方式が提供されている可能性もありますが、一般的なファイルサーバ用途で使用する場合は、やはりローカルユーザ・グループによるアクセス権管理は避けることを強く推奨します。

• 移行元ファイルサーバの負荷状況

移行計画の段階で移行元ファイルサーバのCPU使用率、ディスクI/O・Busy率、ネットワーク使用率の傾向を把握しておく必要があります。

移行元ファイルサーバの負荷状況が高い場合は、データ移行による業務影響を避ける為、データ転送帯域を絞る、もしくはデータ転送の実行時間を限定するなどの調整が必要になる可能性があります。また、データの初期転送完了にかかる想定期間はこれら条件を加味した上で概算を算出する必要があります。

• 運用・監視等の機能の差異・ソフトウェア対応状況

移行元ファイルサーバで提供している機能が移行先ファイルサーバでも提供可能なのか、また、現在使用している周辺ソフトウェアがある場合、移行先ファイルサーバにも対応しているのか予め確認が必要です。例えば、データバックアップ機能、重複排除・圧縮機能、アンチウィルス機能、ファイルアクセスの監査機能、障害通知機能などを現環境で利用している場合、移行先ファイルサーバの環境でもサービス提供出来るのか、提供可能な場合、機能的な差異がないのか、周辺ソフトウェアのバージョンアップや設定変更が必要なのか等、確認が必要になります。

ここまでファイルサーバの移行の流れ、必要な準備、注意事項などを紹介してきました。データ移行の際に利用可能なソフトウェアの紹介、各ソフトウェア使用時の注意事項については、後日公開予定の「ファイルサーバ　データ移行（実行）」をご覧下さい。

脚注:

1. 通常、UTF-16では1文字あたり、全角・半角に関係なく、2バイトで表現される。ただし、2バイトで表現できる文字の種類は65,536文字までとなり、全ての文字を組み込むには足りない状況となっている。そこで1文字=2バイトの基本ルールを踏襲しつつ、一部の文字については4バイトで表記するサロゲートペアという方式が採用されている。サロゲートペアでは、従来未使用だった0xD800～0xDBFF(1024通り)を上位サロゲート、0xDC00～0xDFFF(1024通り)を下位サロゲートとして、上位と下位を合わせて4バイトで1文字を表現する。サロゲートペアの導入により、1024x1024=1,048,576文字の領域が追加されるようなった
2. Windows NT系のOSのユーザーアカウントやユーザーグループに与えられる、固有の識別番号。「S-1-」で始まる長い数字の列で表される。ユーザー・アカウントやグループなどは、管理ツールに表示される「名前」ではなく、「SID（Security Identifier。セキュリティ識別子）」と呼ばれる一意のID番号列を使用して管理されている。