На главную страницу
 
  Главная 
  Новости 
  Статьи  RSS
  Программное обеспечение 
  Форум 
  Опросы 
  Полезные ссылки 
MSExchange.ru ISADocs.ru WinSecurity.ru NetDocs.ru

Exchange 5.5
Exchange 2000
Exchange 2003
Exchange 2007
Общее
Exchange 2010

Поиск по сайту


Авторизация

Запомнить меня на этом компьютере
  Забыли свой пароль?
  Регистрация

Подписка

Изменение параметров

Статистика

Hits 2747283
11976
Hosts 1649541
423
Visitors 229616
486

6

Главная / Статьи / Exchange 2003 / Только скажите НЕТ для A/A


SurfCop

Только скажите НЕТ для A/A

Версия для печати Версия для печати

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.

По моему мнению, электронная почта все еще остается интернетовским приложением-убийцей. И в соответствии с Forbes.com, Exchange является корпоративным сервером электронной почты номер один. Следует ли вам использовать кластеризацию для Exchange? Хорошо, это зависит от требований вашего бизнеса и от того, как много вы готовы потерять от вынужденных простоев. Следует ли вам использовать Active/Active кластеризацию? НЕТ!

Введение

Является ли электронная почта критическим приложением? Ответ на это — твердое ДА!

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

Надежность сервера за последние годы претерпела значительные улучшения. Серверы стали более крепкими и надежными, были объединены технологии из мира майнфреймов, а также разработаны новые технологии. «Прямо из коробки» современные серверы, возможно, смогут обеспечить вас надежность «две девятки» (99%) или более, в будущем. Но затем вы захотите получить дополнительную 9 в наработке на отказ. Вот когда вы начинаете думать о кластеризации.

Вред от Active/Active кластеризации

Одна из наиболее спорных проблем состоит в том, следует ли вам использовать Active/Active (A/A Активный/Активный) конфигурацию на вашем Exchange кластере.

Кластеризация является дорогостоящей технологией. Если вы уже используете ее или, по крайней мере, рассматриваете вопрос о ее применении, то это потому, что вы не можете допустить вынужденных простоев. Вы только должны быть объективными при убеждении вашего начальника одобрить огромный бюджет на покупку этого кластера state-of-the-art («состояния искусства»): ориентировочная прибыль, которую вы получите от увеличения время наработки на отказ при применении кластерной технологии, выше, чем потери в следствие вынужденных простоев в течение ожидаемого времени жизни оборудования.

Это подводит нас к главной теме этой статьи: следует ли вам использовать A/A конфигурацию с вашим кластером Exchange Server или нет. Конечно, эта дискуссия применима только к 2-узловому кластеру, так как для больших кластеров вы всегда должны иметь пассивный узел.

Рисунок 1: A/A Exchange кластер

Microsoft рекомендует Active/Passive (A/P — Активный/Пассивный) конфигурацию, в основном из-за масштабируемости, проблем с фрагментацией виртуальной памяти и производительностью. На протяжении следующих параграфов я попытаюсь объяснить немного подробнее, почему вам следует принять эти рекомендации.

1. Главная цель использования кластера — это не производительность, а повышенная работоспособность

Остановитесь на минуту и подумайте: почему вы используете кластер? Потому что вы хотите иметь высокую работоспособность и отказоустойчивость, правильно? Хорошо, в случае отказа одного узла, вы будете иметь 2 экземпляра Exchange на одном узле. Если вы не имеете соответствующее аппаратное обеспечение, ваши сервера не будут хорошо отвечать на клиентские запросы. За исключением, конечно, если вы не купите двукратную мощность, по отношению к требуемой вам обычно, (и даже тогда будут некоторые ограничения, как вы увидите в дальнейшем), но зато, почему бы вам не купить сервера подешевле и не сделать 3-узловой кластер?

2. Фрагментация виртуальной памяти

В высоко-масштабируемых кластерах требования виртуальной памяти при введении второго Exchange Virtual Server (EVS — Виртуальный Сервер Exchange) в режиме online на узле, который уже имеет установленным и выполняемым другой экземпляр Exchange, может привести к повышенной фрагментации виртуальной памяти.

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

Очевидно, в ситуации A/A наихудшим сценарием является тот, в котором два независимых экземпляра Exchange Virtual Server (EVS) находятся на одном и том же узле (вследствие сбоя, обновления, обслуживания и т.д.). Так как на узле кластера может выполняться только один процесс store.exe, каждый Exchange Virtual Server старается заполучить его в личное владение экземпляром Extensible Storage Engine (ESE — Наращиваемый Движок Хранилища) внутри такого же процесса хранения.

В конечном счете, продолжительное выделение и освобождение различных по размеру блоков памяти внутри процесса приводит к тому, что виртуальное адресное пространство становится фрагментированным и ведет к полному сбою Exchange Virtual Server. Нам необходим, по крайней мере, 10 Мбайтный блок непрерывной виртуальной памяти для того, чтобы этот EVS успешно переходил online на другой узел. Если другой узел не может обеспечить такой непрерывный участок памяти (возможно, что он уже испытывает фрагментацию виртуальной памяти), то EVS не перейдет в online и останется в состоянии ошибки.

Множество EVS на одиночном узле — это сценарий, который не может случиться в двух-узловом A/P кластере, следовательно, этот момент отображает одну потенциальную возможность аварии и проблем с производительностью.

