Veeam Log Dalış Komponentləri və Sözlük

Veeam Log Dalış Komponentləri və Sözlük

Biz Veeam-də qeydləri sevirik. Həlllərimizin əksəriyyəti modul olduğundan, onlar çoxlu loglar yazır. Fəaliyyətimizin əhatə dairəsi məlumatlarınızın təhlükəsizliyini təmin etmək olduğundan (yəni, rahat yuxu), o zaman qeydlər yalnız hər asqırmağı qeyd etməməli, həm də bəzi təfərrüatlarla etməlidir. Bu, ona görə lazımdır ki, hər hansı bir hadisə baş verdikdə, bunun necə baş verdiyi, kimin günahkar olduğu və bundan sonra nə etmək lazım olduğu aydın olsun. Bu, məhkəmə tibbində olduğu kimidir: Laura Palmerin qatilini tapmağa hansı kiçik şeyin kömək edəcəyini heç vaxt bilmirsən.

Buna görə də, loglara nə yazdığımız, onları harada saxladığımız, quruluşu ilə necə dəli olmamaq və içərisində nə axtarmaq lazım olduğu barədə ardıcıl olaraq danışacağım bir sıra məqalələrə diqqət yetirməyə qərar verdim.

Niyə bir sıra məqalələr və niyə hər şeyi bir anda təsvir etmirsiniz?

Sadəcə olaraq hansı logun harada olduğunu və orada nəyin saxlandığını sadalamaq kifayət qədər fəlakətli bir işdir. Və bu məlumatı aktual saxlamaq barədə düşünmək belə qorxuncdur. Veeam Backup & Replication proqramında bütün mümkün jurnal növlərinin sadə siyahısı kiçik çapda bir neçə vərəqdə olan cədvəldir. Bəli və yalnız nəşr zamanı aktual olacaq, çünki. növbəti yamaq buraxıldıqda yeni loglar görünə bilər, köhnələrində saxlanılan məlumatların məntiqi dəyişəcək və s. Buna görə də, onların strukturunu və onlarda olan məlumatların mahiyyətini izah etmək daha sərfəli olacaqdır. Bu, adların banal sıxılmasından daha yaxşı yerləri gəzməyə imkan verəcəkdir.

Buna görə də, mətn vərəqləri hovuzuna tələsməmək üçün bu məqalədə bəzi hazırlıq işləri aparaq. Buna görə də, bu gün biz logların özlərinə girməyəcəyik, ancaq uzaqdan gedəcəyik: bir lüğət tərtib edəcəyik və Veeam strukturunu logların yaradılması baxımından bir az müzakirə edəcəyik.

Lüğət və jarqon

Burada, ilk növbədə, rus dilinin təmizliyi uğrunda mübarizə aparanlardan və Ozhegovun lüğətinin şahidlərindən üzr istəməyə dəyər. Biz hamımız öz ana dilimizi çox sevirik, amma lənətə gəlmiş İT sənayesi ingilis dilində işləyir. Bəli, biz bunu düşünməmişik, amma bu, tarixən baş verib. Bu mənim günahım deyil, özü gəldi (c)

Bizim işimizdə anglicisms (və jarqon) probleminin özünəməxsus xüsusiyyətləri var. “Ev sahibi” və ya “qonaq” kimi məsum sözlər altında bütün dünya çoxdan çox konkret şeyləri başa düşdükdə, o zaman torpağın ⅙ hissəsində qəhrəmancasına çaşqınlıq və lüğətlərə girmək ilə məəttəllik davam edir. Və ciddi məcburi arqument "Ancaq bizim işimizdə ...".

Üstəlik, bəzi sözlər və ifadələr insanlara keçsə də, Veeam məhsullarına xas olan sırf bizim terminologiyamız var. Buna görə də, indi hansı terminin nə demək olduğunu razılaşdıracağıq və gələcəkdə "qonaq" sözü altında mən işdə öyrəşdiyinizi deyil, məhz bu fəsildə yazılanları nəzərdə tutacağam. Bəli, bu mənim şəxsi şıltaqlığım deyil, bunlar sənayedə köklü terminlərdir. Onlarla mübarizə aparmaq bir qədər mənasızdır. Baxmayaraq ki, mən həmişə şərhlərdə soyuqqanlı olmağın tərəfdarıyam.

