TOP>企業情報>コラム>技術情報>はじめましてOracle! Vol.4

はじめましてOracle! Vol.4

はじめましてOracle!

第4回目となる今回は、Oracle Database Applianceの可用性を検証した結果について解説します。

(全6回連載)

Vol.4 買ってつないだらすぐ使える!Oracle Database Applianceがやってきた!(可用性検証編)

Oracle Database Applianceを徹底検証!


前回はOracle Database Applianceの概要とインストール方法を解説しました。データベースに必要なハードウェアとソフトウェアが設計・テスト済の状態で提供されるため、電源を入れてから、わずか2時間でインストールが完了しました。

このような手軽さもOracle Database Applianceならではのメリットですが、データベースとしての実力はどうなのでしょうか。

 ・一般的なRAC構成と比べて、可用性に違いはないのか?
 ・Pay as you growでスモール・スタートした後にコアを増やした場合、性能は上がるのか?
 ・Enterprise EditionとStandard Editionでは、どのくらい性能差があるのか?

など、気になる要素はたくさんあります。

第4回目となる今回は、データベースの代表的な非機能要件である可用性に焦点を当て、Oracle Database Applianceをいち早く検証した結果をお伝えします。

データベースにおける可用性の考え方


可用性とは、データベースが本来期待された動作を継続する能力のことで、24時間365日にわたってサービスを提供するようなシステムには欠かせない要素です。

可用性はシステム故障が発生するまでの平均時間である『MTBF(Mean Time Between Failure)』と、システム故障が発生してから復旧までの平均所要時間である『MTTR(Mean Time To Repair)』の2つから算出されます。

MTBF

MTBF

MTTR

MTTR

MTBFはデータベースが使える期間、MTTRはデータベースが使えない期間と考えることができます。従って、高い可用性を実現するためには、MTBFを長く、MTTRを短くする必要があります。

MTBFを長くするには故障しない機器を用意すればよいのですが、データベースのようにサーバーやストレージなど様々な機器から構成されるシステムにおいては、故障の可能性が少なからず存在します。

そのため、可用性を考える場合は、いかにMTTRを短くするかがポイントになります。

データベース・タイプによる可用性の違い


Oracle Database Applianceには3つのデータベース・タイプが存在し、それぞれ可用性のレベルが異なります。サーバーに障害が発生した場合を想定して、動作の違いを説明します。

タイプ① シングル・インスタンス構成

シングル・インスタンス構成では、2台のうち1台のサーバーだけを使用します。

インスタンスとデータベースの関係が1:1になっているため、インスタンスが稼働しているサーバーに障害が発生すると、データベースにアクセスできなくなります。

停電などの一時的な障害であれば短時間で復旧できますが、ハードウェアの部品交換が必要になる場合は、復旧までに数時間かかることもあります。Oracle Database Applianceでは部品のほとんどが冗長化されているため、ある程度の障害に耐えることができますが、それでも可用性が高い構成とは言えません。

シングル・インスタンス構成

シングル・インスタンス構成

②Real Application Clusters One Node(RAC One Node)構成

Real Application Clusters One Node(以下、RAC One Node)は、Oracle Database 11g Release2から提供されている新機能です。2台のサーバーを使用しますが、インスタンスが稼働するのはそのうち1台のサーバーのみです。

いわゆる『アクティブ・スタンバイ構成』と呼ばれているものに近い構成です。

サーバーに障害が発生すると、自動的に生き残ったノードにインスタンスがフェイルオーバー(移動)するため、わずかな時間で処理を再開できます。

RAC One Node構成

RAC One Node構成

③Real Application Clusters(RAC)構成

Real Application Clusters(以下、RAC)構成では、2台のサーバーを使用します。

各サーバーでそれぞれインスタンスが稼働しており、インスタンスとデータベースの関係が2:1になっているため、1台のサーバーに障害が発生しても生き残ったサーバーがあればタイムラグなく処理を継続できます。

『アクティブ・アクティブ構成』と呼ばれることもあり、Oracle Databaseにおいても最も可用性が高いといえます。

RAC構成

RAC構成

可用性の違い(まとめ)

Oracle Database Applianceで選択可能な3つのデータベース・タイプでは、それぞれ使用するサーバー数やインスタンス数が異なるため、可用性に差があります。

