Microsoft® Exchange Server 2003 Scalability with SP1 and SP2

3.5 Scaling the Active Directory 165

Chapter 3

 Local quorum: you just need to have a locally attached disk where

quorum information is stored, and that must be present. Local quo-

rum is appropriate for any environment that does not have a storage

interconnect. Local quorum is appropriate for lone-wolf clusters—in

other words, single-node clusters.

 Majority node set: you need to have a majority of the nodes up and

running the Microsoft cluster service for the cluster to be considered

healthy and operable. This mode of quorum is only applicable for

clusters that have three nodes or more and are appropriate in that you

do not need to provision storage resources access to each of the nodes

of the cluster. This method is particularly interesting for geographi-

cally dispersed clusters.

iSCSI-Based Cluster

This is the newbie in the list of enhancements of the clustering software in

Windows Server 2003, which appeared with SP1 of Windows Server 2003.

When using the Microsoft iSCSI Software Initiator, you can now build up

to eight-node clusters. This is a significant improvement because as data

networks evolved, iSCSI is becoming more and more a viable way of con-

necting a Windows Server to back-end storage networks in block-mode

across a simple IP network. Of course, with the I/O workload that is typi-

cally demanded from Microsoft Exchange, you might hesitate to deploy

storage networks over iSCSI rather than a fibre channel, which has proven

itself in terms of high-performance transport.

SAN Boot Support

Although it was possible to build diskless servers in Windows 2000 clusters,

the requirement was to use a separate fibre channel path to the boot units

from the shared storage disk units. This required users to use 4 (2 × 2) HBA

(Host Bus Adapter) for ensuring a redundant path to the data disks (first

pair of HBA) and to the system disks (second pair). With Windows Server

2003 and the combined use of STORport drives, it is now possible to build

clusters with diskless servers (i.e., servers that boot off the storage area net-

work) and use the same data path for the system disks and the data disks in

the cluster.

3.5 Scaling the Active Directory

There are two ways in which the Active Directory can scale: using a scale-up

model, where you attempt to store a large number of objects in the Active

166 3.5 Scaling the Active Directory

Directory, and using a scale-out model, where you try to deploy a large

number of Active Directory domain controllers and servers. A combination

of the two can be used by corporations that decide to have a global roll-out

of the Active Directory, which results in gathering a large number of objects

into a single forest (in separate domains, however) and a large number of

domain controllers due to the presence of multiple sites.

Scale-Up the Active Directory

The scale-up of the Windows Active Directory service is typically achieved

across two dimensions:

 Growing the number of objects in the Windows Active Directory;

 Diminishing the number of domain controllers and GC servers in

the infrastructure: a single Windows Active Directory server would

serve more client machines/Microsoft Exchange servers.

When I first worked on this book, we looked at growing the number of

items in the Windows Active Directory by loading it with the U.S. phone

book. It was a simple experience that consisted of adding as many contacts

as possible and making observations on the scalability factor of the Win-

dows Active Directory service. That corresponded to approximately 100

million objects stored into the directory. We found interesting things as the

result of this experience:

1. The size of the database would grow in a linear fashion. That

was of little surprise to us. The Active Directory database engine

is a variant of the ESE (discussed in Chapter 1 of this book),

which has proved in past versions of Exchange to scale quite well

in capacity. The only issue with it is the single-file database

model, but for most deployments that shouldn’t provide too

much of a problem.

2. The response time for a transaction would not grow with the size

of the database. This is a very important aspect of the scalability

of the Active Directory, and in general of any directory service,

based on solid database technology. With 100 million objects, we

found that for a given request, more time was spent in rendering

the information for the user’s browser than actually looking up