none
Как осуществить перенос Primary Active Manager в Dag Для обновления второго сервера Exchange2013 RRS feed

  • Вопрос

  • В организации есть два сервера Exchange2013 находящиеся в Dag

    Задача обновить с CU3 До CU 10. Делал все по инструкции перевел второй сервер в режим обслуживания и обновил до CU10

    Теперь необходимо сделать то же самое с первым сервером. В настоящий момент этот сервер имеет роль Primary Active Manager. Перед обновлением необходимо перевести PAM На второй сервер и вынести с первого все базы. 

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

    Команда 
    Move-ClusterGroup -Name "Cluster Group" -Node exchange2

    Выдает ошибку о неверном синтаксисе. Подскажите как передать роль PAM на второй сервер. Рисковать не хочется, а до нового года сделать надо. 


    25 декабря 2015 г. 6:10

Ответы

  • В итоге перенес все активные базы на второй Exchange и перезапустил первый. PAM переехал, базы активировались, все работает. Но конечно это не лучший способ переноса на мой взгляд :)

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

    Move-ClusterGroup –Cluster имя_DAG –Name “Cluster Group” –Node: имя_ноды_куда_переместить

    25 декабря 2015 г. 7:30

Все ответы

  • Здравствуйте!

    По какой инструкции? Как нам узнать?

    Вы вернули второй сервер обратно, все проверили?

    Вам наверно данный командлет нужен:

    Suspend-ClusterNode <ServerName>

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

    Перед выполнением любого вида обслуживания программного или аппаратного обеспечения для члена группы DAG необходимо сначала перевести этого члена DAG в режим обслуживания. Это подразумевает перемещение всех активных баз данных с сервера и запрет на перемещение активных баз данных на сервер. Сценарий также обеспечивает перемещение всех важных средств поддержки группы DAG, находящихся на сервере (например, роль основного диспетчера Active Manager (PAM)), на другой сервер и блокирует их перемещение назад. В частности, не выполнять следующие задачи:

        • Чтобы начать процесс опустошения транспортных очередей, выполните Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance

        • Чтобы начать процесс опустошения транспортных очередей, выполните команду Restart-Service MSExchangeTransport

        • Чтобы начать процесс очистки всех вызовов единой системы обмена сообщениями, выполните Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance

        • Чтобы перенаправить сообщения, ожидающие доставки в локальных очередях, на сервер почтовых ящиков, указанный в параметре "Цель", выполните Redirect-Message -Server <ServerName> -Target <MailboxServerFQDN>

        • Чтобы приостановить узел кластера, не позволяющий узлу являться или стать PAM, выполните Suspend-ClusterNode <ServerName>

        • Чтобы переместить все активные базы данных, размещенные на сервере группы DAG, на другие серверы группы DAG, выполните Set-MailboxServer <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $True

        • Чтобы предотвратить размещение на сервере копий активной базы данных, выполните Set-MailboxServer <ServerName> -DatabaseCopyAutoActivationPolicy Blocked

        • Чтобы перевести сервер в режим обслуживания, выполните Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance

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

        • Чтобы убедиться, что сервер переведен в режим обслуживания, выполните Get-ServerComponentState <ServerName> | ft Component,State -Autosize

        • Чтобы убедиться, что на сервере нет копий активной базы данных, выполните Get-MailboxServer <ServerName> | ft DatabaseCopy* -Autosize

        • Чтобы убедиться, что узел приостановлен, выполните Get-ClusterNode <ServerName> | fl

        • Чтобы убедиться, что были опустошены все транспортные очереди, выполните Get-Queue

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

        • Чтобы обозначить выход сервера из режима обслуживания, выполните Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance

        • Чтобы разрешить прием сервером вызовов единой системы обмена сообщениями, выполните Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance

        • Чтобы возобновить работу узла в кластере и включить полную функциональность кластера для сервера, выполните Resume-ClusterNode <ServerName>

        • Чтобы разрешить базам данных стать активными на сервере, выполните Set-MailboxServer <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $False

        • Для снятия блокировки автоматической активации выполните Set-MailboxServer <ServerName> -DatabaseCopyAutoActivationPolicy Unrestricted

        • Чтобы включить транспортные очереди и разрешить серверу принимать и обрабатывать сообщения, выполните команду Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance

        • Чтобы возобновить действие транспорта, выполните команду Restart-Service MSExchangeTransport

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

        • Чтобы проверить, не работает ли сервер в режиме обслуживания, выполните команду Get-ServerComponentState <ServerName> | ft Component,State -Autosize

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

        • Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional

        • Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional

      • Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional


    25 декабря 2015 г. 6:22
  • Да, второй сервер вернули, он в даге перенос баз с одного сервера на другой в Dag проходит без проблем. При обновлении сервера переводили ноду два в паузу

    Suspend-ClusterNodeExchange2

    Этой после завершения обновления вывел из режима обслуживания обновляемого и перевел ноду в рабочий режим Resume-ClusterNode exchange1.

    Тогда такой вопрос, если выполнить команду Suspend-ClusterNode exchange1 с сервера Exchange1 Pam переедет без ошибок ?

    25 декабря 2015 г. 6:29
  • Да, второй сервер вернули, он в даге перенос баз с одного сервера на другой в Dag проходит без проблем. При обновлении сервера переводили ноду два в паузу

    Suspend-ClusterNodeExchange2

    Этой после завершения обновления вывел из режима обслуживания обновляемого и перевел ноду в рабочий режим Resume-ClusterNode exchange1.

    Тогда такой вопрос, если выполнить команду Suspend-ClusterNode exchange1 с сервера Exchange1 Pam переедет без ошибок ?

    -------------------------------------

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

    25 декабря 2015 г. 6:41
  • Если Ваш DAG работает в штатном режиме, то да, перейдет на другую ноду.


    25 декабря 2015 г. 6:43
  • В итоге перенес все активные базы на второй Exchange и перезапустил первый. PAM переехал, базы активировались, все работает. Но конечно это не лучший способ переноса на мой взгляд :)
    25 декабря 2015 г. 6:58
  • Я так понимаю инструкция была вот эта

    Проделайте все то же начиная с этапа 3, но для первого сервера.

    Suspend-ClusterNode там кстати фигурирует.
    25 декабря 2015 г. 6:58
  • Я сейчас одну неполиткорректную вещь скажу. На самом деле для обновления Экса вовсе не нужно проделывать указанные в инструкциях действия. Когда запускается инсталлятор, он автоматически останавливает все службы Exchange, что с точки зрения остальных серверов Экса выглядит как выключение сервера. Соответственно, срабатывают штатные механизмы, которые переносят все службы типа координаторов на альтернативные серверы, активируют там пассивную копию базы и т.п. После обновления и перезагрузки сервера службы на нем поднимаются, и все возвращается в штатное состояние.

    Предварительные ручные действия нужны для того, чтобы убедиться в работоспособности всех служб Экса на альтернативных серверах и их способности принять на себя нагрузку (и по возможности сразу эту нагрузку перенести). Иначе - в теории - возможна ситуация, когда в DAG из двух серверов один начал обновляться, а другой по какой-то причине не смог поднять базу, и вся ваша система легла до завершения работ на обновляемом сервере. Но если вы и без того видите, что партнер функционирует нормально, особо заморачиваться о "правильной" последовательности действий необходимости нет. Активировали пассивную копию базы, дождались, когда на всех серверах устаканятся очереди и индексы, и вперед.


    Evgeniy Lotosh // MCSE: Server infrastructure, MCSE: Messaging


    25 декабря 2015 г. 7:23
  • В итоге перенес все активные базы на второй Exchange и перезапустил первый. PAM переехал, базы активировались, все работает. Но конечно это не лучший способ переноса на мой взгляд :)

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

    Move-ClusterGroup –Cluster имя_DAG –Name “Cluster Group” –Node: имя_ноды_куда_переместить

    25 декабря 2015 г. 7:30