バックアップに時間がかかるため、ファイアウォールが接続を閉じます

Question

ここではシステムのマッシュアップが少しありますので、ご容赦ください。基本的に、リモートLinuxサーバーをバックアップしようとしているときに、Oracle用のBackupExecエージェントを使用する際に問題が発生します。 BEエージェントはRMANを使用してデータベースをバックアップしているようです

バックアップサーバーは1つのVLANにあり、ターゲットサーバーは別のサーバーにあり、CiscoASAファイアウォールがそれらの間の唯一のリンクを提供します。バックアップサーバーは多数のクライアントをサポートするためであり、各クライアントが相互にアクセスできないように、各クライアントは独自のVLAN上にある必要があるため、これは仕様によるものです。少なくともエージェントがメディアサーバーと通信できるように、ファイアウォールに推奨ポートを追加しました。

バックアップは十分に開始されますが（実際、同じサーバー上の小さなOracleデータベースは問題なく完了します）、200 GBのデータベースは、明らかに完了するのに数時間かかりますが、完了できません。

この問題は http://www.symantec.com/business/support/index?page=content&id=TECH59632 に関連していると思います。これは、CORBAセッションがポート5633のバックアップの開始であり、各RMAN操作の前に使用されますが、データが転送されている間、CORBAセッションのソケットはパケットを受信しません。ファイアウォールでの接続タイムアウトは60分であるため、CORBAセッションはドロップされ、RMANエージェントが次のアクションを実行しようとすると、プロセス全体が爆破されます。 Symantecによると、この問題は以前のバージョンのBackup Execで修正されたとのことですが、それを実施するための追加設定については詳しく説明していません。

ファイアウォールの接続タイムアウトをバックアップウィンドウをカバーするのに十分な高さ（たとえば12時間）に設定することは間違っているように思われます。これは不動産全体の変更であり、（たとえば）別のクライアントのWebサーバーへのWeb要求。

Linuxサーバーをバックアップサーバーと同じLANに移動することは問題外です。

私はLinuxの第一人者ではありませんが、大まかに自分のやり方を知っています。これまで、libkeepalive（ http://libkeepalive.sourceforge.net/ ）を使用して、KEEPALIVE TCPフラグを使用してベリモートプロセスのソケットを強制的に作成しようとしました。 、ただし、クイックnetstat -topは、実行されていないことを示します。 libkeepaliveを誤って使用しているか、ベレモテバイナリで機能しません

自分がいる環境に合ったオプションを探していると思います。次の1つ以上を探していると思います。

• 接続を維持するようにBEエージェントを構成する方法は？
• キープアライブフラグを既存のTCP接続に挿入する方法（例：cronjob経由）？
• 特定のソース/ターゲット（おそらくポリシーマップ）の接続タイムアウトを増やすようにCiscoデバイスに指示する方法はありますか？

任意/すべての（その他の）アイデアを歓迎します...

J。

---

RE：@Weaverによるコメント

要求に応じて、class-map、policy-map、およびservice-mapエントリ...

class-map CLS_INSPECTION_TRAFFIC
 match default-inspection-traffic
class-map CLS_ALL_TRAFFIC
 match any
class-map CLS_BACKUPEXEC_CORBA
 description Oracle/DB2 CORBA port for BackupExec traffic
 match port tcp eq 5633
!
!
policy-map type inspect dns PMAP_DNS_INSPECT_SETTINGS
 parameters
  message-length maximum client auto
  message-length maximum 1280
policy-map PMAP_GLOBAL_SERVICE
 class CLS_INSPECTION_TRAFFIC
  inspect dns PMAP_DNS_INSPECT_SETTINGS 
  inspect ftp 
  inspect h323 h225 
  inspect h323 ras 
  inspect rsh 
  inspect rtsp 
  inspect esmtp 
  inspect sqlnet 
  inspect skinny  
  inspect sunrpc 
  inspect xdmcp 
  inspect sip  
  inspect netbios 
  inspect tftp 
  inspect ipsec-pass-thru 
  inspect icmp 
  inspect snmp 
 class CLS_BACKUPEXEC_CORBA
  set connection timeout idle 1:00:00 dcd 
 class CLS_ALL_TRAFFIC
  set connection decrement-ttl
!

Answer 1

ASAタイムアウト/タイマーの背景：

グローバルtimeout connis TCP仮想回線（セッション）アイドルタイマーで、デフォルトは60分です。グローバルtimeout udpはUDPホール用で、デフォルトは2です。グローバルtimeout xlateは、残りの翻訳をクリアするためのものですafterconnがタイムアウトしました conn（TCP）タイムアウトがxlateタイムアウトよりも優先されます。 =次の段落では、connタイマーとxlateタイマーの関係についてさらに説明します。

