Review haproxy SOP
Signed-off-by: Michal Konečný <mkonecny@redhat.com>
This commit is contained in:
parent
3fb039d94f
commit
d405e732a6
2 changed files with 23 additions and 27 deletions
|
@ -45,7 +45,7 @@
|
||||||
** xref:greenwave.adoc[Greenwave - SOP]
|
** xref:greenwave.adoc[Greenwave - SOP]
|
||||||
** xref:guestdisk.adoc[Guest Disk Resize - SOP]
|
** xref:guestdisk.adoc[Guest Disk Resize - SOP]
|
||||||
** xref:guestedit.adoc[Guest Editing - SOP]
|
** xref:guestedit.adoc[Guest Editing - SOP]
|
||||||
** xref:haproxy.adoc[haproxy - SOP in review ]
|
** xref:haproxy.adoc[Haproxy Infrastructure - SOP]
|
||||||
** xref:hotfix.adoc[hotfix - SOP in review ]
|
** xref:hotfix.adoc[hotfix - SOP in review ]
|
||||||
** xref:hotness.adoc[hotness - SOP in review ]
|
** xref:hotness.adoc[hotness - SOP in review ]
|
||||||
** xref:index.adoc[index - SOP in review ]
|
** xref:index.adoc[index - SOP in review ]
|
||||||
|
|
|
@ -5,18 +5,17 @@ at the http layer. It can do generic tcp balancing but it does
|
||||||
specialize in http balancing. Our proxy servers are still running apache
|
specialize in http balancing. Our proxy servers are still running apache
|
||||||
and that is what our users connect to. But instead of using
|
and that is what our users connect to. But instead of using
|
||||||
mod_proxy_balancer and ProxyPass balancer://, we do a ProxyPass to
|
mod_proxy_balancer and ProxyPass balancer://, we do a ProxyPass to
|
||||||
[45]http://localhost:10001/ or [46]http://localhost:10002/. haproxy must
|
http://localhost:10001/ or http://localhost:10002/. haproxy must
|
||||||
be told to listen to an individual port for each farm. All haproxy farms
|
be told to listen to an individual port for each farm. All haproxy farms
|
||||||
are listed in /etc/haproxy/haproxy.cfg.
|
are listed in /etc/haproxy/haproxy.cfg.
|
||||||
|
|
||||||
== Contents
|
== Contents
|
||||||
|
|
||||||
[arabic]
|
* <<_contact_information>>
|
||||||
. Contact Information
|
* <<_how_it_works>>
|
||||||
. How it works
|
* <<_configuration_example>>
|
||||||
. Configuration example
|
* <<_stats>>
|
||||||
. Stats
|
* <<_advanced_usage>>
|
||||||
. Advanced Usage
|
|
||||||
|
|
||||||
== Contact Information
|
== Contact Information
|
||||||
|
|
||||||
|
@ -45,7 +44,6 @@ request 1 goes to app1, request2 goes to app2, request 3 goes to app3
|
||||||
request 4 goes to app1, and the whole process repeats.
|
request 4 goes to app1, and the whole process repeats.
|
||||||
|
|
||||||
[WARNING]
|
[WARNING]
|
||||||
.Warning
|
|
||||||
====
|
====
|
||||||
These checks do add load to the app servers. As well as additional
|
These checks do add load to the app servers. As well as additional
|
||||||
connections. Be smart about which url you're checking as it gets checked
|
connections. Be smart about which url you're checking as it gets checked
|
||||||
|
@ -64,42 +62,40 @@ subtraction of specific nodes when we need them.:
|
||||||
....
|
....
|
||||||
listen fpo-wiki 0.0.0.0:10001
|
listen fpo-wiki 0.0.0.0:10001
|
||||||
balance roundrobin
|
balance roundrobin
|
||||||
server app1 app1.fedora.phx.redhat.com:80 check inter 2s rise 2 fall 5
|
server app1 app1.fedora.iad2.redhat.com:80 check inter 2s rise 2 fall 5
|
||||||
server app2 app2.fedora.phx.redhat.com:80 check inter 2s rise 2 fall 5
|
server app2 app2.fedora.iad2.redhat.com:80 check inter 2s rise 2 fall 5
|
||||||
server app4 app4.fedora.phx.redhat.com:80 backup check inter 2s rise 2 fall 5
|
server app4 app4.fedora.iad2.redhat.com:80 backup check inter 2s rise 2 fall 5
|
||||||
option httpchk GET /wiki/Infrastructure
|
option httpchk GET /wiki/Infrastructure
|
||||||
....
|
....
|
||||||
|
|
||||||
* The first line "listen ...." Says to create a farm called 'fpo-wiki'.
|
* The first line "listen ...." Says to create a farm called _fpo-wiki_.
|
||||||
Listening on all IP's on port 10001. fpo-wiki can be arbitrary but make
|
Listening on all IP's on port 10001. _fpo-wiki_ can be arbitrary but make
|
||||||
it something obvious. Aside from that the important bit is :10001.
|
it something obvious. Aside from that the important bit is :10001.
|
||||||
Always make sure that when creating a new farm, its listening on a
|
Always make sure that when creating a new farm, its listening on a
|
||||||
unique port. In Fedora's case we're starting at 10001, and moving up by
|
unique port. In Fedora's case we're starting at 10001, and moving up by
|
||||||
one. Just check the config file for the lowest open port above 10001.
|
one. Just check the config file for the lowest open port above 10001.
|
||||||
* The next line "balance roundrobin" says to use round robin balancing.
|
* The next line _balance roundrobin_ says to use round robin balancing.
|
||||||
* The server lines each add a new node to the balancer farm. In this
|
* The server lines each add a new node to the balancer farm. In this
|
||||||
case the wiki is being served from app1, app2 and app4. If the wiki is
|
case the wiki is being served from app1, app2 and app4. If the wiki is
|
||||||
available at [53]http://app1.fedora.phx.redhat.com/wiki/ Then this
|
available at http://app1.fedora.iad2.redhat.com/wiki/ Then this
|
||||||
config would be used in conjunction with "RewriteRule ^/wiki/(.*)
|
config would be used in conjunction with "RewriteRule ^/wiki/(.*)
|
||||||
[54]http://localhost:10001/wiki/$1 [P,L]".
|
http://localhost:10001/wiki/$1 [P,L]".
|
||||||
* 'server' means we're adding a new node to the farm
|
* _server_ means we're adding a new node to the farm
|
||||||
* {blank}
|
* _app1_ is the worker name, it is analagous to fpo-wiki but should::
|
||||||
+
|
|
||||||
'app1' is the worker name, it is analagous to fpo-wiki but should::
|
|
||||||
match shorthostname of the node to make it easy to follow.
|
match shorthostname of the node to make it easy to follow.
|
||||||
* 'app1.fedora.phx.redhat.com:80' is the hostname and port to be
|
* _app1.fedora.iad2.redhat.com:80_ is the hostname and port to be
|
||||||
contacted.
|
contacted.
|
||||||
* 'check' means to check via bottom line "option httpchk GET
|
* _check_ means to check via bottom line "option httpchk GET
|
||||||
/wiki/Infrastructure" which will use /wiki/Infrastructure to verify the
|
/wiki/Infrastructure" which will use /wiki/Infrastructure to verify the
|
||||||
wiki is working. If that URL fails, that entire node will be taken out
|
wiki is working. If that URL fails, that entire node will be taken out
|
||||||
of the farm mix.
|
of the farm mix.
|
||||||
* 'inter 2s' means to check every 2 seconds. 2s is the same as 2000 in
|
* _inter 2s_ means to check every 2 seconds. 2s is the same as 2000 in
|
||||||
this case.
|
this case.
|
||||||
* 'rise 2' means to not put this node back in the mix until it has had
|
* _rise 2_ means to not put this node back in the mix until it has had
|
||||||
two successful connections in a row. haproxy will continue to check
|
two successful connections in a row. haproxy will continue to check
|
||||||
every 2 seconds whether a node is up or down
|
every 2 seconds whether a node is up or down
|
||||||
* 'fall 5' means to take a node out of the farm after 5 failures.
|
* _fall 5_ means to take a node out of the farm after 5 failures.
|
||||||
* 'backup' You'll notice that app4 has a 'backup' option. We don't
|
* _backup_ You'll notice that app4 has a _backup_ option. We don't
|
||||||
actually use this for the wiki but do for other farms. It basically
|
actually use this for the wiki but do for other farms. It basically
|
||||||
means to continue checking and treat this node like any other node but
|
means to continue checking and treat this node like any other node but
|
||||||
don't send it any production traffic unless the other two nodes are
|
don't send it any production traffic unless the other two nodes are
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue