ProHoster > Blogs > Administrācija > No kurienes nāk baļķi? Veeam nirŔana no baļķiem

No kurienes nāk baļķi? Veeam nirŔana no baļķiem

No kurienes nāk baļķi? Veeam nirŔana no baļķiem

Mēs turpinām iegremdēties aizraujoÅ”ajā uzminētajā pasaulē... problēmu novērÅ”ana, izmantojot baļķus. IN iepriekŔējais raksts mēs vienojāmies par pamatjēdzienu nozÄ«mi un ar vienu aci skatÄ«jāmies uz Veeam kopējo struktÅ«ru kā vienu pieteikumu. Å Ä« uzdevuma uzdevums ir noskaidrot, kā tiek veidoti žurnālfaili, kāda veida informācija tajos tiek parādÄ«ta un kāpēc tie izskatās tā, kā izskatās.

Kas, jÅ«suprāt, ir Å”ie "baļķi"? Vairums uzskata, ka jebkuras aplikācijas žurnāliem jāpieŔķir sava veida visvarenās bÅ«tnes loma, kas lielākoties veÄ£etē kaut kur pagalmā, bet Ä«stajā brÄ«dÄ« nez no kurienes parādās mirdzoŔās bruņās un glābj visus. Tas nozÄ«mē, ka tajos jāietver viss, sākot no mazākajām kļūdām katrā komponentā un beidzot ar atseviŔķām datu bāzes transakcijām. Un tā, ka pēc kļūdas uzreiz tika rakstÄ«ts, kā vēl labot. Un tam visam vajadzētu ietilpt pāris megabaitos, ne vairāk. Tas ir tikai teksts! Teksta faili nevar aizņemt desmitiem gigabaitu, es to kaut kur dzirdēju!

Tātad baļķi

Reālajā pasaulē žurnāli ir tikai diagnostikas informācijas arhÄ«vs. Un ko tur glabāt, kur iegÅ«t informāciju glabāŔanai un cik tai jābÅ«t detalizētai, tas ir paÅ”u izstrādātāju ziņā. Kāds iet minimālisma ceļu, veicot IESLĒGÅ ANAS / IZSLĒGÅ ANAS lÄ«meņa uzskaiti, un kāds cÄ«tÄ«gi grābj visu, ko vien var sasniegt. Lai gan ir arÄ« starpposma iespēja ar iespēju izvēlēties tā saukto Logging Level, kad pats norādāt, cik detalizētu informāciju vēlies glabāt un cik tev ir papildu diska vietas =) VBR, starp citu, ir seÅ”i Ŕādi lÄ«meņi. Un, ticiet man, jÅ«s nevēlaties redzēt, kas notiek ar visdetalizētāko reÄ£istrÄ“Å”anu ar brÄ«vu vietu jÅ«su diskā.

Labi. Mēs aptuveni sapratām, ko vēlamies ietaupÄ«t, taču rodas pamatots jautājums: no kurienes iegÅ«t Å”o informāciju? Protams, mēs esam daļa no notikumiem, lai reÄ£istrētos paÅ”i ar mÅ«su iekŔējiem procesiem. Bet ko darÄ«t, ja notiek mijiedarbÄ«ba ar ārējo vidi? Lai neslÄ«dētu kruÄ·u un velosipēdu ellē, Veeam mēdz neizgudrot jau izgudrotus izgudrojumus. Ikreiz, kad ir gatava API, iebÅ«vēta funkcija, bibliotēka utt., mēs dosim priekÅ”roku gatavām opcijām, pirms sākam iežogot savus Ä·ermeņus. Lai gan ar pēdējo arÄ« pietiek. Tāpēc, analizējot žurnālus, ir svarÄ«gi saprast, ka lielākā daļa kļūdu attiecas uz ziņojumiem no treÅ”o puÅ”u API, sistēmas zvaniem un citām bibliotēkām. Å ajā gadÄ«jumā VBR loma ir Å”o kļūdu pārsÅ«tÄ«Å”ana uz žurnāla failiem. Un lietotāja galvenais uzdevums ir iemācÄ«ties saprast, kura lÄ«nija ir no kuras un par ko Å”is ā€œkurÅ”ā€ ir atbildÄ«gs. Tātad, ja kļūdas kods no VBR žurnāla novirza jÅ«s uz MSDN lapu, tas ir labi un pareizi.

