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

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

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

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

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

誤解されやすいのですが、「ディスク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は標準機能なので導入にあたっての敷居は高くありませんが、ASMのネットワークが新しく追加されるなど従来の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の可用性を検証します。RAC構築にあたっては、運用中に起こるであろう障害を想定した可用性検証を行い、アプリケーションへの影響と復旧までの時間を計測して実際の運用に備えるのが一般的となっています。Flex ASMにおける障害発生時の動作や復旧までの時間を知ることは、従来のASMとどちらを選択するかにおいて非常に重要なポイントになります。

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

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

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

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

ディスク再同期の制御

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

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

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

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

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

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

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

・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.1
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.2
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.3
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.5
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.6
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.7

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。