Təəssüf ki, işimizdə və məhsullarımızda çoxlu terminlər var, ona görə də hamısını sadalamağa çalışmayacağam. Dənizdə yaşamaq üçün ehtiyat nüsxələri və loglar haqqında yalnız ən əsas və zəruri məlumatlar. Maraqlananlar üçün mən də edə bilərəm məqalə təklif edin lentlər haqqında həmkarları, burada o, funksionallığın həmin hissəsi ilə bağlı terminlərin siyahısını da verdi.

Ev sahibi (ev sahibi): Virtuallaşdırma dünyasında bu, hipervizoru olan bir maşındır. Fiziki, virtual, bulud - fərqi yoxdur. Əgər bir şey hipervizorla işləyirsə (ESXi, Hyper-V, KVM və s.), onda bu "nəsə" host adlanır. İstər on raflı bir klaster, istərsə də bir yarım virtual maşın üçün laboratoriyası olan noutbukunuz olsun - hipervizoru işə salsanız, ev sahibi oldunuz. Çünki hipervizor virtual maşınları yerləşdirir. Hətta belə bir hekayə var ki, VMware bir vaxtlar host sözünün ESXi ilə möhkəm birləşməsinə nail olmaq istəyirdi. Amma o etmədi.

Müasir dünyada “host” anlayışı praktiki olaraq “server” anlayışı ilə birləşib ki, bu da kommunikasiyaya müəyyən çaşqınlıq gətirir, xüsusən də söhbət Windows infrastrukturundan gedir. Beləliklə, bizi maraqlandıran bəzi xidmətlərə ev sahibliyi edən hər hansı bir maşın təhlükəsiz olaraq host adlandırıla bilər. Məsələn, WinSock qeydlərində hər şey host sözü ilə qeyd olunur. Klassik "Host tapılmadı" buna misaldır. Beləliklə, biz kontekstdən başlayırıq, amma unutmayın - virtualizasiya dünyasında qonaqları qəbul edən ev sahibidir (bu barədə daha çox aşağıda iki sətirdə).

Yerli jarqondan (bu halda hətta qısaltmalar da) burada xatırladılır ki, VMware VI, vSphere VC, Hyper-V isə HV-dir.

Qonaq (Qonaq): Host üzərində işləyən virtual maşın. Burada izah ediləcək bir şey yoxdur, hər şey çox məntiqli və sadədir. Ancaq bir çoxları səylə başqa mənaları buraya sürükləyirlər.

Nə üçün? Mən bilmirəm.
Qonaq OS, müvafiq olaraq, qonaq maşınının əməliyyat sistemi. Və s.

Yedəkləmə/Replikasiya İşi (iş A): Bəzi vəzifələri ifadə edən təmiz Wim jarqonu. Yedəkləmə işi == Yedəkləmə işi. Heç kim onu ​​rus dilinə necə gözəl tərcümə edəcəyini başa düşməyib, ona görə də hamı “JobA” deyir. Son hecaya vurğu ilə.

Bəli, sadəcə götürüb “joba” deyirlər. Hətta məktublarda belə yazırlar, hər şey qaydasındadır.
Hər cür Yedəkləmə işləri, Yedəkləmə Tapşırıqları və s., təşəkkürlər, lakin ehtiyac yoxdur. Sadəcə bir iş, və səni başa düşəcəksən. Əsas odur ki, vurğunu sonuncu hecaya qoyun.

