高可用性(HA)環境においてDB2 10.5の分散データ・サーバーのライセンスを取得する方法

高可用性環境を構築するために、IBM DB2 for Linux, UNIX, and Windowsのバージョン10.5のライセンスを正確に取得する必要がありますか?製品発表レターやライセンスの許諾条件を正しく理解したいとお考えですか?本記事は、2013年6月14日に提供が開始されたDB2 10.5についてわかりやすく説明します。

Amyris Rada, Senior Information Developer, DB2 for Linux, UNIX, and Windows, IBM

Amyris RadaAmyris Radaは、カナダのオンタリオ州マーカムにあるIBMカナダ研究所でDB2 for Linux, UNIX, and Windows担当のシニア・ライターを務めています。1998年よりDB2のチームに属し、パートナー・イネーブルメント、品質保証、インフォメーション・デベロップメントなどさまざまな業務に携わっています。シモン・ボリバル大学でコンピューター・エンジニアリングの学位を取得。現在DB2のインフォメーション・センターに関するいくつかのコンテンツ領域を担当し、DB2のベストプラクティスの構築に取り組んでいます。最近の共著として、「Best practices: Physical database design for online transaction processing (OLTP) environments」および「DB2 best practices: Physical database design for data warehouse environments」があります。IBMで業務を行う前には、AmyrisはKL GroupとINTERGRAPHで勤務していました。



Roman Melnyk, B., DB2 Information Development, IBM Canada, Ltd.

Roman MelnykRoman B. Melnykは、シニア・スタッフとしてDB2のインフォメーション・デベロップメント・チームに属しています。Romanが編集を行った書籍には、「DB2 10.5 with BLU Acceleration: New Dynamic In-Memory Analytics for the Era of Big Data (McGraw-Hill, 2013)」、「Harness the Power of Big Data: The IBM Big Data Platform (McGraw-Hill, 2013)」、「Warp Speed, Time Travel, Big Data, and More: DB2 10 for Linux, UNIX, and Windows New Features (McGraw-Hill, 2012)」、および「Apache Derby - Off to the Races (Pearson Education, 2006)」があります。共著としては、「DB2 Version 8: The Official Guide (Prentice Hall Professional Technical Reference, 2003)」、「DB2: The Complete Reference (Osborne/McGraw-Hill, 2001)」、「DB2 Fundamentals Certification for Dummies (Hungry Minds, 2001)」、および「DB2 for Dummies (IDG Books, 2000)」があります。



2014年 2月 26日

はじめに

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

IBMには、HA環境においてDB2のライセンスを取得するケースについてユーザーから多くの質問が寄せられています。通常ユーザーがライセンスの許諾条件について混乱する第1の原因は、さまざまなベンダーがHA環境用に提供するデータベース製品のライセンスの許諾条件が大きく異なることにあります。

さらにHA環境に関連するさまざまな用語によっても、混乱が生じています。その例として、「クラスター」という用語が挙げられます。IT業界ではHA環境そのものを「クラスター」と呼ぶことがあります。「クラスター」という言葉はさまざまな意味を持つため、IBMでは、何の注釈もなくそのまま使用することは通常しません。というのも、クラスターという用語は拡張性を実現するためのクラスタリング環境(DB2 Advanced Enterprise Editionを使用する際に利用可能なパーティショニングが行われたデータベース環境)のことも指せば、可用性を実現するためのクラスタリング環境(DB2と緊密に連携するTivoli System Automation for Multi-platformsのクラスタリング・ソフトウェアを使用する場合)のことも指し、さらには両方の環境(DB2 pureScaleクラスターまたは IBM Smart Analytics Systemを使用する場合など)のことを指すこともあるためです。本記事で「クラスター」という用語を使用する場合は、別段の記載がないかぎりHA環境を実現するためのクラスタリング環境のことを指します。

通常クラスターについて説明する際には、明確な説明を行うために、高可用性や拡張性といったクラスター環境を実現するための目的を明示する必要があります。もちろんソリューションによっては、1つのクラスターで拡張性と高可用性の両方を実現するケースもあるため、クラスターで実現しようとする目的を明確に説明することが必要です。

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

IBMのソフトウェア・グループ(SWG)では、通常スタンバイ・サーバーのことを説明する際には、「コールド・サーバー」、「ウォーム・サーバー」、および「ホット・サーバー」といったサーバーのアクセス頻度に基づく用語を使用します。DB2 に関しても、DB2 9.5以来これらの用語を使用しています。

本記事は2013年6月14日に提供が開始されたDB2 10.5に合わせて改訂されたもので、DB2 の高可用性環境におけるライセンスの許諾条件を詳しく説明します。また本記事では、DB2 10.5で大幅な機能改善(フィックスパックのアップデート、DB2 pureScaleインスタンスと通常のDB2インスタンス間のバックアップとリストア機能、およびHADR機能など)が行われたDB2 pureScaleテクノロジーについても説明しています。DB2 10.5ではDB2 pureScaleはDB2 Developer Edition、DB2 Advanced Workgroup Edition、およびDB2 Advanced Enterprise Editionに含まれています。

図1は、DB2 10.5の高可用性(HA)環境において使用されるコンフィギュレーションの例(サーバーのアクセス頻度に基づいて分類)を示しています。

