Thanks Jon, unfortunately its not that :( Hopefully it will be something else simple I've overlooked.
On Mon, 2003-12-08 at 16:14, Jon Carnes wrote: > 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 -- Ryan Leathers <[EMAIL PROTECTED]> Global Knowledge
signature.asc
Description: This is a digitally signed message part
-- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
