配備とアップグレードに関する特別な情報 (Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Update 2 リリースノート)

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Update 2 リリースノート

配備とアップグレードに関する特別な情報

ここでは、HADB の配備とアップグレードに関する追加情報を示します。

導入

デバイス、ログ、および履歴ファイルはローカルディスクにのみ格納するようにし、リモートマウントのファイルシステムは使用しないでください。
ホストに複数のノードが配置されている場合は、各ノードに所属するデバイスを別のディスクに保管することをお勧めします。そうしないと、ディスクの競合によってパフォーマンスが低下します。この問題の症状は、「BEWARE - last flush/fputs took too long」などのメッセージによって履歴ファイルで確認できます。1 つのノードに複数のデータデバイスファイルがある場合は、これらのデバイスファイルに別々のディスクを使用することをお勧めします。
ローカルディスク (可能であれば、データデバイスに使用されているものとは別のディスク) を使用して、HADB ホストに HADB バイナリをインストールしてください。NFS の遅延またはディスクの競合によって、履歴ファイルに「Process blocked for nnn, max block time is nnn」という警告が出力され、ノードが再起動される可能性があります。
HADB デバイス、履歴ファイル、管理エージェントディレクトリ、およびエージェント設定ファイルを HADB パッケージのパスには配置しないでください。これを行うと、新しいバージョンにアップグレードし、古いパッケージのパスを削除したときに問題が発生します。
このリリースの HADB では、最大 28 ノード (24 のアクティブデータノード、および 4 つのスペア) が正式にサポートされています。
JDBC ドライバおよび HADB サーバーには同じバージョンを使用することをお勧めします。
IPv6 はサポートしていません。IPv4 のみです。
Windows でのコマンド行の長さは、2048 バイトに制限されています。
UDP マルチキャスト用にネットワークを設定する必要がある。
RedHat Enterprise Linux 3.0 Update 1 〜 3 は、過剰なスワッピングが見られるため、配備プラットフォームとしてはお勧めできません。この問題は、RedHat Enterprise Linux 3.0 Update 4 では修正されています。
NSUP をリアルタイム優先度を使用して実行する可能性は次のとおりです。

ノードスーパーバイザー (NSUP) のプロセス (clu_nsup_srv) は、タイムリーな方法による「ハートビート」メッセージ交換を利用して、HADB の高可用性を保証します。NSUP がほかのプロセスと同じ場所に配置されていると、このタイミングが影響を受け、リソースの枯渇が発生します。その結果、誤ったネットワークパーティションが発生し、ノードが再起動します (その前に、履歴ファイルに「Process blocked for n seconds」という警告が出力される)。それにより、トランザクションの中止やその他の例外が発生します。

この問題を解決するには、clu_nsup_srv (installpath/lib/server に格納されている) の suid ビットを設定し、そのファイルをルートが所有するようにする必要があります。これを手動で行うには、次のコマンドを実行します。
# chown root clu_nsup_srv # chmod u+s clu_nsup_srv
これにより、clu_nsup_srv プロセスは、起動されると、ユーザー root として実行されます。さらに、起動後、自分自身にリアルタイム優先度を自動的に与えることができるようになります。setuid を使用することによるセキュリティーへの影響を避けるために、リアルタイム優先度は最初の間だけ設定され、優先度が変更されたらプロセスは有効な uid に戻ります。ほかの HADB プロセスは、優先度をタイムシェアするために自分の優先度を低くします。

NSUP がリアルタイム優先度を設定できない場合は、「Could not set realtime priority」(unix: errno will be set to EPERM) という警告を出力します。この警告は ma.log ファイルに書き込まれ、リアルタイム優先度を使用しないで処理が継続されます。

リアルタイム優先度を設定できない例として、次のような場合があります。
- Solaris 10 の非大域ゾーンにインストールされている場合
- Solaris 10 で、PRIV_PROC_LOCK_MEMORY (プロセスが物理メモリー内のページをロックできる) または PRIV_PROC_PRIOCNTL 特権、あるいはその両方が無効になっている場合
- ユーザーが setuid 権限を無効にしている場合
- ユーザーがソフトウェアを tar ファイルとしてインストールしている場合 (App.server 用のルート以外のインストールオプション)
clu_nsup_srv プロセスは CPU の消費が少なく、フットプリントも小さいため、リアルタイム優先度を使用して実行してもパフォーマンスには影響しません。

Solaris での HADB 用の IP ネットワークマルチパスの設定 (Solaris 9 でのみテスト済み)

可能な範囲で最高のネットワーク可用性を保証するために、HADB を実行している Solaris ホストをネットワークマルチパスを使用して設定することをお勧めします。ネットワークマルチパスの設定は、『IP Network Multipathing Administration Guide』で詳細に説明されています。HADB でマルチパスを使用することにした場合は、後述されている HADB 用のマルチパス設定への対応に進む前に、『IP Network Multipathing Administration Guide』の「Administering Network Multipathing」の節を参照してマルチパスを設定してください。『IP Network Multipathing Administration Guide』は、Solaris 9 の『System Administrator Collection』に含まれており、http://docs.sun.com からダウンロードできます。

ネットワークインタフェース障害検出時間の設定

HADB でマルチパスのフェイルオーバーを適切にサポートするには、/etc/default/mpathd 内の FAILURE_DETECTION_TIME パラメータで指定されているネットワークインタフェース障害検出時間が 1000 ミリ秒を超えないようにする必要があります。元の値がこの値を超えている場合は、このファイルを編集して、このパラメータの値を 1000 に変更します。
FAILURE_DETECTION_TIME=1000
変更を有効にするために、次のコマンドを実行します。
pkill -HUP in.mpathd
HADB で使用する IP アドレス

