top of page

​

High Availability. Высокая доступность.

​

В данной главе речь пойдёт о кластеризации.

Высокая доступность в Exchange реализуется за счёт дублирования серверов.

Отказоустойчивость каждой отдельной роли обеспечивается отдельно. Т.е. отдельно CAS, отдельно Mailbox, отдельно Hub, отдельно Edge. 

​

Начнём мы с кластеризации Mailbox. Она обеспечивается одним единственным способом, который называется DAG (Database Availability Group). Ни один из предыдущих вариантов кластеризации продолжения не получил. В 2003 был Single Copy Cluster (два сервера и одна БД лежит на СХД). В 2007 было 4 варианта кластеризации Mailbox. 

DAG - это объединение нескольких Mailbox-серверов вместе. Когда они объединены, вы можете включать репликацию БД с одного сервера на другой. У вас на каждом сервере будет находится копия БД. Но в активном (т.е. в работоспособном) состоянии БД может находится только на одном сервере. В случае падения сервера или выходе из строя самой БД, происходит переключение. Становится активной вторая база. И CAS организует подключение уже на неё.

Запомните нюанс. Кластеризовать в DAG'e можно только базы данных почтовых ящиков. Кластеризовать в DAG'е Public Folder нельзя. Для этого используется простая репликация, которая обсуждалась в главе про Mailbox.  

В 2010 DAG имеет несколько приятных особенностей:

- можно поднимать на стандартной версии Exchange. В предыдущих версиях, кластеризация Mailbox была доступна, только если у вас версия Enterprise.

- возможность осуществлять кластеризацию в любой момент, а не только на этапе установки. 

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

​

В группу DAG может входить до 16 серверов. Т.е. каждая БД может иметь 16 копий. Идёт постоянная синхронизация от активной базы на пассивную. Групп DAG может быть сколько угодно, но один сервер входит только в одну группу DAG. Т.е. фактически группа DAG представляет собой зону репликации БД, т.е. БД не может реплицироваться за пределами серверов группы DAG.

​

Итак, как всё это работает.

Меню изучения Exchange 2010

Вы берете сколько нужно серверов. Объединяете их в группу DAG. После этого, при создании БД, говорите, что эта БД должна иметь реплики, к примеру, на 2-м и 3-м сервере группы DAG. Либо берете уже существующую БД, кликаете ПКМ и говорите добавить реплики (Add Mailbox DB Copy).

Имейте ввиду, вам не обязательно делать создание копий (реплик) на каждом сервере группы DAG. Т.е. если у вас 10 серверов, вы для одной БД можете указать, что она реплицируется только на 3 и 10, а другая на 4,6 и 9. Более того, вы можете вообще оставить БД как есть, т.е. без копии.

Т.к. CAS подключен к той БД, которая является активной (в нашем случае DB1), все клиентские подключения идут на эту базу. Если клиенты что-то делают, в ней генерируются трансзакционные логи. Эти ТЛ копируются в копии БД и там проигрываются. По умолчанию они проигрываются по мере поступления, т.е. сразу после копирования. Таким образом происходит актуализация. Если вдруг что-то случается с активной базой, нужно выбирать, какая из пассивных копий заменит активную. Во-первых отметаются все те сервера, которые сейчас не доступны или БД, которые сейчас не работают (например размонтированы). Потом, из оставшихся в сети баз, выбирается наиболее актуальная по отношению к упавшей актуальной версии. Очередь непроигранных ТЛ может отличаться, т.к. сервера по мощности могут быть разные, скорость сети может быть разная и прочее. Следовательно, потому и надо выбирать самую актуальную. В Exchange 2010 sp1 переключение при падении БД составляет 30 секунд. Это гарантия самого MS.

     Обязательным условием при создании DAG является установка на Exchange-сервер компонента ОС "Failover cluster". Поэтому в 2008 ОС у вас должна быть версии Enterprise. Exchange может быть Standard, а ОС Enterprise. От этого никуда не деться.

Представим картину. У нас есть 3 Mailbox-сервера. На каждом сервере несколько баз. 

DB1 на сервере1 - активная, пассивных реплик у неё нет.

DB2 на сервере2 - активная, имеет пассивные реплики на сервере1 и сервере3.

DB3, DB4 на сервере3 - логика, думаю, понятна.

У нас падает сервер3.

