hadiscard exchange что это

Hadiscard exchange что это

Вопрос

1 when i run the above command and when i filter the output in csv file i can eventid listed below
what does those eventid’s mean
HARECEIVE
HADISCARD
HAREDIRECT
TRANFER
AGENTINFO

2. what does sourcecontext mean

3. Under source i can see routing & agent, what does they mean.

Ответы

HARECEIVE: A shadow message was received by the server in the local database availability group (DAG) or Active Directory site.

HADISCARD: A shadow message was discarded after the primary copy was delivered to the next hop. For more information.

HAREDIRECT: A shadow message was created.

AGENTINFO: This event is used by transport agents to log custom data.

Sourcecontext: Extra information associated with the source field.

Such as when the source is StoredDriver, the information in Sourcecontext will related with database and mailbox.

Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

Источник

Отслеживание сообщений

Журнал отслеживания сообщений — это подробный отчет о всех действиях по потоку почты через транспортный конвейер на серверах почтовых ящиков и на транспортных серверах edge. Отслеживание сообщений можно использовать для судебной экспертизы сообщений, анализа потока сообщений, отчетности и устранения неполадок.

По умолчанию Exchange для ограничения журнала отслеживания сообщений в зависимости от размера файла и возраста файлов для управления пространством жесткого диска, используемым файлами журнала. Чтобы настроить журнал отслеживания сообщений, см. в тексте Настройка отслеживания сообщений.

Поиск в журнале отслеживания сообщений

Журналы отслеживания сообщений содержат огромное количество данных по мере перемещения сообщений через сервер почтовых ящиков или на границе транспортного сервера. Когда речь заходит о поиске журналов отслеживания сообщений, у вас есть варианты:

Get-MessageTrackingLog. Администраторы могут использовать этот Exchange команды управленческой оболочки для поиска журнала отслеживания сообщений для получения сведений о сообщениях с использованием широкого спектра критериев фильтрации. Дополнительные сведения см. в журнале отслеживания сообщений поиска.

Отчеты о доставке для администраторов. Администраторы могут использовать вкладку Отчеты о доставке в центре администрирования Exchange или в окне поисковых сообщений Search-MessageTrackingReport и Get-MessageTrackingReport в оболочке управления Exchange для поиска журналов отслеживания сообщений для получения сведений о сообщениях, отправленных или полученных определенным почтовым ящиком в организации. Дополнительные сведения см. в сообщении о доставке для администраторов.

Структура файлов журналов отслеживания сообщений

Другие места в именах файлов журнала представляют следующую информацию:

yyyymmdd — это дата создания файла журнала (в формате UTC). yyyy = год, мм = месяц и dd = день.

nnnn — это номер экземпляра, который начинается со значения 1 каждый день для каждого журнала.

достигнут максимальный срок хранения файла журнала;

Папка журнала отслеживания сообщений достигает максимального размера.

Примечания:

Максимальный размер папки журнала отслеживания сообщений рассчитывается как общий размер всех файлов журнала с одним и тем же префиксом имен. Другие файлы, которые не следуют конвенции префикса имен, не учитываются в расчете общего размера папки. Переименование старых файлов журнала или копирование других файлов в папку журнала отслеживания сообщений может привести к превышению указанного максимального размера папки.

Файлы журналов отслеживания сообщений представляют собой текстовые файлы с данными в формате CSV. Каждый файл журнала отслеживания сообщений имеет заголовок, содержащий следующие сведения:

#Date. Время даты UTC, когда был создан файл журнала. Дата UTC представлена в формате дата-времени ISO 8601: yyyy-mm-dd T hh:mm:ss.fff Z, где yyyy = год, мм = месяц, dd = день, T указывает начало компонента времени, hh = час, мм = минута, ss = second, fff = доли секунды, а Z означает Zulu, который является еще одним способом обозначить UTC.

#Fields: имена полей, которые используются в файлах журнала отслеживания сообщений.

Поля в файлах журналов отслеживания сообщений

В журнале отслеживания сообщений каждое событие, связанное с сообщением, заносится в отдельную строку. Информация о событиях с сообщениями упорядочена по полям, разделенным запятыми. Обычно имя поля достаточно полно характеризует информацию, которая в нем хранится. Однако некоторые поля могут быть пустыми, или тип сведений в поле может изменяться в зависимости от типа события сообщения и службы, записав событие. В следующей таблице приводятся общие описания полей, которые используются для классификации каждого события отслеживания сообщений.

Типы событий в журнале отслеживания сообщений

Различные типы событий в поле event-id используются для классификации событий, связанных с сообщениями, в журнале отслеживания сообщений. Некоторые события, связанные с сообщениями, отображаются только в одном типе файлов журнала отслеживания сообщений, а некоторые — во всех типах файлов. Типы событий, используемые для классификации каждого события, приведены в следующей таблице.

Значения источника в журнале отслеживания сообщений

Значения в поле source в журнале отслеживания сообщений указывает на компонент транспорта, ответственный за событие отслеживания сообщений. В следующей таблице описаны значения поля source.

Примеры записей в журнале отслеживания сообщений

Не вызвавшее событий сообщение, отправленное между двумя пользователями, создает несколько записей в журнале отслеживания сообщений. Результаты можно просмотреть с помощью командлета Get-MessageTrackingLog. Подробнее см. в разделе Поиск в журналах отслеживания сообщений.

Это пример записей журнала отслеживания сообщений, созданных при успешной chris@contoso.com отправки тестового сообщения пользователю michelle@contoso.com. У обоих пользователей есть почтовые ящики на одном и том же сервере.

Журнал отслеживания сообщений и вопросы безопасности

