Oracle Real Application Clusters 10g Release 2: Microsoft SQL Server 2005との技術的比較

(1)

Oracle Real Application Clusters 10g Release 2:

Microsoft SQL Server 2005

との技術的比較

オラクル・コンペティティブ・ホワイト・ペーパー

(2)

Oracle Real Application Clusters 10g Release 2:

Microsoft SQL Server 2005

との技術的比較

概要 ... 3

ORACLE REAL APPLICATION CLUSTERSアーキテクチャ ... 4

SQLSERVER 2005 連合データベース ... 5

SQLServer 2005 連合データベースのレイアウト ... 5

SQLServer 2005 連合データベースのサマリー ... 7

Oracle Real Application Clustersが優れている理由 ... 8

SQLSERVER 2005 フェイルオーバー・クラスタ ... 10

SQLServer 2005 フェイルオーバー・クラスタ・

データベースのレイアウト... 10

SQLServer 2005 フェイルオーバー・クラスタ・データベースのサマリー

... 10

Oracle Real Application Clustersが優れている理由 ... 11

SQLSERVER 2005 データベースミラーリング ... 12

SQLServer 2005 データベースミラーリングのレイアウト ... 12

SQLServer 2005 データベースミラーリングのサマリー ... 12

Oracle Real Application Clustersが優れている理由 ... 12

(3)

Oracle Real Application Clusters 10g Release 2:

Microsoft SQL Server 2005

との技術的比較

概要

クラスタ・データベース市場では、競合に対するマーケティングの主張があふれ、各ベンダーは自社アーキテクチャの利点を盛んに宣伝しています。顧客は、急速に進化していく大量のベンチマークの結果、相反するアナリストの批評記事、一様に肯定的な顧客の事例広告を取捨選択して、基幹ソフトウェア・プラットフォームを選ぶことが必要です。このドキュメントでは、Microsoft の 3 つのデータベース・テクノロジを技術的に評価します。対象となるテクノロジは「Federated Architecture」、「Failover Clustering Architecture」（MS Cluster Server を利用）、および Microsoft SQL Server 2005 の代表的機能である「Database Mirroring Architecture」です。各テクノロジを Oracle のクラスタ・アーキテクチャ、Oracle Real Application Clusters10g Release 2 と比較します。Oracle Real Application Clusters は、Oracle の高可用性アーキテクチャの一部で、データベースに対する障害からの保護をさらに強化しています。

Federated および Failover Clustering アーキテクチャは、SQL Server の以前のバージョンに既存しています。Microsoft Database Mirroring テクノロジは、SQLServer 2005 の新機能です。

(4)

ORACLE REAL APPLICATION CLUSTERS アーキテクチャ

ここで重要なことは、Microsoft の SQLServer 2005 が提供する機能には、Real Application Clusters のように高可用性とスケーラビリティをあわせ持つものがないことです。

図 1: Oracle Real Application Cluster アーキテクチャ

Oracle の RAC アークテクチャは、Unix、Windows および Linux サーバー市場において他社製品とは異なる、特徴的なものです。上記の例では、6 つのノードのすべてが、1 つのデータベースのデータを要求するクライアントのリクエストを処理できます。RAC の主な優位性の 1 つは、そのアーキテクチャにより、ノード障害に対してシームレスに耐えることです。上記の状況でノードに障害が発生した場合、そのノードに接続されたセッションは残りのノードにフェイルオーバーされ、残りの 5 つのノードで使用可能なリソースを有効活用するために、接続のバランスが保たれます。クラスタ内の他のノードはクライアントからのリクエストの処理を継続し、障害が発生していないノードに接続されたセッションは切断されません。クラスタ内のノードを全く同じ構成にする必要がないことも重要なポイントです。複合ワークロード環境を例にあげます。ここでのデータベースは OLTP および DSS （意思決定支援）のユーザーによって共有されます。データベース・インスタンスを最適に構成して、接続されたユーザーの要求が処理できます。

また、Oracle Real Application Clusters は、クラスタ内のすべてのマシンを同時に使用可能にして、パフォーマンスをさらに向上させます。たとえば、この環境では、データ・ウェアハウスへの問合せを、クラスタで使用可能なすべての CPU で自動的にパラレル化し、DSS（意思決定支援）アプリケーションのパフォーマンスを高めます。高度なロード・バランシング・アルゴリズムを使用することで、ユーザー・セッションは、クラスタの中で最も負荷が低いノードにルーティングできます。

(5)

SQLSERVER 2005 連合データベース

