Одакле потичу дневници? Вееам Лог Дивинг

Одакле потичу дневници? Вееам Лог Дивинг

Настављамо са урањањем у фасцинантан свет нагађања ... решавања проблема помоћу евиденције. ИН претходни чланак сложили смо се око значења основних појмова и посматрали целокупну структуру Вееам-а као једну апликацију са једним оком. Задатак за овај је да схвати како се формирају датотеке евиденције, какве информације се у њима приказују и зашто изгледају онако како изгледају.

Шта мислите шта су ови "дневници"? Према већини, логовима било које апликације треба доделити улогу својеврсног свемоћног ентитета који већину времена вегетира негде у дворишту, али се у правом тренутку појављује ниоткуда у сјајном оклопу и спасава све. То јест, требало би да садрже све, од најмањих грешака у свакој компоненти до појединачних трансакција базе података. И тако да је после грешке одмах писало како другачије да је исправим. И све ово треба да стане у пар мегабајта, не више. То је само текст! Текстуални фајлови не могу да заузму десетине гигабајта, негде сам то чуо!

Дакле, трупци

У стварном свету, дневници су само архива дијагностичких информација. А шта да тамо складиштите, где да добијете информације за складиштење и колико детаљан треба да буде, на самим програмерима да одлуче. Неко иде путем минимализма тако што води евиденцију нивоа ОН/ОФФ, а неко вредно грабља све што стигне. Иако постоји и средња опција са могућношћу одабира такозваног Логгинг Левел-а, када сами назначите колико детаљне информације желите да чувате и колико додатног простора на диску имате =) ВБР, иначе, има шест таквих нивоа. И, верујте ми, не желите да видите шта се дешава са најдетаљнијим евидентирањем са слободним простором на вашем диску.

У реду. Отприлике смо схватили шта желимо да сачувамо, али поставља се легитимно питање: одакле добити ове информације? Наравно, ми чинимо део догађаја за логовање кроз наше унутрашње процесе. Али шта учинити када постоји интеракција са спољним окружењем? Да не би склизнуо у пакао штака и бицикала, Вееам тежи да не измишља изуме који су већ измишљени. Кад год постоји готов АПИ, уграђена функција, библиотека, итд., даћемо предност готовим опцијама пре него што почнемо да ограђујемо наше направе. Иако је и ово друго довољно. Стога, када анализирате дневнике, важно је разумети да највећи део грешака пада на поруке из АПИ-ја трећих страна, системске позиве и друге библиотеке. У овом случају, улога ВБР-а се своди на прослеђивање ових грешака у датотеке евиденције. А главни задатак корисника је да научи да разуме која линија је од кога и за шта је овај „ко“ одговоран. Дакле, ако вас код грешке из ВБР евиденције одведе на МСДН страницу, то је у реду и исправно.

Као што смо се раније договорили: Вееам је такозвана апликација заснована на СКЛ-у. То значи да су сва подешавања, све информације и уопште све што је потребно само за нормално функционисање – све се чува у његовој бази података. Отуда једноставна истина: оно што није у евиденцији највероватније је у бази података. Али ни ово није сребрни метак: неке ствари се не налазе у локалним евиденцијама Вееам компоненти, нити у његовој бази података. Због тога морате научити како да проучавате евиденције хоста, евиденције локалне машине и евиденције свега што је укључено у процес прављења резервних копија и враћања. А такође се дешава да потребне информације уопште нису нигде доступне. То је начин. 

Неки примери таквих АПИ-ја

Ова листа нема за циљ да буде изузетно потпуна, тако да у њој не треба тражити коначну истину. Његова сврха је само да прикаже најчешће АПИ-је и технологије трећих страна које се користе у нашим производима.

Почнимо од VMware

Први на листи ће бити вСпхере АПИ. Користи се за аутентификацију, читање хијерархије, креирање и брисање снимака, тражење информација о машинама и још много тога (веома много). Функционалност решења је веома широка, тако да могу да препоручим ВМваре вСпхере АПИ Референце за верзију 5.5 и 6.0. За актуелније верзије, све је само гуглано.

ВИКС АПИ. Црна магија хипервизора, за коју постоји посебан листа грешака. ВМваре АПИ за рад са датотекама на хосту без повезивања на њих преко мреже. Крајња варијанта када треба да ставите фајл у машину којој нема бољег канала комуникације. То је бол и патња ако је датотека велика и хост је учитан. Али овде функционише правило да је чак 56,6 Кб/с боље од 0 Кб/с. У Хипер-В, ова ствар се зове ПоверСхелл Дирецт. Али то је било само раније

