Load Balancing of Business functionality in a Distributed Scenario

Load Balancing of Business functionality in a Distributed Scenario

• Thebitter

  Sai,

  Your problem sounds quite interesting. Would you please able to share more thoughts around the application -- Existing or New application , How many claims does a center process , Who submits the claims to these centers , What kind of servers do you have , Have you thought about the multi-threaded approach What's the need to distribute load to a completely different center -- are there any SLA for claims processing

  The reason why I'm asking all these questions is so that you don't lean towards over-engineering this solution. Please let me know.

  On a general note, I think you are leaning towards the right solution if you have valid reasons. Actually, it would not be that challenging to design a central solution like that but you would have to definitely think about how would you mitigate this single point of failure a.k.a. your central server. This central server will be a global registry for all the servers. You could design your local servers in a way that the init of your application always registers the server and the port that it is running on with the central server. The central server always chooses the right server to process claims based on the load each server has(This is considering the hardware and software are alike on all the servers and they are only running your application). When it submits the claim, it would also send the URL for the persistence service where it can fetch the data from. Thus, you would always two services running on each server -- Application and Data Service. The data service will help process retrieve data for claims processing. I can expand on further but I think you are already thinking on the same lines.

  I will check this forum in another 5-6 hours and we can have further discussion if you still haven't hit the right idea.

  Tarun

  
  

• Dottj

  Hi, all

  I have a question, why don't you build a web application and put it in the DMZ with 1 central database. This would make more sense and would greatly simplify your application landscape. Rollout of the app is also very simple : install the brower and you're off.

  If I were you I would consider this alternative. It will cost you some effort now (rewriting your presentation layer, but you can reuse Data and business layer) but will be payed back in time. Redesigning an application should always be considered, as the business landscape changes, so should your application. It you would have another 10 stores extra, just create new users in your web application. And they could even work from home or any other location.

  With regards,

  Hans.

  
  

• Jefy

  It's hard to belive that you could package up enough data to complete a trnasaction, send it over the network, process it on a remote store, and return the results in less time than it would take to just do the transaction locally unless the trnasactions do huge amounts of computations and no data access. The data access at the local site would be the same whether the transaction is processed loacally or remotely because the data would have to be retreived to be sent to the remote system and the results would have to be writtn into the local database when they are returned. In most business operations a majority of the time spent is either data access or network time. In your proposed solution the data access is the same and the network access time is significantly greater for a remote transaction so in most cases there won't be a significant benefit to remote processing.

  If you do decide to do remote processing, you could periodically send queue lengths to other stores so a store can pick a short queue. If you have a large number of stores it probably doesn't make sense to allow any store to send to any other store - a store should probably be configured with two or three alternates that can be used to process transactions. This will simplify the loogic to send remote transactions. This should reduce the issue you might run into if dozens of stores all select the same store to send transactions to at the same time so that store gets saturated.

  In general, I don't think this is a practical architecture. In addition to the complexity and network overhead this solution imposes, there are difficult security and privacy concerns that must be overcome if trnasactions from one store are processed at another store. You would also have to deal with the issues of what happens when a server crashes while processing a transaction from another store Do you keep track of where all transactions are being processed so you can reprocess them if the remote server fails Better yet, what does a remote server do if the local server crashes so it has no place to return results to The solutions to these issues will involve local and remote recording of all operations so the distrbuted system can recover from failures. This extra overhead may reduce the total throughput of your distributed system. Some of these issues could be resolved by using the SQL Server Service Broker to control your transactions because the Service Broker would make the operations reliable and recoverable. Also, pulling transactions in when the local queue is empty is significantly simpler and leads to much better scheduling behavior than pushing transactions from full queues to empty queues.

  
  

• AlanKohl

  Thanks for your quick response. The queue approach was what I had in mind but things get a bit more complicated when it comes to the business requirement.
  Firstly I have the client app calling services which in turn calls in some workflow and so on.
  Now I have this application installed in various locations. Each location has its own database with 4-5 clients connected to each store. I would have many such stores across various locations.
  
  Now when I have submitted a particular order for processing and 10 more orders are in queue in this Store. The user decides that he can only process 10 and decide to offload the remaining 5 to the any other store which is not loaded.
  
  Now my problem is two fold. First how do I determine which particular store is loaded or free. Secondly I would have to package the entire set of data, and the particular ruleset for this store for processing it with the other store. It wouldnt be right to mix this data with the data that is already present in that store. Hence I would need to demark with some identifier in the DB to help me differentiate the same. Now when the other store processes this order it needs to intimate and then send all the details to the original store.
  
  One approach I was thinking of is that have a central server for all this respective stores. Any kind of such overload requests would be sent to the queue on central server. The central server does the tracking, routing and load balancing. But designing such kind of app/service at the central server would be quite a challenge
  
  
  
  

• Steven Fl

  The thing that makes this challenging is that in order for operations to be processed at an alternate site, the databases must be replicated. If this is something you want to do anyway for avalability or query balancing reasons then it makes sense but if you are replicating the databases only for load balancing purposes you may find that the extra overhead of replication cancels out the advantages of load balancing.

  One of the best ways to architect this kind of solution is to put all work that needs to be processed on a queue in each server. The processing logic then processes the local queue until it is empty and then process a message from one of the remote queues. This has the advantage that work is never pushed to another server to be processed. If you push work, there's always the chance that the low work load at the remote server was temporary and when the work gets there it will have to compete with newly queued local work items. By only processing remote items when the local queue is empty, there will never be more than a one item gap in message processing.

  You can either have a fixed order for checking remote queues - based on proximity or average work volume - or periodically check the queue depth of remote queues so you know which server to check first.

  Keep in mind that supporting a system where an entity can be updated in more than one place makes replication more complex. Your choices are distributed transactions - very expensive - or merge replication that handles update conflicts.

  
  

• Vishal Shah

  I think you are trying to build a diversly located 'grid' system. I don't think you are likely to have much success with in a reasonable budget. Look how much people like Sun and Oracle spend on R&D on this type of thing - and its still a bit dodgy :-)

  If you bring all the systems to one location this would not be a problem. You should then be able to implement load balancing across the app layer very easily.

  You'll also find security, supportability, management, availablity and release management improved, at the cost of increased bandwidth costs.

  
  
  

• Ledeni_Plamen

  Sai,

  It seems to me there is confusion about the scenario you are presenting. You mean "load balancing" human activities, not processing power, is this right

  If so, depending on how complex is your scenario, you might be better of implementing a mecanism which lets them access the information asigned to them on the remote machine, and then submitting the results at the end.

  
  

• Susana Guedes

  I have a similiar problem ,I am trying to load balance sql server 2005 do u know how

  PS: we need a product that does have such capabilities.

  
  
  

• Benj78

  Decided to go with the following approach.
  
  Store A offloads say 5 orders to Central Server. Other Stores which are free would then connect to the Central Store and process the order at the server itself. Once the order is completed sync would happen from central to Store A
  
  Eglasius- Yep, its load balancing of business processes and not processing power
  
  
  
• Load Balancing of Business functionality in a Distributed Scenario