Что будет с DB2? Ничего, это пассивная копия.

При падении DB3 она будет заводится на сервере2.

При падении DB4 два варианта. Заводить её на сервере1 или на сервере2. Будет выбрана та реплика, которая на момент падения была наиболее актуальной.

Нагрузку Exchange не рассчитывает. Поэтому будьте внимательны. Может сложится ситуация, когда всё переедет на один сервер (в нашем примере, например на сервер2). Нагрузка резко возрастет. Так что мощностей должно быть у вас с запасом.

Настройка DAG.

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

Что такое Witness Server и Witness Directory? Witness - свидетель.

Представим. В DAG у нас входят два сервера, один активный, другой пассивный. Сервера между собой будут постоянно обмениваться heart beat'ами (собственно, именно для этого вы устанавливаете компонент Failover Cluster. От него берется heart beat).

У нас падает активный сервер. Какие мысли у пассивного сервера:

1. Активный сервер упал, мне нужно становится активным.

2. Проблемы у меня, активным становиться не нужно.

В кластерах есть понятие Quorum, т.е. голосование по большинству. Но у нас

всего два сервера (и один погиб), голосование по большинству при таком раскладе ничего не даст. Поэтому предполагается использовать Witness Server. Это любой сервер в вашей сети под управлением Windows, на котором создается специальная расшаренная папка, в которой создаются файлы, которые используются серверами группы DAG. И фактически этот сервер с расшаренной папкой является третьим голосом в нашем случае (так сказать, свидетель). Если активный сервер упал, но доступен свидетель и второй сервер со свидетелем видят друг друга, то ситуация два против одного. Профит. Кластер продолжает работать. Если вдруг второй сервер не видит ни свидетеля, ни первый сервер, он делает вывод, что у него проблемы и работать начинать не надо. 

Есть режим работы DAC mode (Datacenter Activation Coordination), когда у вас три сервера. Тогда всё проще. Свидетель не нужен, всё будет решаться голосованием. Пока два сервера из трех друг друга видят, работа продолжается.

Итак, указываем сервер-свидетель и папку. Для папки задаем не сетевой путь, а локальный. 

Обратите внимание, вам необходимо группу Exchange Trusted Subsystem (она в AD) добавить в группу локальных администраторов на сервере, который является свидетелем.

     Если свидетель - это КД, то можно в AD на этом компьютере найти группу Exchange Trusted Subsystem и в свойствах во вкладке Member Of добавить её в группу локальных админов.

Заходим в свойства DAG и на вкладке IP Addresses указываем IP-адрес группы DAG. Это служебный IP, который используется серверами группы DAG. Он должен быть из той же подсети, где расположены сами сервера (или если они в разных сайтах, то из каждой подсети должно быть по одному IP). 

Указываем 10.10.0.80.

Итак, группа DAG у нас есть, но пока ни одного сервера в ней нет (загляните во вкладку Operational Servers, там пусто. Собственно как и на вкладке General и в колонке Member Servers, в окне, где отображается наш DAG1).

Щелкаем ПКМ на DAG1 и выбираем Manage DAG Membership. Жмакаем Add и выбираем сервера, которые нужно добавить. В нашем примере выберем van-ex1 и van-ex2.

Повторюсь, что все действия можно сделать в любой момент. В предыдущих версиях Exchange, когда вы настраивали cluster continuous replication и single copy cluster,  кластеризацию нужно было делать на этапе установки. Если установили обычный сервер, придется переинсталировать. Уже кластер не сделать. Более того, кластеризуя Mailbox, никакие Hub'ы и CAS'ы использовать было нельзя.

Итак, ожидаем некоторые время и видим, что сервера добавлены в DAG.

Теперь можно кластеризовать какую-нибудь базу. Имейте ввиду, что если БД на активном сервере у вас находится , например, в D:/base, то на пассивном сервере, куда вы будете включать реплику, тоже должен быть диск D (папка base создастся при реплике автоматом на этом диске). Т.е. должна быть полная синхронизация, т.к. копия базы будет создаваться по тем же путям. Реальный пример из моего опыта - на каждом сервере создан отдельный логический диск под каждую базу (или несколько баз на одном логическом диске, если они небольшие). У меня 10 баз. Я сделал 5 одинаковых дисков на каждом сервере Mailbox. На 3-х дисках лежит по одной базе. На оставшихся двух лежат оставшиеся 7 небольших баз.  

