ストレージ・アーキテクチャとは何か

　3. バックアップ・アーキテクチャ

　バックアップ・アーキテクチャは、1. ストレージ機能を利用した筐体内のバックアップ、2. バックアップ・ツールを利用したバックアップの2種類に大別されます。1. は、さらに物理的にバックアップ・データを保持するボリューム複製機能と、主ボリュームとの差分データのみ保持し論理バックアップ・イメージを作成するスナップショット機能に分かれます。双方ともボリューム・レベルでのバックアップが基本です（これに関しては、SAN／NASストレージの項目で述べています）。2. は、バックアップ・イメージは完全に主ボリュームからは独立して得られますが、バックアップ手法により、ボリューム・レベル、ファイル・レベルに大別されます。バックアップの媒体も、テープ・メディア、安価なディスク装置、テープ装置をエミュレーションしたディスク装置などの選択が可能です。このように、バックアップ・ソリューションはさまざまな形態が選択可能です。

　バックアップ・アーキテクチャとしては、少なくとも以下の観点で整理しておくことが必要です。

• バックアップ単位（ボリューム・レベル、ファイル・レベル）
• 筐体内バックアップを利用する場合の手法　（ボリューム複製、スナップショット）
• ストレージ筐体内、筐体外毎のバックアップ世代数と保管周期
• バックアップ・メディア（ディスク、テープ）

　バックアップ・ツールを利用したバックアップでは、バックアップ単位、媒体の種類のほかに、バックアップの取得経路をファイバ・チャネル経由にするか、ネットワーク経由にするかという選択もあります。また、バックアップ・メディアの複製を取得するかどうかの検討も必要です。特にテープ媒体のみにバックアップを実施し、災害対策の一環で別の場所に保管をすることが要件にある場合、緊急なリストア要求に応えるため、そのバックアップ・テープの複製を取得し、データセンター内にも保管するなどが必要になる場合も考えられます。

　バックアップ・サーバを検討する場合は、バックアップ・サーバ自体の可用性の検討を忘れないでください。バックアップ・サーバ自身の障害を想定し、必要に応じて冗長化を図るなどの対策を検討してください。

　情報の保護は、もっとも重要なストレージ基盤機能ではありますが、そのためバックアップ基盤は容易に過剰投資になりやすい領域です。バックアップに関する、論理要件を完全に満たすためのアーキテクチャを立案し、その上で再度、費用対効果を検討して、実現可能で効果的な実装計画とすることが求められます。

　4. アーカイブ・アーキテクチャ

　長期保存が必要なデータは、アーカイブとして検討します。多くの場合は、バックアップ基盤と同様の仕組みで、保存期限が通常のバックアップ・データより、はるかに長い期間を設定することで代用しています。

　この場合、もっとも注意すべきは、バックアップ・サーバのライフサイクルと互換性の問題です。業界によっては、10年以上のデータ保管を義務付けられている場合もありますが、特定のバックアップ・サーバで取得されたバックアップ・データ（正確にはアーカイブ・データ）が10年後にでも確実に利用できることを保障しなくてはなりません。このような、長期保存が義務付けられるデータのアーカイブに関しては、可能な限り、特定の技術に依存しない汎用的なフォーマットで保管されることが望まれます。また、メディアの信頼性の懸念もあります。テープ・メディアでの保管が10年後でも正常に回復できることを保障できるかという点です。過去に比べればその信頼性は格段に進歩していますが、一定レベルでのエラーの発生は覚悟すべきです。

　経験的に長期間互換性が保たれるメディアは、磁気ディスク、もしくはCD/DVDなどのIT以外でも利用されているメディアです。運用保守面まで含めた投資対効果を検討し、適切なアーキテクチャ・モデルを検討してください。

　5. リモート・バックアップ・アーキテクチャ

　災害対策として、最も利用されているパターンは、テープ・メディアを本番データセンター以外の遠方に保管する方法です。ただし、ほとんどの場合、この方法は災害発生時のデータ回復に伴うリスクが、自社とは別の業者に大きく依存してしまうことになります。また、有事の際の業務再開までの適時性を確保することも、企業にとっては重要な項目であり、必要に応じて、より業務再開までの時間を短縮可能とするためのIT基盤を計画することとなります。リモート・バックアップは、データセンター設備、ネットワーク設備から必要となるため、かなり大きな投資となりますので、可能な限り、日常的な運用費は極力抑えて実現させるのが望ましいと思います。そのためには、仕組みをできるだけ単純にすることが重要です。

　有事の際に、再調達困難な経営資源は、“人”と“情報”です。そのため、少なくとも再生が困難な情報だけでも、保全したいという要件と、単純な仕組みによる実装という要件により、ストレージ・ベースのソリューションを活用した、リモート・バックアップを採用する企業が多く見られます。

　ストレージ・ベースのリモート・バックアップ方式には、大きく同期型と非同期型があります。非同期型は、その更新データのずれのタイミングの差により、さらにいくつかのレベルに分かれます。

　同期型はローカル・データとリモート・データが完全に同期されますが、その分、センター間のネットワークの帯域の確保や、ローカル側の性能遅延発生を抑制するための仕組みや管理などが複雑になります。

　非同期型は、ローカル・データとリモート・データの差異の発生程度と、管理負荷が反比例の関係になり、データの差異の許容度が大きいほど、日常的な管理負荷は軽減されます。
自社の論理要件（ストレージ・サービス・カタログ）を元に、リモート・バックアップ・アーキテクチャを検討し、それに伴う投資額や、日常的な運用負荷を合わせて検討し、投資対効果が適切でない場合は、論理要件の見直しを含め、現実的な実装計画に調整をしていくアプローチが必要となります。

●●●

　これまで、論理要件から、実現可能なアーキテクチャを検討していく段階を紹介してきました。実際の現場では、さまざまな制限や、投資対効果の側面から、論理要件の見直しが必要になる場合が多く見られ、それにより若干の手戻りが発生します。

　現実には、論理要件と物理要件（アーキテクチャ）を同時に検討されることもよくありますが、その場合、業務要件から発生すべき論理要件が、アーキテクチャを前提とした論理要件になってしまう場合が少なくありません。これは、ソリューションの組み合わせや、実現時期の若干の見直しなどにより実現可能となる本来の論理要件を見失う可能性を高めてしまう危険性を含んでいます。特定の時間的制約の中で検討を進めていかなければならない場合が多く、止むを得ないと思いますが、アーキテクトとしては常に自身の本来の目的を忘れずに、業務を推進していっていただきたいと思います。

　さて、これまでの検討により、ストレージ・サービス・カタログが完成に近づいてきました。次回は、このストレージ基盤、ストレージ・サービスを誰が、どのように運用、維持、管理すべきか、という点を検討していきます。

4/4

Index
ストレージ・アーキテクチャとは何か
	Page1 統合ストレージ・アーキテクチャ概要の決定 1. SANストレージ・アーキテクチャ 　　　ストレージ・エリア・ネットワーク（SAN） 　　　ストレージ筐体
	Page2 　　　ディスク構成 　　　論理ディスク構成 　　　ストレージ・ベース・ソリューションの選択 2. NASストレージ・アーキテクチャ 　　　NASネットワーク
	Page3 　　　NASヘッド 　　　ストレージ構成 　　　ファイルシステム構成 　　　ストレージ・ベース・ソリューションの選択
	Page4 3. バックアップ・アーキテクチャ 4. アーカイブ・アーキテクチャ 5. リモート・バックアップ・アーキテクチャ