Oracle Clusterware 18c技術概要 Oracle ホワイト・ペーパー | 2018 年 2 月

1 | Oracle Clusterware 18c技術概要

目次

概要 ................................................................................................................................................................... 2

クラスタ・ドメイン ...................................................................................................................................... 3

変換 ........................................................................................................................................................... 3

Oracle ACFS リモート・サービス ...................................................................................................... 5

アプリケーション・メンバー・クラスタでの単一ネットワーク・サポート ......................... 6

共有 SCAN ........................................................................................................................................................ 7

ノード VIP のないクラスタ .......................................................................................................................... 9

クロスクラスタ依存性プロキシ ............................................................................................................... 10

まとめ ............................................................................................................................................................. 12

2 | Oracle Clusterware 18c技術概要

概要

Oracle Clusterware を使用すると、通常は個々に独立したサーバーをクラスタ化し、1 つのシステムとして連携させることができます。これらのサーバーは、クラスタとして、Oracle Real Application Cluster（RAC）Databases とユーザー・アプリケーションが高可用性と高スケーラビリティ確保のために利用する統合基盤を提供します。

サーバーのクラスタは Oracle Clusterware を介して連携し、1 台以上のクラスタ・サーバーやノード上のクラスタで稼働する Oracle RAC データベースとアプリケーションの高可用性要件に対応できるように、必要に応じてクラスタ・リソースを提供します。Oracle 10g Release 1で導入された Oracle Clusterware は、より汎用性のある高機能なインフラストラクチャへの需要に対応するためにその機能を進化、拡張させた一方で、イベントおよびアクションの調整の多くを内部で自動化してきました。

Oracle Clusterware 12c Release 2 では、特に大規模クラスタ資産に関して実際の所有コストの低下を目指す新しい機能や強化点が提供されました。Oracle Clusterware 18c でも、主に操作性の向上と省力化の点でそのような機能強化が継続されます。

Oracle Clusterware 18c には、次の新機能と強化点が導入されています。

» クラスタ・ドメイン・アーキテクチャの強化：

» 変換：

o スタンドアロン・クラスタからメンバー・クラスタへ

o データベース・メンバー・クラスタのストレージ・アクセス構成を別のストレージ・アクセス構成へ

» Oracle ACFS リモート・サービス：ドメイン・サービス・クラスタ上のリモートからホスティングされた ASM ストレージ・サービスを利用する、ローカル・メンバー・クラスタ上の Oracle ACFS ファイル・システムを有効化します。

» アプリケーション・メンバー・クラスタでの単一ネットワーク・サポート。

» 共有 SCAN - あるクラスタの SCAN VIP が別のクラスタの SCAN VIP として機能するようにオプションで選出すると、複数クラスタに対して単一 SCAN VIP セットアップを使用することになり、必要な IP アドレスの数を削減できます。

» ノード VIP のないクラスタ - オプションで、ノード VIP なしで新しいクラスタをデプロイすることで、クラスタ・リソースを解放して必要な IP アドレスの数を削減できます。

» クロスクラスタ依存性プロキシ - 複数クラスタにわたる Clusterware リソース依存関係をサポートします。

3 | Oracle Clusterware 18c技術概要

クラスタ・ドメイン

Oracle Clusterware 12c Release 2 でオプションのデプロイメント・モデルとして導入されたクラスタ・ドメイン・アーキテクチャにより、導入がシンプルで簡単になり、ストレージ管理の負担が軽減され、I/O 操作におけるパフォーマンスが向上します。特に大規模な Oracle Clusters を管理する場合にとても便利です。Oracle Clusterware 18c は、リモート ASM ストレージを利用するにも関わらずメンバー・クラスタ上にローカルにマウントされた Oracle ACFS ファイル・システムのサポートを追加し、既存のスタンドアロン・クラスタからメンバー・クラスタへの変換をサポートすることで、このアーキテクチャ上に構築されます。

図1：クラスタ・ドメイン・アーキテクチャ

変換

Oracle Database 12c Release 2 でクラスタ・ドメインが導入されたとき、新しいアーキテクチャを採用するのは新しくデプロイされるものだけであると予測されていたため、Oracle Universal Installer（OUI）によるサポートのみが要件でした。これが採用された今では、Oracle Database 18cで追加された新機能が変換の需要に対応しています。

スタンドアロン・クラスタからメンバー・クラスタへの変換

