Consul. Антиэнтропия

Перевод "ANTI-ENTROPY" из раздела "Consul Internals".

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

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

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

Компоненты

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

Агент

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

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

Каталог

Обнаружение сервисов(service discovery) опирается на каталог сервисов. Этот каталог формируется из агрегированной информации со всех агентов. Каталог - это доступ к более высокоуровневому представлению кластера, которое предоставляет информацию о доступных сервисах, их состоянии, нодах и многое другое. Все это доступно через HTTP или DNS интерфейс Consul.

У сервисов и проверок, в контексте каталога, значительно меньше опций, в сравнении с агентом. Каталог только записывает и возвращает информацию о сервисах, нодах и проверках.

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

Антиэнтропия

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

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

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

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

Периодическая синхронизация

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

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

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

Максимальные усилия для синхронизации

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

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