目次


高可用性 (HA) 環境における DB2 10.1 分散データ・サーバーのライセンス

Comments

ご注意

本記事で説明するライセンスの許諾条件とパッケージングに関する情報は、参照目的のためにのみ提供されます。DB2 のパッケージングと DB2 のライセンスに基づく権利と義務に関する詳細情報については、DB2 のライセンス契約書をご参照ください。

はじめに

ユーザーが DB2 を選択するにあたっては、価値創出までのスピードが非常に速いこと、様々な環境で拡張性とデータ統合を実現できること、堅牢な機能が提供されること、ダウンタイム (予定されたダウンタイムと不測のダウンタイムを含む) を最小限に抑えられることが評価されています。本記事では高可用性 (HA) 環境において DB2 を使用することについて、DB2 の機能の観点からではなく (本観点については既に記事が作成されています)、ライセンスの許諾条件の観点から説明します。

IBM には、HA 環境において DB2 のライセンスを取得するケースについてユーザーから多くの質問が寄せられています。HA 環境は、不測のシステム停止および予定されたシステム停止に対応するにあたって最適なシステム環境です。通常、ユーザーが HA 環境におけるライセンスの許諾条件について混乱する第 1 の原因は、様々なベンダーが HA 環境において提供するデータベース製品のライセンスの許諾条件が大きく異なるためです。

さらに、HA 環境に関連する様々な用語によっても、混乱が生じています。その例として、「クラスター」という用語が挙げられます。IT 業界では HA 環境そのものを「クラスター」と呼ぶことがあります。IBM では、「クラスター」という言葉を何の注釈もなくそのまま使用することは通常しません。というのも、クラスターという用語は拡張性を実現するためのクラスタリング環境 (InfoSphere Warehouse が提供する、DB2 ベースの Database Partitioning Feature を使用する場合など) のことも指せば、可用性を実現するためのクラスタリング環境 (DB2 と緊密に連携する Tivoli System Automation for Multi-platforms (SA-MP) のクラスタリング・ソフトウェアを使用する場合など) のことも指し、さらには両方の環境 (DB2 pureScale クラスターまたは IBM Smart Analytics を使用する場合など) のことを指すこともあるためです。本記事で「クラスター」という用語を使用する場合は、別段の記載がないかぎり HA 環境を実現するためのクラスタリング環境のことを指します。通常クラスターについて説明する際には、明確な説明を行うために、高可用性や拡張性といったクラスター環境を実現するための目的を明示する必要があります。勿論、ソリューションによっては、1 つのクラスターで拡張性と高可用性の両方を実現するケースもあるため、クラスターで実現しようとする目的を明確に説明することが必要です。

さらに、システムが停止した場合にフェイルオーバー・サーバーとして機能とするサーバーを説明するための用語の使い方によっても、混乱が生じています。このサーバーのことは、「スタンバイ・サーバー」と呼ぶこともあれば、「セカンダリー・サーバー」と呼ぶこともあります。この環境に慣れているユーザーであれば、スタンバイ・サーバーが実行する機能を指す様々な用語について聞いたことがあるでしょう。「アイドル・サーバー」、「アクティブ・サーバー」、「コールド・サーバー」、「ウォーム・サーバー」、「ホット・サーバー」、「パッシブ・サーバー」といった用語が高可用性環境に関連して使用されています。

IBM のソフトウェア・グループ (SWG) では、通常スタンバイ・サーバーのことを説明する際には、「コールド・サーバー」、「ウォーム・サーバー」、および「ホット・サーバー」という用語を使用します。DB2 に関しても、DB2 9.5 以来、これらの用語を使用しています。本記事は DB2 10.1 に基づいて最新情報を提供するために作成されており、DB2 の高可用性環境におけるライセンスの許諾条件を説明します。

また、本記事では、2009 年 10 月に初めて提供され、2012 年 4 月 30 日に発売された DB2 10.1 で大幅に機能改善が行われた DB2 pureScale テクノロジーについても説明しています。DB2 10.1 では pureScale は DB2 Workgroup Edition に含まれ、DB2 Enterprise Edition と DB2 Advanced Enterprise Edition のアドオン・フィーチャーとしても提供されています。

図 1 では、DB2 10.1 の高可用性 (HA) 環境で使用される用語と、各カテゴリーで使用される様々な種類のコンフィギュレーションの例について説明しています。

図 1. DB2 10.1 で高可用性を実現するためのホット・サーバー、ウォーム・サーバー、およびコールド・サーバーの例
Hot: full license required; warm: partial license; cold: no license required
Hot: full license required; warm: partial license; cold: no license required

表 1 は、DB2 の高可用性環境でよく使用される用語とライセンスの許諾条件をまとめたものです。

表 1. DB2 のライセンスの許諾条件に関連する高可用性環境
コールド・サーバーウォーム・サーバーホット・サーバー

データベース・ソフトウェアが、フェイルオーバーを実行するために別のサーバーにインストールされている。

データベース・ソフトウェアが、フェイルオーバーを実行するために別のサーバーにインストールされている。

データベース・ソフトウェアが、フェイルオーバーを実行するために別のサーバーにインストールされている。

本データベース・インスタンスは通常の運用時には起動せず、フェイルオーバーが発生した場合にのみ起動する。また、本データベースは、保守 (Fix Pack の適用やバックアップの実行など) の目的のために短時間起動することがあり、その後サーバーの起動を停止する。

本データベース・インスタンスは起動しており、高可用性を実現するためにのみ (ログの適用やリカバリー処理の実行など) プライマリー・データベースから更新データを受領する場合がある。本スタンバイ・データベースには、エンドユーザーはアクセスしない。

本サーバーはプライマリー・サーバーの可用性を高めるだけでなく、本サーバー自体がプライマリー・データ・サーバーとしてその他のアプリケーションを提供する。障害が発生していない場合でも、エンドユーザーは本スタンバイ・データベースにアクセスする。

通常、DB2 pureScale、High Availability Disaster Recovery (HADR)、またはログ・シッピングの機能を実装しておらず、データベース・マネージャーが起動していないクラスタリング環境で使用されます (以前は HACMP と呼ばれていた PowerHA for AIX クラスターの場合など)。

通常、Read on Standby 機能を使用しない HADR、Q レプリケーション、またはログ・シッピングを伴う環境で使用されます。

通常、ツィン・フェイルオーバーHADR (以下にさらに説明があります)、Read on Standby 機能を使用する HADR、DB2 pureScale、またはレプリケーションを伴う環境で使用されます。

表 1 は、HA 環境の種類ごとに目安となる大まかな基準を説明したものです。なお、本記事の記載内容を理解すれば、詳細内容について理解を深めることができるようになります。高可用性環境において DB2 サーバーのライセンスを取得する方法は、以下の状況によって影響を受けます。

インストール済みの DB2 のエディションはどれか?

インストール済みの DB2 は、DB2 Express-C (なお、DB2 Express-C は「エディション」ではなく、「パッケージ」です)、DB2 Express、DB2 Workgroup、DB2 Enterprise、または DB2 Advanced Enterprise のどれでしょうか?無償の DB2 Express-C の場合は、DB2 Express-C はいかなる種類の HA コンフィギュレーションでも使用することができないことを認識する必要があります。HA 環境を実現する必要がある場合は、最低でも DB2 Express のライセンスを取得する必要があります。DB2 10.1 の全てのエディションは、ホット・スタンバイ・サーバー、ウォーム・スタンバイ・サーバー、およびコールド・スタンバイ・サーバーのコンフィギュレーションに対応することができます (本件については、以下に詳細の説明があります)。このことは、HADR を使用する DB2 Express のお客様にとって非常に好条件と言えます。というのも、DB2 Express 9.7 では、HADR に基づくフェイルオーバーを実現するには、DB2 High Availability Feature を別途取得する必要があったためです。

システム障害が発生しない時点で、スタンバイ・マシンがどのように使用されているのか?

スタンバイ・マシンは、DB2 に基づいてトランザクションとクエリーを行うための本番サーバーとして使用されているでしょうか?本サーバー上の DB2 インスタンスは起動済みでしょうか?インスタンスによって一定のジョブが実行されているものの、その主な目的は HADR のコンフィギュレーションに基づいて障害が発生した場合にリカバリー用のデータベースとして機能するためでしょうか?DB2 pureScale のクラスターを管理していますか?問題なくシステムが稼働している際にスタンバイ・サーバーが行っている処理の内容によって、DB2 サーバーに対してどのようなライセンスを取得すべきかが決まります。

高可用性を実現する必要のある DB2 のプライマリー・サーバーに対してどのライセンス体系を適用したのか?

