Windows Server 2008 High Availability : Load Balancing (part 2) - Load-Balancing Hardware & Load Balancing and SharePoint Farm Topology

Load-Balancing Hardware

Hardware load balancers are specialized networking applications designed to route traffic to certain individual servers in a network. You can configure hardware load balancers to distribute network traffic across multiple servers based on a variety of conditions such as connection volume, bandwidth utilization, processor utilization, and overall server performance. Software load balancers add an additional task load to the servers in the cluster on top of their normal tasks, such as generating the load-balanced content. Hardware load balancers, on the other hand, are specialized hardware devices whose sole responsibility is distributing traffic to their constituent servers according to their configuration. They are designed, engineered, and tested to efficiently and flexibly spread network traffic across the servers clustered beneath them.

The most obvious benefit to the use of a hardware load balancer is the reduction of workload on your servers compared to Windows NLB. Because the servers are not responsible for establishing and managing the NLB cluster, those free cycles can be allocated to other responsibilities, such as generating and serving content. Hardware load balancers also offer a variety of configuration and management options, although options do vary from manufacturer to manufacturer. Traffic destinations can be determined by affinity, server workload, bandwidth availability, geographic location, and several other factors. Clusters can span network subnets or even datacenters. Servers can be automatically or manually removed from active service depending on a range of criteria such as failure to respond or errors being displayed in requested content. Hardware load balancers are offered by several network hardware vendors, including Cisco, F5, Juniper, Coyote Point Systems, Barracuda Networks, and many more. Each vendor has its own feature sets, capabilities, and limitations. You should work with your organization’s network administrator(s) to determine the hardware solution that is the best fit for your needs if you decide to use a hardware load balancer.

Load-Balancing Hardware and SharePoint

Much like Windows NLB, hardware load-balancing is going to be most effective for a Share-Point farm when its affinity settings are configured to meet the farm’s most prevalent usage pattern, such as making sessions sticky when data needs to be maintained across server calls or stateless when transactions are anonymous. This is a universal requirement that should be tested and implemented (when testing shows that it is beneficial) whenever possible. One difference between hardware load balancers and Windows NLB is that the Unicast/Multicast operating modes are functions unique to NLB; there may be hardware solutions that offer similar functionality or drawbacks. You should review their documentation and conduct your own testing to determine the behavior of that functionality.

SharePoint is supported on most, if not all, hardware load-balancing solutions, so it is ultimately up to you and your network administrators to determine which solution is right for you. When evaluating a hardware load balancer, do not make your choice simply based on the load-balancing functionality of the devices. Also consider each candidate’s manageability and flexibility, because networking administration (especially for Web server-based solutions like SharePoint) is a fluid and ever-changing responsibility. Your hardware load balancer should be able to quickly enable configuration changes, effectively identify status changes in the servers beneath it, and make your life as a SharePoint administrator easier, not harder.

As SharePoint’s sales and popularity have grown, so has the need to deliver it to end users efficiently and consistently. This has not gone unnoticed by the manufacturers of hardware load balancers; several have begun to provide information, guidance, and configurations specifically geared toward the load balancing of SharePoint content with their products. This is great news for SharePoint administrators, because it means that the manufacturers have taken care of the extensive testing and monitoring activities necessary to find the configuration sweet spot for running SharePoint behind their devices. This allows you to quickly and often drastically improve the performance of your SharePoint environment with reduced risk to your service quality.

You should still exercise caution when considering a hardware load-balancing device optimized for SharePoint, because the gains in stability and functionality offered by these products can vary drastically depending on the configuration of your SharePoint environment and its network. If your SharePoint servers and the client workstations accessing your SharePoint site have high-bandwidth connections, you may not see performance gains worth the cost of implementing a SharePoint-optimized load balancer. This is because many manufacturers have focused on situations where network configurations lead to smaller or slower pipes for data to flow through, such as WAN connections. Connection speeds for WANs, which often use public communication links to connect local area networks (LANs) across multiple geographic locations, can pale in comparison to LANs.

