Защита Microsoft Exchange в физических и виртуальных средах

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

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

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

Опции доступности Exchange

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

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

Избавьтесь от отказа ‘ избавьтесь от простоя

Большинство продуктов доступности полагаются на процесс восстановления, называемый обходом отказа (‘failover’), который начинается после возникновения проблемы. Обход отказа перемещает обработку приложений на аварийный узел после возникновения незапланированного сбоя или по команде оператора для выполнения запланированных мероприятий по обслуживанию. Обход отказа эффективен для вывода приложений обратно в активный режим в течение довольно короткого времени, но все же он приводит к простою приложений, потере транзакций, находящихся в обработке и данных, находящихся в памяти, а также подвергает данные потенциальному риску повреждения. Даже рутинный обход отказа вызовет простой приложений в течение минут или десятков минут, включая время, необходимое на перезапуск приложений и восстановление данных после возникновения незапланированного сбоя. В худшем случае ошибки в софтверном коде или операционных процедурах могут стать причиной ситуаций обхода отказа, которые не работают должным образом; в результате время простоя может затянуться на часы или даже на дни. Снижение количества обходов отказа, сокращение времени обходов отказа и уверенность в том, что обход отказа абсолютно надежен, все это позволяет снизить общее время простоя Exchange.

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

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

Незапланированный простой может быть вызван различными причинами:

• Серьезный сбой сервера, вызванный отказом работы памяти, процессора или материнской платы
• Отказы в работе компонентов сервера, включая блок питания, кулеры, внутренние диски, контроллеры дисков, адаптеры главной шины и сетевые адаптеры
• Сбои программного обеспечения операционной системы, промежуточного ПО или приложений
• Такие проблемы мест расположения предприятия, как перебои питания, перебои в работе сети, пожары, наводнения или природные бедствия

Меры предупреждения каждой категории незапланированного простоя подробно описаны ниже.

Как избегать сбоев аппаратного оборудования сервера

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

Обходы отказа, явившиеся результатом сбоев в работе компонентов сервера можно значительно снизить с помощью избыточности на уровне компонентов. Надежные серверы доступны с избыточными компонентами энергообеспечения и охлаждения. ECC память, с возможностью исправления одиночных ошибок памяти (single-bit memory errors), является стандартной функцией большинства серверов на протяжении вот уже нескольких лет. Более новые технологии памяти, включая улучшенный ECC код, резервную онлайн память (online spare memory) и зеркальную память (mirrored memory), обеспечивают дополнительную защиту, но они доступны лишь на более дорогих серверах. Резервная онлайн память и зеркальная память могут значительно увеличивать стоимость памяти и могут не быть эффективными в ценовом отношении для многих организаций Exchange.

Внутренние диски, контроллеры дисков, адаптеры главной шины и сетевые адаптеры можно дублировать. Однако добавление избыточности ко всем серверам может быть дорогим и сложным.

Снижение рисков отказа работы аппаратного оборудования хранения

Защита хранилищ полагается на избыточность устройств в сочетании с RAID хранением для защиты доступа к данным и целостности данных от сбоев аппаратного оборудования. Есть определенные проблемы как для хранения на локальных дисках, так и для хранения в общем сетевом ресурсе.

Критические шаги для защиты локального хранилища

Локальное хранение используется только для статичных и временных данных системы в кластерных решениях. Решения репликации данных содержат и обслуживают копии всех локальных данных на втором сервере. Однако сбой незащищенного локального хранилища обернется незапланированным отказом работы сервера, что может вызвать простой и представить риски, связанные с обходом отказа на резервном сервере. Для локальных хранилищ крайне просто добавлять дополнительные диски с настроенной RAID 1 защитой. Очень важно использовать второй контроллер диска, а также важно, чтобы все диски в каждом массиве RAID 1 были подключены к отдельным контроллерам. Использование других уровней RAID, таких как RAID 5, не рекомендуется для хранилищ на локальных дисках, теряется кэш записи.

Защита общего хранилища

Общее хранилище (Shared storage) полагается на избыточность в самом массиве хранения. К счастью, массивы хранения от различных производителей доступны с полной избыточностью, которая включает диски, контроллеры хранения, кэш, сетевые контроллеры, энергообеспечение и охлаждение. Избыточные синхронизированные КЭШи записи, доступные в многих массивах хранения, позволяют использовать повышающее производительность кэширование записи без рисков повреждения данных, связанных с КЭШем одинарной записи (single write caches). Однако крайне важно использовать только полностью избыточные массивы хранения; следует избегать более дешевых массивов хранения, на которых отсутствует избыточность.