SQL Server の連合データベースは、独立したサーバーの集合で、リソースを共有せず LAN で接続されます。連合データベースの実装は複雑です。次の図に、6 ノードの連合データベースを示します。 SQL Server の連合データベースにより、一定レベルのスケーラビリティが提供されますが、可用性が犠牲になります。SQL Server データベースにノードが追加されると、予測される可用性が低下します。クライアントからの要求を処理する為には、データベースの全てのノードが利用可能でなければならない為です。次の図では、6 つの独立した SQLServer データベースがあり、それぞれが別個のバックアップとリカバリを必要とします。クライアント・アプリケーションからの要求を満たすには、これらのデータベースすべてがオンラインであることが必要です。図 2: Microsoft の連合データベース・アーキテクチャこのアーキテクチャをサポートするパッケージ・アプリケーションは限られています。

SQLServer 2005 連合データベースのレイアウト

次に、連合データベースを設定するプロセスを説明します。データは、クラスタに参加している各サーバーに分散されます。DBA とアプリケーション開発者の両方にとって、特定のサーバーに接続されたディスク上の「ローカル」データと、連合データベースの他のサーバーが所有する「リモート」

データは明確に違います。アプリケーションは、UNION ALL ビューと Distributed SQL を使用して、データの論理的な単一のビューを表示します。Microsoft は、このテクノロジを「分散型パーティション・ビュー」（DPV）と呼びます。DPV は、各ノードで異なった方法で構成され、ローカルなパーティションとリモートなパーティションを明示的に考慮する必要があります。例として、Microsoft SQL Server で複数のサーバーにまたがる顧客のパーティション化の方法を簡単に示します。

(6)

アプリケーションで、各表に対して次の作業をします。 • まず、各ノードで独立した表を作成します。 -- On Server1:

CREATE TABLE Customers_33

(CustomerID INTEGER PRIMARY KEY

CHECK (CustomerID BETWEEN 1 AND 32999), ... -- Additional column definitions)

-- On Server2:

-- On Server3:

このコードはhttp://msdn.microsoft.com/library/en-us/createdb/cm 8 des 06 17zr.aspに掲載されています。

• 次に接続性情報を作成します

クラスタに参加している各サーバーにおいて、リンクされたサーバーの定義と問合せ最適化オプションが必要です。

• 最後に、各ノードで DPV を作成します。各ノードでビューが異なることに注意してください。

CREATE VIEW Customers AS

SELECT * FROM CompanyDatabase.TableOwner.Customers_33 UNION ALL

SELECT * FROM Server2.CompanyDatabase.TableOwner.Customers_66 UNION ALL

SELECT * FROM Server3.CompanyDatabase.TableOwner.Customers_99

ベンチマーク

これまで、Microsoft は、TPC-C ベンチマークのテストに DPV を使用していました。TPC-C スキーマは実環境のアプリケーションとは異なり、9 つの表で構成され、このうち 7 つが主キーの一部として Warehouse_ID を持っています。それぞれの表に DPV を提供し、関連する索引の作成は単純な仕事です。この単純な OLTP スキーマを実環境のアプリケーションと比較します。表主キー索引代替キー索引 Peoplesoft 7,493 6,438 900

Oracle eBusiness (ERP)* 8,155 800 5,100

SAP 16,500 16,329 2,887

* Oracle E-Business Suite は、SQLServer をサポートしません。ここでは、そのような企業全体のアプリケーションのサポートに使用するスキーマのサイズの尺度として使用されています。

これらのアプリケーションでは、スピーディなデータ・アクセスとデータ整合性の両方を確保するため、非プライマリ・キー列に対するグローバル一意索引が必要です。このタイプの索引例として、Oracle E-Business Suite における RA_Customers 表での Customer_Number に対する一意索引があります。これによって、ある値の一意のビジネス・キーを持つ顧客がただ 1 人であることが確認されます。ビジネ

(7)

ス・キーは、表の主キー以外のキーです。この索引がないと、重要な役割を担うアプリケーション・データに破損、複製または紛失が生じる可能性があります。また、アプリケーションは通常、データ・アクセスを明確にパーティション化しません。一般的に、高い頻度で「ローカル」データにアクセスを行えるようなアプリケーション表のパーティション化キーを見つけることは不可能です。ローカル・アクセスでは、単一パーティションのデータの内容のみを使って、問合せ要件を満たすことができます。SAP、PeopleSoft または Oracle E-Business Suite では、非常に重要な問合せには複数の表を結合します。そして、別の問合せには述語結合に別の代替キーを使用します。非ローカル・データ・アクセスは、頻繁な分散トランザクションによる許容できないパフォーマンス・オーバーヘッドを招きます。適切なパーティション化キーが見つかった場合でも、何千ものアプリケーション表をパーティション化することが必要になります。そのため、PeopleSoft または SAP を連合データベースへ移植するには、SQLServer の構成に DPV（パーティション化された表ごとに 1 つ）を作成、管理することが必要ですが、これは極めて困難な作業です。また、DPV が代替キーに基づくグローバルな一意の索引をサポートできないため、連合データベースへの移植によって重大なビジネス情報の整合性が侵害されます。したがって、移植した連合データベースで実行できるのは、シンプルな OLTP アプリケーションのみです。

