Новый дизайн хранилищ Exchange Server 2007 в Microsoft – II

Бизнес требования

MaximumExchange.ru - about How Microsoft IT Implements New Storage Designs for Exchange Server 2007

В процессе подготовки к развертыванию Exchange Server 2007 в производственной среде, в 2006 году, Microsoft IT проанализировал внутреннюю статистику и тенденции обмена электронной почты, учел количество пользователей, прояснил юридические и регулирующие обязательства, а также пересмотрел текущие соглашения об уровне обслуживания (SLA) для почтового документооборота, чтобы определить важнейшие требования бизнеса.

Выявленная статистика и тенденции четко показали необходимость увеличения объемов хранилищ для почтовых систем. Количество почтовых ящиков выросло примерно на 75% за последние пять лет до развертывания Exchange Server 2007. Стало также ясно, что эта тенденция сохранится и после его внедрения. Далее, корпоративное руководство стало рекомендовать сотрудникам не использовать личные папки для архивации сообщений. Основываясь на опросах и в ходе экспериментных проектов, Microsoft IT определил, что в зависимости от рабочих условий, пользователям могут понадобиться почтовые ящики до 2GB в размере.

VI. Бизнес требования увеличения почтовых ящиков

MaximumExchange.ru - about How Microsoft IT Implements New Storage Designs for Exchange Server 2007

Перед фактом необходимости увеличения размеров почтовых ящиков примерно в 10 раз, при условии выполнения текущих SLA, Microsoft IT тщательно изучил общие рабочие показатели и нужды отдельного пользователя. Выше изображен демографический профиль корпоративного почтового документооборота, основанный на категориях, определенных в документации к Exchange Server 2007. Документация системы учитывает средний размер сообщения в 50KB. Понятие профиля пользователя, определено Microsoft IT для утверждения стандартов требований к размерам почтовых ящиков.

Демографическое исследование выявило, что не всем сотрудникам Microsoft необходимы огромные почтовые ящики для выполнения своих рабочих обязанностей. По факту, только около трети пользователей были признаны «тяжелейшими получателями», требующими огромные почтовые ящики. Порядка 15% пользователей, являются «тяжелыми» и могут полноценно работать с ящиками около 2GB. И основное большинство составляют «легкие» и «средние» получатели, нуждающиеся в почтовых ящиках ординарного размера. Так например большинство из партнеров и вендоров Microsoft с ящиками внутри компании, принадлежат к группам средних и легких пользователей. Соответственно, департамент Microsoft IT определил около 33% пользователей с ящиком в 2GB и около 66% пользователей – 500MB квоту, для начала. Постоянные сотрудники с 500MB квотой могут запросить ее увеличение до 2GB в случае необходимости. Такое ранжирование оказало непосредственное влияние на дизайн Mailbox серверов, созданный Microsoft IT для начала развертывания Exchange в 2006 году.

В начале развертывания продукта в промышленной среде, использовалось три разных схемы Mailbox серверов, для удовлетворения нужд получателей с большими ящиками. Наиболее средний тип серверов Exchange с CCR/DAS поддерживает до 2000 пользователей с 500MB ящиками. Другие два типа Mailbox серверов поддерживают 2400 и 3600 пользователей с 2GB квотой. В стадии Beta1 продукта, Microsoft IT развертывала CCR сервера для 3600/2GB на корпоративном SAN, и к выходу Exchange Server 2007 Beta 2, сервера для 2400/2GB развертывались уже полностью на CCR/DAS. Детальное описание дизайна Mailbox серверов Exchange Server 2007 всех трех типов приведено в «Going 64-bit with Microsoft Exchange Server 2007» и будет вскоре опубликовано здесь на русском языке.

IV. Соглашения об уровне обслуживания, SLA

MaximumExchange.ru - about How Microsoft IT Implements New Storage Designs for Exchange Server 2007

Различные факторы заставляли Microsoft IT крайне тщательно подходить к дизайну серверов. Одним из важнейших факторов было то, что CCR находился еще в бета-стадии и еще не был одобрен в качестве промышленной технологии. Кроме того, единственной, доступной в то время технологией архивации Mailbox серверов CCR/DAS в Microsoft IT был Windows® Backup, потоковое приложение архивации, с ограниченной пропускной способностью и требованием выполнения онлайн архивации на активном узле. Онлайн-архивация на пассивном узле требует применения VSS-архивации, такой как в System Center Data Protection Manager 2007, но тогда этого продукта еще не было. Также, двухъядерные процессоры и модели серверов в целом, используемые Microsoft IT в начальном периоде, накладывали свои ограничения на масштабируемость серверов. Microsoft IT не мог размещать 6000 или более почтовых ящиков на сервере, без того чтобы подвергнуть опасности выполнение SLA.

