- Understanging Availability
- Understanding Scalability
- Scaling a Web Farm
- Summary
Scaling a Web Farm
The Application layer of the .NET platform is broken conceptually into Web clusters, COM+ clusters, and data clusters. Each tier uses different technologies to achieve scale. Web clusters are the most familiar, and the technology choices are both hardware and software based. COM+ clusters are available only with Application Center 2000 and finally address the single point of failure that is DCOM. Data clusters vary in size and scope, but the most common, SQL Server 2000, provides ways to scale database servers up and out.
Scaling the Web Tier
Traditionally, the Web tier is scaled out. This tier has the most robust set of load-balancing technologies available. Network Load Balancing (NLB) is the obvious choice. NLB ships as part of Windows 2000 Advanced Server with all the features needed to load balance network traffic on any TCP/IP port. This fits perfectly with HTTP, which by default uses port 80. Another way to scale the Web service tier is with a hardware solution like Cisco's Local Director or CSS, Foundry's ServerIron, and F5's BigIP. These hardware solutions provide the same functionality as NLB, but they work with any operating system.
NOTE
Scaling the Web tier using Application Center 2000 is discussed in Chapter 12, "Deploying Application Center 2000 Web Clusters."
Using Network Load Balancing
Network Load Balancing (NLB) works by creating a virtual network name. This virtual network name is then associated with a fake MAC Address. A MAC address is a network address that uniquely identifies a network interface card on a layer two network. It is a globally unique number that every network interface card has burned into its chips. NLB creates a mangled, fake MAC address that up to 32 machines can listen on for traffic. Then, each machine examines all the packets targeted at the mangled MAC address and a hashing algorithm determines which machine actually handles each packet.
Network Load Balancing has limited options for determining which server will handle an incoming packet. Servers can be designated to handle packets based on percentage of the traffic. There are no options to direct packets based on CPU, memory, or other traditional starved server conditions. NLB lacks the traditional round-robin, weighted algorithm, and response time balancing found on all hardware-based solutions. NLB is not a panacea, but it is a very good solution in most situations.
Figure 3.3 shows an NLB-scaled Web site with three machines listening to the packets directed at Foo.com. To migrate from the original framework in Figure 3.1, the administrators at Foo.com purchased a second Web server and installed Windows 2000 Advanced server with NLB. Then they copied the existing site from the old server onto the Windows 2000 Advanced Server machine. Next they ensured that the site was functioning properly and pointed the Foo.com URL to that new machine. Then they rebuilt the original Foo.com server with Windows 2000 Advanced Server and NLB and joined it to the farm. This created a situation where up to 32 Web servers could handle Foo.com's traffic.
NOTE
Using Network Load Balancing is covered in great depth in Chapter 5, "Using Microsoft Network Load Balancing in a Web Farm."
Figure 3.3 Foo.com's simple .NET Web farm using Network Load Balancing.
Using Hardware Load Balancing
With hardware load balancing (HLB), the change to a multiserver site happens at the network layer. Commonly referred to as layer 37 network switches, hardware load balancing is becoming the norm for successful sites. HLB acts as the traffic cop, handling all the requests for Foo.com and directing them to the servers configured in HLB to handle the traffic. Figure 3.4 shows Foo.com using HLB.
NOTE
Using hardware load balancing is covered in great depth in Chapter 6, "Using Hardware Load Balancing in a Web Farm," and Appendix C, "Hardware Load Balancing Vendors."
Figure 3.4 Foo.com's simple .NET Web farm using HLB.
Scaling COM+ Using Component Load Balancing
COM+ Services via DCOM use RPC, a connected network protocol, for remote COM+ component invocations. This means that once a client and a server have established a connection, they remain connected like FTP. This is the opposite of HTTP, which is a disconnected protocol. A special technology called Component Load Balancing (CLB) was created to provide scalability and availability for COM+ and circumvent the connected nature of DCOM.
CLB works by intercepting component creation requests before they leave the client computer. CLB maintains a list of servers, usually members of a COM+ cluster in an server architecture like that shown in Figure 3.5, to send remote component activations. Through a combination of statistics-gathering using WMI and a round-robin load-balancing algorithm, CLB picks the best server for a component's activation. CLB still uses DCOM, so the client server in Figure 3.5 has a DCOM connection to each member of the COM+ cluster.
NOTE
More information on Component Load Balancing and COM+ clusters can be found in Chapter 13, "Deploying Application Center 2000 COM+ Clusters."
Scaling the Data Tier
Unlike the Web and component tiers, scaling of the data tier is much more complicated. With disparate entities like LDAP directory services and SQL Server 2000, each requires a different mechanism for dealing with scalability problems. Some, like SQL Server, have limited options for scaling out and could force application changes under load. However, careful planning can help prevent situations in which the data tier becomes a bottleneck.
Figure 3.5 Component Load Balancing in a Web farm.
Scaling Out Directory Services
LDAP is a TCP/IPbased directory service. Scaling out of directory services like LDAP is accomplished in much the same way as scaling out the Web services tier. Technologies like hardware and software load balancing provide linear scalability for any TCP/IPbased data services system.
Improving Availability Using SQL Server 2000 with a Windows Server Cluster
With SQL Server 2000 and Windows 2000 there are two types of shared-nothing clusters: those that use a disk to maintain cluster state and those that use the network. A shared-nothing cluster that uses a disk to maintain cluster state is called a Windows Server cluster. The operating systems of cluster members have access to the same physical data on a shared disk. This systems does not rely on complicated distributed lock management techniques, so even though there is a shared disk, the clusters are considered shared nothing.Windows Server clusters improve the availability of SQL Server by allowing failure of one node of the cluster. Clients make requests of a virtual SQL server through a Windows Server cluster virtual network name. When a SQL server fails, the virtual network name and SQL server are restarted on a different member of the cluster. Availability is greatly improved as new client requests of the virtual name move to the failover cluster member. When the failed node is repaired, the virtual name and SQL server can be moved back to their original cluster member. Figure 3.6 shows a shared-disk SQL Server 2000 cluster and what happens during a fail-over.
NOTE
Chapter 17, "Introducing Windows Server Clusters," discusses clustering Windows 2000 using Windows Server clusters.
Figure 3.6 A Windows Server cluster for SQL Server 2000.
NOTE
More information on SQL Server 2000 distributed partition views and federated database support in SQL 2000 can be found in Appendix D, "Scaling Out SQL Server 2000."