SQLServer 2005 連合データベースのサマリー

実環境のアプリケーションで連合データベースがうまく適用できないことには、数多くの要因があります。

ホット・ノード

DBA はデータをパーティション化する際に、ホット・ノードが生じないように注意する必要があります。単純にデータベースの割合に基づいてパーティション化することはできません。この方法では問合せの分散が考慮されず、ホット・ノードが生じます。このホット・ノードがボトルネックになり、スループットを制限します。さらに、DBA が完全にパーティション化して負荷をすべてのノードに分散しても、時間の経過とともにデータの追加や変更、問合せプロファイルの変更によって、最初は完全に分散されていたシステムが、ホット・ノードを持つアンバランスなシステムになります。

データの不整合性

データベースの全データをパーティション化するのは、簡単な作業ではありません。DBA は大きな表のみをパーティション化し、小さい表をすべてのノード間で複製する傾向があります。各ノードには固有のデータベースがあるため、比較的小さい表に対するすべての変更を、クラスタのすべてのノード間でレプリケートすることが必要になります。この重複によって、データの複数コピーが複数の SQLServer データベースに格納されます。

(8)

ノードの追加

ワークロードが増加すると、DBA が SQLServer 連合データベースに新しいノードを追加することが必要です。そのプロセスは、次のとおりです。OS をインストールする、SQLServer をインストールする、新しいパーティション化計画を決定する、既存のノードからデータをアンロードする、データをパーティション化する、データを新しいノードの集合にロードする、データベースをオンラインに復帰する、必要に応じて、アプリケーションを変更する。

一貫性バックアップ

Microsoft SQLServer DPV データベースは実際には多数の個別のデータベースで構成されており、それぞれにバックアップが必要です。さらに、DPV データベースのリカバリが必要な場合、独立したデータベースを同じ時点まで個別にリカバリし、最終的にはオンラインに復帰させることが必要です。

ノード障害の処理

ノード障害時に、そのノードが持つデータは、アプリケーションから使用できなくなります。実環境のアプリケーションのほとんどは、データの一部分がオフライン化されることを許容できません。

ベンチマーク

Microsoft の DPV アーキテクチャは、特殊なベンチマーク専用として知られるようになりました。Microsoft は、TPC-C では問合せが事前に定義されているため、 TPC-C ベンチマーク用のデータ取得、および TPC-C の結果処理が実現できました。また、このテクノロジを使用して最近発行された TCP（-C または-H）ベンチマークを持っていません。

Oracle Real Application Clusters が優れている理由

Oracle Real Application Clusters アーキテクチャは、根本的に異なります。オラクル社が提供する共有ディスク・アプローチは、次の問題に対処します。

ホット・ノード

RAC でのデータは、ノード・ベースでパーティション化されません。コネクションは、負荷の最も少ないノードにルーティングされます。ホット・ノードは、Oracle Real Application Clusters データベースでは発生しない傾向にあります。

データの整合性

Oracle が必要とするのは、データベースの 1 つのコピーのみです。RAC アーキテクチャを使用すると、追加のコピーは必要ありません。「データのコピーが 1 つ」と「データの整合性」は、同じ意味です。

(9)

ノードの追加

ワークロードの増加に対し、Oracle Real Application Clusters データベースのノード数が十分ではなくなることが考らえられます。Oracle Real Application Clusters の場合、次の手順に従います。OS をインストールする、Oracle Real Application Clusters をインストールする、新規インスタンスを起動させる。すると、インスタンスは自動的にデータベース・リスナーに登録され、アプリケーションはスキーマ、またはアプリケーションのいずれも変更せず即座に新しいノードを使用できます。

一貫性バックアップ

ノード数にかかわらず、Oracle Real Application Clusters データベースは単一データベースのイメージです。したがって、データベースは単一のバックアップとリストアにより一貫した方法でバックアップ・リカバリされます。

ノード障害の処理

