Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Deploy exchange 2016 highly available clusters

2025-01-28 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/03 Report--

This case environment is followed by the previous migration environment, if there is anything you do not understand can refer to the previous two chapters blog, the operation steps have been written very clearly:

Exchange 2010 migration exchange 2016 build environment

Migrating Exchange 2010 to Exchange 2016

1. Case analysis 1. Case overview

After migrating Exchange 2010 to Exchange 2016, the mail system has been working steadily and has implemented a relatively complete backup plan. However, there is always the potential for a single point of failure, which can disrupt email traffic throughout the enterprise while backups are used for recovery. To avoid the loss of a single point of failure, it was decided to deploy a new server and deploy the exchange 2016 DAG.

2. Pre-knowledge points 1) DAG

Exchange 2007 and earlier To achieve high availability, you must first deploy a Windows failover cluster with only the Mailbox server role installed on the cluster nodes (other roles cannot be installed within the cluster). If a mailbox database fails on one server in the cluster, all databases and mail services, including the failed database, stop working, and then transfer and activate the other servers and their database replicas. This mechanism is a "server-level" failover in which the failed node loses service and the database that did not fail is forced to migrate.

DAG is the foundational component of the Mailbox Server High Availability and Site Recovery Framework built into Exchange Server 2016. A DAG consists of a group of up to 16 mailbox servers, each of which synchronizes and maintains a copy of the DAG's mailbox database, automatically performing a database-level failover in the event of a single server or database failure. That is, DAG is a failover at the database level, with the following key characteristics:

Cost savings. Exchange 2016 has consolidated multiple roles so that small and medium-sized organizations can achieve a complete solution with two servers.

Flexible deployment and easy to scale. Instead of deploying failover clusters first, it is more in line with the reality of organizational evolution: starting with a single server and then creating DAGs as needed.

Limited dependency on Windows failover clusters, DAG uses only the cluster's quorum, heartbeat, and other features.

Implement database level migration without migrating a failure-free database.

Do not stop the service. The transfer process does not affect user access.

No Windows failover cluster management experience required, managed from exchange admin center.

Reduce the importance of backups "to avoid database corruption." When the DAG mailbox database has more than 3 copies, there is basically no need to backup. The primary effect of DAG backups is to prevent users from accidentally deleting messages that have exceeded the recovery cycle (default 14 days).

Remote disaster recovery can be realized. For example, if a DAG's member servers are distributed across multiple sites within the same domain, the mailbox databases within each site will backup each other because of the DAG's working mechanism. All servers in the DAG must be running the same version of exchange. 3. DAG clustering and arbitration

When a DAG is initially created, AD Active Directory uses an empty object to store information about the DAG, such as DAG membership information and configuration. When the first server is added to the DAG, a DAG-specific failover cluster is automatically created, and then the failover cluster's heartbeat mechanism and cluster database are used to track and manage the state of the DAG. Clients access the cluster through the DAG cluster's unique name or cluster IP address and are responded to by active servers within the cluster.

Because the DAG is based on Windows failover clusters, failover clusters use arbitration to determine which members are active and which are offline to determine whether the DAG is functioning properly (if N is the number of members, at least N/2+1 members are active). Therefore, arbitration is important for DAGs, and if the cluster loses arbitration, the DAG becomes unavailable and all mailbox databases are unloaded until an administrator can intervene manually to restore them.

4. There are two arbitration modes of DAG:

1) When the DAG has an odd number of member servers, the DAG uses the failover cluster node majority arbitration mode. Witness servers are not used in this pattern. Each DAG member stores cluster quorum data locally, and if the DAG configuration changes, the changes are synchronized on different disks, and changes are considered valid and persisted only if synchronized changes occur on most members 'disks. For example, when the DAG has 3 members, the total number of votes should be 3, and the actual minimum number of votes is 4/2+1=2, that is, at most 1 member can fail.

2) When the DAG has an even number of member servers, the DAG uses the "failover cluster node and file sharing majority arbitration mode," which uses an external witness as referee. By default, each DAG member stores a copy of the cluster arbitration data and stays synchronized, so they all have voting rights, while the witness server uses a file to record which member has the latest copy of the arbitration data, so the witness server provides a critical vote to that DAG member, thus ensuring that most voters can communicate with each other (active state). For example, when the DAG has 4 members, the total number of votes should be 5 (1 of which is the witness server), and the actual minimum number of votes is 5/2+1=3, that is, at most 2 members can fail at the same time.

5. Witness server

Because arbitration is required, when creating a DAG, you need to configure a witness server and witness directory, which are used only if the DAG has an even number of members. The requirements for witness servers are as follows:

Witness servers cannot also be DAG members;

Witness servers must be in the same AD forest as DAG;

The witness server must be running a version of Windows supported by the exchange server;

A witness server can support multiple DAGs at the same time, but each DAG must have its own witness directory.

DAG01 node server adds two network cards VM2 (external service) and VM3 (heartbeat transmission)

Configure IP address of VM3

1. Configure DAG_02:

DAG02 node also adds two network cards, VM2 (external service) and VM3 (transmission heartbeat)

Configure IP address and join domain

computer joins a domain

Administrator login domain

Install Exchange 2016 dependent software

Installation complete, restart computer, mount exchange 2016 CD

Running a shell as administrator installs two dependencies

Copy all CD files to a new folder on your computer

Open the replicated setup program to begin installing exchange 2016

Select Do not check for updates now and click Next

Do not use recommended settings, click Next

Check Mailbox Role and click Next

Default Next

Select No and click Next

Prerequisites check complete, start installation

Wait for the installation to complete

Installation complete, restart computer

Create a DAG directory on domain controller DC1

add permissions

Check whether permissions were added successfully

2. Configure DAG_01:

Add DAG Members

Add database, create two folders

Add database copy

Migrate user mailboxes

Domain controller add user alice

Add user mailbox for Alice, mailbox database set to IT_DB

Delete DNS alias of intranet

add new ones

Open pop3 front-end and back-end services for DAG02

DAG02 Node Configuration Receive Connector

DAG02 Node Add Send Connector

Configure DNS external lookups for DAG02 nodes

Configure public DNS, add hosts, aliases and MX records again

add a host

new alias

New MX Record

Testing email on the intranet

Close DAG01 node, simulate automatic switching DAG02 node

Alice logs in to the client and sends an email to marry to test the internal and external network sending and receiving

-----This article ends here, thanks for reading----

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report