Oracle Real Application Clusters アーキテクチャ詳説編 日本オラクル株式会社 クラウドエンジニアリング統括 オラクルデジタル本部 第一クラウドアーキテクト部 小畑 晶 

1. Oracle Real Application Clusters概要 2. Oracle RACとシングル・データベースとの違い 3. Oracle Grid Infrastructure概要 4. 接続ロード・バランシングと接続フェイルオーバー 5. まとめ Agenda Copyright © 2024, Oracle and/or its affiliates 2 

1. Oracle Real Application Clusters概要 • Oracle Real Application Clusters(Oracle RAC)とは • Oracle RACの特徴 • Oracle RACの代表的な構成 2. Oracle RACとシングル・データベースとの違い 3. Oracle Grid Infrastructure概要 4. 接続ロード・バランシングと接続フェイルオーバー 5. まとめ Agenda Copyright © 2024, Oracle and/or its affiliates 3 

【シングル構成】 • 障害時にサービスが停止する構成 • 予備サーバにOracleソフトウェアをイ ンストールし、再構築する必要がある 【高可用性構成: HA構成】 • 障害時に切り替える待機サーバをあ らかじめ用意 • 現用系と待機系を用意するため、待 機サーバ・リソースは遊休資産となる 構成例: • サードパーティ製Clusterwareとの連携 • CLUSTERPRO X (NEC) • LifeKeeper (サイオステクノロジー) • Windows Server Failover Cluster+ Oracle Fail Safe (19c 非推奨) 【Oracle RAC】 • 複数のサーバのリソースを活用した Active-Activeのクラスタ構成 • 高い性能と高い可用性を唯一両立 Oracle Databaseにおける一般的なデータベース構成例 Copyright © 2024, Oracle and/or its affiliates 4 Active Active Standby Active Active 本日の内容 

Oracle Real Application Clustersとは • システム障害によるダウンタイムを最小に抑え、データ保護と連続的なサービス環境を実現する Oracle Databaseのクラスタ技術 特徴 • 高可用性：Active-Activeのクラスタ構成により、障害時にも継続してサービスを提供可能 • 高拡張性：サーバの追加によって容易にスケールアウトが可能 Oracle Real Application Clusters (Oracle RAC) とは Copyright © 2024, Oracle and/or its affiliates 5 共有ストレージ 障害によるサーバ停止 があっても、サービスは 停止しない 1つのデータベースに 複数のサーバから 同時にアクセスできる 処理量の増加に合わせ、 容易に拡張可能 

