[TriLUG] Re: RHEL. LVS, piranha

Jon Carnes jonc at nc.rr.com
Mon Dec 8 16:14:58 EST 2003


One item that may be impeding you...

You can't test from a machine in the LVS unless you create a secondary
route that goes through another firewall (other than the front end of
the LVS) which points to the Director's external address.  Your interior
machines are NATted for outbound and your inbound traffic to the LVS is
reverse NATted and the two things just don't work at the same time on
the same Firewall.

Hope that is all that wrong.

Jon

On Mon, 2003-12-08 at 14:31, Ryan Leathers wrote:
> 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




More information about the TriLUG mailing list