none
Строим active-active site resilience 2DAGs систему RRS feed

  • Вопрос

  • Коллеги, доброго дня! Есть теоретический вопрос  по построению системы active-active site resilience между двумя георгафически удалёнными датацентрами.

    В каждом датацентре (ДЦ) - своя популяция активных пользователей - каждая популяция соответствующего территориально Датацентру - офиса. Задача такая - обеспечить полную работоспособность в случае потери одного из датацентров - и нераскачивания кластера в случае пропадания связи между датацентрами.

    По условиям задачи - рассматриваю схему, предложенную тут http://technet.microsoft.com/en-us/library/dd979781.aspx#TwoFourTwo и состоящую из двух DAG - распределённых географически, но только я планирую вместо четырёх узлов в каждой DAG - использовать три - то есть схема выраждается в следующую

     

    по моим разуменьям, убирая пару четвёртых серверов - мы экономим на железе и хранилище, но вот сильно ли теряем в общей отказоустойчивости системы? Планирую три копии включая активную - то есть, при отказе одного из двух серверов одной из DAG в одном датацентре - наступает файловер, при отказе двух серверов одной группы в одном датацентре - ручной свитчовер в другой датацентер и принудительная активация копий баз на третьем сервере. При обрыве WAN между ДЦ - кворум сохраняется, ничего не дёргается никуда. При потере датацентра - принудительная активация третьего сервера в той группе, первичный датацентр которой был потерян. Вроде бы всё гладко, не нужен witness-сервер для обеспечения кворума, экономим ресурсы и деньги при, собственно, не сильной потере в качестве - плинируется, что сервера выбраны и расчитаны с запасом и тянут всё кол-во пользователей в случаях файловера и свитчовера соотв-но. Что я мог упустить из виду в такой схеме? Проксирование cas-cas при свитчовере будет рабоать? Вопрос планирования пространства имён также будет интересен, но наверно чуть позже, после одобрения Вами основной концепции :) Что скажете?




    • Изменено k0lin 12 сентября 2011 г. 14:01
    12 сентября 2011 г. 13:05

Ответы

  • witness нужен в любом случае. А переключение CAS будет ручками.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    • Помечено в качестве ответа Yuriy Lenchenkov 20 сентября 2011 г. 13:38
    12 сентября 2011 г. 14:15
    Модератор
  • Была внедрена схема ресурсного домена с рамещением в  3 цод. Точно такая же, как Вы хотите реализовать. Долго описывать все подводные камни. Внедрение и миграция 4000 пользователей около года.


    • Изменено Oleg.KovalenkoModerator 27 сентября 2011 г. 11:26
    • Помечено в качестве ответа k0lin 27 сентября 2011 г. 13:23
    27 сентября 2011 г. 11:20
    Модератор
  • witness нужен в любом случае. А переключение CAS будет ручками.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/

    безусловно, без witness никуда - хотя бы в случае вылета одного из двух в первичном ДЦ - для поддержания кворума.

    Переключение cas - в случае переключения между ДЦ?

    Вот пример Datacenter Switchovers.
    http://technet.microsoft.com/en-us/library/dd351049.aspx

    • Предложено в качестве ответа Oleg.KovalenkoModerator 27 сентября 2011 г. 11:37
    • Отменено предложение в качестве ответа k0lin 27 сентября 2011 г. 13:23
    • Помечено в качестве ответа k0lin 27 сентября 2011 г. 13:24
    27 сентября 2011 г. 11:23
    Модератор