Итак, приступим к реплике базы.

Для примера возьмем базу Accounting, которая лежит на van-ex1. Будем делать её копию на van-ex2. Откроем свойства и скопируем путь к ней. Посмотрим через проводник.

Через проводник видим, что на van-ex1 папка Accounting имеется (логично, база и логи лежат в этой папке). На van-ex2 её пока нет (логично, она будет создана в процессе создания реплики).

Тыкаем ПКМ на базе и выбираем Add Mailbox DB Copy.

Через Browse выбираем сервер, на который будем включать копию. У нас он один, van-ex2, поэтому доступен только он.

Activation preference number - номер базы. Т.е. при равных условиях будет выбираться сервер в порядке preference number.

Нажимаем Add. Процесс пошел. Идем на van-ex2, видим, что папка Accounting появилась. Открыв её, в реальном времени можно наблюдать, как в неё копируется информация. Дожидаемся окончания.

Теперь, когда мы выбираем базу, внизу отображается информация о том, на каких серверах она расположена. Статус Mounted говорит, что пользователи сейчас работают с этой базой на указанном левее Mailbox-сервере. Статус Healthy указывает на пассивную копию, готовую встать в строй. Иногда статус может быть Dismounted или Service unavailable (например, когда сервер в DAG не доступен).

Теперь протестим, как же всё это работает.

Возьмём юзера в базе Accounting и отправим от него письмо через owa. После этого можно сразу заметить, что логи в пассивной копии увеличиваются, что говорит о том, что синхронизация работает.

Берем базу в состоянии Healthy и делаем её активной, тыкнув Activate DB copy.

Обратите внимание на Suspend DB copy. Это "поставить БД на паузу". Т.е. она жить будет, но трансзакционные логи в неё копироваться и проигрываться не будут, синхронизация работать не будет.

Итак, жмём Activate DB copy на базе в состоянии Healthy.

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

информации.

При выборе Lossless БД не будет подключена автоматически, пока все журналы, созданные на активной копии БД не будут скопированы в пассивную копию БД. 
При выборе Good Availability, БД будет подключена автоматически, при условии, что длина очереди копирования меньше или равна 6. Если очередь копий хранит более 6 файлов журнала, БД не будет подключена.
С Best Effort база будет подключена независимо от длины очереди копирования Будьте осторожны с этой настройкой, так как вы можете потерять много данных в почтовых ящиках.
С Best Availbility БД будет подключена автоматически, если длина очереди копирования меньше или равна 12. Если длина очереди копирования превышает 12, БД не может быть смонтирована.

Информацию про варианты активации переводил как умею. С оригиналом можно ознакомиться здесь:

http://www.msexchange.org/articles-tutorials/exchange-server-2010/high-availability-recovery/uncovering-exchange-2010-database-availability-groups-dags-part4.html

Выбираем любой, можно Lossless, мы же в тестовой среде.

И видим, что статусы у баз поменялись местами. Теперь активной является БД на van-ex2. Синхронизация и копирование логов будет теперь идти в обратную сторону.

Кстати, справа обратите внимание на  колонку

Replay Queue Length (блин, как криво я обрезал). Это очередь проигранных логов. Она была =22. Обновите окно, она будет =0. Логи то уже в обратку идут.

​

Проверяем, как там наш пользователь owa и видим, что он отвалился (обновите страницу). CAS полез и не обнаружил базу. Поэтому обновляем ещё раз и CAS перекинет нас на нужную базу.

 

Закончим на этом с тестированием. В нём мы перемещали базу вручную. Естественно, при падении, всё должно сработать автоматом.

 

Поговорим о различных проблемах. 

​

Есть 2 отдельных mailbox-сервера и 1 отдельный Hub. Активный mailbox1 падает. У mailbox2 не будет всей информации, которая была в момент отказа у mailbox1. Связано это с тем, что как минимум всегда есть последний транзакционный лог, который залочен и скопируется только тогда, когда будет

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

Есть механизм Transport Dumpster. Это такой карман на каждом Hub-сервере, который хранит фиксированное количество последней почты. По умолчанию Transport Dumpster хранит 18 Мб на каждую БД.  Приходит письмо и попадает в Transport Dumpster. Затем приходит следующее и если размер Transport Dumpster превышен, старая информация выкидывается, новая добавляется.