Yedəkləmə (Yedəkləmə, ehtiyat nüsxə nüsxə nüsxə nüsxə nüsxə nüsxə nüsxəsi. Əsl köhnəlmişlər üçün ehtiyat nüsxəyə icazə verilir): Aşkar olana əlavə olaraq (bir yerdə yatan məlumatların ehtiyat nüsxəsi), bu da işin özü deməkdir (yuxarıda üç sətir, əgər artıq unutmusunuzsa), nəticədə çox ehtiyat faylı görünür. Yəqin ki, ingilis dilində danışan cənablar hər dəfə ehtiyat işimlə məşğul olduğumu söyləmək üçün çox tənbəldirlər, ona görə də sadəcə olaraq deyirlər ki, ehtiyat nüsxəmi işləmişəm və hamı bir-birini mükəmməl başa düşür. Sizi bu gözəl təşəbbüsü dəstəkləməyə dəvət edirəm.

Konsolidasiya (konsolidasiya): ESXi 5.0-da görünən termin. Snapshot menyusunda, yetim qalmış şəkillərin silinməsi prosesini başlatan seçim. Yəni fiziki olaraq mövcud olan, lakin göstərilən məntiqi strukturdan kənara çıxan anlıq görüntülər. Teorik olaraq, bu proses snapshot menecerində göstərilən fayllara təsir etməməlidir, lakin hər şey ola bilər. Konsolidasiya prosesinin mahiyyəti ondan ibarətdir ki, snapshotdan (alt disk) verilənlər əsas (ana) diskə yazılır. Disklərin birləşdirilməsi prosesi birləşmə adlanır. Əgər konsolidasiya əmri verilmişdirsə, o zaman snapshot birləşdirilmədən və silinməzdən əvvəl snapshot qeydi verilənlər bazasından silinə bilər. Və hər hansı bir səbəbdən snapshot silinə bilmirsə, o zaman bu eyni yetim snapshotlar görünür. Snapshotlarla işləmək haqqında VMware var yaxşı KB. Biz də bir növ onlar haqqında Habré-də yazdı.

Məlumat anbarı (Stora və ya yaddaş):  Çox geniş bir anlayışdır, lakin virtuallaşdırma dünyasında virtual maşın fayllarının saxlandığı yer kimi başa düşülür. Ancaq hər halda, burada konteksti çox aydın başa düşməli və ən kiçik bir şübhə ilə həmsöhbətinizin nəyi nəzərdə tutduğunu aydınlaşdırmalısınız. 

Proksi (Proksi): Dərhal başa düşmək vacibdir ki, Veeam Proxy bizim İnternetdə istifadə etdiyimiz proqramla tamamilə eyni deyil. Veeam məhsulları daxilində bu, məlumatların bir yerdən digərinə ötürülməsi ilə məşğul olan bir növ qurumdur. Əgər təfərrüatlara girməsəniz, VBR əmr və idarəetmə serveridir, proksilər isə onun işçi qüvvəsidir. Yəni, proxy, trafikin axdığı və bu trafiki idarə etməyə kömək edən VBR komponentlərinin quraşdırıldığı bir maşındır. Məsələn, məlumatları bir kanaldan digərinə ötürmək və ya sadəcə diskləri özünə yapışdırmaq (HotAdd rejimi).

Repozitoriya (Repository):  Texniki cəhətdən bu, VBR verilənlər bazasında ehtiyat nüsxələrin saxlandığı yeri və bu yerə necə qoşulacağını göstərən bir girişdir. Əslində, bu, ya sadəcə bir CIFS topu, ya da buludda ayrıca disk, server və ya vedrə ola bilər. Yenə də biz kontekstdəyik, lakin anlayırıq ki, anbar sadəcə ehtiyat nüsxələrinizin olduğu yerdir.

 Snapshot (SnapshOt): Oksford qrammatika həvəskarları kimin snapshot və kimin snapshot olduğunu söyləməyə üstünlük verirlər, lakin savadsız əksəriyyət daha böyük kütlədən faydalanır. Hər kəs bilmirsə, bu, müəyyən bir zamanda diskin vəziyyətini bərpa etməyə imkan verən bir texnologiyadır. Bu, ya giriş/çıxış əməliyyatlarını müvəqqəti olaraq əsas diskdən uzaqlaşdırmaqla həyata keçirilir - sonra o, RoW (Yazıda Yönləndirmə) snapshot adlanacaq - və ya yenidən yazıla bilən blokları diskinizdən digərinə köçürməklə - bu CoW (Copy on Write) adlanacaq. ) şəkil. Məhz bu funksiyalardan istifadə etmək üçün geniş imkanlar sayəsində Veeam öz ehtiyat sehrini işlədə bilər. Düzünü desək, təkcə onların deyil, bu, növbəti buraxılışların məsələsidir.