図 1. アクセス頻度別にHAを実現するDB2 10.5データベースを分類する
アクセス頻度別にHAを実現するDB2 10.5データベースを分類する

表 1 は、HA環境でよく使用される用語をDB2のライセンスの許諾条件に基づいて分類したものです。

表 1. 高可用性環境でよく使用される用語をDB2のライセンスの許諾条件に基づいて分類する
ホットウォームコールド
データベース・ソフトウェアが、フェイルオーバーを実行するために別のサーバーにインストールされている。データベース・ソフトウェアが、フェイルオーバーを実行するために別のサーバーにインストールされている。データベース・ソフトウェアが、フェイルオーバーを実行するために別のサーバーにインストールされている。
本サーバーはプライマリー・サーバーの可用性を高めるだけでなく、本サーバー自体がプライマリー・データ・サーバーとしてその他のアプリケーションを提供する。障害が発生していない場合でも、エンドユーザーは本スタンバイ・データベースにアクセスする。本データベース・インスタンスは起動しており、高可用性を実現するためにのみ(ログの適用やリカバリー処理の実行など)プライマリー・データベースから更新データを受領する場合がある。本スタンバイ・データベースには、エンドユーザーはアクセスしない。本データベース・インスタンスは通常の運用時には起動せず、フェイルオーバーが発生した場合にのみ起動する。また本データベースは、保守 (フィックスパックの適用やバックアップの実行など)の目的のために短時間起動することがあり、その後サーバーの起動を停止する。
通常、2ノードでフェイルオーバーを実現するHADR(以下にさらに説明があります)、スタンバイ・サーバー上で読み取り機能 (Read on Stanby) を提供するHADR、DB2 pureScale、またはレプリケーションを伴う環境で使用されます。通常、スタンバイ・サーバー上で読み取り機能を提供しないHADR、Q レプリケーション、またはログ・シッピングを伴う環境で使用されます。通常、DB2 pureScaleやHADR、あるいはログ・シッピングの機能を実装しておらず、DB2のインスタンスが起動していないクラスタリング環境で使用されます(以前はHACMPと呼ばれていた PowerHA for AIXクラスターの場合など)。

HA環境においてDB2サーバーのライセンスを取得する方法は、以下の条件によって影響を受けます。

インストール済みのDB2のエディションはどれか?
インストール済みのDB2は、DB2 Express-C、DB2 Express、DB2 Workgroup、DB2 Enterprise、DB2 Advanced Workgroup、または DB2 Advanced Enterpriseのどれでしょうか?無償のDB2 Express-Cは、いかなる種類のHAコンフィギュレーションでも使用することができないことを認識する必要があります。HA環境が必要な場合は、最低でも DB2 Express のライセンスを取得する必要があります。DB2 10.5のすべてのエディションは、ホット・スタンバイ・サーバー、ウォーム・スタンバイ・サーバー、およびコールド・スタンバイ・サーバーのコンフィギュレーションに対応することができます(本件については、以下に詳細の説明があります)。このことは、HADRを使用するDB2 Expressのユーザーにとって非常に好条件と言えます。というのも、DB2 Express 9.7でHADRに基づくフェイルオーバーを実現するには、Express Edition用にDB2 High Availability Featureのライセンスを別途取得する必要があったためです。
高可用性を実現する必要のあるDB2のプライマリー・サーバーに対してどの課金体系を適用したのか?
スタンバイ・サーバーに適用するDB2のエディションと課金体系は、プライマリー・サーバーのDB2のエディションと課金体系と一致する必要があります。例を挙げると、Limited Use Virtual Serverライセンス(以降サーバー・ライセンスと記載)、またはFTLライセンスによってDB2 Expressのライセンスを取得した場合は、スタンバイ・サーバーに関しては、ホット・サーバーかウォーム・サーバーかにかかわらず、サーバー・ライセンス(またはFTL ライセンス)を追加で取得する必要があります。スタンバイ・サーバーがコールドの場合は、サーバー・ライセンス(または FTL ライセンス)は必要ありません。許可ユーザー・シングル・インストール(AUSI)ライセンスに基づいてDB2 Expressサーバーのライセンスを取得した場合は、ウォーム状態で使用するスタンバイ・サーバーに対しては5 AUSIライセンスを取得し、コールド・スタンバイ・サーバーに対してはライセンスを取得する必要はありません。プロセッサーValue Unit (PVU)ライセンスに基づいてDB2 Expressサーバーのライセンスを取得した場合は、ウォーム・スタンバイ・サーバーに対してはサーバーが使用するプロセッサー・アーキテクチャーの種類にかかわらず100 PVUライセンス取得し、コールド・スタンバイ・サーバーに対しては一切ライセンスを取得する必要はありません。
システム障害が発生しない時点で、スタンバイ・マシンがどのように使用されているのか?
スタンバイ・マシンは、DB2のトランザクションとクエリーを行うための本番サーバーとして使用されているのでしょうか?本サーバー上のDB2インスタンスは起動していますか?インスタンスによって一定のジョブが実行されているものの、その目的はHADRのコンフィギュレーションに基づいて障害が発生した場合にリカバリー用のデータベースとして機能することに限られていますか?DB2 pureScaleのクラスターを管理していますか?問題なくシステムが稼働している際にスタンバイ・サーバーが行っている処理の内容によって、DB2サーバーに対してどのようなライセンスを取得すべきかが決まります。

