Навчання on etcd

Модель даних

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Дизайн клієнта etcd

Mon, 01 Jan 0001 00:00:00 +0000

Дизайн клієнта etcd

Gyuho Lee (github.com/gyuho, Amazon Web Services, Inc.), Joe Betz (github.com/jpbetz, Google Inc.)

Вступ

Сервер etcd довів свою надійність за роки тестування з інʼєкціями відмов. Більшість складної логіки застосунків вже обробляється сервером etcd та його сховищами даних (наприклад, членство в кластері є прозорим для клієнтів, з пересиланням пропозицій на лідера на рівні Raft). Хоча компоненти сервера є правильними, його поєднання з клієнтом вимагає іншого набору складних протоколів для забезпечення його правильності та високої доступності в умовах збоїв. Ідеально, сервер etcd надає один логічний вигляд кластера з багатьох фізичних машин, а клієнт реалізує автоматичне перемикання між репліками. Цей документ описує архітектурні рішення клієнта та деталі їх реалізації.

Дизайн learner etcd

Mon, 01 Jan 0001 00:00:00 +0000

etcd Learner

Gyuho Lee (github.com/gyuho, Amazon Web Services, Inc.), Joe Betz (github.com/jpbetz, Google Inc.)

Передумови

Переналаштування членства було однією з найбільших операційних проблем. Розгляньмо поширені проблеми.

1. Новий член кластера перевантажує Лідера

Новий член etcd починає без даних, тому вимагає більше оновлень від лідера, поки не наздожене журнали лідера. Тоді мережа лідера більш ймовірно буде перевантажена, блокуючи або скидаючи такти лідера до послідовників. У такому випадку послідовник може вийти з тайм-ауту виборів і почати нові вибори лідера. Тобто кластер з новим членом більш вразливий до виборів лідера. І вибори лідера, і подальше розповсюдження оновлень новому члену схильні викликати періоди недоступності кластера (див. Рисунок 1).

Дизайн автентифікації в etcd v3

Mon, 01 Jan 0001 00:00:00 +0000

Чому не використовувати систему автентифікації v2?

Протокол v3 використовує gRPC як транспорт замість RESTful інтерфейсу, як у v2. Цей новий протокол надає можливість покращити дизайн v2. Наприклад, автентифікація v3 базується на зʼєднанні, а не на кожному запиті, як у v2. Крім того, семантика автентифікації v2 на практиці є незручною з погляду узгодженості, що буде описано в наступних розділах. Для v3 є чіткий опис та реалізація механізму автентифікації, який виправляє недоліки системи автентифікації v2.

etcd API

Mon, 01 Jan 0001 00:00:00 +0000

Цей документ призначений для надання огляду центрального дизайну API v3 etcd. Це не слід плутати з API v2 etcd, який був визнаний застарілим з випуском etcd v3.5. Він не є всеосяжним, але має на меті зосередитися на основних ідеях, необхідних для розуміння etcd без відволікання на менш поширені виклики API. Усі API etcd визначені в gRPC сервісах, які категоризують віддалені виклики процедур (RPC), зрозумілі серверу etcd. Повний перелік усіх RPC etcd задокументований у markdown у списку gRPC API.

Файли постійного сховища etcd

Mon, 01 Jan 0001 00:00:00 +0000

Цей документ пояснює формат постійного сховища etcd: іменування, вміст та інструменти, які дозволяють розробникам перевіряти їх. У майбутньому документ буде доповнюватися змінами в моделі зберігання даних. Цей документ призначений для розробників etcd, щоб допомогти їм у відновленні даних.

Передумови

Наступні статті надають корисну інформацію для цього документа:

Огляд моделі даних etcd
Огляд Raft: https://raft.github.io/raft.pdf (особливо розділ “5.3 Реплікація журналу”).

Огляд

Довготривалі файли

