Given a small, globally routable netblock to be used for front-end web servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities. Jeremiah being a customer stinks
On Wed, 5 Jul 2000, Jeremiah Kristal wrote:
Given a small, globally routable netblock to be used for front-end web servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities.
Dude, saying things like that on this group is likely to get you executed. Building a discontigious AS isn't the answer. Have you looked at the global load balacing products like Cisco's Distributed Director or Arrowpoints's whatever they call it? There are many products that do both global and local load balacing, each one is different has has a specific application they fit best. It would be silly to recommend a product to you without understanding your application, so check out these companies and see for yourself: Cisco (LocalDirector and DistributedDirector) Foundry (Server Iron) Alteon (ACE Director) Arrowpoint (CS-xxx) F5 Labs (BIG/ip & 3DNS) Resonate BrightTiger Some are software solutions, some are hardware that run on PC's and some are ASIC based solutions. See what fits. later- devin --- Devin P. Anderson Network Operations Stargate Industries Direct: 412.316.1052 Main: 412.316.7827 x1052 FAX: 412.316.7899 --- PGP Key Available ---
Given a small, globally routable netblock to be used for front-end web servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities.
Dude, saying things like that on this group is likely to get you executed. Building a discontigious AS isn't the answer.
i missed the part where he said discontiguous as. please point it out to us. randy
On Wed, 5 Jul 2000, Randy Bush wrote:
Given a small, globally routable netblock to be used for front-end web servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities.
Dude, saying things like that on this group is likely to get you executed. Building a discontigious AS isn't the answer.
i missed the part where he said discontiguous as. please point it out to us.
'short of building a network connecting hosting facilities' and numbering the servers with the sames addresses. Maybe I misunderstood. Its seems to me that a better way to do it would be to use some product that goes global load balancing. later- devin
On Wed, Jul 05, 2000, Randy Bush wrote:
Given a small, globally routable netblock to be used for front-end web servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities.
Dude, saying things like that on this group is likely to get you executed. Building a discontigious AS isn't the answer.
i missed the part where he said discontiguous as. please point it out to us.
[quote] Given a small, globally routable netblock to be used for front-end web servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities. [end quote] Note hosting(sic) providers .. providers being plural. There are multiple options. I wouldn't count doing discontinuous AS stuff as being a good solution. Stuff like the Cisco Distributed Director works, but I'm of the opinion that the server shouldn't ever decide whats best for the clients from a network point of view. Being evil and out of whack, the only solution thats going to work for this and various other distributed service requirements is finding a way to push the server selection *out* towards the clients. Modelling the internet to try and return the 'best choice' for a client is a good idea, but you aren't solving anything. (Unless of course your concept of 'telling the client' is so wide spread you affect the internets traffic patterns from your decisions .. :-) Adrian -- Adrian Chadd Build a man a fire, and he's warm for the <adrian@creative.net.au> rest of the evening. Set a man on fire and he's warm for the rest of his life.
maybe what folk here are missing is that many of the largest providers use the "v4 anycast" hack (what the original question described) today, and very successfully. and, for the pedants and seemingly illiterate, what the questioner was suggesting was an rfc1930 violation, the same prefix from more than one origin as, not a partitioned as. 1930 was a good year, but not a great year, i.e. compliance is not enforced as far as i am aware. i believe that his hack will work, and work well. and moving this kind of thing to the client, when the alternative is making the distributed internet work for you, is product marketing promoted by folk with something to sell. and moving it to dns servers is a disfunctional disease of the bad idea fairy. randy
Randy Bush: Wednesday, July 05, 2000 8:38 AM
Jeremiah Kristal: Wednesday, July 05, 2000 8:17 AM
with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem?
Devin P. Anderson: Wednesday, July 05, 2000 8:34 AM
Building a discontigious AS isn't the answer.
i missed the part where he said discontiguous as. please point it out to us.
More than one hosting providers always means discontinuous IP-blocks, per CIDR. Remember the big discussion of about 6 weeks ago, WRT CIDR and peering? If he wants to do this, he's either going to have to burn a portable /19, or two portable /24's. In most cases, burning the /19 will be required, depending on level of prefix filtering, along with negotiatiing up-stream peering relationships.
At 11:17 AM 7/5/2000 -0400, you wrote:
Given a small, globally routable netblock to be used for front-end web servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities.
Jeremiah being a customer stinks
If you have cisco, you could use a BGP non-exist-map and advertise-map and conditionally advertise that globally routable block in the case of an outage, or have your provider do so. The main concern here being a flapping interface, of course. Does anyone know of a way to get around the flapping/dampening issue? Brantley
actually, Foundry has a global solution based on BGP, check them out. There is a load-balancing mailing list, which addresses such issues. http://vegan.net/lb is the info to sign up. Tony On Wed, 5 Jul 2000, Jeremiah Kristal wrote:
Given a small, globally routable netblock to be used for front-end web servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities.
Jeremiah being a customer stinks
-------------- -- ---- ---- --- - - - - - -- - - - - - - Tony Bourke tony@vegan.net
the major disadvantage of the foundry (bgp) solution is longer prefix injection. the major problem with the dns-based solutions is that they're not topology-aware (-> suboptimal routing). attempts to make dns smart lead to rather awkward reverse pinging configurations and proprietary protocols running between load balancers. (there was also rfc2052 by paul vixie but it required modification of dns clients.) there is also the "triangle data flow" solution, which is broken by cef... i'm in the process of preparing an overview of the available techniques along with introduction of a new one, which solves a lot of headaches. it requires a feature set that is not available on any of the currently existing lb platforms, hence, for testing, i had to develop one using open source (i chose linux to make it fast (it had almost all bits in place -- check http://www.linuxvirtualserver.org/)). -- dima.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of tony bourke Sent: Wednesday, July 05, 2000 2:11 PM To: Jeremiah Kristal Cc: nanog@merit.edu Subject: Re: bad idea?
actually, Foundry has a global solution based on BGP, check them out.
There is a load-balancing mailing list, which addresses such issues.
http://vegan.net/lb is the info to sign up.
Tony
On Wed, 5 Jul 2000, Jeremiah Kristal wrote:
Given a small, globally routable netblock to be used for front-end web servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities.
Jeremiah being a customer stinks
-------------- -- ---- ---- --- - - - - - -- - - - - - - Tony Bourke tony@vegan.net
The Foundry solution (ServerIron) is not BGP based. It is a DNS-based solution that uses a round-trip-time metric (calculated based on TCP syn/ack from client to server by the ServerIron on a per connection basis). The two down-sides of a DNS based solution are both caused by the fact that client source IPs are not contained in the request that comes from the client DNS resolver: 1] persistant connections must be managed on each real server. 2] client's whose IP is not within the same netblock (defaults to /20, tuneable) as DNS resolver do not get the benefit of RTTmetrics. Peter At 6:10 PM -0400 7/5/00, Dmitri Krioukov wrote:
the major disadvantage of the foundry (bgp) solution is longer prefix injection.
the major problem with the dns-based solutions is that they're not topology-aware (-> suboptimal routing). attempts to make dns smart lead to rather awkward reverse pinging configurations and proprietary protocols running between load balancers. (there was also rfc2052 by paul vixie but it required modification of dns clients.)
there is also the "triangle data flow" solution, which is broken by cef...
i'm in the process of preparing an overview of the available techniques along with introduction of a new one, which solves a lot of headaches. it requires a feature set that is not available on any of the currently existing lb platforms, hence, for testing, i had to develop one using open source (i chose linux to make it fast (it had almost all bits in place -- check http://www.linuxvirtualserver.org/)). -- dima.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of tony bourke Sent: Wednesday, July 05, 2000 2:11 PM To: Jeremiah Kristal Cc: nanog@merit.edu Subject: Re: bad idea?
actually, Foundry has a global solution based on BGP, check them out.
There is a load-balancing mailing list, which addresses such issues.
http://vegan.net/lb is the info to sign up.
Tony
On Wed, 5 Jul 2000, Jeremiah Kristal wrote:
Given a small, globally routable netblock to be used for front-end web servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities.
Jeremiah being a customer stinks
-------------- -- ---- ---- --- - - - - - -- - - - - - - Tony Bourke tony@vegan.net
foundry does have a bgp based solution. it's called "route health injection". it is available on bigirons and it is described in their official documentation. they also have the dns based solution available on serverirons. -- dima.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Peter Francis Sent: Wednesday, July 05, 2000 6:59 PM To: Dmitri Krioukov; tony bourke Cc: nanog@merit.edu Subject: LoadBalancing products: Foundry ServerIron
The Foundry solution (ServerIron) is not BGP based.
It is a DNS-based solution that uses a round-trip-time metric (calculated based on TCP syn/ack from client to server by the ServerIron on a per connection basis).
The two down-sides of a DNS based solution are both caused by the fact that client source IPs are not contained in the request that comes from the client DNS resolver:
1] persistant connections must be managed on each real server.
2] client's whose IP is not within the same netblock (defaults to /20, tuneable) as DNS resolver do not get the benefit of RTTmetrics.
Peter
At 6:10 PM -0400 7/5/00, Dmitri Krioukov wrote:
the major disadvantage of the foundry (bgp) solution is longer prefix injection.
the major problem with the dns-based solutions is that they're not topology-aware (-> suboptimal routing). attempts to make dns smart lead to rather awkward reverse pinging configurations and proprietary protocols running between load balancers. (there was also rfc2052 by paul vixie but it required modification of dns clients.)
there is also the "triangle data flow" solution, which is broken by cef...
i'm in the process of preparing an overview of the available techniques along with introduction of a new one, which solves a lot of headaches. it requires a feature set that is not available on any of the currently existing lb platforms, hence, for testing, i had to develop one using open source (i chose linux to make it fast (it had almost all bits in place -- check http://www.linuxvirtualserver.org/)). -- dima.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of tony bourke Sent: Wednesday, July 05, 2000 2:11 PM To: Jeremiah Kristal Cc: nanog@merit.edu Subject: Re: bad idea?
actually, Foundry has a global solution based on BGP, check them out.
There is a load-balancing mailing list, which addresses such issues.
http://vegan.net/lb is the info to sign up.
Tony
On Wed, 5 Jul 2000, Jeremiah Kristal wrote:
Given a small, globally routable netblock to be used for
front-end web
servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities.
Jeremiah being a customer stinks
-------------- -- ---- ---- --- - - - - - -- - - - - - - Tony Bourke tony@vegan.net
F5 Networks also has a DNS based system (www.f5.com). A new feature (real soon now) coming out will eliminate most of the need for reverse pinging to discover RTT to the client. We will instead sample traffic as it passes through our load balancers, summarizing the data and passing it up to the 3DNS box for decision making. JMH Brantley Jones wrote:
Speaking of using a DNS proxy, does anybody know of anybody else doing this besides Foundry??
Brantley
-- John Hall <j.hall@f5.com> F5 Networks, Inc. Senior Test Engineer 206-505-0800 Yea from the table of my memory I'll wipe away all trivial fond records. -- Hamlet
I'm being told by my colo provider (in NY) that Cable & Wireless northeast is currently under a major DoS. Has anyone else heard anything about this?
Part of the Foundry GSLB (Global Server Load Balancing) solution is BGP based, as well as DNS based, depending on what you want to implement. The problem with DNS is that it doesn't work 100% in case of one location's failure The problem with BGP is route injection is that its very complicated to implement, and I havn't seen it used at all. Most load balancing products employ some sort of DNS based method for global distribution, and many offer something on top of this to compenstate for DNS's shortcomings. GSLB is still rapidly evolving, so 6 monthes from now there will be several other solutions available as well. Tony On Wed, 5 Jul 2000, Peter Francis wrote:
The Foundry solution (ServerIron) is not BGP based.
It is a DNS-based solution that uses a round-trip-time metric (calculated based on TCP syn/ack from client to server by the ServerIron on a per connection basis).
The two down-sides of a DNS based solution are both caused by the fact that client source IPs are not contained in the request that comes from the client DNS resolver:
1] persistant connections must be managed on each real server.
2] client's whose IP is not within the same netblock (defaults to /20, tuneable) as DNS resolver do not get the benefit of RTTmetrics.
Peter
At 6:10 PM -0400 7/5/00, Dmitri Krioukov wrote:
the major disadvantage of the foundry (bgp) solution is longer prefix injection.
the major problem with the dns-based solutions is that they're not topology-aware (-> suboptimal routing). attempts to make dns smart lead to rather awkward reverse pinging configurations and proprietary protocols running between load balancers. (there was also rfc2052 by paul vixie but it required modification of dns clients.)
there is also the "triangle data flow" solution, which is broken by cef...
i'm in the process of preparing an overview of the available techniques along with introduction of a new one, which solves a lot of headaches. it requires a feature set that is not available on any of the currently existing lb platforms, hence, for testing, i had to develop one using open source (i chose linux to make it fast (it had almost all bits in place -- check http://www.linuxvirtualserver.org/)). -- dima.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of tony bourke Sent: Wednesday, July 05, 2000 2:11 PM To: Jeremiah Kristal Cc: nanog@merit.edu Subject: Re: bad idea?
actually, Foundry has a global solution based on BGP, check them out.
There is a load-balancing mailing list, which addresses such issues.
http://vegan.net/lb is the info to sign up.
Tony
On Wed, 5 Jul 2000, Jeremiah Kristal wrote:
Given a small, globally routable netblock to be used for front-end web servers, and a strong aversion for using DNS for any type of load balancing, would it be reasonable to build two identical servers farms with the same public IP addresses and rely on the BGP sessions with the hosing providers to remove one advertisement in the event of a problem? I've been looking at ways to ensure that the webservers are always available, short of building a network connecting hosting facilities.
Jeremiah being a customer stinks
-------------- -- ---- ---- --- - - - - - -- - - - - - - Tony Bourke tony@vegan.net
-------------- -- ---- ---- --- - - - - - -- - - - - - - Tony Bourke tony@vegan.net
participants (12)
-
Adrian Chadd -
Brantley Jones -
Devin P. Anderson -
Dmitri Krioukov -
Ian Gulliver -
Jeremiah Kristal -
John Hall -
Peter Francis -
Randy Bush -
Rick Irving -
Roeland M.J. Meyer -
tony bourke