Որտեղի՞ց են գալիս տեղեկամատյանները: Veeam Log Diving

Մենք շարունակում ենք մեր ընկղմվելը գուշակությունների հետաքրքրաշարժ աշխարհում ... անսարքությունների վերացում տեղեկամատյանների միջոցով: IN նախորդ հոդվածը մենք պայմանավորվեցինք հիմնական տերմինների իմաստի շուրջ և նայեցինք Veeam-ի ընդհանուր կառուցվածքին որպես մեկ աչքով մեկ հավելված: Այս մեկի խնդիրն է պարզել, թե ինչպես են ձևավորվում գրանցամատյանների ֆայլերը, ինչպիսի տեղեկատվություն են ցուցադրվում դրանցում և ինչու են դրանք իրենց տեսքին:

Ի՞նչ եք կարծում, որո՞նք են այս «գերանները»: Ըստ մեծամասնության՝ ցանկացած հավելվածի տեղեկամատյաններին պետք է վերապահել մի տեսակ ամենազոր էակի դեր, որը ժամանակի մեծ մասը բուսում է ինչ-որ տեղ բակում, բայց ճիշտ պահին հայտնվում է ոչ մի տեղից փայլող զրահով և փրկում բոլորին: Այսինքն՝ դրանք պետք է պարունակեն ամեն ինչ՝ սկսած յուրաքանչյուր բաղադրիչի ամենափոքր սխալներից մինչև տվյալների բազայի առանձին գործարքներ։ Եվ այնպես, որ սխալից հետո անմիջապես գրված էր, թե այլ կերպ ինչպես ուղղել այն։ Եվ այս ամենը պետք է տեղավորվի մի երկու մեգաբայթի մեջ, ոչ ավելին։ Դա պարզապես տեքստ է: Տեքստային ֆայլերը չեն կարող տասնյակ գիգաբայթեր տանել, ես դա ինչ-որ տեղ լսել եմ:

Այսպիսով, տեղեկամատյանները

Իրական աշխարհում տեղեկամատյանները պարզապես ախտորոշիչ տեղեկատվության արխիվ են: Իսկ թե ինչ պահեստավորել այնտեղ, որտեղից տեղեկություններ ստանալ պահեստավորման համար և որքանով այն պետք է մանրամասն լինի, դա հենց մշակողների որոշելիքն է: Ինչ-որ մեկը հետևում է մինիմալիզմի ուղին՝ պահելով ON/OFF մակարդակի գրառումները, իսկ ինչ-որ մեկը ջանասիրաբար հավաքում է այն ամենը, ինչին կարող է հասնել: Չնայած կա նաև միջանկյալ տարբերակ՝ այսպես կոչված Logging Level ընտրելու հնարավորությամբ, երբ դուք ինքներդ նշում եք, թե որքան մանրամասն տեղեկատվություն եք ուզում պահել և որքան սկավառակի լրացուցիչ տարածք ունեք =) VBR-ն, ի դեպ, ունի վեց այդպիսի մակարդակ։ Եվ, հավատացեք ինձ, դուք չեք ցանկանում տեսնել, թե ինչ է տեղի ունենում ձեր սկավառակի վրա ազատ տարածությամբ առավել մանրամասն գրանցման դեպքում:

Լավ: Մոտավորապես հասկացանք, թե ինչ ենք ուզում փրկել, բայց օրինաչափ հարց է առաջանում՝ որտեղի՞ց ստանալ այս տեղեկատվությունը։ Անշուշտ, մենք իրադարձությունների մի մասն ենք կազմում մեր ներքին պրոցեսների միջոցով ինքներս մեզ լուսաբանելու համար: Բայց ի՞նչ անել, երբ արտաքին միջավայրի հետ փոխազդեցություն կա։ Հենակների և հեծանիվների դժոխքի մեջ չսահելու համար Veeam-ը հակված է չհորինել արդեն իսկ հորինված գյուտեր: Ամեն անգամ, երբ կա պատրաստի API, ներկառուցված գործառույթ, գրադարան և այլն, մենք նախապատվությունը կտանք պատրաստի տարբերակներին, նախքան մեր հակասությունները ցանկապատելը: Չնայած վերջինս նույնպես բավական է։ Հետևաբար, տեղեկամատյանները վերլուծելիս կարևոր է հասկանալ, որ սխալների առյուծի բաժինը բաժին է ընկնում երրորդ կողմի API-ների, համակարգային զանգերի և այլ գրադարանների հաղորդագրություններին: Այս դեպքում VBR-ի դերն իջնում ​​է այս սխալները տեղեկամատյանների ֆայլերին փոխանցելուն: Իսկ օգտագործողի հիմնական խնդիրն է սովորել հասկանալ, թե որ տողը ումից է, և ինչի համար է պատասխանատու այս «ով»: Այսպիսով, եթե VBR մատյանից սխալի կոդը ձեզ տանում է MSDN էջ, դա լավ է և ճիշտ:

