 |
|
 |
|
|
|
|
You're aware of the alluring promises of server technology as described in business-focused publications, and you talk to savvy IT professionals regularly. The message from both sources is that flexible, scalable server infrastructures can be planned and implemented with a little careful design. But exactly what does that mean? First and foremost, it's essential to understand that servers are specially constructed computers that differ from ordinary desktop PCs in the following ways:
- Servers are specifically designed to store, manage, send, and process data across a network.
- Server technology makes them more reliable than desktop systems.
- Server hardware is more powerful than desktop systems, which means they can process data faster and more efficiently. This increase in capability includes a server's processor(s), disk subsystem(s), network interface(s), and more.
- Servers can easily be extended to support data backup and enhanced security.
- Servers are designed to bring horsepower where system demands are highest, reduce data bottlenecks, and allow information to flow quickly and freely.
- Servers are designed to support multiple channels of powerful processing -- which applies to processors, disk and network access, and so forth -- to permit them to add capacity and capability to meet increasing demand. This is called scalability, but might be more precisely described as "server-level scalability" since it occurs within a single server at a time by adding more (or more powerful) devices and components.
Servers are different animals from desktop computers, and use different technologies to provide intense levels of processing and capability for the user communities they serve.
|
|
|
|
|
The possibility of a scalable server infrastructure enters the picture when processing demands grow to the point where multiple servers become necessary. In such circumstances, identifying specialized server roles is your first step in choosing solution components that meet the different processing demands for each role. Even so, you don't want to make technology purchases that won't help your bottom line, improve key business processes, or otherwise improve your organization's situation. There really is no single test you can apply to determine if you need multiple servers, but some general guidelines will help. In general, when you need a computer system that processes, shares, or otherwise manages data, you'll need a server! For example:
- If your organization has more than five staff members, or if it operates various elements of an IT infrastructure itself -- such as a public or private Web services, e-mail services, database services, and the like -- one or more servers will definitely help. Servers not only provide a central location for important files and services -- they can also support shared applications and other common resources you'd like to share.
- If you need to run a company intranet, an ERP (enterprise resource planning) or CRM (customer relationship management) application, or some kind of e-commerce or e-business solution.
- When access to specific services -- such as e-mail, database, Web services like e-business or e-commerce, ERP, CRM, and so forth -- represents a mission-critical objective or when a single server lacks sufficient horsepower to do as many things as your organization needs done.
|
|
|
|
|
ABC Corp sells widgets through its Web site, which has several components:
- Web server
- Parts database
- Production tracking system
- E-commerce solution
This setup permits ABC to process and track purchase orders and cash purchases online as the number of customers grows into the hundreds or beyond. In this situation, the kind of server architecture shown in Figure 1 makes sense.
|
Figure 1: ABC Corp's role-based server infrastructure.
This architecture segregates servers by role: a Web server, a database server, an e-commerce server, and a departmental server (for intracompany use) all fit together nicely into an integrated whole. As a side benefit, authorized employees can access all servers directly to monitor performance, manage security, generate reports, or use their database engine to manage private databases (such as employee or accounting data) as well as public information.
|
|
|
|
|
|
|
The most important thing you can do to ensure that a server infrastructure meets your company's needs and fits your budget is to devote some time and energy to assessing your needs and planning a comprehensive solution. Until you understand what kinds of servers you need, and how you want to use them, you run the risk of implementing an underpowered solution or of spending more money on hardware and equipment than you really need. Before you launch into planning a server infrastructure, however, you need to understand two ways you can scale such an infrastructure:
- Incremental growth: adding capabilities to servers you already own
- Server multiplication: adding new servers to your current server collection
When it comes to adding capacity or capability to your server collection, the decision to augment an existing server versus the decision to add one or more new servers is a matter of degree, cost and complexity. If your planning and analysis indicate that your processing and other related needs (storage, network bandwidth, and so forth) won't increase by more than 50-60% over current levels, this level of boost is attainable by adding more processors and possibly other components like disk controllers, disk drives, or network interfaces, to an existing server.
But as soon as your needs for processing reach or exceed twice your current levels, you're probably better off duplicating the existing servers that need the boost and doubling up (or as many multiples as are necessary) to meet projected peak loads. In this case, you'll also need to make sure you can cluster your servers for the role that needs the processing boost.
Let's call the strategy where you add components to a server incremental growth, and where you add servers server multiplication.
Alternatively, you might decide to use some kind of load-balancing hardware or service to spread processing loads evenly across multiple servers offering the same services. This is particularly feasible for Web services, where such configurations are commonplace, well-understood, and relatively easy to implement. For example, Figure 2 shows what might happen at ABC Corp if customer load picked up to the point where more Web and e-commerce processing were required.
|
 |
Figure 2: ABC Corp expands its Web and e-commerce servers.
Remember, also, that this kind of architecture is usually only justified when quick response from servers is absolutely necessary, or when large numbers of users (typically, 100 or more) are likely to be active online simultaneously. For smaller active user populations, you may be able to double up on server functionality -- that is, use one server for multiple functions. For example, if ABC Corp only expects 25 simultaneous user sessions, it could double up e-commerce and Web services on a single server, and possibly also double up database and departmental services on another server.
Once you understand what your options are, you can move on to the sometimes arduous, yet inevitably rewarding planning process.
|
|
|
|
|
|
Printable version