『Solaris IP Network Multipathing Administration Guide』で説明されているように、マルチパスを使用するには、物理ネットワークインタフェースをマルチパスインタフェースグループにグループ化する必要があります。このようなグループ内の各物理インタフェースには、物理インタフェースアドレスとテストアドレスの 2 つの IP アドレスが関連付けられます。データの送信に使用できるのは物理インタフェースアドレスのみであり、テストアドレスは Solaris 内部の使用のためにのみ用意されています。hadbm create --hosts が実行されると、各ホストは、マルチパスグループの 1 つの物理インタフェースアドレスによってのみ指定されます。

例

ホスト 1 とホスト 2 のそれぞれに、2 つの物理ネットワークインタフェースが含まれていると仮定します。各ホスト上で、これらの 2 つのインタフェースをマルチパスグループとして設定し、ifconfig -a を実行すると次の出力が得られます。

ホスト 1

bge0: flags=1000843<mtu 1500 index 5 inet 129.159.115.10 netmask ffffff00
broadcast 129.159.115.255 groupname mp0
bge0:1: flags=9040843<mtu 1500 index 5 inet 129.159.115.11 netmask ffffff00
broadcast 129.159.115.255
bge1: flags=1000843<mtu 1500 index 6 inet 129.159.115.12 netmask ffffff00
broadcast 129.159.115.255 groupname mp0
bge1:1: flags=9040843<mtu 1500 index 6 inet 129.159.115.13 netmask ff000000
broadcast 129.159.115.255

ホスト 2

bge0: flags=1000843<mtu 1500 index 3 inet 129.159.115.20 netmask ffffff00
broadcast 129.159.115.255 groupname mp0
bge0:1: flags=9040843<mtu 1500 index 3 inet 129.159.115.21 netmask ff000000
broadcast 129.159.115.255
bge1: flags=1000843<mtu 1500 index 4 inet 129.159.115.22 netmask ffffff00
broadcast 129.159.115.255 groupname mp0
bge1:1: flags=9040843<mtu 1500 index 4 inet 129.159.115.23 netmask ff000000
broadcast 129.159.115.255

ここで、両方のホスト上の物理ネットワークインタフェースは、bge0 および bge1 として表示されています。『IP Network Multipathing Administration Guide』で説明されているように、bge0:1 および bge1:1 として表示されているのはマルチパステストインタフェースです (そのため、ifconfig 出力ではこれらのインタフェースが「非推奨」としてマークされている)。

この環境で HADB を設定するには、各ホストから 1 つの物理インタフェースアドレスを選択します。この例では、ホスト 1 からは 129.159.115.10 を、ホスト 2 からは 129.159.115.20 を選択します。ホストあたり 1 つのデータベースノードを含むデータベースを作成するには、hadbm create に次の引数を使用します。

--host 129.159.115.10,129.159.115.20

ホストあたり 2 つのデータベースノードを含むデータベースを作成するには、次の引数を使用します。

--host 129.159.115.10,129.159.115.20,129.159.115.10,129.159.115.20

どちらの場合も、両方のホストの ma.server.mainternal.interfaces 変数を 129.159.115.0/24 に設定してください。

4.4.1 から 4.4.2 へのオンラインアップグレード

オンラインで 4.2 または 4.3 から 4.4 にアップグレードすることはできません。ただし、4.4 の将来のバージョンではオンラインアップグレードがサポートされます。4.4.1 から 4.4.2 にアップグレードするには、次の手順を実行します。

すべての HADB ホストに 4.4.2 をインストールします。パスは 4.4.1 とは別のパス、たとえば /opt/SUNWhadb/4.4.2-6 にします。
hadbm クライアントホストに新しいバージョンをインストールします。
HADB ホスト上で実行されているすべての管理エージェントを停止します。
新しいバージョンのソフトウェアを使用して (ただし、設定ファイルは古いまま)、管理エージェントプロセスを起動します。残りの手順では、新しいバージョンの bin ディレクトリにある hadbm コマンドを使用してください。
管理ドメインでパッケージを登録します。ここで、デフォルトのパッケージ名が V4.4 になるため、同じ名前を持つ既存のパッケージとの競合を避けるために別のパッケージ名が必要になる場合があります。
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-6 V4.4.2
新しいバージョンを使用してデータベースを再起動します。次のコマンドでは、ノードの順次再起動が実行されます。
hadbm set packagename=V4.4.2 database_name
データベースが「実行中」の状態にあり (hadbm status コマンドを使用して確認)、かつ正常に動作してクライアントトランザクションを処理していることを確認します。
すべてが正常に動作している場合は、あとで古いインストールを削除することができます。

古いパッケージの登録を解除する前に、古いパッケージへのすべての参照を ma リポジトリから削除します。そうしないと、「使用中のパッケージ」のために hadbm unregisterpackage が失敗します。たとえば、ダミーの再設定操作 hadbm set connectiontrace=<same_as_previous_value> によって、古いパッケージへのすべての参照が削除されます。ここで、古いパッケージの登録を解除します。
hadbm unregisterpackage [--hosts=<host_list>] <old_package_name>
HADB のインストール手順で説明されているように、ファイルシステムから古いインストールを削除します。