[TriLUG] Re: RHEL. LVS, piranha

Ryan Leathers ryan.leathers at globalknowledge.com
Mon Dec 8 14:31:07 EST 2003


If Im not becoming a pest yet, a troubleshooting question...

I have decided to configure by hand and borrow (heavily) from Jon's
backup director scripts.  However, I still have not been able to get the
basics working.

Here is what I have:
Pulse is working
The director and real server can ping one anothers private addresses
The real server uses the directors private address as its gateway
The real server can ping the directors virtual (floating) ip
The real server's httpd on port 80 can be seen by local hosts in the
private network

The output of ipvsadm is:
IP Virtual Server version 0.8.1 (size=65536)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port             Forward Weight ActiveConn InActConn
TCP  216.134.205.210:http rr
  -> 172.16.240.202:http            Masq    1      0          0


Given all this, it seems that things should be working but I can not get
a page to render and dont see the connection count increment.  Any
ideas?

-Ryan


On Fri, 2003-12-05 at 17:01, Jon Carnes wrote:
> On Fri, 2003-12-05 at 12:35, Lance A. Brown wrote:
> > Ryan Leathers wrote:
> > > I'd love to see what you've done, but I want to stay with piranha if I
> > > can.  The only reason is that I want this to be easily supported by
> > > somebody else, so "the less custom stuff the better" has been my goal.
> > > 
> > > One of the things that I've been grumbling about is that the RHEL 2.1
> > > docs say that lvs-nat is the only supported option.  I want to use the
> > > lvs-dr option.  I get the feeling that piranha is the limiting factor. 
> > > I really just need this to work reliably.  I could care less about
> > > having a configuration gui so its kind of frustrating right now.
> > 
> > I've had good luck using UltraMonkey (www.ultramonkey.org) with Red Hat 
> > 9 to implement a webserver farm using lvs-dr.  The farm has two 
> > directors (primary and secondary using heartbeat) and two web servers 
> > (so far).  It took me a bit to wrap my head around the ultramonkey 
> > documentation vs. the config files but once I realized what was going 
> > on, setup was easy.
> > 
> > --[Lance]
> 
> I have to second Lance's endorsement of Ultra-Monkey.  In an LVS
> situation Ultra-Monkey is good stuff!
> 
> Here is a set of "actual" scripts, in use at a client for running a
> Master/Slave Fail-over pair for a SquidGuard installation.  The slave
> kicks in and takes over if the master goes off-line.  If the master
> comes back on-line then the slave backs down again.
> 
> http://www.trilug.org/~jonc/Failover_scripts
> 
> All these scripts run on the Slave:
>   Server_Sync  - Keeps the Slave up-to-date with the Master.
>                  Runs once a night.
> 
>   conf_files   - The files and directories to be updated nightly
>                  by Server_Sync (Not a script... just a list)
> 
>   Server_check - Runs every minute out of cron to check on 
>                  the status of the Master server. Initiates
>                  the Failover or the Return scripts
> 
>   Server_Failover - Script to move the slave onto the network
>                  as the master, and startup any necessary services
> 
>   Server_Return - script to move the slave back off the network
>                  and into stand-by mode.
> 
> I hope you find them entertaining!
> 
> The interesting thing about this setup is that the Master can be totally
> ignorant of the Slave. The Slave server can also be doing other tasks
> for the company while in standby mode, and can actually continue those
> tasks as well as taking on the new tasks of the Failed Master (whenever
> that happens).
> 
> Jon Carnes
-- 
Ryan Leathers <ryan.leathers at globalknowledge.com>
Global Knowledge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://www.trilug.org/pipermail/trilug/attachments/20031208/df056126/attachment.pgp>


More information about the TriLUG mailing list