Эта статья переведена сetc.io/docs/v3.4.0…
О etcd
Главный герой этой статьи etcd. Название «etcd» происходит от двух идей: папки unix «/etc» и распределенной системы «d». В папке «/etc» хранятся данные конфигурации для одной системы, а папка etcd используется для хранения информации о конфигурации, распространяемой в больших масштабах. Следовательно, «/etc» с назначенным «d» — это «etcd».
etcd разработан как основа общего назначения для больших распределенных систем. Эти большие системы должны избегать операций с разделенным мозгом и готовы пожертвовать доступностью для достижения этой цели. etcd хранит метаданные согласованным и отказоустойчивым образом. Кластеры etcd предназначены для обеспечения стабильности, надежности, масштабируемости и производительности хранилища ключей и значений.
Распределенные системы используют etcd в качестве согласованного компонента хранилища ключей и значений для управления конфигурацией, обнаружения служб и координации распределенной работы. Многие организации используют etcd в производственных системах, таких как планировщики контейнеров, службы обнаружения служб и распределенные хранилища данных. Общие распределенные шаблоны с использованием etcd включают выбор лидера, распределенные блокировки и мониторинг состояния активности компьютера.
Случаи применения
- Container Linux для CoreOS: приложения, работающие в Container Linux, будут получать автоматические обновления ядра Linux без простоев. Контейнер Linux использует блокировки для координации обновлений. Locksmith реализует распределенный семафор на etcd, чтобы гарантировать, что только подмножество кластера перезапускается в любой момент времени.
- Kubernetes хранит данные конфигурации в etcd для обнаружения служб и управления кластером; согласованность etcd имеет решающее значение для оркестровки контейнеров. Сервер Kubernetes API сохраняет состояние кластера в etcd. Он использует API наблюдения etcd для мониторинга кластера и отката критических изменений конфигурации.
многомерное сравнение
Может быть, etcd уже подходит, но, как и в случае со всеми другими технологиями, нам нужно действовать осторожно. Хотя объективное сравнение методов и функций было бы идеальным, опыт и предвзятость автора явно благоприятствуют etcd (эксперименты и документация написаны авторами etcd).
Следующая таблица является кратким справочником по различиям между etcd и его наиболее популярными альтернативами. Дополнительные описания и подробные сведения о каждом столбце приведены в разделах, следующих за таблицей.
с ZooKeeper
ZooKeeper решает те же задачи, что и etcd: координация распределенной системы и хранение метаданных. Тем не менее, etcd наступает на плечи своих предшественников, что относится к опыту проектирования и реализации ZooKeeper. Уроки, извлеченные из Zookeeper, безусловно, повлияли на разработку etcd, помогая поддерживать большие системы, такие как Kubernetes. Улучшения etcd для Zookeeper включают:
- Динамическая перенастройка членов кластера
- Стабильное чтение и запись при высокой нагрузке
- Модель данных управления параллелизмом с несколькими версиями
- Надежный мониторинг пар «ключ-значение»
- Примитивы аренды разделяют соединения в сеансах
- API для распределенных общих замков
Кроме того, etcd поддерживает несколько языков и фреймворков из коробки. Zookeeper имеет собственный настраиваемый протокол Jute RPC, который полностью уникален для Zookeeper и ограничивает поддерживаемые им языковые привязки, в то время как клиентский протокол etcd построен на gRPC, популярном фреймворке RPC с поддержкой go, C++, Java и других языков. Точно так же gRPC можно сериализовать в JSON через HTTP, поэтому даже общие утилиты командной строки, такие как curl, могут взаимодействовать с ним. Поскольку системы могут выбирать из множества вариантов, они строятся на etcd с собственными инструментами, а не на etcd на основе фиксированного набора технологий.
С точки зрения функций, поддержки и стабильности etcd больше подходит как компонент согласованного хранилища ключей и значений, чем Zookeeper.
Consul
Consul — это сквозная среда обнаружения сервисов. Он обеспечивает встроенные проверки работоспособности, обнаружение сбоев и службы DNS. Кроме того, Consul предоставляет хранилище ключей и значений с помощью RESTful HTTP API. В Consul 1.0 система хранения не масштабировалась в операциях ключ-значение, как другие компоненты, такие как etcd или Zookeeper. Системы с миллионами ключей будут страдать от высокой задержки и нехватки памяти. Консулу особенно не хватает многоверсионных ключей, условных транзакций и надежного мониторинга потоков.
etcd и Consul решают разные задачи. Если вы ищете распределенное согласованное хранилище ключей и значений, etcd — лучший выбор, чем Consul. Если вы ищете сквозное обнаружение службы кластера, etcd не будет иметь достаточной функциональности. Выберите Kubernetes, Consul или SmartStack.
NewSQL(Cloud Spanner, CockroachDB, TiDB)
Как базы данных EtCD, так и NewsQL (например, Cabrach, TIDB, Google Gangerner) обеспечивают большие гарантии согласованности данных с высокой доступностью. Однако различные идеи дизайна системы приводят к значительному различным клиентским API и характеристики производительности.
Базы данных NewSQL предназначены для горизонтального масштабирования в центрах обработки данных. Эти системы обычно разбивают данные на несколько согласованных групп репликации (сегментов), которые могут быть сильно разделены и хранить наборы данных в терабайтах или больше. Такое масштабирование делает их плохими кандидатами для распределенной координации, поскольку они требуют длительной задержки и должны обновляться в основном с локализованной топологией зависимостей. Данные NewSQL организованы в таблицы, включая инструменты запросов в стиле SQL с более богатой семантикой, чем etcd, но за счет дополнительной сложности обработки и оптимизации запросов.
Короче говоря, выберите etcd для хранения метаданных или координации распределенных приложений. Если вы храните больше нескольких гигабайт данных или вам нужен полный SQL-запрос, выберите базу данных NewSQL.
Хранение данных метаконфигурации с помощью etcd
etcd реплицирует все данные в пределах одной группы репликации. Это наиболее эффективный метод хранения до нескольких гигабайт данных в последовательном порядке. Каждому изменению состояния кластера (которое может изменить несколько ключей) назначается глобально уникальный идентификатор (называемый ревизией в etcd) из монотонно увеличивающегося счетчика для упорядочения. Поскольку существует только одна группа репликации, запросы на изменение необходимо отправлять только через плотный протокол. Ограничивая консенсус одной группой репликации, etcd использует простой протокол для достижения распределенной согласованности с низкой задержкой и высокой пропускной способностью.
Репликация позади etcd не может масштабироваться по горизонтали, потому что в ней отсутствует сегментация данных. Напротив, базы данных NewSQL обычно разбивают данные по нескольким согласованным группам репликации, сохраняя наборы данных на уровне терабайт или более. Однако, чтобы присвоить каждой модификации глобально уникальный и добавочный идентификатор, каждый запрос должен пройти дополнительный протокол координации между группами репликации. Этот дополнительный шаг согласования может столкнуться с глобальным идентификатором, что приведет к повторной попытке упорядоченного запроса. В результате производительность методов NewSQL обычно сложнее, чем у etcd для обеспечения строгой согласованности.
Если приложение в основном связано с сортировкой метаданных или метаданных, выберите ETCD. Если приложение требует больших хранилищ данных по нескольким центрам обработки данных, в значительной степени выберите базу данных NewsQL, если вы не зависите от мощных глобальных сортировочных свойств.
Использование etcd в качестве распределенного компонента координации
etcd имеет распределенные примитивы координации, такие как мониторинг событий, аренда, выборы и распределенные блокировки. Эти примитивы обслуживаются и поддерживаются разработчиками etcd; предоставление этих функций внешним библиотекам, ответственным за разработку лежащего в их основе распределенного программного обеспечения, по существу делает систему незавершенной. Базы данных NewSQL обычно предполагают, что эти примитивы распределенной координации будут написаны третьими сторонами. Точно так же ZooKeeper имеет отдельную библиотеку координации. Консул, который предоставляет локальный API блокировки, даже извиняется за то, что он «не пуленепробиваемый метод» (после того, как 1 клиент снимает блокировку, другие клиенты не могут получить блокировку немедленно, что может быть вызвано настройкой задержки блокировки).
Теоретически эти примитивы могут быть построены на любой системе хранения, обеспечивающей строгую согласованность. Однако алгоритмы имеют тенденцию быть тонкими. Легко разработать алгоритм блокировки, который, казалось бы, работает, но ломается из-за ограничений и временного перекоса. Кроме того, другие примитивы, поддерживаемые etcd (такие как транзакционная память), зависят от модели данных MVCC etcd; простой строгой согласованности недостаточно.
Для распределенной координации выбор etcd может помочь избежать операционных головных болей и снизить рабочую нагрузку.