VPN 経由で Oracle のセッションが切れた？ keepalive 層を確認する

二十五分間の有益なデータベース作業はほとんど出力を生まず、経路上のどの機器から見てもそのフローはアイドル状態に見えます。まさにそのアイドル状態が回収されます。後から振り返る報告はいつも同じ形です。クエリは動いていた、そのうちセッションが消え、結果は届かなかった、というものです。

静かなセッションが生き残るかどうかは四つの確認で決まり、それらはソケットから外側へ進みます。前の層が仕事をしていると前提するので、順番に行ってください。

どのフローが静かになるか

重要なのはデータベースのトラフィックを運ぶ接続で、それ自身のアドレスとポートで識別されます。それ以外の何もこの接続を更新しません。ゲートウェイへの ping、同じホストからの二本目の SQL 接続、トンネル自身のハートビートは別々のフローであり、それらを追跡するすべての機器で状態が別々です。

ss -tio dst 10.60.4.20
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

ソケット一覧は、生きている接続のタイマーとキュー状態を示し、到達性テストより多くの情報を与えます。sysctl の値は keepalive の挙動に関するカーネルの既定値で、次の節ではそれがあなたのセッションに決して適用されない可能性を説明します。決して発動しない既定値は、既定値がまったく無いのと区別できません。

接続が使うアドレス、ポート、インターフェースを書き留めてください。セッションが死んだとき、ネットワークが上がっていたかを尋ねる代わりに、正しい機器に何をしたのかを尋ねられるのは、この詳細のおかげです。

アイドルポリシーは期限切れか、制限か

二つのポリシーは同じ症状を生み、反対の対応を要求します。アイドルタイムアウトは、適格なトラフィックが更新できたはずの状態を削除し、keepalive はそれを防げます。絶対セッション制限は、活動に関係なく一定時間でフローを削除し、どんな keepalive もそれを変えません。

各中間装置の所有者に、どちらを実装しているかを尋ねてください。ファイアウォール、NAT 装置、ロードバランサー、クラウドゲートウェイはすべて状態を保持でき、互いに一致している必要はありません。最も狭いものが、打ち負かすべき期限を決めます。

この区別は、いつ調整をやめるかも教えます。ポリシーが絶対制限なら、正しい解決はより短い作業単位、再開可能なジョブ、承認された例外であり、下の確認は keepalive が何も変えなかったことを確かめるだけです。

Linux の既定値の背後にあるソケットスイッチ

keepalive はソケットごとの選択です。カーネルの既定値は、ソケットが仕組みを有効にした後にプローブがどう振る舞うかを記述するもので、既存の接続に対して有効化するものではありません。決して要求しないアプリケーションは、sysctl の値が何であれプローブを受け取りません。

だから数値を上げるだけではデータベースクライアントに何の変化もありません。仕組みはクライアントライブラリかアプリケーションが有効にする必要があり、接続ごとの制御をスタックが提供する場面では、無関係なサービスに影響するホスト全体の変更より限定的な設定が勝ります。

最初のプローブまでの間隔もクエリのタイムアウトではありません。健全な接続はプローブの間は静かなままで、死んだ相手はプローブの間隔と回数で判定されます。この三つの値を一つのタイムアウトとして読むと、障害をずっと遅く、あるいはずっと早く検出する設定に至ります。それらは検出を制御するのであって、アプリケーションの我慢を制御するのではありません。

EXPIRE_TIME はデータベースの設定であり、ネットワークの修正ではない

Oracle Net は独自の生存確認の仕組みを提供し、それはプロセスの有効なプロファイルで構成され、たまたま似た名前の任意のファイルで構成されるのではありません。値は分単位で表されます。

SQLNET.EXPIRE_TIME = 5

主な目的はサーバー側での死んだ接続の検出で、拡張モデルをサポートするプラットフォームではこれらの接続の TCP keepalive の挙動も調整します。これは有用な性質です。データベース層がクライアントアプリケーションに変更を求めることなくプローブを用意できます。

上の例示値は想定された期限に対する調整済みの選択であり、推奨ではありません。文書化された一般の指針はより長い間隔で、正しい数値は導入された実装、受け入れるプローブの負荷、経路上の実際の更新規則に依存します。設定は該当するプロセスが読むプロファイルに置き、プロセスがそれを取り込んだことを確認してください。Oracle はプロファイルの場所と検出の挙動をパラメーターリファレンスで文書化しています。

静かな間隔を試し、そのうえで復旧を計画する

新しく許可された接続を、打ち負かそうとしている期限より長い静かな期間に通し、生存確認のトラフィックとアプリケーションの結果を観察してください。不要なペイロードの中身は取得しないでください。タイマーと接続状態が問いに答えます。

ss -tio dst 10.60.4.20
# after the quiet interval, same command
ls -l "$ORACLE_HOME/network/admin/sqlnet.ora"

それでもセッションが消えるなら、期限はまだ尋ねていない機器のものであるか、ポリシーが絶対制限です。生き残るなら、どの層が変わったのかを記録し、次の静かな操作で調査を繰り返さないようにしてください。

最後に、接続が実際に落ちたときに何が起きるかを決めてください—生存確認は頻度を下げるだけで、可能性をなくすことはありません。データベース操作の記録された結果を、再送する前に確定してください。応答を失ったことは、作業が確定したかどうかを何も証明しません。ノート PC を閉じることやトンネルの再起動を耐えなければならないものには、サーバーが所有し永続的な結果を持つジョブのほうが強い設計であり、keepalive はスケジューラーではありません。