Oracle Database 12c Release 2 Oracle Real Application Clusters

Oracle ホワイト・ペーパー | 2017 年 3 月

Oracle Real Application Clusters 12c Release 2 – 技術概要

目次

はじめに 1

Oracle Real Application Clusters - 概要 2

Oracle RAC ソリューション・ファミリー 2

Oracle Clusterware 3

Oracle Clusterware 12c Release 2 の新機能 3

デプロイメント・モデルの選択 4

Oracle ASM 12c Release 2 の新機能 5

Autonomous Health Framework（AHF） 6

より優れたスケーラビリティ 7

アルゴリズムの改善 8

サービス指向バッファ・キャッシュ 9

プラガブル・データベースとサービスの独立性 10

より優れた可用性 11

スマートな再構成 11

Recovery Buddy 11

オラクルの、読取りノード上の読取インスタンス 12

Node Weighting 12

アプリケーション継続性 13

クラスタ・プールの効率的な管理 13

Oracle Rapid Home Provisioning 13

Oracle Autonomous Health Framework 14

まとめ 16

1 | Oracle Real Application Clusters 12c Release 2 – 技術概要

はじめに

Oracle Real Application Clusters（Oracle RAC）は、Oracle Database に高可用性とスケーラビリティをもたらす高機能ソリューションとして、お客様に利用され続けています。アプリケーションの変更なしに Oracle RAC が実現する機能をすべて組み合わせたソリューションは、市場にはほかに存在しません。Oracle RAC の最新リリースでは、これらの機能が改善され、ビジネスにとって極めて重要なすべての領域で大幅な機能強化が実現しました。

Oracle RAC は当初はクラス最高のデータベース・サービスを提供することに重点を置いていました。しかし、数年にわたって革新を遂げた後、現在はパブリック・クラウド、プライベート・クラウド、またはハイブリッド・クラウドで使用できる包括的な高可用性（HA）スタックを提供することで、あらゆるアプリケーションで高可用性、スケーラビリティ、柔軟性、俊敏性を実現しています。

Oracle Database の可用性とスケーラビリティの要件は、近年いっそう厳格になっています。企業では、データベースやアプリケーションのいかなる停止時間も許されません。Oracle RAC ソリューション・ファミリーにより、データベースやアプリケーションの可用性およびスケーラビリティ要件を確実に満たすことができる微調整された製品バンドルが提供されます。

Oracle Real Application Clusters 12c Release 2 では、クラウド・コンピューティングや機械学習など、最新のハードウェア・イノベーションと業界の傾向を活用する多数の専用技術リソースを使用して、これらの機能を引き続き向上しています。

これらの機能は、以下を提供する機能に大まかに分類できます。

» より優れたスケーラビリティ

» より優れた可用性

» より優れた効率性とクラスタ・プールの管理

2 | Oracle Real Application Clusters 12c Release 2 – 技術概要

Oracle Real Application Clusters - 概要

Oracle Database で Oracle Real Application Clusters オプションを使用すると、異なるサーバーで実行されている複数のインスタンスから、共有ストレージに保存された同じ物理データベースにアクセスできます。データベースは複数のハードウェア・システムにまたがりますが、アプリケーションに対しては、1 つの統合データベースとして表示されます。このため、汎用ハードウェアを使用して総所有コストを削減し、さまざまなアプリケーション・ワークロードをサポートする拡張性の高いコンピューティング環境を提供できます。追加の計算容量が必要な場合は、既存のサーバーを置き換えるのではなく、ノードを追加できます。その際、クラスタ内のすべてのサーバーで、同一のオペレーティング・システムと同じバージョンの Oracle が実行されている必要がありますが、容量が同じである必要はありません。お客様は、最新の CPU とメモリを搭載したサーバーを購入し、既存のサーバーと一緒に使用できるため、資本支出が抑えられます。このアーキテクチャでは、RAC インスタンスが異なる複数のノードで実行されており、ノード障害から保護されるため、高可用性も実現されます。なお Oracle Applications、PeopleSoft、Siebel、SAP をはじめとする（ほぼ）すべてのアプリケーションは、一切変更なしで Oracle RAC データベース上で実行することができます。

データベースの可用性とスケーラビリティに対するお客様の要件は増え続けています。お客様の環境ではいかなる停止時間も許されません。これらの要件は、データベースのみに限定されず、サーバー、ネットワーク、クライアント接続など、他の重要なコンポーネントにも及びます。さらに、受け取ったワークロードを使用されていないノードや、場合によってはより高い計算能力と大容量のメモリを備えたノードに動的にリダイレクトできる、賢いリソース・マネージャが必要です。