高可用性の実現（HA構成との比較） HA(Active-Standby）構成 障害時にストレージ接続の切り替えやデータベースの 再起動が必要 RAC(Active-Active）構成 全てのサーバが稼働しているためすぐに別のサーバで処理 を引き継ぐことが可能 Oracle RACの特徴（１） Copyright © 2024, Oracle and/or its affiliates 6 共有ストレージ 共有ストレージ ストレージ接続 の切り替え 稼働 数分〜十数分 本番機 バックアップ機 待機 データベース 再起動 稼働 稼働 稼働 全てのサーバのリソースを 有効活用 高速な フェイルオーバー 数秒〜数十秒 ※フェイルオーバー: 稼動中のシステムやサーバに障害が発生した際に、 自動的に待機システムに切り替える仕組み 

高拡張性の実現（HA構成との比較） HA(Active-Standby）構成 ハードウェアの処理能力が限界になった場合、ハードウェア をリプレイスしなければならない RAC(Active-Active）構成 それまでのサーバを交換せずに追加することで処理能力 をより安価に向上可能 Oracle RACの特徴（２） Copyright © 2024, Oracle and/or its affiliates 7 共有ストレージ 共有ストレージ 稼働 待機 稼働 稼働 稼働 サーバを追加することで 処理能力を向上 コスト増大 安価にスケールアウト 稼働 サーバごと リプレイス 

Oracle RACの代表的な構成 Copyright © 2024, Oracle and/or its affiliates 8 共有ストレージ データ・ベース・ サーバ データベース・ クライアント パブリック・ネットワーク データベース・クライアントと の通信 インターコネクト・ ネットワーク Computeノード間通信 ストレージ・ネットワーク 全Computeノードが 全ストレージと通信 S/W Oracle データベース 関連ファイル Oracleデータベース関連ファイル REDOログ ファイル UNDO ファイル データファイル 制御 ファイル SPFILE アーカイブ REDOログ ファイル インスタンスごとに 用意 Oracle ソフトウェア • Oracle Database • Oracle Grid Infrastructure • Oracle Clusterware • Oracle ASM DNSサーバ （SCANのIPアドレス解決で使用 ※後述） OS 

参考）Oracle Exadata すべてのデータベース・ワークロードのための 最高のプラットフォーム • 単一ベンダーによるサポート • データベースに特化した設計 • ハードウェアとソフトウェアの 密なインテグレーション • ストレージへの革新的なアプローチ • Real Application Clustersにより、DBサーバを並列稼働させ、 高可用性と高拡張性を実現 • Automatic Storage Managementにより、ストレージ・サーバを並列 稼働させ、高いI/O性能と高可用性・高拡張性を実現 • さらに、Exadata System Softwareが処理の一部をオフロードし、大 量データの高速処理を実現 9 Copyright © 2024, Oracle and/or its affiliates 驚異的なパフォーマンス、優れた運用効率、最高の可用性とセキュリティ、クラウド対応 スケールアウト可能なインテリジェント・ストレージ スケールアウト可能なデータベース・サーバ 最速の内部ネットワーク DBサーバを並列稼働 ストレージを並列稼働 オンプレミスにも クラウドにも 理想的 

1. Oracle Real Application Clusters概要 2. Oracle RACとシングル・データベースとの違い • アプリケーションはシングル・データベースと同じものを利用（透過性） • Oracle RACならではの拡張性 • Oracle RACのデータアクセス • Cache Fusion • Oracle RACのインスタンス・リカバリ 3. Oracle Grid Infrastructure概要 4. 接続ロード・バランシングと接続フェイルオーバー 5. まとめ Agenda Copyright © 2024, Oracle and/or its affiliates 10 

Oracleクライアントから見た挙動がシングル・インスタンスと同じ すべてのOracleインスタンスから同じデータをアクセス • ストレージを共有しており、1つのOracleインスタンスから すべてのデータにアクセス可能 • Oracle RAC独自のデータ構造はなく、シングル・データベー スと同じ トランザクション分離レベルの挙動が同じ • 複数のセッションがノード内/ノード間で同じデータにアクセス したときの挙動が同じ • 複数ノード間でのキャッシュの一貫性を全自動で維持 (Cache Fusion) アプリケーションはシングル・データベースと同じものを利用（透過性） Copyright © 2024, Oracle and/or its affiliates 11 Oracleクライアント Oracle インスタンス2 Oracle インスタンス1 Oracle インスタンス3 Oracle インスタンス4 シングル・インスタンスで開発したアプリケーションがそのまま動作する 

トランザクション系も分析系も同じアーキテクチャで対応 トランザクション系 • 多数のセッションからの同時並行リクエスト • より多くの同時リクエストを処理 集計/分析系 • 1つのSQL処理を並列化 • より高い並列度で1つのSQLを処理 Oracle RACならではの拡張性 Copyright © 2024, Oracle and/or its affiliates 12 Oracleクライアント Oracle インスタンス2 Oracle インスタンス1 Oracle インスタンス3 Oracle インスタンス4 Oracleクライアント Oracle インスタンス2 Oracle インスタンス1 Oracle インスタンス3 Oracle インスタンス4 QC PX PX PX PX PX PX PX PX QC: Query Coordinator PX: Parallel Execution Server 

シングルインスタンスと同じように低速なストレージアクセスを減らすという考え方で動作 キャッシュ・ヒットした場合 • キャッシュのデータを使用 キャッシュ・ミスした場合 • シングルインスタンスの場合 • ストレージから読み込む • RACの場合 • ストレージから読み込む • （存在すれば）他ノードのキャッシュから受け取る Oracle RACのデータアクセス Copyright © 2024, Oracle and/or its affiliates 13 共有ストレージ SGA Buffer Cache サーバ プロセス SGA Buffer Cache SQL発行 

共有ロックのブロックは複数ノードにコピー可能 • Shared モードのデータブロックは複数ノードにコピーを持つこ とができる • 複数ノードで並列に読み出すことができる 更新するには、ブロックの排他ロックが必要 • eXclusive モードのデータブロックは1つのノードしかもつことが できない • 他のノードがキャッシュしていたデータブロックは Null モードに 変換される 参考）データベース・ブロックのロック・モード Copyright © 2024, Oracle and/or its affiliates 14 共有ストレージ SGA Buffer Cache SGA Buffer Cache S S SELECT SELECT 共有ストレージ SGA Buffer Cache SGA Buffer Cache X N UPDATE/DELETE/INSERT SELECT X→N S→N 

Global Resource Directory を使ってキャッシュ状態とデータ・ブロックのロック状態を管理 Global Resource Directory (GRD) • リソース保持ノードとロック状態が記録されるDirectory • クラスタの全てのノードのメインメモリ上に分散配置 • あるデータ・ブロックのロックの状態に責任をもつGRDは、 クラスタのノードのうち1つのみで、リソース・マスタと呼ぶ Global Cache Service (GCS): • バッファ・キャッシュ上のブロックを管理 Global Enqueue Service (GES): • ブロック以外の対象(エンキュー等)を管理 Cache Fusion Copyright © 2024, Oracle and/or its affiliates 15 共有ストレージ SGA Buffer Cache SGA Buffer Cache SGA Buffer Cache GRD GRD GRD サーバ プロセス SQL発行 に格納されている データを処理したい のリソース・マスタ 共有ストレージへの アクセスが早い場合は ストレージから読み込む 

インスタンス障害 • インスタンス(メモリー＋プロセス)上の情報が失われる障害 Oracle RAC構成時: • 障害が発生したインスタンスを再起動しなくてもよい • 正常ノードが障害ノードのREDOログを読み込んでリカバリ実施 • リカバリを実施するインスタンスはIRエンキューを取得 • Global Resource Directoryの再構成 Oracle RACのインスタンス・リカバリ Copyright © 2024, Oracle and/or its affiliates 16 原因: 停電などによるハードウェア障害、プロセス障害などによ り、データベースが異常終了 問題: メモリー上の変更がファイルに反映されていない可能性 解決法: Single構成時: データベースの再起動 (インスタンス・リカバリ) データベース・ バッファ・キャッシュ REDOログ・ バッファ 制御ファイル データ・ファイル REDOログ・ファイル A A 変更履歴 A→B B 変更前データ A A→B SMON B 消失 SGA Buffer Cache SGA Buffer Cache SGA Buffer Cache GRD GRD GRD 共有ストレージ インスタンス１ インスタンス1用 REDO UNDO 消失 インスタンス2 インスタンス3 インスタンス2用 REDO UNDO インスタンス3用 REDO UNDO データ領域 再構成 

可用性レベル（アプリケーションからのデータアクセスの制限度合い） 障害発生からアプリケーションが待たされる時間と範囲 Oracle RACのインスタンス・リカバリ（２） Copyright © 2024, Oracle and/or its affiliates 17 時間 可 用 性 レ ベ ル 高 低 障害 ①インスタンス 障害発生 ②GRD 再構成 ③1回目のREDO読み込み リカバリ対象のブロックを特定 （読み込みのみ） ④2回目のREDO読み込み リカバリ対象のブロックに対する リカバリ処理 ⑤ロールバック アプリケーションからの アクセス待機 リカバリ対象が確定すると、リカバリ対象外にアクセスする アプリケーションは通常通りアクセス可能 リカバリが進むにつれ、 アクセス待機させられる データの範囲が少なくなる ※ Recovery Buddy (12c R2〜)により、 「③1回目のREDO読み込み」の短縮をおこなう 「アプリケーションからのアクセス待機」時間は 19cでは11g R2に比べ 1/6 に短縮 ②、③は並列処理 

1. Oracle Real Application Clusters概要 2. Oracle RACとシングル・データベースとの違い 3. Oracle Grid Infrastructure概要 • Oracle RAC利用時のソフトウェア構成 • Oracle Automatic Storage Management(Oracle ASM) • Oracle Clusterware • Oracle Clusterwareのコンポーネント 4. 接続ロード・バランシングと接続フェイルオーバー 5. まとめ Agenda Copyright © 2024, Oracle and/or its affiliates 18 

Oracle Database Oracle Grid Infrastructure (GI) Oracle Grid Infrastructure / Oracle Database Oracle Grid Infrastructure • エンタープライズ・グリッド・アーキテクチャ用のイン フラストラクチャを提供するソフトウェア • Oracle Clusterware および Oracle Automatic Storage Management (Oracle ASM)が含まれます 【補足】 バージョンの組合せ • Grid InfrastructureとOracle Databaseの バージョンの組合せについては、Oracle Supportの提供する以下のドキュメントをご確 認ください • Oracle Clusterware (CRS/GI) - ASM - Database Version Compatibility (Doc ID 337737.1) Oracle RAC利用時のソフトウェア構成 Copyright © 2024, Oracle and/or its affiliates 19 共有ストレージ Grid ホーム DB ホーム Oracle Clusterware Oracle ASM リスナー Oracle Database ※リスナーはGIのものを利用 

スタック構成イメージ図 高性能、高可用性、管理容易性を提供するデータベースとして理想的なストレージ管理機能 Oracle Databaseのストレージ仮想化機能 • Oracle Databaseに対するボリューム・マネージャ兼ファイル システム • シングルまたはクラスタ環境ともに利用可能 • ASMによるファイルシステム機能も提供 • Oracle Automatic Storage Management Cluster File System (Oracle ACFS) I/O性能を最大限引き出しつつ、ストレージ管理工数を 大幅削減 • すべてのストレージ・デバイスにまたがったディスクの仮想化と ストライピングを自動で行い、アクセスを均一化 • ストレージ・デバイスの増減にあわせた自動リバランス （本セミナーではFlex ASMの説明は省略） Database ASM OS Storage Oracle Automatic Storage Management (Oracle ASM) Copyright © 2024, Oracle and/or its affiliates 20 dbf dbf dbf dbf dbf dbf ・・・ idx idx redo tbl tbl tbl Tablespace ・・・ ・・・ device device device device ・・・ LU LU LU LU ・・・ RAID Group ・・・ Disk Group 詳細: • データベースに最適なストレージ構成の極意 (Oracle Database Technology Night 2016年9月) 

ASMディスク・グループ ASMインスタンス • ASMディスク・グループを管理するメモリとプロセス群 • Oracle インスタンスと同じテクノロジーに基づいており、 Oracle RACと同様クラスタ化できる ASMディスク・グループ • Oracleインスタンスからみえる仮想化ストレージ・プール 障害グループ • データのミラー化コピーを配置するためのもの ASMディスク • ASMディスクを構成する個々のディスク • 通常は物理ディスクをそのまま使用 ASMメタデータ • ASMがディスク・グループの制御に使用する情報 • ディスク・グループに属しているディスク • ディスク・グループで使用可能な領域のサイズ • ディスク・グループのデータファイルのデータ・エクステントの場所 Oracle Automatic Storage Management (Oracle ASM) Copyright © 2024, Oracle and/or its affiliates 21 データベース インスタンス ASM インスタンス 障害グループ A 障害グループ B ASMファイル(データファイルなど) ASMメタデータ ASMメタデータ データ ASM ディスク ミラー化コピー 

Oracle RACの実行に必要なインフラストラクチャを提供 Oracle Clusterware の技術スタック 1. Cluster Ready Services技術スタック • Cluster Ready Services (CRS) CRSリソースの管理・監視 • Cluster Synchronization Services (CSS) クラスタのメンバーシップ管理・監視 2. Oracle高可用性サービス技術スタック • Oracle High Availability Services (OHAS) Clusterwareプロセスの管理・監視 Oracle Clusterwareの2種類のファイル • OCR: Oracle Cluster Registry • クラスタの構成情報の保持 • OLR: Oracle Local Registry • クラスタ内の各ノードに存在し、特定のノードごとにOracle Clusterwareの 構成情報を管理。OHASで利用される • Voting Disk • 共有ストレージ上のハートビート通信経路 Oracle Clusterware Copyright © 2024, Oracle and/or its affiliates 22 共有ストレージ Voting Disk OCR CSS CRS CSS CSS CRS CRS Listener Oracle Listener Oracle Listener Oracle CRSリソース例 OLR OLR OLR OHAS OHAS OHAS ※OCRとVoting Diskは Oracle ASMに配置 (スタンドアロン・クラスタのインストールでは共有ファイル・システムへ格納可能) Oracle ASMで標準、または高い冗長性のディスク・グループを使用することで 複数のVoting Diskが確実に構成される また、OCRは最大５つの場所に配置できる Oracle Clusterware プロセス Oracle Clusterware を監視 VIP VIP VIP 

Cluster Synchronization Services (CSS) クラスタ・メンバーシップの管理 • ハートビートをおこない他ノードの生存確認 • ハートビートが途絶えると、障害ノードを切り離す • ハートビートが一定時間途切れるとCSSが障害として検知 • もっともメンバーシップが多いグループでクラスタを再構成 Oracle Clusterwareのコンポーネント Copyright © 2024, Oracle and/or its affiliates 23 共有ストレージ Voting Disk CSS CSS CSS 共有ストレージ Voting Disk CSS CSS CSS クラスタ再構成 ノード 切り離し ※1 ※2 ※1: タイムアウト値はmisscount(秒)に依存 ※2: タイムアウト値はdisktimeout(秒)などに依存 

Instant Failure Detection ※ • ExadataはCSS間ハートビートと並行して短時間でのノード 障害検出機能がある(約2秒) • 通常、サーバ障害の検出では長いタイムアウトを設定し、誤 検知によるクラスタからのサーバ除外を回避 • ハートビートへの応答が遅い原因が、 CPUが高負荷状態なのか、 サーバ障害によるものなのかをすぐに区別するのは難しいため • Exadataは迅速なサーバ障害確定にRDMAを利用 • RDMAはH/Wを使用するためS/Wが遅くてもリモートのポートは 応答を返す • 4つのRDMA読み取りが、送信元/ターゲットポートのすべての組み 合わせで疑わしいサーバに送信 • 4つの読み取りすべてが失敗した場合、サーバはクラスタから削除 【補足】 • RoCE: RDMA over Converged Ethernet • Ethernet上でInfiniBand RDMAソフトウェアを実行するための プロトコル • Open Consortiumにより規定 • RDMA: リモート・ダイレクト・メモリ・アクセス • 1台のコンピューターがOSやCPUの関与なしにリモート・コンピュー ターからデータにアクセスする機能 • RDMAアクセスの場合、ネットワーク・カードは、余分なコピーやバッ ファリングなしでメモリーを直接読み取り/書き込みすることができる ため、待ち時間が非常に短くなる • RDMAはInfiniBandとともにExadataに導入され、Exadataの高 性能アーキテクチャの基本的な部分 参考）Exadata RoCE Instant Failure Detection (Fast Node Death Detection) Copyright © 2024, Oracle and/or its affiliates 24 RDMA NIC Port #1 NIC Port #2 NIC Port #1 NIC Port #2 詳細: Exadata X8Mの紹介：OLTPとアナリティクスの両方の点で共有 ストレージのすべての利点を備えたインメモリ・パフォーマンス ※ Exadata System Software 19.3以降のExadata X8Mと統合 Grid Infrastructure 12.1.0.2 BP7以降 

Cluster Ready Services (CRS) / Event Manager (EVM) およびOracle Notification Service (ONS) Cluster Ready Services (CRS) • CRSリソースの起動、停止、監視 • 障害を検知すると、リソースの再起動又はフェイルオー バーを試行 • CRSリソースの構成及びステータスはOracle Cluster Registry(OCR)に記録 Event Manager (EVM)および Oracle Notification Service (ONS) • EVMはアプリケーションに対するイベントの発行をおこなう • ONSはイベント通知のためのサービス • Fast Application Notification (FAN) で利用 ※ 後述 Oracle Clusterwareのコンポーネント Copyright © 2024, Oracle and/or its affiliates 25 共有ストレージ OCR CRS CRS CRS Listener Oracle Listener Oracle Listener Oracle VIP VIP VIP クラスタ再構成 VIP 共有ストレージ OCR CRS CRS CRS クラスタ再構成 EVM EVM EVM ONS ONS ONS インスタンス・ ダウン検知 Oracleクライアントへ通知 リソースが再起動 できない場合は フェイルオーバー 

障害箇所 障害内容 Oracleクライア ント・セッション への影響 障害からの復旧の動き 障害からの復旧の流れ (図のボックスの長さはあくまでもイメージです) Oracle Database 致命的でないバッ クグラウンド・プロセ ス障害 影響せず Oracleインスタンスにより 当該バックグラウンド・プロ セスの再起動 ー 致命的なバックグ ラウンド・プロセス 障害 一時的に アクセス不可 正常ノード上の Oracleインスタンスによる インスタンス・リカバリ実施 Grid Infrastructure CRS障害 影響せず CRS再起動 ー CSS障害 一時的に アクセス不可 当該ノードはOS再起動 他の正常ノードによる クラスタ再構成。 (以下と同様の流れ) ハードウェア障害 電源断など 一時的に アクセス不可 他の正常ノードによる クラスタ再構成 障害からの復旧の流れ Copyright © 2024, Oracle and/or its affiliates 26 障害検出 CSS再構成 GRD再構成 CRSリソース(VIPなど)のフェイルオーバー 1回目REDO読み込み 2回目REDO読み込み(リカバリ処理) 時間 障害 通常利用 一部は処理待ち アプリケーションは処理待ち 時間 障害 通常利用 一部は処理待ち 処理待 ※Exadataの場合、ノード障害時の排除時間は２秒 (Instant Failure Detectionによる) 

Oracle Restart • シングル・インスタンス環境におけるOracle Databaseの 可用性を向上させるために利用 • シングル・インスタンス環境でOracle ASMを利用する場合において も利用 • Oracle Clusterwareのサブセット。Oracle Clusterwareから クラスタ構成の管理を省略したもの • ハードウェア障害やソフトウェア障害が発生した後やデータベー ス・ホスト・コンピュータが再起動した場合に常に、様々な Oracleコンポーネントを自動的に再起動できる 参考）Oracle Restart Copyright © 2024, Oracle and/or its affiliates 27 Oracle Database Oracle Grid Infrastructure (GI) Grid ホーム DB ホーム Oracle Restart Oracle ASM Oracle Database 

1. Oracle Real Application Clusters概要 2. Oracle RACとシングル・データベースとの違い 3. Oracle Grid Infrastructure概要 4. 接続ロード・バランシングと接続フェイルオーバー • Single Client Access Name(SCAN) • 接続先の決定 • 接続時ロード・バランシング（Oracle Client機能） • サーバ側接続ロード・バランシング • 接続時フェイルオーバー（Oracle Client機能） • 確立済みコネクションの異常切断への対応（Application Continuity） • コネクション・プール利用時のロード・バランシングとフェイルオーバー • Demo 5. まとめ Agenda Copyright © 2024, Oracle and/or its affiliates 28 詳細: • Oracle Databaseのネットワーク接続 (Oracle Database Technology Night #52) 

SCANおよびSCANの構成 Single Client Access Name (SCAN) • クラスタ内で実行中のOracle Databaseにアクセスする際の 単一の名前（11g R2〜） • SCAN導入前と比べ、クライアントおよびサーバの接続設定 の手間や複雑さを排除 • ロードバランシングやフェイルオーバー機能の設定 • ノード追加 / 削除時の設定変更 • SCAN導入前の tnsnames.ora ファイルの記述例 • ノード上のVIPを直接指定。ノード追加、削除時に修正が必要 SCANの構成 • DNSにSCAN名に対応する3個のIPアドレス (SCAN VIP)を 登録 • SCANの名前解決で3個の内のいずれかのアドレスが戻される (DNSラウンド・ロビンに依存) • SCAN導入後の tnsnames.ora ファイルの記述例 Single Client Access Name (SCAN) Copyright © 2024, Oracle and/or its affiliates 29 (DESCRIPTION = (LOAD_BALANCE=ON)(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=vip1)(PORT = port)) (ADDRESS=(PROTOCOL=TCP)(HOST=vip2)(PORT = port)) (ADDRESS=(PROTOCOL=TCP)(HOST=vip3)(PORT = port)) (CONNECT_DATA=(SERVICE_NAME=SERVICE_A))) (DESCRIPTION = (LOAD_BALANCE=ON)(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=scanhost)(PORT = port)) (CONNECT_DATA=(SERVICE_NAME=SERVICE_A))) DNSサーバ scanhost scanvip1 scanvip2 scanvip3 (DESCRIPTION = (LOAD_BALANCE=ON)(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=scanvip1)(PORT = port)) (ADDRESS=(PROTOCOL=TCP)(HOST=scanvip2)(PORT = port)) (ADDRESS=(PROTOCOL=TCP)(HOST=scanvip3)(PORT = port)) (CONNECT_DATA=(SERVICE_NAME=SERVICE_A))) もしくは 

SCAN VIPとSCANリスナーはクラスタを構成する いずれかのノード上で稼働 • SCAN VIPとSCANリスナーが実行されているノードで障害が発生すると別のノードへフェイルオーバー • SCANリスナーはクライアントからの接続リクエストを、ローカル・リスナーにリダイレクト • サーバ側接続ロード・バランシング（後述） CRSリソースとしてのSCAN VIPおよびSCANリスナー Copyright © 2024, Oracle and/or its affiliates 30 tnslsnr Oracle インスタンス1 vip1 tnslsnr Oracle インスタンス2 vip2 tnslsnr Oracle インスタンス3 vip3 tnslsnr Oracle インスタンス4 vip4 tnslsnr1 (scan) scanvip1 tnslsnr2 (scan) scanvip2 tnslsnr3 (scan) scanvip3 SERVICE_A ノード障害時には フェイルオーバー 

接続時ロード・バランシング（Oracle Client機能） 接続時ロード・バランシング • Client-side Connect-Time Load Balancing • Oracle Listenerを(ランダムに)選択 • 実際に接続先が決まるのは サーバ側接続ロード・バランシングによる 接続先の決定（１） Copyright © 2024, Oracle and/or its affiliates 31 tnslsnr Oracle インスタンス1 vip1 tnslsnr Oracle インスタンス2 vip2 tnslsnr Oracle インスタンス3 vip3 tnslsnr Oracle インスタンス4 vip4 tnslsnr1 (scan) scanvip1 tnslsnr2 (scan) scanvip2 tnslsnr3 (scan) scanvip3 SERVICE_A Oracle Client (DESCRIPTION = (LOAD_BALANCE=ON)(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=scanvip1)(PORT = port)) (ADDRESS=(PROTOCOL=TCP)(HOST=scanvip2)(PORT = port)) (ADDRESS=(PROTOCOL=TCP)(HOST=scanvip3)(PORT = port)) (CONNECT_DATA=(SERVICE_NAME=SERVICE_A)) ) tnsnames.ora ファイル 

サーバ側接続ロード・バランシング • SCANリスナーはどのサービスをどのOracleインスタンスが 担当しているかを認識している • サービスがアクティブになっているOracleインスタンスに 接続リクエストをリダイレクトして負荷分散する • ロード・バランシング・アドバイザ 接続先の決定（２） Copyright © 2024, Oracle and/or its affiliates 32 tnslsnr Oracle インスタンス1 vip1 tnslsnr Oracle インスタンス2 vip2 tnslsnr Oracle インスタンス3 vip3 tnslsnr Oracle インスタンス4 vip4 tnslsnr1 (scan) scanvip1 tnslsnr2 (scan) scanvip2 tnslsnr3 (scan) scanvip3 SERVICE_A Oracle Client ①接続リクエスト発行 ②リダイレクト tnslsnr (scan) SERVICE_A Oracle インスタンス1 Oracle インスタンス2 Oracle インスタンス3 Oracle インスタンス4 SERVICE_Aの 接続先候補 

接続時フェイルオーバー (Connect-Time Failover: CTF) • 障害ノードを避けて正常ノードと接続 • LOAD_BALANCE=OFF の場合、上から接続試行 • SCANリスナーは可用性のために複数存在 接続時フェイルオーバー（Oracle Client機能） Copyright © 2024, Oracle and/or its affiliates 33 tnslsnr Oracle インスタンス1 vip1 tnslsnr Oracle インスタンス2 vip2 tnslsnr Oracle インスタンス3 vip3 tnslsnr Oracle インスタンス4 vip4 tnslsnr1 (scan) scanvip1 tnslsnr2 (scan) scanvip2 tnslsnr3 (scan) scanvip3 SERVICE_A Oracle Client (DESCRIPTION = (LOAD_BALANCE=ON)(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=scanvip1)(PORT = port)) (ADDRESS=(PROTOCOL=TCP)(HOST=scanvip2)(PORT = port)) (ADDRESS=(PROTOCOL=TCP)(HOST=scanvip3)(PORT = port)) (CONNECT_DATA=(SERVICE_NAME=SERVICE_A)) ) tnsnames.ora ファイル 