It is easy to understand, given the connection limitations WANs face and the amount of network traffic that an active SharePoint site can generate, why this is a main area of focus for manufacturers. But if your network does not use or include WAN connections, you may not see large performance gains when using a SharePoint-optimized load-balancing device. Does this mean you shouldn’t use such a device in your network? Not at all. It’s just that you need to evaluate the reasons and requirements for load-balancing devices, along with the possible avenues of growth your network might follow, and select your resources accordingly. If your environment is not likely to include WAN connections and there is a more affordable device available that offers all the load-balancing capabilities you need, it is probably a better choice than an expensive purchase for technology that you are not going to see much benefit from.

Advantages of Hardware Load Balancing and SharePoint

Because hardware load balancers usually run on computing devices specifically devoted to providing load-balancing capabilities to a network, they are generally more stable and reliable than NLB. NLB has to run on your SharePoint WFE servers, so it is using computing resources that are tasked with a variety of functions. This in turn can lead to contention and impact the performance of an NLB cluster. But because hardware load balancers do not face the same competition for resources, they are more stable and offer better performance.

Hardware load balancers also offer a much wider range of functionality and features than what’s available in NLB. Depending on what the manufacturer of a specific device decides to include in it, you may have options for securing, compressing, or caching traffic sent through the device, not present in NLB. Also, hardware load balancers often can better identify and respond to errors, such as routing traffic away from failed nodes without an outage, or enabling a predetermined static error page should all of a cluster’s nodes become unavailable.

Drawbacks of Hardware Load Balancing and SharePoint

Just as cost is an advantage for NLB, the high cost of purchasing specialized hardware is a definite drawback for hardware load balancing. The good news is that this is a diverse marketplace with offerings filling a broad range of price points, and feature sets to match those costs. For some budget-minded organizations, it might be awfully difficult to get away from a comparison of potentially high costs against NLB’s price tag of $0.00.

Adding a hardware load balancer to your environment also means that you need to integrate yet another component from yet another manufacturer into your environment, adding to its overall complexity and making it more difficult to manage. Manufacturers often implement unique, proprietary hardware components and setups to add to their ability to differentiate their products and lock customers into their solutions. These dependencies can make it more difficult to manage your SharePoint environment in general, not to mention your HA solutions in particular.

Finally, not all hardware load-balancing options offer the advanced error detection and handling capabilities mentioned earlier, which means your environment could face the same kind of risks NLB clusters do because they lack this functionality. Regardless of the load-balancing solution you choose, make certain that you understand exactly what it can and cannot do; optimally, you’ll be able to mitigate those risks via other tools or procedures, but at a minimum you need to be aware of what they are.

Load Balancing and SharePoint Farm Topology

Implementing load balancing to distribute traffic across multiple resources within your Share-Point farm can positively impact the performance of your servers and, most importantly, the end user experience. It can also ensure that your environment can withstand the loss of a server within the farm by sharing the load between multiple resources. But you don’t achieve that benefit simply by adding more servers to your environment, installing SharePoint on them, and adding them to an NLB cluster. You need to understand not only the areas within your Share-Point farm where load balancing can be advantageous, but where it provides little to no value and where it can actually be detrimental to the health of your system. Not only that, but Share-Point 2010 introduces a new approach to scalability with the Service Application model (which replaces the SharePoint 2007 concept of Shared Service Providers, or SSPs); allowing you to architect a much more highly available solution for your entire SharePoint environment, not just your Web servers or SQL Server instances.

The WFE Role

The most obvious item within your farm that benefits from load balancing is the WFE role, which is responsible for serving SharePoint’s Web pages, content, and functionality to your end users. If you have a large user base who frequently visit your SharePoint sites or you need to make sure that your content is always online and available, you will most certainly want to load-balance your WFEs.

