In today’s over-hyped cloud computing market one hears terms such as “elastic scaling” being applied to capabilities for software load balancing. Load balancing is a term applied generically to any of a variety of computing methodologies in a distributed network whereby workload can be distributed across multiple computers or servers for the purpose of achieving optimized throughput, response times and resource utilization. Additional benefits in the form of greater reliability through redundancy and “failover” techniques are often closely associated with software load balancing.
Here in the Magic of uniPaaS blog we talk frequently about the differences between standard 3GL and 4GL approaches to software development and deployment versus the benefits of an application platform such as Magic Software’s uniPaaS application platform. Load balancing is a subject with rather significant implications because of the relative complexity of accomplishing load balancing without an application platform.
If you look at a cloud computing platform such as Amazon Elastic Compute Cloud (Amazon EC2), you see that significant additional effort is required to achieve load balancing through the use of approaches such as Round Robin DNS or add-on software such as HA Proxy. In fact, Amazon says specifically that “Applications that require a persistent connection to a specific database or backend server are generally incompatible by default.”
But what if you had an application platform with built-in load balancing capabilities? That’s where the Magic uniPaaS Application Platform performs exceptionally well and can help you achieve the real potential of cloud computing.
For simple load balancing you should have at least two uniPaaS Enterprise Servers connected to the same Broker with the same application. The Broker will balance the load between the uniPaaS servers automatically.
A new option was added to the Magic Request Broker’s load balancing mechanism that will distribute the load evenly between runtime engines according to the percentage of executing threads out of the maximum number of threads allowed for an engine.
You can implement more complex load balancing by starting several different uniPaaS servers on several different machines. In addition, you can give each server a different priority level by setting the Options->Settings->Environment->Server->Load Balancing Priority.
uniPaaS provides a middleware agent known as the Magic Request Broker. The Magic Request Broker, also referred to as the broker, maintains the pool of available uniPaaS Runtime engines.
When a Runtime engine loads, it registers itself with the broker. Each subsequent engine also registers itself with that broker.
When the broker loads it starts listening on its defined port. The broker handles a list of all the available uniPaaS Runtime engines and directs each request from the uniPaaS Internet requester to the available Runtime engine for execution.
Each Runtime engine can handle more than one request simultaneously, each in its own thread.
The request broker provides load balancing and recovery capabilities to handle any fail over.
The main functions of the Magic Request Broker are:
· Queuing client requests
· Allocating available runtime engines for requests
· Logging all operations
· Maintaining and distributing the status of all submitted requests
· Activating programs in asynchronous (No Wait) mode
Usually, when you install uniPaaS, you don't have to know how the distributed application architecture is set up. However, sometimes when working with a Rich Client or Browser project, it can be helpful to understand what is happening behind the scenes, so that you can tweak some of the settings. The Magic uniPaaS Application Platform has this built-in ability to control the way the application platform implements load balancing. So if you seek true elastic scaling, consider the Magic uniPaaS Application Platform as your foundation for cloud computing applications that are truly scalable with software load balancing across n-tiered architectures and distributed computing networks.
No comments:
Post a Comment