DB2 10.5サーバーの各エディションとライセンスの取得方法の概要については、「最適なDB2 10.5のエディションを選択する方法」を読んでください。DB2 10.5のさまざまなエディションのフィーチャー、機能、メリットを比較するには、「DB2 10.5の分散データ・サーバーのさまざまなエディションの機能を比較する」を読んでください。

DB2のライセンス・オプションに対していくつかの改善が行われたことによって、過去数年間においてDB2サーバーを使用してHA環境を実現するためのコストが大幅に下がりました。DB2 10.5からは、ウォーム・スタンバイ・サーバーまたはコールド・スタンバイ・サーバーとして機能するDB2サーバーに対して特定のツールのライセンスを取得する必要がなくなりました。本条件は以下のツールに対して適用されます。

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


HA環境で使用できるDB2のライセンス・オプション

DB2 10.5は以下の5種類の課金体系を提供します。

HA環境で各課金体系を使用する際に注意すべきポイントは以下のとおりです。

サーバー・ライセンス (Limited Use Virtual Server ライセンス)
サーバー・ライセンスは、DB2 Expressサーバーに対してのみ取得することができます。サーバー・ライセンスを使用してDB2 Expressサーバーのライセンスを取得する場合は、ホットまたはウォームの場合、物理サーバーまたは仮想サーバーごとに1ライセンスを購入すれば済みます。DB2のコールド・スタンバイ・サーバーにはライセンスは不要です。HA 環境においては、サーバー・ライセンスに基づいて取得する DB2 Expressサーバーのアクティビティー・レベルを考慮する必要はありません。最小ユーザー数は設定されておらず、サーバーの PVU値などのその他の条件を考慮する必要もないため、非常にシンプルな課金体系です。実装例については、図2を見てください。
使用期間付きのサーバー・ライセンス(FTL)
DB2 ExpressのFTLライセンスを取得すると、1年間DB2 Expressのソフトウェアを使用することができます。DB2の他のエディションでは永続的なライセンスを提供しますが、本ライセンスは使用期間が設定されたライセンスです。FTLを使用してDB2 Expressのライセンスを取得する場合は、DB2 Expressのサーバー・ライセンスと同様にホットまたはウォームの場合は物理サーバーまたは仮想サーバーごとに1ライセンスを購入すれば済みます。コールド・スタンバイ・サーバーにはライセンスは不要です。サーバー・ライセンスと同様に、FTLライセンスには最小ユーザー数は設定されておらず、サーバーのPVU値を考慮する必要はありません。
Limited Use Socketライセンス
Limited Use Socketライセンスは DB2 9.7 で初めて提供され、DB2 Workgroupサーバーに対してのみ取得することができます。Limited Use Socketライセンスを使用してDB2 Workgroupのホット・スタンバイ・サーバーのライセンスを取得する場合は、プライマリー・サーバーの場合と同様に、物理サーバーまたは仮想サーバーのソケット数に基づいてライセンスを購入するだけです。すべてのサーバーが通常の処理のために使用されるためです。Limited Use Socketライセンスを使用して物理サーバーまたは仮想サーバー上で稼働するDB2のウォーム・スタンバイ・サーバーのライセンスを取得する場合は、1 Limited Use Socketライセンスを取得すれば済みます。

パーティショニングが行われていない2台の4-way(デュアル・コア)のIBM POWER7サーバーでクラスターを構成し、プライマリー・サーバーと同じスタンバイ・サーバーを使用しているとします。

  • DB2のプライマリー・サーバーに対しては、DB2 WorkgroupのLimited Use Socketライセンスを4ライセンス取得します。
  • DB2のホット・スタンバイ・サーバーの場合は、DB2 WorkgroupのLimited Use Socketライセンスを4ライセンス取得します。本サーバーのPVU値は960 PVUであるものの、購入が必要なDB2 WorkgroupのLimited Use Socketライセンスは4ライセンスのみです。プライマリー・サーバーに対しても、DB2 WorkgroupのLimited Use Socketライセンスを4ライセンス取得します。
  • DB2のウォーム・スタンバイ・サーバーの場合は、Limited Use Socketライセンスを1ライセンス取得するだけで済みます。
  • DB2のコールド・スタンバイ・サーバーの場合は、ライセンスは不要です。

DB2 WorkgroupサーバーではLimited Use Socketライセンスの適用が有効です。というのも、本ライセンス・オプションによってシステム環境において追加のCPUキャパシティーを活用することができるためです。

テラバイト課金
テラバイト課金は、DB2 Advanced WorkgroupおよびDB2 Advanced Enterpriseで利用できます。これらのエディションは、各データベースのテラバイト数を計算するスクリプトを提供します。ホット・スタンバイ・サーバーの場合は、必要となるテラバイト課金のライセンス数はプライマリー・サーバーに必要なライセンス数と同じです。ウォーム・スタンバイ・サーバーの場合は、サーバー上のデータベースごとにテラバイト課金のライセンスを1ライセンス取得する必要があります。コールド・スタンバイ・サーバーの場合は、ライセンスは不要です。なお、テラバイト課金ではHADRまたはpureScale機能を使用できません。

図4のサーバーの構成でHADRを使用しないケースを想定すると、テラバイト課金でライセンスを取得している場合は、データ・サーバーAとデータ・サーバーBには同じ数のテラバイト課金のライセンスが必要です。