スタンバイ・サーバーに適用される DB2 のエディションとライセンス体系は、プライマリー・サーバーの DB2 のエディションとライセンス体系に一致する必要があります。例を挙げると、サーバー・ライセンス (または FTL ライセンス) によって DB2 Express のライセンスを取得した場合は、スタンバイ・サーバーに関しては、ホット・サーバーかウォーム・サーバーかにかかわらず、サーバー・ライセンス (または FTL ライセンス) を追加で取得する必要があります。サーバー・ライセンス (または FTL ライセンス) の追加ライセンスの購入が必要とならないのは、スタンバイ・サーバーがコールドの場合に限られます。許可ユーザー・シングル・インスタンス (AUSI) のライセンスに基づいて DB2 Express のライセンスを取得した場合は、ウォーム状態で使用するスタンバイ・サーバーに対しては 5 AUSI ライセンスを取得し、コールド・スタンバイ・サーバーに対してはライセンスを取得する必要はありません。プロセッサー Value Unit (PVU)ライセンスに基づいて DB2 Express のライセンスを取得した場合は、ウォーム・スタンバイ・サーバーに対しては 100 PVU ライセンス取得し (サーバーで使用されているプロセッサー・アーキテクチャーの種類にかかわらず)、コールド・スタンバイ・サーバーに対しては一切ライセンスを取得する必要はありません。

DB2 10.1 サーバーの各エディションとライセンスの取得方法の概要については、「最適な DB2 10.1 のエディションを選択する方法」をご参照ください。DB2 10.1 の様々なエディションのフィーチャー、機能、メリットの比較については、「DB2 10.1 のデータベース・サーバーの様々なエディションの機能を比較する」をご参照ください。

DB2 8.2 以来 IBM はライセンスの許諾条件を何度か変更し、DB2 サーバーで高可用性を実現するためのコストを大きく削減してきました。例を挙げると、DB2 8.2 では DB2 Workgroup のライセンスをお持ちの場合に HADR を使用する場合は、High Availability Feature オプションを購入する必要があり、本フィーチャーを両方のサーバーに適用する必要がありました。DB2 9 でこの条件が変更され、スタンバイ・サーバーで本フィーチャーのライセンスを取得する必要がなくなりました。DB2 9.5 では、IBM は DB2 Workgroup サーバーに関して High Availability Feature オプションを無償で提供しました。既に説明したとおり、DB2 10.1 ではさらにこの条件を広げ、DB2 Express でも High Availability Feature オプションは無償で提供されるようになりました。すなわち、バージョンが新しくなるたびに IBM は以下の条件を通じてユーザーの DB2 の高可用性環境を実現するためのコストを削減する施策を実施してきました。

  • 1 台の物理サーバーが複数の本番サーバーに対するウォーム・スタンバイ・サーバーとして機能していて、それぞれのスタンバイ・サーバー上で稼働する DB2 のエディションも課金体系も同じ場合、DB2 8.2 ではウォーム・スタンバイ・サーバーに対しては 1 つ分だけライセンスを取得すればよくなりました。本ルールは、ウォーム・スタンバイが物理サーバー上の別々のパーティションで稼働している場合であれ、同じパーティションで稼働している場合であれ、適用されます。例えば、無制限の人数のユーザーがアクセスできるように DB2 のホット・サーバーのライセンスを取得した場合、ウォーム・スタンバイ・サーバーには 100 PVU ライセンスを取得する必要があります。5 台のサーバー (PVU 値は 500 PVU) で DB2 Workgroup が稼働していて、各サーバーが HADR クラスター内で同じスタンバイ・サーバーに対してフェイルオーバーを行うように設定されている場合、2,500 PVU ライセンス[ (5 台のサーバー×400 PVU) + (5 台のサーバー×100 PVU) ]ではなく、2,100 PVU ライセンス[ (5 台のサーバー×400 PVU) + (1 台のスタンバイ・サーバー×100 PVU) ]を取得するだけでよくなりました。

  • DB2 9 では、ウォーム・スタンバイ・サーバーまたはコールド・スタンバイ・サーバーのために DB2 のフィーチャー・オプションのライセンスを取得する必要がなくなりました。例えば、DB2 Enterprise サーバーに対して Storage Optimization Feature オプション (XML データ、テーブル、インデックス、一時テーブルなどに対する圧縮機能を提供) を取得し、当該データベースが HADR クラスター内で機能するように設定した場合は、スタンバイ・サーバー上で稼働する DB2 Enterprise に対して 100 PVU を取得するだけでよくなりました。Storage Optimization Feature オプションをスタンバイ・サーバー上で使用するために、追加のライセンス料金を支払う必要はなくなりました。

  • DB2 10.1 では、ウォーム・スタンバイ・サーバーまたはコールド・スタンバイ・サーバーとして機能する DB2 サーバーに対して特定のツールのライセンスを取得する必要がなくなりました。本条件は以下のツールに対して適用されます。

    • DB2 Recovery Expert for Linux, UNIX, and Windows
    • DB2 Merge Backup for Linux, UNIX, and Windows
    • InfoSphere Optim High Performance Unload for Linux, UNIX, and Windows
    • InfoSphere Optim Performance Manager Extended Insight for Linux, UNIX, and Windows
    • InfoSphere Optim Performance Manager Extended Edition for Linux, UNIX, and Windows
    • InfoSphere Optim Performance Manager Enterprise Edition for Linux, UNIX, and Windows
    • InfoSphere Optim Performance Manager Workgroup Edition for Linux, UNIX, and Windows
    • InfoSphere Optim Performance Manager Content Manager Edition for Linux, UNIX, and Windows
    • InfoSphere Optim Configuration Manager for Linux, UNIX, and Windows
    • InfoSphere Optim Query Workload Tuner for Linux, UNIX, and Windows
  • DB2 9 では、HADR が DB2 Workgroup に無償フィーチャーとして含まれるようになりました。さらに DB2 10.1 では、HADR が DB2 Express にも含まれるようになりました。他のベンダーのデータベース製品の条件を見ると、SMB 企業向けのサーバーに対して同様の機能 (DB2 Workgroup または DB2 Express では、提供される HADR テクノロジーに制限は設定されていません) を提供しているベンダーは他に存在しません。

  • DB2 9 では、DB2 の全てのエディションでクラスタリング環境の管理ソフトウェア (Tivoli System Automation for Multi-platforms: Tivoli SA-MP) を無償で取得でき、DB2 サーバーの HA クラスターを構築することができるようになりました。

  • DB2 9.5.では、コールド・スタンバイ・マシンに対してライセンスを取得する必要がなくなりました。一部のベンダーでは HA ソリューションを実現するために 10 日間であればフェイルオーバーを行うことができる権利をメリットとして提供していますが、DB2 では同様のクラスタリング環境に関して日数の制限はありません。さらに、クラスタリング・ソフトウェアも無償で提供されます。DB2 9.5 では Tivoli SA-MP によるクラスタリング・ソフトウェアが DB2 と緊密に連携するようになり、HA クラスターの TCO を削減するための豊富な管理機能を提供するようになりました。

  • DB2 10.1 では、HADR によって最大 3 台のスタンバイ・サーバーをサポートするようになり、複数サイトへのデータのレプリケーションができるようになりました。その結果、DB2 のエディションに含まれる、使いやすく信頼性の高いテクノロジーを使用して高可用性と災害復旧を実現する冗長化ソリューションを実装できるようになりました。

この記事では「サーバー」に対してライセンスを取得する条件について説明していますが、DB2 の全てのエディションではサプキャパシティー・ライセンスの使用が可能で、本ライセンスによって DB2 サーバーが実際に使用しているキャパシティーに対してのみライセンスを購入すればよくなります。IBM が「サーバーの PVU 値に基づいてライセンスを取得する」という説明をする場合は、ユーザーが仮想化テクノロジーを使用している際には、VMware のセッションや LPAR の PVU 値に基づいてライセンスを取得します。PVU に基づくサプキャパシティー・ライセンスと PVU 以外の条件に基づくサプキャパシティー・ライセンスには一定の条件と特別なルールが設定されているため、このような環境で DB2 を実装する前には詳細の条件を理解する必要があります。

DB2 による HA クラスターについては、ライセンス・コストと管理コストの観点からシステム保有の総コスト (TCO) を削減するために様々な変更が行われています。コスト削減のための施策について検討することは非常に重要です。DB2 10.1 のライセンスの許諾条件と HA クラスターの関連性について検討するにあたっては、DB2 の HA 環境で使用される用語に基づいてサーバーの使用例を検討することがまず重要です。既に説明したとおり、DB2 10.1 では 3 種類のスタンバイ・サーバー (ホットウォーム、およびコールド) を想定しています。

ホット・スタンバイ

