Veeam-ում մենք սիրում ենք գերաններ: Եվ քանի որ մեր լուծումների մեծ մասը մոդուլային է, նրանք բավականին շատ տեղեկամատյաններ են գրում։ Եվ քանի որ մեր գործունեության շրջանակը ձեր տվյալների (այսինքն՝ հանգիստ քուն) անվտանգությունն ապահովելն է, ապա տեղեկամատյանները պետք է ոչ միայն գրանցեն յուրաքանչյուր փռշտոց, այլև դա կատարեն որոշակի մանրամասնությամբ։ Սա անհրաժեշտ է, որպեսզի եթե ինչ-որ բան լինի, պարզ լինի, թե ինչպես է տեղի ունեցել այս «ինչը», ով է մեղավոր և ինչ է պետք անել հետո։ Դա նման է դատաբժշկական փորձաքննությանը. երբեք չգիտես, թե ինչ փոքր բան կօգնի քեզ գտնել Լաուրա Փալմերի մարդասպանին:
Հետևաբար, ես որոշեցի սկսել հոդվածների շարք, որտեղ հետևողականորեն կխոսեմ այն մասին, թե ինչ ենք գրում տեղեկամատյաններում, որտեղ ենք դրանք պահում, ինչպես չխելագարվել դրանց կառուցվածքով և ինչ փնտրել դրանց ներսում:
Ինչու՞ հոդվածաշար և ինչու չնկարագրել ամեն ինչ միանգամից:
Պարզապես թվարկել, թե որ տեղեկամատյանը որտեղ և ինչ է պահվում դրանում, բավականին աղետալի գաղափար է: Եվ սարսափելի է նույնիսկ մտածել այս տեղեկատվությունը արդիական պահելու մասին: Veeam Backup & Replication-ում գրանցամատյանների բոլոր հնարավոր տեսակների պարզ ցուցակը փոքր տպագրությամբ մի քանի թերթերի աղյուսակ է: Իսկ դա ակտուալ կլինի միայն հրապարակման պահին, քանի որ... Երբ հաջորդ կարկատելը թողարկվի, կարող են հայտնվել նոր տեղեկամատյաններ, կփոխվի պահպանված տեղեկատվության տրամաբանությունը հիններում և այլն: Ուստի շատ ավելի ձեռնտու կլինի բացատրել դրանց կառուցվածքը և դրանցում պարունակվող տեղեկատվության էությունը։ Սա թույլ կտա ձեզ ավելի լավ կողմնորոշվել վայրերում, քան անունների սովորական խճողումը:
Հետևաբար, որպեսզի չշտապենք տեքստային թերթիկների լողավազանի մեջ, եկեք մի քանի նախապատրաստական աշխատանք կատարենք այս հոդվածում: Հետևաբար, այսօր մենք չենք խորանա հենց տեղեկամատյանների մեջ, այլ կգնանք հեռվից. մենք կկազմենք բառարան և մի փոքր կքննարկենք Veeam-ի կառուցվածքը տեղեկամատյանների ստեղծման տեսանկյունից:
Բառարան և ժարգոն
Այստեղ, նախ և առաջ, արժե ներողություն խնդրել ռուսաց լեզվի մաքրության պաշտպաններից և Օժեգովի բառարանի վկաներից։ Մենք բոլորս շատ ենք սիրում մեր մայրենի լեզուն, բայց անիծված ՏՏ ոլորտն աշխատում է անգլերենով: Դե, մենք դա չենք մտածել, բայց պատմականորեն այսպես է եղել: Ես մեղավոր չեմ, նա ինքն է եկել (գ)
Մեր բիզնեսում անգլիականության (և ժարգոնի) խնդիրն ունի իր առանձնահատկությունները։ Երբ «հյուրընկալող» կամ «հյուր» անմեղ բառերով ողջ աշխարհը վաղուց հասկացել է շատ կոնկրետ բաներ, ապա երկրի ⅙-ի վրա հերոսական շփոթմունքն ու բառարանները թոթովելը շարունակվում է: Եվ խիստ պարտադիր փաստարկը «Բայց մեր աշխատանքում...»:
Բացի այդ, կա զուտ մեր տերմինաբանությունը, որը հատուկ է Veeam-ի արտադրանքին, թեև որոշ բառեր և արտահայտություններ հայտնի են դարձել: Հետևաբար, հիմա մենք կպայմանավորվենք, թե ինչ է նշանակում տերմինը, իսկ ապագայում «հյուր» բառով ես նկատի կունենամ հենց այն, ինչ գրված է այս գլխում, և ոչ թե այն, ինչին դուք սովոր եք աշխատանքի մեջ: Եվ այո, սա իմ անձնական քմահաճույքը չէ, սրանք ոլորտում կայացած տերմիններ են։ Նրանց հետ պայքարելն ինչ-որ չափով անիմաստ է: Չնայած ես միշտ կողմնակից եմ մեկնաբանություններում լավ լինելուն։
Ցավոք սրտի, մեր աշխատանքում շատ տերմիններ և ապրանքներ կան, ուստի ես չեմ փորձի թվարկել դրանք բոլորը: Միայն ամենահիմնական տեղեկությունները պահուստների և տեղեկամատյանների մասին, որոնք անհրաժեշտ են ծովում գոյատևելու համար: Ցանկացողների համար կարող եմ նաև գործընկերները հոսքերի մասին, որտեղ նա նաև տրամադրեց ֆունկցիոնալության այդ մասի հետ կապված տերմինների ցանկը:
Հյուրընկալող: Վիրտուալիզացիայի աշխարհում սա հիպերվիզորով մեքենա է: Ֆիզիկական, վիրտուալ, ամպային - դա նշանակություն չունի: Եթե ինչ-որ բան աշխատում է հիպերվիզորով (ESXi, Hyper-V, KVM և այլն), ապա այս «ինչ-որ բանը» կոչվում է հոսթ: Լինի դա տասը դարակներով կլաստեր, թե մեկուկես վիրտուալ մեքենաների լաբորատորիա ունեցող ձեր նոութբուքը, եթե գործարկեք հիպերվիզոր, կդառնաք հյուրընկալող: Քանի որ հիպերվիզորը հյուրընկալում է վիրտուալ մեքենաներ: Նույնիսկ պատմություն կա, որ VMware-ը մի ժամանակ ցանկանում էր հասնել հյուրընկալող բառի ամուր ասոցիացիան ESXi-ի հետ: Բայց նա չկարողացավ դա անել:
Ժամանակակից աշխարհում «հյուրընկալող» հասկացությունը գործնականում միաձուլվել է «սերվեր» հասկացության հետ, ինչը որոշակի շփոթություն է առաջացնում հաղորդակցության մեջ, հատկապես երբ խոսքը վերաբերում է Windows ենթակառուցվածքին: Այսպիսով, ցանկացած մեքենա, որի վրա գտնվում է մեզ հետաքրքրող ինչ-որ ծառայություն, կարելի է ապահով անվանել հյուրընկալող: Օրինակ, WinSock տեղեկամատյաններում ամեն ինչ նշված է host բառով: Դասական «Host not found»-ը դրա օրինակն է: Այսպիսով, մենք ելնում ենք համատեքստից, բայց հիշեք, որ վիրտուալացման աշխարհում հյուրընկալողն այն է, ինչ հյուրընկալում է հյուրերին (ավելին այս երկու տողում ստորև):
Տեղական ժարգոնից (ավելի հավանական է նույնիսկ հապավումներ, այս դեպքում), ես հիշում եմ, որ VMware-ը VI-ն է, vSphere-ը՝ VC-ն, իսկ Hyper-V-ը՝ HV-ն։
Հյուր. Վիրտուալ մեքենա, որն աշխատում է հոսթի վրա: Այստեղ նույնիսկ բացատրելու բան չկա, ամեն ինչ այնքան տրամաբանական է և պարզ: Այնուամենայնիվ, շատերն այստեղ ջանասիրաբար քաշում են որոշ այլ իմաստներ։
Ինչի համար? չգիտեմ։
Guest OS-ն, համապատասխանաբար, հյուրի մեքենայի օպերացիոն համակարգն է: Եվ այսպես շարունակ։
Պահուստավորման/կրկնօրինակման աշխատանք (jobA): Մաքուր Wim ժարգոն, որը նշանակում է առաջադրանքներից մեկը: Պահուստային աշխատանք == Պահուստային աշխատանք: Ոչ ոք չի հասկացել, թե ինչպես դա գեղեցիկ թարգմանել ռուսերեն, այնպես որ բոլորն ասում են «jobA»: Վերջին վանկի վրա շեշտադրումով։
Այո, այդպես են գնում և ասում «ջոբա»: Եվ նույնիսկ տառերով են այդպես գրում, ու ամեն ինչ լավ է։
Բոլոր տեսակի պահեստային աշխատանք, պահեստային առաջադրանքներ և այլն, շնորհակալություն, բայց կարիք չկա: Պարզապես գործ արա, և նրանք քեզ կհասկանան։ Գլխավորը շեշտը դնել վերջին վանկի վրա։
Պահուստավորում (Պահուստավորում, կրկնօրինակում: True-oldfags-ի համար Պահուստավորումը թույլատրվում է): Բացի ակնհայտից (ինչ-որ տեղ ընկած տվյալների կրկնօրինակը), դա նաև նշանակում է հենց աշխատանքը (երեք տող վերևում, եթե արդեն մոռացել եք), որի արդյունքում հայտնվում է նույն պահուստային ֆայլը: Հավանաբար, պարոնայք, անգլիախոսները չափազանց ծույլ են ասել, որ ես ամեն անգամ վարել եմ իմ պահեստային աշխատանքը, ուստի նրանք պարզապես ասում են, որ ես գործարկել եմ իմ պահեստային տարբերակը, և բոլորը հիանալի հասկանում են միմյանց: Առաջարկում եմ աջակցել այս հրաշալի նախաձեռնությանը։
Համախմբել: Տերմին, որը հայտնվել է ESXi 5.0-ում Պատկերների ընտրացանկի տարբերակ, որը սկսում է այսպես կոչված որբացված լուսանկարների ջնջման գործընթացը: Այսինքն՝ նկարահանումներ, որոնք ֆիզիկապես հասանելի են, բայց դուրս են եկել ցուցադրվող տրամաբանական կառուցվածքից։ Տեսականորեն, այս գործընթացը չպետք է ազդի snapshot manager-ում ցուցադրվող ֆայլերի վրա, սակայն ամեն ինչ կարող է պատահել: Համախմբման գործընթացի էությունն այն է, որ snapshot-ի (երեխայի սկավառակի) տվյալները գրվում են հիմնական (ծնող) սկավառակի վրա: Սկավառակների միաձուլման գործընթացը կոչվում է միաձուլում: Եթե համախմբման հրաման է տրվել, ապա snapshot-ի գրառումը կարող է ջնջվել տվյալների բազայից՝ նախքան snapshot-ի միաձուլումը և ջնջումը: Իսկ եթե ինչ-որ պատճառով չհաջողվեց ջնջել նկարահանված նկարը, ապա հայտնվում են նույն որբացած նկարահանումները։ VMware-ը տեղեկություններ ունի snapshot-ի հետ աշխատելու մասին . Եվ մենք նույնպես ինչ-որ կերպ խոսում ենք նրանց մասին .
Datastore (Stora կամ հարյուրավոր): Շատ լայն հասկացություն, բայց վիրտուալացման աշխարհում այն վերաբերում է այն վայրին, որտեղ պահվում են վիրտուալ մեքենայի ֆայլերը: Բայց ամեն դեպքում, դուք պետք է շատ հստակ հասկանաք ենթատեքստը և, եթե ամենաչնչին կասկած ունեք, պարզաբանեք, թե կոնկրետ ինչ նկատի ուներ ձեր զրուցակիցը։
Վստահված անձ: Կարևոր է անմիջապես հասկանալ, որ Veeam Proxy-ը լրիվ նույնը չէ, ինչին մենք սովոր ենք ինտերնետում: Veeam-ի արտադրանքներում սա որոշակի կազմակերպություն է, որը զբաղվում է տվյալների փոխանցումով մի վայրից մյուսը: Առանց մանրամասների մեջ մտնելու, VBR-ը հրամանի սերվեր է, և վստահված անձինք նրա աշխատուժն են: Այսինքն՝ վստահված անձը մեքենա է, որի միջոցով հոսում է երթևեկությունը և որի վրա տեղադրված են VBR բաղադրիչներ, որոնք օգնում են կառավարել այս տրաֆիկը: Օրինակ, փոխանցեք տվյալներ մի ալիքից մյուսը կամ պարզապես սկավառակներ կցեք ինքներդ ձեզ (HotAdd ռեժիմ):
Պահեստ: Տեխնիկապես սա ընդամենը մուտք է VBR տվյալների բազայում, որը ցույց է տալիս այն վայրը, որտեղ պահվում են կրկնօրինակները և ինչպես միանալ այս վայրին: Փաստորեն, դա կարող է լինել կամ պարզապես CIFS բաժնետոմս կամ առանձին սկավառակ, սերվեր կամ դույլ ամպի մեջ: Կրկին, մենք համատեքստում ենք, բայց մենք հասկանում ենք, որ պահեստը պարզապես այն վայրն է, որտեղ գտնվում են ձեր կրկնօրինակները:
Պատկերապատկեր: Օքսֆորդյան քերականության սիրահարները նախընտրում են ասել, թե ով է ակնթարթ, ով է նկարիչ, բայց անգրագետ մեծամասնությունը հաղթում է ավելի մեծ զանգվածի շնորհիվ։ Եթե որևէ մեկը չգիտի, սա տեխնոլոգիա է, որը թույլ է տալիս վերականգնել սկավառակի վիճակը ժամանակի որոշակի կետում: Սա արվում է կամ ժամանակավորապես վերահղելով I/O գործողությունները հիմնական սկավառակից հեռու, այնուհետև այն կկոչվի RoW (Վերահղում գրելու վրա) լուսանկար, կամ վերագրանցելի բլոկները ձեր սկավառակից մյուսը տեղափոխելով, որը կկոչվի CoW (Պատճենել Գրել) պատկեր. Այս գործառույթների օգտագործման լայն հնարավորությունների շնորհիվ է, որ Veeam-ը կարող է աշխատել իր պահեստային մոգությունը: Խիստ ասած՝ ոչ միայն նրանց համար, այլ սա առաջիկա թողարկումների խնդիր է։
Փաստաթղթերում և ESXi-ի տեղեկամատյաններում այս տերմինի շուրջ քաոս է տիրում, և snapshot-ների հիշատակման համատեքստում կարող եք գտնել ակնոցներ, կրկնել մատյան և նույնիսկ դելտա սկավառակ: Veeam-ի փաստաթղթերում նման տարաձայնություններ չկան, և snapshot-ը լուսանկար է, իսկ Redo log-ը հենց REDO ֆայլ է, որը ստեղծվել է անկախ ոչ մշտական սկավառակի կողմից: REDO ֆայլերը ջնջվում են, երբ վիրտուալ մեքենան անջատված է, այնպես որ դրանք շփոթել նկարների հետ, ձախողման բաղադրատոմս է:
Սինթետիկ: Սինթետիկ կրկնօրինակումները վերաբերում են հակադարձ աճող և ընդմիշտ առաջ կրկնօրինակումներին: Եթե դուք չեք հանդիպել այս տերմինին, դա պարզապես այն մեխանիզմներից մեկն է, որն օգտագործվում է պահեստային շղթայի փոխակերպումը կառուցելու համար: Այնուամենայնիվ, տեղեկամատյաններում կարող եք գտնել նաև Transform-ի հայեցակարգը, որն օգտագործվում է որպես հավելումներից ամբողջական պատճեններ ստեղծելու մաս (սինթետիկ լրիվ):
Առաջադրանք. Սա յուրաքանչյուր առանձին մեքենայի մշակման գործընթաց է աշխատանքի շրջանակներում: Այսինքն՝ դուք ունեք պահեստային աշխատանք, որը ներառում է երեք մեքենա: Սա նշանակում է, որ յուրաքանչյուր մեքենա կմշակվի առանձին առաջադրանքի շրջանակներում: Ընդհանուր առմամբ կլինեն չորս տեղեկամատյաններ՝ հիմնականը աշխատանքի համար և երեքը՝ առաջադրանքների համար: Այնուամենայնիվ, կա մի կարևոր նրբերանգ. ժամանակի ընթացքում «taska» բառը դարձել է չափազանց երկիմաստ: Երբ մենք խոսում ենք ընդհանուր տեղեկամատյանների մասին, նկատի ունենք, որ առաջադրանքը VM է: Բայց և՛ վստահված անձը, և՛ պահեստն ունեն իրենց «առաջադրանքները»: Այնտեղ սա կարող է նշանակել վիրտուալ սկավառակ, վիրտուալ մեքենա կամ ամբողջ աշխատանքը: Այսինքն՝ կարևոր է չկորցնել համատեքստը։
Veeam %name% ծառայություն: Հաջող կրկնօրինակումների օգտին միանգամից մի քանի ծառայություններ են աշխատում, որոնց ցանկը կարելի է գտնել ստանդարտ սարքավորումներում: Նրանց անունները բավականին թափանցիկ են արտացոլում իրենց էությունը, բայց հավասարների մեջ կա ամենագլխավորը՝ Veeam Backup Service, առանց որի մնացածը չի աշխատի։
VSS: Տեխնիկապես VSS-ը միշտ պետք է լինի Microsoft Volume Shadow Copy Service: Իրականում շատերի կողմից օգտագործվում է որպես Application-Aware Image Processing-ի հոմանիշ: Ինչն, իհարկե, կտրականապես կեղծ է, բայց սա պատմություն է «Ցանկացած ամենագնաց կարելի է անվանել ջիպ, և նրանք քեզ կհասկանան» կատեգորիայից։
Ֆանտաստիկ գերաններ և այն վայրերը, որտեղ նրանք ապրում են
Ես ուզում եմ սկսել այս գլուխը՝ բացահայտելով մի մեծ գաղտնիք՝ ժամը քանիսն է ցուցադրված տեղեկամատյաններում:
Հիշեք.
- ESXi-ը միշտ տեղեկամատյաններ է գրում UTC+0-ով:
- vCenter-ը պահում է տեղեկամատյանները՝ հիմնվելով իր ժամային գոտու ժամանակի վրա:
- Veeam-ը պահում է տեղեկամատյանները՝ հիմնվելով այն սերվերի ժամանակի և ժամային գոտու վրա, որի վրա այն տեղադրված է:
- Եվ միայն EVTX ձևաչափով քամու իրադարձությունները չեն տուժում որևէ բանի հետ կապված լինելուց։ Բացելիս ժամանակը վերահաշվարկվում է ըստ այն մեքենայի, որի վրա դրանք բացվել են։ Ամենահարմար տարբերակը, թեև դրա հետ կապված դժվարություններ կան: Միակ նկատելի դժվարությունը տեղանքների տարբերությունն է: Սա գրեթե երաշխավորված ճանապարհ է դեպի անընթեռնելի տեղեկամատյաններ: Այո, կան տարբերակներ, թե ինչպես վարվել սրան, բայց եկեք պարզապես չվիճենք այն փաստի հետ, որ ՏՏ-ում ամեն ինչ աշխատում է անգլերենով և համաձայնվենք սերվերների վրա միշտ սահմանել անգլերենի տեղայնացումը: Օ, խնդրում եմ:
Հիմա եկեք խոսենք այն վայրերի մասին, որտեղ ապրում են գերանները և ինչպես ստանալ դրանք: VBR-ի դեպքում երկու մոտեցում կա.
Առաջին տարբերակը հարմար է, եթե դուք չեք ցանկանում փնտրել ֆայլեր ընդհանուր կույտում, որոնք վերաբերում են հատուկ ձեր խնդրին: Դրա համար մենք ունենք առանձին հրաշագործ, որին կարող եք նշել կոնկրետ աշխատանք և որոշակի ժամանակահատված, որի համար ձեզ անհրաժեշտ են տեղեկամատյաններ: Հաջորդը, նա ինքը կանցնի թղթապանակների միջով և կտեղադրի այն ամենը, ինչ իրեն անհրաժեշտ է մեկ արխիվում: Այն մասին, թե որտեղ փնտրել և ինչպես աշխատել դրա հետ, մանրամասն գրված է .
Այնուամենայնիվ, հրաշագործը չի հավաքում տեղեկամատյանները բոլոր առաջադրանքներից և, օրինակ, եթե դուք պետք է ուսումնասիրեք ռեստորանի տեղեկամատյանները, ձախողումը կամ ձախողումը, ձեր ճանապարհը գտնվում է թղթապանակում: %ProgramData%/Veeam/Backup. Սա VBR մատյանների հիմնական պահեստն է, և %ProgramData%-ը թաքնված թղթապանակ է, և դա լավ է: Ի դեպ, լռելյայն տեղադրությունը կարող է վերանշանակվել՝ օգտագործելով REG_SZ տիպի ռեեստրի բանալի՝ LogDirectory HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication մասնաճյուղում:
Linux մեքենաներում աշխատող գործակալների տեղեկամատյանները պետք է գտնվեն /var/log/VeeamBackup/, եթե օգտագործում եք root կամ sudo հաշիվ: Եթե դուք չունեք նման արտոնություններ, ապա փնտրեք մուտքեր /tmp/VeeamBackup.
Veeam գործակալի համար %OS_name% տեղեկամատյանները պետք է որոնվեն %ProgramData%/Veeam/Endpoint (Կամ %ProgramData%/Veeam/Backup/Endpoint) Եվ /var/log/veeam համապատասխանաբար:
Եթե դուք օգտագործում եք Application-Aware Image Processing (և, ամենայն հավանականությամբ, դուք եք), ապա իրավիճակը որոշ չափով ավելի բարդ է դառնում: Ձեզ անհրաժեշտ կլինեն մեր օգնականների մատյանները, որոնք պահվում են հենց վիրտուալ մեքենայի ներսում, և VSS մատյանները: Ինչպես և որտեղից ստանալ այս երջանկությունը, մանրամասն գրված է . Եվ իհարկե կա հավաքել անհրաժեշտ համակարգի տեղեկամատյանները:
Հարմար է Windows-ի իրադարձությունները հավաքել ըստ . Եթե դուք օգտագործում եք Hyper-V, գործն ավելի բարդ է դառնում, քանի որ ձեզ նույնպես անհրաժեշտ կլինեն դրա բոլոր տեղեկամատյանները՝ Applications and Service Logs > Microsoft > Windows մասնաճյուղից: Չնայած դուք միշտ կարող եք գնալ ավելի հիմար ճանապարհով և պարզապես վերցնել բոլոր օբյեկտները %SystemRoot%System32winevtLogs-ից:
Եթե տեղադրման/թարմացման ժամանակ ինչ-որ բան կոտրվում է, ապա այն ամենը, ինչ ձեզ հարկավոր է, կարող եք գտնել %ProgramData%/Veeam/Setup/Temp պանակում: Թեև ես չեմ թաքցնի այն փաստը, որ դուք կարող եք ավելի օգտակար տեղեկատվություն գտնել ՕՀ-ի իրադարձություններում, քան այս տեղեկամատյաններում: Մնացած հետաքրքիր նյութերը գտնվում են %Temp-ում, բայց հիմնականում կան հարակից ծրագրերի տեղադրման մատյաններ, ինչպիսիք են տվյալների բազան, .Net գրադարանները և այլ բաներ: Խնդրում ենք նկատի ունենալ, որ Veeam-ը տեղադրված է msi-ից, և դրա բոլոր բաղադրիչները տեղադրվում են նաև որպես առանձին msi փաթեթներ, նույնիսկ եթե այն չի ցուցադրվել GUI-ում: Հետևաբար, եթե բաղադրիչներից մեկի տեղադրումը ձախողվի, VBR-ի ամբողջ տեղադրումը կդադարի: Հետևաբար, դուք պետք է գնաք տեղեկամատյաններ և տեսնեք, թե կոնկրետ ինչն է կոտրվել և որ պահին:
Եվ մի վերջին կյանքի հաքեր. եթե տեղադրման ժամանակ սխալ եք ստացել, մի շտապեք սեղմել OK: Նախ վերցնում ենք տեղեկամատյանները, այնուհետև կտտացնում ենք OK: Այս կերպ դուք կստանաք գրանցամատյան, որն ավարտվում է սխալի պահին, վերջում առանց աղբի:
Եվ պատահում է, որ դուք պետք է մտնեք vSphere տեղեկամատյաններ: Դա շատ անշնորհակալ աշխատանք է, բայց երբ թևերդ բարձրացնում ես, պետք է այլ բան անես: Ամենապարզ տարբերակում մեզ անհրաժեշտ կլինեն վիրտուալ մեքենայի իրադարձությունների տեղեկամատյաններ vmware.log, որոնք գտնվում են նրա .vmx ֆայլի կողքին: Ավելի բարդ դեպքում բացեք Google-ը և հարցրեք, թե որտեղ են գտնվում հաղորդավարի ձեր տարբերակի տեղեկամատյանները, քանի որ VMware-ը սիրում է փոխել այս տեղադրությունը թողարկումից մինչև թողարկում: Օրինակ, , բայց համար . vCenter տեղեկամատյանների համար մենք կրկնում ենք ընթացակարգը . Բայց ընդհանուր առմամբ, մեզ կհետաքրքրեն hostd.log-ի իրադարձությունների տեղեկամատյանները, vCenter vpxa.log-ի կողմից կառավարվող հյուրընկալող իրադարձությունները, vmkernel.log միջուկի տեղեկամատյանները և վավերացման տեղեկամատյանները auth.log-ը: Դե, ամենաառաջադեմ դեպքերում SSO տեղեկամատյանը, որը գտնվում է SSO թղթապանակում, կարող է օգտակար լինել:
Ծանրությո՞ւն: Շփոթվե՞լ եք: Վախկոտ? Բայց սա նույնիսկ այն տեղեկատվության կեսը չէ, որով աշխատում է մեր աջակցությունը ամենօրյա ռեժիմով: Այսպիսով, նրանք իսկապես, իսկապես հիանալի են:
Veeam բաղադրիչներ
Եվ այս ներածական հոդվածը եզրափակելու համար եկեք մի փոքր խոսենք Veeam Backup & Replication բաղադրիչների մասին: Որովհետև երբ փնտրում ես ցավի պատճառը, լավ կլինի հասկանալ, թե ինչպես է հիվանդը աշխատում։
Այսպիսով, ինչպես բոլորը հավանաբար գիտեն, Veeam Backup-ը այսպես կոչված SQL-ի վրա հիմնված հավելված է: Այսինքն, բոլոր կարգավորումները, ամբողջ տեղեկատվությունը և, ընդհանրապես, այն ամենը, ինչ անհրաժեշտ է նորմալ գործելու համար, այս ամենը գտնվում է իր տվյալների բազայում: Ավելի ճիշտ՝ երկու տվյալների բազայում, եթե խոսքը VBR-ի և EM-ի համադրության մասին է՝ համապատասխանաբար VeeamBackup և VeeamBackupReporting: Եվ այդպես էլ եղավ՝ մենք տեղադրում ենք մեկ այլ հավելված՝ հայտնվում է մեկ այլ տվյալների բազա։ Որպեսզի բոլոր ձվերը չպահեն մեկ զամբյուղի մեջ։
Բայց որպեսզի այս ամբողջ ձեռնարկությունը սահուն աշխատի, մեզ անհրաժեշտ կլինեն մի շարք ծառայություններ և հավելվածներ, որոնք կմիացնեն բոլոր բաղադրիչները միասին: Պարզապես, օրինակ, իմ լաբորատորիաներից մեկում այսպիսի տեսք ունի.
Գործում է որպես գլխավոր դիրիժոր Veeam Backup Service. Նա է պատասխանատու տվյալների բազաների հետ տեղեկատվության փոխանակման համար։ Նա նաև պատասխանատու է բոլոր առաջադրանքների մեկնարկի, հատկացված ռեսուրսների կազմակերպման և տարբեր կոնսուլների, գործակալների և մնացած ամեն ինչի համար որպես կապի կենտրոն աշխատելու համար: Մի խոսքով, առանց նրա բացարձակապես ճանապարհ չկա, բայց դա ամենևին չի նշանակում, որ նա ամեն ինչ ինքն է անում։
Օգնում է նրան իրականացնել իր ծրագրերը Veeam Backup Manager. Սա ոչ թե ծառայություն է, այլ մի սուբյեկտ, որը գործարկում է աշխատատեղեր և վերահսկում դրանց կատարման ընթացքը։ Պահուստային ծառայության աշխատանքային ձեռքերը, որոնցով այն միանում է հոսթներին, ստեղծում է նկարներ, վերահսկում է պահպանումը և այլն:
Բայց վերադառնանք ծառայությունների ցանկին։ Veeam բրոքերային ծառայություն. Հայտնվել է v9.5-ում (և սա կրիպտո հանքագործ չէ, ինչպես ոմանք կարծում էին այն ժամանակ): Հավաքում է տեղեկատվություն VMware հոսթերի մասին և թարմացնում այն: Բայց անմիջապես մի՛ վազեք գրելու զայրացած մեկնաբանություններ այն մասին, որ մենք լրտեսում ենք ձեզ և ձեր բոլոր մուտքերը/գաղտնաբառերը արտահոսում ենք drag major-ին: Ամեն ինչ մի փոքր ավելի պարզ է. Երբ դուք սկսում եք կրկնօրինակում, առաջին բանը, որ դուք պետք է անեք, միանալն է հոսթին և թարմացնել նրա կառուցվածքի մասին բոլոր տվյալները: Բավականին դանդաղ ու անտանելի պատմություն է: Պարզապես հիշեք, թե որքան ժամանակ է տևում վեբ ինտերֆեյսի միջոցով ձեր մուտքի գործարկումը և հիշեք, որ այնտեղ դիտարկվում է միայն վերին շերտը: Եվ հետո, ի դեպ, դուք դեռ պետք է ընդլայնեք ամբողջ հիերարխիան ճիշտ տեղում: Մի խոսքով սարսափ. Եթե դուք գործարկում եք տասնյակ կրկնօրինակումներ, ապա յուրաքանչյուր աշխատանք պետք է անցնի այս ընթացակարգը: Եթե մենք խոսում ենք խոշոր ենթակառուցվածքների մասին, ապա այս գործընթացը կարող է տևել տասը րոպե կամ ավելի։ Ուստի որոշվել է դրա համար հատկացնել առանձին ծառայություն, որի միջոցով հնարավոր կլինի ստանալ միշտ արդի տեղեկատվություն։ Գործարկման ժամանակ այն ստուգում և սկանավորում է ամբողջ ավելացված ենթակառուցվածքը, այնուհետև փորձում է աշխատել միայն աստիճանական փոփոխությունների մակարդակով: Այսպիսով, նույնիսկ եթե դուք ունեք միաժամանակ գործարկվող հարյուր կրկնօրինակներ, նրանք բոլորը տեղեկատվություն կպահանջեն մեր բրոքերից և չեն տանջի հյուրընկալողներին իրենց խնդրանքներով: Եթե ձեզ անհանգստացնում են ռեսուրսները, ապա մեր հաշվարկներով 5000 վիրտուալ մեքենաների համար անհրաժեշտ է ընդամենը մոտ 100 Մբ հիշողություն։
Հաջորդը մենք ունենք Veeam կոնսոլ. Aka Veeam Remote Console, aka Veeam.Backup.Shell: Սա նույն GUI-ն է, որը մենք տեսնում ենք սքրինշոթերում: Ամեն ինչ պարզ է և ակնհայտ. կոնսոլը կարող է գործարկվել ցանկացած վայրից, քանի դեռ այն Windows է և կապ կա VBR սերվերի հետ: Միակ բանը, որ կարելի է ասել, այն է, որ FLR պրոցեսը միավորները տեղադրելու է տեղում (այսինքն այն մեքենայի վրա, որտեղ աշխատում է վահանակը): Դե, տարբեր Veeam Explorer-ներ նույնպես կաշխատեն լոկալ, քանի որ դրանք կոնսոլի մի մասն են: Բայց սա արդեն ինձ տարել է վայրի բնություն...
Հաջորդ հետաքրքիր ծառայությունն է Veeam Backup Catalog Data Service. Ծառայությունների ցանկում այն հայտնի է որպես Veeam Guest Catalog Service: Նա զբաղվում է հյուրերի մեքենաների ֆայլային համակարգերի ինդեքսավորմամբ և այս գիտելիքներով լրացնում է VBRCatalog թղթապանակը։ Օգտագործվում է միայն այն դեպքում, երբ ինդեքսավորման վանդակը միացված է: Եվ իմաստ ունի միայն այն միացնել, եթե ունեք Enterprise Manager: Հետևաբար, իմ սրտի խորքից խորհուրդ. մի՛ միացրեք ինդեքսավորումը հենց այնպես, եթե չունեք EM: Խնայեք ձեր նյարդերը և աջակցեք ժամանակը:
Հատկանշական է նաև այլ կարևոր ծառայություններից Veeam Installer Service, որի օգնությամբ մատակարարվում և տեղադրվում են անհրաժեշտ բաղադրիչները պրոքսիների, պահեստների և այլ դարպասների վրա։ Փաստորեն, նա մատակարարում է անհրաժեշտ .msi փաթեթները սերվերներին և տեղադրում դրանք։
Veeam Data Mover — վստահված անձանց վրա գործարկված օժանդակ գործակալների օգնությամբ (և ոչ միայն) այն փոխանցում է տվյալներ։ Օրինակ, կրկնօրինակման ժամանակ մեկ գործակալը կկարդա ֆայլերը հյուրընկալող տվյալների շտեմարանից, իսկ երկրորդը զգուշորեն կգրի դրանք կրկնօրինակում:
Առանձին-առանձին, ես կցանկանայի նշել մի կարևոր բան, որին հաճախորդները հաճախ արձագանքում են՝ Ծառայությունների և տեղեկատվության տարբերակների տարբերությունը Ծրագրերի և Հատկությունների ներդիրում: Այո, ցուցակը նույնն է լինելու, բայց տարբերակները կարող են լիովին անհամապատասխան լինել: Սա շատ լավ չէ տեսողական տեսանկյունից, բայց դա լիովին նորմալ է, եթե ամեն ինչ կայուն է աշխատում: Օրինակ, Installer ծառայության տարբերակի համարը զգալիորեն զիջում է իր հարեւաններին: Սարսափ և մղձավանջ. Ոչ, քանի որ այն ամբողջությամբ չի վերատեղադրված, բայց դրա DLL-ը պարզապես թարմացվում է: v9.5 U4 պատչում տեղի ունեցավ տեխնիկական աջակցության մղձավանջ՝ թարմացման ընթացքում բոլոր ծառայությունները ստացան նոր տարբերակներ, բացառությամբ ամենակարևորից։ U4b կարկատանում տրանսպորտային ծառայությունը բոլորից առաջ էր երկու տարբերակով (դատելով թվերից): Եվ սա նույնպես նորմալ է. դրա մեջ հայտնաբերվել է լուրջ սխալ, ուստի այն ստացել է բոնուսային թարմացում մյուսների համեմատ: Այսպիսով, ամփոփելու համար. տարբերակների տարբերությունները ԿԱՐՈՂ են խնդիր լինել, բայց եթե կա տարբերություն և ամեն ինչ ճիշտ է աշխատում, ապա, ամենայն հավանականությամբ, այդպես էլ պետք է լինի: Բայց ոչ ոք ձեզ չի արգելում դա պարզաբանել տեխնիկական աջակցությամբ։
Դրանք այսպես կոչված պարտադիր կամ Պարտադիր ծառայություններն էին։ Եվ կա օժանդակների մի ամբողջ փաթեթ, ինչպիսիք են Tape Service, Mount Service, vPowerNFS Service և այլն:
Hyper-V-ի համար ընդհանրապես ամեն ինչ նույնն է, միայն կա կոնկրետ Veeam Backup Hyper-V ինտեգրման ծառայություն և սեփական վարորդը CBT-ի հետ աշխատելու համար:
Եվ վերջում մենք կխոսենք այն մասին, թե ով է աշխատում վիրտուալ մեքենաների վրա պահուստավորման ժամանակ: Այն օգտագործվում է նախնական և հետսառեցման սկրիպտներ գործարկելու, ստվերային պատճեններ ստեղծելու, մետատվյալներ հավաքելու, SQL գործարքների տեղեկամատյանների հետ աշխատելու և այլն: Veeam Հյուրերի օգնական. Եվ եթե ֆայլային համակարգերը ինդեքսավորվեն, Veeam Հյուրերի ինդեքսատոր . Սրանք ժամանակավոր ծառայություններ են, որոնք տեղադրվում են պահուստավորման ընթացքում և ջնջվում դրանից հետո:
Linux-ի մեքենաների դեպքում ամեն ինչ շատ ավելի պարզ է՝ շնորհիվ մեծ թվով ներկառուցված գրադարանների առկայության և հենց համակարգի հնարավորությունների։ Օրինակ, ինդեքսավորումը կատարվում է mlocate-ի միջոցով։
Առայժմ այսքանը
Էլ չեմ համարձակվում քեզ տանջել ու կարճ Veeam շարժիչի հատվածի ներդրումը համարում եմ ավարտված: Այո, մենք նույնիսկ չենք մոտեցել տեղեկամատյաններին, բայց հավատացեք ինձ, որպեսզի դրանցում ներկայացված տեղեկատվությունը չթվա որպես գիտակցության անհամապատասխան հոսք, նման ներածություն բացարձակապես անհրաժեշտ է: Ես նախատեսում եմ անցնել հենց տեղեկամատյաններին միայն երրորդ հոդվածում, իսկ հաջորդի պլանն է բացատրել, թե ով է ստեղծում տեղեկամատյանները, կոնկրետ ինչ է ցուցադրվում դրանցում և ինչու հենց այս ձևով և ոչ այլ կերպ:
Source: www.habr.com