TOP>企業情報>コラム>技術情報>移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.4

移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.4

前回はOracle Database 12c(以下、12c)から実装されたAutomatic Data OptimizationとHeat MapによるILMの自動化について解説しました。今回は12cのReal Application Clusters(以下、RAC)関連の機能について検証結果を紹介します。

Vol.4 真の可用性を実現するために、12cのRACでやるべきこと


※RAC関連の新機能概要は「連載:徹底解説!Oracle Database 12cのすべて」の中で解説していますので、併せてご参照ください。

Flex ASMで障害点を減らす


ASM(自動ストレージ管理)はOracle Databaseのボリューム・マネージャ兼ファイル・システムとしてディスクを仮想化するための機能です。RACに不可欠な機能と言っても過言ではなく、Oracle Database 11g(以下、11g)以降のRACではおよそ9割がASMを使用しているとも言われています。ASM以外にもRAWデバイス、クラスタ・ファイル・システム、NFSといった選択肢がありますが、12cではRAWデバイスが非サポートになったため、これまで以上にASMの重要性が高まると考えられます。

新機能を説明する前に、ASMの基本について復習しておきましょう。ASMにはストライピング、ミラーリング、リバランシングなど性能と可用性を両立させるための機能が搭載されており、データが格納されている位置をASMインスタンスで管理するという仕組みになっています。この位置情報はエクステント・マップと呼ばれ、データベース・インスタンス(以下、DBインスタンス)がディスクI/Oを行う際に参照されます。これがなければ目的のデータに辿りつけないため、ASMインスタンスは非常に重要な役割を担っていると言えます。

ASMインスタンスとDBインスタンスの関係

ASMインスタンスとDBインスタンスの関係

誤解されやすいのですが、「ディスクI/Oが発生するたびにASMインスタンスに問い合わせる」という仕組みではないのでご注意ください。エクステント・マップはDBインスタンスのSGA内にキャッシュされているため、毎回ASMインスタンスに問い合わせる必要はありません。また、「ASMインスタンスを経由してデータにアクセスする」という仕組みでもありません。エクステント・マップさえあればASMインスタンスを経由せず直接ディスクI/Oを実行できるため、オーバーヘッドが出ないようになっています。

ASMにおける真の課題は性能ではなく、「ASMインスタンスに障害が発生するとDBインスタンスも併せてダウンしてしまう」という動作にあります。ASMインスタンスはRAC内の全ノードで起動する必要があるため、ノード数に比例して障害点が増えてしまいます。ASMを使用する上で仕方のないこととは言え、止まらないシステムを目指すRACにおいて障害点が増えてしまうというのは望ましいことではありません。

この課題を解決するために、12cではFlex ASMという構成を採ることができるようになりました。Flex ASMでは、ASMインスタンスとDBインスタンスを同じノードで起動せずに分離できるため、結果的にASMインスタンスの数(=障害点)が少なくなります。デフォルトではクラスタ全体で3つのASMインスタンスが起動するようになっており、以下のように5ノードのクラスタを構成している場合は2ノード分のASMインスタンスを削減できます。なお、ASMインスタンスがないノードは、ネットワークを経由して別ノードにあるASMインスタンスにリモート接続して処理を行います。

Flex ASMの構成

Flex ASMの構成

Flex ASMは標準機能なので導入にあたっての敷居は高くありませんが、ASMのネットワークが新しく追加されるなど従来のASMから変更された点もいくつかあります。そこで今回は、Flex ASMの性能と可用性についての検証を行ってみます。

Flex ASMの性能と可用性を検証する


Flex ASMでまず気になるのは、「ネットワーク経由でASMインスタンスにアクセスすることによって、性能が低下しないか?」という点です。ASMインスタンスが存在するノードとしないノードが存在することになるので、それらの間で性能に差が出てしまうようでは障害点が減っても意味がありません。今回は以下の3パターンで性能を比較してみます。ベンチマークにはSwingbenchを使用します。

 ①Flex ASMでASMインスタンスが起動しているノード
 ②Flex ASMでASMインスタンスが起動していないノード
 ③従来のASM

性能検証パターン

性能検証パターン

Swingbenchのセッション数を50、100、200と増やしていき結果を比較したのが以下のグラフです。今回の検証では、懸念していたようなASMインスタンスが存在するノードと存在しないノードでの性能差は見受けられませんでした。従来のASMと比べてもほとんど同じ結果になっているため、性能については問題ないと言えます。冒頭で解説しましたが、仕組み上必ずASMインスタンスを経由するというわけではないので、ASMインスタンスが存在しないノードであっても性能には大きく影響しないと考えられます。

Flex ASMの性能検証結果(平均トランザクション数)

Flex ASMの性能検証結果(平均トランザクション数)

続いてFlex ASMの可用性を検証します。RAC構築にあたっては、運用中に起こるであろう障害を想定した可用性検証を行い、アプリケーションへの影響と復旧までの時間を計測して実際の運用に備えるのが一般的となっています。Flex ASMにおける障害発生時の動作や復旧までの時間を知ることは、従来のASMとどちらを選択するかにおいて非常に重要なポイントになります。

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

疑似障害 内容
ASMインスタンス障害 ASMインスタンスのプロセスを強制停止
DBインスタンス障害 DBインスタンスのプロセスを強制停止
クラスタ障害 Oracle Grid Infrastructureのプロセスを強制停止

