Ne vazhdojmë zhytjen tonë në botën magjepsëse të supozimeve ... zgjidhjen e problemeve me shkrime. NË ne ramë dakord për kuptimin e termave bazë dhe shikuam strukturën e përgjithshme të Veeam si një aplikacion i vetëm me një sy. Detyra për këtë është të kuptojë se si formohen skedarët e regjistrave, çfarë lloj informacioni shfaqet në to dhe pse duken ashtu siç duken.
Çfarë mendoni se janë këto "loge"? Sipas shumicës, regjistrave të çdo aplikacioni duhet t'i caktohet roli i një lloj entiteti të gjithëfuqishëm që në shumicën e rasteve vegjeton diku në oborrin e shtëpisë, por në momentin e duhur shfaqet nga hiçi në forca të blinduara të shndritshme dhe i shpëton të gjithë. Kjo do të thotë, ato duhet të përmbajnë gjithçka, nga gabimet më të vogla në secilin komponent deri tek transaksionet individuale të bazës së të dhënave. Dhe kështu që pas gabimit u shkrua menjëherë se si ta rregullojmë atë. Dhe e gjithë kjo duhet të përshtatet në disa megabajt, jo më shumë. Është thjesht tekst! Skedarët e tekstit nuk mund të marrin dhjetëra gigabajt, e kam dëgjuar diku!
Pra shkrimet
Në botën reale, regjistrat janë vetëm një arkiv informacioni diagnostikues. Dhe çfarë të ruhet atje, ku të merret informacioni për ruajtje dhe sa duhet të jetë i detajuar, varet nga vetë zhvilluesit që të vendosin. Dikush ndjek rrugën e minimalizmit duke mbajtur shënime të nivelit ON / OFF, dhe dikush me zell mbledh gjithçka që mund të arrijë. Megjithëse ekziston edhe një opsion i ndërmjetëm me aftësinë për të zgjedhur të ashtuquajturin Niveli i Regjistrimit, kur ju vetë tregoni se sa informacione të detajuara dëshironi të ruani dhe sa hapësirë shtesë në disk keni =) VBR ka gjashtë nivele të tilla, meqë ra fjala. Dhe, më besoni, nuk dëshironi të shihni se çfarë ndodh me regjistrimin më të detajuar me hapësirë të lirë në diskun tuaj.
Mirë. Ne e kuptuam përafërsisht se çfarë duam të kursejmë, por lind një pyetje legjitime: nga ta marrim këtë informacion? Sigurisht, ne jemi pjesë e ngjarjeve për regjistrimin e vetvetes nga proceset tona të brendshme. Por çfarë duhet bërë kur ka një ndërveprim me mjedisin e jashtëm? Për të mos rrëshqitur në një ferr me paterica dhe biçikleta, Veeam tenton të mos shpikë shpikje që tashmë janë shpikur. Sa herë që ka një API të gatshme, funksion të integruar, bibliotekë, etj., ne do t'u japim përparësi opsioneve të gatshme përpara se të fillojmë të rrethojmë kontraceptivët tanë. Edhe pse mjafton edhe kjo e fundit. Prandaj, kur analizoni regjistrat, është e rëndësishme të kuptoni se pjesa më e madhe e gabimeve bie mbi mesazhet nga API-të e palëve të treta, thirrjet e sistemit dhe bibliotekat e tjera. Në këtë rast, roli i VBR zbret në përcjelljen e këtyre gabimeve në skedarët e regjistrit siç janë. Dhe detyra kryesore e përdoruesit është të mësojë të kuptojë se cila linjë është nga kush, dhe për çfarë është përgjegjës ky "kush". Pra, nëse një kod gabimi nga regjistri VBR ju çon në një faqe MSDN, kjo është mirë dhe e saktë.
Siç u pajtuam më herët: Veeam është një aplikacion i ashtuquajtur i bazuar në SQL. Kjo do të thotë që të gjitha cilësimet, të gjitha informacionet dhe në përgjithësi gjithçka që është e nevojshme vetëm për funksionimin normal - gjithçka ruhet në bazën e të dhënave të saj. Prandaj e vërteta e thjeshtë: ajo që nuk është në regjistrat ka shumë të ngjarë në bazën e të dhënave. Por kjo nuk është as një plumb argjendi: disa gjëra nuk janë në regjistrat lokalë të komponentëve të Veeam, as në bazën e të dhënave të tij. Prandaj, duhet të mësoni se si të studioni regjistrat e hostit, regjistrat e makinës lokale dhe regjistrat e gjithçkaje që është e përfshirë në procesin e kopjimit dhe rivendosjes. Dhe gjithashtu ndodh që informacioni i nevojshëm nuk është fare i disponueshëm askund. E tillë është rruga.
Disa shembuj të API-ve të tilla
Kjo listë nuk synon të jetë jashtëzakonisht e plotë, kështu që nuk ka nevojë të kërkoni të vërtetën përfundimtare në të. Qëllimi i tij është vetëm të tregojë API-të dhe teknologjitë më të zakonshme të palëve të treta të përdorura në produktet tona.
Le të fillojmë me VMware.
I pari në listë do të jetë vSphere API. Përdoret për vërtetim, leximin e hierarkisë, krijimin dhe fshirjen e fotografive, kërkimin e informacionit rreth makinerive dhe shumë (shumë) të tjera. Funksionaliteti i zgjidhjes është shumë i gjerë, kështu që unë mund të rekomandoj Referencën VMware vSphere API për versionin и . Për më shumë versione aktuale, gjithçka thjesht kërkohet në google.
VIX API. Magjia e zezë e hipervizorit, për të cilën ka një të veçantë . VMware API për të punuar me skedarë në host pa u lidhur me to përmes rrjetit. Një variant i mjetit të fundit kur duhet të vendosni një skedar në një makinë në të cilën nuk ka kanal më të mirë komunikimi. Është dhimbje dhe vuajtje nëse skedari është i madh dhe hosti është i ngarkuar. Por këtu funksionon rregulli që edhe 56,6 Kb/s është më mirë se 0 Kb/s. Në Hyper-V, kjo gjë quhet PowerShell Direct. Por kjo ishte vetëm më parë
vSpehere Web Services API Duke filluar nga vSphere 6.0 (përafërsisht, që kur kjo API u prezantua për herë të parë në versionin 5.5) përdoret për të punuar me makinat e ftuar dhe ka zëvendësuar VIX pothuajse kudo. Në fakt, ky është një tjetër API për menaxhimin e vSphere. Për ata që janë të interesuar, ju rekomandoj të studiojnë manual.
VDDK (Kit për zhvillimin e diskut virtual). Biblioteka, e cila u diskutua pjesërisht në këtë . Përdoret për të lexuar disqe virtuale. Njëherë e një kohë ishte pjesë e VIX, por me kalimin e kohës u zhvendos në një produkt të veçantë. Por si trashëgimtar, ai përdor të njëjtat kode gabimi si VIX. Por për disa arsye, nuk ka asnjë përshkrim të këtyre gabimeve në vetë SDK. Prandaj, u zbulua në mënyrë empirike se gabimet VDDK me kode të tjera janë vetëm një përkthim nga kodi binar në atë dhjetor. Ai përbëhet nga dy pjesë - gjysma e parë është informacion i padokumentuar në lidhje me kontekstin, dhe pjesa e dytë janë gabimet tradicionale VIX / VDDK. Për shembull, nëse shohim:
VDDK error: 21036749815809.Unknown error
Më pas e kthejmë me guxim këtë në heks dhe marrim 132200000001. Thjesht hedhim poshtë fillimin joinformativ të 132200, dhe pjesa tjetër do të jetë kodi ynë i gabimit (VDDK 1: Gabim i panjohur). Në lidhje me gabimet më të shpeshta të VDDK, kohët e fundit ka pasur një të veçantë .
Tani le të shikojmë Dritaret.
Këtu, gjithçka që është më e nevojshme dhe më e rëndësishme për ne mund të gjendet në standard Event Viewer. Por ka një kapje: sipas një tradite të gjatë, Windows nuk regjistron tekstin e plotë të gabimit, por vetëm numrin e tij. Për shembull, gabimi 5 është "Qasja u refuzua", dhe 1722 është "Serveri RPC është i padisponueshëm" dhe 10060 është "Koha e lidhjes mbaroi". Sigurisht, është mirë nëse mbani mend më të famshmit, por ç'të themi për ato që nuk janë parë deri tani?
Dhe në mënyrë që jeta të mos duket fare si mjaltë, gabimet ruhen edhe në formë heksadecimal, me parashtesën 0x8007. Për shembull, 0x8007000e është në të vërtetë 14, pa memorie. Pse dhe për kë u bë kjo është një mister i mbështjellë në errësirë. Sidoqoftë, një listë e plotë e gabimeve mund të shkarkohet falas dhe pa SMS nga .
Nga rruga, ndonjëherë ka prefikse të tjera, jo vetëm 0x8007. Në një situatë kaq të trishtueshme, për të kuptuar HRESULT ("trajtimi i rezultatit"), duhet të thellohesh edhe më thellë në për zhvilluesit. Në jetën e zakonshme, unë nuk ju këshilloj ta bëni këtë, por nëse papritmas shtypni murin ose jeni thjesht kurioz, tani e dini se çfarë të bëni.
Por shokët e Microsoft-it na mëshirën pak dhe i treguan botës një dobi . Kjo është një pjesë e vogël e lumturisë së konsolës që mund të përkthejë kodet e gabimit në njerëz pa përdorur Google. Punon kështu.
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"Shtrohet një pyetje legjitime: pse nuk e shkruajmë menjëherë deshifrimin në regjistrat, por i lëmë këto kode misterioze? Përgjigja është në aplikacionet e palëve të treta. Kur tërhiqni vetë disa thirrje WinAPI, nuk është e vështirë të deshifroni përgjigjen e saj, sepse ekziston edhe një thirrje speciale WinAPI për këtë. Por siç u përmend tashmë, gjithçka që na vjen vetëm në përgjigje futet në regjistrat tanë. Dhe këtu, për ta deshifruar atë, do të duhej të monitorohej vazhdimisht kjo rrjedhë e vetëdijes, të nxirrte prej saj copa me gabime të Windows, t'i deshifrojë dhe t'i ngjisë përsëri. Le të jemi të sinqertë, jo aktiviteti më emocionues.
API për menaxhimin e skedarëve të Windows përdoret në çdo mënyrë të mundshme gjatë punës me skedarë. Krijimi i skedarëve, fshirja, hapja për shkrim, puna me atributet, e kështu me radhë e kështu me radhë.
të përmendura më lart PowerShell Direct si një analog i VIX API në botën Hyper-V. Fatkeqësisht, jo aq fleksibël: shumë kufizime në funksionalitet, nuk funksionon me çdo version të hostit dhe jo me të gjithë mysafirët.
RPC (Thirrja e procedurës në distancë) Unë nuk mendoj se ka asnjë person të vetëm që ka punuar me Windows që nuk ka parë gabime të lidhura me RPC. Pavarësisht nga keqkuptimi popullor, ky nuk është një protokoll i vetëm, por çdo protokoll klient-server që plotëson një sërë parametrash. Megjithatë, nëse ka një gabim RPC në regjistrat tanë, 90% të rasteve do të jetë një gabim nga Microsoft RPC, i cili është pjesë e DCOM (Distributed Component Object Model). Ju mund të gjeni një sasi të madhe dokumentacioni për këtë temë në rrjet, por pjesa më e madhe e tij është mjaft e vjetëruar. Por nëse ka një dëshirë akute për të studiuar temën, atëherë unë mund të rekomandoj artikuj , dhe listë të gjatë .
Shkaqet kryesore të gabimeve RPC në regjistrat tanë janë përpjekjet e dështuara për të komunikuar ndërmjet komponentëve VBR (server > proxy, për shembull) dhe më shpesh për shkak të problemeve të komunikimit.
Pjesa e sipërme midis të gjitha majave është gabimi Serveri RPC është i padisponueshëm (1722). Me fjalë të thjeshta, klienti nuk mund të krijonte një lidhje me serverin. Si dhe pse - nuk ka asnjë përgjigje të vetme, por zakonisht është një problem me autentifikimin ose me aksesin në rrjet në portin 135. Kjo e fundit është tipike për infrastrukturat me caktimin dinamik të portit. Në këtë temë, ka edhe . Dhe Microsoft ka për të gjetur shkakun e dështimit.
Gabimi i dytë më i popullarizuar: Nuk ka më pika fundore të disponueshme nga hartuesi i pikës fundore (1753). Klienti ose serveri RPC dështoi t'i caktonte vetes një port. Zakonisht ndodh kur serveri (në rastin tonë, makina e ftuar) është konfiguruar që të ndajë në mënyrë dinamike portet nga një gamë e ngushtë që ka përfunduar. Dhe nëse identifikoheni nga ana e klientit (në rastin tonë, serveri VBR), kjo do të thotë që VeeamVssAgent ynë ose nuk filloi ose nuk ishte regjistruar si një ndërfaqe RPC. Ka edhe për këtë temë .
Epo, për të plotësuar 3 gabimet kryesore të RPC, le të kujtojmë se thirrja e funksionit RPC dështoi (1726). Shfaqet nëse lidhja është krijuar, por kërkesat RPC nuk përpunohen. Për shembull, ne kërkojmë informacion për statusin e VSS (papritmas tani po bëhet një minierë në hije atje dhe ne po përpiqemi të ngjitemi), dhe si përgjigje ndaj nesh, heshtni dhe injoroni.
Windows Tape Backup API nevojiten për të punuar me bibliotekat e shiritave ose disqet. Siç e përmenda në fillim: ne nuk kemi kënaqësi të shkruajmë drejtuesit tanë dhe më pas të vuajmë me mbështetjen e secilës pajisje. Prandaj, vim nuk ka asnjë drejtues të vetin. Gjithçka përmes një API standarde, mbështetja e së cilës zbatohet nga vetë shitësit e harduerit. Shumë më logjike, apo jo?
SMB / CIFS Nga zakoni, të gjithë i shkruajnë ato krah për krah, megjithëse jo të gjithë e mbajnë mend që CIFS (Sistemi i Skedarëve të Përbashkët të Internetit) është vetëm një version privat i SMB (Blloku i mesazheve të serverit). Pra, nuk ka asgjë të keqe në përgjithësimin e këtyre koncepteve. Samba është tashmë një implementim LinuxUnix, dhe ka veçoritë e veta, por unë devijoj. Çfarë është e rëndësishme këtu: kur Veeam kërkon të shkruajë diçka në shtegun UNC (drejtoria e serverit), serveri përdor hierarkinë e drejtuesve të sistemit të skedarëve, duke përfshirë mup dhe mrxsmb, për të shkruar në top. Prandaj, këta drejtues do të gjenerojnë gjithashtu gabime.
Nuk mund të bëjë pa Winsock API. Nëse diçka duhet të bëhet përmes rrjetit, VBR funksionon përmes API-së së Windows Socket, e njohur gjerësisht si Winsock. Pra, nëse shohim një grup IP:Port në regjistër, kjo është ajo. Dokumentacioni zyrtar ka një listë të mirë të mundshme .
të përmendura më lart WMI (Windows Management Instrumentation) është një lloj API i plotfuqishëm për menaxhimin e gjithçkaje dhe të gjithëve në botën e Windows. Për shembull, kur punoni me Hyper-V, pothuajse të gjitha kërkesat për hostin kalojnë përmes tij. Me një fjalë, gjëja është absolutisht e pazëvendësueshme dhe shumë e fuqishme në aftësitë e saj. Në një përpjekje për të ndihmuar të zbuloni se ku dhe çfarë është prishur, mjeti i integruar WBEMtest.exe ndihmon shumë.
Dhe e fundit në listë, por aspak më e rëndësishmja - VSS (Vëllimi Shadow Storage). Tema është aq e pashtershme dhe misterioze aq sa është shkruar shumë dokumentacion për të. Kopja e hijes kuptohet më thjesht si një lloj i veçantë fotografish, që në thelb është. Falë tij, ju mund të bëni kopje rezervë në përputhje me aplikacionin në VMware dhe pothuajse gjithçka në Hyper-V. Unë kam plane për të bërë një artikull të veçantë me pak shtrëngim në VSS, por tani për tani mund të përpiqeni të lexoni . Vetëm kini kujdes, sepse. Përpjekja për të kuptuar VSS menjëherë mund të çojë në dëmtim të trurit.
Mbi këtë, ndoshta, mund të ndalemi. Unë e konsideroj detyrën e shpjegimit të gjërave më themelore të përfunduara, kështu që në kapitullin tjetër do të shikojmë tashmë regjistrat. Por nëse keni ndonjë pyetje, mos ngurroni t'i pyesni ato në komente.
Burimi: www.habr.com