Настройка размеров ваших почтовых серверов IBM Lotus Domino

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

Уровень сложности: средний

Энди Нолет, инженер-разработчик программного обеспечения, IBM
Барбара Филиппи, IT-специалист, IBM
Майк Войтон, IT-специалист, IBM

13.12.2006

Вы получите практическую информацию по настройке размеров, помогающую спланировать почтовую среду Lotus Domino. Увидите, какие из факторов более всего влияют на выбор размеров, узнаете, как запланировать рост, выясните, какую информацию можно получить из базы данных Statrep.nsf. Исследование проблемы показывает, как использовать то, что вы узнали из вашей среды Domino.

Только что вы закончили с определением требований к размерам ваших серверов разделов IBM Lotus Domino (DPAR) на новой аппаратной платформе, на которой вы будете проводить инсталляцию, объединение или миграцию. Если вы перенесётесь немного в будущее, то заметите, что серверы разделов DPAR потребляют ресурсов процессора больше, чем предполагала ваша настройка размеров. Как вы планируете вместить остальных ваших пользователей в ваши новые сервера разделов DPAR? Почему они оказались недостаточной величины?

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

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

• посмотрите, как вы могли бы сегодня планировать размеры
• повторите факторы, влияющие на расчёт размеров
• узнаете, как собрать данные от существующих серверов разделов, чтобы облегчить расчёты потребления ресурсов процессора вашим новым сервером DPAR.
• повторите исследование проблемы планирования размеров и рассмотрите пример

"Как же я до этого дошёл?"

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

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

Потребители стремятся использовать счётчик транзакций Domino (server.trans.total) как способ измерения нагрузки, проходящей через их серверы DPAR. Однако, счётчик транзакций Domino (его значения, которые сообщает вам сервер Domino) не является точным показателем нагрузки, проходящей через ваши серверы. Скорее это показатель трафика NRPC между вашими DPAR и клиентами Lotus Notes или другими серверами Domino DPAR. Обновление релиза Notes/Domino (на серверной либо на клиентской стороне) может изменить счётчики транзакций при одних и тех же нагрузках.

Кроме того, изменения в других запущенных задачах Domino (репликация, AdminP, индексация и т.д.) также влияют на счётчики транзакций, не смотря на то, что ваши пользователи выполняют одни и те же действия. Наконец, клиенты, не использующие протокол NRPC, такие как HTTP, IMAP и POP3, могут показывать основательное изменение в потреблении ресурсов и при этом маленькое изменение в счётчиках транзакций. На самом деле не существует прямой зависимости между счётчиками транзакций в ваших серверах DPAR и потреблением ресурсов процессора. Для детального анализа этого факта обратитесь к разделу "Измерение в промышленном сервере DPAR" в статье "Lotus Domino 7 на IBM zSeries" на developerWorks, в которой сервер DPAR показывал один и тот же уровень транзакций спустя несколько месяцев, не смотря на то, что количество пользователей на нём увеличилось втрое!

Важно, чтобы вы не только знали, сколько пользователей (зарегистрированных, подключенных, активных за последние 15 минут) находится на ваших серверах DPAR, но чтобы вы также понимали, какие нагрузки они создают для ваших серверов DPAR. С целью настройки размеров, специалисты IBM по планированию загрузки обычно подразделяют почтовых пользователей на четыре различные категории, основанные на характеристиках нагрузки: лёгкие, средние, тяжёлые и мощные пользователи. Поскольку каждая категория имеет свой профиль потребления ресурсов процессора, вы можете легко ошибиться в расчёте количества ресурсов, необходимых для поддержания вашего сообщества пользователей, если вы не понимаете, к какой категории относятся ваши пользователи или какой у вас набор категорий.

В начало

Факторы, влияющие на настройку размеров

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

Агенты

Разрешение исполнения на ваших серверах DPAR агентов, написанных пользователями, равноценно предоставлению карт-бланша вашим пользователям на потребление любого количества ресурсов процессоров ваших серверов. Поскольку вы не имеете представления о том, что могут делать эти агенты, как часто они будут запускаться, или сколько пользователей будет их запускать, то нет возможности предположить, какие ресурсы им понадобятся. Агенты обычно используются в режиме разделения между многими пользователями одной организации и быстро распространяются, особенно, если у них есть какая-либо полезная функция; они могут переходить от одного человека к двум, к четырём, к восьми, к 16 и т.д. очень быстро.

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

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

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