アプリケーション・コンティニュイティ / Application Continuity • アプリケーション・コンティニュイティ対応接続ドライバは Oracleサーバに発行した処理を記憶 • Oracle接続ドライバがセッション切断を検出すると 自動再接続 • COMMIT時の障害はトランザクション・ガードでトランザクショ ンの状態を確認してCOMMIT完了していなければトランザ クションを自動再実行 • Oracle接続ドライバがセッション切断を検出すると (1) 再接続 (2) トランザクション状態の確認 (3) トランザクション再実行 まで自動で行う。 • アプリケーションから見ると エラーを検出せずにトランザクションが完了 確立済みコネクションの異常切断への対応 Copyright © 2024, Oracle and/or its affiliates 34 Oracle Client Oracle インスタンス1 サーバ プロセス LGWR Oracle インスタンス2 サーバ プロセス LGWR Oracle 接 続 ド ラ イ バ ー DML 1 DML 2 COMMIT : DML 1 DML 2 COMMIT : 再接続 ア プ リ ケ ー シ ョ ン DML 1 DML 2 DML 1 DML 2 COMMIT : トランザクション状態を 管理する内部表 ⇒トランザクション・ガード機能で用意 コミット無し トランザクション・ガード 機能で コミット有無を確認 コミット無し REDOログに書込み 