Kā mēs vienojāmies iepriekÅ”: Veeam ir tā sauktā uz SQL balstÄ«ta lietojumprogramma. Tas nozÄ«mē, ka visi iestatÄ«jumi, visa informācija un vispār viss, kas nepiecieÅ”ams tikai normālai darbÄ«bai ā€“ viss tiek glabāts tās datubāzē. LÄ«dz ar to vienkārŔā patiesÄ«ba: tas, kas nav žurnālos, visticamāk, ir datu bāzē. Bet arÄ« Ŕī nav sudraba lode: dažas lietas nav ne Veeam komponentu lokālajos žurnālos, ne tā datubāzē. Tāpēc jums jāiemācās izpētÄ«t resursdatora žurnālus, vietējās maŔīnas žurnālus un visu, kas ir iesaistÄ«ts dublÄ“Å”anas un atjaunoÅ”anas procesā, žurnālus. Un gadās arÄ« tā, ka vajadzÄ«gā informācija vispār nekur nav pieejama. Tāds ir ceļŔ. 

Daži Ŕādu API piemēri

Å Ä« saraksta mērÄ·is nav bÅ«t ārkārtÄ«gi pilnÄ«gam, tāpēc nav vajadzÄ«bas tajā meklēt galÄ«go patiesÄ«bu. Tā mērÄ·is ir tikai parādÄ«t mÅ«su produktos visbiežāk izmantotās treÅ”o puÅ”u API un tehnoloÄ£ijas.

Sāksim ar VMware. 

Pirmais sarakstā bÅ«s vSphere API. Izmanto autentifikācijai, hierarhijas lasÄ«Å”anai, momentuzņēmumu izveidei un dzÄ“Å”anai, informācijas pieprasÄ«Å”anai par maŔīnām un daudz ko citu. Risinājuma funkcionalitāte ir ļoti plaÅ”a, tāpēc varu ieteikt versijai VMware vSphere API Reference 5.5 Šø 6.0. Jaunākām versijām viss ir tikai google.

VIX API. Hipervizora melnā maÄ£ija, kurai ir atseviŔķs kļūdu saraksts. VMware API darbam ar failiem resursdatorā, neveidojot savienojumu ar tiem tÄ«klā. Pēdējās iespējas variants, kad fails jāievieto maŔīnā, kurai nav labāka saziņas kanāla. Tas ir sāpes un cieÅ”anas, ja fails ir liels un resursdators ir ielādēts. Bet Å”eit darbojas noteikums, ka pat 56,6 Kb / s ir labāks par 0 Kb / s. Programmā Hyper-V Å”o lietu sauc par PowerShell Direct. Bet tas bija tikai agrāk

vSpehere Web Services API Sākot no vSphere 6.0 (aptuveni, kopÅ” Ŕī API pirmo reizi tika ieviesta versijā 5.5), tas tiek izmantots darbam ar viesu maŔīnām un gandrÄ«z visur ir aizstājis VIX. Faktiski Ŕī ir vēl viena API vSphere pārvaldÄ«bai. Interesentiem iesaku studēt lieliski rokasgrāmata. 

VDDK (Virtuālā diska izstrādes komplekts). Bibliotēka, kas tika daļēji apspriesta Å”ajā raksts. Izmanto virtuālo disku lasÄ«Å”anai. Kādreiz tas bija daļa no VIX, bet laika gaitā tas tika pārvietots uz atseviŔķu produktu. Bet kā mantinieks tas izmanto tos paÅ”us kļūdu kodus kā VIX. Bet kaut kādu iemeslu dēļ paŔā SDK nav Å”o kļūdu apraksta. Tāpēc empÄ«riski tika noskaidrots, ka VDDK kļūdas ar citiem kodiem ir tikai tulkojums no binārā uz decimālo kodu. Tā sastāv no divām daļām ā€“ pirmajā pusē ir nedokumentēta informācija par kontekstu, bet otrā daļa ir tradicionālās VIX/VDDK kļūdas. Piemēram, ja mēs redzam:

VDDK error: 21036749815809.Unknown error

Pēc tam mēs drosmÄ«gi pārvērÅ”am to par hex un iegÅ«stam 132200000001. Mēs vienkārÅ”i atmetam neinformatÄ«vo 132200 sākumu, un pārējais bÅ«s mÅ«su kļūdas kods (VDDK 1: Nezināma kļūda). Par visbiežāk sastopamajām VDDK kļūdām nesen bija atseviŔķs raksts.

Tagad apskatīsim LOGI.

Å eit standartā ir atrodams viss, kas mums ir pats nepiecieÅ”amākais un svarÄ«gākais Event Viewer. Bet ir viens āķis: saskaņā ar senām tradÄ«cijām Windows nereÄ£istrē pilnu kļūdas tekstu, bet tikai tās numuru. Piemēram, kļūda 5 ir ā€œPiekļuve liegtaā€, un 1722 ir ā€œRPC serveris nav pieejamsā€, un 10060 ir ā€œSavienojuma taimautsā€. Protams, ir lieliski, ja atceries slavenākos, bet kā ar lÄ«dz Å”im neredzētajiem? 