В журнале отслеживания сообщений не хранится содержимое сообщений. По умолчанию в этот журнал заносятся темы сообщений электронной почты. Возможно, вам потребуется отключить ведение журнала субъектов, чтобы соответствовать повышенным требованиям безопасности или конфиденциальности. Инструкции по отключению ведения журнала субъектов см. в инструкции По настройке отслеживания сообщений.

Источник

Управление группами доступности баз данных в Exchange Server

Группа доступности базы данных (DAG) — это набор до 16 серверов почтовых ящиков Exchange, которые обеспечивают автоматическое восстановление на уровне базы данных из базы данных, сервера или сбоя сети. В группах DAG используется непрерывная репликация и подмножество технологий отказоустойчивых кластеров Windows, чтобы обеспечить высокий уровень доступности и устойчивость сайта. Почтовые серверы в группе доступности базы данных отслеживают сбои в работе друг друга. Когда сервер почтовых ящиков добавляется в DAG, этот сервер работает с другими серверами в DAG, чтобы обеспечить автоматическое восстановление базы данных на уровне базы данных после сбоев в базе данных.

Первоначально создается пустая группа DAG. Когда первый сервер добавляется к группе DAG, для нее автоматически создается отказоустойчивый кластер. Кроме того, инициализируется инфраструктура, которая отслеживает сбои на серверах и в сети. Механизм периодических сигналов о подтверждении соединения с отказоустойчивым кластером и база данных кластера затем используются для отслеживания и обработки информации о группе доступности, которая может быстро изменяться, например о состоянии подключения базы данных, состоянии репликации и о последнем подключении.

Создание групп обеспечения доступности баз данных

DAG можно создать с помощью мастера группы доступности новой базы данных в центре администрирования Exchange (EAC) или с помощью команды New-DatabaseAvailabilityGroup в Exchange Management Shell. При создании группы обеспечения доступности базы данных необходимо указать ее имя, а также необязательные параметры следящего сервера и следящего каталога. Кроме того, группе можно назначить один или несколько IP-адресов, используя статические IP-адреса или разрешив группе автоматически получить необходимые IP-адреса с помощью протокола DHCP. Вы можете вручную назначить IP-адреса DAG с помощью параметра DatabaseAvailabilityGroupIpAddresses. Если этот параметр не указан, группа попытается получить IP-адрес с помощью DHCP-сервера в сети.

Если создается DAG, который будет содержать серверы почтовых ящиков, работающие Windows Server 2012 R2, у вас также есть возможность создания DAG без точки административного доступа кластера. В этом случае у кластера не будет объекта имени кластера (CNO) в Active Directory, а группа основных ресурсов кластера будет без ресурса сетевого имени или ресурса IP-адреса.

Дополнительные сведения о создании группы обеспечения доступности баз данных см. в разделе Создание группы обеспечения доступности баз данных.

При создании группы обеспечения доступности баз данных в службах Active Directory создается пустой объект, представляющий группу доступности с указанным именем, и класс объекта msExchMDBAvailabilityGroup.

В Windows Server 2008 R2 используются подмножество технологий кластерного кластерного кластера Windows, таких как кластерное сердцебиение, кластерные сети и база данных кластеров (для хранения данных, которые изменяются или могут быстро изменяться, например изменения состояния баз данных с активного на пассивный или обратный, а также с установки на демонтаж или обратное). Таким образом, можно создавать на Exchange серверах почтовых ящиков, установленных на поддерживаемых версиях Windows, включающих кластеризация Windows сбоем.

Отказоустойчивый кластер, создаваемый и используемый группой DAG, должен быть выделен для этой группы. Кластер не может использоваться для другого решения для обеспечения высокого уровня доступности или в каких-либо других целях. Например, невозможно использовать отказоустойчивый кластер для кластеризации других приложений и служб. Использование базового отказоустойчивого кластера группы обеспечения доступности баз данных в других целях, кроме группы DAG, не поддерживается.

Следящий сервер и следящий каталог группы обеспечения доступности баз данных

При создании группы обеспечения доступности базы данных необходимо указать ее имя (не более 15 символов), которое является уникальным в пределах леса Active Directory. Кроме того, настраивается каждая группа доступности с помощью следящего сервера и следящего каталога. Следящий сервер и каталог на нем используются только в том случае, если в группе DAG четное число членов, и только в целях формирования кворума. Нет необходимости заранее создавать следящий каталог. Он будет автоматически создан и защищен системой Exchange на следящем сервере. Каталог свидетелей не должен использоваться для каких-либо целей, кроме сервера свидетелей DAG.

В топологии зеркального зеркального зеркала в базе данных может быть вызван третий сервер. Сервер свидетеля позволяет автоматически отключиться от основного к зеркальным серверам или наоборот. В отличие от основных и зеркальных серверов, сервер свидетелей не служит базе данных. Роль свидетеля заключается в проверке того, работает ли данный сервер партнеров и работает ли он. Поддержка автоматического сбойного копирования является единственной функцией для сервера-свидетеля, и она определяет, какой сервер содержит основной экземпляр, а какой сервер содержит зеркальную копию базы данных.

Для следящего сервера существуют следующие требования:

Следящий сервер не должен быть членом группы DAG.

Следящий сервер должен располагаться в том же лесу Active Directory, что и группа DAG.

Сервер свидетелей должен быть запущен Windows Server 2008 или более поздней.

Один сервер может быть следящим сервером для нескольких групп DAG. Однако для каждой группы DAG требуется собственный следящий каталог.

Независимо от того, какой сервер используется в качестве следящего, если на нем включен брандмауэр Windows, необходимо включить исключение брандмауэра Windows для общего доступа к файлам и принтерам. Сервер свидетелей использует порт SMB 445.

