買ってつないだらすぐ使える！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はデータベースが使える期間、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台のサーバーのみです。

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

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

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

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

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

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

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

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の機能を使って実装されています。

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

　また、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の性能を検証します。

岸和田 隆関 俊洋 [著]