Размер и скорости почты

Средний размер вашего почтового файла влияет на то, сколько ресурсов требуется серверам DPAR для поддержания всех ваших пользователей. Чем больше средний размер почты, тем больших ресурсов это требует от ваших серверов DPAR для обработки заданий. Задание Маршрутизатор использует большую часть ресурсов для доставки этих сообщений на другие серверы, а задание Сервер/HTTP использует большую часть ресурсов для доставки этих сообщений вашим клиентам. Пользователи, отправляющие большие почтовые сообщения или сообщения с большими вложениями более дороги в обслуживании, чем такое же количество, но отправляющих маленькие сообщения. Очевидно, чем больше сообщений отправляет сообщество пользователей, тем больших ресурсов требуется на их поддержку.

Размеры папки Входящие и базы данных

Размер почтовых файлов ваших пользователей также влияет на количество ресурсов, необходимых для поддержки сообщества пользователей. Статья на developerWorks "Лучшие методы работы с большими почтовыми файлами в Lotus Notes," обсуждает влияние размеров ваших почтовых файлов, количество документов в представлении папки Входящих и ресурсов, необходимых для поддержки вашего сообщества пользователей. Статья ясно показывает, что и размер вашей базы данных и число сообщений во Входящих являются критическими факторами в определении объёма ресурсов, необходимых для поддержания ваших пользователей, а также тот факт, что наличие большого числа сообщений во Входящих обходится дороже, чем наличие большого почтового файла.

Кластеризация и репликация

Если вы настраиваете кластеризацию и/или репликацию между вашими серверами DPAR, это влияет на объём ресурсов, необходимый для поддержания ваших пользователей. Тогда как кластеризация имеет вполне предсказуемые накладные расходы (основанные на размере почтового тома, так как это событийно управляемый процесс), репликация может создавать непредсказуемое влияние на требования по поддержанию ваших пользователей. При кластеризации только базы данных, в которые вносятся изменения, выдвигаются или реплицируются. Однако если вы используете репликацию по графику, все базы данных, предназначенные для репликации, будут реплицированы, не обращая внимания на то, были в них изменения или нет (включая открытие баз данных и поиск любых различий). Также чем меньше у вас интервал между репликациями, тем выше влияние на ресурсы ваших серверов DPAR, так как циклы процессора будут использоваться более часто для выяснения того, что реплицировать ничего не надо.

Репликация по графику, тем не менее, является рекомендуемой, даже когда вы используете кластеры. Это позволяет серверам DPAR изредка синхронизировать базы данных на каждой стороне кластера и создаёт уверенность, что все они идентичны. Вы также можете использовать документ Program для начала репликации при запуске сервера DPAR, что обеспечит вам событийно управляемую репликацию в случае рестарта DPAR, а не планирование её на каждый час или около на всякий случай. Хитрость заключается в том, чтобы при кластеризации реплицировать данные всего несколько раз в день.

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

Полнотекстовая индексация

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

Ведение протоколов транзакций

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

Другие факторы

Вы также должны смотреть на любую другую функциональную возможность Domino, функцию-дополнение (add-in) или на продукт третьей стороны, который может влиять на требования к ресурсам. Например, обратите внимание на сканирование вирусов, резервное копирование и восстановление, использование RIM/Blackberry, единичный шаблон, отслеживание сообщений, сетевую компрессию и написанные заказчиком приложения, которые обращаются к почте. Все эти действия в разной степени влияют на ресурс процессора, необходимый для поддержания вашего сообщества пользователей.

В начало

Как осуществляется администрирование на ваших серверах

Поскольку вышеприведённый список скорее включает отдельные функциональные возможности, функции и характеристики рабочей нагрузки, то способ, которым вы конфигурируете и управляете вашими серверами DPAR, также может влиять на загрузку процессора и на ваши требования к настройке размеров серверов DPAR. Например, если вы разрешаете выполнение репликации AdminP или Domino Directory на ваших серверах DPAR во время основной рабочей смены, то вы должны планировать циклы, требуемые для поддержки этих возможностей в дополнение к вашей рабочей нагрузке, создаваемой пользователями. Хотя репликация вашего каталога не может быть устранена во время основной смены, вы можете контролировать частоту, с которой она происходит. Очевидно, что чем чаще вы продвигаете изменения в Domino Directory к вашим серверам DPAR, тем выше влияние на ресурсы.

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

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

