etcd у порівнянні з іншими сховищами ключі-значення

Назва “etcd” походить від двох ідей: теки unix “/etc” та “d"istributed систем. Тека “/etc” є місцем для зберігання конфігураційних даних для однієї системи, тоді як etcd зберігає конфігураційну інформацію для великих розподілених систем. Отже, “d"istributed “/etc” — це “etcd”.

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

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

Використання

• Container Linux від CoreOS: Застосунки, що працюють у Container Linux, отримують автоматичні оновлення ядра Linux без простоїв. Container Linux використовує locksmith для координації оновлень. Locksmith реалізує розподілений семафор через etcd, щоб забезпечити перезавантаження лише частини кластера в будь-який момент часу.
• Kubernetes зберігає конфігураційні дані в etcd для виявлення сервісів та управління кластером; послідовність etcd є критично важливою для правильного планування та роботи сервісів. API сервер Kubernetes зберігає стан кластера в etcd. Він використовує watch API etcd для моніторингу кластера та впровадження критичних змін конфігурації.

Порівняльна таблиця

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

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

ZooKeeper

ZooKeeper вирішує ту саму проблему, що й etcd: координація розподіленої системи та зберігання метаданих. Однак, etcd має розкіш ретроспективного огляду на інженерний та експлуатаційний досвід проєктування та впровадження ZooKeeper. Уроки, отримані з Zookeeper, безумовно, вплинули на дизайн etcd, допомагаючи йому підтримувати великомасштабні системи, такі як Kubernetes. Серед покращень, які etcd зробила у порівнянні з Zookeeper, можна виділити наступні:

• Динамічна переконфігурація членства кластера
• Стабільне читання/запис під високим навантаженням
• Модель даних з багатоверсійним контролем паралелізму
• Надійний моніторинг ключів, який ніколи не пропускає події
• Примітиви оренди, що розʼєднують зʼєднання від сесій
• API для безпечних розподілених спільних блокувань

Крім того, etcd підтримує широкий спектр мов та фреймворків з коробки. У той час як Zookeeper має свій власний унікальний протокол Jute RPC, який обмежує його підтримувані мовні привʼязки, клієнтський протокол etcd побудований на основі gRPC, популярного фреймворку RPC з мовними привʼязками для go, C++, Java та інших. Так само, gRPC може бути серіалізований у JSON через HTTP, тому навіть загальні командні утиліти, такі як curl, можуть спілкуватися з ним. Оскільки системи можуть вибирати з різних варіантів, вони будуються на основі etcd з нативними інструментами, а не навколо etcd з єдиним фіксованим набором технологій.

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

Consul

Consul є комплексною системою виявлення сервісів. Він надає вбудовані перевірки справності, виявлення збоїв та DNS-сервіси. Крім того, Consul надає сховище ключ-значення з RESTful HTTP API. Як це виглядає в Consul 1.0, система зберігання не масштабується так добре, як інші системи, такі як etcd або Zookeeper, в операціях ключ-значення; системи, що вимагають мільйонів ключів, страждатимуть від високих затримок та тиску на памʼять. API ключ-значення відсутній, зокрема, багатоверсійні ключі, умовні транзакції та надійні потокові спостереження.

etcd та Consul розвʼязують різні проблеми. Якщо ви шукаєте розподілене послідовне сховище ключ-значення, etcd є кращим вибором над Consul. Якщо ви шукаєте комплексне виявлення сервісів у кластері, etcd не матиме достатньо функцій; вибирайте Kubernetes, Consul або SmartStack.

NewSQL (Cloud Spanner, CockroachDB, TiDB)

І etcd, і бази даних NewSQL (наприклад, Cockroach, TiDB, Google Spanner) забезпечують сильні гарантії послідовності даних з високою доступністю. Однак, значно різні параметри дизайну систем призводять до значно різних клієнтських API та характеристик продуктивності.

Бази даних NewSQL призначені для горизонтального масштабування між центрами обробки даних. Ці системи зазвичай розподіляють дані між кількома групами послідовної реплікації (шардами), потенційно віддаленими, зберігаючи набори даних обсягом у терабайти та більше. Таке масштабування робить їх поганими кандидатами для розподіленої координації, оскільки вони мають довгі затримки через очікування на цикли та очікують оновлень з переважно локалізованими графами залежностей. Дані організовані в таблиці, включаючи SQL-стиль запитів з багатшими семантиками, ніж в etcd, але коштом додаткової складності для обробки, планування та оптимізації запитів.

