diff options
| author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
|---|---|---|
| committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 18:20:36 -0400 |
| commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
| tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /net/ipv4/ipvs/Kconfig | |
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Diffstat (limited to 'net/ipv4/ipvs/Kconfig')
| -rw-r--r-- | net/ipv4/ipvs/Kconfig | 244 |
1 files changed, 244 insertions, 0 deletions
diff --git a/net/ipv4/ipvs/Kconfig b/net/ipv4/ipvs/Kconfig new file mode 100644 index 0000000000..63a82b4b64 --- /dev/null +++ b/net/ipv4/ipvs/Kconfig | |||
| @@ -0,0 +1,244 @@ | |||
| 1 | # | ||
| 2 | # IP Virtual Server configuration | ||
| 3 | # | ||
| 4 | menu "IP: Virtual Server Configuration" | ||
| 5 | depends on INET && NETFILTER | ||
| 6 | |||
| 7 | config IP_VS | ||
| 8 | tristate "IP virtual server support (EXPERIMENTAL)" | ||
| 9 | depends on INET && NETFILTER | ||
| 10 | ---help--- | ||
| 11 | IP Virtual Server support will let you build a high-performance | ||
| 12 | virtual server based on cluster of two or more real servers. This | ||
| 13 | option must be enabled for at least one of the clustered computers | ||
| 14 | that will take care of intercepting incoming connections to a | ||
| 15 | single IP address and scheduling them to real servers. | ||
| 16 | |||
| 17 | Three request dispatching techniques are implemented, they are | ||
| 18 | virtual server via NAT, virtual server via tunneling and virtual | ||
| 19 | server via direct routing. The several scheduling algorithms can | ||
| 20 | be used to choose which server the connection is directed to, | ||
| 21 | thus load balancing can be achieved among the servers. For more | ||
| 22 | information and its administration program, please visit the | ||
| 23 | following URL: <http://www.linuxvirtualserver.org/>. | ||
| 24 | |||
| 25 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 26 | module, choose M here. If unsure, say N. | ||
| 27 | |||
| 28 | config IP_VS_DEBUG | ||
| 29 | bool "IP virtual server debugging" | ||
| 30 | depends on IP_VS | ||
| 31 | ---help--- | ||
| 32 | Say Y here if you want to get additional messages useful in | ||
| 33 | debugging the IP virtual server code. You can change the debug | ||
| 34 | level in /proc/sys/net/ipv4/vs/debug_level | ||
| 35 | |||
| 36 | config IP_VS_TAB_BITS | ||
| 37 | int "IPVS connection table size (the Nth power of 2)" | ||
| 38 | depends on IP_VS | ||
| 39 | default "12" | ||
| 40 | ---help--- | ||
| 41 | The IPVS connection hash table uses the chaining scheme to handle | ||
| 42 | hash collisions. Using a big IPVS connection hash table will greatly | ||
| 43 | reduce conflicts when there are hundreds of thousands of connections | ||
| 44 | in the hash table. | ||
| 45 | |||
| 46 | Note the table size must be power of 2. The table size will be the | ||
| 47 | value of 2 to the your input number power. The number to choose is | ||
| 48 | from 8 to 20, the default number is 12, which means the table size | ||
| 49 | is 4096. Don't input the number too small, otherwise you will lose | ||
| 50 | performance on it. You can adapt the table size yourself, according | ||
| 51 | to your virtual server application. It is good to set the table size | ||
| 52 | not far less than the number of connections per second multiplying | ||
| 53 | average lasting time of connection in the table. For example, your | ||
| 54 | virtual server gets 200 connections per second, the connection lasts | ||
| 55 | for 200 seconds in average in the connection table, the table size | ||
| 56 | should be not far less than 200x200, it is good to set the table | ||
| 57 | size 32768 (2**15). | ||
| 58 | |||
| 59 | Another note that each connection occupies 128 bytes effectively and | ||
| 60 | each hash entry uses 8 bytes, so you can estimate how much memory is | ||
| 61 | needed for your box. | ||
| 62 | |||
| 63 | comment "IPVS transport protocol load balancing support" | ||
| 64 | depends on IP_VS | ||
| 65 | |||
| 66 | config IP_VS_PROTO_TCP | ||
| 67 | bool "TCP load balancing support" | ||
| 68 | depends on IP_VS | ||
| 69 | ---help--- | ||
| 70 | This option enables support for load balancing TCP transport | ||
| 71 | protocol. Say Y if unsure. | ||
| 72 | |||
| 73 | config IP_VS_PROTO_UDP | ||
| 74 | bool "UDP load balancing support" | ||
| 75 | depends on IP_VS | ||
| 76 | ---help--- | ||
| 77 | This option enables support for load balancing UDP transport | ||
| 78 | protocol. Say Y if unsure. | ||
| 79 | |||
| 80 | config IP_VS_PROTO_ESP | ||
| 81 | bool "ESP load balancing support" | ||
| 82 | depends on IP_VS | ||
| 83 | ---help--- | ||
| 84 | This option enables support for load balancing ESP (Encapsultion | ||
| 85 | Security Payload) transport protocol. Say Y if unsure. | ||
| 86 | |||
| 87 | config IP_VS_PROTO_AH | ||
| 88 | bool "AH load balancing support" | ||
| 89 | depends on IP_VS | ||
| 90 | ---help--- | ||
| 91 | This option enables support for load balancing AH (Authentication | ||
| 92 | Header) transport protocol. Say Y if unsure. | ||
| 93 | |||
| 94 | comment "IPVS scheduler" | ||
| 95 | depends on IP_VS | ||
| 96 | |||
| 97 | config IP_VS_RR | ||
| 98 | tristate "round-robin scheduling" | ||
| 99 | depends on IP_VS | ||
| 100 | ---help--- | ||
| 101 | The robin-robin scheduling algorithm simply directs network | ||
| 102 | connections to different real servers in a round-robin manner. | ||
| 103 | |||
| 104 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 105 | module, choose M here. If unsure, say N. | ||
| 106 | |||
| 107 | config IP_VS_WRR | ||
| 108 | tristate "weighted round-robin scheduling" | ||
| 109 | depends on IP_VS | ||
| 110 | ---help--- | ||
| 111 | The weighted robin-robin scheduling algorithm directs network | ||
| 112 | connections to different real servers based on server weights | ||
| 113 | in a round-robin manner. Servers with higher weights receive | ||
| 114 | new connections first than those with less weights, and servers | ||
| 115 | with higher weights get more connections than those with less | ||
| 116 | weights and servers with equal weights get equal connections. | ||
| 117 | |||
| 118 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 119 | module, choose M here. If unsure, say N. | ||
| 120 | |||
| 121 | config IP_VS_LC | ||
| 122 | tristate "least-connection scheduling" | ||
| 123 | depends on IP_VS | ||
| 124 | ---help--- | ||
| 125 | The least-connection scheduling algorithm directs network | ||
| 126 | connections to the server with the least number of active | ||
| 127 | connections. | ||
| 128 | |||
| 129 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 130 | module, choose M here. If unsure, say N. | ||
| 131 | |||
| 132 | config IP_VS_WLC | ||
| 133 | tristate "weighted least-connection scheduling" | ||
| 134 | depends on IP_VS | ||
| 135 | ---help--- | ||
| 136 | The weighted least-connection scheduling algorithm directs network | ||
| 137 | connections to the server with the least active connections | ||
| 138 | normalized by the server weight. | ||
| 139 | |||
| 140 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 141 | module, choose M here. If unsure, say N. | ||
| 142 | |||
| 143 | config IP_VS_LBLC | ||
| 144 | tristate "locality-based least-connection scheduling" | ||
| 145 | depends on IP_VS | ||
| 146 | ---help--- | ||
| 147 | The locality-based least-connection scheduling algorithm is for | ||
| 148 | destination IP load balancing. It is usually used in cache cluster. | ||
| 149 | This algorithm usually directs packet destined for an IP address to | ||
| 150 | its server if the server is alive and under load. If the server is | ||
| 151 | overloaded (its active connection numbers is larger than its weight) | ||
| 152 | and there is a server in its half load, then allocate the weighted | ||
| 153 | least-connection server to this IP address. | ||
| 154 | |||
| 155 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 156 | module, choose M here. If unsure, say N. | ||
| 157 | |||
| 158 | config IP_VS_LBLCR | ||
| 159 | tristate "locality-based least-connection with replication scheduling" | ||
| 160 | depends on IP_VS | ||
| 161 | ---help--- | ||
| 162 | The locality-based least-connection with replication scheduling | ||
| 163 | algorithm is also for destination IP load balancing. It is | ||
| 164 | usually used in cache cluster. It differs from the LBLC scheduling | ||
| 165 | as follows: the load balancer maintains mappings from a target | ||
| 166 | to a set of server nodes that can serve the target. Requests for | ||
| 167 | a target are assigned to the least-connection node in the target's | ||
| 168 | server set. If all the node in the server set are over loaded, | ||
| 169 | it picks up a least-connection node in the cluster and adds it | ||
| 170 | in the sever set for the target. If the server set has not been | ||
| 171 | modified for the specified time, the most loaded node is removed | ||
| 172 | from the server set, in order to avoid high degree of replication. | ||
| 173 | |||
| 174 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 175 | module, choose M here. If unsure, say N. | ||
| 176 | |||
| 177 | config IP_VS_DH | ||
| 178 | tristate "destination hashing scheduling" | ||
| 179 | depends on IP_VS | ||
| 180 | ---help--- | ||
| 181 | The destination hashing scheduling algorithm assigns network | ||
| 182 | connections to the servers through looking up a statically assigned | ||
| 183 | hash table by their destination IP addresses. | ||
| 184 | |||
| 185 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 186 | module, choose M here. If unsure, say N. | ||
| 187 | |||
| 188 | config IP_VS_SH | ||
| 189 | tristate "source hashing scheduling" | ||
| 190 | depends on IP_VS | ||
| 191 | ---help--- | ||
| 192 | The source hashing scheduling algorithm assigns network | ||
| 193 | connections to the servers through looking up a statically assigned | ||
| 194 | hash table by their source IP addresses. | ||
| 195 | |||
| 196 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 197 | module, choose M here. If unsure, say N. | ||
| 198 | |||
| 199 | config IP_VS_SED | ||
| 200 | tristate "shortest expected delay scheduling" | ||
| 201 | depends on IP_VS | ||
| 202 | ---help--- | ||
| 203 | The shortest expected delay scheduling algorithm assigns network | ||
| 204 | connections to the server with the shortest expected delay. The | ||
| 205 | expected delay that the job will experience is (Ci + 1) / Ui if | ||
| 206 | sent to the ith server, in which Ci is the number of connections | ||
| 207 | on the the ith server and Ui is the fixed service rate (weight) | ||
| 208 | of the ith server. | ||
| 209 | |||
| 210 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 211 | module, choose M here. If unsure, say N. | ||
| 212 | |||
| 213 | config IP_VS_NQ | ||
| 214 | tristate "never queue scheduling" | ||
| 215 | depends on IP_VS | ||
| 216 | ---help--- | ||
| 217 | The never queue scheduling algorithm adopts a two-speed model. | ||
| 218 | When there is an idle server available, the job will be sent to | ||
| 219 | the idle server, instead of waiting for a fast one. When there | ||
| 220 | is no idle server available, the job will be sent to the server | ||
| 221 | that minimize its expected delay (The Shortest Expected Delay | ||
| 222 | scheduling algorithm). | ||
| 223 | |||
| 224 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 225 | module, choose M here. If unsure, say N. | ||
| 226 | |||
| 227 | comment 'IPVS application helper' | ||
| 228 | depends on IP_VS | ||
| 229 | |||
| 230 | config IP_VS_FTP | ||
| 231 | tristate "FTP protocol helper" | ||
| 232 | depends on IP_VS && IP_VS_PROTO_TCP | ||
| 233 | ---help--- | ||
| 234 | FTP is a protocol that transfers IP address and/or port number in | ||
| 235 | the payload. In the virtual server via Network Address Translation, | ||
| 236 | the IP address and port number of real servers cannot be sent to | ||
| 237 | clients in ftp connections directly, so FTP protocol helper is | ||
| 238 | required for tracking the connection and mangling it back to that of | ||
| 239 | virtual service. | ||
| 240 | |||
| 241 | If you want to compile it in kernel, say Y. To compile it as a | ||
| 242 | module, choose M here. If unsure, say N. | ||
| 243 | |||
| 244 | endmenu | ||
