Planning Servers and Internal Connections to Them


There's quite a bit to do in planning your servers and user links. You must decide what kinds of hardware to use for each of your Exchange servers. Then you need to think through some policies relating to storage. After that, you must figure out how to back up the servers. Then you need to make sure you've got adequate bandwidth on your local networks to keep Exchange happy; if you don't have it, you have to decide how to get it. Finally, before you go on to the next step in the Exchange design process, you must think about remote users and how you'll connect them to Exchange.

Designing Your Exchange Servers

The intricacies of Exchange Server design and fine-tuning could occupy a whole book; you'll have to experiment here. Fortunately, Microsoft doesn't leave you out in the cold when it comes to this experimentation. The company provides applications for testing the capacity of hardware you might use to run Exchange Server. These include the Exchange Server Jetstress, Exchange Load Generator, and Exchange Server Stress and Performance tools. Jetstress places load on your disk subsystem similar to an Exchange server load while the Exchange Load Generator and the Exchange Server Stress and Performance tools tests your server hardware (CPU, disk drives, RAM) and network capacity by simulating messaging loads on an Exchange 2007 server.

To begin your experimentation, install Windows Server 2003 and Exchange Server 2007. There are earlier versions of these tools (such as a tool called LoadSim) but we recommend you use the latest versions available from Microsoft. You can download these from http://preview.tinyurl.com/37k89y.

Warning 

Tools such as Load Generator, Stress and Performance, and Jetstress should never be run against production mail servers or in production environments.

Next, take out that set of user-demand numbers that you put together when you did your user needs assessment. Plug those numbers into LoadSim, and run it against a reasonable Exchange server machine - say, a 3GHz Pentium 4 or Xeon machine with 2GB of memory and at least two 9GB SCSI hard drives. Don't run LoadSim on your Exchange server. Instead, run it on a separate 1GHz or better Pentium-based Windows XP workstation with at least 1GB of memory. And don't try to simulate more than 200 users on one LoadSim machine. If you don't follow these guidelines, LoadSim might not be capable of generating the loads that you've asked it to and you could be led to believe that your Exchange server hardware is adequate when it's not.

In selecting servers for Exchange, our recommendation is to always go for the biggest guns that you can afford, commensurate with expected user loads. After working a while now with Windows Server 2003 and Exchange Server 2007, we have our own ideas about server sizing. A good machine would be a dual-core Intel Xeon or greater computer with 4GB of random access memory (RAM) and a hardware RAID-5 disk capacity of at least 500GB. Such a computer should be capable of handling upwards of 200 average Exchange Server 2007 users, network bandwidth willing.

In a busier environment, Exchange 2007 not only doesn't benefit from running on a domain controller, it actually suffers as it competes with Active Directory and other CPU/disk-intensive software that runs on a Windows Server 2003 domain controller.

If you had to gulp a few times after reading our recommendations for a production Exchange 2007 server, don't worry. You can get by with less horsepower, especially if you need to support fewer users.

If you do decide to go with less costly or less powerful hardware, we strongly suggest that you go with SCSI disk drives over Enhanced IDE drives or SATA drives. Enhanced IDE and SATA drives are nice and inexpensive, but for production Exchange servers, we prefer SCSI drives. They're fast and tend to be more reliable than IDE drives over the long haul. For best performance, choose ultrawide SCSI drives.

When you're comfortable with the basic design of your servers, you need to plan for uninterruptible power supplies (UPSs). We consider a UPS to be part of a server, not an add-on. UPSs are cheap, given the peace of mind that they can bring. In spite of Windows Server 2003's and Exchange Server 2007's capability of recovering from most disastrous events, you don't want to tempt fate and risk damage to your organization's precious electronic messaging data. Get enough UPSs to serve the power needs of each server, and get a UPS that comes with software to gracefully shut down your servers if power stays off for an extended period. We'll talk more about UPSs in Chapter 15, "Reliability and Availability 101."

image from book
Server Fault Tolerance

