Проект CoreOS (http://www.opennet.me/opennews/art.shtml?num=40275), развивающий основанное на идеях контейнерной изоляции серверное окружение, опубликовал (https://coreos.com/blog/introducing-etcd-2.1/) релиз etcd 2.1 (https://coreos.com/using-coreos/etcd/), высоконадёжного распределённого хранилища параметров конфигурации, задаваемых в форме ключ/значение. Основным назначением etcd является предоставление унифицированного механизма хранения конфигурации и информации о работающих сервисах для изолированных контейнеров с типовой начинкой. Код etcd написан на языке Go и распространяется (https://github.com/coreos/etcd) под лицензией Apache.Etcd позволяет организовать единое хранилище конфигурации для группы серверов, которое реплицируются на все узлы и поддерживается в синхронизированном состоянии с использованием протокола Raft (https://github.com/goraft/raft). Наличие копии данных на всех хостах позволяет исключить потерю конфигурации при выходе из строя отдельного узла. В etcd также могут сохраняться временные данные, для которых предусмотрена возможность определения времени жизни записи. Для доступа к конфигурации предоставляется простой API, основанный на использовании HTTP и JSON, web-интерфейс (https://github.com/henszey/etcd-browser), утилита etcdctl для работы с хранилищем из командной строки и FUSE-модуль etcd-fs (https://github.com/xetorthio/etcd-fs) для экспорта хранилища в виде файловой системы.
Для перехода на новую версию подготовлены средства бесшовного обновления, позволяющие заменить etcd 2.0 на etcd 2.1 без остановки работы сервиса. Особенности (https://github.com/coreos/etcd/releases/tag/v2.1.1) выпуска etcd 2.1:- Реализован API /v2/auth (https://github.com/coreos/etcd/blob/master/Documentation/aut...), расширяющий типовой API etcd средствами для аутентификации и авторизации. Данный Auth API даёт возможность управления доступом к группам хранимых ключей на основе задания ролей и владельцев префиксов ключей c аутентификацией через штатные методы HTTP. Поддержка Auth API добавлена в сервер etcd, утилиты командной строки и клиентские привязки;
- Новый Metrics API (https://github.com/coreos/etcd/blob/master/Documentation/met...), который может применяться для мониторинга и отладки в режиме реального времени. Через данный API можно получить доступ к актуальной статистике о работающих с хранилищем клиентах и расходуемых ресурсах;
- Увеличена стабильность работы в условиях использования ненадёжных каналов связи, в которых наблюдаются провалы пропускной способности и высокие задержки в доставке пакетов. Сокращена интенсивность создания соединений - вместо создания серии единичных соединений для каждой операции, etcd теперь применяет установку долгоживущих соединений с хостами, не разрываемых после каждого запроса. Произведено объединение отправки команд достижения консенсуса между узлами (raft (https://godoc.org/github.com/coreos/etcd/raft)) с индексом коммитов, что позволило увеличить отзывчивость со 100 мс до 1 мс в условиях небольшой нагрузки (менее 100 записей в секунду). Реализация алгоритма raft расширена более качественными средствами контроля потока, что существенно снизило вероятность потери raft-сообщений и увеличено эффективность расходования памяти и ресурсов CPU;- Подготовлен фреймворк (https://coreos.com/blog/new-functional-testing-in-etcd/) для функционального тестирования etcd, позволяющего выявить и устранить возможные проблемы, проявляющиеся в условиях высокой нагрузки, и оценить поведение системы при возникновении различных видов сбоев.- Реализована система (https://github.com/coreos/etcd/blob/master/Documentation/con...) многоуровневых логов, дающая возможность определять степень охвата журналируемых действий через задание уровня ведения лога - от вывода только критичных уведомлений до подробнейшего лога в режиме отладки. Кроме того, улучшена читаемость информации в логах.
URL: https://coreos.com/blog/introducing-etcd-2.1/
Новость: http://www.opennet.me/opennews/art.shtml?num=42716
То что надо! Предстоит заюзать подобное :)
Очень не стабильное и глючное поделие
CoreOS, или конкретно сабж?
Конкретно etcd, но думаю и CoreOS так же расслабленно разрабатывают.
Простой пример, когда выпустили первую стабильную версию, не проверили работу этой поделки по шифрованным протоколам! Из-за чего на следующий день после релиза стейбла пришлось выпускать внеочередное обновление. На нашем опыте эта штука работает очень не предсказуемо. Хотели внедрять её, но передумали.
вот блин! а казалось бы небольшая утилита! я вот как раз раздумывал, не начать ли использовать ли ее, если появилась авторизация. У вас давно глюки были? На старых или текущих версиях?
Последний раз смотрели версию 2.0. Попробуйте может подкрутили постабильности, главное использовать больше 3-х нод.
ну понятно, спасибо
Это они реестр придумали?
Это они Active Directory нИасилили!))
Именно так. Только Поттеригу это не показывайте.
Ну и зачем эти наколенные поделия если есть каталожные сервера, которые (в том числе) для этого и предназначены?
Это не каталог, это быстрая хранилка ключь-значение как redis или zookeeper.
Etcd отличается от них тем, что она изначально планировалась как распределенная и отказоустойчивая.
Ну LDAP - это тоже своего рода "хранилка ключ-значение", оптимизированная на чтение
LDAP - оптимизированная?
ты даже не поверишь, насколько.
это запись в ldap обычно медленная, оно больше для справочных данных, которые обновляются редко, а нужны часто.
а на чтение боевые ldap решения быстрые как понос.
Эта - универсальная. Потому и Go.
Они что, перепридумали sqlite?
Можно пример ldap с реализацией Raft?
А можно сперва узнать нафейхоа? В смысле, зачем может понадобится этот протокол в деле синхронизации узлов LDAP? Сколько мне известно в OpenLDAP эту задачу выполняет LDAP Content Synchronization protocol и его (вы не поверите!) вполне достаточно для решения всех задач связанных с распространением обновленных данных по узлам. У других каталожных серверов тоже есть подобные механизмы, так зачем цеплять кирпич к хвосту синицы?
он просто не знает ничего про лдап, это даже не NIH-синдром, это простая безграмотность, как у авторов сабжа.
Давайте Вы сначала расскажете как вместо реализаций Raft (etcd) использовать LDAP с LDAP Content Synchronization protocol? :-)
> Давайте Вы сначала расскажете как вместо реализаций Raft (etcd) использовать LDAP с
> LDAP Content Synchronization protocol? :-)ровно так же как школофанбои вместо давно известных средств для всего лепят новые и новые костыли, только по итогам использования проблем меньше огребётся
Единственное, что могу придумать - это адовая сложность этих самых каталожных серверов. Нужная далеко не всегда, начиная с тех же asn.1 и kerberos.
>адовая сложность этих самых каталожных серверов.мозг из задницы вынь и вставь обратно в голову
Увы все чаще данный орган атрофирован
Вы про задницу ?
>Ну и зачем эти наколенные поделия если есть каталожные сервера, которые (в том числе) для этого и предназначены?Для LDAP нужен код, который его поддерживает, библиотеки, конфигурационные файлы. А эта хрень конфигурирует микросервисы прямо по DNS ничего лишнего.
чем-то напоминает идею registry ot MS