データの一部を管理するのは、1 つのノードだけではないため、RAC クラスタで 1 つのノードが使用不可能になっても、すべてデータにアクセスできます。数秒後に RAC フェイルオーバーが発生すると、障害が発生したノードへの接続は、自動的に残りのノードに再接続されます。アプリケーション層は、Fast Connection Failover によってノードの停止通知を即座に受け、障害が発生したノードに関連する接続プール内の接続を無効にできます。

ベンチマーク

オラクル社は、定期的に RAC クラスタ・データベースを用いてベンチマーク試験を行います。最新のベンチマークは、Linux を使用して HP ハードウェアで行われました。詳細は、次のサイトで参照してください。 http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=103120803。このベンチマークのために、オラクル社はデータを各ノードに分割する必要はありませんでした。

(10)

SQLSERVER 2005 フェイルオーバー・クラスタ

Microsoft Cluster Server（MSCS）は、スタンドアロン・ノードと比較して多少高レベルの可用性を提供するために、Microsoft がサポートするテクノロジです。 Microsoft は、これを「フェイルオーバー・クラスタ」と呼んでいます。MSCS が管理する SQLServer データベースを次に示します。 SQL Server のフェイルオーバー・クラスタ・データベースは、標準的なスタンドアロン・データベースと比較して多少高レベルの可用性を提供しますが、スケーラビリティの面では何も提供しません。図 3: Microsoft のファイルオーバー・クラスタのアーキテクチャハードウェアのアーキテクチャは、RAC 環境に似ています。2 つのノードがネットワーク・インターコネクトで接続されています。共有ディスクのようなものもあります。実際のところは、フェイルオーバー・クラスタ・データベース内のディスクは共有されません。SQLServer データベースは、ノードの 1 つでのみ実行されます。2 番目のノードは、最初のノードに障害が起きた場合のバックアップとして提供されています。

SQLServer 2005 フェイルオーバー・クラスタ・データベースのレイ

アウト

このアーキテクチャでインストールされた SQLServer データベースは、単一の SQLServer データベースのように動作をします。このデータベースは、ハードウェアとオペレーティング・システムに課される制限事項に左右されます。また、単一サーバーのスケーラビリティに制限されます。データベースを構成するファイルは、中央のディスクに配置します。SQLServer データベースを実行するノードは、このディスクを使用できます。

SQLServer 2005 フェイルオーバー・クラスタ・データベースのサマ

リー

このクラスタ化技術は、スケーラビリティを向上させるものではありません。個々のデータベースは 1 つのノードで実行されるのみです。このため、単一ノードのスケーラビリティに制限されます。

フェイルオーバーがアプリケーション・ブラックアウトを引き起こす

稼働中のノード（ノード 1）に障害が発生した場合、SQLServer データベースを他のノード（ノード 2）で再起動するために必要な手順を完了するまでに、遅延が生じます。手順は、次のようにまとめることができます。 1. ノード 2 は、ノード 1 の停止を認識することが必要です。

(11)

2. ノード 1 が参照したディスクを、ソフトウェアを使用してノード 2 で参照できることが必要です。 3. ノード 1 で使用した IP アドレスをノード 2 で作成します。 4. ノード 1 で使用したネットワーク名をノード 2 で作成します。 5. ノード 1 で管理したサービス（たとえば、SQLServer）をノード 2 で起動します。 6. 次に、ノード 2 の SQLServer をリカバリしてデータベースを開きます。 7. アプリケーションが再接続され、トランザクションを再開します。この手順はシリアルに行う必要があります。SQLServer は、ディスクとネットワークが起動されるまで、起動できません。また、IP アドレスが作成されるまで、ネットワーク名を作成できません。

Oracle Real Application Clusters が優れている理由

Oracle Real Application Clusters の場合、同じデータベースのインスタンスは、クラスタ内の全ノードで実行され、クラスタの全ノードがワークロードを共有します。

RAC クラスタには MSCS が必要ないため、MSCS が課すノード制限には影響されません。Oracle Real Application Clusters 10g Release 2 は、最大 100 のノードをサポートします。 1 つのノードに障害が発生すると、クラスタ内の他のノードが既存の接続に対するサービスを継続します。実行中のトランザクションは、クラスタ内の他のノードによって直ちにロールバックされます。したがって、リソースが再起動され、データベースが他のノードで起動するまで待つ必要がありません。データベースは、すでに起動しているからです。 RAC では、フェイルオーバーは分単位ではなく、秒単位で終了します。障害が発生したノードへの接続は、自動的に残りのノードに再接続されます。アプリケーション層は、Fast Connection Failover によってノード停止の通知を即座に受け、接続プール内の、障害が発生したノードに対する接続を無効にできます。

