Часто задаваемые вопросы

Общие вопросы об etcd

Что такое etcd?

etcd — согласованное распределённое хранилище ключей и значений. В основном оно используется как отдельная служба координации в распределённых системах и предназначено для небольших объёмов данных, целиком помещающихся в памяти.

Как произносится etcd?

etcd произносится как /ˈɛtsiːdiː/ и означает «распределённый каталог etc».

Должны ли клиенты отправлять запросы лидеру etcd?

Raft основан на лидере: лидер обрабатывает все клиентские запросы, требующие консенсуса кластера. Однако клиенту не нужно знать, какой узел является лидером. Любой требующий консенсуса запрос, отправленный последователю, автоматически пересылается лидеру. Запросы, не требующие консенсуса (например, сериализуемое чтение), может обработать любой участник кластера.

Конфигурация

Чем различаются listen-<client,peer>-urls, advertise-client-urls и initial-advertise-peer-urls?

listen-client-urls и listen-peer-urls задают локальные адреса, к которым сервер etcd привязывается для приёма входящих соединений. Чтобы слушать порт на всех интерфейсах, укажите 0.0.0.0 как IP-адрес прослушивания.

advertise-client-urls и initial-advertise-peer-urls задают адреса, по которым клиенты или другие участники etcd должны обращаться к серверу. Объявленные адреса должны быть доступны с удалённых машин. В рабочем окружении не объявляйте адреса наподобие localhost или 0.0.0.0, поскольку удалённые машины не могут к ним подключиться.

Почему изменение --listen-peer-urls или --initial-advertise-peer-urls не обновляет объявленные URL одноранговых узлов в etcdctl member list?

Объявленные URL одноранговых узлов участника берутся из --initial-advertise-peer-urls при первоначальном запуске кластера. Изменение URL прослушивания или исходных объявленных URL после запуска участника не влияет на опубликованные адреса: во избежание расщепления конфигурации состава такие изменения должны пройти через кворум. Для обновления URL одноранговых узлов участника используйте etcdctl member update.

Развёртывание

Системные требования

Поскольку etcd записывает данные на диск, производительность сильно зависит от диска. Поэтому настоятельно рекомендуется SSD. Оценить, достаточно ли быстр диск для etcd, можно инструментом тестирования наподобие fio ; пример приведён здесь . Чтобы предотвратить снижение производительности или непреднамеренную перегрузку хранилища ключей и значений, etcd устанавливает настраиваемую квоту хранилища, по умолчанию равную 2GB. Во избежание свопинга или исчерпания памяти машина должна иметь как минимум достаточно RAM для покрытия квоты. Для обычных окружений рекомендуемый максимальный размер — 8GB; при превышении настроенного значения etcd выдаёт предупреждение при запуске. В CoreOS кластер etcd обычно развёртывается на выделенных машинах CoreOS Container Linux как минимум с двухъядерными процессорами, 2GB RAM и SSD на 80GB. Обратите внимание: производительность по своей природе зависит от нагрузки; проведите тестирование до рабочего развёртывания. Дополнительные рекомендации см. в разделе оборудование .

Наиболее стабильное рабочее окружение — операционная система Linux с архитектурой amd64; подробнее см. поддерживаемые платформы .

Почему в кластере должно быть нечётное число участников?

Для согласования обновлений состояния кластеру etcd требуется большинство узлов — кворум. В кластере из n участников кворум равен (n/2)+1. Добавление одного узла в любой кластер нечётного размера всегда увеличивает количество узлов, необходимое для кворума. Хотя добавление узла кажется улучшением благодаря большему числу машин, отказоустойчивость ухудшается: без потери кворума может отказать ровно столько же узлов, но возможных точек отказа становится больше. Если кластер больше не допускает ни одного отказа, добавлять узел до удаления неисправного опасно: если новый узел не сможет зарегистрироваться, например из-за неверного адреса, кворум будет потерян навсегда.

Каков максимальный размер кластера?