図6のサーバーの構成でHADRを使用しないケースを想定すると、テラバイト課金でライセンスを取得し、データベースのサイズが7.5 TBの場合は、データ・サーバー2にはテラバイト課金のライセンスが8ライセンス必要で、データ・サーバー2にはテラバイト課金のライセンスを1ライセンス取得するだけで済みます。データ・サーバー2上に2つ目のデータベース(5 TB)が存在する場合は、データ・サーバー2には13テラバイト・ライセンスが必要で、データ・サーバー1には2テラバイト・ライセンスが必要になります。

プロセッサーValue Unit (PVU)ライセンス
DB2の物理サーバーまたは仮想サーバーには、PVUライセンスを取得することができます。ホット・スタンバイ・サーバー(スタンバイ・サーバー上での読み取り機能を提供)の場合は、当該サーバーの総PVU値に基づいてライセンスを取得する必要があります。もちろん使用しているDB2サーバーがHAクラスターに含まれていない場合でも、当該サーバーは本番業務をサポートしているため、同じ方法に基づいてライセンスを取得する必要があります。したがって、この点については既に説明した条件と同じです。

図3で記載されたサーバーが各POWER6サーバー上で64プロセッサー・コアを使用していて、各マシンでDB2 Enterpriseが稼働している場合は、本ソリューションのために合計で15,360 PVUライセンス(データ・サーバー1用に7,680 PVUライセンス+データ・サーバー2用に7,680 PVUライセンス)を取得する必要があります。

ウォーム・スタンバイ・サーバーの場合は、PVU値にかかわりなく100 PVUライセンスを取得すれば済みます。図6ではデータ・サーバー2に対しては7,680 PVUライセンスを取得し、ウォーム・スタンバイ・サーバーとして機能するデータ・サーバー2に対しては100 PVUライセンスを取得します。コールド・スタンバイ・サーバーの場合は、ライセンスは不要です。

許可ユーザー・シングル・インストール(AUSI)ライセンス
1名の許可ユーザー(AU)とは、ユーザーの社内外に在籍し、特定のIDを保有する1名の個人(AUは、他のユーザーの代理としてアクセスを行うことのない、アプライアンスまたはアプリケーションのことを指すこともあります)を指します。AUSIの課金体系を使用する場合は、以下の条件が適用されます。
  • DB2のプライマリー・サーバーには、当該サーバーにアクセスするAUの総数に基づいてAUSIライセンスを取得する必要があります。当該サーバーにアクセスするすべてのユーザーを含め、エディションごとに適用される最小ユーザー数を満たす必要があります。DB2 ExpressとDB2 Workgroupでは、5 AUSIライセンス以上を取得する必要があります。DB2 Enterprise、およびDB2 Advanced Enterpriseでは、サーバーの100 PVUごとに25 AUSIライセンス以上を取得する必要があります。DB2 Advanced Workgroupでは1ソケットごとに20AUSIライセンス以上を取得する必要があります。
  • DB2のウォーム・スタンバイ・サーバーの場合は、DB2 ExpressまたはDB2 Workgroupの場合は5 AUSIライセンスを取得する必要があります。その他すべてのエディションの場合は、物理サーバーごとに25 AUSIライセンスを取得する必要があります。図6でAUSIの課金体系を使用する場合は、ウォーム・スタンバイ・サーバーには25 AUSIライセンスを取得する必要があります。
  • DB2のコールド・スタンバイ・サーバーの場合は、ライセンスは不要です。

ライセンスの許諾条件および管理の観点から、DB2のHAクラスターで必要となる総コスト(TCO)を削減するためのさまざまな変更が行われています。現在の経済状況を考えると、これらの条件は非常に好ましいと言えます。表 2はこれらの変更点をまとめたものです。

表 2. HA環境におけるDB2のライセンスの許諾条件のサマリー
DB2のエディションコールドウォームホット
DB2 Express-C
  • 高可用性環境の構築はできません。
  • 高可用性環境の構築はできません。
  • 高可用性環境の構築はできません。
DB2 Express Edition
  • スタンバイ・サーバーにはライセンスは不要です。
  • プライマリー・サーバーがPVUライセンスの場合、スタンバイ・サーバーには100 PVUライセンスを取得する必要があります。
  • プライマリー・サーバーがAUSIライセンスの場合は、スタンバイ・サーバーには5 AUSIライセンスを取得する必要があります。
  • プライマリー・サーバーがサーバー・ライセンス(LUVS)の場合、スタンバイ・サーバーには1サーバー・ライセンスを取得する必要があります。
  • スタンバイ・サーバーにはプライマリー・サーバーと同じDB2のエディションと課金体系のライセンス(Advanced Recovery Featureを含む)を取得する必要があります。
DB2 Workgroup Edition
  • スタンバイ・サーバーにはライセンスは不要です。
  • プライマリー・サーバーがPVUライセンスの場合、スタンバイ・サーバーには100 PVUライセンスを取得する必要があります。
  • プライマリー・サーバーがLimited Use Socketライセンスの場合は、スタンバイ・サーバーに1ソケット分のライセンスを取得する必要があります。
  • プライマリー・サーバーがAUSIライセンスの場合は、スタンバイ・サーバーには5 AUSIライセンスを取得する必要があります。
  • スタンバイ・サーバーにはプライマリー・サーバーと同じDB2のエディションと課金体系のライセンス(Advanced Recovery Featureを含む)を取得する必要があります。
