WEB Farm - Load Balancing in Asp.net
The concept behind the web farm is that a number of different web sites share pooled resources. They typically share a common front-end dispatcher to perform load control and distribute customer requests. They share the multiple web servers themselves.
Scope:
Considering the high volume of traffic the Web site uses two or more servers needed to handle user requests. The concept behind the web farm is that a number of different web sites share pooled resources. They typically share a common front-end dispatcher to perform load control and distribute customer requests. They share the multiple web servers themselves. Based on experience and with reference to Microsoft sites this document was created to address certain issues faced in web farm while using ASP.NET.
Machine Key:
Consider a scenario while doing a PostBack in ASP.NET and which looses the form information.
For Example:
When a user selects an item from a DropDownList and then clicks a submit button, the Click event on the button redirects them to the value of the selected item. This works fine if you are on Webserver1 and the button click PostBacks to Webserver1. If you are on Webserver1 and the load balance submits back to Webserver2, the page reloads and the Button click event never fires. This happen site wide and affects utilities such as submitting a textbox search and other form posting events.
Approach 1
You can modify the pages element in In machine.config of both the servers:
EnableViewStateMac indicates that ASP.NET should run a machine authentication check (MAC) on the page’s view state when the page is posted back from the client;
True - if view state should be MAC checked
False - We need to ensure that it is kept to false.
Approach 2
Force every server in your farm to use the same key; generate a hex encoded 64-bit or 128-bit and put that in each server's machine.config.
You can generate a key from
http://www.eggheadcafe.com/articles/GenerateMachineKey/GenerateMachineKey.aspx
Session Management:
ASP.NET provides two solutions for sharing state information between multiple servers:
1. The ASP.NET State Server service
2. Microsoft SQL Server.
State Server
In a web farm, make sure you have the same in all your web servers.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q3103091
For session state to be maintained across different web servers in the web farm, the application path of the website (for example. \LM\W3SVC\2) in the IIS metabase should be identical in all the web servers in the web farm.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q325056
Make sure objects are serializable. Here in state server session gets serialized and stored in memory in a separate process (aspnet_state.exe). Also if you try to store instance of a class that is not marked as serializable into a session variable, the request returns without an error. However, Asp.net actually fails to save the session data and blocks subsequent requests in the same session. (Because the class is not marked as serializable).
SQL Server
Make sure objects are serializable (as like above).
If you specify integrated security in the connection string (For example "trusted_connection= true", or "integrated security=sspi") it won't work also if you turn on impersonation in asp.net.
For session state to be maintained across different web servers in the web farm, the application path of the website (for example. \LM\W3SVC\2) in the IIS metabase should be identical in all the webservers in the web farm.
Using SQL Server to Store ASP.NET Session State:
Run the InstallSqlState.sql script on the Microsoft SQL Server where you intend to store session state. This script will create the necessary database and database objects.
The .NET Framework installs this script in the same folder as its compilers and other tools.
For example: C:\WINNT\Microsoft.NET\Framework\v1.0.3705 on a Windows 2000 computer with the 1.0 version of the Framework.
Edit the sessionState element in the web.config file for your ASP.NET application as follows:
SqlConnectionString = "data source=SERVERNAME; user id=sa; password=sa"
cookieless="false" timeout="20" />
Supply the server name, user name, and password for a SQL Server account that has access to the session state database in the sqlConnectionString attribute.
Steps to run the InstallSqlState.sql and the UninstallSqlState.sql script files to configure SQL Server mode session state management.
In SQL Query Analyzer, on the File menu, click Open.
In the Open Query File dialog box, browse to the InstallSqlState.sql script file, and then click Open. By default, InstallSqlState.sql is located in one of the following folders:
system drive\Windows\Microsoft.NET\Framework\version\
After InstallSqlState.sql opens in SQL Query Analyzer, click Execute on the Query menu to run the script.
Before you run the UninstallSqlState.sql script file to uninstall SQL Server mode session state management configuration, you must stop the w3svc process. To do this, follow these steps:
• On the Windows Start menu, click Run, type cmd, and then click OK to open a command prompt.
• At the command prompt, type net stop w3svc. You receive confirmation that the w3svc process is stopped.
In SQL Query Analyzer, on the File menu, click Open.
In the Open Query File dialog box, browse to the UninstallSqlState.sql script file, and then click Open. By default, UninstallSqlState.sql is located in one of the following folders:
system drive\Windows\Microsoft.NET\Framework\version\
After UninstallSqlState.sql opens in SQL Query Analyzer, click Execute on the Query menu to run the script.
After you uninstall SQL Server mode session state management configuration, you must restart the w3svc service. To restart the w3svc process, type net starts w3svc at a command prompt.
Security Considerations Sql Server [Session]:
The following aspects need to be kept in mind:
• Use Windows authentication to the database
• Encrypt sqlConnectionString
• Limit the application's login in the database
• Secure the channel
Caching Considerations:
There are three options explained below.
1. Synchronizing all servers in web farm
2. Centralized Cache location to be maintained.
3. SQL server caching
1. Synchronizing all servers in web farm
By providing a wrapper class simply having a CacheControl.aspx receiver page in each of the Applications, it is possible to send a WebRequest to each of the machines (maintained in an easy-to-configure web.config AppSettings element) and have each enabled with code to do its own update "on demand".
So, whenever add a "real" item to the Cache, it will also create a new populated instance of the same class, serialize it into a compact byte stream, and iterate through our server list sending it over the wire via the WebRequest so that each app in the farm, WebGarden, etc can receive and deserialize it, and update its own Cache. Simple, elegant, and fast! Even if it is a complex object such as a class that you have added to your Cache, provided that it is serializable, it will work.
2. Centralized Cache location
One Cache-application is to be created, which will take care of the caching and returning the cached items. And that is to be placed in centralized location. All applications should send the data to be cached, to that cache-application. The Cache-application will store the data. When any application requests the cached
data, it will be retrieved from the Cache-application. (The centralized Cache-application can be called with credentials.)
3. SQL server caching
SQL Server caching is easy to implement by using ADO.NET and the .NET Framework, and it provides a common development model to use with existing data access components. It provides a robust security model that can easily be configured to work across a Web farm using SQL Server replication.
If the application requires cached data to persist across process recycles, reboots, and power failures, in-memory cache is not an option. In such cases, Caching mechanism based on a persistent data store, such as SQL Server or the NTFS file system. It also makes sense to use SQL Server to cache smaller data items to gain persistency.
Because the cache service needs to access SQL Server over a network and the data is retrieved using database queries, the data access is relatively slow. We need to carefully compare the cost of recreating the data versus retrieving it from the database.
NLB(Network Load Balancing):
Network Load Balancing_NLB is a network driver that distributes the load for networked client/server applications across multiple c luster servers. Network Load Balancing works by distributing client requests across a set of servers.
Shopping cart contents at an e-commerce site and Secure Sockets Layer (SSL) authentication data are examples of a client's session state. Network Load Balancing can be used to scale applications that manage session state spanning multiple connections. When its client affinity parameter setting is enabled, Network Load Balancing directs all TCP connections from one client IP address to the same cluster host. This allows session state to be maintained in host memory.
NLB provides the client affinity parameter, which, when enabled, basically makes you "always come back to the server you landed on first", thereby insuring that your Session and Application variables don't get thrown away. Use the client affinity feature. When client affinity is enabled, Network Load Balancing directs all TCP connections to the same cluster host. This allows session state to be maintained in host memory. You can enable client affinity in the Add/Edit Port Rules dialog box in Network Load Balancing Manager. Choose either Single or Class C affinity to ensure that only one cluster host will handle all connections that are part of the same client session. This is important if the server application running on the cluster host maintains session state (such as server cookies) between connections.
Network Load Balancing, a clustering technology included in the Microsoft Windows 2000 Advanced Server and Datacenter Server operating systems, enhances the scalability and availability of mission-critical, TCP/IP-based services, such as Web, Terminal Services, virtual private networking, and streaming media servers. This component runs within cluster hosts as part of the Windows 2000 operating system and requires no dedicated hardware support.
Other Tasks:
Request distribution: Incoming HTTP requests must be distributed among all servers by using a mechanism such as round-robin DNS, Microsoft Application Center 2000, or a third-party load distribution device.
Log aggregation: Before you process HTTP usage logs, it is a good idea to combine the logs to create a single log that includes requests sent to all systems.
Monitoring: To detect problems that affect a single server or the whole site, you must monitor both the external URL for the site and the URLs for each of the Web servers.
Scheduler: Scheduling an event to occur on a single server should cause only that one server to run the task. Scheduling an event to occur on all servers should cause all servers to run the task. [Updations need to be done and should get reflected in all servers hence scheduler should appropriately picked-up]
Centralized database: Web applications that use a database must have a single database that is shared between multiple Web servers. In environments that require no single point of failure, cluster the database server.
Synchronize Configuration and Content:
You need to ensure that the config files are present in the right path on all the servers, and that their contents are continuously in sync.
You can copy configuration files to servers by using any standard file copy or synchronization method, including DFS, the File Replication service, and Microsoft Application Center 2000.
The following batch file will work in environments where each Web server has the virtual server root folder shared as:
wwwroot$: XCOPY \\source-server\wwwroot$ \\destination-server#\wwwroot$\D\E\O\X
When you deploy configuration information and ASP.NET content to multiple servers, it is critical to deploy the content from a single staging server to all production servers at the same time. This reduces the chance of problems occurring when a user's requests are sent to different servers. Microsoft recommends that all configuration and content updates occur on the staging server. Ideally, this staging server does not receive requests from users. It is dedicated to the task of testing and deploying new content.
What is Load-balancing and Do I Need It?
In today’s high tech world, the Internet is quickly becoming a favorite resource for knowledge gathering and entertainment alike. As the owner of a popular website, you may find yourself running into problems because your servers cannot handle the number of visitors to your site. That’s where load-balancing comes in.
Load-balancing, by definition, is dividing the amount of work that a computer has to do between one or more additional computers so that more work gets done in the same amount of time and, in general, all processing get done faster.
Consider this analogy. You own a restaurant, where you currently employ one chef. As your restaurant gains popularity, the chef becomes busier with the preparation for the food for each of your visitors. There will eventually come a time when the stream of customers is too much for your chef to keep up with them. So how do you solve it? You hire a second chef. When a new order comes in, the chef with the smaller load takes it and fills it accordingly. This way, neither of the chefs is bogged down the whole time and all orders are completely quicker. This is the essence of load-balancing.
Why Load Balance?
There are many reasons to institute load-balancing for your website. The two most popular are:
• Response Time – When you institute load-balancing for your website, one of the biggest benefits is the boost you can look forward to in load time. With two or more boxes sharing the load of your web traffic, each of them will be running less of a load than 1 server alone. This means there are more resources available to fulfill your page requests, which in turn, means a zippier website.
• Redundancy – With load-balancing, you inherit a bit of redundancy. For example, if your website is balanced across 3 servers and one of them dies completely, then the other two can keep running and your website visitors will not even notice any downtime. Any load-balancing solution worth its salt will immediately stop trying to send traffic to the down server.
The two reasons alone are an excellent reason for implementing load-balancing across your website(s). There are many more scenarios where this kind of architecture is advantageous, but these usually have the biggest impact.
Designing a Load-balancing Solution
In the world of load-balancing, there are primarily two options to consider when designing your load-balancing solution. These options are a software solution versus a hardware solution. Each of the options has their own requirements, strengths, and weaknesses. It is up to you and your team to evaluate your needs, configuration, and growth path so you can identify the optimal solution to meet your requirements. It is not uncommon for a website to begin with a simpler software solution and eventually grow into the more robust hardware solution.
What is Software Load-balancing?
Many web servers, including the popular Apache Web Server, have built-in support for load-balancing. While using a software configuration to accommodate your load-balancing needs is a less expensive approach than a hardware-centric approach, it tends to be much less robust, and suitable mostly for medium-to-low traffic scenarios.
The most popular software load-balancing solution is called ‘DNS Round Robin’. Simply put, DNS Round Robin sits on a server in front of your web servers, and as requests come in for web pages, it hands them to the next available web server to be processed. In this process, each server is hit sequentially, in turn. So, if you have three boxes on a DNS Round Robin configuration, the sequence of page requests would be server1, sever2, server3, server1, server2… I’m sure you get the picture. Unfortunately, this method of load-balancing does have some limitations:
• There is no way of telling that a skipped server is down or is just busy.
• The type of data requested is not taken into consideration. Images and other supporting files may benefit from sitting on a different server than the ones processing scripting and database logic.
• The server containing DNS Round Robin is a single point of failure. If for some reason this server becomes unavailable, your other servers will never receive any traffic.
• As your site grows and more servers begin to be implemented, this solution becomes more difficult to configure and manage.
There are a number of software load-balancing solutions on the market, but most tend to be geared more to smaller sites and simple networks. The software solutions that can handle the more robust requirements often require a sizable investment in hardware for them to handle the traffic adequately.
What is Hardware Load-balancing?
Hardware load-balancing, as the name implies, takes the approach of using a specially designed piece of equipment to assist in the balancing of your web traffic. These devices, by design, are very robust and able to handle the most mission critical of configurations.
A hardware load-balancing device (HLD) uses many factors to decide how to route traffic to the group of web servers that it maintains. These factors can include the number of connections each machine has, the utilization of the servers, as well as the overall server performance of each. The HLD will examine each of the elements it has been configured to support, and intelligently optimize the load across the servers.
The method used by HLDs is designed to take advantage of all available processing in such a way that the load is shared evenly across the servers, and all web users can have their data served to them in a timely fashion.
Hardware vs. Software – A Comparison
(Page 5 of 6 )
Pros Cons
Software Load-balancing • Less expensive than hardware solutions.
• Some packages have many more configuration and customization options allowing specific tailoring to your needs. • Most packages cannot handle large sites or complex networks.
• Packages that will support larger systems require an abundant amount of hardware.
Hardware Load-balancing • Hardware-centric approach is typically more robust than software options.
• Processes traffic at the network level, which is nominally more efficient than software decryption.
• Work with any OS or platform.
• Higher costs than normally associated with software based solutions.
Conclusion
That covers the basics about load-balancing: what it is, how it works, and why you would want or need it. There are many resources available on the Internet that can go into more the intricate details of hardware and software solutions.
In addition, the rules for load-balancing may change, depending on exactly what it is you are trying to balance. Our discussion here has focused on the assumption that you will be balancing the load across several web servers. But if we had chosen to load balance servers with other tasks, like a mail server or database server, there are many other considerations that must be taken into account. Not all applications are able to be load-balanced, and this will need to be researched on a case-by-case basis.
Deciding on a load-balancing solution for your website can be a very important decision to your site’s continued success. Be sure to analyze your requirements, and make the best decision to fit your website’s current needs, as well as those into the near future. There is nothing more frustrating than setting up a complete system to ensure the availability of your website, and then having to re-engineering your load-balancing architecture after only a few months, which can be both a disappointing AND expensive proposition.
The concept behind the web farm is that a number of different web sites share pooled resources. They typically share a common front-end dispatcher to perform load control and distribute customer requests. They share the multiple web servers themselves.
Scope:
Considering the high volume of traffic the Web site uses two or more servers needed to handle user requests. The concept behind the web farm is that a number of different web sites share pooled resources. They typically share a common front-end dispatcher to perform load control and distribute customer requests. They share the multiple web servers themselves. Based on experience and with reference to Microsoft sites this document was created to address certain issues faced in web farm while using ASP.NET.
Machine Key:
Consider a scenario while doing a PostBack in ASP.NET and which looses the form information.
For Example:
When a user selects an item from a DropDownList and then clicks a submit button, the Click event on the button redirects them to the value of the selected item. This works fine if you are on Webserver1 and the button click PostBacks to Webserver1. If you are on Webserver1 and the load balance submits back to Webserver2, the page reloads and the Button click event never fires. This happen site wide and affects utilities such as submitting a textbox search and other form posting events.
Approach 1
You can modify the pages element in In machine.config of both the servers:
EnableViewStateMac indicates that ASP.NET should run a machine authentication check (MAC) on the page’s view state when the page is posted back from the client;
True - if view state should be MAC checked
False - We need to ensure that it is kept to false.
Approach 2
Force every server in your farm to use the same key; generate a hex encoded 64-bit or 128-bit and put that in each server's machine.config.
You can generate a key from
http://www.eggheadcafe.com/articles/GenerateMachineKey/GenerateMachineKey.aspx
Session Management:
ASP.NET provides two solutions for sharing state information between multiple servers:
1. The ASP.NET State Server service
2. Microsoft SQL Server.
State Server
In a web farm, make sure you have the same in all your web servers.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q3103091
For session state to be maintained across different web servers in the web farm, the application path of the website (for example. \LM\W3SVC\2) in the IIS metabase should be identical in all the web servers in the web farm.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q325056
Make sure objects are serializable. Here in state server session gets serialized and stored in memory in a separate process (aspnet_state.exe). Also if you try to store instance of a class that is not marked as serializable into a session variable, the request returns without an error. However, Asp.net actually fails to save the session data and blocks subsequent requests in the same session. (Because the class is not marked as serializable).
SQL Server
Make sure objects are serializable (as like above).
If you specify integrated security in the connection string (For example "trusted_connection= true", or "integrated security=sspi") it won't work also if you turn on impersonation in asp.net.
For session state to be maintained across different web servers in the web farm, the application path of the website (for example. \LM\W3SVC\2) in the IIS metabase should be identical in all the webservers in the web farm.
Using SQL Server to Store ASP.NET Session State:
Run the InstallSqlState.sql script on the Microsoft SQL Server where you intend to store session state. This script will create the necessary database and database objects.
The .NET Framework installs this script in the same folder as its compilers and other tools.
For example: C:\WINNT\Microsoft.NET\Framework\v1.0.3705 on a Windows 2000 computer with the 1.0 version of the Framework.
Edit the sessionState element in the web.config file for your ASP.NET application as follows:
SqlConnectionString = "data source=SERVERNAME; user id=sa; password=sa"
cookieless="false" timeout="20" />
Supply the server name, user name, and password for a SQL Server account that has access to the session state database in the sqlConnectionString attribute.
Steps to run the InstallSqlState.sql and the UninstallSqlState.sql script files to configure SQL Server mode session state management.
In SQL Query Analyzer, on the File menu, click Open.
In the Open Query File dialog box, browse to the InstallSqlState.sql script file, and then click Open. By default, InstallSqlState.sql is located in one of the following folders:
system drive\Windows\Microsoft.NET\Framework\version\
After InstallSqlState.sql opens in SQL Query Analyzer, click Execute on the Query menu to run the script.
Before you run the UninstallSqlState.sql script file to uninstall SQL Server mode session state management configuration, you must stop the w3svc process. To do this, follow these steps:
• On the Windows Start menu, click Run, type cmd, and then click OK to open a command prompt.
• At the command prompt, type net stop w3svc. You receive confirmation that the w3svc process is stopped.
In SQL Query Analyzer, on the File menu, click Open.
In the Open Query File dialog box, browse to the UninstallSqlState.sql script file, and then click Open. By default, UninstallSqlState.sql is located in one of the following folders:
system drive\Windows\Microsoft.NET\Framework\version\
After UninstallSqlState.sql opens in SQL Query Analyzer, click Execute on the Query menu to run the script.
After you uninstall SQL Server mode session state management configuration, you must restart the w3svc service. To restart the w3svc process, type net starts w3svc at a command prompt.
Security Considerations Sql Server [Session]:
The following aspects need to be kept in mind:
• Use Windows authentication to the database
• Encrypt sqlConnectionString
• Limit the application's login in the database
• Secure the channel
Caching Considerations:
There are three options explained below.
1. Synchronizing all servers in web farm
2. Centralized Cache location to be maintained.
3. SQL server caching
1. Synchronizing all servers in web farm
By providing a wrapper class simply having a CacheControl.aspx receiver page in each of the Applications, it is possible to send a WebRequest to each of the machines (maintained in an easy-to-configure web.config AppSettings element) and have each enabled with code to do its own update "on demand".
So, whenever add a "real" item to the Cache, it will also create a new populated instance of the same class, serialize it into a compact byte stream, and iterate through our server list sending it over the wire via the WebRequest so that each app in the farm, WebGarden, etc can receive and deserialize it, and update its own Cache. Simple, elegant, and fast! Even if it is a complex object such as a class that you have added to your Cache, provided that it is serializable, it will work.
2. Centralized Cache location
One Cache-application is to be created, which will take care of the caching and returning the cached items. And that is to be placed in centralized location. All applications should send the data to be cached, to that cache-application. The Cache-application will store the data. When any application requests the cached
data, it will be retrieved from the Cache-application. (The centralized Cache-application can be called with credentials.)
3. SQL server caching
SQL Server caching is easy to implement by using ADO.NET and the .NET Framework, and it provides a common development model to use with existing data access components. It provides a robust security model that can easily be configured to work across a Web farm using SQL Server replication.
If the application requires cached data to persist across process recycles, reboots, and power failures, in-memory cache is not an option. In such cases, Caching mechanism based on a persistent data store, such as SQL Server or the NTFS file system. It also makes sense to use SQL Server to cache smaller data items to gain persistency.
Because the cache service needs to access SQL Server over a network and the data is retrieved using database queries, the data access is relatively slow. We need to carefully compare the cost of recreating the data versus retrieving it from the database.
NLB(Network Load Balancing):
Network Load Balancing_NLB is a network driver that distributes the load for networked client/server applications across multiple c luster servers. Network Load Balancing works by distributing client requests across a set of servers.
Shopping cart contents at an e-commerce site and Secure Sockets Layer (SSL) authentication data are examples of a client's session state. Network Load Balancing can be used to scale applications that manage session state spanning multiple connections. When its client affinity parameter setting is enabled, Network Load Balancing directs all TCP connections from one client IP address to the same cluster host. This allows session state to be maintained in host memory.
NLB provides the client affinity parameter, which, when enabled, basically makes you "always come back to the server you landed on first", thereby insuring that your Session and Application variables don't get thrown away. Use the client affinity feature. When client affinity is enabled, Network Load Balancing directs all TCP connections to the same cluster host. This allows session state to be maintained in host memory. You can enable client affinity in the Add/Edit Port Rules dialog box in Network Load Balancing Manager. Choose either Single or Class C affinity to ensure that only one cluster host will handle all connections that are part of the same client session. This is important if the server application running on the cluster host maintains session state (such as server cookies) between connections.
Network Load Balancing, a clustering technology included in the Microsoft Windows 2000 Advanced Server and Datacenter Server operating systems, enhances the scalability and availability of mission-critical, TCP/IP-based services, such as Web, Terminal Services, virtual private networking, and streaming media servers. This component runs within cluster hosts as part of the Windows 2000 operating system and requires no dedicated hardware support.
Other Tasks:
Request distribution: Incoming HTTP requests must be distributed among all servers by using a mechanism such as round-robin DNS, Microsoft Application Center 2000, or a third-party load distribution device.
Log aggregation: Before you process HTTP usage logs, it is a good idea to combine the logs to create a single log that includes requests sent to all systems.
Monitoring: To detect problems that affect a single server or the whole site, you must monitor both the external URL for the site and the URLs for each of the Web servers.
Scheduler: Scheduling an event to occur on a single server should cause only that one server to run the task. Scheduling an event to occur on all servers should cause all servers to run the task. [Updations need to be done and should get reflected in all servers hence scheduler should appropriately picked-up]
Centralized database: Web applications that use a database must have a single database that is shared between multiple Web servers. In environments that require no single point of failure, cluster the database server.
Synchronize Configuration and Content:
You need to ensure that the config files are present in the right path on all the servers, and that their contents are continuously in sync.
You can copy configuration files to servers by using any standard file copy or synchronization method, including DFS, the File Replication service, and Microsoft Application Center 2000.
The following batch file will work in environments where each Web server has the virtual server root folder shared as:
wwwroot$: XCOPY \\source-server\wwwroot$ \\destination-server#\wwwroot$\D\E\O\X
When you deploy configuration information and ASP.NET content to multiple servers, it is critical to deploy the content from a single staging server to all production servers at the same time. This reduces the chance of problems occurring when a user's requests are sent to different servers. Microsoft recommends that all configuration and content updates occur on the staging server. Ideally, this staging server does not receive requests from users. It is dedicated to the task of testing and deploying new content.
What is Load-balancing and Do I Need It?
In today’s high tech world, the Internet is quickly becoming a favorite resource for knowledge gathering and entertainment alike. As the owner of a popular website, you may find yourself running into problems because your servers cannot handle the number of visitors to your site. That’s where load-balancing comes in.
Load-balancing, by definition, is dividing the amount of work that a computer has to do between one or more additional computers so that more work gets done in the same amount of time and, in general, all processing get done faster.
Consider this analogy. You own a restaurant, where you currently employ one chef. As your restaurant gains popularity, the chef becomes busier with the preparation for the food for each of your visitors. There will eventually come a time when the stream of customers is too much for your chef to keep up with them. So how do you solve it? You hire a second chef. When a new order comes in, the chef with the smaller load takes it and fills it accordingly. This way, neither of the chefs is bogged down the whole time and all orders are completely quicker. This is the essence of load-balancing.
Why Load Balance?
There are many reasons to institute load-balancing for your website. The two most popular are:
• Response Time – When you institute load-balancing for your website, one of the biggest benefits is the boost you can look forward to in load time. With two or more boxes sharing the load of your web traffic, each of them will be running less of a load than 1 server alone. This means there are more resources available to fulfill your page requests, which in turn, means a zippier website.
• Redundancy – With load-balancing, you inherit a bit of redundancy. For example, if your website is balanced across 3 servers and one of them dies completely, then the other two can keep running and your website visitors will not even notice any downtime. Any load-balancing solution worth its salt will immediately stop trying to send traffic to the down server.
The two reasons alone are an excellent reason for implementing load-balancing across your website(s). There are many more scenarios where this kind of architecture is advantageous, but these usually have the biggest impact.
Designing a Load-balancing Solution
In the world of load-balancing, there are primarily two options to consider when designing your load-balancing solution. These options are a software solution versus a hardware solution. Each of the options has their own requirements, strengths, and weaknesses. It is up to you and your team to evaluate your needs, configuration, and growth path so you can identify the optimal solution to meet your requirements. It is not uncommon for a website to begin with a simpler software solution and eventually grow into the more robust hardware solution.
What is Software Load-balancing?
Many web servers, including the popular Apache Web Server, have built-in support for load-balancing. While using a software configuration to accommodate your load-balancing needs is a less expensive approach than a hardware-centric approach, it tends to be much less robust, and suitable mostly for medium-to-low traffic scenarios.
The most popular software load-balancing solution is called ‘DNS Round Robin’. Simply put, DNS Round Robin sits on a server in front of your web servers, and as requests come in for web pages, it hands them to the next available web server to be processed. In this process, each server is hit sequentially, in turn. So, if you have three boxes on a DNS Round Robin configuration, the sequence of page requests would be server1, sever2, server3, server1, server2… I’m sure you get the picture. Unfortunately, this method of load-balancing does have some limitations:
• There is no way of telling that a skipped server is down or is just busy.
• The type of data requested is not taken into consideration. Images and other supporting files may benefit from sitting on a different server than the ones processing scripting and database logic.
• The server containing DNS Round Robin is a single point of failure. If for some reason this server becomes unavailable, your other servers will never receive any traffic.
• As your site grows and more servers begin to be implemented, this solution becomes more difficult to configure and manage.
There are a number of software load-balancing solutions on the market, but most tend to be geared more to smaller sites and simple networks. The software solutions that can handle the more robust requirements often require a sizable investment in hardware for them to handle the traffic adequately.
What is Hardware Load-balancing?
Hardware load-balancing, as the name implies, takes the approach of using a specially designed piece of equipment to assist in the balancing of your web traffic. These devices, by design, are very robust and able to handle the most mission critical of configurations.
A hardware load-balancing device (HLD) uses many factors to decide how to route traffic to the group of web servers that it maintains. These factors can include the number of connections each machine has, the utilization of the servers, as well as the overall server performance of each. The HLD will examine each of the elements it has been configured to support, and intelligently optimize the load across the servers.
The method used by HLDs is designed to take advantage of all available processing in such a way that the load is shared evenly across the servers, and all web users can have their data served to them in a timely fashion.
Hardware vs. Software – A Comparison
(Page 5 of 6 )
Pros Cons
Software Load-balancing • Less expensive than hardware solutions.
• Some packages have many more configuration and customization options allowing specific tailoring to your needs. • Most packages cannot handle large sites or complex networks.
• Packages that will support larger systems require an abundant amount of hardware.
Hardware Load-balancing • Hardware-centric approach is typically more robust than software options.
• Processes traffic at the network level, which is nominally more efficient than software decryption.
• Work with any OS or platform.
• Higher costs than normally associated with software based solutions.
Conclusion
That covers the basics about load-balancing: what it is, how it works, and why you would want or need it. There are many resources available on the Internet that can go into more the intricate details of hardware and software solutions.
In addition, the rules for load-balancing may change, depending on exactly what it is you are trying to balance. Our discussion here has focused on the assumption that you will be balancing the load across several web servers. But if we had chosen to load balance servers with other tasks, like a mail server or database server, there are many other considerations that must be taken into account. Not all applications are able to be load-balanced, and this will need to be researched on a case-by-case basis.
Deciding on a load-balancing solution for your website can be a very important decision to your site’s continued success. Be sure to analyze your requirements, and make the best decision to fit your website’s current needs, as well as those into the near future. There is nothing more frustrating than setting up a complete system to ensure the availability of your website, and then having to re-engineering your load-balancing architecture after only a few months, which can be both a disappointing AND expensive proposition.
Comments
Post a Comment