Un, lai dzÄ«ve nemaz neŔķistu medus, kļūdas tiek saglabātas arÄ« heksadecimālā formā ar prefiksu 0x8007. Piemēram, 0x8007000e faktiski ir 14, TrÅ«kst atmiņas. Kāpēc un kam tas tika darÄ«ts, ir tumsā apvÄ«ts noslēpums. Tomēr pilnu kļūdu sarakstu var lejupielādēt bez maksas un bez SMS no decentrs.

Starp citu, dažreiz ir arÄ« citi prefiksi, ne tikai 0x8007. Šādā skumjā situācijā, lai saprastu HRESULT (ā€œrezultāta rokturiā€), ir jāiedziļinās vēl dziļāk. dokumentācija izstrādātājiem. Parastā dzÄ«vē es jums neiesaku to darÄ«t, bet, ja pēkŔņi piespiedāties pie sienas vai esat vienkārÅ”i ziņkārÄ«gs, tagad jÅ«s zināt, ko darÄ«t.

Bet Microsoft biedri par mums nedaudz apžēloja un parādÄ«ja pasaulei lietderÄ«bu ERR. Tas ir neliels konsoles laimes gabals, kas var pārvērst kļūdu kodus cilvēka valodā, neizmantojot Google. Tas darbojas Ŕādi.

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"

Rodas pamatots jautājums: kāpēc mēs uzreiz neierakstām atÅ”ifrÄ“Å”anu žurnālos, bet atstājam Å”os noslēpumainos kodus? Atbilde ir treÅ”o puÅ”u lietojumprogrammās. Pats izvelkot kādu WinAPI zvanu, nav grÅ«ti atÅ”ifrēt tā atbildi, jo Å”im nolÅ«kam ir pat Ä«paÅ”s WinAPI izsaukums. Bet, kā jau minēts, viss, kas mums nonāk tikai atbildēs, nonāk mÅ«su žurnālos. Un Å”eit, lai to atÅ”ifrētu, bÅ«tu pastāvÄ«gi jāuzrauga Ŕī apziņas straume, jāizvelk no tās gabali ar Windows kļūdām, jāatÅ”ifrē un jāielÄ«mē atpakaļ. BÅ«sim godÄ«gi, ne pati aizraujoŔākā nodarbe.

Windows failu pārvaldÄ«bas API izmanto visos iespējamos veidos, strādājot ar failiem. Failu izveide, dzÄ“Å”ana, atvērÅ”ana rakstÄ«Å”anai, darbs ar atribÅ«tiem un tā tālāk, un tā tālāk.

pieminēts virs PowerShell Direct kā VIX API analogs Hyper-V pasaulē. Diemžēl ne tik elastīgs: daudz funkcionalitātes ierobežojumu, tas nedarbojas ar katru resursdatora versiju un ne ar visiem viesiem.

RPC (Remote Procedure Call) Es nedomāju, ka ir neviena persona, kas bÅ«tu strādājusi ar WIndows un nebÅ«tu redzējusi ar RPC saistÄ«tas kļūdas. Neskatoties uz populāro nepareizo priekÅ”statu, Å”is nav viens protokols, bet jebkurÅ” klienta-servera protokols, kas atbilst vairākiem parametriem. Tomēr, ja mÅ«su žurnālos ir RPC kļūda, 90% gadÄ«jumu tā bÅ«s kļūda no Microsoft RPC, kas ir daļa no DCOM (Distributed Component Object Model). TÄ«klā var atrast milzÄ«gu daudzumu dokumentācijas par Å”o tēmu, taču lielākā daļa no tās ir diezgan novecojuÅ”as. Bet, ja ir akÅ«ta vēlme papētÄ«t tēmu, tad varu ieteikt rakstus Kas ir RPC?, Cik RPC darbojas un garÅ” saraksts RPC kļūdas.

Galvenie RPC kļūdu cēloņi mÅ«su žurnālos ir neveiksmÄ«gi mēģinājumi sazināties starp VBR komponentiem (piemēram, serveris > starpniekserveris) un visbiežāk sakaru problēmu dēļ.

Visām populārākajām vietām ir kļūda RPC serveris nav pieejams (1722). VienkārÅ”i sakot, klients nevarēja izveidot savienojumu ar serveri. Kā un kāpēc - nav vienas atbildes, bet parasti tā ir problēma ar autentifikāciju vai tÄ«kla piekļuvi 135. portam. Pēdējais ir raksturÄ«gs infrastruktÅ«rām ar dinamisku portu pieŔķirÅ”anu. Par Å”o tēmu ir pat atseviŔķa HF. Un Microsoft ir apjomÄ«gs ceļvedis lai atrastu neveiksmes cēloni.