Ինչպես ավելի վաղ պայմանավորվել էինք, Veeam-ը, այսպես կոչված, SQL-ի վրա հիմնված հավելված է: Սա նշանակում է, որ բոլոր կարգավորումները, բոլոր տեղեկությունները և ընդհանրապես այն ամենը, ինչ անհրաժեշտ է միայն նորմալ գործելու համար, ամեն ինչ պահվում է իր տվյալների բազայում: Այստեղից էլ պարզ ճշմարտությունը. այն, ինչ չկա տեղեկամատյաններում, ամենայն հավանականությամբ գտնվում է տվյալների բազայում: Բայց սա նույնպես արծաթափայլ չէ. որոշ բաներ չկան Veeam բաղադրիչների տեղական տեղեկամատյաններում, ոչ էլ տվյալների բազայում: Հետևաբար, դուք պետք է սովորեք, թե ինչպես ուսումնասիրել հյուրընկալող տեղեկամատյանները, տեղական մեքենայի տեղեկամատյանները և այն ամենի տեղեկամատյանները, որոնք ներգրավված են պահուստավորման և վերականգնման գործընթացում: Եվ պատահում է նաև, որ անհրաժեշտ տեղեկատվությունն ընդհանրապես ոչ մի տեղ հասանելի չէ։ Դա է ճանապարհը։ 

Նման API-ների որոշ օրինակներ

Այս ցանկը բացառապես ամբողջական լինելու նպատակ չունի, ուստի կարիք չկա դրանում վերջնական ճշմարտություն փնտրել։ Դրա նպատակն է միայն ցույց տալ երրորդ կողմի ամենատարածված API-ները և մեր արտադրանքներում օգտագործվող տեխնոլոգիաները:

Սկսենք նրանից VMware. 

Ցանկում առաջինը կլինի vSphere API. Օգտագործվում է նույնականացման, հիերարխիան կարդալու, նկարներ ստեղծելու և ջնջելու, մեքենաների մասին տեղեկություններ խնդրելու և շատ (շատ) ավելին: Լուծման ֆունկցիոնալությունը շատ լայն է, ուստի ես կարող եմ առաջարկել VMware vSphere API-ի հղումը տարբերակի համար 5.5 и 6.0. Ավելի ընթացիկ տարբերակների համար ամեն ինչ պարզապես googled է:

VIX API. Հիպերվիզորի սեւ մոգությունը, որի համար կա առանձին սխալների ցուցակ. VMware API՝ հոսթում ֆայլերի հետ աշխատելու համար՝ առանց ցանցի միջոցով դրանց միանալու: Վերջին միջոցի տարբերակ, երբ դուք պետք է ֆայլ դնեք մեքենայի մեջ, որի համար չկա ավելի լավ հաղորդակցման ալիք: Ցավ ու տառապանք է, եթե ֆայլը մեծ է, և հյուրընկալողը բեռնված է: Բայց այստեղ գործում է այն կանոնը, որ նույնիսկ 56,6 Կբ/վ-ն ավելի լավ է, քան 0 Կբ/վ-ը: Hyper-V-ում այս բանը կոչվում է PowerShell Direct: Բայց դա միայն նախկինում էր

vSpehere Web Services API Սկսած vSphere 6.0-ից (մոտավորապես, քանի որ այս API-ն առաջին անգամ ներկայացվել է 5.5 տարբերակում), այն օգտագործվում է հյուր մեքենաների հետ աշխատելու համար և գրեթե ամենուր փոխարինել է VIX-ին: Փաստորեն, սա ևս մեկ API է vSphere-ի կառավարման համար: Հետաքրքրվողներին խորհուրդ եմ տալիս սովորել մեծ է ձեռնարկ. 

