Главная Exchange/UC, Без рубрики, Новое Построение системы высокой доступности в Exchange 2010
  • Построение системы высокой доступности в Exchange 2010

    cluster Много копий ломается по поводу построения систем высокой доступности. Раньше считалось, что систему высокой доступности могут позволить себе только крупные предприятия, потому что за каждую девятку после запятой надо платить в десятикратном размере. Безусловно, это правда – высокая доступность стоит денег. Но что изменилось с выходом Exchange 2010? Какие подходы к высокой доступности существуют и какие возможности у вас есть для того, чтобы построить такую систему?

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

    Теперь, когда мы с этим определились, можно идти дальше и рассмотреть подходы к обеспечению сервиса высокой доступности Exchange 2010

    1. Традиционный подход. Можно забыть о том, что мы имеем дело с Exchange 2010  и построить стандартный отказоустойчивый кластер с единым хранилищем. Как? Очень просто – использовать виртуализацию. Выбор вендора виртуализации за вами, также как и средств управления виртуализацией.

    Какие преимущества у этого подхода? Их не так уж мало

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

    Но и недостатков немало

    • Единое хранилище – это единая точка отказа. Аппаратное резервирование данных стоит очень дорого. То есть цена решения сильно возрастает. Кроме того, СХД с возможностью подключения нескольких серверов стоят значительно дороже хранилищ, подключаемых к серверу напрямую (DAS)
    • Exchange ничего не знает про такую модель. Соответственно в данной модели не предусматривается отказоустойчивость на уровне данных Exchange. Например на уровне базы данных.
    • Восстановление на уровне ящиков также становится более сложным делом.
    • Немаловажный момент – в данном случае получается, что вам придется использовать разные инструменты для управления Exchange и отказоустойчивостью

    Ограничения использования виртуализации:

      Поддерживается серверная виртуализация вендоров – участников SVVP (Server Virtualization Validation Program). Подробнее о программе можно почитать здесь
      Не поддерживается (хотя и работает) виртуализация роли Unified Messaging. То есть нужно относиться к этому осторожно, возможны проблемы при использовании неподдерживаемой конфигурации
      Хранилищем может быть как VHD, так и ICSCI (то есть раздел в сети). Учитывайте, что производительность  дисковой подсистемы часто является узким местом системы виртуализации

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

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

    Для начала немного истории

    В Exchange 2003 для повышения доступности использовался кластер с единым хранилищем. Поскольку как таковых ролей не было (были Front End и Back End сервера, но это немного не то), можно было построить отказоустойчивую систему на двух серверах. Но при этом масштабировалась данная система не очень хорошо, да и общее хранилище являлось единой точной отказа.

    С появлением Exchange 2007 для отказоустойчивости на уровне данных стали использоваться технологии репликации (LCR, SCR, CCR). Репликация позволяет избавиться от единой точки отказа в виде общего хранилища. К недостаткам данной системы следует отнести то, что для разных целей используются различные технологии. Кроме того, единственная технология, обеспечивающая доступность системы при выходе из строя одного из серверов (CCR), требует построения кластера Exchange и Enterprise редакции сервера. Также следует заметить, что совмещение ролей на одном сервере в этом случае невозможно.

    В Exchange 2010 появились новые возможности по повышению доступности системы.  Давайте посмотрим – что же это за возможности

    • Database Availability Groups или группы доступности баз данных. Новая технология позволяет реализовать доступность на уровне баз данных, а не серверов. Вы можете иметь до 16 серверов в одной группе выскокой доступности, и соответственно до 16 копий одной базы данных. При этом активные копии разных баз данных могут быть расположены на разных серверах. Использование DAG позволяет решить проблему доступности данных как в основном ЦОД (на случай аппаратного сбоя), так и в резервном ЦОД (на случай катастрофы). Кроме того, DAG можно использовать как инструмент резервного копирования. Эту технологию хорошо иллюстрирует рисунок ниже

    DAG

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

    • CAS Arrays или массивы серверов клиентского доступа. В Exchange 2010 клиенты Outlook  (за исключением общих папок, от которых уже многие отказались) подключаются через RPC Client Access Service на серверах клиентского доступа. Все остальные клиенты подключались к CAS еще в версии 2007, так что теперь схема является также унифицированной. Итак, что такое CAS Array и для чего он нужен? Массив – это логическое объединение серверов клиентского доступа, которое позволяет задать единое имя массива и использовать его при подключении клиентов (например cas.contoso.com). Кроме того, вы можете использовать CAS Array в свойствах базы данных почтовых ящиков (параметр RPC Client Access Server). Далее дело за вами.
      • Вы можете использовать балансировку в DNS (например создав 2 записи cas.contoso.com). При выходе из строя одного из серверов массива вам придется вручную удалить одну из записей из DNS (что конечно снижает доступность системы). При этом TTL записи не должен быть большим
      • Вы можете использовать ip адрес DAG (при создании DAG указывается ip адрес), который является ресурсом кластера. При выходе из строя одного из серверов, ip адрес перейдет на другой. Но во первых данная схема не поддерживается Microsoft (хотя и работает). Подробнее об этом можно почитать здесь. А во вторых, при выходе из строя IIS, кластерный ресурс никуда не переедет и клиенты будут получать ошибку.
      • Вы можете использовать NLB. При этом вы можете использовать как Windows NLB, так и любой другой балансировщик (аппаратный или программный). Стоит заметить, что вы не можете использовать Windows NLB и DAG на одних и тех же серверах. Если вы совмещаете роли клиентского доступа и транспорта, стоит учитывать некоторые нюансы, о которых я писал ранее. Применяйте технологию балансировки сетевой нагрузки осторожно, неправильная настройка может привести к проблемам при доступе к сервисам. Схема с DAG и NLB на рисунке нижеDAG NLB

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

    • Online Mailbox Move, то есть перемещение почтового ящика в режиме online (на лету). Перемещение почтового ящика может понадобиться вам по разным причинам. Например при логическом повреждении базы данных или ее переполнении. Независимо от причины переноса, раньше приходилось ждать окна обслуживания системы или мириться с недоступностью сервиса для пользователя в процессе переноса, который мог занимать и несколько часов (в зависимости от размера ящика и количества элементов). Использование окон обслуживания приводило к удорожанию операций обслуживания системы. Конечно вы можете запланировать перенос ящиков по расписанию. Но что, если окно обслуживания у вас только одно и вам надо убедиться, что перенос выполнен успешно и иметь возможность оперативно исправить ситуацию, если что то пойдет не так? Как правило работать ночью администраторы Exchange не очень любят – сужу по собственному опыту. Поэтому предпочитают, чтобы такая работа дополнительно оплачивалась. Теперь же можно смело переносить ящики из одной базы в другую, не опасаясь жалоб пользователей. Данный принцип изображен на рисунке ниже

    Online mailbox move

    Таким образом, мы с вами рассмотрели отказоустойчивость двух ролей Exchange 2010 – почтовых ящиков и клиентского доступа. Как же насчет остальных, спросите вы? Здесь мало что меняется по сравнению с Exchange 2007 SP1. Все очень просто

    • Транспортные сервера. Здесь отказоустойчовость внутренней маршрутизации реализована встроенными способами. При наличии более одного сервера Hub Transport в сайте Active Directory вы автоматически получаете отказоустойчивую схему внутреннего транспорта. Правда если у вас используются внутренние smtp клиенты, вам потребуется приложить определенные усилия для отказоустойчивости данного сервиса. Вы также можете использовать NLB, учитывая определенные соображения, описанные мною ранее
    • Пограничные сервера. Балансировка и отказоустойчивость внешней почты обеспечивается с помощью MX записей во внешней зоне DNS (можно использовать MX записи с одинаковым или разным весом). Балансировка почты из организации осуществляется автоматически при подписывании серверов Edge на сайт Active Directory
    • Сервера Unified Messaging. Вы можете настроить ip шлюз таким образом, чтобы он ссылался более чем на один сервер UM. Таким образом будет обеспечена высокая доступность и этой роли
      Надо заметить, что вы можете использовать технологии высокой доступности Exchange и виртуализацию. Однако совмещение технологий высокой доступности (кластера виртуализации и отказоустойчивости Exchange) не поддерживается. Выбирайте – или то, или другое

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