DB2 Advanced Workgroup Edition
  • スタンバイ・サーバーにはライセンスは不要です。
  • プライマリー・サーバーがPVUライセンスの場合、スタンバイ・サーバーには100 PVUライセンスを取得する必要があります。
  • プライマリー・サーバーがAUSIライセンスの場合、スタンバイ・サーバーには物理サーバーごとに25 AUSIライセンスを取得する必要があります。
  • プライマリー・サーバーがテラバイト・ライセンスの場合、スタンバイ・サーバーのデータベースごとに1テラバイト・ライセンスを取得する必要があります。
  • スタンバイ・サーバーにはプライマリー・サーバーと同じDB2のエディションと課金体系のライセンス(Advanced Recovery Featureを含む)を取得する必要があります。
DB2 Enterprise Server Edition
  • スタンバイ・サーバーにはライセンスは不要です。
  • プライマリー・サーバーがPVUライセンスの場合、スタンバイ・サーバーには100 PVUライセンスを取得する必要があります。
  • プライマリー・サーバーがAUSIライセンスの場合は、スタンバイ・サーバーには物理サーバーごとに25 AUSIライセンスを取得する必要があります。
  • スタンバイ・サーバーにはプライマリー・サーバーと同じDB2のエディションと課金体系のライセンス(Advanced Recovery Featureを含む)を取得する必要があります。
DB2 Advanced Enterprise Server Edition
  • スタンバイ・サーバーにはライセンスは不要です。
  • プライマリー・サーバーがPVUライセンスの場合、スタンバイ・サーバーには100 PVUライセンスを取得する必要があります。
  • プライマリー・サーバーがAUSIライセンスの場合、スタンバイ・サーバーには物理サーバーごとに25 AUSIライセンスを取得する必要があります。
  • プライマリー・サーバーがテラバイト・ライセンスを取得した場合は、スタンバイ・サーバーのデータベースごとに1テラバイト・ライセンスを取得する必要があります。
  • スタンバイ・サーバーにはプライマリー・サーバーと同じDB2のエディションと課金体系のライセンス(Advanced Recovery Featureを含む)を取得する必要があります。

ホット・スタンバイ

「ホット・スタンバイ・コンフィギュレーション」とは、すべての物理サーバーまたは仮想サーバーにおいてユーザーがトランザクションとクエリーを行うDB2データベースが稼働している状態を指します。本コンフィギュレーションは「ホット・ホット・クラスター」と呼ばれます(クラスターに含まれるすべてのサーバーが常に同じレベルでビジネス業務を処理するため、「アクティブ・アクティブ・コンフィギュレーション」と呼ばれることもあります)。HAクラスターに含まれる1台のサーバーで障害が発生すると、クラスタリング・ソフトウェアが、障害が発生したサーバーのワークロードをHAクラスター内で稼働し続ける1台以上のサーバーに移行します。

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

ここまでをまとめると、「ホット・スタンバイ・サーバー」とは通常の運用時にユーザーが行うトランザクションとクエリーをサポートするマシンまたは仮想サーバーのことを指します。同時に本サーバーは、通常の運用時にユーザーのトランザクションをサポートする他のサーバーのスタンバイ・サーバーとしても機能します。あるサーバーで障害が発生すると、ホット・スタンバイ・サーバーは障害が発生したサーバーのワークロードを引き継ぎます。スタンバイ・サーバーが通常の運用時に処理している業務を処理し続けるかどうかは重要ではありません。スタンバイ・サーバーを通常の運用時にユーザーのトランザクションやクエリーをサポートするために使用するため、スタンバイ・サーバーに対してはフル・ライセンスが必要になります。

以下のセクションでは、下記のホット・スタンバイの実装シナリオを詳しく説明します。

2ノードを使用したホット・スタンバイHAクラスター

2ノードを使用したホット・スタンバイHAクラスターの環境を図2に示します。本環境では、データ・サーバー1がデータ・サーバー2のホット・スタンバイ・サーバーとして機能し、データ・サーバー2がデータ・サーバー1のホット・スタンバイ・サーバーとして機能します。障害が発生すると、データ・サーバー2のワークロードはデータ・サーバー1にフェイルオーバーし、逆の場合も同様に、データ・サーバー1のワークロードはデータ・サーバー2にフェイルオーバーします。データ・サーバー1にはDB2 Expressのサーバー・ライセンスが適用されています。したがって、データ・サーバー2にもDB2 Expressのサーバー・ライセンスを適用する必要があります。

図 2. 2ノードを使用したホット・スタンバイHAクラスターの実装シナリオ
2ノードを使用したホット・スタンバイHAクラスターの実装シナリオ

上記の例では、パーティショニングが行われていないデータ・サーバー1とデータ・サーバー2が通常の運用時にトランザクションとクエリーのワークロードをサポートしています。薄いグレーのボックスは障害が発生する前の時点でワークロードを処理する各マシンのデータベースを指し、濃いブルーのボックスは他のマシンで障害が発生した際に処理を行うスタンバイ・データベースを指します。

