The operational management tasks associated with DAGs include:

• Creating one or more DAGs   Creating a DAG is typically a one-time procedure performed during the deployment phase of the solution lifecycle. However, there may be reasons for creating DAGs that occur during the operational phase. For example:
  
  
  • The DAG is configured for third-party replication mode, and you want to revert to using continuous replication. You can't convert a DAG back to continuous replication; you need to create a DAG.
    
    
  • You have servers in multiple domains. All members of the same DAG must also be members of the same domain.
    
    
• Managing DAG membership   Managing DAG members is an infrequent task typically performed during the deployment phase of the solution lifecycle. However, because of the flexibility provided by incremental deployment, managing DAG membership may also be performed throughout the solution lifecycle.
  
  
• Configuring DAG properties   Each DAG has various properties that can be configured as needed. These properties include:
  
  
  • Witness server and witness directory   The witness server is a server outside the DAG that acts as a quorum voter when the DAG contains an even number of members. The witness directory is a directory created and shared on the witness server for use by the system in maintaining a quorum.
    
    
  • IP addresses   Each DAG will have one or more IPv4 addresses, and optionally, one or more IPv6 addresses. The IP addresses assigned to the DAG are used by the DAG's underlying cluster. The number of IPv4 addresses assigned to the DAG equals the number of subnets that comprise the MAPI network used by the DAG. You can configure the DAG to use static IP addresses or to obtain addresses automatically by using Dynamic Host Configuration Protocol (DHCP).
    
    
  • Database activation coordination mode   Database activation coordination mode is a property setting on a DAG that's designed for DAGs with three or more members that have been deployed to multiple sites. Database activation coordination mode is used to handle conditions that would otherwise lead to a split-brain syndrome within the DAG, such as a site failure. For more information about database activation coordination mode, see Understanding Datacenter Activation Coordination Mode.
    
    
  • Alternate witness server and alternate witness directory   The alternate witness server and alternate witness directory are values that you can preconfigure as part of the planning process for DAGs configured for site resilience.
    
    
  • Replication port   By default, all DAGs use TCP port 64327 for continuous replication. You can modify the DAG to use a different TCP port for replication by using the ReplicationPort parameter of the Set-DatabaseAvailabilityGroup cmdlet.
    
    
  • Network discovery   You can force the DAG to rediscover networks and network interfaces. This operation is used when you add or remove networks or change DAG network subnets. Rediscovery of all DAG networks can be forced by using the DiscoverNetworks parameter of the Set-DatabaseAvailabilityGroup cmdlet.
    
    
  • Network compression   By default, DAGs use compression only between DAG networks on different subnets. You can enable compression for all DAG networks or for seeding operations only, or you can disable compression for all DAG networks.
    
    
  • Network encryption   By default, DAGs use encryption only between DAG networks on different subnets. You can enable encryption for all DAG networks or for seeding operations only, or you can disable encryption for all DAG networks.
    
    
• Managing DAG networks   Although using a single network interface card (NIC) is supported, we recommend that each DAG member have at least two NICs. One NIC is used for the MAPI network, and one NIC is used for the replication network. Additional NICs can be added to create additional replication networks, for use as dedicated backup networks, or for use by the system as Internet SCSI (iSCSI) storage. DAG network management involves designating a network as a MAPI network or as a replication network, and configuring network subnets.
  
  
• Shutting down DAG members   The Exchange 2010 high availability solution is integrated with the Windows shutdown process. If an administrator or application initiates a shutdown of a Windows server in a DAG that has a mounted database that's replicated to one or more DAG members, the system will try to activate another copy of the mounted databases prior to allowing the shutdown process to complete. However, this new behavior doesn't guarantee that all of the databases on the server being shut down will experience a loss-less activation. As a result, it's a best practice to perform a server switchover prior to shutting down a server that's a member of a DAG.
  
  

For detailed steps to create a DAG, see Create a Database Availability Group. For detailed steps to configure DAGs and DAG properties, see Configure Database Availability Group Properties. For more information about each of the preceding management tasks, and about managing DAGs in general, see Managing Database Availability Groups.

Return to top