Теоретически жёсткого ограничения нет. Однако кластер etcd, вероятно, не должен содержать более семи узлов. Служба блокировок Google Chubby , похожая на etcd и много лет широко используемая в Google, рекомендует пять узлов. Кластер etcd из 5 участников выдерживает отказ двух участников, чего достаточно в большинстве случаев. Более крупные кластеры лучше переносят отказы, но производительность записи снижается, поскольку данные нужно реплицировать на большее число машин.

Какова устойчивость к отказам?

Кластер etcd работает, пока можно сформировать кворум участников. Если кворум потерян из-за временных сетевых сбоев, например разделения сети, после её восстановления etcd автоматически и безопасно возобновляет работу и восстанавливает кворум; Raft обеспечивает согласованность кластера. На случай отключения питания etcd сохраняет журнал Raft на диск, воспроизводит его до точки сбоя и возобновляет участие в кластере. При постоянном отказе оборудования узел можно удалить посредством динамического изменения конфигурации .

Рекомендуется использовать в кластере нечётное число участников. Кластер нечётного размера выдерживает столько же отказов, сколько кластер чётного размера, но содержит меньше узлов. Различие показано в таблице:

Добавление участника, доводящее размер кластера до чётного числа, не повышает отказоустойчивость. Кроме того, при разделении сети нечётное число участников гарантирует существование части с большинством, которая продолжит работу и останется источником истины после устранения разделения.

Работает ли etcd в развёртываниях между регионами или центрами обработки данных?

Развёртывание etcd в нескольких регионах повышает отказоустойчивость, поскольку участники находятся в разных доменах отказа. Цена этого — повышенная задержка запросов консенсуса из-за пересечения границ центров обработки данных. Поскольку для консенсуса etcd опирается на кворум, задержка между центрами будет заметной: на запросы должно ответить как минимум большинство участников. Кроме того, данные кластера реплицируются на все одноранговые узлы, что требует дополнительной пропускной способности.

При больших задержках конфигурация etcd по умолчанию может вызывать частые выборы или истечение тайм-аутов сигналов активности. Настройка тайм-аутов для таких развёртываний описана в разделе оптимизация .

Эксплуатация

Как создать резервную копию кластера etcd?

Для создания резервных копий etcdctl предоставляет команду snapshot. Подробнее см. резервное копирование .

Следует ли добавлять участника до удаления неисправного?

При замене узла etcd важно сначала удалить участника, а затем добавить замену.

etcd использует распределённый консенсус на основе кворума: прежде чем предложение будет зафиксировано в кластере, с ним должно согласиться большинство — (n/2)+1 участников. Предложения включают обновления ключей и значений и изменения состава кластера. Эта модель полностью предотвращает несогласованность из-за расщепления кластера, но постоянная потеря кворума катастрофична.

Применительно к составу это означает следующее. Если в кластере из 3 участников 1 участник не работает, кластер всё ещё может продвигаться: кворум равен 2, и 2 участника активны. Однако добавление нового участника в кластер из 3 участников увеличивает кворум до 3, поскольку для большинства из 4 участников нужны 3 голоса. Из-за увеличения кворума дополнительный участник не повышает отказоустойчивость: кластер по-прежнему отделяет от невосстановимого состояния отказ одного узла.

Кроме того, новый участник создаёт риск: он может оказаться неверно настроенным или неспособным присоединиться к кластеру. Тогда восстановить кворум невозможно: два участника не работают, два работают, но для изменения состава и отмены неудачного добавления нужны три голоса. По умолчанию etcd отклоняет попытки добавления участников, способные вывести кластер из строя таким образом.

Если же сначала удалить неработающего участника из состава кластера, число участников станет равно 2, а кворум останется равен 2. Последующее добавление нового участника также сохранит кворум 2. Поэтому даже при невозможности запустить новый узел его всё ещё можно удалить решением кворума оставшихся активных участников.

Почему etcd не принимает изменения состава кластера?