この例では、データ・サーバー2で障害が発生し、本サーバーのワークロードがフェイルオーバー・サーバーであるデータ・サーバー1に移行します。データ・サーバー1はデータ・サーバー2 のホット・スタンバイ・サーバーであり、データ・サーバー2はデータ・サーバー1のホット・スタンバイ・サーバーです。このようなコンフィギュレーションは、通常「高可用性クラスタリング・ペア」、「ツイン・フェイルオーバー・ペア」、「ホット・ホット・ペア」、または「アクティブ・アクティブ・ペア」と呼ばれ、現在のIT環境ではよく見られるものです。

DB2でホット・ホット・コンフィギューレーションに基づいて高可用性クラスターを実装するにあたってはいくつかの方法があります。ユーザーのニーズに基づいて、PowerHA for AIX、各サーバー上のデータベースが他のデータベースにフェイルオーバーを行うHADR、スタンバイ・サーバー上で読み取り機能を提供するHADR、Qレプリケーション、スナップショット・テクノロジーやディスク・イメージのコピーによってレポーティングを行うホット・スタンバイ環境を活用できます。さらには拡張性と可用性を最大限に高めるために、DB2 pureScaleを活用することもできます。

ホット・ホット・コンフィギュレーションによるHADRクラスター

HADRクラスターは、ホット・ホット・クラスターとしてさまざまな機能を提供することができます。図3の環境を見てください。両方のサーバーに対して、DB2 EnterpriseのプロセッサーValue Unit(PVU)ライセンスが適用されています。

図 3. ホット・ホット・コンフィギュレーションによるHADRクラスターの実装シナリオ
ホット・ホット・コンフィギュレーションによるHADRクラスターの実装シナリオ

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

この実装シナリオでは、本システム環境内にスタンバイ・データベースが存在しない場合でも、両方のサーバーにフル・ライセンスの取得が必要になります。これは重要なポイントです。DB2のあるエディションが稼働する物理サーバーまたは仮想サーバーに対してフル・ライセンスを購入済みの場合は、同じ物理サーバーまたは仮想サーバーにおいて同じエディションのスタンバイ・データベースを稼働するにあたっては追加のライセンスは不要です。この条件は、課金体系の種類やスタンバイ・データベースの種類(ウォームまたはホット)にかかわらず適用されます。

  • 例えば、図3の構成で、すべてのデータベースにサーバー・ライセンス(Limited Use Virtual Serverライセンス)に基づいてDB2 Expressのライセンスを取得する場合、必要となるサーバー・ライセンスは合計で2ライセンスで済みます。しかしながら、プライマリー・データベースとスタンバイ・データベースを別々のLPAR上で稼働している場合は、4サーバー・ライセンスの取得が必要になります。
  • 2台のDB2 Workgroupサーバーに対して100名のユーザーがアクセスしている場合は、200ユーザー分のAUSIライセンス(2サーバー×100許可ユーザー)を取得する必要があります。ある時点でいずれかのサーバーにアクセスユーザーの数が100名より少ない場合でも、各サーバーに対して100名のユーザー分のライセンスを取得する必要があります。
  • DB2 ExpressまたはDB2 Workgroupを使用していて、これらのサーバーにアクセスするユーザー数が3名しかいない場合でも、DB2 ExpressまたはDB2 Workgroupに適用されるAUSIライセンスの最小数を満たすために、これらのエディションのAUSIライセンスを10ライセンス(2サーバー×5最小ユーザー)取得する必要があります。

ホット・ホット・コンフィギュレーションによるHADRクラスター(スタンバイ・サーバー上で読み取り機能を提供する)

図4はスタンバイ・サーバー上で読み取り機能を提供するHADRクラスターの例を示しています。両方のサーバーに対してDB2 Advanced Enterprise の7,680 PVUライセンスが適用されています。

図 4. ホット・ホット・コンフィギュレーションによるHADRクラスター(スタンバイ・サーバー上で読み取り機能を提供する)の実装シナリオ
ホット・ホット・コンフィギュレーションによるHADRクラスター(スタンバイ・サーバー上で読み取り機能を提供する)の実装シナリオ

ユーザーはプライマリー・サーバー(ホット・サーバー)に対して読み取りと書き込みを行うことができる一方で、通常の運用時においてセカンダリ―・サーバーに対しても読み取りを行うため、本サーバーもホット・サーバーとなり、両方のサーバーに対してフル・ライセンスの取得が必要になります。業務目的のためにあるサーバーからデータの読み取りを行う場合は、当該サーバーはホット・サーバーとなります。この実装シナリオではプライマリー・サーバーにはDB2 Advanced Enterpriseの7,680 PVUライセンスが適用されているため、セカンダリー・サーバーに対してもDB2 Advanced Enterpriseの7,680 PVUライセンスを適用する必要があります。プライマリー・サーバーに対してDB2 Advanced EnterpriseのAUSIライセンスを適用した場合は、両方のサーバーに対して1,925 AUSIライセンス以上を取得する必要があります(100 PVUごとに25 AUSIライセンス以上を取得する必要があるため)。

DB2 pureScale環境(3つのメンバーをサポートする場合)

図5は、HAと拡張性を実現するDB2 pureScale環境を示しています。本環境は、3つのメンバーと2つのCluster Caching Faclity (CF)サーバーをサポートします。メンバーには、DB2 Advanced WorkgroupのPVUライセンスが適用されています。DB2 pureScaleは、DB2 Advanced WorkgroupのPVUライセンスまたはAUSIライセンスで提供されます。テラバイト・ライセンスではDB2 pureScaleは提供されないため、本課金体系は使用できません。