The more fault tolerance you can build into your Exchange Server hardware, the better you and your users will sleep at night. Almost nothing is worse than losing even one user's e-mail messages. Here are a few steps that you can take to improve server fault tolerance:

  • Look for systems with error-correcting RAM memory.

  • On the disk side, consider multiple SCSI controllers or RAID level 5 technologies implemented in hardware.

  • Look for computers with two or more redundant power supplies.

  • Buy computers that let you swap out failed RAID drives and power supplies without even bringing down your system.

  • Consider Microsoft's Windows 2003 Advanced and Datacenter Server editions, which let you set up clusters of Windows 2003/Exchange 2007 servers that are able to continue serving users even if one cluster node fails.

  • Use load-balancing services such as the Windows Load Balancing or the Cisco Local Director to provide higher availability for Client Access and Edge Transport servers

  • Install multiple Hub Transport servers in each Active Directory site that has Mailbox server roles for redundancy in message routing.

image from book

Setting Exchange Server Storage Policies

You need to start thinking now about how you'll manage user storage on each server. Storage management gives you more control over how much of what is stored on Exchange server disks, and it helps you remain within your server disk budget. You need to answer several disk management policy questions, including these:

  • Do you want some or all of your users to store messages in personal folders on a workstation or networked disk drives instead of in their Exchange Server-based mailboxes? This is probably not a good idea and we recommend against using personal folders as a user's primary mail storage location.

  • For those who will use their Exchange Server mailboxes, do you want to limit the amount of storage that they can use?

  • Do you want to impose limits on the storage used by public folders?

  • If you have public folders containing messages that lose value with time (for example, messages from Internet lists or Usenet news feeds), do you want Exchange to automatically delete messages from these folders based on message age?

  • Will you implement Exchange Server's capability to save deleted messages for a designated period of time? This is a neat capability because users can recover messages that they accidentally deleted. However, all those "deleted" messages can take up lots of Exchange server disk space.

You can base your answers to most of these questions on the results of your user needs assessment, although you're bound to make adjustments as you pass through iterations of the design process. Also note that while it's tempting to force users to store messages in personal folders on local or networked disk drives to save on the Exchange server disk, you then run the risk that key user messages won't get backed up. As the ever-present "they" say, "You pays your money and you takes your chances."

Planning disk storage is important enough that we had an entire section on planning your mailbox storage requirements and disk space. Later in Chapter 9, "Imposing Limits and Why," we will further this concept by dedicating an entire chapter to how you can impose storage limits and message size limits on your users.

Backing Up Your Exchange Servers

When you know what your Exchange servers and networks will look like, you can begin thinking about backing up your servers. You need to use backup software that is especially designed for Exchange's client/server-transaction-oriented architecture. Such software enables you to back up an Exchange server's information store without shutting down Exchange processes and thus closing off user access to the server. The software communicates with Exchange's information store service to ensure that the databases that it is responsible for are fully backed up. We'll talk more about the fine points of Exchange backup in Chapter 16, "Backup and Disaster Recovery."

Windows Server 2003's own backup program has add-ons to do a proper backup of Exchange servers. Windows 2003's volume snapshot capability is a great way to get a consistent image of a disk drive while applications such as Exchange are running and online. Other Windows Server 2003 backup vendors have released add-ons that can properly back up Exchange Server 2007. Third-party vendors can also support Windows 2003's volume snapshot capability. These products add better backup scheduling, easier-to-use logs, multiple-server backup from a single instance of the backup program, quicker and easier restore of backed-up data, and disaster recovery options.

Backups can be to tape or disk or, for greater reliability, to both. Volume snapshots are best and most quickly done to disk. Do backups to tape during off-hours when backup speed is less of an issue. Be sure to include both backup disk and backup tape in your hardware/software backup resources plans.