Коротко кажучи, вибирайте etcd для зберігання метаданих або координації розподілених застосунків. Якщо потрібно зберігати більше кількох ГБ даних або потрібні повні SQL-запити, вибирайте базу даних NewSQL.

Використання etcd для метаданих

etcd реплікує всі дані в межах однієї послідовної групи реплікації. Для зберігання до кількох ГБ даних з послідовним порядком це найефективніший підхід. Кожна модифікація стану кластера, яка може змінити кілька ключів, отримує глобальний унікальний ідентифікатор, званий ревізією в etcd, з монотонно зростаючого лічильника для розуміння порядку. Оскільки є лише одна група реплікації, запит на модифікацію повинен пройти лише через протокол raft для коміту. Обмежуючи консенсус однією групою реплікації, etcd отримує розподілену послідовність з простим протоколом, досягаючи низької затримки та високої пропускної здатності.

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

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

Використання etcd для розподіленої координації

etcd має примітиви розподіленої координації, такі як спостереження за подіями, лізинг, вибори та розподілені спільні блокування з коробки (Зверніть увагу, що у випадку розподіленого спільного блокування користувачі повинні бути обізнані про його неочевидні властивості. Деталі описані нижче). Ці примітиви підтримуються і супроводжуються розробниками etcd; передача цих примітивів зовнішнім бібліотекам дозволяє уникнути відповідальності за розробку фундаментального розподіленого програмного забезпечення, по суті залишаючи систему незавершеною. Бази даних NewSQL зазвичай очікують, що ці примітиви розподіленої координації будуть створені третіми сторонами. Так само, ZooKeeper відомий своєю окремою та незалежною бібліотекою координаційних рецептів. Consul, який надає нативний API блокування, навіть просити вибачення, що це “не є надійним методом”.

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

Для розподіленої координації вибір etcd може допомогти запобігти головному болю в роботі та заощадити інженерні зусилля.

Примітки щодо використання блокування та оренди

etcd надає API блокування, які базуються на механізмі оренди та його реалізації в etcd. Основна ідея механізму оренди полягає в тому, що сервер надає токен, який називається орендою (lease), клієнту, що його запитує. Коли сервер надає оренду, він асоціює з нею TTL. Коли сервер виявляє проходження часу, що перевищує TTL, він відкликає оренду. Поки клієнт має не відкликану оренду, він може стверджувати, що володіє доступом до ресурсу, повʼязаного з орендою. У випадку etcd, ресурсом є ключ у просторі ключів etcd. etcd надає API блокування з цією схемою. Однак, API блокування не можуть бути використані як механізм взаємного виключення самі по собі. API називаються блокуванням через історичні причини. API блокування можуть, однак, бути використаними як механізм оптимізації взаємного виключення, як описано нижче.

Найважливіший аспект механізму оренди полягає в тому, що TTL визначається як фізичний інтервал часу. І сервер, і клієнт вимірюють проходження часу своїми власними годинниками. Це дозволяє ситуацію, коли сервер відкликає оренду, але клієнт все ще стверджує, що володіє орендою.

Як же механізм оренди гарантує взаємне виключення механізму блокування? Насправді сам механізм оренди не гарантує взаємного виключення. Володіння орендою не може гарантувати, що власник утримує блокування ресурсу.

У випадку контролю взаємного доступу до ключів самого etcd за допомогою блокування etcd, взаємне виключення реалізується на основі механізму перевірки номера версії (іноді його називають порівнянням і заміною в інших системах, таких як Consul). У RPC etcd, таких як Put або Txn, ми можемо вказати необхідні умови щодо номера ревізії та ідентифікатора оренди для операцій. Якщо умови не виконуються, операція може зазнати невдачі. За допомогою цього механізму etcd надає розподілене блокування для клієнтів. Це означає, що клієнт знає, що він отримує блокування ключа, коли його запити успішно виконуються кластером etcd.

У літературі про розподілене блокування описані подібні дизайни:

• У статті про Chubby введено концепцію послідовника. Ми інтерпретуємо, що послідовник майже такий самий, як комбінація номера ревізії та ідентифікатора оренди в etcd.
• У Як робити розподілене блокування Мартін Клеппманн ввів ідею захисного токена. Автори інтерпретують, що захисний токен — це номер ревізії у випадку etcd. У Примітці про захисні токени та розподілені блокування Флавіо Жункейра розглянув, як ідея захисного токена повинна бути реалізована у випадку з Zookeeper.
• У Практичні використання синхронізованих годинників у розподілених системах ми можемо знайти опис, що Thor реалізує механізм розподіленого блокування на основі перевірки номера версії та оренди.

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

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