Exchange 2010 Monitoring: Database Availability Groups
Database Availability Groups are the key component for Microsoft Exchange 2010 High Availability. As such it is critical to ensure their overall health and availability. High availability can give a false sense of security, in order to ensure an IT service is highly available the overall solution must include monitoring.
When monitoring the high availability function of Database Availability Groups it is important to consider three separate components:
- Replication Health
- Database Copy Health
- Access
Replication Health
In Exchange 2010 any given Mailbox server in the Database Availability Group can host all, some or none of the active mailbox copies at any given time. Proper replication between mailbox servers is vital to ensure high availability function.
In order to monitor replication health manually we can use the Management Shell cmdlet, Test-ReplicationHealth. In the example below, we specify the Database Availability Group
Database Copy Health
After multiple copies of a database are created, the health of each becomes critical to your overall high availability solution. Again we can use the Exchange Management Shell to monitor the health and status of each copy and to perform other management tasks associated with database copies. Some of the management tasks you may need to perform include suspending or resuming a database copy, seeding a database copy, monitoring database copies, configuring database copy settings, and removing a database copy.
For Database copy health we can use the Get-MailboxDatabaseCopyStatus cmdlet to view status information about the mailbox database copies. This cmdlet enables you to view information about all copies of a particular database, information about a specific copy of a database on a specific server, or information about all database copies on a server. Running this cmdlet will present the status of a database copy as seen below.
- Failed
- Seeding
- SeedingSource
- Suspended
- Healthy
- ServiceDown
- Initializing
- SinglePageRestore
- Resynchronizing
- Mounted
- Dismounted
- Mounting
- Dismounting
- DisconnectedAndHealthy
- DisconnectedAndResynchronizing
- FailedAndSuspended
Access
Once we can ensure that replication is working as expected and we have healthy database copies we need to know that the information stores are accessible.
We can use the Test-MapiConnectivity cmdlet to verify server functionality and database availability. This cmdlet will log on to the mailbox specified and retrieve a list of items in the Inbox. This test will also check two critical protocols used when a client connects to a Mailbox server: MAPI and LDAP. During authentication, the cmdlet indirectly verifies that the MAPI server, Exchange store, and Directory Service Access (DSAccess) are working.
Only by monitoring and measuring performance across these three components can you be sure that your Database Availability Groups are actually delivering high availability. Please join me next week when i detail how you can use GSX Monitor to Monitor your Database Availability Groups.