ESXi sənədlərində və qeydlərində bu termin ətrafında xaos var və anlıq görüntüləri qeyd etmək kontekstində siz anlıq görüntülərin özlərini, redo log və hətta delta diskini tapa bilərsiniz. Veeam sənədlərində belə cırılma yoxdur və snapshot snapshot, redo log isə tam olaraq müstəqil qeyri-davamlı disk tərəfindən yaradılmış REDO faylıdır. REDO faylları virtual maşın söndürüldükdə silinir, ona görə də onları anlıq görüntülərlə qarışdırmaq uğursuzluğa aparan yoldur.

Sintetik (sintetik): Sintetik ehtiyat nüsxələri tərs artımlı və əbədi irəliyə doğru ehtiyat nüsxələridir. Bu terminə rast gəlmədiyiniz halda, bu, ehtiyat zənciri çevrilməsi yaratmaq üçün istifadə edilən mexanizmlərdən yalnız biridir. Bununla birlikdə, qeydlərdə artımlardan (sintetik dolu) tam nüsxələrin yaradılması çərçivəsində istifadə olunan Transform konsepsiyasını da tapa bilərsiniz.

Tapşırıq (tapşırıq): Bu, iş daxilində hər bir fərdi maşının işlənməsi prosesidir. Yəni: üç maşından ibarət ehtiyat işiniz var. Bu o deməkdir ki, hər bir avtomobil ayrıca tapşırığın bir hissəsi kimi işlənəcək. Ümumilikdə dörd jurnal olacaq: əsas iş üçün, üçü isə tapşırıqlar üçün. Lakin burada mühüm bir nüans var: zaman keçdikcə “tapşırıq” sözü lazımsız yerə birmənalı deyil. Ümumi qeydlər haqqında danışarkən, bir tapşırığın tam olaraq VM olduğunu nəzərdə tuturuq. Ancaq həm proxy, həm də depoda "tapşırıqlar" var. Orada virtual disk, virtual maşın və bütün işi ifadə edə bilər. Yəni konteksti itirməmək vacibdir.

Veeam %name% Xidməti:  Uğurlu ehtiyat nüsxələrinin faydası üçün bir neçə xidmət eyni anda işləyir, onların siyahısını standart avadanlıqda tapa bilərsiniz. Onların adları onların mahiyyətini olduqca şəffaf şəkildə əks etdirir, lakin bərabərləri arasında ən vacibi də var - Veeam Backup Service, onsuz qalanları işləməyəcək.

VSS: Texniki cəhətdən VSS həmişə Microsoft Volume Shadow Copy Service üçün dayanmalıdır. Əslində, bir çoxları tərəfindən Tətbiqdən xəbərdar olan Şəkil Emalının sinonimi kimi istifadə olunur. Bu, əlbəttə ki, tamamilə səhvdir, lakin bu, "İstənilən SUV-ni cip adlandırmaq olar və sizi başa düşəcəksiniz" kateqoriyasından bir hekayədir.

Fantastik loglar və onların yaşadığı yer

Mən bu fəsli böyük sirri açmaqla başlamaq istəyirəm - jurnallarda saat neçədə göstərilir?

