こんにちは。宮崎です。
今回のブログの内容は11g R2以降に準拠した内容になります。
まず、RACというテーマを踏まえて、
ASM(Automatic Storage Management)に関しての11gのR1とR2の違いを述べます。
11g R1までは、投票ディスクとOracle Cluster Registry(以下、OCR)という2つのOracle ClusterwareファイルをASMで管理できず、rawデバイスや共有ディスク内に配置していました。
ところが、11g R2では大きな変更がありました。
それは、11g R2ではこの2つのファイルをASM内で管理できるようになり、
ディスクの領域管理が楽になったのです。
・OCR
OCRとは、一言でいうと、RACの構成情報レポジトリ用ファイルのことです。
Oracle Clusterwareで制御するデータベース、サービス、リスナーなどのコンポーネントや各クラスタ・リソースのプロファイル情報やステータス情報など、Oracle Clusterware稼働に必要な情報が含まれているファイルです。
・投票ディスク
投票ディスクとは、Oracle Clusterwareがクラスタ内のノードの生死判断するのに用いるファイルです。クラスタ内の各ノードは、ハートビートと呼ばれるクラスタ同期サービス(以下、CSS)同士で生存確認を行います。その結果として、あるノードにサーバーダウンなどの異常が発生した場合、その異常が起きたノードを切り離し、クラスタを正常に保つスプリット・ブレインという機能に使用されます。下の図は前回のブログでも出てきた、3ノードからなるクラスタ・データベースのイメージ図です。

インスタンス君①
「おーい生きてるかー?」
インスタンス君②
「こっちは無事だよー」
インスタンス君③
「俺も大丈夫!」
各インスタンスはCSS社の糸電話で、こまめにお互いの無事を確かめ合っています。
しかし、ある日のこと、急にインスタンス③君が倒れてしまいました。
インスタンス君①
「おーい生きてるかー?」
インスタンス君②
「インスタンス君③から返事が帰ってこないの!」
インスタンス君①
「何度呼びかけても応答してくれないな・・・」
意識を失っているので当然、糸電話で2人のインスタンス君たちと話すことはできません。
インスタンス君③がいない以上、このままでは今あるクラスタ・データベースを維持することができません。そこで残った2人のインスタンス君はある決断を下します。
インスタンス君①
「インスタンス君③から応答があるまで、2人だけでクラスタを作りなおそうよ」
インスタンス君②
「僕も同じ意見だよ。賛成票2票でインスタンス君③をクラスタから切り離そう」
こうして多数決によりインスタンス君③はクラスタから切り離され、インスタンス君①と②からなる新しいクラスタ・データベースができました。
それからしばらくしてインスタンス君③は何事もないかのように2人のもとに戻ってきました。
インスタンス君③
「みんな、ただいま!」
インスタンス君①
「おっ、やっと帰ってきたね。」
インスタンス君②
「2人だけで大変だったんだよ!」
インスタンス君③
「ごめんごめん!積もる話もあると思うけど、先にクラスタ作りなおそうぜ」
インスタンス君②
「そうだね」
異常の発生したインスタンスが再び正常に起動すると、自動的にクラスタの再構成が始まります。
OCRと投票ディスクをASMで管理する利点としては、障害時にOracle Clusterwareを継続的に稼働したまま障害に対応し、その後の復旧まで自動的に行う点が挙げられます。その際、ディスクの冗長化設定を利用してデータ保護を行うとなおさらよいです。
Oracle ClusterwareとASMは、コンポーネントとしては独立しているものの、この2つが1つの機能として統合され、Grid Infrastructureと呼ばれるRACを支える重要なアーキテクチャとして提供されています。
ASMに関してはそれ自体もさることながら、ACFSも含めて色々と記事が書ける素材のため、
また折をみてお伝えしたいと思います。