 |
|
|||||||||||||||||||||||||||||||||||||||||||
DB2 Universal Databaseと可用性の高いデータ保存 |
||||||||||||||||||||||||||||||||||||||||||||
|
2003年10月 |
||||||||||||||||||||||||||||||||||||||||||||
はじめに ミッションクリティカル・ソフトウェアとe-コマースに特化している市場調査会社のStandish Group Internationalは、実際に実験してデータ停止のコストを測定する調査を実施しました。あるトランザクション処理システムについて、このコスト試算を実施したところ、データ停止に伴うコストは、1分当たり約2,500ドル(1)でした。これは、1時間当たりに換算すると約15万ドルです。実際、ピーク営業時間中の停止に伴うコストは、1分当たり7,800ドル、1時間当たり実に46万8,000ドルになります。 システムの常時稼働を必要としているのはオンライン・オークションハウスやオンライン書店だけではありません。Standish Groupは、データ・ウエアハウス・システムのデータ停止関連コストも調査しました。結果は、なんと1分当たり5,800ドル、意思決定支援デリバラブルが生成されるピーク・ロード時には1分当たり6,300ドルでした。カスタマー・リレーションシップ・マネージメント（CRM）、リアルタイム・リスク・アセスメント、サプライチェーン・マネージメント（SCM）、エンタープライズ・リソース・プランニング（ERP）アプリケーションは、会社のデータ・ストリームと連携しています。ビジネス・データの要件が、会社の営業のやり方をどのように変えてきたか、わかりはじめてきたことと思います。 こうした数字は、データ停止が現実となったときに実際に失われるであろう金額について、多分慎重な見方に当たるものであるかもしれません。しかし、今日なぜ、24時間×7日ベースで休むことなくシステムを常時稼働させることにわたしたちが注力しているのか、それなりの説明を提供してくれます。 それにしても、データ停止の機会コストはなぜそれほどまでに高いのでしょうか。今日、データは、これまで以上に、企業の命綱としての性格を強めています。データは、ビジネス・インテリジェンスを構成する生の材料であり、ビジネスをとりまく活動の大部分です。したがって、一瞬でもデータ・アクセスが失われると、ビジネスは窒息し、貴重なリソース（人的および資本投資）が、非効率または使用不能になります。 企業向け市場は、ほんの3年ほど前と比べても大きく様変わりしています。顧客は、それぞれの都合でサービスを要求します。この「あなたを待っていられない」現象に、インターネット接続機能を備えた多様なデバイスの普及 − 常時接続、常時対応 − が加わり、その影響に一層拍車がかかっています。政策も、使用可能データに対する需要を高めました。Basel II（新BIS規制）などの義務的なリアルタイム・リスク評価モデルから、HIPPAAなど医療情報の保存要件についての厳格な基準まで、情報アセットは、ますます、日常の業務実施の確たる一部となっています。 根本的に、使用可能データの基礎は、使用可能なディスク・サブシステム、ネットワーキング・レイヤー、ストレージ・アーキテクチャーにあります。しかし、データ・アセットからどのように「知恵」を活用できるかは、選択するデータ管理ソフトウェアに依存します。IBM DB2® Universal DatabaseTM（DB2 UDB）は、信頼性と可用性を目的に構築されており、営業中 − インターネット上で、これは常時を意味します − 常に稼働します。 ビジネス・データの可用性に影響する2つのタイプのダウンタイムがあります。計画停止は、通常は、データ・ローディング、データ再構成、統計収集など、保守に類するアクティビティーの結果としてデータが使用不能になるオペレーションを指します。DB2 UDB Version 8.1は、管理アクティビティーのための計画停止のほぼすべてを事実上解消する機能を備えています。 計画外停止は、災害、サーバーの故障など、予定外の事象を意味します。この記事では、計画外停止に付随するダウンタイムの削減のための主要アプローチに焦点を当てます。各アプローチそれぞれの長所と短所を比較・対照します。
計画外停止に対応する高可用性クラスタリング クラスターのセットアップ時にプランニングの必要ないくつかの重要項目があります。
表1 − 高可用性ソフトウェアとDB2 UDB
DB2 UDBは、DB2 UDBのサポートするすべてのプラットフォーム上で各ベンダーのクラスタリング・ソフトウェア用に適応する専用のスクリプトとコマンドを提供しています。これらのスクリプトとコマンドを使って、データベース管理者（DBA）は、高可用性クラスタリングに対応する、幅広く柔軟なクラスタリング・シナリオを展開することができます。DB2 UDBでは、区画分割、非区画分割両方のデータベースにフェイルオーバー・クラスタリングを実装することができます。 フェイルオーバー・クラスタリングを実装するときに、DBAが考慮する必要のあるいくつかの要因があります。まず、障害を検出するのに要する時間の量とバックアップ・サーバーへの新しいリソース割り当てに付随する移行時間です。ハートビートを定義するときに、特別な配慮が必要です。たとえば、正常範囲のネットワーク遅延やアプリケーション性能であるにもかかわらず、実際に障害の発生していないサーバーを障害発生サーバーとして識別するようなシナリオを実装したいとは考える人はいません。次の考慮要因は、バックアップ・サーバー上でデータベースが回復するのに要する時間の量です。これは可用性の高い環境（available environment）を構成しようとするときに、おそらく、最大の考慮要因となります。最後に、アプリケーションがタイムアウトしてデータベース・サーバーに再接続するときの所要時間の量もDBAは認識していなければなりません。 HAクラスタリング構成 図1 − 最も一般的なHA構成 DB2 UDBには、高可用性に特別な料金設定があることに留意してください。詳しくは、Paul Zikopoulosの記事『高可用性構成でのDB2 V8分散サーバーのライセンス』を参照してください。 さあ、異なる構成方法それぞれの利点や特徴について、調べてみましょう。 アイドル・スタンバイ アイドル・スタンバイの長所は、フェイルオーバー後も障害発生前と同じ3台のマシンが稼働することです。したがって、フェイルオーバー後の性能低下がありません。 このアプローチの短所は、高コストの印象を与える点です。別のマシンに障害が発生するまで、ただ座して待つマシンを用意しなければならないということです。ただし、注目してほしいのは、アイドル時間の間、このマシンを開発、テストなどの別用途に使う道もあることです。もう一点、システムの全体をケーブル接続するのに一定量の作業が必要になります。当然、経費はかかりますが、DB2 UDBの競争力ある価格のおかげで、実際には、今日市販されている一般的なクラスター化データベースでアクティブ／アクティブ・システムを構成するよりも、DB2 UDBでアイドル・スタンバイ・システムを実装する方が（サーバーとソフトウェア・コストを含めて）経済的です。 図2に、アイドル・スタンバイ高可用性ソリューションの詳細を示します。この例では、3台のマシンが稼働し、4台目がスタンバイ待機しています。マシン番号3に障害が発生し、使用不能になると、そのワークロードがアイドル・マシンに移されます。それまでアイドルだったマシンがマシン3のワークロードとIPアドレスを引き継ぎます。 障害発生マシン（この例ではマシン番号3）に接続されていたエンドユーザーは、既存の接続を失うことになりますが、マシン番号3のIPアドレスは、マシン番号4に継承されています。アプリケーションがマシン番号3に接続するため新しいCONNECTステートメントを発行すると、マシン番号4に接続されることになります。この接続の移行は、エンドユーザーには見えません。エンドユーザーは、移行されたことに気付きません。 ほかのマシン上のエンドユーザーは、この障害にまったく影響を受けません。区画番号1と区画番号2上のデータに引き続きアクセスすることができます。これらの区画上のエンドユーザーは、区画番号3のデータにアクセスしようとしなければ、どのようなかたちでも影響を受けることはありません。 図2 − アイドル・スタンバイ・クラスタリング・ソリューション 名前が示すように、アイドル・スタンバイ構成は、高可用性に関するDB2 UDBライセンシングの条件からいえば、アクティブ／アイドル・セットアップの例に該当します。 アクティブ・スタンバイ 相互テークオーバー 図3の赤い矢印は、相互テークオーバーのためのクラスター・シリーズ定義を表しています。クラスター番号1内では、障害発生後、区画番号1がマシン番号2に移行することになります。マシン番号2に障害が発生した場合は、区画番号2がマシン番号1に移行することになります。クラスター番号2についても、マシン番号3と4、およびそれぞれのデータベース区画の間で、同じことがいえます。 ここで、一点、留意してほしいのは、DB2 UDBがこのシナリオで認識するのは、1つのクラスターであること、つまり、4台のマシンで構成する1つのクラスターであることです。図3には見るとおり2つのクラスターがあるため、少し混乱されるかもしれません。これは、なぜかといえば、これらのクラスターが高可用性クラスターだからです。このシナリオでは、2つの独立したクラスターが定義されています。クラスター番号1に2台のマシンがあり、クラスター番号2にも同様です。DB2 UDBに関しては、たとえ区画分割されたデータベース・システムであるにしても、それぞれ独立しています。 このことは、相互テークオーバー構成の長所の一つを際立たせます。その長所とは、データベース・クラスターのサイズを気にする必要なしに、高可用性フェイルオーバー・シナリオを複製できる点です。たとえば、単一データベース内に、各2ノードの125クラスターがあるシナリオを考えてください。このデータベースの250ノードは、わずか2つのノードでそれぞれ1つのHAクラスターを構成して、各ノードが高可用性環境にあります。図3のストレージ・インタコネクトは、どの時点でも、2つのマシンに接続するだけで済むので、利益をもたらします。このタイプの相互接続は、図3に示すようなすべてのマシンを接続する恐怖のケーブル配線に比べて、低コストで、かなり一般的です。 図3 − 相互テークオーバー・クラスタリング・ソリューション 図3に示すように、区画番号4を定義している論理定義は、障害発生後、マシン番号3に移行します。テークオーバー後、マシン番号3が、区画番号3と区画番号4両方のワークロードを処理します。したがって、区画番号4の所在するディスクは、マシン番号3からアクセス可能でなければなりません。 図3の相互テークオーバー構成は、高可用性に関するDB2 UDBライセンシングの条件からいえば、アクティブ／アクティブ・セットアップの例に該当します。 負荷分散（平衡）相互テークオーバー 負荷分散（平衡）相互テークオーバーを図4に示します。 図4 − 負荷分散（平衡）相互テークオーバー・クラスタリング・ソリューション 相互テークオーバーの例（図3）では、障害発生後に、システムは不均衡になりました。考えてください。最初の時点では、それぞれに1区画の稼働している4つのノードがあります。テークオーバー後は、そのうちの1つのノードが2つの区画を賄うことになります。当然、システムは不均衡になります。クラスター1の性能がクラスター2を凌駕するのは自然です。 負荷分散（平衡）相互テークオーバーでは、各マシン上の区画数は最終的に同じになります。したがって、障害発生の影響はシステム全体に分散されます。これは、非常に重要です。そうした場合に、システム全体にわたってすべてのトランザクションが遅くなるのでしょうか。多分、そうなります。これが問題である場合には、アクティブ／アイドルの構成を使用したい希望もあるかもしれません。しかし、多くのIT部門は、いわゆるサービス・レベル・アグリーメント（SLA）を尊重することを誓約しています。微調整されている環境で、フルキャパシティで実稼働システムが動けば、SLAターゲットを破棄することになるおそれもあります。負荷分散（平衡）相互テークオーバーのアプローチでは、DBAは、複数のマシンにわたってワークロードを均等に分散させることによって、フェイルオーバー後もSLA範囲内に維持されるように、環境を構成することができます。 図4では、マシン番号1に区画1、2、3があり、マシン番号2に区画4、5、6、マシン番号3に区画7、8、9、マシン番号4に区画10、11、12があります。マシン番号4に障害発生後、区画10はマシン番号3に、区画11はマシン番号2に、区画12はマシン番号1にそれぞれ移されます。 しかし、このアプローチの短所は、一目瞭然です。この構成では、ストレージ相互接続を4台のマシンすべてにしなければなりません。さきほどの相互テークオーバーの例で、ストレージ相互接続が必要とされたのは、マシン2台の間でだけでした。今度の構成では、セットアップも少し複雑になります。しかし、障害発生後にも、最終的に均衡化されたシステムが達成されます。これはかならずしも、4台のマシンが稼働していた障害前と同じ性能が達成されるということではありません。3台のマシンしかないのは事実です。しかし、各マシンが等しい負荷を負担しますので、性能は均衡化されます。 負荷分散（平衡）相互テークオーバー構成は、高可用性に関するDB2 UDBライセンシングの条件からいえば、アクティブ／アクティブ・セットアップの例に該当します。ただし、やり方によっては、アクティブ／アイドル実装としてセットアップすることも可能です。 災害時復旧 災害時復旧は、多くの分野にわたります。たとえば、洪水、台風、地震などの自然災害がデータ・センターに被害を及ぼす可能性があります。停電、火災、水道管破裂といったインフラ災害が、起きるかもしれません。ウイルス、人的エラー、破壊工作などのオペレーション災害にも配慮しなければなりません。 サイトに障害が発生することがあっても、適正なプランニングにより、別サイトにデータを保存し、オペレーションを再開することができます。このセクションでは、物理的中断からシステムを保護するためにDBAが実行できるいくつかの異なるアプローチを説明します。 データベース・バックアップの転送 このアプローチを選択するDBAがこのやり方を気に入っているのは、低コストのオプションであることと、最後のデータベース・バックアップまですべてを回復できることが理由です。もちろん、最後にバックアップをとった時点以降のトランザクションはすべて失われることになります。この点が問題になるかどうかは、環境によります。DB2 UDB v7.2で、累積バックアップ、差分バックアップなど、このプロセスをより簡単にする多数の新しい機能が用意されました（ただし、DBAは生成ファイルのすべてにアクセスできなければなりません）。 ログも一緒に転送すれば、このアプローチを強化することができます。そうすれば、他のサーバー上で、最後のバックアップ日付からログの末尾まで、ログを使ってロールフォワードすることができます。このアプローチで、回復できるデータは多くなります。しかし一方で、最後のバックアップからデータベース・ログの最後までロールフォワードする必要があるため、時間は長くなります。また、アクティブ・ログで現在進行しているトランザクションを捕捉する方法はありません。 スタンバイ・データベースへのログ・シッピング ログ・シッピングは、おそらく、スタンバイ・データベースをサポートする最も一般的な方法です。スタンバイ・データベースとは何でしょうか。スタンバイ・データベースは、リモート・サイトのデータベースです。実稼働データベースの完全コピーです。ログ全部が、継続ベースでスタンバイ・データベースにコピーされます。スタンバイ・マシンにログを転送するには、この機能をサポートするアーカイブ・ソリューション、FTPプロトコルを使用するカスタム・スクリプト、あるいはログ・シッピングをサポートするDB2 UDB付属のネーティブuser exitプログラムを使用することができます。 スタンバイ・データベースは、継続的にログを通じてロールフォワードし、最後に正常に転送されたログ・ファイルの時点までの最新性を保証します。1次データベースに障害が発生したときは、単純に、残されたログがあればコピーし、ログの末尾までロールフォワードし、終了します。そのあと、クライアントは、スタンバイ・データベースに接続します。このプロセスを図5に示します。 図5 − ログ・シッピングとDB2 UDB ログ・シッピングはセットアップの仕方も使い方も非常に単純です。これは、災害時復旧戦略としてのこのアプローチの大きな長所の一つです。追加のソフトウェアは要求されません。DB2 UDB付属のすべての機能を使ってネーティブに実装可能です。実稼働システムへの影響は最小限です。トランザクション喪失ゼロ・システムを提供するように、実装することができます。 データのクリティカリティについて心配されている読者には、このアプローチにいくらか不安があることと思います。たとえば、実稼働サイトが実際に何らかの種類の自然災害で破壊されることを考えてください。さらに悪いことに、ちょうどフル・ログが終了したあと、災害時復旧サイトに転送される寸前にこの災害が起きたとします。このシナリオでは、スタンバイ・データベースには、そのフル・ログ、そして、アクティブ・ログに書き込まれたトランザクションがだめになります。データの「ログ喪失」が許容されない場合には、ミラーリング手法（下記参照）を使って、ログ・シッピングを強化することができます。もちろん、格納するトランザクション数を制限するように、ログを設定することもできますが、このアプローチでは、性能のペナルティが生じる可能性があります。欠落トランザクションの影響も、最小化するに留まります。クリティカルなトランザクションが欠落する可能性は依然残ります。 ログ・シッピングのもう一つの短所は、スタンバイ・データベースが実稼働データベースと物理的、論理的に同一でなければならない点です。また、スタンバイ・データベースは、ロールフォワード待機状態にあるため、読み出し操作に利用することはできません。最後に、一部の管理上の変更（たとえば、インデックスの作成）は、ログに反映されません。 トランザクション喪失ゼロをゴールとする、スタンバイ・データベースへのログ・シッピング ログ・シッピングの利益を維持しながら、この懸念に対処するために、今日、多くのシステムは、たとえば、IBMのPeer to Peer Remote Copy （PPRC）®など、何らかの種類の独自規格ミラーリング・システムを展開しています。図6は、図5にこのタイプの機能を追加しています。アーカイブ保存したあとすぐにログを転送する代わりに、ログをミラーリングしています。このケースでは、PPRCが、ログのためだけにディスク・ミラーリングを実装します。このアプローチの長所は、ミラーにデータが格納されることです。実稼働データベース・サイトが実際に破壊された場合に、トランザクション喪失はゼロです。DB2 UDBは、Version 7.2以来、ログ・ミラーリングをサポートしています。 図6 − ログ・シッピングとDB2 UDB −ログ・ミラーリング付き スタンバイ・データベースの初期化を迅速にするために、新しいI/Oサスペンド機能 − スプリット／ミラー・サポートとも呼ばれています − も使用できます。スタンバイ・データベースを頻繁に初期化する必要があるケースも少なくありません。ログに記録されないデータ定義言語（DDL）の変更を頻繁に行うシナリオでは、ログを適用するまえに、新しいスタンバイ・データベースを作成する必要があります。DB2のI/Oサスペンド機能は、これを簡単にします。I/Oサスペンド機能に関連するもう一つの機能は、実稼働システムのバックアップをスタンバイ・データベースにオフロードする機能です。DB2は、スタンバイ・データベースを作成し、そのデータベースを使ってバックアップ・イメージを作成する機能をサポートしています。バックアップの作成に伴うワークロードから実稼働システムを解放します。 ログ・シッピングは、各種タイプの人的エラーからデータを保護する目的にも使用できます。たとえば、DBAが、ログ・ロールフォワード・プロセスに遅延をもたせることができます。営業日の開始時点までしかログをロールフォワードしない、といったことがあるかもしれません。そうした場合、実稼働データベース上のユーザーは、自分がエラーを犯したと認識したら訂正ができる可能性があります。おそらく、実行してはいけない何か大きな削除操作をしてしまった、あるいは無意識にテーブル（表）をdropしてしまったということがあるかもしれません。遅延を持たせてあるので、次のロールフォワード操作を実行するまえに、こうしたエラーから回復することが可能である可能性があり、そうして、人的エラーからデータを保護することができるかも知れません。 Dale McInnis著『The Basics of Log Shipping』は、DB2 UDBによるログ・シッピングの優れた入門書です。データを保護するこの一般的アプローチに関心のある方には、是非一読されることをお奨めします。 スタンバイ・データベースへのレプリケーション 図7 − DB2 UDBに組み込まれたCAPTUREとAPPLYプロセスを使って、スタンバイ・データベースにデータを複製する。 ログ・シッピングに優るレプリケーション使用の利点は、スタンバイ・データベースが読み出し／書き込み（R/W）アクセスに使用可能なことです。ログ・シッピング・シナリオでは、スタンバイ・データベースは、ロールフォワード待機状態にあるため、ユーザーが照会をかけることはできません。実稼働サーバーとしての働きが必要になるまでの間は、レポート・ツールとしてスタンバイ・データベースを活用するのが便利というケースもあります。 また、スタンバイ・データベース上のログの再生として、実質的にデータを複製するため、下層のハードウェアやオペレーティング・システムが実稼働データベースと同じである必要はありません。たとえば、鉄壁の独自規格UNIX®システム上に実稼働システムをホスティングしている環境で、スタンバイ・マシンには低コストのコモディティー・ハードウェアとWindowsベースのレポート・ツールを選択することも可能です。 レプリケーションの使用について、DBAに好まれているもう一つの機能は、DB2 UDBが双方向のレプリケーションをサポートしている点です。これは、データ更新の食い違いに対応する十分なコンフリクト解消戦略を用意したうえで、必要なときには、アプリケーションがスタンバイ・データベース上のデータを更新して、実稼働データベース上でそれを再生できることを意味します。 最後の長所として、データベース全体を複製する必要がありません。DB2 UDBはテーブル・レベルのレプリケーションに対応しているため、すぐに再ロード可能なテーブル（たとえば、サマリーあるいはレポート・テーブル）は除外して、クリティカルなテーブル（たとえば、トランザクション・テーブル）のみを指定して複製することもできます。 レプリケーションを使ってスタンバイ・データベースを維持するアプローチの短所は、レプリケーションが本質的に非同期である点です。このため、サイト災害発生時に一部のトランザクションが再生されない可能性があります。さらに悪いことに、レプリケーション・サイクル前にキューの深さがどれくらいであったか不明のために、どのトランザクションが再生されていないのかがわからないこともあります。それに加えて、ログ・シッピングの場合と同様に、（インデックスの作成など）一部の管理オペレーションが、ログに反映されません。 レプリケーションは、災害時復旧シナリオのためのフェイルオーバーとは異なる問題の解決のために設計されました。この設計目的の相違は、レプリケーションに、ログ・シッピングにはない相当のオーバーヘッドが存在することを意味します。ログの読み込みとステージング・テーブル（表）の作成（CAPTUREコンポーネント）は、実稼働サーバーにワークロードを追加します。その本来の目的のためにレプリケーションを使用している場合には、災害時復旧用に用途を拡張することは理にかなっているかもしれません。ただし、レプリケーションでは、ターゲット・サーバー上への適用を待機するステージング・テーブルのトランザクション数が明確である保証はどこにもないことを常に心に留めておいてください。これはつまり、実際にどれだけの数のトランザクションが喪失される可能性があるか、最大値を予測するためのテストを実行する必要があるということです。この最大値を受け入れるときに、現実の障害が発生したときに、予測が外れる可能性も受け入れなければなりません。ワークロードが変化して、追加のテストも行われていません。そうなったときに、喪失トランザクションの予測に確信がもてるでしょうか。ログ・シッピングには、ログのサイズがあります。また、さらに良いものとしては、PPRCなどトランザクション喪失ゼロを保証する技術も使えます。 リモート・ミラーリング おそらく、究極のソリューションは、図8に示すように、すべて − データとログ − を同期的にリモート・ミラーリングすることでしょう。リモート・ミラーリングでは、「ブリック・アンド・モルタル」あるいはローカルを越えて、遠隔地の災害用サイトにログとデータを転送します（実稼働サーバーとスタンバイ・サーバーが隣接する2つの建物に配置されている場合には、災害時復旧計画としては、それほど有意義ではありません）。リモート・ミラーリングにはいくつかのアプローチがあります。 図8 − 災害時復旧にリモート・ミラーリングを使用 可用性にフォーカスしたハードウェアとソフトウェアを組み合わせることで、万能の可用性を実現することができます。たとえば、IBM Enterprise Storage ServerR（ESS）とRAMAC® Virtual Arrayシステムの組み合わせは、ストレージ・サブシステム経由でデータとログの両方をミラーリングする機能を提供します。これは経費のかかるアプローチですが、最高水準の可用性を達成する必勝法です。この「データ喪失ゼロ技術」タイプの実装には、このほかに、EMCによるCLARiiON with SRDF、日立のHDSなどがあります。 このアプローチでは、データベースに関連するすべてのデータがリモート・サイトにミラーリングされます。障害発生時には、ミラーリングされたディスクがリモート・サイトにマウントされます。DB2が起動し、クラッシュ・リカバリーを実行します。これは、単純なアプローチですが、次の理由でコスト高となることもあります。
要約 どの可用性ソリューションを選択するにせよ、投資する金額がいくらであるにせよ、あるいは部門の所要するスキル・セットがどんなものであるにせよ、高可用性プランにクリティカルな1つの重要な要素があります。実地演習です。現実にクラッシュあるいはサーバー・ダウンが生じたときが、「準備が万全」かどうかを確認する初めての経験、ということがないようにしてください。
IBM、AIX、DB2、DB2 Universal Database、Enterprise
Storage Server（ESS）、High Availability Cluster Multiprocessing（HACMP）、High
Availability Geographic Cluster（HAGEO）、RAMACおよびTivoliは、米国、その他の国または両方におけるIBM
Corporationの商標または登録商標です。  原文はこちら
|
||||||||||||||||||||||||||||||||||||||||||||