アプリケーション・コンティニュイティ対応クライアントとリクエスト境界 リクエスト境界 • アプリケーション・コンティニュイティが想定するコード: 1. Oracle製コネクション・プールからコネクション取得 2. DML発行 3. 最後に1回だけCOMMIT 4. コネクション・プールに返却 確立済みコネクションの異常切断への対応（２） Copyright © 2024, Oracle and/or its affiliates 35 【主な対応クライアント】 ... 後述のFAN対応クライアントのサブセット • Oracle JDBC Thin • Replay Driverを利用 • Oracle Universal Connection Pool (UCP) • Oracle WebLogic Server • Oracle Tuxedo for non-XA datasources • Oracle Call Interface (OCI) Session Pool • SQL*Plus • ODP.Net Unmanaged Provider • Managed DriverとCore Driverは未対応 ⇒ 23cより対応 • UCPを使ったサードパーティ製Java Application Server • Tomcatなど 詳細はOracle Supportの提供する以下のドキュメントを ご確認ください • Client Validation Matrix for Application Continuity (Doc ID 2511448.1) ConnectionPool ConnectionPool getConnection() close() DML 1 DML n COMMIT リクエスト境界 

アプリケーション・コンティニュイティの考慮点とアプリケーション・コンティニュイティがカバーできる領域 【考慮点】 • 可変オブジェクト(SYSDATEなど) • 副作用のあるプロシージャの扱い(UTL_MAILなど) • 自律トランザクション(Autonomous Transaction) • アプリケーション・コンティニュイティで再実行できないケース (バッチ処理に多い複数回コミットなど) • 詳細はOracle Database Tech Night ＃39を参照 「アプリケーション・コンティニュイティ セッション異常切断時の更新トランザクション自動再実行」 • 資料 • YouTube • マニュアル記述もご確認ください。 • アプリケーション・コンティニュイティに関する制限および 他の考慮事項 アプリケーション・コンティニュイティがカバーできる領域: • コネクション・プールを使用した(オンライン・トランザクション処 理系)アプリケーション 1. コネクション・プールから論理コネクションを取得 2. 最後に1回COMMIT 3. コネクション・プールに論理コネクションを返却 アプリケーション・コンティニュイティではカバーできない領域: • 分散トランザクション • データベース・リンク、XA • コネクション・プールを使用せずに直結している (バッチ処理系)アプリケーション • リプレイ境界内で複数回COMMITを発行する • 非トランザクション系ツール • RMAN/Data Pump/SQL*Loader ... 確立済みコネクションの異常切断への対応（３） Copyright © 2024, Oracle and/or its affiliates 36 