「ホット・スタンバイ・コンフィギュレーション」とは、全ての物理サーバーと仮想サーバーにおいてユーザーがトランザクションとクエリーを行う DB2 データベースが稼働しているケースを指します。本コンフィギュレーションは「ホット・ホット・クラスター」と呼ばれます (クラスターに含まれる全てのサーバーが常に同じレベルでビジネス業務を処理するため、「アクティブ・アクティブ・コンフィギュレーション」と呼ばれることもあります)。HA クラスターに含まれるサーバーの 1 台で障害が発生するとクラスタリング・ソフトウェアが障害が発生したサーバーのワークロードを HA クラスター内で稼働し続ける 1 台以上のサーバーに移行します。本環境の特徴としては、各サーバーが他のサーバーのバックアップを行う単一のアプリケーションが存在し、達成すべきサービス・レベル・アグリーメント (SLA) が設定されていることが挙げられます。

2 ノードのクラスターの場合、サーバーのうちの 1 台で障害が発生すると、リソースの移行によってホット・スタンバイ・サーバー (メンバー数が 2 の pureScale クラスター内で稼働し続けるマシン) のワークロードロードは 2 倍になります。もともとのワークロードに加えて、障害が発生したサーバーのワークロードも処理する必要があるためです。HA 環境を設定する際には、この状況について留意する必要があります。厳しい SLA を達成するためにあらゆるコンポーネントの配置を行うデータベース管理者 (DBA) は、HA トポロジーを検証のうえ、どのような HA ソリューションを選択すべきか検討する必要があります。

ここまでをまとめると、「ホット・スタンバイ・サーバーと」は通常の運用時にユーザーが行うトランザクションとクエリーをサポートするマシンまたは仮想サーバーのことを指します。同時に、本サーバーは、通常の運用時にユーザーのトランザクションをサポートする他のサーバーのスタンバイ・サーバーとしても機能します。クラスター内のサーバーで障害が発生すると、ホット・スタンバイ・サーバーが障害が発生したサーバーのワークロードを引き継ぎます。しかしながら、スタンバイ・サーバーが通常の運用時に処理している業務を処理し続ける (DB2 pureScale を使用した場合) か、当該業務を継続しない (HADR Read on Standby 機能を使用した場合でプライマリー・サーバーからワークロードを引き継ぐ際にスタンバイ・サーバーの読み取り処理を中断する) かは、重要ではありません。スタンバイ・サーバーを通常の運用時にユーザーのトランザクションやクエリーをサポートするために使用するため、スタンバイ・サーバーに対してはフル・ライセンスが必要になります。図 2 に、2 ノードのホット・スタンバイ・サーバーを使用した HA クラスターの例を示しており、マシン 1 はマシン 2 のホット・スタンバイ・サーバーとして機能し、マシン 2 はマシン 1 のホット・スタンバイ・サーバーとして機能しています。障害が発生した場合は、マシン 2 のワークロードはマシン 1 に移行し、マシン 1 のワークロードはマシン 2 に移行します。

図 2. 2 ノードのホット・スタンバイによる HA クラスター
Machine 1 is a hot standby for machine 2 who is a hot standby for machine 1
Machine 1 is a hot standby for machine 2 who is a hot standby for machine 1

上記の例では、パーティショニングが行われていないマシン 1 とマシン 2 の 2 台のサーバーがあり、通常の運用時にトランザクションとクエリーのワークロードをサポートしています。斜線の付いていないボックスは障害が発生する前の時点でワークロードを処理するデータベースを指し、斜線の付いたボックスは各マシンで障害が発生した際に処理を行うスタンバイ・サーバーを指します。この例では、マシン 2 で障害が発生し、ワークロードがフェイルオーバー・サーバーであるマシン 1 に移行します。マシン 1 はマシン 2 のホット・スタンバイ・サーバーであり、マシン 2 はマシンの 1 のホット・スタンバイ・サーバーです (図をよく見てください。マシン 1 にもマシン 2 にも斜線の付いたボックスが存在します)。このような種類のコンフィギュレーションは通常「高可用性クラスタリング・ペア」、「ツイン・フェイルオーバー・ペア」、「ホット・ホット・ペア」、または「アクティブ・アクティブ・ペア」と呼ばれますが、現在の IT 環境ではよく見られるものです。DB2 でホット・ホット・コンフィギューレーションに基づいて高可用性クラスターを実装するにあたってはいくつかの方法があり、ユーザーのニーズに基づいて、各サーバー上のデータベースが他のデータベースにフェイルオーバーを行うために PowerHA for AIX と HADR を実装することもできれば、Read on Standby 機能を有効化した HADR や Q レプリケーションを実装することもできれば、スナップショット・テクノロジーやディスク・イメージ・コピーによってレポーティングを行うためにホット・スタンバイ環境を構築することもできます。さらには、拡張性と可用性を最大限に高めるために、DB2 pureScale テクノロジーを活用したソリューションを構築することもできます。

既に説明したとおり、図 2 においては通常の起動時にマシン 1 とマシン 2 の両方とも DB2 の本番ワークロード用に使用されています。マシン 2 で障害が発生すると、DB2 のワークロードはマシン 1 に単に移行します。

HADR クラスターがホット・ホット・クラスターとして機能する形態として、様々な形態があります。図 3 の環境を見てみましょう。

図 3. 相互に HADR フェイルオーバーを行うクラスターを利用した、HADR ホット・ホット・クラスター
An HADR hot/hot mutual cluster.
An HADR hot/hot mutual cluster.

図 3 では、パーティショニングが行われていないサーバーA において、データベース A という名称の本番データベースとデータベース B1 という名称の HADR クラスターに含まれるスタンバイ・データベースが稼働しています。さらに、パーティショニングが行われていないサーバーB において、データベース B という名称の本番データベースとデータベース A1 という名称の同じ HADR クラスターに含まれるスタンバイ・データベースが稼働しています。このケースでは、障害が発生していない時点では、サーバーA とサーバーB はそれぞれデータベース A とデータベース B における処理を実行するため、この環境はホット・ホット・コンフィギュレーションと考えられ、両方のサーバーに対してフル・ライセンスの取得が必要になります。

図 3 では、本システム環境内にスタンバイ・データベースが存在しない場合でも、両方のサーバーにフル・ライセンスの取得が必要になることに注目する必要があります。この例では重要なポイントを示しています。DB2 のエディションが稼働する物理サーバーまたは仮想サーバーに対してライセンスを購入済みの場合は、同じ物理サーバーまたは仮想サーバーにおいて同じエディションのスタンバイ・データベースを稼働するにあたっては追加のライセンスは不要です。この条件は、ライセンス体系の種類やスタンバイ・データベースの種類 (ウォームまたはホット) にかかわらず適用されます。例えば、図 3 に示される全てのデータベースにサーバー・ライセンスに基づいて DB2 Express のライセンスを取得する場合、必要となるサーバー・ライセンスは合計で 2 ライセンスです。しかしながら、プライマリー・データベースとスタンバイ・データベースを別々の LPAR 上で稼働している場合は、4 サーバー・ライセンスの取得が必要になります。

図 4 は、DB2 9.7 Fix Pack 1 以降に含まれている HADR の Read on Standby 機能 (HADR スタンバイ・データベースの読み取り機能) を使用した例を示しています。

図 4. Read on Standby 機能を使用した、HADR ホット・ホット・クラスター
An HADR hot/hot cluster due to Read on Standby
An HADR hot/hot cluster due to Read on Standby

図 4 では、クライアントはプライマリー・サーバー (ホット・サーバー) に対して読み取りと書き込みを行うことができる一方で、通常の運用時においてセカンダリ―・サーバー (ホット・サーバー) に対しても読み取りを行うため、本サーバーもホット・サーバーとなり、両サーバーに対してフル・ライセンスの取得が必要になります。ビジネス目的のためにサーバーからデータの読み取りを行う場合は、当該サーバーはホット・サーバーとなります。

図 5 は、HA と拡張性を実現するための、メンバー数が 3 の DB2 pureScale クラスターについて説明しています。

図 5. DB2 pureScale クラスター
A DB2 pureScale cluster.
A DB2 pureScale cluster.

図 5 では、メンバー (トランザクションを処理するマシン) に対しては、DB2 と DB2 pureScale Feature Pack のライセンスを取得するだけです。Cluster Caching Facility (CF) サーバー (上記の例では、通常よく見られるように 2 重化構造を取っています) には、一切ライセンスは必要ありません。この例では、3 つのメンバー間でトランザクションがシームレスに分散されているため、全てのメンバーはホット・サーバーであり、フル・ライセンスの取得が必要になります。

ホット・スタンバイ・マシンにライセンスを取得する際の考慮ポイント

一般的な目安として、ホット・ホット・コンフィギュレーションの各サーバーに対しては、HA クラスターに存在しない場合と同様にライセンスを取得する必要があります。

