- Відновлення неузгоджених об'єктів
- заповнені OSD
- Ведення журналів OSD
- Мала продуктивність
- Дуже низька продуктивність або відсутність введення / виведення
- Початківці відмовляти диски
- Розслідування PG в стані down
- Великі бази даних монітора
{Прим. пер .: рекомендуємо відразу звертатися до нашого перекладу 2 видання вийшов в лютому 2019 Повного керівництва Ceph Ніка Фіска}
Ceph багато в чому автономний в турботі про себе і при відновленні в разі відмов, проте в деяких випадках потрібна втручання людини. Дана глава розгляне такі загальні помилки і варіанти відмов, а також як переносити Ceph назад в робочий стан знаходячи несправності в ньому. Ви вивчіть наступні питання:
Відновлення неузгоджених об'єктів
Зараз ми розглянемо як ми можемо правильно відновлювати неузгоджені об'єкти.
Щоб мати можливість відновлення неузгодженого сценарію створіть якийсь RBD і далі ми зробимо в ньому якусь файлову систему:
Тепер перевірте переглядом які об'єкти були створені шляхом форматування даного RBD деякої файлової системою:
Візьміть довільний об'єкт і скористайтеся командою osd map для пошуку того, в яких PG збережений даний об'єкт:
Знайдіть цей об'єкт на певному диску на одному з вузлів OSD; в даному випадку це osd.0 на osd1:
Зруйнуйте його скопіювавши на нього командою echo сміттєву запис:
Тепер запросите Ceph виконати в тій PG, яка містить зруйнований нами об'єкт, чистку:
Якщо ви перевірите стан Ceph, ви побачите, що Ceph виявив зіпсований об'єкт і позначив його PG неузгодженою. Починаючи з цього моменту і далі забудемо що ми зруйнували даний об'єкт вручну і відпрацюємо весь процес так, як якщо б це сталося в реальності:
Розглядаючи більш уважно повідомлення про працездатність, ми можемо виявити ту PG, яка містить зіпсований об'єкт. Ми можемо тепер просто запросити у Ceph відновлення даної PG; проте, якщо саме первинний OSD містить зіпсований об'єкт, це перепише залишилися хороші копії. Це буде не добре; таким чином, щоб переконатися, що цього не станеться, перед тим як виконати команду відновлення ми переконаємося в тому який саме OSD містить зіпсований об'єкт.
Переглянувши отриманий звіт про працездатність ми можемо побачити всі три OSD які містять якісь копії даного об'єкта, причому найперший OSD є первинним.
Реєструватимемося на своєму вузлі первинного OSD і відкриємо файл журналу для шуканого первинного OSD. Ви повинні мати можливість відшукати ту запис журналу, яка відображає той факт, що об'єкт був помічений операцією чистки PG.
Тепер, переміщаючись по відповідній структурі PG і відкриваючи відповідний файл журналу знайдете необхідні об'єкти, згадані у відповідному файлі журналу і обчисліть md5sum кожної копії.
md5sum об'єкта в osd першого вузла
md5sum об'єкта в osd другого вузла
md5sum об'єкта в osd третього вузла
Ми можемо виявити, що об'єкт в osd.0 має відмінне значення md5sum і тому ми знаємо що саме він є зруйнованим об'єктом.
OSD.0 = \ 0d599f0ec05c3bda8c3b8a68c32a1b47 OSD.2 = \ b5cfa9d6c8febd618f91ac2843d50a1c OSD.3 = \ b5cfa9d6c8febd618f91ac2843d50a1c
Хоча ми вже знаємо яка копія об'єкта була зруйнована, оскільки ми вручну понівечили об'єкт в OSD.0, давайте прикинемося що ми не робили цього і таке руйнування могло бути викликано випадковими космічними променями. Тепер у нас є md5sum трьох реплікованих копій і можна ясно зрозуміти що копія в OSD.0 невірна. Це очевидний факт для того чому схема з двома реплікаціями погана; якщо якась PG стає неузгодженою, ви можете визначити яка з них погана. Оскільки первинним OSD для цієї PG є 2, як ми могли переконатися і в подробицях про працездатність Ceph, і в виведенні команди Ceph OSD map, ми можемо безпечно виконати наявну команду ceph pg repair без побоювань що скопіюємо поганий об'єкт поверх залишилися незіпсованою копій.
Ми можемо відзначити, що наша неузгоджена PG відновила себе:
При виникненні ситуації, коли зруйнована копія на самому первинному OSD, тоді необхідно зробити наступні кроки:
Зупинити первинний OSD.
Видалити цей об'єкт з каталогу даної PG.
Повторно запустити цей OSD.
Проінструктувати Ceph відновити цю PG.
заповнені OSD
За замовчуванням Ceph застерігає коли використання OSD досягає 85% і зупинить операції введення / виводу на запис в даний OSD коли буде досягнуто 95%. Якщо з якої-небудь причини даний OSD повністю заповниться до 100%, тоді даний OSD швидше за все зруйнується і відмовиться повернутися назад в робочий стан. Якийсь OSD який перевищив рівень попередження в 85% також відкидає участь в наповненні, тому відновлення даного кластера може отримати удар в разі якщо OSD знаходяться близько заповненого стану.
Перш ніж розглянути всі кроки пошуку несправностей в ситуації заповнених OSD настійно рекомендується щоб ви спостерігали за використанням ємності ваших OSD, як це описувалося в чолі про моніторинг. Це забезпечить вас завчасним повідомленням таким як підхід до OSD з пороговим попередженням near_full.
Якщо ви виявили що перебуваєте в ситуації коли ваш кластер переступив через стан попередження близькості до заповнення у вас є два основних варіанти:
Додати трохи додаткових OSD.
Видалити деякі дані
Однак в реальному світі вони обидва або неможливі, або вимагатимуть часу і в такому випадку ситуація може погіршитися. Якщо даний OSD тільки в пороговому значенні near_full, тоді ви швидше за все ймовірно можете повернути все в правильне русло перевіркою збалансовано чи використання вашого OSD, з можливою подальшою балансуванням, якщо її немає. Це було детально розглянуто в попередньої чолі про регулюваннях. Те ж саме стосується й ситуації коли OSD too_full; хоча ви навряд чи повернете його назад нижче 85%, ви принаймні можете відкидати операції записи.
Якщо ваші OSD заповнилися повністю, тоді вони все в стані відключених і будуть відкидати запуск. Тепер ви маєте деяку додаткову проблему. Якщо дані OSD не запуститься, тоді незалежно від того що ви виконаєте - ребалансування або видалення даних, вони не позначаться на всіх заповнених OSD, так як вони відключені. Єдиний спосіб відновитися з даної ситуації - це вручну видалити деякі PG з файлової системи даних дисків щоб зробити можливим запуск такого OSD.
Ось кроки, які необхідно для цього зробити:
Переконайтеся що даний процес OSD не виконується.
Встановіть в даному кластері nobackfill щоб зупинити всі відновлення від їх настання після повернення в роботу даного OSD.
Знайдіть якусь PG, яка знаходиться в активному, чистому і перепризначення стані і присутній в даному відключеному OSD.
Видаліть цю PG з даного відключеного OSD.
Будемо сподіватися, що ви тепер зможете перезапустити даний OSD.
Видаліть дані з даного кластера Ceph або виконайте повторну балансування PG.
Видаліть nobackfill.
Виконайте очистку і відновлення тієї PG, яку ви тільки що видалили.
Ведення журналів OSD
При виявленні помилок дуже зручно мати можливість переглядати всі файли журналів Ceph щоб отримувати кращі ідеї з приводу того що відбувається. За замовчуванням наявні рівні ведення журналу встановлені так, щоб реєструвалися тільки всі важливі події. В процесі пошуку несправностей може виникнути потреба підвищити ці рівні ведення журналів щоб виявити викликає цю помилку причину. Для збільшення рівня ведення журналу ви можете або змінити ceph.conf, додавши новий рівень журналу, а потім перезапустити цей компонент, або, якщо ви не бажаєте перезапускати сам демон Ceph, ви можете впровадити необхідний новий параметр настройки в свій працюючий в реальному часі демон. Для впровадження параметрів застосовуйте команду ceph tell:
ceph tell osd.0 injectargs --debug-osd 0/5
Тут ми встановлюємо рівень ведення журналу для журналу OSD на osd.0 в значення 0/5. Число 0 є рівнем журналу на диску, а число 5 рівень журналу в оперативній пам'яті.
Порада
На рівні ведення журналу 20, такий журнал стає занадто багатослівним і буде швидко рости. Не залишайте високий рівень подробиць включеним занадто довго. Більш високі рівні ведення журналу також впливають на продуктивність.
Мала продуктивність
Низька продуктивність визначається в тому випадку, коли сам кластер активно обробляє запити операцій введення / виводу, однак вони здаються працюють на більш низькому рівні продуктивності ніж це очікується. Зазвичай мала продуктивність викликається якимось компонентом у вашому кластері Ceph, який досяг насичення і стає вузьким місцем. Це може бути обумовлено збільшенням числа запитів клієнтів або якимось відмовою компонента, який змушує Ceph виконувати відновлення.
Хоча є безліч речей, які можуть змусити Ceph відчувати низьку продуктивність, ось деякі з найбільш загальних, які можуть відбуватися:
Зросла робоче навантаження клієнтів
Часом низька продуктивність може бути обумовлена не лежать в її основі відмовами; це може бути просто результатом того, що загальне число і тип запитів клієнтів можуть перевершувати можливості наявного обладнання. Будь то наслідки деякого числа робочих навантажень, які все виконуються в один і той же час, або всього лише якесь повільне загальне збільшення на якийсь період часу, якщо ви відстежуєте загальне число запитів клієнтів по всьому своєму кластеру, це повинно бути простим для відстеження. Якщо збільшилася робоче навантаження виглядає як щось постійне, тоді єдиним рішенням буде додати деякий додаткове обладнання.
зупинка OSD
Якщо в деякому кластері значне число OSD позначені як down, можливо через те, що зупинений цілий вузол, хоча відновлення не почнеться поки ці OSD НЕ будуть позначені як out, це вплине на загальну продуктивність, оскільки загальна кількість IOP, доступне для обслуговування всіх операцій введення / виводу клієнтів тепер буде нижче. Ваше рішення моніторингу має повідомити вас якщо це станеться і дозволить вам зробити дії.
Відновлення та наповнення
Коли якийсь OSD позначений як out, що потрапили під вплив цього PG перевстановити однорангові з'єднання на нові OSD і почнуть свій процес відновлення і наповнення даними по всьому кластеру. Цей процес може розмістити на всі диски в деякому кластері Ceph додаткове навантаження і спричинити великі затримки для запитів клієнтів. Є ряд параметрів регулювання, які можуть мінімізувати можливі перешкоди для заповнення зменшенням його швидкості і пріоритету. Це слід оцінити на противагу впливу зниження відновлення відмовили дисків, що могло б зменшити рівень живучості всього кластера.
очищення
Коли Ceph виконує глибоке очищення для перевірки того, чи знаходяться ваші дані в будь-якої неузгодженості, йому доводиться зчитувати всі об'єкти з даного OSD; це може бути дуже інтенсивною завданням щодо операцій введення / виводу, а на великих дисках цей процес може забирати багато часу. Очищення життєво важлива для захисту від втрати даних і, отже, її не можна відключати. Різні варіанти налаштувань обговорювалися в Главі 9, Тонка настройка Ceph , Що відносяться до установок вікон для очищення і її пріоритету. Регулюючи ці установки можна уникнути більшу частину впливу на робоче навантаження клієнта від очищення.
Уривок знімків
Коли ви видаляєте якийсь моментальний знімок, Ceph повинен видалити всі наявні об'єкти, які були створені завдяки природі копіювання при записі даного процесу отримання знімка. Починаючи з Ceph 10.2.8 і далі є деяка покращена установка OSD з назвою osd_snap_trim_sleep, яка змушує Ceph очікувати запропонованого установкою значення між подрезкой кожного об'єкта моментального знімка. Це гарантує, що всі лежать в основі зберігання об'єкти не стануть перевантаженими.
застереження
Хоча ці установки були доступні в попередніх редакціях Jewel, їх поведінка була не тим же самим і їх не слід застосовувати.
Проблеми з обладнанням або драйверами
Якщо ви тільки що додали нове обладнання в свій кластер Ceph і, після того як заповнення повторно збалансував ваші дані, ви починаєте відчувати повільну продуктивність, перевірте своє вбудоване програмне забезпечення або драйвери пов'язані з вашим обладнанням, оскільки нові драйвери можуть вимагати більш нового ядра. Якщо ви додали тільки невеликий обсяг апаратних засобів, тоді ви можете тимчасово позначити ці OSD як out не виходячи нижче встановленого для ваших пулів значення min_size; це може бути хорошим способом виключення проблем з обладнанням.
Саме тут приходить на користь той моніторинг, який ви налаштували в Главі 7, Моніторинг Ceph , Так як він дозволить вам порівнювати довгострокові тенденції з читанням поточних вимірювань і побачити деякі ясні аномалії, якщо вони є.
Спочатку рекомендується поглянути на продуктивність дисків так як, в більшості випадків поганий продуктивності, саме лежать в основі диски зазвичай стають тими компонентами, які стають пляшковим горлечком.
Якщо у вас немає налаштованого моніторингу або ви бажаєте вручну заглибитися в пучину наявних параметрів продуктивності, тоді є цілий ряд інструментів, який ви можете застосувати для цього.
iostat
iostat може бути застосований для отримання огляду роботи щодо наявних продуктивності і латентності всіх дисків, що функціонують в ваших вузлах OSD. Виконайте span class = "term"> iostat за допомогою наступної команди:
iostat -d 1 -x
Ви отримаєте відображення подібне наступного, яке оновлюється раз в секунду:
Як висіченого в граніті правила, якщо достатньо велика кількість ваших дисків показують високий відсоток util протягом тривалого часу, швидше за все ваші диски перенасичені запитами. Може бути непогано поглянути на час r_await щоб перевірити що запити на читання не займають більше часу, ніж це слід очікувати для даного типу диска в ваших вузлах OSD. Як уже згадувалося раніше, якщо ви виявите що інтенсивне використання дисків є причиною низької продуктивності і тим переключающим фактором, який навряд чи розсмокчеться скоро, тоді додаткові диски є єдиним рішенням.
htop
Як і стандартна утиліта top, htop надає в реальному часі перегляд споживання наявних ЦПУ і оперативної пам'яті даного хоста. Однак, вона також надає більш інтуїтивне відображення, яке може зробити оцінку використання всіх ресурсів системи простіше, особливо для швидко мінливого використання ресурсів Ceph.
atop
Іншим корисним інструментом є atop; він вловлює параметри продуктивності для ЦПУ, оперативної пам'яті, дисків, мережевий середовища і може представляти все це в одному перегляді, що робить його дуже простим для отримання повного огляду всіх застосовуваних ресурсів системи.
Існує певна кількість внутрішніх інструментів Ceph, які можна застосовувати в допомогу діагностування низьку продуктивність. Більшість корисних команд для дослідження повільної продуктивності скидають поточні операції в реальному часі, що може бути зроблено командою, наприклад такий:
sudo ceph daemon osd.x dump_ops_in_flight
Вона скидає всі поточні операції для даного певного OSD і розчленовує всі наявні різні часи для кожного етапу цієї операції. Ось такий собі приклад якийсь операції введення / виводу на льоту:
З попереднього прикладу операції введення / виводу ми можемо побачити всі наявні етапи, які зареєстровані для кожної операції; очевидно що дана операція виконується без будь-яких проблем з продуктивністю. Однак, при виникненні низьку продуктивність ви можете побачити якісь великі затримки між двома етапами і, направивши свої дослідження в цю область, можете вийти на викликала проблему процедуру.
Дуже низька продуктивність або відсутність введення / виведення
Якщо ваш кластер працює дійсно повільно, причому до такої міри що він майже не обслуговує запити операцій введення / виводу, тоді, швидше за все, є певні лежать в основі цього відмова або проблема настройки. Такі повільні запити будуть ймовірно виділені в дисплеї стану Ceph за допомогою лічильника для того, наскільки довго запит був блокований. В цьому випадку необхідно перевірити кілька моментів.
У своїх моніторах перевірте ceph.log і переконайтеся не виглядають вони як якісь OSD б'ються в up і down. Коли якийсь OSD приєднується до кластеру, його групи розміщення підлягають включенню в однорангові з'єднання (peering). Протягом даного процесу установки тимчасових з'єднань операції введення / виведення тимчасово зупиняються, тому в разі деякого число биття OSD це може певним чином впливати на операції введення / виведення клієнта. Якщо з очевидністю є мерехтливі OSD, наступним етапом буде прохід по журналам для виявлення тих OSD, які є мерехтливими і чи немає ключів до того що викликає їх биття. Мерехтіння OSD може бути складним для відстеження, так як можливо викликається різними причинами і до того ж дана проблема може широко розповсюджуватися.
Переконайся что Зміни в мережевий середовіщі НЕ віклікалі проблем з кадрами jumbo, если смороду застосовуються. Якщо кадри jumbo не працюють належним чином, пакети меншого розміру швидше за все можуть бути успішними для проходження до інших OSD і MON, однак більш довгі пакети будуть відкидатися. Це матиме результатом то, що виникне половинчаста функціональність, а це може бути дуже важким для виявлення очевидним чином. Якщо відбувається щось дивне, завжди перевіряйте із застосуванням ping той факт, що кадри jumbo дозволені по всій вашій мережі.
Початківці відмовляти диски
Так як Ceph чергує дані по всіх дисках в наявному кластері, якийсь окремий диск, який знаходиться в процесі падіння, але все ж поки ще повністю не відмовив, може почати викликати уповільнення або блокування операцій введення / виводу по всьому кластеру. Найчастіше це буде викликано деяким диском, який переповнений великим числом помилок читання, однак все ще недостатнім для того, щоб цей диск відмовив повністю. Зазвичай такий собі диск буде всього лише повторно виділяти (reallocate) сектори під час запису в якийсь поганий сектор. Спостереження за статистиками SMART з усіх дисків зазвичай вкаже на таку умову як описано тільки що і дозволить вам зробити дію.
Часом якийсь OSD може показувати дуже погану продуктивність без всяких помітних причин. Якщо немає нічого очевидного, що виявляється вашими інструментами спостереження, перевірте ceph.log і докладний висновок працездатності вашого Ceph. Ви також можете виконати osd perf Ceph, який видасть перелік всіх затримок фіксацій і застосувань для кожного вашого OSD і також може допомогти вам виявити якийсь проблемний OSD.
Якщо існує якийсь загальний шаблон OSD, які проявляють себе повільними в запитах, тоді є хороша ймовірність що саме згадані OSD викликають дані проблеми. Є ймовірність того, що перезапуск даного OSD в змозі вирішити дану труднощі; якщо ж даний OSD все ще залишиться проблемним, слід запропонувати помітити його як out а потім замінити цей OSD.
Розслідування PG в стані down
Якась PG в стані down не обслуговуватиметься ніякі операції клієнта і все що містяться в цій групі розміщень будуть недоступними. Це викличе уповільнення побудови запитів по всьому кластеру, так як клієнти намагаються отримати доступ до цих об'єктів. Найбільш поширеною причиною, по якій якась PG знаходиться в стані down відбувається коли відключений ряд OSD, що означає, що немає мають силу копій даних PG на будь-яких активних OSD. Однак, щоб визначити чому якась PG знаходиться в стані down ви можете виконати таку команду:
ceph pg xy query
Вона надасть достатньо велика кількість виведення; та секція, яка представляє для нас інтерес відображає стан однорангового обміну. Наведений тут приклад було взято з групи розміщення, чий пул був встановлений в значення 1 для min_size і мав записані в нього дані в той час як тільки OSD 0 знаходився в up і робочому станах. Потім OSD був зупинений, а OSD 1 і 2 були запущені.
Ми можемо побачити, що був блокований весь процес однорангового обміну, так як Ceph знає що дана PG має більш нові дані, записані в OSD 0. Він опитав OSD 1 і 2 на предмет цих даних, що означає що він не виявив нічого з того що йому було потрібно. Він би хотів спробувати і опитати OSD 0, що проте не можливо, оскільки цей OSD down, отже то повідомлення, яке починається з цього osd або позначає його дозволить нам продовжити.
Великі бази даних монітора
Монітори Ceph застосовують leveldb для зберігання всіх потрібних монітора даних для вашого кластера. Вони містять такі речі як карту монітора, карту OSD і карту PG, які OSD і клієнти отримують з цих моніторів щоб мати можливість визначати місце розташування об'єктів в усьому кластері RADOS. Одне особливе властивість, про який повинні бути поінформовані всі полягає в тому, що в той період, коли працездатність всього кластера не дорівнює HEALTH_OK, все дисплей може не відкидають ніякі наявні більш старі карти кластера зі своїх баз даних. Якщо даний кластер знаходиться в деградированном стані протягом досить тривалого періоду часу і / або даний кластер має досить велике число OSD, дана база даних монітора може вирости дуже значно.
При нормальних умовах роботи все монітори мають дуже малу вагу щодо споживання ресурсів; завдяки цьому досить поширене застосовувати диски меншого розміру для всіх моніторів. При тій ситуації, коли деградоване стан відбувається тривалий час, може статися для того диска, який розміщує базу даних монітора, що він заповниться, що, якщо це відбудеться з усіма вузлами моніторів, призведе до падіння всього кластера.
Щоб уберегтися від такої поведінки, може виявитися розумним розгорнути ваші вузли монітора з використанням LVM з тим, щоб при виникнення потреби в розширенні даних дисків це можна було б зробити більш простим способом. Коли ви потрапляєте в цю ситуацію, додавання дискового простору є єдиним рішенням поки ви не отримаєте весь залишок свого кластера в стан HEALTH_OK.
Якщо ваш кластер знаходиться в стані HEALTH_OK, проте база даних монітора все ще велика, ви можете зменшити її виконавши наступну команду:
sudo ceph tell mon. {id} compactОднак, це працює тільки в разі коли ваш кластер знаходиться в стані HEALTH_OK; даний кластер не зможе відкинути старі карти кластера, які можуть бути щільно упаковані, поки він не знаходиться в стані HEALTH_OK.
У цьому розділі ми вивчили як обробляти ті проблеми, з якими Ceph не в змозі впоратися самостійно. Тепер ви розумієте всі необхідні етапи пошуку несправностей при виникненні різних проблем які, якщо їх залишити невирішеними, можуть вирости в ще більші проблеми. Більш того, ви також маєте хороші ідеї про те що є ключовими областями для пошуку в ситуації, коли ваш кластер Ceph не працює так як очікувалося. Ви повинні отримати впевненість, що ви тепер в набагато кращому становищі для обробки відносяться до Ceph проблем як тільки вони з'являться.