Comments 6
Отличный разбор, особенно про разнесение WAL и bbolt по разным дискам — это редко где так внятно объясняют. Вопрос: в managed-кубах (EKS/GKE/AKS) мы обычно не видим ни --wal-dir, ни метрик etcd напрямую. Есть ли у вас практики, как в таких условиях хотя бы косвенно ловить «диск не тянет fsync» — по apiserver-метрикам, request latency, чему-то ещё?
Манагед кубы снимают с тебя ответственность за диски, в этом их плюс. Если смотреть универсально - единственное что торчит наружу из control plane это сам apiserver, он же точка входа для kubectl. Придется навешивать Prometheus. Можно скрапить обычный /metrics apiserver и он сам скажет сколько времени у него ушло на каждый поход в etcd (etcd_request_duration_seconds). Если она растёт именно на записи, но на чтении всё ровно, можно сделать предположение что под etcd тупит именно диск. Может послужить косвенным сигналом о здоровье етсд. еще есть счётчик объектов по каждому ресурсу. Если он только растёт и не падает, значит где-то плодятся кривые объекты. etcd может упереться в квоту и присесть в read-only. Больше ничего облако не покажет, только эти два сигнала через apiserver могут послужить маячками. Даже если etcd там крякнет остается только идти с тикетом в поддержку облака
Какие еще best practice по etcd можно добавить:
НИКОГДАне выполнять командуdefragодновременно на всех нодах etcd кластера. Это, гарантировано, на нагруженном кластере, приведет к отказу в обслуживании; да, скорее всего временно, но тем не менее, может стать триггером к более серьезным проблемам. Почему такое может случиться? Каждый раз перечислять все узлы кластера в аргументе--endpoints=дляetcdctlконтрпродуктивно, поэтому, как правило, используется env переменнаяETCD_ENDPOINTS, где прописаны все участники кластераЕсли у вас etcd до версии
v3.6.xможет быть неожиданностью, чтоauto compaction modeработает не так как ожидается. В предыдущих версиях много неразберихи: в v3.2.x, например, параметр --auto-compaction-mode отсутствует, в v3.3/4/5.x разные дефолты для cli-флага --auto-compaction-mode и в функции NewConfig() при запуске через--config-file. С версии v3.6.x это все устранили
Можно еще для синтетики прогнать fio:
[global]
time_based=1
group_reporting=1
directory=/mnt/wal
loops=1
ramp_time=5s
[etcd]
ioengine=sync
fdatasync=1
direct=0
bs=2300
iodepth=1
rw=write
nrfiles=1000
filesize=64MiB
fallocate=truncate
Это близкое к тому как пишется WAL: etcd преаллоцирует 64MiB файл, последовательно в него пишет, после заполнения текущего открывает новый файл и так далее.
Тут есть нюанс: fio не умеет преаллоцировать файлы во время работы и после заполнения удалять их, поэтому все файлы нужно создать заранее.
Задавайте число файлов (nrfiles) достаточно большим, чтобы тест не завершился за считанные секунды на SSD/NVMe.
Длительность теста по времени (runtime=) нет смысла проводить, потому как после заполнения всех преаллоцированных файлов fio начнет писать в уже заполненные файлы, что провоцирует паттерн readModifyWrite и iops падают на порядок. У меня было так 250k -> 20k.
Block size (bs) не кратен 4k, чтобы было честно, так как etcd при записи в wal никакие границы блока не выравнивает и запись может быть любого размера (разве что ограничена --max-request-bytes).
Можно добавить fio сценарий для bbolt (он, кстати, совершенно другой), но основной паттерн для etcd, все таки WAL
спасибо! обязательно дополню статью!
Я экперементировал дома с k3s на трёх нодах. etcd кластер на трёх нодах.
Каждая нода - 2 TB NVMe диск, быстрый.
Но так как там вместе и поды и etcd, то постоянно в логах жалуется на тормоза диска. Но работает.
Я вот думаю поменять настройка дискового кэша, чтобы игнорировались fsync для etcd. Хотя везде пишут, что это прям плохо. А я вот думаю: ну если рассчитывать на backup даже каждый час, то всё равно будут какие-то потери. А если потеряется что-то из-за кэша, то это всё равно на так много, как потери при восстановлении из backup.
Как ещё можно оптимизировать etcd? kine ставить не хочу.
Не трогайте лучше fsync, идея плохая. Может возникнуть мысля мол “потеряю немного, как при откате к бэкапу”, но это вообще не так. Если щелкнет свет, а все три ноды словят рассинхрон одновременно придётся сносить кластер и поднимать заново. Это хуже чем бэкап. Я бы проверила точно ли дело в диске, может гадит какой-то из процессов (частый виновник в домашних кластерах эт какой нибудь Traefik/cert-manager со своим статус-чурном). Можно погонять fio с fdatasync на директорию etcd и посмотреть p99, он если укладывается в 10ms то тормозят не диск, а может логи от конкуренции с подами за очередь. Стоит еще глянуть есть ли у дисков PLP (nvme id-ctrl флаг VWC). Если нет то у диска нет полной гарантии durability, еще один повод не трогать fsync руками. Как вариант подкрутить heartbeat-interval и election-timeout, может уменьшить лишние перевыборы лидера из логов без всякого риска. Прежде чем тюнить дальше не лишним будет посмотреть кто вообще генерит основную запись, иногда там режется большая часть нагрузки одной правкой конфига.
etcd для самых маленьких: гайд по хранилищу kubernetes