Комментарии 18
А потом начинается — нужно разделение этого ключа по правам доступа для разных клиентов. Ограничение на размер ключа ( а если там 1КБ таких значений?). Консистентность в том же консуле можно реализовать через "косвенную адресацию". Что-то типа симлинка. Мы создаём под /key/rev_v1 пачку ключей. Потом мы хотим их обновить. Пишем в /key/rev_v2 новую пачку ключей, но приложение наше о них сейчас не знает. Как записали — меняем /key/revision, чтобы оно указывало, что приложение должно смотреть в поддерево rev_v2. Задача решена. Это, конечно, не спасает от ИзМЕНЕНИЯ ключей, которое несогласованное. Но можно попросту договориться на уровне организации, что мы ключи не меняем, а создаём новое поддерево (rev_v3, rev_v4 и и.т.д.). Проблема решена.
этим может заниматься админка.
Админка чего, простите? У меня само приложение лезет за своей конфой в etcd/consul/zk. Но очевидно, что не каждый инстанс приложения и даже не каждый его компонент одинаков в своих правах.
решение 1: выполнение всех шагов ещё до стадии "отправка в реплику". фиксация всех изменений и отправка в реплику нового значения конфига целиком (или блока).
Это очень интересный вопрос. Потому что если etcd гарантирует то, что сначала происходит запись во все живые члены кластера, то это не совсем асинхронная KV схема с Ваших слов. А вполне синхронная — запись была? Была. Надежная? Да, вполне, в несколько узлов. И только после того, как большинство участников кластера подтвердили запись — мы увидим "новое" значение ключа. Или у Вас смещение терминологии и реплика — это клиент etcd? Ну, тогда извините — говорить не о чем
Етсд кластер на 300 нод никто в здравом уме делать не будет. Обычно делают 3,5. Я уж не говорю, что в условиях кроссдц там начинаются интересные (на самом деле нет) эффекты
А это тут причем? Одно дело — кластер с конфигурацией. Другое дело — кластер с рабочими узлами. Посмотрите на кубернетес — количество мастер нод вполне ограничено разумными значениями. Никто не собирает кубернетес с количеством мастеров 500 нод. Зато 5 мастеров вполне тянут кластер на 1000-5000 рабочих узлов
Даже не знаю, что в это комментарии наиболее безграмотно:
- Предложения, начинающиеся с маленькой буквы.
- Отделение отдельных предложений абзацами.
- Использование выдуманных терминов: "АСИНХРОННОЕ ключ-значение хранилище", ""доехать" по репликации", "конфигфайле", "ключ-значение-хранилище".
- И наконец, отсутствие понимание исходной задачи, какие гарантии хотим предоставлять с точки зрения консистентности, доступности и отказоустойчивости.
По поводу оригинальной статьи. Ее автор — небезызвестный Aphyr, который каждый раз находит проблемы в распределенных системах, начиная от документации, и заканчивая разбором крайне нетривиальных сценариев обработки запросов и моделирование сбоев системы. В данном случае можно констатировать, что etcd выстояла очень достойно и решила свою главную задачу на отлично.
исходная задача — обеспечить консистентность частей старого и нового конфига приложения между собой. При том что едет на хост он частями.
Мне не очень понятно, откуда взялась такая задача. В исходной статье решается задача консистентной репликации KV-хранилища. При этом под консистентностью здесь понимается вполне определенное поведение — это линеаризумость операций чтений и записи. Помимо этого здесь вводится сериализумость и транзакционное поведение. Можно доказать, что для решения этой задачи необходимо использовать консенсус, который и будет являться строительным блоком для подобного рода хранилищ.
Если не использовать консенсус в качестве базы, то можно легко показать (и Aphyr это не раз демонстрировал), что данные разъезжаются, реплики будут содержать разные данные, что может приводить к конфликтам и некорректной работе всей системы. Именно поэтому важно поддерживать согласованность данных, и консенсус — это единственный способ этого достичь.
Уровень дискуссии в стиле "всё реализовывать не обязательно в KV хранилище, а например вообще в админке" говорит о фундаментальном непонимании, что такое админка и как она взаимодействует с хранилищем. Не говоря уже про саму задачу консенсуса, свойств живучести и безопасности, и способов верификации полученного решения.
У вас разная трактовка понятия "разъезжаются".
Это и "данные распределяются по кластеру", и "данные неконсистентны". Вы уж определитесь, что в конкретном контексте
etcd 3.4.3: исследование надёжности и безопасности хранилища