Продолжуваме со нашето потопување во фасцинантниот свет на погодување ... решавање проблеми со дневници. ВО се согласивме за значењето на основните поими и ја разгледавме целокупната структура на Veeam како единствена апликација со едно око. Задачата за оваа е да открие како се формираат датотеките за дневници, какви информации се прикажани во нив и зошто изгледаат така како што изгледаат.
Што мислите, какви се овие „трупци“? Според повеќето, на дневниците на која било апликација треба да им се додели улога на еден вид семоќен ентитет кој најчесто вегетира некаде во дворот, но во вистинскиот момент се појавува од никаде во сјаен оклоп и ги спасува сите. Односно, тие треба да содржат сè, од најмали грешки во секоја компонента до индивидуални трансакции со базата на податоци. И така што по грешката веднаш беше напишано како поинаку да се поправи. И сето ова треба да се вклопи во пар мегабајти, не повеќе. Тоа е само текст! Текстуалните датотеки не можат да земат десетици гигабајти, некаде го слушнав!
Значи дневниците
Во реалниот свет, дневниците се само архива на дијагностички информации. А што да се складира таму, каде да се добијат информации за складирање и колку тоа треба да биде детално, зависи од самите програмери да одлучат. Некој го следи патот на минимализмот со водење евиденција за нивото на ВКЛУЧЕНО/ИСКЛУЧЕНО, а некој вредно собира сè што може да достигне. Иако има и средна опција со можност за избор на таканареченото Logging Level, кога самиот ќе посочиш колку детални информации сакате да зачувате и колку дополнителен простор на дискот имате =) VBR има шест такви нивоа, патем. И, верувајте ми, не сакате да видите што се случува со најдеталната евиденција со слободен простор на вашиот диск.
Добро. Грубо разбравме што сакаме да заштедиме, но се поставува легитимно прашање: од каде да ги добиете овие информации? Се разбира, ние сме дел од настаните за да се евидентираме со нашите внатрешни процеси. Но, што да се прави кога има интеракција со надворешното опкружување? За да не се лизне во пеколот од патерици и велосипеди, Veeam има тенденција да не измислува пронајдоци кои се веќе измислени. Секогаш кога има готов API, вградена функција, библиотека итн., ќе им дадеме предност на готови опции пред да почнеме да ги оградуваме нашите контрацептиви. Иако второто е исто така доволно. Затоа, кога се анализираат дневниците, важно е да се разбере дека лавовскиот дел од грешките паѓа на пораки од API-и од трети страни, системски повици и други библиотеки. Во овој случај, улогата на VBR се сведува на препраќање на овие грешки до датотеките за евиденција како што е. И главната задача на корисникот е да научи да разбере која линија е од кого, и за што е одговорен овој „кој“. Значи, ако кодот за грешка од дневникот на VBR ве однесе до страницата MSDN, тоа е во ред и точно.
Како што се договоривме претходно: Veeam е таканаречена апликација базирана на SQL. Ова значи дека сите поставки, сите информации и воопшто сè што е потребно само за нормално функционирање - сè е зачувано во неговата база на податоци. Оттука и едноставната вистина: она што го нема во дневниците најверојатно е во базата на податоци. Но, ова не е ни сребрен куршум: некои работи не се во локалните дневници на компонентите на Veeam, ниту во неговата база на податоци. Затоа, треба да научите како да ги проучувате дневниците на домаќинот, дневниците на локалната машина и дневниците на сè што е вклучено во процесот на резервна копија и обновување. И, исто така, се случува потребните информации да не се достапни никаде. Тоа е патот.
Некои примери на такви API
Оваа листа нема за цел да биде исклучително комплетна, па затоа нема потреба да ја барате крајната вистина во неа. Неговата цел е само да ги прикаже најчестите API и технологии од трети страни што се користат во нашите производи.
Да почнеме со VMware.
Прв на листата ќе биде vSphere API. Се користи за автентикација, читање на хиерархијата, создавање и бришење снимки, барање информации за машините и многу (многу) повеќе. Функционалноста на решението е многу широка, така што можам да го препорачам VMware vSphere API Reference за верзијата и . За повеќе актуелни верзии, сè е само гуглано.
VIX API. Црната магија на хипервизорот, за која постои посебна . VMware API за работа со датотеки на домаќинот без поврзување со нив преку мрежата. Варијанта на последно средство кога треба да ставите датотека во машина до која нема подобар канал за комуникација. Тоа е болка и страдање ако датотеката е голема и домаќинот е вчитан. Но, овде функционира правилото дека дури и 56,6 Kb / s е подобро од 0 Kb / s. Во Hyper-V, ова нешто се нарекува PowerShell Direct. Но, тоа беше само порано
vSpehere Web Services API Почнувајќи од vSphere 6.0 (приближно, бидејќи ова API за прв пат беше претставено на верзијата 5.5) се користи за работа со гостински машини и го замени VIX речиси насекаде. Всушност, ова е уште еден API за управување со vSphere. На заинтересираните им препорачувам да учат прирачник.
ВДДК (Комплет за развој на виртуелен диск). Библиотеката, за која делумно се зборуваше во ова . Се користи за читање виртуелни дискови. Некогаш беше дел од VIX, но со текот на времето беше преместен во посебен производ. Но, како наследник, ги користи истите кодови за грешка како VIX. Но, поради некоја причина, нема опис на овие грешки во самиот SDK. Затоа, емпириски беше откриено дека грешките во VDDK со други кодови се само превод од бинарен во децимален код. Се состои од два дела - првата половина е недокументирана информација за контекстот, а вториот дел се традиционалните VIX / VDDK грешки. На пример, ако видиме:
VDDK error: 21036749815809.Unknown error
Потоа смело го претвораме ова во хексадецимален и добиваме 132200000001. Едноставно го отфрламе неинформативниот почеток на 132200, а остатокот ќе биде нашиот код за грешка (VDDK 1: Непозната грешка). За најчестите грешки на VDDK, неодамна имаше посебна .
Сега да погледнеме Windows.
Овде се што ни е најпотребно и најважно може да се најде во стандардот Прегледувач на настани. Но, постои еден фаќање: според долгата традиција, Windows не го евидентира целиот текст на грешката, туку само неговиот број. На пример, грешката 5 е „Пристапот е одбиен“, а 1722 е „серверот RPC е недостапен“, а 10060 е „Времето на врската истече“. Секако, одлично е ако се сеќавате на најпознатите, но што е со досега невидените?
И за животот воопшто да не изгледа како мед, грешките се чуваат и во хексадецимална форма, со префикс 0x8007. На пример, 0x8007000e е всушност 14, без меморија. Зошто и за кого е направено ова е мистерија обвиткана во темнина. Сепак, комплетната листа на грешки може да се преземе бесплатно и без СМС од .
Патем, понекогаш има и други префикси, не само 0x8007. Во таква тажна ситуација, за да го разберете HRESULT („рачка за резултат“), треба да навлезете уште подлабоко во за програмери. Во обичниот живот, не ве советувам да го направите ова, но ако одеднаш сте притиснале на ѕидот или сте само љубопитни, сега знаете што да правите.
Но, другарите во Мајкрософт малку се сожалија и му покажаа на светот корисност . Ова е мало парче среќа на конзолата што може да ги преведе кодовите за грешки во човечки без користење на 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 од него, да се дешифрираат и да се залепат назад. Да бидеме искрени, не е највозбудливата активност.
АПИ за управување со датотеки на Windows се користи на секој можен начин при работа со датотеки. Креирање датотеки, бришење, отворање за пишување, работа со атрибути и така натаму и така натаму.
претходно споменато PowerShell Direct како аналог на VIX API во светот Hyper-V. За жал, не толку флексибилен: многу ограничувања на функционалноста, не работи со секоја верзија на домаќинот и не со сите гости.
Rpc (Повик за далечинска процедура) Мислам дека нема ниту едно лице кое работело со WIndows кое не видело грешки поврзани со RPC. И покрај популарната заблуда, ова не е единствен протокол, туку каков било протокол клиент-сервер кој задоволува голем број параметри. Меѓутоа, ако има грешка RPC во нашите дневници, 90% од времето ќе биде грешка од Microsoft RPC, која е дел од DCOM (Distributed Component Object Model). Можете да најдете огромна количина на документација на оваа тема на мрежата, но лавовскиот дел од неа е прилично застарен. Но, ако постои акутна желба да се проучува темата, тогаш можам да препорачам статии , и долга листа .
Главните причини за грешките на RPC во нашите дневници се неуспешните обиди за комуникација помеѓу компонентите на VBR (сервер > прокси, на пример) и најчесто поради проблеми во комуникацијата.
Врвот меѓу сите врвови е грешката Серверот RPC е недостапен (1722). Во едноставни термини, клиентот не можеше да воспостави врска со серверот. Како и зошто - нема единствен одговор, но обично се работи за проблем со автентикација или со мрежен пристап до портата 135. Последново е типично за инфраструктури со динамично доделување порти. На оваа тема има дури . И Мајкрософт има да се најде причината за неуспехот.
Втора најпопуларна грешка: Нема повеќе достапни крајни точки од маперот на крајната точка (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). Значи, нема ништо лошо во генерализирањето на овие концепти. Самба е веќе имплементација на LinuxUnix и има свои особености, но јас отстапувам. Она што е важно овде: кога Veeam бара да напише нешто на патеката UNC (директориум на сервери), серверот ја користи хиерархијата на двигатели на датотечниот систем, вклучувајќи ги mup и mrxsmb, за да напише на топката. Соодветно на тоа, овие драјвери исто така ќе генерираат грешки.
Не може без Winsock API. Ако нешто треба да се направи преку мрежата, VBR работи преку Windows Socket API, популарно познат како Winsock. Значи, ако видиме куп IP:Port во дневникот, ова е тоа. Официјалната документација има добра листа на можни .
претходно споменато WMI (Windows Management Instrumentation) е еден вид семоќен API за управување со сè и секого во светот на Windows. На пример, кога работите со Hyper-V, речиси сите барања до домаќинот поминуваат низ него. Со еден збор, нештото е апсолутно незаменливо и многу моќно во своите можности. Во обид да помогне да откриете каде и што е скршено, вградената алатка WBEMtest.exe помага многу.
И последно на листата, но ни најмалку по важност - VSS (Складирање на сенки за волумен). Темата е неисцрпна и мистериозна колку што е напишана многу документација на неа. Shadow Copy наједноставно се сфаќа како посебен тип на снимка, што во суштина е. Благодарение на него, можете да направите резервни копии во согласност со апликациите во VMware, и речиси сè во Hyper-V. Имам планови да направам посебна статија со малку стискање на VSS, но засега може да се обидете да прочитате . Само бидете внимателни, бидејќи. обидот за брзо разбирање на VSS може да доведе до повреда на мозокот.
На ова, можеби, можеме да застанеме. Задачата за објаснување на најосновните работи ја сметам за завршена, па во следното поглавје веќе ќе ги разгледаме дневниците. Но, ако имате какви било прашања, слободно прашајте ги во коментарите.
Извор: www.habr.com