VERITAS Data Availability Solution
TM V E R I T A Oracle データベースを利用した e ビジネスサイトにおける データ・ストレージ管理ソリューション W S VERITAS Data Availability Solution H I T E P A P E R ベリタスソフトウェア株式会社および VERITAS Software Corporation は、本資料に含まれている誤り、本書によるソフトウェア の動作、および本資料の使用に関して、いかなる損害（直接損害、間接損害、付随的損害、結果的損害、逸失利益、懲罰的損害 を含むがこれらに限定されない）に関して責任を一切負わないものとします。これはベリタスソフトウェア株式会社および VERITAS Software Corporation がかかる損害の発生する可能性について知らされていた場合でも同様です。 発行元：ベリタスソフトウェア株式会社 TM 目次 はじめに.............................................................................................................................................. 1 e ビジネスのための総合データストレージ管理 ............................................................................ 5 I. データストレージ管理のファウンデーション.................................................................................. 8 e ビジネスのデータベース I/O の性質 .......................................................................................... 8 ボリューム：データ整合性と I/O パフォーマンス....................................................................... 10 e ビジネスデータベース用のファイルシステム .......................................................................... 18 データストレージ管理のファウンデーション製品に関するまとめ .............................................. 29 II. レプリケーション........................................................................................................................ 30 レプリケーションはなぜ必要か ................................................................................................. 30 VERITAS のストレージレプリケーション・テクノロジ.............................................................. 30 III. クラスタリング .......................................................................................................................... 41 e ビジネスデータ処理における「処理」の意味 .......................................................................... 41 クラスタの定義 ......................................................................................................................... 41 アプリケーションとクラスタ..................................................................................................... 42 クラスタのコンポーネント ........................................................................................................ 45 クラスタの使用 ......................................................................................................................... 46 IV. データ管理................................................................................................................................. 51 データ管理とはなにか............................................................................................................... 51 バックアップ：データ管理の核 ................................................................................................. 51 バックアップポリシー............................................................................................................... 56 フルバックアップとインクリメンタルバックアップ................................................................... 57 バックアップとデータベース..................................................................................................... 60 バックアップ・ストラテジー..................................................................................................... 64 バックアップのその他の形態..................................................................................................... 65 アーカイブ ................................................................................................................................ 66 ストレージリソースを効率的に使う：ストレージの階層管理 ..................................................... 67 V. まとめ......................................................................................................................................... 71 VERITAS ソリューションを選ぶ理由......................................................................................... 71 TM 図 図 1：e ビジネスのデータアクセス/管理「スタック」.......................................................................... 6 図 2：VERITAS Volume Manager のミラー構成 ..................................................................................11 図 3：異なるタイプの RAID ボリュームの耐障害性............................................................................ 12 図 4：2 次障害の可能性を最小限に抑える再配置（ホットリロケーション）....................................... 13 図 5：Volume Manager の RAID5 ロギングとダーティリージョンロギング ........................................ 14 図 6：システムクラッシュ後のデータベースのリカバリ..................................................................... 15 図 7：データテーブルのレイアウトへのデータストライピングの効果 ................................................ 17 図 8：エクステントベースのファイルシステム .................................................................................. 19 図 9：アプリケーションスペースからの直接 I/O を実現する Quick I/O for Databases ......................... 21 図 10：Quick I/O for Databases による 4GB 以上のキャッシュ........................................................... 21 図 11：ボリュームの断片化 ............................................................................................................... 24 図 12：オープン・ファイルの移動..................................................................................................... 24 図 13：ファイルシステム・スナップショットの流れ.......................................................................... 27 図 14：データベースのスナップショットの作成 ................................................................................ 28 図 15：ファイルおよびボリュームのレプリケーション ...................................................................... 31 図 16：VERITAS の同期ボリュームグループレプリケーションの流れ ................................................ 34 図 17：同期レプリケーションと非同期レプリケーションのパフォーマンス........................................ 35 図 18：データベースのためのハイブリッドレプリケーション・テクノロジ........................................ 37 図 19：レプリケーションとネットワーク停止.................................................................................... 38 図 20：IBC メッセージの流れ............................................................................................................ 39 図 21：相補的な災害復旧 .................................................................................................................. 39 図 22：基本クラスタモデル............................................................................................................... 41 図 23：クラスタサービスリソース依存関係グラフ ............................................................................. 43 図 24：VERITAS クラスタリングモデル ............................................................................................ 45 図 25：クラスタ内の全ストレージ共有と部分ストレージ共有 ............................................................ 47 図 26：並列サービスリソースグループ.............................................................................................. 48 図 27：同時アプリケーションアクセスによるデータ不整合のシナリオ .............................................. 49 図 28：クラスタテクノロジとレプリケーションテクノロジの結合 ..................................................... 50 図 29：バックアップを構成する機能要素........................................................................................... 53 図 30：スケーラブルなバックアップアーキテクチャ.......................................................................... 54 図 31：大企業向けのバックアップアーキテクチャ ............................................................................. 55 図 32：フルバックアップとインクリメンタルバックアップ ............................................................... 58 図 33：フルバックアップおよびインクリメンタルバックアップによるファイルシステムの復旧......... 59 図 34：差分バックアップと累積バックアップからファイルシステムを復旧する................................. 60 図 35：ストレージチェックポイント ................................................................................................. 61 図 36：複数のチェックポイントとデータベースのロールバック......................................................... 62 図 37：データベースにおけるインクリメンタルバックアップの問題.................................................. 63 図 38：ストレージチェックポイントを使った整合性のあるデータベースバックアップ ...................... 63 図 39：アーカイブとバックアップ..................................................................................................... 66 図 40：ストレージの階層 .................................................................................................................. 67 表 表 1：RAID の e ビジネスアプリケーション：可用性..........................................................................11 表 2：RAID を用いる e ビジネスアプリケーションのパフォーマンス................................................. 16 表 3：週間バックアップスケジュールのサンプル............................................................................... 60 はじめに ビジネスを電子的に展開する場合、方法はさまざまですが、その本質は、人々を情報で結びつけるこ とです。e ビジネスを機能させるための情報は、たいていコンピュータ・システムで格納され管理され る電子データの形式になっています。この情報は、e ビジネスを形成するパートナ（従業員、納入業者、 およびカスタマ）が利用するもので、以下の条件を備えている必要があります。 è 信頼性 システムが応答をしないというのは、カスタマの信頼を打ち砕く最も簡単な方法です。 è システムにディスク障害が発生したのか、アプリケーションが停止したのか、システム保守のた めに装置の再設定が必要なのか、そんなことは問題ではありません。電子ビジネスを展開すると いうことは、パートナのニーズに応じていつでも情報を使用可能にしておく必要があるというこ とを意味します。 è パフォーマンス e ビジネスは、1 クリックの勝負です。カスタマまたはビジネスパートナは、情報を照会したとき、 コンピュータ・システムがどれだけ多忙を極めていたとしても、すぐさま応答が返ってくること を期待しています。 è 管理の容易性 装置の障害や人間の手による間違いから情報が保護されている必要があります。オンラインデー タは、保存したり、必要な場所に移動したりすることが必要で、しかも実稼働中にこれを行わな ければならないことも珍しくありません。 è 拡張性 e ビジネスの成長には実に信じがたいものがあります。あるアナリストの予測によれば、企業はた だオンライン化するだけで、その収益を 50%伸ばすと言われています。しかし、e ビジネスの成 長に伴いシステムも拡張することができない限り、成功は失敗へと転じてしまう可能性がありま す。 è 災害対策 オンライン化することにより、経営を合理化し、コストを削減し、収益性を改善することができ ます。しかし、いったんオンライン化したら、もう後戻りはできません。火災があろうと洪水や 大規模な停電が起きようと、電子データとアプリケーションは使用可能な状態になっていなけれ ばならないのです。不測の事態が発生したときにも、e ビジネスは「正確に動き続けて」いる必要 があるのです。 本書のテーマは、e ビジネスのためのデータストレージ管理です。これには、電子データの可用性の維 持、データへの高速アクセスの提供、データの管理、ビジネスの成長に合わせたデータの拡張、災害 からのデータの保護が含まれます。ここでは、VERITAS のテクノロジを使用して、e ビジネスの展開 を可能にする情報資産を保持するためのストレージを管理する方法についても説明します。 e ビジネスのデータの要件 リレーショナルデータベースは、e ビジネスを高速で効率的にオンライン展開するために必要なテクノ ロジです。データベーステクノロジは成熟した堅固なテクノロジであり、今日のミッションクリティ カルなアプリケーションの大半は、データベースを基盤としています。データベース管理システムは、 www.veritas.com/jp VERITAS Data Availability Solution Page 1 トランザクションの一貫性を維持し注１、複数のアプリケーションが同じデータに同時にアクセスした 場合にも、整合性が失われないようにします。 データベース管理システムは、データの整合性も保証します。個々のデータ項目は、それを使用する アプリケーションの数に関係なく、整合性が保証されます。組み込みフィルタは、無効な値がデータ ベースに入ることを防ぐことができます。システムまたはアプリケーションに障害が起きた後でデー タベースの一貫性を再構成するには、REDO ログが役立ちます。 データベースは、アプリケーションスィートの導入にも役立ちます。SAP R3、Baan、PeopleSoft など の主要なビジネスアプリケーションは、データベーステクノロジを基礎としています。Oracle 等のデ ータベース・ベンダが、基礎となるデータベース管理テクノロジを活用した、完成されたビジネスア プリケーションスィートを提供しています。 --------------------------------------注 1 トランザクション全体が処理されるか、全体がロールバックされて何も処理されないかのどちらかです。「半分だけ処理 済み」のトランザクションが生じてデータが破壊されることはありません。 ---------------------------------------- e ビジネス用のデータベース管理システム e ビジネスには、コンピューティングの分野で最も取り組みがいのある IT 要件がいくつかあります。1 日 24 時間、週 7 日間フル稼働のインターネットビジネスは、少なくとも企業のデータセンターにイン ストールされている最も完成度の高いアプリケーションと同じだけの堅牢性を備えていなければなり ません。その一方で、この新しいビジネスの躍進は、ハードウェアの追加や配置変更、電子ファイル の移動や再作成など、アプリケーションがビジネスニーズやビジネス手法と共に進化するにつれて、 そのたびにハードウェアの構成も頻繁に再設定が必要になるということを意味します。この混沌した 状態においても、カスタマ、納入業者、および従業員が、必要な情報に対する信頼できるアクセスを、 不満を感じさせないパフォーマンスレベルで提供することが問題となってきています。 Oracle 等のデータベース管理システムが、混沌とした e ビジネス環境に秩序をもたらすのに役立つの は明らかです。データベース管理の基本概念は、データとアプリケーションを分離することです。デ ータベースは、安定性、データ整合性の保証、トランザクションの一貫性、およびリカバリを提供し ます。つまり、アプリケーションと IT インフラストラクチャが成長し、変化し、置き換えられるのに 歩調を合わせて、 「データを全体として保持する」ための能力を提供するものです。 データベース管理システム用のオンライン・ストレージ データベース管理システムが、e ビジネスで要求される厳しい条件を満たす方法であることは明らかで す。しかし、データベース管理システムは真空中に存在しているわけではありません。基礎を成すス トレージの品質が高ければ高いほど、データベース管理システムが実行できるジョブも優れたものに なります。データベース管理システムには、ストレージから提供される以下の 3 つの属性が必要です。 è 信頼性 データベース管理システムは、非常に多数のディスクブロックのコンテンツをユーザデータとメ タデータから成る、相互に関連するテーブルに編成します。これらのテーブルの集合が e ビジネ スの状態を表すものになります。データベース管理システムはデータの論理的な整合性を維持す ることでは素晴らしい能力を発揮しますが、データの物理的整合性を維持するための、堅実な基 盤によるサポートを必要とします。 è 高性能 トランザクション一貫性を提供するために、データベース管理システムは、I/O オペレーションを 慎重にシーケンス化します。これには、データ整合性を保証しシステム障害後のリカバリを可能 Page 2 VERITAS Data Availability Solution www.veritas.com/jp にする、多数のオーバヘッドオペレーションも含まれています。データベース管理システムの物 理ストレージは、一般に、アプリケーションデータベースリクエストが示唆する速度よりはるか に高い稼働率で働くことになります。データベース管理システムは、キャッシュを幅広く活用す ることによって物理 I/O を最小限に抑える努力をしますが、最終的には、ディスクの読取りと書 込みが必要です。データアクセスのパフォーマンスが高いほど、アプリケーションの応答性も高 くなります。 è 拡張性 データベース管理システムは、概して拡張性に優れています。ほとんどのシステムは、オンライ ンデータベースにストレージを追加する機能をサポートしています。しかし、この機能を活用す るためには、ストレージにも、ダイナミックに拡張できる機能が備わっていることが必要です。 ストレージをオンラインデータベースに追加できるだけでなく、すべてのストレージリソースに わたって I/O の作業負荷をダイナミックに調整して均衡化し、アイドル状態のものがある一方で 一部のディスクやバスに過剰の負担がかかるといったホットスポットの発生を回避できるだけの 能力が必要です。 e ビジネス用ストレージの選択：ディスクかボリュームか データベース管理者は、データベースのテーブルスペースとメタデータを入れるためのコンテナとし て、Raw パーティションを使用するか論理ボリュームを使用するかを決定する必要があります。Raw パーティションは、連続番号の付いたディスクブロックの範囲で、I/O ドライバに対して直接発行され た I/O リクエストによりアドレスされます。ボリュームは、ディスクブロックを論理的に組み合わせた もので、VERITAS Volume Manager などのホストソフトウェアや（より限定された形で）RAID コント ローラに実装されたボリューム管理ツールから提供されるものです。ボリューム管理ツールの役割は、 物理ディスクを細分化または結合して、所要のパフォーマンスおよび可用性を達成することです。ボ リューム管理ツールは以下のことができます。 è 大きいディスクを複数の小さいボリュームにパーティション分割する。 è 複数のディスクからなるストレージの一部または全部を連結またはストライプして、1 つの大きい ボリュームとして扱えるようにする。 è 同じデータのコピーを 2 つ以上のディスクまたはディスクセットにミラーする。 è データのパリティを作成して、ディスク障害によるデータの喪失からデータを保護する。 ボリューム管理ツールは、Disk 装置単体で提供できる最大サイズ、最大パフォーマンスを向上するこ とができます。一般に、データベースユーザは、以下のような小さな制約があるにしても、ボリュー ムを好む傾向があります。 è データの整合性 RAID 製品によっては、書込みキャッシュを使用してパフォーマンスを高めています。この場合、 適正な保護措置を講じないと、システムクラッシュが生じたときにはデータベース管理システム でデータの整合性を確保することが困難です。 è ボリュームの操作性 ハードウェア RAID 製品は一般的に、ホストオペレーティング環境との統合が密接ではありませ ん。このタイプではほとんどの場合、ボリュームは SCSI ディスクまたはファイバチャネルディス クをエミュレートしています。この場合、ダイナミックなディスク容量の拡張、システム再起動 www.veritas.com/jp VERITAS Data Availability Solution Page 3 の必要のない障害 （例えばパリティ付き RAID ボリューム内の単一ディスクの障害）への対処な どのような、ディスク側にそれに対応する機能がないようなボリューム固有の機能は、使用が困 難になる可能性があります。 上記ような問題は VERITAS Volume Manager にはありません。また、上記のような問題のあるなしにか かわらず、ボリュームはデータベース管理システムのストレージ基盤として一般に好まれています。 e ビジネス用ストレージの選択：ファイルシステムかパーティションか 直観的には、ファイルはデータベーステーブルとインデックスを入れるための理想的な「コンテナ」 になるように見えます。ファイルは便利で管理可能です。ファイルは必要なときに拡張することもで きます。しかも、簡単で分かりやすい管理オペレーションにより、どこにでも移動することができま す。ファイルはバックアップに適したオブジェクトです。従来のファイルシステムには、データベー スストレージとして使用する場合に、このような利点を相殺する幾つかの欠点があることが分かって います。 è 永続性の保証が弱い ほとんどのファイルシステムは、ライトバックキャッシュを使用することによって、アプリケー ションのパフォーマンスとデータの整合性との間の調整を図っています。データが実際にディス クに書き込まれる前に、アプリケーションの書込みリクエストの完了を示すシグナルが出されま す。書込みはその後ゆっくりと行われるので、実際に完了する前に、データが安全に格納された という前提のもとで、アプリケーションが何らかのアクションを実行してしまうこともあります。 この場合、アプリケーションのパフォーマンスは向上しますが、ディスクにまだ書き込まれてい ないデータがキャッシュにある時点でシステムクラッシュが発生すると、失われた更新情報はリ カバリ不能になり、 「対応する貸し方のない借り方（debit without matching credit） 」というデータ ベースシナリオを招くことになります。 è パフォーマンス特性が望ましくない 大半のファイルシステムは、データをディスクに書き込む前に、プライベートバッファキャッシ ュにデータを移動します。これによって、アプリケーションが誤って書込みが完了する前に不用 意にメモリが上書きされた場合でも、ディスクには確実に正しいデータを書き込むことができま す。しかし、大量のデータをメモリのある部分から別の部分に移動することは、大きなパフォー マンス上のペナルティを強いることになります。データベース管理システムには、このような書 込み時の保護は必要ありません。データベース管理システムにとっては、専用のメモリスペース との間で直接の I/O オペレーションを行う方が望ましいためです。 è ファイル共有時の最適化が不十分 ほとんどのファイルシステムでは、任意の数のアプリケーションを同じファイルから同時に読取 ることができますが、そのファイルへの書込みを行うことができるのは、同時にアプリケーショ ン 1 つだけです。ほとんどの場合、これはアプリケーションにとっては道理にかなった方式です。 2 つのアプリケーションが同じファイルに同時に書込みを行うと、互いの更新に干渉し合ってデ ータを破壊する可能性があるからです。Oracle 等のデータベース管理システムでは、並行実行さ れるスレッドから成っています。したがって、ファイルシステム側から見れば、多数の個別アプ リケーションのようなものです。しかし、通常のアプリケーションとは異なり、データベース管 理システムのスレッドは共同作業のための高度な調整が施されています。 2 つ以上のスレッドは、 不整合を引き起こさない場合に限り、同時に 1 つのデータオブジェクトにアクセスすることがで きます。一度に 1 つのスレッドのみにアクセスを制限することは、データベースのパフォーマン Page 4 VERITAS Data Availability Solution www.veritas.com/jp スを不必要に拘束することになります。 以上のような理由から、従来のファイルシステムは、データベース用のコンテナとしては不適切だと する考えが一部にあります。しかし、VERITAS のファイルシステムには、このような制限は何もあり ません。それだけでなく、VERITAS のファイルシステムには他にも次の節で述べるようなさまざまな 利点があり、e ビジネスのデータベースストレージとして明らかに最適な選択肢です。 e ビジネスのための総合データストレージ管理 オンラインでビジネスを展開する場合には避けられない、あらゆる予測不能な状況のもとで、データ ベースが最適に稼働するためには、以下の特性を備えた、基礎となるインフラストラクチャが必要で す。 è 堅牢で高性能のストレージ環境を提供する。 è データベースの稼働中もバックアップおよびその他の管理オペレーションを実行できる。 è 広範囲の容量にわたるデータベース拡張をサポートできる。 è データの最大限の可用性を確保する。たとえ災害が発生した場合であっても。 総合的に、VERITAS のテクノロジは、e ビジネス用のデータベースに適した上記のようなインフラス トラクチャを提供します。VERITAS では、このインフラストラクチャをデータストレージ管理という 名前で呼んでいます。e ビジネスデータベース用の VERITAS のトータルなデータストレージ管理は、 I/O 管理およびストレージ管理を広くカバーする複数のソフトウェアテクノロジを統合したものです。 VERITAS は、さらに一歩進めて、そのテクノロジの幾つかを主要なアプリケーション管理システムと 組み合わせ、環境に合わせて最適化したカスタマイズ済みのストレージ管理スィートを作成しました。 VERITAS Database Edition for Oracle は、そのようなスィート製品の 1 つです。 VERITAS Database Edition for Oracle VERITAS Database Edition for Oracle は、以下のコンポーネントで構成されています。 è VERITAS File System データベースの作業負荷のために最適化された、高性能で高速リカバリのファイルシステムです。 è VERITAS Volume Manager データのストライピング、ミラーリング、およびその他のデータの可用性とパフォーマンスの向 上をもたらす機能をサポートする、ボリューム管理ツールです。 è VERITAS Visual Administrator VERITAS File System および Volume Manager に対して、操作しやすいグラフィカルユーザインタ フェースを提供します。 è VERITAS Quick I/O for Databases VERITAS のファイルシステム上に作成された Oracle データベースの Raw ディスクのパフォーマ ンスを向上させるファイルシステムの I/O 方式。Cached Quick I/O モードは、大容量システムメモ リを利用して頻繁にアクセスされるデータをバッファに格納することにより、さらにデータベー スのパフォーマンスを向上させます。 è Storage Checkpoints ファイルシステムの一時的なイメージを保存する機能です。Storage Checkpoints を利用し、デー www.veritas.com/jp VERITAS Data Availability Solution Page 5 タベースをある時点のイメージにリカバリする Storage Rollback および NetBackup DateCenter を連 携した BLIB（Block-Level Incremental Backup：ブロックレベル・インクリメンタル・バックアッ プ）を実現します。 VERITAS File System、Volume Manager、および Visual Administrator は、その利点をすべてのアプリケ ーションが活用できる製品です。Quick I/O for Databases と Storage Checkpoints は、Oracle の機能と統合 されて、Oracle に固有の利点を提供します。 データアクセスと管理スタック トータルなデータストレージ管理のコンポーネント（VERITAS Database Edition for Oracle に組み込みの ものとその他のものの両方）の位置関係を理解しやすいように、図 1 に、アプリケーション実行環境 でのデータアクセスおよび管理の概観を示します。ネットワークの類似概念を借りて表すと、図 1 は、 e ビジネスアプリケーション用のデータアクセス/管理スタックと考えることができます。 e ビジネスアプリケーション e ビジネスアプリケーション e ビジネスアプリケーション e ビジネス アプリケーション データベース管理システム データベース管理システム Oracle 階層ストレージ管理 VERITAS の トータルなデータ ストレージ管理 その他のストレージ 管理ツール バックアップ クラスタリング データのレプリケーション データ管理 クラスタリングと レプリケーション ファイルシステム ファウンデーション ボリューム管理ツール Solaris, HP-UX, その他 ストレージハードウェアのデバイスドライバ ストレージサブシステム（RAID コントローラまたはテープライブラリ） オペレーティング システム ストレージ ハードウェア 図 1 e ビジネスのデータアクセス／管理「スタック」 図 1 に示すように、e ビジネスのデータベースアプリケーションにはかなりのソフトウェアインフラス トラクチャが必要です。 VERITAS のトータルなデータストレージ管理ソフトウェアは、このインフ ラストラクチャを提供します。本書では、 VERITAS のトータルなデータストレージ管理ソフトウェ アのテクノロジを以下の項目に分けて説明します。 è ファウンデーションテクノロジ VERITAS File System および Volume Manager を合わせて、または個別に使用することによって、 高性能、フレキシブル、かつスケーラブルな e ビジネスデータベースのシステム基盤を構築する ことができます。これらのソフトウェアを使用することにより、データのストライピング、RAID、 特定時点スナップショット、BLIB（Block Level Incremetal Backup：ブロックレベル・インクリメ ンタル・バックアップ） 、オンラインのストレージ拡張と再構成、およびシステムクラッシュから の高速リカバリが可能になります。 è データレプリケーションテクノロジ VERITAS Storage Replicators は、データセンター全体にわたる障害が発生した場合にも、データへ Page 6 VERITAS Data Availability Solution www.veritas.com/jp のアクセスを保証します。レプリケーションを元に、地理的に離れて配置されたデータセンター にタイムリーに情報を配布することができ、そのセンタで情報を使用できるので、通信回線を短 縮したり、データセンターの災害または環境的な災害からのリカバリを図ることができます。 è クラスタリングテクノロジ VERITAS Cluster Server は、コンピュータ、ストレージ、またはデータセンターに大規模な障害が 発生した場合にも、e ビジネスのビジネス活動を維持することができます。アプリケーションを実 行中のコンピュータに問題が発生したとき、クラスタリングは、アプリケーションを代替コンピ ュータに「フェールオーバ」する機能をサポートします。アプリケーションによっては、クラス タリングにより、既存のクラスタに新しいコンピュータを順次追加して、増分的に拡張すること ができます。 è データ管理テクノロジ e ビジネス情報は、1 日 24 時間、週７日間フル稼働のオンライン環境の中で管理する必要があり ます。e ビジネスの典型的な特徴となっている爆発的成長は、これまでの IT 環境よりはるかに困 難な問題を生み出しています。VERITAS の NetBackup と Storage Migrator は、この難題にさまざ まな方法で対処します。データベース管理システムが常に認識しているバックアップにより、ト ランザクションレベルで一貫性のあるデータベースバックアップを作成することができます。ま た、プログラムイメージおよびその他の補助的なファイルの最新コピーを維持することができ、 必要な場合にはそれを使用してオペレーティング環境を高速でリストアすることができます。階 層ストレージ管理は、ほとんど使用されていないファイルを検出し、それらをオフラインに切り 替えて、オンラインのストレージおよび I/O リソースを解放し、ビジネス活動に使用できるよう にします。モニタリングテクノロジは、ストレージ管理ポリシーを決定するための客観的な基盤 を提供します。 本書では、以下 4 章にわたって、上記の分類したテクノロジグループについて詳しく説明し、e ビジネ スのデータベースストレージ管理のためのニーズに対処するためにはこれらのテクノロジをどのよう に組み合わせればよいかを示します。最後の章では、総合データストレージ管理を提供することで VERITAS がなぜストレージ管理テクノロジのリーダーとなるのか、その理由を明らかにします。 www.veritas.com/jp VERITAS Data Availability Solution Page 7 I. データストレージ管理のファウンデーション 情報への高性能オンラインアクセス e ビジネスのデータベース I/O の性質 VERITAS は、ボリューム管理およびファイルシステムのテクノロジを統合して、e ビジネスデータベ ースのための高度な可用性、パフォーマンス、およびスケーラビリティを備えたストレージ管理のた めのファウンデーションを提供しています。VERITAS は、e ビジネスのデータベースのために、その I/O 特性にマッチした、理想的なデータストレージ管理を提供します。 e ビジネスアプリケーションは、典型的な I/O リクエスト集約型のアプリケーションです。この種のア プリケーションは、毎秒膨大な数の I/O リクエストを実行しますが、個々のリクエストはわずか数キロ バイトを転送するだけです。アプリケーションのリクエストが発生する順序は予測不能なので、e ビジ ネス管理システムは、ストレージにランダムにアクセスすることになります。このようにランダムな アクセスと小規模な I/O リクエストが結びついているということは、e ビジネスデータベース I/O のパ フォーマンスにとって、データの転送より、データのアクセス（ディスク読み書きヘッドを正しいデ ィスクプラッタの正しい位置に置く）の方が重要であることを意味します。データにアクセスするに は大きな機械的コンポーネントが必要になるので、ディスクの機械的パフォーマンスがアプリケーシ ョンのパフォーマンスに大きな影響を与えます。 I/O リクエスト集約型アプリケーションのパフォーマンスを改善するには、方法が 2 つあります。 è ソリッドステートメモリ（solid state memory）にデータをキャッシュする è ディスクの数を増やし、ディスク間での I/O 負荷の調整を図る キャッシュとデータベース管理システム キャッシュは、データベースからの読取りに大きな効果を発揮します。一度キャッシュにデータを読 み込んでおけば、そのデータは何十回もアプリケーションから利用できます。データベース管理シス テムでは、ホストベースの読取りキャッシュが幅広く活用されています。大規模なデータベースが使 用するキャッシュの量は、データベース管理システムが直接取り扱える量を簡単に超えてしまう可能 性があります。先述の VERITAS Cached Quick I/O for Databases では、きわめて大きい読取りキャッシ ュメモリを活用できます。書込みキャッシュは、これとは少々様相が異なります。ライトスルーキャ ッシュでは、書込みオペレーションの完了が通知される前に、データがディスクに書き込まれます。 ライトバックキャッシュでは、完了は通知されますが、ディスクへのデータの書込みは都合のよい時 点に達するまで遅延されます。ライトスルーキャッシュによる書込みのパフォーマンスは、キャッシ ュがまったくない場合の書込みのパフォーマンスと、ほぼ同じです。このキャッシュが効力を発揮す るのは、最近書き込まれたデータをアプリケーションが再度読み取って使用し、しかもキャッシュか ら直接そのデータを送達することができる場合です。 これに対して、ライトバックキャッシュを使用すると、アプリケーションはディスクからの応答を待 たずに処理を進めることができるので、アプリケーションのパフォーマンスは著しく向上します。し かし、これには、電源障害またはその他のシステム障害によりキャッシュの内容が破壊された場合に、 アプリケーションにより書き込まれたデータが事実上消滅するという危険性があります。データベー ス管理システムにはデータの保全性という点について定評がありますが、その一部は、ユーザデータ に関する確実で検証可能な安全性をどれだけ提供できるかという能力に依存しています。特に、デー タベース管理システムでは、トランザクションがコミットされたことをアプリケーションに通知する Page 8 VERITAS Data Availability Solution www.veritas.com/jp 前に、更新が安全確実にディスクに記録されていることが必要です。その理由は簡単です。コミット されたデータベース更新に関するデータが揮発性のキャッシュにしか入っていないとすれば、電源障 害またはその他のシステム障害によりそのデータのトレースがすべて無に帰し、ビジネス活動と電子 的な記録との間に不整合が生じるおそれがあるからです。 データベースベンダは、一般に、揮発性のライトバックキャッシュの使用を推奨していません。ほと んどのベンダは、RAID サブシステムおよびディスクライトバックキャッシュを利用しないよう勧めて います。その根拠は、ライトバックキャッシュを使用した場合、データベース管理システムは、デー タがどの時点で安全にディスクに格納されたかを正確に知ることができず、したがってデータ保全性 を保証することができないという点にあります。したがって、ライトバックキャッシュは最も有効な I/O パフォーマンス向上の手段の 1 つではありますが、データベース管理システムはライトバックキャ ッシュからはまったく利益を得ることができない場合が多いというのが実情です。 I/O ロードバランシング I/O リクエスト集約型のアプリケーションにとって、ディスクの機械的パフォーマンスは重要な要件に なります。それならディスクの数を増やし（つまり個々のデータ項目にアクセスするために使用でき る容量を増やし） 、それらのディスク間にデータを分散することによって、パフォーマンスを改善する ことができるはずです。しかし、残念ながらほとんどの場合、事はそれほど単純ではありません。ほ とんどのアプリケーションにはデータアクセスの「ホットスポット」というものがあり、少数のテー ブルセグメントまたはインデックスが、データベース内のその他の部分よりはるかに頻繁にアクセス されるという現象が生じます。ホットスポットには、例えばインデックスツリーのルートのように恒 常的なものもあります。しかし、その他のホットスポットは刻々と変化します。例えば、ある一日を とった場合、早い時間における顧客データベースのホットスポットは、東海岸地域の顧客レコードを 含むテーブルセグメントとなります。時間がたつにつれて、アクティビティの比重は西海岸地域のレ コードを含むテーブルセグメントに移っていきます。 個々のインデックスまたはテーブルセグメントがそれぞれ異なるディスクに格納されているとすれば、 インデックスまたはテーブルのアクセス速度はディスクのパフォーマンスにより制限されます。大き いデータベースを含む少数のディスクだけに I/O リクエストが集中し、大半のディスクは遊んでいると いう現象も珍しいことではありません。 アプリケーションのパフォーマンスを改善する方法の 1 つとして、インデックスとテーブルセグメン トを再配置して、アクセス頻度の高いものを複数のディスクに分散することが考えられます。この方 法は原理的には有効ですが、次の 3 つの理由により、効果が得られない場合がしばしばあります。 è 時間とリソースが大量に必要になる この技法によりパフォーマンスを改善するには、データベース管理者は、アクセス速度を監視し、 結果を分析し、データオブジェクトを移動するために時間を使わなければなりません。ほとんど のデータベース管理者にとって最も避けたいのは反復的な作業です。また、データベースにおい て最も回避すべきなのは、オンライン状態における非生産的なバックグラウンド I/O です。 è 分析結果についての保証がない データオブジェクトをディスク間で入れ替えるためには分析が必要ですが、この種の分析は、過 去のデータベースの動向が将来も同じであるという前提に基づいて行われます。データベース内 の使用頻度の高い部分が月曜日と火曜日とでは異なっているとすれば、このような調整を行って も効果はなく、管理者はさらに分析を繰り返さなければなりません。 www.veritas.com/jp VERITAS Data Availability Solution Page 9 è 不可能な場合がある 通常、テーブルは、1 種類のインデックス（例えば、顧客名の範囲、または郵便番号の範囲）に 基づいてセグメント化され、セグメントは異なるディスクに格納されます。しかし、データアク セスとこのセグメント化の間に相関関係があれば、依然としてホットスポットは発生します。た とえば、ソートされた一群のトランザクションが、名前が「B」で始まっている顧客のレコードを 更新するとします。この場合、該当するテーブルセグメントを含むディスクだけがアクセスされ、 他のディスクは遊んでいるという状況が生じます。 VERITAS Volume Manager は、データブロックを複数のディスク間にストライピングすることにより、 ほとんどすべての I/O 負荷を均衡化します。データストライピングとは、データベース管理システムに とって透過的な形で、個々のテーブルを複数のディスクに分散する技法です。データストライピング を使用すれば、どのテーブルセグメントが「ホット」な状態になるかはまったく問題になりません。 各テーブルが複数のディスクに分散されているので、アクセスはすべてのハードウェアリソースの間 で均衡化されます。 ボリューム：データ整合性と I/O パフォーマンス e ビジネスアプリケーションの第 1 の条件は、ストレージをいつでも使用できるということです。e ビ ジネスを成功に導くには、たとえディスク、I/O バス、さらにはコンピュータにまで障害が生じたとし ても、情報が常にアクセス可能な状態になっていなければなりません。VERITAS Volume Manager は、 物理ディスクを仮想ディスクの集合体として編成し直して、ディスクや I/O バスに障害が発生してもそ の影響を回避できるようにします。データベース管理システムやその他のアプリケーションから見れ ば、ボリュームは機能的には物理ディスクと同じです。ボリュームはディスク障害を乗り越えて生き 残りますが、そのためにホストベースの RAID テクノロジが使用されます。ホストベースの RAID ボ リュームはディスクサブシステム RAID とほぼ同じものであり、その主な利点としては次の 2 つがあ ります。 è ハードウェアに対する初期および追加の投資が非常に少なくてすむ ある e ビジネスが最初に稼働する時点では、一般に多量のオンライン情報は存在しません。ホス トベースの RAID は、低価格の市販ホストバスアダプタに接続された低価格の市販ディスクで稼 働できるので、少量のデータを保護する場合、ストレージハードウェアに対する多額の投資をす る必要がありません。この e ビジネスが成長を続け、オンラインデータが増加するにつれて、ホ ストベースの RAID は、1 ディスクずつ段階的に拡張することができます。しばしば高額の追加投 資が必要となるハードウェア RAID サブシステムとは、この点が異なります。 è ホストベースのボリュームは RAID ディスクサブシステムを補完する e ビジネスが成長し、 アプリケーションの数とアクセスされるオンラインデータの量が増加するに つれて、単に物理的なパッケージングという理由だけでも、最終的にはハードウェア RAID が必 要になることがあります。ホストベースのボリュームは、ハードウェア RAID アレイを統合して、 容量を増やしたり可用性を向上させたりすることができます（例えば、複数のディスクサブシス テムにわたるデータのミラーリング）。 どのような種類の RAID があるのか VERITAS Volume Manager は、非冗長ボリュームだけではなく、ミラー化およびパリティ付き RAID の Page 10 VERITAS Data Availability Solution www.veritas.com/jp 両方のボリュームをサポートしています。表 1 は、サポートされる各ボリュームタイプと、その可用 性に関する特性を示しています。 ボリュームタイプ データ保護（可用性） e ビジネスデータベースアプリケーション ミラー（2x 以上） （RAID 1） きわめて高い 比較的小さい（単一ディスク） クリティカルなデータオブジェクト ストライプおよびミラー（RAID 0＋1） きわめて高い 大きい（複数ディスク） クリティカルなデータオブジェクト パリティを伴うストライピング （RAID 5） 高い 重要な「ほとんど読取り専用」のデータ パリティなしのストライピング （RAID 0） 単一ディスクより低い 最小限の適用度 （容易に交換できる重要度の低いデータ） 連結（容量集約型） 単一ディスクより低い 最小限の適用度 （容易に交換できる重要度の低いデータ） 表 1 RAID の e ビジネスアプリケーション：可用性 表 1 から分かるように、ミラー化ボリュームは、ディスク障害に対する最も優れた保護能力を備えて います。これは、単に、冗長データを保持するディスクの数が多いため、複数の障害モード（すべて ではありませんが）を乗り切って生き残ることができるということです。さらに、ディスクに障害が 生じた場合、パリティ付き RAID の場合よりアプリケーションのパフォーマンスに対する影響が少な くてすみます。VERITAS Volume Manager は、図 2 に示すように、複数のディスクにまたがる複数のデ ータ領域、複数のディスク全体、または複数のマルチディスクセットにわたってデータをミラー化す ることができます。 ディスク A ミラー化テーブル ディスク A ディスク A ディスク C ミラー化テーブル ミラー化大規模テーブル （前半部分） ミラー化大規模テーブル （後半部分） ディスク B ディスク B ディスク D ミラー化テーブル ミラー化大規模テーブル （前半部分） ミラー化大規模テーブル （後半部分） 追加できる ストレージ容量 成長 成長 ディスク B ミラー化テーブル 追加できるストレージ容量 ディスク容量の一部が他の ディスクにミラー化される ディスク容量の全体が他の ディスクにミラー化される マルチディスクデータセッ トが他のディスクセットに ミラー化される 図 2 VERITAS Volume Manager のミラー構成 このようなフレキシビリティがあるため、少ないコストで開始し、成長に伴いストレージ容量を追加 することができるので、一度に多額の投資の追加が必要になることがありません。オンラインボリュ ーム管理ユーティリティは、アプリケーションがデータを使用中であっても、ボリューム間でのデー タの移動をサポートします（この様子が、図 2 の「成長」の方向に示されています）。 ミラー化ボリュームのその他の利点 VERITAS Volume Manager は、データの同じコピーを 3 つ以上別々のディスクに保持することができま す。このような第 3 コピー・ミラーリングは、主要なデータベースのコピーを一時的に凍結し、他の www.veritas.com/jp VERITAS Data Availability Solution Page 11 目的（バックアップや新規アプリケーションのテストなど）に使用する場合に便利です。VERITAS の 第 3 コピー・ミラーリングでは、ボリュームのコピーの 1 つを他の目的のために切り離しても、アプ リケーションは、依然としてディスク障害に対する保護能力を備えたデータベースを使用することが できます。 I/O 負荷を均衡化するデータストライピング VERITAS Volume Manager は、複数のディスクにわたるデータのストライピングもサポートしており、 負荷が均衡化されるため最適なパフォーマンスを達成することができます。データは、次の 3 種類の 構成で複数のディスクにわたってストライピングすることができます。 è 障害保護なし この構成は RAID 0 とも呼ばれるもので、複数のディスクリソースにわたって I/O 負荷を均衡化し ますが、ディスク障害に対する保護の能力はありません。この構成を、クリティカルな e ビジネ スデータに使用するのは望ましくありません。 è パリティ保護付き この構成は RAID 5 とも呼ばれるもので、ミラーリングより低コストの保護機能を提供します。こ れは、「チェックデータ」ディスクが、任意の数のユーザデータディスクを障害から保護するため です。しかし、RAID 5 には書込みのパフォーマンスに難点があり、更新頻度の高いテーブルには 不向きです。e ビジネスアプリケーションの中では、Web ページやデータウェアハウスなどのよ うな、更新頻度がきわめて低いデータに適しています。 è ミラーリング付き この構成は RAID 1+0 とも呼ばれるもので、ミラーリングによる障害保護に加えて、ストライピ ングによるロードバランシングの機能も提供します。これは、ビジネスクリティカルなオンライ ンデータを対象とする、耐障害性、パフォーマンス、および実用性を兼ね備えた優れた構成です。 ミラーリング付きのストライピングは、販売レコードや財務レコードなどのミッションクリティ カルな e ビジネス情報、および、在庫レコード、製造レコード、または出荷レコードなどの更新 頻度の高いデータに使用します。 ディスク A ディスク A ディスク C ディスク E ディスク A ディスク B ディスク C ディスク B ミラー化ボリューム 耐障害性：1 つまたは 2 つ のディスク ディスク B ディスク D ディスク E ストライピングミラー化ボリューム 耐障害性：特定の状況下で最大半数のディスク ディスク B RAID 5 ボリューム 耐障害性： N 個のうちの 1 ディスク 図 3 異なるタイプの RAID ボリュームの耐障害性 RAID 保護されたデータの可用性を維持 特定形式の RAID が e ビジネスに適合するかどうかを左右する最も大きい条件は、障害が発生したと きにデータに何が起きるかということです。ホストベースの RAID において可用性に大きな影響を与 える障害には、次の 2 種類があります。 Page 12 VERITAS Data Availability Solution www.veritas.com/jp è RAID ボリュームの一部となっているディスクの障害 è RAID ボリューム管理ツールを実行しているシステムのクラッシュ RAID とディスク障害 ミラー化ディスクに障害が生じた場合、Volume Manager は、単に、ボリュームに残ったディスクの 1 つにアクセスします。障害ディスクのあるパリティ RAID では、Volume Manager は、アプリケーショ ンのリクエストに対してデータを生成しなおす必要があります。したがって、ミラー化ボリュームと パリティ付き RAID ボリュームのどちらも単一ディスクの障害に対する耐性があります。しかし、デ ィスク障害から速やかにリカバリして、第 2 のディスク障害によるデータの消失を防ぐことも重要で す。ディスク障害からのリカバリは 2 段階に分けて行われます。 è 障害ディスクの代替ディスクを導入する è 障害ディスクの内容を代替ディスク上に再構成する ストレージ管理者は、VERITAS Volume Manager のホットリロケーションを使用して、ディスク障害が 生じたときに自動的に使用されるスペアとして、1 つまたは複数のディスクを事前に指定しておくこと ができます。スペアディスクがあれば、Volume Manager は、ただちにそのディスクを割り当てて、障 害ディスクの内容をスペアディスク上に再構成します。これにより、リカバリのために人手は不要に なり、完全なデータ冗長性をリストアするための所要時間が最小限に短縮されます。 ディスクグループ ストライピングミラー化ボリューム ディスク A ディスク C ディスク E Volume Manager は、指定された スペアを自動的に割り当て、 再構成を開始します。 ディスク A ディスク B ディスク D ディスク E 指定された スペア 図 4 2 次障害の可能性を最小限に抑える再配置（ホットリロケーション） VERITAS Volume Manager は、障害の影響を受けるボリュームをアプリケーションが使用中であっても、 透過的な方法で障害ディスクの内容を再構成します。しかし、再構成は I/O 集約型の作業であるため、 アプリケーションの実行に悪影響をもたらす場合があります。Volume Manager を使用することで、シ ステム管理者は、再構成に伴う I/O を抑制して、アプリケーションへの影響を最小限に抑えることがで きます。 RAID とシステムクラッシュ RAID ボリュームへの書込みは、複数ディスクへの I/O が含まれる場合であっても、アトミックに行わ れるようにする必要があります。つまり、各書込みが完全に行われるか、またはまったく行われない かのどちらかであることが必要です。たとえば、アプリケーションがミラー化ボリュームにデータを 書き込む場合、そのデータはボリュームのすべてのディスクに書き込まれなければなりません。同様 に、アプリケーションが RAID 5 ボリュームにデータを書き込むときは、必ずパリティおよびユーザデ ータの両方が自動的に更新されることが必要です。このアトミックな更新を保証することは、RAID テ クノロジにおける最大の難題の 1 つです。なぜなら、RAID ボリューム更新シーケンスの一部が完了し www.veritas.com/jp VERITAS Data Availability Solution Page 13 た段階で、システム障害が発生することもあるからです。その場合、データが損傷していても、クラ ッシュの後で長い間その損傷が発見されないことがあります。 è ミラー化ボリュームを形成するすべてのディスクへの書込みが終わる前にクラッシュが生じた場 合、以後の読取りリクエストでは、どのディスクで読取りを行うかに応じて異なる結果が生じる ことがあります。 è RAID 5 ボリュームのユーザデータが更新された後で、ただしパリティが更新される前にクラッシ ュが生じた場合は、新たなディスク障害が発生し非現行のパリティを使用してデータが再生成さ れるまで、何週間または何ヶ月も、損傷が発見されないままになることがあります。 RAID ボリュームの更新がアトミックであることを保証するには、次のことが必要です。 è システムクラッシュによりボリュームの一貫性が失われた場合は、それを検出できる。 è クラッシュからのリカバリの後できるだけ速やかに、内部ボリュームの一貫性をリストアする（例 えば、ミラー化ボリューム上のすべてのディスクを等しい内容にする。また、RAID 5 ボリューム 内のすべてのブロックについてパリティがユーザデータに対応するようにする）。 極端な場合、ボリューム管理ツールは、システムクラッシュの後ですべてのボリュームの一貫性が失 われていると見なすことがあります。その場合は、すべての冗長データを再コピーまたは再作成しな ければならなくなるため、リカバリに長い時間がかかります。常套手段の 1 つとして、ボリューム内 のデータ更新を記録しておくためのログを保持することが考えられます。この場合、システムのリス タート時にこのログが読み取られ、このログに記録されているデータ領域だけが再作成されます。 VERITAS Volume Manager は、2 つの異なる更新ログ記録テクノロジを使用して、システムクラッシュ 後のミラー化ボリュームおよびパリティ RAID ボリュームの整合性を保証します。 è RAID 5 ロギングは、RAID 5 ボリューム内のストライプを更新しようとする Volume Manager の意 図を記録します。 è ダーティリージョンロギングは、ミラー化ボリュームのどの領域（つまりブロック範囲）がアプ リケーションにより書き込まれたか（つまり「ダーティ」になっているか）を記録します。障害 のあとで一貫性をリカバリする必要があるのは、その「ダーティ」領域だけです。 図 5 にこれらのロギング技法を示します。 VERITAS Volume Manager ストライピングミラー化ボリューム ディスク A ディスク C データ ディスク E データ パリティ RAID 5 ボリューム ディスク A ディスク B ダーティリー ディスク G ジョンログ ディスク B ディスク D ディスク C RAID 5 ログ ディスク P ログボリューム ディスク F Volume Manager は、システムクラッシュ からの早期回復のために ボリューム状態を記録します。 図 5 Volume Manager の RAID5 ロギングとダーティリージョンロギング Page 14 VERITAS Data Availability Solution www.veritas.com/jp RAID 5 ボリュームの RAID 5ログは、 ストライプの全体または一部を更新しようとする Volume Manager の意図を追跡します。システムクラッシュからリカバリしようとするときに、Volume Manager は、イ ンテントログエントリを持つデータの各ストライプについて、パリティを再構成します。個々のイン スタンスで更新されるのはボリュームのストライプのほんのわずかな部分だけなので、システムクラ ッシュの後で、ボリュームをリカバリしアプリケーションデータアクセスをリストアするための所要 時間が、最小限に抑えられます。 ダーティリージョンログは、ミラー化ボリュームに似た機能を提供します。アプリケーションが一連 のブロックアドレス（1 つの領域）にデータを書き込むと、ログエントリに、その領域が変更されたこ と、およびシステムクラッシュ後にリカバリが必要になる場合があることが示されます。 ロギングのオーバヘッドを最小限に抑えるために、新たにダーティとなった領域についてのみログエ ントリが作成されます。ダーティとなった領域更新の完了（つまり領域がダーティではなくなった状 態）は、新たにダーティになった領域が記録されるタイミングで記録されます。システムクラッシュ の後で内容の調整が必要になるのは、ダーティ領域だけです。ほとんどの場合、ダーティとなってい る領域はボリューム容量のわずかな部分にすぎないので、ボリュームリカバリはわずかな時間ですみ ます。 データベースリカバリメカニズムとの統合 データベース管理システムは、ロギングメカニズムとリカバリメカニズムを統合して、システムクラ ッシュの後でデータベースの一貫性を復元します。クラッシュの後でデータベースのストレージボリ ュームに手が加えられていなくても、データベースのトランザクション一貫性、つまり完全なトラン ザクションのみがデータベースに反映されているという保証はありません。例えば、Oracle は、シス テムクラッシュの後で、データベースの一貫性に対する損傷を修復するために、REDO ログをデータ ベースに再適用します。データベース管理システムは、どのデータが危機にさらされているかについ てもっと厳密に把握していますので、システム障害の後では、データベース管理システムにリカバリ の制御を任せるのが得策です。 VERITAS Volume Manager ダーティリー ジョンログ インテントログ データベース ログ REDO データベース データベース管理 システム REDO ログ データベースボリューム ボリューム のリカバリ データベースデータボリューム データベース のリカバリ 図 6 システムクラッシュ後のデータベースのリカバリ ミラー化ボリュームを使用するデータベースでは、VERITAS Database Edition for Oracle を使用すること により、Oracle がリカバリプロセスの大部分を制御できるため、データベースのリカバリ速度が増進 されます。Volume Manager は、ダーティリージョンログを使用して、Oracle の（ミラー化）REDO ロ グをリカバリします。そして、Oracle は REDO ログを再適用し、実際に危機にさらされているデータ を正確にリカバリします。Volume Manager は、データベーステーブルを含むボリュームについてはダ ーティリージョンログを使用しません。この統合されたリカバリ方法には、次の 2 つの利点がありま す。 www.veritas.com/jp VERITAS Data Availability Solution Page 15 è 高速再起動 Volume Manager は、ほとんどのデータベースの大きな部分を占めるデータテーブルをリカバリす る必要がないので、データベース管理システム（そしてアプリケーション）が処理を早く再開す ることができます。 è 高精度のリカバリ データベース管理システムは、必要なデータのみを正確に復元できるので、不要なデータリカバ リは実質的に排除されます。 e ビジネスのパフォーマンス要件を満たすボリュームテクノロジ VERITAS Volume Manager は、オンラインデータのための高度な可用性を備えたストレージコンテナを 提供するだけでなく、一般に Raw ディスクより性能が優れています。RAID ボリュームのタイプによ って、それぞれ I/O パフォーマンスが少し異なります。e ビジネスデータベースを設計するときは、 RAID ボリュームの特性を知っておけば、最適なデータ配置を決定するのに役立ちます。表 2 は RAID ボリ ュームのパフォーマンス特性を示しています。 RAID ボリューム パフォーマンス e ビジネスデータベース アプリケーション ミラー化（2x あるいはそれ以 読取りパフォーマンスは高い 単一ディスクのクリティカルなデータオブジ 上） （RAID 1） 書込みパフォーマンスは中程度 ェクト ストライピングおよびミラ 読取りパフォーマンスはきわめて高い 大きいマルチディスクのクリティカルなデー ー化（RAID 1＋0） 書込みパフォーマンスは高い タオブジェクト パリティを伴うストライピ 読取りパフォーマンスは高い ほとんど読取り専用のデータ ング（RAID 5） 書込みパフォーマンスは低い 例えば、Web ページ、データウェアハウス パリティなしのストライピ 読取りと書込みのパフォーマンスは高い 最小限の適用度 例えば人事データベース 例えば、販売データや製造データ ング（RAID 0） （容易に交換できる重要度の低いデータ） 連結（容量集約型） 読取りと書込みのパフォーマンスは 最小限の適用度 中程度 （容易に交換できる重要度の低いデータ） 表 2 RAID を用いる e ビジネスアプリケーションのパフォーマンス 表 2 を見て分かるように、ミラー化ボリュームは、一般に読取りのパフォーマンスが単一ディスクよ り優れています。これは、読取りリクエストを満たすために、ミラー化ボリュームのディスクのうち 最も使用度の低いものを選択することにより、Volume Manager が、I/O 待ち時間を最小限に抑えること ができるからです。 2 多重（two way）ミラー化ボリュームの書込みパフォーマンスは、単一ディスクよりわずかに劣るも のの、ほぼ匹敵すると言えます。Volume Manager は、個々のアプリケーション書込みリクエストをボ リュームの各ディスクにミラー化する必要がありますが、各々の書込みは互いに独立しているので （RAID 5 の書込みとは異なります） 、並行して実行することができます。さらに、ダーティリージョ ンロギングは、アプリケーション書込みにより新たな領域が更新されるたびに、わずかながらオーバ ヘッドを必要とします。 RAID 5 書込みは、単一ディスク書込みに比べるとパフォーマンスが劣る傾向があります。これは、各 アプリケーション書込みのたびに、Volume Manager が RAID ボリュームのディスクと同時にインテン トログエントリにも、一連の読み書きを行うからです。この理由により、更新頻度の高い e ビジネス データベーステーブルには、RAID 5 ボリュームをお勧めできません。 Page 16 VERITAS Data Availability Solution www.veritas.com/jp ストライピングボリューム マルチディスクミラー化ボリュームと RAID 5 ボリュームは、どちらもデータストライピングを使用し て、透過的に、ファイルおよびテーブルスペースを複数のディスクに分散します。図 7 は、データベ ーステーブルレイアウトへのデータストライピングの効果を示しています。 データベース管理システムの テーブルのビュー 物理データレイアウト Aaron ディスク A ディスク B ディスク C ボリュームブロック 000 ボリュームブロック 004 Armbruster ボリュームブロック 001 Aaron Baker Able Bally Allen Bell Carrow Denbey Drew Cermak Dickson Droll Dabney Dodge Dustin Dalton Dower Felton Able Allen Armbruster ストライプ 0 Baker ボリュームブロック 002 Bally ボリュームブロック 003 「深度」 Bell Carrow ブロック アドレスの 増加 Cermak ストライプ 1 Dabney Dalton Denbey Dickson Finbar Geste Hall Dodge Gamel Gross Heron その他 その他 その他 ストライプ 2 Dower その他 図 7 データテーブルのレイアウトへのデータストライピングの効果 図 7 は、データベース管理システムから見たテーブルビューが、連続番号の付いたブロックに格納さ れたレコードで形成されることを示しています。しかし、Volume Manager は、ボリュームブロックを 水平方向にストライプを行いディスクブロックにマップします。図 7 で、ボリュームブロック 0∼3 は、 ディスク A のブロック 0∼3 に対応し、ボリュームブロック 4∼7 はディスク B のブロック 0∼3 に対 応するというようになっています。単一ディスク上の連続ブロックにマップされるボリュームブロッ クの数を、「ストライプ深度（stripe depth）」と言います（図 7 では 4 ブロック）。ボリューム内のすべ てのディスクにおけるストライプ深度単位のブロック集合を、ストライプと呼びます。 図 7 では、ストライプにより、順序付けられたレコード（例えばメジャーキーによりソートされたデ ータベーステーブル）が、ボリューム内の複数のディスクに分散配置されています。これは、I/O パフ ォーマンスに有益な効果をもたらします。 è アプリケーションのボリューム I/O リクエストがボリュームのディスク間に均等に分散されると すれば、Volume Manager のディスク I/O リクエストは、ボリュームのすべてのディスクに分散さ れる可能性が高くなります。したがって、アクティブディスクの数を最大化するという、I/O リク エスト集約型アプリケーションのパフォーマンスに関する目標が達成されることになります。 è 図 7 で、アプリケーション I/O が「クラスタ」を要求し、例えば「D」で始まる名前のみに処理が 集中したとしても、ストライピングにより、リクエストは複数のディスクリソースに分散されま す。 ストライプ方式によるボリュームブロックのディスクブロックへのマッピングは、データベース管理 システムから見たテーブルビューから独立して行われるので、データベース管理リクエストのパター ンがどのようなものであっても、I/O 負荷が均衡化される可能性が高くなります。 データストライピングは、マルチディスクミラー化ボリュームと RAID 5 ボリュームのどちらにも使用 されます。これは、読取りのパフォーマンスには一様に有益な効果をもたらします。ミラー化ボリュ ームへの書込みの場合は、データストライピングにより、ディスク間で I/O 負荷が均衡化されるため、 www.veritas.com/jp VERITAS Data Availability Solution Page 17 書込みに関するパフォーマンス上のわずかなペナルティがさらに軽減されます。RAID 5 ボリュームの 場合は、個々のデータベース管理システム書込みにより Volume Manager に課せられるオーバヘッドに よって、I/O パフォーマンスが左右されます。このため、 RAID 5 は、「ほとんど読取り専用（read-mostly） 」 のデータベーステーブルのみに使用することをお勧めします。 e ビジネスデータベース用のファイルシステム VERITAS Volume Manager は、e ビジネスデータベースのための堅固でパフォーマンスの高い基盤を提 供します。さらに、VERITAS File System は、データベーステーブルおよびインデックスに適した、高 性能かつフレキシブルで管理しやすいコンテナを提供します。すでに述べたように、ファイルシステ ムをデータベースコンテナとして使用した場合の主な制約条件として、以下の点が挙げられます。 è 永続性の保証が弱い ほとんどのファイルシステムは、データが実際にディスクに入れられる前に、I/O の完了をアプリ ケーションに知らせます。したがって、データベース管理システムは、データの永続性（クラッ シュ時のリカバリ可能性） 、つまりデータの整合性を保証することができません。 è パフォーマンス特性が望ましくない 大半のファイルシステムは、データをディスクに書き込む前に、カーネルバッファキャッシュに データを移動します。そのため高い処理オーバヘッドが発生しますが、これはデータベースにと っては不要なものです。 è ファイル共有時の最適化が不十分 ほとんどのファイルシステムでは、ファイルの書込みをしようとするアプリケーションは、カー ネルロックを設定する必要があります。データベース管理システムにとっては、これは不要なオ ーバヘッドであり、これにより並列性も低下します。 VERITAS のファイルシステム−VERITAS File System には、このような制限は何もありません。しか も、e ビジネスデータベーステーブル用のコンテナとして使用するファイルに、他の幾つかの利点もも たらします。これらの利点の多くは、このファイルシステムのエクステントベースのアーキテクチャ から生じています。 エクステントベースの VERITAS File System エクステントベースの VERITAS File System は、ストレージスペースとして従来の UNIX ファイルシス テムで使用されている 1∼8KB の固定長ユニットを割り当てる代わりに、可変長のエクステントを割 り当てます。各エクステントは、連続番号の付いた複数のディスクブロックから成る任意の大きさの セットであり、したがって、開始ブロック番号とブロック数により簡潔に記述することができます。 エクステント記述子は、グループ分けされて、ディスク上のファイル記述子（「i ノード」 ）となります。 各エクステントはサイズを大きくすることができるため、1 つの i ノードによって、非常に大きいファ イルをきわめて小さいオーバヘッドで、ボリューム上のブロックにマップすることができます。 Page 18 VERITAS Data Availability Solution www.veritas.com/jp ファイル A の記述子 間接 ブロック ブロック ブロック ポインタ ポインタ ポインタ ポインタ ブロックベースの ファイルシステム ファイル A の記述子 間接 エクステント エクステント エクステント ポインタ ポインタ ポインタ ポインタ ファイル A' エクステント 1 フリースペース ファイル A （ブロック 1） フリースペース 2∼8KB の固定 サイズブロック ファイル A （ブロック 2） フリースペース ファイル A （ブロック 3） ファイル A 追加のブロック ポインタ エクステントベースの ファイルシステム ファイル A' エクステント 2 大きなファイルの ために必要な 間接ポインタ ファイル A' 追加のエクステント ポインタ（必要な場合） 単純な構造で 大きいファイル のマッピングが 可能 頻繁に拡張され るファイルのみ 間接ポインタが 必要 図 8 エクステントベースのファイルシステム データベース管理システムにとって、エクステントの最大の利点は、連続した大きいストレージ領域 を少ないオーバヘッドで記述できるということです。大きい連続ストレージ領域は、データベース管 理システムに幾つかの利点をもたらします。 è ストレージ記述子構造が簡素化される 1 つの記述子で多数のブロックをマップできるので、1 つのファイルをマップするために必要な記 述子が少なくてすみます。記述子の数が少ないということは、アプリケーションのリクエストで 指定されているファイルオフセットから、I/O リクエストで必要なディスクアドレスまたはボリュ ームアドレスへの間の変換が速いということを意味します。 è I/O の効率が高い 大きい連続ストレージ領域を使用できるので、I/O リクエストにより大規模なシーケンシャルテー ブルスキャンを行うことができます。これにより、I/O 処理のオーバヘッドが軽減されると共に、 ディスクが次のシーケンシャルデータ転送の開始点まで回転するのを待つ時間が短縮されます。 さらに、大きい連続ストレージ領域の使用によりディスクの断片化が少なくなるため、個々のデ ータオブジェクトが分断され、ディスク上の複数の非連続部分に格納されるという状況が解消さ れます。ディスクの断片化が生じると、アプリケーションのリクエストが、データの非連続ブロ ックを求める複数のディスクリクエストに分割しなければならない場合があるため、I/O 全体の効 率が低下します。 è 積極的なシーケンシャル I/O ポリシー 連続配置されたデータは、シーケンシャルテーブルスキャンの際に先読みが可能です。したがっ てアクセス待ち時間が短縮されます。しかも、データが連続配置されていれば、ファイルシステ ムは、複数のアプリケーション書込みリクエストを 1 つにまとめることができる場合が多く（I/O リクエストのクラスタリングと呼ばれます）、したがって処理オーバヘッドは減少し、I/O 効率は 向上します。 è 大規模ファイル エクステントベースのストレージ割り当てにより、大規模ファイルを効果的に利用できます。 VERITAS File System は、オペレーティングシステムがサポートしている限り、最大 2 テラバイト のサイズのファイルをサポートします。 www.veritas.com/jp VERITAS Data Availability Solution Page 19 効率とアプリケーションの堅牢性のための事前割り当て 非データベースアプリケーションでは、ファイル作成、拡張、および削除は、比較的頻度の高い作業 です。しかし、データベースでは、比較的静的なテーブル構造が使用されます。テーブルスペースの 作成、拡張、および削除は、頻繁に行われる操作ではありません（ただし、これらの操作は可能であ り実際に行われることもあります） 。 VERITAS File System では、ファイルの作成時に（書込みが行われる前に） 、ストレージスペースを予 約することができます。これには、e ビジネスデータベースにとって 2 つの利点があります。 è 最適なデータレイアウト 新しいデータベースを作成するデータベース管理者は、スペース予約を利用して、既知の要件を 満たす最適のテーブルスペースを設定することができます。 è スペース割り当て障害の抑制 ファイルシステムは、新しいファイル用のスペースを割り当てるときに、前のスペース予約を尊 重します。たとえ既存のテーブルスペースが最大サイズに達しても拡張できるだけのスペースが 予約されていれば、スペース割り当て障害が回避可能なためトランザクションおよびバッチジョ ブが失敗することはありません。 VERITAS Database Edition for Oracle では、Oracle とファイルシステムの間で、事前割り当てされたテー ブルスペースを、ファイルシステムのエクステントの境界に位置合わせするよう調整することができ ます。これにより、エクステントの境界にまたがる「分割」データベースページが最小限に抑えられ、 データベース管理システムは、I/O リクエストクラスタの利点を最大限に活用することができます。 エクステントベースのアーキテクチャと、ストレージスペースの事前割り当てとの組み合わせは、フ ァイルシステムに Raw パーティションのような働きをさせるもう 1 つの VERITAS テクノロジ、つま り Quick I/O for Databases の基盤となっています。 Quick I/O for Databases：データの永続性と低いオーバヘッド Quick I/O for Databases は、データベース管理システムが、Raw デバイスと同じように、事前割り当て ファイルへの I/O を行えるようにします。I/O は、データベース管理のメモリスペースとディスクの間 で直接行われます。Raw デバイスでの I/O の場合と同等の効率を得ることができます。効率に貢献す る要素は 4 つあります。 è ダイレクト I/O I/O はデータベース管理システムのメモリ（例えば Oracle の共有グローバル領域（SGA））から、 中間のデータ移動なしで、直接カーネルスペースに対して実行されます。これにより、処理オー バヘッドが大幅に削減されます。 è 冗長キャッシングの排除 データベース管理システムはプライベートキャッシュ（例えば Oracle の共有グローバル領域）を 備えているので、ファイルシステムのキャッシュは冗長であり、最適な基盤構成ではありません。 Quick I/O for Databases のダイレクト I/O は、この冗長性を排除します。 è 非同期 I/O の実現 キャラクタデバイスを使用することにより、データベース管理システムは多数の並列 I/O リクエ ストを実行することができます。これにより、データベース管理システムの並行制御が増加し、 ドライバ、コントローラ、およびストレージデバイスは、デバイスパフォーマンスを最適化する Page 20 VERITAS Data Availability Solution www.veritas.com/jp ための、より大きな I/O リクエストリストのソートを可能にします。 è カーネルファイルロックの抑制 カーネルファイルロックは回避されます。データベース管理システムは独自に内部的にロックを 行うので、カーネルファイルロックは冗長であり、過剰なシリアライゼーションが生じることに なります。これを排除すれば、データベース管理システムの並列性が最大限に発揮され、データ 整合性が損なわれることはまったくありません。 カーネルスペースから データベース管理システム アプリケーション スペースへの の共有グローバル領域 メモリ間コピー 書込まれるデータ 読取り用のバッファ 従来のファイル システム カーネルバッファ キャッシュ 書込まれるデータ カーネルスペースと の間の実際の I/O ファイル 新規データ 読取り用のバッファ 要求されたデータ 従来の I/O Quick I/O ＆VERITAS File System データベース管理システム の共有グローバル領域 ファイル 書込まれるデータ 新規データ 読取り用のバッファ 要求されたデータ Quick I/O for Databases 図 9 アプリケーションスペースからの直接 I/O を実現する Quick I/O for Databases さらに、Quick I/O for Databases を用いることによって、I/O 機能が損なわれることはまったくありませ ん。、Quick I/O ファイルへの UNIX シンボリックリンク（代替ファイルシステムアクセスパス）を設定 し、通常のファイルシステムパスを介しアクセスすることを、例えばレコード抽出やその他の管理目 的のために行うことができます。 Cached Quick I/O for Databases: 4GB の壁を克服 32 ビットのアプリケーションまたはデータベース管理システムで取り扱えるのは、最大 4GB のメモリ までです。大規模なデータベースまたは高度なパフォーマンスを要求するデータベースアプリケーシ ョンでは、使用するキャッシュデータの量がこの限界を簡単に超えてしまいます。VERITAS Cached Quick I/O for Databases は、データベース管理システムがより大きな物理キャッシュを利用できるよう にします。 カーネルキャッシュ （4GB 以上） キャッシュ データ データベース管理システム 書込み時に拡張キャッシュ の共有グローバル領域 にコピーされるデータ 書込まれるデータ Quick I/O & VERITAS File System 拡張カーネルキャッシュから 送達されるキャッシュデータ 読取り用のバッファ ファイル 新規データ 要求されたデータ アプリケーションスペースとストレージの間で直接読み書きされるデータ 図 10 Quick I/O for Databases による 4GB 以上のキャッシュ www.veritas.com/jp VERITAS Data Availability Solution Page 21 Cached Quick I/O for Databases を使用すると、データは Oracle キャッシュからディスクに直接書き込ま れ、さらに、データはオペレーティングシステムのバッファキャッシュにもコピーされます。以後の シーケンシャルな読取りにはこのキャッシュが使用されるため、ディスクアクセスよりはるかに高速 な読取りが実現します。 同様に、ディスクから読み取られたデータも、システムバッファキャッシュにコピーされるので、再 度要求されたときにただちに提供されます。Cached Quick I/O for Databases は、データ先読みを積極的 に行います。先読みされたデータはシステムバッファキャッシュに入れられるので、データ管理シス テムのリクエストを受けたテーブルスキャンの際に、即時にそのデータが送達されます。 データベースメモリとシステムバッファキャッシュの間のデータコピーという操作があるため、 Cached Quick I/O for Databases は、きわめて大きいメモリへ直接アクセスできる 64 ビットデータベース 管理システムと比較して、よりオーバヘッドの大きいソリューションです。しかしながら、完全 64 ビ ットのデータベース管理システムが利用可能になるまでは、Cached Quick I/O for Databases は、データ ベース管理システムできわめて大規模な物理メモリを利用する唯一の手段を提供しています。 高速なリカバリ e ビジネスのために最善の構成を用意しても、望ましくない状況が生じる場合があります。アプリケー ション、ハードウェアコンポーネント、または操作手順のいずれもが、システムクラッシュの原因と なることがあります。したがって、迅速に復旧するためのリカバリ・プランを用意することが不可欠 です。リカバリのための重要な要素の 1 つは、アプリケーションが可能な限り速やかに再起動できる ようにすることです。 Oracle データベースをリカバリするための技法については、すでに説明しました。しかし、これと同 じように重要なのは、アプリケーションを実行するために必要なデータベース自体を構成していない ファイル、すなわち、数十個または数百個もの構成ファイル、ログファイル、およびその他の補助フ ァイルをリカバリすることです。 使用中のシステムがクラッシュした場合、ファイルシステムの構造の整合性に関する保証がなくなり ます。ファイルが作成、拡張、または削除されている可能性がありますが、永続的な（ディスク上の） ファイルシステムメタデータはまだ完全に更新されていない場合があります。悪いときにクラッシュ が生じると、ファイルやストレージスペースが失われたり、さらに事態が悪化するとブロックが複数 のファイルに割り当てられこともあります。ファイルシステムのメタデータの整合性を検査するため の通常の手段は、ファイルシステムをマウントし使用する前に、構造の整合性をチェックし修復する プログラムを実行することです。UNIX システムでは、このプログラムは一般に fsck（File System check: ファイルシステムチェック）と呼ばれています。Windows オペレーティングシステムにも同様の機能 があります。 fsck プログラムおよび他の同等のプログラムは、ファイルシステムの構造の有効性を検査し、失われ たり多重割り当てされているディスクブロックがないことを確認します。この種のプログラムは、部 分的なメタデータ変更を取り消すため、最近の更新は失われますが、ファイルシステムの構造は元の 状態のまま残されます。e ビジネスにおいて fsck を使用することには、大きいファイルシステムの場 合に、所要時間が長くなるという問題点があります（一例によれば、1GB のデータにつき 2∼5 分） 。 fsck が完了するまでは、データベース管理システムも含めて、どのアプリケーションも実行を開始す ることができないので、リカバリに長時間を要し、システムの可用性が低下します。 VERITAS File System には、これに代わる方法として、インテントロギングと呼ばれる第 1 レベルのリ カバリ技法が組み込まれています。これは、先述した VERITAS Volume Manager の RAID5 ロギングと 同様のものです。ファイルシステムの構造が変更されるたびに（例えば、ファイルが作成、拡張、ま たは削除されたときに） 、そのインテント（意図）が独立したボリュームに記録されます。インテント Page 22 VERITAS Data Availability Solution www.veritas.com/jp ログエントリは、構造変更が始まる前にディスクに書き込まれます。このエントリには、構造の変更 に伴って生じる個々のメタデータ変更がすべて含まれています。ファイルシステムのインテントログ は、比較的小さく、循環形式で、自動消去が行われます。 システム障害後のリカバリの際に、ファイルシステムはインテントログを読み、その中のすべてのメ タデータ更新が正しく適用されていることを確認します。大規模なファイルシステムでは一般に、あ る時点での不完全なメタデータ変更の数はメタデータの総量に比べてきわめて少ないので、ほとんど の場合、インテントログを再生する方が、完全に fsck を実行するよりはるかに早く完了します。した がって、ファイルシステムを速やかにマウントできるため、データベース管理システムは早期にデー タベースのリカバリに着手でき、その結果システムの可用性も向上します。 オンライン管理 e ビジネスは、一般的に通常のビジネスに比べて急激な成長を遂げることが多くあります。成長し変化 するということは、ときどき大量のデータを 1 つの場所から別の場所に移動することが必要になると いうことでもあります。 è データベースがストレージ容量を超えるまでに成長したときは、ストレージの拡張または交換が 必要になります。 è パフォーマンスを改善するために、ボリューム内でデータベースの再編成が必要になることがあ ります。 è データベースを、1 つのコンピュータまたは場所から別のコンピュータまたは場所に移さなければ ならないときがあります。 データの再編成、拡張、再配置の必要性は、e ビジネスの根本的要件である最大限の可用性達成にとっ ては不利な条件です。VERITAS File System のオンライン管理機能を使用すれば、頻繁に実行する管理 機能の大半を、ファイルの使用中に実行することができます。 オンライン・デフラグメンテーション アプリケーションを実行すると、ファイルの作成、拡張、切り捨て、および削除が行われます。そし て、時間がたつにつれてボリュームが断片化されてきます。図 11 の右に示されているように、断片化 されたボリュームでは、ファイルとフリースペースが混在する状態が生じます。新規ファイル用に使 用できるフリースペースは、少数の連続ブロックから成る多数の範囲に分断されている場合がありま す。このような場合、ボリューム全体には十分なスペースがあったとしても、大規模な連続したスペ ースのエクステントを必要とするファイル作成リクエストは失敗することがあります。非連続割り当 てリクエストは成功はしますが、その場合でも、断片化したファイルへのアクセスには大きなオーバ ヘッドが伴うため、パフォーマンスが低下するおそれがあります。 www.veritas.com/jp VERITAS Data Availability Solution Page 23 断片化された ボリューム 断片化されていない ボリューム ファイル A ファイル A ファイル B フリースペース ファイル C ファイル C ファイル D フリースペース ファイル E 時間の経過 ファイル F フリースペース • • • • • • フリースペースが 統合されて大きい ファイルシステム のエクステントの 割り当てが可能に なります ファイル F ファイル D の更新（再書込み） ファイル D の再更新 ファイル E の更新 ファイル B の更新 ファイル E の再更新 ファイル E の再更新 フリースペース 多数の小さい エクステントに 分かれた同量の フリースペース ファイル D フリースペース ファイル B フリースペース ファイル E 新規初期化またはデフラグ メンテーションされた ボリューム アプリケーション使用 後のボリューム 図 11 ボリュームの断片化 VERITAS File System は、この状況を解消するために、ボリュームのデフラグメンテーション（断片化 の解消）をします。ファイルシステムは、ファイルを一組のブロックから別の組のブロックに移し、 ファイルの新しい位置に合わせてメタデータを更新します。これはアプリケーションから見れば透過 的に行われるので、アプリケーションは移動の前も後も同じようにファイルにアクセスできます。ボ リューム上のすべてのファイルが連続ブロックのファイルになれば、ボリューム上のフリースペース がまとめられて、図 11 の左側の部分に示されているように、ボリュームは断片化が解消された状態に なります。 使用中でないファイルを移動することは簡単です。しかし、アプリケーションが現在アクセスしてい るファイルを移動するというのは難題です。たとえば、100 ブロックから成るファイルを移動している 場合に、ファイルシステムが 50 ブロックを移動してしまった時点で、前のファイルメタデータを使用 しているアプリケーションが最初の 1 ブロックを変更したとすれば、新しいファイル位置に合わせて ファイルメタデータが更新されたときに、その変更は失われてしまう可能性があります。 アプリケーションの読取り リクエストはソースボリュームに送られる アプリケーションの書込みリクエストがソースボリューム と同時にターゲットボリュームにも送られる ターゲット ボリューム ソースボリューム ファイルA：エクステント1 ファイルA：エクステント1 フリースペース これらのブロックは すでにコピーされて いるか？ ファイルA: エクステント2 ファイル D Yes ファイルA: エクステント2 ファイルA: エクステント３ ファイルA: エクステント４ ファイルA: エクステント３ フリースペース ファイル F ファイルA: エクステント４ フリースペース 大きいファイルの場合、コピー操作は長時間を要することがある ファイルA: エクステント1 ファイルA: エクステント２ ファイルA: エクステント３ ファイルA: エクステント４ ボリューム上で断片化されている ファイル ファイル H フリースペース ファイル J フリースペース ファイル K ファイルはここに移されて断片化が 解消された状態になる 図 12 オープン・ファイルの移動 Page 24 VERITAS Data Availability Solution www.veritas.com/jp 図 12 は、ファイルの移動中に、前の位置と新しい位置の両方で行われたアプリケーション更新が、 VERITAS File System にどのように反映されるかを示しています。アプリケーションが更新したブロッ クがすでにコピーされていれば、ファイルシステムは、透過的にその更新を両方の位置にコピーしま す。この方法により、データベースをオンラインにしたままで、データベースのテーブルスペースお よびその他のファイルを再配置することができます。 データベースのコンテナファイルの移動 一般に、データベースのテーブルスペース、テーブル、およびインデックスは、比較的静的なもので す。これらはデータベースをインプリメントする前に定義され、その後は頻繁にサイズが変更される ことはありません。再編成は、定常的なものではなく例外的な状況と言えます。したがって、e ビジネ スデータベースストレージのデフラグメンテーションが時々必要になりますが、それはオンラインフ ァイルの管理が役立つのは、それ以外の目的の場合の方が多くなります。データベース管理者が、テ ーブルスペースを使用中に移動するのは、テーブルの拡張、再配置、または再構成の必要性を満たす ためであり、これは、急速に成長する e ビジネス環境において必然的に発生する状況です。例えば以 下のような場合が考えられます。 è ストレージポリシーの変更（例えば、重要性または更新頻度が増したテーブルを、単純ボリュー ムまたは RAID 5 ボリュームからミラー化ボリュームに変更）を、テーブルが使用されているとき に実施することができます。 è テーブルが膨張してデバイスの容量が不足しそうなときに、もっと大きいデバイスまたは大きな 使用可能容量が残っているデバイスに、テーブルを移すことができます。 è ストレージデバイスの障害が検出された場合、ファイルを他のデバイスに移すことができます。 使用中のファイルを移動する能力は、上記のほかにもさまざまの管理機能を可能にするものであり、 これによって e ビジネスコンピューティング環境の成否が大きく左右されます。 オンライン拡張 e ビジネスにおいて、使用中のファイルの移動が必要になる理由として最も多いのは、オンラインでの 容量の拡張です。e ビジネスの成長に伴い以下のような状況が生じるようになります。 è 提供する製品およびサービスの量が増加する。 è 顧客の数が増加する。 è トランザクション履歴が膨張する。 è オンラインアプリケーションの数が増加する。 上記のどの要因の場合も、オンラインの状態を維持する必要がある情報の量が増加し、したがってス トレージの拡大が必要になります。Oracle テーブルスペースは、それぞれのコンテナが拡大可能であ れば、オンライン状態のままで拡張することができます。このオンライン拡張は、自動的に行うこと も、データベース管理者が操作することもできます。Raw パーティションおよび一部の一般的なファ イルシステムでは、パーティションまたはファイルシステムの容量の限度まで拡張が可能です。 VERITAS のファウンデーション・テクノロジでは、ストレージ容量を追加することで、オンラインボ リュームを拡張できます。そして、ファイルシステムを、同じくオンラインのままで拡張して、新た な容量の使用を開始することができます。 また、テーブルの一部を、使用中のままで別のボリュームに移すことが必要になることもあります。 これは、例えば、アクセスの並列性を向上させるためにボリュームの細分化が必要な場合などです。 この目的も、VERITAS のオンラインファイル移動機能により実現できます。 www.veritas.com/jp VERITAS Data Availability Solution Page 25 スナップショット e ビジネスで要求される可用性という条件は、定期的なバックアップという総合的なビジネス方針と相 反します。データベースのバックアップコピーは、一時点におけるビジネスの状態を反映するもので ない限り、ほとんど価値がありません。したがって、バックアップコピーは、進行中のデータベース トランザクションが 1 つもないときに作成する必要があります。しかし、オンラインデータベースは いつでも更新が可能なので、オンライン状態のデータベースのバックアップによって、特定時点での 整合性のあるデータイメージを取得することは困難です。 特定時点バックアップを達成するための方法の 1 つは、バックアップ操作の間データベースの使用を 停止することです。この方法によるバックアップは、コールドデータベースバックアップと呼ばれて います。コールドデータベースバックアップではデータベースのアクティビティがまったく発生しな いため、最も短時間でデータベースのフルバックアップをとることができます。コールドデータベー スバックアップを行うには、システム管理者は、いわゆるバックアップウィンドウ、つまり、データ ベースが使用不能になることが容認されるタイミングを判断する必要があります。従来は、深夜や週 末がバックアップウィンドウとして利用されてきました。しかし、e ビジネスではこれらの期間も、通 常の営業日と同様にデータが使用可能な状態になっていることが要求されます。したがって、コール ドデータベースバックアップでは、e ビジネスの可用性の要件を満たすことはできません。しかも、ビ ジネスが成長するにつれて、オンラインデータの量も増加します。それに比例してバックアップの所 要時間も増加しますが、バックアップウィンドウは元のままです。つまり、コールドデータベースバ ックアップの実用性はますます低くなっていきます。 VERITAS File System のスナップショット機能は、この難題を克服します。スナップショットとは、フ ァイルシステム自体が作成し維持している、ファイルシステムの特定時点の状態のイメージです。ス ナップショットは、作成の時点以外は、データベース管理システムからは見えません。スナップショ ットが作成されているファイルシステムを、プライマリ・ファイルシステムと言います。アプリケー ションは、スナップショットの開始後も、通常通りファイルシステムを更新することができます。特 定時点のイメージは、アプリケーションにとっては読取り専用のファイルシステムであり、これがス ナップショット・ファイルシステムと呼ばれています。 スナップショットの作成には数秒かかります。ファイルシステムは、未割り当てのスペースを使用し て変更済みブロックマップを作成し、プライマリ・ファイルシステムに対する変更をそこに記録しま す。さらに、ファイルシステムは、変更済みブロック領域のためのスペースを割り当て、スナップシ ョットの開始後に変更されたブロックの元の内容をそこに記録します。これらの構造の作成が完了す れば、アプリケーションは、プライマリ・ファイルシステムとスナップショット・ファイルシステム のどちらも使用できるようになります。 スナップショットの働き VERITAS スナップショット・ファイルシステムは、書込み時コピー（copy on write）を使用して、特 定時点のファイルシステムイメージを維持します。アプリケーションがプライマリ・ファイルシステ ムにブロックを書込むと、ファイルシステムは、まず、上書き対象のブロックの内容を、スナップシ ョットの変更済みブロック領域にコピーします。次に、ファイルシステムは、プライマリ・ファイル システム内でそのブロックを上書きします。そして最後に、スナップショットの変更済みブロックマ ップを更新します。したがって、スナップショットに使用されるストレージスペースは、スナップシ ョットがアクティブな状態にある間に更新されるデータの量に比例します。 バックアップなどのアプリケーションがスナップショットからブロックを読取るときは、ファイルシ ステムは、まず変更済みブロックマップをチェックして、スナップショット作成の時点以降にそのブ Page 26 VERITAS Data Availability Solution www.veritas.com/jp ロックが変更されたかどうかを調べます。ブロックが変更されていなければ、プライマリ・ファイル システム内の元の位置からそのブロックが読取られます。スナップショット作成の時点以降にそのブ ロックに書込みが行われている場合は、そのブロックの元の内容がスナップショットの変更済みブロ ック領域内のどこにあるかが変更済みブロックマップに示されているので、その位置からそのブロッ クが読取られます。 プライマリ・ ファイルシステム スナップショット・ ファイルシステム ファイル A：エクス テント 1 変更ブロックマップ ファイル D：ブロック 1 空き領域 その他の変更ブロック ファイル A：エクス テント 2 空き領域 空き領域 いいえ ファイル D はい これらブロックへの 書き込みは、スナップ ショット生成以来初めて スナップショットにデー の書込みか プライマリ・ファイル への書込み 空き領域 タをコピーし、変更ブロ ックマップを変更後、プ ライマリ・ファイルに書 込む ファイル D：ブロック 1 の書込み アプリケーションによるスナップショット・ ファイルシステムへの 書込みリクエスト 図 13 ファイルシステム・スナップショットの流れ スナップショットの一貫性 スナップショットは、単にファイルシステムの特定時点のイメージを表すだけでなく、データベース の静止状態を表すものでない限り、バックアップ用のソースとして役に立ちません。静止状態とは、 以下の両方の条件を満たしている状態を言います。 è 部分的に完了し現在進行中のトランザクションが 1 つもない。 è 完了したすべてのトランザクションが（キャッシュだけではなく）ディスクに反映されている。 これらの条件を満たしているとき、データベースは静止状態にあります。 管理者がスナップショットを開始すると、ファイルシステムは、I/O リクエストを制止し、キャッシュ されているユーザデータおよびメタデータをフラッシュ（ディスクに書込み）して、ディスクイメー ジを整合性のあるものにすることができます。ただし、ファイルシステムは、そのファイルシステム をストレージとして使用しているデータベース管理システムが、進行中のトランザクションを持って いるかどうかを確認することはできません。データベースでは、未完了の I/O リクエストがない状態で トランザクションが進行している可能性があります。注 2 VERITAS Database Edition for Oracle には、ファイルシステム管理ツールが組み込まれています。このツ ールは、未完了のすべてのトランザクションを完了させ、キャッシュをフラッシュし、新規のトラン ザクションを制止するように Oracle データベースに要求して、整合性のあるスナップショットが開始 されるようにします。データベースが静止状態になると、ファイルシステムはスナップショットを開 始します。このオペレーションの所要時間は 1∼2 秒です。スナップショットが開始されると、データ www.veritas.com/jp VERITAS Data Availability Solution Page 27 ベースが解放され、新規トランザクションの実行が再開されます。これにより、アプリケーションが データベースを使用できなくなる時間が最小限に短縮されます。図 14 にスナップショットがどのよう に作成されるかを示します。 データベース管理者コマンド データベース A のテーブル スペースのスナップショットの作成 ファイル A （テーブル 1） フリースペース ファイル B （テーブル 2） ファイルシステム · ¶ データベースを 静止状態にする リクエスト フリースペース ファイル C （テーブル 3） ¸ ファイルシステム スナップショット用の データ構造の作成 プライマリ・ファイル システム 未完了のすべての トランザクション が完了し キャッシュが フラッシュされた ことを知らせる シグナル スナップショット 変更済みブロックマップ フリースペース ¹ データベース の処理を再開 するよう指示 するシグナル データベース管理システム データベース管理システムは、処理再開の シグナルを受け取るまで 新規トランザクションの受け入れを停止 図 14 データベースのスナップショットの作成 作成されたスナップショットは、読取り専用ファイルシステムになります。データベース、ファイル、 または Raw デバイスのバックアッププログラムは、バックアップコピーを作成するためのソースとし て、スナップショットを読取ることができます。スナップショットから読取られるデータは、スナッ プショットの作成の時点でファイルシステムから読取った場合のデータと同じものです。したがって、 スナップショットをもとにして作成されたバックアップの内容は、コールドデータベースバックアッ プの内容とまったく同じです。違っているのは、アプリケーションがデータベースを使用中であって も、スナップショットをバックアップできるという点です。 ---------------------------------------注 2 例えば、人間が介在するトランザクションの場合は、実行中に「考える時間」が発生することがよくあります。これは人 間が次のアクションを思案している時間なので、トランザクション進行中の状態になっているデータベースの I/O はあり ません。 ----------------------------------------- スナップショットのパフォーマンスへの影響 スナップショットの作成という方式をとることで、バックアップウィンドウは時間単位から秒単位に まで短縮されますが、それでもアプリケーションへの影響はあります。更新されるブロックは、更新 の書込みの前に、読取られてスナップショットの変更済みブロック領域にコピーされなければなりま せん。したがって、スナップショットの最中のファイルシステムに対する更新は、少なくとも 3 回必 要であり、これは通常に更新される場合の I/O アクティビティと同じです。経験によれば、スナップシ ョットが有効な状態にあるとき、Oracle データベースを使用するオンライントランザクション処理ア プリケーションのパフォーマンスは 15%低下することが予測されます。注 3 しかし、これは、データベ ースの可用性が実質的には途切れない状態で、一貫性のあるバックアップが得られるという利点を考 えれば、比較的軽微な代償と言えます。 -----------------------------------注 3 『VERITAS Database Edition for Oracle Administrator's Guide』参照。当然のことながら、厳密な影響は、スナップショ ットがアクティブ状態にある間にスナップ済みデータベースが更新される頻度によって異なります。 ------------------------------------- Page 28 VERITAS Data Availability Solution www.veritas.com/jp データストレージ管理のファウンデーション製品に関するまとめ 3 ページで、e ビジネスデータベースの要件として以下の事項を掲げました。 è 信頼性 è パフォーマンス è スケーラブルな成長 この章では、VERITAS ファウンデーション製品−VERITAS Volume Manager 及び VERITAS File System が、これらの要件をどのように満たすかを説明しました。 è 信頼性 Volume Manager の RAID およびミラーリングテクノロジにより実現します。これは、ディスクお よびその他のハードウェアコンポーネントに障害が生じても、オンラインデータの可用性を維持 します。 è パフォーマンス Volume Manager のデータストライピング、および Quick I/O for Databases の両方により実現します。 さらに Cashed Quick I/O for Databases により、32 ビットオペレーティングシステムにおける 4GB の限界を超えて、きわめて大きいキャッシュをデータベースに使用することができます。 è スケーラビリティ ボリューム、ファイルシステム、およびデータベース自体を、使用中のままで拡張できる能力に よって実現します。 VERITAS のファウンデーション・テクノロジは、e ビジネスデータベースの必要条件である可用性を 維持するために必要な、ストレージ管理能力のほとんどを提供します。この後の各章では、この基盤 を土台としてトータルなデータストレージ管理を構築するための、その他の VERITAS テクノロジにつ いて説明します。 www.veritas.com/jp VERITAS Data Availability Solution Page 29 II. レプリケーション 最適なタイミングで正しいデータを正しい場所へ レプリケーションはなぜ必要か ごく標準的な e ビジネスでも、複数の処理サイトの設置が必要な規模に成長するまでに、さほどの時 間はかかりません。カスタマ、納入業者、および従業員が応答性に対して求める要件を考慮すると、 一般に情報を使用する場所の近くにその情報を置くのが最も効率的です。同じ情報を複数のサイトで 使用できるようにするためには、それらのサイトに情報をレプリケーションする（またはそれらのサ イトにあてて発行する）ことが必要です。価格表、製品仕様書、Web ページなどは、e ビジネスを運用 するすべてのロケーションにレプリケーションされることが多くなります。この種のデータは、組織 内のどこにあっても同一のものになっていることが重要なのは明らかです。したがって、変更がすべ てのロケーションにわたって同期される必要があります。 データのレプリケーションは、データマイニングの目的で行われることもよくあります。e ビジネスが 成熟するにつれて、ビジネスオペレーションに関する履歴データの本体は限りなく大きくなり続けま す。企業は、履歴データをデータウェアハウスに格納し、必要に応じて探し出し、傾向を分析してさ まざまな計画立案に使用できることに気づきました。これはきわめて便利ではありますが、データマ イニングには大量の I/O オペレーションが伴います。e ビジネスのオンラインデータをデータマイニン グの対象にしようとすると、一般に、ビジネスオペレーションに重大な影響が出ます。オペレーショ ンへの悪影響を避けるには、データを別のサーバ（つまりデータウェアハウス）にレプリケーション し、ウェアハウスのコピーをマイニングの対象にし、その間にビジネスオペレーションの方はそのま ま続けるという方法があります。 3 番目の、そしておそらくはレプリケーションの最も重要な理由と言えるものは、災害復旧です。e ビ ジネスが成長するにつれて、データセンターが機能を停止した場合の経済的社会的影響は重大なもの になってきます。賢明なビジネス手法では、e ビジネスが生き残るために、火事、洪水、破壊行為、停 電、ソフトウェア障害、その他のデータセンターの機能を完全に麻痺させる可能性のあるできごとか ら迅速にリカバリできる能力が必要です。 レプリケーションの性質 目的が、発行、マイニング、災害リカバリのいずれにあるかに関係なく、データのレプリケーション の性質は同じです。メインデータセンターとは別の 1 つまたは複数のサイトに稼働データの最新コピ ーを保持し、ビジネスオペレーションに使用するプライマリデータベースと常に同期させておく必要 があります。 VERITAS のストレージレプリケーション・テクノロジ レプリケーションでは、e ビジネスデータの 1 つまたは複数のセカンダリコピーと、アプリケーション が処理中のマスタコピー（プライマリコピー）との同期を維持します。VERITAS のレプリケーション テクノロジでは、以下のどちらかをレプリケーションすることができます。 è プライマリファイルシステムから、別のコンピュータにある 1 つまたは複数のセカンダリファイ ルシステムへ。 è プライマリボリュームグループから、別のコンピュータにある 1 つまたは複数のセカンダリボリ ュームグループへ。 Page 30 VERITAS Data Availability Solution www.veritas.com/jp ファイルのレプリケーションとボリュームグループのレプリケーションは、どちらも、ネットワーク 停止やシステム停止が発生したときにレプリケーションされたデータの保全性を維持できると同時に、 実際的なオペレーションに十分なパフォーマンスを提供できるように設計されています。 図 15 に、データのレプリケーションの仕組みを示します。 ファイルシステム 単純ボリューム、 連結ボリューム、 ミラー化ボリューム、 または RAID ボリューム ファイル A ファイル B ファイル C ファイルシステム ファイル A セカンダ リサーバ ファイル B アプリケーション 更新 ファイル C プライマリ サーバ ボリューム テーブルスペース P ボリューム グループ ボリューム テーブルスペース Q ファイル システム ファイル A ファイル B ファイル C ボリューム ボリューム テーブルスペース R テーブルスペース P Volume セカンダ リサーバ テーブルスペース Q Volume ボリューム テーブルスペース P ボリューム テーブルスペース R アプリケーション更新が セカンダリサイトに プロパゲートされる テーブルスペース Q ボリューム テーブルスペース R ネットワーク 図 15 ファイルおよびボリュームのレプリケーション 図 15 では、アプリケーションはプライマリサーバで実行され、ファイルシステム内のファイルと、 （フ ァイルシステムの有無に関係なく）ボリュームグループに格納されているデータベーステーブルの両 方を更新します。ファイルシステムとボリュームグループの両方のレプリカが、2 つのセカンダリサー バに保持されます。図 15 に、レプリケーションに関する次の 3 つのキーポイントが示されています。 è ファイルシステムか、 （1 つ以上のファイルシステムを含む）ボリュームのグループか、どちらか をレプリケーションすることができる。多数の管理ファイルと各種の雑多なファイルがあるとい う状況は、複雑な e ビジネスアプリケーションの避けられない一面ですが、ファイルシステムの レプリケーションはこのような状況に適した方法です。ボリュームグループのレプリケーション は、データベースの場合一般に、つまり少数の大きいファイルが複数のファイルシステムにまた がって複数のボリュームに格納されているような場合に適しています。 è レプリケーションは 1 対多のオペレーションである。個々のファイルシステムまたはボリューム グループごとに、単一のソース（プライマリサイト）と、1 つまたは複数のターゲットがあります。 プライマリサイトは、アプリケーションにデータの読取り/書込みアクセスを提供します。ファイ ルシステムのレプリカは、アプリケーションが使用するためにマウントすることができます。ボ リュームグループのレプリカは、レプリケーションがアクティブになっている間はアプリケーシ ョンがレプリカを使用することはできません。 è レプリケーションは、標準的なハードウェアコンポーネントとネットワーク接続を使用する。デ ータを複写するのに特別なハードウェアは不要です。また、レプリケーション専用の通信リンク も必要ありません（ただし、スループットとアプリケーションの応答性を最大限にするために、 VERITAS では専用リンクを使用することをお勧めします）。プライマリデータとセカンダリデー タのレプリカは、タイプやサイズが同一のディスクに格納する必要はありませんが、レプリケー ション先のボリュームの容量は同じでなければなりません。 www.veritas.com/jp VERITAS Data Availability Solution Page 31 レプリケーションは、データアクセス/管理スタック内のレイヤの 1 つです（7 ページの図 1 を参照） 。 レプリケーションオブジェクトはファイルシステムまたはボリュームなので、すべての VERITAS ファ ウンデーションの機能（ミラーリングなどの可用性に対する付加機能や Quick I/O for Databases などの パフォーマンス拡張機能も含む）を、データレプリケーションと組み合わせて使用することができま す。レプリケーションはポリシーをベースとしています。システム管理者は、ビジネス要件に合った レプリケーションを行うために、ポリシーを設定することができます。レプリケーションポリシーに は以下の条件を組み込みます。 è プライマリサイトのどのファイルシステムまたはボリュームグループをレプリケーションするか。 è セカンダリサイトのどのファイルシステムまたはボリュームをレプリケーションのターゲットと するか。 è プライマリサイトとの間に、どの程度の同期を維持するか。 è 一時的障害（ネットワーク停止など）にどのように対処するか。 ポリシーを設定した後は、レプリケーションは自動的に行われ、サイト災害などのような例外的イベ ントが発生するまでは、システム管理者が介入する必要はありません。ファイルシステムのレプリケ ーションもボリュームグループのレプリケーションも、基本的な達成目標は同じで、同一データを複 数のコンピュータに保持しておくことですが、この 2 つの方法の間には幾つかの相違点があります。 これらの相違点は、主としてレプリケーションオブジェクトの性質からくるものです。この相違があ るため、それぞれのタイプのレプリケーションに適したアプリケーションも異なってきます。 ファイルシステム・レプリケーション ファイルシステムのレプリケーションは、同期レプリケーションです。これは、プライマリサイトで のアプリケーションによる書込みは、データがすべてのセカンダリサイトに書き込まれてしまうまで、 完了しないということを意味します。同期書込みのメカニズムについては後で説明しますが、本質的 な問題点は、アプリケーションがレプリケーション先のファイルシステムに書き込むときにかかる時 間が、ローカルファイルシステムに書き込む場合より大幅に長い場合があるということです。したが って一般的には、ファイルシステムのレプリケーションは更新頻度の高いアプリケーションには適し ていません。 ファイルシステムのレプリケーションは、セカンダリサイトのデータを完全に最新の状態に保ち、デ ータのプライマリコピーとセカンダリコピーはまったく同じものになるので、通信障害やセカンダリ サイト障害からのリカバリに備えて更新をログに記録しておく必要はありません。これは、レプリケ ーションにかかるオーバヘッドを最小限に抑えるための効果はありますが、欠点もあります。つまり、 プライマリサイトとセカンダリサイトの間に通信障害が起きると、長時間の再同期プロセスが必要に なるということです。 ネットワーク停止の発生後は、プライマリファイルとセカンダリファイルのレプリケーションサイト は、個々のレプリケーションファイルごとに、それぞれが持つコピーが同一かどうかを判別すること が必要になります。この判別は、両サイトが独自に、各ファイルのチェックサムをに計算することに よって行います。そして、両方のサイトのチェックサムが異なるファイルがあれば、セカンダリサイ トのバージョンをプライマリサイトからのコピーで置き換えます。 このリカバリ技法は、ログの再生に比べて時間がかかります。ファイルシステムのレプリケーション では、通常のオペレーション時のオーバヘッドを最小化するのと引き換えに、リカバリ時間を犠牲に することになります。したがって、ファイルシステムのレプリケーションは、再同期が必要になるよ うな停止がめったに発生しない、信頼性の高いネットワークに最適な方法です。 Page 32 VERITAS Data Availability Solution www.veritas.com/jp ファイルシステムのレプリケーションにはもう 1 つの利点があります。レプリケーションデータオブ ジェクトについてかなり多くのこと（たとえばファイルが使用中かどうかなど）が判明しているので、 ファイルシステムのレプリケーションには双方向性があります。セカンダリサイトのアプリケーショ ンは、レプリケーションされたファイルシステムの中のファイルにアクセスすることができます。一 部の状況のもとでは、セカンダリサイトのアプリケーションで変更したファイルをプライマリサイト に複写し戻すこともできます。ボリュームグループのレプリケーションではこれはできません。ボリ ュームグループの場合は、完全に単一方向のみのレプリケーションです。 ボリュームグループ・レプリケーション ボリュームグループのレプリケーションでは、プライマリサイトのボリュームに書き込まれたブロッ クが、1 つまたは複数のセカンダリサイトにあるボリュームにコピーされます。ボリュームのレプリケ ーションに必要なコンテキストは非常に少ないので、非同期レプリケーションを行うことができます。 非同期レプリケーションのメカニズムについては後で説明しますが、アプリケーションにとっての主 要な利点は、アプリケーションのパフォーマンスが向上し、ネットワーク停止からの高速リカバリが できるということです。 ネットワーク停止が発生している間、ボリュームレプリケーションのプライマリサイトは、レプリケ ーションボリュームグループに対するすべての更新を記録します。ネットワークがリカバリした後で、 停止中にプライマリサイトのログに記録されていたブロック更新が、セカンダリサイトに送られます。 したがって、ボリュームグループのレプリケーションは、プライマリサイトとセカンダリサイト間の ネットワークの信頼性が低い場合に適した選択肢です。 ボリュームグループのレプリケーションでは、その性質上、レプリケーションがアクティブになって いる間は、原則としてセカンダリサイトのアプリケーションがレプリカを使用することはできません。 そのため、ボリュームグループのレプリケーションは、以下の 2 つの一般的な利用分野に使用するの が最適です。 è データの発行 企業によっては、データを中央（プライマリロケーション）に保持していて、複数のセカンダリ ロケーションで使用するためにそのデータを発行します。この種の利用方法の主なものとしては、 Web ページ、価格表、製品仕様、および複数の e ビジネスロケーションで使用されるその他の文 書類があります。 è 災害復旧 災害復旧サイトは、プライマリデータセンターから十分に離れた場所にあり、ある程度の範囲に わたって災害が発生した場合でも稼働し続けることができるような、セカンダリデータセンター です（例えば、地震の頻発する地域では、そうでない地域と比べて、プライマリサイトから災害 復旧サイトまでの距離を遠くする必要があります）。プライマリサイトのボリュームグループを、 災害復旧サイトにレプリケーションすることにより、プライマリサイトに災害が発生した場合、 災害復旧サイトでアプリケーションを迅速にリスタートして、最新のデータレプリカを使用して 処理を再開することができます。 この 2 つの利用方法両方に共通した特徴として、セカンダリサイトのデータが使用されるのは、レプ リケーション処理の実行中でなく、レプリケーションされた後であるということが挙げられます。 同期レプリケーション セカンダリサイトのボリュームグループの内容がプライマリサイトにある対応ボリュームグループの www.veritas.com/jp VERITAS Data Availability Solution Page 33 内容とまったく同じ場合に、セカンダリレプリカは最新であると言えます。どの時点をとってもセカ ンダリサイトを最新の状態にしておくためには、すべての更新をすべてのサイトに同期化してコピー する必要があります。つまり、個々のアプリケーション更新をプライマリボリュームと、それに対応 するすべてのセカンダリサイトのボリュームに書き込んでしまって初めて、アプリケーションは次の 処理に進むことができるわけです（VERITAS File Replicator はこのモードで動作します）。 データを同期的に複写するために必要なオペレーションの数が多くある結果、アプリケーションの応 答時間が受け入れがたいほど長くなる場合があります。VERITAS Volume Replicator では、最適化を使 用して、データレプリケーションという目標を犠牲にせずにアプリケーションの応答時間を向上させ ています。同期レプリケーションボリュームに書込みを行うアプリケーションは、その書込みが以下 の状態に達した時点で、すぐに次の処理に進むことができます。 è プライマリサイトのログに記録される。さらに、 è すべてのセカンダリサイトあてに送信される。 図 16 は、このレプリケーションアーキテクチャを時間軸に沿って表したもので、並行して発生可能な アクションを示しています。ローカルの非レプリケーションボリュームへの書込みと比較すると、同 期レプリケーションボリュームへの書込みには時間がかかります。これは、以下の時間が必要なため です。 è ローカルログに記録する時間（ディスク I/O 時間） è 時間的に最も遠い場所にあるセカンダリサイトとの間のメッセージの往復時間 同期レプリ ケーション 処理リク エスト レプリケーションログ へのデータの書込み プライマリディスクへ のデータの書込み ネットワーク経由 のデータ送信 すべてのセカンダリへ の書込みは並行処理が 可能 イベントは一定の比率 で示されていません。 セカンダリディスクへ のデータ書込み プライマリへの書 込み確認 アプリケーションへの 処理続行指示 アプリケーション の処理続行 プライマリからセカンダリへの書込みと 送信は並行処理が可能 時間 図 16 VERITAS の同期ボリュームグループレプリケーションの流れ 図 16 に示すレプリケーションアルゴリズムを使用すると、以下のような場合にデータを安全に保護す ることができます。 è プライマリサイトの災害（各セカンダリサイトにコピーがある） è セカンダリサイトまたは通信網の障害（すべての更新記録がプライマリサイトにある） この最適化を使用したとしても、アプリケーション更新のピーク時や、ネットワークに一時的なオー バロードが生じた場合、または単にセカンダリサイトが多数あるということだけでも、アプリケーシ ョンのパフォーマンスという観点から見れば、同期レプリケーションは実用性が薄くなります。 VERITAS Volume Replicator は、このような状況に対処するために、非同期レプリケーションモードを サポートしています。 非同期レプリケーション 非同期レプリケーションでは、アプリケーションは、書込みリクエストがプライマリサイトのログに Page 34 VERITAS Data Availability Solution www.veritas.com/jp 記録されるとすぐに、処理を続行することができます。セカンダリサイトへの伝送と書込みは非同期 に行われ、通常はアプリケーションが書込み完了の通知を受け取った後で実行されます。図 17 は、同 期レプリケーションと非同期レプリケーションの間のアプリケーション応答タイミングの違いを示し ています。 同期レプリ ケーション 処理リク エスト レプリケーションログ へのデータの書込み プライマリディスクへ のデータの書込み ネットワーク経由 のデータ送信 イベントは一定の比率 で示されていません。 セカンダリディスクへ のデータ書込み プライマリへの書 込み確認 アプリケーションへの 処理続行指示 アプリケーション の処理続行 時間 非同期レプリ ケーション 処理リク エスト レプリケーションログ へのデータの書込み プライマリディスクへ のデータの書込み ネットワーク経由 のデータ送信 セカンダリディスクへ のデータ書込み アプリケーションへの 処理続行指示 アプリケーションの 処理続行 アプリケーションの 応答性の向上 図 17 同期レプリケーションと非同期レプリケーションのパフォーマンス 図 17 に示すように、非同期レプリケーションでは、待ち時間、つまり終端間のアプリケーション書込 みリクエストの実行時間が減少します。しかし、非同期レプリケーションにより得られるもっと重要 な成果は、ネットワークに一時的なオーバロードが発生しても、アプリケーションの停止や、書込み リクエストの失敗がないということです。 非同期でコピーされるボリュームに対して書込みを行うアプリケーションは、ネットワークの負荷が 原因となる速度低下、あるいは処理停止が発生することはありません。これは、通信リンクおよびセ カンダリサイトとは独立して、アプリケーションが実行されるからです。 レプリケーションマネージャは、ネットワークおよびセカンダリサイトの能力が許す限り速い速度で、 プライマリサイトログからセカンダリサイトに書込みリクエストを送信します。ネットワークの負荷 が一時的なものであれば、最終的には解消され、セカンダリサイトが最新状態に更新されます。ネッ トワークの負荷が慢性的な場合は、レプリケーション未完了の書込みのプライマリログがどんどん大 きくなり、最終的にはアプリケーションが停止します。非同期レプリケーションは、短時間のネット ワーク負荷に対する緩衝機能としての役割を果たすことはできますが、ネットワーク帯域幅の確保が 不十分な場合にその代わりをすることはできません。 非同期レプリケーションの利点は、同期レプリケーションに比べて総じてアプリケーションの応答性 がよくなること、一時的なネットワークの負荷に対する許容性があること、およびセカンダリサイト のクラッシュまたはネットワーク停止などの後での高速リカバリが可能なことです。欠点は、短いと は言え、セカンダリボリュームが完全には最新の状態になっていない時間帯が生じることです。この 状態のときにセカンダリコンピュータのクラッシュまたは通信障害が発生した場合、プライマリログ からのデータは、リカバリの後で伝送され、書き込まれます。しかし、プライマリサイトにリカバリ 不能な災害が発生し、プライマリログの内容を取り出すことができなくなった場合は、セカンダリサ イトのリカバリは、多少古いデータを使用して行わなければなりません。 このような損失可能状態に制限を設けるために、システム管理者は、最大書込み数を指定して、セカ ンダリサイトが非整合状態に置かれる程度を抑えることができます。このしきい値を超えると、未送 信データの量が許容しきい値より下がるまで、プライマリサイトでのアプリケーションの書込みが停 www.veritas.com/jp VERITAS Data Availability Solution Page 35 止します（完了は通知されません） 。このしきい値は、レプリケーションデータの非整合性が許される 限界を規定します。 非同期レプリケーションは、完全な整合性を保証するものではないにしても、多くの場合は、パフォ ーマンス上の理由からオペレーションに欠かせない存在です。更新による一時的なオーバロード、ま たは他のソースからの大量のネットワーク負荷が加わった場合には、アプリケーションの応答時間が 受け入れ可能な範囲を超えて増大することがあります。非同期レプリケーションにより、リモートか らデータを複写するために必要なアクションのほとんどをアプリケーション応答時間から取り除くこ とができ、レプリケーションに実用性があるかないかの違いもここから生まれます。 レプリケーションボリュームの使用 ボリュームレプリケーションでは、レプリケーションマネージャには、更新済みブロックの特性に関 する情報、つまりファイルデータ、ファイルシステムメタデータ、データベースページ、またはその 他のオブジェクトが更新済みブロックに含まれているかどうかに関する情報は通知されません。この 種の情報なしには、レプリケーションマネージャはプライマリサイトとセカンダリサイトの更新の同 期をとることはできません。したがって、ボリュームグループのレプリケーションは完全に単一方向 となります。つまり、ブロックはプライマリサイトから 1 つまたは複数のセカンダリサイトにコピー することはできますが、逆方向にはコピーできません。 ハイブリッドリカバリ 非同期レプリケーションを使用しているシステムにリカバリ不能なプライマリサイト災害が発生した 場合は、セカンダリサイトのボリュームはやや古いものになっていることがあります。プライマリサ イトで（多くの場合はアプリケーションまたはユーザのアクションの結果として）完了に向けての処 理の途中だった更新の中には、災害が発生した瞬間には、転送の途中であったり、後で送達するため にログに入っていたりするものもあります。このような更新は、災害から復旧するために使用するセ カンダリデータベースには反映されていません。このような状況のもとでのリカバリには、一般に、 より高度なレベルのシステム機能（例えばデータベースログ）を使用したハイブリッド技法が必要に なります。 例えば、レプリケーション元のボリュームグループのボリューム上に構築するファイルシステムには、 データベースのテーブルスペースを入れておきます。パフォーマンス上の理由から、ボリュームグル ープは非同期で複写することにします。しかし、データベースジャーナルは、同期レプリケーション するファイルシステムの中のファイルに入れておきます。この場合、プライマリサイトに災害が発生 し、その結果としてテーブル更新が転送途中で失われた場合でも、セカンダリサイトのデータベース レプリカを現行状態に保つために必要な REDO ログは、無傷のまま最新状態でセカンダリサイトに残 っていることになります。ログは同期レプリケーションされるので、データベースイメージ自体にま だ適用されていない更新も含めて、すべてのデータベース更新がログに反映されています。図 18 に、 このハイブリッドレプリケーションを用いたレプリケーションを示します。 Page 36 VERITAS Data Availability Solution www.veritas.com/jp ネットワーク ファイルシステム データベースジャーナル アプリケーシ ョン更新 プライマリ サーバ データベースジャーナルの 同期レプリケーション ファイルシステム データベースジャーナル ファイル B ファイル B ファイル C ファイル C ボリューム ボリューム テーブルスペース P テーブルスペース P Volume Volume テーブルスペース Q テーブルスペース Q Volume テーブルスペース R データベーステーブル 非同期レプリケーション セカンダリ サーバ Volume テーブルスペース R 図 18 データベースのためのハイブリッドレプリケーション・テクノロジ 災害と障害 災害復旧におけるストレージレプリケーションの重要性はこれまでも強調されてきました。主要デー タの最新のリモートレプリカを使用することによって、災害の発生後も e ビジネスを迅速にインター ネット上で再開することができます。リモートサイトに最新データを置いておくことは、ビジネスを 継続させるための重要な要素ですが、これはほんの一部分にすぎません。従業員、通信、運輸手段そ の他の事項を考慮すると、正真正銘の災害が起こらない限り、プライマリデータセンターからバック アップデータセンターへのオペレーションの移動は通常は望ましくありません。 一般に、システムクラッシュとストレージデバイス障害は、ローカルな問題として取り扱う方が便利 です。ストレージデバイス障害に対処するための推奨ソリューションは、自動スペアリング機能を備 えた RAID です。システムクラッシュ時にデータセンターを根本的に無傷で機能できる状態にしてお くためのソリューションとしては、アプリケーションの自動フェールオーバ機能を備えたクラスタリ ング（次章で説明）の方が適しています。e ビジネスの災害復旧における重要な戦略のひとつは、どの ような場合でも、一時的にレプリケーションを中断する短期障害と、セカンダリデータセンターが e ビジネスのオペレーションを継承する必要がある真の災害とを区別するための、客観的基準を明確に することです。 ネットワーク停止は、プライマリサーバまたはセカンダリサーバのクラッシュと同様に、ボリューム レプリケーションの破壊の原因になります。プライマリおよびセカンダリのレプリケーションログは、 このタイプの破壊を乗り切り、すべての必要な施設や機能が再び使用可能になったときに再同期して レプリケーションを再開するためのメカニズムです。プライマリレプリケーションログは、更新情報 をセカンダリサイトに送信できるようになるまで、更新を保持しています。プライマリサイトの災害 により、セカンダリサイトの 1 つを新しくプライマリのアプリケーション実行サイトにする必要が生 じた場合は、そのセカンダリサイトのレプリケーションログが新たなプライマリログとして使用され ます。 www.veritas.com/jp VERITAS Data Availability Solution Page 37 ネットワーク停止 プライマリログ 更新 X 更新 Y アプリケーシ ョン更新 更新 Z プライマリ サーバ セカンダリログ 通信再開まで、更新情 報はプライマリログに 収集される サービス停止の間、更 新はプライマリサイト のみに適用される ボリューム テーブルスペース P Volume テーブルスペース Q Volume テーブルスペース R ボリューム セカンダリ サーバ テーブルスペース P Volume テーブルスペース Q Volume テーブルスペース R 図 19 レプリケーションとネットワーク停止 レプリケーションの「ハートビート」 VERITAS のボリュームレプリケーションには、ハートビート（心拍）、つまりプライマリサーバそれ ぞれのセカンダリサーバの間で定期的に交信するメカニズムが組み込まれています。ハートビートに よって、レプリケーションに関与する両者が常に接続の状態を確認し、アプリケーション I/O トラフィ ックがあるかどうかを判断することができます。すなわち、通信障害は能動的な方法で検出されます。 アプリケーションがレプリケーションボリュームへの書込みをしようとしたときの応答により、受動 的に判明するのではありません。 レプリケーションとデータの復旧可能性 VERITAS Volume Replicator では、プライマリサイトとセカンダリサイト間のブロックの書込み順序が 維持されます。これによって、ネットワークが複雑なためにアプリケーション更新の到着順序が狂っ た場合でも、新しいアプリケーション更新が同じブロックの古い更新情報で上書きされる事態を防ぐ ことができます。書込み順序の維持は、災害復旧のため、例えば、災害の発生前に書き込まれた新し い更新情報が、リカバリ中に古い更新情報で上書きされることを防止するためにも、必要な情報です。 レプリケーションとデータベースの整合性 データベースが以下の 2 つの条件を満たす場合にのみ、オンディスクイメージにはトランザクション レベルの一貫性があり、したがって、バックアップまたは災害リカバリに適しているといえます。 è 未解決のトランザクションがない è まだ書込みの済んでいないデータがキャッシュに残っていない 他のアプリケーション管理ツールやデータ管理ツールもそれぞれ独自の整合性に対する判断基準を持 っていて、レプリケーションマネージャがそれを検出することはできません。データ整合性の要件は アプリケーション固有の要件なので、VERITAS のレプリケーションテクノロジには、インバンド制御 （IBC）用のアプリケーションプログラミングインタフェース（API）が組み込まれています。この IBC-API により、プライマリサイトに登録されたアプリケーションは、レプリケーションされたデー タストリームの特定ポイントでセカンダリサイトにメッセージを渡すことができます。プライマリサ イトのアプリケーションは、e ビジネスにとって重要なイベント（例えば 1 営業日の終了）が発生した Page 38 VERITAS Data Availability Solution www.veritas.com/jp ときに、IBC メッセージをすべてのセカンダリサイトに送信することができます。IBC メッセージはセ カンダリサイトでのレプリケーションを凍結させます。セカンダリサイトのレプリケーションデータ は、IBC メッセージが発行された時点のプライマリサイトのデータとまったく同じ状態で凍結されま す。セカンダリサイトの登録アプリケーションは、IBC メッセージを受け入れ、それを処理し、対応 する API を起動してレプリケーションを再開できるようにする必要があります。図 20 に、レプリケー ションの IBC の流れを示します。 プライマリサイトは データの更新を続行 レプリケーションログ へのデータ1の書込み プライマリ サイト IBC メッセージの 送信 レプリケーションログ へのデータ2の書込み プライマリディスクへ のデータ1の書込み レプリケーションログ へのデータ3の書込み レプリケーションログ へのデータ4の書込み その他 プライマリディスクへ のデータ2の書込み プライマリディスクへ のデータ3の書込み プライマリディスクへ のデータ4の書込み ネットワーク経由 のデータ 1 の送信 ネットワーク経由 のデータ 2 の送信 ネットワーク経由 のデータ 3 の送信 時間 IBC メッセージの 受け入れ セカンダリ サイト IBC メッセージの 処理 レプリケーション 再開のための API セカンダリディスクへ インバンド制御メッセージを セカンダリサイトのアプリケーション のデータ1の書込み 受信すると は API を使用してレプリケーションを レプリケーションが停止 再開できるようにする セカンダリディスクへ のデータ1の書込み etc 図 20 IBC メッセージの流れ 相補的な災害復旧 プライマリとセカンダリというレプリケーションサイトの役割は、レプリケーションするボリューム グループまたはファイルシステムとの関係で決まるものです。あるサーバが、あるレプリケーション ボリュームグループにとってはプライマリサーバであり、別のレプリケーションボリュームグループ にとってはセカンダリサーバであることは十分にあり得ることです。図 21 は、この特性を利用して相 補的に災害からの復旧可能性を得る方法を示しています。 ネットワーク アプリケーショ ン A の更新 アプリケーシ ョン A 用の プライマリ サーバ アプリケーシ ョン B 用の プライマリ サーバ アプリケーション A のボリューム アプリケーション B のボリューム テーブルスペース L テーブルスペース P Volume Volume テーブルスペース M テーブルスペース Q アプリケーション B のレプリカ アプリケーション A のレプリカ テーブルスペース P' テーブルスペース L' レプリケーションの方向 Volume テーブルスペース Q' アプリケーシ ョン B 用の プライマリ サーバ アプリケーショ ン B の更新 アプリケーシ ョン A 用の セカンダリ サーバ Volume テーブルスペース M' 図 21 相補的な災害復旧 図 21 に示したシステムには、アプリケーション A および B のそれぞれに専用サーバがあります。ア プリケーション A のデータは、アプリケーション B のサーバに接続されたレプリケーションボリュー ムグループに複写され、逆の関係のレプリケーションも行われます。どちらかのサイトの機能が停止 した場合、残っている方のサイトのサーバで最新のデータを使用して、そのサイトのアプリケーショ ンを再開することができます。 e ビジネスが成長し、専用アプリケーションサーバの配置が始まるに伴い、レプリケーションテクノロ ジをベースとした相補的な災害からのリカバリを、検討するのが賢明です。ハードウェアに関しては、 www.veritas.com/jp VERITAS Data Availability Solution Page 39 通常の場合、以下の投資が必要です。 è データのレプリカ用に必要なストレージデバイス è サーバ処理能力とメモリ容量の増強。これは、レプリケーションを処理し、フェールオーバが生 じたときに十分なパフォーマンスを提供できるようにするためです。 è 通常のオペレーショントラフィックと並行してレプリケーショントラフィックを処理できるだけ の十分なネットワーク帯域幅 これらの条件が満たされていれば、e ビジネスは、災害によって 1 つのデータセンター全体の機能が失 われた場合でも、迅速にオペレーションを再開しビジネス活動を継続することができます。 Page 40 VERITAS Data Availability Solution www.veritas.com/jp III. クラスタリング e ビジネスアプリケーションの可用性の維持 e ビジネスデータ処理における「処理」の意味 本書では、これまで、e ビジネスにおけるストレージおよびデータ管理、つまり、ビジネス要件を満た すために、高度な可用性を備えたデータを十分なパフォーマンスレベルでアプリケーションに提供す ることに重点を置いて説明を進めてきました。しかし、e ビジネスの可用性とスケーラビリティに関す る要件を満たすには、高度な可用性を備えたデータ処理の能力をも提供する必要があります。e ビジネ スでは、常に以下のような質問に対する回答を考慮すべきです。 è システムに障害が生じたりデータセンターの機能が失われても継続してアプリケーションサービ スを提供できるようにするには、どうすればよいか。 è e ビジネスが成長し、コンピューティングリソースへの負荷が増大したときに、アプリケーション のパフォーマンスを高めるにはどうすればよいか。 è 複数の関連システムを妥当なコストで集中管理するには、どうすればよいか。 VERITAS Cluster Server は、これらの質問に対する説得力のある回答を提供します。それは、クラスタ リングによって複数のサーバ上にあるアプリケーションのオペレーションを調整し、アプリケーショ ンの可用性とスケーラビリティを向上させることです。 クラスタの定義 堅固なクライアント ネットワーク 共通クライアントアクセス サーバ A サーバ B 共通データアクセス 堅固なストレージネットワーク ファイルシステム データベース ファイル A ファイル B ファイル C テーブル P テーブル Q テーブル R 図 22 基本クラスタモデル クラスタとは、一組のコンピュータおよびストレージを相互に接続して、何らかの利益が得られるよ うに個々のオペレーションを調整したものです。図 22 は、クラスタの基本機能を示しています。 クラスタリングを使用する目的は、ほとんどの場合、アプリケーションの可用性を高め、スケーラビ リティを向上させることにあります。一部のクラスタリングテクノロジには単一システムイメージの 概念が付加されて、1 つの場所で複数のコンピュータを単一のシステムとして管理できるようになって います。 クラスタは、コンピューティングの長年の課題を克服することが可能なため、コンピュータユーザに www.veritas.com/jp VERITAS Data Availability Solution Page 41 とって魅力的な概念の 1 つとなっています。 è すべてのサーバが同じデータストレージデバイスおよび同じクライアントに接続しているので、 サーバのどれかに障害が生じたりアプリケーションのどれかがクラッシュした場合に、クラスタ 内の他のサーバがワークロードを引き継ぐことができます。 è 特定のアプリケーションの負荷が高くなり、既存のサーバでは対処できなくなった場合に、新た なサーバを追加して、複数のサーバ間にワークロードを分散することができます。 è ネットワーク接続に障害が生じた場合に、クライアントは代替パスを使用してデータにアクセス し、稼働を続けることができます。 è データセンター全体が稼働不能になった場合に、クラスタに属するリモートコンピュータがその ワークロードを引き継ぎ、オンラインデータのレプリカを使用して処理を続けることができます。 上記の利点のどれも、クラスタリングを利用してある程度実現することができます。VERITAS Cluster Server を使用すると、最大 32 台の Solaris または HP-UX コンピュータを疎結合ユニットとして相互に 接続して、互いに他のアプリケーションを障害から保護できるようにすることができます。アプリケ ーションによっては、VERITAS Cluster Server を利用することにより、クラスタ内の異なるコンピュー タで複数のインスタンスを実行して、単一コンピュータの限界を超える総スループットを達成するこ とも可能です。 アプリケーションとクラスタ クラスタリングは実質的にアプリケーションの動作を拡張するので、妥当な出発点は、アプリケーシ ョンをクラスタサーバの視点から考察すること、つまり、一群の関連システムリソースが提供するサ ービスの 1 つとして見た場合に可用性の向上を検討することです。たとえば、ある Web サーバアプリ ケーションが以下のコンポーネントから成っているとします。 è サービス対象の Web ページを格納するディスク è ディスク上に作成されたボリューム è ボリュームを使用するファイルシステム è テーブルスペースがファイルであり、行にページポインタが含まれているデータベース è ネットワークインタフェースカード（NIC）または Web サービスをエクスポートするために使用 するカード è ネットワークインタフェースカードに関連付けられた 1 つまたは複数の IP アドレス è アプリケーションプログラムおよび関連のコードライブラリ クラスタの視点から見れば、アプリケーションサービスをリソースの集合として認識した場合、重要 な局面が 2 つあります。 è サービスが特定のサーバ上で実行すべきものである場合は、そのサービスに必要なすべてのリソ ースが、そのサーバで使用可能でなければならない。 è 1 つのサービスを形成するリソース間には相互依存性がある。つまり、あるリソース（例えばファ イルシステム）が稼働するためには、他の特定のリソース（例えばボリューム）が稼働状態にな っていなければなりません。 VERITAS Cluster Server は、1 つのサービスを形成するリソースを 1 つのグラフとして見ます。このグ ラフの中で、丸でかこんだ部分はリソースを表し、太線は依存関係を表します。図 23 は、クラスタサ Page 42 VERITAS Data Availability Solution www.veritas.com/jp ービスにおけるリソース依存関係のグラフを示しています。 アプリケーション アプリケーション はデータベースと IP アドレスを必要 とする データベース IP アドレス ネットワーク カード ファイルシステム ボリューム ボリュームはディスク を必要とする ディスク 図 23 クラスタサービスリソース依存関係グラフ 図 23 で、下位（子）ノードは、上位（親）ノードが機能するために必要なリソースを表しています。 例えば、ボリュームにとってはディスクがオンラインになっていることが必要であり、ファイルシス テムにとってはボリュームがアクティブになっていることが必要です。アプリケーションプログラム 自体にとっては、2 つの独立したリソースサブツリー、つまり、データベースと、クライアント通信用 の IP アドレスが機能していることが必要です。 リソースのアクティブ化と非アクティブ化 VERITAS Cluster Server には、リソース依存関係グラフを指定するための言語が組み込まれています。 クラスタ制御/監視デーモン（エンジン）は、アプリケーションをアクティブまたは非アクティブにす るときに、リソース依存関係グラフを使用します。一般に、親リソースをアクティブにするには、そ の子リソースが機能していることが必要です。クラスタエンジンは、特定のサービスをアクティブに するときに、そのサービスのリソース依存関係グラフの枝葉となっているノードが表しているリソー スをオンラインにします。 例えば、図 23 では、ディスクとネットワークカードの間には相互依存関係がないので、両者を並行し てにオンラインにすることができます。親が必要とするすべての子リソースがオンラインになると、 今度は親自体がオンラインにされます。このようにしてツリーをさかのぼり、最後にはアプリケーシ ョンプログラム自体が起動されます。 同様に、サービスを非アクティブにするときには、クラスタエンジンはグラフの最上位から操作を進 めます。図 23 の場合、まずアプリケーションプログラムが停止され、次にデータベースと IP アドレ スが並行してに続き、残りのリソースに対しても操作が続けられます。 これまで説明してきたリソースグループは、フェールオーバグループと呼ばれています。フェールオ ーバグループ内のリソースは、一度にクラスタ内の 1 つのコンピュータでのみオンラインにすること ができます。これは、2 つのコンピュータが、同じデータを対象として同じアプリケーションを実行で きないようにするためです。クラスタエンジンは、他のタイプのリソース依存関係も認識します。例 えば、同じアプリケーションのテストバージョンと実動バージョンの場合のように、2 つのサービスを www.veritas.com/jp VERITAS Data Availability Solution Page 43 同時に実行できないようにすることが必要な場合があります。このような関係をリソースグループ内 で表現するには、サービス全体の間の依存関係を指定することができます。クラスタエンジンは、こ のような依存関係を管理します。上記に示した例では、クラスタエンジンは、テストアプリケーショ ンと実動アプリケーションが同時に実行できないようにします。 アプリケーションのスケーラビリティを確保するために、クラスタエンジンはパラレルグループとい うリソースグループも認識します。パラレルグループ内のリソースは、同時に複数のサーバでオンラ インにすることができます。したがって、単一サーバより大きい容量を必要とするアプリケーション を複数のインスタンスに分けて、各インスタンスを別々のサーバで実行することができます。パラレ ルリソースグループでは、クラスタ内の複数のサーバ上で実行される複数のアプリケーションインス タンスからの共有データへの同時アクセスを調整するのは、アプリケーションの責任です。 異なるタイプのリソースの調整 リソースをオンラインまたはオフラインにするために必要なアクションは、リソースのタイプによっ て大きく異なります。例えば、ディスクをオンラインにするには、ディスクをスピンアップするため の SCSI コマンドが必要であり、Oracle データベースをオンラインにするには、データベースマネージ ャプロセスを起動し、適切な startup コマンド（群）を発行する必要があります。クラスタエンジンか ら見れば、どの場合も、リソースが使用可能になるという同じ結果がもたらされることになります。 しかし、実施されるアクションはまったく異なります。VERITAS Cluster Server は、このようなリソー スタイプ間の機能的な相違に、きわめて効果的な方法で対処します。これにより、アプリケーション およびハードウェアの開発者は、新しいタイプのリソースを簡単にクラスタフレームワークに組み込 むことができます。 クラスタ内でサポートされる各リソースタイプは、それぞれ 1 つのエージェントに関連付けられます。 エージェントは、インストールされクラスタエンジンに登録されているプログラムです。エージェン トは、以下に示す 3 つのメソッド（エントリポイント）のいずれかにより呼び出すことができます。 è オンライン リソースをアクティブにする必要がある場合に、クラスタエンジンにより呼び出されます。 è オフライン リソースを非アクティブにするときに、クラスタエンジンにより呼び出されます。 è モニタ リソースの稼働状態をテストするときに呼び出されます。 クラスタエンジンは、必要なときにエージェントのメソッドを呼び出して、アプリケーションサービ スの起動と停止、およびフェールオーバを行います。各エージェントメソッドには、クラスタエンジ ンにより呼び出されるときに、属性と呼ばれる一連のパラメータが与えられます。 クラスタリソースエージェントの構造は単純なので、新たなクラスタリソースタイプの追加が必要に なった場合、比較的簡単にエージェントを開発することができます。例えば、Database Edition for Oracle には、Oracle データベースをクラスタリソースにするエージェントが組み込まれています。組み込ま れているのは以下の 2 つのエージェントです。 è Oracle プロセスエージェント startup コマンドおよび shutdown コマンドを発行します。 è SqlNet Listener エージェント Page 44 VERITAS Data Availability Solution www.veritas.com/jp Oracle クライアントリスナを起動および停止します。 これらはどちらもエージェントのモニタエントリポイントで、それぞれ対応するリソースが実行され ているときに、データベースの状態を監視するための Oracle Monscript を実行します。 クラスタのコンポーネント VERITAS Cluster Server は、上記で述べたアプリケーションサービスアーキテクチャを使用して、シス テム全体に障害が生じてもほとんど継続的にクライアントにサービスを提供できるような、堅牢なア プリケーション実行環境を提供します。クラスタを構成するコンポーネントは、図 24 に示すとおりで す。 クライアントアクセス ネットワーク クラスタ サーバ クラスタ サーバ クラスタ サーバ クラスタ サーバ プライベートクラスタ 相互接続 ストレージアクセス ネットワーク 図 24 VERITAS クラスタリングモデル 1 つのクラスタは、VERITAS クラスタサーバを実行する 2∼32 台のサーバから成っています。クラス タサーバには、幾つかの機能を有するコンポーネントが含まれています。 è エンジン クラスタ内に存在するすべてのクラスタサーバインスタンスの状態を監視し、管理ポリシーに従 って状態変更（例えばフェールオーバ）を行うリアルタイムプロセスです。 è 通信モジュール 特化された、堅固で待ち時間の小さいプロトコルを使用して、他のクラスタサーバインスタンス と通信し、負荷を均衡化し、クラスタ通信リンクの状態を絶えず監視します。 è トランスレータ 構成言語で表されたリソース依存関係グラフを読み、エンジン用に解釈します。 è 負荷監視機能 ローカルコンピュータの負荷を監視します。クラスタエンジンインスタンスは、この情報に基づ き、使用可能なリソース間でアプリケーション負荷が均衡化されるような方法で、アプリケーシ ョンサービスをコンピュータに割り当てます。 è エージェント クラスタ内のリソースタイプごとにエージェントがあります。 è コマンドラインおよびグラフィカルの両方のシステム管理インタフェース www.veritas.com/jp VERITAS Data Availability Solution Page 45 クラスタサーバインスタンスは、複数の物理的に異なる相互接続を介して、互いに通信します。これ らの相互接続の少なくとも 1 つは、プライベート接続、つまりクラスタサーバインスタンスの相互通 信専用の接続でなければなりません。構成によっては、共有ディスクパーティションを、クラスタサ ーバのインスタンス間の相互接続用として使用することもできます。 一般にクラスタリングには、障害が通信相手となっている別のコンピュータ内で発生しているか、両 者を接続している（非冗長）リンクで発生しているかを、コンピュータプログラムが区別できないと いう問題がつきまといますが、複数の相互接続があればクラスタサーバのインスタンスはこの問題を 克服できます。コンピュータ障害とリンク障害の区別がつかない限り、クラスタ内のコンピュータが アプリケーションフェールオーバを実行することはできません。このような場合にフェールオーバを 行えば、互いに通信できない複数のコンピュータが、同じアプリケーションサービスを起動し、同じ データを処理しようとすることになります。その場合、ほぼ確実にデータの不整合が生じます。 クラスタ内のすべてのサーバは、共通のクライアントアクセスネットワークに接続され、同じストレ ージにアクセスできるようになっていることも必要です。現実的には、並列 SCSI 接続ストレージを備 えたクラスタは、4 台以下のサーバを持つ構成が一般的です。これは、並列 SCSI 固定優先順位バスア ービトレーションスキームでは、1 つのバス上に 4 台を超えるサーバを構成すると、欠乏状態が生じる おそれがあるからです。しかも、並列 SCSI バスは、最大 16 個までのデバイス（コンピュータ、ディ スク、テープ、または RAID サブシステム）にしか接続できません。したがって、クラスタにこれよ り多くのサーバを追加すると、アドレッシングできるストレージデバイスの数が減少するという、ま さにスケーラビリティに逆行する結果が生じることになります。 SAN（ストレージエリアネットワーク） 、特に FC（ファイバチャネル）ベースの SAN は、並列 SCSI のストレージ接続性に関する制約を緩和します。FC-AL（Fibre Channel Arbitrated Loop）では、最大 126 個のノード（FC ポートを持つデバイス）を接続でき、これらのノードは、コンピュータ、ストレージ サブシステム、およびストレージデバイスのどのような組み合わせであっても構いません。FC ファブ リックスイッチを用いれば、理論上 224 個のデバイスを相互に接続することができ（現実にこれまでに 構築されているネットワークでは、通常デバイス数は 100 個以下ですが） 、したがって、クラスタリン グにおけるストレージ接続性という問題は事実上解消されます。 クラスタ化コンピューティングの真髄は、堅固なデータ処理にあります。原理的には、直接接続ディ スクも含めてどのようなタイプのマルチホストストレージデバイスでも、クラスタデータストレージ として使用できます。しかし、最大限のシステム可用性を達成するには、複数のホストアクセスパス を持ち、障害に対する高度な耐性と可用性を備えたストレージサブシステムを使用するのが最適です。 ほとんどのクラスタは、何らかの形で障害に対する耐性を備えた RAID サブシステムを使用していま す。VERITAS Cluster Server には、主要な RAID サブシステム製品をサポートする幾つかのエージェン トが組み込まれています。 クラスタの使用 フェールオーバ おそらく、e ビジネスにおけるクラスタの最大の使用目的は、アプリケーションサービスの可用性を強 化することでしょう。重要なリソース（例えば、アプリケーションプログラム、またはサーバとアプ リケーションデータを接続するホストバスアダプタなど）の障害、または、アプリケーションが実行 されているサーバの障害が原因で、アプリケーションサービスに障害が生じることがあります。どの ような理由であれ、サービス障害を検出すると（つまり、監視対象のサービスリソースグループのハ ートビートが応答しない） 、クラスタエンジンは、フェールオーバオペレーションを開始して、別のコ Page 46 VERITAS Data Availability Solution www.veritas.com/jp ンピュータ上でアプリケーションをリスタートします。クラスタの構成を行う際に、管理者は、各ア プリケーションサービスを実行に適したコンピュータの順位を指定したリストを設定します。フェー ルオーバサービスのリソースグループおよびコンピュータ間の類似性を指定することにより、カスケ ード式フェールオーバが可能になります。図 25 で、クラスタサーバ A が、あるアプリケーション用の 優先サービスのリソースグループとして指定されているとすれば、そのアプリケーションは、最初に 起動されるときにはサーバ A で実行されます。サーバ A に障害が生じた場合は、サービスグループは、 サーバ群の中の優先フェールオーバサーバとして指定されているサーバでリスタートされます。その 優先フェールオーバサーバに障害が生じた場合は、セカンダリフェールオーバサーバ以下が順次引き 継ぎます。物理構成上可能であれば、クラスタ内のすべてのサーバを、特定のサービスグループ用の 潜在フェールオーバサーバとして指定することができます。 クラスタ サーバ A クラスタ サーバ B クラスタ サーバ C クラスタ サーバ D クラスタ サーバ A' クラスタ サーバ B' クラスタ サーバ C' クラスタ サーバ D' ファイバチャネル ハブまたは スイッチ ボリューム X フルストレージ接続モデル （例えばファイバチャネル） ボリューム Y ボリューム Z 部分ストレージ接続モデル （例えば並列 SCSI） 図 25 クラスタ内の全ストレージ共有と部分ストレージ共有 サーバは、アプリケーションサービスを実行するためには、そのサービスのすべてのリソースにアク セスできることが必要です。特定のサービスを実行できるコンピュータは、ストレージオブジェクト およびプロセスオブジェクト（このオブジェクトのイメージはストレージオブジェクト上にある）と いう 2 つのタイプのリソースにより制約されます。なぜなら、これらのオブジェクトは、クラスタ内 のすべてのコンピュータに物理的に接続されていないかもしれません。図 25 に、2 つのクラスタ接続 モデルを示してあります。 è 全ストレージ共有 クラスタ内のすべてのコンピュータと、クラスタ内にあるすべてのストレージデバイスの間に物 理的な直接接続があります。 è 部分ストレージ共有 すべてのコンピュータがすべてのストレージデバイスに直接接続されているわけではありません。 全ストレージ共有のハードウェア構成では、クラスタ内のどのコンピュータも、特定のアプリケーシ ョンサービスグループ用のフェールオーバターゲットとして指定できます。したがって、図 25 の左側 に示されているクラスタでは、通常はサーバ A で実行されるアプリケーションサービスは、サーバ B、 サーバ C、およびサーバ D に、この順序で（または他の任意の順序で）フェールオーバすることがで きます。これに対して、図 25 の右側に示されているクラスタでは、通常はサーバ A'で実行されるアプ リケーションはサーバ B'にはフェールオーバできますが、その他のサーバにはフェールオーバできま せん。その他のサーバは、このアプリケーションサービスのデータまたはアプリケーションプログラ www.veritas.com/jp VERITAS Data Availability Solution Page 47 ムイメージにアクセスできないからです。 同様に、通常はサーバ B'で実行されるアプリケーションサービスは、必要なすべてのリソースがボリ ューム X のみを使用している（またはそれのみに依存している）のであれば、サーバ A'にフェールオ ーバすることができます。また、すべてのリソースがボリューム Y のみを使用している（またはそれ のみに依存している）のであれば、このサービスはサーバ C'にフェールオーバできます。このアプリ ケーションサービスに、ボリューム X とボリューム Y の両方を使用する（またはこの両方に依存する） リソースが含まれている場合は、このサービスはフェールオーバできません。 この例は、ハードウェアにより実現される接続が部分ストレージ共有のみである場合に、クラスタを 構成するシステム管理者が注意する必要がある点を示しています。フレキシビリティと成長の観点か ら見れば、全ストレージ共有を提供するハードウェアソリューション（例えばファイバチャネル SAN） の方が優れています。 アプリケーションのスケーリング VERITAS のクラスタテクノロジは、パラレルリソースグループのほかに、複数サーバへのアプリケー ションサービスのスケーリングもサポートしています。図 26 は、いわゆる並列アプリケーションを複 数のサーバで同時に実行するように構成されたクラスタを示しています。 クラスタ サーバ A クラスタ サーバ B クラスタ サーバ C クラスタ サーバ D アプリ ケーション P1 アプリ ケーション P2 アプリ ケーション P3 アプリ ケーション P4 ファイバチャネル ハブまたは スイッチ 図 26 並列サービスリソースグループ 図 26 に示したクラスタは、4 つのサーバのそれぞれで、アプリケーションサービス P のインスタンス を 1 つずつ実行します。クラスタエンジンは、クラスタの初期化の時点で、パラレルリソースグルー プを認識し、4 つのアプリケーションインスタンスを自動的に起動します。ただし、図 26 から連想さ れるように、1 つのアプリケーション内にある複数のインスタンスがデータを共有する場合は、アプリ ケーションまたはデータ管理システムに、複数のインスタンスが互いに干渉し合うことがないようす るためのメカニズムが組み込まれていることが必要です。 未調整の状態で複数のアプリケーションが同時にデータにアクセスすると、さまざまの形でデータの 不整合が生じるおそれがあります。例えば、オンラインの販売アプリケーションが、毎日の販売額の 累計を更新するとします。販売が行われるたびに、日次累計が読取られ、その販売額が加算され、結 果がストレージに書き込まれます。図 27 は、このアプリケーションの複数のインスタンスがクラスタ 内の異なるコンピュータで実行されているときに、日次売り上げ累計のデータが不整合される場合の 一例を示しています。 Page 48 VERITAS Data Availability Solution www.veritas.com/jp 日次売り上げ累計 の読取り – $10,000.00 アプリケーション インスタンス P1 新規販売額の加算 – $100.00 新しい日次売り上 げ累計の書込み -$10,100.00 ディスクの内容 日次売り上げ累計 $10,000.00 日次売り上げ累計 $10,100.00 日次売り上げ累計 $10,400.00 時間 わずかに遅れて 2 番目の更 新が発生し、第 1 の更新 よりわずかに長い時間が かかる 日次売り上げ累計 の読取り – $10,000.00 アプリケーション インスタンス P2 新規販売額の加算 – $400.00 新しい日次売り上 げ累計の書込み – $10,400.00 日次売り上げ累計は 2 つの売り上げ額のいず れかとして解釈される 図 27 同時アプリケーションアクセスによるデータ不整合のシナリオ 図 27 に示したデータ不整合の問題は、更新プロセス間に相互の認識がないことが原因で発生します。 操作が正しく行われるようにするには、両方の読取り/変更/書込みの更新シーケンスがアトミックでな ければなりません。つまり、どちらかのシーケンスが発生している間は、日次売り上げ累計レコード に対して、他の何らかの操作が行われてはならないということです。これらの更新を行うアプリケー ションインスタンスが同じコンピュータで実行されている場合は、正しい操作が行われるようにする には、複数同時書込み機能を許容するファイルシステムが必要です。このようなファイルシステムに はローカルロックマネージャが組み込まれています。このマネージャは、ファイル内の個々のバイト 範囲へのアクセスを予約して、複数のプロセスによる同時更新を防止します。 図 27 に示したプロセスがそれぞれ異なるコンピュータで実行されている場合は、分散ロックマネージ ャが必要です。ローカルロックマネージャはメモリデータ構造内の状態を維持しますが、共同作業を 行う各コンピュータ内の分散ロックマネージャインスタンスは、データオブジェクトがロックされた ことまたは解放されたことを示すメッセージを、互いに交換します。このように、ファイルシステム の複数のインスタンスが別々のコンピュータで実行され、分散ロックマネージャを使用してデータへ のアクセスを調整しているとき、これらのインスタンスを総称的に分散ファイルシステムまたはクラ スタファイルシステムと呼んでいます。データベース管理システム（例えば Oracle Parallel Server）は、 データベースオブジェクトをロックするための内蔵の分散ロックマネージャにより、同様の機能をサ ポートしています。 ベリタスでは、Database Edition for Oracle という統合スィートで、Oracle Parallel Server への対応を予定 しています。 www.veritas.com/jp VERITAS Data Availability Solution Page 49 クラスタと災害復旧 VERITAS クラスタリングテクノロジとストレージレプリケーションを結合することにより、サイト災 害からの自動的なリカバリを実現することができます。図 28 は、レプリケーションおよびクラスタリ ングテクノロジを結合した場合の災害リカバリシナリオの一例を示しています。 初期アプリケーションサイトの アプリケーション P 災害回復サイトの アプリケーション P1 インターネット クラスタ サーバ A クラスタ サーバ B クラスタ サーバ C クラスタ サーバ D ボリューム Y ボリューム X レプリケーション 図 28 クラスタテクノロジとレプリケーションテクノロジの結合 図 28 で、サーバ A、B、C、および D は 1 つのクラスタを形成しています。そして、ボリューム X の データは WAN を介してボリューム Y にレプリケーションされます。アプリケーションサービス P は サーバ A で実行でき、サーバ B にフェールオーバできます。同様に、アプリケーション P'はサーバ C で実行でき、サーバ D にフェールオーバできます。アプリケーション P'には、例えば以下のようなも のが含まれています。 è ボリューム Y をレプリケーションセカンダリとして解放し、読取り/書込みボリュームとして再マ ウントするスクリプト è アプリケーション P をリスタートするために必要なアプリケーション依存のデータチェックを行 うスクリプトまたはプログラム è アプリケーションサービス P が使用するものと同じプログラムイメージ すでに述べたように、クラスタサーバの観点から見た場合、アプリケーションサービスリソースグル ープ P および P'は、オフラインの関係を持つものとして構成されます。クラスタエンジンは、サービ スグループ P がオフラインになった場合に限り、サービスグループ P'をオンラインにします。サーバ A または B に障害が生じた場合は、同じサイトのもう一方のサーバがアプリケーションサービス P を フェールオーバし、サービスグループ P'は活動化されません。しかし、災害によりサイト全体が稼働 不能状態に陥った場合は、サーバ A とサーバ B のハートビートが両方共途絶します。この場合、サー バ C および D にあるクラスタ監視メカニズムは、サービスグループ P がオフラインになったものと宣 言し、その結果アプリケーションサーバ P'がアクティブにされます。リスタート及びリスタートに関 連する処理の後で、 サービスグループ P からの同じアプリケーションイメージの代替インスタンスが、 代替サイトからクライアントへのサービスを再開します。 もちろん、リソース利用の最適化を図るために、先述した、相補的フェールオーバ配置を採用するこ ともできます。 Page 50 VERITAS Data Availability Solution www.veritas.com/jp IV. データ管理 稼働中断のない効率的な情報資産保護 データ管理とはなにか オンラインデータは e ビジネスにとって基本的な資産であり、当然管理が必要になります。データ管 理という言葉にはいろいろな意味がありますが、VERITAS では以下のことを指して「データ管理」と 呼んでいます。 è コンピュータ、ストレージ、ソフトウェア、サイトなどの障害の際に、e ビジネスをできるだけ 早急に再開できるようにすること。 è ビジネス用のデータを必要なときに必要なところで手に入れられること。 è 管理ポリシーやビジネス・ポリシーに定められている記録保存要件を満たすこと。 すでに繰り返して説明したように、e ビジネスにおけて情報サービス部門に課せられているのは、ユ ーザがいつでもオンラインデータにアクセスできるようにしておくことです。e ビジネスではオンラ インデータベースは年中無休で稼働し、したがってデータ管理も年中無休の環境で実行されます。 データ管理とは基本的にはデータオブジェクトを移動しコピーする活動であり、例えば次のような内 容になります。 è オンラインデータベースやその他のデータ（HTML ファイル、スクリプト、プログラムイメージ など）のバックアップとアーカイブのコピーを作成します。 è 電子アーカイブをデータセンターから安全な保管場所に移動します。 è データをその発生場所から使用場所へとコピーします。 è データをあまり使われていない場所から頻繁に使われる場所へ移動します。 データオブジェクトのコピーと移動は一見して単純な作業ですが、技術的には次のような困難な課題 があります。 è （エラーが発生した場合でも）必要なときに必要な場所へデータを送るためのポリシーを設計し、 実施する。 è どのデータがどこに格納されているかがわかるようにしておく。例えば、バックアップがどのテ ープに保存されており、そのテープがどこに保管されているかがすぐにわかるようにしておきま す。 è データオブジェクトの移動やコピーのあとでも、データの整合性が失われないようにする。 è データオブジェクトを移動またはコピーすることによって生じるサービスの中断を最小限にする。 è 管理ポリシーの変更について決定する。例えば、バックアップの回数の変更や、製品データや価 格リストのコピーを各支店で複製する回数（これはネットワークのトラフィックに影響します） の変更を決定します。 e ビジネスの IT 部門がこれらの課題に挑むうえで、VERITAS のテクノロジ（バックアップ、階層スト レージ管理、ストレージ最適化など）は大きな助けになります。 バックアップ：データ管理の核 バックアップはデータ管理のアーキテクチャの中で中心的な役割をはたします。バックアップとは特 www.veritas.com/jp VERITAS Data Availability Solution Page 51 定のデータ集合のコピーであり、一定の時点におけるデータをそのままの状態でコピーするのが理想 的です注 4。バックアップしたデータは使用中のデータとは別にして、テープやその他のリムーバルメ ディアに格納されます。バックアップコピーをデータセンターの外部に保管しておけば、災害などに よってデータベースが破壊されても、バックアップしてあるデータで対処できます。バックアップコ ピーの保管には次のようなやり方があります。 è データセンターに保管し、ストレージデバイス、システム、アプリケーションの障害や人間のミ スによって重要なオンラインデータが破壊されても、e ビジネスをごく最近の状態にただちに復 旧できるようにしておきます。 （別途に保管されている限り）データベースログもほぼ最新の状態 に復元できます。 è 1 つまたは複数の別のサイトへ保管し、火災や洪水によってデータセンターが破壊されても、デー タを保護できるようにしておきます。データベースのバックアップコピーがあれば、代替の設備 が使用可能になり次第、e ビジネスを再開できます。 è バックアップコピーを CD-ROM やその他の書込み不可のメディアに保管し、変更ができないよう にします。こうすれば、オンラインでは必要がなくなったデータを長持ちする形で保存でき、管 理ポリシーやビジネス・ポリシーで定められているビジネス記録保存の要件を満たすことができ ます。 --------------------------------------注 4 流動的なデータのコピーを作成する「ファジー」なバックアップも存在します。この種のテクニックによって作成するバ ックアップコピーの場合、データの即時性や整合性には限界があります。したがって、障害時のデータベース復旧には役 立ちますが、ビジネス記録としての価値は低くなります。 --------------------------------------- バックアップは見かけほど単純でない バックアップは一見したところ単純な作業です。システム管理者はまずバックアップすべきデータオ ブジェクトを決め、続いてビジネスにできるだけ影響しないでバックアップを実行できる日時を検討 します。これらが決まったら、ユーティリティプログラムを使ってバックアップコピーを作成します。 作成したコピーは安全な場所に保管し、障害時に必要になった場合に備えます。概念的にはバックア ップはこのようにごく単純なプロセスですが、問題は細部にあります。 è 数の問題 大規模な組織では、システム管理者はいろいろなタイプの数多くのサーバからデータをバックア ップしなければなりません。このため、作業量が膨大になるだけではなく、各プラットフォーム に応じたスキルを身に付け、維持することが必要になります。 è 信頼性の問題 システム管理者はバックアップが実際に実行されるように取り計らう必要があります。利用者が 多く複雑なデータ処理環境では、これは思うほど簡単でありません。重大な障害でも発生しない 限り、バックアップコピーが必要になるようなことはありません。したがって、そうでなくても 忙しいオペレータが、いますぐ必要でないタスクを怠るのはありがちなことです。 è メディアの取り扱いの問題 e ビジネスが進行するにつれ、データを保存したテープやその他のバックアップメディアの数も 必然的に多くなります。人間がメディアを扱う際には、不注意によるミスから、バックアップコ ピーの紛失や上書きが発生することもあります。 Page 52 VERITAS Data Availability Solution www.veritas.com/jp è プレッシャーの問題 失われたオンラインデータを復旧するためにバックアップコピーが必要になるような状況では、 システム管理者はどうしても緊張してしまいます。データ復旧というめったに行わない作業をプ レッシャーのもとで行わなければならないため、手順の読み間違え、誤ったメディアのロード、 安全措置の無視などが起こりがちで、復旧に失敗したり、長い時間がかかったりします。 バックアップの構造 バックアップを 4 つの機能要素に分解すると、VERITAS のバックアップテクノロジがわかりやすくな ります。図 29 はエンタープライズレベルのバックアップのアーキテクチャを示しています。 バックアップクライアント （アプリケーションサーバ） バックアップ ストレージユニット ファイルシステム テーブルスペース A テーブルスペース B スケジュール 1 バックアップ テーブルスペース C エージェント 空きスペース マスター メディア サーバ サーバ スケジュール 2 スケジュール 3 スケジュールに従って バックアップを開始するコマンド バックアップデータフロー 図 29 バックアップを構成する機能要素 図 29 は以下の 4 つの機能コンポーネントを示しています。 è バックアップクライアント（単にクライアントと呼ばれることもあります） バックアップすべきデータが入っているコンピュータシステムです。こうしたコンピュータシス テムは一般にはアプリケーションサーバ、データベースサーバ、ファイルサーバですから、「バッ クアップクライアント」という用語は少し誤解を招くかもしれません。 è バックアップサーバ（単にサーバと呼ばれることもあります） バックアップコピーを作成し、履歴情報を管理するコンピュータシステムです。バックアップサ ーバには以下の 2 つのタイプがあります。 Ø マスターサーバは、バックアップと復旧のスケジュールを確立し、バックアップコピーのカ タログを管理します。こうした機能を実行するマスターバックアップのソフトウェアはバッ クアップマネージャと呼ばれます。 Ø メディアサーバは、マスターサーバの指示に従ってバックアップコピーを作成します。メデ ィアサーバにはバックアップストレージユニットが接続されています。 è バックアップストレージユニット メディアサーバによって制御されるテープ、磁気ディスク、光ディスクなどです。 バックアップを成功させるには、バックアップクライアント、マスターサーバ、メディアサーバの連 携が必要です。 www.veritas.com/jp VERITAS Data Availability Solution Page 53 è バックアップクライアントはバックアップされるファイルに関する情報をマスターバックアップ サーバに送り、オンラインボリュームにあるデータをメディアサーバに送ります。 è バックアップマネージャはバックアップスケジュールに従ってバックアップのジョブを実行しま す。 è メディアサーバは 1 つまたは複数のバックアップストレージユニットからメディアを選んでロー ドし、ネットワークを介して受け取ったクライアントデータをバックアップメディアに書込みま す。 バックアップされているデータを復旧する手順は次のとおりです。 è クライアントが復旧を要求すると、マスターサーバが該当のバックアップコピーを管理している バックアップメディアを見つけ、復旧の要求を送信します。 è メディアサーバは復旧すべきデータオブジェクトを格納しているバックアップメディアを見つけ てマウントし、要求を出したバックアップクライアントにデータを送信します。 è バックアップクライアントはメディアサーバからデータを受け取り、ローカルファイルシステム に書込みます。 e ビジネスを始めたばかりのような小さいシステムでは、上述の 3 つのバックアップ操作が同一のコ ンピュータで行われることもまれではありません（このコンピュータはアプリケーションサーバの役 割も果たしています） 。VERITAS のバックアップ管理アーキテクチャはモジュール式になっており、 システムが大きくなり、ニーズが変化するのに対応して、それぞれの機能をスムーズに（上述のバッ クアップの手順を中断することなく）専用のサーバにマイグレーションします。図 30 はバックアップ アーキテクチャのスケーリングを示しています。 バックアップ クライアント メディア サーバ バックアップ マスター メディア クライアント サーバ サーバ ニーズの 増加 バックアップ マネージャ 当初： ニーズ増加後： バックアップ機能がすべて単一のアプリケーション/ データベースサーバで実行されている 業務やパフォーマンスに関するニーズの上昇に伴い、 バックアップ機能が専用のサーバにマイグレーションする 図 30 スケーラブルなバックアップアーキテクチャ Page 54 VERITAS Data Availability Solution www.veritas.com/jp スケーラブルなバックアップアーキテクチャの利点は e ビジネスの拡大やシステムの分散化が進むに つれて明らかになります。図 31 はスケーラブルなバックアップアーキテクチャが e ビジネスとともに 進化する様子を示しています。 バックアップ クライアント メディア サーバ バックアップ クライアント マスター サーバ メディア サーバ バックアップ クライアント アプリケーションサーバ （バックアップクライアント） 図 31 大企業向けのバックアップアーキテクチャ 図 31 はスケーラブルなバックアップアーキテクチャの 2 つの利点を示しています。 è 中央からのコントロール マスターサーバはすべてのアプリケーションサーバのバックアップスケジュールとデータカタロ グを管理しています。一カ所からのコントロールの利点は、各所に分散する部署やオフィスのバ ックアップを単一の管理チームで実行できることです。 è リソースの共有 メディアサーバを必要に応じて追加することができます。テープドライブは（特にロボット型の メディアライブラリと組み合わせたときには）高価なリソースであり、耐久性もあまりありませ ん。したがって、複数のアプリケーションサーバでテープドライブを共有すれば、かなりのコス トを節約できます。 図 31 に示したような分散アーキテクチャでは、管理費用が少なくてすみ、高価なハードウェアリソー スを有効に活用できます。その反面、ネットワークのトラフィックが増加するというマイナスもあり ます。NetBackup はバックアップの作業がネットワークに与える影響を抑えるためにいろいろなテクニ ックを採用していますが、ときにはネットワークのトラフィックが混んでいるときにバックアップク ライアントからバックアップサーバへ大量のデータを送信しなければならないこともあります。分散 コンピューティング用のバックアップアーキテクチャをデザインする場合は、図 31 のような分散バッ クアップがローカルネットワークのトラフィックに対して与える影響を考慮して、次のいずれかを採 用します。 è アプリケーションのトラフィックとバックアップのトラフィックを同一のネットワークで共有す る。 è バックアップデータ専用にイーサネットまたはファイバチャネルのプライベートなネットワーク を構築する。 è いくつかの（あるいはすべての）アプリケーションサーバ上にメディアサーバを構築して、ロー www.veritas.com/jp VERITAS Data Availability Solution Page 55 カルなバックアップを実行する。 バックアップポリシー e ビジネスに必要なデータはすべてバックアップしなければなりません。その一方で、バックアップ は大量のリソースを必要とする作業であり、システムの通常の稼働に対する影響も考慮しなければな りません。システム管理者はバックアップポリシーでこれら相反するニーズを調整します。バックア ップポリシーは以下のことを定めたルールの集合です。 è どのデータオブジェクトをバックアップするか è いつデータをバックアップするか è どこにデータをバックアップするか 以下に説明するように、VERITAS バックアップ管理コンポーネントはバックアップポリシーを自動的 に実行します。 何をバックアップするか どのデータオブジェクトをバックアップするかを決めるには、ビジネスとシステムの両方に関する知 識が必要になります。効果的なバックアップポリシーは、めったに変更されないデータと頻繁に変更 されるデータを区別し、前者のバックアップ回数を少なめに設定します。 バックアップの対象となるデータはファイルのリストとして指定することもできますが、大規模で活 発な環境では特定のディレクトリツリーの全体をバックアップ対象として指定したほうが効率的です。 こうすれば、個別のファイルの追加や削除をいちいち追跡する必要がなくなります。 もっと複雑な指定もあります。例えば、UNIX 環境では、ファイルシステムは root ディレクトリのも とにマウントされるのが普通です。この場合、下位のファイルシステムとは別のスケジュールで root ディレクトリをバックアップするには、マウントポイントを表すディレクトリをバックアップの対象 から外す必要があります。VERITAS NetBackup は例外リストの機能を備えており、特定のファイルや ディレクトリをバックアップ対象から除外することができます。 いつバックアップするか いつバックアップするかを決める場合にも、ビジネスとシステムの両方の知識が必要になります。シ ステム管理者は、バックアップに奪われるリソースとバックアップエイジ（どれだけの時間のビジネ ス記録をバックアップ以外の手段によって復旧しなければならないか）とをうまくバランスさせなけ ればなりません。リソースを考慮しなければ、すべてのオンラインデータを絶えずバックアップする のがベストです。つまり、オブジェクトが変更されるごとに丸ごとバックアップすればよいわけです。 しかし、手持ちのリソースを考慮しないわけにはいきません。たえずバックアップするためには、CPU、 I/O、ネットワークにかなりのキャパシティが必要であり、ストレージやカタログのスペースも大量に 消費します。リソースの消費は、コストやオンラインアプリケーションのパフォーマンスにマイナス の影響を与えます。バックアップスケジュールを決める際には、オンラインアプリケーションへの影 響ができるだけ少なくなるように配慮しなければなりません。忙しいときと暇なときがはっきりして いる業種なら、暇なときにバックアップを実行します。しかし、e ビジネスの進展は、忙しいときと 暇なときのこうした明確なパターンはくずれつつあります。オンラインアプリケーションと共存でき るように、バックアップが使うリソースを少なくする手段を探る必要が高まっています。 Page 56 VERITAS Data Availability Solution www.veritas.com/jp いつバックアップするか 「いつバックアップするか」は一見簡単な問いのように思えます。データソースはバックアップクラ イアントであり、データの宛先は（場合によっては複数の）メディアサーバです。どのメディアサー バを選ぶかは、ビジネスサイクルや機器の使用状況などによって異なってきます。マスターサーバは 各クライアントでのバックアップジョブを監視し、テープローディングの条件やバックアップデバイ スの空き状態に基づいてバックアップデータを受け入れるメディアサーバを選びます。 メディアサーバはシステム管理者が定めたポリシーのガイドラインに基づいて特定のバックアップデ バイス（例えばテープドライブ）を選びます。システム管理者はバックアップデバイスをグループに 分けて、スケジュールされた各バックアップジョブを特定のグループに関連付けることができます。 メディアサーバはグループの中から空いているデバイスを選択します。 メディア（テープや光ディスク）の取り扱いについても同様であり、使用可能なメディアはプールに まとめられ、スケジュールされた各バックアップジョブが特定のプールに関連付けられます。バック アップマネージャは一定のアルゴリズムに従って、プールの中から空いているメディアを選択します。 このアルゴリズムはメディアの使用頻度（摩耗度）を均等にするようにデザインされています。メデ ィアマネージャはメディアのクリーニングと交換のスケジュールを管理し、メディアの保管場所の記 録も行います。 バックアップクラス NetBackup はバックアップポリシーのパラメータ（適切なメディアサーバ、メディアタイプ、デバイス グループ、ファイルリスト/ディレクトリリスト、スケジュール情報など）をまとめ、バックアップク ラスを作成します。バックアップクラスにはこのほか、データオブジェクトの名前付きの集合やバッ クアップクライアントの名前付きの集合、あるいはバックアップクラスの一定の属性（例えば他のク ラスと比較した場合の優先度）も含まれています。マスターサーバは、システムのバックアップクラ スを管理し、バックアップクライアントやメディアサーバと協力して、スケジュールされたバックア ップを実行、監視します。 フルバックアップとインクリメンタルバックアップ 通常の e ビジネス環境では、前回のバックアップと次回のバックアップとの間に変更されるオンライ ンデータは全体のごく一部です。ファイル中心型のシステムの場合、ごく一部のファイルだけが変更 されます。インクリメンタルバックアップとは、この事実を利用して、バックアップに要するリソー スを最小限に抑えるテクノロジです。インクリメンタルバックアップでは、前回のバックアップ以降 に変更があったデータオブジェクトだけをコピーします。バックアップエージェントがファイルシス テムのメタデータを調べ、変更されたオブジェクトを見つけて、コピーします。図 32 はフルバックア ップとインクリメンタルバックアップの相違を示しています。 www.veritas.com/jp VERITAS Data Availability Solution Page 57 アプリケーションの更新 ファイルＢ ファイルＨ ファイルシステム ファイルシステム ファイル A ファイル A ファイルＢ ファイルＢ ファイルＢ ファイル A ファイルＨ ファイルＢ ファイルＣ ファイルＣ ファイルＤ ファイルＤ ファイルＥ ファイルＥ ファイルＦ ファイルＦ ファイルＧ ファイルＧ ファイルＨ ファイルＨ ファイルＣ ファイルＤ ファイルＥ ファイルＦ ファイルＧ ファイルＨ バックアップコピーには 前回のバックアップ以降 に変更されたファイル だけが入る ファイルＩ ファイルＩ ファイルＪ ファイルＪ ファイルＩ ファイルＪ フルバックアップ（ベースライン） インクリメンタルバックアップ（ベースラインの変更分） 図 32 フルバックアップとインクリメンタルバックアップ インクリメンタルバックアップはフルバックアップを補完するものであり、フルバックアップの代替 にはなりません。インクリメンタルバックアップに入っているのは、前回のフルバックアップ以降に 変更のあったオブジェクトだけです。インクリメンタルバックアップからファイルシステム全体を復 旧するには、ベースラインとして最初にフルバックアップが復旧されていなければなりません。その うえで、インクリメンタルバックアップが順に復旧され、ベースライン中の変更されたファイルを上 書きします。インクリメンタルバックアップを利用すれば、時間のかかるフルバックアップの回数を 減らすことができまます。 大きなファイルシステム内の少数のファイルだけが前回のバックアップ以降に変更されているような 場合、バックアップを必要とするのはごく限られた割合のデータだけです。インクリメンタルバック アップはフルバックアップよりもずっと高速であり、オンラインの稼働に与える影響もわずかですみ ます。 インクリメンタルバックアップがポリシーに組み入れられている場合、マスターサーバはフルバック アップとインクリメンタルバックアップの順番を記録します。個々のファイルを復旧するときには、 マスターサーバは最新のバックアップコピーを探します。ファイルシステム全体を復旧するときには、 マスターサーバは復旧に必要なテープをどの順番にマウントすればよいかを指示します。 インクリメンタルバックアップの影響 マスターサーバが管理しているオンラインカタログには、バックアップされたファイルの各バージョ ンとそれぞれの格納場所がリストされています。したがって、個々のファイルの復旧については、イ ンクリメンタルバックアップを使用するかどうかにかかわらず作業内容は同じであり、該当のファイ ルを収納しているテープを見つけてロードし、ファイルをコピーするだけです。 Page 58 VERITAS Data Availability Solution www.veritas.com/jp 最後に復旧された最新の インクリメンタルバックアップ ファイル A ファイルＢ ファイルＣ ファイルＤ ファイルＥ ファイルＦ ファイルＧ ファイルＨ ファイルＩ ファイルＪ ファイル E ファイルＪ インクリメンタルバックアップの 復旧の基準 ファイル A ファイルＦ ファイルシステム ステップ ¬ ファイル A ファイルＢ ファイルＣ ファイルＤ 最新の完全 バックアップ バックアップから作成可能な 最新のデータ ファイルシステム ファイル A ファイルＣ ファイルＪ ファイルＢ ステップ - ファイルＣ 結果 ファイルＤ ファイルＥ ファイルＥ ファイルＦ ファイルＦ ファイルＧ ファイルＧ ファイルＨ ファイルＨ ファイルＩ ファイルＩ ファイルＪ 最初に復旧された最も古い インクリメンタルバックアップ すべてのイン クリメンタル バックアップ が復旧された 場合、ファイ ル J に対する 最新の更新デ ータはオンラ インとなる。 ファイルＪ 図 33 フルバックアップおよびインクリメンタルバックアップによるファイルシステムの復旧 インクリメンタルバックアップからファイルシステム全体を復旧するとなると、作業はもっと複雑で す。まずベースラインのフルバックアップを復旧し、続いてそのフルバックアップ以降のすべてのイ ンクリメンタルバックアップを（古い順に）復旧することが必要となります。このプロセスには人間 による意思決定やメディアの取り扱いが関与せざるをえません。図 33 は、フルバックアップとインク リメンタルバックアップからファイルシステムを復旧する手順を示しています 一般にフルバックアップは比較的間隔を置いて（例えば週に一度）、それほど忙しくないとき（例えば 週末）に実行され、インクリメンタルバックアップは頻繁に（例えば毎日）実行されます。こうすれ ば、毎日コピーするデータはほんの少しになり、 （フルバックアップに比べて）オンラインの実働に対 する影響も小さくなります。この反面、復旧に要する時間は長くなり、メディアの出し入れも煩雑に なりますが、いずれにしても復旧すべきインクリメンタルバックアップは 1 週間分だけです。 インクリメンタルバックアップの種類 インクリメンタルバックアップには 2 つの種類があります。差分バックアップでは、前回のバックア ップ（フルかインクリメンタルかを問いません）以降に変更されたファイルがすべてコピーされます。 したがって、週に一度フルバックアップを実行し、毎日差分バックアップを実行している場合、ファ イルシステムを最新の状態に復旧するには、最新のフルバックアップを復旧し、さらに各差分バック アップを古い順にすべて復旧しなければなりません。週の終わりに近づけば近づくほど、復旧の作業 が長くなります。 累積バックアップでは、前回のフルバックアップ以降に変更されたファイルがすべてコピーされます。 したがって、累積バックアップからファイルシステム全体を復旧するには、最新のフルバックアップ と最新の累積バックアップを復旧するだけですみます。しかし、復旧の作業が手軽である反面、前回 のフルバックアップから長い時間が経過しているとその分だけバックアップに要する時間が長くなり ます。 www.veritas.com/jp VERITAS Data Availability Solution Page 59 どちらの復旧も最新の フルバックアップを 復旧することから始める ファイル A ファイルＢ File C ファイルＥ File D ファイルＪ File E File F ファイル A File G ファイルＦ File H File I ファイルＣ File J ファイル A ファイルＢ File C ファイルＥ Fileファイル D A File E ファイルＦ File F ファイルＣ File G ファイルＪ File H File I File J ファイルシステム ファイル A ファイルＢ ファイルＪ ファイルシステム ファイル A ファイルＢ ファイルＣ ファイルＣ ファイルＤ ファイルＤ ファイルＥ ファイルＥ ファイルＦ ファイルＦ 最新の累積 バックアップ ファイルＧ ファイルＧ ファイルＨ ファイルＨ ファイルＩ ファイルＩ ファイルＪ ファイルＪ 同じファイルシステムが復旧する 前回のフルバックアップ以降に作成さ れたすべての差分バックアップ 図 34 差分バックアップと累積バックアップからファイルシステムを復旧する フル、累積、差分のバックアップを組み合わせれば、バックアップが通常の稼働に与える影響とファ イルシステムまたはデータベースを復旧するのに要する時間をうまくバランスさせることができます。 表 3 は、フル、累積、差分のバックアップを組み合わせてバックアップに要する時間と復旧に要する 時間をバランスさせるやり方の一例を示しています。 日曜日 月曜日 火曜日 水曜日 木曜日 金曜日 土曜日 バックアッ フルバック 差分 差分 累積 差分 差分 差分 プの種類 アップ インクリメ インクリメ インクリメ インクリメ インクリメ インクリメ ンタル ンタル ンタル ンタル ンタル ンタル バックアッ 日曜日の時 日曜日のフ 月曜日のバ 日曜日のフ 水曜日のバ 木曜日のバ 金曜日のバ プコピー内 点のデータ ルバックア ックアップ ルバックア ックアップ ックアップ ックアップ のデータ ベース全体 ップ以降に 以降に変更 ップ以降に 以降に変更 以降に変更 以降に変更 変更された されたファ 変更された されたファ されたファ されたファ ファイル イル ファイル イル イル イル データベー 日曜日のバ 日曜日のバ 日曜日のバ 日曜日のバ 日曜日のバ 日曜日のバ 日曜日のバ ス全体を復 ックアップ ックアップ ックアップ ックアップ ックアップ、 ックアップ、 ックアップ、 旧する手順 を復旧する と月曜日の と月/ 火曜日 と水曜日の 水曜日の累 水曜日の累 水曜日の累 差分を復旧 の差分を復 累積を復旧 積、木曜日の 積、木 /金曜 積、木/金/土 する 旧する する バックアッ 日の差分を 曜日の差分 プを復旧す 復旧する を復旧する る 表 3 週間バックアップスケジュールのサンプル NetBackup は表 3 のようなバックアップスケジュールを自動的に作成します。ロボット型のテープライ ブラリを利用すれば、スケジュールされたバックアップを自動的に実行できます。バックアップポリ シーさえ設定すれば、あとはシステム管理者やオペレータの手をわずらわせることはありません。 バックアップとデータベース 一般に、Oracle 等のデータベース管理システムでは、一定の時点でデータベースをバックアップする 機能が組み込まれます。この機能の詳細は製品ごとに異なりますが、その効果は先述のファイルシス テムのスナップショット機能に似ています。バックアップを開始するときには、データベースの活動 Page 60 VERITAS Data Availability Solution www.veritas.com/jp は瞬間的に停止します。バックアップが始まると、データベースオブジェクトが変更されるたびに、 そのオブジェクトの古い内容が保存されます。バックアッププログラムがデータを読み出すときには、 このようにして保存された変更前イメージが返されます（他のプログラムがデータを読み出すときに は、オブジェクトの現在の内容が返されます）。 このようにして作成したバックアップには、バックアップ開始時のデータベースの内容が入っていま す。このテクニックはホットデータベースバックアップと呼ばれ、広く使われています。VERITAS Database Edition for Oracle は NetBackup のスケジューリング機能をデータベース管理システムと組み合 わせており、ホットデータベースバックアップの開始時にはデータベースの活動は一時的に停止しま す。しかし、データベースをコピーし、データベースオブジェクトの変更前イメージを保存しなけれ ばならないため、データベース上での I/O 活動は増加します。 NetBackup は、ストレージチェックポイントという Database Edition for Oracle の一機能を使い、オーバ ヘッドをほとんどかけずに、オンラインデータベースの一定時点のバックアップを実行します。スト レージチェックポイントは先述したファイルシステムのスナップショットとよく似た機能です。スト レージチェックポイントは、データベースを格納しているファイルシステムの一定時点のイメージか ら構成されます。ストレージチェックポイントは前述のスナップショットと同様に書込み時コピー （copy on write）を使用して、ストレージのスペースを節約しています。ストレージチェックポイント は以下の 3 つの点でスナップショットと異なります。 è ストレージチェックポイントは永続的です（システムを再起動しても消滅しません）。 è ストレージチェックポイントはファイルシステムの空きスペースプールを使います。 è ストレージチェックポイントは NetBackup と連携し、BLIB（Block Level Incremental Backup)を実 現します。 メインの データベースイメージ テーブルスペース A ストレージチェックポイント アプリケーション 更新 テーブルスペースＢ 変更ブロックのマップ 更新データの「変更前イメージ」 変更されたブロックの 「変更前イメージ」 テーブルスペースＣ 同じファイル システム 図 35 ストレージチェックポイント スナップショットと同様にストレージチェックポイントも、データベースが静止状態で、ディスクイ メージの整合性が保たれている瞬間に開始しなければなりません。つまり、トランザクションが進行 しておらず、キャッシュされたデータがディスク上のデータを正確に反映している瞬間に開始しなけ ればなりません。VERITAS Database Edition for Oracle は Oracle とやり取りして、ストレージチェック ポイントの整合性を保証します。ストレージチェックポイントの作成は、まず Oracle へ「データベー スを一時的にシャットダウンしてくれ」と要求することから始めます。Oracle から「データベースが 静止状態になった」というメッセージが届いたら、ストレージチェックポイントを開始します。スト レージチェックポイントを開始したあとで（これは数秒かかります） 、Oracle にデータベースの再開を www.veritas.com/jp VERITAS Data Availability Solution Page 61 要求し、データベースをアプリケーションが使用できる状態に戻します。 ストレージチェックポイントが当初に必要とするストレージスペースは、データベースを格納してい るファイルシステムの変更ブロックのマップを収めるに必要なだけであり、ごくわずかです。アプリ ケーションからデータベースへの書込みがあると、ストレージチェックポイントにブロックが割り当 てられ、更新されたブロックの変更前イメージがストレージチェックポイントにコピーされて、変更 ブロックのマップが更新されます。 ストレージチェックポイントのおかげで、データベース用のバックアップウィンドウは必要なくなり ます。フルバックアップもインクリメンタルバックアップも、ストレージチェックポイントから実行 できます。また、NetBackup は、データベースアプリケーションとは異なるファイルシステムオブジェ クト（ストレージチェックポイント）からデータを読み出すため、データベースの読み書きのオーバ ヘッドが少なくなります。 ストレージチェック ポイント T1 変更ブロックのマップ メインの データベースイメージ T1 以降に変更された ブロックの 「変更前イメージ」 テーブルスペース A ストレージチェック ポイント T2 テーブルスペースＢ アプリケーション 更新 変更ブロックのマップ 更新データの 「変更前イメージ」 T1 T2 T3 T2 以降に変更された ブロックの 「変更前イメージ」 テーブルスペースＣ ストレージチェック ポイント T3 変更ブロックのマップ データベースは T1、T2、または T3 として バックアップできる。 T3 以降に変更された ブロックの 「変更前イメージ」 データベースは T1、T2、または T3 の 状態にロールバックできる 図 36 複数のチェックポイントとデータベースのロールバック 図 36 に示すように、VERITAS File System では同時に複数のチェックポイントを格納できます。スト レージチェックポイントはそれぞれストレージのスペースを必要とし、 （データ更新時には）I/O のリ ソースも消費します。しかし、複数のチェックポイントが用意されていれば、システム管理者はいろ いろな時点のバックアップを選択できます。VERITAS Database Edition for Oracle には、変更ブロックの 変更前イメージをストレージチェックポイントからメインデータベースへ書き戻すユーティリティス トレージロールバック（Storage Rollback）が用意されています。このユーティリティはデータベース 全体、個々のテーブルスペース、個々のファイルのいずれに対しても実行できます。このユーティリ ティを使えば、データベースやテーブルスペースをストレージチェックポイント作成時の状態に「ロ ールバック」（リカバリ）することができます。例えば、データベースアプリケーションをある程度の 期間使っていて、あとでエラーが見つかったような場合、これが役に立ちます。 ストレージチェックポイントはファイルシステムの空きスペースを使うため、複数のチェックポイン トは予期しないスペース割り当てエラーを引き起こすことがあります。これを防止するために、スペ ースの都合上やむをえない場合にはファイルシステムはストレージチェックポイントを削除します。 あるいは、ファイルシステムの空きスペースが一定のレベル以下になったときにスクリプトを実行す Page 62 VERITAS Data Availability Solution www.veritas.com/jp るようにして、問題を回避することもできます。スクリプトには、ファイルシステム（およびその土 台であるボリューム）の拡大、必要なくなったストレージチェックポイントの削除など、いろいろな 回避策を記述しておきます。 BLIB（Block Level Incremental Backup：ブロックレベル・インクリメンタル・バックアップ） 差分バックアップや累積バックアップはファイル中心型のシステムでは非常に役に立ちますが、デー タベースとの相性はあまりよくありません。データベースは一般にサイズの大きい少数のファイルに 格納されたテーブルからなり、テーブルは頻繁に更新されます。したがって、変更されたデータをフ ァイル単位でコピーするインクリメンタルバックアップでは、データベースのテーブルスペースがす べてコピーされてしまいます（このテーブルの大部分が前回のバックアップからまったく変わってい ない場合でも同様です） 。 ファイルシステム テーブルスペース A テーブルスペース A テーブルスペース B テーブルスペース B アプリケーション更新 テーブルスペースＣ インクリメンタルバックアップで は、テーブル内のデータが一部で も変更されていると、テーブルス ペース全体がコピーされてしまう テーブルスペースＣ 図 37 データベースにおけるインクリメンタルバックアップの問題 しかし、ストレージチェックポイントの変更ブロックマップは、チェックポイント作成時以降に変更 されたデータベースブロックを識別します。NetBackup は変更ブロックマップ内の情報を利用して、ブ ロックレベルでのインクリメンタルバックアップ BLIB（Block Level Incremental Backup）を実行するこ とができます。図 38 は BLIB を示しています。 ストレージチェック ポイント バックアップすべきブロックは 変更ブロックマップによって 判別される 変更ブロックの マップ 変更されたブロックの 「変更前イメージ」 メインデータベース イメージ テーブルスペース A 更新されたデータの 「変更前イメージ」 アプリケーション 更新 変更ブロック テーブルスペースＢ テーブルスペースＣ NetBackup の BLIB バックアップ用のデータは（ストレージ チェックポイントからではなく） データベースイメージから読み出される Agent 図 38 ストレージチェックポイントを使った整合性のあるデータベースバックアップ www.veritas.com/jp VERITAS Data Availability Solution Page 63 BLIB では、ストレージチェックポイント作成以降に変更されたデータベースブロックだけがバックア ップされます。バックアップの対象がデータベースのごく一部なら、BLIB のイメージも小さいものに なります。データベースを丸ごとバックアップするのに比べれば、BLIB は短時間で完了し、ストレー ジのスペースや I/O 用の帯域幅もあまり使いません。 他の種類のインクリメンタルバックアップと同様、BLIB もフルバックアップを補完するものです。 BLIB からデータベースを復旧するには、インクリメンタルバックアップのベースとなっているストレ ージチェックポイントから実行したフルバックアップが必要です。 BLIB のメリットは、個々のバックアップの作業負荷が低いため、頻繁なバックアップを可能にします。 BLIB を頻繁に実行すれば、バックアップに要するリソース（帯域幅とストレージのキャパシティ）も 少なくなり、障害発生時により近い時点の状態にデータベースを復旧できます。 ファイルシステムのインクリメンタルバックアップの場合と同様、BLIB でもリソースが少なくてすむ 反面、その分だけ復旧に手間がかかります。NetBackup のマスターサーバは BLIB を記録しており、復 旧の手順を提示してくれます。 バックアップ・ストラテジー バックアップの多重化 図 31 に示したような分散環境では、以下の要因がバックアップの速度に影響します。 è クライアントの負荷 アプリケーションサーバが他のタスクでビジーのときは、バックアップクライアントのソフトウ ェアがデータに高速にアクセスできず、バックアップのデータパスに空きが出てしまいます。 è ネットワークの負荷 ネットワークがアプリケーションのトラフィックでビジーのときは、バックアップクライアント がデータを高速に転送できず、バックアップサーバやテープドライブが待ち状態になります。 è バックアップサーバの負荷 バックアップサーバが数多くのバックアップジョブ（あるいはバックアップサーバがアプリケー ションサーバを兼ねている場合には他のジョブ）で過負荷になっているときは、テープドライブ のストリーミングがとぎれます。 è テープドライブのデータ転送速度 データが高速に供給されず、テープドライブのストリーミング（テープが回転しデータを書き込 んでいる状態）がとぎれると、ドライブのパフォーマンスは著しく低下します。データストリー ムのちょっとした中断によってテープドライブの位置調整が発生し、データの流れがかなり長い 間中断されることがあります。 メディアを効率的に使用することも重要です。ハイエンドのテープカートリッジはディスクの 2 倍か ら 4 倍の容量を持っています。ビジネス上の理由からインクリメンタルバックアップを頻繁に実行す るようなポリシーを採用した場合、小さいサイズのバックアップデータセットが数多く作成されるこ とがあります。小さいバックアップデータセットはテープの全容量のほんのちょっとしか使いません。 これはメディアの無駄づかいです。また、メディアライブラリが肥大化し、管理のコストがかかるう え、取り扱いのミスも増えてきます。 バックアップのデータパス上の各局面でパフォーマンスに段差があるとバックアップの速度に悪い影 Page 64 VERITAS Data Availability Solution www.veritas.com/jp 響が出ますが、NetBackup はこうした影響を最小限に抑えます。中でも効果が大きいのは多重化、つま り複数のバックアップジョブからのデータブロックを単一のテープ上でインターリーブすることです。 最大 32 のバックアップジョブが単一のメディアを共有できます。クライアントデータの転送の遅れ、 ネットワークの混雑、 （ネットワークとテープドライブの間の）速度の相違などの影響はこれによって ある程度補正されます。複数のバックアップストリームをインターリーブする場合、各ストリームの ブロックにはジョブ ID のタグが付き、バックアップサーバに到着した順にテープに書き込まれます。 バックアップサーバに到着するデータが増えると、テープのストリーミングが活発になり、システム 全体としてバックアップのスループットが向上します。複数のジョブからのデータが同一のテープに 送られるため、メディアの利用効率もアップします。インターリーブされたバックアップジョブから ファイルやファイルシステムを復旧するときには、テープから読み出されたブロックをバックアップ エンジンが透過的にフィルタします。バックアップがインターリーブされていることは、ユーザやア プリケーションには意識されません。 並列バックアップストリーム 高いパフォーマンスのネットワークとボリュームを備えたシステムでは、複数のテープへの並列的な 書込みによって大きなバックアップジョブの速度をアップすることができます。これが効果を発揮す るのは、例えば大規模なデータベースのフルバックアップをストレージスナップショットから実行す るような場合です。各バックアップジョブはそれぞれ一度に 1 個のファイルを処理します。しかし、 データベーススナップショットのコンテナファイルがそれぞれ別個のファイルリストに分割され、バ ックアップジョブを同時に実行するようにスケジュールされていれば、複数のネットワーク回線を使 って複数のバックアップストリームを同時にアクティブにすることができます。この場合、クライア ント、ネットワーク、サーバ、テープドライブのそれぞれの速度を考慮し、並列ジョブを複数のテー プドライブに送るか、または単一のテープで多重化するかどちらかの方法をとります。 バックアップのその他の形態 VERITAS File System 及び VERITAS Volume Manager では、基本となるのはストレージチェックポイン トを利用するバックアップですが、データベースの通常の稼働を中断しないバックアップの方法がこ のほかにも 2 つあります。 è 前述しましたように VERITAS File System のスナップショットをソースとして整合性のあるデー タベースバックアップを実行することもできます。このためには、任意のバックアッププログラム を使って、データベースが静止状態のときに作成された VERITAS File System のスナップショット をバックアップします。この方法の利点は最小限の I/O リソースしか使わないことであり、スケジ ュールにない臨時のバックアップが必要になったときや、なんらかの理由でストレージチェックポ イントをベースとするバックアップを実行できないときに役に立ちます。スナップショットはシス テムを再起動すると消滅するため、バックアップ中にシステムがクラッシュしたときには、最初か らやり直さなければなりません。 è ミラーリングされたボリュームはスナップショットとみなすことができ、データベースが静止状 態のときにミラーコピーの 1 つをボリュームから切り離すことができます。スナップショットの場 合と同様、切り離されたミラーコピーをマウントすれば、任意のバックアッププログラムでバック アップできます。ボリュームのスナップショットは大量のディスク容量を必要としますが、ディス クの障害に対応するにはこの方法しかありません。そのうえ、VERITAS Volume Manager によるボ リュームのミラーリングでは、同一のデータコピーを 3 つ以上作成できます。したがって、ディス www.veritas.com/jp VERITAS Data Availability Solution Page 65 ク障害に対してオンラインデータを保護しながら、別のコピーを使ってバックアップを実行できま す。 アーカイブ e ビジネスが成熟するにつれて、ビジネスを記録したデータも増加します。月次レポート、四半期レ ポート、年次レポート、売上、製造、出荷、サービスの記録など、大量のデータを保存しなければな りません。この種の過去のデータは一般にオンラインにしておく必要はありません。NetBackup を使え ば、こうしたデータをアーカイブに保存できます。アーカイブは機能的にはバックアップと同じであ り、指定したデータオブジェクトをスケジュールに従ってバックアップメディアにコピーし、あとで 必要なときに参照できるようにカタログ化しておきます。アーカイブとバックアップとの相違は、ア ーカイブではジョブ（システム管理者によって指示されている場合には、アーカイブされたコピーを 読み出して整合性を検査することも含む）の完了後、オンラインのファイルが削除され、そのファイ ルが使っていたスペースが解放されることです。 データベース ファイルシステム バックアップ テーブルスペース A テーブルスペース A テーブルスペースＢ テーブルスペースＢ 使用中のデータディレクトリ バックアップコピー作成後も データはオンラインに残る 月末アーカイブ バックアップ テーブルスペースＣ テーブルスペース D (毎月の最新情報) テーブルスペースＣ レポートファイル 月末のデータディレクトリ アーカイブコピーを作成した あとオンラインスペースは 翌月のデータ用となる テーブルスペース D （毎月の最新情報） アーカイブ レポートファイル 図 39 アーカイブとバックアップ 図 39 に示すファイルシステムでは、オンラインデータベースのテーブルスペースが 1 つのディレクト リに格納され、毎月の最新情報とレポートが別のディレクトリに格納されています。オンラインデー タベースのディレクトリは、先に説明したやり方によって定期的にバックアップされています。月々 の最新情報とレポートは一定期間オンラインにアップし、あとは記録としてオフラインで保存します。 したがって、毎月の最新情報が入っているディレクトリは定期的にアーカイブされます。このディレ クトリに入っているファイルはアーカイブメディアに書き込まれたあとで削除され、（翌月の）新しい データのためにスペースを解放します。ロボット型のメディアライブラリを使っている場合は、アー カイブの作業はすべて自動化され、特別な状況が発生しない限り、システム管理者やオペレータが介 在する必要はありません。 アーカイブとバックアップのもう 1 つの相違は、前者には有効期限がないことです。NetBackup が作成 するバックアップコピーにはデフォルトで有効期限が設定されています。有効期限を過ぎると、コピ ーは価値のないものとみなされ、そのコピーを格納しているメディアを他の目的に使用できるように なります。これに対し、アーカイブは長期のビジネス記録とみなされ、有効期限は設定されません。 Page 66 VERITAS Data Availability Solution www.veritas.com/jp ストレージリソースを効率的に使う：ストレージの階層管理 e ビジネス用のある種のオンラインデータは時間の経過とともにだんだんとアクセスされなくなりま す。売上記録、サービス記録、廃止になった製品の仕様、社員の記録などは自然に古くなります。e ビ ジネス用のデータの多くにはいわば寿命があり、一定の期間を過ぎればオンラインに残しておく意味 がなくなります。しかし、経営管理の面からはこうしたデータも価値を持っており、長く（多くの場 合何年も）保存しておかなければなりません。 めったにアクセスしないデータオブジェクトをオンラインに残しておくのは、パフォーマンスにも影 響します。データベースが古いレコードで肥大化すると、ディスクアクセスや検索にかかる時間が長 くなります。要するにパフォーマンスが不必要に低下するわけです。めったにアクセスしないデータ オブジェクトを別のボリュームに移動するか、あるいはオフラインにしておけば、オンラインのパフ ォーマンスは向上します。 バックアップの場合と同様、めったにアクセスしないデータオブジェクトを低コストのニアラインま たはオフラインのストレージに移すのは、理論的には簡単なのですが、細部ではいろいろな問題があ ります。さまざまな種類の数多くのデータオブジェクトがあちこちに散在していると、系統的なデー タマイグレーションは人間の手ではほとんど不可能になります。したがって、ポリシーをベースとし て、アクティブなオンラインストレージから低コストで非アクティブなストレージ（テープや光ディ スク）に透過的にデータオブジェクトをマイグレーションする自動的な手段が必要になります。 VERITAS の階層ストレージ管理テクノロジ：Storage Migrator VERITAS Storage Migrator は、ポリシーをベースとして非アクティブなデータオブジェクトをマイグレ ーションするためのツールです。階層ストレージ管理（HSM：Hierarchical Storage Management）の土 台となっているのは、いろいろなストレージメディアをコストやパフォーマンスの階層としてとらえ るアプローチです。コストをかければ、その分だけ大きな帯域幅で（より短い待ち時間で）データに アクセスするストレージを入手できます。図 40 の左側は、こうしたコストパフォーマンスをベースと したストレージテクノロジの階層を示しています。階層の頂点にあるのはソリッドステートメモリの テクノロジです。ソリッドステートメモリは非常に高価ですが、ほとんど瞬時のうちにデータにアク セスします。階層を下るにつれて、ビット当たりのコストは低下しますが、その分だけアクセスとデ ータ転送は遅くなります。 待ち時間の減少 帯域幅の増加 DRAM ソリッドステート メモリ 磁気ディスク 高速レスポンス アクティブなデータ コストの増加 高帯域幅 最近のデータ 光ディスク ニアライン/オフラインの アーカイブ ストレージテクノロジの階層 ストレージアプリケーションの階層 アクセス可能性の 増加 図 40 ストレージの階層 図 40 の右側に示されているストレージアプリケーションの階層は、階層ストレージ管理に対するもう 1 つの面からのアプローチを表しています。e ビジネスを開始してからある程度時間が経つと、データ に次のような区別が現れてきます。 è アクティブなデータ 毎日の業務で頻繁にアクセスするデータ。 www.veritas.com/jp VERITAS Data Availability Solution Page 67 è 最近のデータ それほど頻繁にはアクセスしないが、オンラインにしておいたほうがよいデータ。 è アーカイブのデータ 保存しておく必要があるが、特別な場合にしかアクセスしないデータ。 場合によっては、ストレージアプリケーションの階層をビジネスのニーズに応じてさらに細かく分割 したほうが好都合なこともあります。例えば、個別の請求金額のデータなどは、光ディスクに格納し ておき、顧客からの問い合わせがあったときにランダムにアクセスできるようにしておくと便利です。 これに対し、売上記録のようにデータマイニングの際に一括してアクセスするデータはテープに格納 しておきます。 以上のように、階層ストレージ管理は e ビジネスに必要なストレージのコストを削減するするのに役 立つだけでなく、データオブジェクトを用途に応じて区別して、アクセスのパフォーマンスを改善す るうえでも効果があります。 VERITAS Storage Migrator は、幅広いストレージテクノロジをサポートし、e ビジネスで必要になる各 種のストレージ状況に対応しています。ディスクファイル、バルクの磁気ディスク、各種の磁気テー プ、光ディスク、ftp を通じたリモートサイトなどがすべてマイグレーション対象となるストレージク ラスとしてサポートされています。Storage Migrator は光ディスク、テープドライブ、メディアプール をバックアップと共有することができます。このため、デバイスの 1 セット、メディアプールの 1 セ ット、管理ポリシーと手順の 1 セットでバックアップと HSM（階層ストレージ管理）の両方のニーズ を満たすことができます。 Storage Migrator による HSM のルック&フィール VERITAS Storage Migrator は管理されたファイルシステムとの間でデータオブジェクトのマイグレー ションを行います。マイグレーションがバックアップやアーカイブと異なるのは、ユーザには意識さ れないことです。マイグレーションされたファイルはそれぞれのオリジナルのディレクトリに呼び出 されます。アプリケーションがマイグレーションされたファイルにアクセスすると、VERITAS Storage Migrator はそのファイルをマイグレーション先の場所からオリジナル（ホーム）ファイルシステムに移 動することによってキャッシュします。ユーザはファイルへのアクセスがちょっと遅いと感じるかも しれませんが、コンソールコマンドや API はファイルが最初からオンラインであるかのように動作し ます。キャッシュされたファイルにユーザまたはアプリケーションがアクセスすると、そのファイル はマイグレーションされていない状態になり、再びホームファイルシステムのマイグレーションポリ シーの適用対象となります。一定期間アクセスのないキャッシュされたファイルは、再度ホームファ イルシステムからマイグレーションされるか、または（ファイルが変更されていなければ）削除され ます。 ファイルのマイグレーションは 2 つの段階で行われます。 è マイグレーションの基準を満たしているファイル（一定期間アクセスがないファイル）について は、Storage Migrator はホームディレクトリからプレマイグレーションディレクトリに論理的に移 動し、ワークリストに追加して、特定の Storage Migrator ボリュームサーバにコピーできるように します。ファイルはマイグレーション先の場所にコピーされますが、ホームファイルシステムの 空きスペースが一定のレベル以下になるまでは元の場所から削除されずオンラインにとどまりま す。 è ホームファイルシステムの空きスペースが一定のレベル以下になると（つまり、割り当て済みの スペースが喫水線を越えると） 、プレマイグレーションファイルはパージされ（元の場所から削除 Page 68 VERITAS Data Availability Solution www.veritas.com/jp され）、マイグレーション先の場所を間接的に示すディレクトリエントリだけが残されます。 以上でわかるように、マイグレーションされたファイルはそのスペースが別の用途に実際に使われる ようになるまでは、ホーム・ファイルシステムにとどまります（したがって、ファイルへのアクセス 速度はほとんど変わりません） 。アプリケーションがプレマイグレーションファイルにアクセスすると、 そのプレマイグレーションファイルは再度アクティブなファイルとなり、アクセスされない状態が一 定時間続くまでオンラインにとどまります。 Storage Migrator のポリシー Storage Migrator はマイグレーションポリシーをきめ細かく制御します。システム管理者は各ファイル システムについて以下のことを指定できます。 è Storage Migrator がファイルの開始/停止する空きスペースのレベル。管理されたファイルシステム の空きスペースが指定したレベル以下になると、Storage Migrator はプレマイグレーションファイ ルが占めていたスペースを解放し、十分な空きスペースができるまでファイルをマイグレーショ ンします。 è マイグレーション対象となるファイルを選択する基準 è パージの対象となるファイルを選択する基準 è ファイルのマイグレーション先の数、マイグレーションに使用するメディア、並行マイグレーシ ョン、マイグレーションしたファイルにアクセスする際に取り出すコピー。 è マイグレーションの階層、またはマイグレーションレベルの数。 システム管理者は一部のポリシーの決定をユーザに任せることができます。例えば以下のことをユー ザが指定できるようにします。 è プレマイグレーションファイル、マイグレーションを行うファイル、パージするファイル、マイ グレーションから除外するファイル。 è ファイルの依存関係（相互に依存するファイルはグループとして一緒にマイグレーションする） è キャッシュなしで読み出すマイグレーションされたファイル ファイルシステムのポリシーを個々のユーザによる制御と組み合わせることにより、ストレージのパ フォーマンスとリソースの使用を最適化しながら、いろいろな e ビジネスの多種多様なニーズに対応 できます。 部分キャッシングとスライス アプリケーションがマイグレーションされたファイルにアクセスしたときのレスポンスを速くするた めに、Storage Migrator は部分キャッシングをサポートしています。ファイルのかなりの部分が「マイ グレーションされていない状態」になり、キャッシュされたブロックによってアプリケーションの読 み出し要求が可能であれば、ファイル全体がキャッシュされていなくてもレスポンスが始まります。 多くのアプリケーション、特にデータ管理ユーティリティは数多くのファイルの最初の数バイトをチ ェックする動作が多いようです。マイグレーションされたファイルにとっては、これは好ましくない 動作です。マイグレーションされたファイルはディレクトリ内に表示されていますが、その内容はど こか別のところ（おそらくはオフライン）にあります。無意味なファイルのキャッシングを防ぎ、フ ァイルの開くときの最初のレスポンスを速くするために、Storage Migrator では、ファイルがマイグレ ーションされたときにホームファイルシステム内に残るそのファイルのスライスを定義できます。 www.veritas.com/jp VERITAS Data Availability Solution Page 69 HSM とデータベース HSM とバックアップの類似点はもう 1 つあります。一般にデータベースは頻繁にアクセスされる少数 のファイルからなるため、データベースのテーブルスペースを格納しているファイルを丸ごとマイグ レーションする方法はあまりよい方法ではありません。ユーザが開発したフィルタリング・アプリケ ーションを使って、データベースから古いデータのみをマイグレーションさせるほうがよいでしょう。 この種のアプリケーションは、テーブルから古い行を取り出して、ファイルにエクスポートします。 そしてこのファイルが HSM ポリシーの対象となります。 Page 70 VERITAS Data Availability Solution www.veritas.com/jp V. まとめ VERITAS 総合データストレージ管理 VERITAS ソリューションを選ぶ理由 この資料では、VERITAS トータル・データストレージ管理を構成する以下の 4 つのテクノロジを紹介 し、それぞれが e ビジネスデータベースのストレージ管理で果たしている役割を説明しました。 è 柔軟性と耐障害性を兼ね備えたなボリューム管理とエンタープライズクラスのファイルシステム からなる堅牢なファウンデーションテクノロジ è 分散 e ビジネスのニーズに対応したバックアップとメディア管理 è e ビジネスのオンラインデータを必要なときに必要なところに送るためのデータマイグレーショ ンとレプリケーションのツール è 機器、アプリケーション、サイトの障害時にもアプリケーションを自動的に継続するためのクラ スタリングテクノロジ VERITAS がエンタープライズクラスのデータ管理ソリューションを提供できる背景には次の 5 つの理 由があります。 è テクノロジにおけるリーダーシップ è 統合ソリューションの提供 è マルチプラットフォームのサポート è サポート、トレーニング、サービス è 実績 テクノロジにおけるリーダーシップ 1992 年に創設されて以来、VERITAS は企業向けの堅固なデータ管理テクノロジを最先端で開発してき ました。VERITAS Volume Manager と VERITAS File System が初めてリリースされたとき、OS のベンダ 以外からボリューム管理とファイルシステムのテクノロジを購入できることにユーザは驚きの声をあ げたものでした。VERITAS のテクノロジは次のような重要な利点を備えています。 è エクステントベースのアロケーション è オンラインでのボリューム拡張 è ファイルシステムのデフラグメンテーション（断片化の解消） è スナップショット è Quick I/O for Databases こうした利点のおかげで、VERITAS のテクノロジは単一ベンダによる従来型のソリューションを凌駕 し、UNIX データストレージ管理ソリューションとして最高であるとの定評を得ることができました。 バックアップに関しても、VERITAS のソリューションは BLIB（Block Level Incremental Backup）テク ノロジを通じて Oracle データベースを高速に（通常の稼働をほとんど中断することなく）バックアッ プすることができ、データベース向けのデータストレージ管理ソリューションとして最高位にランク されています。現在、VERITAS はクラスタとストレージレプリケーションという新しい領域に挑戦し ており、すでにユーザの支持を得ています。 www.veritas.com/jp VERITAS Data Availability Solution Page 71 データストレージ管理テクノロジのリーダーとして、VERITAS は将来のアーキテクチャの標準化のた めに積極的に活動しています。主として Storage Networking Industry Association を通じ、VERITAS は、 SAN の管理、バックアップの効率化、 （SAN 管理に向けた）ファイルシステムの強化、インテリジェ ントなストレージデバイスの使用と管理など、様々な分野でオープンテクノロジの確立のために尽力 しています。VERITAS は、先進のテクノロジをいち早く取込み、新しいデータストレージ管理ソリュ ーションを他社に先がけて提供します。 統合ソリューションの提供 e ビジネス用のデータストレージ管理にとって VERITAS がベストである第二の理由は、総合的なソリ ューションを提供していることです。 è VERITAS Volume Manager と VERITAS File System は相互に連携して、オンラインでの拡張とデフ ラグメンテーション、スナップショット、データベースへの高速アクセスを実現します。 è レプリケーションテクノロジはファイルシステムやボリュームマネージャと連携して、高度に統 合された読取り専用のリモートデータコピーを作成します。 è クラスタエージェントは上述のテクノロジをファイルシステム、ボリューム管理、バックアップ のテクノロジと結合します。 VERITAS は、個々の製品開発、新しい製品への積極的な取込みに加えて、ユーザの環境をトータルに 支援する、データストレージ管理ソリューションを提供していきます。 マルチプラットフォームのサポート エンド・ツー・エンドのデータストレージ管理ソリューションとして VERITAS テクノロジを選択する 第三の理由は、主要なプラットフォームの幅広いサポートです。 VERITAS の基本テクノロジ、あるいはデータ管理や可用性のテクノロジは、主要な UNIX システムと Windows NT で利用できます。ビジネスの拡大に伴って Windows NT から UNIX へのマイグレーション が必要になっても、VERITAS のデータストレージ管理ツールとテクニックはこれまでと同じように使 用できます。ビジネスが進展すれば、おそらく複数のコンピューティングプラットフォームが混在す る環境が一般的になるでしょう。VERITAS の総合データストレージ管理はどのコンピューティングプ ラットフォームでも通用するソリューションであり、スキルと知識という最も貴重な IT 資産をビジネ スのすべての場面で活用できます。プラットフォームが増えても、管理機能を追加する必要はありま せん。 サポート、トレーニング、サービス VERITAS テクノロジを選択する第四の理由は、ユーザに対するサポートとサービスの幅広いネットワ ークが用意されており、トレーニングのプログラムが充実していることです。VERITAS のテクノロジ と製品がターゲットとしているのは、一筋縄ではいかないいろいろな困難な問題です。回答はすぐに 見つかるとは限りません。VERITAS のトレーニングを通じて、ユーザは複雑な製品の機能を理解し、 e ビジネスに向けた IT ソリューションを自分で構築できるようになります。e ビジネスの情報サービ スを計画し、設計し、実施する際には、VERITAS のコンサルティングサービスが役に立ちます。 実績 データストレージ管理のソリューションとして VERITAS テクノロジを選択する第五の理由は、実績と 企業ユーザの間での評判です。エンタープライズコンピューティングのビジネスはなまやさしいもの ではなく、最良の会社しか生き残れません。VERITAS は生き残っただけではなく、企業向けの UNIX データ管理の分野でリーダーとしての地位を確立しました。現在では、Fortune 1000 にリストされてい Page 72 VERITAS Data Availability Solution www.veritas.com/jp る企業のうちの 60%以上が VERITAS のソリューションを使っています。 VERITAS は堅実で信頼性のあるソリューションで定評がありますが、新しいデータストレージ管理の テクノロジに対しても積極的であり、ストレージの複製やクラスタリングといった最新のソリューシ ョンでもユーザの幅広い指示を受けています。VERITAS のユーザはこうした最新の IT 機能を他に先が けて導入することになり、競争力をいっそう強化することができます。 VERITAS のデータストレージ管理ソリューションは単なる製品の集合ではありません。VERITAS はテ クノロジ、ビジョン、製品、スキル、リソースを一体化した会社であり、e ビジネスデータベースの ために堅牢でしかも身軽な IT ソリューションを提供します。今日の厳しい競争に勝ち抜くには、こう したソリューションこそが求められています。 www.veritas.com/jp VERITAS Data Availability Solution Page 73 TM V E R I T A S W H I T E P A P E R Copyright ©2001 VERITAS Software Corporation. All rights reserved. VERITAS, VERITAS SOFTWARE, VERITAS ロゴ, BUSINESS WITHOUT INTERRUPTION, VERITAS The Data Availability Company およびベリタス製品は、米国および各国の VERITAS Software Corporation の商標または登録商標です。その他の会社名、製品名等は、それぞれ各社の商標または登録 商標です。 ※製品の仕様･性能等は予告なく変更する場合がありますので、ご了承ください。 ※本資料の無断転載を禁じます。 お問い合わせ先 〒100-0011 東京都千代田区内幸町２丁目２番２号 富国生命ビル TEL 03-5532-8242 FAX 03-5532-0889 http://www.veritas.com/jp www.veritas.com/jp VE-D-001-11
© Copyright 2024