В начало

Типы клиентов

Тип используемого вашими пользователями клиента также влияет на требования к процессору для поддержания этого сообщества пользователей, но, поскольку стоимость клиента изменяется с релизами Lotus Domino, здесь невозможно обеспечить точное значение стоимости клиента.

К примеру, допустим, что NRPC клиент требует 100 единиц процессора в текущем релизе, а клиент X требует 200 единиц, что означает соотношение 2:1. Если в будущем релизе вы обнаружите 30% улучшение в NRPC и 15 процентное в клиенте X, то соотношение станет 2,45:1. Это не означает, что клиент Х стал хуже в новом релизе (он стал на 15% лучше). Однако при сравнении со стоимостью NRPC клиента в новом релизе клиент X потребляет ресурсов пропорционально больше, чем раньше. Если мы поменяем процент улучшений так, что теперь NRPC будет лучше на 15%, а клиент X – лучше на 30%, то новое соотношение составит 1,65:1.

Кроме того, меняться может не только стоимость каждого клиента относительно NRPC клиента, но и каждая платформа также может демонстрировать отличия. Например, в релизе 7 Linux на базе Intel демонстрировал огромное усовершенствование для NRPC клиентов по сравнению с релизом 6.x, тогда как Linux на базе System Z этого не делал. Это произошло из-за того, что основные изменения в масштабировании для Linux были ранее разработаны и помещены в Linux для System Z в релиз 6.5, потому эти огромные изменения не отразились в цифрах 7-го релиза. Это происходит для всех платформ по мере разработки улучшения и переносится обратно в код ядра и другие платформы, где возможно. Таким образом, с колебаниями среди улучшений в различных клиентах, поддерживаемых на различных платформах Lotus Domino, надо считаться.

Можно ожидать, что пользователи HTTP будут забирать значительно больше циклов процессора на сервере DPAR, чем клиент NRPC. А точнее, до 6 раз больше, чем пользователь NRPC, в зависимости от того, используете ли вы Web-доступ Lotus Domino или Web-почту, потому что обработка, которая осуществлялась клиентом Notes, теперь вытесняется на сервер для выполнения. Вместе с клиентом Notes сервер может передавать данные и позволяет клиенту Notes форматировать и представлять результаты. Тем не менее, вместе с клиентом HTTP сервер также должен выполнять большую часть этой работы или даже полностью осуществлять форматирование и представление данных.

Пользователи POP3 могут потреблять приблизительно на 20% меньше процессора, чем клиент NRPC. По умолчанию POP3 - это инициированный клиентом протокол. Почта скачивается из сервера к клиенту, удаляется из сервера, а затем обрабатывается и используется на клиенте. Тем не менее, вы можете настроить POP3 так, чтобы почта оставлялась на сервере, и запускать его как инициируемый сервером протокол, таким образом, влияя на стоимость использования клиентов POP3 с вашими серверами DPAR.

Пользователи IMAP могут потреблять приблизительно на 60% больше процессора, чем клиент NRPC. По умолчанию IMAP - это протокол, инициируемый сервером. Почта остаётся на сервере и клиент должен непрерывно общаться с сервером, в то время как пользователи перемещаются по почте. Хотя некоторые клиенты IMAP могут быть настроены так, чтобы скачивать почту с сервера и работать с ней на клиенте, вы должны понимать, какие возможности/функции вы разрешаете и их потенциальное влияние.

В начало

Что делают ваши пользователи

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

Как упоминалось ранее, пользователей можно поделить на четыре категории: лёгкие, средние, тяжёлые и мощные. Как вы могли бы ожидать, количество ресурсов процессора для поддержания 1000 лёгких пользователей гораздо меньше, чем количество, необходимое для поддержания 1000 тяжёлых пользователей. Ниже определяется каждый тип пользователя с учётом настройки размеров, как это используется командой Lotus Domino для zSeries и сопровождается кратким изложением в Таблице 1.

Лёгкие пользователи

