Автономне тестування надійності etcd

Це допис із блогу CNCF, яким ми також ділимося з нашою спільнотою.

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

Покращення тестування надійності etcd

Багато критично важливих систем залежать від правильної та узгодженої роботи etcd, зокрема як основного сховища даних для Kubernetes. Після деяких проблем із випуском v3.5 підтримувачі etcd розробили нову структуру тестування надійності для кращого тестування коректності за різних сценаріїв збоїв. Щоб ще більше розширити наші можливості тестування, ми інтегрували детерміновану платформу симуляційного тестування від Antithesis у наш робочий процес.

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

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

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

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

Як ми тестували

Наші цілі для цих зусиль з тестування полягали в тому, щоб:

1. Перевірити надійність etcd v3.6.
2. Покращити якість програмного забезпечення etcd, знаходячи та виправляючи помилки.
3. Розширити нашу поточну структуру тестування автономним тестуванням.

Ми запускали наші наявні тести надійності на симуляційній платформі Antithesis, тестуючи кластер etcd із 3 вузлів та 1 вузла проти різноманітних збоїв, включно з:

• Мережеві збої: затримка, перевантаження та розділення.
• Збої на рівні контейнера: призупинення потоків, завершення процесів, коливання тактової частоти та обмеження продуктивності CPU.

Ми тестували старіші версії etcd із відомими помилками для перевірки методології тестування, а також наші стабільні випуски (3.4, 3.5, 3.6) та головну гілку розробки. Загалом ми провели 830 годин тестування, що дорівнювало 4.5 рокам використання.

Що ми знайшли

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

Ось деякі з ключових висновків:

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

Проблеми в головній гілці розробки

Відомі проблеми

Antithesis також успішно знайшла та відтворила ці відомі проблеми в старіших випусках — «Brown M&Ms», встановлені підтримувачами etcd.

Висновок

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

• ←Попередня
• Наступна→