вСпехере Веб Сервицес АПИ Почевши од вСпхере 6.0 (отприлике, пошто је овај АПИ први пут представљен у верзији 5.5) користи се за рад са гостујућим машинама и скоро свуда је заменио ВИКС. У ствари, ово је још један АПИ за управљање вСпхере. За оне који су заинтересовани, препоручујем да уче Одлично упутство. 

ВДДК (Кит за развој виртуелног диска). Библиотека, о чему је у овом делу било речи Чланак. Користи се за читање виртуелних дискова. Некада је био део ВИКС-а, али је временом премештен у посебан производ. Али као наследник, користи исте кодове грешака као ВИКС. Али из неког разлога, у самом СДК-у нема описа ових грешака. Стога се емпиријски показало да су ВДДК грешке са другим кодовима само превод из бинарног у децимални код. Састоји се из два дела - прва половина је недокументована информација о контексту, а друга део су традиционалне ВИКС / ВДДК грешке. На пример, ако видимо:

VDDK error: 21036749815809.Unknown error

Затим храбро конвертујемо ово у хексадецимални и добијамо 132200000001. Једноставно одбацимо неинформативни почетак 132200, а остатак ће бити наш код грешке (ВДДК 1: Непозната грешка). О најчешћим ВДДК грешкама, недавно је било посебно чланак.

Погледајмо сада ВИндовс.

Овде се у стандарду може наћи све што је за нас најпотребније и најважније Приказивач догађаја. Али постоји једна квака: према дугој традицији, Виндовс не бележи цео текст грешке, већ само њен број. На пример, грешка 5 је „Приступ одбијен“, а 1722 је „РПЦ сервер је недоступан“, а 10060 је „Време је истекло за везу“. Наравно, одлично је ако се сетите оних најпознатијих, али шта је са до сада невиђеним? 

А да живот уопште не изгледа као мед, грешке се чувају и у хексадецималном облику, са префиксом 0к8007. На пример, 0к8007000е је заправо 14, Нема меморије. Зашто и за кога је то урађено, мистерија је обавијена мраком. Међутим, комплетна листа грешака се може преузети бесплатно и без СМС-а девцентер.

Иначе, понекад постоје и други префикси, а не само 0к8007. У тако тужној ситуацији, да бисте разумели ХРЕСУЛТ („управљач резултатом“), потребно је да уђете још дубље у документација за програмере. У обичном животу, не саветујем вам да то радите, али ако сте се изненада притиснули на зид или сте само радознали, сада знате шта да радите.

Али другови из Мајкрософта су нам се мало сажалили и показали свету корисност ЕРР. Ово је мали део среће на конзоли који може да преведе кодове грешака у људски без коришћења Гоогле-а. То ради овако.

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"

Поставља се легитимно питање: зашто одмах не упишемо дешифровање у дневнике, већ оставимо ове мистериозне кодове? Одговор је у апликацијама трећих страна. Када сами повучете неки ВинАПИ позив, није тешко дешифровати његов одговор, јер постоји чак и посебан ВинАПИ позив за ово. Али као што је већ поменуто, све што нам дође само у одговорима улази у наше дневнике. А овде, да би се то дешифровало, морало би се стално пратити овај ток свести, из њега извлачити делове са Виндовс грешкама, дешифровати их и лепити назад. Будимо искрени, не најузбудљивија активност.

Виндовс АПИ за управљање датотекама користи се на све могуће начине при раду са датотекама. Креирање датотека, брисање, отварање за писање, рад са атрибутима и тако даље и тако даље.

Горе поменути ПоверСхелл Дирецт као аналог ВИКС АПИ-ја у Хипер-В свету. Нажалост, није тако флексибилан: пуно ограничења у функционалности, не ради са сваком верзијом домаћина и не са свим гостима.

РПЦ (Позив даљинске процедуре) Мислим да не постоји ниједна особа која је радила са ВИндовс-ом а која није видела грешке везане за РПЦ. Упркос популарној заблуди, ово није један протокол, већ било који клијент-сервер протокол који задовољава низ параметара. Међутим, ако постоји РПЦ грешка у нашим евиденцијама, у 90% случајева то ће бити грешка из Мицрософт РПЦ-а, који је део ДЦОМ-а (Дистрибутед Цомпонент Објецт Модел). На мрежи можете пронаћи огромну документацију о овој теми, али је њен лавовски део прилично застарео. Али ако постоји акутна жеља за проучавањем теме, онда могу препоручити чланке Шта је РПЦ?, Како РПЦ Воркс и дуга листа РПЦ грешке.