Oracle RAC ソリューション・ファミリーにより、これらの要件すべてを確実に満たすことができる事前調整済みの製品バンドルが提供されます。Oracle RAC スタックは、“Oracle RAC ソリューション・ファミリー”と呼ばれる以下のコンポーネントで構成されます。

Oracle RACソリューション・ファミリー

図1：オラクルのソリューション・ファミリー

3 | Oracle Real Application Clusters 12c Release 2 – 技術概要

Oracle RAC ソリューション・ファミリーによって提供される機能は、Oracle RAC または Oracle RAC One Node のライセンスを所有するお客様が追加料金なしで利用できます。

Oracle Clusterware

Oracle Clusterware は、サーバー群をクラスタ化する技術です。Oracle Clusterware では、とりわけ、ノードの追加、ノードの切断、最適なリソース配置をはじめとする機能が提供されます。Oracle Clusterware は、Oracle RAC、RAC One Node、そしてシングル・インスタンスの Oracle データベースとともに使用できる、完全で無料のクラスタリング・ソリューションです。

Oracle Clusterware 12c Release 2の新機能

Oracle Clusterware 12c Release 2 では、クラスタの大規模な展開を容易に管理できる新たな配置の選択肢が導入されました。この新しいアーキテクチャは、Oracle クラスタ・ドメインと呼ばれます。クラスタ・ドメインの配置方式を使用すると、データベースやアプリケーションのためにすべてのリソースを使用できるように個々のクラスタが開放される一方で、展開、ストレージ管理、パフォーマンス監視などの管理タスクは、ドメイン・サービス・クラスタに移行されます。

図2：Oracleクラスタ・ドメイン

図 2 で示すように、クラスタ・ドメインは、ドメイン・サービス・クラスタ（DSC）と 1 つまたは多数のメンバー・クラスタで構成されます。ドメイン・サービス・クラスタ（DSC）により、サービスがメンバー・クラスタに提供されます。メンバー・クラスタは、データベースまたはアプリケーションが配置されるクラスタです。メンバー・クラスタには、次の 4 種類が存在します。（1）高パフォーマンスのローカル・ストレージをそのメンバー・クラスタに持つデータベース・メンバー・クラスタ、（2）共有ストレージのないアプリケーションを通常はホストするアプリケーション・メンバー・クラスタ、（3）ASM I/O サービスを使用して DSC 上の ASM ストレージにアクセスするデータベース・メンバー・クラスタ、（4）SAN ストレージを使用して直接 DSC 上の ASMストレージにアクセスするデータベース・メンバー・クラスタ。すべてのメンバー・クラスタでは、

4 | Oracle Real Application Clusters 12c Release 2 – 技術概要

一元管理される管理リポジトリ・サービス、Trace File Analyzer サービス、およびドメイン・サービス・クラスタによって提供されるその他のサービスを利用します。

Oracle Clusterware 12c Release 2 は、前リリースにスタンドアロン・クラスタとして配置することも可能です。

配置モデルの選択

配置モデルの選択は、インストールの種類によって異なります。新規のインストールでは、クラスタ・ドメイン・ベースの配置モデル、またはスタンドアロン・クラスタの配置モデルのどちらかを選択できます。前リリースからアップグレードした場合は、配置モデルがアップグレード中に変更されないため、引き続きスタンドアロンとなります。Oracle Clusterware のライセンスは、どちらの配置モデルを選択した場合も同じです。配置モデルを選択する際に考慮すべきいくつかの側面を次に示します。

» クラスタ・ドメインのアーキテクチャでは、メンバー・クラスタの管理面がドメイン・サービス・クラスタに移行されます。これにより、プロビジョニングとパフォーマンス管理の双方について、メンバー・クラスタの管理が最適化されます。メンバー・クラスタの CPU などのリソースは、データベースの処理ニーズのための専用リソースとして使用できるようになります。

» クラスタ・ドメインのアーキテクチャにより、ドメイン・サービス・クラスタ（DSC）を使用した統合型のストレージ・ソリューションが実現されます。このモデルでは、Oracle ASM のクローニング機能を使用して、新たなデータベースを容易にプロビジョニングできます。DSC デプロイメント・モデルを使用したストレージ統合では、Oracle ASM 12c Release 2 で導入された、データベース指向の新たなストレージ管理機能の利点が大いに生かされます。

» DSC で Autonomous Health Framework（AHF）によって、一元管理されるデータ収集機能により、メンバー・クラスタの動作は機械学習によって分析できます。AHF では、機械学習により、メンバー・クラスタが継続的に監視されます。これにより、多くの場合、問題は発生する前に防止できます。たとえば、AHF では、リアルタイムのパフォーマンス・カウンタと予想される値との差異を検出できるため、システム管理者に差し迫ったパフォーマンス問題を通知する一方で、的を絞った診断を生成し、是正措置を講じることができます。

