MORE INFORMATION
Exres.dll is an Exchange-specific resource DLL. The
Microsoft Cluster Service (MSCS) communicates through a resource monitor to
Exres.dll, and Exres.dll then communicates with the Exchange components.
Exres.dll translates the cluster actions, such as "resource online" and
"resource offline" into the starting and stopping of Exchange-related services.
Exres.dll also monitors the stopping of these resources and notifies the
Cluster service if the operation is unsuccessful.
Exres.dll
In a cluster, the Cluster service is responsible for starting and
stopping services through Exres.dll. Because of this, an administrator should
not stop a service from the command-line. When you stop a service from the
command-line, the
IsAlive call to that service does not work, and because of this, the
Cluster service tries to bring that service back online. The
IsAlive function is implemented to return the last value that was pooled
from the resource health-monitoring thread. The
LooksAlive function has the same implementation as
IsAlive, and is not called because Exres.dll provides resource-failure
event handles to the cluster resource monitor that tells when a resource has
failed. The health-monitoring thread checks resources every 10 seconds, and you
cannot configure this check. The Excluadm.dll program provides cluster-specific
Wizards and the user interface (UI) that is associated with Exchange.
Exchange Resources
An Exchange virtual server (EVS) is a collection of Exchange
resources. Each resource has all the properties that a Microsoft Windows 2000
resource has, such as dependencies, possible owners, and retry properties. Each
resource in the EVS represents a different component of Exchange. The possible
Exchange-specific resources are the following:
- System Attendant (SA)
- Information Store (IS)
- Protocols
- Routing
- Message Tracking Agent (MTA)
- MSSearch
This resource is managed by its own resource
DLL, Gathercl.dll.
For each resource, the
IsAlive and
LooksAlive calls that the Cluster service makes to that resource are the
same. Each of these Exchange resources have dependencies as shown in the
following diagram, where the arrows point to the resource that the resource
depends on:
________________
| |
| |
| IP Address |
| |
|________________|
^
|
|
________________ ____________________
| | | |
| | | |
| Network Name | | Physical Disk |
| | | |
|________________| |____________________|
^ ^
| |
| |
____________________________
| |
| |
| System Attendant |
| |
|____________________________|
^ ^ ^
| | |
| | |
_________ ___________________ ________________________
| | | | | |
| | | | | |
| Routing | | Information Store | | Message Transfer Agent |
| | | | | |
|_________| |___________________| |________________________|
^ ^ ^ ^
| | | |
| | | |
__________________________________
| | | | |
| MS Search | POP3 | SMTP | IMAP |
|___________|_______|_______|______|Exchange Resource Dependencies
System Attendant
The default dependencies that are shown in the previous diagram
are created when the System Attendant is created. The System Attendant is the
fundamental resource that controls the creation and deletion of all the
resources in an Exchange virtual server. These resources are created when you
create the System Attendant resource. To delete the server and its object from
Active Directory, delete the System Attendant. The
IsAlive call to the System Attendant checks the Service Control Manager (
Service_Control_Interogate) to obtain the immediate state of the System Attendant.
Information Store
When the Information Store is brought online, the Information
Store service (Store.exe) starts and begins to mount the storage groups. When
all the storage groups are mounted and the store has "played" all the
transaction logs, the resource is considered to be online. The
IsAlive call to the Information Store sends a Remote Procedure Call (RPC)
call to the Store.exe process. On the Store process side, the check consists
only of verifying that the virtual server name exists in the list of active
virtual servers.
Message Transfer Agent
The Message Transfer Agent (MTA) resource is an Active/Passive
resource. There can be only one MTA per cluster. The MTA is created in the
first Exchange virtual server (EVS) and cannot be moved to a different EVS.
Although the MTA is an Active/Passive resource, it serves all virtual servers
in the cluster while it is online. The
IsAlive call to the Message Transfer Agent checks the Service Control
Manager (Service_Control_Interogate) to obtain the immediate state of the MTA.
Protocols (SMTP, POP3, IMAP, HTTP)
The
IsAlive call acts in the same way for all the protocols. Exres.dll opens
a TCP socket port to the protocol by using the bindings that are provided from
the Internet Information Services (IIS) metabase and waits for a response in
the form of a banner. If the start of the banner matches the expected value,
the resource is considered to be online. If the banner is not returned before
the time-out period, the Cluster service determines that the protocol virtual
server is unavailable and the
IsAlive call is unsuccessful. None of the protocols can be set to reject
all connections from all servers or the protocol virtual server will reject
IsAlive calls from itself. Because of this, each protocol virtual server
must accept connections from its own IP address. For the HTTP protocol,
Exres.dll sends a
GET command to obtain a response.
When an Exchange virtual
server is brought into an offline state such as in a planned failover, all
instances of the SMTP protocol virtual server on the node are stopped. This
causes the SMTP resource of other Exchange virtual servers to quickly go
offline and restart. The SMTP resource does not restart automatically if the
Do not restart option is selected in its properties.
Routing
The
IsAlive call to the Routing resource checks the Service Control Manager
to determine if the Routing service is running.
Content Indexing
The MSSearch resource provides content indexing for the Exchange
virtual servers. The
IsAlive call to the MSSearch process returns a pointer to the data
structure for the database that is being indexed. If the pointer is valid, the
resource is determined to be working correctly. To re-create the MSSearch
resource after it has been deleted, you must delete and then re-create the
Information Store resource for that Exchange virtual server.
Active/Active Architecture
To make Exchange 2000 Server cluster-aware, multiple storage
groups and protocol virtual servers are used. This section describes in more
detail how Active/Active clustering is implemented.
Use a cluster
node with one Exchange virtual server as an example, and that virtual server
has one storage group that is associated with it. The protocols are associated
with the IP address and network name of the virtual server, and not the cluster
node itself. If another Exchange virtual server in the cluster fail over to
this node, the Store.exe process mounts the storage groups that are associated
with this new virtual server, and then creates additional protocol virtual
servers to use to respond to the IP address and network name resource of the
second Exchange virtual server.
A stand-alone server cannot have more
than four storage groups mounted and active at a time. Because of this, you
must monitor the number of storage groups in a cluster. The limitation of four
storage groups applies to a single cluster node. No matter how many Exchange
virtual servers are failed over to a single node, the Store.exe process can
mount no more than four storage groups.
ExchangeOpen/ExchangeClose Functions
The
ExchangeOpen and
ExchangeClose functions are called whenever the Exchange resources are moved to
the current node. Inside the
ExchangeOpen functions, memory is initialized or allocated for the basic
information of the resource. These functions also handle the loading and
unloading of DLL files that are used by the Resource DLL, and this is
controlled by reference counters.
ExchangeOnline/ExchangeOffline Functions
The
ExchangeOnline and
ExchangeOffline functions create new
OnlineWrapperThread and
OfflineWrapperThread worker-threads and then immediately return an
ERROR_IO_PENDING to the cluster resource monitor. To prevent situations where
Remote Procedure Calls stop responding (hang), these two worker threads create
the real online/offline thread. The Wrapper threads act as monitors for the
online/offline thread, and uses timers to monitor the operation of the
online/offline thread. If the online/offline thread does not return in the
PendingTimeOut value that was set in the Cluster administrator, the Wrapper
thread determines that the operation has been unsuccessful, and sets the
resource's state as "failed". It then returns an error. The only exceptions to
this behavior are for upgrade operations or for store resource online
operations. In these two cases, the Wrapper thread waits for an upgrade to
complete or for a store resource to go online, without timing
out.
When the Wrapper thread returns a failure to the resource
monitor, the resource monitor tries to restart the resource an additional two
times. During this time, the
ExchangeOnline function checks to see if the previous online/offline thread has
returned. If the online/offline thread does not return, the
ExchangeOnline function returns.
For the
OfflineWrapperThread, if the ExchangeOffline thread does not return in the
PendingTimeOut limit, for the Store, System Attendant, and MTA resources, the
resource monitor terminates the corresponding process.
The
ExchangeOnlineThread/ExchangeOfflineThread performs the following the Exchange
resources:
- System Attendant, Information Store, and Routing:
Starts the service if it is not already started, and then makes RPC calls to
each of the services to start or stop the corresponding virtual server
instance. - Protocol Resources:
Sets the command bit in the IIS
metabase, and then starts the service if it has not already been started. The
corresponding service picks up the command, and then starts or stops the
virtual server. The only exception to this is the SMTP virtual server. In this
case, the whole SMTP service must be stopped when a virtual server instance is
taken offline. The IsAlive function checks for other virtual servers running on the same
physical computer, detects that the underlying SMTP service is stopped, and
then restarts the virtual server.
ExchangeIsAlive and ExchangeLookIsAlive
The
ExchangeOnline function returns an event handle to the resource monitor, and the
resource monitor then stops calling the
LookIsAlive function. Instead, the resource monitor calls the
ExchangeIsAlive function at intervals that are set in the Cluster Administrator
"Looks Alive" polling interval. Whenever a resource is online, The Exchange
resource DLL creates two threads for that resource to monitor the status of
that resource. The first thread, called
ExchangeIsAliveMonitor, checks the status of the resource every 10 seconds by waking the
second thread, called
ExchangeCheckIsAliveWrapper.
ExchangeCheckIsAliveWrapper performs the actual
IsAlive checking. If the
ExchangeCheckIsAliveWrapper thread does not return in the
PendingTimeOut limit, or if the
IsAlive check is unsuccessful, the
ExchangeIsAliveMonitor thread signals a failure event for the particular resource to the
resource monitor. The
ExchangeIsAlive function returns the status of the last
IsAlive check.
ExchangeTerminate
This function terminates the existing
ExchangeIsAliveMonitor thread and for the Store, System Attendant, and MTA resources,
also performs the corresponding offline procedure to make sure that the
database is dismounted. If the offline procedure does not complete successfully
in the
PendingTimeOut limit, the Resource DLL also terminates the corresponding
process.
Creating Resources
When the user creates a resource first, and then creates a call to
Excluadm.dll prompting for information, Excluadm.dll obtains all the required
information for the resource, passes it to the Cluster service, and then the
resource monitor creates a call to the
ExchangeResourceControl function in the resource DLL with the information that was passed
from Excluadm.dll and Clusctl_Resource_Set_Private_Properties as the control
code.
ExchangeSetPrivateResProperties is used to handle this control code. It first saves the
information to the cluster database under the
Parameters registry key for that resource, and then makes a call to
Exsetdata.dll to have Exsetdata.dll create objects in Active Directory. In some
cases, a problem may occur and some configuration information may be modified
in Exchange System Manager, without having the changes synchronized with the
cluster database.