ЧаПи

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 або інші члени etcd повинні використовувати для звʼязку з сервером etcd. Рекламовані адреси повинні бути доступні з віддалених машин. Не оголошуйте адреси, такі як localhost або 0.0.0.0, для промислового налаштування, оскільки ці адреси недоступні з віддалених машин.

Чому зміна --listen-peer-urls або --initial-advertise-peer-urls не оновлює рекламовані peer URLs у etcdctl member list?

Оголошені peer URLs учасника надходять з --initial-advertise-peer-urls під час початкового завантаження кластера. Зміна URL-адрес прослуховування peer або початкових оголошених peer після завантаження учасника не вплине на експортовані оголошені peer URLs, оскільки зміни повинні пройти через кворум, щоб уникнути розщеплення конфігурації членства. Використовуйте etcdctl member update, щоб оновити peer URLs учасника.

Розгортання

Системні вимоги

Оскільки etcd записує дані на диск, його продуктивність сильно залежить від продуктивності диска. З цієї причини наполегливо рекомендується використовувати SSD. Щоб оцінити, чи достатньо швидкий диск для etcd, можна використовувати інструмент для тестування диска, такий як fio. Для прикладу, як це зробити, дивіться тут. Щоб запобігти деградації продуктивності або ненавмисному перевантаженню сховища ключ-значення, etcd застосовує налаштовувану квоту розміру сховища, стандартно встановлену на 2 ГБ. Щоб уникнути свопінгу або нестачі памʼяті, машина повинна мати принаймні стільки ж оперативної памʼяті, щоб покрити квоту. 8 ГБ — це рекомендований максимальний розмір для звичайних середовищ, і etcd попереджає при запуску, якщо налаштоване значення перевищує його. У CoreOS кластер etcd зазвичай розгортається на виділених машинах CoreOS Container Linux з двоядерними процесорами, 2 ГБ оперативної памʼяті та 80 ГБ SSD як мінімум. Зверніть увагу, що продуктивність залежить від навантаження; будь ласка, тестуйте перед розгортанням у промисловій експлуатації. Дивіться апаратне забезпечення для отримання додаткових рекомендацій.

Найстабільніше промислове середовище — операційна система Linux з архітектурою amd64; дивіться підтримувані платформи для отримання додаткової інформації.

Для чого в кластері непарна кількість членів?

Кластер etcd потребує більшості вузлів, кворуму, щоб погодитися на оновлення стану кластера. Для кластера з n членами кворум становить (n/2)+1. Для будь-якого кластера з непарною кількістю додавання одного вузла завжди збільшить кількість вузлів, необхідних для кворуму. Хоча додавання вузла до кластера з непарною кількістю здається кращим, оскільки є більше машин, відмовостійкість гірша, оскільки точно така ж кількість вузлів може вийти з ладу без втрати кворуму, але є більше вузлів, які можуть вийти з ладу. Якщо кластер перебуває в стані, коли він не може терпіти більше збоїв, додавання вузла перед видаленням вузлів небезпечно, оскільки якщо новий вузол не вдасться зареєструвати в кластері (наприклад, адреса неправильно налаштована), кворум буде втрачено назавжди.

Який максимальний розмір кластера?

Теоретично немає жорсткої межі. Однак кластер etcd, ймовірно, не повинен мати більш як сім вузлів. Служба блокування Google Chubby, подібна до etcd і широко розгорнута в Google протягом багатьох років, рекомендує запускати пʼять вузлів. Кластер etcd з 5 членами може витримати два збої членів, чого достатньо в більшості випадків. Хоча більші кластери забезпечують кращу відмовостійкість, продуктивність запису страждає, оскільки дані повинні бути репліковані на більшу кількість машин.

Що таке відмовостійкість?

Кластер etcd працює, поки можна встановити кворум членів. Якщо кворум втрачено через тимчасові мережеві збої (наприклад, розділення), etcd автоматично і безпечно відновлюється після відновлення мережі та відновлення кворуму; Raft забезпечує консистентність кластера. У разі втрати живлення etcd зберігає журнал Raft на диск; etcd відтворює журнал до точки збою та відновлює участь у кластері. У разі постійного апаратного збою вузол може бути видалений з кластера через переконфігурацію під час виконання.

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

Додавання члена, щоб збільшити розмір кластера до парного числа, не забезпечує додаткової відмовостійкості. Так само під час розділення мережі непарна кількість членів гарантує, що завжди буде більшість, яка зможе продовжувати працювати та бути джерелом істини, коли розділення закінчиться.

Чи працює etcd у розгортаннях між регіонами або між центрами обробки даних?

Розгортання etcd між регіонами покращує відмовостійкість etcd, оскільки члени знаходяться в окремих доменах відмов. Вартість вища через затримку запитів консенсусу pf межі центрів обробки даних. Оскільки etcd покладається на кворум членів для консенсусу, затримка через центри обробки даних буде дещо вираженою, оскільки принаймні більшість членів кластера повинні відповідати на запити консенсусу. Крім того, дані кластера повинні бути репліковані на всі вузли, тому також будуть витрати на пропускну здатність.

З довшими затримками, стандартна конфігурація etcd може спричинити часті вибори або тайм-аути в тактах. Дивіться налаштування для коригування тайм-аутів для розгортань з високою затримкою.

Експлуатація

Як зробити резервну копію кластера etcd?

etcdctl надає команду snapshot для створення резервних копій. Дивіться резервне копіювання для отримання додаткової інформації.

Чи слід додавати члена перед видаленням несправного члена?

При заміні вузла etcd важливо спочатку видалити члена, а потім додати його заміну.