Oracle Clusterware について詳しくは、www.oracle.com/goto/clusterware を参照してください。

Oracle Automatic Storage Management（Oracle ASM）

Oracle Automatic Storage Management は、Oracle RAC とシングル・インスタンスの Oracle Database の双方で使用できる推奨のボリューム・マネージャです。Oracle ASM では、“Stripe And Mirror Everything”（SAME）の原則を基にストレージ管理を簡素化します。賢いミラー化機能によって、管理者は 2 重または 3 重のミラー化を定義して、重要なデータを保護できます。読取り処理でディスクの破損ブロックが識別されると、Oracle ASM は、有効なブロックをミラー・コピーからディスクの破損していない部分に自動的に再配置します。

5 | Oracle Real Application Clusters 12c Release 2 – 技術概要

Oracle ASM 12c Release 2の新機能

Oracle ASM 12c Release 2 では、ASM フレックス・ディスク・グループを使用した、データベース指向のストレージ管理が導入されました。ASM フレックス・ディスク・グループでは、（a）データベース・ファイルで構成されたファイル・グループごとに変更が可能な冗長性、（b）スナップショット機能、（c）統合環境におけるデータベース・レベルでの割当て制限管理など、管理機能が強化されています。

データベース管理者は、下層ストレージのスナップショット機能に頼らずにスナップショットを作成できる機能を使用して、データベースを迅速にプロビジョニングできます。Oracle ASM のスナップショットは、停止時間や手作業での追加のリカバリ操作なしに、データベース・レベルで実行できます。冗長性は変更可能なため、データベース管理者は、保守的なミラー化戦略から開始して、ビジネス・ニーズに応じて後で冗長性を変更できます。ストレージ管理者は、割当て制限管理機能を使用して、データベース・レベルで割当て制限を設定できます。この設定は、1 つのデータベースがフレックス・ディスク・グループの全領域を使用する状況を回避できるため、統合環境で有用です。

Oracle Automatic Storage Management について詳しくは、http://www.oracle.com/goto/asm を参照してください。

Oracle ASM Cluster File System（Oracle ACFS）

Oracle ACFS は、汎用ファイルとデータベース・ファイルを保存する POSIX 互換ファイル・システムを提供することで、ASM のファイル管理機能を補完しています。Oracle データベースでは長い間、BLOB、XML、テキスト・ファイルなどを保存する列タイプが提供されていました。しかしユーザーは、アプリケーションやビジネスの要件を満たすために、そのようなデータを保存するファイル・システムを必要としていました。そのようなデータを Oracle データベースの外部に保存するためには、言うまでもなく、バックアップやサイト間の同期などのデータ管理作業を手作業で計画する必要があります。

Oracle ACFS により、そういったデータの保存に使用できるクラスタ・ファイル・システムが提供されます。タグ機能、レプリケーション、スナップショットなどの ACFS 機能をさらに使用すれば、データ管理作業が容易になります。ACFS タグ機能を使用してデータにタグを追加したり、コマンドラインを使用してタグを取得したりできるほか、アプリケーションからタグ API 呼び出しを直接利用できます。

また、特別なストレージに依存せずに、汎用システムで Copy-On-Write（COW）を利用する ACFSスナップショット機能を使用することもできます。この機能により、お客様は消費領域を最低限に抑えながら、複数のスナップショットを作成できます。Oracle ACFS では、サイトの可用性のために、これらのデータを他のシステムにレプリケートするレプリケーション機能も提供されます。

Oracle ACFS について詳しくは、http://www.oracle.com/goto/acfs を参照してください。

6 | Oracle Real Application Clusters 12c Release 2 – 技術概要

Rapid Home Provisioning（RHP）

オラクルの Rapid Home Provisioning を使用すると、Oracle データベースの管理者は、Oracle のグリッド基盤と Oracle データベースを迅速かつ効率的にプロビジョニングできます。RHP では、一元管理されたソフトウェアの展開とメンテナンス機能が提供され、RHP サーバーに保存されたソフトウェアをあらゆるノードやクラスタにプロビジョニングできます。

Oracle RHP について詳しくは、www.oracle.com/goto/rhp を参照してください。

Autonomous Health Framework（AHF）

