Главная Exchange/UC, Новое Предпочитаемая архитектура Exchange Server 2013
  • Предпочитаемая архитектура Exchange Server 2013

    12232 Каждые 3-4 года компания Microsoft изобретает новый уникальный, идеальный и удобный велосипед под названием архитектура Exchange Server. Все течет, все меняется и архитектура Exchange Server 2013 не стала исключением. Концепция построения средних и крупных решений на базе Exchange изменилась. Очень серьезный мужчина по имени Ross Smith IV написал на продуктовом блоге статью «The Preferred Architecture».  Мужчина этот, к слову сказать, является  Principal Program Manager в Microsoft и работает в компании с Exchange  уже 14 лет. Т.е человек в сфере Exchange   авторитетней некуда. Все что написано ниже это вольное изложение статьи Ross Smith-а.

    Собственно новый подход основан на накопленном опыте, который был получен Microsoft  при эксплуатации такого решения как Office 365.

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

    • Снижение стоимости инфраструктуры, обслуживающей почтовые системы
    • Обеспечение защиты от пожаров, наводнений, отключений электричества, масок-шоу и любых угроз, которые выводят из стоя дата-центр целиком
    • Обеспечение поддержки множества копий каждой базы и наличие быстрой активации резервной копии
    • Упрощения системы и увеличение доступности за счет сокращение точек отказа

    Естественно не все предписания новой рекомендуемой архитектуры должны быть использованы каждым заказчиком. (например далеко не все имеют два дата-центра) Да и многие заказчики в принципе имеют другие бизнес требования, которым не нужна такая архитектура. Если вы серьезная компания у которой тысячи ящиков, много офисов и требования к доступности электронной почты тоже серьезные, то при развертывании  Exchange в организации данные рекомендации все же стоит использовать , отклоняясь только в там, где это действительно необходимо. Ну или использовать Office  365, где с одной стороны вы получите почтовую систему построенную по всем правилам, а с другой не будете заниматься ее построением.

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

    Простота.

    «Shit happens». Рано или поздно сбои случаются.  Диски, сервера, хранилища, сетевое оборудование, кабеля, генераторы, подстанции, операционные системы, приложения, драйвера и сторонние сервисы. Каждый элемент может  дать сбой. Если мы хотим застраховаться, то строим отказоустойчивые решения. Там где объект может стать причиной сбоя используется два или  более подобных объектов. Этот подход может быть задействован в массиве веб-серверов или дисковой системе. Но отказоустойчивость при дублировании каждого компонента и стоить будет соответственно, за все придется платить  дважды.

    Сердцем старых версий Exchange была система хранения. Стоимость и сложность систем хранения побудили команду разработчиков Exchange произвести изменения в стеке хранения и интегрировать важные элементы хранилища напрямую в архитектуру продукта. При планировании принималось как факт, что любая система хранения в конечном итоге упадет, а обеспечение высокой доступности систем хранения будет непомерно дорогим. В ответ, Exchange поменял подход и теперь вместо трат на отказоустойчивые СХД, предлагается высокая доступность  за счет масштабирования серверов с низкоскоростными SATA\SAS дисками в конфигурации JBOD, естественно  с использованием самых обычных контроллеров. Т.е для обеспечения высокой доступности предлагается развертывать несколько дешевых серверов Exchange, каждыйаждый из которых имеет копию данных и полнофункционален. Все это позволяет обеспечить защиту от падения любого хранилища и при этом обеспечить большие почтовые ящики пользователям при разумной цене решения.

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

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

    Примеры комплексной избыточности это сетевые устройства работающие в режиме активный\пассивный, тиминг сетевых карт, RAID, несколько Fiber путей и многое другое. Уход от комплексной избыточности кажется странным – как удалить избыточность и при этом сохранить отказоустойчивость?  Все просто – осуществляется переход от комплексной избыточности к избыточности исключительно на уровне приложения. Это делает возможные отказы прогнозируемыми.

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

    Новая архитектура состоит из четырех приоритетных компонентов:

    • Дизайн пространства имен
    • Дизайн дата центра
    • Дизайн серверов
    • Дизайн DAG

    Дизайн пространства имен

    Пользователи всегда подключаются к Exchange по какому-то имени, вне зависимости от того вводят они его или нет. Существуют различные варианты конфигурации имен доступа в Exchange 2013.

    С точки зрения имен для подключения есть два варианта:

    • Определенный дата-центр (когда все пользователи подключаются к определенному дата-центру)
    • Свободное распределение (когда пользователи подключаются к любому дата-центру без приоритета)

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

    • autodiscover.contoso.com
    • Для HTTP-клиентов: mail.contoso.com
    • Для IMAP клиентов: imap.contoso.com
    • Для SMTP клиентов: smtp.contoso.com

    clip_image003

    Схема 1. Дизайн пространства имен

    Если у вас есть общее имя для подключения mail.contoso.com, то клиентские подключения на него должны балансироваться между дата-центрами. Для этого используется либо DNS балансировка, либо geo-DNS или другие доступные технологии, вроде аппаратных балансировщиков. С точки зрения Microsoft чем проще тем лучше, а поэтому обычная DNS балансировка предпочитаемый вариант. В случае если у вас есть несколько дата-центров, вам необходимо решить, либо использовать одно имя, либо контролировать трафик задействовав для регионов собственные имена.

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

    Дизайн дата центра (пара дата-центров в отказоустойчивой схеме)

    Для построения высоко доступной системы вам желательно иметь два и более дата-центров, соединенных хороши каналом. (в идеале задержка на канале должна быть минимальна) В дополнении так же необходимо иметь резервирование каналов в каждом дата-центре. Microsoft поддерживает сайты Active Directory растянутые на два дата-центра, но для архитектуры Exchange рекомендуя каждый дата-центр делать отдельным сайтом.

    Но это есть две причины:

    • Отказоустойчивость транспорта через Shadow Redundancy и Safety Net может быть реализована, только если члены DAG группы расположены в разных сайтах.
    • Рекомендации по Active Directory говорят, что если между подсетями задержка выше 10ms, то эти подсети должны быть закреплены за разными сайтами AD DS.

    Дизайн серверов

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

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

    Сейчас рекомендуется развёртывание серверов с совмещенными ролями, архитектура упрощается, т.к все серверы используют одно и тоже оборудование, процесс установки, настройки, и.т.п. Серверы с несколькими ролями более эффективно используют ресурсы, распределяя задачи CAS\MBX между пулом серверов. При этом в проектировании закладывается максимальный уровень загрузки в 80% для самого плохого варианта, когда уже потеряна часть серверов.

    Для реализации архитектуры рекомендуются 2U сервера с возможностью установки до 12 дисков. Количество дисков зависит от количества ящиков, их размера и подхода к масштабируемости. Каждый сервер несет пару дисков в RAID1 на котором располагается ОС, файлы Exchange, логи и очередь сообщений. Остальные диски объединятся в JBOD из обычных больших дисков SCSI (SAS) (не смотря на то, что SATA диски все еще доступны, SAS показывает более низкий процент отказов)

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

    clip_image004

    Схема 2. Дизайн серверов

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

     

    Группы высокой доступности DAG

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

    Это дает преимущество:

    1. Постоянное уверенность в том, что каждый член DAG у вас работает (плюс CAS\Transport). Люди распределены между дата-центрами и если все спокойно, значит оба дата-центра функционируют штатно.
    2. Распределение нагрузки между серверами и уменьшение зоны поражения в случае падения одного дата-центра. При выходе из строя одного дата-центра половина сотрудников вообще не ощутит изменений, т.к будет работать во второй площадке.

    Поскольку дата-центры симметричны, в каждом дата-центре будет установлено четное количество серверов. А это требует использовать свидетеля для обеспечения кворума. DAG это основа Exchange 2013 и в рамках архитектуры подразумеваются большие DAG группы. (обычно от 8 серверов) Создание нового DAG это либо еще большее масштабирование (например 30 серверов Exchange), либо просто ограничение области репликации баз в рамках организации. (в Европе свой DAG, в Америке свой)

    Сетевой дизайн DAG

    С момент появления репликации баз данных в Exchange 2007 было рекомендовано использование нескольких сетевых интерфейсов для разграничения сети клиентской и сети для репликации данных. Наличие доп. интерфейса позволяет изолировать трафик, по которому базы реплицируются и не перегружать клиентский интерфейс. Хотя это относится больше к 100 мегабитным каналам. При этом и каналы связи тоже должны были быть разными. Но у многих клиентов оба сетевых адаптера использовали общую сетевую инфраструктуру и поэтому разделение было неполным.

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

    Размещение свидетеля.

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

    clip_image005

    Если у компании нет третьей площадки, естественно свидетеля придется размещать в одной из двух площадок. Размещать придется в основном дата-центре там где больше всего пользователей. Так же нужно убедиться, что Primary Active Manager (PAM) находится в этом же сайте.

    Отказоустойчивость данных

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

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

    В отсроченной копии параметр ReplayLagTime конфигурируется в 7-дневный интервал. В добавок в Replay Lag Manager включается в режим динамического проигрывания транзакционных логов.

    Транзакционные логи проигрываются в следующих случаях:

    1. Заканчивается место на диске
    2. Когда отложенная копия физически повреждена и страницы должны быть исправлены
    3. Когда есть меньше трех доступных здоровых копий за 24 часа

    Используя отсроченную копию, важно понимать, что это не гарантия бэкапа на конкретную точку времени.  Для защиты от случайного удаления элементов существуют отдельные технологии Single Item Recovery или In-Place Hold, которые позволяют поддерживать SLA. Если использовать все и сразу, то бэкап не нужен, такой подход называется  Exchange Native Data Protection.

    Основные итоги

    1. Кластеризация Exchange это дешево и просто
    2. Виртуализация Exchange не рекомендуется
    3. Exchange использует простые 2U сервера
    4. Рекомендуется совмещать роли Exchange  на севере
    5. Сервера Exchange  дублируются и взаимозаменяемы
    6. Рекомендуется использовать DNS балансировку клиентов
    7. Можно использовать один сетевой адаптер для кластеров
    8. Рекомендуется иметь несколько датацентров

    P.S Тут можно дискутировать по некоторым пунктам, но такова рекомендация Microsoft.

    Оригинал The Preferred Architecture

    MCT/MVP Илья Рудь

    Курсы Exchange Server 2013

    • Рубрика: Exchange/UC,Новое
    • Автор: Илья Рудь
    • Дата: Суббота 17 Май 2014