Otrā populārākā kļūda: galapunktu kartētājs (1753) vairs nav pieejams galapunktam. RPC klientam vai serverim neizdevās pieŔķirt sev portu. Parasti notiek, kad serveris (mÅ«su gadÄ«jumā viesu maŔīna) ir konfigurēts, lai dinamiski pieŔķirtu portus no Å”aura diapazona, kas ir beidzies. Un, ja jÅ«s piesakāties no klienta puses (mÅ«su gadÄ«jumā VBR servera), tas nozÄ«mē, ka mÅ«su VeeamVssAgent vai nu nestartēja, vai arÄ« nebija reÄ£istrēts kā RPC saskarne. Ir arÄ« par Å”o tēmu atseviŔķa HF.

Lai pabeigtu 3 populārākās RPC kļūdas, atcerēsimies, ka RPC funkcijas izsaukums neizdevās (1726). Parādās, ja savienojums ir izveidots, bet RPC pieprasÄ«jumi netiek apstrādāti. Piemēram, mēs pieprasām informāciju par VSS statusu (pēkŔņi tieÅ”i Å”obrÄ«d tur top ēnu mÄ«na, un mēs cenÅ”amies kāpt), un atbildot uz mums, klusēt un ignorēt.

Windows Tape Backup API nepiecieÅ”ams darbam ar lentu bibliotēkām vai diskdziņiem. Kā jau minēju sākumā: mums nav nekāda prieka rakstÄ«t paÅ”iem savus draiverus un pēc tam ciest ar katras ierÄ«ces atbalstu. Tāpēc vim nav neviena sava draivera. Viss caur standarta API, kuras atbalstu ievieÅ” paÅ”i aparatÅ«ras pārdevēji. Tik daudz loÄ£iskāk, vai ne?

SMB / CIFS Aiz ieraduma visi raksta tos blakus, lai gan ne visi atceras, ka CIFS (Common Internet File System) ir tikai SMB (Server Message Block) privāta versija. Tātad Å”o jēdzienu vispārināŔanai nav nekā slikta. Samba jau ir LinuxUnix implementācija, un tai ir savas Ä«patnÄ«bas, bet es novirzos. Å eit ir svarÄ«gi: kad Veeam lÅ«dz kaut ko ierakstÄ«t UNC ceļā (servera direktorijā), serveris izmanto failu sistēmas draiveru hierarhiju, tostarp mup un mrxsmb, lai rakstÄ«tu uz bumbu. AttiecÄ«gi Å”ie draiveri radÄ«s arÄ« kļūdas.

Bez nevar Winsock API. Ja kaut kas ir jādara tīklā, VBR darbojas, izmantojot Windows Socket API, ko tautā sauc par Winsock. Tātad, ja žurnālā redzam virkni IP:Port, tas ir tas. Oficiālajā dokumentācijā ir labs iespējamo iespēju saraksts kļūdas.

pieminēts virs WMI (Windows Management Instrumentation) ir sava veida visvarens API, lai pārvaldītu visu un visus Windows pasaulē. Piemēram, strādājot ar Hyper-V, gandrīz visi resursdatoram adresētie pieprasījumi tiek cauri tam. Vārdu sakot, lieta ir absolūti neaizvietojama un savās spējās ļoti spēcīga. Mēģinot palīdzēt noskaidrot, kur un kas ir bojāts, iebūvētais WBEMtest.exe rīks ļoti palīdz.

Un pēdējā sarakstā, bet nebÅ«t ne mazāk svarÄ«gi - VSS (Volume Shadow Storage). Tēma ir tikpat neizsmeļama un noslēpumaina, cik daudz dokumentācijas par to ir uzrakstÄ«ts. Shadow Copy visvienkārŔāk tiek saprasts kā Ä«paÅ”s momentuzņēmuma veids, kas pēc bÅ«tÄ«bas arÄ« ir. Pateicoties viņam, jÅ«s varat izveidot lietojumprogrammām atbilstoÅ”us dublējumus VMware un gandrÄ«z visu Hyper-V. Esmu plānojis uztaisÄ«t atseviŔķu rakstu ar nelielu piespieÅ”anu VSS, bet pagaidām varat mēģināt palasÄ«t Å”is apraksts. VienkārÅ”i esiet uzmanÄ«gi, jo. mēģinājums zibenÄ«gi saprast VSS var izraisÄ«t smadzeņu traumu.

Par Å”o, iespējams, mēs varam apstāties. Uzdevumu izskaidrot elementārākās lietas uzskatu par pabeigtu, tāpēc nākamajā nodaļā jau apskatÄ«sim žurnālus. Bet, ja jums ir kādi jautājumi, droÅ”i uzdodiet tos komentāros.

Avots: www.habr.com

Pievieno komentāru