web-dev-qa-db-ja.com

F5 BIG_IP永続性iRulesが適用されましたが、選択したメンバーには影響しません

私は仮想サーバーを持っています。リソースとして2つのiRule（以下を参照）が割り当てられています。

サーバーログから、ルールが実行されているように見え、正しいメンバーが選択されます

セッションを永続化した後（ログメッセージに基づいて判断できる限り）プールから送信されますが、要求は最終的に別の場所に送信されます。

両方のルールは次のようになります。

when HTTP_RESPONSE {

  set sessionId [HTTP::header X-SessionId]

  if {$sessionId ne ""} { 

    persist add uie $sessionId 3600 

    log local0.debug "Session persisted: <$sessionId> to <[persist lookup uie $sessionId]>"

  }

}



when HTTP_REQUEST {

  set sessionId [findstr [HTTP::path] "/session/" 9 /]

  if {$sessionId ne ""} {

     persist uie $sessionId

     set persistValue [persist lookup uie $sessionId]

     log local0.debug "Found persistence key <$sessionId> : <$persistValue>"
  }
}

ルールからのログメッセージに従って、適切なバランサーメンバーが選択されます。

注：2つのルールは競合できません。パス内で異なるものを探しています。これらの2つのものが同じパスに表示されることはありません。

サーバーに関する注意事項：*デフォルトの負荷分散方法はRRです。 *仮想サーバーに割り当てられた永続性プロファイルはありません。

これで永続性を有効にするのに十分かどうか疑問に思っています。あるいは、2つのルールを組み合わせて、仮想サーバー用の永続性プロファイルを作成する必要がありますか？

それとも私が見逃したものは他にありますか？

編集：結局のところ、私は何かを逃しました。キープアライブ接続はルールに干渉するため、 this サポートケースが提案されているため、ルールを少し変更しました。

when HTTP_REQUEST {

  set sessionId [findstr [HTTP::path] "/session/" 9 /]

  if {$sessionId ne ""} {
     # added this line:
     LB::detach

     persist uie $sessionId

     set persistValue [persist lookup uie $sessionId]

     log local0.debug "Found persistence key <$sessionId> : <$persistValue>"
  }
}
load-balancingf5-big-ip
1
zoli

それで、ログエントリを見ると、期待される情報が表示されていますが、トラフィックはまだどこか別の場所に行き着いていますか？どこに行き着くの？また、同じセッションに2つの永続性エントリがあるのはなぜですか？それはシステムを混乱させるかもしれません。

仮想に永続性プロファイルを割り当てる必要はありません。永続性が設定されている場合は、iRuleがそれをオーバーライドする必要があります。ログエントリはどのように見えますか？また、DevCentralに投稿しましたか？ F5の経験を持つより多くの人々がそこでそれを見るかもしれません。 - http://devcentral.f5.com

変数の名前を変更してみましたか？どちらの場合も、変数名として「sessionID」を使用しています。 iRules内の変数はセッションベースです。つまり、システムとのセッションの間、変数はメモリに固定されたままになります。これらのiRuleの両方を実行している場合は、同じ変数名を要求と応答の両方のデータで上書きすることになり、セッションIDが空であるかどうかを確認するロジックチェックが役に立たなくなる可能性があります。つまり、sessionIDが要求に応じて設定され、応答には設定されないが、応答はコードを実行して空かどうかを確認します...希望どおりに失敗することはありません。異なる変数名は良いことです。

それ以外は、構文は正しいです。その問題が混乱を引き起こしていない限り、問題はiRule自体ではなく、永続性が要求と相互作用する方法にあるように見えます。

コリン

3
Colin

この状況では、最初のHTTPリクエストで、上記のiRulesに基づいて正しい永続性エントリをログに記録することはありません。これは、F5がこの要求の負荷分散先のプールメンバーをまだ決定していないため、後で別のイベントで永続性が設定されるためです。この決定は行われていないため、永続性エントリをまだ作成することはできません。これは、HTTP_REQUESTイベント全体の存続期間中、永続性の値を取得できないことを意味します。これは、HTTP_REQUESTイベントが完了し、次のイベントが発生した後にのみ実行できます。これが、期待されるデバッグデータが表示されていなくても機能していた理由です。代わりに、LB_SELECTEDで確認してみてください。そのイベントでエントリが作成されたことがわかります。

1
James Shewey