ConnがTCPティアダウンを介して正常に破棄された場合、connとxlateはそれに伴います（動的xlateの場合、静的NATおよび静的PATxlateは削除されません） ）connがタイムアウトした場合、xlateタイマーが考慮されます。xlateが最初にタイムアウトした場合（実際に低く設定した場合）、接続が切断されるまで connがタイムアウトします。

ASAには、さまざまなタイムアウトを処理するためのいくつかの方法があります。 Connは、クラスマップに基づいてグローバル設定をオーバーライドできるものです。可能であれば、グローバル設定を増やすよりも、これを優先する必要があります。

ASAが持つもう1つの興味深い機能はデッドコネクション検出です-DCD。 DCDを使用すると、[グローバル]接続タイムアウトを60分（デフォルト）に保ち、60分に達したときに-ASA man-in-the-middleは、他のエンドポイントとして各エンドポイントにnullデータACKをスプーフィングします。ヌルデータは、シーケンス番号が増加するのを防ぐために機能します。両側が応答すると、接続のアイドルタイマーは0にリセットされ、再開します。特定の期間に設定された回数（構成可能）の試行後にいずれかの側が応答しない場合、接続が削除され、xlateタイマーが上記のように関連性を獲得します。

クラスマップを設定し、それをDCDを有効にするポリシーに追加することをお勧めします。 ACLまたはポートを使用できます（他のものも使用できます）。ポートの使用はすばやく簡単で、TCP/5633が問題の原因であることが確実な場合にうまく機能します。

以下のglobal_policyを使用しましたが、必要に応じて自由に調整してください。

class-map BE-CORBA_class
 description Backup Exec CORBA Traffic Class
 match port tcp eq 5633

policy-map global_policy
 class BE-CORBA_class
  -->::Choose one below::<--
  set connection timeout idle 1:00:00 dcd --> for 8.2(2) and up
  set connection timeout tcp 1:00:00 dcd --> for prior to 8.2(2)

service-policy global_policy global

@コメント

リファレンスガイドによる -"パケットは、各機能タイプのポリシーマップ内の1つのクラスマップにのみ一致できます。」

キーフレーズは太字で示しています。インターフェイスを通過するパケットは、ポリシーマップ内の複数のクラスと一致できますが、それらのクラスが異なる「機能」を使用している場合に限ります。前述のリンクを少し上にスクロールすると、さまざまな機能が一覧表示されます。そのページ全体がMPFの一口の金鉱です。

あなたが言ったようにあなたはmatch anyクラスマップが定義され、ポリシーマップ内のクラスとして参照されます-そのポリシーマップクラスで他のTCPおよびUDP接続制限とタイムアウトの変更を実行している場合は、トラフィックに一致する後続のクラスマップ（ポリシーマップで設定されている場合）は、そのパケットでTCPおよびUDP接続制限とタイムアウト変更を実行しません。

すべてのACLを投稿する場合、class-map's、policy-map'砂 service-policy確かに判断できます。

Answer 2

私は、1つのTCPセッションが強制終了されたときに、おもちゃを持って帰宅する（そしてバックアップに失敗する）アプリケーションのファンではありませんが、この場合は、 ASAのTCPセッションタイムアウト。

セッションの長さに厳しい制限を設けることは、実際には、状態（および通常はNAT）を維持するためにすべての接続を追跡するASAの必要性の産物にすぎません。デバイスの接続制限に反して実行している場合は、問題になる可能性があります。それ以外の場合は、6時間程度までクランクしてください。

TCPセッションの終わりにある両方のノードが暗くなる場合を除いて、ASAは、接続が自然に終了したときに、一方の端またはもう一方の端が接続を終了するのを監視し、接続を切断します（またはトリガーします）。ハーフクローズ接続のタイムアウトが短いため）、大量のデッド接続が詰まる可能性はほとんどありません。エンドポイントデバイスは、無駄な接続を切断することにも関心があります。Webサーバーは良い例です。通常、ASAよりも接続タイムアウトがはるかに短くなります。

Answer 3

BackupExecからローカルCORBAポートへの接続に応答して転送するリモートLinuxマシンで汎用TCPプロキシを使用することを検討してください（BackupExecサーバーが接続するように簡単に調整できます）。このプロキシは、ファイアウォールのNATルール）を使用します。そのTCPプロキシでは、作成するリスニングソケットにSO_KEEPALIVEオプションを設定する必要があります。My proxy-of-choiceは rinetd ですが、ソースをざっと見ると、リスニングソケットにSO_KEEPALIVEオプションが設定されていないことがわかります（したがって、動作を取得するには、それを変更する必要がありますデフォルトで（またはオプションとして）SO_KEEPALIVEを設定する別の汎用TCPプロキシがありますが、頭のてっぺんから1つはわかりません。

別のオプションは、接続を維持するためにSO_KEEPALIVEまたはSSH nullパケットのいずれかを使用するように設定されたSSHクライアントを使用して、ジョブ前スクリプトの一部としてリモートマシンへのSSHトンネルを起動することです。