Fail-slow у масштабі: коли хмара перестає працювати

  • Oct 17, 2023

Комп’ютерні системи виходять з ладу. Більшість збоїв є правильними: система перестає працювати. Але бувають і погані збої, коли системи працюють, але справді п-л-о-ш-л-й. Які компоненти найімовірніше вийдуть із ладу? Відповіді можуть вас здивувати.

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

треба прочитати

Що таке хмарні обчислення? Усе, що вам потрібно знати, від публічної та приватної хмари до програмного забезпечення як послуги

Вступ до хмарних обчислень від IaaS і PaaS до гібридної, публічної та приватної хмари.

Читайте зараз

Тож ви перезавантажуєтеся та сподіваєтесь на краще — і, можливо, це спрацює. Якщо ні, ще більше висмикуйте волосся.

Тепер уявіть, що у вас є кластер із 100 вузлами, який раптово сповільнюється до повзання. Перезавантажити 100 вузлів?

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

І, так, є повільний мережевий адаптер ємністю 1 Гб – плата вартістю 50 доларів США – який спричинив каскадний збій, який поставив ваш кластер вартістю півмільйона доларів на коліна.

Fail-slow у масштабі

На конференції Usenix File and Storage Technology (FAST '18) цього місяця в Окленді, Каліфорнія, команда з 23 авторів представила Fail-Slow at Scale: Докази помилок продуктивності обладнання у великих виробничих системах. Вони описують повільні збої в п’яти компаніях, чотирьох університетах і трьох національних лабораторіях із кількістю вузлів від понад 100 до понад 10 000.

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

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

... один оператор поставив офісне крісло поруч із кластером зберігання. Оператору подобалося гойдатися в кріслі, постійно вириваючи диски з гарячим підключенням із шасі (важка кореляція для діагностики).

Але багато невдач були більш непомітними:

  • "... помилкове мікропрограмне забезпечення постачальника призвело до зупинки партії твердотільних накопичувачів на секунди, вимкнувши рівень флеш-кешу та сповільнивши весь стек пам’яті».
  • "... машина була визнана нефункціональною через інтенсивну корекцію ECC багатьох біт-фліпів DRAM».
  • "... погані чіпи в SSD зменшують розмір надмірно виділеного простору, активуючи більш часте збирання сміття».
  • "... додатки, які створюють велике навантаження, можуть спричинити недостатнє керування потужністю стійки живлення для інших машин (знижуючи їх продуктивність), але лише до енергоємних програм закінчити».
  • «Вентилятор у обчислювальному вузлі перестав працювати, що змусило інші вентилятори компенсувати непрацюючий вентилятор, працюючи на максимальних швидкостях, що потім викликало багато шуму та вібрації, які згодом погіршили роботу диска продуктивність».

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

Першопричини

У статті підсумовуються причини 101 проаналізованого інциденту повільної роботи. Проблеми з мережею були причиною №1, потім ЦП, диск, SSD і пам’ять. Більшість мережевих збоїв були постійними, тоді як SSD і процесори мали найбільше тимчасових помилок.

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

Біти зберігання займають

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

Для (ще одного) прикладу,

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

Загалом, захоплюючий збірник статистики та типів несправностей. І для тих із нас, хто не треба керувати великими кластерами, приємне відчуття ухилення від багатьох куль. Вау!

Ввічливі коментарі, звичайно, вітаються.