Проект CoreOS (https://www.opennet.me/opennews/art.shtml?num=40275), развивающий основанное на идеях контейнерной изоляции серверное окружение, представил (https://coreos.com/blog/etcd-3.2-announcement) релиз etcd 3.2 (https://coreos.com/etcd/), высоконадёжного распределённого хранилища параметров конфигурации, задаваемых в форме ключ/значение. Основным назначением etcd является предоставление унифицированного механизма хранения конфигурации и информации о работающих сервисах для изолированных контейнеров с типовой начинкой. Код etcd написан на языке Go и распространяется (https://github.com/coreos/etcd) под лицензией Apache 2.0.
Etcd позволяет организовать единое хранилище конфигурации для группы серверов, которое реплицируются на все узлы и поддерживается в синхронизированном состоянии с использованием протокола Raft (https://github.com/goraft/raft). Наличие копии данных на всех хостах позволяет исключить потерю конфигурации при выходе из строя отдельного узла. В etcd также могут сохраняться временные данные, для которых предусмотрена возможность определения времени жизни записи. Для доступа к конфигурации предоставляется простой API (https://github.com/coreos/etcd/blob/master/Documentation/dev... основанный на использовании gRPC (http://www.grpc.io/).Имеется встроенная возможность отслеживания изменения состояния ключа или директории с вызовом обработчика в случае обнаружения изменения (например, можно применить новое значение параметра конфигурации). Для защиты канала связи при обращении из внешней сети предоставляется поддержка TLS-шифрования, аутентификации (https://coreos.com/etcd/docs/latest/authentication.html) клиентов по ключам и разграничения доступа через ACL. На типовом оборудовании etcd обеспечивает производительность порядка 10 тысяч операций записи в секунду. Для доступа к базе можно использовать утилиту etcdctl (https://github.com/coreos/etcd/tree/master/etcdctl).
Основные новшества (https://github.com/coreos/etcd/releases/tag/v3.2.0):- Поддержка мультиарендности (https://ru.wikipedia.org/wiki/%D0%9C%D1%... (multi-tenancy) - благодаря применению пространств имён, один экземпляр etcd теперь может обслуживать несколько разных коллекций ключей, полностью изолированных между собой, т.е. разные пользователи и приложения могут манипулировать своим набором ключей, имена которых в разных наборах могут повторяться. Изоляция реализована на уровне клиента и прокси, т.е. etcd идентифицирует пространство имён при помощи специального префикса, который отсеивается и вырезается на уровне прокси и клиентской библиотеки.
- gRPC-прокси теперь могут применяться для снижения нагрузки на ядро системы с процессе доставки уведомлений о наступлении событий. Если раньше большое число клиентских подписчиков на событие создавало большую паразитную нагрузку и негативно влияло на производительность всего кластера, то теперь gRPC-прокси может выступать в роли серверного подписчика, события к которому по цепочке распределяются между клиентами. Подобный подход позволяет добиться производительности на уровне доставки миллиона событий в секунду;
- Новые распараллеливаемые службы RPC со встроенной системой распределённых блокировок и механизмов выбора лидера группы. В новой версии появилась возможность экспорта совместных блокировок (https://github.com/coreos/etcd/blob/master/Documentation/dev... и механизмов выбора лидера группы (https://github.com/coreos/etcd/blob/master/Documentation/dev...через сервиcы RPC (т.е. ранее реализуемые на стороне клиента блокировки и методы election теперь доступны через интерфейс gRPC), что значительно упрощает координацию распределённой системы и положительно влияет на производительность.
URL: https://coreos.com/blog/etcd-3.2-announcement
Новость: http://www.opennet.me/opennews/art.shtml?num=46682
Здорово! Интересно, а что, если etcd просто втупую лепить на каждую minion-node кластера, на каком количестве начнёт тормозить? Или всё-таки придётся по-старому держать 3 или 5 etcd-серверов?
Тормоза при росте количества мастер-нод - это ограничение протокола рафт. потому, да, много мастер-нод в одном кластере лучше не поднимать.
Не холивара ради, а для расширения кругозора...Чем etcd отличается от zookeeper? На мой взгляд, плюс-минус то же самое... Что лучше/круче? Почему?
Для расширения кругузора достаточно по-гуглитьhttps://yandex.ru/yandsearch?&clid=2186621&text=etcd vs zookeeper&lr=213
https://www.google.ru/search?ie=UTF-8&hl=ru&q=etcd vs zookeeper&gws_rd=sslСравнений etcd vs ZooKeeper уже есть много. Самая свежая волна обсуждений была когда недавно к etcd Выкатили ZooKeeper-интерфейс. То есть etcd умеет прикидываться ZooKeeper'ом.
Начнем с того, что zookeeper потребляет гораздо больше памяти.
Написан на Java.
Пр сути одно и то же, да. Отличия в интерфейсе. Зукипер на мой взгляд гораздо сложнее использовать. Там и клиентская библиотека прибитая какая-то, и примитивы синхронизации сложнее. Етцд в этом плане несравнимо проще.
Параметры, как их называют в этой гадости, бэкапятся каждые 24 часа.
Вот нахрена эта поделка???
Если восстановить виртуалку делов полторы минуты, а накатить конфиги ещё полторы минуты. А можно даже не накатывать, так как конфиги актуальны.
Задачи этой хрени непонятны обычному человеку, попробуй подвернуть джинсы и выпить смузи
>восстановить виртуалку делов полторы минутыа если виртуалок тысяча?
>конфиги актуальныоткуда такая уверенность?
Зачем нужен etcd - текст под презентацией http://rootconf.ru/2015/abstracts/1779
а чем от консула отличается? или от редиса?а есть там поддержка иерархии ключей в стиле к1/к2/к3 ?