Комментарии

  1. Забавные моменты, которые обращают на себя внимание:

    1. Внутри MS нет согласия между командами разных продуктов. Команда платформы (Windows Server) рвётся в облака — всё должно быть в облаке (частном или публичном), на виртуальных серверах. Команда Exchange пятится назад, возвращая по сути архитектуру 10-летней давности — Exchange Server 2003 (добавив к ней репликацию баз) и предлагает опять много мелких физических серверов вместо облака. Интересно, есть ли в MS кто-то, кто тянет в воду?

    2. Стремление реализовать много мелких дешёвых серверов имеет для MS достоинство: больше серверов — больше продастся лицензий. Вопрос, оценят ли это достоинство пользователи.

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

  2. 1. MS это лебедь, рак и щука, тут сомнений нет. Планы меняются очень быстро и несогласованность видна невооруженным взглядом. Не соглашусь с тем что 2013 отличается от 2003 только репликацией баз. По функционалу за десять лет ооочень много что изменилось.

    2. Про количество серверов и лицензии спорно, не думаю что это причина. Все бабки делаются клиентскими лицензиями, а не серверными.

    3. Я думаю смысла в этом нет, DAG сейчас устраивает всех и даже в Site Resilience отрабатывает отлично.

  3. «3. Я думаю смысла в этом нет, DAG сейчас устраивает всех и даже в Site Resilience отрабатывает отлично.»

    Проблема с надежностью witness share в Exchange 2013 DAG, тем не менее, существует. Microsoft не обеспечила автоматический переход на alternate witness share и вообще никак не комментирует этот момент (а что тут комментировать, если архитекторы облажались).

  4. Я честно не вижу проблемы с надежностью witness. Иметь кластер и терять сразу ноду со свидетелем это талант нужно иметь. А автоматический переход на alternate witness share сразу вносит столько неоднозначных сценариев с определением кворума, что нафик оно не нужно.

  5. Размещение следящего сервера в третьем датацентре у МС в разделе заблуждений.

    blogs.technet.com/b/excha...s-addressed.aspx

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

  7. «Рекомендуется совмещать роли Exchange на севере»

    Для 2013 Exchange данный вывод не актуален, так как есть всего 3 роли:

    Edge

    Cas

    Mbx

    Edge находится в DMZ, а если объединим CAS + MBX — получим невозможность создать DAG.

  8. Артем, в понедельник придешь на пересдачу)

  9. Точно! Был не прав. Уже MBX и CAS можно совмещать. Готовлюсь пересдавать 🙂

  10. Здравствуйте Илья!

    Почему вы рекомендуете использовать совмещенные роли CAS+MBX? Разве CAS сервера не должны быть отдельно? Ведь они играют роль прокси или я ошибаюсь? В чем фишка совмещения ролей? На мой взгляд если использовать раздельную архитектуру ролей, то мы получим более гибкую и надежную структуру Exchange, в отличии от архитектуры совмещенных ролей. У меня есть сомнения по поводу совмещения ролей, и хотелось бы услышать или прочесть примеры и факты, почему все таки лучше всего совмещать роли?

    Заранее Спасибо!

  11. Namik, без обид, но прочитайте статью, аргументация там написана. (чем проще тем лучше, причин для разделения нет) P.S Рекомендую не я, а Microsoft)

  12. Я прочел вашу статью, сорри Спасибо, забыл поблагодарить вас.

    Согласен с вами, нет смысла строить сложную структуру там где нагрузок особых нет, но если все таки нагрузки есть например на 5000 пользователей? как тогда поступать разделять роли или совмещать по любому? Ну например рекомендации от Microsoft для exchange 2010 было разделять роли, а тут же рекомендации совмещать их, и нет конкретных ответов почему? Плюс ко всему выход нового протокола mapi/http, работает быстрее, чем rpc/http, который все больше меня запутал. Если проблема в rpc/http, то ок, согласен он не устойчив, и тогда я пойму, что лучше избавится от лишних прыжков при подключении, и совместить роли, но как же с mapi/http? и все таки почему MS рекомендует совмещать роли, ведь это не маловажный фактор при построении архитектуры ms exchange 2013. Не думаю, что только потому что, «чем проще тем лучше» и с какими проблемами могут столкнутся сис админы, если будут разделять роли?

    Заранее Спасибо!!

  13. Namik в штатах на совмещенных ролях работают компании за 100 тыс человек с кол-вом серверов в DAG под 15 штук. И работают нормально, так что мы можем точно не переживать.

  14. Илья, и все таки ответа я не получил :). Ведь есть же смысл слов «рекомендую». Вы говорите про штаты, где стоят аппаратные балансировшики с встроенными механизмами проверки состояния каждого сервиса, встроенными фаирволами итд, где по сути играют роль CAS-ов. То тогда ок, нет смысла разделять и еще больше усложнять структуру. Ок Илья не буду вас отвлекать своими вопросами и мыслями. Спасибо за вашу статью, я всегда наблюдаю за вашими очень полезными публикациями.

    Спасибо что уделили мне время!

  15. Добрый вечер, Илья я у Вас учился в УЦ Специалист на курсах 20341, 20342.

    Получилось так, что вместо роли MBX поставил CAS 🙂

    Хотел У Вас узнать как удалить корректно сервер CAS Exchange 2013 ?

  16. Запускаете установку Exchange, снимаете галку CAS, ставите другую MBX и прогоняете процесс установки.

  17. Илья, галочка CAS неактивна

    Exchange 2013 Sp1

  18. Ггг... посмотрел, оказывается этот косяк тянется с 2013 версии. Предлагается снести полностью сервер через установку и удаление программ. А потом поставить нужную роль новой установкой. P.S Люди, зачем вы делите сервера на роли?

  19. Спасибо Илья буду пробовать.

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

  20. Раньше нормально состав ролей меняло. Халтурят ((

  21. Илья а есть рекомендации по количеству сетевых адаптеров для серверов с объединением ролей ?

    И можно ли разрулить трафик по ним к примеру так:

    1-сеть HB

    2-сеть обмен DAG

    3-сеть транспорт

    4-сеть CAS

  22. Рекомендация — один гигабит на все. Остальное это... таллинский стриптиз.

  23. Просто с CAS и транспортом можно коннекторами а вот с DAG трафиком непонятно

  24. Спасибо Илья.

Опубликовать

Я не робот.