Scaling Up and Out

 <  Day Day Up  >  

Scaling is the process of adding resources to a system so it can handle increased workloads. In the n - tier architecture we have described throughout this volume, an application is divided into logical units (tiers) organized into layers for user interface, business rules, and database access. These tiers do not necessarily map to servers on a one-to-one basis. When it comes to scaling a solution, we have options on which tier to bolster in order to provide the needed performance and availability. While there are many approaches to achieving scalability, they may be divided into two broad categories: scaling up and scaling out. The first approach is to create bigger and bigger boxes (such as servers) and the second is to set up many smaller, often inexpensive ones.

Scaling Up

Scaling up (or vertical scaling) means adding more resources to a server to meet growing demand. These resources include storage, memory, processors, and network adapters, or even replacing the entire server. If response time of your email degrades over time, for instance, adding memory and processors to your Exchange Server will probably improve performance for all users. In its early days, large-scale computing achieved scalability strictly through scaling up. With mainframes, computing power was a scarce resource that was centrally controlled and managed. When new users or heavier loads were added, the mainframe was upgraded to accommodate them. Because it was centrally managed, mainframe configuration changes only needed to be performed once if they were done correctly, and users could do little to disrupt the performance of the system.

Figure 14.1. Scaling Up and Scaling Out

graphics/14fig01.gif


Windows operating systems support scaling up by supporting multiple processors, large amounts of memory, and other resources. Windows Server 2003 (like its predecessor) supports multiple processors with the symmetric multiprocessing standard (SMP). The operating system allocates threads to run on the available processors, achieving performance boosts over single-processor systems.

The Windows Server 2003 family represents the latest generation of Microsoft operating systems and therefore the highest performance and scalability. A system can move from a single-processor all the way to a 64-way Itanium box that would make any network administrator chuckle with glee.

Windows 2003 supports a range of storage options, offered by many manufacturers. Windows Storage Server 2003 is based on the NTFS (NT file system) and supports capacities from 320 gigabytes (GB) to over 60 terabytes. The NTFS has no upper limits on the number of files on a volume (over four billion have been tested ), and each volume can be up to 256 terabytes.

The most important advantage of scaling up is that adding memory or other hardware does not add to your administrative or management burden . Troubleshooting a single server is simpler than handling multiple servers. The disadvantage is that scaling up only takes you so far, and you may need more performance than a single server can offer. Performance gains from scaling up are not usually as dramatic as those from scaling out. Scaling up also runs the risk of creating user contention for shared resources, while scaling out essentially segments users into groups with their own resources that they do not share with the entire user community. Scaling up creates fewer points of failure; but when a failure occurs, it can be catastrophic. It can also present a security liability, as application components with external exposure may end up hosted side-by-side with sensitive internal information. Scaling out allows a physical separation of data in such a case and provides more architectural options.

Another advantage of scaling up is that it is easy to measure your success. By monitoring server utilization statistics, you can determine when it is time to add more resources. For instance, if the CPU capacity exceeds 80%, it may be time to add additional CPUs. If disk queue length averages more than one, or if disk I/O utilization approaches 100%, go write a check for additional physical disks. You can set up an early warning system with a performance monitor and establish alerts in SQL Server to notify the administrator when performance problems are coming.

Scaling Out

Scaling out (or horizontal scaling) means adding additional resources by adding one or more additional computers, or nodes, to the system. In some cases the new servers are essentially clones of one another. The traffic generated by the largest web sites creates processing and communications loads that exceed the capacity of large individual servers. In these cases, scaling out may be the best option for increasing the processing capacity of the system, as increasing the memory or other resources for a single server will produce limited gains. For instance, if static page hits represent the bulk of your web traffic, you can achieve performance benefits from spreading the workload across multiple servers. When communications bandwidth is the bottleneck, performance can be improved by moving the web servers as close to the users as possible to reduce network traffic. If the largest traffic volume for your site comes from the United States and the Philippines, deploying servers to both regions would likely improve performance.

Microsoft Windows Server products (2000 and 2003) are designed to support scaling out. You can use software components in clusters of Windows 2000 application servers to form a clustered business services tier. Each server can be configured with identical sets of components, and Windows 2000 balances the cluster processing load by sending new requests to the server that has the least processing load. New servers can be easily added to this cluster to meet scalability needs. The cluster is relatively easy to administer regardless of the number of servers employed.

Several portal products can take advantage of clustering and load balancing. For instance, Commerce Server, SharePoint Portal Server 2003, and Microsoft Content Management Server components use network load balancing on the web tier. Load balancing across the web tier is particularly suitable for stateless data such as static web pages or streaming media. A web cluster using network load balancing typically consists of multiple servers called cluster members , each an independent web server that does not share data with other cluster members. When an HTTP request is received, it is routed to an available web server, which handles the request. In the event of failure, the cluster member can be removed from the cluster so incoming client requests are directed to other cluster members. You can add new servers to a cluster relatively easily and often without halting the operation of the cluster.