Лёгкие пользователи используют электронную почту только без функции планирования календаря. Изредка они могут получать оповещения о назначении встречи, но сами никогда не планируют встреч. Они никогда не отправляют/не получают вложения в письмах, и размеры их сообщений составляют 10 KB или меньше. Они отправляют или получают не больше 10 сообщений в день (включая сообщения из Internet), равномерно распределённых в течение дня. Почтовые файлы лёгких пользователей не превышают 50 MB. Пользователи, начинающие как "лёгкие", быстро осваивают продукт и переходят в категорию средних пользователей. Поэтому для правильной настройки размеров вы не должны переоценивать количество лёгких пользователей.

Средние пользователи

Средние пользователи используют электронную почту в месте с небольшим (одна или меньше встреч в день) использованием функциональности календаря и планирования (C&S). Они изредка отправляют/получают почту с небольшими вложениями или графикой. Их средний размер сообщений – 25 KB, при этом большая часть меньше 100 KB, и они отправляют/получают от 10 до 25 сообщений в день. Размеры их почтовых файлов колеблются от 50 до 200 MB. Большая часть пользователей приходится на эту категорию. Если вы не уверены в том, как работают ваши пользователи, используйте эту категорию пользовательской активности.

Тяжёлые пользователи

Тяжёлые пользователи больше эксплуатируют электронную почту и функционал C&S (5 или более назначений встречи), чем средние пользователи. Размеры их сообщений больше (в среднем 50 KB), и большинство почтовых сообщений не превышает 500 KB. Тяжёлые пользователи отправляют/получают 26 – 40 сообщений в день, и размеры их почтовых файлов – более 200 MB.

Мощные пользователи

Мощные пользователи используют Lotus Notes/Domino для функций основных рабочих функций. Мощный пользователь может быть административным помощником, который управляет несколькими календарями и часто использует поиск свободного времени для планирования встреч, или техническим экспертом, который интенсивно использует почту, C&S и другие возможности Lotus Domino, такие как полнотекстовая индексация/поиск, почтовые агенты и комплексные правила. Средний размер сообщений для мощного пользователя равен 75 KB, а типичный размер сообщений – 100 KB или более. Мощные пользователи получают 10 или более назначений встреч в неделю, отправляют/получают более чем 40 сообщений в день, а размеры их почтовых файлов превышают 200 MB. Вообще говоря, относительно мало пользователей в вашем сообществе могут подпадать под эту категорию.

Таблица 1. Краткий обзор определений категорий пользователей

В дополнение к этой классификации вам также необходимо понимать, какая рабочая нагрузка, включая использование репликации локальной почты и каталог директорий, может быть перенесена на клиента Notes. При помощи использования локального почтового файла с клиентом Notes, устраняется большая часть трафика между клиентом и сервером DPAR, потому что клиент перемещается по локальному почтовому файлу для осуществления большинства своих действий. За счёт использования каталога директорий на клиенте, вы также можете перенести поиски в Domino Directory (директория Domino), которые происходят при обращении к почте. Вместо того чтобы содержимое буферов чтения проходило через сеть к вашим серверам DPAR, вы можете направлять его в каталог директорий, доступный локально на клиенте Notes.

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

Может быть очень непросто разделить ваших пользователей на 4 ранее упомянутые категории, возможно, легче классифицировать их по роду занятий (завод, служащий, специалист по информационным технологиям, студент, преподаватель, кассир, биржевой брокер и т.д.). Затем вы можете отнести каждый род занятий к одной из категорий пользователей, что даст вам общее представление о распределении пользователей и о предполагаемой нагрузке. Вы можете уточнять определения по мере того, как возрастает ваше понимание.

В начало

Рост

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

В одном случае у предприятия наблюдался 5% ежемесячный комплексный рост потребления процессора на серверах DPAR, приводя к почти 80% ежегодного роста требований сервера. Не было никаких квот или ограничений на размер пользовательских почтовых ящиков, никаких ограничений на личные агенты или ограничений на полнотекстовое индексирование или поиск. Более того, к старой почте не применялось никакой стратегии архивирования или управления, поэтому пользователи хранили всё в папке Входящие.

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

Максимальная нагрузка в сравнении со средней нагрузкой

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