Комментарии

  1. Отличная статья. Я целиком за “Прогрессивный подход”, лично мне он кажется более гибким так как покрывает и падение данныхсервиса и падение железа.

    При “Online Mailbox Move” всеравно недоступность будет, просто она ничтожна, если сравнивать с предыдущим вариантом.

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

  3. Павел, спасибо за статью!
    Можно Вас попросить не много расскрыть тему для использования DAG в двух сайтах Active Directory с обеспечением доступности CAS и Hub серверов. На сколько я понял CAS Arrays работает только в одном сайте.

  4. Попросить можно, отчего же нельзя. Но здесь все достаточно просто. Обеспечить высокую доступность CAS можно только в случае наличия более чем одного сервера в массиве, а массив действительно может принадлежать только к одному сайту Active Directory. Со всеми вытекающими отсюда выводами
    Естественно при этом вы можете обеспечить доступность данных с помощью DAG
    Что касается доступности HUB, то не совсем понятно – доступность для чего имеется ввиду. Если для внешней входящей почты, то здесь все зависит от того – как и что вы настроите. Edge сервер подписывается на сайт AD, соответственно потребуется перенастройка. Если Edge неподписан или используется другой сервер для приема почты – потребуется перенастройка на HUB в другом сайте (если схема пересылки не реализована с помощью нескольких MX и DNS). Если речь идет о доступности хаба для внутренних клиентов, то их также придется перенастроить (лучше подумать об этом заранее и использовать отдельную запись в DNS с небольшим TTL, которую можно будет быстро перебросить на другой сервер)
    При этом сами клиенты смогут работать с сервером Exchange в другом сайте. Просто нужно будет вручную сменить параметр RpcClientAccessServer в свойствах базы данных

  5. Правильно ли я понимаю, что если один из сайтов полностью будет уничтожен автоматического переключения на CAS и HUB в другом сайте не будет. Придется пользователей либо руками либо через DNS и TTL перекидывать? Вариант с межсайтовым WLB не получиться :-).

  6. Правильно. Однако если сайт выйдет из строя целиком, то как правило этот сценарий предполагает проблемы со всеми сервисами у клиентов в данном сайте. К тому же выход сайта из строя как правило предполагает ручную активацию резервного датацентра. Все таки это случай больше похожий на катастрофический
    В этом смысле главное, что будет обеспечено – это отказоустойчивость данных Exchange в резервном датацентре
    Есть еще один вариант – использовать выделенный сайт для Exchange, распределенный между двумя датацентрами. Тогда в случае, если вы сможете обеспечить сетевую доступность при выходе одного датацентра из строя – все будет ок

  7. Спасибо за разъяснения.

  8. Не за что – обращайтесь

  9. Добрый день, спасибо за статью! Павел, можно Вас попросить, чтобы расставить точки на i, указать порядок действий в случае падения одного из серверов, либо где про это можно почитать; интересует в том числе, сколько в среднем времени займут эти операции. Спасибо.

  10. Добрый день. Возможны различные сценарии. Если мы говорим про “прогрессивный” подход, то в этом случае следующие варианты
    1. При использовании DAG, в случае выхода из строя одной из копий баз данных или сервера целиком, базы данных автоматически активируются на другом сервере. Никаких действий для восстановления сервиса предпринимать не придется
    2. При выходе из строя одного из CAS серверов в CAS Array:
    а) Если используется WNLB и сервер выключен, то также все подключения пойдут на оставшийся сервер. То же касается и Hardware Load Balancer (HLB)
    б) Если используется WNLB и произошла проблема скажем с IIS (служба перестала быть доступной), то необходимо будет выключить проблемный сервер.Иначе часть пользователей получит отказ в обслуживании. На этом примере мы видим, что использование HLB является предпочтительным, так как с ним такой проблемы не будет
    в) Если используется балансировка в DNS (две записи на одно имя массива), то одну из записей нужно будет удалить. В этом случае сервис восстановится когда клиент обновит информацию из DNS. А это зависит от TTL записи. В общем случае можно рекомендовать 5 минут
    Касательно остальных ролей – для них при наличии дублирования делать ничего не придется по причинам, которые я описал выше
    Это в общем случае. Частности всегда могут быть разными