VDDK (Վիրտուալ սկավառակի մշակման հավաքածու): Գրադարանը, որը մասամբ քննարկվել է այս Հոդված. Օգտագործվում է վիրտուալ սկավառակներ կարդալու համար: Ժամանակին այն VIX-ի մի մասն էր, բայց ժամանակի ընթացքում այն ​​տեղափոխվեց առանձին արտադրանք: Բայց որպես ժառանգորդ, այն օգտագործում է նույն սխալի կոդերը, ինչ VIX-ը: Բայց չգիտես ինչու, այս սխալների նկարագրությունը հենց SDK-ում չկա: Հետևաբար, էմպիրիկորեն պարզվեց, որ այլ կոդերի հետ VDDK սխալները պարզապես թարգմանություն են երկուականից տասնորդական կոդ: Այն բաղկացած է երկու մասից՝ առաջին կեսը չփաստաթղթավորված տեղեկատվություն է համատեքստի մասին, իսկ երկրորդ մասը՝ ավանդական VIX/VDDK սխալները: Օրինակ, եթե տեսնենք.

VDDK error: 21036749815809.Unknown error

Այնուհետև մենք համարձակորեն փոխակերպում ենք սա վեցանկյունի և ստանում ենք 132200000001: Մենք պարզապես մերժում ենք 132200-ի ոչ տեղեկատվական սկիզբը, իսկ մնացածը կլինի մեր սխալի կոդը (VDDK 1: Անհայտ սխալ): Ամենահաճախակի VDDK սխալների մասին, վերջերս կար առանձին հոդված.

Հիմա եկեք նայենք Windows.

Այստեղ ստանդարտում կարելի է գտնել այն ամենը, ինչ մեզ համար առավել անհրաժեշտ և կարևոր է Միջոցառումների դիտում. Բայց կա մեկ բան. երկար ավանդույթի համաձայն, Windows-ը չի գրանցում սխալի ամբողջական տեքստը, այլ միայն դրա համարը: Օրինակ, սխալ 5-ը «Մուտքը մերժված է», իսկ 1722-ը՝ «RPC սերվերն անհասանելի է», իսկ 10060-ը՝ «Միացման ժամանակը սպառվել է»: Իհարկե, հիանալի է, եթե հիշեք ամենահայտնիները, իսկ մինչ այժմ չտեսնվածների մասին ի՞նչ կասեք: 

Եվ որպեսզի կյանքը ընդհանրապես մեղր չթվա, սխալները պահվում են նաև տասնվեցական ձևով՝ 0x8007 նախածանցով։ Օրինակ, 0x8007000e-ն իրականում 14 է, հիշողությունից դուրս է: Ինչու և ում համար դա արվեց, առեղծված է մթության մեջ: Այնուամենայնիվ, սխալների ամբողջական ցանկը կարելի է ներբեռնել անվճար և առանց SMS-ից devcenter.

Ի դեպ, երբեմն լինում են այլ նախածանցներ, ոչ միայն 0x8007: Նման տխուր իրավիճակում HRESULT-ը («արդյունքի բռնակ») հասկանալու համար հարկավոր է ավելի խորանալ. փաստաթղթեր մշակողների համար: Սովորական կյանքում ես ձեզ խորհուրդ չեմ տալիս դա անել, բայց եթե հանկարծ սեղմել եք պատին կամ պարզապես հետաքրքրվել եք, հիմա գիտեք, թե ինչ անել:

Բայց Microsoft-ի ընկերները մի քիչ խղճացին մեզ և աշխարհին ցույց տվեցին օգտակար բան Մոլորվել. Սա վահանի երջանկության փոքրիկ կտոր է, որը կարող է սխալի կոդերը թարգմանել մարդու՝ առանց Google-ի օգտագործման: Այն աշխատում է այսպես.

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"

Օրինական հարց է ծագում՝ ինչո՞ւ մենք անմիջապես չենք գրում վերծանումը տեղեկամատյաններում, այլ թողնում ենք այս առեղծվածային ծածկագրերը։ Պատասխանը երրորդ կողմի հավելվածներում է: Երբ դուք ինքներդ եք վերցնում ինչ-որ WinAPI զանգ, դժվար չէ վերծանել դրա պատասխանը, քանի որ դրա համար նույնիսկ կա հատուկ WinAPI զանգ: Բայց, ինչպես արդեն նշվեց, այն ամենը, ինչ գալիս է մեզ միայն պատասխաններով, մտնում է մեր տեղեկամատյանները: Եվ այստեղ, այն ապակոդավորելու համար, պետք է անընդհատ վերահսկել գիտակցության այս հոսքը, այնտեղից հանել Windows-ի սխալներով կտորներ, վերծանել և ետ տեղադրել։ Եկեք անկեղծ լինենք, ոչ ամենահուզիչ գործունեությունը:

Windows Ֆայլերի կառավարման API օգտագործվում է ամեն կերպ ֆայլերի հետ աշխատելիս: Ֆայլերի ստեղծում, ջնջում, գրելու համար բացում, ատրիբուտների հետ աշխատանք և այլն, և այլն:

Վերը նշված PowerShell Direct որպես VIX API-ի անալոգ Hyper-V աշխարհում: Ցավոք, ոչ այնքան ճկուն. ֆունկցիոնալության շատ սահմանափակումներ, այն չի աշխատում հյուրընկալողի յուրաքանչյուր տարբերակի և ոչ բոլոր հյուրերի հետ:

RPC (Remote Procedure Call) Չեմ կարծում, որ կա մեկ մարդ, ով աշխատել է WIndows-ի հետ, ով չի տեսել RPC-ի հետ կապված սխալներ: Չնայած տարածված թյուր կարծիքին, սա մեկ արձանագրություն չէ, այլ ցանկացած հաճախորդ-սերվեր արձանագրություն, որը բավարարում է մի շարք պարամետրեր: Այնուամենայնիվ, եթե մեր տեղեկամատյաններում կա RPC սխալ, ապա 90% դեպքերում դա սխալ կլինի Microsoft RPC-ից, որը DCOM-ի (Բաշխված բաղադրիչ օբյեկտի մոդել) մաս է կազմում: Ցանցում դուք կարող եք գտնել հսկայական քանակությամբ փաստաթղթեր այս թեմայով, բայց դրա առյուծի բաժինը բավականին հնացած է: Բայց եթե կա թեման ուսումնասիրելու սուր ցանկություն, ապա կարող եմ հոդվածներ խորհուրդ տալ Ի՞նչ է RPC-ն:, Ինչպես RPC աշխատանքներ և երկար ցուցակ RPC սխալներ.

Մեր տեղեկամատյաններում RPC սխալների հիմնական պատճառները VBR բաղադրիչների միջև հաղորդակցվելու ձախողված փորձերն են (օրինակ՝ սերվեր > վստահված անձ) և առավել հաճախ կապի հետ կապված խնդիրների պատճառով:

Բոլոր գագաթների շարքում վերին վերևը սխալ է: RPC սերվերն անհասանելի է (1722): Պարզ ասած, հաճախորդը չկարողացավ կապ հաստատել սերվերի հետ: Ինչպես և ինչու – չկա մեկ պատասխան, բայց սովորաբար դա նույնականացման կամ 135 նավահանգստի ցանցի հասանելիության խնդիր է: Վերջինս բնորոշ է դինամիկ պորտի նշանակմամբ ենթակառուցվածքների համար: Այս թեմայով նույնիսկ կա առանձին ՀՖ. Իսկ Microsoft-ն ունի ծավալուն ուղեցույց գտնել ձախողման պատճառը.

Երկրորդ ամենահայտնի սխալը. Վերջնակետի քարտեզագրիչից (1753) այլևս վերջնակետեր չկան: RPC հաճախորդին կամ սերվերին չհաջողվեց ինքն իրեն մի նավահանգիստ հատկացնել: Սովորաբար տեղի է ունենում, երբ սերվերը (մեր դեպքում՝ հյուրի մեքենան) կազմաձևված է, որպեսզի դինամիկ կերպով բաշխի նավահանգիստները նեղ միջակայքից, որն ավարտվել է: Եվ եթե դուք մուտք եք գործում հաճախորդի կողմից (մեր դեպքում՝ VBR սերվերից), դա նշանակում է, որ մեր VeeamVssAgent-ը կամ չի սկսել, կամ գրանցված չէ որպես RPC ինտերֆեյս։ Այս թեմայով էլ կա առանձին ՀՖ.

Դե, լավագույն 3 RPC սխալները լրացնելու համար եկեք հիշենք, որ RPC ֆունկցիայի կանչը ձախողվեց (1726): Հայտնվում է, եթե կապը հաստատվել է, բայց RPC հարցումները չեն մշակվում: Օրինակ՝ խնդրում ենք տեղեկություն VSS-ի կարգավիճակի մասին (հանկարծ հենց հիմա այնտեղ ստվերային ական է սարքում, և մենք փորձում ենք բարձրանալ), իսկ մեզ ի պատասխան՝ լռել ու անտեսել։