Oracle Autonomous Health Framework では、種々の次世代ツールが提供されます。これらのツールが 24 時間 365 日体制で自律的に稼働することで、人的な対応時間が最小限に抑えられながらも、データベース・システムの健全な稼働が維持されます。AHF デーモンにより、オペレーティング・システムとデータベースからパフォーマンス・データと構成データが継続的に収集され、分析されます。AHF では、機械学習の概念をリアルタイムに適用することで、差し迫ったコンポーネント障害やワークロードの変更などのイベントを予測します。この分析の結果を基に、ワークロードを他のインスタンスに自動的に移行する、または手作業での介入を要する可能性のある差し迫った障害を管理者に通知します。

AHF について詳しくは、www.oracle.com/goto/ahf を参照してください。

SCAN

Single Client Access Name（SCAN）は、クラスタ内でデータベースのクラスタ・エイリアスとして機能します。Oracle Grid Infrastructure 11g Release 2 で導入されました。SCAN を使用するメリットは、クラスタでノードを追加したり削除したりしても、クライアントの接続情報を変更する必要がないことです。

Oracle Grid Infrastructure 12c では、SCAN は次の点が強化されました。（a）IPv6 ベースの IP アドレスをサポートすることで、必要に応じて IPv4 または IPv6 ベースのアドレスを選択できる、（b）クラスタ内の複数のサブネットをサポートすることで、受信クライアントを異なるネットワーク・サブネットに分離してきめ細かい管理を実現できる、（c）サービスの登録を制限することで、RACクラスタの一部ではない恣意的なサービスを SCAN で登録できないようにする。これによりユーザー・セッションを悪意のあるノードに転送できなくなるため、セキュリティが向上する。

SCAN について詳しくは、http://www.oracle.com/technetwork/jp/database/options/clustering/overview/scan-129069-ja.pdfを参照してください。

7 | Oracle Real Application Clusters 12c Release 2 – 技術概要

動的データベース・サービス

セッションは、サービスを使用してインスタンスに接続されます。サービスそのものは、1 つまたは複数のインスタンスで実行されるように構成できます。1 つのインスタンスは、1 つまたは複数のサービスをホストできます。サービスにより、より粒度の高い、ワークロードを管理しやすいコンポーネントに分割できます。たとえば、OLTP ユーザーは、セッションをハブ・ノードにリダイレクトするサービスを使用するように構成できます。一方、DSS ユーザーは、別のサービスを使用して読取り専用のインスタンスにセッションをリダイレクトするように構成できます。サービスが構成されると、セッションは自動的に適切なノードに転送されるため、お客様が手作業で介入しなくとも、サービスではリソースが最適に使用されます。

接続ロードバランシング

クライアント側“ロードバランシング”は、クライアント接続文字列のアドレス・リストで SCAN を使用することで、クラスタ内のすべての SCAN リスナーに接続リクエストを分散させます。SQL*NET は、SCAN IP アドレスの 1 つをランダムに選択します。

サーバー側ロードバランシングは、SCAN リスナーを使用して実現されます。各 SCAN リスナーは、各サービスを提供するクラスタのインスタンスすべてを認識します。サービスに定義された目標に基づき、リスナーは目標を達成するのに最適なインスタンスを選択し、ローカルのリスナーを通じて、そのインスタンスへの接続を確立します。

ロードバランシング・アドバイザ

ロードバランシングによって、利用可能なすべての Oracle RAC データベース・インスタンス間に作業を分散できます。アプリケーションは、接続プールを使用し、特定のサービスを提供するインスタンスをまとめて永続的に接続しておくことが推奨されています。永続的接続を使用すると、接続が作成される頻度が低く、長期間維持されます。その分、頻繁な処理要求があっても、この接続を借用し、短時間で処理できます。ロードバランシング・アドバイザにより、ユーザーからの接続要求を、その負荷に最適な品質のサービスを提供するインスタンスに振り分けます。このため、後で負荷を再配置する手間が最小限で済みます。

上記のコンポーネントがすべて密に連携し、全体的に最適なサービス時間となるように負荷が再ルーティングされ、刻々と変化し続けるシステムの状況に合わせて再ルーティングされます。

より優れたスケーラビリティ

お客様が管理しなければならないデータの量は、驚異的な速度で増加しています。企業は、より適切に日々の業務や長期的なビジネス・イベントに対応するために、データを取得して分析するという困難なタスクに直面し続けています。このような大量のデータを処理するには、相当な計算能力が必要です。Oracle RAC はそのようなタスクに最適です。お客様はより小規模な基盤を配置し、徐々に必要に応じて水平にスケールアウトできるためです。

図 3 は、Oracle RAC を使用した SAP 販売管理（SD）モジュールのベンチマーク結果です。Oracle インスタンスをシステムに追加するのに伴い、SD ユーザーが増加していることが示されています。

8 | Oracle Real Application Clusters 12c Release 2 – 技術概要

図3：アプリケーション・コードの変更が不要なスケーラビリティ