One interesting thing that Microsoft discovered in SharePoint 2007 about load-balancing WFE servers is that there is a point where the performance of your environment flattens as you insert additional WFEs to scale out the farm. Microsoft conducted extensive testing of how SharePoint 2007 performs under extremely heavy loads, for a variety of typical use cases. Although Microsoft has made a great deal of information about the product available well ahead of its release, the problem with SharePoint 2010 being such a new product is that there just has not been enough time to do the same kind of capacity performance testing with the final version of the product.

To its credit, Microsoft has been working to deliver this content with the launch of SharePoint 2010, but it is not fully released for all of SharePoint’s numerous use cases. At the time this book is being written, Microsoft has released case and lab studies that examine the performance metrics of large-scale SharePoint environments focused on collaborative activities, SharePoint’s most common use. Much as in SharePoint 2007, these studies show that in a SharePoint 2010 collaborative environment, there is a definitive point where performance gains flatten out as new WFEs are added to a load-balanced farm. The flattening tends to occur when a fourth WFE is added to a farm. After that point, there was no value in adding additional WFEs. Beyond the fourth WFE, performance was being constrained by CPU utilization on the SQL Server instance hosting SharePoint’s databases, not SharePoint itself. If you would like more information on Microsoft’s testing approach and findings with SharePoint 2010’s capacity and performance limitations, head to the Capacity Management for SharePoint Server 2010 Resource Center on TechNet, at http://technet.microsoft.com/en-us/sharepoint/ff601870.aspx. It is an outstanding repository that is sure to have new content on the subject of SharePoint 2010 capacity planning added on a regular basis and well worth a look.

If you are planning a large implementation of SharePoint, test your configuration on its own so that you can determine your performance baseline and whether it’s going to meet your needs. Performance may vary depending on a variety of factors, as follows:

• Network configuration. The unique configuration of your network and its hardware may provide you with performance metrics that vastly differ from Microsoft’s.

• Hardware configuration. The unique configuration of your server hardware may also provide you with performance metrics that vastly differ from Microsoft’s.

• Caching configuration. Configuring your farm’s servers and content to leverage caching functionality can drastically improve the performance of your Web servers.

• Farm usage scenarios. A farm intended for internal collaboration and knowledge sharing by authenticated users is going to perform differently from a farm intended for Web content management and anonymous users.

Adding More Servers to a SharePoint Farm

Because load balancing is common for SharePoint to improve performance, Microsoft has made the process to add additional servers to a SharePoint farm easy and straightforward. The SharePoint installer should be run on the server to be added to the farm, using the same accounts and configuration as the rest of the servers in the farm, making sure to do a Complete Advanced installation. Once the installer finishes, the SharePoint Products and Technologies Configuration Wizard starts up. Walk through the wizard, making sure to select the Connect to an Existing Farm option, and then connect to the configuration database for the existing farm. Confirm that the server is not set to host the farm’s Central Administration site (unless you have a specific requirement to create a redundant site), and complete the wizard. Log into the Central Administration site, and configure the server with the WFE role that it should play in the farm.

Service Applications

In Microsoft Office SharePoint Server (MOSS) 2007, Microsoft introduced the concept of SSPs, applications within a farm designed to provide specialized services—such as My Sites, Search, and User Profiles—to multiple Web applications within the farm. SSPs were helpful in that they allowed common functionality to be used consistently across sites and Web applications in the farm, but the approach was not without its drawbacks. SSPs were often difficult to manage, especially in large farms, and they were a challenge to protect from a DR standpoint. In the case of Search specifically, SSPs represented a single point of failure because only a single server could be designated for operation in the Index Server role for a given SharePoint Search index.

Microsoft has revamped its approach to these types of applications in SharePoint 2010 by retiring the concept of an SSP and introducing the Service Application model. It also applies to both SharePoint Foundation 2010 and SharePoint Server 2010 instead of just the server product. Microsoft has designed the Service Application model to build on the direction taken by the SSP approach while addressing some of its shortcoming and drawbacks. Service Applications are designed to provide scalability to your SharePoint farm, give administrators greater control over which services are delivered to SharePoint resources, and allow third-party vendors to create their own custom Service Applications to enhance and extend the functionality available through a SharePoint environment.