図 5. DB2 pureScaleによるクラスターの実装シナリオ
DB2 pureScaleによるクラスターの実装シナリオ

この実装シナリオでは、3つのメンバー間でトランザクションがシームレスに分散されているため、すべてのメンバーはホット・サーバーであり、それぞれのサーバーにフル・ライセンス(7,680 PVUライセンス)の取得が必要になります。CFサーバー(通常二重化構造を持つ)にはライセンスは不要です。


ウォーム・スタンバイ

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

ウォーム・スタンバイ・コンフィギュレーションはよく誤解されることがあります。リカバリー処理のためだけにウォーム・スタンバイ・サーバーを使用することはシステム・リソースの無駄であるというものです。しかしながら、ウォーム・スタンバイ・サーバーはスタンバイの役割以外にもさまざまな役割を果たすことができます。例えば、ウォーム・スタンバイ・サーバー上で別のDB2インスタンスを作成し(これによって必要なライセンスに影響が発生することがあります)、テスト・サーバーとして使用したり、場合によっては本サーバーにその他のワークロードや機能のオフロードを行うことができます。障害が発生した場合は、これらのワークロード(またはこれらのワークロードが稼働する仮想パーティションに割り当てられたリソース)の処理を抑え、ウォーム・スタンバイ・サーバーのすべてのリソースを使用して障害が発生したサーバーのワークロードを処理することができます。

スタンバイ・データベースを本番データベースのほぼ最新データの読み取り専用データベースとして使うことによって、より多くのリソースのコストを分散することができます。スタンバイ・サーバー上でデータの読み取りを提供する機能は、DB2 9.7のフィックスパック1から提供されています。ここで留意すべき点は、多くのベンダーのデータベースでは、データベースから読み取りを行っている間はログのロールフォワードによってデータを最新に保つことができないということです。読み取り機能とロールフォワード機能を両方提供できる場合でも、REDO処理のスピードなどで課題が発生することがあります。(訳者注:なお、スタンバイ側で読み取りをする場合はウォーム・スタンバイではなく、ホット・スタンバイの扱いになります。)

ホット・ウォーム・コンフィギュレーションによるHADRクラスター

図6は、2ノードを使用してウォーム・スタンバイ(「アクティブ・アイドル」と呼ばれることもあります)を実現するHAクラスターを実装したケースを示しています。本実装シナリオは、本番のOLTP環境用に構築したスタンバイ・サーバー上で読み取り機能を提供しないHADRコンフィギュレーションです。この例では、通常の運用時にデータ・サーバー2はトランザクションとクエリーのワークロード(図では「実行中の処理」と記載)のために使用され、データ・サーバー1はウォーム・スタンバイ・サーバーとして機能します。データ・サーバー2で障害が発生すると、本サーバーのDB2のワークロードはデータ・サーバー1に移行します。データ・サーバー2にはDB2 Expressの280 PVUライセンスを適用し、データ・サーバー2にはDB2 Expressの100 PVUライセンスを適用します。

障害が発生する前にデータ・サーバー1において何らかの処理を実行している場合、本サーバーの処理を抑えることによってデータ・サーバー2のワークロードを追加で処理します。

図 6. 2ノードを使用したホット・ウォーム・コンフィギュレーションによるHADRクラスター
2ノードを使用したホット・ウォーム・コンフィギュレーションによるHADRクラスター

もし上記シナリオにおいて、データ・サーバー2にDB2 WorkgroupのLimited Use Socketライセンスを4ライセンス適用する構成の場合、データ・サーバー2をウォーム・スタンバイ・サーバーとして使用するには追加で1ライセンスを取得するだけで済みます。Limited Use Socketライセンスを取得する際には、PVU値を考慮する必要はありません。

もし上記シナリオにおいてDB2 EnterpriseでAUSIライセンスの選択を検討する場合、100ユーザー分のライセンスを取得する必要があります。ウォーム・スタンバイ・サーバー用の25ユーザーに加えて、プライマリー・サーバー用に100 PVUあたり少なくとも25ユーザーを取得する(280÷100 = 繰り上げて3、3×25 = 75 AUSIライセンス)必要があるためです。


コールド・スタンバイ

「コールド・スタンバイ・コンフィギュレーション」とは、以下のいずれかの条件が適用される状態を指します。

  • クラスターに含まれる1つ以上の物理サーバーまたは仮想サーバーに、通常の運用時にユーザーが行うトランザクションやクエリーのワークロードを処理するDB2データベースが含まれない場合。
  • クラスターに含まれる1つ以上の物理サーバーまたは仮想サーバーが、フェイルオーバー処理に関係するサポート業務(HADRをサポートするためにデータベースをロールフォワード・ペンディング状態に保つなど)を実行しない場合。なお、コールド・スタンバイ・サーバーは、メンテナンス(バックアップの実行やフィックスパックの適用を含む)のために短時間使用することは可能です。

ホット・コールド・コンフィギュレーションによるHADRクラスター

図7は、2ノードを使用したコールド・スタンバイ・コンフィギュレーションによるHAクラスターの実装シナリオを示しています。

図 7. 2ノードを使用したホット・コールド・コンフィギュレーションによるHADRクラスターの実装シナリオ
2ノードを使用したホット・コールド・コンフィギュレーションによるHADRクラスターの実装シナリオ

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