Unutmayın:

  • ESXi həmişə UTC+0-da qeydlər yazır.
  • vCenter öz vaxt qurşağının vaxtına uyğun olaraq qeydləri saxlayır.
  • Veeam işlədiyi serverin vaxtına və saat qurşağına görə qeydləri saxlayır.
  • Və yalnız EVTX formatında olan Windows hadisələri heç bir şeyə bağlanmaqdan əziyyət çəkmir. Açıldıqda, açıldıqları avtomobil üçün vaxt yenidən hesablanır. Bununla bağlı çətinliklər olsa da, ən əlverişli seçimdir. Yeganə nəzərəçarpacaq çətinlik yerli fərqlərdir. Bu, oxunmayan qeydlərə praktiki olaraq zəmanətli bir yoldur. Bəli, buna necə yanaşmağın variantları var, amma gəlin İT-də hər şeyin ingilis dilində işləməsi ilə mübahisə etməyək və serverlərdə həmişə ingilis dilini təyin etməyə razılaşaq. Oh, xahiş edirəm. 

İndi logların yaşadığı yerlər və onları necə əldə etmək barədə danışaq. VBR vəziyyətində iki yanaşma var. 

Birinci seçim, probleminizlə əlaqəli olan ümumi yığındakı faylları axtarmaq istəmirsinizsə uyğun gəlir. Bunu etmək üçün ayrı bir sehrbazımız var, ona xüsusi bir işi və qeydlərə ehtiyacınız olan müəyyən bir dövrü təyin edə bilərsiniz. Sonra özü qovluqları keçəcək və sizə lazım olan hər şeyi bir arxivə yığacaq. Onu harada axtarmaq və onunla necə işləmək ətraflı təsvir edilmişdir bu HF.

Bununla belə, sehrbaz bütün tapşırıqların qeydlərini toplamır və məsələn, bərpa, uğursuzluq və ya uğursuzluq qeydlərini öyrənmək lazımdırsa, yolunuz qovluqdadır. %ProgramData%/Veeam/Yedəkləmə. Bu, əsas VBR loqo mağazasıdır və %ProgramData% gizli qovluqdur və bu, yaxşıdır. Yeri gəlmişkən, defolt yeri HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Yedəkləmə və Replikasiya filialında REG_SZ: LogDirectory tipli qeyd açarından istifadə etməklə yenidən təyin etmək olar.

Linux maşınlarında işçi agent qeydləri / ünvanında axtarılmalıdır.var/log/VeeamBackup/kök və ya sudo hesabından istifadə edirsinizsə. Əgər belə imtiyazlarınız yoxdursa, daxil olun /tmp/VeeamBackup

%OS_name% üçün Veeam agenti üçün jurnallarda axtarış aparılmalıdır %ProgramData%/Veeam/Endpoint (Və ya %ProgramData%/Veeam/Backup/Endpoint) Və /var/log/veeam müvafiq.

Tətbiqdən xəbərdar olan şəkil emalından istifadə edirsinizsə (və çox güman ki, siz də), onda vəziyyət bir qədər mürəkkəbləşir. Sizə virtual maşının özündə saxlanılan köməkçimizin qeydləri və VSS qeydləri lazımdır. Bu xoşbəxtliyi necə və haradan əldə etmək barədə ətraflı yazılmışdır Bu məqalə. Və əlbəttə var ayrı məqalə lazımi sistem qeydlərini toplamaq. 

Windows hadisələri uyğun olaraq rahat şəkildə toplanır bu HF. Hyper-V istifadə edirsinizsə, işlər daha da mürəkkəbləşir, çünki onun bütün qeydlərinə Proqramlar və Xidmət Qeydləri > Microsoft > Windows bölməsindən də ehtiyacınız olacaq. Baxmayaraq ki, siz həmişə daha axmaq yolla gedə və sadəcə %SystemRoot%System32winevtLogs-dan bütün obyektləri götürə bilərsiniz.

Quraşdırma/təkmilləşdirmə zamanı nəsə xarab olarsa, sizə lazım olan hər şeyi %ProgramData%/Veeam/Setup/Temp qovluğunda tapa bilərsiniz. Gizlətməyəcəyəm ki, OS hadisələrində bu qeydlərdən daha faydalı məlumat tapa bilərsiniz. Qalan maraqlı şeylər %Temp%-də yerləşir, lakin əsas, .Net kitabxanaları və digər şeylər kimi əlaqəli proqram təminatı üçün quraşdırma qeydləri var. Qeyd edək ki, Veeam msi-dən quraşdırılıb və onun bütün komponentləri GUI-də göstərilməsə belə, ayrıca msi paketləri kimi quraşdırılıb. Buna görə də, komponentlərdən birinin quraşdırılması uğursuz olarsa, bütün VBR quraşdırılması dayandırılacaq. Buna görə də, loglara girməlisiniz və nəyin tam olaraq pozulduğunu və hansı nöqtədə olduğunu görməlisiniz.

