Ni daŭrigas nian mergon en la fascinan mondon de divenado ... problemojn per ŝtipoj. EN ni konsentis pri la signifo de la bazaj terminoj kaj rigardis la ĝeneralan strukturon de Veeam kiel ununuran aplikon per unu okulo. La tasko por ĉi tiu estas eltrovi kiel protokolaj dosieroj estas formitaj, kiaj informoj estas montritaj en ili kaj kial ili aspektas kiel ili aspektas.
Kio laŭ vi estas ĉi tiuj "ŝtipoj"? Laŭ plej multaj, la protokoloj de iu ajn aplikaĵo devus esti asignitaj la rolon de speco de ĉiopova ento, kiu plejofte vegetas ie en la korto, sed en la ĝusta momento aperas de nenie en brila kiraso kaj savas ĉiujn. Tio estas, ili devus enhavi ĉion, de la plej etaj eraroj en ĉiu komponanto ĝis individuaj datumbazaj transakcioj. Kaj por ke post la eraro oni tuj skribis kiel alie ripari ĝin. Kaj ĉio ĉi devus konveni en kelkaj megabajtoj, ne pli. Ĝi estas nur teksto! Tekstaj dosieroj ne povas preni dekojn da gigabajtoj, mi aŭdis ĝin ie!
Do la ŝtipoj
En la reala mondo, protokoloj estas nur arkivo de diagnozaj informoj. Kaj kion stoki tie, kie akiri informojn por stokado kaj kiom detala ĝi estu, dependas de la programistoj mem decidi. Iu sekvas la vojon de minimumismo konservante rekordojn de la ON / OFF nivelo, kaj iu diligente rastas ĉion, kion ili povas atingi. Kvankam ekzistas ankaŭ meza opcio kun la kapablo elekti la tiel nomatan Logging Nivelo, kiam vi mem indikas kiom detalajn informojn vi volas konservi kaj kiom da kroma diskospaco vi havas =) VBR havas ses tiajn nivelojn, cetere. Kaj, kredu min, vi ne volas vidi, kio okazas kun la plej detala registrado kun libera spaco sur via disko.
Bone. Ni proksimume komprenis, kion ni volas ŝpari, sed legitima demando ekestas: de kie akiri ĉi tiun informon? Kompreneble, ni formas parton de la eventoj por registri nin mem per niaj internaj procezoj. Sed kion fari kiam estas interago kun la ekstera medio? Por ne gliti en inferon de lambastonoj kaj bicikloj, Veeam emas ne inventi inventojn kiuj jam estis inventitaj. Kiam ajn ekzistas preta API, enkonstruita funkcio, biblioteko, ktp., ni donos preferon al pretaj opcioj antaŭ ol komenci bari niajn ilojn. Kvankam la lasta ankaŭ sufiĉas. Tial, kiam oni analizas protokolojn, estas grave kompreni, ke la plej granda parto de eraroj falas sur mesaĝoj de triaj API-oj, sistemvokoj kaj aliaj bibliotekoj. En ĉi tiu kazo, la rolo de VBR konsistas en plusendi ĉi tiujn erarojn al la protokolaj dosieroj. Kaj la ĉefa tasko de la uzanto estas lerni kompreni, kiu linio estas de kiu, kaj pri kio ĉi tiu "kiu" respondecas. Do se erarkodo de la VBR-protokolo kondukas vin al MSDN-paĝo, tio estas bona kaj ĝusta.
Kiel ni konsentis pli frue: Veeam estas tiel nomata SQL-bazita aplikaĵo. Ĉi tio signifas, ke ĉiuj agordoj, ĉiuj informoj kaj ĝenerale ĉio, kio estas nur necesa por normala funkciado - ĉio estas konservita en sia datumbazo. Tial la simpla vero: kio ne estas en la protokoloj estas plej verŝajne en la datumbazo. Sed ĉi tio ankaŭ ne estas arĝenta kuglo: iuj aferoj ne estas en la lokaj protokoloj de Veeam-komponentoj, nek en ĝia datumbazo. Tial vi devas lerni kiel studi la gastigajn protokolojn, la protokolojn de la loka maŝino kaj la protokolojn de ĉio, kio estas implikita en la sekurkopio kaj restarigo. Kaj ankaŭ okazas, ke la necesaj informoj tute ne haveblas ie ajn. Tio estas la vojo.
Kelkaj ekzemploj de tiaj APIoj
Ĉi tiu listo ne celas esti escepte kompleta, do ne necesas serĉi la finfinan veron en ĝi. Ĝia celo estas nur montri la plej oftajn triajn API-ojn kaj teknologiojn uzatajn en niaj produktoj.
Ni komencu per VMware.
La unua en la listo estos vSphere API. Uzita por aŭtentigo, legi la hierarkion, krei kaj forigi momentfotojn, peti informojn pri maŝinoj, kaj multe (tre) pli. La funkcieco de la solvo estas tre larĝa, do mi povas rekomendi la VMware vSphere API Referencon por la versio и . Por pli aktualaj versioj, ĉio estas nur guglata.
VIX API. La nigra magio de la hiperviziero, por kiu ekzistas aparta . VMware API por labori kun dosieroj sur la gastiganto sen konekti al ili tra la reto. Lasta rimeda elekto kiam vi bezonas meti dosieron en maŝino al kiu ne ekzistas pli bona komunika kanalo. Estas doloro kaj sufero se la dosiero estas granda kaj la gastiganto estas ŝarĝita. Sed ĉi tie funkcias la regulo, ke eĉ 56,6 Kb/s estas pli bona ol 0 Kb/s. En Hyper-V, ĉi tiu afero nomiĝas PowerShell Direct. Sed tio estis nur antaŭe
vSpehere Web Services API Komencante de vSphere 6.0 (proksimume, ĉar ĉi tiu API unue estis lanĉita en versio 5.5) ĝi estas uzata por labori kun gastmaŝinoj kaj anstataŭis VIX preskaŭ ĉie. Fakte, ĉi tio estas alia API por administri vSphere. Por tiuj, kiuj interesiĝas, mi rekomendas studi manlibro.
VDDK (Virtuala Diska Disvolva Ilaro). La biblioteko, kiu estis parte diskutita en ĉi tio . Uzita por legi virtualajn diskojn. Iam ĝi estis parto de la VIX, sed kun la tempo ĝi estis movita en apartan produkton. Sed kiel heredanto, ĝi uzas la samajn erarkodojn kiel VIX. Sed ial ne estas priskribo de ĉi tiuj eraroj en la SDK mem. Tial oni eksciis empirie, ke VDDK-eraroj kun aliaj kodoj estas nur traduko de duuma al dekuma kodo. Ĝi konsistas el du partoj - la unua duono estas nedokumentitaj informoj pri la kunteksto, kaj la dua parto estas la tradiciaj VIX / VDDK-eraroj. Ekzemple, se ni vidas:
VDDK error: 21036749815809.Unknown error
Tiam ni kuraĝe konvertas ĉi tion al dekseso kaj ricevas 132200000001. Ni simple forĵetas la neinforman komencon de 132200, kaj la resto estos nia erarkodo (VDDK 1: Nekonata eraro). Pri la plej oftaj VDDK-eraroj, estis ĵus aparta .
Nun ni rigardu Fenestroj.
Ĉi tie, ĉio, kio estas plej necesa kaj grava por ni, troviĝas en la normo Eventa Vizitanto. Sed estas unu kapto: laŭ longa tradicio, Vindozo ne registras la plenan tekston de la eraro, sed nur ĝian numeron. Ekzemple, eraro 5 estas "Aliro malakceptita", kaj 1722 estas "La RPC-servilo estas nedisponebla", kaj 10060 estas "Konekto elĉerpita". Kompreneble estas bonege, se oni memoras la plej famajn, sed kio pri la ĝis nun neviditaj?
Kaj por ke la vivo tute ne ŝajnu mielo, eraroj ankaŭ konserviĝas en deksesuma formo, kun la prefikso 0x8007. Ekzemple, 0x8007000e estas fakte 14, El Memoro. Kial kaj por kiu tio estis farita estas mistero envolvita en mallumo. Tamen, kompleta listo de eraroj povas esti elŝutita senpage kaj sen SMS de .
Cetere, foje ekzistas aliaj prefiksoj, ne nur 0x8007. En tia malĝoja situacio, por kompreni HRESULT ("rezulta tenilo"), vi bezonas eĉ pli profundiĝi en por programistoj. En la ordinara vivo, mi ne konsilas al vi fari ĉi tion, sed se vi subite premis la muron aŭ estas nur scivolema, nun vi scias kion fari.
Sed la kamaradoj ĉe Microsoft iomete kompatis nin kaj montris al la mondo utilon . Ĉi tio estas malgranda peco de konzola feliĉo, kiu povas traduki erarkodojn en homan sen uzi Guglon. Ĝi funkcias tiel.
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"Leĝa demando ŝprucas: kial ni ne tuj skribas la deĉifradon al la protokoloj, sed lasas ĉi tiujn misterajn kodojn? La respondo estas en triaj aplikoj. Kiam vi tiras iun WinAPI-vokon mem, ne estas malfacile deĉifri ĝian respondon, ĉar ekzistas eĉ speciala WinAPI-voko por tio. Sed kiel jam menciite, ĉio, kio venas al ni nur en respondoj, eniras en niajn protokolojn. Kaj ĉi tie, por deĉifri ĝin, oni devus konstante monitori ĉi tiun fluon de konscio, eltiri el ĝi pecojn kun Vindozaj eraroj, deĉifri ilin kaj alglui ilin reen. Ni estu honestaj, ne la plej ekscita agado.
Windows File Management API uzata en ĉiuj eblaj manieroj kiam oni laboras kun dosieroj. Krei dosierojn, forigi, malfermi por skribi, labori kun atributoj, ktp kaj tiel plu.
supre menciitaj PowerShell Rekta kiel analogo de la VIX API en la Hyper-V-mondo. Bedaŭrinde, ne tiom fleksebla: multaj limigoj pri funkcieco, ĝi ne funkcias kun ĉiu versio de la gastiganto kaj ne kun ĉiuj gastoj.
CPR (Fora Procedura Voko) Mi ne pensas, ke estas unu homo, kiu laboris kun WINdows, kiu ne vidis RPC-rilatajn erarojn. Malgraŭ la populara miskompreno, ĉi tio ne estas ununura protokolo, sed iu ajn klient-servila protokolo, kiu kontentigas kelkajn parametrojn. Tamen, se estas RPC-eraro en niaj protokoloj, 90% de la tempo ĝi estos eraro de Microsoft RPC, kiu estas parto de DCOM (Distributed Component Object Model). Vi povas trovi grandegan kvanton da dokumentado pri ĉi tiu temo en la reto, sed la plej granda parto de ĝi estas sufiĉe malmoderna. Sed se estas akra deziro studi la temon, tiam mi povas rekomendi artikolojn , kaj longa listo .
La ĉefaj kaŭzoj de RPC-eraroj en niaj protokoloj estas malsukcesaj provoj komuniki inter VBR-komponentoj (servilo > prokurilo, ekzemple) kaj plej ofte pro komunikadproblemoj.
La supra supro inter ĉiuj pintoj estas la eraro La RPC-servilo estas nedisponebla (1722). En simplaj terminoj, la kliento ne povis establi ligon kun la servilo. Kiel kaj kial - ne ekzistas ununura respondo, sed kutime ĝi estas problemo kun aŭtentikigo aŭ kun retaliro al haveno 135. Ĉi-lasta estas tipa por infrastrukturoj kun dinamika haveno-tasko. Pri ĉi tiu temo, ekzistas eĉ . Kaj Microsoft havas trovi la kaŭzon de la malsukceso.
Dua plej populara eraro: Estas ne pliaj finpunktoj haveblaj de la finpunktomapisto (1753). La RPC-kliento aŭ servilo ne asignis al si havenon. Kutime okazas kiam la servilo (en nia kazo, la gastmaŝino) estis agordita por dinamike asigni havenojn de mallarĝa gamo kiu finiĝis. Kaj se vi ensalutas de la klienta flanko (en nia kazo, la VBR-servilo), tio signifas, ke nia VeeamVssAgent aŭ ne komenciĝis aŭ ne estis registrita kiel RPC-interfaco. Estas ankaŭ pri ĉi tiu temo .
Nu, por kompletigi la Suprajn 3 RPC-erarojn, ni memoru RPC-funkcivokon malsukcesis (1726). Aperas se la konekto estis establita, sed RPC-petoj ne estas procesitaj. Ekzemple, ni petas informojn pri la stato de VSS (subite ĝuste nun ombra mino estas farita tie, kaj ni provas grimpi), kaj responde al ni, silentu kaj ignoru.
Windows Tape Backup API bezonata por labori kun bendbibliotekoj aŭ diskoj. Kiel mi menciis komence: ni ne havas plezuron skribi niajn proprajn ŝoforojn kaj poste suferi kun la subteno de ĉiu aparato. Tial vim ne havas proprajn ŝoforojn. Ĉio per norma API, kies subteno estas efektivigita de la aparataj vendistoj mem. Tiom pli logike, ĉu ne?
SMB / CIFS Pro kutimo, ĉiuj skribas ilin flank-al-flanke, kvankam ne ĉiuj memoras, ke CIFS (Komuna Interreta Dosiersistemo) estas nur privata versio de SMB (Server Message Block). Do estas nenio malbona kun ĝeneraligo de ĉi tiuj konceptoj. Samba jam estas realigo de LinuxUnix, kaj ĝi havas siajn proprajn proprecojn, sed mi eliras. Kio estas grava ĉi tie: kiam Veeam petas skribi ion al la UNC-vojo (serverdirectory), la servilo uzas la hierarkion de dosiersistemaj ŝoforoj, inkluzive de mup kaj mrxsmb, por skribi al la pilko. Sekve, ĉi tiuj ŝoforoj ankaŭ generos erarojn.
Ne povas malhavi Winsock API. Se io devas esti farita tra la reto, VBR funkcias per la Windows Socket API, populare konata kiel Winsock. Do se ni vidas amason da IP:Port en la protokolo, ĉi tio estas. La oficiala dokumentaro havas bonan liston de eblaj .
supre menciitaj WMI (Windows Management Instrumentation) estas speco de ĉiopova API por administri ĉion kaj ĉiujn en la Vindoza mondo. Ekzemple, kiam vi laboras kun Hyper-V, preskaŭ ĉiuj petoj al la gastiganto trairas ĝin. Unuvorte, la afero estas absolute neanstataŭebla kaj tre potenca laŭ siaj kapabloj. Provante helpi eltrovi kie kaj kio estas rompita, la enkonstruita ilo WBEMtest.exe multe helpas.
Kaj laste en la listo, sed tute ne malpli grave - VSS (Volumo Shadow Storage). La temo estas same neelĉerpebla kaj mistera, kiom multe da dokumentaro estis skribita pri ĝi. Ombra Kopio estas plej simple komprenata kiel speciala speco de momentfoto, kio esence ĝi estas. Danke al li, vi povas fari aplikajn sekurkopiojn en VMware, kaj preskaŭ ĉion en Hyper-V. Mi planas fari apartan artikolon kun iom da premo sur VSS, sed nuntempe vi povas provi legi . Nur atentu, ĉar. provi kompreni VSS en fulmo povas konduki al cerbolezo.
Pri ĉi tio, eble, ni povas ĉesi. Mi konsideras la taskon klarigi la plej bazajn aferojn finita, do en la sekva ĉapitro ni jam rigardos la protokolojn. Sed se vi havas demandojn, bonvolu demandi ilin en la komentoj.
fonto: www.habr.com