Убедитесь, что понимаете, о чём говорят ваши статистические данные. Рассматриваете ли вы полный 24-часовой интервал или интервал основной смены? Просто меняя образец представления ваших данных, вы можете значительно изменить значения в ваших отчётах. Например, сервер может иметь среднюю нагрузку процессора 60% в течение всего дня. Хотя, рассматривая одни и те же данные, но, фильтруя их по максимальной нагрузке в течение основной смены, вы можете увидеть среднее потребление на уровне 85% с отдельными пиками, достигающими 95 – 100%. Хотя значение, равное 60%, верно для полного 24-часового периода, оно не является точным представлением действительной максимальной рабочей нагрузки. Если вы используете это значение для планирования нового сервера, то вам очень быстро будет не хватать мощности, когда появятся скачки до 95-100%.

То же понимание надо применять, когда вы просматриваете вашу статистику Domino, многая из которой является кумулятивной по своей природе. Вы получаете эти данные либо из команды показа статистики, либо, просматривая базу данных Statrep.nsf, имея в виду, что значение постоянно увеличивается с момента, когда сервер был впервые запущен или когда значение было последний раз сброшено. Если вы не собираете регулярно эти данные, а глядите на них только через определённые интервалы, вы можете не только пропустить, что происходит на ваших серверах DPAR, но также не узнаете, когда и сколь часто это происходит.

Когда ваши данные собраны

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

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

Нагрузка, создаваемая приложением, в сравнении с почтовой нагрузкой

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

Например, новый релиз Lotus Domino может иметь улучшенную на 25% производительность и использование ресурсов процессора. Это может позволить вам объединить два сервера DPAR в один на новой аппаратной платформе, которую вы планируете приобрести. Однако, если приложение написано неэффективно, или Lotus Domino сконфигурирован некорректно, так, что происходит какая-нибудь блокировка семафора (или другой ограничивающий фактор), то вы можете никогда не достигнуть полного использования процессора в рамках одного сервера DPAR до появления узкого места.

В начало

Мониторинг ваших серверов

Объём информации, которую необходимо учитывать при настройке размеров серверов, может очень быстро задавить вас, но важно помнить, что Lotus Domino может предоставить вам большинство этих данных. Как минимум, вы должны последовательно собирать данные мониторинга на ваших серверах DPAR, чтобы понять законы их роста и определить, какое влияние оказывают на них новые возможности и функции. Это может помочь вам понять текущее использование, а также понять, почему вы, возможно, используете больше ресурсов, чем предполагали.

Информация об элементах, перечисленных ранее в разделе "Факторы, влияющие на вашу настройку размеров", может быть обнаружена в вашей базе данных Statrep.nsf, если вы включили сбор статистических данных. По умолчанию, в этой базе данных сохраняются лишь События (Events); статистическая информация вашего сервера DPAR не сохраняется там, пока вы не включите задачу Collect (Сбор). Вы можете также настроить один сервер DPAR на сбор статистической информации с множества серверов DPAR, чтобы иметь единую консолидированную базу данных Statrep.nsf вместо многочисленных. Вам нет необходимости включать задачу Collect на всех серверах DPAR, а только на тех, которые собирают для вас информацию.

На рисунке 1 показан пример базы данных Statrep.nsf со статистическими данными в Lotus Domino 7.

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

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

В начало

Анализ данных из Statrep.nsf

Давайте теперь обсудим несколько диаграмм, основанных на данных, взятых из базы данных Statrep.nsf на промышленном сервере DPAR внутри IBM. Эти диаграммы представляют данные в нескольких различных разрезах, а именно:

• Интервал: Все значения отображаются по принципу 7х24 часа
• Смена: Отображаются все значения, которые укладываются в период основной рабочей смены, определяемой как с Понедельника по Пятницу с 8:00 до 16:00
• Ежедневно: Одна точка за каждый день. Точки для каждого дня представляют полный 24-часовой вид этого дня; хотя, в зависимости от типа данных, они могут суммироваться, может браться максимум, минимум или среднее значение.
• Ежедневно за смену: Одна точка для каждого дня. Точка для каждого дня представляет вид для основной рабочей смены за этот день. Также, в зависимости от типа данных, они могут суммироваться, может браться максимум, минимум или среднее значение.

Рисунок 4 показывает количество пользователей, подключенных по NRPC (server.user) и количество активных NRPC-пользователей за 15 минут (server.users.active15) для данного сервера DPAR.

Определив, количество активных NRPC-пользователей за 15 минут в период вашей пиковой нагрузки, вы сможете сравнить его с размером зарегистрированного сообщества, чтобы определить, какой процент ваших пользователей является активным на сервере DPAR