Oracle Clusterware 18c ではまず、スタンドアロン・クラスタをローカル ASM を持つメンバー・クラスタに変換できる変換機能が導入されました。この変換により、Grid Infrastructure Management Repository（GIMR）がローカルにある必要性が実質的に排除されてローカルの共有ストレージが解放される一方、クラスタ・ドメインの管理サービスをサブスクライブすることでこれをドメイン・サービス・クラスタに移動できます。

4 | Oracle Clusterware 18c技術概要

図2：スタンドアロン・クラスタ（ローカルGIMR）からデータベース・メンバー・クラスタ（DSCにオフロードされたGIMR）への変換

データベース・メンバー・クラスタのストレージ・アクセス変換

Oracle Clusterware 18c では新たに、ASM が管理するリモートのストレージを使用する際に、確立されたデータベース・メンバー・クラスタのストレージ・アクセス方式を変換する機能が導入されました。この変換により、データベース・メンバー・クラスタは、ドメイン・サービス・クラスタ（DSC）上の IOServer を使用するか、ストレージに直接アクセスするかを切り替えられるようになります。

図4：リモートASMを使用するデータベース・メンバー・クラスタのストレージ・アクセス変換

5 | Oracle Clusterware 18c技術概要

この機能は、長い停止時間を必要とすることなく、クラスタ・ドメインの柔軟性と適応力をさらに強化します。ただしこの変換では、新しいアクセス・パスをサポートするよう基盤となるインフラストラクチャを変更するために、データベース・メンバー・クラスタを短時間停止する必要があります。

Oracle ACFSリモート・サービス

Oracle ACFS 18c では、データベース・メンバー・クラスタおよびアプリケーション・メンバー・クラスタ上でのネイティブの Oracle ACFS 機能のサポートが導入されています。ローカル共有ファイル・システムのない Oracle のメンバー・クラスタは、ドメイン・サービス・クラスタ上でホスティングされる Oracle ACFS リモート・サービスを介して、Oracle ACFS のすべての特長と機能を活用できます。

このサービスを使用することで、メンバー・クラスタがリモート・ストレージを使用しながらローカル・ストレージを共有できるようになりました。NFS マウントの管理も不要です。Oracle ACFSファイル・システムは、フラット・ファイル、ログ、トレース・ファイル、抽出、およびデータベース・ファイルにも使用できます。

図3：アプリケーション・メンバー・クラスタ上にマウントされたOracle ACFSリモート・ファイル・システム

6 | Oracle Clusterware 18c技術概要

アプリケーション・メンバー・クラスタでの単一ネットワーク・サポート

アプリケーション・メンバー・クラスタでは、クラスタ・インターコネクトに対する専用プライベート・ネットワークの要件はなくなりました。デプロイメント時に、プライベート・ネットワーク情報を提供するオプションがあり、それが空欄のままである場合（デフォルト）、クラスタ・インターコネクト・トラフィックはすべて、パブリック・ネットワーク間でルーティングされます。これにより、アプリケーション・メンバー・クラスタのデプロイメントが大幅に容易になります。

デプロイメント時に、インターコネクト・トラフィックがパブリック・ネットワークを使用するように指定します。

図6：アプリケーション・メンバー・クラスタのデプロイメント時にパブリック・ネットワークのみを選択

アプリケーション・メンバー・クラスタのインターコネクト・トラフィックは、クラスタの健全性とメンバーシップのメッセージに制限されます。キャッシュ・フュージョン・トラフィックはありません。このため、アプリケーション・メンバー・クラスタに単一ネットワーク（つまりパブリック・ネットワーク）を使用できるようにすることは、比較的簡単な機能強化です。ただし、Oracle RAC データベースをホスティングするクラスタでは、インターコネクト・ネットワーク間を行き来する通信量のかなりの割合をキャッシュ・フュージョンが占めるため、事情が異なります。Oracle RAC データベースのパフォーマンスおよび応答性は、キャッシュ・フュージョン・トラフィックの独立性と信頼性に依存します。さらに、プライベート・インターコネクト・ネットワークを使用すると、そのキャッシュ・フュージョン・トラフィックを暗号化する必要がありません。これは、アプリケーション・メンバー・クラスタのインターコネクト・トラフィックには不要です。

7 | Oracle Clusterware 18c技術概要

共有SCAN

共有 SCAN は主に、クラスタ・デプロイメント時に必要な IP アドレスの数を削減するために導入されました。クラスタ上に構成された共有 SCAN VIP（‘共有 SCAN クラスタ’）では、既存および新しい 18c 以降のクラスタを、それらクラスタの各々に対して構成するのでなく、この単一 SCAN VIPセットアップを利用するように構成できます（‘共有 SCAN クライアント’）。