さまざまな種類のスタンバイ・サーバーが混在する環境

上記においては、スタンバイ・サーバーがすべてホット、ウォーム、またはコールドのいずれかであるHA環境について説明しました。クラスター内にスタンバイ・サーバーが1台しか存在しない場合や、ホット・スタンバイのみをサポートするDB2 pureSaleを使用している場合は、この条件が常に当てはまります。しかしながら、HA環境には同じタイプの可用性のみをサポートするとは限らないさまざまな種類のスタンバイ・サーバーが存在することもあります。

ホット・スタンバイとウォーム・スタンバイをサポートするHAクラスター

以下の実装シナリオでは、プライマリーのデータセンターにおいては冗長性を実現するHA環境が必要な一方で、リモートの2つ目のデータセンターでは災害復旧を実現する必要がある場合があります。さらに、通常の運用時においてはプライマリー・サーバーの負荷を増やさずに読み取りのワークロードを実行する必要がある場合があります。図8は、このような要件を最低限満たす特定のアーキテクチャーを示しています。

図 8. ホット・スタンバイとウォーム・スタンバイをサポートするHAクラスターの実装シナリオ
ホット・スタンバイとウォーム・スタンバイをサポートするHAクラスターの実装シナリオ

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

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

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

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

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


可用性をさらに高めるために

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

表 3. 複数階層のソリューションを通じてHA環境を実現する
ブロンズシルバーゴールド
DB2が標準で提供するクラスタリング機能HADRDB2 pureScale
  • ホット・コールド・コンフィギュレーション
  • 基本的な可用性を実現
  • ほとんどの場合、無償で構築可能
  • 通常5分以内でフェイルオーバーを実現
  • ホット・ウォーム・コンフィギュレーション(場合によっては、スタンバイ・サーバー上で読み取り機能を提供することによってホット・ホット・コンフィギュレーションを実現)
  • 通常1分以内の非常に迅速なフェイルオーバーを実現
  • 簡単なセットアップで迅速に可用性を実現
  • スタンバイ・サーバーで必要となるライセンス数を最小限に抑えることが可能
  • データ損失をゼロにできるオプションを提供
  • ホット・ホット・コンフィギュレーション
  • オンライン・フェイルオーバー
  • 稼働を続けるノード上のトランザクションが影響を受けない
  • 通常30秒以内の最も迅速なフェイルオーバーを実現
  • オンライン・スケールアウト機能によって、ワークロードの急激な増大に対応

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

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

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

表 4. 複数階層のソリューションを通じてDR環境を実現する
ブロンズシルバーゴールド
QレプリケーションHADR機能を提供する物理レプリケーションHADR機能を提供するDB2 pureScale
  • ホット・ホット・コンフィギュレーション
  • ターゲット・データベースに制限なくアクセス可能
  • ソース・サーバーとターゲット・サーバーにおいてさまざまなバージョンのDB2を使用可能
  • データのサブセット化を実現
  • 複数のターゲット・サーバーをサポート
  • オンライン・フェイルオーバー
  • 異なるトポロジーへのレプリケーションが可能
  • 非同期通信のみをサポート
  • セットアップが複雑になる場合がある
  • DDLはサポートしない
  • ホット・ウォーム・コンフィギュレーション
  • データ損失をゼロにできるオプションを提供
  • 通常1分以内の非常に迅速なフェイルオーバーを実現
  • 簡単なセットアップで迅速に可用性を実現
  • DDLとDMLのレプリケーションをサポート
  • スタンバイ・サーバーではサーバーの使用用途が限られる
  • 複数のスタンバイ・サーバーをサポート
  • データベース全体のレプリケーションのみを実行
  • 一定の時間遅延に基づいて災害復旧を実現することも可能
  • ホット・ホット・コンフィギュレーション
  • データ損失をゼロにできるオプションを提供
  • オンライン・フェイルオーバー
  • 通常30秒以内の最も迅速なフェイルオーバーを実現
  • オンライン・スケールアウト機能によって、ワークロードの急激な増大に対応
  • ターゲット・データベースに制限なくアクセス可能
  • 一定の時間遅延に基づいて災害復旧を実現することも可能
  • 単一のスタンバイ・サーバーをサポート
  • DDLとDMLのレプリケーションをサポートする
  • オンラインでフィックスパックをアップデートすることが可能
  • 異なるトポロジーへのレプリケーションが可能

原典

Licensing distributed DB2 10.5 servers in a high availability (HA) environment

参考文献

学ぶために

製品や技術を入手するために

  • developerWorksから直接ダウンロードできるIBMの試用版ソフトウェアを今後の開発プロジェクトに役立ててください。
  • DB2 for Linux, UNIX, and Windowsの無償の試用版をダウンロードしてください。
  • 無償でDB2を使用できます。コミュニティー向けの無償のDB2 Express EditionであるDB2 Express-Cをダウンロードしてください。本ソリューションはDB2 Express Editionと同じコア機能を提供し、アプリケーションの構築と実装に役立つ基盤を提供します。
  • 最適な方法でIBM製品を評価してください。製品の試用版をダウンロードし、オンラインで製品を試し、クラウド環境で製品を使用してください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=962023
ArticleTitle=高可用性(HA)環境においてDB2 10.5の分散データ・サーバーのライセンスを取得する方法
publish-date=02262014