Mailbox2, как только он становится активным, оповещает все Hub'ы в своём сайте, о том, что для базы db1 он теперь активный. Поэтому доставайте свои Transport Dumpster и перешлите мне.   

​

Посмотреть настройки Transport Dumpster можно через EMC командой Get-TransportConfig | fl *dupmster*

Параметр *dumpster* возвращает нам 2 значения, где встречается это слово.

MaxDupmsterSizePerDatabase - это максимальный размер dumster'а на базу данных.

MaxDumpsterTime - Максимальная продолжительность хранения сообщения в dumpster'е (по умолчанию 7 дней).

​

Как всё это будет выглядеть со стороны пользователя? Он писал/получал почту. Вдруг клиент (например, Outlook) задумался, т.к. упал mailbox-сервер. Outlook думал секунд 20 и снова начал работать, т.к. база переподключилась. Но у пользователя пропали последние письма. Проходит ещё секунд 20 и последние письма разом появляются.

 

Интересный вопрос. Почему все подключения, в том числе и MAPI, осуществляются через CAS. Представьте, что у вас подключения были бы осуществлены к БД. БД упала. И сотням клиентов надо понять, куда переехала копия. А вот когда все подключены к CAS, CAS видит куда переехала копия, переустанавливает соединение и для клиентов ничего не меняется.

​

Рассмотрим следующую проблему, когда Hub совмещен с Mailbox-сервером и падать они будут вместе. Соответственно вариант с dumpster'ом 

накрывается. Чтобы такой неприятности не было, то придумана следующая схема. Если БД находится на mailbox1, то используется соседский Hub, т.е. Hub2. Если БД на mailbox2, то используется Hub1.

В таком случае, получить падение БД и почты, находящейся в dumpster'е, мы не можем.

Данный факт относится только к серверам, включенным в DAG.

Без DAG, в случае установки Hub на компьютере, где также установлен Mailbox, роль Mailbox будет предпочитать локальный Hub любым другим Hub'ам в сайте Active Directory (даже если локально установленный Hub недоступен), когда служба отправки почты Microsoft Exchange отправляет сообщения. Но данный факт, как я уже сказал, не относится к серверам, включенным в DAG группу. В случае, если Hub'ы установлены на сервера MailBox, входящие в DAG, то MailBox будет предпочитать любой другой Hub Transport в сайте AD, и только в последнюю очередь будут обращаться к локальным.

По поводу отказоустойчивости Hub-серверов. Решается она легко - путем установки 2-х Hub-серверов на одной площадке. Один всегда страхует другой. У вас будет работать Round robin, т.е. распределение нагрузки (часть писем через один сервер, часть через другой). Никаких дополнительных манипуляций с Hub-сервером делать не нужно. В предыдущих версиях Exchange была проблема. Если Hub совмещен с Mailbox, то этот Mailbox всегда использует этот Hub. Если Hub падает, то Mailbox не видит, что есть ещё один Hub. Сейчас такой проблемы нет. Ставите два Hub'а и спите спокойно.

 

Краткие итоги по Hub'у.

1. Если у вас два mailbox'а не в DAG'е и два отдельных Hub'а, то mailbox оповещает Hub'ы по очереди и делает отправку через оба. Если один Hub лёг, будет использоваться оставшийся.

2. Если у вас два mailbox'а не в DAG'е и два совмещенных Hub'а, то mailbox вначале использует свой Hub. Если свой Hub лёг, будет использоваться соседний.

3. Если у вас два mailbox'а в DAG'е и два совмещенных Hub'а, то используется перекрестный вариант, как на схеме выше.

​

Как быть с входящей почтой? Т.е. у вас есть два Hub'а и вы хотите чтобы входящая почта балансировала.

Вы делаете две mx-записи с одинаковым удельным весом. Всё. Если один Hub Лег, входящая почта пойдёт на другой. Т.е. те, кто ломанутся на нерабочий Hub, поймут что он не работает и пойдут на другой.

 

И ещё один момент, относящийся к отказоустойчивости Hub. Shadow Redundancy (Теневая избыточность).