etcd задаёт strict-reconfig-check, чтобы отклонять запросы изменения конфигурации, приводящие к потере кворума. Отказ от кворума крайне опасен, особенно если кластер уже неисправен. При потере кворума может возникнуть желание отключить проверку ради добавления участника, однако это способно привести к полной несогласованности кластера. Для многих приложений проблема станет ещё хуже («повреждение геометрии диска» — один из наиболее пугающих вариантов).

Почему etcd теряет лидера при всплесках дисковой задержки?

Это сделано намеренно: дисковая задержка влияет на активность лидера. Предположим, лидеру кластера требуется минута для fsync обновления журнала raft на диск, а тайм-аут выборов кластера etcd равен одной секунде. Хотя лидер может обрабатывать сетевые сообщения в пределах интервала выборов, например отправлять сигналы активности, фактически он недоступен, поскольку не может зафиксировать новые предложения и ждёт медленный диск. Если кластер часто теряет лидера из-за дисковой задержки, попробуйте настроить параметры диска или времени etcd.

Что означает предупреждение etcd “request ignored (cluster ID mismatch)”?

Каждый новый кластер etcd создаёт новый идентификатор кластера на основе исходной конфигурации и заданного пользователем уникального значения initial-cluster-token. Уникальные идентификаторы защищают etcd от взаимодействия между кластерами, способного повредить кластер.

Обычно предупреждение возникает после уничтожения старого кластера и повторного использования части его адресов одноранговых узлов в новом. Если какой-либо процесс etcd старого кластера всё ещё работает, он попытается связаться с новым кластером. Новый кластер обнаружит несовпадение идентификаторов, проигнорирует запрос и выдаст предупреждение. Как правило, проблема устраняется, если адреса одноранговых узлов разных кластеров не пересекаются.

Что означает “mvcc: database space exceeded” и как это исправить?

Модель данных etcd с многоверсионным управлением параллелизмом хранит точную историю пространства ключей. Без её периодической компактизации, например посредством --auto-compaction, etcd в итоге исчерпает место в хранилище. При нехватке места etcd активирует аварийный сигнал квоты, защищая кластер от дальнейших записей. Пока сигнал активен, etcd отвечает на запросы записи ошибкой mvcc: database space exceeded.

Чтобы восстановиться после аварийного сигнала нехватки места:

1. Компактизируйте историю etcd.
2. Дефрагментируйте каждую конечную точку etcd.
3. Сбросьте аварийный сигнал.

Что означает предупреждение etcd “etcdserver/api/v3rpc: transport: http2Server.HandleStreams failed to read frame: read tcp 127.0.0.1:2379->127.0.0.1:43020: read: connection reset by peer”?

Это предупреждение gRPC появляется, когда сервер получает флаг TCP RST при преждевременном закрытии клиентских потоков. Например, клиент закрывает соединение, пока сервер gRPC ещё не обработал все кадры HTTP/2 в очереди TCP. Часть данных на стороне сервера могла быть потеряна, но это допустимо, если клиентское соединение уже закрыто.

Такое сообщение записывают только старые версии gRPC . etcd >=v3.2.13 по умолчанию записывает его на уровне DEBUG , поэтому оно видно лишь при включённом флаге --log-level=debug.

Производительность

Как тестировать производительность etcd?

Используйте инструмент benchmark . Для сравнения доступны текущие результаты тестов .

Что означает предупреждение etcd “apply entries took too long”?

После того как большинство участников etcd согласится зафиксировать запрос, каждый сервер etcd применяет его к своему хранилищу данных и сохраняет результат на диск. Даже с медленным механическим или виртуализированным сетевым диском наподобие Amazon EBS или Google PD применение запроса обычно должно занимать менее 50 миллисекунд. Если средняя длительность превышает 100 миллисекунд, etcd предупреждает, что применение записей занимает слишком много времени.