Таблица выше показывает SLA всей организации, с Важным уровнем для бизнеса (BIL), который влиял на дизайн Mailbox серверов в корпоративной промышленной среде.

Важно отметить, что Microsoft IT также использует Значение точки восстановления (Recovery Point Objective, RPO) и Значение времени восстановления (Recover Time Objective, RTO) для усиления максимальной эффективности. Значения настоящих RPO и RTO для полного восстановления серверов составляют менее 24 часов. Однако эти RPO и RTO оставались со времен Exchange Server 2003, и были определены задолго до появления длительных репликаций, и не отвечали новым объемам. Так например эти RPO и RTO не определяли четко время для повторной закладки всего сервера, для восстановления отказоустойчивости после полного падения узла. Данный аспект имел неформальное значение и попадал под общее RTO сервера в менее 24 часов.

Выработка новых RPO и RTO есть постоянная задача. Microsoft IT также создает новые процедуры аварийного восстановления, чтобы задействовать все преимущества CCR, и возможно LCR. Целями Microsoft IT в настоящее время являются RTO в 12 часов, и RPO в менее часа, в случае полного выхода из строя всего Центра обработки данных. И хотя эти цели выглядят достаточно достижимыми, архитекторы Microsoft IT все равно должны выверять новые процедуры в ЦОД с более чем 12 терабайтами почтовых данных на Mailbox сервере.

V. Преимущества дизайна хранилища на DAS

MaximumExchange.ru - about How Microsoft IT Implements New Storage Designs for Exchange Server 2007

C точки зрения бизнеса, главным и наиболее важным преимуществом CCR на DAS, по сравнению с любой другой технологией хранения, для Mailbox серверов, является возможность хранить почтовые ящики существенно больших размеров, при значительном снижении стоимости хранения, вместе с тем соблюдая и улучшая имеющиеся уровни стабильности и отказоустойчивости.

Для ответственных за принятие технических решений в Microsoft IT, одним из наиболее учитываемых факторов по CCR/DAS явилась возможность управления огромными массивами данных на Mailbox серверах, обладая высокой стабильностью служб. Имея в 10 раз больше хранимых данных, с постоянным увеличением количества получателей – все меньше приходится полагаться на операции архивации и восстановления, в качестве основного решения восстановления после сбоя хранилища, и продолжать поддерживать обязательства высокой доступности. Учитывая RTO Microsoft IT, по которому требуется восстановить Mailbox сервер со всеми почтовыми базами данных за менее чем 24 часа. CCR, в этом плане, переводит фокус с архивации к преодолению отказа, failover, в качестве основного механизма восстановления, после сбоя сервера или хранилища, это является ключевой особенностью длительной стратегии Microsoft IT, по управлению большими почтовыми ящиками.

Microsoft IT извлекает следующие выгоды из CCR/DAS в дизайне Mailbox серверов:

Увеличение отказоустойчивости данных Exchange. Перехват отказов, failover – это основной метод восстановления после сбоя хранилища на основном узле кластера. Основной узел на программном уровне имеет встроенный механизм репликации и синхронизации копий почтовых баз данных, на разных узлах, и обеспечивает время восстановления в менее чем две минуты. Службы Mailbox сервера продолжают работать на втором узле, после незначительного времени перерыва, тогда как ни один из SCC (Single Copy Cluster, кластер единой копии) узлов кластерного Mailbox сервера, не может продолжать работу после сбоя хранилища. server running after a storage failure.

Архивация на лету, в обычное рабочее время. Раздельное хранение синхронных копий данных на активном и пассивном узлах, подразумевает возможность архивации пассивного узла Mailbox сервера, без прерывания работы пользователей с почтовыми ящиками, на активном узле. Microsoft IT использует Data Protection Manager 2007, полностью поддерживающий CCR и архивацию пассивных кластерных узлов каждые 15 минут.

Снижение зависимости от традиционной архивации и восстановления. В CCR кластерах, Microsoft IT использует архивацию в качестве вторичного инструмента восстановления данных, в случае выхода из строя хранилища также и на втором узле. А это маловероятно, поскольку Microsoft IT реагирует на падение любого основного узла немедленно. Это, в свою очередь, достигается постоянным мониторингом Microsoft IT всех Mailbox серверов в корпоративной инфраструктуре с помощью Microsoft System Center Operations Manager 2007 (MS SCOM). В случае сбоя узла SCOM 2007 автоматически оповещает операторов фронт-линии, выполняющих точные инструкции. А имея Mailbox службы на втором узле, Microsoft IT может восстанавливать сбоивший узел и затем посеять базу данных снова, без необходимости ее восстановления из архивных копий. Повторный посев требуется редко, поскольку Extensible Storage Engine (ESE) поддерживает автоматические механизмы восстановления, основываясь на журналах транзакций, и успешно противостоит большинству из сбоев.