Və nəhayət, həyat hiyləsi: quraşdırma zamanı xəta alsanız, OK düyməsini sıxmağa tələsməyin. Əvvəlcə qeydləri götürürük, sonra OK düyməsini sıxırıq. Bu yolla, sonunda zibil olmadan, səhv zamanı bitən bir jurnal alacaqsınız.

Və belə olur ki, vSphere qeydlərinə daxil olmalısınız. İşğal çox nankordur, amma qolları çırmalayıb başqa bir şey etmək lazımdır. Ən sadə versiyada, .vmx faylının yanında yerləşən vmware.log virtual maşın hadisələri ilə qeydlərə ehtiyacımız var. Daha çətin vəziyyətdə, Google-u açın və host versiyanızın qeydlərinin harada yerləşdiyini soruşun, çünki VMware bu yeri buraxılışdan buraxılışa dəyişməyi sevir. Misal üçün, 7.0 üçün məqalə, lakin üçün 5.5. vCenter qeydləri üçün proseduru təkrarlayın googling. Lakin ümumilikdə bizi hostd.log hadisə qeydləri, vCenter vpxa.log tərəfindən idarə olunan host hadisələri, vmkernel.log nüvə qeydləri və auth.log autentifikasiya qeydləri maraqlandıracaq. Yaxşı, ən çox diqqətdən kənarda qalan hallarda, SSO qovluğunda olan SSO jurnalı faydalı ola bilər.

Çətin? Qarışıq? Qorxulu? Ancaq bu, dəstəyimizin gündəlik işlədiyi məlumatların yarısı belə deyil. Beləliklə, onlar həqiqətən çox gözəldirlər.

Veeam Komponentləri

Və bu giriş məqaləsinin yekunu olaraq, Veeam Backup & Replication komponentləri haqqında bir az danışaq. Çünki ağrının səbəbini axtararkən xəstənin necə işlədiyini başa düşmək yaxşı olardı.

Beləliklə, yəqin ki, hər kəsin bildiyi kimi, Veeam Backup SQL əsaslı bir proqramdır. Yəni, bütün parametrlər, bütün məlumatlar və ümumiyyətlə, yalnız normal işləmək üçün lazım olan hər şey - bütün bunlar onun məlumat bazasındadır. Daha doğrusu, iki verilənlər bazasında, əgər söhbət bir dəstə VBR və EM-dən gedirsə: müvafiq olaraq VeeamBackup və VeeamBackupReporting. Və belə oldu: başqa bir proqram qoyduq - başqa bir verilənlər bazası görünür. Bütün yumurtaları bir səbətdə saxlamamaq üçün.

Lakin bütün bu iqtisadiyyatın rəvan işləməsi üçün bizə bütün komponentləri birləşdirəcək bir sıra xidmətlər və proqramlar lazımdır. Məsələn, laboratoriyalarımdan birində belə görünür:

Veeam Log Dalış Komponentləri və Sözlük
Baş dirijor kimi fəaliyyət göstərir Veeam Yedəkləmə Xidməti. Bazalarla məlumat mübadiləsinə cavabdeh olan odur. O, həmçinin bütün tapşırıqların icrasına, ayrılmış resursların təşkilinə və müxtəlif konsollar, agentlər və hər şey üçün bir növ rabitə mərkəzi kimi işləməyə cavabdehdir. Bir sözlə, onsuz heç bir yol yoxdur, amma bu, heç də o demək deyil ki, o, hər şeyi özü edir.