The big reason that Microsoft’s change from SharePoint 2007’s SSP model to SharePoint 2010’s Service Application model makes such a difference is in how it handles load. With SharePoint 2007, applications within the SSP were often difficult to scale out as usage increased. Some applications, such as Excel Services, required careful consideration and configuration to set up for large environments or high availability. Search in SharePoint 2007 was an even more frustrating story: the Index server role could not be spread across multiple servers, making it a single point of failure.

In a multiserver SharePoint 2010 farm, Microsoft recommends that Service Applications are hosted on dedicated application servers (giving the farm a three-tier hierarchy, with the other tiers consisting of WFEs and SQL Server hosts). These application servers host the Service Applications and respond to requests made by the client applications hosted by the farm’s WFEs to deliver their functionality. If the farm has multiple application servers, it is not necessary to configure a load-balanced cluster (via NLB or a hardware load balancer) as it would be for a farm with multiple WFEs. Instead, Microsoft has built a simple round-robin load balancer into its Service Application Framework that distributes traffic across each application server automatically.

Search Roles

The one piece of SharePoint most impacted by the new Service Application model in SharePoint Server 2010 is Search. SharePoint’s Search capabilities have always been a highly touted aspect of the platform, and that’s no different in 2010, featuring lots of new features and functionality for end users. But with this new release also comes a much better story around the idea of making SharePoint’s Search infrastructure pieces highly available. This simply wasn’t possible in MOSS 2007 due to the inflexible nature of the Index server role, but SharePoint Server 2010 gives you a great deal of flexibility and scalability.

SharePoint servers in a farm can serve a few different roles to add performance and functionality to the farm’s search capabilities. The two listed server roles affiliated with searching in a Share-Point farm are the Crawl server role (known as the Index server in MOSS 2007) and the Query server role. Crawl servers are responsible for generating the farm’s search index by crawling the target content sources and building the index with the results of that crawl. Query servers are tasked with the processing required to execute all requested queries against a copy of the farm’s search index stored locally on the Query server. In SharePoint 2010, you can assign both the Crawl server and Query server roles to multiple servers within a farm, allowing for redundancy and load distribution of SharePoint’s Search functionality.

A Crawl server must be associated with a single Crawl database; this database specifies the content that the Crawl server must crawl to build its assigned index. This relationship allows for Search indexing to be constructed for both redundancy and scalability, as desired. You can add redundancy to a farm’s Search crawls by associating multiple Crawl servers with a single Crawl database so that if one Crawl server becomes unavailable, a replacement is available to continue indexing the Crawl database’s designated content. If you want to improve the performance of the crawl activities, you can create additional crawl databases. This allows you to separate the crawl content between databases so that multiple Crawl servers can process and crawl it in parallel.

Query servers respond to search queries submitted by end users on WFE servers and return results using the Search index generated by the farm’s Crawl servers. If a single server in the farm is configured with the Query role, a copy of the entire index is stored in the Query server’s file system. If a farm has multiple Query servers, each Query server receives an index partition, or a portion of the overall index. By default, the distribution of index partitions is based on the number of Query servers in a farm, but administrators can manually specify the number of index partitions that are created and how they are distributed. In the case of two Query servers, for example, each server stores an index partition equal to half the index. If there are four Query servers, each server stores an index partition containing 25 percent of the overall index. This approach allows for redundancy (if one of many Query servers in a farm goes down, the index partitions can be redistributed to cover the outage) and may improve performance as additional Query servers are added to a farm.

This new Search architecture also allows for entire SharePoint Server 2010 farms dedicated to crawling content and responding to search queries. This is typically only a consideration in large, often global, SharePoint deployments, but it does add versatility in search scenarios that were often troublesome in MOSS 2007.