Professional Documents
Culture Documents
10135A-ENU - TrainerHandbook - Vol2 исправвленный
10135A-ENU - TrainerHandbook - Vol2 исправвленный
MICROSOFT
LEARNING
PRODUCT
10135A
Configuring, Managing and Troubleshooting Microsoft Exchange Server 2010 Volume 2
xv
Contents
Module 7: Implementing High Availability
Lesson 1: Overview of High Availability Options Lesson 2: Configuring Highly Available Mailbox Databases Lesson 3: Deploying Highly Available Non-Mailbox Servers Lab: Implementing High Availability 7-3 7-9 7-27 7-34
xvi
Module 12: Upgrading from Exchange Server 2003 or Exchange Server 2007 to Exchange Server 2010
Lesson 1: Overview of Upgrading to Exchange Server 2010 Overview Lesson 2: Upgrading from Exchange Server 2003 to Exchange Server 2010 Lesson 3: Upgrading from Exchange Server 2007 to Exchange Server 2010 12-4 12-12 12-34
7-1
Module 7
Implementing High Availability
Contents:
Lesson 1: Overview of High Availability Options Lesson 2: Configuring Highly Available Mailbox Databases Lesson 3: Deploying Highly Available Non-Mailbox Servers Lab: Implementing High Availability 7-3 7-9 7-27 7-34
7-2
Module Overview
Many people rely on messaging environments so that they can perform critical business tasks, and it is extremely important for your messaging solution to be available for an extended time. Thus, many organizations place strict availability requirements on e-mail and other critical applications. As the Microsoft Exchange Server product has improved over the last decade, it has become very stable and resilient, even in standalone configurations. To be a truly high availability solution, however, further designing and configuration was required. Not only are technology and configuration crucial, but also the processes and procedures that you use to maintain the messaging system. This module describes the high availability technology built into Exchange Server 2010 and some of the outside factors that affect highly available solutions. After completing this module, you will be able to: Describe high availability options. Configure highly available mailbox databases. Deploy highly available non-Mailbox servers.
7-3
Lesson 1
High availability is a commonly used term that refers to a specific technology or configuration that promotes service availability. Although many technologies and configurations can lead to highly available configurations, they are not by themselves truly highly available. Much more effort is required to provide a high availability solution. In this lesson, you will review high availability, and some of the factors that go into designing and deploying a highly available solution. After completing this lesson, you will be able to: Describe high availability. Identify the components of a high availability solution. Implement a high availability solution for Mailbox servers. Implement a high availability solution for non-Mailbox servers.
7-4
Key Points
High availability is a system design implementation that ensures a high level of operational continuity over a specific time. Although many people attribute high availability to a specific technology, such as failover clustering or load balancing, you can truly achieve high availability only with good design, testing, training, and operational processes. There are two types of downtime: planned and unplanned. Planned downtime is the result of events you schedule, such as maintenance. By contrast, unplanned downtime is the result of events not within direct control of information technology (IT) administrators. These events can be minor, such as a buggy hardware driver or a processor that fails, or catastrophic, such as flood, fire, or earthquake.
7-5
Measuring Availability
Availability often is expressed as the percentage of time that a service is available for use. For example, a requirement for 99.9 percent availability over a one-year period allows 8.75 hours of downtime. In complex environments, organizations typically specify availability for a specific service, such as Exchange messaging, which in turn may have availability goals tied to specific features such as Microsoft Outlook Web App, Simple Mail Transfer Protocol (SMTP) message delivery, and Outlook Anywhere. For more information on high availability, refer to the CD content.
7-6
Key Points
Numerous components can comprise a messaging solution, and you should scrutinize them to ensure that failures will not affect the entire solutions availability. Once you identify these components, you can mitigate failures. Question: Which components are important for running a high availability solution? Question: What are some common single points of failure in a messaging solution?
7-7
Key Points
Exchange Server 2010 provides a number of improvements for mailbox availability. Although mailbox high availability implementation differs in Exchange Server 2007, the basic concepts are the same. Exchange Server 2010 improves upon many of the Exchange Server 2007 mailbox availability features. For example, one database can have as many as 16 copies on 16 servers, and you can activate it on any of the servers without disconnecting clients. Additionally, to provide increased insurance against corruption, you can set these database copies to not apply transaction logs for up to 14 days. With the appropriate tools, you can use these lag copies to recover database information from a point up to 14 days previously. Details about how mailbox high availability works appears later in this module. There are no changes to public folder high availability in Exchange Server 2010. Although you should consider the location of the public folder servers, create a high availability environment by adding replicas to multiple servers. Since this requires no additional configuration, this module does not discuss public folder high availability.
7-8
Key Points
It is as important to have high availability solutions for non-Mailbox server roles as for the Mailbox server roles, because not having them affects connectivity with the Mailbox server. For each of the non-Mailbox server roles, adding redundancy starts with adding multiple servers, and ends with configuring load balancing, whether with configuration, or software or hardware load balancing. If you are familiar with the high availability solutions for non-Mailbox server roles in Exchange Server 2007, these concepts largely hold true in Exchange Server 2010. This module provides details about making each of the non-Mailbox server roles highly available.
7-9
Lesson 2
Historically, the Mailbox server role was the most complex and critical component in a highly available Exchange Server deployment. Although this remains true, to a degree, Exchange Server 2010 reduces the complexity of deploying a highly available Mailbox server. In doing so, it also reduces the likelihood that administrators will configure an Mailbox server cluster improperly. After completing this lesson, you will be able to: Describe database availability group (DAG). Describe Active Manager. Describe continuous replication. Describe how DAGs protect databases. Identify the differences between Exchange Server 2010 and Exchange Server 2007 mailbox availability options.
7-10
Configure databases for high availability. Create and configure a DAG. Describe the transport dumpster. Describe the failover process. Monitor replication health.
7-11
Key Points
A DAG is a collection of servers that provides the infrastructure for replicating and activating database copies. The DAG leverages continuous transaction log replication to each of the passive database copies within the DAG, which: Requires the failover clustering feature, although all installation and configuration tasks occur with the Exchange Server management tools. Although a DAG requires the failover clustering feature, Exchange Server does not use Windows failover clustering to handle database failover. Instead, it uses Active Manager to control failover. Uses an enhanced version of the continuous replication technology that was in Exchange Server 2007. The best continuous replication pieces from Exchange Server 2007 were improved. Can be created after you install the Mailbox server. You can set up a Mailbox server to host active mailboxes, and then add it to the DAG later.
7-12
Allows you to move a single database between servers in the group without affecting other databases. Failover clustering occurs per mailbox database, not for an entire server, which makes Exchange Server 2010 more flexible than previous Exchange Server versions. Allows up to 16 copies of a single database on separate servers. You can add up to 16 servers to a DAG, which allows you to create up to 16 copies of a database. The database copies must be stored in the same path on all servers. For example, if you store Mailbox Database 1 in D:\Mailbox\DB\Mailbox Database 1\ on VAN-EX1, then you must also store it in D:\Mailbox\DB \Mailbox Database 1\ on all other servers that host Mailbox Database 1 copies. Defines the boundary for replication since only servers within the DAG can host database copies. You cannot replicate database information to Mailbox servers outside the DAG.
7-13
Key Points
Exchange Server 2010 includes a new component called Active Manager. Active Manager replaces the resource model and failover management features that previous Exchange Server versions provided during integration with the cluster service. Exchange Server no longer uses the cluster resource model for high availability. Exchange Server uses a Windows failover cluster, but there are no cluster groups for Exchange Server, and the cluster has no storage resources. In the Failover Cluster Management Console, you will see only the core cluster resources (IP Address and Network Name).
7-14
The Active Manager runs on all Mailbox servers that are DAG members and runs as either the primary active manager (PAM) or a standby active manager (SAM). The PAM is the Active Manager in a DAG that decides which copies will be active and passive, and it is responsible for processing topology change notifications and reacting to server failures. Far from having a passive role, the SAM provides information about which server hosts the active copy of a mailbox database to other components of Exchange Server, such as the RPC Client Access service and the Hub Transport server. The SAM detects local database and local Information Store failures. It reacts to failures by asking the PAM to initiate a failover (if the database is replicated).
7-15
Key Points
Continuous replication was introduced for Mailbox servers in Exchange Server 2007. This feature creates a passive database copy on another Exchange Server computer in the DAG, and then uses asynchronous log shipping to maintain the copies. The continuous replication process is as follows: 1. 2. 3. The active log is written, and then closed. The Replication Service replicates the closed log to servers hosting the passive databases. Since each copy of the database is identical, the transaction logs are inspected and then replayed or applied to the database copies. The databases remain in sync.
7-16
Key Points
The active database copy uses continuous replication to keep the passive copies in sync based on their lag-time setting. A DAG leverages the Windows Server operating system failover clustering feature. However, it relies on the Active Manager server to maintain the status of all of the DAGs hosted databases. You can switch or fail over a single database between DAG servers. However, it is only active on one node at a time. At any given time, a copy is either the replication source or the replication target, but not both. A server may not host more than one copy of a given database. Not all databases need to have the same number of copies. In a 16-node DAG, one database can have 16 copies, while another database is not redundant and contains only the one active copy.
7-17
Database failovers occur when failures cause the active database to go offline. Either a single server failure or something specific to a database may cause the failure. A switchover occurs when an administrator intentionally coordinates moving the active database from one server to another.
7-18
Comparing Exchange Server 2010 to Exchange Server 2007 Mailbox Availability Options
Key Points
Exchange Server 2010 extends and improves upon the continuous replication technology that Exchange Server 2007 used. The new high availability model using the DAG is a more flexible and resilient solution than previous high availability solutions. The Exchange Server 2010 database high availability model: Has no single point of failure. Supports backups. Allows up to 16 copies of a database with a 14-day lag time. Can have multiple servers roles run on the same server as the mailbox server. Allows you to move a single database between servers.
7-19
Key Points
Creating a DAG is only the first step to providing database availability. You must create and configure additional database copies. Not only can you create a database copy initially, but an administrator also can create one at any time. You can distribute database copies across Mailbox servers in a flexible and granular way. You can replicate one, some, or all mailbox databases on a server in several ways. Specify the following information when creating a mailbox database copy: The name of the database you are copying. The name of the Mailbox server that will host the database copy. The amount of time (in minutes) for log replay delay. This is as the replay lag time, which sets how long to wait before the logs are committed to the database copy. Setting the value for replay lag time to 0 turns off log replay delay.
7-20
The amount of time (in minutes) for log truncation delay. This is truncation lag time, which sets how long to wait before truncating committed transaction logs. Setting the value for truncation lag time to 0 turns off log truncation delay. An activation preference number. This is referred to as a preferred list sequence number, and it represents the activation preference order of a database copy after a failure or outage of the active copy.
DAG Networks
A DAG network is a collection of one or more subnets that Exchange Server uses for either replication traffic or MAPI traffic. Although Exchange Server supports one network adapter and path, we recommend a minimum of two DAG networks. In a two-network configuration, you typically dedicate one network to replication traffic and the other network to MAPI traffic. You can create additional networks in a DAG and configure them as replication networks for redundancy. We recommend that you do not use Internet SCSI (iSCSI) networks for DAG replication. Question: How do you plan to use the preferred list sequence number?
7-21
Key Points
In this demonstration, you will review how to create a new database availability group, add member servers to it, and create a copy of a mailbox database.
Demonstration Steps
1. 2. Click Start, click All Programs, click Microsoft Exchange Server 2010, and then click Exchange Management Shell. Use the New-DatabaseAvailabilityGroup cmdlet to create a Database Availability Group named DAG1 with a WitnessServer on VAN-DC1, and a WitnessDirectory of C:\FSWDAG1. Assign the DAG an IP Address of 10.10.0.25. Use the Add-DatabaseAvailabilityGroupServer cmdlet to add VAN-EX1 as a member. Click Start, click Programs, click Microsoft Exchange Server 2010, and then click Exchange Management Console.
3. 4.
7-22
5. 6.
Use the Manage Database Availability Group Membership Wizard to add VAN-EX2 as a member of DAG1. Use the Add Mailbox Database Copy Wizard to add a copy of Mailbox Database 1 to the second Mailbox server.
Note: Once you create a DAG, you then can create and configure DAG networks for replication or for MAPI traffic. Add additional networks for redundancy or improved throughput.
Question: What information do you need before you can configure a DAG?
7-23
Key Points
If a failure occurs and some transaction logs are not replicated to the passive copy, you can use the transport dumpster to redeliver any recently delivered e-mail. The transport dumpster operates on the Hub Transport servers within Active Directory Domain Services (AD DS) or Active Directory directory service. When a database failover occurs, a request will be made to the Hub Transport servers to redeliver the lost e-mail messages. The next section details database failovers. The transport dumpster only holds e-mail that has been delivered. The local submission queue holds any pending e-mail. Once the transaction logs are replicated to each DAG server, the transport dumpster purges the message.
7-24
Key Points
A failover occurs when the server hosting the active database goes offline or something causes the active database to dismount. A switchover occurs when an administrator moves the active database from one server to another. When a failure affecting the active database occurs, Active Manager uses several sets of selection criteria to determine which database copy to activate. In the process for selecting the best copy to activate, Active Manager: 1. 2 3. 4. Enumerates the available copies. Ignores all unreachable servers. Sorts available copies by how current they are. The factors considered include the content index, copy queue length, and replay queue length. Uses the activation preference, if a tie breaker is necessary.
7-25
Database Failovers
Before using the previously mentioned criteria to locate the best copy to activate, a process called attempt copy last logs (ACLL) occurs. ACLL makes parallel remote procedure calls to each DAG Mailbox server that hosts a copy of the mailbox database. This call checks if the server is available and healthy, and to examine the LogInspectorGeneration value for the database copy. The mailbox database copy with the highest LogInspectorGeneration value is the best source for copying log files. After the ACLL process is complete, and if all missing log files were copied from the selected best source, the database mounts without any data loss. This is known as a lossless failure. If the ACLL process fails, then the configured AutoDatabaseMountDial value is consulted. If the number of lost logs is within the configured AutoDatabaseMountDial value, then Exchange Server mounts the database. If the number of lost logs falls outside the configured AutoDatabaseMountDial value, then Exchange Server does not mount the database until either missing log files are recovered, or an administrator explicitly mounts the database and accepts the larger data loss. Use the Set-MailboxServer cmdlet to configure the AutoDatabaseMountDial setting for each DAG Mailbox server.
7-26
Key Points
In this demonstration, you will review how to use the Exchange Management Console and Exchange Management Shell to review the available information regarding database-replication health.
Demonstration Steps
1. 2. 3. 4. On VAN-EX1, click Start, click All Programs, click Microsoft Exchange Server 2010, and then click Exchange Management Console. In the Console Tree, expand Microsoft Exchange On-Premises, expand Organization Configuration, and then expand Mailbox. Review the status of each of the Mailbox Database 1 database. Close Exchange Management Console.
7-27
Lesson 3
Other Exchange Server roles now handle some functionality that was handled by the Mailbox server in previous Exchange Server versions. For example, Microsoft Office Outlook clients no longer directly connect to the Mailbox server, but rather connect to the Client Access server for MAPI-based communication. Additionally, the Mailbox server no longer processes mailbox. The Hub Transport server now performs this task. With the other server roles performing more tasks, they become more important to the messaging environments overall health. In this lesson, you will consider providing high availability for these non-mailbox servers. After completing this lesson, you will be able to: Describe and configure high availability for Client Access servers. Describe and configure high availability for Hub Transport servers. Describe and configure high availability for Edge Transport servers.
7-28
Key Points
A client access array is a load-balanced collection of Client Access servers that is in a single site. Since all client connections, including MAPI, rely on connections to Client Access servers, it is important to provide a redundant server array to improve availability. To create a client access array, you first must deploy multiple Client Access servers. Next, you need to use either hardware or software-based network load balancing to create a cluster. Then, add the name for the network load-balanced cluster into the Domain Name System (DNS). For example, you could add an A record for caa1.contoso.com that points to 10.10.10.25. After adding the DNS record, you can create the client access array and assign it to an Active Directory site using the New-ClientAccessArray cmdlet. Finally, you must assign the client access array to each of the mailbox databases in the site using the Set-MailboxDatabase cmdlet with the RpcClientAccess parameter. A client access array can exist only in a single Active Directory site. Therefore, you would need to create a client access array in each Active Directory site that needs to load balance client access servers.
7-29
How Shadow Redundancy Provides High Availability for Hub Transport Servers
Key Points
Exchange Server 2010 includes the shadow redundancy feature, which provides redundancy for messages for the entire time they are in transit. This is in addition to the transport dumpster. With shadow redundancy, the message deletion from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting successful delivery, the transport server resubmits the message for delivery to that next hop. In the shadow redundancy scenario, the message flow follows these stages: 1. Hub delivers message to Edge. a. b. c. Hub opens SMTP session with Edge. Edge advertises shadow redundancy support. Hub notifies Edge to track discard status.
7-30
d. Hub submits message to Edge. e. f. 2. Edge acknowledges the receipt of message and records the Hubs name for sending discard information for the message. Hub moves the message to the shadow queue for Edge and marks Edge as the primary server. Hub becomes the shadow server.
Edge delivers message to the next hop: a. b. c. Edge submits message to third-party mail server. Third-party mail server acknowledges the messages receipt. Edge updates the discard status for the message as delivery complete.
3.
Hub queries Edge for discard status (success case): a. At end of each SMTP session with Edge, Hub queries Edge for discard status on messages previously submitted. If Hub has not opened any SMTP sessions with Edge after the initial message submission, it will open an SMTP session with Edge to query for discard status after a specific time. Edge checks local discard status and sends back the list of messages that have been delivered, and removes the discard information. Hub server deletes the list of messages from its shadow queue.
b. c. 4.
Hub queries Edge for discard status and resubmits the message (failure case): a. b. If Hub cannot contact Edge, Hub resumes the primary server role and resubmits the messages in the shadow queue. Resubmitted messages are delivered to another Edge server, and the workflow starts from step 1.
Within Exchange Server 2010, the Shadow Redundancy Manager (SRM) is the core component of a Transport server that is responsible for managing shadow redundancy. The SRM is responsible for maintaining the following information for all the primary messages that a server is currently processing: The shadow server for each primary message being processed. The discard status to be sent to shadow servers.
7-31
The SRM is responsible for the following, for all the shadow messages that a server has in its shadow queues: Maintaining the list and checking primary server availability for each shadow message. Processing discard notifications from primary servers. Removing the shadow messages from the database once it receives all expected discard notifications. Deciding when the shadow server should take ownership of shadow messages, thus making it the primary server.
7-32
Key Points
Edge Transport servers provide both inbound and outbound e-mail delivery. For outbound delivery, providing high availability is as simple as deploying multiple Edge Transport servers and creating an Edge subscription. If you have deployed Exchange servers in multiple Active Directory sites, you may need additional redundant Edge Transport servers.
7-33
7-34
Lab Setup
For this lab, you will use the available virtual machine environment. Before you begin the lab, you must: 1. 2. On the host computer, click Start, point to Administrative Tools, and click Hyper-V Manager. Ensure that the 10135A-VAN-DC1, 10135A-VAN-EX1, 10135A-VAN-EX2, and the 10135A-VAN-EX3 virtual machines are running: 3. 10135A-VAN-DC1: Domain controller in the Adatum.com domain. 10135A-VAN-EX1: Exchange 2010 server in the Adatum.com domain. 10135A-VAN-EX2: Exchange 2010 server in the Adatum.com domain. 10135A-VAN-EX3: Exchange 2010 server in the Adatum.com domain.
If required, connect to the virtual machines. Log on to the virtual machines as Adatum\Administrator, using the password Pa$$w0rd.
7-35
Lab Scenario
You are the messaging administrator for A. Datum Corporation. You have completed the basic installation for three Exchange servers. Now you must complete the configuration so that they are highly available.
7-36