Обслуговування

Огляд

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

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

Збереження журналу Raft

etcd --snapshot-count налаштовує кількість застосованих записів Raft, які зберігаються в памʼяті перед стисненням. Коли досягається --snapshot-count, сервер спочатку зберігає дані знімка на диск, а потім обрізає старі записи. Коли повільний послідовник запитує журнали до стисненого індексу, лідер надсилає знімок, змушуючи послідовника перезаписати свій стан.

Вищий --snapshot-count зберігає більше записів Raft у памʼяті до знімка, що призводить до постійного вищого використання памʼяті. Оскільки лідер зберігає останні записи Raft довше, повільний послідовник має більше часу, щоб наздогнати перед знімком лідера. --snapshot-count є компромісом між вищим використанням памʼяті та кращою доступністю повільних послідовників.

З версії v3.2 стандартне значення --snapshot-count змінено з 10 000 на 100 000.

З погляду продуктивності, --snapshot-count більш як 100 000 може вплинути на пропускну здатність запису. Більша кількість обʼєктів у памʼяті може уповільнити фазу маркування Go GC runtime.scanobject, а рідкісне відновлення памʼяті уповільнює виділення. Продуктивність варіюється залежно від робочих навантажень і системних середовищ. Однак, загалом, занадто часте стиснення впливає на доступність кластера та пропускну здатність запису. Занадто рідкісне стиснення також шкідливе, оскільки створює занадто великий тиск на збирач сміття Go. Дивіться Розуміння аспектів продуктивності etcd та Raft для отримання додаткових результатів досліджень.

Стиснення історії: v3 API База даних ключ-значення

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

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

Стиснення, ініційоване etcdctl, працює наступним чином:

# стиснути до ревізії 3
$ etcdctl compact 3

Ревізії до ревізії стиснення стають недоступними:

$ etcdctl get --rev=2 somekey
Error:  rpc error: code = 11 desc = etcdserver: mvcc: required revision has been compacted

Автоматичне стиснення

etcd можна налаштувати на автоматичне стиснення ключового простору за допомогою опцій --auto-compaction-mode та --auto-compaction-retention. Існує два режими стиснення: periodic (стандартно) та revision.

Періодичне стиснення

Періодичне стиснення зберігає часове вікно історії ключового простору:

# зберігати одну годину історії
$ etcd --auto-compaction-retention=1h

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

Коли період збереження перевищує 1 годину, etcd виконує стиснення щогодини, зберігаючи повне вікно збереження. Коли період збереження становить 1 годину або менше, etcd виконує стиснення з інтервалом періоду збереження.

Наприклад, з --auto-compaction-retention=10h etcd чекає 10 годин для першого стиснення, а потім виконує стиснення щогодини:

0hr  (rev = 1)
1hr  (rev = 10)
...
8hr  (rev = 80)
9hr  (rev = 90)
10hr (rev = 100, Compact(1))
11hr (rev = 110, Compact(10))
...

Рекомендовані значення залежать від випадку використання:

• Часті оновлення тих самих ключів: короткий період, наприклад 1h або 30m
• Рідкісні оновлення: довший період, наприклад 24h, 48h або 72h
• Загальне стандартне значення: 10h

Стиснення за ревізіями

Стиснення за ревізіями зберігає фіксовану кількість ревізій:

# зберігати 1000 ревізій
$ etcd --auto-compaction-mode=revision --auto-compaction-retention=1000

etcd перевіряє кожні 5 хвилин і виконує стиснення на "latest revision" - 1000. Наприклад, коли остання ревізія становить 30000, він стискає на ревізії 29000.

Дефрагментація

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

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

Щоб дефрагментувати учасника etcd, використовуйте команду etcdctl defrag:

$ etcdctl defrag
Finished defragmenting etcd member[127.0.0.1:2379]

Запустіть операції дефрагментації для всіх точок доступу у кластері, повʼязаних зі стандартною точкою доступу:

$ etcdctl defrag --cluster
Finished defragmenting etcd member[http://127.0.0.1:2379]
Finished defragmenting etcd member[http://127.0.0.1:22379]
Finished defragmenting etcd member[http://127.0.0.1:32379]

Щоб дефрагментувати теку даних etcd безпосередньо, коли etcd не працює, використовуйте команду:

etcdutl defrag --data-dir <path-to-etcd-data-dir>

Квота на дисковий простір

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

Стандартно etcd встановлює консервативну квоту на дисковий простір, яка підходить для більшості застосунків, але її можна налаштувати у командному рядку в байтах:

# встановити дуже маленьку квоту 16 МіБ
$ etcd --quota-backend-bytes=$((16*1024*1024))

Квоту на дисковий простір можна викликати за допомогою циклу:

# заповнити ключовий простір
$ while [ 1 ]; do dd if=/dev/urandom bs=1024 count=1024  | ETCDCTL_API=3 etcdctl put key  || break; done
...
Error:  rpc error: code = 8 desc = etcdserver: mvcc: database space exceeded
# підтвердити, що квота на дисковий простір перевищена
$ ETCDCTL_API=3 etcdctl --write-out=table endpoint status
+----------------+------------------+-----------+---------+-----------+-----------+------------+
|    ENDPOINT    |        ID        |  VERSION  | DB SIZE | IS LEADER | RAFT TERM | RAFT INDEX |
+----------------+------------------+-----------+---------+-----------+-----------+------------+
| 127.0.0.1:2379 | bf9071f4639c75cc | 2.3.0+git | 18 MB   | true      |         2 |       3332 |
+----------------+------------------+-----------+---------+-----------+-----------+------------+
# підтвердити, що тривогу здійнято
$ ETCDCTL_API=3 etcdctl alarm list
memberID:13803658152347727308 alarm:NOSPACE

Видалення надлишкових даних ключового простору та дефрагментація бази даних бекенду поверне кластер у межі квоти:

# отримати поточну ревізію
$ rev=$(ETCDCTL_API=3 etcdctl --endpoints=:2379 endpoint status --write-out="json" | egrep -o '"revision":[0-9]*' | egrep -o '[0-9].*')
# стиснути всі старі ревізії
$ ETCDCTL_API=3 etcdctl compact $rev
compacted revision 1516
# дефрагментувати надлишковий простір
$ ETCDCTL_API=3 etcdctl defrag
Завершено дефрагментацію учасника etcd[127.0.0.1:2379]
# зняти тривогу
$ ETCDCTL_API=3 etcdctl alarm disarm
memberID:13803658152347727308 alarm:NOSPACE
# перевірити, що записи знову дозволені
$ ETCDCTL_API=3 etcdctl put newkey 123
OK

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

etcd_debugging_mvcc_db_total_size_in_bytes перейменовано на etcd_mvcc_db_total_size_in_bytes з версії v3.4.

Резервне копіювання знімків

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

Знімок робиться за допомогою etcdctl:

$ etcdctl snapshot save backup.db
$ etcdutl --write-out=table snapshot status backup.db
+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| fe01cf57 |       10 |          7 | 2.1 MB     |
+----------+----------+------------+------------+