高可用性構成でのDB2 V8分散サーバーのライセンス

Paul C. Zikopoulos
カナダIBM
2003年1月

お客様がIBM® DB2® Universal Database™を選ぶのは、DB2 UDBがパフォーマンスに優れ、異種環境にまたがるスケーラビリティーと統合機能を備え、堅牢で、そしてダウン時間 (計画および計画外の両方) が最小限であるためです。この記事では、DB2が提供する高可用性について、様々な文書で説明されているような機能面ではなくライセンスの観点から検証します。

高可用性 (HA) 環境 (計画外のダウンに対応するように設計されている構成) でのDB2のライセンスについて、多くの質問を耳にします。構成の価格をどのように計算するか、何を基準にしてアイドル・スタンバイ・マシンまたはアクティブ・スタンバイ・マシンと言うか、どの製品にどのライセンス方式を使用できるかなどを、お客様が必ずしも理解しているとは言えません。HA環境でのライセンスは、次のようないくつかの質問にどのように答えるかにより決まります。

• インストールしてあるDB2のエディションは何か? DB2 Workgroup Server Edition (DB2 WSE)、DB2 Workgroup Server Unlimited Edition (DB2 WSUE)、またはDB2 Enterprise Server Edition (DB2 ESE) のうちのどれか?
  
  
• インストール済みのDB2のライセンスの種類は何か? ライセンス・オプションには、同時ユーザー (キャパシティー) 単位ライセンス、登録ユーザー・ライセンス、プロセッサー単位ライセンスなどが含まれます。
  
  
• 障害が発生しなかったとき、フェイルオーバー・マシンはどのように使用されるか? 本番のサーバーとしてトランザクションや照会用に使用されるか、または障害が発生したときのためにアイドルで待機状態になっているか?

さらに、専門家は競合製品やIBMの他の分野での自身の経験に基づいて、それぞれいろいろな用語を使うので、話はもっと複雑になります。この記事の目的は、HA環境でDB2 V8サーバーをライセンスする方法を要約し、IBMがDB2でのフェイルオーバー・クラスターを記述するために使用する用語を定義することです。

DB2では、スタンバイ・サーバーとして、アクティブとアイドルという2つの構成を定義しています。

アクティブ・スタンバイ構成とは、すべてのサーバーが、ユーザーのトランザクションや照会に対してサービス提供するDB2データベースを作動可能な状態でそれぞれ独立して持っている構成です。クラスター・サーバーのうちの1台に障害が発生した場合、クラスタリング・ソフトウェアは障害の発生したサーバーのワークロードをクラスター内の残りのサーバーに転送します。アクティブ・スタンバイ・サーバーは自身のワークロードと障害が発生したサーバーのワークロードを処理しなければならないため、このフェイルオーバーにより、アクティブ・スタンバイ・サーバー上のワークロードは実質的に2倍になります。

DB2の世界では、アクティブ・スタンバイ・サーバーとは、ユーザーのトランザクションや照会に対応するように設定されたマシンで、障害時には同じような別のマシンのワークロードを引き受けられるマシンのことです。アクティブ・スタンバイ・マシンは、障害が発生した場合でも、ユーザーのトランザクションや照会用として使用されるため、フルにライセンスされている必要があります。

アクティブ・スタンバイのシナリオを図1に示します。この例では、マシンは物理的に4台 (番号1から4) あり、トランザクションおよび照会のワークロードに使用されます。マシン4に障害が発生し、そのワークロードがフェイルオーバー・パートナーであるマシン3に転送されます。このシナリオでは、マシン3がアクティブ・スタンバイ・マシンです。マシン3はトランザクションおよび照会のワークロード用として常時使用され、マシン4に障害が発生した場合、マシン4のワークロードが単純にマシン3に転送されます。

アイドル・スタンバイ構成とは、フェイルオーバー・クラスター内の最低1台のサーバーが、ユーザーのトランザクションや照会のワークロードに対してサービス提供する作動可能なDB2データベースを持っていない構成のことです。このマシンにはDB2がインストールしてあり、マシンの電源がオンになっているかどうかは関係なく、アイドル状態つまり「有用な」作業を実行していない状態のものです。「有用でない」作業として分類される作業には、フェイルオーバー/HAシナリオでの支援を行う管理作業 (たとえば、ログ出力をサポートするためにデータベースをロールフォワード保留状態にしたり、DB2データベースのフラッシュ・コピーを作成してからこのコピーのデータベース・バックアップを別サーバー上で実行するなどの作業) が含まれます。クラスター・サーバーのうちの1台に障害が発生した場合、クラスタリング・ソフトウェアはそのワークロードをアイドル・スタンバイ・データベース・サーバーに転送します。

アイドル・スタンバイ・シナリオを図2に示します。この例では、マシンは物理的に3台 (番号1から3) あり、トランザクションおよび照会のワークロードに使用されます。マシン3に障害が発生し、そのワークロードがアイドル・パートナーに転送されます。このシナリオでは、新しいマシン (マシン3のワークロードの転送先のマシン) がアイドル・スタンバイ・マシンです。

業界でHAクラスターを記述するその他の用語は、コールド・スタンバイ、ウォーム・スタンバイ、パッシブ・スタンバイ、ホット・スタンバイなど多数あります。

各ベンダーはそれぞれ異なる用語を使用するため、このような用語をDB2での用語に対応付けることはできません。あるベンダーによるアイドル・スタンバイの記述は、DB2のライセンス使用条件に定義されている用語と異なる可能性があります。DB2環境以外で他の用語が見つかった場合は、詳しい記述を入手し、この記事に説明されているDB2用語のアクティブ・スタンバイまたはアイドル・スタンバイと対応付けてみてください。困ったときは、筆者まで連絡してください (paulz_ibm@msn.com)。

まとめ
DB2は強力で、信頼性が高く、スケーラブルで、なおかつどのようなIT環境にでも統合できる機能を提供し、その価値に関して議論の余地はありません。可用性の高いフォールト・トレラント環境用のDB2のライセンス条項はコストを抑えるようになっていて、ユーザーにとっては一石二鳥です。

特記事項
この記事に含まれている情報は、記事の刊行時点のもので、IBMにより予告なく変更されることがあります。この記事の情報は、Linux、UNIX®、およびWindows®用のDB2を対象とします。