Если у вас много транспортных серверов (неважно, Hub'ы или Edge'и), при прохождении письма через них может возникнуть проблема. Сервер передал письмо на следующий транспортный сервер, следующий должен передать ещё куда-то. Но в процессе передачи он падает. И получается ситуация, что вы, как изначальный отправитель, от письма избавились, а оно не дошло. Поэтому внутри между Hub'ами и Edge'ами действует Shadow Redundancy: любое письмо, которое вы передаете дальше, вы не удаляете из очереди, а перемещаете в Shadow Redundancy. При следующей SMTP-сессии сервер будет отчитываться за письма, которые вы ему передавали. Если он становиться недоступен и отчет не пошел, значит ищем альтернативные варианты. Итого, запомните, если встретите очередь с Shadow Redundancy - это значит, что сервер письмо передал, но отчет еще не получен. 

Подробнее с Shadow Redundancy можно ознакомится на сторонних ресурсах в статьях "Exchange 2010: Shadow Redundancy" и "Transport Hight Avaliability в Exchange 2007-2010".

​

​

​

Сложнее ситуация обстоит с отказоустойчивостью CAS. Тут несколько вариантов.

Вариант "для бедных". 

Совмещаем роли, установив два CAS'а. В DNS создаем две записи. mail.adatum.com разрешаем в IP первого и второго CAS'а. Когда подключаются клиенты, они обращаются к DNS, который возвращает им записи по порядку. Первому запросу первую запись, второму вторую, третьему первую, червертому вторую и т.д. Это будет делать Round Robin, который включен по умолчанию. Об этом мы уже говорили в самой первой главе в разделе "Настройка DNS записей".

В чём проблема? В случае выхода из строя одного из CAS'ов, клиентам будет возвращаться запись на неисправный сервер, т.е. часть клиентов никуда не попадет. В таком случае в быстром темпе вы удаляете запись на упавший CAS. Затем ждем 180 секунд пока очухается клиентский кэш (он очиститься и клиенты ещё раз обратятся) и после этого все подключатся. Также есть тонкость с работой MAPI-клиентов (все остальные подключения будут работать нормально). Об этом мы поговорим чуть ниже, в разделе CAS Array.

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

Вариант "для богатых". 

Устанавливаем аппаратный балансировщик (например Cisco). Делаем настройку, что необходимые порты (80, 443 и куча для MAPI) должны балансироваться между двумя CAS'ами. Имя mail.adatum.com разрешаем в IP-адрес балансировщика. Этот балансировщик и будет заниматься раскидыванием клиентов. Если один CAS вылетает, балансировщик адресует всё на один оставшийся.

Таким образом мы реализуем хорошую отказоустойчивую схему. Если один сервер (со всеми ролями) падает, то БД переезжает на другой Mailbox, Hub'у вообще плевать, а балансировщик переводит всё на оставшийся CAS.

Балансировщики стоят немалых денег. И раз уж мы добиваемся отказоустойчивости, их нужно два (они работают у себя в кластере), что увеличит и без того круглую сумму в два раза. 

Вариант "для среднего класса". Client Access Server Array в связке с балансировкой NLB. NLB доступен в любой версии Windows. Но есть проблема. Windows NLB не дружит на одной ОС с компонентом Failover cluster, который используется при установке DAG. Тут вообще интересная тема. Если у вас установлен NLB и вы пытаетесь накатить Failover Cluster, Server Manager вас сразу пошлет. А вот если ситуация обратная и вы накатываете NLB на сервер, где уже есть Failover Cluster, NLB-оснастку Server Manager установит. Но когда вы будете создавать NLB-кластер, NLB Manager вас пошлет с ошибкой "Не могу продолжить, т.к. установлен Failover Cluster". Такой вот тупняк. 

