Проект CoreOS (https://www.opennet.ru/opennews/art.shtml?num=40275), развивающий основанное на идеях контейнерной изоляции серверное окружение, представил (https://coreos.com/blog/etcd-3-1-announcement.html) релиз etcd 3.1 (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.1.0):
- Проведена оптимизация линеаризованной модели чтения ключей, в отличие от сериализированной модели обеспечивающей выдачу актуальных ключей, но ценой потери производительности из-за накладных расходов, связанных с необходимостью определения консенсуса (сериализированная модель читает ключи значительно быстрее, но может выдавать не самое свежее состояние). Оценка состояния ключей в линеаризованной модели производится с использованием протокола Raft. В новой версии для увеличения производительности, снижения нагрузки на дисковую подсистему и сокращения задержек применена индексация запросов через Raft и обеспечена возможность объединения групп запросов;
- Исключены ситуации кратковременной потери доступности кластера при выполнении операции обновления программного обеспечения. Ранее, в момент обновления лидирующего узла могла возникнуть ситуация временной потери работоспособности, если другие узлы инициировали выбор нового лидирующего узла из-за истечения таймаута. Отныне лидирующий узел автоматически передаёт лидерство другому узлу перед переходом в offline.- Для исключения возникновения ситуации потери кворума из-за ошибки оператора, при которой кластер становится неработоспособен, перед перенастройкой состава кластера теперь осуществляется проверка работоспособности его участников, а изменение состава вступает в силу только, когда оно безопасно для сохранения работоспособности. Например, запрос на удаление узла будет отвергнут, если без этого узла не может быть сформирован кворум из-за недостаточного числа активных участников. Или будет отвергнут запрос на добавление участника, если кворум будет потерян из-за невозможности включить узел в состав кластера (например, указан неверный адрес);
- В etcd v3 API добавлена порция новых средств для учёта времени жизни операций извлечения, определения закреплённых за сеансом ресурсов, эффективной обработки ключей по их ревизиям (при выборке диапазона ключей можно ограничить минимальное и максимальное время модификации или создания ключа) и сокращения круговых задержек через отключение операций подтверждения (допущение возврата старых значений для удалённых событий).
- В разряд стабильный переведён API аутентификации, все дальнейшие изменения в v3 Auth API будут сохранять совместимость с текущими клиентами etcd v3. Основными отличиями от модели аутинтификации API v2 являются использование токенов для аутентификации (без необходимости выполнения операций bcrypt для каждого запроса) и возможность определения прав доступа для интервалов ключей, вместо привязки к префиксам ключей;- Предоставлена возможность обращения к API по протоколу gRPC, использующему protobuf, через прокси. Прокси gRPC может применяться для сокращения нагрузки на ядро кластера etcd через применение кэширования недавно извлекаемых ключей и слияния отслеживаемых запросов. Например, прокси gRPC позволяет защитить кластер от наводнения запросами одного и того же ключа со стороны неправильно настроенного клента или объединить типовые потоки отслеживания для нескольких клиентов, что позволяет сократить число сетевых соединений к кластеру и уменьшить трафик.
URL: https://coreos.com/blog/etcd-3-1-announcement.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=45897
etcd
etcdctl
...
шёл логопед по шоссе и сосал etcdctl
dhcpcd
итдд -- "И так далее"-демон
Привет windows-реестр!
как будто что-то плохое
Плохое. Хранилище настроек, требующее специальных костылялок для редактирования не есть хорошо. Храните, трам-пам-пам, данные в простых текстовых файлах.
Так получилось, что получить ключ-значение из реестра быстрее, чем прочитать-распарсить из файла. И хотелось бы, чтобы в линуксах таки было нечто кроссдистрибутивное для этого вместо gconf или как там их реестр называется.
> Так получилось, что получить ключ-значение из реестра быстрее, чем прочитать-распарсить из файла.Это какой-то системд головного мозга (там тоже быстрее грузиться хотели)!
Зачем нужно получать это значение быстрее?У приложений что, основное занятие - это чтение/сохранение настроек?
> Так получилось, что получить ключ-значение из реестра быстрее, чем прочитать-распарсить из файла.Что курил? Когда начнётся фрагментирование этого твоего реестра, чтение будет ещё дольше.
В текстовых хотя бы есть комментарии от разработчиков, а для реестра ещё сразу чистилку изобретут, потом ходи чертыхайся.
Ещё и бекап реестра делать, да. Не-е, не надо нам такого барахла.
Парсинг файла конфигурации происходит как правило на момент старта один раз. Возможно он обновляется в процессе работы.
Но если вы обновляете конфигурацию 1000 раз в секунду, или у вас конфигурационный файл весит 100Мб, то тут уже что-то в консерватории надо править.
Если у тебя 20 типов сервисов и каждый имеет по 100 копий, то ты не будешь делать редеплой всего этого для изменения одного параметра.
В "распределённых" тестовых файлах? :)
Возможно админам локалхоста плохое. В перспективе, когда ценность каждого инстанса ОС стремится к нулю, хранение настроек приложений и системных в том числе где-то (не локально) в сети, становится очень привлекательным. Это примерно как хранить данные в БД которая хз где находится и непонятно как работает, но она есть и она работает. Также и с настройками.
> В перспективе, когда ценность каждого инстанса ОС стремится к нулюНевесёлая перспектива. Очень много энергии тратится.
Как буд-то текстовый фал редачится астралом, а не текстовым редактором, и вообще, можете курлом дергать рыкчу rest api. Ну и система пилилась как раз под микросервисную архитектуру, когда у вас "зеро" конфигурация, при старте микросервиса передал где исктаь etcd (вообще есть и зукипер, консул, тыщи их), а то само вытащило нужные ему данные для работы, узнало еще о членах кластера, которые выполняют анаогичную роль... Короче, там писали про админа локалхоста)
>Как буд-то
>фал
>рыкчу
>исктаь
>анаогичнуюСпеллчекер может помочь!
Спеллчекер тут уже не поможет.
Если не знаешь, что такое сабж и зачем он нужен, то лучше промолчать.
Windiws-реестр весьма неплохая идея. Плохо то, что там практически невозможно перенести конфигурацию с одной машины на другую путем копирования реестра. Если тут это будет работать, будет замечательно. Считай, те же конфигурационные файлы, только в унифицированном формате.
Весь софт под линукс придётся перелопатить, чтобы он хранил конфиги в этом реестре. Это не на один год. А в конечном счёте, зачем?
Чтобы было так же плохо как в винде. 100500%
Ну чтобы в реестре случилась одна ошибка и вся система из-за этого стала раком, как любят вантузятники.
> Ну чтобы в реестре случилась одна ошибка и вся система из-за этого
> стала раком, как любят вантузятники.Ну линукс же сложный, а венду переустановил и всё!
Ну не всё ешё потерянно! сысиемды уже прибит гвоздями, скоро и под линуксы пойдут очистители и оптимизаторы реестра ...
жрали мы это, хватит
> Весь софт под линукс придётся перелопатить, чтобы он хранил конфиги в этом реестреДа фих там. Скорее сделают etcfs, которая будет представлять конфиг из реестра в виде файлов с настройками.
странно, что никто не заныл про go, видимо win реестр больше ненавидят =)
Меня всегда удивляет, когда местные эксперты высказывают недовольство языком программирования, на котором написан софт. Я понимаю, когда программисты высказывают мнение по поводу того или иного языка программирования, они с ними работают. Но пользователю-то софта какая разница, на чем софт написан? Все эти рассуждения о том, что джава плохая, а божественная сишечка рулит - пустая болтовня делитантов, не работавших ни с тем, ни с другим. Особенно ситуация выглядит смешно, если учесть, что местным админам локалхоста тот же етцд никогда админить не придется.
> о том, что джава плохая,Правильно, индусы и интели с кингстонами прямо обожают жабу.
> а божественная сишечка рулит - пустая болтовня делитантов,
А что они делят?
> Но пользователю-то софта какая разницаКак это? Большая. Во-первых, требования. Память больше не дешевая, и на каждый хелловорлд тратить по гигабайту уже никто не будет. Алсо, есть армы и мипсы с сотнями мегабайт памяти, где эти помойки вообще не взлетят, ибо будут висеть в GC паузах 90% времени. Потом, развитость инструментов. Go со своим недокомпилятором MIPS уже научился? IDE там не забывайте. В-третьих, инфраструктура. Чуждый cargo который вместо установки пакетов в систему как в нормальных языках, тащит при сборке рандомные версии зависимостей по сети, ломая повторяемые сборки, кэширование и всё остальное. В общем, новаязы эти это один хайп, связываться с ними никто серьёзно не будет.
> сишечка рулит - пустая болтовня делитантов, не работавших ни с тем, ни с другим
Такие как раз считают что язык не важен.
Скажи честно: "я Go видел только на картинке, но мнение уже имею"
Ты путаешь память и дисковое пространство. Ты не представляешь какой реально процент времени забирает GC и сколько длится в Go 1.7 STW. Пользователя софта не интересует IDE. Чуждый cargo это к Rust, а не Go, зачем ты всё в кучу мешаешь? Новоязу Go восьмой год пошел и он успешно юзается в самых нагруженных веб сервисах.
Не агрись, человек отвечал про яву.
По крайней мере, первая часть написана как будто про яву.
Про которую ты знаешь из напевов Рабиновича. Ты вправду считаешь, что helloworld на яве требует гига памяти?
Я не считаю, я знаю. Умельцы из соседне страны на букву у, написали флеш полиси сервер который в итоге отъедает этот самый гиг.
Специально для икспердов.
/usr/bin/time -v java HelloWorld
Hello, World
Command being timed: "java HelloWorld"
User time (seconds): 0.02
System time (seconds): 0.00
Percent of CPU this job got: 100%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.03
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 13560То есть HelloWorld вместе с самой java занял 13MB. Как легко понять на деле сам HelloWorld не занял практически ничего и 13MB это виртуальная машина java. Заодно любители сказок про долгий старт этой vm могут глянуть на время исполнения.
Я понятие не имею про какую криворукую поделку ты говоришь, но написать памятижорку можно и на благословенных Сях. Но если хочется поговорить про нечто большее, чем HelloWorld, то к примеру LDAP сервер opendj у меня работает, занимая на старте 176MB оперативки и не более 256MB при дальнейшем использовании. Погугли минимальные требования для openldap.
Некоторые приложения на жабе могут требовать уйму памяти, но это вовсе не означает, что _любое_ приложение на жабе требует минимум гигабайта.
> икспердовк логопеду.
> это вовсе не означает, что _любое_ приложение на жабе требует минимум гигабайта.
к офтальмологу. я про любое и не говорил.
> Чуждый cargo который вместо установки пакетов в систему как в нормальных языках, тащит при сборке рандомные версии зависимостей по сети, ломая повторяемые сборки, кэширование и всё остальное.Не надо путать тёплое с мягким. Cargo -- это не пакетный менагер. Если вам нужны повторяемые сборки и прочее, то выберите версию нужного пакета, возьмите Cargo.toml, скомпилируйте его в ебилд, или что там у вас, и разруливайте депендансы ручками. Так как это делают мейнтейнеры дистрибутивов в отношении _всех_остальных_ программ. Не только тех, которые разрабатываются при помощи cargo.
Или халявы захотелось? Думали, что разработчики программ вдруг начнут решать проблемы мейнтейнеров дистрибутивов, просто потому что у них появился cargo? Нет уж, дудки!
> армы и мипсы с сотнями мегабайт памятиТак прямо и вижу серьёзную энтерпрайзную архитектуру на армах и мипсах. Ты опять путаешь свой локалхост на малине с работой.
>Но пользователю-то софта какая разница, на чем софт написан?Ну как какая. Если какая-нибудь утилита написана на жабке, то вслед на ней столько зависимостей паровозиком вытянется, что аж спасибо-ненада.
Утилиты на жабе не пишут. Start time не тот :) На жабе пишут чё нить стартующее не часто и висящее долго. Ну в смысле так делают те кто мозги на смууу-уу-уузи не заменил.
Еще один иксперд.time ldapsearch
real 0m0.201s
user 0m0.211s
sys 0m0.029sКакой страшный start time для весьма полезной утилиты, целых 0.2 секунды.
Удивление - когнитивная эмоция, возникающая при возникновении неожиданной ситуации.
Для тебя правда каждое высказывание такого плана неожиданно? Как ты живешь с этим?!Админ занимается эксплуатацией ПО. В зависимости от языка разработки, это ПО имеет отличные эксплуатационные особенности.
Если в течёт память, а программисты говорят "какая-то хрень с garbige collector", то какие выводы должен сделать админ?
Раз за разом натыкаясь на однотипные грабли, админ делает допущение про эксплуатационные качества класса программ написанных на данном языке программирования.> Но пользователю-то софта какая разница, на чем софт написан?
Никакой. Пользователь с жалобами на задержки в интерфейсе или производительности идёт к админу.
> Все эти рассуждения о том, что джава плохая, а божественная сишечка рулит - пустая болтовня делитантов, не работавших ни с тем, ни с другим.
Где такое написано в этой новости?
> Особенно ситуация выглядит смешно, если учесть, что местным админам локалхоста тот же етцд никогда админить не придется.
Обхохочешься. Можно подумать, что админы в массе получали профильное образование, а не выросли из дилетантов.
> Если в течёт память, а программисты говорят "какая-то хрень с garbige collector",
> то какие выводы должен сделать админ?Что конкретные программисты не умеют программировать на этом языке, а может и вообще ни на чем не умеют? Так как для того, чтобы добиться утечек памяти в языке с gc, надо постараться, например вообще никогда никакой ресурс не закрывать и держать ссылку на него в глобальной переменной.
> Так как для того, чтобы
> добиться утечек памяти в языке с gc, надо постараться, например вообще
> никогда никакой ресурс не закрывать и держать ссылку на него в
> глобальной переменной.Есть многое на свете, друг Горацио, что по размеру тяжелее ldapsearch.
Твоё мнение, как эксперта по всем вопросам и во всех профессиях, конечно, очень ценно, но что-то мне подсказывает, что такие всесторонние личности заняты более интересными делами, нежели кривляньем на опеннете.
> Все эти рассуждения
> о том, что джава плохая, а божественная сишечка рулит - пустая
> болтовня делитантов, не работавших ни с тем, ни с другим.Хорошо, давай я с точки зрения пользователя тебе за java поясню. Она тянет java-машину, которая мало того, что любит память, так ещё и сама по себе вешает 200 метров. Доволен?
Вы не умеете готовить жабу.Она может пахать на компьютере из 1960-х годов. И пашет: http://thenewstack.io/happens-use-java-1960-ibm-mainframe/
Правда странички отдаёт за 6-10 секунд.
>хранилище параметров конфигурации, задаваемых в форме ключ/значениененужно, хороните
для тех админов локалхоста, кто не понял: возьмите простейший конфиг апача со всеми его иерархиями и инклюдами, и попробуйте представить его в виде ключ-значение. Опционально можете подумать обычной сетевой фс с приколюхами
оптимизация чтения конфигов (почти единоразовая операция при старте) вообще убивает. чуваки смешали базу данных и конфиги, покажите им mongodb чтоли
> для тех админов локалхоста, кто не понял: возьмите простейший конфиг апача со
> всеми его иерархиями и инклюдами, и попробуйте представить его в виде ключ-значение.Я ни разу не сторонник etcd и понятия не имею как это решают там, но в общем случае ничего сложного в твоей задаче нет, достаточно лишь додуматься, что ключ может быть составным.
Вообще у проекта очень неудачное название, оно вводит в заблуждение, намекая на drop-in замену обычному /etc, но на деле не имеет с /etc почти ничего общего.
Очередной dconf/gconf ?
Очередной ты? Уже ведь были люди, зачем было еще тебя создавать?
Удваиваю этого господина (а не того, что сверху)
Удивляюсь тому что большинство комментаторов не заметили слова 'распределенный'.Системы подобные etcd возникли потому что распределенно хранить конфигурации в текстовых файлах, на сотнях и тысячях хостов, мягко говоря, неудобно.
Любопытно было бы услышать сравнение с Consul, который обеспечивает похожую функциональность.