Для получения процента активных пользователей рекомендуется использовать NRPC-счётчики активности за 15 минут (server.users.active15), а не счётчики подключенных пользователей (server.user). На счётчики подключенных пользователей оказывает влияние значение тайм-аута серверной сессии (server-session-timeout) сервера DPAR в Notes.ini, означая, что одна и та же нагрузка может приводить к двум различным количествам пользователей, подключенных по NRPC, в зависимости от значения тайм-аута сессии на сервере DPAR. Счётчик активных за 15 минут пользователей не изменяется, но напрямую зависит от активности ваших пользователей.

И хотя вы можете получить кое-что из статистики в базе данных Statrep.nsf, такой, например, как количество пользователей, непосредственно из каждого документа, другая статистика должна выводиться путём сравнения различий между двумя интервалами.

Хотя 21 миллион транзакций на рисунке 2 выглядят как большое количество, помните, что это итог, накопленный с момента запуска сервера DPAR или с момента принудительного сброса этой статистики. Если этот сервер проработал один или два дня, то это большое количество транзакций; хотя, если сервер проработал месяц, то это количество не обязательно будет большим. Путём сравнения различных документов в Statrep.nsf вы можете выстроить поинтервальную историю того, как эта статистика накапливалась в процессе работы сервера DPAR.

Рисунок 5 показывает пример интервального представления количества транзакций Domino за трёхнедельный период для данного сервера DPAR.

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

Как упоминалось ранее, понимание нагрузок вашего сервера DPAR является ключом к правильной настройке размеров. В дополнение к пользователям, вы можете рассматривать любые данные в базе данных Statrep.nsf чтобы увидеть, что дают различные возможности Lotus Domino. Например, рисунок 7 показывает количество почтовых сообщений, доставленных локально на данном сервере DPAR, в разрезе их размеров за период в несколько недель во время основной рабочей смены.

На рисунке 7 вы можете увидеть, что имели место большие выбросы в количестве сообщений размером от 1 до 10 КБ (голубая линия), но, что ещё интереснее, – это выбросы в диапазоне 100 КБ и более (чёрная, розовая и бирюзовая линии). Подробности про большие размеры сообщений можно увидеть на эт3ой же диаграмме, изображенной на второй оси Y (см. легенду графика). Несмотря на то, что эти объёмы намного ниже зелёной линии, размер сообщения может вызывать очень большой выброс в потреблении ресурсов процессора на этом сервере DPAR. Если вы отразите эту информацию на ежедневной диаграмме (как на рисунке 6), вы можете увидеть как, спустя время, меняются размеры и количество сообщений, доставленных локально на этом сервере DPAR. Если это происходит, то это является признаком растущей нагрузки на ваш сервер DPAR, а вам в этом случае предстоит спланировать использование дополнительных ресурсов.

Рисунок 8 показывает пример объёма кластерной активности, происходящей в одном сервере DPAR.

Как и данные о доставке почты с рисунка 7 данный рисунок может чётко показать любые изменения в вашей кластерной активности на протяжении времени. Поняв, как изменяются ваши рабочие нагрузки и с какой скоростью, вы сможете лучше настроить ваши серверы DPAR на требования к размерам.

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

В дополнение к Statrep.nsf, обратите внимание на собственную статистическую информацию вашей платформы (а не только статистику платформы Domino), которая предоставляет дополнительную детальную информацию помимо представления Lotus Domino, показывающего как работают разные компоненты в составе вашего сервера DPAR. Рисунок 9 показывает взаимосвязь центрального процессора и 12 ведущих процессов в сервере DPAR, а также как эти задачи соотносятся с задачей Сервер. Задача Сервер была выбрана для этого примера потому, что этот сервер DPAR поддерживает клиенты Notes, а все запросы NRPC-клиентов также обрабатываются задачей Сервер. Соотнося эти задачи с задачей Сервер, вы можете понять, как потребляются ресурсы процессора различными заданиями, из которых состоит данный сервер DPAR.

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

Если бы этот график показал, что задача Agent Manager (Менеджер Агентов) потребляет больше циклов, чем задача Server (Сервер), тогда вы знали бы, что следует учитывать эти дополнительные ресурсы процессора при настройке размеров. (Известно, что имело место высокое потребление процессора задачами Agent Manager, AdminP, Update, Replica и другими задачами Domino). Понимая, что делают эти различные задачи, вы можете лучше понять, какие ресурсы требуются для поддержания вашего сообщества пользователей.