可用性検証の項目

Flex ASMと従来のASMを比較した結果が以下のグラフです。ダウンタイムは細かく分けると「ポーリング」、「クラスタ再構成」、「インスタンス再構成」、「インスタンス・リカバリ」という4つのステップになりますが、今回はそれらの合計時間で比較しています。

Flex ASMの可用性検証結果(ダウンタイム)

Flex ASMの可用性検証結果(ダウンタイム)

結果を見てみると、ASMインスタンス障害のダウンタイムにおいて差が出ています。Flex ASMの場合はダウンタイムがほぼゼロとなっており、障害が発生してもアプリケーションからは分からないほどです。これは従来のASMで課題となっていた「ASMインスタンスに障害が発生するとDBインスタンスも併せてダウンしてしまう」という動作が、Flex ASMによって解消されたことを示す結果と言えます。Flex ASMの場合は、仮にASMインスタンスが1つダウンしたとしても、残存するASMインスタンスにリモート接続することができるため、DBインスタンスが停止することはありません。この動作がダウンタイムの極小化に繋がっています。

ASMの新機能で素早くメンテナンスを行う


これまで解説したFlex ASM以外にも、12cのASMには多くの新機能が追加されています。細かいものが多いですが、中にはASMのメンテナンス時間を短くするなどすぐに使える機能もありますので、代表的なものを中心にいくつか紹介します。

機能 概要
ディスク・グループ数の制限 ディスク・グループの最大数が63から511に拡張
記憶域の制限 1ASMディスクあたり、最大32PBのサイズをサポート(AUサイズ8MBの場合)、システム全体で10,000のASMディスクをサポート
ディスク再同期の制御 再同期操作の速度や使用するリソース量をPOWER句で制御することが可能に
リバランスの並列実行 複数ディスク・グループへのリバランス処理を並列実行することが可能に
リバランスの見積もり リバランス処理で移動するデータ量を事前に見積もることが可能に
処理の進行状況確認 リバランス、ディスク再同期処理の進行状況や残りの所要時間の目安等が確認可能に
パスワード・ファイルの管理 ORACLE_HOME配下で管理していたパスワード・ファイルをASMで管理可能に
ディスク・グループ均等読取り ディスク・グループ内のすべてのディスクで均等に分散させてデータを読取る(ミラー・データからも読取る)
ディスク修正 データの破損をチェックし、破損が検出された場合、ミラー・データを使用してリバランス時に自動的に修正

12cで追加/拡張されたASMの機能

ディスク再同期の制御

ASMのミラーリング機能を使用している場合、複数のASMディスク(障害グループ)間でデータが多重化されます。ディスクの故障といった障害に対応できるのはもちろんのこと、Oracle Database 11gR1(以下、11gR1)以降ではディスク再同期と呼ばれる機能によって停電やストレージ・パスの不具合といった一時的な障害にも柔軟に対応できるようになっています。ディスク再同期を使用すると、障害から復旧した際に更新部分だけが同期されるため、メンテナンスの時間を大幅に短縮することができます。

ASMのディスク再同期

ASMのディスク再同期

12cではこのディスク再同期がさらに拡張され、POWER句を使用して再同期に割り当てられるリソース量を制御できるようになりました。POWER句に大きな値を指定することで、より短い時間で再同期を行うことができます。以下のグラフは、POWER句によって再同期の時間にどの程度違いが出るのかを検証した結果です。再同期の時間が約1/2に短縮されていることが分かります。

10GB分の再同期に必要な時間

10GB分の再同期に必要な時間

リバランスの並列実行と見積り

ASMにはリバランスの機能があり、ディスクの追加や削除が発生した際にデータが偏って格納されないよう再配置が行われます。Oracle Database 11gR2(以下、11gR2)までは複数のディスク・グループにおいて同時にリバランスを実施することはできませんでしたが、12cでは並列実行ができるよう機能が拡張されました。そのため、より短い時間でリバランスを終えることができます。

リバランスの並列実行

リバランスの並列実行

さらに、12cではリバランスを実施する前にリバランス量を見積ることができるようになりました。11gR2までは検証環境でテストをするか実際にリバランスを実行しない限り分からなかった情報ですが、12cでは事前にリバランス量を把握してメンテナンスの計画を立てることができます。また、リバランスの進行状況も見やすく表示できるようになったため、管理性が向上しています。

りバランス量の見積もり

りバランスの進行状況を確認


今回解説したように、12cではRACやASMの機能が多数追加されています。12cへのバージョンアップを検討する際は、現在の運用課題に効く新機能があるかどうかを是非確認してみてください。

次回は12cのセキュリティ機能について検証結果を紹介します。


執筆者紹介

関 俊洋(Toshihiro Seki)

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

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

関の紹介記事はこちら

「移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ」
連載記事一覧

オンライン・セミナー続々公開中!

アシストでは、全国どこからでも好きな時間に参加できるOracle Databaseのオンライン・セミナーを開催しています。アーキテクチャの基礎からEnterprise Managerやバックアップなどの運用テクニック、12cやアプライアンスといった最新情報まで20種類以上のコンテンツを用意しています。便利なオンライン・セミナーに是非ご参加ください。

関連製品


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

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



ページの先頭へ戻る