適化技術、レプリケーション最適化ツール、帯域制御装置といったツールを使用して帯域幅を制御できる。ダウンタイムは必ずしも悪いことではない一部のベンダーは、アプリケーションにダウンタイムを一切発生させずにデータを移行できることを謳っている。ある程度のダウンタイムを見込んでおくことを推奨する専門家もいる。いうのも、通常の本稼働時間中にデータを移行して、移行中のデータの整合性を確保するというのは、存外油断のならない作業だからだ。可能であれば、何か問題が発生した場合に「あまり強いプレッシャーを受けなくて済むように」営業時間外に移行作業を行うよう同氏は推奨している。「この点については、私はいわば保守派です。遭う危険にさらされることがある。異なるファイルシステム間で(たとえば、NTFSからNFSに)データを移行しただけでも、アクセス権とセキュリティの設定が失われるおそれがある、とグラスハウス・テクノロジーズ社のナドカルニ氏は言う。「WindowsからUNIXに、またはUNIXからWindowsに移行するときは、きわめて慎重に行う必要があります。高確率で、ユーザアクセス権の設定が完全に破損してしまうからです。」セキュリティの問題を回避するための最も簡単な方法は、ファイルレベルではなくブロックレベルで移行を行うことだ。すれば、移行は「ファイルシステムの下のレベルで」実行されるため、データの「差異がホストに認識されることさえない」とナドカルニ氏は言う。Directoryなどのサービスにおける同じ認証またはアクセス許可のドメイン内にあれば、セキュリティ設定を保持することは可能、とも同氏は言っている。ファイルベース移行ツールの中には、そのようなセキュリティ設定を保持するために必要な高度な機能を備えたものもあるという。シュルツ氏は、ファイル複製ユーティリティがどのように動作するかを詳細に理解することが重要だと言う。「何がどのようにコピーされるのか。コピーされるのか、それともその他の属性、メタデータ、関連情報もすべてコピーされるのか。いったことがまさに予想外の不具合の原因となりえます。タが、どのように移行されるのかを理解する必要があります。際の移行作業を苦労なく行うことができたと言う。「ファイバチャネルスイッチでXPをゾーン分割したので、IPStorには(XP環境が)別のハードディスクのセットとして認識されました。XP24000アレイ上にミラーリングしたLUNを作成して、同期を実行したのです。プライマリアレイとバックアップLUNの同期が完了したら......あとはプライマリからバックアップにスイッチを切り替えるだけで、バックアップがプライマリに切り替わりました。し、すべての仮想化がこれと同じように実現するわけではない。作業が増えてしまったり、管理者がドライバや、ストレージ管理に使用されているボリュームマネージャを更新する際にアプリケーションの障害が発生したりすることもあるという。Inquiry中の文字列が変更されることにより問題が発生するおそれがあるケースだ。アプライアンスによってInquiryの(削除→照会)文字列が変更されると、ストレージ管理に使用されているボリュームマネージャを再構成して新しい文字列を認識させなければならなくなり、そうしないと、そのボリュームに依存しているアプリケーションが適切に動作しないおそれがあるという。ストレージ管理者は、仮想化ベンダーに、その仮想化製品が「完全に透過的」なのかどうか、あるいはサーバやその他のコンポーネントへの変更(アプリケーション障害の原因となり得る)を必要とするものなのかどうかを確認する必要がある、とナドカルニ氏は言う。訳注:そもそもボリュームマネージャが適切に元の論理ボリュームを再構成できないとアプリケーションは起動できないはず。同氏は、ストレージソリューションを仮想化する(または仮想化を解除する)のにアレイまたはストレージネットワーク全体のサービスを停止する必要があるような仮想化アプライアンスは使わないよう推奨している。したり、ストレージアレイ全体を停止したりする必要が生じるケースがあります。管理者がドライバ、マルチパス対応ソフトウェア、ボリュームマネージャといった「ホスト上のものを変更する」必要が生じるアプライアンスもあるという。6、シン・プロビジョニングシン・プロビジョニングとは、ストレージスペースを有効活用する手法である。アプリケーションやユーザが使用するボリュームは、ボリュームが初期構成された時ではなく、データが実際に書き込まれる時にだけディスク上のスペースが占有される。このことにより、アプリケーションやユーザが結局はディスクスペースを必要としなかったという場合に無駄が発生しなくなる。シマンテックのストレージ管理/高可用性担当ディレクター、ショーン・デリントン氏によると、多くのデータ移行ツールでは、どのブロックが実際に使用されているのかを無視して、移行先システム上のボリュームの「ブロック0から最終ブロックまで」のすべてに書き込みが行われるため、ユーザが移行元のアレイにシン・プロビジョニングを適用していたとしてもそのメリットが無効になってしまうという。高度な機能を備えた」ファイルシステムユーティリティまたはホストベースのボリュームマネージャを使用すれば、この問題を回避するのに役立つという。持するには不向きだと同氏は言う。悪魔は(ソフトウェアの)細部に宿る古い環境と新しい環境でソフトウェアに適用されているパッチのレベルが異なるといった単純なことでも、移行後にサーバのクラッシュが起きる原因となりうる。ナドカルニ氏は、ストレージアレイ間の移行でも、サーバから前のベンダーのソフトウェアをアンインストールして新しいベンダーのものをインストールする必要があると言う。競合した場合に、環境が不安定となる原因にもなりうる。合」に満ちた複雑な作業だ、ということだ。ナドカルニ氏はこう言う。「データの移行を成功させるための鍵は、環境の中に未知のものを残さないことです。知のものがあればあるほど、リスクは大きくなります。適切に完了させるために必要な時間を短く見積もりがちだ。個々のデータ移行に伴う技術的課題に加えて、移行のビジネス目標を明確に理解することも重要だ、とマサチューセッツ州ミルフォードにあるエンタープライズ・ストラテジー・グループのアナリスト、テリ・マクルーア氏は言う。データ移行のROIはどの程度か。object)を短縮することなのか、それとも両方か、といったことだ。その両方が目的ならば、たとえば自動化されたストレージポリシーを作成して、手動での移行作業を何度も繰り返さずに済むようにすると考えられる、と同氏は言う。フューチャーエレクトロニクス社のファルサーフィ氏はこう言う。準備とはつまり、分析、データ収集、トレンド分析を行うことです。私のような立場の者にとっては、ストレージ管理者が、何であれ作業を実行する前にこれらの情報を入手し、システムの動作を正確に把握してくれることがきわめて重要となります。分の時間とは比べものにならないほど大きくなるのです。TechTarget*この翻訳記事の翻訳著作権はJDSFが所有しています。このページに掲載されている記事・写真・図表などの無断転載を禁じます。表示させるためには、JavaScriptを有効にしてください。