We care currently running LDAP as a Master-Master configuration with one primary. We are supplying the Spring LdapContextSource with two LDAP nodes to use as primary/failover.
We went to this configuration because previously our LDAP had been behind an f5 load balancer, but we would run into replication issues when a user was created on Node A, but the f5 sent the updates to Node B before the two could sync.
However, now we are running into a situation where we are over-utilizing one node. And ignoring the second node.
What I would like to be able to do is configure the f5 such that all Create, Update, Delete operations went to a primary node, but reads were distributed between the two LDAP Nodes.
Any thoughts on how to configure the f5 to achieve this?
For reference we are using a 389-ds implementation of LDAP.
Recommendation: Split the work into two separate VIPs if possible. At least that's what we've done with mysql here — a write VIP and a read-only VIP. I know this question is for LDAP, but LDAP is a type of database, and your needs are very similar to mysql read/write dilemmas.
Write VIP: Set up your F5 pool with Priority Group Activation set to "Less than 1" on the Members tab. This is a failover configuration and does not split load since the LDAP sync isn't fast enough to support it. The higher priority number takes the traffic first. If it goes down, traffic flows to the lower priority. You assign priority as you are adding each node.
Read VIP: Load-balance traffic with a typical configuration as you had it before.
In both VIPs, of course you need a valid LDAP query in your health monitor that proves the service is working correctly. If allowed by your directory, you don't even have to login. You can just read the directory, searching for a particular base and filter defining an object within that base. This makes the health monitor faster and less troublesome while remaining effective. LDAP login in F5 monitors can be a major pain, so it's nice to skip it when feasible.
Related
I have a Apache web server in front of 2 tomcats which are connected to the same MySQL backend database.
I need to load balance the incoming requests between two tomcats based on a URL parameter named "projectid". For example all even project ids may be served with tomcat 1 and odd requests with tomcat 2.
This is required because the user may start jobs in a project of tomcat 1 which tomcat 2 won't be aware of and these jobs are currently not stored in the database.
Is there a way to achieve this using mod-proxy-load-balancing?
I'm not aware of such a load algorithm being already present. However, keep in mind that the most common loadbalancing outcome (especially when you have server-side state as you obviously have) is a sticky session: You're only balancing the initial request. After that, all requests are typically directed to the same server.
I typically recommend against distributing the session data as it adds some commonly unnecessary performance hit onto each request, negating the improved performance that you can get with clustering. This is subject to be changed in actual installations though and just a first rule of thumb.
You might be able to create your own loadbalancing algorithm with mod-proxy-load-balancing (you'll need to configure the algorithm in the config file), but I believe your time is better spent fixing your implementation, or implement business specific logic to check all cluster machines for running jobs.
Currently I have the following setup:
Hardware load balancer directing traffic to two physical servers each with 2 instances of weblogic running.
Works ok. I'd like to be able to shutdown one of the servers without dropping active sessions. Right now if I shutdown one of the physical servers any traffic that was going there gets bounced back to a login screen.
I'm looking for the simplest way of accomplishing this with the smallest performance hit.
Things I've considered so far:
1. See if I can somehow store the session information on the Load Balancer and through some Load Balancer magic have it notice a server is dead and try another one with the same session information (not sure this is possible)
2. Configure weblogic clustering. Not sure what the performance hit would be. Im guessing this is what I'll end up with, but still fishing for alternatives.
3. ?
What I currently have is an overly designed DR solution (which was the requirement), but I'd like to move it more in the direction of HA (for the flexibility)
edit Also is it worthwhile to create 2 clusters and replicate the sessions between them (I was thinking one cluster per site, sites are close enough). This would cover the event of one cluster failing.
You could try setting up a JDBC Session Storage pointing (of course) both instances to the same datasource without setting up a cluster, but I think the right approach would be setting up a Weblogic Cluster.
A nice thing about clustering Weblogic Servers is that - (from the link above, emphasis mine):
Sessions can be shared across clustered WebLogic Servers. Note that session persistence is no longer a requirement in a WebLogic Cluster. Instead, you can use in-memory replication of state. For more information, see Using WebLogic Server Clusters.
We've got a write up of this on our blog http://blog.c2b2.co.uk/2012/10/basic-clustering-with-weblogic-12c-and.html which provides step by step instructions on setting up web session failover in a cluster.
Clusters are not heavyweight assuming you don't store huge amounts of data in the cluster as it will be replicated.
LDAP Fault-tolerance configuration (e.g SunOne):
Does anyboby know how to configuration "Fault-tolerance" for LDAP, e.g SunOne LDAP.
I search via google without any userful result?
Thanks
Assuming, by "fault tolerance," "high availability (HA)" is being asked, I would say it can be achieved by redundancy. And, it would not be peculiar to SunOne or any directory server software from other vendors.
There are different ways to solve this. It depends on the business requirements and the affordability. One method that comes to mind is to have the LDAP software installed on an HA pair. This requires hardware and OS capabilities for fail-over and it requires two servers (in a world of virtualization, "server" can mean different things [physical box, frame, LPAR, etc.]; so, I'll just leave the interpretation to the reader). When one server fails, the other server takes over and assumes the primary role in the pair. This is the fault-tolerance part. In this approach, the machine/server with the secondary role is passive (i.e., it's not serving clients) until the primary goes down. You will need to implement LDAP data replication between two servers. They can be two LDAP masters in a P2P replication topology.
Another method is to have multiple LDAP servers (i.e., masters, replicas) and cluster them using a network dispatcher (ND) software/appliance/etc., which would distribute the incoming traffic to the individual servers (usually replicas) in the cluster. If you lose one replica in the cluster, ND will not send any traffic to that replica until it comes back. However, other replicas will still be receiving load and therefore serving to the incoming traffic. This is the fault-tolerance part in this method. The degree of the availability you want will also dictate what can be done in a clustered environment. You can have a single LDAP master (to which the organization's applications would make updates) and keep it out of the cluster, but pair with another server for fail-over (so you wouldn't lose availability for updates from the applications - this also gives you the freedom to do maintenance on the master without interrupting your applications [well, they need to be written to be able to write to more than one LDAP master if the primary one is not available]). You would have to have the secondary server to receive replication from the primary in any case. If the budget doesn't let you have more servers/replicas, then you can put the master server along with replicas in the cluster as well to help with the read traffic. Instead of an HA-pair in which one of the servers would be passive, you can have two masters configured in a P2P replication topology and have them both in the cluster to help with the traffic too. There are different ways to approach to this method depending on the level of redundancy wanted or that can be afforded.
In the context of Tomcat, can session replication takes place without enabling sticky session?
I understand the purpose of sticky session is to have the client 'sticks' to 1 server throughout the session. With session replication, the client's interaction with the server is replicated throughout the cluster (many web servers).
In the above case, can session replication takes place? i.e. client's session is spread though out the web servers and each interaction with any one web server is replicated across, thus, allowing seamless interaction.
AFAIK, tomcat clustering does not support non-sticky sessions. From tomcat docs:
Make sure that your loadbalancer is configured for sticky session
mode.
But there's a solution (I created, so you know I'm biased :-)) called memcached-session-manager (msm), that also supports non-sticky sessions. msm uses memcached (or any backend speaking the memcached protocol) as backend for session backup/storage.
In non-sticky mode sessions are only stored in memcached and no longer in tomcat, as with non-sticky sessions the session-store must be external (to avoid stale data).
It also supports session locking: with non-sticky sessions multiple, parallel requests may hit different tomcats and could modify the session in parallel, so that some of the session changes might get overwritten by others. Session locking allows synchronization of parallel requests going to different tomcats.
The msm home page mainly describes the sticky session approach (as it started with this only), for details regarding non-sticky sessions you might search or ask on the mailing list.
Details and examples regarding the configuration can be found in the msm wiki (SetupAndConfiguration).
Just to give you an idea regarding the complexity: what you need is one or more memcached servers running (or s.th. similar speaking memcached) and an updated tomcat context.xml like this:
<Context>
...
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:host1.domain.com:11211,n2:host2.domain.com:11211"
sticky="false"
sessionBackupAsync="false"
lockingMode="auto"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
/>
</Context>
Your load-balancer does not need special configuration, so once you have these things in place you can start testing your application.
An excellent article about this topic here:
http://www.mulesoft.com/tomcat-cluster
The terracotta product they mention has a simplistic tutorial here:
http://www.terracotta.org/documentation/web-sessions/get-started
Terracotta works on Tomcat but you must pay attention to check which bits of Terracotta are free and which are commercial. A couple of years ago their redundant store was paid and I don't remember this solution being a separated product.
I have actually found the inverse to this question. Session replication for me (Tomcat7) with the OOTB options only works properly WITHOUT Sticky Session. After turning the logging up I found that with the JVMRoutes enabled my session ID goes from A123456789 to A123456789.01 -- suffixed with the jvmroute. That session is successfully replicated from Node 01 in the cluster to Node 02 but uses the same ID (A123456789.01). When I take Node 01 out of the cluster then the traffic starts to stick on Node 02 -- and it looks now for a session A123456789.02 which of course does not exist. .01 is there, but basically sits idle until it expires. If I bring the other server up and the sessions are replicated and then take 02 down, I get even odder behaviour because the session is picked up where it left off.
For me, so far, session replication without sticky sessions (just regular RR amongst the nodes in the cluster) is the only thing that has worked.
Can someone explain to me how high-availability ("HA") works for a web application ... because I assume HA means that there exist no single-point-of-failure.
However, even if a load balancer is used- isn't that the single point of failure?
I have found this article on the subject:
http://www.tenereillo.com/GSLBPageOfShame.htm
Basically if you do not require long lasting sticky sessions you can configure your DNS servers to return multiple A records (IP addresses) for your website.
Web browsers are smart enough to try all the addresses until they find one that works.
In simple words high availability can be defined as running a system 24*7 without a downtime even if there are hardware and software failures. In other way a fault tolerance application. This helps ensure uninterrupted use of the application for it’s intended users.
Read more on High Availability Deployment Architecture
It works the following way that you setup two HA Proxy servers with heartbeat, so when one fails (stops responding to queries), it's being removed from the cluster.
Requests from HA Proxy can be forwarded to web servers in round robin fashion, and if one web server fails, HA Proxy servers do not try to contact it until it's alive.
Web servers are storing all dynamic information in database, which is replicated across two MySQL instances.
As you can see, HA Proxy and Cluster MySQL (or simply MySQL replication) as well IP Clustering here is the key.
Sure it is when operated alone. Usual highly available setup includes 2 or more load balancers running in cluster in either active/active or active/passive configuration. To further increase the availability you can have 2 different Internet Service Providers (or geo distributed datacenters) each running a pair of clustered load balancers. Then you configure DNS A record resolving to 2 distinct public IP addresses which guarantees round-robin processing splitting DNS requests evenly (CloudFlare is very fast and reliable at this). There's also possibility to return IP address of datacenter closest to your originating geo location by using something like PowerDNS dnsdist
This is what big players do to make their services highly available.
Please read https://docs.oracle.com/cd/E23824_01/html/821-1453/gkkky.html for more clearity. Actually both load balancer uses same vip(Virtual IP Address. https://techterms.com/definition/vip).
HA architecture is a entire field and multiple books were written on it, so it is hard to answer in a short paragraph.
To sum up the ideal situation, you would be using multiple servers, interconnected to a layer of multiple load balancers. The nodes and LB will be located in a few different data centers, and connected to different network backbone. Ideally the data centers will be located all over the world.
In short, all component will have redundancy, including the load balancers.
For a starting point, see Wikipedia for High Availability Cluster