Oracle RAC では、可用性とスケーラビリティのあらゆる機能に加えて、ほとんどのアプリケーションが必要とする ACID プロパティも提供されます。Oracle RAC を使用してアプリケーションをデプロイするお客様は、最新ではない誤ったデータを読み取る心配がありません。トランザクション管理に関するすべての要件は Oracle RAC によって処理されるため、お客様はビジネス・ロジックをアプリケーションに追加することに集中できます。その上、Oracle RAC とともに、Oracle Database の他の機能も活用できます。たとえば、Oracle RAC とともに、Oracle Data Guard をディザスタ・リカバリに使用したり、Oracle In-memory Database を高度な分析に、Oracle Multitenant を統合集約化に使用したりできます。その際、構成の変更はほとんど、または全く必要ありません。実際、このようなデータベース機能がもたらす利点は、Oracle RAC とともに使用することでさらに増大します。

アルゴリズムの改善

Oracle RAC のスケーラビリティの高さは、技術の進化に合わせて、アルゴリズムを最適化した結果です。Oracle Real Application Clusters のコンポーネントである Oracle キャッシュ・フュージョンは、複数のユーザーが Oracle RAC インスタンスのキャッシュを盛んに更新するトランザクションを実行している場合でも、すべての Oracle RAC インスタンス上のバッファ・キャッシュを背後で同期させることができる機能です。この同時実行性に手作業の操作は一切不要です。これまでは回転ディスクのパフォーマンスが低かったため、Oracle キャッシュ・フュージョンでは最近まで、プライベート・ネットワークを単独で利用してキャッシュの同期を維持していました。しかしながら、ストレージ・ベンダーが SSD や NVME などの新たなテクノロジーを利用して I/O レイテンシを低減した結果、ディスクのパフォーマンスは近年向上しています。そのため、特定の状況下においては、プライベート・ネットワーク経由でブロックを送信するよりも、ディスクからブロックを読み取る方が実際は有効な場合があります。

9 | Oracle Real Application Clusters 12c Release 2 – 技術概要

キャッシュ・フュージョンの強化されたアルゴリズムにより、双方の利点がもたらされます。図 4で示すように、キャッシュ・フュージョンではネットワークとストレージ I/O 統計を継続的に監視し、必要に応じてより効率的なパスを利用します。この処理は、手作業による介入なしに、自動的かつ継続的に行われます。こうした最適化により、お客様はハードウェアを変更した場合でも、手作業で環境をそのハードウェアに適応させなくとも、Oracle Real Application Clusters の利点を引き続き享受できます。

Oracle RAC により複雑なアルゴリズムをアプリケーション側に実装する作業から解放されます。アプリケーション・コードの変更は不要です。

図4：アプリケーション・コードの変更が不要なスケーラビリティ

サービス指向バッファ・キャッシュ

Oracle RAC 12c Release 2 で導入されたサービス指向バッファ・キャッシュにより、計画された単一サービスのフェイルオーバー後、“物理的な読取り”は基本的に削減されるか、多くの場合は排除されます。この機能が導入される以前は、単一サービスのフェイルオーバーはレスポンス時間に影響を及ぼしていました。障害が発生したインスタンスにキャッシュされたバッファは、ディスクから再度読み取る必要があり、物理的な読取りでオーバーヘッドが発生していたためです。Oracle RAC 12c Release 2 以降、バッファ・キャッシュのブロック、およびセッションが接続に使用するサービス名を追跡するインメモリ・ハッシュが、キャッシュ・フュージョンによって保守されるようになりました。キャッシュ・フュージョンでは、このハッシュを次の 2 つの方法で使用します。

10 | Oracle Real Application Clusters 12c Release 2 – 技術概要

(a) リソース制御の最適化：バッファにキャッシュされたリソースの制御は、セッションがリソースへのアクセスに使用したサービスを実行中のノードでのみ考慮されます。これにより、リソースの変更操作のたびにメッセージをプライベート・ネットワークに送信する必要がなくなるため、パフォーマンスが向上します。

(b) バッファ・キャッシュのリロード：計画的なメンテナンスにおいて単一サービスがフェイルオーバーされる場合、キャッシュ・フュージョンにより、サービスがこれからフェイルオーバーを行う先のインスタンスのバッファにリロードします。これにより、セッションが引き起こしたであろう物理的な読取りが削減され、図 5 で示すように、フェイルオーバーされたセッションで一貫したパフォーマンスが実現します。

図5：サービス指向バッファ・キャッシュ

プラガブル・データベースとサービスの独立性

