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

Балансировщики нагрузки используют относительно ограниченный набор алгоритмов и позволяют задавать протоколы, трафик которых должен распределяться по серверам. В книге Тео Шлосснейгла «Scalable Internet Architectures» приведена чрезвычайно полезная информация о балансировщиках нагрузки и их роли в веб-архитектурах.

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

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

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

Джереми Заводны (Jeremy Zawodny) в первом издании книги «High Performance MySQL» поведал историю о том, как в базах данных Yahoo! применялась балансировка нагрузки по схеме «минимальною количества подключений». Такая схема хорошо работает при распределении нагрузки на веб-серверах: она гарантирует, что трафик будет направлен на сервер, обслуживающий минимальное количество запросов. Но веб-запросы почти всегда имеют короткий жизненный цикл, и их результаты (в среднем) не имеют заметных различий по размеру и задержке. Однако для баз данных эта парадигма подходит плохо, потому что запросы могут значительно различаться по размерам и времени обработки, а результаты запросов могут иметь весьма значительные объемы. Заводны привел этот пример для того, чтобы: читатели усвоили важный урок — относительно небольшое количество подключений к базе данных вовсе не означает, что сервер выдержит дополнительную нагрузку.

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

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

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

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

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

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

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

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

Не вдаваясь в подробности, по одному внешнему виду графиков в левом столбце можно сказать, что произошло нечто необычное. На этих графиках представлена информация о нагрузке и процессах, выполняемых в кластерах, тогда как графики в правом столбце содержат сводные отчеты по использованию памяти в этих кластерах. Оси X всех графиков соответствуют одному периоду времени, поэтому мы сразу замечаем, что количество выполняемых процессов падает (особенно хорошо заметно в кластере WWW) одновременно с появлением пика в кластере GEO.

Кластер WWW — это серверы frontend flickr.com на базе Арасhе, а в кластере GEO объединены серверы, выполняющие географический поиск для таких функций, как географическая привязка фотографий (geotagging) Взглянув на одну эту веб-страницу, я смогу найти источник проблем (GEO) и область распространения ее последствий (все остальные кластеры). Оказывается, это событие произошло в тот момент, когда на одном из наших серверов кластера GEO затормозилась обработка некоторых запросов, в результате чего запросы от веб-серверов стали накапливаться. После перезапуска сервера GEO работа веб-серверов постепенно нормализовалась.

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

• В чем заключается суть сбоя?
• Когда произошел сбой?
• Что было причиной сбоя?

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

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

Таким образом, журналы упрощают выявление проблем. У многих баз данных имеется возможность регистрации в журнале запросов, продолжительность обработки которых превысила определенный промежуток времени; журнальные данные упрощают идентификацию и исправление таких медленных запросов. Почти все продукты, используемые в вашей работе, — почтовые серверы, распределители нагрузки, брандмауэры — способны вести журналы: либо напрямую, либо через механизм syslog в стиле Unix. Например, в Flickr подсчитывается количество ошибок веб-серверов и записей в журнале обращений за минуту и отображают эти метрики на графиках Ganglia. Затем инженеры приступают к интерпретация результатов измерений.

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

Задача агента — периодически собирать данные на конкретном компьютере и передавать их сводному серверу. Сервер сохраняет данные для каждого компьютера, за которым ведется наблюдение, в дальнейшем эти данные могут обрабатываться разными способами. Большинство сводных серверов использует для хранения информации ту или иную форму базы данных: особой популярностью пользуется формат RRD (Round-Robin Database).

Формат RRD и RRDTool

Вероятно, самой распространенной программой для хранения системных и сетевых данных (по крайней мере в LAMP) является RRDTool. Здесь я ограничусь кратким обзором, а учебные материалы вы можете найти на сайте RRDTool по адресу http://rrdtool.org.

Основной недостаток данных системного мониторинга — их объем данных много, и они постоянно прибавляются. Как ни парадоксально, приходится заниматься планированием мощностей для данных, собранных с целью планирования мощностей! Чтобы решить эту проблему программа RRDTool предполагает, что подробная информация нужна только для относительно свежих данных, а для старых данных допустимо некоторое снижение точности. По истечении максимального срока, определяемого пользователем (допустим, 1 год), данные уничтожаются. Такой подход снижает объем хранимых данных, но за это приходится расплачиваться потерей детализации с течением времени.

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

Ganglia

Диаграммы, приведенные далее, были сгенерированы в программе Ganglia (http://ganglia.info). Я выбрал именно эту интерфейсную оболочку для примеров и демонстрации полезных приемов мониторинга по нескольким причинам. Во-первых, Flickr в настоящее время использует Ganglia для проведения подобного мониторинга. Этот выбор объясняется теми же причинами, по которым она также может хорошо подойти и вам, функциональностью (Ganglia хорошо соответствует критериям, приведенным в начале раздела) и популярностью. Кроме того, программа Ganglia изначально разрабатывалась для сбора данных и управления решетчатыми структурами (grids) в кластерах НРС (High Performance Computing). Ganglia хорошо сочетается с инфраструктурой Flickr, так как архитектура сходна с НРС: back-end подсистема сегментирована по кластерам, каждый из которых играет свою роль.

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

SNMP

Протокол SNMP (Simple Network Management Protocol) входит в число распространенных механизмов сбора метрических данных для большинства моделей сетевого и серверного оборудования. SNMP можно рассматривать как стандартизированный протокол мониторинга и сбора метрических данных. Он поддерживается многими маршрутизаторами, коммутаторами и серверами. SNMP способен собирать и передавать множество разнообразных метрик, в том числе и редко используемых администраторами.

Так как сетевые и встроенные (embedded) устройства обычно являются закрытыми системами, для работы с ними не удастся использовать пользовательские приложения вроде агента сбора метрических данных gmond. Но поскольку поддержка SNMP уже давно стала стандартом для сетевых устройств, SNMP предоставляет простой механизм получения метрик от этих устройств без участия агента.

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

Несколько примеров таких программ:

• Cacti (http://cacti.net).
• Munin (http://munim.projects.linpro.no/).
• Ganglia (httр://gаnglia.info).
• Hyperic HQ (http://hyperic.com).

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

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

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

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

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

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

• регистрации и сохранения изменения данных во времени;
• построения нестандартных метрик;
• сравнения метрик, полученных из различных источников;
• импорта и экспорта метрик.

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

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