Partager via

Link + Pasted from Technet - Exchange 2013 (>=CU1) : How does Autoreseed works

  • Article

First configure Autoreseed for your DAG(s):

https://technet.microsoft.com/en-us/library/jj619303.aspx

Second, here is the process, explained by Scott Schnoll:

AutoReseed is designed to automatically restore database redundancy after a disk failure by using spare disks that have been provisioned on the system.

CU1 includes numerous fixes to AutoReseed, including fixes for issues around AutoReseed not detecting spare disks correctly and AutoReseed not using detected spare disks.  In addition, the following enhancements have been made to AutoReseed:

  • GetCopyStatus now has a new field 'ExchangeVolumeMountPoint', which shows the mount point of the database volume under C:ExchangeVolumes (or a custom folder if you are not using the default setting of C:ExchangeVolumes).  This is useful information to know because in a configuration that uses multiple disks per volume, the LogicalDisk performance counters show up as the first mount point (which would be the one under C:ExchangeVolumes) instead of as the database path like they used to in Exchange 2010 with a single disk per volume.
  • We now have better internal tracking around mount paths and the ExchangeVolume path.
  • The limits for AutoReseed have been increased from 4 databases per volume in Exchange 2013 RTM to 8 databases per volume in CU1.
  • AutoReseed properties have been added to Active Directory that allow you to enable and disable automatic reseeding and the DiskReclaimer function (which formats Exchange volumes). The two new properties are:
    • AutoDagAutoReseedEnabled - Setting AutoDagAutoReseedEnabled to false turns off AutoReseed (including automatic resume, sparing, and in-place reseeds).
    • AutoDagDiskReclaimerEnabled - Setting AutoDagDiskReclaimerEnabled to false turns off the DiskReclaimer, which formats exchange volumes. The default setting is true, and it only tries to format volumes mounted under C:ExchangeVolumes.
  • The unused AutoDagFailedVolumesRootFolderPath property was also removed from the DAG object.

As a result of these and other changes, the workflow for AutoReseed in CU1 has changed.  The primary input condition for the AutoReseed workflow is still a database copy that is in an Failed and Suspended (F&S) state for 15 consecutive minutes.  When that condition is detected, the following AutoReseed workflow is initiated:

  1. The system will first try to resume the database copy up to 3 times, with 5 minute sleeps in between each try.  Sometimes, after an F&S database copy is resumed, the copy remains in a Failed state. This can happen for a variety of reasons, so this first step is designed to handle all such cases; AutoReseed will automatically suspend a database copy that has been Failed for 10 consecutive minutes to keep the workflow running. If the suspend and resume actions don’t result in a healthy database copy, the workflow continues.
  2. Next, AutoReseed will perform a variety of pre-requisite checks. For example, it will verify that a spare disk is available, that the database and its log files are configured on the same volume, and in the appropriate locations that match the required naming conventions. In a configuration that uses multiple databases per volume, AutoReseed will also verify that all database copies on the volume are in an F&S state.
  3. Next, AutoReseed will attempt to assign a spare volume up to 5 times, with 1 hour sleeps in between each try.
  4. Once a spare has been assigned, AutoReseed will perform an InPlaceSeed operation using the SafeDeleteExistingFiles seeding switch.  If one or more database files exists, AutoReseed will wait for 2 days before in-place reseeding (based on the LastWriteTime of the database file).  This provides an administrator with an opportunity to preserve data, if needed.  AutoReseed will attempt a seeding operation up to 5 times, with 1 hour sleeps in between each try.

Once all retries are exhausted, the workflow stops.  If, after 3 days, the database copy is still F&S, the workflow state is reset and it starts again from Step 1.  This reset/resume behavior is useful (and intentional) since it can take a few days to replace a failed disk, controller, etc..

Complete article here: https://blogs.technet.com/b/scottschnoll/archive/2013/04/02/high-availability-changes-in-exchange-server-2013-cumulative-update-1.aspx