Назва файлу	Основна мета
./member/snap/db	bbolt b+tree, що зберігає всі застосовані дані, інформацію про авторизацію членства та метадані. Воно знає, який останній застосований індекс журналу WAL ("consistent_index").
./member/snap/0000000000000002-0000000000049425.snap ./member/snap/0000000000000002-0000000000061ace.snap	Періодичні знімки старого сховища v2, що містять: основну інформацію про членство версію etcd Гарантії API etcd Mon, 01 Jan 0001 00:00:00 +0000 etcd — це консистентне та надійне сховище ключ-значення. Сховище ключ-значення доступне через gRPC Services. etcd забезпечує найсильніші гарантії консистентності та надійності для розподіленої системи. Ця специфікація перераховує гарантії API, які надає etcd. API для розгляду KV API Range Put Delete Transaction Watch API Watch Lease API Grant [Revoke] Keep alive KV API дозволяє безпосередньо читати та маніпулювати сховищем ключ-значення. Watch API дозволяє підписуватися на зміни в сховищі ключ-значення. Lease API дозволяє призначати час життя ключа. etcd у порівнянні з іншими сховищами ключі-значення Mon, 01 Jan 0001 00:00:00 +0000 Назва “etcd” походить від двох ідей: теки unix “/etc” та “d"istributed систем. Тека “/etc” є місцем для зберігання конфігураційних даних для однієї системи, тоді як etcd зберігає конфігураційну інформацію для великих розподілених систем. Отже, “d"istributed “/etc” — це “etcd”. etcd розроблено як загальну основу для великих розподілених систем. Це системи, які ніколи не терплять “розділення мозку”¹ і готові пожертвувати доступністю для досягнення цієї мети. etcd зберігає метадані послідовно та відмовостійко. Кластер etcd призначений для забезпечення сховища ключ-значення з найкращою стабільністю, надійністю, масштабованістю та продуктивністю. Глосарій Mon, 01 Jan 0001 00:00:00 +0000 Цей документ визначає різні терміни, що використовуються в документації, командному рядку та вихідному коді etcd. Тривога (Alarm) Сервер etcd спричиняє тривогу, коли кластер потребує втручання оператора для збереження надійності. Автентифікація (Authentication) Автентифікація керує дозволами доступу користувачів до ресурсів etcd. Клієнт (Client) Клієнт підключається до кластера etcd для виконання сервісних запитів, таких як отримання пар ключ-значення, запис даних або спостереження за оновленнями. Кластер (Cluster) Кластер складається з кількох учасників.

Назва файлу

Основна мета

./member/snap/db

bbolt b+tree, що зберігає всі застосовані дані, інформацію про авторизацію членства та метадані. Воно знає, який останній застосований індекс журналу WAL ("consistent_index").

./member/snap/0000000000000002-0000000000049425.snap
./member/snap/0000000000000002-0000000000061ace.snap

Періодичні знімки старого сховища v2, що містять:

основну інформацію про членство
версію etcd

Гарантії API etcd

Mon, 01 Jan 0001 00:00:00 +0000

etcd — це консистентне та надійне сховище ключ-значення. Сховище ключ-значення доступне через gRPC Services. etcd забезпечує найсильніші гарантії консистентності та надійності для розподіленої системи. Ця специфікація перераховує гарантії API, які надає etcd.

API для розгляду

KV API
- Range
- Put
- Delete
- Transaction
Watch API
- Watch
Lease API
- Grant
- [Revoke]
- Keep alive

KV API дозволяє безпосередньо читати та маніпулювати сховищем ключ-значення. Watch API дозволяє підписуватися на зміни в сховищі ключ-значення. Lease API дозволяє призначати час життя ключа.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Глосарій

Mon, 01 Jan 0001 00:00:00 +0000

Цей документ визначає різні терміни, що використовуються в документації, командному рядку та вихідному коді etcd.

Тривога (Alarm)

Сервер etcd спричиняє тривогу, коли кластер потребує втручання оператора для збереження надійності.

Автентифікація (Authentication)

Автентифікація керує дозволами доступу користувачів до ресурсів etcd.

Клієнт (Client)

Клієнт підключається до кластера etcd для виконання сервісних запитів, таких як отримання пар ключ-значення, запис даних або спостереження за оновленнями.

Кластер (Cluster)

Кластер складається з кількох учасників.