Если сервер свидетеля, который вы указываете, не является сервером Exchange 2010 или более позднего года, необходимо добавить группу универсальной безопасности Exchange доверенных подсистем (USG) в локализованную группу администраторов на сервере свидетелей до создания DAG. Эти разрешения безопасности необходимы для создания каталога и файлового ресурса на следящем сервере в приложении Exchange.

Ни следящий сервер, ни каталог не должны быть отказоустойчивыми или использовать какую-либо форму избыточности или высокой доступности. Не требуется использовать кластеризованный файловый сервер или какую-либо другую форму устойчивости для следящего сервера. На это есть несколько причин. Чтобы возникла необходимость в следящем сервере при работе с большими группами обеспечения доступности баз данных (например, с шестью и более членами), должно произойти несколько сбоев. Так как группа DAG из шести членов может выдержать сбои двух серверов без потери кворума, то, чтобы для сохранения кворума потребовался следящий сервер, сбои должны произойти у трех членов группы. Кроме того, при наличии сбоя, который влияет на текущий следящий сервер (например, следящий сервер потерян из-за сбоя оборудования), для настройки нового следящего сервера и следящего каталога (при наличии кворума) используйте командлет Set-DatabaseAvailabilityGroup.

Если следящий сервер утратил свое хранилище или кто-либо изменил следящий каталог или разрешения для общего ресурса, для настройки следящего сервера и следящего каталога в исходном расположении можно использовать командлет Set-DatabaseAvailabilityGroup.

Варианты размещения следящего сервера

Размещение следящего сервера группы обеспечения доступности баз данных зависит от требований компании и вариантов, доступных в организации. Exchange теперь включает поддержку новых параметров конфигурации DAG, которые в 2010 г. не рекомендуется или не Exchange. Такие параметры включают использование третьего расположения, например третьего центра обработки данных, филиала или виртуальной сети Microsoft Azure.

В следующей таблице приведены общие рекомендации по размещению следящего сервера в различных сценариях развертывания.

После развертывания DAG в двух центрах обработки данных можно использовать третье расположение для размещения сервера свидетелей. Если ваша организация имеет третье расположение с сетевой инфраструктурой, изолированной от сбоев в сети, влияющих на два центра обработки данных, в которых развернут ваш DAG, можно развернуть сервер свидетелей DAG в этом третьем расположении, тем самым настроив DAG с возможностью автоматического отказа баз данных в другой центр обработки данных в ответ на событие сбоя на уровне данных. Если в вашей организации два физических местоположения, вы можете использовать виртуальную сеть Microsoft Azure как третье расположение для размещения следящего сервера.

Определение следящего сервера и следящего каталога во время создания группы обеспечения доступности баз данных

При создании группы обеспечения доступности базы данных необходимо указать ее имя. Дополнительно можно указать следящий сервер и следящий каталог.

При создании группы DAG доступны следующие сочетания параметров и реакций на события:

