Mailing List Archive: (no subject)

(no subject)

jgmercado at micro-d

Feb 28, 2002, 10:57 PM

Post #1 of 8 (4378 views)

Permalink

(no subject) [ In reply to ]

greg55 at ozemail

May 15, 2002, 4:34 PM

Post #2 of 8 (4306 views)

Permalink

Dear all,

We've been looking at possibly using mod_backhand to allow us to run multiple Apache boxes side-by-side (on Solaris) in front of an app server. Failover, not specifically improved performance is our major concern here.

The reason we want to run the Apache boxes side by side is so that one or more can be taken down for maintenance, etc, while still offering some level of service on a 24x7 basis.

What are our options for setting this up to provide the best level of failover?

e.g. Can DNS round-robin be setup in front of the mod_backhand webservers so that a downed server can be detected and taken out of the round-robin'ing?

Thanks very much,
Greg.

This message was sent through MyMail http://www.mymail.com.au

(no subject) [ In reply to ]

yairamir at cnds

May 15, 2002, 5:26 PM

Post #3 of 8 (4318 views)

Permalink

Hi,

mod_backhand does not deal with failover. Sure, if one of the boxes is down,
mod_backhand will detect it and will not balance to it, but accesses that
arrive directly at this box will not be answered.

You might want to look at Wackamole which is our solution for NxWay fail over for
IP addresses. It is a component of our Backhand clustering project and can
be found in the same web site http://www.backhand.org

Wackamole bases its IP allocation decisions on the agreed-upon membership
provided by the Spread Toolkit http://www.spread.org

Enjoy,

:) Yair. http://www.cs.jhu.edu/~yairamir

greg55@ozemail.com.au wrote:

> Dear all,
>
> We've been looking at possibly using mod_backhand to allow us to run multiple Apache boxes side-by-side (on Solaris) in front of an app server. Failover, not specifically improved performance is our major concern here.
>
> The reason we want to run the Apache boxes side by side is so that one or more can be taken down for maintenance, etc, while still offering some level of service on a 24x7 basis.
>
> What are our options for setting this up to provide the best level of failover?
>
> e.g. Can DNS round-robin be setup in front of the mod_backhand webservers so that a downed server can be detected and taken out of the round-robin'ing?
>
> Thanks very much,
> Greg.
>
>
> This message was sent through MyMail http://www.mymail.com.au
>
>
>
> _______________________________________________
> backhand-users mailing list
> backhand-users@lists.backhand.org
> http://lists.backhand.org/mailman/listinfo/backhand-users
>
>
>

(no subject) [ In reply to ]

nCornejo at elsendero

May 30, 2002, 11:33 PM

Post #4 of 8 (4293 views)

Permalink

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C2087D.E8E32650
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_000A_01C2087D.E8E32650
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV> </DIV></BODY></HTML>

------=_NextPart_000_000A_01C2087D.E8E32650--

(no subject) [ In reply to ]

indra.kusuma at 1rstWAP

Jun 11, 2002, 5:37 AM

Post #5 of 8 (4283 views)

Permalink

Dear *,

we have this messeges on every backhand server :

TCP: Treason uncloaked! Peer 212.152.91.158:23802/80 shrinks window
3102037669:3102038205. Repaired.
TCP: Treason uncloaked! Peer 212.152.91.158:23802/80 shrinks window
3102037669:3102038205. Repaired.
TCP: Treason uncloaked! Peer 212.152.91.158:23802/80 shrinks window
3102037669:3102038205. Repaired.
TCP: Treason uncloaked! Peer 212.152.91.158:23802/80 shrinks window
3102037669:3102038205. Repaired.
TCP: Treason uncloaked! Peer 212.152.91.158:23802/80 shrinks window
3102037669:3102038205. Repaired.
TCP: Treason uncloaked! Peer 212.152.91.158:23802/80 shrinks window
3102037669:3102038205. Repaired.
TCP: Treason uncloaked! Peer 212.152.91.158:23802/80 shrinks window
3102037669:3102038205. Repaired.
TCP: Treason uncloaked! Peer 212.152.91.158:23802/80 shrinks window
3102037669:3102038205. Repaired.
__alloc_pages: 3-order allocation failed.
__alloc_pages: 3-order allocation failed.

Any clue about this ?

Indra Kusuma

(no subject) [ In reply to ]

marcoberetta27 at hotmail

Oct 18, 2002, 5:43 AM

Post #6 of 8 (4290 views)

Permalink

Hi,
I have 2 linux pc each of which runs an Apache web-server and a Resin
application server. I want to balance the 2 web-servers.
I have already configured Apache httpd.conf files following the
documentation on site, but I have a problem: when a request for a dynamic
page (.jsp) comes, module backhand doesn't work and only an application
server responds, otherwise if a request for a static page(.html) comes
module backhand works succesfully.
Can anyone help me?
Thank you

_________________________________________________________________
Vuoi chattare e scambiare canzoni e foto con gli amici?
http://messenger.msn.it

(no subject) [ In reply to ]

gene at poh

Jul 30, 2003, 7:56 PM

Post #7 of 8 (4287 views)

Permalink

How do I keep the diagnostic handler from giving out the versions of apache,
ssl, etc. Or minimally limit who can access the diagnostic handler page?

Thanks
Gene Dellinger
POH

(no subject) [ In reply to ]

jesus at omniti

Jul 31, 2003, 8:44 AM

Post #8 of 8 (4307 views)

Permalink

Gene Dellinger wrote:
> How do I keep the diagnostic handler from giving out the versions of apache,
> ssl, etc. Or minimally limit who can access the diagnostic handler page?

(1) edit the code

(2) put an Allow directive in the Location handler. See the Apache manual for
the proper syntax for "Allow" and "Deny". It is trivial to limit access to
that "diagnostic page" to your IP block or user/passwords or a combination.

--
Theo Schlossnagle
Principal Consultant
OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
Phone: +1 410 872 4910 x201 Fax: +1 410 872 4911
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7