paulchinonline.com

The Keys to Maintaining Intranet Integrity, Part 1

By Paul Chin

Originally published in Intranet Journal (26-Aug-2004)

back back to portfolio


I'm reminded of a week-long backpacking trip I took into the interior of British Columbia several years ago. There were four of us in the group, each carrying their fair share of the load. We split up our supplies so that no one single person carried all of any one particular item. Instead of one big first aid kit, we each carried smaller, individual kits; instead of one large stove fuel canister, we carried two smaller ones; instead of having one person carrying all the breakfasts, another the lunches, another the trail snacks, and another the dinners, we all carried equal portions of each. This way, if we lost a pack or (gulp) a person we would still have enough supplies between us to trek back to civilization—which may be days away.

This proved to be great foresight on our part when one of our members lost his footing during a dicey stream crossing and had to dump his gear for fear of being pulled into the water below by the weight of his pack. He was carrying one of our fuel canisters, and I packed the other one. Had he been carrying our only one, we would have been up that fabled creek without a paddle.

So there's something to be learned from that old clichéd about putting all our eggs into one basket: Try it and you'll become bear fodder.


System Availability

Every company has any number of IT applications and systems driving its operation; some play a minor supporting role, others are vital business tools that aid the decision making process. While the unavailability of certain applications may be little more than a minor inconvenience, applications such as e-mail and personal information managers (PIMs) leave a deeper cut in their absence. Then there are those systems we consider mission critical—those used by defense agencies, energy control facilities, medical institutions, and financial organizations—whose very absence, if even for a few hours, would bring about the fury of the Four Horsemen of the Apocalypse.

An intranet, due to the variety of its possible applications in business, can fall anywhere in this scope of system availability because the importance of uptime is directly related to an intranet's function, as well as how tightly integrated it is with corporate business processes. For example, if an intranet acts as a simple document repository—for documents that can also be found outside the system—then a few hours downtime might not negatively impact a company as much as, say, an intranet housing applications that tie directly into core databases required for daily operation. But again, this depends on an intranet's purpose within the company. To some organizations, an intranet's information itself is considered the mission critical system.

As much as we would like to have a 24/7 intranet, regardless of purpose, this is not always feasible. There are numerous situations, both planned and unplanned, that will affect the availability of your system as shown by the examples in the table below:

Planned Downtime Unplanned Downtime
Scheduled, routine server maintenance.

Hardware and/or software upgrades.

Physical server re-location.

System crash caused by hardware and/or software failure.

Database corruption.

System compromised by virus(es), malicious attacks, or careless misuse.

With a little planning, you can maximize system uptime and overall intranet integrity by following these steps:

  1. Design an intranet architecture in relation to the importance of system availability
  2. Implement a thorough security infrastructure
  3. Follow a regular maintenance schedule
  4. Maintain consistent backups
  5. Design a disaster recovery procedure

This article will focus on the first point, intranet architectures, while the remaining four points will be discussed in the second part of this series.


Intranet Architecture

When users log onto a corporate intranet it will appear to them as though they're accessing one giant system. For all they know, everything they see on their intranet could be sitting inside a single monolithic server parked comfortably beside someone's desk in a far-off corner of the company and managed by a Gollum-like IT creature coddling its precious. And, perhaps, that's the way it should be because end-users probably have enough of their own problems to deal with, without having to try figuring out the inner workings of their intranet.

Intranet developers and systems administrators, on the other hand, need to consider an intranet as being composed of various individual components—network infrastructure, Web and application server(s), static content, databases. And all of these components must be available collectively at any given time in order to provide users with a functional whole, and managed behind-the-scenes in such a way as to appear completely transparent to the user community. That's a tall order.

So what type of architecture is right for your intranet? There are dozens of possibilities—from a single server to a whole array of servers. Where and how you house your various intranet components is dependent upon:

