Scalable server infrastructure : plan it

     Call to order at

     0 800 1111 222

     (toll free) or

     021 574 1111

Ultimately, assessing needs and determining solutions requires you to answer various important "how much," "what kind," and "how many" questions. Please note further that these questions must be answered for each individual server role you plan to implement. For example, ABC Corp needs to develop separate sets of answers for its Web servers, database servers, e-commerce servers, and departmental servers. Once you have formulated the broad outlines for the kind of solution you want, you can work with a reseller or a consultant. The tools at hp.com will help you convert your broad-stroke picture into more detailed server specifications (more on these topics in the Use It section later in this guide).

To assess your architecture needs, you must evaluate several different aspects of your operation before you can confidently select the right servers to support your solution. In the next section we'll consider your requirements in the following areas:Servers are specifically designed to store, manage, send, and process data across a network.

• The solution itself
• Software 
• Data 
• Users 
• Special requirements

You may already have some idea about the kind of solution you plan to create. The more details you can supply, the easier it will be for you to choose the right server hardware. For example, if you are planning to build a public Web server, do you plan to include interactive forms, handle database queries when processing user requests, or make use of Web-enabled services for technical or customer support? All these things require additional processing capability and horsepower, and mandate a more powerful server.

On the other hand, if you simply want to post some static documents (brochures, tip sheets, price lists, blank forms for printing, and so forth) for easy Internet access, you'll need far less capability. For each server role you contemplate implementing, you must decide what kinds of capabilities and servers you want the corresponding servers to offer.

Above and beyond deciding how your servers will behave when first deployed, you should also consider what kinds of changes or enhancements you plan to make in the near term. Set your time horizon between a few months and the next year. While you may plan to start small with a modest collection of static documents, if your phase two planning includes more complex capabilities, you should "buy ahead" to support them. Then, you'll be able to implement an online purchase capability, a purchase and shipment tracking facility, or an accounts database for your sales force without having to replace or upgrade your first batch of servers.

Server roles

Returning to ABC Corp, let's analyze the various server roles we've identified:

• Web server: must support up to 100 simultaneous users for access to static documents, e-forms for ordering and purchase tracking, and billing and payment information. This represents a light to moderate processing load.
• Database server: must support a comprehensive widgets database with technical specifications, user's manuals, tip sheets, brochures, stock information, and component ordering, tracking, and delivery for manufacturing use. This represents a moderate processing load, but involves large amounts of data (which in turn require extra storage and memory).
• E-commerce server: must support up to 100 active users on the system, each with multiple orders open or pending. This represents a moderate processing load, but involves extra security considerations (money is involved) and requires quick response time (extra memory and processing power can help a lot here).
• Departmental server: must support all 50 ABC Corp employees simultaneously, plus as many as 20 contractors or temp workers. The server needs to provide file and print services for all users, and will also act as a domain/directory controller to manage access controls, security settings, and so forth. This represents a moderate processing load.

If you plan to run a particular set of software packages or network services on a server, such as a Web server or database software, you must assemble all pertinent details about such services or packages before you go server shopping. In the preceding section, we've tried to specify the basic kinds of information you'll have to determine in advance.

Now its time to translate your data on server roles into specific implementations (IIS or Apache for the Web server software, for example, or SQL Server or Oracle for the database package). Most such packages state specific requirements for the kinds of systems they can run on, and will typically mention minimum and recommended processor speeds, RAM size, and hard disk space needs.

When the documentation for such packages or services includes requirements information, you might also consider asking the software vendor for advice on what kind of system to purchase. They want to sell you their software, so they'll be happy to share the benefits of their usually considerable experience in implementing their software on various types of servers. They may also be able to alert you to additional requirements you may have overlooked. Finally, they can usually recommend the kinds of servers that work best when their software is used in standalone mode (that is, when a server is dedicated only to running their software, as is normally the case when building scalable server infrastructures), or when their software is run in combination with other packages or services. Best of all, such advise is normally free, so you're wise to use it to your advantage.

