Sorry Aaron, I didn't say we're content with our ACEs--as you say, the replication and UI stink, plus bandwidth sharing/throttling between applications is counterintuitive. I wouldn't recommend them, especially as they're end-of-life. More just an illustration that authentication load balancing is entirely possible.
John On Wed, Mar 13, 2013 at 9:51 AM, Aaron Macks <[email protected]> wrote: > I'd just add a strong recommendation AGAINST Cisco ACE products. Their > actual load-balancing is fine, but everything else about them > (replication, UI, API, logging) is terrible. To what Nahum said, in a > master-slave failover configuration, the configs are synced, but SSL > certs are not, so frequently the slave is not identical, and a failover > event fails > A > > On 3/13/13 9:41 AM, Nahum Shalman wrote: > > I second the idea of having replicated LDAP servers. If all clients can > > be configured to know about multiple servers, that's the way to go. > > > > But if not, we could expand the conversation with a brief tangent on how > > to make a single IP address survive the failure of a single server: > > > > VRRP or CARP or whatever other implementation is in fashion these days > > could be used to make both LDAP servers work to ensure that one of them > > is managing a particular IP address for the clients that can't be > > configured to use multiple servers. > > > > So with two LDAP servers: > > Server A, IP 10.0.0.1 > > Server B, IP 10.0.0.2 > > You could also define IP address 10.0.0.3 that always is answered by > > only one of those servers (the "master"), and if the master goes down, > > the backup will take over the IP. > > > > Or... You could have two load balancers at 10.0.4 and 10.0.0.5 be the > > machines that use VRRP to manage 10.0.0.3 so that traffic to that > > floating IP will always be balanced across both backend servers, and if > > the master load balancer goes down, the IP will move over to the backup. > > > > But this adds complexity, and more complexity means more places where I > > find I can screw things up, so once again, I recommend the replicated > > LDAP servers rather than mess with load balancers and VRRP. > > (If you have a master and backup load balancer, Murphy's law would seem > > to dictate that when the master load balancer goes down you will > > discover that the backup load balancer was misconfigured...) > > > > -Nahum > > > > > > > > On Tue, Mar 12, 2013 at 10:44 PM, Paul Beltrani <[email protected] > > <mailto:[email protected]>> wrote: > > > > Keep in mind that, unless you're careful, fronting an > > authentication service with a load balancer may simply push the > > problem further out, i.e your load balancer becomes the central > > point of failure. Which is more work making your authentication > > service highly available or setting up highly available load > > balancing service ? > > > > At my previous job I specified a a replicated OpenLDAP > > infrastructure to provide authentication services for the production > > Linux environment. The clients were likewise configured to take > > advantage of multiple servers. I could have fronted the > > authentication service with a load balancer but chose not to. The > > trade-off was between a simpler implementation and quicker fault > > recovery. As that environment could handle the the small timeout > > some clients would experience should a server fail, I went with the > > simpler implementation. > > > > I appreciate this may not be appropriate for your environment. Just > > suggesting an option. > > > > > > - Paul Beltrani > > > > > > > > > > On Tue, Mar 12, 2013 at 1:44 AM, Rob Taylor <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Matt. Thanks for the reply. > > > > The authentication is ldaps. > > > > We are only looking to use the load balancer for internal use, no > > external use is planned. (I'm not a fan of devices straddling > > boundaries > > like that anyway). I think we would use it more for service > > redundancy > > than for actual load distribution most of the time. > > Most of the services that we might use it for are not heavily > > used, (not > > a ton of connections per second or anything). > > > > rgt > > > > > > On 3/11/13 11:02 PM, Matt Finnigan wrote: > > > Generic answers to this are only going to be of minor help for > > you. > > > Knowing more about your specific use cases (particularly, what > > protocols > > > you're using for authentication) will help a lot. > > > > > > Also, we don't know your architecture. Unless you have a flat > > network, a > > > single load-balancer for authentication (typically on the back > > end) > > > won't help you with web load-balancing (typically on the front > > end) - > > > unless your LB has a lot of interfaces and you're OK with it > > straddling > > > your DMZ and internal networks. And, like I said, without > > knowing what > > > protocols you need, a web LB might not be the right fit for > > your auth needs. > > > > > > On Mon, Mar 11, 2013 at 10:53 PM, Rob Taylor <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > Hi Guys. We have some applications here that either can't > > or can't > > > easily support connections to redundant servers for > > authentication, > > > and another application that has been known to beat the > > tar out of > > > the single authentication server it uses. > > > I was asked to look into it and some talk had came up > > about looking > > > into a load balancer for distributing the load, or at > > least making > > > it so that the less capable clients can failover to > > another server. > > > I'm sure we would find other uses for it besides this, > > like web > > > redirection during server outages/maintenance, and possibly > > > distributing logins to cluster login nodes. > > > > > > Right now, our needs are pretty meager. I've started > > looking at a > > > some software ones, like balanceNG, HAproxy, to see what > > they can do. > > > I've also downloaded a demo of stingray, which used to be > > known as Zeus. > > > Coyote point also makes a very inexpensive starter > > hardware model, > > > $2k list. > > > I've got cisco gear in house, but none that seem to > > support SLB or I > > > would have looked at that as well. > > > > > > Load balancers are a technology that I've never really had > > a chance > > > to play with, so I don't really know what to look for and > > what to avoid. > > > Can anyone out there provide any insight on products that > > they have > > > used, what they have used them for and their experiences? > > > > > > Thanks. > > > > > > rgt > > > > > > Whitehead Network/System Administrator > > > > > > _______________________________________________ > > > bblisa mailing list > > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > http://www.bblisa.org/mailman/listinfo/bblisa > > > > > > > > > > _______________________________________________ > > bblisa mailing list > > [email protected] <mailto:[email protected]> > > http://www.bblisa.org/mailman/listinfo/bblisa > > > > > > > > _______________________________________________ > > bblisa mailing list > > [email protected] <mailto:[email protected]> > > http://www.bblisa.org/mailman/listinfo/bblisa > > > > > > > > > > _______________________________________________ > > bblisa mailing list > > [email protected] > > http://www.bblisa.org/mailman/listinfo/bblisa > > > > -- > _______________________________________________________ > Aaron Macks([email protected]) [http://www.wiglaf.org/~aaronm ] > My sheep has seven gall bladders, that makes me the King of the Universe! > > _______________________________________________ > bblisa mailing list > [email protected] > http://www.bblisa.org/mailman/listinfo/bblisa >
_______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
