web-dev-qa-db-ja.com

LVSがパケットをドロップするのはなぜですか？

私は現在、LVSディレクターがクライアントからのパケットを時々ドロップしているように見える問題の核心に立ち向かおうとしています。実動システムでこの問題が発生し、ステージングで問題を再現できます。

この問題をlvs-users-mailing-listに投稿しましたが、これまでのところ応答がありません。

私たちのセットアップ：

PVXEN-DomUでLinuxCentOS5x86_64でipvsadmを使用しています。

現在のバージョンの詳細：

  • カーネル：2.6.18-348.1.1.el5xen
  • ipvsadm：1.24-13.el5

LVS-セットアップ：

Lvs-kissを使用して実行中の接続を管理するために、DRモードでIPVSを使用します。

ipvsadmはheartbeat-v1-cluster（2つの仮想ノード）で実行されており、マスターとバックアップは両方のノードで常に実行されています。

LVSサービスの場合、ハートビートによってセットアップされている論理IPを使用します（アクティブ/パッシブクラスターモード）

実サーバーは物理的なLinuxマシンです。

ネットワークセットアップ：

ディレクターとして機能するVMは、ブリッジネットワークを使用してDom0上でXEN-PV-DomUとして実行されています。

「インプレー」のネットワーク：

  • abn-network（staging-network、クライアントをダイレクタに接続するために使用）、実サーバーがクライアントに応答を送信するために使用（ダイレクトルーティングアプローチ）、ipvsadmスレーブ/マスターマルチキャストトラフィックに使用
  • lvs-network：これは専用のVLAN）であり、ダイレクタと実サーバーを接続します
  • DR-arp-problem：service-ipの実サーバーでのarp-answersの抑制を解決しました
  • Service-IPは、実サーバーのlvs-interfaceで論理IPとして構成されます。
  • この設定では、ip_forwardingはどこにも必要ありません（directorでも実サーバーでも）。

VMの詳細：

1 GB RAM、2 vCPU、システム負荷はほぼ0、メモリは73M空き、224Mバッファ、536Mキャッシュ、スワップなし。

topは、ほとんどの場合100％アイドル、0％us/sy/ni/wa/hi/si/stを示します。

構成の詳細：

ipvsadm -Ln問題のサービスの場合：

TCP  x.y.183.217:12405 wrr persistent 7200
 -> 192.168.83.234:12405   Route   1000   0          0
 -> 192.168.83.235:12405   Route   1000   0          0

x.y最初の2つのオクテットは、内部クラスB範囲からのものです。ステージング用のlvs-networkとして192.168.83.xを使用します。

永続的なipvsadm-構成：/ etc/sysconfig/ipvsadm：-set 20 20 20

クラスター構成：/ etc/ha.d/haresources：$ primary_directorname lvs-kiss x.y.183.217

上記のサービスのlvs-kiss-configuration-snippet：

<VirtualServer idm-abn:12405>
  ServiceType       tcp
  Scheduler         wrr
  DynamicScheduler    0
  Persistance         7200
  QueueSize           2
  Fuzz              0.1
  <RealServer rs1-lvs:12405>
    PacketForwardingMethod  gatewaying
    Test ping -c 1 -nq -W 1 rs1-lvs >/dev/null
    RunOnFailure   "/sbin/ipvsadm -d -t idm-abn:12405 -r rs1-lvs"
    RunOnRecovery   "/sbin/ipvsadm -a -t idm-abn:12405 -r rs1-lvs"
  </RealServer>
  <RealServer rs2-lvs:12405>
    PacketForwardingMethod  gatewaying
    Test ping -c 1 -nq -W 1 rs2-lvs >/dev/null
    RunOnFailure   "/sbin/ipvsadm -d -t idm-abn:12405 -r rs2-lvs"
    RunOnRecovery   "/sbin/ipvsadm -a -t idm-abn:12405 -r rs2-lvs"
  </RealServer>
</VirtualServer>

idm-abn、rs1、およびrs2は、/ etc/hostsを介して解決されます。

サービスについて：

これはsoa-web-serviceです。

エラーを再現する方法：

クライアントから、3秒に1回の呼び出しの間隔で、Webサービスへの一定の呼び出しを実行します。ときどき、ダイレクタからクライアントへの接続がリセットされます。

興味深い：これはn x 100回+1回の試行で発生します-興味深いのは1回です。

問題を追跡するために私たちがしたこと：

  • チェック済み/ proc/sys/net/ipv4/vs：すべての値がデフォルトに設定されているため、drop_packetが配置されていません（= 0）
  • クライアントのtcpdump、ディレクターのフロント/ abn、ディレクトリのバックエンド/ lvs、実サーバーのlvsとabn

このtcpdumpでは、クライアントからの要求が表示され、ディレクターによる接続リセットによって応答されます。パケットはLVS経由で転送されませんでした。

この問題をさらに追跡する方法についてのアイデアを歓迎します。問題を掘り下げるための情報が不明確/欠落している場合は、お問い合わせください。

xencentos5lvs
2
Nils

LVS-DRダイレクタにステートフルiptablesルールはありますか？ご覧のとおり、ポート12405を使用しているので、次のようなルールがある場合：

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 12405 -j ACCEPT

LVS-DR実サーバーがクライアント（ディレクターではなく）からの要求に応答している場合、ディレクターはそれらの接続を接続追跡テーブルに追加せず、FINパケットはディレクターのiptablesで検出されません。ルールでESTABLISHED,RELATED。ポート12405ではNEW（SYN）パケットのみを許可するため、FINはブロックされます。負荷分散サービスには、LVS-DRダイレクタでステートレスファイアウォールを使用する必要があります。

iptables -A INPUT -m tcp -p tcp --dport 12405 -j ACCEPT
5
Strahinja Kustudic