Упрощение дизайна хранилищ и снижение затрат на техническое обслуживание. В противоположность SAN, сложным комплексным системам хранения, управляемым высококвалифицированными инженерами, DAS – сравнительно прост, и требует минимальных навыков от любого администратора Exchange. Microsoft IT использует отдельные корзины дисков и RAID-контроллеров в каждом кластерном узле. И при этом нет необходимости использовать строго идентичное оборудование в кластерных узлах. Должны совпадать только буквы дисков. По факту, Microsoft поддерживает CCR-кластеры Mailbox серверов из самых различных компонентов и моделей серверов, начиная от стандартных по HCL (Hardware Compatibility List), и вплоть до разных вендоров оборудования для всех узлов кластера. Однако, важно отметить, что Microsoft IT всегда использует идентичные аппаратные конфигурации серверов, чтобы перехват отказов в кластере происходил без деградации производительности.

Предсказуемая производительность Mailbox-серверов. Локальное подключение DAS гарантирует оптимальную производительность, поскольку полностью локально управляемый кластер может задействовать 100% ресурсов хранения. При этом не требуется управление распределением объемов, поскольку единственное серверное приложение, такое как Exchange 2007 будет единолично использовать ресурсы накопителей. Следовательно, Mailbox-сервера на DAS естественным образом отвечают рекомендации Microsoft о выделении отдельного хранилища для операций Exchange Server.

Повышение отказоустойчивости данных Exchange посредством избыточности

Изображение выше демонстрирует архитектуру кластеров на базе SAN, которую Microsoft IT использовал до Exchange Server 2007 в корпоративной производственной среде. 4 Активных узла соответствуют четырем Exchange 2003 Mailbox-серверам, и еще 1 пассивный узел доступен для перехвата отказов (failover) любого из этих Mailbox-серверов, без потерь производительности. Еще два пассивных узла были менее производительными, и служили, в основном, для выполнения процессов архивации на ленточные накопители. Как показано выше, оборудование SAN полностью отказоустойчиво на аппаратном уровне, начиная от кластерных узлов и вплоть до носителей данных. В любом компоненте передачи данных может произойти сбой, без остановки служб. После прохождения таймаутов задержанных I/O операций, SAN автоматически переключится на второй путь и Mailbox-сервер продолжит работать на том же самом узле кластера.

MaximumExchange.ru - about How Microsoft IT Implements New Storage Designs for Exchange Server 2007

Несмотря на всю комплексность и отказоустойчивость SAN, базы данных Exchange все еще остаются критичным пунктом возможного отказа. Кластер на SAN может предоставить высокий уровень отказоустойчивости почтовых баз данных, а сервера кластера могут перехватить отказ до трех узлов, но эта конструкция не сможет восстановиться после критического сбоя накопителей. Если хранилище SAN отказывает, по любой причине, ни один из семи узлов кластера не может продолжить работу поврежденного Exchange сервера или серверов, пока Microsoft IT не восстановит систему и почтовые базы данных из архивной копии. И хотя маловероятно, что оба диска в определенном наборе будут повреждены, вызвав сбой RAID 10, аппаратные сбои и ошибки в низкоуровневом программном обеспечении оборудования (firmware) могут привести к выходу из строя SAN. Возможен также и человеческий фактор. Де-факто, человеческие ошибки являются наибольшим фактором риска, в связи с комплексностью архитектуры SAN. Может пройти много времени, прежде чем произойдет сбой хранилища, но когда это происходит – крайне важно иметь вторую, синхронизированную копию данных, готовую к работе. И CCR представляет такую возможность.

Как показано на изображении выше, архитектура CCR очень проста и полностью отказоустойчива на уровне баз данных Exchange. Microsoft IT подключает несколько корзин хранения к каждому узлу кластера, и создает RAID 10 наборы между корзинами, это будет более подробно описано далее. На уровне баз данных Exchange – это предоставляет вдвое больше отказоустойчивости по сравнению с Mailbox серверами на SAN из иллюстрации выше.

Продолжение следует…

I | Часть II | III | IV | V

10 thoughts on “Новый дизайн хранилищ Exchange Server 2007 в Microsoft – II”

  1. Читаю уже не первую неделю Ваш блог, узнаю много интересного. Спасибо Вам за Ваш труд!

  2. Спасибо за статью, жду продолжения!

    Касательно Service Level Agreement хотелось бы увидеть больше букв и цифр, уж очень интересно

  3. Круто! Все очень понятно и грамотно, и в то же время без излишних умствований и самолюбования, и на доступном языке. Редкий случай когда человек делится актуальной и полезной инфой. Спасибо автору!

  4. Очень интересно, но все в будущем хотелось бы еще побольше узнать об этом. Очень понравилась ваша статья!

  5. А будет продолжение новости? Очень было бы интересно почитать

Leave a Reply

Your email address will not be published.