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

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

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

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

• Проведена оптимизация линеаризованной модели чтения ключей, в отличие от сериализированной модели обеспечивающей выдачу актуальных ключей, но ценой потери производительности из-за накладных расходов, связанных с необходимостью определения консенсуса (сериализированная модель читает ключи значительно быстрее, но может выдавать не самое свежее состояние). Оценка состояния ключей в линеаризованной модели производится с использованием протокола Raft. В новой версии для увеличения производительности, снижения нагрузки на дисковую подсистему и сокращения задержек применена индексация запросов через Raft и обеспечена возможность объединения групп запросов;
• Исключены ситуации кратковременной потери доступности кластера при выполнении операции обновления программного обеспечения. Ранее, в момент обновления лидирующего узла могла возникнуть ситуация временной потери работоспособности, если другие узлы инициировали выбор нового лидирующего узла из-за истечения таймаута. Отныне лидирующий узел автоматически передаёт лидерство другому узлу перед переходом в offline.
• Для исключения возникновения ситуации потери кворума из-за ошибки оператора, при которой кластер становится неработоспособен, перед перенастройкой состава кластера теперь осуществляется проверка работоспособности его участников, а изменение состава вступает в силу только, когда оно безопасно для сохранения работоспособности. Например, запрос на удаление узла будет отвергнут, если без этого узла не может быть сформирован кворум из-за недостаточного числа активных участников. Или будет отвергнут запрос на добавление участника, если кворум будет потерян из-за невозможности включить узел в состав кластера (например, указан неверный адрес);
• В etcd v3 API добавлена порция новых средств для учёта времени жизни операций извлечения, определения закреплённых за сеансом ресурсов, эффективной обработки ключей по их ревизиям (при выборке диапазона ключей можно ограничить минимальное и максимальное время модификации или создания ключа) и сокращения круговых задержек через отключение операций подтверждения (допущение возврата старых значений для удалённых событий).
• В разряд стабильный переведён API аутентификации, все дальнейшие изменения в v3 Auth API будут сохранять совместимость с текущими клиентами etcd v3. Основными отличиями от модели аутинтификации API v2 являются использование токенов для аутентификации (без необходимости выполнения операций bcrypt для каждого запроса) и возможность определения прав доступа для интервалов ключей, вместо привязки к префиксам ключей;
• Предоставлена возможность обращения к API по протоколу gRPC, использующему protobuf, через прокси. Прокси gRPC может применяться для сокращения нагрузки на ядро кластера etcd через применение кэширования недавно извлекаемых ключей и слияния отслеживаемых запросов. Например, прокси gRPC позволяет защитить кластер от наводнения запросами одного и того же ключа со стороны неправильно настроенного клента или объединить типовые потоки отслеживания для нескольких клиентов, что позволяет сократить число сетевых соединений к кластеру и уменьшить трафик.