Продължаваме да се потапяме в очарователния свят на отгатване ... отстраняване на неизправности чрез регистрационни файлове. IN договорихме се за значението на основните термини и погледнахме цялостната структура на Veeam като едно приложение с едно око. Задачата за този е да разберете как се формират лог файловете, каква информация се показва в тях и защо изглеждат така, както изглеждат.
Какво мислите, че са тези "дървени трупи"? Според повечето на дневниците на всяко приложение трябва да се приписва ролята на нещо като всемогъщ субект, който през повечето време вегетира някъде в задния двор, но в точния момент се появява от нищото в блестяща броня и спасява всички. Тоест те трябва да съдържат всичко, от най-малките грешки във всеки компонент до отделни транзакции в базата данни. И така, че след грешката веднага беше написано как иначе да се поправи. И всичко това трябва да се побере в няколко мегабайта, не повече. Това е просто текст! Текстовите файлове не могат да заемат десетки гигабайти, чух го някъде!
Така че трупите
В реалния свят регистрационните файлове са само архив от диагностична информация. И какво да съхранявате там, къде да получите информация за съхранение и колко подробно трябва да бъде, зависи от самите разработчици да решат. Някой следва пътя на минимализма, като води записи на нивото ON / OFF, а някой усърдно изгребва всичко, до което може да достигне. Въпреки че има и междинна опция с възможност за избор на така нареченото ниво на регистриране, когато вие сами посочвате колко подробна информация искате да съхранявате и колко допълнително дисково пространство имате =) VBR има шест такива нива, между другото. И, повярвайте ми, не искате да видите какво се случва с най-подробното регистриране със свободно място на вашия диск.
Глоба. Приблизително разбрахме какво искаме да спестим, но възниква легитимен въпрос: откъде да вземем тази информация? Разбира се, ние сами сме част от събитията за логване чрез нашите вътрешни процеси. Но какво да правим, когато има взаимодействие с външната среда? За да не се плъзне в ада на патериците и велосипедите, Veeam не изобретява изобретения, които вече са били изобретени. Винаги, когато има готов API, вградена функция, библиотека и т.н., ние ще дадем предпочитание на готови опции, преди да започнем да ограждаме нашите измишльотини. Въпреки че последното също е достатъчно. Следователно, когато анализирате регистрационните файлове, е важно да разберете, че лъвският дял от грешките се пада на съобщения от API на трети страни, системни повиквания и други библиотеки. В този случай ролята на VBR се свежда до препращане на тези грешки към лог файловете. И основната задача на потребителя е да се научи да разбира коя линия от кого е и за какво е отговорен този „кой“. Така че, ако код за грешка от регистрационния файл на VBR ви отведе до страница на MSDN, това е добре и правилно.
Както се съгласихме по-рано: Veeam е така нареченото SQL-базирано приложение. Това означава, че всички настройки, цялата информация и изобщо всичко, което е необходимо само за нормалното функциониране - всичко се съхранява в неговата база данни. Оттук и простата истина: това, което не е в регистрационните файлове, най-вероятно е в базата данни. Но това също не е сребърен куршум: някои неща не са в локалните регистрационни файлове на компонентите на Veeam, нито в неговата база данни. Следователно трябва да се научите как да изучавате регистрационните файлове на хоста, регистрационните файлове на локалната машина и регистрационните файлове на всичко, което участва в процеса на архивиране и възстановяване. И също така се случва необходимата информация да не е достъпна никъде. Това е начинът.
Някои примери за такива API
Този списък няма за цел да бъде изключително пълен, така че няма нужда да търсите истината от последна инстанция в него. Целта му е само да покаже най-често срещаните API и технологии на трети страни, използвани в нашите продукти.
Нека започнем с VMware.
Първо в списъка ще бъде vSphere API. Използва се за удостоверяване, четене на йерархията, създаване и изтриване на моментни снимки, искане на информация за машини и много (много) повече. Функционалността на решението е много широка, така че мога да препоръчам VMware vSphere API Reference за версията и . За по-актуални версии всичко е само гугъл.
API на VIX. Черната магия на хипервайзора, за която има отделна . VMware API за работа с файлове на хоста, без да се свързвате с тях по мрежата. Крайна възможност, когато трябва да поставите файл в машина, към която няма по-добър комуникационен канал. Това е болка и страдание, ако файлът е голям и хостът е зареден. Но тук работи правилото, че дори 56,6 Kb/s е по-добре от 0 Kb/s. В Hyper-V това нещо се нарича PowerShell Direct. Но това беше само преди
vSpehere API за уеб услуги Започвайки от vSphere 6.0 (приблизително, тъй като този API беше въведен за първи път във версия 5.5), той се използва за работа с машини за гости и измести VIX почти навсякъде. Всъщност това е друг API за управление на vSphere. За тези, които се интересуват, препоръчвам да проучат ръководство.
VDDK (Комплект за разработка на виртуален диск). Библиотеката, която беше частично обсъдена в това . Използва се за четене на виртуални дискове. Някога беше част от VIX, но с времето беше преместен в отделен продукт. Но като наследник, той използва същите кодове за грешка като VIX. Но по някаква причина няма описание на тези грешки в самия SDK. Следователно емпирично беше установено, че грешките на VDDK с други кодове са просто превод от двоичен към десетичен код. Състои се от две части - първата половина е недокументирана информация за контекста, а втората част са традиционните VIX / VDDK грешки. Например, ако видим:
VDDK error: 21036749815809.Unknown error
След това смело преобразуваме това в шестнадесетичен и получаваме 132200000001. Просто изхвърляме неинформативното начало на 132200 и остатъкът ще бъде нашият код за грешка (VDDK 1: Неизвестна грешка). За най-честите VDDK грешки, съвсем наскоро имаше отделна .
Сега нека разгледаме Windows.
Тук всичко най-необходимо и важно за нас може да се намери в стандарта Event Viewer. Но има една уловка: според дълга традиция Windows не регистрира пълния текст на грешката, а само нейния номер. Например грешка 5 е „Достъпът е отказан“, а 1722 е „RPC сървърът е недостъпен“, а 10060 е „Връзката изтече“. Разбира се, страхотно е, ако си спомняте най-известните, но какво ще кажете за невижданите досега?
И така, че животът изобщо да не изглежда като мед, грешките се съхраняват и в шестнадесетична форма с префикс 0x8007. Например 0x8007000e всъщност е 14, липса на памет. Защо и за кого е направено това е мистерия, забулена в мрак. Въпреки това, пълен списък с грешки може да бъде изтеглен безплатно и без SMS от .
Между другото, понякога има и други префикси, не само 0x8007. В такава тъжна ситуация, за да разберете HRESULT („дръжка на резултата“), трябва да се задълбочите още повече в за разработчици. В обикновения живот не ви съветвам да правите това, но ако внезапно сте се притиснали до стената или просто сте любопитни, сега знаете какво да правите.
Но другарите от Microsoft се смилиха малко над нас и показаха на света помощна програма . Това е малка част от щастието на конзолата, която може да превежда кодовете за грешки на човешки, без да използва Google. Работи така.
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, да ги декриптирате и да ги поставяте обратно. Нека бъдем честни, не е най-вълнуващото занимание.
API за управление на файлове на Windows използвани по всякакъв възможен начин при работа с файлове. Създаване на файлове, изтриване, отваряне за запис, работа с атрибути и така нататък и така нататък.
споменати по-горе PowerShell Direct като аналог на VIX API в света на Hyper-V. За съжаление не е толкова гъвкав: много ограничения във функционалността, не работи с всяка версия на хоста и не с всички гости.
RPC (Извикване на отдалечена процедура) Не мисля, че има човек, който е работил с WIndows, който да не е виждал грешки, свързани с RPC. Въпреки популярното погрешно схващане, това не е единичен протокол, а всеки клиент-сървър протокол, който отговаря на редица параметри. Въпреки това, ако има RPC грешка в нашите регистрационни файлове, 90% от времето ще бъде грешка от Microsoft RPC, който е част от DCOM (Разпределен компонентен обектен модел). Можете да намерите огромно количество документация по тази тема в мрежата, но лъвският дял от нея е доста остарял. Но ако има остро желание да се проучи темата, тогава мога да препоръчам статии , и дълъг списък .
Основните причини за RPC грешки в нашите регистрационни файлове са неуспешни опити за комуникация между VBR компоненти (сървър > прокси, например) и най-често поради проблеми с комуникацията.
На първо място сред всички топове е грешката RPC сървърът е недостъпен (1722). С прости думи, клиентът не може да установи връзка със сървъра. Как и защо - няма еднозначен отговор, но обикновено това е проблем с автентикацията или с мрежовия достъп до порт 135. Последното е типично за инфраструктури с динамично присвояване на портове. По тази тема дори има . И Microsoft има за да откриете причината за повредата.
Втората най-популярна грешка: Няма повече налични крайни точки от съпоставителя на крайни точки (1753). RPC клиентът или сървърът не успя да си присвои порт. Обикновено се случва, когато сървърът (в нашия случай машината за гости) е конфигуриран да разпределя динамично портове от тесен диапазон, който е приключил. И ако влезете от страната на клиента (в нашия случай, VBR сървъра), това означава, че нашият VeeamVssAgent или не е стартиран, или не е регистриран като RPC интерфейс. Има и по тази тема .
Е, за да завършим Топ 3 RPC грешки, нека си спомним неуспешно извикване на RPC функция (1726). Появява се, ако връзката е установена, но RPC заявките не се обработват. Например, изискваме информация за състоянието на VSS (внезапно точно сега там се прави мина в сянка и ние се опитваме да се изкачим) и в отговор на нас мълчание и игнориране.
Windows Tape Backup API необходими за работа с лентови библиотеки или устройства. Както споменах в началото: нямаме удоволствието да пишем собствени драйвери и след това да страдаме с поддръжката на всяко устройство. Следователно vim няма собствени драйвери. Всичко чрез стандартен API, чиято поддръжка се изпълнява от самите доставчици на хардуер. Толкова по-логично, нали?
SMB / CIFS По навик всеки ги пише едно до друго, въпреки че не всеки си спомня, че CIFS (Common Internet File System) е само частна версия на SMB (Server Message Block). Така че няма нищо лошо в обобщаването на тези понятия. Samba вече е реализация на LinuxUnix и има своите особености, но аз се отклоних. Какво е важно тук: когато Veeam поиска да напише нещо в UNC пътя (сървърна директория), сървърът използва йерархията на драйверите на файловата система, включително mup и mrxsmb, за да напише в топката. Съответно тези драйвери също ще генерират грешки.
Не може без Winsock API. Ако нещо трябва да се направи през мрежата, VBR работи чрез API на Windows Socket, известен като Winsock. Така че, ако видим куп IP:Port в дневника, това е всичко. Официалната документация има добър списък с възможни .
споменати по-горе WMI (Windows Management Instrumentation) е един вид всемогъщ API за управление на всичко и всички в света на Windows. Например, когато работите с Hyper-V, почти всички заявки към хоста минават през него. С една дума, нещото е абсолютно незаменимо и много мощно в своите възможности. В опит да помогнете да разберете къде и какво е счупено, вграденият инструмент WBEMtest.exe помага много.
И последно в списъка, но в никакъв случай не на последно място по важност - VSS (Volume Shadow Storage). Темата е толкова неизчерпаема и мистериозна, колкото и документация е изписана по нея. Shadow Copy най-просто се разбира като специален тип моментна снимка, което по същество е. Благодарение на него можете да правите съвместими с приложения архиви във VMware и почти всичко в Hyper-V. Имам планове да направя отделна статия с малко натискане на VSS, но засега можете да опитате да прочетете . Просто внимавайте, защото. опитвайки се да разберете VSS светкавично, може да доведе до мозъчно увреждане.
На това, може би, можем да спрем. Смятам задачата да обясня най-основните неща за изпълнена, така че в следващата глава вече ще разгледаме дневниците. Но ако имате въпроси, не се колебайте да ги зададете в коментарите.
Източник: www.habr.com