こんにちは。宮崎です。
今回のブログの内容は11g R2以降に準拠した内容になります。
まず、RACというテーマを踏まえて、
ASM（Automatic Storage Management）に関しての11gのR1とR2の違いを述べます。
11g R1までは、投票ディスクとOracle Cluster Registry（以下、OCR）という２つのOracle ClusterwareファイルをASMで管理できず、rawデバイスや共有ディスク内に配置していました。
ところが、11g R2では大きな変更がありました。
それは、11g R2ではこの２つのファイルをASM内で管理できるようになり、
ディスクの領域管理が楽になったのです。
・OCR
OCRとは、一言でいうと、RACの構成情報レポジトリ用ファイルのことです。
Oracle Clusterwareで制御するデータベース、サービス、リスナーなどのコンポーネントや各クラスタ・リソースのプロファイル情報やステータス情報など、Oracle Clusterware稼働に必要な情報が含まれているファイルです。
・投票ディスク
投票ディスクとは、Oracle Clusterwareがクラスタ内のノードの生死判断するのに用いるファイルです。クラスタ内の各ノードは、ハートビートと呼ばれるクラスタ同期サービス（以下、CSS）同士で生存確認を行います。その結果として、あるノードにサーバーダウンなどの異常が発生した場合、その異常が起きたノードを切り離し、クラスタを正常に保つスプリット・ブレインという機能に使用されます。下の図は前回のブログでも出てきた、３ノードからなるクラスタ・データベースのイメージ図です。
インスタンス君①
「おーい生きてるかー？」
インスタンス君②
「こっちは無事だよー」
インスタンス君③
「俺も大丈夫！」
各インスタンスはCSS社の糸電話で、こまめにお互いの無事を確かめ合っています。
しかし、ある日のこと、急にインスタンス③君が倒れてしまいました。
インスタンス君①
「おーい生きてるかー？」
インスタンス君②
「インスタンス君③から返事が帰ってこないの！」
インスタンス君①
「何度呼びかけても応答してくれないな・・・」
意識を失っているので当然、糸電話で２人のインスタンス君たちと話すことはできません。
インスタンス君③がいない以上、このままでは今あるクラスタ・データベースを維持することができません。そこで残った２人のインスタンス君はある決断を下します。
インスタンス君①
「インスタンス君③から応答があるまで、２人だけでクラスタを作りなおそうよ」
インスタンス君②
「僕も同じ意見だよ。賛成票２票でインスタンス君③をクラスタから切り離そう」
こうして多数決によりインスタンス君③はクラスタから切り離され、インスタンス君①と②からなる新しいクラスタ・データベースができました。
それからしばらくしてインスタンス君③は何事もないかのように２人のもとに戻ってきました。
インスタンス君③
「みんな、ただいま！」
インスタンス君①
「おっ、やっと帰ってきたね。」
インスタンス君②
「２人だけで大変だったんだよ！」
インスタンス君③
「ごめんごめん！積もる話もあると思うけど、先にクラスタ作りなおそうぜ」
インスタンス君②
「そうだね」
異常の発生したインスタンスが再び正常に起動すると、自動的にクラスタの再構成が始まります。
OCRと投票ディスクをASMで管理する利点としては、障害時にOracle Clusterwareを継続的に稼働したまま障害に対応し、その後の復旧まで自動的に行う点が挙げられます。その際、ディスクの冗長化設定を利用してデータ保護を行うとなおさらよいです。
Oracle ClusterwareとASMは、コンポーネントとしては独立しているものの、この2つが1つの機能として統合され、Grid Infrastructureと呼ばれるRACを支える重要なアーキテクチャとして提供されています。
ASMに関してはそれ自体もさることながら、ACFSも含めて色々と記事が書ける素材のため、
また折をみてお伝えしたいと思います。