Например, в средней нижней части рисунка 9 вы можете увидеть, что задача Compact (бирюзовая линия) выполнялась во время основной смены. Хотя это единственный случай в данном образце, но для целей настройки размеров, вы должны определить, как часто эти задачи выполняются во время основной смены. График такого типа позволяет вам быстро профилировать использование вашего сервера DPAR и понимать соотношения между запущенными задачами. Большой скачок в задаче Router (Маршрутизатор) соответствует массовой отправке почты, другому примеру скачка рабочей нагрузки, который вы должны учитывать.

Для получения этого графика ресурсы процессора, использованные каждой задачей, были разделены на ресурсы, использованные задачей Server, для каждого интервала. Вы можете также легко выбрать задачу HTTP, IMAP или POP3 в качестве вашей основной задачи, если эти клиенты являются у вас основными. Для центрального сервера DPAR используйте задачу Router (Маршрутизатор) в качестве основной.

В начало

Исследование проблемы: настройка размеров для консолидации серверов

Исследуя эту проблему, давайте изучим возможность консолидации серверов, при которой есть существующий набор серверов DPAR Domino на некоем аппаратном обеспечении, которому не хватает мощности процессора. План заключается в том, чтобы объединить сообщество пользователей на новом наборе более мощного серверного аппаратного обеспечения. Некоторое количество серверов DPAR также должно быть консолидировано. Был сделан эксперимент, при котором приблизительно 10% от существующего сообщества пользователей Notes было перемещено на новый сервер DPAR с новой аппаратной платформой, для того чтобы оценить правильность настройки размеров.

После того, как намеченные 10% сообщества пользователей были перемещены на новый сервер DPAR, было установлено, что эти пользователи потребляли почти 50% от общего количества ресурсов процессора, отведённых для всего сообщества пользователей. Чтобы понять, что же произошло, со всех существующих, а также с вновь созданного сервера DPAR были собраны данные, которые потом сравнили.

Таблица 2 показывает результаты анализа этих данных. Вторая колонка показывает анализ нового консолидированного сервера DPAR, а третья колонка показывает анализ исходных серверов DPAR с остающимися на них 90% пользовательского населения. Поскольку исходные сервера DPAR работали на более старом релизе Lotus Domino, показатели активности пользователей за 15-минут на них были недоступны.

Таблица 2. Исследование проведённого анализа консолидации серверов

Как видите, активность пользователей на новом консолидированном сервере DPAR была гораздо выше, чем на исходных серверах DPAR. Сравнение рабочих нагрузок на этих двух серверах DPAR показано в колонке 4. Чтобы понять эту разницу в рабочих нагрузках, давайте проанализируем пользователей, которых переместили на экспериментальный сервер DPAR.

Во-первых, исходные серверы имели ограниченные ресурсы и процессора и диска. Администраторы Notes решили переместить пользователей с самыми большими базами данных на вновь консолидированный сервер DPAR, чтобы снять для себя проблемы с дисками. Однако, непреднамеренно они консолидировали мощных и тяжёлых пользователей со всей организации на вновь консолидированный сервер DPAR. Потребление ресурсов, необходимых для поддержания этой группы тяжёлых/мощных пользователей, было гораздо большим, чем необходимое для поддержания оставшейся части сообщества пользователей.

Другой признак этого феномена заключался в том, что новейшие/самые лёгкие пользователи были помещены на один из исходных серверов DPAR. Анализ этого единичного сервера DPAR можно увидеть в колонке 5. Сравнивая этот сервер с нашим вновь консолидированным сервером DPAR, вы можете увидеть, что разница результатов (колонка 6) была даже более показательной.

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

Ключевым моментом здесь является тот факт, что любая из этих групп пользователей (тяжёлые/мощные или лёгкие) по отдельности представляла бы неточную проекцию всего пользовательского сообщества. Вот почему два сервера DPAR с одинаковым количеством пользователей могут иметь совсем разное использование ресурсов, даже, несмотря на то, что у них одинаковое количество пользователей на одних и тех же клиентах.

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

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

Пример упражнения по настройке

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

ЗАМЕЧАНИЕ: Этот пример – всего лишь пояснение. Он не подразумевает, что эта настройка размеров применяется к определённому релизу Lotus Domino на определённой платформе.

