Comments
Description
Transcript
ASM機能を持つOracle 11g とEVA8x00を使用した複製のベスト
ASM機能を持つOracle 11gとEVA8x00を使用した複製のベ スト プラクティス 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . ソリューションの構成 . . . . . . . . . . . . . . . . . . . . Oracle 11gデータベース . . . . . . . . . . . . . . . . . EVAからASMへのディスク グループのマッピング . . . . . . HP OpenView Operations for Windows . . . . . . . . . . . Benchmark Factory for Databases . . . . . . . . . . . . . HP StorageWorks Command View EVAとContinuous Access EVA SANインフラストラクチャ . . . . . . . . . . . . . . . . . テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . 複製の概念と留意事項 . . . . . . . . . . . . . . . . . 目標復旧時点と目標復旧時間 . . . . . . . . . . . . データ複製グループ . . . . . . . . . . . . . . . . 同期複製と非同期複製 . . . . . . . . . . . . . . . 帯域幅、遅延、ワークロード、および距離 . . . . . . . . 帯域幅 . . . . . . . . . . . . . . . . . . . . 遅延 . . . . . . . . . . . . . . . . . . . . . ワークロード . . . . . . . . . . . . . . . . . . 距離 . . . . . . . . . . . . . . . . . . . . . ベンチマーク結果 . . . . . . . . . . . . . . . . . . . . 同期複製のテスト . . . . . . . . . . . . . . . . . 拡張非同期複製のテスト . . . . . . . . . . . . . . パフォーマンス メトリック . . . . . . . . . . . . . . . ベスト プラクティス . . . . . . . . . . . . . . . . . . . . . ストレージ管理者のベスト プラクティス . . . . . . . . . . . サーバ管理者のベスト プラクティス . . . . . . . . . . . . データベース管理者 . . . . . . . . . . . . . . . . . . 結論 . . . . . . . . . . . . . . . . . . . . . . . . . . . まとめ . . . . . . . . . . . . . . . . . . . . . . . . 付録A—部品表 . . . . . . . . . . . . . . . . . . . . . . . 付録B—フェールオーバーのテスト . . . . . . . . . . . . . . . フェールオーバーの手順 . . . . . . . . . . . . . . . . 環境の準備 . . . . . . . . . . . . . . . . . . . . バックアップ データベースを開く . . . . . . . . . . . 付録C—略語 . . . . . . . . . . . . . . . . . . . . . . . . 詳細情報 . . . . . . . . . . . . . . . . . . . . . . . . . HP技術情報 . . . . . . . . . . . . . . . . . . . . . . HPのソリューションとトレーニング . . . . . . . . . . . . . HPの製品サイト . . . . . . . . . . . . . . . . . . . . Oracle . . . . . . . . . . . . . . . . . . . . . . . . Quest Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 4 5 10 10 11 11 13 13 13 14 14 17 17 18 18 20 21 21 27 31 36 37 37 38 39 39 40 43 43 44 44 46 48 48 48 48 49 50 概要 ここ10年の間に、ディスクアレイベースのリモート コピー インフラストラクチャが利用できるようになり、 実際に使われるようにもなりました。そのようなインフラストラクチャを正しく構成および配備すれば、 データ センタ サイト全体の機能停止を含むさまざまな障害から、適切な時間内に復旧することが できます。HPでは、よく知られている技術上の問題に加え、最近の顧客の聞き取り調査やIDCとの 受託調査からの情報を組み合わせた結果、主要な要件を確認しました。ソリューションを実際に役 立つものにするには、ネイティブ リレーショナル データベース管理システム（RDBMS）テクノロジと の連携でデータベースのリモート コピーを行う必要があります。 このホワイト ペーパーでは、HP EVA（Enterprise Virtual Array）上でCA（Continuous Access）をリモー ト コピー インフラストラクチャとして使用し、OracleのASM（Automatic Storage Manager）を使用した Oracle 11gデータベースの正しい構成、配備、運用のための、テストによって実証された一連の包括 的なベスト プラクティスを紹介します。とくに、このホワイト ペーパーでは配備に関する以下の基 本的な問題を調査したときに明らかになった点を検討します。 • EVA上で複製用にOracle 11gデータベースを構成するための最善の方法、およびその構成とスタン ドアロン（複製を行わない）構成との相違点と共通点。 • 複製の方法、帯域幅、遅延、および距離が、複製の動作に及ぼす影響。 • 同期複製、非同期複製、拡張非同期複製のそれぞれがデータベースのパフォーマンスに及ぼす影 響と、使用する最善の方法を選択するための実用的な考察。 • サイト間の距離が及ぼす影響。 • リモート リンクの適切なサイジングのために、Oracleアプリケーションについて知っておくべきこと。 • 配備の主要要素（サーバ、ストレージ、インターコネクト、およびデータベース）に関するベス ト プラクティス このホワイト ペーパーで説明する方法およびベスト プラクティスを参考にして、予測可能なパフォーマ ンス特性や運用の容易さ、満足できるリカバリ能力を備えた、完全に機能するリモート コピー インフ ラストラクチャを、生産的にプランニングし適切なタイミングで配備してください。このホワイト ペー パーによって、配備にかかる時間を短縮し、リスクを軽減し、しかもトータル コストを最小化する方 法で、この目的を達成してください。 このホワイト ペーパーは、http://h50146.www5.hp.com/products/storage/whitepaper/pdfs/ 4aa1-4941jap_jp.pdfに掲載されている、以前に公開された『ASM機能を持つOracle 10gとEVA8000を使 用した複製のベスト プラクティス』で説明したトピックを再検討したものです。新しいバージョンの変更 点には、インフラストラクチャ（ホスト バス アダプタ（HBA）、スイッチ、EVAコントローラ）の4Gbへのアッ プグレードと、Oracle 11g Enterprise Editionを使用したテストが含まれます。さらに、新しく注目した項 目には、オプティカル キャリアOC6とOC9の比較、オンラインREDOログ サイズの影響、書き込み履歴 ログの利用、さまざまなリンク遅延における目標復旧時点（RPO）があります。 注記： HPは、Oracleの11gベータ パートナー プログラムのメンバーです。そのため、このプロジェクトでは、11gのベータ コードを受 け取ってテストしました。 2 ソリューションの構成 複製のための構成は、FCIP（Fibre Channel over Internet Protocol）経由で接続された2台のHP EVA8000 間で構築されました。プライマリ サイト（のサイトA）では、ASM（Automatic Storage Management）を使 用するOracle 11g RAC（Real Application Clusters）データベースが実行されました。このデータベース が、バックアップ サイト（サイトB）のOracle11gシングル インスタンス データベースに複製されました。 図1 ハイレベルの構成 今回のテストを実施するために、HPでは図2に示すシステムを構成しました。 3 図2 サイトAの構成 これらの環境は、顧客の聞き取り調査に基づいたもので、典型的なOracleデータベース環境を再現し ています。正確なバージョンと製品番号を「付録A—部品表」（40ページ）に示します。 Oracle 11gデータベース ASM機能を備えた2ノードOracle 11g RACデータベースを、ProLiant DL580 G4サーバ上で実行しまし た。サーバには、4基のデュアルコアCPU（ハイパースレッド対応）が搭載され、合計16の論理CPUが存 在しました。それぞれのサーバには32GBのRAMと3つの4Gbデュアルチャネル ホスト バス アダプタ （HBA）を搭載しました。G4モデルのサーバでは、新しいPCI-Expressスロットを使用しました。選択した オペレーティング システムはRed Hat Enterprise Linuxであり、内蔵のLinux用HP HBAドライバによっ て、オプション3（ダイナミック）：LST（Least Service Time）を用いたマルチパス機能が提供されました。 RACデータベースのインターコネクト用には、HP Procurveスイッチ2708を使用しました。 テストしたデータベースは500GBで、オンライン トランザクション処理（OLTP）ベンチマークでは8KB のブロック サイズを使用しました。ベンチマーク ツールを使用して、1,000の同時ユーザーを専用 モードでシミュレートしました。アーカイブを設定し、フラッシュバック領域を設定しましたが、オン ラインREDOログのミラーコピーはフラッシュバック領域のディスク グループから削除されました （「EVAからASMへのディスク グループのマッピング」（5ページ）の注で説明します）。Oracleのベスト プ ラクティスに従い、REDOログのサイズを2GBに設定しました。これにより、約20分ごとにログ スイッチ が発生しました。ベンチマークツールが生成するワークロードに対応できるように、データベースが最 も効率的な設定になるよう準備テストの実施中にチューニングしました。これには、システム グローバ ル領域（SGA）のサイジング、プロセス パラメータの増加、サード パーティのアプリケーション コードに 4 とって必須であるcursor_sharingのforceへの設定が含まれます。また、初期パラメータに対し てoptimizer_index_cost = 25、optimizer_index_caching = 90という変更を加え、 db_file_multiblock_read_count = 8に設定しました。これらの値は、OLTPワークロードに対 して一般的に推奨されるものです。準備段階のチューニングによって、ベンチマーク ツールによる1秒あ たりのトランザクション数（TPS）で測定した全体的なベースライン パフォーマンスは15%向上しました。 ベスト プラクティス 基本的なデータベース チューニングにより、OLTPワークロードのベースライン パフォーマンスが15%向上します。 セカンダリ サイトでは、同じくRed Hat Enterprise Linuxが稼動するProLiant DL580 G3サーバ上で、 ASM機能を備えたシングル インスタンスのOracle 11gデータベースを実行しました。このサーバに は、4つの4GbデュアルチャネルHBAを搭載しました。すべてのサーバは、最新のProLiant Support Packを使用してインストールしました。 図3の構成に、単一の大型ファイル表領域内に存在する複数のスキーマを使用したレイアウトを 示します。 図3 Oracle表領域の構成 EVAからASMへのディスク グループのマッピング データベースの一般的なベスト プラクティスは、2つのEVAディスク グループと2つのASMディスク グ ループを備え、メイン グループにオンライン ファイル、セカンダリ グループにバックアップ ファイル を配置することです（図4）。 5 図4 Oracle ASMのレイアウト例 これは、http://h50146.www5.hp.com/products/storage/whitepaper/pdfs/4aa0-9728enw_ja4.pdfに掲 載されているHPのホワイト ペーパー、『Automatic Storage Management機能を持つOracle 10gとHP StorageWorks Enterprise Virtual Arrayのベスト・プラクティスに関するホワイト・ペーパー』で説明されて いるHPとOracleのガイドラインです。このベスト プラクティスはパフォーマンスを目的としたものではな く、ファイルを分離することでリカバリを確実にすることを目的にしています。これにより、仮にプライマ リ ディスク グループを失った場合でも、セカンダリ ディスク グループにあるバックアップ ファイルから データベースを復旧できます。また、バックアップ ファイルのアクセス頻度はデータベース ファイルより はるかに低いため、バックアップ ディスク グループでは、使用するドライブの数を減らすことやスピンド ル速度の遅いドライブを使うことが可能になります。さらにRAID5を使用すれば、投資対効果を最大化 することができます。テストに使用したEVAの構成は2つのコントローラと12のディスク エンクロージャ （2C12D）に168台のドライブを収容したもので、そのうち136台のドライブをメイン ディスク グループに、 32台のドライブをバックアップ ディスク グループに配置しました。すべてのドライブは、146GB 15K RPM スピンドルで、各論理ユニット（LUN、仮想ディスクとも呼ばれます）は、RAID1で構成されました。（ただ し、この構成だけが可能な構成ということではありません。これはベスト プラクティスのためのガイドラ インに過ぎません。データベース管理者は、実際の環境に合わせて、この構成を変更できます。） 6 注記： Oracle 11gでフラッシュバック領域を設定する場合は、注意が必要です。OracleはオンラインREDOログのミラー コピーを自動 的にバックアップ ディスク グループに配置しますが、図4に示す構成を設計する場合は、このことがデータベースのパ フォーマンスに影響を及ぼす可能性があります。最も簡単な解決策は、オンラインREDOログのミラー コピーをバックアッ プ ディスク グループから削除することです。 図4では、コントローラ間でLUNが負荷分散されていることにも注意してください（黄色のLUNはコント ローラAが管理し、青色のLUNはコントローラBが管理しています）。これはスタンドアロン（複製なし の環境）に関するベスト プラクティスですが、複製環境では好ましくありません。データベースを複 製する場合は、単一のデータ複製（DR）グループ内のすべてのLUNを同じコントローラの管理下に 置く必要があります（図5）。DRグループを作成し、そのグループにLUNを追加すると、アレイが自 動的にこの構成にします。 図5 EVA8x00上でのOracleの構成1 ベスト プラクティス 図5の赤い線で示すように、単一のアプリケーションのすべてのLUNを1つのDRグループに配置することをお勧めします。 7 これは推奨されるソリューションですが、複製が開始される前の時点で、図6に示すように両方の コントローラの利用率がすでに50%を上回っている場合には、注意が必要です。その場合、この構 成では実質的にそのワークロード全体を1つのコントローラに配置することになるため、パフォーマ ンスが低下する可能性があります。 図6 コントローラのワークロードの例 この問題に対する実現可能なソリューションは、2つのDRグループを作成することです（図7）。 8 図7 EVA8x00上でのOracleの構成2 このプロジェクトでは、この構成のみを使用しました。DRグループを2つ使用することで、両方のコント ローラをアクティブの状態に保つことができます。ただし、この方法には二重障害のリスクがあることに 注意する必要があります。何らかの理由でDRグループの一方が複製を停止し（最初の障害）、同 時にプライマリ サイトに障害が発生すると（2番目の障害）、一部の重要なファイル変更が失われ、 複製先サイトでのデータ復旧が不可能になる可能性があります。二重（または三重以上）の障害 に対して計画を立てるのは困難なので、リカバリに使用できる何らかの手段（たとえばテープ）の バックアップも用意してください。実際の業務でこの水準のリスクが許容できるなら、図7に示す構成 は有効です。そうでない場合、適切な構成は最初の構成（単一のアプリケーションのすべてのLUN を同一のDRグループに配置する、図4）です。 最後に、多くの顧客がオンラインREDOログをデータベース ファイルから分離したいと考えています。 このソリューションはまったく問題ありませんが、複製のためにこれらのオンラインREDOログを専 用のDRグループに配置するのは避けてください。これには、特に二重障害が発生した場合に、潜 在的な危険性があります。これはデータベースの正式なバックアップやリストアではなく、本質的 にはインスタンス リカバリであるため、リカバリの際にはオンラインREDOログが必要です。最善の 手段は、オンラインREDOログをデータベース ファイルと同じDRグループに置くか（図8）、単一 のDRグループを使用することです。 9 図8 EVA8x00上でのOracleの構成3 HP OpenView Operations for Windows データベース サーバのパフォーマンスのメトリックは、HP OVOW（OpenView Operations for Windows）、 特にPerformance Managerを使用して収集しました。このツールは、32ビットMicrosoft Windows 2003 Enterprise Editionが動作しているProLiant DL580 G2サーバで実行されました。OVOWは、各ホスト サーバにエージェントを配備することにより、Linuxを含む各種オペレーティング システムのサーバを監 視できます。このテストでは、OVOWを使用することにより、CPUの利用率、メモリの利用率とページン グ、ディスクのスループットなど、さまざまなサーバ メトリックを監視できました。OVOWを使用して、メト リックのグラフ化と分析も実行しました（「テスト」（13ページ）を参照）。 Benchmark Factory for Databases Oracleデータベースに対してOLTPワークロードを実現するために、Quest SoftwareのBenchmark Factory for Databasesを使用しました。32ビットMicrosoft Windows 2003 Enterprise Editionが動作して いる5台のProLiant DL580 G2サーバ上で、このツールを同時に実行しました。このツールにより、 各ユーザーのデータベース接続をリアルタイムで監視し（図9）、TPSおよび最小、最大、平均のト 10 ランザクション時間を測定しました。TPSは、OLTPベンチマークの主要な測定値であり、複製の遅 延を基準にして各テストの結果を評価する目的で使用します。 図9 Benchmark Factory for Databasesの出力例 HP StorageWorks Command View EVAとContinuous Access EVA この環境では、ProLiant BL20pサーバは2つの役割を担当しました。このサーバは、EVAPerf （Enterprise Virtual Array性能監視ツール）とContinuous Access EVAの両方を含むHP Command View EVAサーバとして機能しました。また、サーバ配備用のRDP（Rapid Deployment Pack）も実行しました。 RDPサーバ用のストレージは、MSA（Modular Smart Array）1500により提供されました。Command View を使用して、ストレージの設定と、EVAからOracleデータベース サーバへの提供を行いました。テスト の実行中、Command View EVAの一部としてインストールされコマンド ラインから実行したEVAPerfを 使用して、アレイのパフォーマンス、全体の利用率、書き込み遅延などの要因を監視しました。 次のコマンドは、指定したEVAに対して3.5時間にわたり15秒ごとにすべてのメトリックを取得するた めに、EVAPerfユーティリティを実行する方法を表しています。 >evaperf mof −csv −od c:\perf −cont 15 −dur 12600 −sz RAC01 出力として、主要なすべてのパフォーマンス メトリック カテゴリに対応する一連の.csvファイルが生成 され、c:\perfディレクトリに格納されます。その後、HP独自のグラフ作成ツールを使用してこれらの メトリックを分析し、パフォーマンスと潜在的ボトルネックを監視しました。 SANインフラストラクチャ ストレージ エリア ネットワーク（SAN）インフラストラクチャは、複数のHP StorageWorks 4/32 SANスイッ チからなる単一のファブリックで構成し、これらのスイッチはHPマルチ プロトコル ルータ（MPR）400経 由でFCIPを使用してサイト間の通信を行いました（図10）。PacketStormのHurricane IIネットワーク遅延 エミュレータを使用して、リンクにネットワーク遅延を追加しました。このデバイスを使用して、OC6と OC9の各オプティカル キャリア リンクの帯域幅制限も追加しました。 11 図10 SANインフラストラクチャ 12 テスト このプロジェクトでは、以下の問題を検討します。テストに基づく答えを、「ベスト プラクティス」（36ページ） に示します。 • 複製を目的にデータベースを構成するための最善の方法は何か。 • 複製の方法によって推奨される構成が変わるか。 • 帯域幅や遅延は複製の動作にどのように影響するか。 • 同期複製はデータベースのパフォーマンスにどのような影響があるか。 • 拡張非同期複製はデータベースのパフォーマンスにどのような影響があるか。 現在のプロジェクトは、エンドツーエンド複製ソリューションの第1フェーズに当たります。このフェーズ では、複製のための配備を開始する前に、複製の手法について十分に理解する必要があります。これ らの手法には、目標復旧時点と目標復旧時間、データ複製グループ、同期複製と非同期複製、帯 域幅や距離、遅延が及ぼす影響、ワークロードの特性などがあります。これらの方式の背景知識 について、このホワイト ペーパーで説明します。このプロジェクトに続くフェーズでは、Oracleデータ ベースの実際のフェールオーバーおよびフェールバックのシナリオ、つまり同期モードおよび非同期 モードで複製を実行中にサイトの障害が突然発生したというシナリオを取り扱います。詳細について は、「付録B— フェールオーバーのテスト」（43ページ）を参照してください。 複製の概念と留意事項 この項では、複製の概念と留意事項に関する概要を説明します。アレイベースの複製の詳細 な説明については、http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01080818/ c01080818.pdf?jumpid=reg_R1002_USENにある『HP StorageWorks Continuous Access EVA planning guide』、およびhttp://h20000.www2.hp.com/bc/docs/support/SupportManual/c01080802/ c01080802.pdf?jumpid=reg_R1002_USENにある『HP StorageWorks Continuous Access EVA administrator guide』を参照してください。 目標復旧時点と目標復旧時間 リカバリポイント目標（RPO）は、消失が容認できるデータの量を意味し、具体的には、どの時点までの データが復旧する必要があるかを意味します。「0」RPOが要求される場合もあります。これは、サイト に障害が発生した場合にコミットされたトランザクションを1つでも失ってはならないことを意味します。 この場合、障害が発生した時刻までのデータを復旧できることが必要です。RPOを0に設定する場合、 考慮するべき点があります。複製ソリューションが同期複製（詳細は、この項で説明します）を必要とす るので、複製対象のアプリケーションのパフォーマンスに影響を及ぼす可能性があります。 RPOが0よりも大きい場合（たとえば30分）、別の方法で対処できます。RPOを30分に設定すると、サイ トに障害が発生した場合、障害発生時点から30分前までのトランザクションを失うのを許容することを 意味します。障害が12:00に発生した場合、少なくとも11:30（障害の30分前）までのデータが復旧できる 必要があります。これは、多くの場合、非同期複製を使って実現できるので、アプリケーションのパ フォーマンスへの影響を最小限に抑えることができます。この状況では、希望するRPOに対応するた めに、書き込み履歴ログについての慎重な計画と監視が不可欠です。 RPOは、それぞれの環境に応じて、ビジネス ルールや管理方法に基づいて決定する必要があり ます。大きなRPOによるデータ消失のリスクと、0 RPOの構成による費用やパフォーマンスへの影 響を比較検討する必要があります。 13 目標復旧時間（RTO）は、プライマリ サイトが完全に停止した後、バックアップ サイトの稼動を開始す るまでにかかる時間のことです。ほとんどの場合、15分から8時間の間でRTOを設定し、平均は約2時 間です。この時間には、複製済みのLUNをバックアップEVAにフェールオーバーする時間、バック アップ データベースを復旧してオンラインにする時間、およびアプリケーションをバックアップ データ ベースサーバにリダイレクトする時間が含まれます。通常、RTOを短くするには、バックアップ サイ トをできる限り準備しておく必要があります。 データ複製グループ データ複製（DR）グループは、他のアレイ上の対応するグループとリモート複製関係にある、仮想ディ スクからなる論理グループです。DRグループ内の仮想ディスクは、一緒にフェールオーバーし、書き込 み履歴ログ（WHL）を共有し、グループ内の書き込み順序を維持します。書き込み順序の保証は、デー タベース アプリケーションでフェールオーバーやリカバリが発生する場合に特に重要です。さらに、リ モートコピーを正しくオンラインにできるようにするために、ASMを使用するOracleデータベースで は必須条件になっています。ホストがデータをDRグループ内の複製元仮想ディスクに書き込み、 アレイがそのデータをDRグループ内の複製先仮想ディスクにコピーします。複製元と複製先の一 対の仮想ディスクをコピー セットと呼びます。 同期複製と非同期複製 EVAシリーズには、同期、非同期、拡張非同期の3種類の複製があります。第1世代のEVA （3000/5000）は同期複製と非同期複製（後者を標準非同期複製とも呼びます）をサポートしています。 次の世代のEVA（4x00/6x00/8x00）は、同期複製と、拡張非同期複製という新しい機能をサポートして います。非同期複製に関するこれら2つのバージョンには互換性がありません。このため、EVA8x00と EVA5000の間で複製を実施する場合、現時点でサポートできるのは同期複製だけです。 同期複製では、ローカル アレイおよびリモート アレイでデータがキャッシュされた後で、入出力（I/O） の完了が通知されます。図11に示す例では、ホスト サーバが1番目のI/O要求をローカルのストレージ アレイに送信します。その後、複製元アレイがそのデータを複製先アレイに複製して、応答を待ちま す。複製元アレイは、複製先アレイからの応答を受け取った時点で、ホスト サーバに確認の通知を送 信します。ホストは、この通知を受け取るまでは、次の（2番目の）I/O要求を送信できません。同期複 製では、複製元LUNと複製先LUNが常に同期されており、フェールセーフ モードで0 RPOをサポートで きます。ただし、複製リンクに大きな遅延が発生すると、サーバ アプリケーションのパフォーマンスに大 きな影響を及ぼす可能性があります。このような状況では、アプリケーションは、I/Oが複製先アレイに 複製され応答が戻ってくるまで待つ必要があります。リンク上の遅延が大きい場合、アプリケーション は次のI/O要求を送信できるようになるまでに、長時間待つことになります。 14 図11 同期複製 標準非同期複製では、データがローカル アレイでキャッシュされた後、リモート アレイに複製される前 にアレイがI/O完了の通知を行います（図12を参照）。つまり、データが複製元アレイのキャッシュに書 き込まれた直後に、アレイはホスト アプリケーションへの確認（ACK）応答を実行します。この時点で、 ホストは次のI/O要求を送信できるようになります。図12では、ホストの4番目のI/O要求が複製元アレ イにより処理されていますが、複製先に複製されているのは1番目のホストI/Oだけです。帯域幅が利 用できるようになった時点で、データが受信順にリンク経由で複製先アレイに複製されます。利用でき ない場合、データは複製元アレイのキャッシュ内でキューに追加されます。EVAファームウェアのバー ジョンにより、最大64KBまたは128KBのI/Oをキャッシュ内のキューに格納できます。送信待ちキュー がいっぱいになると、複製グループは同期モードに切り替わります。 図12 非同期複製 非同期複製では、複製がバックグラウンドで進行するため、ホスト アプリケーションのパフォーマンス への影響は最小限に抑えられます。非同期複製の欠点は、データ消失の可能性があることです。複 製要求が複製元アレイのキューに格納されているときに障害が発生すると、複製の済んでいないすべ てのデータが消失します。その際、プライマリ アレイでコミット済みのトランザクションも消失する可能 性があります。一方、リンクの遅延が小さく帯域幅が十分な場合は、非同期複製がデータのワー クロードに遅れず進行できるため、ほぼ0のRPOが実現します。 拡張非同期複製は、EVA4x00/6x00/8x00シリーズの新機能です。拡張非同期複製では、受信したホ ストI/Oをキャッシュ内に保存する代わりに、ディスク上に作成される書き込み履歴ログを使用するの 15 で、標準非同期複製よりも多くの数の要求をサポートできます。受信した要求はキャッシュと書き込み 履歴ログに書き込まれ、ホスト サーバに対して確認の応答が戻されます（図13を参照）。 図13 拡張非同期複製 書き込み履歴ログのサイズは1.6GB～2TBの間で任意に設定できます。書き込み履歴ログのサイズを 正しく設定すると、RPOのサポートに役立ちます。書き込み履歴ログは循環バッファです。アレイは、書 き込み履歴ログがいっぱいになるとログの内容を削除して複製元LUNから複製先への高速コピーを開 始します。高速コピーでは、ログの最初のエントリ以降に変更されたすべてのブロックが複製先にコピー されます。該当する期間に変更されていないブロックは、複製先ではそのままの状態で残ります。高速 コピーの実行中、複製元のコントローラはログがクリアされるまでホストI/Oを同期モードで処理します。 たとえば、サイジングとテストの結果、書き込み履歴ログのサイズを50GBに設定したと仮定します。ま た、これをアプリケーション ワークロードに基づいて計算すると、30分のRPOに相当するデータに なると仮定します。ログがいっぱいになると、アレイは同期モードに移行します。高速コピーが終了 するまでは複製が同期モードで実行されるため、受信I/Oのパフォーマンスに悪影響が生じます。 高速コピーの進行中、複製先グループのデータは複製元と一致しておらず、使用できません。高 速コピーが完了すると、アレイは非同期モードに戻り、2つのサイトは同期した状態から再び動作 を開始します。高速コピーの間、2つのサイトが再同期されるまでは指定したRPOを保証できませ ん。この場合、二重障害のリスクがあります。 必ず、書き込み履歴ログがいっぱいにならないように、慎重にログを監視してください。ログの容量が 約80～90%に近づいたら、RPOをサポートし続けるために、ログが十分に減少するまでストレージ管理 者は複製グループを手動で一時的に同期モードに切り替える必要があります。この操作により、ログ は「縮小」状態に移ります。この状態では、ホストから新しいI/Oを1つ受信するごとに、2つの記録済み I/Oが複製先に送信されます。目標は、ログを、設定したRPOをサポートできるだけの十分な大きさに 設定することですが、止むを得ない場合を除いてログがいっぱいにならないようにしてください。 ここでは、リンク障害やリストアなどの複製の特定の概念については触れません。リンクに 一時的な障害が発生した場合の動作は、複製の手法によって異なります。この件に関する 詳細についても、http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01080802/ c01080802.pdf?jumpid=reg_R1002_USENにある『HP StorageWorks Continuous Access EVA administrator guide』を参照してください。 16 帯域幅、遅延、ワークロード、および距離 帯域幅 複製の重要な側面の1つは、サイト間リンクの帯域幅について正しく理解することです。2つのアレイが 同じデータ センタ、建物、サイト、あるいは都市内にある場合は、SANのファイバ チャネル リンク経由 で複製を実行できることがあります。この場合、通常、1、2、または4Gb/秒の速度に対応します。そ れ以上の距離では、FCIPが必要になる場合があります。2つのサイト間のリンクについて理解する ことも重要です。リンク全体に対してアクセスできる場合もあれば、 部門の利用率が20%に制限さ れている場合もあります。また、リンクには別のトラフィックが存在することもあります。別のアプリ ケーションがすでに容量の50%を使用している可能性もあります。 サイト間に不適切なネットワーク リンクが存在する場合、複製が阻害されることに注意してください。こ のプロジェクトではFCIPソリューションを選択しました。サイト間のリンクには、かなり一般的な、ネット ワーク ジェネレータに対してOC6を使用する方式を採用しました。これは310Mbpsをサポートできるリン クです。図14に、OC6経由で複製を実施する2つのシナリオを示します。 図14 帯域幅の例 最初の図では、ピーク時のユーザーのワークロードは、220Mb/秒です。帯域幅全体が使用可能で、リ ンク上に他のトラフィックがない場合は、310Mb/秒のOC6リンクはこのワークロードをサポートしま す。2番目の図では、ユーザーのワークロードは480Mb/秒です。これは、リンクの帯域幅を上回っ ているので、データの複製に時間がかかり、アプリケーションのパフォーマンスや書き込み履歴ロ グ内のキューに影響が及ぶことがあります。 17 遅延 複製リンク上の遅延（ラウンドトリップ遅延）も重要な要素です。遅延が短い方が望ましいのは言う までもありません。1～2msの遅延は、通常、ファイバ チャネル経由でのみ実現できます。同期複 製ソリューションには、このような低遅延 リンクが最適です。リンクの遅延が大きい場合、非同期 ソリューションがより適切になります。たとえば、遅延が100msの場合、同期複製ではほとんどのア プリケーションがほぼ停止状態になることがあります。このような状況では、非同期ソリューション 以外の選択肢はありません。一部のアプリケーションは、ネットワーク遅延にきわめて弱く、最大 スレッショルドの推奨値が指定されています。 このプロジェクトでは、さまざまな遅延をテストしました。最初のテストは基準として、4Gbファイバ チャネ ルに対して、ネットワーク エミュレータによるリンク遅延を付加しませんでした。次に、付加遅延なしで OC6リンクをテストしました。最後に、20msおよび100msの遅延を付加してOC6リンクをテストしました。 遅延が「付加」されたものであることに注意してください。リンクには何らかの固有の遅延が必ずありま す。特に、FCIPソリューションではそれは顕著です。たとえば、0msの遅延を付加したOC6のテストは、 実際には、FCIP上での約8msのラウンドトリップ遅延を再現するものでした。テストでは好結果が得 られました。100msの遅延を追加しても、Oracleデータベースがクラッシュしたり応答しなくなったり することはまったくありませんでした。テスト結果から、同期モードではこのような遅延の大きい状 態でアプリケーションの応答時間が急に低下することがわかりますが、同時ユーザー数が1,000の 場合でもデータベースは動作を続けました。 ワークロード 複製を計画するときは、「平均」ワークロードを使わないように注意してください。正しい計画を立 てるには、統計関数の95パーセンタイル値を使用してください。また、0 RPOを計画する場合は、 100パーセンタイル値を使用します。以下、このプロジェクトで使用したアプリケーション ワーク ロード（表1）に基づいて説明します。 表1 アプリケーション ワークロード 書き込み平均（Mb/秒） 書き込み95パーセンタイル値（Mb/秒） 265 464 EVAPerfを使用してEVAに関して収集したパフォーマンスに基づくと、平均書き込みワークロードはわ ずか265Mb/秒です。一見すると、この平均は、310Mb/秒のOC6リンクを経由して複製を実施するのに 非常に適しているように思えます。しかし、アプリケーション ワークロードに関するより明確な全体像を 示す95パーセンタイル値は、書き込みワークロードが464Mb/秒であることを示しています。これは、複 製リンクの最大容量を上回っているうえ、残りの5%のデータは464Mb/秒より高い数値に達しています。 複製ソリューションの計画を開始する前に、アプリケーション ワークロードの全体像を明確に把握して おく必要があります。ワークロードの把握作業は、通常、利用率の高い期間（たとえば、月末処理時） を選んで、48時間実施します。平日が最も忙しい場合は、必ず、平日の統計値を収集してください。 EVAPerfを使用した実際のメトリックの収集は、アレイやアプリケーションのパフォーマンスには影響を 及ぼしません。また、プランニングの対象が複製であり読み取り要求は複製されないため、注目する 必要があるのは1秒当たりの書き込みだけです。たとえば、アプリケーションの合計ワークロードが 500Mb/秒の場合でも、実際の書き込み要求の値は100Mb/秒に過ぎない可能性があります。 このプロジェクトの目的に合わせて、OC6複製リンクの帯域幅を少しだけオーバーするワークロードを 意図的に選択しました。ワークロードは、テスト サイクル全体をとおして安定していました。これは、ひ とつには、過度に小さいリンクを使用したときのアプリケーションへの影響を調査するためでした。ま 18 た、このテストでは、リンクがアプリケーション ワークロードに対応しきれないため、非同期複製の間に 書き込み履歴ログへの何らかの記録が発生することを保証できます。 アプリケーション ワークロードについて理解する必要があるもう1つの点は、その特性です。つまり、 ワークロードのピーク時刻とそのときの大きさ、ワークロードの谷間（作業休止期間）の時刻と持続時 間などです。図15に、24時間にわたる仮想的なワークロードの例を示します。 図15 ワークロードの例 深夜は、夜間のバックアップが行われる間に利用率がわずかに増え、その後下がって元に戻ります。 午前8時ごろ、社員が出社するにつれてワークロードが増加します。その後、ワークロードは昼食時間 までの3時間にわたり高水準にあります。この期間中は複製リンクの帯域幅を超えています。 このピーク トラフィック時間が、今回のプロジェクトの主な注目点です。同期複製を実行している場合、 アプリケーションのパフォーマンスが低下します。非同期複製の場合は、一部のデータが書き込み履 歴ログのキューに格納され始めるので、データ消失のリスクが発生します。昼食時には、ワークロード は減少します。この谷間の持続時間は、計算のうえで非常に重要です。この期間中、書き込み履歴ロ グは、キューに格納したデータをすべて複製しようとします。この期間が十分長く、書き込み履歴ログを 空にすることができれば、 データに非同期複製によるリスクが発生するのは、論理的にはこの作業休 止期間の1時間程度のみです。昼食時間後は、複製のバックログは発生しません。ワークロードは増え 続け、社員が退社する夕方になると減り始めます。この期間中は、帯域幅はワークロードに対して十 分です。パフォーマンスの低下や書き込み履歴ログの大量のキューへの格納は発生しないはずです。 この仮想的なワークロードでは、いくつかの重要な点を学べます。まず、複製リンクの帯域幅に対する 超過が発生し、これが毎日、午前中の遅い時間に発生することが予想されました。この場合、リンクを OC9にアップグレードすることを考慮するべきかもしれません。アップグレードしない場合、同期複製を 使用するのであれば、このピーク時間帯にパフォーマンスが低下することが予想されます。あるいは、 19 データ消失のリスクを許容できるのであれば、このソリューションで非同期複製を使用するという選択肢 もあります。この場合、アプリケーションのパフォーマンスへの影響はありません。また、トラフィックの ピーク時間はわずかの間です。最後に、アプリケーションをさらに詳しく調査すると、ワークロードの一 部をどこかに移動できると判断できることがあります。たとえば、帳票処理などの機能が午前10時およ び11時に発生する場合、これを延期して昼食時間に実行できる可能性があります。このような簡単な変 更だけでワークロードをOC6リンクのスレッショルドの枠内に十分収めることが可能なことがあります。 距離 最後に、距離の複製への影響について説明します。多くの顧客が、まず最初に、「500マイル離れた データ センタへデータを複製したい」というように、距離を問題にします。たしかに、光の速度とファイ バ チャネルの速度には理論的な限界値があり、通信プラットフォームを左右しますが、これらの制限 は通常、最大の制限である遅延、帯域幅、およびワークロードと比べると、重要ではありません。 図16に、実際の顧客の事例を示します。 図16 ネットワーク リンク内の距離 この顧客は、100km離れたデータ センタでデータ複製を行っていました（青色の線）。さまざまな物理学 的また数学的な計算に基づいて、ネットワーク遅延が最小で約1～5msの非常に速い複製が期待され ましたが、ソリューションの実際のパフォーマンスは非常に貧弱であり、まったく満足できませんでし た。この状況に対して徹底したトラブルシューティングを行った結果、バックアップ サイトへの直接リン クがないことがわかりました。実際は、通信会社がリンクを通信会社の本社にルーティングしており、 そこからセカンダリ サイトへのリンクが構築されていました。このため、距離が大幅に延長されていま した（赤色の線）。その上、リンク上には数多くのルータが配置され、それぞれがリンク上の遅延を増や していました。ソリューションの距離だけに注目するのではなく、まず、リンクのラウンドトリップ遅延 （30ms）を把握していたら、数多くの困難や苦労を避けることができたはずです。 20 注記： これは実際の事例に基づいていますが、図は実際の場所を示したものではなく、決して企業の特定を意図したものでは ありません。 ベンチマーク結果 テストは、関連する3つのテーブルに対してランダムな読み書きワークロードを実行するOLTPベンチ マークで構成されました。5つのユーザー スキーマは、データベース内の約7億2,500万行のデータを再 現したものです。各テストは、すべての構成に対して複数回実行し、すべてのテスト実行の平均値を使 用しました。ベンチマークは、TPS単位で測定しました。TPSを使用して、さまざまな遅延とデータベー スのパフォーマンスに対する影響を比較しました。ベンチマークは、データベース内のテーブルへの read、insert、updateで構成されています（図17）。また、読み取りと書き込みの割合を調整するために weightsの値を変更することも可能ですが、このテストではデフォルト値を使用しました。今回のテス トでは、これは読み/書きの比率として約65/35に相当します。 図17 ベンチマークで使用したトランザクションの組み合わせ 同期複製のテスト このテスト結果に関して、ネットワーク リンクの帯域幅を超えるワークロードを意図的に選択したことに 注意する必要があります。複製ソリューションの設計を開始する前に、ワークロードについて把握する 必要があるという点を強調しておきます。図18に示す今回の結果から、このことが明らかになります。 21 図18 同期の結果 同期の結果（青い線で表示）では、左端の点が、フル4Gbファイバ チャネル経由でのベースライン複製 速度で、7,141TPSを示しています。まったく同じテストをOC6パイプ経由で実行した場合は5,870TPSで あり、データベースのスループットは18%低下しています。テストでは、過度に多い量のデータを単純に 送信しようとしたので、パイプはこのワークロードが処理できていません。リンク上の遅延を大きくする と（20ms）、同期複製でのデータベースのパフォーマンスは引き続き低下します。100msの遅延では、 パフォーマンスは大幅に低下しています。このポイントでは、アプリケーションのパフォーマンスは元 のベンチマークよりも69%も低速の2,232TPSになっています。これは、遅延の大きいリンク経由で同 期複製を使用する場合のトレードオフです。 今回は、不十分なインターコネクト リンクが及ぼす影響について明確に示すことを目的としていまし た。したがって、上記のワークロードに対して、OC6リンクを選択しました。一方、帯域幅が適切で、 リンクの遅延が許容範囲内にあるという両方の条件がそろったときに、複製ソリューションが成功 すると保証することも目的としていました。OC9パイプ経由で、0msおよび20msの遅延を使用し、同 期複製テストを繰り返しました。図19で、追加の遅延が0msの場合、データベースのTPSが5,870か ら6,790に改善されたことに注意してください。 22 図19 OC6およびOC9ネットワーク リンク 構成には他の変更を加えず、帯域幅だけを増やしました。また、興味深い点として、今回のワーク ロードに対して帯域幅が十分でなかったことに注意してください。4Gbのベースライン テストのTPS は7,141でした。帯域幅の不足によるパフォーマンスの低下を発生させることなくデータを複製した い場合は、実際にはOC12リンクが必要です。 ベスト プラクティス ワークロードに適したネットワーク帯域幅を選択してください。ネットワーク リンクをOC6から、遅延0msのOC9に強化し たところ、アプリケーションのパフォーマンスは16%向上しました。それまでの帯域幅は、上記のワークロードを複製するに は不十分だったからです。 テストのもう1つの分野では、異なるサイズのオンラインREDOログを使用して、複製に及ぼす影響を判 断しました。より小さいREDOログ（512KB）を使用したところ、ログ スイッチはより頻繁になりました （図20）。ログ スイッチの時間が短くなり、パフォーマンスに及ぼす影響は最小限でした（1%）。より大き いREDOログ サイズ（4Gb）を使用したところ、パフォーマンスは7%低下しました。これらの大きいログで ログ スイッチが発生した場合、より長い時間にわたって影響が持続し、同期複製の場合ははっきりと パフォーマンスが低下しました。適切なルールは、実際の環境でさまざまなログ サイズをテストし、複 製ソリューションにとって最適なサイズを見つけておくことです。 23 図20 3種類のREDOログ サイズを使用した同期複製 図21に示すEVAPerfデータの分析では、ログ スイッチがメイン ディスク グループに及ぼす影響を示し ています（大きい方のEVAディスク グループには136台のドライブがあり、データベース ファイルとオン ラインREDOログを格納しています）。このグラフは、2GBのオンラインREDOログ サイズを使用し、追加 遅延が0msのOC6リンクを経由して同期モードで複製する構成を表しています。また、バックアップ ディスク グループ（32台のドライブからなるより小規模なEVAディスク グループで、アーカイブ ログ ファイルを格納）に及ぼす影響についても分析しました。その結果はここには掲載しませんが、こ のディスク グループに関しても同様のスパイクが見られました。 24 図21 2GBのオンラインREDOログを使用した場合の平均書き込み遅延 図22に、短い間隔でログ スイッチが発生した場合の書き込み遅延の増加を示します。512KBのREDO ログ サイズを使用した場合、サンプル期間内にログ スイッチの回数が増加することに注意してく ださい。ログ スイッチが発生するたびに、メイン ディスク グループの書き込み遅延が増加しま した。ログ スイッチの時間は短いものでしたが、回数が非常に多いので、パフォーマンスにある程 度の影響を及ぼしました。 25 図22 512KBのオンラインREDOログを使用した場合の平均書き込み遅延 最後に、図23に4GBのREDOログ サイズに関する結果を示します。予期されるとおり、ログ スイッチ頻 度は低下しましたが、持続時間はかなり長くなりました。オンラインREDOログを過度に大きいサイズに した結果、同期複製の実行中はデータベースのパフォーマンスに影響を及ぼしました。 26 図23 4GBのオンラインREDOログを使用した場合の平均書き込み遅延 ベスト プラクティス 同期複製を使用する場合は、オンラインREDOログを過度に大きいサイズにしないでください。このプロジェクトで使用した 特定のワークロードに関して、REDOログのサイズが大きすぎる場合は、アプリケーションのパフォーマンスが7%低下す ることが観察されました。 拡張非同期複製のテスト 拡張非同期複製では、大きく異なる結果が得られました。初期のベースラインであるフル4Gbファイバ チャネル経由での値は6,910TPSです（図24）。 27 図24 拡張非同期の結果 OC6リンク経由でワークロードを転送する場合、拡張非同期複製ではほぼ一定の結果が得られました （正確に言うと、1%の変動はありましたが、重要なものではありません）。拡張非同期アルゴリズムに対 して最近加えられた改善は、今回のテストで明確になりました。古いファームウェアを使用した以前の テストでは、遅延が大きいリンクを使用した場合、パフォーマンスがいったん12%低下してから回復しま した。新しいファームウェアを使用した今回は、そのような状況はありませんでした。 さて、ネットワーク遅延が増加（20ms）した状態でも、データベースのパフォーマンスは引き続き安定し ています。ホスト サーバが複製元アレイからすぐに確認を受信しているためですが、すべてのデータ がリンク経由で複製されたわけではなく、一部のデータは書き込み履歴ログのキューに格納され始め ています。これは、障害発生時にデータが消失するリスクがあることを意味します。 より興味深い事実は、100msに関する結果です。アプリケーションに関して顕著なパフォーマンスの違 いは観察されませんでしたが、これは当てにならないデータです。ログに対する大量の記録が発生し ているからです。書き込み履歴ログの使用率については、このセクションの図26の後で説明します。 図25に、2つの複製方式の結果を、1つのグラフに重ね合わせる形で示します。 28 図25 同期と拡張非同期の結果 高帯域幅と小さいリンク遅延を活用できる場合は、同期複製に比べて拡張非同期複製はわずかに 劣ります。この理由として、書き込み履歴ログをディスクに書き込むことと、メモリ内でデータを2回 キャッシングすることが挙げられます。注意すべき主要なポイントは、これらの結果は遅延が6ms前 後に達するまで成り立つことです。 この時点で、非同期複製のパフォーマンスが、同期複製のパ フォーマンスを上回ります。 ベスト プラクティス リンクの遅延が6ms以内で帯域幅が十分な場合は、同期複製を使用することをお勧めします。 拡張非同期複製をテストしている間に、各テスト サイクルの最終工程として、書き込み履歴ログの 利用率に関するメトリックを収集しました。これらのメトリックは、複製先サイトに対してまだ複製さ れていないデータの量を表します。図26では、遅延が0msの4Gbリンクでは0に近い結果を観察で きます（実際には、ログの中に1つか2つのトランザクションが存在していましたが、これらは0の データ消失とみなすことができます）。 29 図26 非同期の書き込み履歴ログ ただし、より正確に言うと、拡張非同期複製が0に近いデータ消失を達成できるのは、帯域幅がワーク ロードに対して十分であり、リンクの遅延が小さい場合です。OC6パイプを経由してワークロードを転送 した場合、ログに6GBのキューが発生し始めたことを観察しました。これは、遅延が20msの場合、17GB に増加しました。最後に、遅延が100msの場合、ログには106GBのデータが記録されました。最悪のシ ナリオとして、この瞬間に障害が発生した場合、106GBのデータが失われる可能性があります。 目標復旧時点は、書き込み履歴ログの中にキューとして書き込まれたデータの量、およびリンク経由 でそのデータの複製を完了させるための所要時間に相関します。各テスト サイクルの終わりに、書き 込み履歴ログを完全にフラッシュするのに要した時間を測定しました（図27）。 30 図27 非同期の目標復旧時点 遅延が0msの4Gb帯域幅を使用した場合は、値は同じく0付近になりました。遅延が0msのOC6パイプ を使用した場合は、ログ内に残っていたデータをフラッシュするのに4分を要しました。遅延を20msに増 やすと、複製を完了するまでの時間は10分に延びました。多くの顧客は、RPOを15分に設定します。上 記と同様のワークロード、帯域幅、リンクの遅延を使用している場合は、拡張非同期複製を使用するこ とにより、そのRPOを達成できます。最後に、遅延を100msに設定した場合、非常に劇的な結果になり ます。各テストで、複製が完了していないデータを処理し終わるまでに、4時間近くを要しました。ログを フラッシュするのに要したこれらの時間は、他のどのデータもリンクを消費していない場合の時間枠 （つまり、各テスト サイクルが完了した時点で、データベースとストレージ アレイに対するワークロード を停止していた）であることに注意してください。仮に他のトラフィックが同じリンクを使用して複製を実 行していた場合、これらの値はさらに増加したことになります。 注記： ワークロードの特性を理解することが重要です。この結果は、それぞれの必要に合った複製ソリューションを決定するため のガイドラインとしてのみ使用してください。 パフォーマンス メトリック データベース サーバは、HP OpenView Operations Performance Managerを使用して監視しました。 OLTPベンチマークは、サーバに負荷をかけるベンチマークであり、このワークロードでは、通常、 サーバが最もボトルネックになりやすい箇所です。このため、サーバを慎重に監視する必要があ ります。図28に、データベース サーバのRACノードのうちの1つのメトリックを示します。これらの結 31 果は、0msの追加遅延を設定した4Gbファイバ チャネル経由での同期複製テストに対応するもの です。このグラフは、16の論理CPU（4基の物理CPU、それぞれがデュアルコアで、ハイパースレッ ド対応）が負荷分散されて協調動作していることを示しています。特定の1基または2基のCPU利 用率が90%で、他が10%であれば、問題があります。しかし、ここではすべてが55%～70%のあい だになるよう完全に負荷分散されています。 図28 各CPUの利用率 Performance Managerには、履歴グラフ機能があります。テスト完了後、過去にさかのぼり、期間を指 定して特定のメトリックのグラフを作成しました。興味深いメトリックの1つが、個々のディスクのスルー プットでした（図29）。このグラフは、細部についての確認は困難ですが、ASMディスク グループ内にあ る8つのEVA LUN（およびRAC voting diskおよびOCR（Oracle Cluster Registry）ディスクとして使用 される2つの付加的なLUN）を示しています。 32 図29 各ディスクのスループット 上部にある4本の折れ線は、データベース ファイルやオンラインREDOログを格納しているプライマリ ASMディスク グループに対して提示された4つのLUNを示しています。これらのLUNで負荷が非常によく 分散されていることは注目に値します。これは、プライマリ ディスク グループに対して提示される4つの LUNに対してASMが非常に巧みにストライピングを行っていることを示しています。グラフ下部にある4本 の折れ線は、ASMバックアップ ディスク グループで使用されるLUNのグラフで、こちらも非常によく負荷 分散されています。グラフの中にあるスパイクは、データベースにおけるログ スイッチを表しています。 これ以外にも多くのサーバ メトリックを監視しましたが、ここでは示しません。その中には、メモリ、 ページング、パブリック ネットワーク、プライベート インターコネクト、グローバル履歴があります。 サーバ環境にはボトルネックとなる単一点はありませんでした。 サーバの監視に加え、EVAPerfを使用したアレイのパフォーマンスの監視も実行しました。これに ついて、HP CFT（Customer Focused Testing）が開発した独自のツールを使用してグラフを作成し、 分析しました。ここでは、以下の基本メトリックに注目します。（EVAPerfのカテゴリによってグルー プ分けしています）。 • Array status（as）— 合計ホスト要求 • Controller status（cs）—CPU利用率 • Data replication tunnel（drt）— ラウンドトリップ遅延 • Host port statistics（hps）— 平均キュー深度、読み込み要求、書き込み要求 33 • Virtual disk group（vdg）— 平均読み込み失敗遅延、平均書き込み遅延、総書き込み、秒当たりMB EVAには重大なボトルネックはありませんでした。複製リンクの遅延が大きくなったとき、それに対応し て同期複製の場合に仮想ディスク グループに対する平均書き込み遅延が大きくなる（および非同期複 製では増加が見られない）ことが予想されますが、実際にそれが確認されました。図30に、遅延が0ms で4Gbのファイバ チャネルをフルに使用したベースライン同期複製テストにおけるArray status（合計ホ スト要求）を示します。理論的なパフォーマンスを計算するための標準的な式（ドライブの台数、ドライ ブの速度、RAIDレベル、書き込みペナルティ、読み取り/書き込み比率）に基づくと、今回のメイン ディ スク グループは毎秒17,000回のI/O（IOPS）を処理する能力があります。今回のデータベース ベンチ マークは、複製テストの目的でストレージ アレイに対して十分強い負荷をかけていました。 図30 合計ホスト要求 このホワイト ペーパーの冒頭で、複製ソリューションで使用できるいくつかの構成について説明しま した。今回のテストでは、構成2（図7を参照）を使用しましたが、これはデータベースを複製するた めに2つのDRグループで構成されているものです。図31に、各DRグループのコントローラのワー クロードを示します。 34 図31 コントローラのステータス 多数のデータベース ファイルを格納しているプライマリ ディスク グループは、DRグループ1に含ま れていて、コントローラAによって管理されています。このコントローラの利用率は80%です。アーカ イブREDOログを格納しているバックアップ ディスク グループはDRグループ2に含まれていて、コ ントローラBによって管理されています。このコントローラの利用率は15%です。複数のデータベー スを複製する場合は、ワークロードが複数のコントローラ間で均一化されるよう、負荷を分散してく ださい。たとえば、データベース2に対応するプライマリ ディスク グループの管理を、データベース 1のレイアウトを反転したコントローラBにする必要があります。 35 ベスト プラクティス 複製は、データベースのパフォーマンスに影響を及ぼすため、状況に応じた管理が必要です。 同期複製は遅延が6ms未満の環境に最適で、0 RPOを実現するために必要です。拡張非同期 複製は、遅延が大きく、高めのRPOが許容できる環境で推奨されるモードです。このプロジェクト の「テスト」（13ページ）で提起した疑問への解答は以下のとおりです。 複製を目的にデータベースを構成するための最善の方法は何か。 • ASMディスク グループ構成に基づき、1つまたは2つのDRグループを使用する必要があります。 • アレイのワークロードが50%未満の場合は、DRグループの数を1つにすることが推奨されます。この 構成は、最も安全な複製ソリューションでもあり、HPの一般的なベスト プラクティスです。 • 同じアレイに複数のデータベースがアクセスしている場合は、データベースごとに1つのDRグルー プを作成しておくと、コントローラ間でのワークロードの均一化に役立ちます。 • オンラインREDOログを分離して独自のDRグループに配置することは避けてください。 複製の方法によって推奨される構成が変わるか。 • いいえ。このプロジェクトで検討した3つの構成については、同期複製も拡張非同期複製もほぼ 同じように動作しました。 • オンラインREDOログを分離して3番目のDRグループに配置することは推奨されません。オンラ インREDOログの複製がデータファイルとともに失敗した場合、完全な復旧が不可能になるこ とがあります。 • 複製方法を選ぶとき、最も重視すべき要素はRPOです。遅延、帯域幅、ワークロード、DRログ ファ イルのサイズ、利用率も決定に必要な要素です。 帯域幅や遅延は複製の動作にどのように影響するか。 • 複製ソリューションの設計を開始する前に、利用できる帯域幅、サイト間リンクのネットワーク遅 延、アプリケーションのスループット、およびワークロードの特性を把握する必要があります。 • 遅延が大きい場合や帯域幅が狭い場合は、拡張非同期複製を使用しなければならないことが あります。 • 拡張非同期複製では、帯域幅が不十分な場合データ消失の危険性が増し、リカバリ ポイント に影響を及ぼす可能性があります。十分な帯域幅と低遅延を維持できる環境では、拡張非 同期複製によりほぼ0 RPOを実現できます。 同期複製はデータベースのパフォーマンスにどのような影響があるか。 • フル4Gbファイバ チャネルからOC6に切り替えた場合のデータベース パフォーマンスの最初の低下 率は18%でした。これは、帯域幅に比べてワークロードがきわめて多くなったために発生しました。 • 20msの遅延では、スループットは引き続き低下し、データベースのパフォーマンスは約27%低 下します。 • 100msでは、ベータベースのパフォーマンスに69%以上と大幅な低下が確認されました。 • ワークロードをサポートするために、リンクの帯域幅を正しくサイジングすることが重要です。同じ ワークロードでOC6からOC9への強化を行ったところ、パフォーマンスは16%改善されました。これ は単により多くのデータがパイプをとおして転送されるようになったためです。 36 • オンラインREDOログのサイズを正しく設定すると、同期モードで複製を行っている場合に、データ ベースのパフォーマンスに効果があります。REDOログのサイズを過度に大きくすると、アプリケー ションに最悪の影響を及ぼし、パフォーマンスは7%低下します。 拡張非同期複製はデータベースのパフォーマンスにどのような影響があるか。 • フル4Gbファイバ チャネルからOC6に切り替えた場合のデータベース パフォーマンスの最初の変 化は無視できる（1%）ものでした。 • 遅延が20msのリンクを使用する場合、スループットに変化はありませんでした。 • 遅延が100msである場合にも、スループットは依然としてベースライン テストと変わりませんで した。ただし、ログに多量のデータがあることが確認されました。これは、リカバリ ポイントに 多大な影響を及ぼします。 • 高速コピーが発生することを防止し、RPOを維持するうえで、書き込み履歴ログを監視することが不 可欠です。遅延0msの4Gbを使用して、ほぼ0のRPOを達成しました。今回のワークロードに対して、 遅延が小さいOC6を使用した場合、ログはそれぞれ7GB以下、および18GB以下にとどまりました。 遅延を100msにした場合、複製されていないトランザクションがログに100GB以上累積されました。 • 書き込み履歴ログをフラッシュするのに要する時間は、ログにあるデータ量と同じ程度に重要で す。遅延0msの4Gbを使用して、ほぼ0のRPOを達成しました。遅延が0msまたは20msのOC6では、 両方とも複製を10分未満で完了できました。遅延100msのOC6を使用した場合は、ログに累積 されたデータの複製を完了するのに4時間近くを要しました。 ストレージ管理者のベスト プラクティス ストレージ管理者は、環境を構築する際、以下のベスト プラクティスを参考にしてください。 • データベース用に、複数のLUNを含む2つ以上のEVAディスク グループを作成します。 • 1つまたは2つのDRグループを作成します。REDOログを分離して3番目のDRグループに配置すること は避けます。オンラインREDOログは、データベース ファイルと同じDRグループに配置してください。 • EVAコントローラ間で複数のDRグループの負荷を分散します。たとえば、DRグループ1をコント ローラAが管理し、DRグループ2をコントローラBが管理します。 • DRグループの書き込み履歴ログのサイズを、RPOをサポートできる適切なものに設定します。ログ がいっぱいになり、高速コピーが強制的に実行されることを避けます。 • サイト間リンクが、複製対象のワークロードにとって適切であることを確認します。 サーバ管理者のベスト プラクティス サーバ管理者は、マルチパスやホストアクセスに注目する必要があります。 • 複数のHBAを使用してパスの可用性を高めパフォーマンスの最適化を行います。2Gbインフラスト ラクチャに対する以前の推奨（強く推奨されていた、ほとんどのワークロードで4ポート以上、DSS/ データ ウェア ハウスの場合は8ポート以上）は、4Gbインフラストラクチャを使用する場合は削減でき ます。より高速な環境では、OLTPの場合は少なくとも2ポート、DSSの場合は4ポートを推奨します。 • パス間でワークロードを負荷分散するために、MPIO（Microsoft Multipath I/O）、セキュア パ ス、内蔵Linuxドライバなどのマルチパス ソフトウェアを使用します。通常、LST（Least Service Time）や同様のマルチパス アルゴリズムにより、基本的なラウンド ロビン（RR）方式を超える最 適なパフォーマンスを得ることができます。 37 • データ ウェアハウス アプリケーションなどで、EVAでのミラー ポートによるパフォーマンス低下を避 けるために、可能な場合（とくに、読み取り操作では）、マスタリング コントローラへのパスを使用し て仮想ディスクへのホスト アクセスを管理します。この操作は、Windows上では、MPIOによる新しい ALB（Automated Load Balancing）を使用して行うことができます。このアクセス方式は厳格なゾーニ ングによっても実現できますが、パス フェールオーバーの妨げになる可能性があります。 • RACをシングル インスタンスに複製する場合は、OCRおよびvoting diskを複製しないでください。 データベース管理者 データベース管理者向けのベスト プラクティスには、ASMディスク グループの正しい構成が含まれます。 • 少なくとも2つのASMディスク グループを作成します。 • ASMディスク グループではEXTERNAL REDUNDANCYを使用します。ASMソフトウェア ミ ラーリングのNORMALまたはHIGHミラーリングは、ハイエンド ストレージ アレイでは不 要です。EVA RAID1の冗長性と仮想ストライピングは、OracleのSAME（Stripe and Mirror Everything）のベスト プラクティスをサポートします。ASMのストライピングを追加すると、 http://h50146.www5.hp.com/products/storage/whitepaper/pdfs/4aa0-9728enw_ja4.pdfで入手でき るホワイトペーパー『Automatic Storage Management機能を持つOracle 10gとHP StorageWorks Enterprise Virtual Arrayのベスト・プラクティスに関するホワイト・ペーパー』で説明されているよう に、ストライピングが2重に行われ最適なパフォーマンスを得ることができます。 • 必要に応じて、各ASMディスク グループに複数のLUNを提示します。ASMの一般的なベスト プラク ティスは、各ASMディスク グループで4つ以上のLUNを使いストライピングを行うことです。 • オンラインREDOログとデータベース ファイルを、最初のASMディスク グループに配置します。 • バックアップ ファイルとアーカイブ ログを2番目のASMディスク グループに配置します。 • 同期複製では、最適なパフォーマンスが達成できるようにオンラインREDOログをサイジングしま す。ログ スイッチの頻度と持続時間によって、アプリケーションのパフォーマンスが低下するこ とがあります。 38 結論 このホワイト ペーパーで示したテスト結果および関連情報により、HPのEnterprise Virtual ArrayとHP Continuous Access EVAを使用するOracle 11gデータベース用のリモート コピー インフラストラクチャの 適切な計画および配備方法が明らかになりました。 プランニングの鍵になる留意点には、リカバリ（RPO）のビジネス要件およびOracle 11gアプリケーショ ンのピーク スループットの特性、具体的にはアプリケーションの書き込み内容コンポーネントの適切な 理解が含まれます。ピーク時の書き込み内容の理解は、リンクの帯域幅のサイズを正しく設定し、許 容できるRPOを保証するための絶対条件です。 サイト間の物理的な距離はリンクの動作とある程度は関連しますが、アプリケーションのパフォーマンス に影響を及ぼす決定的な要素は距離ではなく実際に測定される遅延です。リンク遅延が増大するにつ れて、アプリケーションのパフォーマンスへの悪影響がしだいに増していきます。このホワイト ペーパー では、この影響を測定したいくつかの例を示しています。同期複製を配備する場合は、リンク遅延が小 さいことが絶対条件です。リンク 遅延が大きい場合は、拡張非同期複製を使用する必要があります。 最後に、EVAベースの既存のスタンドアロン（複製が使われていない）インフラストラクチャを、複製が 行われるインフラストラクチャにアップグレードする場合は、重要な留意事項が2つあります。 • 第1に、リンクの導入により遅延が発生し、またローカルEVAの全体的な物理的要求も増大するの で、アプリケーションのスループットが低下します。このホワイト ペーパーでは、このような変化の 予測に役立つ測定値をいくつか紹介しています。 • 第2に、EVAコントローラ間の負荷分散を維持しながら、LUNおよびEVAディスク グループの物理レ イアウトを変更し、リカバリ用のDRグループを正しく構成する必要があります。このホワイト ペー パーでは、物理データ レイアウトの適切な変更方法についても詳しく説明しています。 まとめ これらすべての主要留意事項の理解と対処方法の正確な把握が、HP EVAとHP Continuous Access EVAを使用するOracle 11gアプリケーションの配備成功の鍵になります。ここで説明されテストで実証さ れたテクノロジは、確実に成功に導く完全なガイドとして利用できます。 フィードバックをお寄せください HPでは、さまざまな情報ニーズに応える技術資料を作成するために、フィードバックを必要としています。 お寄せいただいたご意見は有効に活用させていただきます。次のリンクは、このホワイト ペーパーの品 質に関する短いアンケートです。http://www.hpwebgen.com/%20questions.aspx?id=12046&pass=41514. 39 付録A— 部品表 項目 数量 バージョン HP StorageWorks Enterprise Virtual Array 8000（2C12D） 2 6110 （CR0ECAxcsp6110） HP StorageWorks 146GB 15K FC HDD 166 HP03 HP StorageWorks 146GB 15K FC HDD 158 HP03 BF14658244 10 HP03 1 7.00 A/A 2 G4 ストレージ BF14658244 BF1465A693 HP StorageWorks Modular Smart Array 1500cs サーバ ProLiant DL580 − OracleデータベースRACサーバ サイトA HP ProLiant Support Pack 7.90 Red Hat Enterprise Linux AS 4.0 Update 4 Kernel 2.6.9-42.EL Oracle 10g Enterprise Edition 11.1.0.3.0 Oracle Clusterware 11.1.0.3.0 HPホットプラグ対応72GB 10K SAS 2.5インチ ハードディスク ドライブ 4 HP DL580R04 X7140M 2P USサーバ 2 HP X7140M 570/580G4キット 2 HP DL580G4メモリ拡張ボード キット 2 HP 4GB REG PC2-3200 2x2GB DDRメモリ 8 Qlogic SANSurfer 5.0.0 build 14 HP Procurveスイッチ2708 1 HP FC1242SR 4GbデュアルチャネルPCI-e HBA 3 8.01.06.01-fo 1.09 4.00.23 ProLiant DL580 − Oracleデータベース シングル インスタンス サーバ サイトB 1 G3 HP ProLiant Support Pack 7.90 Red Hat Enterprise Linux AS 4.0 Update 4 Kernel 2.6.9-42.EL Oracle 11g Enterprise Edition 11.1.0.3.0 HPホットプラグ対応36GB 15K Ultra320ハードディスク ドライブ 2 インテルX3.00GHz G3プロセッサ 4 HP DL580R03メモリ拡張ボード 2 HP 4GB REG PC2-3200 2x2GB DDRメモリ 8 Qlogic SANSurfer 5.0.0 build 14 HP FC1243DC 4Gb PCI-Xホスト バス アダプタ 4 8.01.06.01-fo 1. 09 4.00.23 ProLiant DL580 − HP OpenView Operations for Windowsサーバ 1 G2 HP ProLiant Support Pack 7.90 Microsoft Windows 2003 Enterprise Edition x32 RC2 SP2 40 項目 数量 バージョン Oracle 10g Client Win32 10.2.0.1 HP OpenView Operations for Windows 7.50、パッチ213、228適用 HP OpenView Smart Plug-in for Unix OS 7.5072 HPホットプラグ対応36GB 15K Ultra320ハードディスク ドライブ 2 インテルX3.00GHz G3プロセッサ 4 HP DL580R03メモリ拡張ボード 2 HP 2GB REG PC2-3200 2x1GB DDRメモリ 8 ProLiant DL580 − HP Fabric Managerサーバ 1 G3 HP ProLiant Support Pack 7.90 Microsoft Windows 2003 Enterprise Edition x64 RC2 SP2 HP Fabric Manager 5.3.0 HPホットプラグ対応36GB 15K Ultra320ハードディスク ドライブ 2 インテルXeon MP X2.85GHz-2MBプロセッサ 4 HPホットプラグ拡張ボード メモリ 2 HP 4096MB PC1600 Reg SDRAMメモリ 8 ProLiant DL580 − Benchmark Factoryサーバ 5 G2 HP ProLiant Support Pack 7.90 Microsoft Windows 2003 Enterprise Edition RC2 SP2 Oracle 11g Client Win32 11.1.0.4.0 Quest Software Benchmark Factory for Databases 5.0.1 HPホットプラグ対応36GB 15K Ultra320ハードディスク ドライブ 2 インテルXeon MP X2.85GHz-2MBプロセッサ 4 HPホットプラグ拡張ボード メモリ 2 HP 4096MB PC1600 Reg SDRAMメモリ 8 ProLiant BL20p − HP Command ViewサーバおよびRapid Deployment Pack 1 G3 サイトA HP ProLiant Support Pack 7.80 Microsoft Windows 2003 Enterprise Edition RC2 SP2 HP StorageWorks Continuous Access EVA 7.0.0 build 070606 HP StorageWorks Command View EVA 7.0.0 build 070606 HP StorageWorks EVAPerf 7.0.0 build 44 インテルXeon 3.06GHzプロセッサ 2 HPホットプラグ対応72GB 15K Ultra320ハードディスク ドライブ 1 Qlogic SANSurfer Qlogic QLA2312ホスト バス アダプタ 5.0.0 build 4 2 9.1.4.15/1.45 Microsoft Storportドライバ パッチ 916048 HP ProLiant Essentials Rapid Deployment Pack - Windows Edition 3.5 (6.8 build 282 SP1) HP MPIO Full Featured DSM for MSA Disk Arrays 1.00.01 HP MPIO DSM Manager 2.00.00 41 項目 数量 バージョン ProLiant BL20p − HP Command Viewサーバ サイトB 1 G3 HP ProLiant Support Pack 7.80 Microsoft Windows 2003 Enterprise Edition RC2 SP2 HP StorageWorks Continuous Access EVA 7.0.0 build 070606 HP StorageWorks Command View EVA 7.0.0 build 070606 HP StorageWorks EVAPerf 7.0.0 build 44 インテルXeon 3.06GHzプロセッサ 2 HPホットプラグ対応72GB 15K Ultra320ハードディスク ドライブ 1 Qlogic SANSurfer Qlogic QLA2312ホスト バス アダプタ 5.0.0 build 4 2 9.1. 3.16 / 1.45 Microsoft Storportドライバ パッチ 916048 HP MPIO Full Featured DSM for EVA Disk Arrays 2.01.00 HP MPIO DSM Manager 2.00.00 SANインフラストラクチャ HP StorageWorksマルチプロトコル ルータ フルモデル（16ポート） 2 5.3.0 HP StorageWorks 4/32 SANスイッチ 4 5.3.0 PacketStorm Hurricane II Network Emulator Analyzer 1 14.2v1 42 付録B— フェールオーバーのテスト プロジェクトのこのフェーズには、フェールオーバーとフェールバックのテストは含まれていませんが、 ここでフェールオーバー ソリューションのサポートに必要な手順を説明します。このプロジェクトの補助 的な概念実証として、フェールオーバーの基本的なテストを行いました。テストは、同期複製モードと非 同期複製モードの両方で行いました。ここでは、「最悪のシナリオ」構成、つまり、100msのネットワーク 遅延を持つOC3リンク経由での拡張非同期複製のテストに注目します。これは、起こりうる最大のデー タ消失量を表します。このシナリオでも、データベースは正常にマウントされ、復旧され、起動しまし た。図32に、クラッシュ時のプライマリ データベースの実際のデータを示します。図33に、フェールオー バー先のデータベースで復旧されたデータを示します。障害発生時、書き込み履歴ログには複製が済 んでいない45GBのデータがありました。ただし、select count(*)はトランザクションの消失を示す 最も正確な方法ではありません。これは、大まかな内容を示すためのものです。 図32 サイト障害前のプライマリ データベース 図33 フェールオーバーとリカバリ後のセカンダリ データベース 前述のとおり、この大幅なデータ消失は、帯域幅が非常に狭く、ネットワーク遅延が大きいリンク経 由で複製が行われたために発生しました。十分な帯域幅のある遅延の小さいリンク経由でワーク ロードの非同期複製を行う場合、ほぼ0 RPOを実現できます。 また、同期複製を用いて行われた同じ内容のフェールオーバー テストでは、期待されるとおり、プライ マリ データベースとバックアップ データベースのテーブルにまったく同じ数の行が存在することが示さ れました （このグラフは掲載されていません）。 フェールオーバーの手順 環境をサイト フェールオーバーに対応させる方法は数多くあります。以下の手順は、このテストで使用 したセットアップ方法です。この方法は、非常に単純に見えますが、きわめて有効に機能し、リカバリ 時間も約10分でした。このような結果を生み出すには、手順2の説明に従って、バックアップ サイト にOracleソフトウェアをインストールし、ダミー データベースを作成する必要があります。この手順 は絶対に必要ではありませんが、これを行っておけばサイト フェールオーバー中の緊急状況で多 くの時間を節約できます。フェールオーバー後にこれらの手順を実行することもできますが、その 場合少なくとも1～2時間はリカバリ時間が余分にかかります。 43 環境の準備 1. プライマリ データベースとASMインスタンスから、spfile（サーバ パラメータ ファイル）に対応する pfile（初期化パラメータ ファイル）を作成します。フェールオーバー リカバリのためには、最新 のpfileのコピーが常に利用可能になっている必要があります。プライマリ データベースまたは ASMの構成に変更を加えたら、必ず、新しいpfileを作成してそのコピーをバックアップ データ ベース サイトに配置してください。 注記： バックアップ サイトでは、プライマリ データベースとASMインスタンスに対応する、最新の整合性のあるpfileを保持し、必要 に応じて更新しなければなりません。サイトで障害が発生する前に、これらのpfileを生成し管理していない場合、バックアッ プデータベースのマウントと起動が不可能になります。 2. バックアップ データベースに対して同じ数のLUNを提示し、プライマリ サイトのものと同じデータ ベースおよびASMインスタンス（同じ名前、同じパスなど）を作成します。この一時データベー スは、LUNのRAWデバイスへのマッピング、正しい権限の割り当て、ユーザー ダンプの送信 先の作成など、フェールオーバーのために必要な構造とファイルを所定の位置に配置する手 段であり、それ以上の役割はありません。LUNのサイズは非常に小さいものでもかまいませ ん。また、どのRAIDレベルでも使用できます。 このデータベースを作成した後、データベースと ASMのインスタンスの両方をシャットダウンしてアレイからのLUNの提示を解除できます。一時 データベースの役割は以上です。 3. pfileを編集して、フェールオーバーに備えるために必要な変更を加えます。たとえば、プライマリ データベースがRACでバックアップ データベースがシングル インスタンスの場合、pfileを変更して クラスタ データベースおよび複数ノードへの参照、ならびに複数のASM参照（+ASM11、+ASM12な ど）を削除する必要があります。また、バックアップ データベースで同じパスを設定しなかった場 合は、pfileのすべてのパス参照を修正する必要があります。 4. 両方のデータベースのバージョンが一致していることを確認します。テストでは、誤って、10.2.0.3 データベースから10.2.0.1データベース構造にフェールオーバーをしようとしました。その結果、マ ウント プロセスで互換性パラメータにエラーが発生しました。それを下位バージョンに修正し ても、データがより新しいバージョンであることを制御ファイルも認識しているので、問題は解 決しませんでした。 これで、障害に対する備えはかなり整いました。サイトで障害が発生したら、以下の手順に従ってバッ クアップ データベースを起動します。 バックアップ データベースを開く 1. バックアップ アレイで、バックアップのCommand View EVAサーバを使用して、DRグループをバッ クアップ アレイにフェールオーバーします。 2. データベースLUNをバックアップ データベース サーバに提示します。フェールオーバーの実行中、 データベースLUNの状態は書き込み禁止から読み取り/書き込みに自動的に切り替わります。 3. バスを再スキャンして、新しいLUNを見つけます（hp_rescan −a）。 4. バックアップ データベース サーバを再起動します。 5. この手順は最も時間がかかり、フェールオーバー プロセスでこの手順が必要となるのは望ましく ありません。しかし、OSは再スキャン後にLUNを認識できるようになりますが、ASMは再起動が行 44 われるまではLUNを使用できません。この問題は、Windows上でもLinux上でも確認されました。こ のプロジェクトに続くテストでは、この問題をさらに詳しく調査し、他の回避策を検討します。 6. 再起動後、以前に作成しコピーしたバックアップpfileを使用してASMインスタンスを手動で起動し ます（startup pfile=’/path/ASMpfilename.ora’）。 • 7. まれに、ASMディスク グループが自動マウントに失敗することがありました。その場合で も、alter diskgroup ASMxyz mountコマンドを使用してASMディスク グループを手動でマウ ントできます。 以前に作成しコピーしたバックアップpfileを使用してデータベースを手動で起動します（startup pfile=’/path/DBpfilename.ora’）。 • 手順5と6は、データベースのサイズとは関係なく、数秒以内に終わります。これは正式な データベースのバックアップとリカバリではないことに注意してください。このソリューションが アレイ ベースの複製であるため、このフェールオーバーは盲目的なデータベース インスタン スのリカバリ以上のものではありません。 8. バックアップ データベースとASMインスタンスを対象に、バックアップpfileから新しいspfileを作 成します。 9. 最後に、必要なアプリケーションをすべてバックアップ データベースにリダイレクトします。 このテストでは、フェールオーバー手順1～8にかかる時間は約10分でした。そのほとんどがデータ ベースサーバの再起動にかかる時間でした。 45 付録C— 略語 2C12D 2コントローラ12ディスク エンクロージャ（EVA構成） ACK 確認応答（acknowledgement） ALB Automated Load Balancing ASM Automatic Storage Management CFT Customer Focused Testing（HP） CPU 中央演算処理装置（central processing unit ） CVEVA Command View Enterprise Virtual Array DBA データベース管理者（database administrator） DR データ複製（data replication） DSS 意思決定サポート システム（decision support system） EVA Enterprise Virtual Array EVAPerf Enterprise Virtual Arrayパフォーマンス監視ツール FATA Fibre Attached Technology Adaptedドライブ Gb ギガビット（gigabit） GB ギガバイト（gigabyte） G2/G3/G4 サーバのジェネレーション モデル（例：DL580G4） FC ファイバ チャネル（Fibre Channel） FCIP インターネット プロトコル上のファイバ チャネル（Fibre Channel over Internet Protocol） HBA ホスト バス アダプタ（Host Bus Adapter） HP-UX Hewlett Packard UNIX I/O 入出力（input/output） IOPS 1秒当たりのI/O（I/Os per second） LUN 論理ユニット番号（logical unit number） Mb メガビット(megabit)。 Mb/s 1秒当たりメガビット（megabits per second）。 MB メガバイト（megabyte） MPIO Microsoft Multipath I/O MPR マルチプロトコル ルータ（multi-protocol router） ms ミリ秒（millisecond） MSA Modular Smart Array OC6およびOC9 オプティカル キャリア（optical carrier）リンク OCR Oracle Cluster Registry 46 OLTP オンライン トランザクション処理（online transaction processing） OVOW HP Open View Operations for Windows PCI Peripheral Component Interconnect pfile 初期化パラメータ ファイル（Oracle） RAC Real Application Clusters RAID redundant array of independent disks RAM random access memory RDBMS relational database management system RDP Rapid Deployment Pack RPO 目標復旧時点（recovery point objective） RTO 目標復旧時間（recovery time objective） SAME Stripe and Mirror Everything（Oracle） SAN ストレージ エリア ネットワーク（storage area network） SGA システム グローバル領域（system global area） spfile サーバ パラメータ ファイル（Oracle） SIM HP Systems Insight Manager TB テラバイト（terabyte）。 TPS 1秒あたりのトランザクション数（transactions per second）。 Vdisk 仮想ディスク（virtual disk）。 WHL 書き込み履歴ログ（write-history log） 47 詳細情報 HP技術情報 • Configuring Oracle ASM hidden parameters for EVA8000 knowledge brief • http://h71028.www7.hp.com/enterprise/cache/429462-0-0-225-121.html • Best Practices for Oracle 10g with Automatic Storage Management and HP StorageWorks Enterprise Virtual Array white paper • http://h71028.www7.hp.com/enterprise/cache/429462-0-0-225-121.html • HP StorageWorks Enterprise Virtual Array configuration best practices — white paper • ftp://ftp.compaq.com/pub/products/storageworks/whitepapers/5982-9140EN.pdf • HP StorageWorks Continuous Access EVA administrator guide • http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01080802/c01080802.pdf • HP StorageWorks Continuous Access EVA planning guide • http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01080818/c01080818.pdf • HP StorageWorks SAN design reference guide • http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00403562/c00403562.pdf HPのソリューションとトレーニング • Customer Focused Testing • http://www.hp.com/go/hpcft • HP & Oracle alliance • http://h71028.www7.hp.com/enterprise/cache/4281-0-0-0-121.html • Network Storage Services • http://h20219.www2.hp.com/services/cache/10825-0-0-225-121.aspx • HP StorageWorks curriculum • http://education.hp.com/curr-storsan.htm HPの製品サイト • Enterprise Class Storage Portfolio • http://h18006.www1.hp.com/storage/enterprisestorage.html • HP StorageWorks 4100/6100/8100 Enterprise Virtual Arrays • http://h18006.www1.hp.com/products/storageworks/eva/index.html • HP StorageWorks 1500cs Modular Smart Array • http://h18006.www1.hp.com/storage/disk_storage/msa_diskarrays/san_arrays/msa1500cs/ index.html • HP StorageWorks Command View EVA Software 48 • http://h18006.www1.hp.com/products/storage/software/cmdvieweva/index.html • HP StorageWorks Continuous Access EVA Software • http://h18006.www1.hp.com/products/storage/software/conaccesseva/index.html • HP ProLiant DL Servers • http://h10010.www1.hp.com/wwpc/pscmisc/vac/us/en/ss/proliant/proliant-dl.html • HP BladeSystem • http://h71028.www7.hp.com/enterprise/cache/80316-0-0-0-121.aspx • B-Series SAN Switches • http://h18006.www1.hp.com/storage/networking/b_switches/san/index.html • HP StorageWorks 400 Multi-Protocol Router • http://h18006.www1.hp.com/products/storageworks/400mpr/index.html • Other Multi-Path Options for HP Arrays • http://h18006.www1.hp.com/products/sanworks/multipathoptions/index.html • Fibre Channel Host Bus Adapters • http://h18006.www1.hp.com/storage/saninfrastructure/hba.html • HP OpenView Operations for Windows • http://h20229.www2.hp.com/products/ovowin/index.html • HP OpenView Performance Manager software • http://h20229.www2.hp.com/products/ovperf/index.html • HP OpenView Smart Plug-in for Windows, Unix, and web servers • http://h20229.www2.hp.com/products/spi/spi_server/index.html • HP StorageWorks Fabric Manager Software • http://h18006.www1.hp.com/products/storageworks/fabricmanager/index.html • HP ProLiant Essentials Rapid Deployment Pack • http://h18013.www1.hp.com/products/servers/management/rdp.html • ProLiant Support Pack • http://h18013.www1.hp.com/products/servers/management/psp/index.html Oracle • Oracle® Database Installation Guide 11g Release 1 (11.1) for Linux • http://download.oracle.com/docs/cd/B28359_01/install.111/b32002.pdf • Oracle® Real Application Clusters Installation Guide 11g Release 1 (11.1) for Linux and UNIX • http://download.oracle.com/docs/cd/B28359_01/install.111/b28264.pdf • Oracle® Clusterware Installation Guide 11g Release 1 (11.1) for Linux • http://download.oracle.com/docs/cd/B28359_01/install.111/b28263.pdf 49 Quest Software • Benchmark Factory® for Databases Database Performance and Scalability Testing • http://www.quest.com/benchmark_factory/ © 2007 Hewlett-Packard Development Company, L.P. 本書の内容は、将来予告なしに 変更されることがあります。Hewlett-Packard Company製品およびサービスに対する 保証については、当該製品およびサービスの保証規定書に記載されています。本書 のいかなる内容も、新たな保証を追加するものではありません。本書の内容につき ましては万全を期しておりますが、本書中の技術的あるいは校正上の誤り、省略 に対して、責任を負いかねますのでご了承ください。 Itanium® は、米国およびその他の国におけるIntel Corporationの商標です。Java™ は、米国におけるSun Microsystems, Inc.の商標です。Linuxは、米国におけるLinus Torvalds氏の登録商標です。MicrosoftおよびWindowsは、米国におけるMicrosoft Corporationの登録商標です。Oracleは、Oracle Corporationおよび関連会社の登録商 標です。UNIXは、The Open Groupの登録商標です。 4AA1-5658JAP、2007年12月 50