Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
High Scalability and Flexibility
For providers of Web-based services, it is the best of times and the worst of times. It is the best of times because customers are spending more than ever on services. It is the worst of times because, with traditional architectures, no matter how much capacity sites allocate, end-user demand outstrips the horsepower and storage capacity of the server plant. The most important problem faced by Web infrastructure designers is how to provision the systems to cope with the incredibly rapid growth in number of users and storage capacity.
SANs, based on Fibre Channel–switched fabrics, provide a powerful framework for building and managing a server plant that is flexible, cost-effective, and future-proof. In this part of the article, an analysis of several scaling problems are presented in order to show how SAN technology can address these issues, allowing the administrator to create a Web infrastructure with unprecedented management, flexibility, performance, and scaling characteristics.
Current Web server design has severe limitations in the ability to scale the storage component of the installation. These issues arise from storage directly attached over I/O channels to each server (Direct Attached Storage).
Switched Fibre Channel networks (SANs) provide a solution to these storage scaling problems. Among the benefits of SAN-attached storage are these:
Open systems model for networked storage provides best price/performance through level playing field.
Enhanced storage management monitors the entire storage asset within a single framework. There is flexibility to add or reconfigure storage as needed without downtime.
Independent scaling of CPU and storage capacity decouples servers and storage so that either can be scaled separately.
Easy migration is supported; current applications run without software changes. Incremental deployment allows flexible adoption.
Web Service Scaling Factors
In capacity planning for Web services, there are several factors to be considered:
Number of hits per minute (measure of number of clients)
Outbound bandwidth
Storage capacity (number and size of Web data to offer to end users)
Number of Hits Per Minute
This is the overall summary capacity metric for a site, the number of hits/minute that can be provided to the user population. This is dependent on the number of servers and the outbound bandwidth (and the size of the delivered content). An important, closely related metric is the average time to deliver a URL. Maintainers of a site usually track these numbers and take action if the time to deliver a URL gets too long (the site is too slow as it becomes busier).
Outbound Bandwidth
The outbound bandwidth capacity is the size in bits per second of the first network hop between the server plant and the Internet (or the network between the users and servers). In Internet-based services, the server plant designer has, in general, no control over the quality of the users' network connections, but this first hop is a first-order consideration in providing a given hit per second rate because every request and reply is pushed through this pipe (see Figure 3)1. The fatter the pipe is, the more requests and replies can be pushed though it in a given time.
){kind=link}
Figure 3 Internet service scaling factors.
The importance of this variable has given rise to the Web hosting segment of the Internet space (see Figure 4)1. This is because Web-hosting facilities (such as Exodus, Level 3, Abovenet, and others) provide very fast connectivity to the Internet. Locating the servers on a corporate site requires purchasing a high-capacity leased line to the Internet. Generally, it is more cost-effective for a given Internet access rate to locate the server equipment at the Web hoster (this service is also called co-location).
){kind=link}
Figure 4 Current Web server architecture.
In discussions forthcoming, let's assume that neither the outbound bandwidth nor the user networks are at issue. If these are a problem, they must be addressed in the network, not in the server plant.
Storage Capacity
Storage capacity is, on the surface, a straightforward issue, but with current server plant design, scaling the amount of storage becomes problematic because server scaling and storage scaling are tightly coupled. The next part of the article provides a description of modern designs for Web server installations. An analysis is then provided of current storage practices in the Web server plant.
Current Web Server Practice
Web sites need to provide scalable capacity for servicing user requests. Most large installations utilize load balancing to achieve CPU capacity scaling. Load balancing can be done in several different ways, but the most prominent and highest-performance method is to use a load-balancing hardware device, often a Layer 4 network switch (see Figure 5)1.
){kind=link}
Figure 5 Server load balancing.
The load-balancing switch sits between the delivery network (Internet) and the servers. As requests come for a URL (such as http://www.mycompany.com), the load balancer intercepts the connection request and selects a particular server from among a pool of servers to handle the request.
Figure 5 shows two different clients requesting the same URL from the server plant. A different server is selected for each client. The paths through the network are shown for the two different clients.
This scheme works extremely well for scaling the CPU capacity of the site. As more CPU cycles are needed, the site administrator purchases and deploys new server hardware to keep pace with the increased demand.
A key point here is that the same data (the URL) is delivered to each client. That implies that each server has a local copy of all of the Web data to be delivered. This is the crux of the storage scaling problem.
Storage in the Web Server Plant
Figures 4 and 5 depict the Web data storage directly attached to the servers. This is how most Web servers begin. The implication of directly attached storage (DAS) is that all servers must have copies of the data (see Figure 6)1. This gives rise to three issues:
){kind=link}
How to keep all copies of the Web data synchronized for all servers—As Web data is updated, added, or removed, it is necessary to make the changes on every server's local disk.
How to expand storage capacity of the entire site—If more storage capacity is needed, every server needs to add disk. When the storage capacity of the servers is reached, no more data can be added. Each server must be taken down to add disk storage.
How to grow servers when more CPU capacity is needed—The load-balancing hardware allows more CPU to be added, but it doesn't solve the problem of storage replication or growth. When servers are added, it is necessary to purchase additional disk storage for each server1.
Figure 6 Adding storage to DAS Web servers.
Introducing the SAN
In this part of the article, the concept of the storage area network is introduced to lay the groundwork for application of SAN principles to Web server architecture. A Fibre Channel switched network or fabric provides a high-performance: any-to-any interconnect for server-to-server or server-to-storage traffic. Fibre Channel combines the characteristics of networks (large address space, scalability) and I/O channels (high speed, low latency, hardware error detection) on a single infrastructure.
Fibre Channel allows multiple protocols for networking (IP), storage (SCSI), and messaging (VIA) over a single infrastructure. This infrastructure can be used to create a storage area network in which peripheral devices such as disk storage and tape libraries are attached to the Fibre Channel network and shared among attached nodes (see Figure 7)1.
){kind=link}
Figure 7 A storage area network.
Some of the desirable features of this manner of organizing servers and storage are:
- Storage management
- Cost-effective open systems model
- High performance
- Scalability
- Distance
- Storage consolidation
- Decoupling servers and storage
- Pay-as-you-go model for advanced features
- Storage efficiency
Storage Management
SAN-attached storage allows the entire investment in storage to be managed in a uniform way. For example, software tools exist that allow storage to be allocated to the hosts, replicated, backed up, and monitored on an ongoing basis. This is in contrast to direct attached storage, in which each host's storage must be managed separately.
Cost-Effective Open Systems Model
SANs provide an open systems model for the server and storage infrastructure that ensures that the site administrators will be able to choose best-of-breed price/performance server and storage equipment. In addition, as hardware price and performance improve, the administrator can evolve the site gracefully while continuing to make full use of existing equipment.
High Performance
Fibre Channel fabrics provide a switched 100MBps full-duplex interconnect. In addition, block-level I/O is handled with remarkable efficiency compared to networking traffic. A single SCSI command can transfer many megabytes of data with very little protocol overhead (including CPU interrupts). As a result, relatively inexpensive hosts and storage devices can achieve very good utilization and throughput on the network.
Scalability
Fibre Channel fabrics use a 24-bit address allowing 16 million devices to be addressed. In addition, Fibre Channel networks allow the number of attached nodes to increase without loss of performance because, as switches are added, switching capacity grows. The limitations on the number of attached devices typical of channel interconnects disappears.
Distance
Traditional storage interconnects are limited in the length of cable that can attach hosts and storage units. Fibre Channel allows links up to 10km, which vastly increases the options for the server administrator.
Storage Consolidation
SANs allow a number of servers to utilize sections of SAN-attached storage devices. This allows for cost efficiencies that come from purchasing storage in large units. In addition, this arrangement makes it possible to ensure consistent quality and support across the entire server population.
Decoupling Servers and Storage
Externalizing the storage from the server makes it a first-class asset in its own right. Servers can now be upgraded while leaving storage in place. Storage can be added at will and dynamically allocated to servers without downtime.
Pay-As-You-Go Model for Advanced Features
Because the SAN is extensible, it allows incremental deployment of features such as fault tolerance and hot-backup sites. There is no need to pay for these features until the economic justification has been demonstrated.
Storage Efficiency
In the SAN, because all servers can, in principle, access any storage device, the potential exists to enhance the server software to share storage devices (see Figure 8)1. This has profound implications for any application in which data is now replicated or shared via traditional networking techniques.
){kind=link}
Figure 8 SAN Back-end server architecture.
Current network-based approaches to sharing peripheral devices suffer from severe protocol inefficiencies. For example, in NFS shared storage, to deliver 1MB from server to client, the server must do the following:
Perform the I/O to the disk
Marshal 667 (1,000,000/1500) data frames onto the Ethernet through the IP stack
The client must do this:
Receive 667 data frames on interrupts from the Ethernet card through the IP stack
Reassemble the data into application format1
In contrast, in a SAN with a shared (or cluster) filesystem, no NFS server is required. The CPU that needs the data simply retrieves it from the storage device in one interrupt through the SCSI stack.
SANs for Web Servers: A Scalable Alternative
Having introduced the benefits of storage area networks, let's explore the application of SAN technology to Web servers, with particular attention to the issues of scaling mentioned earlier.
Figure 8 depicts a Web server plant with the addition of a SAN with SAN-attached storage and a shared file system. This organization of the server infrastructure retains all the benefits of the previous architecture while addressing its storage scaling limitations. The next part of the article elaborates on the specific benefits of the SAN for an application and explains how the limitations are removed and scalability is enhanced.
Storage Management
Storage is a significant portion of the investment in the server infrastructure. In the Web space, storage requirements are growing at least 100% per year. As this investment grows, managing this resource becomes more important.
The SAN provides a management framework in which storage is viewed not as subordinate to servers, but as a first-class asset that can be managed in its own right. A growing number of software tools (BROCADE ZONING, Veritas Volume Manager, Transoft SANManager, and so on) provide a principled methodology for the following:
- Partitioning storage
- Allocating storage to hosts
- Replicating data
- Storage health monitoring
- Backup1
These capabilities are key in allowing for the growth of storage and maintaining the site uptime targets while controlling administrative costs.
Hot-Pluggability and Rapid Reaction to Success
One of the key ingredients in planning Internet infrastructure is the ability to scale rapidly as a site becomes popular. If a new site is successful in attracting users, it is not unusual to find that the number of hits per day increases by 3 or 4 orders of magnitude in 60 days or less.
Switched Fibre Channel SANs allow the site administrator to bring the site online with a modest investment in infrastructure without committing to expensive custom-configured servers with built-in limits on storage or number of clients. New storage can be installed, configured, and brought online without server downtime.
Independent Scaling of Servers and Storage
Traditional server design binds storage to individual CPUs. Servers with large storage capacity are more expensive because of additional controllers, chassis, and power supply requirements.
Because the SAN allows storage and servers to be added on an as-needed basis, relatively modest server configurations can be used for the initial implementation (see Figures 9 and 10)1. If more server CPU cycles are necessary to meet a user load, servers can be easily added with or without associated storage. Also, if more storage is needed across a server plant (to accommodate more content), it can be easily added by attaching to the SAN and associating it with the existing servers.
){kind=link}
){kind=link}
Figure 9 Adding servers.
Figure 10 Adding storage.
SAN Scaling
Switched Fibre Channel SANs provide a framework in which the server/storage infrastructure can be scaled up indefinitely as the number of users increases without downtime for forklift upgrades.
Switching Capacity Increases as Number of Switches Grows
One reason why switched SANs can continue to scale is that, like other switched networks, switching capacity increases as switches are added to the network. In contrast, in shared-medium networks (such as Fibre Channel–Arbitrated Loop and shared Ethernet), performance degrades as the available bandwidth is shared among an increasing number of attached nodes.
Advanced Routing Allows the SAN to Grow Indefinitely
As the number of nodes in the network grows, the administrator simply adds switches to the network. There is typically no user configuration necessary; the fabric automatically learns the topology of the network as switches and nodes are added.
For example, Brocade's switches allow the Storage Network administrator to build large meshed networks of switches that may have multiple paths between attached nodes. The Fabric Operating System (Fabric OS) software automatically routes around any failed links. This makes it possible to create SANs that have no single point of failure. In addition, the Fabric OS allows for multiple links between switches to add bandwidth in the network, in case a bottleneck exists.
Easy Migration
It is not at all difficult to migrate from existing infrastructure to the SAN. To configure a SAN, the following components are needed:
Host Bus Adapters (HBAs) that connect servers to the SAN
Fibre Channel storage that connects directly to the SAN
SCSI-FC bridge that allows SCSI (disks and tape) components to be attached to the SAN
SAN network components—Fibre Channel switches1
Because current Fibre Channel HBAs for Windows NT and UNIX make SAN-attached storage look like locally attached SCSI resources, there are no operating system or application software upgrades required to get started with SANs. It is straightforward to begin with one or two hosts and a single SAN-attached storage device, either JBOD (Just a Bunch of Disks, Fibre Channel–Arbitrated Loop disk drives) or Fibre Channel RAID.
Many contemplating implementing SANs in their Web sites begin with a focus on SAN attachment for tape libraries. SAN-attached tape allows backup to be done faster and with less contention than a network-based backup. Many of the enterprise tape backup vendors have programs in place to support this configuration
Shared Storage
In principle, in the SAN, all servers may share a pool of storage using a software layer known as a cluster file system or shared file system. As of this writing, software is under development at several vendors.
In traditional approaches, content is replicated from one server's disk to the other servers' disks. With cluster file systems, the potential exists to coalesce all storage to create a much larger shared pool of SAN attached storage that all the servers can share.
Figure 11 shows two different clients requesting the same URL from the site1. The load-balancing hardware selects a server for each client. The paths show that both servers access the URL from the same disk storage. This is in contrast to the scheme shown previously, in which each server must have its own copy of the Web data.
){kind=link}
Figure 11 Shared file system access to data.
Pay-As-You-Go Model for Advanced Features
Because the SAN is extensible, it allows incremental deployment of features such as fault tolerance and hot-backup sites. There is no need to pay for these features until the economic need has been demonstrated.
For example, with this architecture, a hot-backup site can be readily constructed by distributing the server and storage plant across two physical sites (see Figure 12)1. By utilizing dark fiber, where available, this can be done in a straightforward manner and the sites can be separated by as much as 10km (up to 120km with link extenders). Without dark fiber, ATM connectivity will be utilized to extend the Fibre Channel fabric across two or more widely separated sites.
){kind=link}
Figure 12 Hot backup site at up to 10km.
Another example is to create a fault-tolerant disk subsystem. Again this is a straightforward extension of the initial architecture. The administrator would add a second adapter to each server and connect to another switch. The disks are already dual-ported so the only expense for adding a second connection to the disks is the second switch port.
This configuration can then seamlessly tolerate the loss of any host adapter, switch, or port on storage units (see Figure 13)1. Software or hardware mirroring precludes downtime caused by failure of any single storage device.
){kind=link}
Figure 13 Fault-tolerant disk subsystem.