Oracle導入に関する留意事項
Oracle導入に関する留意事項
Active-Standby構成の両系のサーバでデータ領域が共有されることが前提となるため、インストールの際には両系でストレージ領域をマウントして上書きをする形で導入を行う。
インストール時に初期のデータ領域を作成するかどうかは任意で選択できるが、今回はインストールの手順でデータ領域を作成せず、インストール終了後 に手動でデータ領域を作成することで作業時間を圧縮することが可能となる。また、共有ストレージ上のデータに両系からアクセスするためには、Oracle 管理ユーザのUIDが両系で同一であるように配慮しなければならない。
またOracle ARKでは、Listenerのダウンを切り替えのトリガとはしていない。動作の仕様としては、監視対象として定義しておき、Listenerのダウン時に再度立ち上げることになる。
この動作を期待する場合、Listenerに使用するVIPがLifeKeeperの保護対象リソースとして定義されており、Listener定義ファイルのHOSTにそのVIPが指定されている必要がある。
Listenerファイルの定義方法については割愛するが、設定にあたりSteelEye社のWebページからダウンロード可能なOracle ARKのドキュメントを一読しておくことをお薦めする。
Oracle ARKによるHAクラスタ化
OracleのHAクラスタ化に関しては、MySQLの構築手順で解説している事項については重複を避け必要な設定項目のみを紹介していく。
GUIからの設定
MySQLの組み込み時と同様に、Oracleをプライマリサーバ上で起動した状態で、GUI画面から以下の操作を行って、をLifeKeeperのリソースとして組み込むことになる。
まずGUI画面メニューバーから、「Edit → Resource → Create Resource Hierarchy 」を選択する。次にGUIの各画面から表7の項目を入力する。
| 画面名 | 選択・入力内容 |
| SelectRecoveryKIT | Oracle Database(※7) |
| SwitchbackType | Intelligent |
| Server | DBのプライマリサーバ |
| Oracle_SID for Database | thinkit(※8) |
| ORACLE_HOME for Database | /opt/oracle/product/10.2.0(※9) |
| Database Tag | ThinkIT(※10) |
※注8、注9: oratabファイル内でORCALE_SIDとORACLE_HOMEを紐づけておく。
※注10: LifeKeeperの管理上の任意の名称を付ける。今回はThinkITとしたが、SIDと関連付けなくとも動作上に影響はない。
以上の項目を入力後「Create」をクリックすることでプライマリサーバ側のORACLEリソースが作成される。
MySQLの場合と同様に、これに続くリソース情報の拡張(Extend)のための手順は割愛する。今回はGUIからのOracleリソースのHA クラスタ化に関しては入力項目の紹介のみとなるが、MySQLと同様にGUI上からシンプルに構築を行うことができる。
続いてMySQLのリソースを例に、LifeKeeperの主要な機能の確認手法について紹介する。
HAクラスタ化後の動作確認
LifeKeeperの機能として最低限確認したい事項は以下の3点である。
- 切り替え操作時の動作
- ローカルリカバリの動作(障害時に現用系サーバ上でサービスの再起動を試行する)
- フェイルオーバーの動作(ローカルリカバリに失敗した場合に待機系に自動的に切り替わる)
切り替え操作についてはGUI画面上から切り替わりを確認するだけであり、また本連載の「第3回:LifeKeeper for Linuxの操作」においても紹介をしているので割愛する。今回は残る2点の動作確認についてMySQLを例に紹介する。
ローカルリカバリの確認
今回は、プロセスにKILLシグナルを送った場合の挙動でローカルリカバリが正常に動作することを確認していく。まずは、作業前の状態を確認する。
[root@ylk1 root]#lcdstatus -e |
||||
BACKUP |
TAG |
ID |
STATE |
PRIO |
ylk2.example.com |
Mysql-ThinkIT |
mysql7712 |
ISP |
1 |
ylk2.example.com |
ip-192.168.44.134 |
IP-192.168.44.134 |
ISP |
1 |
(以下出力略) |
||||
表示の確認上、一部出力を割愛している点はあるが、アクティブ側のサーバ上でlcdstatus -eコマンドを打つと作成したMysql-ThinkITリソースのステートがISPとなっている。さらにpsコマンドとnetstatコマンドにより MySQLが起動していることを確認しておく。
[root@ylk1 root]# ps auxwww | grep mysql |
|||||||||
root |
7432 |
0.0 |
0.0 |
5204 |
156 |
tty1 |
S |
Dec11 |
0:00 |
/bin/sh /usr/local/bin/mysqld_safe |
|||||||||
(出力略) |
|||||||||
mysql |
7497 |
0.0 |
4.7 |
105464 |
12096 |
tty1 |
S |
Dec11 |
0:02 |
/usr/local/libexec/mysqld |
|||||||||
(以下出力略) |
|||||||||
[root@ylk1 root]# netstat -anp | grep 3306 |
||||||
tcp |
0 |
0 |
0.0.0.0:3306 |
0.0.0.0:* |
LISTEN |
7497/mysqld |
上記のようにMySQLが正常に起動していることを確認できたら、これらのプロセスにKILLシグナルを送り擬似障害を発生させる。
[root@ylk1 root]# kill -9 7432 7497
[root@ylk1 root]# netstat -anp | grep 3306
[root@ylk1 root]#
この時点で、MySQLが停止していることがわかる。LifeKeeperの障害検出のための監視は、初期設定であれば2分ごとに行われるため2分程度間隔をおいた後に再度起動状態を確認する。
[root@ylk1 root]# netstat -anp | grep 3306 |
||||
tcp |
0 0 0.0.0.0:3306 |
0.0.0.0:* |
LISTEN |
17623/mysqld |
停止前と異なるPIDで3306番ポートをListenしていることがわかる。これにより、LifeKeeperのローカルリカバリによりMySQLが再度起動されたことを確認することができる。