|
Roberto Nibali <ratz@xxxxxx> said:
> Hi Don,
> > I don't understand what you mean. What does this mean, "24 zone with 24
NICs"?
>
> Ok, given you want to build a hosting and datacenter for a huge ISP. This
> ISP has the resources and connections to aquire potential hosting partners
> or customers which cannot afford an own datacenter but will want to be
present
> on the Internet with bleeding edge technology and high availability and
> security. Now, for one aspect of HA you decide to create a DMZ for every
> new incoming customer which wants to host his services in this datacenter.
> You have two choices:
>
> o For every DMZ zone behind the packetfilter you buy one, maybe
> two commercial load balancer / per customer. So every customer
> gets the idea that he owns a lb of his own. The costs for the
> ISP providing this HA solution are too high compared to what they
> can ask the customer for without loosing important market share
> (yes, I know there are marketing technical terms for it, but I'm
> not a manager)
> o You take one single or for HA of the lb two linux boxes, and
> simulate every zone ("dmz of the according customer") with a
> NIC. So for example if you put in 24 NICs into one lb the ISP
> can sell the same load balancer 24 times to a customer but only
> pays one piece. The end customer still gets the impression of
> having his own loadbalancer. If you write intelligent software
> to manage such a biest, you're definitely ready for the lb
> market.
>
> Did I make my point clear? And this is where you might run into
> problems with NAT faster then with DR.
Uh. Yea I would think so. Would that be 6x4port or 3x8port NICS? Who is doing
this? In any case, this would definately be a special case. I was making a
point that you are fine with NAT for -most- applications.
> > I don't know how long the requests were sustained. The cluster was
managed by
> > a close friend of mine and the .com that owned it has gone under and the
> > cluster was dismantled and auctioned off. Yes, they were dynamic
(mostly). I
> > don't think the db queries were long, the db servers were Sequent boxes
(8 or
> > 10 of them as I recall) with 8 p3/500s and Oracle.
>
> To decide if going with NAT and DR you still have to do field testing
> and tuning. Every load balanced application has its tricky part. If
> db queries take too long you might have problems with the NAT table in
> the kernel. I only mention it because basically I agree the NAT and DR
> can be put into the same pot for most of the cases but one has to have
> the ideas of possible problems in his mind.
Yes, one must always be looking at all the angles.
> > > Good point for the howto. Indeed, with nowadays Internet technology and
> > > computer technology we should not give the reader the impression that as
> > > soon as he wants to load balance a moderately surfed site he needs to
> > > choose LVS_DR.
> >
> > Exactly. DR and TUN are valuable, but you have to have a VERY busy site,
or
> > other special circumstances to really need them.
>
> It's a tradeoff between how much time the implementation manager gives
> you to fiddle around with the arp problem and how saturated the lb will
> really be when not choosing DR or TUN. Managers tend to use low cost _and_
> time friendly solutions which don't mix well with the DR approach, when
> done the first time. I would say: Instead of pissing everyone off trying
> to set up DR to impress the boss, you'd rather go and impress him with
> a NAT setup done in 2 hours (with testing).
Yea, unless you have a setup that needs DR. :)
-=dwh=-
________________________________________________________________
http://www.OpenRecording.com For musicians by musicians.
Now with free Web-Based email too!
|
