役割変更アクションスクリプトの作成

Sun Cluster Geographic Edition ソフトウェアは、保護グループ内のクラスタが secondary 役割から primary 役割に変わるときにコマンドを実行するように構成できます。この役割変更は、スイッチオーバーまたはテイクオーバー操作の結果として発生する可能性があるものです。

アクションコマンドは、新しい主クラスタ上で保護グループが起動されたときに、その新しい主クラスタ上でスイッチオーバーまたはテイクオーバー中に実行されます。スクリプトは、データ複製の役割が二次クラスタから主クラスタに変更されたあと、アプリケーションリソースグループがオンラインになる前に、新しい主クラスタ上で呼び出されます。データ複製の役割変更が成功しなかった場合は、スクリプトは呼び出されません。

このスクリプトへのパスは、保護グループをホストできるすべてのパートナークラスタの全ノードで有効にしてください。

スクリプトの実行は次のコマンドによって行われます。

# custom-action-command-path -o primary -c clustername \ 
 -s partnershipname protectiongroupname userarguments

customactioncommandpath

作成したアクションコマンドのパスを指定します。

-o primary

クラスタに、主クラスタの役割 (primary) を指定します。

-c clustername

新しく主クラスタの役割を担う二次クラスタの名前を指定します。

-s partnershipname

保護グループをホストするパートナーシップの名前を指定します。

protectiongroupname

役割変更が行われる保護グループの名前を指定します。

userarguments

Sun Cluster Geographic Edition に用意されているオプションがすべて渡されてから渡される静的引数を指定します。

必要に応じ、スクリプトを使用してこの自由書式の文字列を解析できます。たとえば、name=sun.com,ip=10.1.2.3 のように、key=value のペアのリストを指定できます。また、-n sun.com -a 10.1.2.3.4 のように、複数のオプションを並べて指定することもできます。これらの引数の書式は、Sun Cluster Geographic Edition ソフトウェアによる制限を受けません。

役割変更アクションスクリプトの終了状態は、geopg switchover または geopg takeover コマンドの結果の一部として報告されます。アクションスクリプトが正常に実行された場合、終了状態は 0 になります。エラーや障害が発生した場合、終了状態は 0 以外になります。終了状態の値は、役割変更アクションのほかの側面には影響を及ぼしません。スイッチオーバーやテイクオーバーを実行すると、アクションスクリプトの終了状態とは関係なく、保護グループ内のアプリケーションリソースグループがオンライン状態になります。

Sun Cluster Geographic Edition ソフトウェアはスクリプトが制御を返すまで待ち、それからアプリケーションリソースグループをオンラインにするなどの処理を行います。したがって、アクションスクリプトを作成する際は、保護グループのためのタイムアウト間隔を適切に設定できるように、スクリプトの実行に必要な時間量をあらかじめ知っておく必要があります。スイッチオーバーやテイクオーバーがタイムアウトとなり、新しい主クラスタ上でアプリケーションリソースグループがオフラインのままになるのを避けるため、スクリプトが完了するだけの十分な時間が含まれるようにタイムアウト間隔を設定してください。

例 9–1 DNS を更新するスイッチオーバーアクションスクリプト

このスクリプト例では、nsupdate コマンドを使用して、新しいクラスタを指すようにホスト名を再構成する方法を示します。nsupdate コマンドについては、nsupdate(1M) のマニュアルページを参照してください。

companyX.com に接続を試みるクライアントは、ネームサービスによって、保護グループの主クラスタのアドレス cluster-paris として参照されます。主クラスタが応答しない場合、管理者は、保護グループを代替クラスタ cluster-newyork にスイッチオーバーします。

#!/bin/ksh
# sample script to update dns
# Assumes each cluster has an entry with name "lh-paris-1" in /etc/hosts
# but different value for the IP in each cluster
# for forward DNS (A) entry: will delete old entry for "lh-paris-1"
# and add one that is correct for "this cluster"
#
# For reverse (PTR) DNS entry, will just add one for this cluster. 
# Will NOT delete PTR record left over from old cluster. So
# eventually you will just have reverse lookup for the IP for both clusters
# doing reverse resolution to the same name (lh-paris-1.odyssey.com)
# This should be fine, as long as the forward resolution stays "correct"
#
# The blank line of input at the end of nsupdate is REQUIRED
#
# A short TTL is put on the new records (600 = 10 minutes)
# but you can't really control what kind of caching goes on on
# the client side


# get IP corresponding to name "lh-paris-1" on THIS Cluster
NEWIP=$(getent hosts lh-paris-1|cut -f1)

# this bit splits out the octets in order to add the reverse PTR entry
IFS=.
set $NEWIP
unset IFS

/usr/sbin/nsupdate <<ENDNSUPDATE
update delete ora-lh.odyssey.com A
update add ora-lh.odyssey.com 600 A $NEWIP
update add $4.$3.$2.$1.in-addr.arpa 600 PTR ora-lh.odyssey.com.

ENDNSUPDATE