How much data you must currently accommodate, and how that data grows over the useful life of your server infrastructure, will determine how much storage space you'll need. Sometimes, a bit of inspired guessing is required to quantify how much space you need right now, and how much more you'll need in the future. However, examining your past history can help you approximate your storage requirements going forward.

For example, if a server role calls for you to provide storage for lots of product documentation, help files, and technical data, you can add the amount of space these things require and divide that number by how many months it took to create that collection. This calculation produces an approximate value for monthly storage growth. You can then use this number to calculate how much additional storage you'll need over a 24- to 36-month period (a typical planning horizon for servers, which seldom last more than three years nowadays).

For more complex solutions like a database-driven Web site, or other data-driven services or applications, talk to your programmers or consultants to figure out how much data the system is likely to generate over a 24- to 36-month period. Don't forget to include the space requirements for operating systems, applications, and other files as well when considering drive space requirements. It's also healthy to leave some empty space on drives to help facilitate disk defragmenting and compression, so it's wise to plan for 130-140% of your project amounts to leave some room for the data to "breathe," as it were, and avoid overloads. Here again, you can also work with resellers or sales associates to help you pull all these numbers together.

Because you're planning an infrastructure, there's another level of analysis you might choose to perform -- one based on storage requirements for multiple servers by role or by network. By aggregating storage needs for multiple server roles, you may discover economies of scale by implementing a special storage-area network (SAN) or network-attached storage (NAS). Because both of these implementations permit you to centralize and manage storage for multiple servers in a single location, they can simplify your individual server designs and let you consolidate your storage space for truly large volumes of data. SAN or NAS essentially depend on using additional special-purpose storage handling servers in tandem with your other role-based servers, so it's safe to think of this as just an additional extension of your existing scalable server infrastructure!

For each server role, you need to have a reasonable estimate for the number of users who'll be interacting with the server at any given moment (hint: plan around time of peak demand for best results) and how well the server needs to support those users. Both of these factors have an impact on server horsepower requirements, which in turn affect the type and number of processors chosen, and the amount of RAM installed. Systems with under 25-30 simultaneous users have only modest horsepower requirements, those between 30 and 100 have moderate or intermediate requirements, and those with 100 or more have increasingly significant requirements as numbers go up. When even the most powerful single server can't do the job, clustering or load balancing (server multiplication strategies) provide the pathway to graceful further scaling.

As we've indicated, you must set values for typical and peak user loads -- the number of simultaneous, active users -- for each individual server role you specify. Here again, it's important to think not only of current loads, but to factor in growth requirements. Think about how many users you need to support in six months, a year, or two years from now. Make sure your server is ready to support an increasing number of users over time.

Depending on a server's role -- and the number of simultaneous users or the levels of response time or service it must support -- special considerations sometimes come into play when designing server infrastructures. The easiest example to present is one where a large number of simultaneous users -- let's say 250 to 300 -- must be supported for a combination database/Web infrastructure on the Internet.

In such circumstances, large amounts of network bandwidth may be required (45 Mbps or higher) as well as sophisticated load-balancing hardware (such as a Cisco 7500 or 9000 class router with load-balancing software and "IP fronting" capability that lets it transparently map a single public IP address to any number of servers providing the same kinds of services and functions). When such special requirements occur, it's even more important to bring in qualified, experienced professional help to help you plan out your solutions. Here, too, you'll find that vendors who offer such solutions are quite willing to help with planning and specification -- not only because such solutions are usually fairly expensive, but also because they often require special expertise that only vendors and high-end resellers will typically possess.

Depending on the complexity of the server roles you implement, you may have to evaluate these different requirements yourself, or the IT professionals who help build your solution may do it for you. If you assemble such a solution yourself, assess your needs as completely as possible, but also be sure to solicit feedback from a reseller, consultant, or some other expert to review your work.

Such experts need not construct the whole solution for you to give you the benefit of their expertise -- for example, you might decide to use such help only in selecting specific server models, picking the number of processors to install, and making a go/no-go decision on implementing a SAN or NAS. But don't overlook the benefit that spending a few hundred dollars up front on expert advice can deliver. It could save you many thousands of dollars in uninformed or ill-advised server and hardware selections.