Regardless of your planned intranet architecture, it should remain under the control of a centralized governing body. If you have an intranet made up of 10 individual departmental servers—each based on a different technological backbone and supported by its own system administrator—it will be extremely difficult to maintain overall intranet availability. Each sub-system may have a different maintenance schedule and varying degrees of fault-tolerance. So while some intranet services may be available, others may not; intranet availability needs to represent the availability of all its pieces.

This issue of intranet centralization is discussed in much greater detail in two of my past articles so I won't repeat myself. You can find these articles by following the links below:

A side note worth mentioning here is that absolutely no testing should ever be done in a production environment because you will be playing with live ammunition—a lot of things can go wrong, bringing down the entire system. Instead, a logical and clearly defined migration path must exist to move applications from a testing to a production environment.


Architecture Types

If budgets are tight and resources scarce, low-to-medium priority systems can get away with residing on a single server since downtime, while inconvenient, probably won't stop anyone from doing their jobs. But high priority intranets—those driving core business processes that need to be constantly available—require fail-safe mechanisms to minimize downtime and its effects on the users.

While it's difficult to describe all the possible intranet architecture combinations, what follows is a range of intranet priority levels and the possible architectures that can be put into place to support them:

Intranet Priority Level Intranet Architecture
Low-to-medium Standalone server
Medium-to-high Mirrored server with external data server(s)
High to mission critical Server cluster with external data server(s)

Standalone Server

A standalone production server can be used in low-to-medium priority intranets where the Web server, applications, content, and databases are stored in a single box. This is by far the simplest and least expensive option since there's very little—beyond backups and/or an internal RAID configuration—in terms of real system and resource redundancy.

Single Server Architecture

Example of a simple standalone intranet server set-up

The obvious downside to this simplicity, of course, is that the entire intranet will be unavailable for as long as the server is down. This could be several minutes for a reboot, several hours for a system restore from back-up medium, or several days to recover from a serious hardware crash or data corruption. This is why single, standalone server architectures should be reserved for lower priority systems where downtime won't cripple the user community.


Mirrored Server with External Data Server(s)

This configuration works well for medium-to-high priority intranets without being overly expensive or complicated. In this set-up, an intranet's primary server is backed-up by a secondary server containing a mirrored image as shown below.

Mirrored Server Architecture

Example of a mirrored intranet server configuration

The main advantage this architecture has over a standalone server is in its ability to alternate between primary and secondary servers in the event of system failure, or when one needs to be taken off-line for maintenance purposes. But the secondary server doesn't actually operate in conjunction with the primary server (such as with load balancing), rather it acts as a backup to be swapped to when the primary server becomes unavailable—a process that's completely transparent to the user community.

You will also notice another major difference between this architecture and a standalone server: The data is stored separately, outside the intranet server, and can be managed in either a RAID or SAN configuration. Separating the data from an intranet's processing server allows content to be maintained in a central repository without requiring it to be duplicated across multiple intranet servers.


Server Cluster with External Data Server(s)

High priority and mission-critical systems require the highest level of fault-tolerance and system availability. One way to accomplish this is with the use of server clustering—sometimes referred to as a "server farm"—where a group (or "cluster") of resources is used in conjunction with one another to provide users with what may appear to them as a single system.

If, for example, one intranet server crashes or is taken offline, another server in the cluster will pick up the slack of the missing server.

Server Cluster Architecture

Example of a server cluster (or "server farm") configuration

In addition to increased fault-tolerance and intranet availability, clustering also allows systems administrators to take advantage of load balancing to ease high traffic and processor payload by spreading the work among several interconnected servers. Obviously, clustering is the most complex and expensive of the three intranet architectures shown here, and should be reserved for systems that truly need to have 24/7 availability.


To Be Continued...

Intranet integrity and availability is not something you what to gamble with. If you're running a high-priority system, don't skimp on your failsafe measures because downtime means loss in productivity, loss of revenue, and an angry mob you once called your users. You only need one major failure to prove this point—and that's not a lesson you want to learn through real-life experience.

Join me in part two of this series on maintaining intranet integrity when I'll be focusing on security, maintenance, data backups, and disaster recovery procedures.


Copyright © 2004 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.