etcd використовує розподілений консенсус на основі моделі кворуму; (n/2)+1 членів, більшість, повинні погодитися з пропозицією, перш ніж вона може бути прийнята в кластер. Ці пропозиції включають оновлення ключ-значення та зміни членства. Ця модель повністю уникає будь-якої можливості синдрому розділеного мозку (split-brain¹). Недоліком є те, що постійна втрата кворуму є катастрофічною.

Як це стосується членства: якщо кластер з 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 захищений від взаємодії між кластерами, що може пошкодити кластер.

Зазвичай це попередження зʼявляється після знищення старого кластера, а потім повторного використання деяких адрес peer для нового кластера. Якщо будь-який процес etcd зі старого кластера все ще працює, він спробує звʼязатися з новим кластером. Новий кластер розпізнає невідповідність ідентифікатора кластера, потім ігнорує запит і видає це попередження. Це попередження часто усувається шляхом забезпечення того, щоб адреси peer серед різних кластерів не перетиналися.

Що означає “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’s EBS або Google’s PD, застосування запиту зазвичай займає менше 50 мілісекунд. Якщо середня тривалість застосування перевищує 100 мілісекунд, etcd попереджає, що записи займають занадто багато часу для застосування.

Зазвичай ця проблема викликана повільним диском. Диск може відчувати конкуренцію між etcd та іншими застосунками, або диск просто занадто повільний (наприклад, спільний віртуалізований диск). Щоб виключити повільний диск як причину цього попередження, моніторьте backend_commit_duration_seconds (тривалість p99 повинна бути менше 25 мс), щоб підтвердити, що диск досить швидкий. Якщо диск занадто повільний, призначення виділеного диска для etcd або використання швидшого диска зазвичай вирішить проблему.

Другою найпоширенішою причиною є голодування процесора. Якщо моніторинг використання процесора машини показує високе завантаження, можливо, недостатньо обчислювальної потужності для etcd. Переміщення etcd на виділену машину, збільшення ізоляції ресурсів процесу за допомогою cgroups або підвищення пріоритету процесу сервера etcd зазвичай вирішує проблему.

Дорогі запити користувачів, які отримують доступ до занадто багатьох ключів (наприклад, отримання всього простору ключів), також можуть спричинити довгі затримки застосування. Доступ до менше кількох сотень ключів на запит, однак, завжди повинен бути продуктивним.

Якщо жодна з наведених вище пропозицій не усуває попередження, будь ласка, відкрийте тікет з детальним журналюванням, моніторингом, метриками та, за бажанням, інформацією про навантаження.

Що означає попередження etcd “failed to send out heartbeat on time”?

etcd використовує протокол консенсусу на основі лідера для консистентної реплікації даних та виконання журналу. Члени кластера обирають одного лідера, всі інші члени стають послідовниками. Обраний лідер повинен періодично надсилати такти своїм послідовникам, щоб підтримувати своє лідерство. Послідовники вважають, що лідер вийшов з ладу, якщо не отримують такти протягом інтервалу виборів і запускають вибори. Якщо лідер не надсилає свої такти вчасно, але все ще працює, вибори є помилковими і, ймовірно, викликані недостатніми ресурсами. Щоб виявити ці мʼякі збої, якщо лідер пропускає два інтервали тактів, etcd попереджає, що не вдалося вчасно надіслати такти.

Зазвичай ця проблема викликана повільним диском. Перш ніж лідер надішле такти з прикріпленими метаданими, можливо, йому потрібно зберегти метадані на диск. Диск може відчувати конкуренцію між etcd та іншими застосунками, або диск просто занадто повільний (наприклад, спільний віртуалізований диск). Щоб виключити повільний диск як причину цього попередження, моніторьте wal_fsync_duration_seconds (тривалість p99 повинна бути менше 10 мс), щоб підтвердити, що диск досить швидкий. Якщо диск занадто повільний, призначення виділеного диска для etcd або використання швидшого диска зазвичай вирішить проблему. Щоб визначити, чи достатньо швидкий диск для etcd, можна використовувати інструмент для тестування, такий як fio. Прочитайте тут для прикладу.

Другою найпоширенішою причиною є голодування процесора. Якщо моніторинг використання процесора машини показує високе завантаження, можливо, недостатньо обчислювальної потужності для etcd. Переміщення etcd на виділену машину, збільшення ізоляції ресурсів процесу за допомогою cgroups або підвищення пріоритету процесу сервера etcd зазвичай вирішує проблему.

Повільна мережа також може спричинити цю проблему. Якщо мережеві метрики між машинами etcd показують довгі затримки або високий рівень втрат, можливо, недостатньо мережевої потужності для etcd. Переміщення членів etcd на менш завантажену мережу зазвичай вирішує проблему. Однак, якщо кластер etcd розгорнуто між центрами обробки даних, очікується довга затримка між членами. Для таких розгортань налаштуйте конфігурацію heartbeat-interval так, щоб вона приблизно відповідала часу кругового проходження між машинами, а конфігурацію election-timeout — щоб вона була принаймні 5 * heartbeat-interval. Дивіться документацію з налаштування для отримання детальної інформації.

Якщо жодна з наведених вище пропозицій не усуває попередження, будь ласка, відкрийте тікет з детальним журналюванням, моніторингом, метриками та, за бажанням, інформацією про навантаження.

Що означає попередження etcd “snapshotting is taking more than x seconds to finish …”?

etcd надсилає знімок свого повного сховища ключ-значення для оновлення повільних послідовників та для резервних копій. Час повільної передачі знімків збільшує MTTR; якщо кластер приймає дані з високою пропускною здатністю, повільні послідовники можуть потрапити в стан живого блокування, потребуючи нового знімка до завершення отримання знімка. Щоб виявити повільну продуктивність знімків, etcd попереджає, коли надсилання знімка займає понад тридцять секунд і перевищує очікуваний час передачі для зʼєднання 1 Гбіт/с.