DB2 10.1 では、サーバー・ライセンス、期間付きサーバー・ライセンス (FTL)、ソケット・ライセンス、許可ユーザー・シングル・インストール (AUSI) ライセンス、およびプロセッサー Value Unit (PVU)ライセンスの 5 種類のライセンス体系が提供されます (一部のライセンス体系は DB2 の特定のエディションに対してのみ提供されます)。以下の情報は、ホット・ホット・クラスターで各ライセンスを取得する際に認識すべき HA 環境におけるライセンスの条件を示したものです。

サーバー・ライセンス (Limited Use Virtual Server License)

サーバー・ライセンスは DB2 9.7 で初めて提供され、DB2 Express サーバーに対してのみ取得することができます。サーバー・ライセンスを使用して DB2 Express サーバーのライセンスを取得する場合は、クラスターに含まれる物理サーバーまたは仮想サーバー (ホットまたはウォーム) ごとに 1 ライセンスを購入するだけです。ライセンスが不要なコールド・サーバーの場合を除いて、HA 環境においては、サーバー・ライセンスに基づいて取得する DB2 Express サーバーのアクティビティー・レベルを考慮する必要はありません。最小ユーザー数は設定されておらず、サーバーの PVU 値などのその他の条件を考慮する必要もないため、非常にシンプルです。ホット・ホット・コンフィギュレーションの場合は、このルールはライセンスの取得条件に一切影響を及ぼさない (両マシンがホット・サーバーであるため) ものの、ウォーム・スタンバイ・コンフィギュレーションの場合は、サーバー・ライセンス (または FTL ライセンス) に適用される条件は他の DB2 のライセンス体系の条件とは異なります。

期間付きサーバー・ライセンス (FTL)

DB2 Express の FTL ライセンスを取得することによって、1 年間 DB2 Express のソフトウェアを使用することができます。本ライセンスは DB2 の他のエディションのライセンスとは異なり、使用期限が設定されたライセンスです。この点を除けば、FTL ライセンスはサーバー・ライセンスと同じ条件 (ホット・コンフィギュレーションにおけるスタンバイ・サーバーに対するライセンスの取得条件を含む) を提供します。

ソケット・ライセンス (Limited Use Socket License)

ソケット・ライセンスは DB2 9.7 で初めて提供され、DB2 Workgroup サーバーに対してのみ取得することができます。ソケット・ライセンスを使用して DB2 Workgroup のホット・スタンバイ・サーバーのライセンスを取得する場合は、プライマリー・サーバーの場合と同様に、物理サーバーまたは仮想サーバーのソケット数に基づいてライセンスを購入するだけです。ホット・ホット・コンフィギュレーションであり、全てのサーバーが通常の処理のために使用されるためです。

例えば、ホット・スタンバイ・サーバーがパーティショニングが行われていないデュアル・コアで 4-way の IBM POWER7 サーバー上で稼働している場合、DB2 Workgroup のソケット・ライセンスを 4 ライセンス購入します。このサーバーの PVU 値が 960 PVU の場合でも、DB2 Workgroup の 4 ソケット・ライセンスを購入することは変わりません。ホット・ホット・コンフィギュレーションの場合で、プライマリー・サーバーがスタンバイ・サーバーと同じ場合は、DB2 Workgroup のソケット・ライセンスが 8 ライセンス (ホット・プライマリー・サーバーに 4 ソケット・ライセンスおよびホット・スタンバイ・サーバーに 4 ソケット・ライセンス) 必要になります。DB2 Workgroup サーバーのライセンスを取得する場合は、まずソケット・ライセンスを検討してください。CPU キャパシティーを追加しても (使用制限内であれば) ライセンスを追加せずに使用できます。

プロセッサー Value Unit (PVU) ライセンス

DB2 の物理サーバーまたは仮想サーバーには、PVU ライセンスを取得することができます。アクティブ・アクティブ・コンフィギュレーションの場合は、ホット・スタンバイ・サーバーの総 PVU 値に基づいてライセンスを取得する必要があります。勿論、使用している DB2 サーバーが HA クラスターに含まれていない場合でも、本番業務をサポートしているため、同じ方法に基づいてライセンスを取得する必要があります。したがって、この点についてはこれまでの条件と変更はありません。

図 3 において 4 コアの POWER7 サーバーを使用していて、各マシンにおいて DB2 Workgroup が稼働している場合は、本ソリューションのために合計で 960 PVU ライセンス (マシン 1 用に 480 PVU ライセンス+マシン 2 用に 480 PVU ライセンス) を取得する必要があります。

許可ユーザー・シングル・インストール (AUSI) ライセンス

AUSI ライセンスが購入可能な DB2 製品に関しては、ホット・プライマリー・サーバーにアクセスする許可ユーザー (AU) の総数に基づいて必要なライセンスを取得する必要があります。さらに、ホット・スタンバイ・サーバーにアクセスするユーザー数についてもライセンスを取得する必要があります (両方のサーバーとも独自のアプリケーションを提供するホット・サーバーであり、お互いのスタンバイ・サーバーとしても機能しているため)。

1 名の AU は、ユーザーの社内外に在籍し、特定の ID を保有する 1 名の個人 (AU は、他のユーザーの代理としてアクセスを行うことのない、アプライアンスまたはアプリケーションのことを指すこともあります) を指します。本ライセンスをインターネット上で提供するソリューション (オンライン・トレーディングのアプリケーションなど) で使用できるのは、エンドユーザーが明確に特定できる場合に限られます。というのも、本ライセンスを適用するにあたっては、各ユーザーを特定する必要があるためです。マルチプレキシングやアクセスを集約するソフトウェアを使用している場合は、そのようなテクノロジーをアクセスのために適用する前のユーザー数を特定のうえ、ライセンス数を決定する必要があります。

サーバーにアクセスするあらゆるユーザーに対して AUSI ライセンスを取得する必要があります。しかしながら、サーバーにアクセスする実際のユーザー数にかかわらず、エディションごとにユーザーの最小数が設定されています。DB2 Express または DB2 Workgroup では、少なくとも AUSI ライセンスを 5 ライセンス取得する必要があります。DB2 Enterprise および DB2 Advanced Enterprise では、サーバーの PVU 値が 100 PVU に達するごとに少なくとも AUSI ライセンスを 25 ライセンス取得する必要があります。つまり、サーバーの PVU 値が 100 PVU に達するごとに、25 AUSI ライセンスのライセンス・パックを購入することになります。

例を挙げると、480 PVU の値が設定された 1 台のサーバーの場合には、PVU 値を 500 PVU に切り上げて最小ユーザー数を決定するため、125 AUSI ライセンスの取得が必要になります。勿論、150 名のユーザーが存在する場合は、最小ユーザー数を超えて実際のユーザー数に基づいてサーバーに対してライセンスを取得する必要があります (この場合は、150 AUSI ライセンスの取得が必要)。AUSI ライセンスはシフト勤務を行うユーザー間では譲渡することはできず (ただし、従業員の退職に基づいてある従業員から別の従業員に譲渡することは可能)、特定のサーバーにアクセスするためにのみ有効です。勿論、図 3 はホット・ホット・コンフィギュレーションの例であり、両サーバーについては個別のサーバーとしてライセンスを取得する必要があるため、本ルールは適用されません。

図 3 において 100 名のユーザーが 2 台の DB2 Workgroup のホット・サーバーにアクセスする必要がある場合は、100 名のユーザーに対して DB2 Workgroup の 200 AUSI ライセンス (2 サーバー×100 AU) を購入する必要があります。これらのユーザーのうちある時点でいずれかのサーバーにアクセスするユーザー数が 12 名しか存在しない場合でも、各サーバーに対して 100 名全員のユーザーがライセンスを取得する必要があります。したがって、この例では 200 AUSI ライセンスの購入が必要になります。

図 3 において DB2 Express または DB2 Workgroup を使用し、社内に 3 名しかユーザーが存在しない場合でも、DB2 Express または DB2 Workgroup の AUSI ライセンスが 10 ライセンス (2 サーバー×5 名の最小ユーザー) 合計で必要になります。DB2 のこれらのエディションで必要となる最小 AUSI ライセンス数の条件を満たす必要があるためです。

既に説明したとおり、図 3 で使用されるサーバーが DB2 Enterprise の場合は、状況が多少異なります。この例において、各サーバーが 4 コアの POWER7 ベースのサーバー (PVU 値が 480 PVU) であると想定します。100 名のユーザーが DB2 Enterprise の両ホット・サーバーにアクセスする必要がある場合は、100 名のユーザーに対して DB2 Enterprise の AUSI ライセンスを合計で 250 ライセンス (2 サーバー×125 AU) 取得する必要があります (DB2 Enterprise サーバーの 100 PVU ごとに 25 ユーザーの最小購入数を満たす必要があるため)。既に説明したとおり、これらのユーザーのうちある時点でいずれかの DB2 サーバーにアクセスするユーザー数が 12 名しか存在しない場合でも、各サーバーに対して 125 ユーザー分のライセンスを取得する必要があります。