共有 SCAN は、ローカル SCAN がセットアップされたそのときにセットアップ さ れ ます 。 つま り 、既 存の SCANセットアップを共有 SCAN として利用できます。違いは、接続がこの共有SCAN を介してどのように共有 SCAN クライアントにルーティングされるかです。主要な相違点は SCAN リスナーの場所です。ローカル SCAN セットアップではローカル・クラスタのノード上に構成されますが、共有 SCAN では共有 SCAN クラスタ上に構成されます。

データベース・クライアント（ユーザー）は、共有 SCAN VIP を介して、共有 SCAN ク ラ ス タ 上 の そ れ ぞ れ のSCAN リスナ ーに接 続しま す。共有SCAN クラスタ上の SCAN リスナーは、続いて共有 SCAN クライアント上のサービスやデータベースの登録済エンドポイントに新しい接続をリダイレクトします。

共有 SCAN を使用するようにクラスタを構成する手順：

» 共有 SCAN クラスタ上のリソースをセットアップする（共有 SCAN クライアントごとに） - 手動で発行：

• 新しい共有 SCAN クライアントに SCAN リスナーと ONS 構成を作成する：

o srvctl add scan_listener -clientcluster <cluster_name>

o srvctl add ons -clientcluster <cluster_name>

• 注：共有 SCAN クライアントごとに 1 つの SCAN リスナーが作成されることになります（たとえば、共有 SCAN クラスタを使用するように構成されたデータベース・クラスタが 6 つある場合、その共有 SCAN クラスタ上に 6 つの SCAN リスナーが構成されることになります）。

• 共有 SCAN クライアントに対して資格証明ファイルを作成する：

o srvctl export scan_listener -clientcluster <cluster_name> -clientdata <filename>

SCAN とは

Single Client Access Name （ SCAN） は 、 Oracle Real Application Clusters（Oracle RAC）環境で使用される機能です。SCAN を使用すると、クラスタ内で実行中のOracle Database にアクセスする際に、クライアントは単一の名前を使用できます。Oracle 11g Release 2 で導入され、クラスタ・ノードの変更（ノードの追加、削除など）の影響をユーザーが受けないようにできます。

Oracle RAC デ ー タ ベ ー ス が SCAN LISTENERS （remote_listener）を登録することで、SCAN LISTENERSが接続文字列に応じて特定のデータベースにユーザー接続をリダイレクトすることを可能にします。

SCAN について詳しくは、次を参照してください。 Oracle Single Client Access Name ホワイト・ペーパー

8 | Oracle Clusterware 18c技術概要

o srvctl export ons -clientcluster <cluster_name> -clientdata <filename>

• 注：ONS と SCAN リスナーの両方に対して単一の資格証明ファイルを指定できます。また、共有 SCAN がドメイン・サービス・クラスタ（DSC）上に構成される場合、SCAN リスナーと ONS の資格証明は、構成されるデータベース・メンバー・クラスタの資格証明ファイルに含まれます。

» 共有 SCAN クライアント上にリソースと接続をセットアップする - 次のコマンドを手動で発行するか、OUI を介して：

• 共有 SCAN クラスタから共有 SCAN クライアントに資格証明ファイルをコピーする

• ローカル・リソースを作成してデータベースの接続性情報を共有 SCAN クライアントに保存する：

o srvctl add scan -clientdata <filename>

o srvctl add scan_listener -clientdata <filename>

o srvctl add ons -clientdata <filename>

より簡単にするには、デプロイメント時に共有 SCAN の資格証明ファイルを指定します。

図7：SCAN/ONS資格証明ファイルのファイル名を入力

9 | Oracle Clusterware 18c技術概要

データベース・クライアント（ユーザー）は、ローカルに構成された SCAN の場合にクラスタ上のデータベースに対して行うのと同様に、共有 SCAN クライアント上の特定のデータベースに接続します。接続文字列には、SCAN の名前、ポートおよびサービスを、ローカルの SCAN 構成の場合とまったく同様に指定します。共有 SCAN クラスタ上の SCAN リスナーを識別するポートとサービスである点に注意してください。

図8：共有SCANとローカルSCANを使用したデータベース・ユーザーの接続