統合集約化により、お客様は全体的なコストを抑えながら、利用可能な処理能力をより効率的に使用できます。オラクルでは、統合のためのさまざまなソリューションを提供しています。ソリューションは、お客様のニーズに応じて組み合わせて使用することも、個別に使用することもできます。Oracle Multitenant オプションは、統合に使用されるそのようなオプションの 1 つです。可用性を十分に計画することなくデータベースを統合する場合、万一の停止時間が心配です。複数のデータベースを 1 つのサーバーで実行すれば、そのサーバーがシングル・ポイント障害となるためです。Oracle RAC をシームレスに使用すれば、Oracle Multitenant に高可用性をもたらすことができます。異なるノードで複数の Oracle RAC インスタンスを実行させた場合、そのような統合環境では、ノードの障害によって停止時間が発生することはありません。さらに、お客様はサービスの独立性の利点を活かし、“プラガブル・データベース”をインスタンスに割当てて分散ロック・マネージャ（DLM）の動きを抑え、一貫したパフォーマンスを達成できます。サービスを 1 つのインスタンスに局在化し、ブロック操作を最適化することができます。

11 | Oracle Real Application Clusters 12c Release 2 – 技術概要

より優れた可用性

ビジネスがアプリケーションやデータベースの停止時間のために負うコストは、年を追うごとに増加しています。統合環境では、複数のアプリケーションやデータベースが影響を受ける場合があるため、このコストはさらに増加します。データセンターでは、複数のレイヤーで冗長性を計画することが、可用性を実現するためには重要です。ファームウェアや OS に対するパッチ適用などのタスクには、計画停止時間が必要です。クラスタからノードを削除する、またはクラスタにノードを追加する作業では、（a）下層のデータベースの中断を最小限に抑え、（b）計画的なメンテナンス操作の影響を受けるノードに接続するユーザー・セッションに対して通知を行うことが不可欠です。そうすることで、これらのセッションをクラスタ内の別のノードに正常に再接続できます。

スマートな再構成

Oracle RAC 12c Release 2 では、Recovery Buddy やサービス独立性などの機能を使って、計画的な操作と計画外の操作の双方による中断がさらに低減されているため、前リリースよりも最大で 4 倍高速になりました。

Recovery Buddy

Recovery Buddy により、すべての Oracle RAC インスタンスに Buddy インスタンスの概念が導入されます。

図6：Recovery Buddy

Recovery Buddy では、Buddy インスタンスの SGA のハッシュ表上でブロック変更が追跡されます。インスタンスが排除されると、そのインスタンスによる変更はその Buddy インスタンスの SGA で利用可能になります。この最適化により、ディスクから REDO ログの変更が読み取られる代わりに、このハッシュ表の最適化により、インスタンスのリカバリ速度が大幅に向上します。Recovery Buddy 機能と最適化された単一ワークロード・スケーリングにより、再構成にかかるパフォーマンスがほぼ 4 倍向上します。

12 | Oracle Real Application Clusters 12c Release 2 – 技術概要

オラクルの、読取りノード上の読取インスタンス

Oracle Grid Infrastructure 12c では、ノードをハブ・ノードまたはリーフ・ノードとして分類するOracle Flex Cluster の概念が導入されました。Oracle Grid Infrastructure 12c Release 1 では、データベース・インスタンスはハブ・ノードにのみインストールでき、リーフ・ノードはアプリケーションをホストするために使用されていましたが、Oracle Grid Infrastructure 12c Release 2 より、リーフ・ノードで読取り専用インスタンスを実行できるようになりました。このアーキテクチャでは、ハブ・ノードで実行されているデータベース・インスタンスが、リーフ・ノード上の読取専用インスタンスのクラスタへの追加・削除の影響を受けないため、可用性が大幅に向上しました。お客様は、OLTP サービスを、ハブ・ノードで実行されているインスタンスに接続するように構成し、DSSまたは読取りセッションを、リーフ・ノードで実行されているインスタンスに割当てできます。

クラスタに追加・削除されるリーフ・ノードは、データベースの全体的な可用性には影響を及ぼさないため、お客様は、読取専用インスタンスをリーフ・ノードに追加することで、DSS 問合せのパフォーマンスをスケールアップして向上できます。メモリを追加し、パラレル問合せスレーブを読取専用インスタンスで実行されるようにすれば、ソートやハッシュ結合などの一般的なパラレル問合せ処理の向上に役立ちます。また、リーフ・ノードで実行されるインスタンスは、新たに“ローカル一時表領域”を使用して構成できるようになりました。大量のソートやハッシュ結合を実行しているパラレル問合せスレーブでは、物理メモリが足りなくなり、代わりにディスクを使用しなければならない場合に、このローカル一時表領域を利用できます。図 7 では、4 つのノードの RAC インスタンスと、サービスが構成された 2 つのハブ・ノードと 2 つのリーフ・ノードを示しています。