ウォーム・スタンバイ

「ウォーム・スタンバイ・コンフィギュレーション」とは、DB2 をインストールした HA クラスターに含まれる 1 台以上の物理サーバーまたは仮想サーバーが通常の運用時にはユーザーのトランザクションやクエリーのワークロードをサポートしないケースのことを指します。サーバーがエンドユーザーにとって「有益な」処理を実行しないため、本コンフィギュレーションを「ウォーム」と呼びます。「有益ではない」と分類される処理 (皮肉なことに、このような処理こそスタンバイ・サーバーが実行する最も有益な処理と言えます) には、フェイルオーバーの際に役立つ管理業務 (データベースをロールフォワード・ペンディング状態に保つことによってログ・シッピングを行うこと、HADR 環境の実現のためにトランザクション・レベルのログ・シッピングを行うこと、バックアップを実行することなど) が含まれます。HA クラスター含まれるサーバーで障害が発生すると、当該サーバーのワークロードはウォーム・スタンバイ・サーバーに移行します。

ウォーム・スタンバイ・コンフィギュレーションに関してよく発生する誤解に、リカバリー処理のためだけにウォーム・スタンバイ・サーバーを使用することはシステム・リソースの無駄であるというものです。このような見方は、このようなコンフィギュレーションに対する理解として間違っています。ウォーム・スタンバイ・サーバーは、スタンバイの役割以外にも様々な役割 (DB2 に関連した役割と DB2 に関連しない役割を含む) を果たすことができます。

例えば、ウォーム・スタンバイ・サーバーにて別の DB2 インスタンスを作成し (DB2 が実行する処理の内容によって、追加で取得すべきライセンスは異なります)、テスト・サーバーとして使用したり、場合によってはその他のワークロードや機能の負荷分散を行うことができます。障害が発生した場合は、これらのワークロード (またはこれらのワークロードが稼働する仮想パーティションに割り当てられたリソース) の処理を抑え、全てのリソースが障害が発生したサーバーのワークロードを処理する環境を構築することによって、上記で説明したホット・ホット・スタンバイ・コンフィギュレーションの際のワークロードの問題を解決することができます。

図 6 は、ウォーム・スタンバイのケースを示しています。これは HADR の「バニラ」コンフィギュレーション (Read on Standby 機能を使用しないコンフィギュレーション) であり、本番用の OLTP 環境をサポートしています。この例では、通常の運用時にはマシン 2 はトランザクションとクエリーのワークロード (図では「Active Work」と記載) のために使用され、マシン 1 はマシン 2 のワークロードのウォーム・スタンバイとして機能しています。マシン 2 で障害が発生すると、マシン 2 の DB2 ワークロードはウォーム・スタンバイ・サーバーであるマシン 1 に移行します。

このケースにおいて、障害が発生する前の時点ではマシン 1 が他の業務を処理している場合は、マシン 2 で障害が発生すると、図 6.で示されるとおり、新規のワークロードの処理を抑えることになります (もしくは、マシン 1 がマシンの 2 のワークロードを同時に処理できるように、もともとのデータベースのサイジングを行います。この設定を行わない場合は、パフォーマンス上の問題が発生します)。

図 6. マシン 2 のワークロードがウォーム・スタンバイ・サーバーであるマシン 1 に移行する、典型的な HADR クラスター
Machine 2's workload is transferred to the warm standby server, machine 1 in this vanilla HADR cluster
Machine 2's workload is transferred to the warm standby server, machine 1 in this vanilla HADR cluster

DB2 の処理の観点からは、通常の運用時にはマシン 2 のみがホット・サーバーとして機能し、マシン 1 上のもう 1 つの DB2 サーバーは HADR のフェイルオーバー・パートナーとして機能するなどウォーム・スタンバイとしてのアクティビティーを実行するため、本コンフィギュレーションは「ホット・ウォーム・コンフィギューレーション」と呼ばれます (場合によっては、「アクティブ・アイドル・コンフィギュレーション」と呼ばれることもあります)。ここで注目すべきことは、システム停止が発生する前の段階ではマシン 1 が DB2 による「有益な」処理を一切実行していないということです。ちなみに、HADR Read on Standby または DB2 pureScale を実装する環境では、スタンバイ・マシン (本マシンはホット・マシンであるため、本来はスタンバイ・マシンと呼ぶことは適切ではありません) が有益な処理を実行しているため、これらのテクノロジーを使用する場合はウォーム・スタンバイやコールド・スタンバイと呼ぶことはできません。

スタンバイ・マシンを活用するにあたって、ユーザーは様々な戦略を立てることができるため、スタンバイ・マシンに関するビジネス上の目標と要件の優先順位を設定する必要があります。例を挙げると、スタンバイ・マシン上に HA 環境を設定すると同時に、スタンバイ・データベースを本番マシンの最新データの読み取り専用マシンとして使用することによって、データベース・コストをより多くのリソースに分散しようとするユーザーも存在します。この環境を構築する場合は、DB2 9.7 Fix Pack 1 以降使用可能となった HADR Read on Standby を使用します。

多くのベンダーでは、データベースの読み取りと最新データへのアクセスを同時に達成することはできません。つまり、データベースの読み取りを行っている最中は、ログのロールフォワードを行うことによって、データを最新の状態に保つことはできません (両方を実行できる場合には、Redo 処理のスピードが遅くなります)。したがって、このような環境においてデータベースを長時間にわたって読み取り専用処理のために提供すると、障害が発生した場合の平均修復時間 (MTTR) が長くなります。これこそ、本コンフィギュレーションで最も回避したい問題と言えます。OLTP のスタンバイ・データベースの読み取り処理についても、同じことが言えます。OLTP データベースはその設計構造上、インデックスの数は最小限に抑えられています。スタンバイ・サーバー上でレポーティングのようなワークロードを起動すると、迅速な検索を実現するために役立つインデックスが存在しないため、スタンバイ・サーバーではいくつかのテーブル・スキャンが発生します。スタンバイ・サーバーでテーブルのフル・スキャンを実行すると非常に多くのリソースが必要になるため、データベースの同期に問題が発生する場合があります。

可用性の要件やワークロードなどによっては、ウォーム・スタンバイはユーザーの環境にとって最適であることもあれば、そうでないこともあります。しかしながら、スタンバイ・サーバーの計画を立てる際には、システム停止の際の MTTR を最小限に抑えるという、HA 環境を構築する際のそもそもの目的を忘れてはいけません。重要な点は、DB2 ではホット・ホット・コンフィギュレーション (DB2 9.7 Fix Pack1 以降に含まれる HADR Read on Standby 機能を含む) と DB2 pureScale を実装できるオプションがあることです。HADR コンフィギュレーションにおいてスタンバイ・サーバーから読み取り処理を行う場合は、当該サーバーはホット・サーバーとみなされます。また、忘れてはならないのは、DB2 の処理の観点からはウォーム・スタンバイ・サーバーは単に待機しているだけのためリソースの無駄であるという考え方は大きな誤解であるということです。ただ、DB2 ソリューションの決定を行う裁量は最終的にはユーザーにあり、DB2 ではあらゆるコンフィギュレーションを構築することができます。

ウォーム・スタンバイ・マシンにライセンスを取得する際の考慮ポイント

DB2 10.1 では、サーバー・ライセンス、期間付きサーバー・ライセンス (FTL)、ソケット・ライセンス、許可ユーザー・シングル・インストール (AUSI) ライセンス、およびプロセッサー Value Unit (PVU) ライセンスの 5 種類のライセンス体系が提供されます (一部のライセンス体系は DB2 の特定のエディションに対してのみ提供されます)。以下の情報は、HA 環境で各ライセンスを取得する際に認識すべき条件を示したものです。

サーバー・ライセンス (Limited Use Virtual Server License)

DB2 9.7 で初めて提供されたサーバー・ライセンスは、DB2 Express サーバーに対してのみ購入することができます。サーバー・ライセンスを使用して DB2 Express のスタンバイ・サーバーのライセンスを取得する場合は、クラスターに含まれる物理サーバーまたは仮想サーバー (ホットまたはウォーム) ごとに 1 ライセンスを購入するだけです (ただし、コールド・スタンバイの場合はライセンスの取得は不要)。最小ユーザー数は設定されておらず、サーバーの PVU 値などのその他の条件を考慮する必要もないため、非常にシンプルです。

