Продовжуємо наше занурення у захоплюючий світ гадан… траблшутинга по логах. У ми домовилися про значення базових термінів і одним оком розглянули загальну структуру Veeam як єдиного додатка. Завдання на це - розібратися як формуються лог файли, що за інформація в них відображена і чому вони виглядають як виглядають.
Як ви вважаєте, що взагалі таке ці «логи»? На думку більшості, логам будь-якої програми має бути відведена роль такої всемогутньої сутності, яка більшу частину часу живе десь на задвірках, але в потрібний момент з'являється з нізвідки в сяючих обладунках і всіх рятує. Тобто, у них має бути все, починаючи з найменших помилок у кожному компоненті, до окремих транзакцій бази. І щоб після помилки одразу писалося як ще виправити. І вміщатись це все має в пару мегабайт, не більше. Це просто текст! Не можуть текстові файли позичати десятки гігабайт, я десь це чув!
Отже, логи
У реальному світі логи це лише архів діагностичної інформації. І що там зберігати, звідки брати інформацію для зберігання і наскільки докладною вона має бути вирішувати самим розробникам. Хтось йде шляхом мінімалізму зберігаючи записи рівня ВКЛ/ВИКЛ, а хтось старанно згрібає все до чого тільки зміг дотягнутися. Хоча є ще й проміжний варіант з можливістю вибору так званого Logging Level, коли ти сам вказуєш наскільки докладну інформацію ти хочеш зберігати і наскільки маєш багато зайвого місця на дисках =) У VBR таких рівнів аж шість, до речі. І, повірте, ви не хочете бачити, що відбувається при максимально докладному логуванні з вільним місцем на вашому диску.
Добре. Ми приблизно зрозуміли, що хочемо зберігати, але постає законне питання: звідки брати цю інформацію? Частину подій для логування, звичайно, ми формуємо самі нашими внутрішніми процесами. Але що робити, коли відбувається взаємодія із зовнішнім середовищем? Щоб не скочуватися в непроглядне пекло з милиць і велосипедів, Veeam має тенденцію не винаходити вже винайдені винаходи. Завжди, коли вже є готове API, вбудована в систему функція, бібліотека тощо, ми віддамо перевагу готовим варіантам, перш ніж починати городити свої хитромудрі рішення. Хоча останніх також вистачає. Тому при аналізі логів важливо розуміти, що левова частка помилок посідає повідомлення від сторонніх API, системних викликів та інших бібліотек. У разі роль VBR зводиться до форварду цих помилок у файли логів as is. А основне завдання користувача - навчитися розуміти, який рядок від когось, і за що цей "хто" відповідає. Тому, якщо код помилки з лога VBR наводить вас на сторінку MSDN, це нормально і правильно.
Як ми домовилися раніше: Veeam - це так звана SQL-based програма. А значить всі налаштування, вся інформація і все, що тільки необхідно для нормального функціонування - все зберігається в його базі. Звідси проста істина: те, чого немає в логах, швидше за все, є в базі. Але це не срібна куля: деяких речей немає ні в локальних логах компонентів Veeam, ні в його базі. Тому треба навчитися вивчати логи хоста, логи локальної машини та логи взагалі всього, що бере участь у процесі бекапу та рестору. А буває й так, що потрібної інформації взагалі немає ніде. Такий шлях.
Декілька прикладів таких API
Цей список не ставить собі за мету бути виняткової повноти, так що не треба в ньому шукати істину в останній інстанції. Його завдання – лише показати найчастіші сторонні API та технології, які використовуються в наших продуктах.
Почнемо з VMware.
Першим у списку буде API vSphere. Використовується для аутентифікації, читання ієрархії, створення та видалення снапшотів, запиту інформації про машини та багато чого (дуже багато чого) чогось іншого. Функціонал рішення дуже широкий, тому всім охочим можу порекомендувати VMware vSphere API Reference для версії и . Для актуальніших версій все просто гуглиться.
API VIX. Чорна магія гіпервізора, для якої є окремий . VMware API для роботи з файлами на хості без підключення до них через мережу. Варіант останньої надії, коли треба покласти файл у машину, до якої немає кращого каналу зв'язку. Уявляє біль і страждання, якщо файлик великий, а хост завантажений. Але тут працює правило, що навіть 56,6 Кб/с це краще ніж 0 Кб/с. У Hyper-V подібна штука називається PowerShell Direct. Але так було лише до появи
vSpehere Web Services API Починаючи з vSphere 6.0 (приблизно тому, що вперше цей API був представлений на версії 5.5) використовується для роботи з гостьовими машинами і вже практично скрізь витіснив VIX. По суті це ще один API для управління vSphere. Ті, хто цікавиться, можу порадити вивчити мануал.
ВДДК (Virtual Disk Development Kit). Бібліотека, про яку частково йшлося у цій . Використовується для читання віртуальних дисків. Колись давно була частиною VIX, проте згодом винесена на окремий продукт. На правах спадкоємця використовує самі коди помилок, як і VIX. Але з якоїсь причини у самому SDK немає жодного опису цих помилок. Тому досвідченим шляхом було з'ясовано, що помилки VDDK з іншими кодами — лише трансляція з бінарного до десяткового коду. Складається із двох частин – перша половина являє собою недокументовану інформацію про контекст, а друга частина – традиційні VIX/VDDK помилки. Наприклад, якщо бачимо:
VDDK error: 21036749815809.Unknown error
То сміливо конвертуємо це в hex і отримуємо 132200000001. Неінформативний початок 132200 просто відкидаємо, а залишок і буде нашим кодом помилки (VDDK 1: Unknown error). Про найчастіші VDDK errors якраз недавно була окрема .
Тепер подивимося на Windows.
Тут все найпотрібніше і важливе для нас можна знайти у стандартному Перегляд подій. Але є одна проблема: за давньою традицією Windows логує не повноцінний текст помилки, а лише її номер. Наприклад, помилка 5 - це "Access denied", а 1722 - це "The RPC server is unavailable", та 10060 - це "Connection timed out". Звичайно, здорово, якщо ти пам'ятаєш найвідоміші, проте як бути з досі небаченими?
А щоб життя зовсім медом не здавалося, помилки ще й у шістнадцятковому вигляді зберігаються з префіксом 0x8007. Наприклад, 0x8007000e - це насправді 14, Out of Memory. Навіщо і для кого так було зроблено — таємниця, вкрита мороком. Однак повний список помилок можна скачати безкоштовно і без СМС .
До речі, іноді трапляються й інші префікси, а не лише 0x8007. У такій сумній ситуації для розуміння HRESULT (“result handle”) потрібно ще глибше влазити в для розробників. У звичайному житті робити я вам таке не раджу, але якщо раптом притиснули до стінки чи просто цікаво, тепер ви знаєте, що робити.
Але товариші в Microsoft дещо зглянулися над нами і явили світові утиліту . Це невеликий шматочок консольного щастя, який вміє перекладати коди помилок на людську мову без використання гугла. Працює вона приблизно так.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Виникає законне питання: а заради чого ми в логи відразу не пишемо розшифровку, а залишаємо ці таємничі коди? Відповідь у сторонніх програмах. Коли ти сам смикаєш якийсь WinAPI виклик, то розшифрувати його відповідь не складно, бо для цього навіть є свій спеціальний WinAPI виклик. Але як було вже сказано, до наших логів потрапляє все, що тільки приходить до нас у відповідях. І тут уже для розшифровки довелося б постійно моніторити цей потік свідомості, чіпляти з нього шматки з помилками вінди, розшифровувати їх і вставляти назад. Скажімо чесно, не найцікавіше заняття.
Windows File Management API всіляко використовується під час роботи з файлами. Створення файлів, видалення, відкриття на запис, робота з атрибутами та інше та інше.
згаданий вище PowerShell Direct як аналог VIX API у світі Hyper-V. На жаль, не такий гнучкий: маса обмежень за функціональністю працює не з кожною версією хоста і далеко не з усіма гостями.
RPC (Remote Procedure Call) Я думаю, що немає жодної людини, яка працювала з WIndows, хто б не бачив помилок, пов'язаних з RPC. Незважаючи на популярну оману, це не якийсь єдиний протокол, а будь-який клієнт-серверний протокол, який задовольняє низку параметрів. Однак, якщо в наших логах є помилка RPC, у 90% випадків це буде помилка від Microsoft RPC, який є частиною DCOM (Distributed Component Object Model). У мережі можна знайти величезну кількість документації на цю тему, проте левова її частка дуже застаріла. Але якщо є гостре бажання вивчити тему, можу рекомендувати статті , та довжелезний список .
Основні причини виникнення RPC помилок у наших логах - це невдалі спроби взаємодії між компонентами VBR (сервер > проксі, наприклад) і найчастіше через проблеми зі зв'язком.
Топовий топ серед усіх топів це помилка The RPC server is unavailable (1722). Якщо по-простому, клієнт не зміг встановити з'єднання з сервером. Як і чому, єдиної відповіді немає, але зазвичай це проблема з автентифікацією або з мережним доступом до порту 135. Остання характерна для інфраструктур з динамічним призначенням портів. На цю тему є навіть . А у Microsoft - пошуку причин несправності.
Друга за популярністю помилка: There are no more endpoints available from the endpoint mapper (1753). RPC клієнт чи сервер не змогли призначити порт. Зазвичай виникає, коли сервер (у нашому випадку гостьова машина) був налаштований на динамічне виділення портів із вузького діапазону, який закінчився. А якщо заходити з боку клієнта (у нашому випадку VBR-сервера), це означає, що наш VeeamVssAgent або не запустився або не був зареєстрований як RPC інтерфейс. На цю тему також є .
Ну і щоб завершити Топ-3 помилок RPC, згадаймо RPC function call failed (1726). З'являється, якщо зв'язок був встановлений, але запити RPC не відпрацьовують. Наприклад, ми запитуємо інформацію про статус VSS (раптом там прямо зараз шедоу копальні робиться, а ми намагаємося лізти), а у відповідь нам тиша і ігнор.
Windows Tape Backup API потрібен до роботи з стрічковими бібліотеками чи приводами. Як я згадував на початку: писати свої драйвера і мучитися потім за допомогою кожного пристрою нам немає ніякого задоволення. Тому у віма немає жодних своїх драйверів. Все через стандартний API, підтримку якого реалізують самі вендори заліза. Адже набагато логічніше, правда?
SMB / CIFS Всі за звичкою пишуть їх поряд, хоча далеко не всі пам'ятають, що CIFS (Common Internet File System) - це приватна версія SMB (Server Message Block). Отже, нічого поганого в узагальненні цих понять немає. Ось Samba це вже LinuxUnix реалізація, і там є свої особливості, але це я відволікся. Що тут важливо: коли Veeam просить записати щось UNC шляху (serverdirectory), сервер використовує ієрархію драйверів файлової системи, включаючи mup і mrxsmb, для запису на кулі. Відповідно, помилки генеруватимуть теж ці драйвери.
Ніяк не можна обійтися без Winsock API. Якщо щось треба зробити через мережу, VBR працює через Windows Socket API, в народі відомий як Winsock. Отже, якщо бачимо в лозі зв'язку IP:Port, це воно. В офіційній документації є непоганий список можливих .
згаданий вище WMI (Windows Management Instrumentation) - це всемогутнє API для управління всього і всім у світі Windows. Наприклад, під час роботи з Hyper-V практично всі запити до хоста відбуваються саме через нього. Словом, річ абсолютно незамінна та дуже потужна у своїх можливостях. У спробах допомогти з'ясувати, де і що зламалося, дуже допомагає вбудована тула WBEMtest.exe.
І останній за списком, але зовсім не останній за значимістю VSS (Volume Shadow Storage). Тема настільки невичерпна та загадкова, наскільки багато з неї написано документації. Shadow Copy найпростіше розуміти як особливий тип снапшота, яким насправді він і є. Завдяки йому в VMware можна робити application-consistent бекапи, а в Hyper-V взагалі мало не все. У мене є в планах зробити окрему статтю з якоюсь вичавкою по VSS, але поки що можете спробувати почитати . Тільки обережно, т.к. Спроба зрозуміти VSS з наскоку може призвести до травм головного мозку.
На цьому, мабуть, можна зупинитися. Завдання пояснити самі базові речі вважаю виконаним, тож у наступному розділі вже дивитимемося на логи. Але якщо залишилися питання, то не соромтеся озвучувати їх у коментарях.
Джерело: habr.com