図7：リーダー・ノードの読取り専用インスタンス

Node Weighting

Oracle RAC 12c Release 2 以前は、クラスタがネットワーク障害で分断されるスプリット・ブレインが発生した場合のノードの排除は、ユーザーのワークロードは考慮されず、ノード番号が大きいノードを排除し、ノード番号が小さいノードをクラスタに残すというパターンに従っていました。この方法は効果的であるものの、ワークロードの重大性や二次的な障害は考慮されませんでした。

Oracle RAC 12c Release 2 では、ノードで実行中のワークロードの重大性、ノードで実行中のサービス数、さらには公共のネットワーク障害といった二次的な障害などの側面までも考慮した Node Weighting 機能が導入されました。そのため、スプリット・ブレインが発生した際は、どのノードを排除するかを情報に基づき決断できるようになりました。

13 | Oracle Real Application Clusters 12c Release 2 – 技術概要

データベースの管理者は、構成時に重要とマーク付けするノードを任意に設定できます。重要性の度合いは、適宜 crsctl または srvctl コマンドを使用して、ノード・レベルまたはサービス・レベルで定義できます。ノード・レベルの定義は、例えば、他のノードよりも CPU やメモリが多い特定のノードをマーク付けするために使用します。一方、サービス・レベルの定義は、そのサービスが、クラスタで実行されている他のサービスよりも重要であるとみなされる場合に使用します。

アプリケーション・コンティニュイティ

アプリケーションの継続性を提供するアプリケーション・コンティニュイティ機能では、ノードをクラスタに追加・削除する際のサービス停止に気づかれずに、関係するデータベース・セッションで仕掛中の作業を暗黙的に再実行しなおすことができます。Oracle RAC 12c Release 2 では、アプリケーション・コンティニュイティは Java、OCI、および ODP.NET を使用しているアプリケーションで使用でき、WebLogic や Tomcat をはじめとする大半のアプリケーション・サーバーと統合できます。

アプリケーション・コンティニュイティについて詳しくは、http://www.oracle.com/technetwork/jp/database/options/clustering/applicationcontinuity/overview/index.html を参照してください。

クラスタ・プールの効率的な管理

お客様が管理しなければならないデータ量は増え続け、分析やモノのインターネット（IoT）といった新たな潮流により、ますます多くのデータが生成され続けています。加えて、データ・マイニングによってさまざまなビジネス・サービスを向上させるニーズは、組織にとっていっそう重要になっています。増え続けるデータを管理するデータベースとアプリケーションには、効率的で拡張性の高い稼働環境が必要です。これらの稼働環境は、稼働開始後、ワークロードのスケジューリングとパフォーマンス管理という両方の側面から管理する必要があります。Oracle RAC 12c Release 2の Rapid Home Provisioning（RHP）と Autonomous Health Framework（AHF）を使用すれば、稼働環境を規模の大小にかかわらず効率的に管理できます。

Oracle Rapid Home Provisioning

Oracle RHP により、オラクルのソフトウェア・インフラストラクチャにおけるあらゆるレイヤーのプロビジョニング、パッチ適用、アップグレードを、運用を中断することなく効率的に実施する方法が提供されます。レイヤーには、Oracle Grid Infrastructure、Oracle Database（RAC、RAC One Node、シングル・インスタンス）、アプリケーション、およびミドルウェアが含まれますが、これらに限定はされません。

RHP を構成することで、図 8 で示すようなスタンドアロン・クラスタ、ドメイン・サービス・クラスタ、メンバー・クラスタでの、プロビジョニング、アップグレード、パッチ適用が容易になります。RHP そのものは、スタンドアロン配置モデルで、または新たなクラスタ・ドメイン配置モデルの一部としてプロビジョニングできます。RHP では、ゴールド・イメージを使用して、お客様のソフトウェア・インストールを標準化できます。基本的にお客様は、環境またはサイト固有のゴールド・イメージを作成でき、ゴールド・イメージはその後、展開する標準イメージとして使用できます。

14 | Oracle Real Application Clusters 12c Release 2 – 技術概要

図8：Rapid Home Provisioning

Oracle Autonomous Health Framework

管理者は、運用、監視、管理、調整が必要なシステムの増加に絶えず悩まされ、そのようなシステムを定められた品質保証契約（SLA）の下で効率的に稼働し続けることに閉口しています。Oracle Autonomous Health Framework は、次世代ツールの集合です。これらのツールが 24 時間 365 日体制で自律的に稼働することで、人的な対応時間を最小限に抑えながら、データベース・システムの健全な稼働が維持されます。これらのコンポーネントには、以下に示すように、既存のツール ORAchk、Cluster Verification Utility、Trace File Analyzer、Cluster Health Monitor、Quality of Service Management、Memory Guard のコンポーネントとして含まれるほか、Cluster Health Advisor やHang Manager の新規コンポーネントも含まれます。

