スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

OracleRACをvmware上で動かすには

vmware上でOralceRACをことを考えると、気になるポイントが4つあります。1つはスプリットブレインを防止するための、投票ディスクの配置、2つ目はインターコネクトにおけるキャッシュフュージョンの帯域確保、3つ目はノード間の時刻同期、4つ目はREDOの性能です。

1つ目は、投票ディスクをVMDKファイル上に置くかどうかが一番の問題です。感覚的には、投票ディスク(クォーラムディスク)はRAWデバイス上に置きたいです。違いとしては、SCSIコマンドを透過的に通せるかどうかになりますが、そこまで神経質にならなくても良い気もします。実際に故障率等で統計は取ったことがないのであくまで机上での設計になります。一気に仮想化ライクにしてしまうとそれだけリスクがあるので、部分的にリスクを排除したい気がします。

感覚的にはRAWデバイス上のほうがいいのですが、RAWデバイス上に配置したいのであれば、Raw Device Mappingの機能を選択します。ただ、オラクルのレポートではVMDKファイル上に投票ディスクを設定しているようです。
http://otndnld.oracle.co.jp/products/database/oracle10g/clustering/pdf/RAC_Config_VMware_Linux-01.pdf
なお、仮想と物理でRACを組むようなイレギュラーな設計を行うのであれば、Raw Device Mappingが必要になると思いますが、普通やらないでしょう。そもそも、VMDK上にファイルを集めておかなければ、LUNの設計やバックアップの設計が困難になってしまうので、無理にRAWデバイスにする必要はないかもしれません。VMDK上に集約されていると運用が本当に楽なんですよね・・・。

2つめのインターコネクトに関しては、キャッシュフュージョンがどれだけ発生するか、もっというと、どれだけの帯域を確保したほうがいいのか、というところがポイントになります。

ただ、実際にはキャッシュフュージョンで性能が出ない場合は、帯域が圧迫されていることは少なく、ブロックの設計や、ロック取得のタイミングが問題になることがほとんどです。そういったあたりの設計をうまくやってあげれば、そもそも問題になることは少ないように考えています。また、10g以降はマスターブロックが移動するようになっているので、より問題になることは少ないと思います。

3つ目の時刻同期と4つ目のREDOの性能に関しては次回以降の記載に譲ろうと思います。

その他、気になるポイントがあるとすると、Oracleのインスタンスやクラスタウェアなどが、OSの特権命令や、命令の優先度をコントロールしている可能性があって、VMwareにそのあたりのコントロールを邪魔されないか、ということでしょう。どういったコントロールをしているかを全てわからないので(仕様として公開もされないので)、感覚的ではあるのでなんとなく気になるというレベルです。得てしてそういうところでハマってしまうのですが・・・。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。