可用性を高めたい場合は、RACまたはRAC One Node構成を選択する必要があります。

RAC構成における可用性検証


先ほどはサーバーに障害が発生した際の動作を説明しましたが、実際の運用において想定される障害は他にも沢山あります。

例えば、RAC構成の場合はサーバー同士を結ぶノード間通信用のネットワークが必要なので、ケーブルの断線やスイッチの故障といった障害が想定されます。RAC構成に必要なハードウェアとソフトウェアは多岐にわたるため、あらゆる障害を想定しておく必要があります。

RAC構成において想定される障害

RAC構成において想定される障害

障害 障害内容
サービス用ネットワーク障害 アプリケーションからの接続に使用するサービス用ネットワークのスイッチやケーブルなどの障害
ノード間通信用ネットワーク障害 RACのノード間通信に使用するネットワークのスイッチやケーブルなどの障害
サーバー障害(ノード障害) インスタンスが稼働しているサーバーのCPUやメモリ、電源装置などの障害
インスタンス障害 Oracleのデータベース・インスタンス及びASMインスタンスの障害
クラスタウェア障害 Oracleのクラスタウェアを構成するプロセスの障害
ストレージ用ネットワーク障害 サーバーとストレージを結ぶスイッチやケーブルなどの障害
ストレージ障害 ストレージのコントローラやディスクの障害


そのため、RAC構成のシステムを新しく構築する場合は、障害を想定した『可用性検証』が必ず行われます。疑似的に障害を発生させ、アプリケーションへの影響と復旧までの時間などを計測することで、実際の運用に備えます。

一般的なRAC構成の場合は長い時間をかけて可用性検証が行われますが、Oracle Database Applianceの場合は事前設計・検証済の状態で提供されているため、あらかじめ正常に動作することが保証されています。そのため、可用性検証に必要な時間を短縮することができます。


検証① 一般的なRAC構成とOracle Database Applianceの比較


まずは、一般的なRAC構成とOracle Database Applianceの可用性を比較してみます。

アプリケーションから処理を実行している最中に疑似障害を発生させ、処理が再開されるまでの時間(ダウンタイム)を計測します。今回発生させる疑似障害は、以下の4つです。

 1.ASMインスタンス障害
 2.DBインスタンス障害
 3.クラスタウェア障害
 4.サーバー(ノード)障害

全ての障害において、どちらか一方のDBインスタンスが異常停止します。

この際、残存インスタンスでインスタンス・リカバリが行われますが、インスタンス・リカバリが完了するまでの間に含まれるRACのノード・メンバシップの更新や、インスタンスが持つリソースの再構成、1st pass log readと呼ばれるリカバリ対象ブロックの識別などが行われる間は、アプリケーションからの処理が停止します。

今回は、アプリケーションからの処理が停止している時間(表の1~6ステップまで)をダウンタイムと定義します。一般的なRAC構成とOracle Database Applianceでは内部動作に違いがないので、同じような結果が出るはずです。

障害発生時の内部動作
ステップ 説明
1. 障害検知 クラスタウェアのプロセスが障害を検知
2. ポーリング 障害と判断されるまでの確認時間
3. クラスタ再構成 クラスタのノード・メンバシップ情報を更新
4. インスタンス再構成 異常停止したインスタンスのリソースを再構成
5. 1st pass log read リカバリ対象ブロックの識別
6. 2nd pass log read 対象ブロックをリカバリ


まずは、一般的なRAC構成での可用性検証結果を見ていきます。

ASMインスタンスとDBインスタンス障害の場合は2~3秒程度のダウンタイムとなっており、非常に短い時間でアプリケーションからの処理を再開できています。

一方、クラスタウェアとノード障害の場合はポーリングの時間(デフォルトで30秒)が含まれるため、30秒ほど多く時間がかかっています。


続いて、Oracle Database Applianceの可用性検証結果です。

全ての検証結果において、一般的なRAC構成と同等の結果が得られています。


内部動作が同じなので、これらの可用性検証項目において一般的なRAC構成との違いが出ることはありませんが、2時間で簡単にインストールできて且つ可用性も保証されているというのは、Oracle Database Applianceならではのメリットであると言えます。

検証② Oracle Database Applianceにおけるディスク障害


RAC構成において想定される障害は多岐にわたりますが、その中で最も発生する可能性が高いと言われているのが、ディスクの障害です。