Ввиду того, что NLB не работает с Failover Cluster (который установлен у нас на Mailbox'ах), роли нам придется разносить. В итоге получится 4 сервера: два с mailbox и два CAS+HUB.

Теперь про NLB временно забываем и разбираемся с Client Access Server Array. CAS Array - это массив CAS-серверов в конкретном сайте AD. Т.е. при создании CAS Array нам необходимо будет указать имя CAS Array (например mail.adatum.com) и в каком сайте он создается. При создании CAS Array произойдёт объединение всех CAS-серверов в этом сайте. И MAPI-клиенты смогут подключиться к БД в DAG только через этот CAS Array.

Создаем CAS Array.

New-ClientAccessArray -FQDN mail.adatum.com -Site "Default-First-Site-Name" -Name "mail.adatum.com"

-FQDN mail.adatum.com - это имя, по которому будут подключаться MAPI-клиенты

-Site "Default-First-Site-Name" - имя сайта AD. Скопировать его можно в оснастке Active Directory Sites and Services.

-Name "mail.adatum.com" - имя самого массива (это чисто для информации, можно любое указать).

Итак, в нашем сайте мы создали объединение CAS-серверов, куда попали van-ex1 и van-ex2 (обратите внимание на столбец Members).

Теперь MAPI-клиенты должны обращаться через CAS Array по адресу mail.adatum.com.

И вот тут начинаются интересности. Идём в свойства БД Get-MailboxDatabase MyDB | fl *rpc*. 

У каждой БД есть параметр RpcClientAccessServer. Это тот сервер, через который клиент может подключиться к базе по MAPI. Т.е. к базе MyDB по MAPI можно подключиться  только через van-ex1.

А в предыдущем шаге мы сделали CAS Array. И клиенты по MAPI могут подключаться только по адресу, указанному в массиве, т.е. mail.adatum.com.

Следовательно, мы должны поменять параметр RpcClientAccessServer у баз, иначе MAPI-клиенты работать не будут.

​

Запомните это! У каждой базы есть параметр RpcClientAccessServer. Это сервер, через который можно подключиться по MAPI. Например, есть база и 20 CAS-серверов. Через owa или ActiveSync вы можете через любой CAS подключиться к этой базе. А по MAPI можно подключиться только через CAS, прописанный как RpcClientAccessServer. По умолчанию в RpcClientAccessServer прописывается CAS-сервер, который стоит вместе с Mailbox. Если CAS отдельный, то прописывается сервер, через который в первый раз произошло подключение. Например Вася в первый раз ломанулся и его подключило через van-ex15. Всё. Теперь все подключения MAPI только через этот сервер. Если этот сервер в последствии станет недоступен, то никто по MAPI не подключится, пока вы не укажите в параметре RpcClientAccessServer новый CAS-сервер.

​

Итак, меняем параметр RpcClientAccessServer на адрес созданного нами CAS Array. Set-MailboxDatabase MyDB -RpcClientAccessServer mail.adatum.com

Готово. Теперь думаем, в какой IP разрешать имя mail.adatum.com. Можно разрешить его в IP-адрес любого из CAS. Но у нас их два, они в массиве и должны подменять друг друга. Если один вылетит, нам придется руками прописывать другой CAS. Поэтому вспоминаем про NLB. Имя mail.adatum.com мы будем разрешать в IP балансировщика.

Устанавливаем NLB на каждый сервер с CAS+HUB и создаем кластер. Настраиваем на балансировщике порты:  135 (это endpoint mapper, т.е. по нему устанавливается соединение для согласования портов), 443 (чтобы балансировались owa, ActiveSync), 1024-65535 (любой из этих портов может быть назначен для подключения по MAPI).

С более подробной информацией можно ознакомится в сторонней статье "Отказоустойчивый Exchange 2010 (DAG + NLB)".

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

​

Подведем итоги по отказоустойчивости CAS.

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

Берем вариант "для бедных". Два сервера (1.1.1.1 и 2.2.2.2), на каждом три совмещенные роли. Собираем CAS Array с именем mail.domain.ru, всем RcpCAS у БД указываем имя этого массива. В DNS делаем две записи:  mail.domain.ru 1.1.1.1 и mail.domain.ru 2.2.2.2. Если один CAS падает, удаляем вручную из DNS запись на него и ждём, когда клиенты переподключаться. Купить аппаратный балансировщик или держать 4 Exchange-сервера мне не по карману. Хотя если вы в Газпроме, то почему бы нет.

​

Отказоустойчивость Edge.

Для отказоустойчивости Edge надо подписать два Edge'а  на один сайт AD. Снаружи делаем две mx-записи, каждую заруливаем на свой Edge. Изнутри делает ничего не нужно, всё работает само. Как только Hub видит, что на его сайт подписаны два Edge'а, он их использует по порядку (первый, второй, первый, второй). Первый недоступен, значит только второй.

Переходите к следующей странице: Резервное копирование и восстановление.

Меню изучения Exchange 2010

bottom of page