(12)

SQLSERVER 2005 データベースミラーリング

Microsoft のデータベースミラーリングは、2005 年にリリースされる SQLServer の一部として提供される新機能です。この機能によって、2 番目のサーバーがリモート・サイトに本番データベースのコピーとして維持されます。

SQL Server Mirror データベースは、 Oracle の Data Guard アーキテクチャのコンポーネントの 1 つに相当します。データベースミラーリング自体は、一定の保護レベルを提供しますが、データベース・ソリューションのスケーラビリティ向上の点では何も提供しません。

SQLServer 2005 データベースミラーリングのレイアウト

Microsoft は通常、新しいデータベースミラーリングテクノロジを高可用性ソリューションとして説明しています。次の図に示すように、3 つの独立した SQLServer データベースが必要です。最初のデータベースは本番データベース、2 番目のデータベースはミラー・データベース、3 番目のデータベースは、Witness サーバーの役割を果たします。この図では、プライマリ・サーバーのログは遠隔地の Mirror サーバーに書き込まれます。3 番目のデータベースはモニターの役割を果たす Witness サーバーです。

SQLServer 2005 データベースミラーリングのサマリー

スケーラビリティの点では、何も提供しません。これは、一見してオラクル社の Data Guard の Physical Standby データベースが提供する可用性に類似しています。 Mirror データベースは、要求されるまでは使用不可能な状態です。この機能は、 Oracle データベースの数多くのリリースですでに存在していました。

Oracle Real Application Clusters が優れている理由

データベースミラーリングにはOracle Real Application Clustersと同等の機能ではありません。それは、Oracle Data Guard製品に類似しているだけです。「Oracle’s High Availability Architecture」1で説明するRACとData Guardの組み合わせにより、比類ないレベルの可用性とスケーラビリティが提供されます。

1_{Oracle’s High Availability Architecture に関連する情報は、次のWebサイトにあります。}

(13)

まとめ

Microsoft の連合データベースは、可用性という点では何も提供しません。実際、ノード追加は可用性の低下を招きます。このソリューションのスケーラビリティは、TPC-C スタイルのベンチマークには有効な場合がありますが、基幹業務アプリケーションにスケーラブルなソリューションを提供する可能性は大幅に制限されます。

Oracle Real Application Clusters の使用により、アプリケーションのコードやスキーマを変更することなく、高可用性とスケーラビリティを提供します。単一ノード上で CPU の数を 2、4、8 と増やした場合に、スケールするアプリケーションでは、ノード数を 2、4、8 と増してスケールできます。 Microsoft フェイルオーバー・クラスタソリューションは、一定のレベルの可用性とコールド・リスタート機能を提供しますが、スケーラビリティという点では何も提供しません。SQLServer データベースは、単一のハードウェア・サーバーの制限によりスケーラビリティが抑制されます。

Oracle Real Application Clusters では、複数のサーバーの組み合わせが可能で、1 つのクラスタで最大 100 ノードのスケーラビリティと可用性を向上します。 Microsoft の最新機能「データベースミラーリング」は、長年にわたって Oracle が Data Guard 製品で使用してきたいくつかの技術を模倣するものです。この場合も、データベースミラーリング・ソリューションは、単一サーバーのハードウェアの制限によりスケーラビリティが抑制されます。

Oracle Data Guard と Oracle Real Application Clusters は、相互に補完関係にあります。 RAC はシステム障害またはインスタンス障害に対処します。RAC は、ノード障害のような、データに影響しない障害からの迅速で自動的なリカバリを提供します。さらに、RAC では、アプリケーションに対して強化されたスケーラビリティの提供と同時に、一般的な価格のサーバーを利用できます。Data Guard は、RAC のコンポーネントとして、トランザクション一貫性のあるプライマリ・データベースとスタンバイ・データベースの使用によりデータを保護します。これらのデータベースはディスクを共有することも lock-step 処理を実行することもありません。したがって、サイトの障害やデータ破損からのリカバリが可能です。

(14)

Oracle Real Application Clusters 10g Release 2: Microsoft SQL Server 2005 との技術的比較 2005 年 9 月著者: Philip Newlan Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com Copyright © 2005, Oracle. 無断転載を禁ずこの文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、契約上の直接的および間接的義務も発生しません。本書は、事前の書面による許可を得ることなく、電子的または機械的に、いかなる形態または手段によっても複製または伝送することはできません。 Oracle は米国 Oracle Corporation および関連会社の登録商標です。他の製品名は、それぞれの所有者の商標です。