Vazhdojmë zhytjen tonë në botën e mahnitshme të trajtimi të problemeve përmes logëve. Në ne u dakorduam për kuptimin e termave bazë dhe shikuam me një sy strukturën e përgjithshme të Veeam, si një aplikacion të vetëm. Detyra për këtë — të kuptojmë si formohen skedarët e logëve, çfarë informacioni është paraqitur në to dhe pse ato duken siç duken.
Si mendoni, çfarë janë këto "logë"? Sipas shumicës, logët e çdo aplikacioni duhet të kenë rolin e një entiteti të gjithdijshëm, i cili shumicën e kohës qendron diku në cep, por në momentin e duhur shfaqet nga askund në armaturat shkëlqyese dhe na shpëton. Do të thotë, ato duhet të kenë gjithçka, duke filluar nga gabimet më të vogla në çdo komponent, deri te transaksionet e veçanta të bazës. Dhe që pas çdo gabimi të shkruhet menjëherë se si të rregullohet. Dhe gjithë kjo duhet të ngjitet në disa megabajt, jo më shumë. Kjo është vetëm tekst! Nuk mund të jenë skedarë tekstualë që zënë dhjetëra gigabajt, kam dëgjuar diku këtë!
Pra, logët
Në botën reale, logët janë thjesht një arkiv i informacionit diagnostik. Dhe se çfarë të ruajmë, prej nga të marrim informacionin për ruajtje dhe sa i detajuar duhet të jetë, është vendim i zhvilluesve. Disa e ndjekin rrugën e minimalizmit duke ruajtur regjistrime të nivelit ON/OFF, ndërsa disa grumbullojnë me përkushtim çdo informacion që mund të arrijnë. Megjithatë, ekziston gjithashtu një variant ndërmjetës me mundësinë e zgjedhjes së ashtuquajturit Logging Level, kur ju vetë përcaktoni sa të detajuar dëshironi të ruani dhe sa hapësirë keni të lirë në disk =) VBR ka gjashtë nivele të tillë, për ta thënë. Dhe besoni, nuk dëshironi të shihni se çfarë ndodh kur logoni me detaje maksimale me hapësirë të lirë në disk.
Mirë. Ne pothuajse e kuptuam se çfarë duam të ruajmë, por lind një pyetje legjitime: nga të merrni këtë informacion? Disa ngjarje për regjistrim, natyrisht, i formulojmë ne vetë me proceset tona të brendshme. Por çfarë të bëjmë kur ndodh ndërveprimi me ambientin e jashtëm? Për të mos rënë në një kaos të plotë me zgjidhje të improvizuara, Veeam ka tendencën të mos shpikë shpikjet që janë tashmë të shpikura. Gjithmonë, kur ka një API të gatshme, një funksion të integruar në sistem, një bibliotekë etj., ne do të japim përparësi mundësive të gatshme, para se të fillojmë të ndërtojmë zgjidhje të sofistikuara. Megjithatë, ka edhe mjaft prej tyre. Prandaj, gjatë analizës së logëve, është e rëndësishme të kuptohet se pjesa më e madhe e gabimeve vjen nga mesazhe nga API të jashtme, thirrje sistemore dhe biblioteka të tjera. Në këtë rast, roli i VBR reduktohet në forwardimin e këtyre gabimeve në skedarët e logëve ashtu si janë. Detyra kryesore e përdoruesit është të mësojë të kuptojë se cila rresht vjen nga kush, dhe për çfarë përgjigjet ky “këtu”. Prandaj, nëse kodi i gabimit nga logu VBR ju drejton në faqen e MSDN, kjo është e zakonshme dhe e saktë.
Si e lamë më parë: Veeam është një aplikacion që bazohet në SQL. Kështu që të gjitha cilësimet, të gjitha informacionet dhe gjithçka që është e nevojshme për funksionimin e tij normal, janë të ruajtura në bazën e të dhënave. Kjo sjell një të vërtetë të thjeshtë: ajo që nuk gjendet në lojëra, ka gjasa të jetë në bazë. Por as kjo nuk është një zgjidhje magjike: disa informacione nuk janë të pranishme as në logët lokale të komponentëve të Veeam, as në bazën e të dhënave. Prandaj, duhet të mësojmë të studiojmë logët e hostit, logët e makinës lokale dhe logët e gjithçkaje që merr pjesë në procesin e backup-it dhe restaurimit. Ndonjëherë ndodh që informacioni i nevojshëm të mos jetë askund. Kështu është rruga.
Disa shembuj të tillë të API-ve
Ky listë nuk ka si qëllim të jetë plotësisht përfundimtar, ndaj mos e kërkoni aty të vërtetën përfundimtare. Qëllimi i tij është vetëm të tregojë API-të dhe teknologjitë më të zakonshme të jashtme që përdoren në produktet tona.
Le të fillojmë me VMware.
I pari në listë është vSphere API. Përdoret për autentifikimin, leximin e hierarkisë, krijimin dhe fshirjen e snapshot-ëve, kërkimin e informacionit mbi makinat dhe shumë (shumë) gjëra të tjera. Funksionaliteti i zgjidhjes është shumë i gjerë, kështu që këshilloj VMware vSphere API Reference për versionin dhe . Për versionet më të fundit, gjithçka është e lehtë për të gjetur me Google.
VIX API. Magji e zezë e hipervizorit, për të cilën ka një listë të veçantë . VMware API për të punuar me skedarët në host pa u lidhur me ta në rrjet. Një opsion i fundit kur duhet të vendosni një skedar në një makinë, për të cilën nuk ka një kanale më të mirë komunikimi. Përdoret shpesh dhe mund të jetë e dhimbshme, sidomos nëse skedari është i madh dhe hosti është i ngarkuar. Megjithatë, rregulli është se madje 56.6 Kb/s është më mirë se 0 Kb/s. Në Hyper-V, një gjë e ngjashme quhet PowerShell Direct. Por kjo ka qenë vetëm deri sa u paraqit
vSphere Web Services API Që nga vSphere 6.0 (afërsisht, pasi ky API u prezantua për herë të parë në versionin 5.5) përdoret për të punuar me makinat gazmore dhe tashmë e ka zëvendësuar pothuajse kudo VIX. Në thelb, është një tjetër API për menaxhimin e vSphere. Ata që janë të interesuar mund të rekomandoj të studiojnë mënyrë të shkëlqyer.
VDDK (Virtual Disk Development Kit). Biblioteka, për të cilën është folur pjesërisht në këtë . Përdoret për leximin e disqeve virtuale. Disa kohë më parë ishte pjesë e VIX, por me kalimin e kohës u bë një produkt i veçantë. Si pasardhës, përdor të njëjtat kode gabimi si VIX. Megjithatë, për një arsye të panjohur, në vetë SDK nuk ka asnjë përshkrim të këtyre gabimeve. Prandaj, me anë të përvojës është zbuluar se gabimet VDDK me kode të tjera janë thjesht një translacion nga binar në kodin dekadash. Përbëhet nga dy pjesë – pjesa e parë përbën informacionin e pa dokumentuar rreth kontekstit, ndërsa pjesa e dytë – gabimet tradicionale VIX/VDDK. Për shembull, nëse shohim:
VDDK gabim: 21036749815809.Gabim i panjohur
Atëherë mund të konvertojmë këtë në hex dhe të marrim 132200000001. Fillimi jo informativ 132200 thjesht e injorojmë, ndërsa e mbetur do të jetë kodi ynë i gabimit (VDDK 1: Gabim i panjohur). Së fundmi, pati një artikull të veçantë për gabimet më të shpeshta VDDK .
Tani le të shohim Windows.
Këtu mund të gjejmë gjithçka të nevojshme dhe të rëndësishme për ne në standardin Event Viewer. Por ka një traditë të vjetër, Windows regjistron vetëm numrin e gabimit, jo tekstin e plotë. Për shembull, gabimi 5 është “Access denied”, gabimi 1722 është “The RPC server is unavailable”, dhe 10060 është “Connection timed out”. Sigurisht, është e madhe nëse i mban mend më të njohurit, por si të veprosh me ato të paimagjinueshme deri tani?
Për të mos e bërë jetën të duket shumë e lehtë, gabimet gjithashtu ruajnë formën e tyre hek dhe kanë prefiksin 0x8007. Për shembull, 0x8007000e është në të vërtetë 14, Out of Memory. Pse dhe për kë është bërë kështu — është një mister i mbuluar nga errësira. Megjithatë, mund të shkarkoni listën e plotë të gabimeve falas dhe pa SMS nga .
Ndërsa ndonjëherë, hasen dhe prefikse të tjera, jo vetëm 0x8007. Në një situatë kaq të trishtueshme për të kuptuar HRESULT (“handle rezultati”) duhet të futesh më thellë në për zhvilluesit. Në jetën e zakonshme nuk do t'jua rekomandoja këtë, por nëse ndiheni të shtypur ose thjesht jeni kuriozë, tani e dini se çfarë të bëni.
Por shokët në Microsoft na ndihmuan pak dhe gjetën për ne utilitarin . Ky është një copë e vogël kënaqësie për konsolën që mund të përkthejë kodet e gabimeve në një gjuhë njerëzore pa përdorur Google. Funksionon më pak si kjo.
C:UsersrootDesktop>err.exe 0x54f
# për hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Ndodhi një gabim i brendshëm.
# si një HRESULT: Severiteti: SUKSES (0), FACILITETI_NULL (0x0), Kodi 0x54f
# për hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Ndodhi një gabim i brendshëm.
# 2 ndeshje të gjetura për "0x54f"Rikthehet një pyetje e legjitimuar: pse ne nuk shkruajmë menjëherë në logët një shpjegim, por i lëmë këto kode misterioze? Përgjigja është në aplikacionet e treta. Kur ti vetë thërret një funksion të WinAPI, atëherë të dekriptojë përgjigjen nuk është e vështirë, sepse për këtë ka edhe një thirrje specifike të WinAPI. Por siç u tha tashmë, në logët tona përfshihet gjithçka që na vjen në përgjigje. Dhe këtu do të duhej të monitoronim vazhdimisht këtë rrjedhë mendimesh, të nxirrnim copëza me gabime të Windows, t'i dekriptojmë ato dhe t'i vendosnim përsëri. Të themi të drejtat, nuk është një aktivitet shumë argëtues.
Windows File Management API kjo përdoret në mënyrë të gjithanshme gjatë punës me skedarë. Krijimi i skedarëve, fshirja, hapja për të shkruar, puna me atribuete dhe shumë të tjera.
I përmendur më sipër PowerShell Direct si një analog i VIX API në botën e Hyper-V. Fatkeqësisht, nuk është aq fleksibël: ka shumë kufizime në funksionalitet, nuk punon me çdo version të hostit dhe jo me të gjithë mysafirët.
RPC (Remote Procedure Call) Mendoj se nuk ka asnjë njeri që ka punuar me Windows dhe nuk ka parë gabimet lidhur me RPC. Pavarësisht nga mitet popullore, kjo nuk është ndonjë protokoll i vetëm, por çdo protokoll klient-server që përmbush një numër parametrash. Megjithatë, nëse në log-et tona ka një gabim RPC, në 90% të rasteve do të jetë një gabim nga Microsoft RPC, i cili është pjesë e DCOM (Distributed Component Object Model). Në rrjet mund të gjeni një sasi të madhe dokumentacioni mbi këtë temë, megjithatë një pjesë e madhe e saj është mjaft e vjetruar. Por nëse ka një dëshirë të madhe për të studiuar temën, mund të rekomandoj artikujt , dhe një listë të gjatë .
Arsyet kryesore për shfaqjen e gabimeve RPC në log-et tona janë përpjekjet e paefektshme për të ndikuar midis komponentëve VBR (server > proxy, për shembull) dhe më shpesh për shkak të problemeve me komunikimin.
Gabimi më i njohur ndër të gjitha gabimet është gabimi The RPC server is unavailable (1722). Në terma të thjeshtë, klienti nuk arriti të krijojë lidhjen me serverin. Nuk ka një përgjigje të vetme për arsyen e këtij problemi, por zakonisht është një çështje e autentikimit ose e aksesit në rrjet deri në portin 135. Kjo është tipike për infrastrukturat me caktim dinamik të porteve. Ka edhe . Microsoft ka gjithashtu për të gjetur arsyet e prishjeve.
Gabimi i dytë më i njohur: There are no more endpoints available from the endpoint mapper (1753). Klienti ose serveri RPC nuk arritën të caktuan një port për veten e tyre. Zakonisht ndodh kur serveri (në këtë rast, makina jpg) është konfiguruar për caktim dinamik të porteve nga një gamë e ngushtë që është shteruar. Dhe nëse shohim nga anë e klientit (në këtë rast serveri VBR), do të thotë se VeeamVssAgent ynë nuk u aktivizua ose nuk u regjistrua si një ndërfaqe RPC. Po ashtu, ka informacion lidhur me këtë temë. .
Dhe të përfundojmë Top-3 gabimet e RPC, le të kujtojmë "RPC function call failed (1726)". Ky gabim shfaqet nëse lidhja është vendosur, por kërkesat RPC nuk funksionojnë. Për shembull, ne kërkojmë informacion në lidhje me statusin VSS (ndoshta po bëhet një kopje e mbetjeve dhe ne po përpiqemi të lidhim), dhe përgjigja që marrim është heshtje dhe injorim.
Windows Tape Backup API nevojitet për të punuar me biblioteka ose disk dragë. Siç përmenda në fillim: të shkruajmë drejtuesit tanë dhe të vuajmë më pas me mbështetje për çdo pajisje nuk është aspak kënaqësi për ne. Prandaj, në Vima nuk ka asnjë drejtues të tij. Të gjitha përmes API-së standarde, mbështetje për të cilën e zbatojnë vetë prodhuesit e harduerit. Kështu është shumë më logjike, apo jo?
SMB/CIFS Të gjithë shkruajnë zakonisht afër, megjithatë nuk është e lehtë për të gjithë të kujtojnë që CIFS (Sistemi i Skedarëve të Internetit të zakonshëm) është thjesht një version privat i SMB (Blloku i Mesazheve të Serverit). Pra, nuk ka ndonjë gjë të keqe në përgjithësimin e këtyre koncepteve. Samba është implementimi për Linux/Unix, dhe aty ka karakteristika të veta, por më shpëtoi pak nga tema. E rëndësishme këtu është: kur Veeam kërkon të shkruajë diçka përmes rrugës UNC (serverdirectory), serveri përdor hierarkinë e shoferëve të sistemit të skedarëve, duke përfshirë mup dhe mrxsmb, për të shkruar në ndarjen. Për pasojë, gabimet do të gjenerohen gjithashtu nga këta shoferë.
Nuk mund të bëhet pa Winsock API. Nëse duhet të bëhet diçka përmes rrjetit, VBR punon përmes Windows Socket API, i njohur në popull si Winsock. Pra, nëse shohim në logun një lidhje IP:Port, është ai. Në dokumentacionin zyrtar ka një listë të mirë të mundësive .
I përmendur më sipër WMI (Windows Management Instrumentation) — është një API që menaxhon gjithçka në botën e Windows. Për shembull, kur punojmë me Hyper-V, pothuajse të gjitha kërkesat ndaj hostit ndodhin pikërisht përmes tij. Në një fjalë, është diçka krejtësisht e pazëvendësueshme dhe shumë e fuqishme në mundësitë e saj. Në përpjekjet për të ndihmuar të kuptohet ku dhe çfarë është prishur, ndihmon shumë mjeti i integruar WBEMtest.exe.
Dhe fundit në listë, por jo më pak i rëndësishëm — VSS (Volume Shadow Storage). Tema është aq e pasur dhe enigmatike sa tërë dokumentacioni që është shkruar për të. Shadow Copy është më e lehtë për t'u kuptuar si një lloj i veçantë snapshot-i, i cili në thelb është pikërisht kjo. Falë tij, në VMware mund të bëni backup të aplikacioneve konsistente, kurse në Hyper-V pothuajse gjithçka. Kam në plan të shkruaj një artikull të veçantë me një përmbledhje mbi VSS, por për momentin mund të provoni të lexoni . Vetëm me kujdes, pasi përpjekja për të kuptuar VSS papritur mund të çojë në dëmtime të trurit.
Dhe me këtë, ndoshta mund të ndalemi. E konsideroj të përfunduar detyrën për të shpjeguar gjërat më themelore, prandaj në kapitullin e ardhshëm do të shohim logët. Por nëse keni pyetje, mos ngurroni t'i shprehni ato në komentet.
Burimi: habr.com
