Я пишу кластерный проект и хочу использовать ETCD в качестве инфраструктуры конфигурации кластера, то есть распределять изменения конфигурации внутри кластера, контролировать подключение кластера и т. Д. Мой кластер относительно мал (ограничен 16 узлами),
Наша ожидаемая рабочая нагрузка для ETCD: ~ 20 клиентов ~ 15 IOPS на клиента.~ 40B размер ключа ~ 512B value-size
Поскольку это небольшая рабочая нагрузка и поскольку работа на очень жесткой системе ограниченных ресурсов, нам нужно наложить некоторые ограничения на каждый узел etcd: * 1 ГБ ОЗУ * 50% откод гиперпотока
Я прочитал следующие ресурсы:
https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/hardware.md https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/performance.md
и понимаю ограничения на диск, процессор, сеть, памятьetc ...
Теперь у меня есть 2 возможности: 1) Запускать подмножество узлов в качестве членов etcd и отдыхать в качестве шлюза.Проблема с этим подходом состоит в том, что, когда узел, на котором выполняется член, дает сбой, мне нужно «переключить» один из шлюзов для работы в качестве «участника», чтобы всегда поддерживать кворум.Этот процесс должен быть автоматизирован без вмешательства пользователя.
2) Развернуть все узлы (до 16) для запуска члена etcd.Это развертывание не соответствует рекомендованному размеру кластера etcd, но я надеюсь, что оно сэкономит нам время на работу со шлюзами и участниками и аварийное переключение после смерти одного участника.
Вопросы:
Известны ли вам проблемы с производительностью, из-за которых у нас возникают проблемы с развертыванием такого кластера, такие как отсутствие поддержки активности, ложные выборы, увеличение задержки ответа и т. Д. *
Знаете ли вы о проекте, который реализует переключение шлюза на участника в автоматическом режиме?