JDSF | ストレージ管理ソリューション部会 | データ・ストレージに関する総合情報サイト

HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

データ移行に役立つヒント

著者：Robert L. Scheier
Storage Magazine 2008年11月号より

データの移行は、ともすれば複雑で時間のかかる作業になりがちである。そしてまたあまりに頻繁に発生する。この記事では、データ移行プロセスを合理化する方法を紹介する。

1年か2年前に保存したデータは、当時のストレージメディアが何であれ、今では別のメディアにすでに移動されており、さらに今後また近いうちに移動される予定、というケースが多いだろう。データの移動が必要となる理由は数多く存在する。たとえば、旧型のファイバチャネル（FC）SANのリース期限が間近に迫っているので新しいハードウェアにアップグレードする、新しいデータセンターに移転する、または増大するデータ需要に対応するために古いファイルをより安価なストレージに移動させる必要がある、といったことだ。

データ移行は、ありふれた単純作業かもしれないが、だからといって簡単というわけではない。ディスク（およびテープ）ドライブは、サーバ、ルータ、スイッチ、およびストレージとデータのネットワークを通じてアプリケーションとビジネスプロセスにリンクしている。アクセス制御ポリシーやその他の階層のセキュリティも同様であることは言うまでもない。環境が複雑になるほど、そして管理するデータが増えるほど、オペレーティングシステムやアレイに組み込まれた単純なコピー機能を使って必要な移行を適切に達成できる可能性は低くなる。

データの移行には、単にこれまでのストレージキャビネットを取り外して別のものを取り付けるという作業にとどまらない、実に多くのことが必要になる。以下では、データ移行をよりスムーズに実現するために役立つヒントを紹介する。

1. マッピングを理解する
どのようなデータであれ、新しいストレージアレイに移行する前に、サーバが現在どのようにストレージにマッピングされているかを理解し、新しい環境でそのマッピングを再現できるようにする必要がある。そうでないと、移行後にサーバが正常に再起動しなくなるおそれがある。

予定外の障害を回避するため、管理者は「移行元と移行先のプラットフォーム間の真のエンドツーエンドの関係を理解する」必要がある、と言うのはEMCの製品・応用技術担当シニアディレクター、ルー・ベルジェ氏だ。このことは、冗長性確保のために、使用しているストレージ・インフラストラクチャが、プライマリアレイに障害が発生した際に代替アレイからホストを再起動できるマルチパス対応環境である場合に特に重要だ。パス設定ソフトウェアが適切にセットアップされるようホストHBAのパラメータを確認しておかないと、ホストが正常に再起動しなくなるおそれがある。

また管理者は、移行後にストレージリソースが適切な順序でホストに認識されるようにする必要がある。アプリケーションの起動シーケンスがあるLUNとデータがあるLUNが異なるケースがあるため、「一部のアプリケーションやデータベースでは、ボリュームを認識する順序が厳密に区別される」とベルジェ氏は言う。

移行後に再起動に失敗するまで、管理者がサーバの存在さえ知らなかった、というケースがあるという。サーバを「インストールした後はすっかり忘れてしまう、ということがよくある」ためと指摘するのは、米国マサチューセッツ州フラミンガムを本拠とするコンサルティング・サービス会社グラスハウス・テクノロジーズの主席コンサルタント、アシシュ・ナドカルニ氏だ。ストレージの検出と監査のツールは有益ではあるが、どれも問題の原因となる可能性のある不適切な構成を100%検出することはできないと同氏は言う。

2. 測定基準を収集する
カナダのモントリオールにある電子部品販売業者フューチャーエレクトロニクス社の情報技術担当ディレクター、ジャリル・ファルサーフィ氏が担当したケースはこうだ。IBMのエントリーレベルアレイDS4100とDS4300から、ヒューレット・パッカード（HP）社のStorageWorks XP24000アレイにデータを移行する必要があった。移行作業は、6週間のうちに、ネットワークトラフィックの比較的少ない時間帯を狙って行う。そのためには、使用しているSANの許容容量、そして、その他データベースバックアップなどの機能によってネットワーク負荷が増大するタイミングを詳細に理解する必要があった。

フューチャーエレクトロニクス社のファルサーフィ氏はこう述べている。「移行しようとするLUNや論理ディスクの数を特定する必要があります。LUNや論理ディスクののサイズを知り、アレイの速度を知り、スイッチの速度を知り、さらにトラフィック負荷がきわめて高くなるポイントも知る必要があります。平均や最善のケースではなく、最悪のシナリオを考慮に入れなければならないのです。」

ファルサーフィ氏は、ファルコンストア･ソフトウェア社のIPStorネットワークストレージサーバで利用できる監視ツールと、ホストベースおよびアレイベースのユーティリティを使用して、それらの測定基準を収集した。

「移行作業は、システム全体のパフォーマンスに深刻な影響をもたらすおそれがあります。」と言うのは、レフトハンド・ネットワークス社（まもなくHPが買収予定）のプロダクトマーケティング担当ディレクター、クリス･マコール氏だ。「移行作業は『このコントローラのパフォーマンスはすでに最大限に達したのか、それとももうすぐ最大限に達するのか』（といった疑問を伴う）非常に扱いにくい問題となります。」と同氏は言い、移行トラフィックでストレージまたはデータのネットワークに過度な負荷をかけると、移行しようとしているデータだけでなく、ネットワーク上のすべてのデータの可用性とパフォーマンスが低下するおそれがある、と警告する。

