Рекомендації щодо обладнання

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

CPUs

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

Памʼять

etcd займає відносно мало памʼяті, але його продуктивність все одно залежить від наявності достатньої кількості памʼяті. Сервер etcd буде активно кешувати дані ключ-значення і витрачатиме більшу частину памʼяті, що залишилася, на відстеження спостерігачів. Зазвичай 8 ГБ достатньо. Для важких розгортань з тисячами спостерігачів і мільйонами ключів виділіть від 16 ГБ до 64 ГБ памʼяті відповідно.

Диски

Швидкі диски є найбільш важливим фактором для продуктивності та стабільності розгортання etcd.

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

etcd дуже чутлива до затримки запису на диск. Зазвичай потрібно 50 послідовних операцій вводу-виводу (наприклад, диск зі швидкістю обертання 7200 об/хв). Для високонавантажених кластерів рекомендується 500 послідовних IOPS (наприклад, типовий локальний SSD або високопродуктивний віртуалізований блоковий пристрій). Зверніть увагу, що більшість хмарних провайдерів публікують паралельні IOPS, а не послідовні IOPS; опубліковані паралельні IOPS можуть бути в 10 разів більшими, ніж послідовні IOPS. Для вимірювання реальної послідовної IOPS ми рекомендуємо використовувати інструмент дискового тестування, такий як diskbench або fio.

etcd вимагає невеликої пропускної здатності диска, але більша пропускна здатність диска забезпечує швидший час відновлення, коли учасник кластера, що вийшов з ладу, повинен наздогнати кластер. Зазвичай 10 МБ/с дозволяє відновити 100 МБ даних за 15 секунд. Для великих кластерів рекомендується 100 МБ/с або вище для відновлення 1 ГБ даних за 15 секунд.

Коли це можливо, створіть резервну копію etcd на SSD. SSD зазвичай забезпечує менші затримки при записі і меншу дисперсію, ніж диск, що обертається, таким чином підвищуючи стабільність і надійність etcd. Якщо ви використовуєте диск, що обертається, придбайте найшвидші диски (15 000 об/хв). Використання RAID 0 також є ефективним способом збільшити швидкість диска, як для дисків, що обертаються, так і для SSD. При наявності щонайменше трьох членів кластера, дзеркальне відображення та/або паритетні варіанти RAID не потрібні; послідовна реплікація etcd вже забезпечує високий рівень доступності.

Мережа

Розгортання etcd з кількома учасниками виграє від швидкої та надійної мережі. Для того, щоб etcd був узгодженим і толерантним до перерозподілу розділів, ненадійна мережа з перебоями в роботі з розділами призведе до низької доступності. Низька затримка гарантує, що учасники etcd можуть спілкуватися швидко. Висока пропускна здатність може скоротити час на відновлення несправного елемента etcd. 1GbE достатньо для звичайних розгортань etcd. Для великих кластерів etcd мережа 10GbE скоротить середній час відновлення.

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

Приклади конфігурацій обладнання

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

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

Невеликий кластер

Малий кластер обслуговує менше ніж 100 клієнтів, менше ніж 200 запитів на секунду і зберігає не більше 100 МБ даних.

Приклад робочого навантаження застосунку: 50-вузловий кластер Kubernetes

Середній кластер

Середній кластер обслуговує менше ніж 500 клієнтів, менше ніж 1 000 запитів на секунду і зберігає не більше 500 МБ даних.

Приклад робочого навантаження застосунку: 250-вузловий кластер Kubernetes

Великий кластер

Великий кластер обслуговує менше ніж 1 500 клієнтменше ніж 10 000 000 запитів на секунду і зберігає не більше 1 ГБ даних.

Приклад робочого навантаження застосунку: 1000-вузловий кластер Kubernetes

Дуже великий кластер

Кластер xLarge обслуговує понад 1 500 клієнтів, понад 10 000 запитів на секунду і зберігає понад 1 ГБ даних.

Приклад робочого навантаження застосунку: 3000-вузловий кластер Kubernetes