Load Balancing and Clustering in EPiServer

Transcription

1 Load Balancing and Clustering in EPiServer Abstract This white paper describes the main differences between load balancing and clustering, and details EPiServer's possibilities of existing in a clustered infrastructure. Product version: 4.50 Document version: 1.0

2 2 Load Balancing and Clustering in EPiServer Table of Contents INTRODUCTION 3 CLUSTERING AND LOAD BALANCING 3 Clustering 3 Load Balancing 4 Combine Clustering and Load Balancing 4 CONFIGURATION OF THE ENVIRONMENT 5 EPISERVER IN A CLUSTERED ENVIRONMENT 5 Files 5 Cache 5 Schedules 6 Access Rights and Authorities 6 CONCLUSION 6 APPENDIX LOAD BALANCING CASE STUDY 7 System Overview 7 Network Load Balancing Manager 7 File Replication via Distributed File System 8 Installation 9 EPiServer Configuration 10 Performance Tests 11 The contents of this document are protected by copyright. Changes to the content or partial copying of the content may not be carried out without permission from ElektroPost Stockholm AB. The document may be freely distributed in its entirety, either digitally or in printed format, to all EPiServer users. EPiServer is a registered trademark of ElektroPost Stockholm AB. Other product and company names mentioned in this document may be the trademarks for their respective owners.

3 Introduction 3 Introduction Load balancing is often required when building solutions that handle large volumes of client requests or that have high demands on security and redundancy. EPiServer fully supports load balancing, for session handling, cache and common files. For more technically detailed information about EPiServer, see EPiServer Operator's Guide. See Microsoft's Web site for information about clustering in the Windows environment. Note A standard EPiServer installation is normally enough from a performance point of view. Load balancing is only required when the Web site experiences very heavy traffic. Clustering and Load Balancing There is some confusion surrounding the concepts clustering and load balancing. This chapter concentrates on defining the differences between the two technologies. Clustering Clustering is an alternative when it is important to minimize downtime and high redundancy in a solution, and is preferably used in business-critical applications, such as databases and servers. Reliability is high in a clustered solution; at least one server handles the incoming requests for the clients and fetches its data from a common disk, which is accessible from the other servers in the cluster. If the active server fails for some reason, another server in the cluster takes over the requests without it greatly affecting the end users. This process is called failover. A server cluster is a collection of physically independent servers with one collective storage area. Clustered servers are physically connected to each other with cables, and are logically connected with the cluster software. The clusters do not need to have identical hardware or configuration. Clients sending requests to the cluster see the cluster as one unit, where it is not possible to differentiate between the different nodes. Figure 1 Clustering services secure availability by letting one of the servers take over from another server at failover.

4 4 Load Balancing and Clustering in EPiServer Load Balancing Load balancing or Network Load Balancing (NLB), which distributes incoming traffic through a network of connected servers, should be seen as a complement to clustering. Load balancing balances the load of incoming network traffic and distributes the requests to the servers that best can handle them. Load balancing is mainly used for scalability and performance reasons. If you want to scale the solution, new servers can be added to the cluster as required. In a load-balanced environment, you set up at least 2 servers that handle incoming requests from the clients. Figure 2 The load balancing distributes incoming requests to a group of servers. Combine Clustering and Load Balancing Large scalable system solutions can be built using both clustering and load balancing, by balancing the loads in a so-called Web server farm and building a cluster of the mission-critical systems, e.g. the database. This results in high availability for the database and high scalability for Web servers.

5 Configuration of the Environment 5 Configuration of the Environment Configuration and dimensions of a cluster for EPiServer is unique for every customer. Some of the factors that can affect this are, for example, expected workload, required reply times, and calculated time for unplanned downtime. These areas are not covered in this document. Further information about this can be found on Microsoft's home page for clustering services, It is important to note that SQL servers can only support clustering and cannot be load-balanced. You should, therefore, plan for upgradeable hardware, if you expect the workload on the database to be high. EPiServer in a Clustered Environment When building a load-balanced EPiServer solution, the Web servers and database must be stored separately, as SQL Server cannot be load-balanced. Refer to EPiServer Operator's Guide for information on how to configure EPiServer to support load balancing, with reference to caching and file management. Files To avoid different file setups, set up the Web site so that the Web servers read files, documents, etc. from a common file server, which also serves as an upload area for editors. Cache As soon as the cache is changed on one of the servers in the cluster, the other servers in the cluster must also be notified of the change and update their own cache. For this reason, each server in the cluster must know about the other servers. These notifications occur via Web service requests between Web services in the cluster. The other nodes in the cluster are registered in web.config. For further information on how authorization and cache notifications are configured, refer to the EPiServer Technical Notes, and EPiServer Operator's Guide.

6 6 Load Balancing and Clustering in EPiServer Schedules In order to avoid collision between the scheduling services on the nodes in the load-balanced cluster, the list with command jobs is checked in the common database. This means that "first come, first served" applies for the different processes. It is also possible to let the scheduler exist on only one node, but then the objects must be identical on the different nodes. Access Rights and Authorities For access rights to work correctly and for all the nodes in the cluster to have access to the common file area, it is necessary to let the ASPNET account run under a user account with access rights to the common file area, so-called impersonation. This is achieved by changing the following in web.config: <identity impersonate="true" username="domain\user" password="pass"/> With this line included, all the anonymous users will be run under the stated account, which will then have access rights to the common file area. Conclusion EPiServer works well in a Windows environment with Clustering Services from Microsoft, from both a performance and scalability point of view. The best results are achieved after careful preparation with the organization, so that the load-balanced environment is configured to best meet the expected workload and security requirements. Experience tells us that a standard EPiServer installation is, in most cases, enough to handle heavy user workload. Clustering and load balancing can be used as a complement, when customers have high demands on performance and redundancy.

