|
Hmm, I wouldn't call it a hack, or even a Walter's Hack. But option three
for that the other dude suggested sounds great, if you can use DR or TUN,
which in certain situations you can't. All our machines have internal
address space, not one machine is routable and without getting into it, we
can use DR or TUN because of silly layers of bullshit and lack of proper
equipment.
Plus I there the dns thing renders better performance. Using dynamic dns
scripts makes it pretty simple to maintain too. Also I thought if you're
using Horm's ipchains transparent proxy method of DR or TUN, you would not
have the local ip on the real servers? Since the arp arangements seem to
always be changing, I'd rather stick with something I know work and will
always work regardless of changes to arp or ipvs code and has no apartent
draw backs other then a little more management. I always choose
performance is stability over management drawbacks. If I use the dns
trick, it will work and continue to work without any worry.
Hi lou.
-jeremy
>
> hi, jeremy. say rock. say roll. say rock. say roll.
> anyway...
>
> yeah i thought about something like this, but damn that's messy. such a
> "hack". and when you're thinking about using this for thousands and
> thousands of sites in a production environment, i'd rather not go that
> route... =)
>
> might as well just use separate webserver configs if you're going to use
> separate nameserver configs. i guess it doesn't really matter.
> either/or. phft.
>
> adding them to /etc/hosts might be simpler than running named on each
> machine. but it's the same issue either way.
>
> less "hack"ish solution, perhaps? =)
>
> -tcl.
>
>
>
> On Thu, 13 Jan 2000, Jeremy Hansen wrote:
>
> >
> > Running small name servers on each individual real host that points dns to
> > the ip of each real server.
> >
> > For example, you have www.fuckstix.com
> > www.shittooth.com
> > www.devildog.com
> >
> > all pointing to the virtual address on your lvs machine. On the actual
> > real servers have name server that point
> >
> > www.fuckstix.com to 192.168.1.1(web1's ip address)
> > www.shittooth.com to 192.168.1.1(web1's ip address)
> > www.devildog.com to 192.168.1.1(web1's ip address)
> >
> > on web2
> >
> > www.fuckstix.com to 192.168.1.2(web2's ip address)
> > www.shittooth.com to 192.168.1.2(web2's ip address)
> > www.devildog.com to 192.168.1.2(web2's ip address)
> >
> > web3, etc.
> >
> > For your virtual host entry on your centralize /usr/webservers directory
> > directory structure :-), you should have something like this in there for
> > each real server:
> >
> > <VirtualHost web1.dicksticker.intra>
> > NameVirtualHost 10.1.1.11
> > ServerAdmin sysadmin@xxxxxxxxxxxxxxx
> > DocumentRoot /usr/webservers/httpd/htdocs
> > ServerName web1.dicksticker.intra
> > ErrorLog /usr/webservers/httpd/logs/error_log
> > CustomLog /usr/webservers/httpd/logs/access_log combined
> > ScriptAlias /cgi-bin/ /usr/webservers/httpd/cgi-bin/
> > </VirtualHost>
> >
> > <VirtualHost web2.dicksticker.intra>
> > NameVirtualHost 10.1.1.12
> > ServerAdmin sysadm@xxxxxxxxxxxxxxx
> > DocumentRoot /usr/webservers/httpd/htdocs
> > ServerName web2.dicksticker.intra
> > ErrorLog /usr/webservers/httpd/logs/error_log
> > CustomLog /usr/webservers/httpd/logs/access_log combined
> > ScriptAlias /cgi-bin/ /usr/webservers/httpd/cgi-bin/
> > </VirtualHost>
> >
> > <VirtualHost web3.dicksticker.intra>
> > NameVirtualHost 10.1.1.13
> > ServerAdmin sysadmin@xxxxxxxxxxxxxxx
> > DocumentRoot /usr/webservers/httpd/htdocs
> > ServerName web3.dicksticker.intra
> > ErrorLog /usr/webservers/httpd/logs/error_log
> > CustomLog /usr/webservers/httpd/logs/access_log combined
> > ScriptAlias /cgi-bin/ /usr/webservers/httpd/cgi-bin/
> > </VirtualHost>
> >
> >
> > Apache is weird cause when specifing a NameBaseVirtualHost the hole point
> > is that the name must resolve to the actual real server and not the
> > virtual ip on the balancer.
> >
> > I'm sure there's got to be a better way to do this, but the DEFINITELY
> > works, plus it's possible that it could render better performance because
> > resolution remains on the local machine rather then having to go somewhere
> > to resolve.
> >
> > Two beans in the bucket.
> >
> > Tell Kenn I said get high, I mean hi.
> >
> > -jeremy
> >
> > >
> > > ok so it's been a couple months since i've actually done any lvs
> > > implementation stuff, so i'm a little rusty. i did up 3 systems with
> > > redhat 6.1, using the default rh6.1 kernel, which has lvs stuff, altho a
> > > little outdated i believe (are there major differences/fixes since then?).
> > > i just wanted to test some stuff. here's what i have going:
> > >
> > > my director machine is 206.245.168.30 (eth0). my vip is 206.245.168.31,
> > > which is eth0:0 on the director. eth0:1 is 192.168.123.1 (yeah i guess i
> > > should really put a 2nd nic in there, but it shouldn't really matter,
> > > should it? all these machines are on the same switch behing the same
> > > router...).
> > >
> > > then i have 2 real servers, with eth0 as 192.168.123.2 and 192.168.123.3
> > > on them, respectively.
> > >
> > > i just set this up with nat and masquerading for the time being. i'll
> > > probably use a direct routing method if i were to actually put something
> > > like this in production. but here's what i have:
> > >
> > > on the director:
> > > [root@jammer /root]# /sbin/ipvsadm
> > > IP Virtual Server version 0.8.3 (size=4096)
> > > Protocol LocalAddress:Port Scheduler Flags
> > > -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> > > TCP 206.245.168.31:80 rr
> > > -> 192.168.123.3:80 Masq 1 0 0
> > > -> 192.168.123.2:80 Masq 1 0 0
> > > [root@jammer /root]# /sbin/ipchains -L
> > > Chain input (policy ACCEPT):
> > > Chain forward (policy DENY):
> > > target prot opt source destination ports
> > > MASQ all ------ 192.168.123.0/24 anywhere n/a
> > > Chain output (policy ACCEPT):
> > >
> > >
> > > on my real servers:
> > > [root@one /root]# /sbin/ipchains -L
> > > Chain input (policy ACCEPT):
> > > target prot opt source destination ports
> > > REDIRECT tcp ------ anywhere telnet-stream.iuinc.com any
> > > -> www => www
> > > Chain forward (policy DENY):
> > > Chain output (policy ACCEPT):
> > >
> > > and:
> > > [root@two /root]# /sbin/ipchains -L
> > > Chain input (policy ACCEPT):
> > > target prot opt source destination ports
> > > REDIRECT tcp ------ anywhere telnet-stream.iuinc.com any
> > > -> www => www
> > > Chain forward (policy ACCEPT):
> > > Chain output (policy ACCEPT):
> > >
> > >
> > > i'm just using round robin because i want to make sure requests hit
> > > alternating servers for this testing.
> > >
> > > then i have a shared apache installation setup for those "one" and "two"
> > > machines.
> > >
> > > now, all of this works fine. requests do alternate, responses get sent
> > > back perfectly, and so on.
> > >
> > > the problem comes in with apache virtualhosts. in this situation, my
> > > apache config has:
> > > NameVirtualHost 206.245.168.31:80
> > >
> > > and then i have, as one example:
> > > <VirtualHost w1.bungalow.intra>
> > > User u1
> > > Group u1
> > > UserDir htdocs
> > > ServerAdmin tim@xxxxxxxxxx
> > > DocumentRoot /home/WWW/w1.bungalow.intra/htdocs
> > > ServerName w1.bungalow.intra
> > > ErrorLog /home/WWW/w1.bungalow.intra/logs/error_log
> > > CustomLog /home/WWW/w1.bungalow.intra/logs/access_log combined
> > > ScriptAlias /cgi-bin/ /home/WWW/w1.bungalow.intra/cgi-bin/
> > > </VirtualHost>
> > >
> > > i've got a nameserver for these machines going that resolves
> > > w1.bungalow.intra to 206.245.168.31.
> > >
> > > so far, so good. right?
> > >
> > > well, when i try to get that w1.bungalow.intra web page from the outside
> > > world (a machine on the 205.147.201 network that i made use that same
> > > nameserver so w1.bungalow.intra resolves to 206.245.168.31 and blah blah),
> > > i get the default apache page. ie: the page from the global document
> > > root, rather than that virtual host's document root.
> > >
> > > i know this seems more like an apache question, but i thought it might
> > > have something to do with how lvs redirects or rewrites those packets.
> > > ie: maybe those requests are coming in to 192.168.123.x instead of
> > > 206.245.168.31, so apache doesn't recognize to follow the virtual host
> > > then or something...i'm not really sure. or maybe apache isn't binding to
> > > 206.245.168.31 since it's just an ipchains redirect rule instead of an
> > > interface. i played around with apache's "Listen" and "BindAddress"
> > > directives to no avail. i may simply not have played enough.
> > >
> > > and i know i've gotten something like this to work before, a few months
> > > back, but i can't tell what the difference is.
> > >
> > > anyone have any experience with this and know what might be up here?
> > >
> > > -tcl.
> > >
> > >
> > > ----------------------------------------------------------------------
> > > LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> > > To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
> > > For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
> > >
> >
> >
> > http://www.xxedgexx.com | jeremy@xxxxxxxxxxxx
> > ---------------------------------------------
> >
> >
> > ----------------------------------------------------------------------
> > LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
> >
> >
>
>
> ----------------------------------------------------------------------
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
>
http://www.xxedgexx.com | jeremy@xxxxxxxxxxxx
---------------------------------------------
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