Oracle Database Applianceには合計24本のディスクが搭載されていますが、RAID構成は組まれていません。データのミラーリングやストライピングについては、ASMの機能を使って実装されています。

Oracle Database Applianceのディスク構成

Oracle Database Applianceのディスク構成

REDOログ領域、データ領域用のASMディスク・グループが構成されており、いずれもトリプルミラー構成になっているため、ディスク2本までであれば、障害に耐えることができます。

また、ASMにはデータのリバランス(再配置)機能があり、ディスクの削除や追加が行われた場合に、ディスク・グループの各ディスクに偏りが出ないよう、データが均等に分散されます。

ASMのリバランス機能

ASMのリバランス機能

今回の検証では、アプリケーションから処理を実行している最中にデータ領域用のディスクを1本引き抜き、スループットへの影響とCPUの使用傾向を計測します。ASMのミラーリングが正常に動作すること、リバランスがスループットに影響なく行われることを確認するのが目的です。

まずは、スループットへの影響を見ていきます。

ディスク障害が発生すると、数秒ほどスループットが落ち込みますが、すぐに障害発生前と同等まで回復しています。


この間、特別な操作は必要ありません。障害が発生したディスクのデータはASMによってミラーリングされているため、自動的に生き残ったディスクのミラー・データにアクセスしてくれます。アプリケーションにエラーが返ることもないため、ディスク障害における影響は僅かであると言えます。

続いて、ディスク障害時のCPU使用率を見ていきます。

ディスク障害発生前後で大きな差はありませんが、数秒ほど%sysが増えている箇所があります。これはASMがディスクの障害を検知し、ミラー・データにアクセスするための前処理に必要な負荷だと考えられます。


実は、ASMには高速ミラー再同期という機能があり、ディスクに障害が発生してもすぐにリバランスが発生しません。デフォルトでは3.6時間後にリバランスが行われます。今回の検証でスループットとCPU使用率に大きな変化が見られなかったのは、この高速ミラー再同期によってリバランスが保留されていたためです。

それでは、リバランスが発生した場合のスループットとCPU使用率はどうなるのでしょうか。データ領域用のASMディスク・グループに2TBのデータを投入した状態でディスク1本分のリバランスを行い、結果を確認します。

リバランス前後のスループットを比較すると、約15%ほど低下するという結果になりました。リバランスが完了するまでの時間はデータ量に依存しますが、今回の環境ではリバランスに約5時間かかりました。データ量が少ない場合は、数分で完了することもあります。


CPU使用率を見ると、リバランス開始後に%iowaitが上昇していることが分かります。


リバランスにどの程度I/Oリソースを割り当てるかは、初期化パラメータのASM_POWER_LIMITを変更することで調整できます。

例えば、ASM_POWER_LIMITを大きく設定すると、リバランスにほとんどのI/Oリソースをつぎ込むため、リバランスは高速になりますが、スループットは低下します。

逆にASM_POWER_LIMITを小さく設定すると、リバランスは低速になりますが、スループットへの影響を最小限に抑えることができます。

デフォルトではASM_POWER_LIMITの値が最小値に設定されており、スループットへの影響が最小限に抑えられています。高速ミラー再同期によるリバランスの保留も行われるため、ディスク障害発生後すぐにスループットが低下することはありません。

次回はOracle Database Applianceの性能を検証します。


執筆者紹介

岸和田 隆

岸和田 隆(Takashi Kishiwada)

株式会社アシスト データベース技術本部

アシスト入社後、Oracle Database の研修講師、フィールド・ サポート、新バージョンの検証を経て、2007年 自社ブランド 「DODAI」の準アプライアンス製品の企画・開発、2009年 PostgreSQL、2011年 EDB Postgres、MySQL / MariaDB の事業立上を担当。 現在は「データベースのアシスト」を目指した活動を行っている。

岸和田の紹介記事はこちら



関 俊洋

関 俊洋(Toshihiro Seki)

株式会社アシスト データベース技術本部

2006年、株式会社アシスト入社。データベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やハードウェアとデータベースを組み合わせたソリューション(DODAI)の立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆・講演活動を行っている。『SQL逆引き大全363の極意』共著。

関の紹介記事はこちら

連載記事一覧


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る