Clustering lets you optimize the site architecture to increase performance and availability. It also simplifies maintenance as you can remove a node from a cluster for scheduled or unscheduled maintenance without disrupting the overall operation of the portal. Management of clusters is nearly as simple as managing single servers, and the clusters can be mapped to the logical architecture of your application to further streamline management. For instance, you may have a business process that accepts certain files from other organizations, and then performs extensive manipulation of the files ”parsing them, checking for errors, and generating messages to many systems. This process can create bottlenecks for your operation. By creating a cluster of servers to perform these tasks , you can allocate resources as necessary and monitor the process easily. This approach is important for BizTalk Server, which deals with such scenarios frequently in enterprise application integration.

Clustering is also an effective technique for databases such as SQL Server. Combined with shared storage, clustered SQL Servers can overcome hardware bottlenecks by handling a large volume of read and write requests. This technique is explained further in the following section on SQL Server.

We have encountered clients who take scaling out to its extreme. One such client had built a web application with a database backend based on Microsoft FoxPro. FoxPro is known to produce excellent performance for a single user on a PC, and even for a workgroup of users on a local area network. In this case, new users kept coming until the user population had grown to over a million. From time to time, performance would deteriorate sharply, and new users would not be allowed to connect to the database. Brought in for a consultation, we met with the development team to help define the best course of action. On the table was the option of migrating the data to SQL Server on a powerful server and building an n -tier architecture for the application. A member of the development team objected, pointing out that this option would require a significant rewrite of the existing FoxPro code base. Because FoxPro works well for a small number of users, he reasoned, why not segment the application into 26 servers, one for each letter of the alphabet. As users logged in, they would be routed to the correct server based on the first letters of their last names .

Despite this cautionary tale, scaling out is an important tool for achieving high performance. It is likely that you will adopt this approach at a minimum for your web servers, and possibly for additional servers in your infrastructure.

Hybrid Approach

In the end, you are likely to arrive at an architecture that combines scaling up with scaling out. You will find that different elements of your portal architecture respond to different scalability and availability prescriptions. Figure 14.2 shows how a complete portal architecture might look for all the server products addressed in this book.

Figure 14.2. Microsoft Portal Architecture Hybrid Scalability

graphics/14fig02.gif


Each implementation varies depending on the business requirements and the performance characteristics desired as well as the hardware and software on hand. A widely dispersed organization would consider spreading this infrastructure around the world, for instance, and many large portal infrastructures would include servers and systems that are not from Microsoft, such as Oracle databases or Documentum document management systems. Your implementation will probably use hardware you have on hand or the fantastic bargain you found on an eight-way server and disk storage subsystem on eBay.

Most of the Microsoft server products lend themselves to the hybrid scalability approach. Microsoft Content Management Server (MCMS), SharePoint Portal Server, BizTalk Server, and Commerce Server all consist of several components that respond to different scaling techniques. Beefing up the SQL Server repository for content, commerce catalogs, and transaction tracking benefits all these servers. You may also need to scale out servers, such as adding a new server dedicated to crawling indexed content (SharePoint), managing the queue of transactions (BizTalk), or serving up web page content (MCMS).

The goal of performance optimization is to achieve maximum throughput and to reduce response time. While optimizing a complex system has many possible adjustments and configurations, using a systematic approach leads to better optimization.

The first step in optimization is collecting data on the system, such as current performance under various load conditions. When a performance issue is identified, the remediation alternatives are analyzed . One of the alternatives is chosen , implemented, and tested. The modification is accepted or rejected, depending on the results of testing as well as cost and other factors. Following the change, the testing process begins anew.

A systematic approach to optimization requires a top-down methodology, starting with system optimization followed by application optimization. For instance, there is little point in tweaking the code of a server component when you do not have adequate performance from your SQL Server database. These larger system components and network performance must be tackled first. A consultant I work with was once troubleshooting a document management system that was taking an inordinate amount of time to check in files. In the course of upgrading some components, he noticed that a particular server was requiring a long time to download any file at all. It turned out that a network port had been configured as half duplex rather than full duplex, bringing this particular server to its knees in terms of file input and output. Once this system flaw was detected and fixed, he could move on to application issues.

To understand how your portal can grow and scale, let's examine the key elements that make up the platform and how they respond to vertical and horizontal scaling techniques.

 <  Day Day Up  >  


Building Portals, Intranets, and Corporate Web Sites Using Microsoft Servers
Building Portals, Intranets, and Corporate Web Sites Using Microsoft Servers
ISBN: 0321159632
EAN: 2147483647
Year: 2004
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net