7 Appendix Load Balancing Case Study 7 Appendix Load Balancing Case Study System Overview In this case study we have used an environment containing Microsoft Windows Server The clustered Web servers are installed with Windows Server 2003 Web Edition and the domain controller has Windows Server 2003 Standard Edition. All the machines are based on a CPU of 1.3 GHz. Network Load Balancing Manager Network Load Balancing Manager is used to configure and monitor load balancing. In this case study, we have created a virtual IP address ( ). The two machines included in the cluster have their own IP address ( and ).

8 8 Load Balancing and Clustering in EPiServer NOTES: 1. One of the nodes in the cluster is always master. When a server crashes, another node in the cluster will take over the role as master. 2. If the service for IIS is switched off on one of the nodes, the cluster will not react. The entire node must be taken out of the cluster for maintenance. File Replication via Distributed File System To ensure that templates and uploaded files are identical on all the nodes in the cluster, there must either be a common area for files, or the files must be replicated to other nodes in the cluster. In this case study, we have chosen the latter solution with Distributed File System (DFS). With DFS it is possible to replicate both files and directories in real-time, as well as being possible to exclude files and directories, for example web.config, which must be unique for the node in question. DFS requires

9 Appendix Load Balancing Case Study 9 Active Directory, which is why we have also installed a primary domain controller (PDC) in this solution. NOTES: 1. In DFS it is possible to set up one or more replications, i.e. it is possible to synchronize entire Web sites or only parts of it, like /upload and /templates. The configuration file web.config must always be excluded, as it must be unique for each node in the cluster. 2. In the case study we also tested connection to normal file sharing, for example, common storage, which also worked. If the server with the shared directory were to fail, there would be obvious consequences for the other nodes in the cluster. This would not be the case with file replication. Installation We installed EPiServer 4.11 on both nodes in the cluster. It is important to manually reconfigure the settings for authorization, as DFS also synchronizes local access rights. The local accounts must be converted to the domain account this mainly applies to NETWORK_SERVICE (ASPNET in Windows 2000) and allow Execute and IUSR_XXX to allow anonymous access. A local group is created on each node in the cluster and it is important that they all have the same name. The domain account is then placed in the new group. Then the domain account is added to the group IIS_WPG. File access rights are finally set to the local groups. Firstly we changed the access rights by selecting Replace existing from the root directory for the Web sites that are not a master. Then we ran EPiServer Configuration Tool and edited the XML file, so that the necessary access rights were given for the domain account. EPiServer Configuration Tool can be downloaded from It is important that MachineKey is the same for all nodes in the cluster. Otherwise login can be requested when different Web servers in the cluster have different keys for signing data. This also effects functions like forms logon, ViewState and session management. The key is created and placed in machine.config.

10 10 Load Balancing and Clustering in EPiServer NOTES: 1. Copy the Web sites that are not to be master in the cluster at installation, (especially web.config). At replication, the entire Web site is synchronized from one master, which results in web.config being written over and the access rights becoming incorrect. 2. IIS_WPG (Internet Information Services Worker Process Group) requires certain Read access rights to the [windir]\temp directory. Otherwise, Web Services will not work correctly, and this is blocked as standard in Windows Server EPiServer Configuration Add the key EPsCacheListener in web.config on all the nodes in the cluster. This makes the nodes react to change and replicate changes in the local cache to other nodes in the cluster. Note that WEB1 should only have WEB2 in this field, and the opposite for WEB2, so that the respective Web servers do not update themselves. This field can also include a comma-separated list, if there are more than 2 servers in the cluster. Go to Remote Web sites in EPiServer Admin mode to set up the Web sites. All the Web sites should have the same name, e.g. WEB. This is so that the cache will know that all the pages belong to the same Web site. Two virtual Web sites, e.g. WEB1 and WEB2, are created after this, so that the nodes in the cluster can reach each other.

11 Appendix Load Balancing Case Study 11 NOTES: 1. It is important that the name of the Web sites are written correctly. 2. Dynamic properties are not synchronized in version 4.11, but this will be changed in future versions. Performance Tests We have used Application Center Test (ACT), which is included in Visual Studio.NET for performance tests. TEST CASE 1 All the page types in the Web site where called individually (without logon). This resulted in a reply frequency of 70 RPS (requests per second). Both of the nodes in the cluster were loaded equally and work at maximum with 100% CPU workload. If one of the machines is removed from the cluster, the reply frequency decreases to approx. 35 RPS, which is as expected. Note Only one connection is used in the test, but this nevertheless results in the traffic being distributed to both nodes, which is preferred. TEST CASE 2 Only calling the start page, which has more content than most pages, results in a reply frequency of 50 RPS. Both of the machines have 100% CPU workload. When we close down one IIS on one of the nodes in the cluster, we receive an HTTP error, The page cannot be found. The reply frequency decreases to 3-5 RPS. This means that a dead IIS process does not remove the node from the cluster. This node will, however, continue to receive calls, which it does not reply to, resulting in the test process being extremely slow, as it sends the calls after one another in the test script. The second node is, in this case, hardly loaded at all. If, however, you remove the node from the cluster, all traffic is directed to the second node in the cluster. The reply frequency is also halved in this case, which is the expected result, and indicates that performance increases in line with the node's hardware.

12 12 Load Balancing and Clustering in EPiServer Note When you remove one of the nodes from the cluster, the cluster receives NO calls for seconds. After this it will reply normally. When you plug in a machine, it is connected without interruption.