3. Самое быстрое время восстановление

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

Помните, вы хотите высокую надежность? Можете вы реально позволить себе эти дополнительные минуты?

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

4. Максимальное количество одновременных соединений

В конфигурации A/A есть предел в 1900 одновременных MAPI соединений для каждого физического узла, при условии, что оба Exchange virtual servers (EVS — виртуальные сервера Exchange) не выполняются на одном узле. Помните, что каждый пользователь может иметь более одного соединения, так что количество почтовых ящиков не всегда является точной мерой для этого ограничения.

Если один узел кластера недоступен и если оба EVS расположены online на одном узле, то предел масштабирования остается 3800 соединений для этих двух EVS. В соответствие с Microsoft (Q815180), это предел масштабирования существует для гарантирования того, что восстановление в узле, который уже выполняет экземпляр Exchange, будет успешным. Это ограничение не применяется, когда нет больше узлов для восстановления, что является случаем A/P конфигурации.

5. Загрузка ЦПУ должна быть менее 40%

Примерное использование ЦПУ для каждого узла не должно превосходить 40%. Порог высокого использования процессора — около 80%, поэтому, если два экземпляра Exchange выполняются на одном и том же узле, они не должны достигать этого значения или же ЦПУ станет для вас узким местом.

6. Exchange 2003 ограничен четырьмя группами хранения на сервер

Хотя это ограничение не специфично для конфигурации A/A, есть отдельные конфигурации, где оно имеет большее влияние. Это ограничение является физическим и применяется к каждому узлу кластера, в основном потому, что выполняться может только один процесс хранения. Даже одиночный сервер не может иметь более четырех групп хранения, смонтированных и активных одновременно. Не важно, сколько виртуальных серверов Exchange будут восстанавливаться на одиночном узле, процесс store.exe может поддерживать не более четырех групп хранения.

Exchange Virtual Server (Виртуальный Сервер Exchange) Состояние Имена группы хранения
Узел 1 EVS1 Активное Группа хранения 1, группа хранения 2
Узел 2 EVS2 Активное Группа хранения 1, группа хранения 2, группа хранения 3, группа хранения 4

Таблица 1 — Двухузловой active/active Exchange 2003 кластер со слишком большим количеством групп хранения

В Таблице 1, кластер Exchange включает 6 групп хранения. Если EVS2 на узле 2 переключится на узел 1, то будут лишние 2 группы хранения сверх 4-группового ограничения на одиночном узле кластера. В результате EVS2 не станет online на узле 1, а будет пытаться вернуться на узел 2, если этот узел все еще будет доступен.

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

7. Стоимость администрирования

Стоимость вашего администрирования, конечно, возрастет. Это довольно очевидно, что два Виртуальных Сервера Exchange требуют приблизительно двойного времени на управление, чем только один. Консолидация стало модным словом, а тенденция идет на уменьшение количества продуктивных серверов, так что остается только следовать остальному IT миру.

Противоречия вымыслов

Далее, я попытаюсь вскрыть противоречия некоторых мифов и заблуждений вокруг концепции active/active кластеризации Exchange:

Лучшая производительность: некоторые люди заявляют, что распределение нагрузки между двумя узлами даст результат в лучшей производительности. Прирост производительности является производной от увеличения дисковых I/O, так как вы будете использовать 2 HBA (адаптера главной шины), и больше памяти, потому что вы имеете два процесса сохранения, выполняемых на раздельных узлах. На уровне ЦПУ выигрыша нет, так как A/A требует использования процессора не более 40%. Хорошо, как я писал ранее, ваша цель — это высокая надежность, но не производительность. Если вы определили размер ваших серверов корректно, то я действительно сомневаюсь, чтобы ваши пользователи заметили какое-либо улучшение. Но я держу пари, что они обязательно заметят большее время восстановления!

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

Заключение

Хотя active/active кластеры и поддерживаются, предпочтительной и рекомендованной конфигурацией для кластера Exchange Server является active/passive конфигурация. И точка!

Если после прочтения этой статьи вы все еще не согласны с этим, то по крайней мере рассмотрите использование A/A/P вместо A/A. Или заново обдумайте вашу потребность в высокой надежности, основываясь на вашем доступном бюджете. Как я уже говорил, надежность сервера довольно высока в наше время, поэтому может быть вы можете добиться своей цели использованием только одного сервера и следуя наилучшим правилам эксплуатации.

Рисунок 2: A/A/P Exchange кластер




Рейтинг:  
1.0 (голосов 1)  
 1   2   3   4   5    

Автор: Руи Силва (Rui J.M. Silva)
Руи Силва (Rui J. Silva) является Старшим Консультантом, работая в основном с Microsoft Technologies at ParaRede, компанией-Золотым Партнером Microsoft в Португалии. Он является сертифицированным MCDBA/MCSA/MCSE:Messaging и признан в качестве Microsoft MVP для Exchange Server, благодаря его вкладу в некоторые технические форумы. Руи тратит немного своего свободного времени на обновление Exchange выделенных блогов http://msmvps.com/ehlo (на английском) и http://ehlo.blogspot.com/ (на португальском).
Эта статья переведена и опубликована с разрешения http://www.msexchange.org

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.





Работает на «Битрикс: Управление сайтом»
Работает на «Битрикс:
 Управление сайтом»
© MSExchange.ru, 2005-2010