Працягваем наша апусканне ў захапляльны свет гадан… траблшутинга па логах. У мы дамовіліся аб значэнні базавых тэрмінаў і адным вочкам разгледзелі агульную структуру Veeam, як адзінага дадатку. Задача на гэтую - разабрацца як фармуюцца лог файлы, што за інфармацыя ў іх адлюстравана і чаму яны выглядаюць як выглядаюць.
Як вы думаеце, што ўвогуле такое гэтыя «лагі»? Па меркаванні большасці, логам любога прыкладання павінна быць адведзена роля гэтакай усемагутнай сутнасці, якая большую частку часу гібее дзесьці на задворках, але ў патрэбны момант з'яўляецца з ніадкуль у зіхатлівых даспехах і ўсіх ратуе. Гэта значыць, у іх павінна быць усё, пачынаючы з найменшых памылак у кожным кампаненце, да асобных транзакцый базы. І каб пасля памылкі адразу пісалася як яшчэ выправіць. І змяшчацца гэта ўсё павінна ў пару мегабайт, не больш. Гэта ж проста тэкст! Не могуць тэкставыя файлы займаць дзясяткі гігабайт, я дзесьці гэта чуў!
Такім чынам, логі
У рэальным свеце логі гэта ўсяго толькі архіў дыягнастычнай інфармацыі. І што тамака захоўваць, адкуль браць інфармацыю для захоўвання і наколькі падрабязнай яна павінна быць, вырашаць самім распрацоўнікам. Хтосьці ідзе па шляху мінімалізму захоўваючы запісы ўзроўню ВКЛ/ВЫКЛ, а хтосьці старанна зграбае ўсё, да чаго толькі змог дацягнуцца. Хаця ёсць яшчэ і прамежкавы варыянт з магчымасцю выбару так званага Logging Level, калі ты сам паказваеш наколькі падрабязную інфармацыю ты хочаш захоўваць і наколькі ў цябе шмат лішняга месца на дысках =) У VBR такіх узроўняў ажно шэсць, дарэчы кажучы. І, паверце, вы не жадаеце бачыць што адбываецца пры максімальна падрабязным лагаванні са вольным месцам на вашым дыску.
Добра. Мы прыкладна зразумелі што жадаем захоўваць, але ўстае законнае пытанне: адкуль браць гэтую інфармацыю? Частка падзей для лагавання, вядома, фармуем мы самі нашымі ўнутранымі працэсамі. Але што рабіць, калі адбываецца ўзаемадзеянне з навакольным асяроддзем? Каб не скочвацца ў апраметнае пекла з мыліц і ровараў, Veeam мае тэндэнцыю не вынаходзіць ужо вынайдзеныя вынаходкі. Заўсёды, калі ёсць ужо гатовае API, убудаваная ў сістэму функцыя, бібліятэка і да т.п., мы аддамо перавагу гатовым варыянтам, перш чым пачынаць гарадзіць свае мудрагелістыя рашэнні. Хаця апошніх таксама хапае. Таму пры аналізе логаў важна разумець, што ільвіная дзель памылак прыходзіцца на паведамленні ад іншых API, сістэмных выклікаў і іншых бібліятэк. У дадзеным выпадку роля VBR зводзіцца да форварда гэтых памылак у файлы логаў as is. А асноўная задача карыстальніка - навучыцца разумець, які радок ад каго, і за што гэты "хто" адказвае. Таму, калі код памылкі з лога VBR прыводзіць вас на старонку MSDN, гэта нармальна і правільна.
Як мы дамовіліся раней: Veeam - гэта так званае SQL-based прыкладанне. А значыць усе наладкі, уся інфармацыя і ўвогуле ўсё, што толькі неабходна для нармальнага функцыянавання — усё захоўваецца ў яго базе. Адсюль простая ісціна: тое, чаго няма ў логах, хутчэй за ўсё ёсць у базе. Але і гэта не сярэбраная куля: некаторых рэчаў няма ні ў лакальных логах кампанентаў Veeam, ні ў яго базе. Таму трэба навучыцца вывучаць логі хаста, логі лакальнай машыны і логі ўвогуле ўсяго, што ўдзельнічае падчас бекапа і рэстара. А бывае і так, што патрэбнай інфармацыі няма ўвогуле нідзе. Такі шлях.
Некалькі прыкладаў такіх API
Дадзены спіс не ставіць сабе за мэту быць выключнай паўнаты, так што не трэба ў ім шукаць ісціну ў апошняй інстанцыі. Яго задача - толькі паказаць самыя частыя іншыя API і тэхналогіі, якія выкарыстоўваюцца ў нашых прадуктах.
Пачнём з VMware.
Першым у спісе будзе vSphere API. Выкарыстоўваецца для аўтэнтыфікацыі, чытання іерархіі, стварэння і выдаленні снапшотаў, запыту інфармацыі аб машынах і шмат чаго (вельмі шмат чаго) чаго іншага. Функцыянал рашэння вельмі шырокі, таму ўсім жадаючым магу парэкамендаваць VMware vSphere API Reference для версіі и . Для больш актуальных версій усё проста гугліцца.
VIX API. Чорная магія гіпервізара, для якой ёсць асобны . 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.
І апошні па спісе, але зусім не апошні па значнасці - ВСС (Volume Shadow Storage). Тэма настолькі невычэрпная і загадкавая, наколькі шмат па ёй напісана дакументацыі. Shadow Copy прасцей за ўсё разумець як асаблівы тып снапшота, якім па сутнасці ён і з'яўляецца. Дзякуючы яму ў VMware можна рабіць application-consistent бекапы, а ў Hyper-V наогул ці ледзь не ўсё. У мяне ёсць у планах зрабіць асобны артыкул з нейкай выцісканнем па VSS, але пакуль можаце паспрабаваць пачытаць . Толькі асцярожна, т.я. спроба зразумець VSS з наскоку можа прывесці да траўмаў галаўнога мозгу.
На гэтым, мабыць, можна і спыніцца. Задачу растлумачыць самыя базавыя рэчы лічу выкананай, так што ў наступным раздзеле ўжо будзем глядзець на логі. Але калі засталіся пытанні, то не саромейцеся агучваць іх у каментарах.
Крыніца: habr.com