高速アプリケーション通知 (Fast Application Notification: FAN) Fast Application Notification (FAN) • Oracle Clusterwareからクライアントにイベント通知 • Runtime Load Balancing (RLB)イベント • UP/DOWNイベント ランタイム接続ロード・バランス • (Runtime Connection Load Balance: RCLB) • サーバ側で最適な負荷配分を算出して通知 • プールされたコネクションから負荷配分を考慮してSQLを実行 するインスタンスを決める 高速接続フェイルオーバー • (Fast Connection Failover: FCF) • サービスの起動および停止、ノード停止イベントの通知 • ノード障害時にクライアントは停止したノードとのコネクションを TCPタイムアウトを待たずに切断できる コネクション・プール利用時のロード・バランシングとフェイルオーバー Copyright © 2024, Oracle and/or its affiliates 37 共有ストレージ OCR CRS CRS CRS クラスタ再構成 EVM EVM EVM ONS ONS ONS インスタンス・ ダウン検知 Oracle クライアントへ通知 Oracle Client Connection Pool 無効な接続の 開放 必要に応じて 接続追加 

特定ノードのサービスを停止させる場合のセッション・ドレイン 1. 特定ノードでsrvctl stop instance発行 2. 物理コネクションのドレインを行い、インスタンス停止 FANによるOracleインスタンスの計画停止（FCFの活用） Copyright © 2024, Oracle and/or its affiliates 38 例）srvctl stop instance -node ノード名 -drain_timeout 60 –stopoption TRANSACTIONAL -failover –force Oracle インスタンス1 Oracle インスタンス2 SERVICE_A FANイベント ※ Connection Pool Clusterware Clusterware Oracle Client ①サービス 停止 ②DOWN 通知 Oracle インスタンス1 Oracle インスタンス2 SERVICE_A Connection Pool Clusterware Clusterware Oracle Client ③インスタンス1との 物理コネクションは プールに返却されたら 切断 SERVICE_A ④新規の物理 コネクションは インスタンス2に接続 ⑤drain_timeout まで待機 ⑥stopoption 設定に基づいて、 インスタンスを shutdown ※異常時のDOWNイベント とは区別される 