Допустим, имеется 10000 зарегистрированных пользователей, и все они используют Lotus Notes в качестве клиента. 20% пользователей активны в течение 15-минутного интервала (классифицируемые как средние пользователи). Журнализация транзакций и сканирование вирусов включены. В этой начальной настройке размеров никакая другая дополнительная задача или продукт третей фирмы не запущены. Имея эту информацию, вы предполагаете, что вам нужно 97% однопроцессорного ядра для поддержания этого сообщества пользователей. Поскольку это не оставляет места для скачков рабочей нагрузки, вы будете более обеспечены, выделив второй процессор в виде двухпроцессорной машины с проектируемой нагрузкой в 50%.

Давайте увеличим уровень активных пользователей с 20 до 30% от числа зарегистрированных. Это, казалось бы, маленькое изменение в параллелизме на деле увеличивает общие требования по нагрузке на 50 %, приводя к проектируемому потреблению процессора, равному 76% на двухпоточном сервере или 52% на трёхпоточном сервере.

Теперь, если вы поменяете всех пользователей со средних на тяжёлых, это приведёт к проектируемому потреблению процессора, равному 77% на четырёхпоточном сервере или 62% на пятипоточном сервере. Затем, давайте добавим кластеризацию, так, что 100% всех пользователей будут обслуживаться кластером при отсутствии плановых назначенных репликаций. Это изменит проектируемое использование ресурсов процессора до 81% на пятипоточном сервере или до 68% на шестипоточном сервере. Затем, переместите 25 % ваших пользователей с Lotus Notes на HTTP/Lotus Domino Web Access. Это изменяет предполагаемое потребление процессора до 82% на восьмипоточном сервере или до 74% на девятипоточном сервере.

Этот простой пример демонстрирует, как меняется потребление ресурсов для тех же самых 10 000 пользователей за счёт простого изменения того, каких клиентов, рабочие нагрузки и дополнительные возможности выполняют пользователи. Вы прошли от однопоточного сервера до девятипоточного, чтобы поддержать одно и то же количество пользователей, внося некоторые ''простые'' изменения. Хотя это кажется довольно резким, такое изменение возможно на ваших серверах DPAR. По мере того, как активность ваших пользователей становится более комплексной и они становятся более опытными в отношении возможностей Lotus Domino, по мере того, как они переходят на другой протокол/клиент, или по мере того, как вы меняете способ управления/администрирования вашего сервера DPAR, потребление вами ресурсов изменяется.

В начало

Заключение

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

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

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

Ресурсы

• Оригинальная статья "Sizing your IBM Lotus Domino mail servers"
  
  
• Статья о Lotus на developerWorks "Lotus Domino 7 на IBM zSeries"
  
  
• Статья о Lotus на developerWorks "Лучшие методы работы с большими почтовыми файлами в Lotus Notes"
  
  
• Статья о Lotus на developerWorks "Lotus Domino 7 производительность в производстве на IBM на серверах pSeries"
  
  
• Статья о Lotus на developerWorks Россия"Новые функциональные возможности в Lotus Domino 7.0"
  
  
• Страничка developerWorks Производительность Lotus
  
  

• Загрузите пробную версию Lotus Domino 7 с сайта developerWorks.
  
  
• Загрузите пробную версию Lotus Notes 7 с сайта developerWorks.

• Примите участие в обсуждении материала на форуме.

Об авторах

		Энди Нолет (Andy Nolet) с середины 90-х годов решал с заказчиками вопросы, связанные с проблемами производительности серверов Notes. Перед тем, как присоединиться к группе по производительности Domino, Энди работал в службе поддержки Lotus.

		Барбара Филиппи (Barbara Filippi) является IT-консультантом в команде по Domino для zSeries в вашингтонском системном центре (Washington Systems Center). Она проработала в IBM 25 лет и участвовала в проекте Domino для zSeries с момента его появления. В основном она занимается вопросами инсталляции и администрирования Domino, расчётом мощности, анализом производительности, а также миграцией на zSeries с других платформ Domino.

		Майк Войтон (Mike Wojton) – IT-специалист расширенной технической поддержки IBM в вашингтонском системном центре. Его стаж в IBM – более двух десятилетий. Основное занятие – базы данных, приложения и анализ производительности. Последние несколько лет Майк посвятил Domino для zSeries.

Выскажите мнение об этой странице