Отслеживание статуса сервисов инфраструктуры веб-приложения
Пензенский
государственный технологический университет
Отслеживание статуса сервисов
инфраструктуры веб-приложения
Чинков М.Ю.,
В статье рассматривается проблема отслеживания большого
количества сервисов, поддерживающих работу веб-приложения, а также решение
данной проблемы с помощью service discovery-инструментов.
Ключевые слова: веб-приложение,
отслеживание сервисов, Consul, проверки состояния.
Современная инфраструктура веб-приложений имеет множество
автономных сервисов, каждый из которых отвечает за определенный функционал
сервиса. Данный подход дает огромное преимущество в масштабировании системы, а
также в обеспечении отказоустойчивости, так как при поломке одного из
компонентов система по-прежнему продолжает работать. Однако появляются новые
недостатки, связанные с эксплуатацией и обслуживанием веб-сервиса в целом.
Основным недостатком распределенных вычислительных систем
является сложность отслеживания состояния всех сервисов одновременно. Трудно
понять, какой именно компонент вышел из строя, опираясь лишь на традиционные
средства мониторинга и проверяя в отдельности каждый компонент.
Решением проблемы отслеживания статуса сервисов
веб-приложения является реализация дополнительного вида мониторинга в виде
методологии исследования сервиса (service discovery). "Service discovery" позволяет
построить на своей базе полноценную систему отслеживания сервисов, которая
позволит не только обнаружить, какой именно сервис вышел из строя, но и
автоматически исправить ошибки и перезапустить сервис.
Самым популярным решением в реализации практик "service discovery" является
применение программного инструмента Consul. Consul является клиент-серверной системой, нацеленной
на решение нескольких задач:
) "Service discovery”. Consul обнаруживает наличие тех
или иных сервисов веб-приложения, отслеживая поведение агентов по протоколам DNS и HTTP.
статус сервис приложение мониторинг
2) Проверка состояния сервисов (health check). Консул позволяет
настроить в рамках кластера неограниченное число проверок сервиса любыми
методами. Например, проверкой состояния сервиса база данных является попытка
подключения к TCP-порту, который должна прослушивать СУБД, командой netcat.
"Health check" обычно имеет 2 состояние - проходящий (passing), в котором описывается
рабочее состояние сервиса и критический (critical), которое говорит о том,
что сервис в данный момент времени не работает.
) Поддержка множества датацентров. Концепция
датацентра является основной концепцией Consul. Каждый датацентр имеет
несколько агентов, работающих в роли серверов и собирающих информацию о нодах
кластера. Каждый датацентр имеет собственное имя и содержит определенное
количество нод и сервисов, работающих внутри нод.
В рамках данного исследования был спроектирован полноценный
кластер Consul из нескольких нод с конечной визуализацией состояния сервисов в
виде статусной страницы (status page). Реализация кластера состояла из следующих базовых
шагов:
1) Скачивание и установка Consul на нодах кластера.
Процесс установки Consul-агента на одной ноде достаточно прост. Необходимо лишь скачать zip-архив и распаковать
бинарный файл в директорию, из которой запускаются системные команды.
2) Скачивание пакета веб-интерфейса Consul. Отдельно на Consul-сервер скачивается пакет
веб-интерфейса. Интерфейс разворачивается самостоятельно при запуске Consul, не требуя
дополнительной конфигурации.
) Создание аккаунта в Hashicorp. Для целевого
веб-приложения был создан отдельный аккаунт в Hashicorp. Данный шаг не является
необходимым, однако через созданный аккаунт возможна автоматическая интеграция
новых нод в кластер без дополнительной переконфигурации сервиса.
) Настройка системных демонов consul-agent и consul-server. По умолчанию consul запускается из командной
строки как foreground-процесс. Для полноценной работы кластера необходимо запускать
агенты в виде фоновых процессов. Данная задача была реализована в виде
работающих системных демонов на ОС Ubuntu 16.04.
) Конфигурация прокси-сервера. Дополнительно на
сервере Consul, где планировалось развернуть веб-интерфейс, был установлен и
сконфигурирован прокси-сервер Nginx, который перенаправляет все соединения со
стандартного 80 порта HTTP на 8500, который прослушивает Consul. Дополнительно настроена
аутентификация для предотвращения входа в систему посторонних лиц.
7) Добавление сущностей сервисов в кластер. На каждой
ноде сконфигурированы сервисы веб-приложения, которые необходимо отслеживать.
Каждый сервиса имеет собственное имя, порт и сервер, на котором он работает.
Дополнительно к сервисам были прикреплены проверки состояния (health checks), проверяющие через
установленный временной интервал состояние работы сервисов.
) Добавление триггеров состояния сервисов. На каждый
сервис был прикреплен собственный триггер - "watch" - который
запускает обработчик событий сразу после того, как "health check" сервиса приобрел
критическое состояние.
) Добавление обработчиков событий. В рамках исследования
для каждой ноды был создан отдельный обработчик - "handler" - который
проверяет доступность внутренних сервисов и пытается перезапустить тот сервиса,
который был помечен, как недоступный.
) Перезагрузка конфигурации кластера. Для вступления
изменений конфигурации в силу на каждой ноде кластера была проведена
перезагрузка кластера запуском команды "consul reload”.
) Проверка работы кластера. Проверка работы кластера
была проведена в два шага: запуск команды "consul members" в консоли сервиса
и проверка веб-интерфейса из локального браузера.
Все вышеперечисленные шаги по созданию кластера были
полностью автоматизированы. Программное обеспечение было установлено и
сконфигурировано с помощью системы управления конфигурации Ansible.
На рисунке 1 показан один из результатов работы кластера в
виде статусной страницы всех сервисов, работающих внутри инфраструктуры
веб-приложения. Внутри веб-интерфейса можно отслеживать не только сервисы, но и
ноды кластера, благодаря чему можно достаточно быстро понять, в какой
конкретной точке произошел отказ.
Рисунок 1 - веб-интерфейс системы отслеживания сервисов
веб-приложения
Конечным итогом данного исследования является построение
полноценно функционирующей системы отслеживания сервисов, которая делает
процесс мониторинга работы веб-приложения и его компонентов гораздо проще.
Хотелось добавить, что в рамках данного исследования была
реализована лишь самая примитивная возможность Consul как инструмента для
"service discovery”. Работая с полноценной микросервисной архитектурой, где
сервисы, упакованные в контейнеры, не имеют постоянного места эксплуатации,
необходима полноценная оркестрация инфраструктурой, динамически конфигурируя
окружение путем изменений настроек подключения к DNS и системам мониторинга. Consul позволяет это делать
автоматически и на лету. Также в Consul можно хранить данные в формате
"ключ-значение”, записывая состояние о нодах кластера.
Таким образом, была рассмотрена проблема отслеживания
состояния множества слабо связанных сервисов веб-приложения с описанием одного
из путей решения проблемы посредством внедрения в инфраструктуру приложения
практики "service discovery" в виде исследования работы такого
инструмента, как Consul.
Список
литературы
1.
Немет Э., Снайдер Г., Хейн Т.Р., Уэйли Б. Unix и Linux. Руководство системного
администратора [Текст] // Вильямс. - 2012. - С.1157-1180.
2. Limoncelli T. The Practice of Cloud System Administration:
Designing and Operating Large Distributed Systems, Volume 2 [Текст] // - 2015.
- С.243-275.