移行を実行に移す前にネットワーク帯域幅を測定する作業は、単純なようだが見過ごされやすいと指摘するのは、米国ミネソタ州スティルウォーターにあるストレージIOグループの創業者でありシニアアナリストのグレッグ・シュルツ氏だ。「明確にわかっているという自信がない限り、必ず再確認して、どのような影響が生じるかを認識すべきです。」と同氏は言う。どれだけの帯域幅を移行に割り当てる必要があるか、割り当てが可能になるのはいつかを管理者が明確に知っていれば、最適化技術、レプリケーション最適化ツール、帯域制御装置といったツールを使用して帯域幅を制御できる。

3. ダウンタイムは必ずしも悪いことではない
一部のベンダーは、アプリケーションにダウンタイムを一切発生させずにデータを移行できることを謳っている。しかし、ある程度のダウンタイムを見込んでおくことを推奨する専門家もいる。ディメンション･データ社の国家サービス・データセンター・ストレージソリューション担当ディレクター、ゲイリー･フォックス氏Gary Fox, もその1人だ。というのも、通常の本稼働時間中にデータを移行して、移行中のデータの整合性を確保するというのは、存外油断のならない作業だからだ。可能であれば、何か問題が発生した場合に「あまり強いプレッシャーを受けなくて済むように」営業時間外に移行作業を行うよう同氏は推奨している。

「この点については、私はいわば保守派です。」とも付け加えた。

4. セキュリティ侵害にご用心
多様なベンダーのアレイ間でデータを移行するケースでは、アクセス権とセキュリティの設定が移行されないままになり、データが盗難、破損、不正使用に遭う危険にさらされることがある。異なるファイルシステム間で（たとえば、NTFSからNFSに）データを移行しただけでも、アクセス権とセキュリティの設定が失われるおそれがある、とグラスハウス・テクノロジーズ社のナドカルニ氏は言う。「WindowsからUNIXに、またはUNIXからWindowsに移行するときは、きわめて慎重に行う必要があります。高確率で、ユーザアクセス権の設定が完全に破損してしまうからです。」

セキュリティの問題を回避するための最も簡単な方法は、ファイルレベルではなくブロックレベルで移行を行うことだ。そうすれば、移行は「ファイルシステムの下のレベルで」実行されるため、データの「差異がホストに認識されることさえない」とナドカルニ氏は言う。

ただし、ファイルベースの移行でも、移行元システムと移行先システムが、マイクロソフトのActive Directoryなどのサービスにおける同じ認証またはアクセス許可のドメイン内にあれば、セキュリティ設定を保持することは可能、とも同氏は言っている。また、ファイルベース移行ツールの中には、そのようなセキュリティ設定を保持するために必要な高度な機能を備えたものもあるという。

ストレージIOのシュルツ氏は、ファイル複製ユーティリティがどのように動作するかを詳細に理解することが重要だと言う。「何がどのようにコピーされるのか。ファイルだけがコピーされるのか、それともその他の属性、メタデータ、関連情報もすべてコピーされるのか。追加のアクセス権とアクセス情報をすべて移行済みでない場合は、こういったことがまさに予想外の不具合の原因となりえます。マニュアルをよく読み、ベンダーやサービスプロバイダに質問して、どのようなタイプのデータが、どのように移行されるのかを理解する必要があります。」

5. 仮想化は慎重に
そのような異なるベンダー間の移行を実現するにあたり、信頼性の高い手段として利用できるのが、多くのベンダーから提供されているホストベースのストレージ仮想化機能だ。フューチャーエレクトロニクス社のファルサーフィ氏は、ファルコンストア･ソフトウェア社が提供するホストベースの仮想化機能によって、実際の移行作業を苦労なく行うことができたと言う。「ファイバチャネルスイッチでXPをゾーン分割したので、IPStorには（XP環境が）別のハードディスクのセットとして認識されました。HP StorageWorks XP24000アレイ上にミラーリングしたLUNを作成して、同期を実行したのです。プライマリアレイとバックアップLUNの同期が完了したら……あとはプライマリからバックアップにスイッチを切り替えるだけで、バックアップがプライマリに切り替わりました。」

しかし、すべての仮想化がこれと同じように実現するわけではない。ナドカルニ氏によると、仮想化アプリケーションによっては、管理者が行わなければならない作業が増えてしまったり、管理者がドライバや、ストレージ管理に使用されているボリュームマネージャを更新する際にアプリケーションの障害が発生したりすることもあるという。たとえば、同氏が例として挙げるのは、ある仮想化アプライアンスで、特定のアレイを識別するのに使用されるSCSI Inquiry中の文字列が変更されることにより問題が発生するおそれがあるケースだ。アプライアンスによってInquiryの（削除→照会）文字列が変更されると、ストレージ管理に使用されているボリュームマネージャを再構成して新しい文字列を認識させなければならなくなり、そうしないと、そのボリュームに依存しているアプリケーションが適切に動作しないおそれがあるという。ストレージ管理者は、仮想化ベンダーに、その仮想化製品が「完全に透過的」なのかどうか、あるいはサーバやその他のコンポーネントへの変更（アプリケーション障害の原因となり得る）を必要とするものなのかどうかを確認する必要がある、とナドカルニ氏は言う。