つまり、HA クラスター (ホットまたはウォーム) では、サーバーがホットまたはウォームのいずれの場合でも、クラスター内の DB2 Express サーバーごとに 1 サーバー・ライセンスを取得します。

期間付きライセンス (FTL)

FTL ライセンスも、サーバー・ライセンスと同様に DB2 Express に対してのみ取得することができます。DB2 Express の FTL ライセンスは、DB2 Express ソフトウェアを 1 年間の期限付きで利用できる権利を許諾することを除けば、上記で説明したサーバー・ライセンスと同じライセンスの許諾条件を提供します。本ライセンスは DB2 の他のエディションが提供する永続的なライセンスとは異なり、使用期限が設定されたライセンスです。FTL ライセンスに基づいて DB2 Express のライセンスを取得する際には、DB2 Express のサーバー・ライセンスを取得する場合と同様に、クラスターに含まれる物理サーバー (ホットまたはウォーム) ごとに 1 FTL ライセンスを購入するだけです。コールド・スタンバイ・サーバーには、ライセンスは必要ありません。FTL ライセンスには最小ユーザー数は設定されておらず、サーバーの PVU 値などのその他の条件を考慮する必要もないため、非常にシンプルです。

つまり、HA クラスター (ホットまたはウォーム) では、サーバーがホットまたはウォームのいずれの場合でも、クラスター内の DB2 Express サーバーごとに 1 FTL ライセンスを取得します。

ソケット・ライセンス (Limited Use Socket License)

ソケット・ライセンスも DB2 9.7 で初めて提供され、DB2 Workgroup サーバーに対してのみ取得することができます。DB2 Workgroup のソケット・ライセンスをウォーム・スタンバイ用に取得する場合は、物理サーバーまたは仮想サーバーに対して 1 ソケット・ライセンスを取得するだけです。例えば、クラスターがパーティショニングが行われていないデュアル・コアで 4-way の IBM POWER7 サーバー2 台で構成されている場合、プライマリー・サーバーに対しては DB2 Workgroup のソケット・ライセンスを 4 ライセンス購入します。ウォーム・スタンバイ・サーバーに対しては、1 ソケット・ライセンスを追加で購入するだけです。図 6 の例では、ホット・マシンであるマシン 2 用に 4 ソケット・ライセンス、ウォーム・スタンバイ・マシンであるマシン 1 用に 1 ソケット・ライセンス購入するため、合計で 5 ソケット・ライセンスの購入が必要です。

プライマリー・サーバーの PVU 値が 960 PVU の場合でも、DB2 Workgroup のソケット・ライセンスの場合は 4 ライセンスを購入することに変わりありません。DB2 Workgroup サーバーのライセンスを取得する場合は、まずソケット・ライセンスを検討してください。CPU キャパシティーを追加しても (使用制限内であれば) ライセンスを追加せずに使用できます。

プロセッサー Value Unit (PVU) ライセンス

PVU のライセンス体系でライセンスを取得する際には、サーバーで使用されているプロセッサー・コアのアーキテクチャーにかかわらず、DB2 のスタンバイ・サーバーに対して物理サーバーまたは仮想サーバーごとに 100 PVU ライセンスを取得します。例えば、クアド・コアの AMD プロセッサーを 4 つ搭載したサーバーの PVU 値が 800 PVU の場合でも、クアド・コアの POWER7 プロセッサーを 2 つ搭載したサーバーの PVU 値が 960 PVU の場合でも、それぞれのウォーム・スタンバイ・サーバーに、該当する DB2 のエディションの PVU ライセンスを 100 ライセンス取得します。

図 6 においてサーバーが POWER7 サーバーの 4 コア (1 コアあたり 120 PVU) を使用し、各マシン上で DB2 Workgroup が稼働している場合は、本ソリューション用に全体で PVU ライセンスを 580 ライセンス取得する必要があります (マシン 2 用に 480 PVU ライセンス+ウォーム・スタンバイのマシン 1 用に 100 PVU ライセンス)。

許可ユーザー・シングル・インストール (AUSI) ライセンス

DB2 サーバーに対して AUSI ライセンスを取得する場合は、ウォーム・スタンバイ・サーバーに対しては AUSI の最小ライセンス数を取得する必要があります。DB2 Express と DB2 Workgroup の場合は、あらゆるインストール形態で必要な AUSI ライセンスの最小数は 5 ライセンスであるため、ウォーム・スタンバイ・サーバーには AUSI ライセンスを 5 ライセンス購入する必要があります。

図 6 において DB2Workgroup サーバーが、HADR クラスター (ホット・ウォーム・コンフィギュレーション) で機能するように設定が行われており、100 名のユーザーが存在する場合は、100 名のユーザーに対して DB2 Workgroup の AUSI ライセンスを 105 ライセンス取得する必要があります (100 AUSI ライセンス+ウォーム・スタンバイ・サーバー用に 5 AUSI ライセンス)。勿論、ホット・サーバーにアクセスするユーザー数が当該サーバーの AUSI ライセンスの最小数を下回る場合でも、AUSI ライセンスの最小購入数の条件を満たす必要があります。

図 6 で DB2 Enterprise が使用される場合は状況が多少異なり、条件がより複雑になります。DB2 Enterprise では AUSI ライセンスの最小購入数は 100 PVU ごとに 25 AUSI ライセンスです (本条件については、本記事において既に説明があります)。DB2 Enterprise サーバーにおいては、PVU ライセンスに基づいてウォーム・スタンバイ・サーバーのライセンスを取得する場合は 100 PVU ライセンスを取得する必要があるため、この最小購入数の 100 PVU ライセンスを 25 AUSI ライセンスに換算します。AUSI ライセンスに基づいて DB2 Enterprise のウォーム・スタンバイ・サーバーのライセンスを取得する際には、この 25 AUSI ライセンスが最小購入数となります。

例えば、図 6 のサーバーが 2 ソケットの Intel x86 ベースのデュアル・コア・サーバーの場合は、ホット・サーバーの総 PVU 値は 200 PVU になります。DB2 サーバーにアクセスするユーザーが 3 名しか存在しない場合でも、本コンフィギュレーションに対しては全体で 75 AUSI ライセンスを取得する必要があります。DB2 Enterprise のホット・サーバーに対しては 50 AUSI ライセンス (200 PVU÷100 PVU = 2、2×25 AUSI = 50 AUSI) を取得し、ウォーム・スタンバイ・サーバーに対しては 25 AUSI ライセンスを取得する必要があるためです。しかし、図 6 のサーバーが 2 ソケットの POWER7 ベースのデュアル・コア・サーバー (すなわち、本サーバーの総コア数は 4 コア) の場合は、本ホット・サーバーの総 PVU 値は 480 PVU になります。DB2 の本ホット・サーバーにアクセスするユーザーが 3 名しか存在しない場合でも、本コンフィギュレーションに対しては全体で 150 AUSI ライセンスを取得する必要があります。DB2 Enterprise のホット・サーバーに対しては 125 AUSI ライセンス (480 PVU÷100 PVU = 4.8、4.8 を切り上げて 5、5×25 AUSI= 125 AUSI) を取得し、ウォーム・スタンバイ・サーバーに対しては 25 AUSI ライセンスを取得する必要があるためです。

ウォーム・スタンバイ・コンフィギュレーションでよく寄せられる質問は、フェイルオーバーを行うことによってライセンスの取得にどのような影響が発生するのかということです。例えば、パーティショニングが行われていない 4 ソケットのプライマリー・サーバーとパーティショニングが行われていない 4 ソケットのウォーム・スタンバイ・サーバーがそれぞれ 1 台存在し、両方のサーバーで稼働する DB2 Workgroup のライセンスをソケット・ライセンスに基づいて取得する場合、5 ソケット・ライセンス (4 ソケット・ライセンス+1 ソケット・ライセンス) を取得する必要があります。仮にプライマリー・サーバーが停止した場合に、スタンバイ・サーバーがプライマリー・サーバーに変わり、これまでプライマリー・サーバーとして機能していたサーバーが再びオンラインなった時点でスタンバイ・サーバーに変わったとします。この場合、追加のライセンスは必要ありません。この場合でも、本コンフィギュレーションが既存の 5 ソケット・ライセンスでカバーされているためです。

