Продължаваме нашето потапяне в увлекателния свят на отстраняване на проблеми по логовете. В се договорихме за значението на основните термини и с един поглед разгледахме общата структура на Veeam, като едно приложение. Задачата за тази - да разберем как се формират лог файловете, каква информация е показана в тях и защо изглеждат така, както изглеждат.
Как мислите, какво всъщност представляват тези „логове“? Според повечето, логовете на всяко приложение трябва да играят ролята на всемогъща същност, която през по-голямата част от времето стои на задния двор, но в нужния момент изскача изневиделица в сияещи доспехи и спасява всички. Тоест в тях трябва да има всичко, започвайки от най-малките грешки във всеки компонент, до отделни транзакции в базата данни. И след грешка, трябва веднага да се записва как да се поправи. И всичко това трябва да се побере в няколко мегабайта, не повече. Това е просто текст! Не могат текстовите файлове да заемат десетки гигабайти, чувал съм го някъде!
И така, логове
В реалния свят логовете са само архив на диагностичната информация. И какво да съхраняваме там, откъде да взимаме информация за съхранение и колко подробна да бъде, сами разработчиците решават. Някой следва пътя на минимализъм, съхранявайки записи на ниво ВКЛ/ИЗКЛ, а други старателно събират всичко, до което само могат да се докоснат. Въпреки това, съществува и междинен вариант с възможност за избор на така нареченото Logging Level, когато сами указвате колко подробна информация искате да съхранявате и колко много излишно място имате на дисковете =) При VBR има цели шест такива нива, между другото. И, повярвайте, не искате да видите какво се случва при максимално подробно логиране с наличното свободно пространство на вашия диск.
Добре. Примерно разбрахме какво искаме да запазим, но възниква законният въпрос: откъде да вземем тази информация? Част от събитията за логване, разбира се, генерираме сами чрез нашите вътрешни процеси. Но какво да правим, когато се случва взаимодействие с външната среда? За да не попаднем в ада от костилета и велосипеди, Veeam има тенденция да не преоткрива вече изобретените неща. Винаги, когато има готово API, вградена функция в системата, библиотека и т.н., ние ще отдаваме предимство на готовите решения, преди да започнем да разработваме свои хитроумни решения. Въпреки че и последните също не са малко. Затова, когато анализирате логовете, е важно да разбирате, че голямата част от грешките идват от съобщения от външни API, системни повиквания и други библиотеки. В този случай ролята на VBR е да препраща тези грешки в лог файлове каквито са. А основната задача на потребителя е да се научи да разбира коя редица е от кого и за какво отговаря този
Както договорихме по-рано: Veeam е така нареченото SQL-базирано приложение. И следователно всички настройки, всяка информация и вообще всичко, което е необходимо за нормалното функциониране - всичко се съхранява в неговата база. Оттук идва простата истина: каквото и да липсва в логовете, вероятно го има в базата. Но и това не е сребърна куршум: някои неща не се намират нито в локалните логове на компонентите Veeam, нито в неговата база. Затова трябва да се научим да изучаваме логовете на хостата, логовете на локалната машина и логовете на всичко, което участва в процеса на бекъп и възстановяване. А понякога е така, че необходимата информация никъде не я има. Такъв е пътят.
Няколко примера за такива API
Този списък не си поставя целта да бъде изключително пълен, затова не трябва да търсите истината в последната инстанция. Неговата задача е само да покаже най-често използваните външни API и технологии в нашите продукти.
Нека започнем с VMware.
Първият в списъка ще бъде vSphere API. Използва се за удостоверяване, четене на йерархията, създаване и изтриване на моментни снимки, искане на информация за машините и много (почти безкрайно) други неща. Функционалността на решението е много широка, затова на всеки, който има интерес, мога да препоръчам VMware vSphere API Reference за версията и . За по-актуалните версии просто потърсете в Google.
VIX API. Черна магия на хипервизора, за която има отделен . VMware API за работа с файлове на хоста без свързване към тях по мрежата. Вариант на последна инстанция, когато трябва да се сложи файл в машина, за която няма по-добър канал за връзка. Представлява болка и страдание, ако файлът е голям, а хостът е натоварен. Но тук важи правилото, че дори 56,6 Кб/с е по-добре от 0 Кб/с. В Hyper-V подобна функция се нарича PowerShell Direct. Но така беше само до появата на
vSphere Web Services API Започвайки от vSphere 6.0 (приблизително, тъй като този API беше представен за първи път в версия 5.5), се използва за работа с гостуващи машини и вече почти навсякъде е заменил VIX. По същество, това е още един API за управление на vSphere. На интересуващите се мога да препоръчам да изучат мануал.
VDDK (Комплект за разработка на виртуални дискове). Библиотека, за която частично се споменава в тази . Използва се за четене на виртуални дискове. Някога беше част от VIX, но с времето беше отделена в самостоятелен продукт. За сметка на това като наследник използва същите кодове за грешки, каквито имаше VIX. Но по някаква причина в самия SDK няма никакво описание на тези грешки. Затова се установи експериментално, че грешките VDDK с други кодове — всъщност са транслация от бинарен в десетичен код. Състои се от две части – първата половина съдържа недокументирана информация за контекста, а втората част — традиционните грешки на VIX/VDDK. Например, ако видим:
VDDK error: 21036749815809.Unknown error
Тогава спокойно преобразуваме това в hex и получаваме 132200000001. Нека неинформативното начало 132200 просто отхвърлим, а остатъкът и ще бъде нашият код за грешка (VDDK 1: Непозната грешка). За най-честите VDDK грешки току-що имаше отделна .
Сега да видим Windows.
Тук всичко най-необходимо и важно за нас можем да намерим в стандартния Event Viewer. Но има едно уловка: по стара традиция Windows логва не пълния текст на грешката, а само нейния номер. Например, грешка 5 — това е “Достъпът е забранен”, а 1722 — “RPC сървърът е недостъпен”, е, и 10060 — “Времето за свързване е изтекло”. Разбира се, страхотно е, ако помниш най-известните, но какво да направиш с невижданите досега?
А за да не изглежда животът напълно меден, грешките също се съхраняват в шеснадесетичен формат, с префикс 0x8007. Например, 0x8007000e — всъщност е 14, Out of Memory. Защо и за кого е направено така — загадка, покрита в мрак. Въпреки това, пълен списък с грешки може да бъде изтеглен безплатно и без SMS от .
Между другото, понякога се срещат и други префикси, а не само 0x8007. В такава тъжна ситуация, за да разберете HRESULT (“result handle”), е нужно да се задълбочите още повече в за разработчиците. В обикновения живот не бих ви съветвал да правите такова нещо, но ако случайно сте стиснати до стената или просто ви интересува, сега знаете какво да правите.
Но другарите от Microsoft малко се съжалиха за нас и представиха на света утилитата . Това е малък парче консолно щастие, което може да превежда кодовете на грешки на човешки език без да използва Google. Работи по следния начин.
C:UsersrootDesktop>err.exe 0x54f
# за hex 0x54f / десетично 1359
ERROR_INTERNAL_ERROR winerror.h
# Настъпи вътрешна грешка.
# като HRESULT: Степен: УСПЕХ (0), УЧАСТИЕ_NULL (0x0), Код 0x54f
# за hex 0x54f / десетично 1359
ERROR_INTERNAL_ERROR winerror.h
# Настъпи вътрешна грешка.
# Намерени 2 съвпадения за "0x54f"Изниква законен въпрос: защо не пишем веднага в логовете разшифровката, а оставяме тези тайствени кодове? Отговорът е в странични приложения. Когато вие самите извиквате някакъв WinAPI, разшифровката на неговия отговор не представлява трудност, тъй като дори за това има свой специален WinAPI извикване. Но, както вече беше споменато, в нашите логове попада всичко, което ни идва в отговор. И тук, за разшифровката, трябваше постоянно да следим този поток на съзнание, да извлечем от него парчета с грешки от Windows, да ги разшифроваме и да ги върнем обратно. Да бъдем честни, това не е най-вълнуващото занимание.
Windows File Management API се използва при работа с файлове. Създаване на файлове, изтриване, отваряне за запис, работа с атрибути и други.
По-горе споменатото PowerShell Direct като аналог на VIX API в света на Hyper-V. За съжаление, не е толкова гъвкав: много ограничения по функционалността, не работи с всяка версия на хоста и далеч не с всички гости.
RPC (Remote Procedure Call) Мисля, че няма човек, работил с Windows, който да не е виждал грешки, свързани с RPC. Въпреки популярното заблуждение, това не е единен протокол, а клиент-сървърен протокол, отговарящ на определени параметри. Обаче, ако в логовете ни има грешка RPC, в 90% от случаите това ще бъде грешка от Microsoft RPC, който е част от DCOM (Разпределен компонентен обектен модел). В интернет можете да намерите огромно количество документация по темата, но голяма част от нея е остаряла. Но ако имате силно желание да проучите темата, мога да препоръчам статии , и дълъг списък .
Основните причини за възникването на грешки 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 необходим за работа с лентови библиотеки или устройства. Както споменах в началото: да пишем свои драйвери и после да се мъчим с поддръжката на всяко устройство не носи никакво удоволствие. Затова Veeam няма собствени драйвери. Всичко минава през стандартния 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
