-
Notifications
You must be signed in to change notification settings - Fork 3
Expand file tree
/
Copy pathREADME
More file actions
173 lines (136 loc) · 6.42 KB
/
Copy pathREADME
File metadata and controls
173 lines (136 loc) · 6.42 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
= Module HaProxy
This module manages installation and configuration of HaProxy. You can use the module in various mode.
== Use of defines haproxy::cluster_balance and haproxy::balanced
The easiest way to use this module is to balance a whole cluster. Balanced cluster's machines will export their configuration, balancer will import these resources.
Suppose to have this scenario:
* cluster foo is a cluster composed by foo01 and foo02.
* cluster bar is a active/passive HA balancer system.
We want to balance every services on foo through bar. Except for http we will use a active/passive balancement method, we suppose that foo01 is the active node, foo02 (and every other machine in cluster), will be the backup.
Cluster_balance and balanced defines don't manage http balancement, to balance http service we'll use http_balance and http_balanced defines that works in the same way of cluster_balance and balanced defines.
node clusterfoo {
haproxy::balanced_http {'bar':
balanced_interface => 'ethX',
}
haproxy::balanced {'bar':
balanced_interface => ethX,
active_node => 'foo01'
}
}
node foo01 inherits clusterfoo {}
node foo02 inherits clusterfoo {}
These resources will export haproxy configuration fragments relative to node foo01 and foo02 for each balanced service. In this example we suppose that foo01 and foo02 have their public address (or private, if you want to balance on backplane addesses) on ethX interface. foo01 is the active node.
On balancer's side:
node clusterbar {
$vip = 'x.x.x.x' #(it can be an array of addresses)
haproxy::http_balance {'clusterfoo_http':
bind_addresses => $vip,
}
haproxy::cluster_balance {'foo':
vip => $vip,
local_interface => 'ethX',
}
}
Note the used resource names. We put balanced cluster name. This is a convention. We specify also a <local_interface> parameter in cluster_balance define. This parameter identify interface used to bind local services on the balancer servers. For example: while bar01 and bar02 balance ssh service, bar01 and bar02 also need to have their ssh service reachable. Address present in ethX interface will be used to bind local ssh service.
== Balance a single service
In the same way of cluster_balance and balanced defines, we can balance a single service. We can use various define on backend's side:
* balanced_ftp
* balanced_http
* balanced_imap
* balanced_imaps
* balanced_ispconfig
* balanced_nrpe
* balanced_pop
* balanced_pops
* balanced_smtp
* balanced_ssh
And the relative define on balancer's side:
* ftp_balance
* generic_tcp_balance
* http_balance
* nrpe_balance
* smtp_balance
* ssh_balance
For example, if we want to balance only ssh service.
On backend side:
node clusterfoo {
balanced_ssh { 'bar':
balanced_interface => 'ethX',
active_node => 'foo01'
}
}
on balancer side:
node clusterbar {
ssh_balance { 'clusterfoo_ssh':
local_ip => 'x.x.x.x',
bind_addresses => $vip
}
}
Please note that ssh_balance resource name is again composed by cluster${balanced_cluster_name}_${service_name}
== Use of generic_tcp_balance
In the previously example note that on balancer side don't exists a define for every service but exists a define called generic_tcp_balance. This define is used on balancer side to balance a generic service, for example pop.
We suppose that we want to balance pop service. On backend side:
node clusterfoo {
balanced_pop { 'bar':
balanced_interface => 'ethX',
active_node => 'foo01'
}
}
On balancer side we use generic_tcp_balance:
node clusterbar {
generic_tcp_balance { 'clusterfoo_pop':
bind_addresses => $vip,
port => '110'
}
}
Note that generic_tcp_balance define's name is again in the form cluster${balanced_cluster_name}_${service_name}
== Configure only balancer's node, without exported resources
In all above examples we export haproxy backends configurations through exported resource using clustername and servicename as conventions to tag exported resources and to retrieve it. If we want to have a more complex balancer configuration we can use a series of defines used to configure only the balancer nodes.
We suppose that we want to balance http for cluster foo
=== Step 1: create a backend:
haproxy::backend {'http':
options => [ 'httpclose' , 'forwardfor' ],
mode => 'http',
}
see backend define documentation for parameter's explaination
=== Step 2: add server to above created backed
haproxy::backend::server {'foo01':
backend_name => 'http',
bind => 'x.x.x.x:80',
}
haproxy::backend::server {'foo02':
backend_name => 'http',
bind => 'y.y.y.y:80',
}
Please note that backend_name parameter is the name of backend resource prevoiusly defined.
=== Step 3: optionaly add appsession or header (see haproxy official documentation for more explainations)
haproxy::backend::add_header {'X-HaProxy-Id':
request => true, #(if response => true is used, header will be added on respose)
value => $hostname,
backend_name => 'http',
}
haproxy::backend::appsession {'JSESSIONID':
backend_name => 'http',
length => 52,
timeout => '30m',
options => [ 'request-learn', 'prefix' ],
}
Please note that in above define backend_name parameter is always the name of backend resource defined in step 1
=== Step 4: create a frontend
haproxy::frontend { 'frontend_http':
bind => [ 'x.x.x.x':80' , 'y.y.y.y:80' ],
default_backend => 'http',
options => [ 'foo' , 'bar'],
mode => 'http'
}
Plese note that default_backend parameter is again the name of backend resource defined in step 1.
=== Use more compact code
We can configure balancer's node without exported resource also using ${service_name}_balance define. These define collect configuration exported by backend nodes, bu we can also set backend manually:
haproxy::http_balance {'http_balance':
bind_addresses => [ 'x.x.x.x' , 'y.y.y.y' ],
backends => { 'foo01' => {bind => 'z.z.z.z',},
'foo02' => {bind => 'k.k.k.k',},}
appsession => [ 'JSESSIONID' ],
cookie_capture => [ 'JSESSIONID=' ],
res_header_capture => [ 'X-Varnish-Id' , 'X-Backend-Id' ],
}
See http_balance documentation to see explaination of used parameters.