Главни узроци РПЦ грешака у нашим евиденцијама су неуспели покушаји комуникације између ВБР компоненти (сервер > проки, на пример) и најчешће због проблема у комуникацији.

Највиши врх међу свим врховима је грешка РПЦ сервер је недоступан (1722). Једноставно речено, клијент није могао да успостави везу са сервером. Како и зашто – нема јединственог одговора, али обично је то проблем са аутентификацијом или са приступом мрежи порту 135. Ово последње је типично за инфраструктуре са динамичким додељивањем портова. На ову тему има чак одвојени ХФ. И Мицрософт има обиман водич да се пронађе узрок неуспеха.

Друга најпопуларнија грешка: Нема више доступних крајњих тачака из мапера крајњих тачака (1753). РПЦ клијент или сервер није успео да себи додели порт. Обично се дешава када је сервер (у нашем случају, машина за госте) конфигурисан да динамички додељује портове из уског опсега који је завршио. А ако се пријавите са стране клијента (у нашем случају, ВБР сервера), то значи да наш ВееамВссАгент или није покренут или није регистрован као РПЦ интерфејс. Има и на ову тему одвојени ХФ.

Па, да довршимо 3 највеће РПЦ грешке, подсетимо се да позив РПЦ функције није успео (1726). Појављује се ако је веза успостављена, али се РПЦ захтеви не обрађују. На пример, тражимо информацију о статусу ВСС (одједном се тамо прави мина у сенци, а ми покушавамо да се попнемо), а као одговор на нас, ћутање и игнорисање.

Виндовс Тапе Бацкуп АПИ потребно за рад са библиотекама трака или диск јединицама. Као што сам поменуо на почетку: немамо задовољство да пишемо сопствене драјвере, а затим да патимо са подршком за сваки уређај. Дакле, вим нема сопствени драјвер. Све кроз стандардни АПИ, чију подршку имплементирају сами произвођачи хардвера. Толико логичније, зар не?

СМБ / ЦИФС По навици, сви их пишу једно поред другог, иако се не сећају сви да је ЦИФС (Цоммон Интернет Филе Систем) само приватна верзија СМБ (Сервер Мессаге Блоцк). Дакле, нема ништа лоше у генерализацији ових појмова. Самба је већ имплементација ЛинукУник-а и има своје специфичности, али сам скренуо пажњу. Оно што је овде важно: када Вееам тражи да упише нешто на УНЦ путању (директоријум сервера), сервер користи хијерархију драјвера система датотека, укључујући муп и мрксмб, да пише у лопту. Сходно томе, ови драјвери ће такође генерисати грешке.

Не може без Винсоцк АПИ. Ако нешто треба да се уради преко мреже, ВБР ради преко Виндовс Соцкет АПИ-ја, популарно познатог као Винсоцк. Дакле, ако видимо гомилу ИП:Порт у евиденцији, то је то. Званична документација има добру листу могућих грешке.

Горе поменути ВМИ (Виндовс Манагемент Инструментатион) је нека врста свемоћног АПИ-ја за управљање свим и свима у Виндовс свету. На пример, када радите са Хипер-В, скоро сви захтеви домаћину пролазе кроз њега. Једном речју, ствар је апсолутно незаменљива и веома моћна у својим могућностима. У покушају да помогне да се открије где и шта је покварено, уграђени алат ВБЕМтест.еке много помаже.

И последње на листи, али никако најмање по важности - ВСС (Волуме Схадов Стораге). Тема је неисцрпна и тајанствена колико је о њој написано документације. Схадов Цопи се најједноставније схвата као посебна врста снимка, што у суштини и јесте. Захваљујући њему, можете да правите резервне копије конзистентне апликације у ВМваре-у и скоро све у Хипер-В-у. Планирам да направим посебан чланак са мало притиска на ВСС, али за сада можете покушати да прочитате овај опис. Само пази, јер. покушај да се брзо разуме ВСС може довести до повреде мозга.

На овоме, можда, можемо стати. Задатак објашњавања најосновнијих ствари сматрам завршеним, тако да ћемо у следећем поглављу већ погледати дневнике. Али ако имате било каквих питања, слободно их поставите у коментарима.

Извор: ввв.хабр.цом

Додај коментар