図9：Autonomous Health Framework

15 | Oracle Real Application Clusters 12c Release 2 – 技術概要

Oracle RAC 11g では、管理者が目的ごとにワークロードを分割して管理しやすいチャンクにし、チャンクごとにクラスタ内の個別のノードで実行するよう指示する、概念としてのサービスが導入されました。たとえば、OLTP サービスは、すべての OLTP ユーザーに対して定義され、分析サービスは、DSS ワークロード向けに定義されます。本番システムでは、こうしたワークロードが制御不能な問合せ処理や障害などの影響を受ける可能性があり、当該サービスの品質保証契約（SLA）に影響を及ぼしかねません。このような障害の根本原因を突き止めるには、手作業による介入が必要であり、対応に時間を割くことは、システム管理者とデータベース管理者の職務としてのしかかります。（a）問題を素早く見つけ、（b）できれば SLA に影響が及ぶ前に問題を隔離することがますます重要になっています。

そうした問題に対処するため、Oracle Autonomous Health Framework の各種コンポーネントは、ともにデーモン・モードで機能し、応答時間がこれらのシステムに与える影響を最低限に抑えます。Cluster Verification Utility（CVU）や ORAchk などの AHF コンポーネントは、Oracle RAC Databaseをはじめとするソフトウェアおよびハードウェア・コンポーネントの Oracle スタックに対する、軽量で邪魔にならない範囲で健全性チェックが提供されます。また、既知の問題に対する事前スキャンが実施され、解決策が提案されます。

Cluster Health Monitor、Cluster Health Advisor、Hang Manager、Trace File Analyzer（TFA）、Quality of Service Management などの AHF コンポーネントは、密に連携して、可用性と診断能力の向上にむけ、ノードのパフォーマンス・メトリクスを絶えず監視してワークロードを効率的に調整します。Hang Manager では、データベースの障害検知と回復を行い、SLA に影響を及ぼすデータベース障害の発生を喰いとめます。TFA では、複数のノードで関連する診断情報を収集し、Oracle Support Services が問題を解決するのに役立ちます。Cluster Health Monitor によって収集されたデータは Cluster Health Advisor によって集約され、差し迫ったパフォーマンス問題を早期に警告します。機械学習の概念を、AHF デーモンによって収集されたデータに適用し、使用パターンを絶えず学習することで、（a）パフォーマンスの低下やサービスの中断を招く問題を予測し、（b）コンポーネント、サーバー、およびインスタンス障害の正確な原因を突き止めます。

AHF の各種コンポーネントは自律的に連携することで、システムの健全性に影響を及ぼす可能性のある問題を特定し、最小限の労力で問題を迅速に解決するための是正措置を提供します。

16 | Oracle Real Application Clusters 12c Release 2 – 技術概要

まとめ

OLTP システムでは、恒常的に高いスケーラビリティと可用性が求められます。こうした重要なシステムではいかなる停止時間も許されません。膨大なデータを素早く分析し、変化し続けるお客様の需要に対応することがますます重要になっています。Oracle Real Application Clusters を Oracle RAC ソリューション・ファミリーとともに使用することで、ビジネス継続性、高可用性、スケーラビリティ、柔軟性、俊敏性などの利点を容易に活かし、変化し続けるビジネス・ニーズに迅速に適応できます。Oracle Real Application Clusters 12c Release 2 は引き続き、ビジネスの持続的な成功に向けてあらゆる面で役に立つよう、大幅な機能強化を実現しています。Autonomous Health Framework や Rapid Home Provisioning などの新機能を導入し、スタックの全コンポーネントでアルゴリズムを改善した Oracle RAC は、クラウド時代の IT 基盤構築に向けた最適なデータベース・ソリューションです。

Oracle Corporation, World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065, USA

海外からのお問い合わせ窓口

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

C O N N E C T W I T H U S

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

Copyright © 2016, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や法律による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません。オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクルの書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。 Oracle および Java は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。 Intel および Intel Xeon は Intel Corporation の商標または登録商標です。すべての SPARC 商標はライセンスに基づいて使用されるSPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMD ロゴおよび AMD Opteron ロゴは、Advanced Micro Devices の商標または登録商標です。UNIX は、The Open Group の登録商標です。0116 Oracle Real Application Clusters 12c Release 2 – 技術概要 2017 年 3 月 著者：Anil Nair 共著者：Markus Michalewicz