Managed Availability — несомненно, очень важный компонент Exchange 2013, и его значение для «облачной» версии в составе Office 365, пожалуй, больше, чем для локального продукта. Но зачем программному продукту вообще нужны возможности самовосстановления?

Начался 2014 год, и полезно оглянуться на развитие технологий, значение которых возрастало в течение 2013 года. Для Exchange существует лишь один кандидат на эту роль: Managed Availability. Этой теме будет посвящено две статьи: в первой будет рассмотрена логика и дано обоснование самого существования Managed Availability; в следующей речь пойдет о реализации и особенностях работы с Exchange 2013.

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

На самом деле, единственная причина привлечения человека к выполнению ИТ-операций общего назначения — это незначительный фактор, именуемый «знанием». Компьютеры и другие машины пока не достигли уровня развития, при котором они могли бы функционировать без присмотра человека. Компьютеры чрезвычайно успешно справляются с четко определенными задачами, но люди должны сформулировать задание и убедиться, что оно успешно выполнено.

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

В мире центров обработки данных проблема стала еще более актуальной. Небольшой компании достаточно одного или двух администраторов, обслуживающих 20 или 30 серверов, но такое соотношение неприемлемо для компании, предоставляющей коммерческие «облачные» службы, так как число серверов может достигать тысяч и десятков тысяч. В действительности, прямое взаимодействие людей с серверами следует полностью исключить, по крайней мере в повседневной работе. Автоматизация — критический фактор, и акцент выполняемых человеком задач перемещается с повседневного управления серверами на поиск способов исключить оператора из контура управления.

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

PowerShell – самый яркий пример развития этого направления. Когда-то высмеиваемая как слабый аналог командной оболочки Unix, сегодня PowerShell признана краеугольным камнем эффективного управления серверами Windows. Без PowerShell компания Microsoft не могла бы управлять центрами обработки данных Azure и Office 365.

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

Managed Availability (MA) — столь же важное техническое достижение в Exchange 2013. Как нередко бывает с техническими новшествами, требуется время, чтобы оценить и признать влияние на приложение таких компонентов, как Managed Availability. Недостаточно просто установить и запустить несколько серверов Exchange 2013 в тестовой среде. Нужно поработать с программным продуктом в производственных условиях, чтобы оценить настоящую глубину влияния, оказываемого Managed Availability на группы DAG, IIS и другие важнейшие компоненты Exchange 2013.

Managed Availability — превосходный пример того, как Microsoft решает проблему, возникающую в центрах обработки данных компании, и в процессе разрабатывает полезную технологию, чтобы передать ее клиентам для локального применения. Office 365 обслуживает десятки миллионов почтовых ящиков, и число серверов и дисков резко увеличилось. Сравнительно просто спланировать, закупить и внедрить необходимое оборудование в центрах обработки данных, наряду с построением центра обработки данных, организацией электропитания и охлаждения и обеспечением безопасности. «Сравнительно» в данном случае означает «очень трудно и дорого, но возможно». Amazon и Google делают для своих центров обработки данных в отношении построения и внедрения примерно то же, что и Microsoft. Различие — в программном обеспечении каждого центра обработки данных.

Одно из преимуществ Google в том, что компания проектирует свои приложения с нуля. По мере развития приложений от начальной до бета-версии и полноценного рабочего продукта Google параллельно выстраивает функционирование и мониторинг центра обработки данных. Благодаря приобретаемому при этом опыту компания непрерывно совершенствует услуги, предоставляемые пользователям. Результаты превосходны. Так, с момента появления Gmail отличается последовательно организованным и надежным обслуживанием.

Для сравнения, когда потребовалось расширить присутствие компании на рынке «облачных» служб, Microsoft усовершенствовала локальную версию Exchange для решения двух задач. Как объяснил мне вице-президент по разработке Перри Кларк, это был единственный приемлемый вариант, так как он позволял компании сохранить существующую аудиторию пользователей. Однако очень трудно преобразовать программный продукт, спроектированный для локальной работы определенного масштаба, для обслуживания десятком миллионов клиентов в тысячах компаний, подключенных к нескольким центрам обработки данных. А после того, как эта задача будет решена, необходимо добиться уровня обслуживания не ниже 99,9%.

Managed Availability — критически важный компонент для достижения этой цели. Его не было в Exchange 2007, а службы Business Productivity Online Services (BPOS) имели совершенно иную природу и не были предназначены для функционирования в таких масштабах. У BPOS много изъянов, но это не удивительно, так как Microsoft пыталась предоставить «облачные» службы с использованием программных продуктов, изначально не предназначенных для «облака».

Exchange 2010 также не располагает компонентом Managed Availability. Продукт Exchange 2010 стал основой для начальной версии Office 365. Его авторам удалось продемонстрировать, что дополнительное время, выделенное для разработки после выпуска Exchange 2007, было потрачено на то, чтобы усовершенствовать Exchange, лучше приспособив продукт к требованиям «облачных» служб. Но на сегодня сложилась ситуация, когда исходные тексты Exchange Online и локальной версии Exchange различаются. Это порождает дополнительные сложности, которые связаны с лишними затратами и вероятными ошибками; ошибки в программах ведут к сбоям в предоставлении «облачных» услуг, что особенно неприятно для инженеров Exchange, обязанных реагировать на вызовы. Сбои обычно происходят в самое неудобное время, например в 3 часа утра.

С появлением Exchange 2013 этот недостаток удалось исправить, и теперь имеется единая база исходного текста. Перед Microsoft по-прежнему стоит задача устранения возможности отключения служб (в том числе для того, чтобы инженеры могли спокойно спать по ночам), и для ее решения предназначен Managed Availability.

Итак, необходимость в Managed Availability очевидна. Без автоматизированного мониторинга и управления трудно поддерживать функционирование центра обработки данных на экономичном уровне. Но полезен ли компонент Managed Availability для локальной установки? Об этом речь пойдет в следующей статье.