Можно указать только имя для DAG и оставить поля каталога witness и witness пустыми. В этом сценарии мастер выполняет поиск локального сайта Active Directory для сервера клиентского доступа, на который не установлен сервер почтовых ящиков, и автоматически создает каталог по умолчанию (%SystemDrive%:\DAGFileShareWitnesses \ сервера-свидетеля. Например, рассмотрим сервер свидетелей CAS3, на котором установлена операционная система на диск C. DAG с именем DAG1 в домене contoso.com будет использовать каталог свидетелей по умолчанию C:\DAGFileShareWitnesses\DAG1.contoso.com, который будет делиться как \ CAS3\DAG1.contoso.com.

Пользователь может указать имя для группы обеспечения доступности баз данных, для используемого следящего сервера, а также для каталога, созданного и открытого для совместного доступа на следящем сервере.

Пользователь может указать имя для группы обеспечения доступности баз данных и используемого следящего сервера и оставить поле Следящий каталог пустым. В этом сценарии на указанном следящем сервере мастер создаст каталог по умолчанию.

Можно указать имя группы обеспечения доступности баз данных, не заполнять поле Следящий сервер и указать каталог, который требуется создать и открыть для совместного доступа на следящем сервере. В этом сценарии мастер выполнит поиск сервера клиентского доступа, на котором не установлена роль сервера почтовых ящиков, автоматически создаст на сервере указанную группу обеспечения доступности баз данных, включит общий доступ для каталога и будет использовать сервер клиентского доступа в качестве следящего сервера.

После формирования группы обеспечения доступности баз данных в ней первоначально используется модель кворума «Большинство узлов». После добавления второго сервера почтовых ящиков в группу обеспечения доступности баз данных кворум автоматически меняется на модель кворума «Большинство сайтов и общих файловых ресурсов». После этих изменений кластер группы обеспечения доступности баз данных будет использовать следящий сервер для сохранения кворума. Если следящего каталога не существует, сервер Exchange автоматически создаст его, включит для него общий доступ и предоставит для общего ресурса разрешения на полный доступ для учетной записи компьютера сетевого объекта кластера (CNO) в группе доступности баз данных.

Использование общей папки, которая является частью пространства имен распределенной файловой системы, не поддерживается.

Если брандмауэр Windows включен на следящем сервере до создания группы обеспечения доступности баз данных, он может блокировать ее создание. Сервер Exchange использует инструментарий управления Windows (WMI) для создания каталога и общего файлового ресурса на следящем сервере. Если брандмауэр Windows включен на следящем сервере и для инструментария управления Windows не настроены исключения брандмауэра, произойдет сбой командлета New-DatabaseAvailabilityGroup. Если указан следящий сервер, а не следящий каталог, отобразится следующее сообщение об ошибке:

Если указаны следящий сервер и следящий каталог, отобразится следующее предупреждение:

Unable to access file shares on witness server ‘ ‘. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: The network path was not found.

Если брандмауэр Windows включен на следящем сервере после создания группы обеспечения доступности баз данных, но перед добавлением серверов, он может блокировать добавление или удаление членов группы обеспечения доступности баз данных. Если брандмауэр Windows включен на следящем сервере и для инструментария управления Windows не настроены исключения брандмауэра, командлет Add-DatabaseAvailabilityGroupServer вернет следующее предупреждение:

Failed to create file share witness directory ‘C:\DAGFileShareWitnesses\DAG_FQDN’ on witness server ‘ ‘. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: WMI exception occurred on server ‘ ‘: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

Чтобы устранить предыдущие сообщения об ошибках и предупреждения, выполните одно из следующих действий.

Вручную создайте следящий каталог и общий ресурс на следящем сервере и назначьте для них разрешения на полный доступ для объекта CNO в группе DAG.

Включите исключение WMI в брандмауэре Windows.

Отключите брандмауэр Windows.

Членство в группы обеспечения доступности базы данных

После создания DAG можно добавлять серверы в DAG или удалять их с помощью мастера группы доступности баз данных в центре администрирования Exchange (EAC) или с помощью команды Add-DatabaseAvailabilityGroupServer или Remove-DatabaseAvailabilityGroupServer в Exchange Management Shell. Подробные действия по управлению членством в DAG см. в описании Управление членством группы доступности баз данных.

Каждый сервер почтовых ящиков, являющийся членом такой группы DAG, также является узлом базового кластера, используемого группой. Таким образом, сервер почтовых ящиков одновременно может быть членом только одной группы обеспечения доступности баз данных.

Если на сервере почтовых ящиков, добавляемом в группу обеспечения доступности баз данных, не установлен компонент отказоустойчивой кластеризации, то с помощью метода, используемого для добавления сервера (например, командлета Add-DatabaseAvailabilityGroupServer или мастера управления группами обеспечения доступности баз данных), будет установлено средство отказоустойчивой кластеризации.

При добавлении первого сервера почтовых ящиков в группу DAG происходит следующее:

Устанавливается компонент отказоустойчивости кластера Windows, если он еще не установлен.

Создается отказоустойчивый кластер с помощью имени группы DAG. Отказоустойчивый кластер используется только группой DAG и должен быть выделен для этой группы. Использование кластера в других целях не поддерживается.

Создается объект CNO в контейнере компьютеров по умолчанию.

Регистрируется имя и IP-адрес группы обеспечения доступности баз данных в качестве записи узла (A) в службе DNS.

Добавляется сервер к объекту DAG в Active Directory.

Обновляется база данных кластера информацией о базах данных, установленных на добавленный сервер.

В крупных средах или средах с несколькими сайтами, особенно в которых группа DAG расширена на несколько сайтов Active Directory, необходимо дождаться завершения репликации Active Directory объекта DAG, содержащего первый член группы DAG. Если этот объект Active Directory не реплицирован во всей среде, при добавлении второго сервера может быть создан новый кластер (и новый объект CNO) для группы DAG. Это происходит потому, что объект DAG является пустым с точки зрения второго добавляемого сервера, в результате чего командлет Add-DatabaseAvailabilityGroupServer создает новый кластер и объект CNO для группы DAG, даже если эти объекты уже существуют. Чтобы убедиться, что объект DAG, содержащий первый сервер DAG, реплицирован, используйте командлет Get-DatabaseAvailabilityGroup на втором добавляемом сервере, чтобы проверить, что первый добавленный сервер включен в список членов группы обеспечения доступности баз данных.

После добавления второго и последующих серверов к группе DAG происходит следующее.

Сервер присоединяется к отказоустойчивому кластеру Windows для группы DAG.

Автоматически настраивается модель кворума:

Используется модель кворума «Большинство узлов» для групп DAG с нечетным количеством участников.

Используется модель кворума «Большинство узлов и общих файловых ресурсов» для групп DAG с четным количеством участников.

При необходимости Exchange автоматически создает следящий каталог и общий ресурс.

Добавляется сервер к объекту DAG в Active Directory.

Обновляется база данных кластера информацией об установленных базах данных.

Автоматически меняется модель кворума. Однако если модель кворума не меняется автоматически на правильную модель, можно запустить командлет Set-DatabaseAvailabilityGroup только с параметром Identity, чтобы исправить параметры кворума для группы обеспечения доступности базы данных.

Регистрация объекта имени кластера для группы DAG

Объект имени кластера — это учетная запись компьютера, создаваемая в службе Active Directory и связываемая с ресурсом имени кластера. Ресурс имени кластера связан с объектом имени кластера, который является объектом с включенной поддержкой Kerberos, действующим как идентификатор кластера и обеспечивающим контекст безопасности кластера. Формирование базового кластера группы обеспечения доступности баз данных и объекта CNO для этого кластера выполняется при добавлении первого члена в группу DAG. После добавления первого сервера в группу DAG удаленная среда Powershell подключается к службе репликации Microsoft Exchange на добавляемом сервере почтовых ящиков. Служба репликации Microsoft Exchange устанавливает средство отказоустойчивой кластеризации (если оно не установлено) и запускает процесс создания кластера. Служба репликации Microsoft Exchange работает в контексте безопасности LOCAL SYSTEM, и создание кластера выполняется в этом контексте.

Если члены группы обеспечения доступности баз данных используют Windows Server 2012, необходимо подготовить объект CNO до добавления первого сервера в группу DAG. Если члены группы обеспечения доступности баз данных используют Windows Server 2012 R2, и она создана без точки административного доступа кластера, объект CNO не создается, и создавать объект CNO для группы обеспечения доступности баз данных не требуется.

В средах, в которых создание учетной записи компьютера ограничено или учетные записи компьютеров создаются в контейнере, отличном от контейнера компьютеров по умолчанию, необходимо зарегистрировать и подготовить объект CNO. Пользователь создает и отключает учетную запись компьютера для объекта CNO, а затем выполняет одно из следующих действий.

Назначить разрешения на полный доступ к учетной записи компьютера для учетной записи компьютера, являющегося первым сервером почтовых ящиков, добавляемым в группу обеспечения доступности баз данных.

Назначить универсальной группе безопасности доверенной подсистемы Exchange разрешения на полный доступ к учетной записи компьютера.

Назначение разрешений на полный доступ к учетной записи компьютера для учетной записи компьютера первого сервера почтовых ящиков, добавленного в группу DAG, позволяет контексту безопасности LOCAL SYSTEM управлять зарегистрированной учетной записью компьютера. Вместо этого можно назначить разрешения на полный доступ к учетной записи компьютера универсальной группе безопасности доверенной подсистемы Exchange, так как эта группа доверенной подсистемы Exchange включает в себя учетные записи компьютеров всех серверов Exchange в домене.

Дополнительные сведения о регистрации и подготовке объекта CNO для группы обеспечения доступности баз данных см. в разделе Регистрация объекта имени кластера для группы обеспечения доступности баз данных.

Удаление серверов из DAG

Серверы почтовых ящиков можно удалить из DAG с помощью мастера управления группой доступности баз данных в EAC или команды remove-DatabaseAvailabilityGroupServer в оболочке управления Exchange. Необходимо удалить все реплицированные базы данных почтовых ящиков с сервера почтовых ящиков, прежде чем удалить сам сервер из группы DAG. При попытке удалить сервер почтовых ящиков с реплицированными базами данных почтовых ящиков из группы DAG произойдет сбой.

Существует несколько сценариев, в которых перед выполнением определенных операций необходимо удалить сервер почтовых ящиков из группы обеспечения доступности баз данных. Это происходит в описанных ниже случаях.

Выполнение операции восстановления сервера. Если сервер почтовых ящиков, который является членом DAG, потерян или иным образом не удается найти и нуждается в замене, можно выполнить операцию восстановления сервера с помощью переключателя Setup /m:RecoverServer. Однако прежде чем выполнить операцию восстановления, необходимо сначала удалить сервер из DAG с помощью комлета Remove-DatabaseAvailabilityGroupServer с параметром ConfigurationOnly.

Удаление группы доступности базы данных. Могут возникнуть ситуации, в которых необходимо удалить DAG (например, при отключении режима репликации сторонних пользователей). Перед удалением группы DAG необходимо сначала удалить из нее все серверы. Попытка удаления группы DAG, содержащей члены, завершится неудачей.

Настройка свойств DAG

После того как серверы были добавлены в DAG, вы можете использовать EAC или Exchange Management Shell для настройки свойств DAG, включая сервер свидетелей и каталог свидетелей, используемый DAG, и IP-адреса, присвоенные DAG.

Настраиваемые свойства включают в себя следующее:

Сервер свидетеля. Имя сервера, на который необходимо уделить файлу для свидетеля обмена файлами. Мы рекомендуем указать сервер клиентского доступа в качестве следящего сервера. Это позволяет системе автоматически формировать, защищать и использовать общий ресурс по мере необходимости, а также позволяет администратору контролировать доступность следящего сервера.

Каталог свидетелей. Имя каталога, который будет использоваться для хранения данных свидетеля обмена файлами. Этот каталог будет автоматически создан системой на указанном следящем сервере.

IP-адреса группы доступности баз данных: один или несколько IP-адресов должны быть назначены DAG, если члены DAG не работают Windows Server 2012 R2 и вы создаете DAG без IP-адреса. В противном случае IP-адреса DAG можно настроить с помощью вручную задаваемых статических IP-адресов, или их можно автоматически привязыть к DAG с помощью сервера DHCP в организации.

Оболочка управления Exchange позволяет настраивать недоступные в EAC свойства DAG, такие как IP-адреса DAG, параметры шифрования сети и сжатия, обнаружение сети, порт TCP, используемый для репликации, а также альтернативные параметры сервера свидетелей и каталогов свидетелей, а также включить режим координации активации datacenter.

Дополнительные сведения о настройке свойств группы DAG см. в разделе Настройка свойств группы обеспечения доступности баз данных.

Шифрование в сети группы обеспечения доступности баз данных

Группы DAG поддерживают использование шифрования путем применения возможностей шифрования ОС Windows Server. Группы DAG используют проверку подлинности Kerberos между серверами Exchange. API DecryptMessage и EncryptMessage поставщика поддержки безопасности (SSP) Microsoft Kerberos отвечают за шифрование сетевого трафика группы DAG. Поставщик поддержки безопасности Microsoft Kerberos поддерживает несколько алгоритмов шифрования. (Полный список см. в подразделе 3.1.5.2 «Типы шифрования» раздела Расширения протокола Kerberos). При подтверждении проверки подлинности Kerberos выбирается самый надежный поддерживаемый протокол шифрования из указанных в списке: обычно стандарт AES с 256-разрядным ключом, возможно, вместе с кодом проверки подлинности сообщения на основе хэша (HMAC) по алгоритму SHA для сохранения целостности данных. Дополнительные сведения см. в разделе HMAC.

Шифрование в сети является свойством группы DAG, а не сети DAG. Можно настроить сетевое шифрование DAG с помощью команды Set-DatabaseAvailabilityGroup в Exchange управленческой оболочки. Возможные параметры для установления связи в сети DAG показаны в следующей таблице.

Сжатие в сети DAG

В группах DAG поддерживается встроенное сжатие. Если сжатие включено, при установлении связи в сети DAG используется сжатие XPRESS, которое является реализацией Microsoft для алгоритма LZ77. Это тот же тип сжатия, используемый во многих протоколах Майкрософт, в частности, сжатие RPC MAPI между microsoft Outlook и Exchange.

Как и шифрование в сети, сжатие в сети является свойством группы DAG, а не сети DAG. Настраивается сжатие сети DAG с помощью команды Set-DatabaseAvailabilityGroup в Exchange управленческой оболочки. Возможные параметры сжатия для установления связи в сети DAG показаны в следующей таблице.

Сети групп обеспечения доступности баз данных

Сеть DAG — это коллекция из одной или нескольких подсетей, используемых либо для трафика репликации, либо для трафика MAPI. Каждая группа DAG содержит не более одной сети MAPI и 0 или более сетей репликации. В конфигурации сетевого адаптера сеть используется как для трафика MAPI, так и для репликации. Хотя поддерживается один сетевой адаптер и путь, мы рекомендуем каждому DAG иметь как минимум две сети DAG. В конфигурации с двумя сетями одна сеть обычно предназначена для трафика репликации, а другая сеть используется в основном для трафика MAPI. Кроме того, вы можете добавить сетевые адаптеры для каждого члена группы DAG и настроить дополнительные сети DAG как сети репликации.

При использовании нескольких сетей репликации невозможно указать приоритет использования сети. Exchange случайным образом выбирает сеть репликации из группы сетей репликации для доставки журналов.

В Exchange 2010 во многих сценариях необходима ручная настройка сетей DAG. По умолчанию в более поздних версиях Exchange сети DAG автоматически настраиваются системой. Перед созданием или изменением сетей DAG необходимо сначала включить ручное управление сетью DAG, выполнив следующую команду:

После включения конфигурации сети DAG вручную можно использовать командлет New-DatabaseAvailabilityGroupNetwork в командной Exchange для создания сети DAG. Подробные действия по созданию сети DAG см. в обзоре Create a database availability group network.

Командлет Set-DatabaseAvailabilityGroupNetwork можно использовать в командлете Exchange управления для настройки свойств сети DAG. Подробные действия по настройке свойств сети DAG см. в инструкции Configure database availability group network properties. В каждой сети DAG есть необходимые и дополнительные параметры для настройки:

Имя сети: уникальное имя для сети DAG с количеством символов до 128 символов.

Описание сети. Необязательный описание для сети DAG с количеством символов до 256 символов.

Сетевые подсети: одна или несколько подсетей, вступив в формат подсетей IPAddress/Bitmask (например, 192.168.1.0/24 для подсетей internet Protocol версии 4 (IPv4); 2001:DB8:0:000. /64 для подсетей internet Protocol версии 6 (IPv6).

Включить репликацию. В EAC выберите контрольный ящик, чтобы посвятить сеть DAG репликации трафика и заблокировать трафик MAPI. Снимите флажок, чтобы запретить использование сети группы DAG для репликации и включить трафик MAPI. В командлете Exchange Management Shell используйте параметр ReplicationEnabled в командлете Set-DatabaseAvailabilityGroupNetwork, чтобы включить репликацию и отключить ее.

Отключение репликации для сети MAPI не гарантирует того, что система не будет использовать эту сеть для репликации. Когда все настроенные сети репликации находятся в автономном режиме, неисправны или недоступны и сохраняется только сеть MAPI, для которой отключена репликация, система будет использовать эту сеть для репликации.

Начальные сети DAG (например, MapiDagNetwork и ReplicationDagNetwork01), создаваемые системой, основаны на подсетях службы кластеров. Каждый член группы DAG должен иметь идентичное количество сетевых адаптеров, а каждый сетевой адаптер должен иметь адрес IPv4 (а также, возможно, и адрес IPv6) в уникальной подсети. Несколько членов группы DAG могут иметь адреса IPv4 в одной подсети, но IP-адрес каждого сетевого адаптера определенного сервера группы DAG должен принадлежать уникальной подсети. Кроме того, шлюз по умолчанию должен использоваться только адаптером сети MAPI. Сети репликации не должны настраиваться на использование шлюза по умолчанию.

Например, рассмотрим группу DAG1 с двумя членами, каждый из которых имеет по два сетевых адаптера (один выделен для сети MAPI, а другой — для сети репликации). Примерные параметры конфигурации IP-адреса представлены в следующей таблице.

Пример настройки параметров сетевого адаптера

В следующей конфигурации группа DAG содержит две настроенные подсети: 192.168.1.0 и 10.0.0.0. При добавлении серверов EX1 и EX2 в группу DAG обе подсети будут пронумерованы и будет создано две сети DAG: MapiDagNetwork (192.168.1.0) и ReplicationDagNetwork01 (10.0.0.0). Эти сети будут настроены, как показано в следующей таблице.

Параметры нумерованных сетей DAG для группы DAG с одной подсетью

Чтобы завершить настройку Replicationdagnetwork01 в качестве выделенной сети репликации, отключите репликацию для MapiDagNetwork, выполнив следующую команду.

После отключения репликации для MapiDagNetwork служба репликации Microsoft Exchange использует ReplicationDagNetwork01 для непрерывной репликации. Если произойдет сбой ReplicationDagNetwork01, то служба репликации Microsoft Exchange вернется к использованию MapiDagNetwork для непрерывной репликации. Это преднамеренное действие системы для обеспечения высокого уровня доступности.

Развертывание нескольких подсетей и сетей группы обеспечения доступности баз данных

В предыдущем примере несмотря на использование в группе DAG двух различных подсетей (192.168.1.0 и 10.0.0.0) эта группа считается группой DAG с одной подсетью, потому что все члены группы используют одну подсеть для формирования сети MAPI. Когда члены группы DAG используют различные подсети для сети MAPI, такая группа называется группой DAG с несколькими подсетями. В группах DAG с несколькими подсетями соответствующие подсети будут автоматически назначаться каждой сети DAG.

Например, рассмотрим группу DAG2 с двумя членами, каждый из которых имеет по два сетевых адаптера (один выделен для сети MAPI, а другой — для сети репликации) и расположен на отдельном сайте Active Directory, а их сети MAPI находятся в различных подсетях. Примерные параметры конфигурации IP-адреса представлены в следующей таблице.

Примерные параметры сетевых адаптеров для группы DAG с несколькими подсетями

В следующей конфигурации группа DAG содержит четыре настроенные подсети: 192.168.0.0, 192.168.1.0, 10.0.0.0 и 10.0.1.0. При добавлении EX1 и EX2 в группу перечисляются четыре подсети, но созданы будут только две сети DAG. MapiDagNetwork (192.168.0.0, 192.168.1.0) и ReplicationDagNetwork01 (10.0.0.0, 10.0.1.0). Эти сети будут настроены, как показано в следующей таблице.

Параметры нумерованных сетей DAG для группы DAG с несколькими подсетями

Сети DAG и iSCSI

По умолчанию в группах DAG выполняется поиск всех сетей, обнаруженных и настроенных для использования с помощью базового кластера. При этом учитываются любые сети Internet SCSI (iSCSI), которые используются в результате применения хранилища iSCSI для одного или нескольких членов DAG. Рекомендуется использовать для хранилища iSCSI выделенные сети и сетевые адаптеры. Эти сети не должны управляться группами DAG и ее кластерами или использоваться в качестве сетей DAG (MAPI или репликация). Вместо этого для них необходимо вручную отключить использование группой DAG и выделить их для трафика хранилища iSCSI. Для отключения обнаружения и использования сетей iSCSI в качестве сетей DAG, настройте DAG так, чтобы игнорировать любые обнаруженные сети iSCSI, с помощью командлета Set-DatabaseAvailabilityGroupNetwork, как показано в следующем примере:

Эта команда также отключит использование сети кластером. Хотя сети iSCSI по-прежнему будут отображаться как сети DAG, они не будут использоваться для трафика репликации или MAPI после выполнения предыдущей команды.

Настройка членов DAG

Серверы почтовых ящиков, являющиеся членами группы DAG, имеют несколько свойств, относящихся к обеспечению высокого уровня доступности, которые необходимо настроить, как описано в следующих разделах.

Автоматическое подключение базы данных

Параметр AutoDatabaseMountDial определяет поведение при автоматическом подключении базы данных после отработки отказа базой данных. С помощью командлета Set-MailboxServer можно настроить одно из следующих значений параметра AutoDatabaseMountDial.

GoodAvailability : Если указать это значение, база данных автоматически устанавливается сразу после сбой, если длина очереди копии меньше или равна шести. Длина очереди копирования — это число журналов, определяемых пассивной копией, для которых необходимо выполнить репликацию. Если значение длины очереди копирования превышает 6, база данных не будет подключаться автоматически. Если длина очереди копирования не превышает 6, Exchange попытается реплицировать оставшиеся журналы на пассивную копию и подключит базу данных.

Пример. Настройка автоматического подключения базы данных

Политика автоматической активации копии базы данных

Параметр DatabaseCopyAutoActivationPolicy указывает тип автоматической активации, доступной для копий базы данных почтовых ящиков на выбранных серверах почтовых ящиков. С помощью командлета Set-MailboxServer можно настроить одно из следующих значений параметра DatabaseCopyAutoActivationPolicy.

Пример. Настройка политики автоматической активации копии базы данных

Максимальное количество активных баз данных

Параметр MaximumActiveDatabases (также используемый с командлетом Set-MailboxServer) указывает количество баз данных, которые можно подключить к серверу почтовых ящиков. Для соблюдения требований развертывания серверы почтовых ящиков можно настроить таким образом, чтобы не превышалась нагрузка на отдельные серверы почтовых ящиков.

В качестве значения параметра MaximumActiveDatabases задается целое число. Когда будет достигнуто максимальное количество баз данных, копии баз данных на сервере не будут активироваться при отработке отказа. Если копии уже активированы на сервере, сервер не позволит выполнить подключение баз данных.

Пример. Настройка максимального количества активных баз данных

В следующем примере показана настройка сервера почтовых ящиков для поддержки не более 20 активных баз данных.

Обслуживание участников DAG

Прежде чем выполнять какое-либо обслуживание программного или аппаратного обеспечения для члена группы DAG, необходимо сначала перевести этого сервера в режим обслуживания. Следующие сценарии предоставляются с помощью Exchange Server для оказания помощи в процедурах обслуживания DAG.

StartDagServerMaintenance.ps1: помогает с перемещением всех активных баз данных с сервера. Он также перемещает все критически важные функции поддержки DAG, например роль Primary Active Manager (PAM) и блокирует их перемещение на сервер до завершения обслуживания.

StopDagServerMaintenance.ps1: помогает выведя участника DAG из режима обслуживания и сделав его активной мишенью для всех баз данных и всех критически важных функций поддержки DAG.

Оба вышеперечисленного сценария принимают параметр ServerName (который может быть либо имя хозяина, либо полное доменное имя (FQDN) участника DAG, так и параметр WhatIf. Оба сценария можно выполнять локально или удаленно. На сервере, на котором выполняются сценарии, должны быть установлены средства управления отказоустойчивым кластером Windows (RSAT-Clustering).

Сценарий RedistributeActiveDatabases.ps1 также avaialble, который помогает смонтировать базы данных почтовых ящиков на определенных членах DAG как inidicated номером предпочтения активации на каждой базе данных. Однако в Exchange 2016 cu2 или более поздней, новое свойство DAG с именем PreferenceMoveFrequency автоматически балансирует копии баз данных через DAG. Поэтому вам потребуется использоватьRedistributeActiveDatabases.ps1, если вы отключили эту функциональность или хотите вручную сбалансировать копии баз данных.

Сценарий StartDagServerMaintenance.ps1 выполняет следующие задачи:

Задает значение параметра DatabaseCopyAutoActivationPolicy для участника DAG, что предотвращает активацию копий баз данных Blocked на сервере.

Приостанавливает работу узла в кластере, что не позволяет этому узлу быть (или становиться) основным диспетчером Active Manager (PAM).

Перемещает все активные базы данных, размещенные на сервере-члене группы DAG, на другие серверы-члены группы DAG.

Если в данный момент член группы DAG владеет кластерной группой по умолчанию, сценарий переместит ее (и роль PAM) на другой сервер-член группы DAG.

Если при выполнении какой-либо задачи произойдет сбой, сценарий отменит все операции, кроме успешного перемещения баз данных.

Чтобы начать обслуживание члена группы DAG, включая очистку очереди транспорта и приостановку подключения клиентов, сделайте следующее:

Чтобы очистить транспортные очереди, запустите следующую команду:

Чтобы инициировать осушение транспортных очередей, запустите следующую команду:

Чтобы начать процесс слива всех вызовов единой системы обмена сообщениями (только Exchange 2016 г.), запустите следующую команду:

Чтобы получить доступ к сценариям обслуживания DAG, запустите следующую команду:

Чтобы запустить StartDagServerMaintenance.ps1, запустите следующую команду:

Для значения параметра MoveComment можно сделать любую нотацию, которая вам нужна. В предыдущем примере используется «Обслуживание».

Выполнение этого сценария может занять некоторое время, в течение которого на экране не будут отображаться никакие действия.

Чтобы перенаправить сообщения до доставки в локальных очередях на Exchange сервер, указанный параметром Target, запустите

Чтобы разместить сервер в режиме обслуживания, запустите:

Чтобы убедиться в готовности сервера к обслуживанию, выполните следующие задачи.

Чтобы убедиться, что сервер помещен в режим обслуживания, убедитесь, что только при запуске следующей команды они находятся в состоянии Monitoring RecoveryActionsEnabled Active:

Чтобы убедиться, что на сервере не размещены активные копии баз данных, запустите:

Чтобы убедиться, что узел кластера приостановлен, запустите:

Чтобы убедиться, что все транспортные очереди опустели, запустите:

Когда обслуживание члена группы DAG завершено и он подготовлен к возобновлению работы, его нужно перевести из режима обслуживания в рабочий режим с помощью сценария StopDagServerMaintenance.ps1. Сценарий StopDagServerMaintenance.ps1 выполняет следующие задачи:

Возобновляет работу узла в кластере, а также восстанавливает полную функциональность кластера для члена группы DAG.

Задает значение параметра DatabaseCopyAutoActivationPolicy для участника Unrestricted DAG.

Запускает командлет Resume-MailboxDatabaseCopy для каждой копии базы данных, размещенной на сервере-члене группы DAG.

Когда вы будете готовы восстановить состояние участника DAG до полного производственного состояния, включая восстановление транспортных очередей и подключение клиентов, выполните следующие задачи:

Чтобы настроить сервер как вне режима обслуживания и быть готовым к приему клиентских подключений, запустите:

Чтобы разрешить серверу принимать вызовы единой системы обмена сообщениями (только Exchange 2016 г.), запустите:

Чтобы получить доступ к сценариям обслуживания DAG, запустите следующую команду:

Чтобы выполнить сценарий StopDagServerMaintenance.ps1, выполните:

Чтобы транспортные очереди могли возобновить прием и обработку сообщений, запустите:

Чтобы возобновить транспортную деятельность, запустите:

Чтобы убедиться, что сервер готов к использованию в производственной среде, выполните следующие действия.

Чтобы проверить, не работает ли сервер в режиме обслуживания, выполните команду

Если вы устанавливаете обновление Exchange и процесс обновления не удается, он может оставить некоторые компоненты сервера в неактивном состоянии, которое будет отображаться в выходе вышеуказанного Get-ServerComponentState cmdlet. Чтобы решить эту проблему, запустите следующие команды:

Завершение работы участников группы обеспечения доступности базы данных

Exchange решение с высокой доступностью интегрировано с процессом Windows остановки. Если администратор или приложение инициирует завершение работы сервера Windows в группе DAG, к которому подключена база данных, реплицированная на один или несколько серверов группы DAG, система попытается активировать другую копию подключенной базы данных до того, как разрешить завершение работы.

Однако это новое поведение не гарантирует, что все базы данных на закрываемом сервере будут lossless активироваться. Поэтому перед завершением работы сервера, который является участником группы DAG, лучше выполнить его переключение.

Установка обновлений на членах группы DAG

Установка Exchange обновлений на сервере, который является членом DAG, является относительно простым процессом. При установке накопительного пакета обновления на сервере, который является членом группы DAG, выполняется остановка нескольких служб, в том числе всех служб Exchange и службы кластеров. Общий процесс применения обновлений для участника группы DAG выглядит следующим образом.

С помощью шагов, указанных выше, переведите члена группы DAG в режим обслуживания.

С помощью шагов, указанных выше, выведите члена группы DAG из режима обслуживания и верните его в рабочий режим.

Как вариант, можно с помощью сценария RedistributeActiveDatabases.ps1 выполнить балансировку активных копий баз данных в группе DAG.

Дополнительные сведения о последних обновлениях Exchange см. в Exchange Server числа сборки и даты выпуска.

Источник