Обычно проблема вызвана медленным диском. Возможно, etcd конкурирует за диск с другими приложениями либо сам диск слишком медленный, например общий виртуализированный диск. Чтобы исключить эту причину, отслеживайте backend_commit_duration_seconds : длительность p99 должна быть меньше 25ms, что подтверждает достаточную скорость диска. Если диск слишком медленный, проблему обычно решает выделенный диск для etcd или более быстрый накопитель.

Вторая по распространённости причина — нехватка CPU. Если мониторинг показывает высокую загрузку CPU машины, вычислительной мощности для etcd может быть недостаточно. Обычно помогает перенос etcd на выделенную машину, усиление изоляции ресурсов процесса с помощью cgroups или повышение приоритета процесса сервера etcd через renice.

Дорогостоящие пользовательские запросы, обращающиеся к слишком большому числу ключей, например извлекающие всё пространство ключей, также могут вызывать длительную задержку применения. Однако запросы менее чем к нескольким сотням ключей всегда должны выполняться эффективно.

Если ни одна из рекомендаций не устраняет предупреждения, создайте проблему с подробными журналами, данными мониторинга, метриками и, по возможности, сведениями о нагрузке.

Что означает предупреждение etcd “failed to send out heartbeat on time”?

Для согласованной репликации данных и выполнения журнала etcd использует протокол консенсуса на основе лидера. Участники кластера выбирают одного лидера, а остальные становятся последователями. Для сохранения лидерства избранный лидер должен периодически отправлять последователям сигналы активности. Если сигнал не поступает в течение интервала выборов, последователи считают лидера отказавшим и запускают выборы. Если работающий лидер не отправляет сигналы вовремя, выборы ложны и, вероятно, вызваны нехваткой ресурсов. Для обнаружения таких мягких отказов etcd предупреждает о несвоевременной отправке сигнала, если лидер пропустил два интервала активности.

Обычно проблема вызвана медленным диском. Перед отправкой сигналов активности с метаданными лидеру может потребоваться сохранить метаданные на диск. Возможно, etcd конкурирует за диск с другими приложениями либо сам диск слишком медленный, например общий виртуализированный диск. Чтобы исключить эту причину, отслеживайте wal_fsync_duration_seconds : длительность p99 должна быть меньше 10ms. Если диск слишком медленный, обычно помогает выделенный диск для etcd или более быстрый накопитель. Проверить скорость диска можно инструментом наподобие fio ; пример приведён здесь .

Вторая по распространённости причина — нехватка CPU. Если мониторинг показывает высокую загрузку CPU машины, вычислительной мощности для etcd может быть недостаточно. Обычно помогает перенос etcd на выделенную машину, усиление изоляции ресурсов процесса с помощью cgroups или повышение приоритета процесса сервера etcd через renice.

Причиной также может быть медленная сеть. Если сетевые метрики между машинами etcd показывают высокую задержку или большую долю потерь, пропускной способности сети может быть недостаточно. Обычно помогает перенос участников etcd в менее загруженную сеть. Однако при развёртывании кластера между центрами обработки данных высокая задержка между участниками ожидаема. В таких развёртываниях настройте heartbeat-interval примерно равным времени прохождения туда и обратно между машинами, а election-timeout — не менее 5 * heartbeat-interval. Подробнее см. документацию по оптимизации .

Если ни одна из рекомендаций не устраняет предупреждения, создайте проблему с подробными журналами, данными мониторинга, метриками и, по возможности, сведениями о нагрузке.

Что означает предупреждение etcd “snapshotting is taking more than x seconds to finish …”?

etcd отправляет снимок всего хранилища ключей и значений для обновления медленных последователей и резервного копирования . Медленная передача снимка увеличивает MTTR; если кластер принимает данные с высокой пропускной способностью, медленные последователи могут попасть в бесконечный цикл, нуждаясь в новом снимке ещё до окончания получения предыдущего. Для обнаружения низкой производительности etcd предупреждает, если отправка снимка занимает более тридцати секунд и превышает ожидаемое время передачи через соединение 1Gbps.