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

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

• Httperf (http://www.hpl.hp.com/research/linux/httperf/)
• Siege (http://www.joedog.org/JoeDog/Siege)

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

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

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

Другое ограничение точное представление отношений «клиент- сервер» присуще всем сценариям нагрузочного тестирования веб-ресурсов. При использовании Httperf или Siege вы сможете имитировать запросы от нескольких клиентов, но в действительности все запросы будут поступать от одного клиентского сервера, на котором выполняется сценарий. Одно из возможных решений основано на запуске сценариев на нескольких машинах. Программа Autobench (http://www.xenoclast.org/autobench/), написанная на Perl обертка для Httperf, обеспечивает возможность скоординированного выполнения сценария на нескольких хостах. Autobench также может собирать сводные результаты.

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

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

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

График сгенерирован на основе данных RRD для одного из вебсерверов Flickr в периоды ежедневных пиков и падений, отсортированных по возрастанию загрузки процессора. Он подтверждает, что загрузка процессора действительно прямо пропорциональна количеству активных процессов Apache, по крайней мере в диапазоне от 40 до 90 процентов загрузки процессора.

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

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

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

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

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

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

Реальный пример: сбор метрических данных для веб-сервера

В качестве примера рассмотрим метрики отдельного веб-сервера на базе Apache, собираемые с разной периодичностью (час, день, неделя). На рисунке представлены графики для всех трех частот сбора данных, на основе которых мы попытаемся определить периодичность пиковых нагрузок.

На почасовом графике никакие закономерности не наблюдаются, тогда как на ежедневном графике видно плавное снижение и подъем. В контексте планирования мощностей наибольший интерес представляет еженедельный график, на котором видно, что по понедельникам веб-сервер обрабатывает наибольший трафик. Как говорится, «это то самое место, начинаем копать».

Для начала следует сузить состав анализируемых аппаратных ресурсов. Чтобы сократить список, мы будем игнорировать ресурсы, работающие в рамках своих возможностей во время пиковых нагрузок. Использование памяти, дисковые операции ввода/вывода и сетевые ресурсы (не рассматриваемые сейчас) даже близко не подходят к своим ограничениям во время пиковых нагрузок. Исключив эти ресурсы из списка потенциальных «узких мест», мы получим достаточно важную информацию о мощности нашего веб-сервера. Остается процессорное время, которое, как можно предположить, и является критическим ресурсом. На рисунке показаны два графика загрузки процессора.

Из рисунка видно, что на пике (с объединением пользовательской и системной загрузки) процессор загружен лишь немногим более чем на 50%. Давайте сравним эти данные с фактической работой, выполняемой веб-сервером, и посмотрим, приводит ли загрузка процессора к видимым последствиям на прикладном уровне. На рисунке ниже, представлено количество активных процессов Apache для анализируемого нами времени.

Графики, приведенные выше, подтверждают то, что и так очевидно, — количество активных процессов Apache пропорционально загрузке процессора. Согласно самым свежим данным RRD, на 50,7 процентах загрузки процессора (45,20 пользовательская + 5,50 системная) задействовано 46 процессов Apache.

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

Журналы и резервные копии данных занимают весьма значительный объем дискового пространства, и выработка требований к ним порой оказывается непростым делом. И журналы, и резервные копии являются частью любых осмысленных процедур планирования непрерывности бизнеса (ВСР) и аварийного восстановления (DR), поэтому требования к ним следует учитывать наряду с базовыми бизнес-требованиями. План резервного копирования необходим всегда, но как долго следует хранить резервные копии? Неделю? Месяц? Вечно? Ответ на эти вопросы зависит от сайта, приложения и области деятельности.

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

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

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

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

• объем читаемых данных;
• объем записываемых данных;
• продолжительность ожидания процессором завершения чтения или записи.

Дисковые накопители — самые медленные устройства на сервере. В зависимости от характеристик нагрузки на сервер их метрики могут определять мощности всей серверной платформы. Существует несколько способов измерения нагрузки и пропускной способности дисков. Многие полезные инструменты сбора данных об использовании дисковых устройств вы найдете далее.

Независимо от того, используется ли RAID-массив в локальной подсистеме, сетевое устройство NAS (Network-Attached Storage) или какая-либо технология кластерного хранения данных, основные метрики остаются неизменными: потребление дискового пространства и потребление ресурсов дискового ввода/вывода. Потребление доступного дискового пространства и интенсивность обращения к нему не зависят от выбора аппаратного решения, но в любом случае отслеживать необходимо и то и другое.

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

Что же касается скорости потребления дискового пространства, главный вопрос формулируется так:

• Когда на диске кончится свободное пространство?

Реальный пример: отслеживание скорости потребления дискового пространства

На сайте Flickr для отправки и хранения фотографий расходуется огромный объем дискового пространства. Я использую этот простой случай как пример планирования скорости потребления.

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

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

Позднее вы увидите, почему были выбраны именно эти метрики, а пока нас интересует последний пункт: общее потребление дискового пространства по времени.

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

Следовательно, данные могут использоваться для прогнозирования того, когда возникнет необходимость в закупке нового оборудования. В таблице представлены данные о потреблении дискового пространства (только для фотографий) за двухнедельный период в 2005 году.

Таблица. Пример статистики ежедневного потребления дискового пространства

Данные в таблице были получены при помощи задания cron, запускающего сценарий для сохранения вывода стандартной команды Unix df. Затем данный объединяются и выводятся в управляющем приложении. (Flickr также собирает информацию с намного большей детализацией [минуты] с использованием Ganglia, но для текущего примера — этo несущественно.)

При отображении данных из таблицы на диаграмме ясно видны два обстоятельства. Из рисунка сразу видно, что 31/7 и 07/08 пользователи отправляли много фотографий. Стоит учесть, что 31 июля и 7 августа 2005 года — это воскресенья. И действительно, данные, собранные за продолжительный период, показывают, что по воскресеньям всегда наблюдается пик отправки фотографий. На диаграмме также проявляется другая общая закономерность: пятница — день недели с минимальным объемом потребления дискового пространства. Тенденции будут рассматриваться далее, а пока достаточно знать, что для их проявления данные должны собираться с соответствующей детализацией. На некоторых сайтах колебания метрик отображаются по часам (например, ленты новостей или информация о погоде), другие сайты используют месячные сводки (повышенный объем продаж перед Рождеством на сайтах розничной торговли).

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

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

• максимальную емкость носителя информации;
• скорость обращения к данным.

Традиционно в задачах управления веб-ресурсами основное внимание уделяли первому фактору — размеру стакана. Тем не менее многие крупные фирмы-поставщики оборудования формировали свои линейки продуктов с учетом обоих соображений. Чаще всего предлагается два варианта: большие, медленные и дешевые диски (обычно с интерфейсом ATA/SATA) и меньшие по размеру, быстрые и дорогие (технологии SCSI и SAS).

Несмотря на то, что хранение данных является достаточно развитой областью, в ней до сих пор появляется много новых (и возможно, революционных) технологий, о которых тоже необходимо знать. Твердотельные (solid-state) накопители и иерархические схемы хранения информации, в которых они используются, вскоре могут стать нормой — стоимость хранения данных продолжает падать, а физическая скорость ввода/вывода при работе с ними за последние годы остается неизменной.

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

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

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

Некоторые метрики, которые отслеживаются в Flickr.

• Переданные фотографии (ежедневная, накопительная )
• Переданные фотографии в час.
• Средний размер фотографии (ежедневная, накопительная )
• Время, потраченное на разделение фотографий по размерам (ежечасная).
• Регистрации пользователей (ежедневная, накопительная).
• Подписка на учетные записи «Pro» (ежедневная, накопительная).
• Количество фотографий, помеченных тегами (ежедневная, накопительная).
• Трафик API (количество используемых ключей API, количество запросов в секунду на один ключ).
• Количество уникальных тегов (ежедневная, накопительная).
• Количество фотографий с географической привязкой (ежедневная, накопительная).

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

Вычисление полной стоимости владения (ТСО, Total Cost of Ownership) будет неполным без информации о том, с какими затратами для бизнеса связаны эти системные и прикладные метрики,

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

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

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