Date: Mon, 10 Dec 2001 09:57:08 -0600 From: "Dustin Puryear" <dpuryear@usa.net> To: "Gabriel Ambuehl" <gabriel_ambuehl@buz.ch>, <freebsd-isp@freebsd.org> Subject: RE: Re[6]: Using DNAT and DNS round-robin Message-ID: <PGECILGGNJGDPJKLFEMICELPCIAA.dpuryear@usa.net> In-Reply-To: <48508292666.20011210105413@buz.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hello Dustin, > > Monday, December 10, 2001, 6:41:56 AM, you wrote: > > Gabriel, after rereading your message I am now definately curious > > how you go about this when using multiple webservers for both IP- > > and name-based virtual hosting. > > Normal hosting consumers we simply setup as name based, those who pay > for SSL we of course give their own IP but since none of these needs > load balancing (and load balancing IS a major PITA since you need > bullet proof filesystem synchronization for it which I currently > can't > see how it should be achieved on FreeBSD), we put all on only one > server. To protect us against server problems, we mirror the servers > every few hours to a twin in order to have a fall back option. Our situation is a bit different as my client is not a web hosting provider. Rather, they have their own web services that they will be offering to existing customers. Since this is a high-load application, we want to be able to spread the load across n servers. Also, to ensure best performance I don't want to assign site A to server 1, site B to server 2, site C to server 1, and so on. Rather, I would like to load-share (load-balance later on) across all servers for any client. I guess that is where the initial confusion came from. In order for each webserver to offer the same IP-based virtual hosts as the other n-1 webservers, it appears that I need to setup the same IP alias on each webserver, unless I am missing something. Obviously, that won't work. That is one reason why I was looking at Squid. I may be able to pressure the client into using only named-based virtual hosting, which would clear this up. However, this is something I would like to know how to solve, and I have a bad feeling it would only be a temporary fix anyway. I am surprised this problem isn't more common. I mean, someone out there must be trying to spread several IP-based virtual hosts across n servers. > > Okay, so I setup my firewall to route any packets destined > > for network xyz to my internal web servers. These web servers may > > be using IP- or name-based virtual hosting. Now how do I configure > > the interfaces on the internal web servers? > > Simply give it the IPs you want them to respond to. But then I hit the problem with n webservers all configured to respond to the same IPs. > > Since each web server needs to be able to serve any of the > > websites, how do I handle each web server needing to have an IP > > alias for one of our IP-based > > How do you go about providing all the data to all servers? I'd very > much like to have a real time filesystem replication facility since > then I could go for a setup like you want... It's easy with data that > you control, since then you can store all volatile data in SQL db, > but > with hosting consumers, that's obviously not possible. Well, we are one of those "we control all data" types. :) > > virtual host? I think that is what is confusing me. If it was just > > named-based virtual hosting there wouldn't be an issue in my mind. > > You simply can't have the same IP based virtual host on two machines. > The online thing that can be done there is round robin NAT but for > reasons pointed out above, that's major PITA. That is becoming rather obvious to me at this point. Regards, Dustin --- Dustin Puryear <dpuryear@usa.net> Information Systems Consultant http://members.telocity.com/~dpuryear In the beginning the Universe was created. This has been widely regarded as a bad move. - Douglas Adams To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?PGECILGGNJGDPJKLFEMICELPCIAA.dpuryear>