Planlarının həyata keçirilməsində ona kömək edir Veeam Backup Manager. Bu, xidmət deyil, iş yerlərini işə salan və onların icrası prosesinə nəzarət edən bir qurumdur. Yedəkləmə xidmətinin hostlara qoşulduğu iş əlləri, anlıq görüntülər yaradır, saxlanmaya nəzarət edir və s.

Ancaq xidmətlər siyahısına qayıdaq. Veeam Broker Xidməti. v9.5-də ortaya çıxdı (və bu, bəzilərinin düşündüyü kimi kriptovalyutası deyil). VMware hostları haqqında məlumat toplayır və onun aktuallığını qoruyur. Ancaq sizə casusluq etdiyimiz və bütün girişləri / parolları taschmajor-a sızdırdığımız barədə qəzəbli şərhlər yazmağa dərhal qaçmayın. Hər şey bir qədər sadədir. Bir ehtiyat nüsxəsini işə saldığınız zaman etməli olduğunuz ilk şey hosta qoşulmaq və onun strukturu ilə bağlı bütün məlumatları yeniləməkdir. Bu, olduqca yavaş və çətin bir hekayədir. Yalnız veb-interfeys vasitəsilə daxil olmağın nə qədər vaxt apardığını xatırlayın və orada yalnız üst təbəqənin hesablandığını unutmayın. Və sonra, yeri gəlmişkən, bütün iyerarxiyanı lazımi yerə açmalısınız. Bir sözlə dəhşət. Bir çox ehtiyat nüsxəsini işlədirsinizsə, hər bir iş bu proseduru yerinə yetirməlidir. Söhbət böyük infrastrukturlardan gedirsə, onda bu proses on dəqiqə və ya daha çox çəkə bilər. Buna görə də bunun üçün ayrıca bir xidmətin ayrılması qərara alındı ​​ki, onun vasitəsilə daim aktual məlumat almaq mümkün olacaq. Başlanğıcda o, bütün əlavə edilmiş infrastrukturu yoxlayır və skan edir, sonra isə yalnız artımlı dəyişikliklər səviyyəsində işləməyə çalışır. Beləliklə, eyni anda yüzlərlə ehtiyat nüsxəsini işlətsəniz belə, hamısı brokerimizdən məlumat tələb edəcək və ev sahiblərini sorğuları ilə incitməyəcəklər. Əgər siz resurslardan narahatsınızsa, o zaman hesablamalarımıza görə, 5000 virtual maşına cəmi 100 Mb yaddaş lazımdır.

Növbəti bizdə Veeam Konsolu. O, Veeam Remote Console, o, Veeam.Backup.Shell. Bu, ekran görüntülərində gördüyümüz eyni GUI-dir. Hər şey sadə və aydındır – konsol istənilən yerdən işə salına bilər, o şərtlə ki, o, Windows-dur və VBR serverinə əlaqə mövcuddur. Deyə biləcəyimiz yeganə şey, FLR prosesinin nöqtələri yerli olaraq quraşdıracağıdır (yəni konsolun işlədiyi maşında). Yaxşı, müxtəlif Veeam Explorers yerli olaraq da işləyəcək, çünki onlar konsolun bir hissəsidir. Amma o, məni artıq çöllərə aparıb...

Digər maraqlı xidmətdir Veeam Backup Catalog Data Service. Xidmətlər siyahısında Veeam Qonaq Kataloq Xidməti kimi tanınır. O, qonaq maşınlarında fayl sistemlərinin indeksləşdirilməsi ilə məşğul olur və bu biliklərlə VBRCatalog qovluğunu doldurur. O, yalnız indeksləşdirmə qutusu aktiv olduqda istifadə olunur. Və yalnız Müəssisə Meneceriniz varsa, onu aktivləşdirməyin mənası var. Buna görə də, ürəyimin altından məsləhət: EAT yoxdursa, indeksləşdirməni belə açmayın. Əsəblərinizə və dəstək vaxtınıza qənaət edin.

Digər mühüm xidmətlərdən də qeyd etməyə dəyər Veeam Quraşdırıcı Xidməti, onun köməyi ilə lazımi komponentlər çatdırılır və proksilərə, depolara və digər şlüzlərə quraşdırılır. Əslində o, lazımi .msi paketlərini serverlərə aparır və quraşdırır. 