You can back up an Exchange server either locally or over the network. When you back it up over the network, you can run the backup from a Windows 2003 server or from an Exchange 2007 server. For Exchange servers with lots of disk space (200GB or more) and slow network links to potential backup servers (less than 100Mbps), we strongly suggest that you bypass the networked server backup option and do the backup locally on and from the Exchange server itself. You have to spend some money on a backup device and software for the Exchange server, but you'll get it back in available bandwidth and faster backups. Available bandwidth means that other network-dependent tasks - and there are lots of those on a Windows 2003/Exchange 2007 network - run faster. Faster backups mean shorter periods of that awful feeling you get when important data is not yet on tape.

If you have high-speed across-the-network backup systems, just make sure that the restoration of data can occur within your service level agreement. If you do not have a service level agreement, at least confirm that the restoration of data can occur in a time that your organization will consider reasonable.

Whether you back up over the network or locally, don't skimp on backup hardware. You're going to add hard disk storage to your Exchange server, not take it away. Go for high-capacity 4mm, 8mm, DLT, or LTO tape backup systems. Think about tape autoloaders, those neat gizmos that give one or more tape drives automatic access to anything from a few tapes to hundreds of them. If you choose to use disk in your backup strategy, use solid RAID-5 disk-based backup systems, or if your organization has the resources and you need their special features, consider storage area networks with their sophisticated backup systems.

Don't forget those personal folders stored on user workstations. You have to decide who will be responsible for backing them up: Exchange staff, other MIS staff, or users themselves. The technology for centralized workstation backup is readily available. For example, agents for most third-party Windows Server 2003 backup products let you back up all or part of specific user workstations.

While you're at it, don't forget Windows Server 2003 backup. If you have Windows 2003 servers that don't support Exchange, you need to back them up too. You can back up a Windows 2003 server over the network, but if the servers have lots of disk space, consider the same local backup strategy that we suggested for Exchange servers. You can also consider a dedicated network just for backups. All you need is an extra Gigabit Ethernet adapter in each server and in your backup computer or computers and a gigabit hub.

Networking Your Exchange Users

When you have your server design down, you need to think about how to connect users to your Exchange servers. It's usually a no-brainer for local connections, although you want to be sure that you've got enough bandwidth to move the stuff that Exchange makes available to your users. For example, a message with a very simple embedded color screen capture is 855KB. The graphic looks impressive, and it lets you make a point that you never could have made without it. Still, you wouldn't want your recipients to get it over a 33.3Kbps or 56Kbps connection.

If you're concerned about LAN bandwidth, you can do a couple things. First, get rid of those slower networks. Dump 4Mbps Token Ring and Arcnet networks. Yes, they are still around. If you haven't already, you might also want to consider upgrading 10BaseT networks to 100BaseT. Second, segment your LANs to reduce the number of users on any segment. In this situation, you might even put multiple network adapters in your Exchange server, one for each segment or group of segments. And do take a look at faster networking technologies such as 100Mbps Ethernet, those really neat networking switches that can replace routers and significantly improve network backbone performance, and the latest switched Fast Ethernet hubs that bring switching to workstation connectivity and are quite low in price these days. Yes, any of these options will cost your organization some bucks, but they're likely to be bucks well spent. Just as with user workstations, slow technologies don't get used and the benefits of the applications that you're trying to run on top of them are lost.

Don't forget remote Exchange users. Many users need to keep in touch when they're away from the office, whether at home or on the road. Remote users can connect to their Exchange servers by way of direct or RPC over HTTP links through an Internet service provider (ISP) using dial-up or home-based DSL or cable connections. And don't forget the Internet-based POP3, IMAP4, and web browser-based client options that are supported by Exchange Server. With their lighter-weight demands on workstation resources, they could be just what the doctor ordered for your remote users.

Ideally, users with lower bandwidth connections should be using Outlook 2003 or later and the Exchange local cache mode configuration. This will provide the best possible experience for the end user.




Mastering Microsoft Exchange Server 2007
Mastering Microsoft Exchange Server 2007 SP1
ISBN: 0470417331
EAN: 2147483647
Year: 2004
Pages: 198
Authors: Jim McBee

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