クライアント接続数オーバーへの対応

事象説明

統合運用管理ツールで設定する「最大同時接続クライアント数」を越えてクライアントから接続があった場合、接続を受け付けた直後にサーバ側から切断するためその接続要求は失敗し、COMM_FAILURE:java.net.SocketException がクライアントに返り、クライアントからのアクセスがエラーとなります(ユーザ実装による)。この原因は以下が考えられます。

クライアント台数の増加や利用頻度が上がったため
ネットワーク要因によりクライアントが終了しても切断事象がサーバに通知されず古いコネクションが残ることで最大数を超過

クライアント接続数オーバが発生した場合、AP サーバへの新たな接続が出来なくなります。またセッションの増大によりファイルディスクリプタ不足などが発生すると予期せぬ事象が発生します。特にリッチクライアントの場合は、クライアントの終了のさせ方がまずかったり、ファイアウォールやプロキシサーバによるセション切断が発生したりするとサーバでセッションの切断を検出できず、本来不要なコネクション(ここではゴーストセッションと名づけます)が増大していきます。このため実際に接続しているクライアント数以上に接続数が増える現象が発生してしまいます。

状況の確認方法

本障害の場合、以下のメッセージがイベントログ・syslogに出力されます。

UNIX：

OTXM:<システム名>:IIOPLSN_CLS:<プロセスID>: W:1:TPS07-00201 TERMINAL CONNECTION REJECTED. PLU:<リスナポート番号> TERMINAL NAME:<端末名> EXCEED MAX TERMINAL NUMBER.

OTXM:<システム名>:IIOPLSN_CLS:<プロセスID>: W:1:TPS07-00201 端末からの接続を拒否した。PLU名:<リスナポート番号> 端末名:<端末名> 理由:最大同時接続数を越えてしまった。

現在のWebOTX に接続しているクライアント数を確認することができます。クライアント情報のStatsHolderMBean（CLIName: tpsystem.ClientSession 運用管理ツール: [統計情報]-[domain]-[TPシステム]-[クライアントセッション]）接続クライアント数(connectionNum)のカレント値を参照します。

現在のWebOTX に接続しているクライアントの情報を取得することができます。接続先のIP アドレスや接続時間なども確認できます。同一のIP アドレスからのセッションが多数存在する場合や異常に長い接続時間のセッションが存在する場合はゴーストセッションが存在する可能性があります。運用管理ツールの「TP システム」-「クライアントセッション」を参照します。otxadmin コマンド(list-tpsystem-clients-status)を使用してコマンドラインから参照することもできます。

OS より提供されているnetstat コマンドにより接続しているセッション数を確認することができます。netstat -a コマンドで表示されるリストのうちlocal 側のポートがiiop リスナのポートであるものが、現在WebOTX が接続しているセッションの数です。

${INSTANCE_ROOT}/logs/tpsystem/sysmsg.trc で接続、切断履歴を確認してください。TPS07-00103 で接続、TPS07-00107 で切断が確認できます。また、現在の利用可能な同時接続数の設定を確認する方法は次のとおりです。

統合運用管理ツールを使用する場合
[TP システム]-[IIOP リスナ]上限設定タブの[最大同時接続クライアント数]

コマンドで確認する場合

otxadmin> get tpsystem.IIOPListener.simultaneousConnectionClients

問題の検出方法

実際にWebOTX で設定した最大数やOS の制限に達する前に問題を検出する方法としては以下の方法があります。

　統計情報における接続クライアント数の監視

クライアント情報のStatsHolderMBean（CLIName: tpsystem.ClientSession 運用管理ツール: [統計情報]-[domain]-[TP システム]-[クライアントセッション]）接続クライアント数(connectionNum)のカレント値の閾値上限を設定してモニタリングします。

採取資料

イベントログ(アプリケーション、システム)・syslog
${INSTANCE_ROOT}/config/tpsystem/iioplsn.ped
netstat -a の結果

復旧方法

実際にこの現象が発生してしまった場合の復旧方法について説明します。

　セッションの強制切断

現在接続しているセッションの強制切断を行い、接続数を減らすことができます。状況の確認方法でも説明していますが、接続時間やクライアントIP アドレスからゴーストセッションが特定できる場合、それに対して強制切断を実施します。
運用管理ツールから「TP システム」-「クライアントセッション」を選択して「クライアント切断(disconnection)」を実行してください。otxadmin コマンド(disconnect-cl)を使用してコマンドラインからも切断できます。

どのセッションを強制切断してよいかが判断がつかない場合は、WebOTX システムの再起動を実施する必要があります。

予防のための対策

この問題を予防するための対策については以下の方法があります。

最大接続セッション数の見直し

セッション数が不足している場合は、TP システム(tpsystem)のIIOP リスナ(IIOPListener)の「最大同時接続クライアント数」を見直します。以下の手順で同時接続クライアント数を設定してください。余裕を持たせた値を設定してください。

TP システムを停止する
最大同時接続クライアント数を設定する
統合運用管理ツール
　[TP システム]-[IIOP リスナ]上限設定タブの「最大同時接続クライアント数」
運用管理コマンド（例）
```
otxadmin> set tpsystem.IIOPListener.simultaneousConnectionClients=100
```
TP システムを起動する

未接続状態であっても、「最大同時接続クライアント数」に比例してメモリを消費します。AP が多段構成になっている場合、手前のAP がクライアントとなって「最大同時接続クライアント数」を消化することがあるので、それも考慮する必要があります。

クライアントが接続しっぱなしの場合、運用的に切断してもよいのであれば無通信監視の設定を行ないます。TP システム(tpsystem)のIIOP リスナ(IIOPListener)の以下の設定を見直します。「クライアント制御」タブにある「クライアントとの無通信監視を行う」をチェックして「クライアントとの無通信監視間隔」に監視間隔を設定します。

ゴーストセッションが発生していると考えられる場合は、TCP レベルでのキープアライブ設定を有効にすることで、その刈り取りを行うことができます。TP システム(tpsystem)の次の設定を見直します。「クライアント制御」タブにある「TCP レベルでのアライブチェックを行う」をチェックします。keepalive 機能自体はOS が持つ監視機能となります。WebOTX ではOS のkeepalive 機能使用有無のみを設定します。keepalive 機能のアライブチェック間隔はOS に依存します。

ERROR : org.omg.CORBA.COMM_FAILURE: java.net.SocketException: Connection reset vmcid:0x1000 minor code: 911 completed: Maybe

ERROR : org.omg.CORBA.COMM_FAILURE: java.net.SocketException: Connection reset by peer:socket write error vmcid: 0x1000 minor code: 911 completed: No

TP システムを停止する
利用可能な接続要求最大保留数を設定する
　[TP システム]-[IIOP リスナ]クライアント制御タブの「接続要求最大保留数」
運用管理コマンド（例）
　
```
otxadmin> set tpsystem.IIOPListener.maxConnectionSuspension=100
```
TP システムを起動する