オンライン業務を止めないために Oracle RACとコネクション・プール Copyright © 2024, Oracle and/or its affiliates 39 Oracle インスタンス1 Oracle インスタンス2 SERVICE_A FAN イベント Connection Pool Clusterware Clusterware Oracle Client 停止 起動 計画停止 (ローリング・パッチ適用など) コマンドによるOracleインスタンスの停止/起動 • トランザクション中のOracleインスタンスを 安全に停止させる ⇒ FAN - 高速接続フェイルオーバー(FCF) FAN イベント Oracleインスタンス/サービス起動 • 新規受付可能なインスタンスへの 新たな接続リクエスト ⇒ FAN - 高速接続フェイルオーバー(FCF) ⇒ FAN -ランタイム接続ロード・バランス(RCLB) 計画外停止 (DBサーバ側のクラッシュ) • クライアント側が切断されたことに気付かずに ハング状態になることを避ける ⇒ FAN - 高速接続フェイルオーバー(FCF) • 切断された接続のトランザクションのエラーを救う ⇒ アプリケーション・コンティニュイティ(AC) 

Demo –アプリケーション コンティニュイティ- Copyright © 2024, Oracle and/or its affiliates 40 内容 SQL実行中にノード障害を起こして、アプリケーション コンティニュイティの機能を試す ・ノード障害時の自動再接続 ・トランザクションの自動再実行 (今回はOracle接続ドライバ: SQL*Plusを使用) 構成 Before After dbase_testテーブル 接続ノード(CDB) Before After dbase1 dbase2 障害発生させて切り替える INSERT時に障害発生 Oracle Client ※ORA-41412のエラーが出るのでv$instanceはselectできない 