Veeam Data Mover - proksilərdə işə salınan köməkçi agentlərin köməyi ilə (yalnız deyil) məlumatların dəyişdirilməsi ilə məşğul olur. Məsələn, ehtiyat nüsxəsini çıxararkən, bir agent host məlumat anbarından faylları oxuyacaq, ikincisi onları ehtiyatla ehtiyat nüsxəyə yazacaq.

Müştərilərin tez-tez reaksiya verdikləri vacib bir şeyi ayrıca qeyd etmək istərdim - bu, Proqramlar və Xüsusiyyətlər snap-inindəki xidmətlərin və məlumatların versiyalarında fərqdir. Bəli, siyahı eyni olacaq, lakin versiyalar tamamilə uyğunsuz ola bilər. Vizual nöqteyi-nəzərdən çox sərin deyil, amma hər şey stabil işləyirsə, bu tamamilə normaldır. Məsələn, Quraşdırıcı xidməti üçün versiya nömrəsi qonşu olanlardan çox geridədir. Dəhşət və kabus? Xeyr, çünki o, tamamilə yenidən quraşdırılmayıb, lakin onun DLL sadəcə yenilənir. v9.5 U4 patch-də texniki dəstək kabusu baş verdi: yeniləmə zamanı ən vacibi istisna olmaqla, bütün xidmətlər yeni versiyalar aldı. U4b yamasında nəqliyyat xidməti bütün digərlərini iki versiyaya qədər üstələdi (rəqəmlərə görə). Və bu da normaldır - onda ciddi bir səhv tapıldı, buna görə qalanlara nisbətən bonus yeniləməsi aldı. Xülasə etmək üçün: versiya fərqləri problem ola bilər, amma fərq varsa və hər şey düzgün işləyirsə, yəqin ki, olmalıdır. Ancaq texniki dəstəkdə bunu dəqiqləşdirməyi heç kim sizə qadağan etmir.

Bunlar məcburi və ya məcburi xidmətlər idi. Tape Service, Mount Service, vPowerNFS Service və s. kimi bir sıra köməkçi vasitələr var.

Hyper-V üçün, ümumiyyətlə, hər şey eynidir, yalnız bir spesifik var Veeam Backup Hyper-V İnteqrasiya Xidməti və CBT ilə işləmək üçün öz sürücünüz.

Və sonda, ehtiyat nüsxə zamanı virtual maşınlarda kimin işlədiyi barədə danışaq. Dondurmadan əvvəl və sonra skriptləri işə salmaq, kölgə surətini yaratmaq, metadata toplamaq, SQL əməliyyat jurnalları ilə işləmək və s. Veeam Qonaq Köməkçisi. Fayl sistemləri indeksləşdirilibsə, Veeam Qonaq İndeksləyicisi . Bunlar ehtiyat nüsxələmə müddətində yerləşdirilən və ondan sonra silinən müvəqqəti xidmətlərdir.

Linux maşınlarına gəldikdə, çox sayda daxili kitabxananın olması və sistemin özünün imkanları səbəbindən hər şey daha sadədir. Məsələn, indeksləşdirmə mlocate vasitəsilə həyata keçirilir.

Hələlik bu qədər

Mən daha səni incitməyə cəsarət etmirəm qısa Hesab edirəm ki, Veeam mühərrik bölməsinin təqdimatı bitdi. Bəli, biz hətta yuvaların özlərinə də yaxınlaşmamışıq, amma inanın mənə ki, onlarda təqdim olunan məlumatlar ardıcıl olmayan şüur ​​axını kimi görünməsin, belə bir giriş mütləq lazımdır. Mən logların özlərinə yalnız üçüncü məqalədə getməyi planlaşdırıram və növbəti üçün plan, qeydləri kimin yaratdığını, onlarda nəyin göstərildiyini və niyə dəqiq olduğunu izah etməkdir, başqa cür deyil.

Mənbə: www.habr.com

Добавить комментарий