同じ物理マシン上で複数のウォーム・スタンバイ・サーバーを稼働する際には、最初のスタンバイ・サーバーに対してのみライセンスを取得すれば済みます。ただし、その場合全てのライセンスが同じライセンス体系で取得した同じ DB2 のエディションのライセンスである必要があります。ウォーム・スタンバイが同じパーティション内で稼働している場合でも、異なるパーティションまたは仮想化セッション上で稼働している場合でも、本ルールは適用されます。また、ウォーム・スタンバイが同じ HA クラスター内に存在する場合でも、異なる HA クラスター内に存在する場合でも、本ルールは変わりません。したがって、HA 環境でコスト削減を行う方法として、複数のウォーム・スタンバイを合理的な範囲でできるだけ少ない数の物理サーバーに集約することが挙げられます。例を挙げると、ある企業で DB2 Enterprise のウォーム・スタンバイ・サーバーが 10 台存在し (PVU ライセンスでライセンスを取得)、10 台の別々のサーバーにインストールが行われているとします。このコンフィギュレーションで必要となるウォーム・スタンバイ用のライセンスの総数は 1,000 PVU (10×100 PVU) です。本企業が全てのスタンバイ・サーバーを 1 台の物理サーバーに集約すると、必要なライセンス数は 100 PVU のみになります。これは非常に大きなコスト削減につながり、しかもハードウェアの統合によるコスト削減効果 (システム使用率の向上、設置面積の削減、管理の簡略化など) をさらに加味することができます。ウォーム・スタンバイを集約することによってメリットが発生する場合は、できるだけこの方式を採用するよう IBM では推奨しています。

コールド・スタンバイ

「コールド・スタンバイ・コンフィギュレーション」とは、クラスター内の 1 台以上の物理サーバーまたは仮想サーバーが以下の条件を満たすケースを指します。

  • 通常の運用時にユーザーのトランザクションやクエリーのワークロードをサポートする DB2 データベースを含まないこと。

  • 通常の運用時にフェイルオーバーに役立つ管理処理 (データベースをロールフォワード・ペンディング状態に保って HADR を実現することを含む) を一切行わないこと。そもそも、コールド・サーバーは保守 (バックアップの実行や Fix Pack の適用など) の目的のために短時間電源を入れる場合を除いて、電源を入れることすらできません。

図 7 では、コールド・スタンバイのケースについて説明しています。

図 7. マシン 1 がマシン 2 のコールド・スタンバイ・サーバーとして機能するケース
Machine 1 is a cold standby server for Machine 2
Machine 1 is a cold standby server for Machine 2

この例では、通常の運用時にマシン 2 がトランザクションとクエリーのワークロード (図では「Active Work」と記載) をサポートし、マシン 1 上では DB2 のインスタンスは起動していません。場合によっては、本マシンには DB2 はインストールされているものの、パワーオフの状態にあり、障害の発生時にはマシン 1 が起動し、バックアップ・イメージに基づいてある時点のデータにリカバリーを行い、ユーザーのトランザクションのサポートを開始します。別の場合には、マシン 1 が Tivoli SA-MP クラスター (HA を実現するためのクラスタリング・オプションであり、その他の例としては PowerHA for AIX などが含まれる) に含まれているものの、データベース・インスタンスは起動していません。これから分かるように、コールド・スタンバイ・コンフィギューレーションにおいてはホットまたはウォームのスタンバイ・コンフィギュレーションに比べて MTTR がずっと長くなるため、効果的な高可用性ソリューションとは言えません。ただし、本コンフィギュレーションは一部のアプリケーションのニーズを満たす場合があり、ニーズに合致する場合は、DB2 9.5 以降のバージョンでは既に説明した理由に基づいて本ソリューションのコストが大きく下がっています。

コールド・スタンバイ・マシンにライセンスを取得する際の考慮ポイント

DB2 のコールド・スタンバイ・サーバーにはライセンスは不要であるため、ライセンスの許諾条件を考慮する必要は全くありません。スタンバイ・マシンがコールド・マシンかどうかを判断するための目安の判断基準としては、DB2 インスタンスが起動しているかどうかを確認することが挙げられますが、いくつかの例外条件があります。例えば、本番サーバーのスナップショット・イメージを取って、バックアップを実行する目的のためにのみ DB2 のスタンバイ・サーバーを起動し、その後本サーバーの起動を中止した場合は、本サーバーはコールド・スタンバイとみなし、本サーバーに対してライセンスを取得する必要はありません。フェイルオーバーを実行した際にコールド・スタンバイが起動し、ホット・プライマリー・サーバーに切り替わった場合は、当該サーバーに必要なライセンスの数が最初にプライマリー・サーバーとして機能したマシンに取得したライセンスの数と同じかより少ない場合は、追加のライセンスの取得は必要ありません。この条件に当てはまらない場合は、切り替わったホット・プライマリー・サーバーに対して適切な数の追加ライセンスを取得する必要があります。もしくは、プライマリー・サーバーをホット・コンフィギュレーションで起動するよう適切なライセンスを取得済みのサーバーに移行する必要があります。

様々な種類のスタンバイ・サーバーが混在する環境

上記においては、スタンバイ・サーバーが全てホット、ウォーム、またはコールドのいずれかである HA 環境についてのみ説明しました。クラスター内にスタンバイ・サーバーが 1 台しか存在しない場合や、ホット・スタンバイのみをサポートする DB2 pureSale を使用している場合は、この条件が常に当てはまります。しかしながら、HA 環境には同じタイプの可用性のみをサポートするとは限らない様々な種類のスタンバイ・サーバーが存在することもあります。例えば、プライマリーのデータセンターにおいては冗長性を実現する HA 環境が必要なものの、リモートの 2 つ目のデータセンターでは災害復旧を実現する必要がある場合があります。さらに、通常の運用時においては、プライマリー・サーバーの負荷をかけないようにするために読み取りのワークロードを実行する必要がある場合があります。図 8 は、このような要件を最低限満たす特定のアーキテクチャーを示しています。

図 8. 様々な種類のスタンバイ・サーバーが混在する環境
Read/write clients connected to Primary machine, read-only clients connect to hot standby, DB2 logs stored on warm standby servers
Read/write clients connected to Primary machine, read-only clients connect to hot standby, DB2 logs stored on warm standby servers

この例では、マシン 1 上のプライマリー・データベースはログ・シッピングまたは Q レプリケーションを使用して、2 台のローカルのスタンバイ・サーバー (マシン 2 とマシン 3) および 3 台目のリモートのスタンバイ・サーバー (マシン 4) にデータのレプリケーションを行っています。マシン 1 で障害が発生すると、マシン 2 がワークロードを引き継ぎます。マシン 2 でも障害が発生すると、マシン 3 がワークロードを引き継ぎます。通常の運用時にはマシン 2 が読み取りのワークロードのためにも使用されるため、マシン 2 にはフル・ライセンスを取得する必要があります。マシン 3 とマシン 4 は通常の運用時にはエンドユーザーのワークロードを一切処理しないものの、プライマリーからログを受領し、ログの適用を行うために、これらのサーバーに対しては、ウォーム・サーバーとしてライセンスを取得する必要があります。

様々なスタンバイ・サーバーが混在する環境における各スタンバイ・サーバーのライセンスの考慮ポイントについては本記事で既に説明しました。例えば、DB2 Enterprise を使用していて、各マシン (図 8 を参照) がパーティショニングが行われていない 2 ソケットの POWER7 のデュアル・コア・サーバー (1 コアあたりの PVU 値が 100 PVU) である場合は、プライマリー・サーバーに対しては DB2 Enterprise のライセンスとして 400 PVU (4×100 PVU) を取得し、ホット・スタンバイ・サーバーにも 400 PVU ライセンスを取得します。各ウォーム・スタンバイ・サーバーについては、それぞれ 100 PVU ライセンスを追加で取得します。したがって、本環境全体については DB2 Enterprise の PVU ライセンスが 1,000 ライセンス必要になります。

別のケースにおいて、DB2 Enterprise のライセンスを AUSI ライセンスで取得し、マシン 1 にアクセスする許可ユーザーが 88 名存在し、通常の運用時にマシン 2 にアクセスする許可ユーザーが 10 名存在する場合は、プライマリー・サーバーに対しては DB2 Enterprise のライセンスとして 100 AUSI ライセンス (4×25 AUSI) を取得し、ホット・スタンバイ・サーバーに対しても 100 AUSI ライセンス (4×25 AUSI) を取得します。各ウォーム・スタンバイ・サーバーに対しては、25 AUSI ライセンスを追加で取得します。したがって、本環境全体については DB2 Enterprise の AUSI ライセンスが 250 ライセンス必要になります。

本環境 (図 8 を参照) を実装するにあたっては様々な方法が存在するものの、最もシンプルな方法としては、DB2 10.1 の全てのエディションで新規に提供されるようになった HADR Multiple Standby 機能を使用します。この新機能を実装することによって、実績があり使いやすい HADR 機能を活用して、最大 3 台のスタンバイ・サーバーをサポートするプライマリー・サーバーのクラスターを構築することができます (DB2 10.1 より前のバージョンでは、HADR クラスターは 1 台のプライマリー・サーバーと 1 台のスタンバイ・サーバーしかサポートできませんでした)。さらに、各スタンバイ・サーバーは、クラスターに含まれる他のスタンバイ・サーバーの種類にかかわらず、コールド、ウォーム、ホットのいずれの形態を取ることもできます。