共有 SCAN 実装には、さらに、ローカルに構成された SCAN とまったく同様に 3 つの IP アドレスが必要です。3 つを超える SCAN VIP をデプロイする必要はありません。また、共有 SCAN クライアントは、登録した共有 SCAN クラスタが属するのと同じネットワーク・サブネットに属する必要があります。また、クラスタ・ドメイン実装の場合、共有 SCAN がドメイン・サービス・クラスタ上でホスティングされる点に注意してください。

ノードVIPのないクラスタ

ノード VIP は、データベース・クライアントに HA 接続性を提供するために長らく使用されてきましたが、Oracle データベースをホスティングしないクラスタ内には居場所がありません。そのようなクラスタは‘アプリケーション・クラスタ’と呼ばれることが多く、アプリケーション VIP がクラスタ・ノード上のアプリケーションやプロセスにフォルト・トレラントな接続性を提供することに依存しています。

Oracle 12c Release 2 でのクラスタ・ドメインの導入では、アプリケーション・メンバー・クラスタが、ノード VIP を含まないデプロイメントの最初の例でした。

今回の Oracle Clusterware 18c では、ノード VIP のないスタンドアロン・クラスタはデプロイメント時の 1 つのオプションです。デフォルトではまだノード VIP が構成されますが、これは後方互換性を維持するためです（また、以前のバージョンからアップグレードされたクラスタには、言うまでもなく、ノード VIP があるからです）。このデプロイメント・オプションは、データベースをホスティングしないクラスタや本番用でない（つまり、障害管理が本番システムほどには重要でない）デプロイメントにお勧めです。

デプロイメント時に、仮想ホスト名を指定しないだけです。

10 | Oracle Clusterware 18c技術概要

図9：ノードVIPのないデプロイメントでは仮想ホスト名を省略

クロスクラスタ依存性プロキシ

クロスクラスタ依存性プロキシは、Clusterware のリソース依存性管理を、単一クラスタのドメインを超えて拡張するために作成されました。つまり、1 つのクラスタ上のリソースが、他のクラスタ上のリソースに依存することが起こりえます。

Oracle Clusterware 18c のデフォルトのデプロイメントは、ドメイン・サービス・クラスタ上のASM が管理するストレージにアクセスするクラスタ・ドメインとデータベース・メンバー・クラスタに適用されます。データベース・メンバー・クラスタ上のデータベースは、データベース・データファイルが格納されている ASM ディスク・グループの可用性とアクセス可能性に依存しています。この依存性は、クロスドメイン・プロトコル（CDP）を使用してマップされます。

11 | Oracle Clusterware 18c技術概要

図10：データベース・メンバー・クラスタでのクロスクラスタ依存性プロキシのセットアップ

さらに、ユーザーが他の用途で CDP を実装する場合があります。その例としては、アプリケーション・メンバー・クラスタと、リモートでホスティングされているデータベースの可用性に対してそれが持つ依存性があります。リモートのデータベース・サービスに対してプロキシを作成すると、アプリケーション・メンバー・クラスタを起動することでそのリモート・データベースも確実に起動します。

また、CDP は、リモート・クラスタでのエンティティのステータスを監視するためにも使用されます。その例として、リモート・クラスタ内のどの VM がアクティブかを追跡する監視プロセスがあり、ローカル・プロセスがこの情報に基づいて動作できるため、そのリモート・エンティティへの接続を確立する必要がなくなります。

12 | Oracle Clusterware 18c技術概要

まとめ

Oracle Clusterware 12c Release 2 では、管理性とデプロイメントを大幅に改善し、障害シナリオにおける Oracle クラスタのダメージ軽減とコントロールを向上させました。Oracle Clusterware 18cは、操作性の向上と省力化の推進によりこの傾向を継続していきます。

クラスタ・ドメイン・アーキテクチャが強化されました。Oracle Clusterware 12c Release 2 でのクラスタ・ドメインの導入は、マルチクラスタ・インフラストラクチャの管理とデプロイメントをよりシンプル、簡単、迅速に実行するためのものであり、大規模なクラスタ環境にとって重要な鍵となります。Oracle Clusterware 18c では、この革新的なクラスタ・アーキテクチャを新規および既存のお客様により一層採用していただけるよう、新しい機能を導入しました。

さらに、新しい Oracle Clusterware の主要な特長として、新しいクラスタのデプロイメント時に、データベースおよびデータベース以外のクラスタにおける IP アドレスの数を削減することが可能になり、またクラスタ全体での Clusterware リソース依存性を管理できるようになりました。

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 © 2018, 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 の登録商標です。0218

Oracle Clusterware 18c - 技術概要

2018 年 2 月

著者：Ian Cookson

共著者：Markus Michalewicz