| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Robin H. Johnson wrote: |
| 5 |
> The primary Bugzilla webserver is now back in operation. |
| 6 |
> |
| 7 |
> Additionally, for the moment, I've re-enabled the load-balancing, but |
| 8 |
> note that it comes with a warning... |
| 9 |
> Load balanced bugzilla webservers: |
| 10 |
> http://bugs-web-lb.gentoo.org/ |
| 11 |
> (HTTPS supported as well, but the SSL certificate won't match). |
| 12 |
> |
| 13 |
> Visiting either specific side of the webserver nodes: |
| 14 |
> http://bugs-web1.gentoo.org/ |
| 15 |
> http://bugs-web2.gentoo.org/ |
| 16 |
> (The web node you're on is listed on the frontpage only). |
| 17 |
> |
| 18 |
> Caveat: |
| 19 |
> - Why can't we just always use the load-balancer? |
| 20 |
> Unfortunately bugzilla writes a number of files to the local disk and |
| 21 |
> then gives you a URL to them. If the file was written to disk on web1, |
| 22 |
> but your request was delivered to web2, then you would get a 404 error. |
| 23 |
|
| 24 |
Robbat, would persistency on loadbalancer level solve this problem ? |
| 25 |
In that case a tcp-connect that has been build stays with that |
| 26 |
real-server instance in the loadbalancer, provided that data from the |
| 27 |
same ip is coming in below a specified timeout. |
| 28 |
|
| 29 |
We've used this in the past when we still used disk-based sessions in |
| 30 |
our webapp. It works well, but can create hotspots in your webfarm if a |
| 31 |
large percentage of your userbase is behind a single NATed gateway. |
| 32 |
|
| 33 |
It would also limit your attacker to a single host. |
| 34 |
|
| 35 |
Ramon |
| 36 |
-----BEGIN PGP SIGNATURE----- |
| 37 |
Version: GnuPG v1.4.8 (Darwin) |
| 38 |
|
| 39 |
iEYEARECAAYFAknQnNoACgkQwiVM6CtDHQ1zwgCfZfEXwjZ9a0y7mHjq7A5MAxTo |
| 40 |
HPIAn17SCBu0M71j6UBH8uW+7bVpMUnD |
| 41 |
=gzHX |
| 42 |
-----END PGP SIGNATURE----- |
Archives