Все ответы

  • witness нужен в любом случае. А переключение CAS будет ручками.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    • Помечено в качестве ответа Yuriy Lenchenkov 20 сентября 2011 г. 13:38
    12 сентября 2011 г. 14:15
    Модератор
  • witness нужен в любом случае. А переключение CAS будет ручками.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/

    безусловно, без witness никуда - хотя бы в случае вылета одного из двух в первичном ДЦ - для поддержания кворума.

    Переключение cas - в случае переключения между ДЦ?

    13 сентября 2011 г. 6:32
  • да, при переключении ДЦ
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    13 сентября 2011 г. 6:46
    Модератор
  • Больше никто ничего не добавит?

    27 сентября 2011 г. 8:50
  • Была внедрена схема ресурсного домена с рамещением в  3 цод. Точно такая же, как Вы хотите реализовать. Долго описывать все подводные камни. Внедрение и миграция 4000 пользователей около года.


    • Изменено Oleg.KovalenkoModerator 27 сентября 2011 г. 11:26
    • Помечено в качестве ответа k0lin 27 сентября 2011 г. 13:23
    27 сентября 2011 г. 11:20
    Модератор
  • witness нужен в любом случае. А переключение CAS будет ручками.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/

    безусловно, без witness никуда - хотя бы в случае вылета одного из двух в первичном ДЦ - для поддержания кворума.

    Переключение cas - в случае переключения между ДЦ?

    Вот пример Datacenter Switchovers.
    http://technet.microsoft.com/en-us/library/dd351049.aspx

    • Предложено в качестве ответа Oleg.KovalenkoModerator 27 сентября 2011 г. 11:37
    • Отменено предложение в качестве ответа k0lin 27 сентября 2011 г. 13:23
    • Помечено в качестве ответа k0lin 27 сентября 2011 г. 13:24
    27 сентября 2011 г. 11:23
    Модератор
  • На счет переключение ручками. Это если они буду в разных VLAN. Но если не экономить на сетевой инфраструктуре, то можно сделать DAG и CAS в одних VLAN. Это очень дорого, зато 24X7. А Witness надо ставить в каждом Цоде, но больше 2 не поставите. При этом надо для третьего скрипт включения. То что вы делаете 3 сервера, и пытаетесь экономить на бекапах. То человеческий фактор и ошибки в базе данных еще никто не отменил. Долго писать о всех проблемах.

    27 сентября 2011 г. 11:34
    Модератор
  • На счет переключение ручками. Это если они буду в разных VLAN. Но если не экономить на сетевой инфраструктуре, то можно сделать DAG и CAS в одних VLAN. Это очень дорого, зато 24X7. А Witness надо ставить в каждом Цоде, но больше 2 не поставите. При этом надо для третьего скрипт включения. То что вы делаете 3 сервера, и пытаетесь экономить на бекапах. То человеческий фактор и ошибки в базе данных еще никто не отменил. Долго писать о всех проблемах.


    по поводу vlan - имеете в виду, L2 маршрутизацию - скорее всего, её мне не дадут.

    по поводу бэкапов - дело не в экономии - а в том, что MS нам даёт такую возможность - почему не воспользоваться? вмоём понимании любой point-in-time backup для exchange - напрямую ассоциируется с зажиманием места под хранилище с оглядкой на то, что если что - это всё надо успеть забэкапить и потом ещё и восстановить. Но это отдельная тема - как раз моя же кстати тут давно была по этому поводу - надо бы поднять наверно

    Олег, скажите, адресное пространство для доступа к CAS - делали раздельное для каждой DAG - или единое - а дальше кросс-датацентровый nlb разбирает - кого куда или типа того что-то, или просто одна точка входа CAS - а дальше проксирование? Имею в виду для owa, activesync, oa?

    27 сентября 2011 г. 13:18
  • Делали одну точку входа, так как это увеличивало количество серверов. А при случае когда CAS без NLB привязка была по базам. Например пользователи из площадки 1 подключаються к ЦОД1 и на ней же находяться активные базы для этих пользователей.

    Это тоже без NLB HUB/CAS публиковались на TMG Standalone ARRAY как Wb Ferma.

    это без NLB Set-MailboxDatabase <Mailbox Database Name> -RpcClientAccessServer <ClientAccessServer>

    Если не будет Backup, то надо ставить систему мониторинга в режиме online. А место всеравно прийдется выделять для логов отложеной записи, для Restore LUN для каждого mailbox. И подписываться на техподдержку MS или аутсорсинг для со службой техподдержки 24X7.


    Потом реализовали сеть и посторили NLB.

    27 сентября 2011 г. 13:30
    Модератор
  • Потом реализовали сеть и посторили NLB.

    это вы о внутренних CAS-подключениях? Я думаю, можно ли сделать так - в каждом датацентре cas-array + WNLB из двух CAS-серверов - с именами, например mailA.contoso.com  и mailB.contoso.com - они будут отдаваться внутренним днс для подключения оутлука - соответственно площадке, на которой находится пользователь - и принадлежности к сайту через autodiscovery. В случае свитчовера - меняем ip у одной из этих записей, чтобы клиенты пошли в другой цод.

    А вот внешние CAS-подключения - можно также выставить две записи в интернет и подключать клиентов, разбивая по принадлежности - а можно сделать единую запись mail.contoso.com или maila.contoso.com - чтобы съэкономить на SAN-сертификате.

    В любом случае, сертификат нужен на минимум три имени - maila,mailb,autodiscover.contoso.com - при условии, что у меня нет старого адреса owa

    27 сентября 2011 г. 14:37
  • А вот внешние CAS-подключения - можно также выставить две записи в интернет и подключать клиентов, разбивая по принадлежности - а можно сделать единую запись mail.contoso.com или maila.contoso.com - чтобы съэкономить на SAN-сертификате.

    В любом случае, сертификат нужен на минимум три имени - maila,mailb,autodiscover.contoso.com - при условии, что у меня нет старого адреса owa


    Это с подключением OWA будет распределение по именам, mail.contoso.com или maila.contoso.com.

    А для autodiscover.contoso.com будет всеравно единая точка входа. )

    Что бы были разные точки входа вам надо стороить на суб доменах  autodiscover.mail.contoso.com и autodiscover.maila.contoso.com.

    И как результат это еще 2 сервера TMG в ARRAY, 2 сервера HUB/CAS.

    Если уйти от концепции единой точки входа, то количество серверов увеличиваеть 3 раза это относиться к TMG и HUB/CAS, PKI.

    По цене это дороже закупки построение отказоустойчивости в единой точке входа.

    28 сентября 2011 г. 6:13
    Модератор
  • witness нужен в любом случае. А переключение CAS будет ручками.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/

    безусловно, без witness никуда - хотя бы в случае вылета одного из двух в первичном ДЦ - для поддержания кворума.

    Вернусь к теме. Построил 3 member DAG, в общем, выяснилось, что, т.к. exchange при нечетном кол-ве членов DAG - НЕ использует witness, то при отказе одного узла в первичном ДЦ - и скажем, пропадании сети между ДЦ - DAG останавливается, есс-но, т.к. кол-во голосов меньше двух, и в сторону witness даже не смотрит. Можно запустить вручную DAG в первичном ДЦ в такой ситуации, используя ключ /forcequorum - но вопрос - как всё-таки заставить использовать witness? В "лоб" не нашёл, как задать node +witness режим вместо majority - именно в настройках exchange - а не через св-ва кворума в failover clustering в ОС. что скажете?
    11 января 2012 г. 18:12
  • Недавно было связанное с работой DAG.

    http://blogs.technet.com/b/exchange/archive/2011/11/20/recommended-windows-hotfix-for-database-availability-groups-running-windows-server-2008-r2.aspx

    Understanding Datacenter Activation Coordination Mode

    http://technet.microsoft.com/en-us/library/dd979790.aspx

    При частом падении каналов, и постороении стабильной работы лучше использовать схему DAG 3+n (где n минимум 1). Чем больше участников DAG, тем стабильней работа кластера, а так же меньше нагрузки на сеть при синхронизации баз DAG после падения.

    Призаданном альтернативном Witness сервере переключение производиться с помощью Restore-DatabaseAvailabilityGroup.

    Решение о срабатывании командлета переключения, возможно включить на основание кода события взятого из лога системы SCOM.


    MCITP. Знание - не уменьшает нашей глупости.
    12 января 2012 г. 6:47
    Модератор
  • Олег, спасибо за ссылку - у вас кстати в продакшене установлен этот хотфикс? Он ведь как interim идёт - то есть не в широком распространении

     

    Про 3+n - согласен, конечно, лучше, чем больше голосов - тем стабильнее, но у меня схема уже определена, на последней стадии тестирования.

    Каналы дублированы, но всё равно построены две DAG в каждой по три сервера - чтобы разделить территориально пользователей по популяциям.

    Есть всё же возможность использовать голос свидетеля как второй голос, когда два из трёх серверов - в оутадже - при чём один в резервном, второй - в основном ДЦ? Ситуация может возникнуть - например, один из серверов основного ДЦ - ребутим скажем ставим обновления - перевели копии на второй сервер основного ДЦ - и тут падает канал (дублированный :) ) - или рубят свет в резервном ДЦ - кластер останавливается. А если бы свидетель выступил в данном случае, то кластер был бы жив. Но мне кажется тут я что-то упускаю в плане того, что при падении скажем двух узлов в основном датацентре - кластер тоже окажеться жив - резервный сервер плюс свидетель - а это уже не правильно :)

    12 января 2012 г. 9:47
  • У нас на данный момент нет продакшен систем, где был бы риск задержки передачи больше 300-500мс и как результат падения DAG. Поэтому мы не устанавливали даный хотфикс в продакшен.


    MCITP. Знание - не уменьшает нашей глупости.
    12 января 2012 г. 11:33
    Модератор
  • Коллеги, подскажите пожалуйста ещё такой момент

    http://technet.microsoft.com/en-us/library/dd351049.aspx

    в процедуре Mailbox Server Role Switchback - есть пункт про размонтирование базы перед перемещением активной копии обратно в первичный датацентр

    b.The databases being reactivated in the primary datacenter should be dismounted in the second datacenter. You can use the Dismount-Database cmdlet to dismount the databases.

    c.After the databases have been dismounted, the Client Access server URLs should be moved from the second datacenter to the primary datacenter. This is accomplished by changing the DNS record for the URLs to point to the Client Access server or array in the primary datacenter. This will result in the system acting as though a database failover has occurred for each database being moved.

    Important: 
    Don't proceed to the next step until the Client Access server URLs have been moved and the DNS TTL and cache entries have expired. Activating the databases in the primary datacenter prior to moving the Client Access server URLs to the primary datacenter will result in an invalid configuration (for example, a mounted database that has no Client Access servers in its Active Directory site). 


    d.Because each database in the primary datacenter is in a healthy state, it can be activated in the primary datacenter by performing database switchovers. This is accomplished by using the Move-ActiveMailboxDatabase cmdlet for each database that will be activated.

    e.After each database is moved to the primary datacenter, it can be mounted by using the Mount-Database cmdlet

    В тестовой среде, на маленьких по размеру базах - и учитывая то, что url cas-массива у меня не меняется - меняется лишь IP - всё прошло пару раз нормально без принудительного размонтирования базы. Я понимаю, всё равно будет оутэдж при переезде баз - но эти действия только лишь для того, чтобы базы не стартовали с неверным URL CAS-сервера? но в св-вах базы я URL CAS-сервера не трогал - следовательно, могу пропустить размонтирование-монтирование? Или это всё-таки ещё для чего-то нужно?

    13 января 2012 г. 13:20
  • При переносе обратно на первичный дата центр, когда базы и сервера востановлены.

    1. Останавливается база в дополнительном цоде.

    2. Меняеться подклюлючение CAS на первый дата центр и базам в нем.

    3. Монтруеться базы в первом цоде.

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

    Это как я понимаю данную процедуру.

    Интиресная статья по DAG 


    MCITP. Знание - не уменьшает нашей глупости.


    13 января 2012 г. 13:44
    Модератор
  •  

    Есть всё же возможность использовать голос свидетеля как второй голос, когда два из трёх серверов - в оутадже - при чём один в резервном, второй - в основном ДЦ?

    Цитата из http://technet.microsoft.com/en-us/library/dd298065.aspx

    When a DAG is formed, it initially uses the Node Majority quorum model. When the second Mailbox server is added to the DAG, the quorum is automatically changed to a Node and File Share Majority quorum model. When this change occurs, the DAG begins using the witness server for maintaining a quorum. If the witness directory doesn't exist, Exchange automatically creates it, shares it, and provisions the share with full control permissions for the cluster name object (CNO) computer account for the DAG.

    Так что можете запустить оснастку Failover Cluster Manager на сервере MB, в свойствах кластера выбрать настройку кворума и увидеть, что она Node and File Share Majority. Если это не так, то уже вопрос почему так получилось и надо исправить.


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    16 января 2012 г. 5:13
    Модератор
  •  

    Есть всё же возможность использовать голос свидетеля как второй голос, когда два из трёх серверов - в оутадже - при чём один в резервном, второй - в основном ДЦ?

    Цитата из http://technet.microsoft.com/en-us/library/dd298065.aspx

    When a DAG is formed, it initially uses the Node Majority quorum model. When the second Mailbox server is added to the DAG, the quorum is automatically changed to a Node and File Share Majority quorum model. When this change occurs, the DAG begins using the witness server for maintaining a quorum. If the witness directory doesn't exist, Exchange automatically creates it, shares it, and provisions the share with full control permissions for the cluster name object (CNO) computer account for the DAG.

    Так что можете запустить оснастку Failover Cluster Manager на сервере MB, в свойствах кластера выбрать настройку кворума и увидеть, что она Node and File Share Majority. Если это не так, то уже вопрос почему так получилось и надо исправить.


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/


    У меня три узла - e2010 будет для трёх узлов автоматом выбирать Node Majority. Когда два узла будут в дауне, полюбому кластер умрёт, пока не сделать свитчовер Restore-DatabaseAvailabilityGroup - с указанием альтернативного витнеса. Тогда кластер "выкинет" лишние узлы из DAG и стартует на одном узле, используя узел и этот витнес в качестве двух голосов. Тогда режим становится Node and File Share. Как только делается свитч бэк - прежде упавшие узлы опять добавляются в DAG и кворум меняется на Node Majority (а если не меняется - то даётся команда Set-DatabaseAvailabilityGroup для DAG без параметров - эксчендж сам выставляет обратно Node Majority для нечетного кол-ва узлов - и менять это, как я понял, некорректно самому - то есть нечетное кол-во узлов - полюбому Node Majority). Витнес в случае Node Majority указывается для DAG - папка на сервере создается, но она пустая и НЕ используется

     

    16 января 2012 г. 7:46
  • Если мне не изменяет память, кластер автоматом будет менять модель при добавлении нечетного узла.

    По поводу набора кворума - обратите внимание на данное обновление, уточню на момент его применения к кластеру Exchange.

    16 января 2012 г. 8:10
    Модератор
  • У меня три узла - e2010 будет для трёх узлов автоматом выбирать Node Majority. Когда два узла будут в дауне, полюбому кластер умрёт, пока не сделать свитчовер Restore-DatabaseAvailabilityGroup - с указанием альтернативного витнеса.

     


    Не должен так кластер себя вести. Это какая-то проблема с кластером. Попробуйте обновление, которое привел Денис.

    Альтернативный витнес это вообще совершенно другая тема: его задействуют в резервном датацентре только тогда, когда основной датацетр полностью умер.


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    16 января 2012 г. 8:15
    Модератор
  • У меня три узла - e2010 будет для трёх узлов автоматом выбирать Node Majority. Когда два узла будут в дауне, полюбому кластер умрёт, пока не сделать свитчовер Restore-DatabaseAvailabilityGroup - с указанием альтернативного витнеса.


    Не должен так кластер себя вести. Это какая-то проблема с кластером. Попробуйте обновление, которое привел Денис.

    Альтернативный витнес это вообще совершенно другая тема: его задействуют в резервном датацентре только тогда, когда основной датацетр полностью умер.


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/

    Илья, почему не должен? Как и сказал Денис, модель меняется при добавлении узла. Если кластер нечетный - то витнес не используется - ссылку сейчас не найду, но четко написано - что директория на витнес-сервере создаётся, но она пустая. уменя так и есть. Про альтернативный витнес - тоже верно, при свитчовере в резервный ЦОД, как я и написал, в случае с тем же 3-х узловым кластером, в резервном ЦОДе - всего один узел, и модель кворума служба кластера автоматом выбирает node+witness - как раз для того, чтобы было два голоса.

    А вот хотфикс - действительно интересный, если в модели с 3-мя узлами - присвоить узлу в резервном цоде - голос = 0 - то по-идее, обрыв связи с резервным ЦОД-ом и выход одного узла из двух в первичном ЦОДе - не должен привезти к выключению оставшегося узла из-за потери кворума. Попробую воспроизвести ситуацию. Возможно это и будет ответ на мой вопрос :)

    16 января 2012 г. 9:58
  • По управлению DAG, в первую очередь опирался на управление, через консоль EMS. Консоль кластера ипользовал как средство мониторинга, и внисение изминенний только после EMS.
    MCITP. Знание - не уменьшает нашей глупости.
    16 января 2012 г. 13:31
    Модератор
  • Краткие результаты - хотфикс на всех узлах и установка для узла в резервном ЦОД nodewote = 0 с переводом кворума кластера в режим ноде+витнес - действительно позволяют кластеру работать на сотавшемся одном из трёх узлов DAG без /forcequorum

    Но смущает то, то эксчендж не предусматривает своими средствами смену кворума - тольк через управление кластером - и при выполнении команды set-databaseavialabilitygroup без параметров или с параметрами - тут же возвращает модель кворума соответственно - если нечетное кол-во узлов, то в ноде маджорити. То есть, каждый раз надо следить, чтобы режим не сменился - иначе будет всего два голоса - и вообще вылет одного узла сразу приведёт к краху кластера. В опщем, опасаюсь я, какое-то "наколеночное" решение. как считаете?

    https://microsoftit.wordpress.com/tag/exchange-2010-dag/ тут то же самое протестили, больше не нашел, кто использует в продакшене - да и в этой статье только в LAB - правда, там предположили, что в режиме DAC - кластер поведёт себя по=другому, но я проверил в обоих режимах - ведёт себя так же.

    17 января 2012 г. 15:04
  • k0lin, что Вас смущает? DAG использует Failover Cluster, на мой взгляд логично, что в текущей реализации это можно делать только с помощью упомянутого компонента. Вообще, в ключе применения данного апдейта и появления новых возможностей кластера, полагаю, мультисайтовый Exchange будет неподдерживаемым решением. Уточню этот момент.

    17 января 2012 г. 15:42
    Модератор
  • k0lin, что Вас смущает? DAG использует Failover Cluster, на мой взгляд логично, что в текущей реализации это можно делать только с помощью упомянутого компонента. Вообще, в ключе применения данного апдейта и появления новых возможностей кластера, полагаю, мультисайтовый Exchange будет неподдерживаемым решением. Уточню этот момент.


    Денис, спасибо в любом случае за информацию, а смущает, что надо доработать напильником то, что производитель не заложил изначально в продукте - сделал хотфикс для win - но не доработал скажем exchange. Я не в претензию к MS - а к тому, что, возможно, из-за каких-то вероятных причин, которых я не разглядел - всё-таки не стоит допиливать, а использовать как есть и строить схему согласно условий, а не подстраивать функционал под реалии.

    Например, потратить ещё уе на "пустой сервер" в DAG основного ДЦ только для поддержания кворума, без размещения баз на этом сервере. Его можно и в вирт среде разместить.

    И пожалуйста, расскажите, что Вы имели в виду под неподдерживаемым решением в будущем?

    17 января 2012 г. 18:18
  • У меня наконец-то достало времени прочитать всю портянку. И теперь я понял, что вы слишком многого хотите :-)

    У вас 2 узла рядом и один удаленный - классика жанра, лучше не сделаешь.

    И классика кластера: n/2= 1 в вашем случае и это означает, что вы можете потерять только одну ноду кластера, где бы она не находилась. http://technet.microsoft.com/ru-ru/library/cc770830(WS.10).aspx

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

    В вашем вопросе один проблемный сценарий: одна локальная копия DAG из двух перезагружается и в это время пропадает канал к третьей копии.
    1. Насколько это вероятно при наличии резервирования каналов? Это очень маловероятно (либо у вас очень все плохо с каналами).
    2.Следовательно суетиться надо только в том случае, когда один локальный узел отказал на долго. Тогда есть вероятность отказа каналов и отказа кластера. Единственный правильный путь - удалить отказавшую копию DAG из конфигурации; кластер перестроится в режим с использованием Witness и потеря канала будет не страшна; после восстановления второго локального сервера нужно будет провести операцию по добавлению на него обратно копии DAG. Казалось бы можно было бы применить ручное изменение режима кворума для включения Witness, но это не так - посмотрите таблицу по приведенной ссылке: в конфигурации остается-то три (!) узла и даже при наличии Witness кластер может потерять только одну ноду.
    3. Ну и еще очивидный вариант: можно не удалять отказавшую копию, а добавить новую :-) что переведет режим кластера с Witness  и позволит терять до двух нод.


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    22 января 2012 г. 17:38
    Модератор
  • k0lin, что Вас смущает? DAG использует Failover Cluster, на мой взгляд логично, что в текущей реализации это можно делать только с помощью упомянутого компонента. Вообще, в ключе применения данного апдейта и появления новых возможностей кластера, полагаю, мультисайтовый Exchange будет неподдерживаемым решением. Уточню этот момент.


    Денис, спасибо в любом случае за информацию, а смущает, что надо доработать напильником то, что производитель не заложил изначально в продукте - сделал хотфикс для win - но не доработал скажем exchange. Я не в претензию к MS - а к тому, что, возможно, из-за каких-то вероятных причин, которых я не разглядел - всё-таки не стоит допиливать, а использовать как есть и строить схему согласно условий, а не подстраивать функционал под реалии.

    Например, потратить ещё уе на "пустой сервер" в DAG основного ДЦ только для поддержания кворума, без размещения баз на этом сервере. Его можно и в вирт среде разместить.

    И пожалуйста, расскажите, что Вы имели в виду под неподдерживаемым решением в будущем?

    Это было тупиковое предложение для вашего вопроса. Главная суть в том, что Exchange сам использует API кластера для построения DAG и править настройки кластера вне оснасток Exchange это как раз и есть неподдерживаемое решение и сейчас и в будущем

    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    22 января 2012 г. 17:45
    Модератор
  • http://www.shudnow.net/2011/08/12/exchange-2010-site-resilient-dags-and-majority-node-set-clustering-part-2/

    "But what happens if you lose a second node? Well, based on the formula above we need to ensure we have 2 voters operational at all times.  At this time, the entire cluster goes offline.  You need to go through steps provided in the site switchover process but in this case, you would be activating the Primary Site and specify a new Alternative File Share Witness Server that exists in the Primary Site so you can active the Exchange 2010 Server in the Primary Site.  The DAG won’t actively use the File Share Witness but you should specify it anyways because part of the Failback process is re-adding the Primary Site Servers back to the DAG once they become operational. And once you re-add the second DAG node, you now have two DAG members in the DAG which will want to switch the DAG Cluster into a Node Majority with File Share Witness which is why you need to still specify a File Share Witness."

    При падении 2-х MBX (или Primary - MBX и канала до Secondary MBX) без site switchover и указании file share witness в PDC не обойтись...  

    17 февраля 2012 г. 10:20