Deciding When to Grow

Do you have clear guidance that tells you when you should expand, add servers, or add capacity? Sometimes your gut instinct just tells you that it is time. But is that something you can take to your boss?

If you are lucky, you can back up your request for a new server or more capacity with tangible evidence. We will discuss both the tangible and intangible factors that may influence the need to expand your Exchange organization.

When you are trying to increase your budget, nothing impresses your boss more than having hard numbers or company policies to back up your requests (well, unless you have a PowerPoint presentation with lots of colorful clipart, charts , and graphs). And you may even be surprised to learn just what you can assign hard- core values to.

The first factors we'll discuss actually involve organizational requirements. A number of different components of organizational requirements may affect the number of servers and their placement. The first is high availability. Here are some factors that will increase the number of Exchange 2007 servers that you will require:

• Clustering always requires at least two servers; one server is the active mailbox server and one server is the passive server. This includes shared copy clusters as well as clustered continuous replication clusters.

• Other server roles cannot be installed on a clustered mailbox server. This means that other roles, such as Hub Transport, Client Access, or Unified Messaging servers, must be placed on a separate physical machine.

• Fault tolerance for internal message routing is achieved with multiple Hub Transport servers. Exchange 2007 will automatically load-balance between multiple Hub Transport servers in the same Active Directory site.

• Fault tolerance or higher availability for server roles such as Client Access or Unified Messaging is achieved with multiple servers and using a load-balancing technology (recommended) or DNS round robin (not recommended).

• Each Active Directory site that contains a Mailbox server must have the Hub Transport and Client Access server roles. If the Unified Messaging server role is used, the Active Directory site must have a Unified Messaging server installed in the site.

• Using Edge Transport services always requires an additional Windows server. Providing fault tolerance for Edge Transport server roles means installing at least two Edge Transport server roles. It is recommended that the Edge Transport servers be installed in your organization's perimeter or DMZ network.

• Large organizations will often create a dedicated Active Directory site containing domain controllers and global catalogs servers. These servers are then used exclusively by Exchange servers. This way Exchange does not interfere with domain controllers that are handling user and computer authentication and vice versa.

Let's not forget about supporting network infrastructure services. In a small organization, a single Windows domain controller/global catalog server/DNS server will be sufficient. However, if your organization is supporting more than a few hundred mailboxes, then the requirements for more supporting infrastructure components will increase as well. Here are some factors that may increase the number of network infrastructure services your organization requires:

• Some organizations split their DNS servers on to servers or appliances that are separate from the servers that support Active Directory. While we normally recommend using the Windows 2003 DNS server running on a domain controller, if you choose to move DNS to another system, make sure that you have redundancy and that all Windows servers are configured with a primary and secondary DNS server. If you want to use the Active Directory-integrated DNS zone feature of the Windows 2003 DNS server, then the DNS server must be running on a domain controller.

• The generic recommendation for the number of domain controllers and global catalog servers is one domain controller CPU for each four Exchange CPUs. This does not take into consideration fault tolerance for the domain controllers, so in organizations with more than 500 mailboxes, we recommend at least one redundant domain controller. That domain controller should be configured as a global catalog server.

• {% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

  If fault tolerance is specified in your Exchange design, it should be specified in your Active Directory design. This means each Active Directory site that contains an Exchange mailbox server (and consequently Hub Transport and Client Access server roles) should contain two domain controller/global catalog servers.

• Remember that Outlook 2000 and later clients also use global catalog servers for global address list lookups.

Another factor that we consider a tangible factor when designing an Exchange 2007 system is recoverability and meeting service level agreements. As you will learn in Chapter 16, "Backup and Disaster Recovery," there are many types of outages and many approaches to recovering from them. Your Active Directory and Exchange designs may be subject to meeting a specific service level agreement that includes a statement defining recovery time for different types of outages:

• The simpler a server's configuration is, the more quickly you can rebuild it if you have to perform a bare metal restore. Bare metal restores usually require that you start over with the server build and redo everything from the operating system on up to the application and all customization that has been done to the server. While small organizations (under 500) may not be able to segment server roles on to dedicated server hardware, for large organizations this certainly can help reduce the complexity of the server. Reduced server configuration complexity assists in speeding recovery.

• The local continuous replication (LCR) feature of Exchange 2007 is one of its most promising features with respect to improving recoverability times. LCR allows you to keep a almost completely synchronized copy of the database ready to put into production in case the live copy of the database has corruption. At a bare minimum, this feature will require twice as much disk space (if you replicate all of your databases) as you had originally planned for. Naturally, there is additional overhead associated with keeping a synchronized copy of the database, so if you are using LCR you may not be able to support as many mailboxes on one mailbox server.

• The time it takes to restore a mailbox database from backup is directly proportional to the size of the database. Larger databases mean longer restoration times in the event of a single database corruption or failure. Creating more databases with fewer mailboxes can help reduce recovery time. Exchange Server 2007 Standard Edition provides you with up to 5 mailbox databases and Exchange Server 2007 Enterprise Edition provides you with up to 50. We recommend that no single database in exceed 100GB in a non-LCR environment and 200GB in an LCR environment.

• Potential speed of data restoration may affect the sizing of your servers. Calculate the amount of data that you will be hosting on any given mailbox server and then calculate how long it will take you to restore that data in a worst-case scenario. Is that acceptable in your environment?

Do you remember those hard numbers and graphs that prove to your boss that you have exceeded your current computing capacity? Nothing beats performance monitoring tools and reports for visually providing tangible evidence that you are exceeding your capacity. We will look at these in more detail later in this chapter, but for now here are some things that you can use performance monitoring to locate bottlenecks that would indicate insufficient resources:

• Performance monitoring may indicate insufficient hardware resources such as memory or disk I/O capacity on existing servers.

• When querying a domain controller or global catalog, performance monitoring may pin-point bottlenecks that indicate either a performance problem or an overloaded domain controller/global catalog.

The final tangible factor in sizing servers and choosing hardware is the eighth layer of the OSI model; this is the political layer. We all frequently joke about our jobs being part politics, but in many organizations this is a reality. Here are some factors that might require a political design decision rather than a technical design decision:

• Satellite or regional offices require their own Exchange server hardware even in the face of consolidation.

• Executives or some divisions of an organization expect to be on isolated server hardware.

• A department feels like having their mail on a server with everyone else is not secure enough.