Проект CoreOS, развивающий основанное на идеях контейнерной изоляции серверное окружение, представил релиз etcd 3.2, высоконадёжного распределённого хранилища параметров конфигурации, задаваемых в форме ключ/значение. Основным назначением etcd является предоставление унифицированного механизма хранения конфигурации и информации о работающих сервисах для изолированных контейнеров с типовой начинкой. Код etcd написан на языке Go и распространяется под лицензией Apache 2.0.

Etcd позволяет организовать единое хранилище конфигурации для группы серверов, которое реплицируются на все узлы и поддерживается в синхронизированном состоянии с использованием протокола Raft. Наличие копии данных на всех хостах позволяет исключить потерю конфигурации при выходе из строя отдельного узла. В etcd также могут сохраняться временные данные, для которых предусмотрена возможность определения времени жизни записи. Для доступа к конфигурации предоставляется простой API, основанный на использовании gRPC.

Имеется встроенная возможность отслеживания изменения состояния ключа или директории с вызовом обработчика в случае обнаружения изменения (например, можно применить новое значение параметра конфигурации). Для защиты канала связи при обращении из внешней сети предоставляется поддержка TLS-шифрования, аутентификации клиентов по ключам и разграничения доступа через ACL. На типовом оборудовании etcd обеспечивает производительность порядка 10 тысяч операций записи в секунду. Для доступа к базе можно использовать утилиту etcdctl.

Основные новшества:

• Поддержка мультиарендности (multi-tenancy) - благодаря применению пространств имён, один экземпляр etcd теперь может обслуживать несколько разных коллекций ключей, полностью изолированных между собой, т.е. разные пользователи и приложения могут манипулировать своим набором ключей, имена которых в разных наборах могут повторяться. Изоляция реализована на уровне клиента и прокси, т.е. etcd идентифицирует пространство имён при помощи специального префикса, который отсеивается и вырезается на уровне прокси и клиентской библиотеки.
• gRPC-прокси теперь могут применяться для снижения нагрузки на ядро системы с процессе доставки уведомлений о наступлении событий. Если раньше большое число клиентских подписчиков на событие создавало большую паразитную нагрузку и негативно влияло на производительность всего кластера, то теперь gRPC-прокси может выступать в роли серверного подписчика, события к которому по цепочке распределяются между клиентами. Подобный подход позволяет добиться производительности на уровне доставки миллиона событий в секунду;
• Новые распараллеливаемые службы RPC со встроенной системой распределённых блокировок и механизмов выбора лидера группы. В новой версии появилась возможность экспорта совместных блокировок и механизмов выбора лидера группы через сервиcы RPC (т.е. ранее реализуемые на стороне клиента блокировки и методы election теперь доступны через интерфейс gRPC), что значительно упрощает координацию распределённой системы и положительно влияет на производительность.