Windows Tape Backup API անհրաժեշտ է ժապավենային գրադարանների կամ սկավառակների հետ աշխատելու համար: Ինչպես սկզբում նշեցի, մենք հաճույք չունենք գրել մեր սեփական դրայվերները և հետո տանջվել յուրաքանչյուր սարքի աջակցությամբ: Հետևաբար, vim-ը չունի սեփական վարորդներ: Ամբողջը ստանդարտ API-ի միջոցով, որի աջակցությունն իրականացվում է հենց ապարատային վաճառողների կողմից: Շատ ավելի տրամաբանական, չէ՞:

SMB / CIFS Սովորությունից դրդված բոլորը դրանք գրում են կողք կողքի, չնայած ոչ բոլորն են հիշում, որ CIFS-ը (Common Internet File System) SMB-ի (Server Message Block) ընդամենը մասնավոր տարբերակն է։ Այսպիսով, այս հասկացությունների ընդհանրացման մեջ ոչ մի վատ բան չկա: Samba-ն արդեն LinuxUnix-ի ներդրում է, և այն ունի իր առանձնահատկությունները, բայց ես շեղվում եմ: Ինչն է կարևոր այստեղ. երբ Veeam-ը խնդրում է ինչ-որ բան գրել UNC ճանապարհին (սերվերի գրացուցակ), սերվերը օգտագործում է ֆայլային համակարգի դրայվերների հիերարխիան, ներառյալ mup և mrxsmb, գնդակին գրելու համար: Համապատասխանաբար, այս դրայվերները նույնպես կառաջացնեն սխալներ:

Չի կարող առանց Winsock API. Եթե ​​ինչ-որ բան պետք է անել ցանցի միջոցով, VBR-ն աշխատում է Windows Socket API-ի միջոցով, որը հայտնի է որպես Winsock: Այսպիսով, եթե մենք գրանցամատյանում տեսնում ենք IP:Port-ի մի փունջ, սա այն է: Պաշտոնական փաստաթղթերն ունեն հնարավորի լավ ցանկ սխալներ.

Վերը նշված WMI (Windows Management Instrumentation) մի տեսակ ամենազոր API է Windows-ի աշխարհում ամեն ինչ և բոլորին կառավարելու համար: Օրինակ, Hyper-V-ի հետ աշխատելիս հոսթին ուղղված գրեթե բոլոր հարցումներն անցնում են դրա միջով: Մի խոսքով, իրը բացարձակապես անփոխարինելի է ու շատ հզոր իր հնարավորություններով։ Փորձելով օգնել պարզել, թե որտեղ և ինչ է կոտրվել, ներկառուցված WBEMtest.exe գործիքը շատ է օգնում:

Եվ վերջինը ցուցակում, բայց ոչ պակաս կարևորությամբ. VSS- ը (Volume Shadow Storage): Թեման նույնքան անսպառ է ու առեղծվածային, որքան էլ դրա վրա գրված է շատ փաստաթղթեր։ Shadow Copy-ն ամենից պարզ հասկացվում է որպես հատուկ տիպի snapshot, որը, ըստ էության, այդպես է: Նրա շնորհիվ VMware-ում կարող եք կատարել հավելվածներին համապատասխան կրկնօրինակումներ, իսկ Hyper-V-ում գրեթե ամեն ինչ։ Ես պլաններ ունեմ առանձին հոդված պատրաստել VSS-ում որոշակի սեղմումով, բայց առայժմ կարող եք փորձել կարդալ այս նկարագրությունը. Պարզապես զգույշ եղեք, քանի որ. VSS-ը միանգամից հասկանալու փորձը կարող է հանգեցնել ուղեղի վնասվածքի:

Սրա վրա, թերեւս, կարող ենք կանգ առնել։ Ամենատարրական բաները բացատրելու առաջադրանքը ես ավարտված եմ համարում, ուստի հաջորդ գլխում մենք արդեն կանդրադառնանք տեղեկամատյաններին: Բայց եթե ունեք հարցեր, ազատ զգալ հարցրեք նրանց մեկնաբանություններում:

Source: www.habr.com