Проект CoreOS (https://www.opennet.dev/opennews/art.shtml?num=40275), на днях купленный (https://www.opennet.dev/opennews/art.shtml?num=47992) компанией Red Hat, опубликовал (https://coreos.com/blog/announcing-etcd-3.3) релиз etcd 3.3 (https://coreos.com/etcd/), высоконадёжного распределённого хранилища параметров конфигурации, задаваемых в форме ключ/значение. Основным назначением etcd является предоставление унифицированного механизма хранения конфигурации и информации о работающих сервисах для изолированных контейнеров с типовой начинкой.
Например, etcd применяется в платформе оркестровки контейнеров Kubernetes (https://www.opennet.dev/opennews/art.shtml?num=47762) для обеспечения хранения данных кластера. Код 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.3.0):
- Улучшена работа бэкенда bbolt (https://github.com/coreos/bbolt), представляющего собой форк Bolt DB (https://github.com/boltdb/bolt), применяемый для хранения локальных данных на каждом узле. Добавлено несколько режимов поддержания списка свободных блоков, позволяющего оптимизировать доступ к блокам, ставшими неактуальными после выполнения транзакций и доступными для повторного использования (заполнения новыми данными). Список свободных блоков сохраняется на диске чтобы избежать ресурсоёмких операций сборки мусора во время запуска. Обратной стороной поддержания такого списка является существенное (https://github.com/coreos/etcd/issues/8009) разрастание списка при выполнении большого числа транзакций. В качестве компромисса выбрана тактика перестроения списка свободных блоков во время выполнения операции восстановления ("recover"). На перестроение БД размером 10 Гб на современных системах тратится около 2 секунд. Для управления данным поведением представлено две опции "freelist sync" и "freelist no sync". Также увеличена производительность работы сборщика мусора;
- Значительно улучшен механизм восстановления соединения клиента в сетях с нестабильным каналом связи, который теперь учитывает возможное сегментирование сети и временные обрывы соединения;- Добавлен экспериментальный режим "--experimental-corrupt-check-time" для мониторинга состояния хранилища на предмет возможных повреждений данных (например, из-за ошибок на уровне файловой системы) во время работы. Также добавлен режим "--experimental-initial-corrupt-check" который во время запуска проводит контроль целостности через запрос у пира контрольных сумм CRC32 для известной ревизии и их сверку с фактическим состоянием хранилища перед началом обработки запросов клиентов и других пиров;
- Добавлен пакет clientv3/ordering с реализацией механизма причинной консистентности (https://ru.wikipedia.org/wiki/%D0%9F%D1%... (causal consistency) для сериализированных запросов на чтение, обеспечивающий логическую целостность порядка операций чтения и записи, независимо от того к какому узлу обратился клиент (т.е. клиент всегда получит доступ к самой свежей ревизии);- Добавлен режим "--experimental-enable-v2v3", позволяющий эмулировать старый API v2 доступа к хранилищу поверх нового API v3 на базе gRPC, обеспечивая при этом более высокую эффективность и масштабироваие по сравнению с нативным API v2, который теперь объявлен устарвшим;
- Добавлена возможность поддержания отдельного списка отозванных сертификатов X.509 (Certificate Revocation List), помимо штатного списка CRL от удостоверяющего центра. Для включения следует использовать опции "--client-crl-file" и "--peer-crl-file";
- Добавлена возможность применения в TLS сертификатов, охватывающих группу поддоменов по маске (*.example.com в поле SAN (Subject Alternative Name));- Добавлена возможность "--peer-cert-allowed-cn" для аутентификации между пирами на основе проверки совпадения имени Common Name (CN) в сертификате;
- Для работы в случае сегментации сети и невозможности прямого подключения клиента добавлена экспериментальная поддержка gRPC-прокси (https://github.com/coreos/etcd/issues/6065) для трансляции запросов клиентов к кластеру etcd при помощи API v3;
- Проведена большая работа по оптимизации производительности. При проведении тестирования отмечено заметное снижение задержек и увеличение пропускной способности с 32976 запросов в секунду до 35682 запросов в секунду.
URL: https://coreos.com/blog/announcing-etcd-3.3
Новость: http://www.opennet.dev/opennews/art.shtml?num=48024
> Проект CoreOS (https://www.opennet.dev/opennews/art.shtml?num=40275), на днях купленный
> (https://www.opennet.dev/opennews/art.shtml?num=47992) компанией Red Hat, опубликовал
> (https://coreos.com/blog/announcing-etcd-3.3) релиз etcd 3.3 (https://coreos.com/etcd/),...пропал колобуховский https://libelektra.org/ дом[I]!
> высоконадёжного распределённого
>задаваемых в форме
>предоставление унифицированного
>сервисах для изолированных контейнеров
>в платформе оркестровки контейнеров Kubernetes
>на языке Go
>под лицензией Apache 2.0.
> колобуховский
>> колобуховский
> https://ru.wikipedia.org/wiki/%D0%9A%D0%...Именно. Сначала пение, потом трубы замёрзнут, потом..
И эти туда же
Эти не туда же, эти оттуда же
2018 года а до сих пор блокчейн не прикрутили (((
Каким боком тут блокчейн?
> Каким боком тут блокчейн?Чтобы никто не мог просто так настройки поломать, вот представь себе вордпресс на блокчейне.
Каждому вордпрессу по Nvidia 1080Ti.
systemd-etcd нет ещё?
https://github.com/coreos/fleet
> https://github.com/coreos/fleethttps://github.com/Xylemon/xlennart#about
http://sisyphus.ru/en/srpm/Sisyphus/xlennart
https://packages.devuan.org/devuan/pool/main/x/xlennart/
Внезапно мы видим приехавший реестр а-ля Windows
В каждой новости про етцд находится школьник, сравнивающий его с реестром.
Потому что школьнику не снятся откаты от покупки вендорлока для работодателя-терпилы, и он может говорить правду.
Говорить - это все, что может школьник.
Омг, ты бы хоть почитал, что это и зачем нужно. Никто не будет заменять dconf в твоей убунте на етцд, админы локалхоста могут спать спокойно.
Кстати dconf - это как раз аналог реестра, а до него был gconf, и оно уже лет десять во всех убунтах и федорах. Где твоя правда теперь?
gconf работает со схемами в xml, которые всё-таки можно поправить в обычном текстовом редакторе, в случае чего. В отличии от бинарного dconf, нарушающего всю идиллию мира *nix. Ну и, несмотря ни на что, - gconf никогда в гегемоны не набивался, ограничиваясь лишь Gnome DE. В отличии, блджад, от...З.Ы. В любом случае, etcd не об этом, так что расходимся, пaцаны... :-)