Demo –アプリケーション コンティニュイティ- Copyright © 2024, Oracle and/or its affiliates 41 再接続 アプリケーション Oracle接続ドライバ (SQL*Plus) SQL 1 SQL 2 SQL n COMMIT SQL 1 SQL 2 SQL n COMMIT Oracleサーバ SQL 1 SQL 2 SQL n COMMIT SQL 1 SQL 2 Oracleクライアント Oracleサーバ ③ノード障害を発生 # kill -9 プロセス(pmon) ②INSERT文を発行 SQL 1> INSERT INTO dbase_test VALUES(2,'BBB’); SQL 2> INSERT INTO dbase_test VALUES(3,'CCC'); Demoの流れ ①dbase_testテーブル、接続ノードを表示 ②INSERT文を発行 ③ノード障害を発生 アプリケーションコンティニュイティが作用 ④再度、接続ノードを表示 自動再接続の確認 ⑤dbase_testテーブルを表示 トランザクションの自動再実行を確認 事前確認 ①dbase_testテーブル、接続ノードを表示 事後確認 ④再度、接続ノードを表示 ⑤dbase_testテーブルを表示 

1. Oracle Real Application Clusters概要 2. Oracle RACとシングル・データベースとの違い 3. Oracle Grid Infrastructure概要 4. 接続ロード・バランシングと接続フェイルオーバー 5. まとめ Agenda Copyright © 2024, Oracle and/or its affiliates 42 

▪ Oracle Real Application Clustersの概要 ▪ Oracle RACとシングルデータベースとの違い • データアクセスの方法 ▪ Oracle Grid Infrastructureの概要 • Oracle ASMとOracle Clusterware • 障害回復の流れ ▪ 接続ロードバランスと接続フェイルオーバー • SCANを使った接続 • Demo -アプリケーションコンティニュイティ- まとめ Copyright © 2024, Oracle and/or its affiliates 43 

No content