Доступ к общим хранилищам полагается либо на волоконные каналы (fibre channel) или на сети хранения Ethernet storage network. Чтобы обеспечить беспрерывный доступ к общему хранилищу, эти сети должны создаваться так, чтобы устранять абсолютно все факторы риска сбоев. Это требует избыточности сетевых путей, сетевых коммутаторов и сетевых подключений к каждому массиву хранения. Несколько адаптеров главной шины (HBA) на каждом сервере могут защитить серверы от сбоев HBA или сетевого пути. ПО многоканального ввода/вывода (Multipath IO software), требующееся для поддержки избыточных адаптеров главных шин, доступно во многих стандартных операционных системах (включая MPIO для Windows), а также предоставляется многими производителями хранилищ; к таким примерам относится EMC PowerPath, HP Secure Path и Hitachi Dynamic Link Manager. Но эти конкурентные решения не поддерживаются всеми производителями сетевых хранилищ и массивов хранения, что зачастую усложняет выбор соответствующего многоканального ПО для определенной среды. Эта проблема становится еще серьезнее, если среда хранения включает сетевые элементы и массивы хранения различных производителей. Многоканальное IO программное обеспечение может быть сложным в настройке и может быть совместимо не со всеми сетевыми хранилищами или массивами хранения.

Попрощайтесь с сетевыми сбоями

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

ПО для управлении обходом отказа и распределением нагрузки среди нескольких адаптеров распределяется по категориям и включает множество различных опций. Опции включают отказоустойчивость (активную/пассивную работу с обходом отказа), компенсацию нагрузки (несколько передач с одним приемом) и объединение соединения (одновременные передачи и приемы по нескольким адаптерам). Компенсация нагрузки и объединение соединений также включает обход отказа.

Выбрать что-либо из всего этого количества вариантов бывает сложно, поэтому следует тщательно продумывать свой выбор и учитывать общие возможности сети и целевые задачи. Например, объединение соединений требует поддержки в сетевых коммутаторах и включает несколько вариантов различных протоколов, например Gigabit EtherChannel и IEEE 802.3ad. Оно также требует, чтобы все подключения осуществлялись через один коммутатор, что повышает риск при сбое в работе коммутатора.

Минимизация рисков отказа ПО

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

Снижение количества ошибок оператора

Ошибки оператора являются основной причиной простоя. Зарекомендовавшие себя, подробно прописанные процедуры, а также высококвалифицированный персонал ИТ значительно снизят шансы возникновения ошибок операторов. Однако некоторые решения высокой доступности на самом деле могут повысить вероятность возникновения ошибок операторов, поскольку требуют специальных навыков и подготовки, разработки и обслуживания сложных сценариев обхода отказа, точной координации изменений настроек на различных серверах.

Защитите себя от сбоев по всей организации

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

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

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

Надежность обхода отказа

Инвестирование в избыточное аппаратное оборудование и программное обеспечение для доступности будет бесполезным, если процесс обхода отказа будет ненадежными. Очевидным является тот факт, что необходимо выбирать надежное решение по доступности, которое будет обеспечивать надежный обход отказа, а также необходимо, чтобы ИТ персонал был специально подготовлен и имел необходимые навыки. Решения нуждаются в корректной установке, настройке, обслуживании и проверке.

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

• Простота в установке, настройке и обслуживании, что значительно облегчает работу ИТ персоналу и уменьшает вероятность ошибки
• Исключение выборов сценариев или политики обхода отказа, которые могут стать причиной ошибок
• Отслеживание актуальных ошибок оборудования и ПО, а не устаревших ошибок
• Гарантированное резервирование ресурсов и алгоритмы лучших методик

Защита от потерь и повреждения данных

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

В прошлом стратегии резервного копирования и восстановления основывались на записи данных на ленточные носители, которые можно было хранить за пределами предприятия. Однако такой подход имеет несколько недостатков:

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

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

Учитывайте моменты, которые вызывают запланированный простой

Реконфигурация оборудования и ПО, обновление оборудования, пакеты обновления и исправления ПО и новые выпуски софтверных продуктов могут требовать запланированного простоя. Запланированный простой может быть запланирован на ночь или на выходные, когда активность системы ниже, но все же есть моменты, которые необходимо учитывать. Настроения ИТ персонала могут страдать, если необходимость работать во внерабочее время будет слишком частой. Компаниям, возможно, придется оплачивать сверхурочные. А время простоя приложений, даже ночами или в выходные дни, все же может вызывать проблемы для многих компаний, которые используют свои системы круглосуточно семь дней в неделю.

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

Дополнительные выгоды от виртуализации

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

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

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