訳注：そもそもボリュームマネージャが適切に元の論理ボリュームを再構成できないとアプリケーションは起動できないはず。

また同氏は、ストレージソリューションを仮想化する（または仮想化を解除する）のにアレイまたはストレージネットワーク全体のサービスを停止する必要があるような仮想化アプライアンスは使わないよう推奨している。一部のアプライアンスでは、「アプライアンスを組み入れるために、ネットワークを停止して再構成したり、ストレージアレイ全体を停止したりする必要が生じるケースがあります。」と同氏は言う。また、管理者がドライバ、マルチパス対応ソフトウェア、ボリュームマネージャといった「ホスト上のものを変更する」必要が生じるアプライアンスもあるという。

6、シン・プロビジョニング
シン・プロビジョニングとは、ストレージスペースを有効活用する手法である。アプリケーションやユーザが使用するボリュームは、ボリュームが初期構成された時ではなく、データが実際に書き込まれる時にだけディスク上のスペースが占有される。このことにより、アプリケーションやユーザが結局はディスクスペースを必要としなかったという場合に無駄が発生しなくなる。ただしシマンテックのストレージ管理/高可用性担当ディレクター、ショーン・デリントン氏によると、多くのデータ移行ツールでは、どのブロックが実際に使用されているのかを無視して、移行先システム上のボリュームの「ブロック0から最終ブロックまで」のすべてに書き込みが行われるため、ユーザが移行元のアレイにシン・プロビジョニングを適用していたとしてもそのメリットが無効になってしまうという。

グラスハウス・テクノロジーズ社のナドカルニ氏によると、ブロックに書き込むことを決定する前に「ブロックがアクセスされているかどうかを判定できる程度に高度な機能を備えた」ファイルシステムユーティリティまたはホストベースのボリュームマネージャを使用すれば、この問題を回避するのに役立つという。ブロックレベルの移行手法は、データまわりのセキュリティを保持するのには有効だが、「ボリューム全体に書き込んでしまうため」シン・プロビジョニングを保持するには不向きだと同氏は言う。

7. 悪魔は（ソフトウェアの）細部に宿る
古い環境と新しい環境でソフトウェアに適用されているパッチのレベルが異なるといった単純なことでも、移行後にサーバのクラッシュが起きる原因となりうる。ナドカルニ氏は、ストレージアレイ間の移行でも、サーバから前のベンダーのソフトウェアをアンインストールして新しいベンダーのものをインストールする必要があると言う。この作業は、時間がかかるだけでなく、古いソフトウェアの不完全なアンインストールにより残されたコンポーネントが他のアプリケーションと競合した場合に、環境が不安定となる原因にもなりうる。

8. 十分な学習時間を見込む
これまで説明したヒントに共通のテーマが1つあるとすれば、それは、ストレージの移行というものは、アプリケーションのアップタイム、信頼性、またはセキュリティを損なう可能性のある「予想外の不具合」に満ちた複雑な作業だ、ということだ。ナドカルニ氏はこう言う。「データの移行を成功させるための鍵は、環境の中に未知のものを残さないことです。未知のものがあればあるほど、リスクは大きくなります。」ストレージ管理者は、新しいストレージ環境について学習するために必要な時間、そしてデータの移行を適切に完了させるために必要な時間を短く見積もりがちだ。

個々のデータ移行に伴う技術的課題に加えて、移行のビジネス目標を明確に理解することも重要だ、とマサチューセッツ州ミルフォードにあるエンタープライズ・ストラテジー・グループのアナリスト、テリ･マクルーア氏は言う。たとえば、データ移行のROIはどの程度か。移行の目的は、まれにしか使用されないデータをより安価なメディアに移行してディスクと電力のコストを削減することなのか、データのRTO（Recovery Time object）を短縮することなのか、それとも両方か、といったことだ。その両方が目的ならば、たとえば自動化されたストレージポリシーを作成して、手動での移行作業を何度も繰り返さずに済むようにすると考えられる、と同氏は言う。

フューチャーエレクトロニクス社のファルサーフィ氏はこう言う。「何事も適切にシームレスに成し遂げようと思えば、多くのことを徹底的に準備する必要があります。準備とはつまり、分析、データ収集、トレンド分析を行うことです。私のような立場の者にとっては、ストレージ管理者が、何であれ作業を実行する前にこれらの情報を入手し、システムの動作を正確に把握してくれることがきわめて重要となります。管理者が事前に移行元と移行先の環境を完全に理解するのにより多くの時間がかかるとしても、そうせずにデータ移行がうまく行かなかった場合に発生する業務の中断、収益や信用の喪失といったコストの方が、そのような余分の時間とは比べものにならないほど大きくなるのです。」