IPVS源代码分析-----persistent connection和fwmark

这篇是自己写的，yfydz的文章中没有对persistent 和 fwmark做分析。

persistent connetion和fwmark主要用于处理多连接的应用。主要参考http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.fwmark.html

首先persistent 和 fwmark是的两种解决方案。

persistent的意思在IPVS中是affinity，即相关的连接。fwmark的功能更强大。

persistence makes a client connect to the same realserver for different tcpip connections。 the client is recognised by its by CIP:dst_port

fwmark is a way of aggregating an arbitary collection of VIP:port services into one virtual service

28.1. LVS persistence

LVS persistence makes a client connect to the same realserver for different tcpip connections. The LVS persistant connection is at the layer 4 protocol level.

LVS persistence is rarely needed and has some pitfalls (as explained below). It's useful when state must be maintained on the realserver, e.g. for https key exchanges, where the session keys are held on the realserver and the client must always reconnect with that realserver to maintain the session.

LVS persistence has two consequences

• A client making a new tcpip connection, within the timeout period (usually 5-10mins), will be sent to the same realserver as on the previous connection. For LVS persistence, the client is recognised by its by CIP:dst_port。The new tcp connection will reset the timer. A connect request made past the timeout period will be treated as a new connection and will be assigned a realserver by the scheduler. The default timeout varies with LVS release, but is in the 300-600sec range.

  When implementing LVS persistence, there are problems in recognising a client as the same client returning for another connection. While the application can recognise a returning client by state information e.g. cookies (which we don't encourage, see below for better suggestions), at layer 4, where LVS operates, only the IPs and port numbers are available. For LVS persistence, the client is recognised by its IP (CIP) or in recent versions of ip_vs, by CIP:dst_port (i.e. by the CIP and the port being forwarded by the LVS). If only the CIP is used to schedule persistence, then the entries in the output of ipvsadm will be of the form VIP:0 (i.e. with port=0), otherwise the output of ipvsadm will be of the form VIP:port.

  Recognising the client is simple enough for machines on static IPs, but people on dial-up links

  • come up on a different IP for each dial-up session. If the phone line drops during a session the client will reappear with a different IP (but probably coming from the same class C network)
  • if they are coming through a proxy (like AOL), they will come from different IPs (again probably in the same class C network) for different tcipip connections, within a single session (i.e. requests for hits for a web page may come from several IPs). (for more info see persistence granularity).

  The solution to this is to set a netmask (e.g. /24) for persistence and to accept any IPs in this netmask as the same client. The downside is that if a significant fraction of your clients are from AOL, they will appear to be a single client and will all be beating on one realserver, while the other realservers are near idle.

  	Note
  	For regular http, you don't care how many different IP(s) the client uses to request its hits for a single webpage and you don't need persistence.

• When all ports (VIP:0) are scheduled to be persistent, then requests by a client for services on different ports (e.g.to VIP:telnet, to VIP:http) will go to the same realserver. This is useful when the client needs access to multiple ports to complete a session. Useful multi-port connections are

  • 20,21 for active ftp
  • 21 and a high port for passive ftp
  • port 80,443 for an e-commerce site

  A side effect is that once persistence is set for all ports, requests by the client to any port, not jus