Asmatzearen mundu zoragarrian murgiltzen jarraitzen dugu... erregistroen bidez arazoak konpontzen. IN Oinarrizko terminoen esanahia adostu genuen eta Veeam-en egitura orokorra begi batekin begiratu genuen aplikazio bakar gisa. Honen zeregina erregistro-fitxategiak nola eratzen diren, haietan zer nolako informazioa bistaratzen den eta zergatik itxura duten itxura da.
Zer uste duzu dira "erregistro" hauek? Gehienen arabera, edozein aplikazioren erregistroei entitate ahalguztidun baten rola esleitu behar zaie gehienetan patioan nonbait landaretzen duena, baina une egokian armadura distiratsuan ezerezetik agertzen dena eta denak salbatzen ditu. Hau da, denetarik eduki behar dute, osagai bakoitzaren akats txikienetatik hasi eta datu-baseen transakzio indibidualetaraino. Eta horrela errorearen ondoren berehala idatzi zen nola konpondu bestela. Eta honek guztiak pare bat megabytetan sartu beharko luke, ez gehiago. Testua besterik ez da! Testu-fitxategiek ezin dituzte hamar gigabyte hartu, nonbait entzun dut!
Beraz, erregistroak
Mundu errealean, erregistroak diagnostiko-informazioaren artxibo bat besterik ez dira. Eta bertan zer gorde, biltegiratzeko informazioa non lortu eta zein zehatza izan behar den, garatzaileek beraiek erabakiko dute. Norbaitek minimalismoaren bidea jarraitzen du ON / OFF mailaren erregistroak mantenduz, eta norbaitek arretaz iraultzen du irits daitekeen guztia. Erregistro Maila deiturikoa hautatzeko aukera duen tarteko aukera ere badago ere, zuk zeuk adierazten duzunean zenbat informazio zehatza gorde nahi duzun eta zenbat leku gehigarri duzun diskoan =) VBR-k sei maila ditu, bide batez. Eta, sinets iezadazu, ez duzu ikusi nahi zer gertatzen den zure diskoan leku librea duen erregistro zehatzenarekin.
Ederki. Gutxi gorabehera ulertu genuen zer gorde nahi dugun, baina zilegizko galdera bat sortzen da: nondik lortu informazio hori? Jakina, gure barne prozesuen bidez erregistratzeko gertaeren parte gara. Baina zer egin kanpoko ingurunearekin elkarrekintza dagoenean? Makuluen eta bizikleten infernu batean lerratu ez dadin, Veeamek dagoeneko asmatutako asmakizunik ez asmatzeko joera du. Prestatutako API, funtzio integratua, liburutegia, etab. dagoen bakoitzean, prest dauden aukerei lehentasuna emango diegu gure tresnak hesitzen hasi aurretik. Azken hau ere nahikoa bada ere. Hori dela eta, erregistroak aztertzean, garrantzitsua da ulertzea erroreen zati handiena hirugarrenen APIen, sistema-deien eta beste liburutegien mezuetan erortzen dela. Kasu honetan, VBRren eginkizuna akats hauek erregistro fitxategietara birbidaltzea da. Eta erabiltzailearen zeregin nagusia zein lerro norengandik dagoen eta βnorβ hori zertaz arduratzen den ulertzen ikastea da. Beraz, VBR erregistroko errore-kode batek MSDN orri batera eramaten bazaitu, ondo eta zuzena da.
Lehenago adostu genuen bezala: Veeam SQLn oinarritutako aplikazioa da. Horrek esan nahi du ezarpen guztiak, informazio guztia eta, oro har, funtzionamendu normalerako soilik beharrezkoa dena - dena bere datu-basean gordetzen dela. Hortik egia sinplea: erregistroetan ez dagoena datu-basean egotea ziurrenik. Baina hau ere ez da zilarrezko bala: gauza batzuk ez daude Veeam osagaien erregistro lokaletan, ezta bere datu-basean ere. Hori dela eta, ostalariaren erregistroak, tokiko makinaren erregistroak eta babeskopia eta leheneratzeko prozesuan parte hartzen duen guztiaren erregistroak nola aztertzen ikasi behar duzu. Eta gertatzen da, gainera, beharrezko informazioa inon ez dagoela inon eskura. Hori da bidea.
Horrelako APIen adibide batzuk
Zerrenda honek ez du aparteko osoa izatea helburu, beraz, ez dago zertan azken egia bilatu behar. Bere helburua gure produktuetan erabiltzen diren hirugarrenen API eta teknologia ohikoenak erakustea da.
Has gaitezen VMware.
Zerrendako lehenengoa izango da vSphere APIa. Autentifikaziorako, hierarkia irakurtzeko, argazkiak sortzeko eta ezabatzeko, makinei buruzko informazioa eskatzeko eta askoz (asko) gehiago erabiltzen da. Irtenbidearen funtzionaltasuna oso zabala da, beraz, VMware vSphere API Reference gomenda dezaket bertsiorako ΠΈ . Egungo bertsioetarako, dena Googlen besterik ez dago.
VIX APIa. Hipervisorearen magia beltza, eta horretarako aparte dago . VMware APIa ostalariaren fitxategiekin lan egiteko sarearen bidez haiekin konektatu gabe. Azken aukera bat komunikazio kanal hoberik ez dagoen makina batean fitxategi bat jarri behar duzunean. Mina eta sufrimendua da fitxategia handia bada eta ostalaria kargatuta badago. Baina hemen arauak funtzionatzen du 56,6 Kb / s ere 0 Kb / s baino hobea dela. Hyper-V-en, gauza honi PowerShell Direct deitzen zaio. Baina hori lehen baino ez zen
vSpehere Web Services APIa vSphere 6.0tik hasita (gutxi gorabehera, API hau 5.5 bertsioan sartu zenetik) gonbidatutako makinekin lan egiteko erabiltzen da eta VIX ordezkatu du ia nonahi. Izan ere, hau vSphere kudeatzeko beste API bat da. Interesa dutenentzat ikastea gomendatzen dut eskuliburua.
VDDK (Disko birtuala garatzeko kit). Liburutegia, partez eztabaidatu zen honetan . Disko birtualak irakurtzeko erabiltzen da. Garai batean VIXaren parte zen, baina denborarekin produktu bereizi batera eraman zen. Baina oinordeko gisa, VIX-en errore-kode berdinak erabiltzen ditu. Baina arrazoiren batengatik, SDKn bertan ez dago errore hauen deskribapenik. Hori dela eta, enpirikoki jakin zen beste kode batzuekiko VDDK akatsak kode bitarretik hamartarrako itzulpena besterik ez direla. Bi zati ditu: lehenengo zatia testuinguruari buruzko dokumentaziorik gabeko informazioa da, eta bigarren zatia VIX / VDDK akats tradizionalak dira. Adibidez, ikusten badugu:
VDDK error: 21036749815809.Unknown error
Ondoren, ausardiaz bihurtzen dugu hau hex eta 132200000001 lortzen dugu. 132200-ren hasiera ez-informatiboa baztertzen dugu, eta gainerakoa gure errore-kodea izango da (VDDK 1: Errore ezezaguna). VDDK akats ohikoenei buruz, duela gutxi bereizi bat izan zen .
Ikus dezagun orain Leihoak.
Hemen, guretzat beharrezko eta garrantzitsuena dena estandarrean aurki daiteke Gertaeren ikustailea. Baina bada harrapaketa bat: tradizio luze baten arabera, Windows-ek ez du akatsaren testu osoa erregistratzen, bere zenbakia baizik. Adibidez, 5 errorea "Sarbidea ukatua" da, eta 1722 "RPC zerbitzaria ez dago erabilgarri" eta 10060 "Konexioaren denbora-muga amaitu da". Noski, bikaina da ospetsuenak gogoratzen badituzu, baina orain arte ikusi gabekoak?
Eta bizitzak batere eztia izan ez dadin, erroreak ere hamaseitar forman gordetzen dira, 0x8007 aurrizkiarekin. Adibidez, 0x8007000e benetan 14 da, Memoriarik gabe. Zergatik eta norentzat egin zen hori iluntasunean inguratutako misterio bat da. Hala ere, akatsen zerrenda osoa doan eta SMS gabe deskargatu daiteke .
Bide batez, batzuetan beste aurrizki batzuk daude, ez bakarrik 0x8007. Egoera triste horretan, HRESULT ("emaitzen heldulekua") ulertzeko, are gehiago sakondu behar duzu. garatzaileentzat. Bizitza arruntean, ez dizut hau egitea gomendatzen, baina bat-batean hormaren kontra estutzen bazara edo jakin-mina baduzu, orain badakizu zer egin.
Baina Microsoft-eko kideek errukitu egin zuten pixka bat eta munduari erabilgarritasun bat erakutsi zioten . Hau kontsolaren zorioneko zati txiki bat da, Google erabili gabe errore-kodeak gizaki bihurtu ditzakeena. Honela funtzionatzen du.
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"Galdera zilegi bat sortzen da: zergatik ez dugu berehala deszifratzea erregistroetan idazten, baina kode misteriotsu hauek uzten? Erantzuna hirugarrenen aplikazioetan dago. WinAPI dei batzuk ateratzen dituzunean, ez da zaila bere erantzuna deszifratzea, WinAPI dei berezi bat baitago horretarako. Baina esan bezala, erantzunetan bakarrik iristen zaigun guztia gure erregistroetan sartzen da. Eta hemen, deszifratzeko, etengabe kontrolatu beharko litzateke kontzientzia-korronte hori, Windows-eko akatsak dituzten piezak atera, deszifratu eta berriro itsatsi. Egia esan, ez da jarduera zirraragarriena.
Windows File Management APIa fitxategiekin lan egiteko modu guztietan erabiltzen da. Fitxategiak sortzea, ezabatzea, idazteko irekitzea, atributuekin lan egitea, etab.
gorago aipatua PowerShell Direct Hyper-V munduan VIX APIaren analogo gisa. Zoritxarrez, ez da hain malgua: funtzionalitatearen murrizketa asko, ez du funtzionatzen ostalariaren bertsio guztiekin eta ez gonbidatu guztiekin.
RPC (Urrutiko Prozedura Deia) Ez dut uste WINdows-ekin lan egin duen pertsona bakar bat dagoenik RPCrekin lotutako akatsak ikusi ez dituenik. Uste oker ezaguna izan arren, hau ez da protokolo bakarra, parametro batzuk betetzen dituen bezero-zerbitzari protokoloa baizik. Hala ere, gure erregistroetan RPC akatsen bat badago, denboraren % 90 Microsoft RPCren errore bat izango da, hau da, DCOM (Distributed Component Object Model) parte den. Gai honi buruzko dokumentazio mordoa aurki dezakezu sarean, baina nahiko zaharkituta dago. Baina gaia aztertzeko gogo bizia badago, orduan artikuluak gomenda ditzaket , eta zerrenda luzea .
Gure erregistroetako RPC akatsen kausa nagusiak VBR osagaien artean (zerbitzaria > proxya, adibidez) komunikatzeko saiakerak huts egiteak dira eta gehienetan komunikazio arazoengatik.
Goiko guztien artean goiko aldea errorea da RPC zerbitzaria ez dago erabilgarri (1722). Termino sinpleetan, bezeroak ezin izan du zerbitzariarekin konexiorik ezarri. Nola eta zergatik - ez dago erantzun bakarra, baina normalean autentifikazioarekin edo sarerako sarbidearekin 135 atakarako arazoa izaten da. Azken hori ohikoa da portu esleipen dinamikoa duten azpiegituretarako. Gai honi buruz, badago ere . Eta Microsoft-ek hutsegitearen kausa aurkitzeko.
Bigarren errorerik ezagunena: ez dago amaiera-puntu gehiago erabilgarri amaiera-puntuen mapa-mapeatik (1753). RPC bezeroak edo zerbitzariak huts egin dio bere buruari ataka bat esleitu. Normalean zerbitzaria (gure kasuan, gonbidatua den makina) amaitu den sorta estu batetik portuak dinamikoki esleitzeko konfiguratu denean gertatzen da. Eta bezeroaren aldetik saioa hasten baduzu (gure kasuan, VBR zerbitzaritik), horrek esan nahi du gure VeeamVssAgent ez dela hasi edo ez zegoela RPC interfaze gisa erregistratu. Gai honi buruz ere badago .
Beno, 3 RPC akats nagusiak osatzeko, gogora dezagun RPC funtzio-deiak huts egin duela (1726). Konexioa ezarri bada, baina RPC eskaerak prozesatzen ez badira agertzen da. Esaterako, VSSren egoerari buruzko informazioa eskatzen dugu (bat-batean oraintxe bertan itzal meategi bat egiten ari da, eta igotzen saiatzen ari gara), eta guri erantzunez, isildu eta baztertu.
Windows Tape Backup APIa zinta liburutegiekin edo unitateekin lan egiteko. Hasieran aipatu dudan bezala: ez dugu atsegin gure gidariak idazteko eta gero gailu bakoitzaren laguntzarekin sufritzeko. Beraz, vim-ek ez du berezko gidaririk. Guztia API estandar baten bidez, zeinaren euskarria hardware saltzaileek beraiek ezartzen dutena. Askoz logikoagoa, ezta?
SMB / CIFS Ohituraz, denek elkarren ondoan idazten dituzte, nahiz eta denek ez duten gogoratzen CIFS (Common Internet File System) SMB (Server Message Block) bertsio pribatu bat besterik ez dela. Beraz, ez dago ezer gaizki kontzeptu hauek orokortzeak. Samba LinuxUnix inplementazio bat da dagoeneko, eta bere berezitasunak ditu, baina alde egiten dut. Hemen garrantzitsua dena: Veeam-ek UNC bidera (zerbitzarien direktorioa) zerbait idazteko eskatzen duenean, zerbitzariak fitxategi-sistemaren kontrolatzaileen hierarkia erabiltzen du, mup eta mrxsmb barne, pilotan idazteko. Horren arabera, gidari horiek akatsak ere sortuko dituzte.
Ezin gabe egin Winsock APIa. Sarean zerbait egin behar bada, VBR-k Windows Socket APIaren bidez funtzionatzen du, Winsock izenez ezagutzen dena. Beraz, erregistroan IP:Port mordoa ikusten badugu, hau da. Dokumentazio ofizialak posibleen zerrenda ona du .
gorago aipatua WMI (Windows Management Instrumentation) Windows munduko guztia eta guzti kudeatzeko API ahalguztidun moduko bat da. Adibidez, Hyper-V-rekin lan egiten denean, ostalariaren eskaera ia guztiak bertatik pasatzen dira. Hitz batean, gauza guztiz ordezkaezina eta oso indartsua da bere gaitasunetan. Non eta zer hautsi den jakiten lagundu nahian, integratutako WBEMtest.exe tresnak asko laguntzen du.
Eta zerrendako azkena, baina inola ere garrantzi gutxienekoa - VSS (Bolumen Itzala Biltegiratzea). Gaia agortezina eta misteriotsua da horren gainean idatzitako dokumentazio asko. Itzal kopia argazki mota berezi gisa ulertzen da, funtsean. Berari esker, aplikazioekin bat datozen babeskopiak egin ditzakezu VMware-n, eta ia dena Hyper-V-en. Artikulu bereizi bat egiteko asmoa daukat VSS-n pixka bat estutuz, baina oraingoz irakurtzen saia zaitezke . Kontuz ibili, zeren. VSS berehala ulertzen saiatzeak garuneko lesioak sor ditzake.
Honetan, agian, gelditu gaitezke. Oinarrizkoenak azaltzeko zeregina amaitutzat jotzen dut, beraz, hurrengo kapituluan erregistroak aztertuko ditugu jada. Baina galderarik baduzu, lasai egin iruzkinetan.
Iturria: www.habr.com