Managing data and availability groups
■
■ Navigating the Information Store 25
■
■ Creating and managing database availability groups 34
■
■ Maintaining database availability groups 55
One of your most important tasks as a Microsoft Exchange Server 2013 admin- istrator is managing the Information Store . The Information Store processes were rewritten in Exchange 2013 to improve performance and manageability . The new Information Store (Microsoft .Exchange .Store .Service .exe) is written in C# and is fully integrated with the Microsoft Exchange Replication service (MSExchange- Repl .exe) and the Microsoft Exchange DAG Management service (MSExchangeDag- Mgmt .exe) .
Each Mailbox server deployed in an organization has an information store, which can contain databases and information about database availability groups (DAGs) . This chapter introduces databases and focuses on the management of database availability groups . After completing this chapter, you should know how to:
■
■ Enable, create, and use database availability groups .
■
■ Manage databases and their related transaction logs .
■
■ Improve Mailbox server availability .
■
■ Manage full-text indexing of Exchange databases .
To learn how to manage databases, see Chapter 3, “Exchange database administration .”
Navigating the Information Store
Exchange 2013 integrates high availability and messaging resilience into the core architecture, providing a simple unified framework for high availability, manage- ment, and disaster recovery . This approach allows Exchange 2013 to improve continuous replication, provide a robust solution that doesn’t require expensive clustering hardware, and reduce maintenance overhead .
Basic database options
Exchange Server 2013 uses Extensible Storage Engine (ESE) databases for mailbox storage . When you install a Mailbox server in an Exchange 2013 organization, this server’s information store has a single, default mailbox database . Mailbox databases have a single, dedicated log stream, which is represented by a series of sequentially named log files. Each log file is 1 megabyte (MB) in size. In addition to log files, data- bases have several other types of files associated with them, including one or more checkpoint files, a temporary working file, and one or more transaction log files.
Depending on the state of Exchange Server, you might see other working files as well.
NOTE Exchange 2013 does not use public folder databases. public folders are now stored in a special type of mailbox.
When you create a mailbox database, you can specify separate folder locations to use for database files and transaction logs. Each database has content-indexing files associated with it as well. These files are generated by the Exchange Search service, which is enabled by default and running on all Mailbox servers . Exchange Search indexes new mail items in the transport pipeline or immediately after the items are created and delivered to a mailbox .
You use Exchange databases to ease the administrative burden that comes with managing large installations . For example, instead of having a single 10-terabyte (TB) database for the entire organization, you can create ten 1-TB databases that you can manage more easily .
TIP As a best practice, 2 tB is the largest recommended size for Exchange Server 2013 databases. Often you’ll find that large databases make it easier to support the large mailboxes that might be required by your organization’s managers and execu- tives. Still, most mailboxes should be limited to between 2 GB and 10 GB in size.
When you create a mailbox database, you specify the name for the database, and this name sets the name of the primary database file as well. For example, if you create a mailbox database called MarketingDept, the primary database file is set as MarketingDept .edb . With Exchange Server 2013, the default location for database files is the same as the log folder. If you want a database to be in a different location, you can specify the location you want to use. Separating database files and log files from the same database and putting them on different volumes backed by different physical disks can help you scale your organization while ensuring high performance and recoverability .
TIP Recoverability is a key reason for separating database files and log files. For example, in the case of a failure on a drive where a database is stored, the transac- tion logs needed for complete recovery would then be on a different (and probably functioning) drive. Whether you want to use this approach depends on the size and configuration of your Exchange Mailbox servers in addition to the service level agreements with which you need to comply.
The many files associated with databases provide granular control over Exchange Server, and if you configure the data files properly, they can help you scale your Exchange organization efficiently while ensuring optimal performance. In a small implementation of Exchange, you might want to place all the data files on the same drive . As you scale from a small organization to a larger organization, you’ll gener- ally want to organize data according to databases, placing all the data for each database on physically separate drives . You can’t always do this, however, in a small- to-medium sized organization with limited resources . For example, if you have ten 1-TB databases and only five data drives, you might want to have the five data drives configured as follows:
■
■ Drive 1 with Database 1 and Database 2 and all related data files
■
■ Drive 2 with Database 3 and Database 4 and all related data files
■
■ Drive 3 with Database 5 and Database 6 and all related data files
■
■ Drive 4 with Database 7 and Database 8 and all related data files
■
■ Drive 5 with Database 9 and Database 10 and all related data files
In a storage area network (SAN) implementation in which you are using logical unit numbers (LUNs) and don’t know about the underlying disk structure, placing the databases on separate LUNs should be sufficient. To protect the data, you might want to consider using hardware RAID (redundant array of inexpensive disks), which is likely already implemented if you are using a SAN. However, if you configure a database availability group with multiple member servers that each have one or more copies of mailbox databases, you likely don’t need to use any type of RAID, and you likely won’t need daily backups either . Just remember that Microsoft rec- ommends having at least three database copies in addition to the active copy .
REAL WORLD If the idea of not needing rAID seems like a radical concept, the idea of not needing to perform backups of your Exchange data might seem revolutionary.
however, when you have multiple copies of your data on separate servers, you really might not need to create daily backups of your Exchange data. this doesn’t mean that you won’t need to create backups ever—it just means you might not need daily back- ups of Exchange data. You will probably still want to create regular backups of your Exchange servers and still create periodic full backups of all server and Exchange data to rotate to off-site storage as a safeguard against catastrophe.
Database available groups can also make you rethink your use of SANs. rather than having a single, massive (and likely very expensive) storage device, you might want to rely on a server’s internal drives or multiple smaller (and likely much less complex) storage devices. One reason to use internal drives is that reliable, multiple-terabyte hard drives are becoming increasingly available, and several servers with multiple, large internal hard drives will likely cost a fraction of the price of a single massive SAN.
If you use SANs, you might find that multiple smaller storage devices are better than a single, massive storage device because you’ll then be protected against a single source of failure (the storage device) causing an outage on all your mailbox servers. I know, I know…the SAN should never go down, but it can (and does) happen.
high availability database options
Exchange 2013 allows you to protect mailbox databases and the data they contain by configuring your mailbox databases for high availability automatically when you use database availability groups . Database availability groups allow you to group databases logically according to the servers that host a set of databases . Each Mail- box server can have multiple databases, and each database can have as many as 16 copies . A single database availability group can have up to 16 Mailbox servers that host databases and provide automatic database-level recovery from failures that affect individual databases . Any server in a database availability group can host a copy of a mailbox database from any other server in the database availability group .
Mailbox servers in a database availability group can also host the Client Access server role . Member servers must be in the same Active Directory domain .
Exchange 2013 integrates high availability and messaging resilience into the core architecture, providing a simple unified framework for both high availability and disaster recovery . This approach reduces the cost and complexity of deploying a highly available solution . How does this work? Exchange 2013 has enhanced con- tinuous replication and has replaced clustering features in Exchange 2007 with a more robust solution that doesn’t require expensive hardware and also requires less maintenance .
In early versions, Exchange was a clustered application that used the cluster resource management model for high availability . In contrast, Exchange 2013 is not a clustered application and therefore does not use the cluster resource model for high availability . Instead, Exchange 2013 uses its own internal high-availability model . Although some components of Windows Failover Clustering are still used, these components are now managed exclusively by Exchange 2013 .
To support continuous replication, early versions of Exchange offered several approaches, including Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), and Standby Continuous Replication (SCR) . LCR was a single-server solution for asynchronous log shipping, replay, and recovery . CCR combined the asynchronous log shipping, replay, and recovery features with the failover and man- agement features of the Cluster service, and it was designed for configurations in which you had clustered Mailbox servers with dedicated active and passive nodes . SCR was an extension of LCR and CCR that used the same log shipping, replay, and recovery features of LCR and CCR but was designed for configurations in which you used or enabled the use of standby recovery servers .
Exchange 2013 includes some aspects of the continuous replication technology previously found in CCR and SCR, but the technology has changed substantially . Because storage groups have been removed from Exchange 2013, continuous repli- cation operates at the database level . Exchange 2013 still uses an Extensible Storage Engine (ESE) database that produces transaction logs that are replicated and replayed into copies of mailbox databases . Because each mailbox database can have as many as 16 copies, you can have one or more database copies on up to 16 different servers .
When a Mailbox server is added to DAG, the server works with other members of the DAG to provide automatic recovery from failures that affect mailbox data- bases, including disk failures, server failures, and other critical failures . When a failure
affecting a database occurs and a new database becomes the active copy automati- cally, this process is known as a failover . When an administrator establishes a data- base copy as the active mailbox database, this process is known as a switchover .
Failover and switchover occur at the database level for individual databases and at the server level for all active databases hosted by a server . When either a switch- over or failover occurs, other Exchange 2013 server roles become aware of the switchover almost immediately and redirect client and messaging traffic automati- cally as appropriate .
Although you can perform most management tasks for availability groups in the Exchange Admin Center, you have additional options when you work with the Exchange Management Shell . Table 2-1 provides an overview of commands you can use to manage availability groups and their various features .
TABLE 2-1 Cmdlets for working with database availability groups MANAGEMENT AREA RELATED COMMANDS Database availability group
management Get-DatabaseAvailabilityGroup New-DatabaseAvailabilityGroup Remove-DatabaseAvailabilityGroup Set-DatabaseAvailabilityGroup Database copy management Add-MailboxDatabaseCopy
Get-MailboxDatabaseCopyStatus Remove-MailboxDatabaseCopy Resume-MailboxDatabaseCopy Set-MailboxDatabaseCopy Suspend-MailboxDatabaseCopy Update-MailboxDatabaseCopy Database management Dismount-Database
Get-MailboxDatabase Move-DatabasePath New-MailboxDatabase Remove-MailboxDatabase Set-MailboxDatabase
Network configuration Get-DatabaseAvailabilityGroupNetwork New-DatabaseAvailabilityGroupNetwork Remove-DatabaseAvailabilityGroupNetwork Set-DatabaseAvailabilityGroupNetwork Switchover management Move-ActiveMailboxDatabase
Start-DatabaseAvailabilityGroup Stop-DatabaseAvailabilityGroup Restore-DatabaseAvailabilityGroup Server membership Add-DatabaseAvailabilityGroupServer
As part of database availability group planning, keep in mind that you can create database copies only on Mailbox servers in the same database availability group that do not host the active copy of a database . An active copy differs from a passive copy in that it’s in use and being accessed by users rather than offline. You cannot create two copies of the same database on the same server . Other guidelines to keep in mind when working with database copies include the following:
■
■ Mailbox databases can be replicated only to other Mailbox servers in the same database availability group . You cannot replicate a database outside a database availability group .
■
■ All copies of a database use the same path on each server containing a copy . The database and log file paths for a database copy on each Mailbox server must not conflict with any other database paths.
■
■ All Mailbox servers in a database availability group must be in the same Active Directory domain . Database copies can be created in the same or different Active Directory sites and on the same or different network sub- nets . However, database copies are not supported between Mailbox servers with roundtrip network latency greater than 250 milliseconds (by default) . The Microsoft Exchange Replication service is responsible for replicating data- bases . The replication service and components that run within the service, includ- ing Active Manager, the TCP listener, and the Volume Shadow Copy Service writer, write results to the event logs. In Event Viewer, you can find these logs by navigating to Applications and Services Logs > Microsoft > Exchange > High Availability . In these logs, you’ll find details on database actions, such as database mount opera- tions, log truncation, and cluster action within DAGs . Events related to failures that affect replicated mailbox databases are written to the logs under Applications and Services Logs > Microsoft > Exchange >MailboxDatabaseFailureItems .
Working with Active Manager
In Exchange 2013, Active Manager provides the resource model and failover man- agement features previously provided by the Cluster service . When you create your first database availability group in an Exchange organization, Exchange creates a Windows Failover Cluster, but there are no cluster groups for Exchange and no stor- age resources in the cluster . Therefore, as shown in Figure 2-1, Failover Cluster Man- ager shows only basic information about the cluster, which includes the cluster name and networks, and the quorum configuration. Cluster nodes and networks will also exist, and their status can be checked in Failover Cluster Manager; however, Exchange manages all cluster resources, including nodes and networks . Exchange makes use of the cluster’s node and network management functions, and you can check the node and network status in Exchange Admin Center .
FIGURE 2-1 Check the status of clustering in Failover Cluster Manager .
REAL WORLD Failover Cluster Manager is the primary management tool for working with the Cluster service. Although you need to use the Exchange Management tools to view and manage database availability groups and related features, Failover Cluster Manager does show the status of clustering in the following ways:
■
■ By selecting the cluster name in the left pane, you get a quick overview of the cluster configuration, including the current quorum configuration, which can be either Node Majority or Node and File Share Majority depending on the number of nodes in the database availability group.
■
■ By selecting the Nodes entry in the left pane, you can quickly check the status of all the nodes in the database availability group.
■
■ By expanding the Networks entry in the left pane and then selecting available cluster networks, you can check the status of the network and individual network connections.
■
■ By selecting the Cluster Events node, you can check the event logs on all cluster nodes for errors and warnings.
Active Manager runs on all Mailbox servers as a subcomponent of the Microsoft Exchange Replication service . On Mailbox servers that aren’t part of a DAG, Active Manager operates as a Standalone Active Manager . On Mailbox servers that are members of a DAG, Active Manager operates as either a primary role holder or a standby secondary role holder with respect to a particular database . The primary role holder, referred to as the Primary Active Manager, decides which database copies will be active and which copies to activate . It also receives topology change notifications and reacts to server failures. Only one copy of a database can be active at any given time, and that copy can be mounted or dismounted .
The group member that holds the primary role is always the member that cur- rently owns the cluster quorum resource and the default cluster group . If the server that owns the cluster quorum resource fails, the primary role automatically moves to another server in the group and that server takes ownership of the default cluster group. Before you take the server that hosts the cluster quorum resource offline for maintenance or an upgrade, you must first move the primary role to another server in the group .
Secondary role holders, referred to as Standby Active Managers, provide infor- mation about which server hosts the active copy of a mailbox database to other Exchange components . The secondary role holder detects failures of replicated, local databases and the local information store, and it issues failure notifications to the primary role holder and asks the primary role holder to initiate a failover . The sec- ondary role holder does not determine which server takes over, nor does it update the database location state with the primary role holder . With respect to its local system, the primary role holder also performs the functions of the secondary role by detecting local database and local information store failures and issuing related notifications.
Active Manager determines which database copy should be activated by attempting to locate a mailbox database that has characteristics similar to the following:
■
■ The database has a status of Healthy, DisconnectedAndHealthy, Disconnected- AndResynchronizing, or SeedingSource .
■
■ The database has a content index with a status of Healthy .
■
■ The database has a copy queue length that is less than 10 log files.
■
■ The database has a replay queue length of less than 50 log files.
■
■ The server hosting the database has all components in a healthy state . If no database copy meets all of these criteria, Active Manager continues looking for the best choice by lowering the selection requirements through successive itera- tions . Active Manager uses the managed availability framework to perform health checks . After one or more copies have been selected, Active Manager attempts to copy any missing log files from the original source to a potential new active copy by using a process called attempt copy last logs (ACLL) . After the ACLL process is com- plete, Active Manager compares the value of the AutoDatabaseMountDial property for Mailbox servers hosting copies of the database to the copy queue length of the database being activated . If the value of the AutoDatabaseMountDial property is greater than the number of missing log files, the Primary Active Manager tries to activate the next best copy (if one is available) .
If the value of the AutoDatabaseMountDial property is equal to or less than the number of missing log files, the Primary Active Manager issues a mount request. At this point, either the database mounts and is made available to clients or the data- base doesn’t mount and the Primary Active Manager tries to activate the next best copy (if one is available) .
Understanding managed availability
In Exchange 2013, the active monitoring and high availability functions are integrated into a single architecture called managed availability, which is implemented on Mail- box servers and Client Access servers . Managed availability is a framework that includes a probe engine for taking measurements and collecting data, a monitor engine for determining the status of Exchange components, and a responder engine for taking recovery actions .