「Active GridLink for RAC」は、Oracle Databaseのクラスタ構成を実現するOracle Real Application Clusters(RAC)との緊密な連携を可能にするWebLogic Server 12cの目玉機能の1つだ。先ごろ同機能について、WebLogic Server 12cの販売パートナーであるNECが、具体的な動作ロジックや実際の性能に関して詳細な検証を行った。作業を担当したNEC 第三ITソフトウェア事業部の牧田雄樹氏に、その結果について話を聞いた。後編となる今回は、「動的なRACノードの追加/削除」、「高速接続フェールオーバー(FCF)」、「GridLinkデータソースの使用の注意点」に関する検証結果を紹介しよう。(編集部)
前編はコチラ
Oracle RAC環境では、特定のRACノードについて、全体の運用を止めることなく任意に追加/削除を行うことができる。障害が発生したノードの切り離しや、パフォーマンス向上のためのノード追加といった作業をシステム全体の稼働に極力影響を与えずに実施する際には、この機能が威力を発揮する。
今回の検証では、3ノードRAC構成で高負荷をかけた状態から、4ノード目をサービスに追加して、見込みどおりに性能が向上するかどうかを確認した。その結果は、次のグラフのようになった。
グラフからわかるとおり、RACノードの追加に伴いレスポンス・タイムの改善が見られた。WebLogic Serverで何も設定を変更することなくRACノードの追加を自動認識し、リクエストの振り分けを実施してRAC全体のスループットを向上させているわけだ。
ただし、今回の検証では、RACノードの追加に伴ってリニアに性能が向上することを確認できた一方で、高い負荷がかかった状態では若干、負荷に偏りが生じるという課題も確認された。牧田氏は今後も検証を進め、より最適な設定やチューニングのノウハウを確立していきたいという。
今回の検証では、検証環境にいくつかの状況を想定した「疑似障害」を発生させ、FCFにより、障害発生からアプリケーション側でのエラー検知までの時間が短縮されるかどうかを確認した。
想定された障害ケースは、次の5つだ。
テストの結果は、下表のようになった。
FCFによる効果が顕著に表れたのは「パブリックネットワーク障害」、「インターコネクト障害」の2つのケースだ。従来、これらのケースではタイムアウトの発生まで障害を検知することはできなかったが、Active GridLink for RAC使用時には、障害の発生に伴ってOracle RAC側で発生するFAN(高速アプリケーション通知)イベントをWebLogic Server側で受け取って早期に障害を検知し、効果的にアプリケーションの停止時間を短縮できることが確認されたわけだ。
さらに牧田氏によれば、「プロセス・ストール障害の場合、Oracle RAC側で障害を検知するまでに時間がかかるため、早期の対応ができない。こうした状況を避けたければ、NECが提供しているクラスタウェアであるCLUSTERPROのオプション製品“CLUSTERPO MC ApplicationMonitor”を使うことにより、SQLがハングアップしたRACノードを強制終了させ、FANイベントを飛ばしてアプリケーション・サーバ側で早期にエラーを検知できるようになる」という。
NECでは、今回の検証結果を踏まえ、今後は多様なアプリケーションを使っての性能検証や、RCLBによる効果に関する総合的な効果測定、アフィニティの自動オン/オフの契機となるパラメータやその閾値の詳細に関する調査、Oracle RACやWebLogic Serverの実際的な運用環境を想定した環境でのActive Grid Link for RACの効果などについて、より深い検証を実施する意向だ。
このように、NECのFusion MiddlewareとOracle Databaseの専門部隊が緊密に連携しながら詳細な検証を進めていくことの意義は極めて大きい。この取り組みは、同社におけるオラクル製品のインテグレーション・レベルを引き上げるばかりでなく、オラクルのソリューションを扱うSIer全体にとっても参考情報として高い価値を持つからだ。
日本オラクルでは「課題となる部分も含めて、NECによる今回の詳細な検証結果には米国のオラクル本社も非常に注目している。今後は、この検証から得られた知見を広め、さまざまなインテグレーション案件でオラクルが提供できる価値をさらに高めていきたい」とコメントしている。
前編はコチラ
(3)動的なRACノードの追加/削除
前編に続き、NECによる国内初のActive GridLink for RACに関する性能検証の結果をハイライトで紹介する。今回は「動的なRACノードの追加/削除」、「高速接続フェールオーバー(FCF)」、「GridLinkデータソースの使用の注意点」の各項目の詳細を取り上げる。NEC 第三ITソフトウェア事業部牧田雄樹氏
今回の検証では、3ノードRAC構成で高負荷をかけた状態から、4ノード目をサービスに追加して、見込みどおりに性能が向上するかどうかを確認した。その結果は、次のグラフのようになった。
グラフからわかるとおり、RACノードの追加に伴いレスポンス・タイムの改善が見られた。WebLogic Serverで何も設定を変更することなくRACノードの追加を自動認識し、リクエストの振り分けを実施してRAC全体のスループットを向上させているわけだ。
ただし、今回の検証では、RACノードの追加に伴ってリニアに性能が向上することを確認できた一方で、高い負荷がかかった状態では若干、負荷に偏りが生じるという課題も確認された。牧田氏は今後も検証を進め、より最適な設定やチューニングのノウハウを確立していきたいという。
(4)高速接続フェールオーバー(FCF)
高速接続フェールオーバー(FCF)とは、データベース側で起きた障害について、アプリケーションがリクエストに対するタイムアウトを受け取るまで待つことなく障害を検知し、障害のないノードへと迅速に接続を切り替えることにより、高い可用性を確保する技術である。今回の検証では、検証環境にいくつかの状況を想定した「疑似障害」を発生させ、FCFにより、障害発生からアプリケーション側でのエラー検知までの時間が短縮されるかどうかを確認した。
想定された障害ケースは、次の5つだ。
- プロセスダウン障害
- プロセス・ストール障害
- パブリックネットワーク障害
- インターコネクト障害
- WebLogic Server側の全ネットワーク障害
テストの結果は、下表のようになった。
FCFによる効果が顕著に表れたのは「パブリックネットワーク障害」、「インターコネクト障害」の2つのケースだ。従来、これらのケースではタイムアウトの発生まで障害を検知することはできなかったが、Active GridLink for RAC使用時には、障害の発生に伴ってOracle RAC側で発生するFAN(高速アプリケーション通知)イベントをWebLogic Server側で受け取って早期に障害を検知し、効果的にアプリケーションの停止時間を短縮できることが確認されたわけだ。
さらに牧田氏によれば、「プロセス・ストール障害の場合、Oracle RAC側で障害を検知するまでに時間がかかるため、早期の対応ができない。こうした状況を避けたければ、NECが提供しているクラスタウェアであるCLUSTERPROのオプション製品“CLUSTERPO MC ApplicationMonitor”を使うことにより、SQLがハングアップしたRACノードを強制終了させ、FANイベントを飛ばしてアプリケーション・サーバ側で早期にエラーを検知できるようになる」という。
(5)GridLinkデータソースの使用の注意点
NECでは、今回の一連の検証を通じて、Active GridLinkのGridLinkデータソースを利用する際の注意点をいくつかまとめている。例えば、Active GridLinkを安定的かつ効果的に動作をさせるための「起動時オプション」の設定方法や、WebLogic Serverの「起動方法」などだ。NECでは、今回の検証結果を踏まえ、今後は多様なアプリケーションを使っての性能検証や、RCLBによる効果に関する総合的な効果測定、アフィニティの自動オン/オフの契機となるパラメータやその閾値の詳細に関する調査、Oracle RACやWebLogic Serverの実際的な運用環境を想定した環境でのActive Grid Link for RACの効果などについて、より深い検証を実施する意向だ。
このように、NECのFusion MiddlewareとOracle Databaseの専門部隊が緊密に連携しながら詳細な検証を進めていくことの意義は極めて大きい。この取り組みは、同社におけるオラクル製品のインテグレーション・レベルを引き上げるばかりでなく、オラクルのソリューションを扱うSIer全体にとっても参考情報として高い価値を持つからだ。
日本オラクルでは「課題となる部分も含めて、NECによる今回の詳細な検証結果には米国のオラクル本社も非常に注目している。今後は、この検証から得られた知見を広め、さまざまなインテグレーション案件でオラクルが提供できる価値をさらに高めていきたい」とコメントしている。