Библиотека сайта rus-linux.net
Проект Graphite
Глава 7 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: Graphite,
глава из книги "The Architecture of Open Source Applications" том 1.
Автор: Chris Davis
Перевод: Н.Ромоданов
7.9. Кластеризация
Объединить несколько серверов Graphite так, чтобы они казались одной системой, с точки зрения пользователя не так уж и трудно, по крайней мере, при наивной реализации. Взаимодействие веб-приложения с пользователем в первую очередь состоит из двух операций: поиск метрик и выборка значений для точек данных (как правило, в виде графика). Операции поиска и выборки из веб-приложения спрятаны в библиотеке, которая абстрагирует их реализацию от остальной части кода, причем они также доступны через обработчики запросов HTTP запроса для того, чтобы их было проще вызывать дистанционно.
Операция поиска find ищет в локальной файловой системе whisper совпадение с образцом, заданным пользователем точно также, как общая файловая система ищет совпадение файлов, например, *.txt, с указанным расширением. Поскольку это древовидная структура, результат, возвращаемый операцией find, является коллекцией объектов Node (Узел), каждый из которых является производным подкласса Branch (Ветка) или Leaf (Лист) класса Node. Каталоги соответствуют узлам-веткам, а файлы whisper - узлам-листьям. Такой уровень абстракции упрощает поддержку хранилищ данных, расположенных ниже, в том числе файлов RRD [5] и заархивированных файлов \code{whisper}.
В интерфейсе leaf определяется метод выборки fetch, реализация которого зависит от типа листа. В случае, если это файл whisper, он является просто тонкой оболочкой вокруг собственной функции fetch библиотеки whisper. Когда была добавлена поддержка кластеризации, функция find была расширена так, чтобы она могла выполнять дистанционные вызовы функции find через протокол HTTP к другим серверам Graphite, указанным в конфигурации веб-приложения. Данные об узлах, содержащиеся в результатах этих HTTP-запросов, предоставляются в виде объектов RemoteNode, которые пригодны для использования с интерфейсами Node, Branch и Leaf. Это делает кластеризацию прозрачной для остальной части кода веб-приложения. Метод fetch для удалённых узлов-листьев выполняется как еще один запрос HTTP для получения значений точек данных с сервера Graphite, где расположен этот узел.
Все эти вызовы выполняются между веб-приложениями точно также, как они выполняются клиентом, за исключением лишь одного параметра, указывающего, что операция должна выполняться локально, а не перераспределяться по кластеру. Когда в веб-приложение приходит запрос на визуализацию графика, оно выполняет операцию find с тем, чтобы найти запрашиваемые метрики, и вызывает операцию fetch для каждой из них для того, чтобы выбрать значения их точек данных. Это работает во всех случаях: когда данные находятся на локальном сервере, на удалённом сервере, или на локальном и удаленном серверах одновременно. Если сервер выходит из строя, то сравнительно быстро возникает состояние таймаута для дистанционных вызовов и сервер помечается как необслуживаемый на короткий промежуток времени, в течение которого к нему не будет запросов. С точки зрения пользователя, все данные, которые были на потерянном сервере, будут отсутствовать на их графиках, если, конечно, эти данные не были продублированы на другом сервере в кластере.
7.9.1. Краткий анализ эффективности кластеризации
Самой дорогостоящей частью запроса графика является отрисовка графика. Каждая отрисовка выполняется одним сервером, поэтому добавление большего количества серверов эффективно увеличивает производительность отрисовки графиков. Однако тот факт, что многие запросы перераспределяют вызовы find на любой другой сервер в кластере, означает, что наша схема кластеризации используется в перераспределении нагрузки, касающейся клиентских запросов, а не рассредоточения нагрузок. Однако, то, чего мы добились на данный момент, является эффективным способом распределения серверных нагрузок, поскольку каждый экземпляр carbon работает независимо от других. Это хороший первый шаг, поскольку в большинстве случаев серверная сторона становится узким местом задолго до того, как это происходит с клиентскими обращениями, но очевидно, что с помощью этого подхода не удастся выполнить горизонтальное масштабирование клиентских обращений.
Что сделать масштабирование клиентских обращений более эффективным, необходимо сократить количество дистанционных запросов find, делаемых веб-приложением. Снова простейшим решением является кеширование. Точно также, как memcached уже используется для кеширования значений точек данных и для нарисованных графиков, этот же самый подход можно использовать для кеширования результатов запросов find. Поскольку маловероятно, что местоположение метрик меняется часто, их можно хранить в кэше достаточно долго. Однако если настройка таймаута кеширования результатов операций find окажется слишком длительной, то новые метрики, которые добавлены в иерархию, могут не сразу стать доступными для пользователя.
7.9.2. Хранение метрик в кластере
В кластере веб-приложение Graphite сравнительно однородное в том смысле, что оно выполняет на каждом сервере одну и ту же работу. Однако, роль carbon может варьироваться от сервера к серверу в зависимости от того, какие данные отправляются на каждый экземпляр сервера. Часто есть много различных клиентов, посылающих данные в carbon, поэтому было бы весьма хлопотно настраивать конфигурацию каждого клиента в соответствие с компоновкой кластера Graphite. Метрики, используемые в обычных приложениях, могут отсылаться на один сервер carbon, а метрики, используемые в бизнес-приложениях, - на несколько серверов carbon с целью обеспечения избыточности.
Чтобы упростить управление сценариями подобного рода, пакет Graphite поставляется с дополнительным инструментальным средством, называемым carbon-relay. Его работа сравнительно проста; он получает от клиентов данные метрики точно также, как и стандартный демон carbon (а точнее, carbon-cache), но вместо того, чтобы запоминать данные, он применяет к именам метрик набор правил с тем, чтобы определить, на какой сервер carbon-cache перенаправить данные. Каждое правило состоит из регулярного выражения и списка серверов, на которые можно направлять данные. Для каждого значения точки данных по порядку применяются правила и используется первое правило, регулярное выражение в котором совпадет с именем метрики. Таким образом всё, что нужно клиенту сделать, это отослать данные на carbon-relay и попадут на надлежащие серверы.
В каком-то смысле carbon-relay предоставляет функциональные возможности репликации, хотя более точно они должны называться дублированием входных данных, поскольку не решаются вопросы синхронизации. Если сервер временно недоступен, то будут отсутствовать значения точек данных за тот период, в течение которого он был недоступен, но все остальное будет функционировать нормально. Есть административные скрипты, которые позволяют системному администратору управлять процессом ресинхронизации.
Далее: Размышления о проекте