Комплексные решения проблем ИТ — это чудесная кроличья нора, в которой конструкторы систем могут прятаться в процессе вынашивания идей для крупных внедрений. Однако в большинстве случаев комплексность решения не дает особых преимуществ для таких приложений как электронная почта, которая на сегодня для большинства клиентов является вспомогательным приложением. Таким образом, возникает вопрос, зачем мы так стараемся сделать наши решения сложнее, чем требуется? Судя по всему, компания Microsoft провела большую работу по упрощению системы Office 365. Возможно, нам стоит учесть этот опыт?

Одной из незначительных, но то и дело упоминаемых тем на недавней конференции Microsoft Exchange Conference (MEC) была необходимость снижения сложности реализации. У специалистов компании явно есть ощущение, что клиенты зачастую плохо принимают разработки Exchange из-за их чрезмерной сложности. Возможно, есть доля истины в том, что архитекторы, администраторы и консультанты любят закладывать комплексность в решения, и это может быть причиной, по которой специалисты Microsoft описали предпочтительную архитектуру системы Exchange 2013 в статье на EHLO (blogs.technet.com/b/exchange/archive/2014/04/21/the-preferred-architecture.aspx). Ключевая идея, которую нужно усвоить, заключается в том, что упрощение просто необходимо.

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

Но электронная почта – это особая статья. На данном этапе своего развития она является вспомогательным приложением. Следовательно, можно сделать обоснованный вывод, что серверы электронной почты должны разрабатываться как упрощенные компоненты, подгоняемые друг к другу при построении службы. Тема упрощения часто затрагивалась на всех этапах разработки системы Exchange 2013, в том числе вопросы сокращения серверных ролей, клиентских протоколов (превосходство протокола HTTP было усилено благодаря использованию схемы «MAPI через HTTP») и появление упрощенных групп DAG.

В выступлениях на конференции не раз мелькали комментарии вроде «комплексность порождает отказ» и «люди – главная угроза для сроков восстановления». Несомненно, компания Microsoft извлекла урок из опыта управления системой Office 365. Мне кажется, многие комментарии, прозвучавшие на конференции MEC, напрямую вытекают из работы с этой системой. Однако лишь у небольшого количества компаний есть кадровые ресурсы, возможности для внедрения, инвестиции или навыки автоматизации, необходимые для того, чтобы перестроить систему Exchange на модель, реализованную в Office 365.

Хотя система Office 365 — это «вещь в себе», мы не должны игнорировать опыт, вытекающий из работы с ней. Я уже проанализировал некоторые советы, озвученные на конференции MEC под влиянием Office 365, такие как снижение количества сетевых интерфейсов на серверах-членах группы DAG и более активное использование отсроченных копий базы данных, и мне кажется, что «облачный» опыт и дальше будет оказывать влияние на рекомендации по архитектуре, которые мы услышим от специалистов Microsoft.

С другой стороны, в мире не существует клиентских решений, подобных системе Office 365, и вы не можете просто взять все подходы, применимые к системе Office 365, за «истину в последней инстанции». Например, система Office 365 использует серверы Exchange 2013 с единственной ролью, в то время как для клиентов предпочтительным является использование мультиролевых серверов, в силу того, что при данном подходе могут быть получены более высокие показатели надежности и эффективности использования оборудования. Мало того, в описании «предпочтительной архитектуры» ясно указано, что она основана на принципе «все серверы физические и мультиролевые». Внимательные читатели отметят, что данный подход не отличается склонностью к виртуализации. Это связано с тем, что гипервизоры добавляют дополнительный слой и повышают сложность процессов настройки, управления и работы.

Еще одним отличием системы Office 365 является метод, используемый для установки пакетов исправлений и обновлений программного обеспечения. Серверы разбираются практически до «голого железа», после чего повторно собираются по «эскизам». Данная операция не под силу большинству отделов ИТ из-за недостатка средств автоматизации. Однако для системы Office 365, учитывая ее масштабы и количество серверов, такой подход необходим. Представьте себе процесс установки важных исправлений на 100 000 серверов. Просто представьте.

Возвращаясь к идее упрощения, стоит упомянуть, что о ней, как о руководящем принципе для архитекторов, красноречиво высказался Борис Лохвитский. Он использовал свой багаж знаний профессора математики, чтобы показать, что, возможно, мы «гоняемся за собственным хвостом», пытаясь использовать комплексные решения для достижения высокой доступности. Идея была проста. На работу системы Exchange влияет множество отдельных компонентов. Если вы хотите получить работоспособность в 99% времени, вам необходимо выяснить, как именно каждый компонент влияет на работу. Если хранилище и сеть по отдельности обеспечивают работоспособность в 99% времени, то общая доступность системы будет равна 98%. Если, условно говоря, бросить показатель работоспособности сервера в миксер и добавить туда программное обеспечение, то вы снизите общий показатель доступности, если только данные компоненты не обеспечивают работоспособность 100% времени. Словом, чем больше частей добавляется в решение, тем ниже его общая доступность. Скорее всего, это связано с тем, что большее количество элементов может сломаться. И, возвращаясь к одному из упомянутых комментариев, человек может ошибаться при работе с большим количеством компонентов.

Еще одно обсуждение с использованием математической базы приведено в статье EHLO «DAG: Beyond the A» (blogs.technet.com/b/exchange/archive/2011/09/16/dag-beyond-the-a.aspx). Данный текст посвящен системе Exchange 2010, но уроки, извлеченные из этой статьи, могут быть применены и к системе Exchange 2013. Если вас не убедит это «послание апостолов доступности», то, наверное, не убедит уже ничто.

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