HADR 環境においては、プライマリー・サーバーのマシン 1 (図 8 を参照) は、トランザクション境界に達した時点でマシン 2、マシン 3、マシン 4 に対してログ・シッピングを行います。さらに、マシン 2 は Read on Standby 機能を使用して、読み取りのワークロードを処理します。マシン 1 で障害が発生すると、HADR に含まれる TSA 機能によって、自動的にマシン 1 のワークロードがマシン 2 に移行します。ワークロードを引き継いだ時点で、マシン 2 はもともと行っていた読み取りのワークロードの処理を中止し、新規のワークロードの処理のみを実行します。マシン 2 でも障害が発生すると、DBA は通常ワークロードをマシン 3 にフェイルオーバーします。最悪の事態が発生し、マシン 1、マシン 2、およびマシン 3 上のデータを含むプライマリー・サイトの機能が失われると、リモートのスタンバイ・マシンであるマシン 4 に最新のデータが提供されます。ただし、場合によっては、プライマリー・サイトが機能を停止した時点で処理中であったログ・データは失われているかもしれません。

可用性を高めるために

DB2 では HA を実現するための様々なオプションが提供されています。可用性が必要なアプリケーションについては、複数階層 (ブロンズ、シルバー、ゴールドなど) で可用性を実現することをお勧めします。通常、ブロンズに分類されるソリューションではコールド・スタンバイと DB2 クラスターが使用され、シルバーに分類されるソリューションでは DB2 HADR が使用され、ゴールドに分類されるソリューションでは DB2 pureScale のようなホット・スタンバイ・コンフィギュレーションが使用されます。HA ソリューションのオプションとその分類については、表 2 にまとめました。

表 2. 複数階層ソリューションに基づいて HA 要件を達成する際に利用可能な DB2 テクノロジー
ブロンズシルバーゴールド

DB2 のクラスタリング機能

HADR

DB2 pureScale

  • ホット・コールド・コンフィギュレーション

  • 基本的な可用性を実現

  • ほとんどの場合、無償で構築可能

  • 通常 5 分以内でフェイルオーバーを実現

  • ホット・ウォーム・コンフィギュレーション (場合によっては、Read on Standby 機能によってホット・ホット・コンフィギュレーションを実現)

  • 通常 1 分以内の非常に迅速なフェイルオーバーを実現

  • 簡単なセットアップで迅速に可用性を実現

  • スタンバイ・サーバーで必要となるライセンス数を最小限に抑えることが可能

  • データ損失をゼロにできるオプションを提供

  • ホット・ホット・コンフィギュレーション

  • オンライン・フェイルオーバー

  • 稼働を続けるノード上のトランザクションが影響を受けない

  • 通常 30 秒以内の最も迅速なフェイルオーバーを実現

  • オンライン・スケールアウト機能によって、ワークロードの急な増大に対応

常にゴールド・レベルのソリューションが必要とは限りません。全てのアプリケーションに関して 24x7 で可用性を達成する必要があると考えるユーザーもいますが、IBM の幅広い経験ではいつもそれが適切な戦略になるとは言えません。

例えば、あるユーザーにおいて 24x7 の可用性を必要とするミッション・クリティカルなアプリケーションが存在するものの、他のアプリケーションは最大 2 日間システムが停止しても問題ないことがあります。このような場合に、全てのアプリケーションに同じ可用性の条件を適用することが正しいでしょうか?予算が無尽蔵であれば、そうかもしれません。この場合、業務に関連するサービス・レベル・アグリーメント (SLA) に合致する適切なソリューションを選択する必要があります。HA は直線的なコスト曲線を描き、冗長性と可用性を高めると、ハードウェアとソフトウェアのコストもそれだけ増大します。HA の機能を高めると、ソフトウェア以外にもコストの増大する様々な要素 (冗長性機能、ライセンス、消費電力など) が発生します。つまり、全てのソリューションにおいて可用性を最大限に高める必要はなく、スマートな決断に基づいて、適切な HA 要件に基づいて適切なテクノロジーを活用する必要があります。

本記事の対象ではないものの、包括的な説明を提供するために、表 3 において HA と似たソリューションである災害復旧 (DR) のオプションを一覧表にまとめました。HA 環境を構築するために必要なライセンスの許諾条件を考慮のうえ、図 8 で既に説明した考慮ポイントに基づいて DR 環境を構築する必要があります。

表 3. 複数階層ソリューションに基づいて DR 要件を達成する際に利用可能な DB2 テクノロジー
ブロンズシルバーゴールド

Q レプリケーション

HADR 物理レプリケーション

HADR 論理レプリケーション

  • ホット・ホット・コンフィギュレーション

  • ターゲット・データベースに制限なくアクセス可能

  • ソース・サーバーとターゲットにおいて様々なバージョンの DB2 を使用可能

  • データのサブセット化を実現

  • 複数のターゲット・サーバーをサポート

  • オンライン・フェイルオーバー

  • 異なるトポロジーへのレプリケーションが可能。

  • 非同期通信のみをサポート

  • セットアップが複雑になる場合がある

  • DDL はサポートしない

  • ホット・ウォーム・コンフィギュレーション

  • データ損失をゼロにできるオプションを提供

  • 通常 1 分以内の非常に迅速なフェイルオーバーを実現

  • 簡単なセットアップで迅速に可用性を実現

  • DDL と DML のレプリケーションをサポート

  • スタンバイ・サーバーではサーバーの使用用途が限られる

  • 単一のターゲット・サーバーのみをサポート

  • データベース全体のレプリケーションのみを実行

  • 一定の時間遅延に基づいて災害復旧を実現することも可能

  • ホット・ホット・コンフィギュレーション

  • データ損失をゼロにできるオプションを提供

  • オンライン・フェイルオーバー

  • 通常 30 秒以内の最も迅速なフェイルオーバーを実現

  • オンライン・スケールアウト機能によって、ワークロードの急な増大に対応

  • ターゲット・データベースに制限なくアクセス可能

  • 一定の時間遅延に基づいて災害復旧を実現することも可能

  • 複数のターゲット・サーバーをサポート

  • DDL と DML のレプリケーションをサポート

  • ローリング・アップグレード機能を提供

  • 異なるトポロジーへのレプリケーションが可能


ダウンロード可能なリソース


関連トピック

  • DB2 データベース・サーバーの様々なエディションの機能を比較する」 (developerWorks、2012年 5月) を一読することによって、William Kulju、Steven Astorino、および Paul Zikopoulos が作成した比較表を参照しながら、DB2 10.1 のサーバー・ファミリーの基本的なライセンスの許諾条件、機能、フィーチャーの違いを確認することができます。
  • 最適な DB2 10.1 のエディションを選択する方法」 (developerWorks、2012年 5月) を一読することによって、DB2 10.1 の各エディションのユニークな機能について確認することができます。DB2 の各エディションの仕様が詳細に説明され、DB2 の各エディションのユニークな活用事例を参照することができます。
  • DB2 と IBM によるプロセッサー Value Unit (PVU)の価格体系」 (developerWorks、2009年 9月) を一読することによって、新規に提供されるプロセッサー Value Unit に基づいて DB2 のライセンスを取得する方法について確認し、実際の活用事例を参照することができます。
  • developerWorks 上の DB2 for Linux, UNIX, and Windows に関するページで様々な記事やトレーニング資料を確認し、DB2 のスキルを高めるためのその他の資料を参照することができます。
  • コミュニティー向けの無償の DB2 Express-C の情報を確認することができます。
  • developerWorks の Information Management のページで、DB2 の開発者と管理者向けの参照情報を確認することができます。
  • Twitter で developerWorks をフォローすることができます。
  • DB2 for Linux, UNIX, and Windows の無償の試用版をダウンロードすることができます。
  • DB2 を無償で使用することができます。コミュニティー用の無償の DB2 Express-C をダウンロードすることができます。本製品は DB2 Express Edition と同じコア機能を提供し、アプリケーションの構築と実装に役立つ堅牢な基盤を実現します。
  • 最適な方法で IBM 製品の評価を行うことができます。製品の試用版をダウンロードし、製品をオンラインで使用し、クラウド環境で製品を使用し、数時間をかけて SOA Sandbox を利用することによってサービス指向アーキテクチャーを効率的に実装するプロセスについて学ぶことができます。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=844799
ArticleTitle=高可用性 (HA) 環境における DB2 10.1 分散データ・サーバーのライセンス
publish-date=11132012