Прогнозирование пропускной способности клиентов Exchange — проблема часовых поясов…

Дата публикации исходной статьи: среда, 20 июня 2012 г.

Обновление от 22.06.2012 — обновлена статья и прилагающиеся файлы для загрузки.

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

В чем же заключается проблема часовых поясов?

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

https://en.wikipedia.org/wiki/Time_zone

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

Например, если мы посмотрим на обычный рабочий день средней организации с 1 000 пользователей, мы, скорее всего, увидим два пика: один утром примерно в 10 часов, продолжающийся 2 часа, и затем пик после обеда примерно в 14 часов, продолжающийся 4 часа. На графике это выглядит следующим образом.

Теперь представим, что мы моделируем требования для пяти различных подразделений по всему миру, в каждом из которых работает по 1 000 пользователей, получающих доступ к общему ресурсу в Нью-Йорке. На этом этапе предположим, что общий ресурс — это балансировщик нагрузки для локального сервера Exchange 2010 (я подумал, что стоит взять локальный пример для разнообразия):

• Лондон (GMT) — 1 000 пользователей.
• Варшава (GMT+1) — 1 000 пользователей.
• Джакарта (GMT+7) — 1 000 пользователей.
• Редмонд (GMT-8) — 1 000 пользователей.
• Нью-Йорк (GMT-5) — 1 000 пользователей.

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

На графике видно, что каждое подразделение с 1 000 пользователей требует примерно 1,56 Мбит/с пропускной способности во время пиковой активности каждый день, и поэтому когда мы складываем результаты для учета всех пользователей, получающих доступ к балансировщику нагрузки в Нью-Йорке, мы получаем требование по пиковой нагрузке в 7,81 Мбит/с. Так мы делали раньше при планировании пропускной способности для распределенных пользователей — прогнозировали их пиковую нагрузку, затем объединяли данные в таблице и складывали.

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

Если мы учтем часовой пояс этих подразделений, график изменится значительно:

Этот график показывает, как рабочие нагрузки могут складываться в действительности, формируя совсем другой профиль использования, чем мы планировали раньше. Особенно интересно здесь то, что пиковая рабочая нагрузка теперь существенно ниже и составляет лишь 3,78 Мбит/с (исходный прогноз был 7,81 Мбит/с). Профиль использования также очень отличается от исходного прогноза.

Что нам делать с этой проблемой?

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

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

Делал ли кто-то такое объединение?

Простой ответ "да" — многие организации максимально объединяют рабочие нагрузки. Это требует от групп разработки планировать рабочие нагрузки на службы от распределенных пользователей, часто с разными профилями и находящихся в разных часовых поясах. Это особенно часто бывает в тех случаях, когда рабочая нагрузка перемещается в облако, так как Office 365 предоставляет только одно региональное клиентское расположение, поэтому глобальные организации, использующие Office 365, должны будут планировать доступ к службе большой части пользователей из разных регионов и часовых поясов, нередко через инфраструктуру общего пользования.

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

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

Использование новой функции часовых поясов

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

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

После заполнения листа входных данных мы переходим на лист Client Mix — здесь есть две новых области для настройки данных о часовых поясах.

Первая область — это Model Timezone, представляющая часовой пояс ресурса, для которого мы проводим планирование, т. е. сетевое подключение или балансировщик нагрузки. В предыдущем примере можно видеть, что я задал часовой пояс модели как GMT-5 для Нью-Йорка, где находится балансировщик нагрузки.

Затем идет новый столбец TimeZone — он представляет часовой пояс для каждого отдельного расположения по отношению к GMT (обратите внимание, что я англичанин, поэтому и указал GMT, но я могу переделать потом и в UTC, если много людей будет жаловаться).

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

Дополнительный бонус

Еще одна замечательная функция — в калькуляторе теперь имеется таблица, которую можно скопировать в Mailbox Role Calculator (калькулятор ролей почтовых ящиков), чтобы облегчить формирование прогнозов сетевой репликации для групп обеспечения доступности баз данных (DAG).

Если посмотреть в сетевом калькуляторе в область справа от прогнозного графика (лист Client Mix), там будет таблица, содержащая процент изменений на каждый час… и если скопировать это в буфер обмена…

И прокрутить вниз лист входных данных (Input) в Mailbox Server Role Calculator (калькуляторе роли сервера почтовых ящиков), там будет таблица конфигурации репликации журнала. Вставьте данные из сетевого калькулятора в эту таблицу.

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

Заключение

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

Направляйте свои отзывы, как положительные, так и отрицательные, по адресу netcalc "собака" microsoft.com. Мы с удовольствием читаем ваши комментарии.

Нил Джонсон (Neil Johnson)
Старший консультант подразделения MCS UK

Это локализованная публикация в блоге. Оригинал — Exchange Client Bandwidth Prediction – the time zone problem…