Deploying Scalable Oracle RAC on Amazon EC2 の考察

JPOUG Advent Calender 2015(https://jpoug.doorkeeper.jp/events/33345) の6日目
AWS Advent Calendar 2015 (http://qiita.com/advent-calendar/2015/aws) の6日目

のクロスエントリです。


とうとうAWSからOracle RAC on Amazon EC2の手順が公開されました。
Deploying Scalable Oracle RAC on Amazon EC2


ここ数年 Oracle RAC on Amazon EC2を考え続けてきた身としては、言及しないわけにはまいりません。
本当はかっちり検証したいのですが、時間がとれなかったので、チュートリアルから読み取れる内容を記載します。
実際に検証した訳ではないので、記載内容が正しくない場合がありますのでご承知おきください。


まず、Oracle RAC on Amazon EC2を作る上で障害となるのは以下です。



1.publicネットワークのVIP(仮想IP)
EC2のネットワーク(VPC)は物理ネットワークと異なり、AWS側でARPが管理されており、
設定されたIPでしか通信ができません。
OS(RAC)側で勝手にIPを振っても他マシンからそのIPへ通信をすることができないのです。
つまり、VIPのフェールオーバができません。


2.internalネットワークのマルチキャスト
EC2のネットワーク(VPC)は物理ネットワークと異なり、マルチキャストがサポートされていません。
したがって、Oracle RACのinternalネットワーク要件を満たしません。


3.共有ディスク
現時点では、共有ディスクに相当するものは正式に提供されていません。


では、どうやって1〜3をクリアしているか?



1.publicネットワークのVIP(仮想IP)
AWS API(aws ec2 assign-private-ip-addresses)を実行するスクリプトOracle Clusterwareのリソースとして登録しているようです。
Oracle Clusterwareがノードの障害を検知すると、/etc/oracle/ec2_vip_failover.shを実行し、
その延長でaws ec2 assign-private-ip-addressesが呼ばれ、VIP/Scan VIPが障害が発生していないノードに付与されるようです。<該当部分抜粋>

oracle@myracnode01$ crsctl add resource myrac02-vip.ec2 -type cluster_resource -attr "CHECK_INTERVAL=10,\
ACTION_SCRIPT=/etc/oracle/ec2_vip_failover.sh,PLACEMENT=favored,HOSTING_MEMBERS=myracnode01 myracnode02,\
AUTO_START=always,START_DEPENDENCIES=hard(intermediate:ora.myracnode02.vip),RELOCATE_BY_DEPENDENCY=1,\
STOP_DEPENDENCIES=hard(intermediate:ora.myracnode02.vip)"


以前、aws ec2 assign-private-ip-addressesをうまく使って、RACを作れないか検討したことがあるんですが、
リソース登録までは思いつかず断念したことがあるので、ちょっと悔しいです。。。


2.internalネットワークのマルチキャスト
これは、n2nというVPNソフトウェアを使用し、実現しています。
以前、当ブログで紹介したOpenVPN/tincでの実現と基本は変わりません。
iSCSI ノード#1にsupernode(n2n仮想ネットワークの経路情報を持つサーバ)
DB ノード#1,#2がそれぞれn2nクライアントの構成のようです。
n2nは、通信自体はPeer to Peerで行うとされていますので、VPNソフトウェアの中では比較的パフォーマンスが良いようです。
(とは言っても、実ネットワークの半分程度のスループットですが)
https://www.buckhill.co.uk/blog/how-to-enable-broadcast-and-multicast-on-amazon-aws-ec2


3.共有ディスク
iSCSIを用いています。
以前当ブログで紹介した手順と基本は変わりません。
冗長性?を意識しているのかiSCSIサーバを二つ用意しているようです。


では、この構成は実運用に耐えうるのかというと、冗長性が確保できていないような。。。。
(以下ちょっと自信がないんので、ツッコミお待ちしてます)



n2n・・・・ iSCSI ノード#1がsupernodeであるため、このサーバに障害が起きるとn2nの仮想ネットワーク全体に影響がでるため、ここが単一障害点となると思います。
(n2nは詳しくないので、自信ないですが、、、、)


iSCSI・・・・ 2台構成ではダメなハズです。
Oracle Clusterwareファイルの場合、3つのディスク・デバイスまたは3つの障害グループが標準冗長性のディスク・グループの最小要件です。」(マニュアル抜粋)
なので、3つの障害グループを2つのiSCSIサーバに構成するとなると2,1の分け方になり、2つの障害グループを割り当てたiSCSIサーバに障害が発生すると
Oracle Clusterwareは稼働できません。
2つの障害グループを割り当てたiSCSIサーバが単一障害点になると思います。



以上、実運用には対障害性でもう一歩と言う気がしますが、
AWS API(aws ec2 assign-private-ip-addresses)を実行するスクリプトOracle Clusterwareのリソースの組み合わせは
かなり面白いアイデアなので、もう少し良い構成がないか検討したいなーと思います。