Biz təxminlərin füsunkar dünyasına dalmağa davam edirik ... qeydlər vasitəsilə problemlərin aradan qaldırılması. IN biz əsas terminlərin mənası ilə bağlı razılığa gəldik və Veeam-in ümumi strukturuna bir gözlə bir tətbiq kimi baxdıq. Bunun vəzifəsi log fayllarının necə formalaşdığını, onlarda hansı məlumatların göstərildiyini və niyə göründüklərini anlamaqdır.
Sizcə, bu “loglar” nədir? Əksəriyyətin fikrincə, hər hansı bir tətbiqin qeydlərinə bir növ hər şeyə qadir olan bir varlıq rolu verilməlidir ki, çox vaxt həyətdə bir yerdə bitki örtür, lakin lazımi anda heç bir yerdən parlaq zirehlərdə görünür və hamını xilas edir. Yəni, onlar hər bir komponentdə ən kiçik səhvlərdən tutmuş fərdi verilənlər bazası əməliyyatlarına qədər hər şeyi ehtiva etməlidirlər. Və beləliklə, səhvdən sonra onu başqa necə düzəltmək olar dərhal yazılıb. Və bütün bunlar bir neçə meqabayta sığmalıdır, daha çox deyil. Bu sadəcə mətndir! Mətn faylları onlarla gigabayt tuta bilməz, mən bunu haradasa eşitmişəm!
Beləliklə, loglar
Real dünyada jurnallar yalnız diaqnostik məlumatların arxividir. Orada nə saxlamaq, saxlama üçün məlumatı haradan əldə etmək və onun nə qədər təfərrüatlı olması, tərtibatçıların özləri qərar verir. Kimsə ON / OFF səviyyəsinin qeydlərini apararaq minimalizm yolunu izləyir, kimsə isə çata biləcəyi hər şeyi səylə dırmdırır. Baxmayaraq ki, Logging Level adlananı seçmək imkanı ilə bir ara seçim var, siz özünüz nə qədər ətraflı məlumat saxlamaq istədiyinizi və nə qədər əlavə disk yeriniz olduğunu göstərdiyiniz zaman =) VBR, yeri gəlmişkən, altı belə səviyyəyə malikdir. Və inanın ki, diskinizdə boş yer olan ən ətraflı girişlə nə baş verdiyini görmək istəmirsiniz.
Yaxşı. Nəyə qənaət etmək istədiyimizi təxminən başa düşdük, lakin haqlı bir sual yaranır: bu məlumatı haradan əldə etmək olar? Təbii ki, biz öz daxili proseslərimizlə özümüzü qeyd etmək üçün tədbirlərin bir hissəsini təşkil edirik. Bəs xarici mühitlə qarşılıqlı əlaqə olduqda nə etməli? Koltuqaltı və velosipedlərdən ibarət cəhənnəmə sürüşməmək üçün Veeam artıq ixtira edilmiş ixtiraları icad etmir. Hər dəfə hazır API, quraşdırılmış funksiya, kitabxana və s. olduqda, kontrapsiyalarımızı hasarlamağa başlamazdan əvvəl hazır variantlara üstünlük verəcəyik. Baxmayaraq ki, sonuncu da yoxdur. Buna görə də, qeydləri təhlil edərkən, səhvlərin aslan payının üçüncü tərəf API-lərindən, sistem zənglərindən və digər kitabxanalardan gələn mesajlara düşdüyünü başa düşmək lazımdır. Bu halda, VBR-nin rolu bu səhvləri olduğu kimi log fayllarına yönləndirməkdən ibarətdir. İstifadəçinin əsas vəzifəsi hansı xəttin kimdən olduğunu və bu "kimin" nəyə cavabdeh olduğunu başa düşməyi öyrənməkdir. Beləliklə, əgər VBR jurnalından bir səhv kodu sizi MSDN səhifəsinə aparırsa, bu, yaxşı və düzgündür.
Daha əvvəl razılaşdığımız kimi: Veeam sözdə SQL əsaslı proqramdır. Bu o deməkdir ki, 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 - hər şey onun verilənlər bazasında saxlanılır. Beləliklə, sadə həqiqət: qeydlərdə olmayanlar çox güman ki, verilənlər bazasındadır. Ancaq bu da gümüş güllə deyil: bəzi şeylər Veeam komponentlərinin yerli qeydlərində və ya verilənlər bazasında yoxdur. Buna görə, host qeydlərini, yerli maşının qeydlərini və ehtiyat nüsxə və bərpa prosesində iştirak edən hər şeyin qeydlərini necə öyrənməyi öyrənməlisiniz. Həm də elə olur ki, lazımi məlumatlar ümumiyyətlə heç yerdə yoxdur. Bu yoldur.
Belə API-lərin bəzi nümunələri
Bu siyahı müstəsna olaraq tam olmaq məqsədi daşımır, ona görə də onda son həqiqəti axtarmağa ehtiyac yoxdur. Onun məqsədi yalnız məhsullarımızda istifadə olunan ən çox yayılmış üçüncü tərəf API və texnologiyalarını göstərməkdir.
Başlayaq VMware.
Siyahıda birinci olacaq vSphere API. Doğrulama, iyerarxiyanı oxumaq, anlıq görüntüləri yaratmaq və silmək, maşınlar haqqında məlumat tələb etmək və daha çox (çox) üçün istifadə olunur. Həllin funksionallığı çox genişdir, ona görə də versiya üçün VMware vSphere API Referansını tövsiyə edə bilərəm. и . Daha cari versiyalar üçün hər şey sadəcə google-da axtarılır.
VIX API. Hipervizorun qara sehri, bunun üçün ayrıca var . Şəbəkə üzərindən onlara qoşulmadan hostda fayllarla işləmək üçün VMware API. Daha yaxşı rabitə kanalı olmayan bir maşına fayl qoymaq lazım olduqda son çarə variantı. Fayl böyükdürsə və host yüklənirsə, bu ağrı və əziyyətdir. Ancaq burada qayda işləyir ki, hətta 56,6 Kb / s 0 Kb / s-dən daha yaxşıdır. Hyper-V-də bu şey PowerShell Direct adlanır. Ancaq bu yalnız əvvəl idi
vSpehere Veb Xidmətləri API vSphere 6.0-dan başlayaraq (təxminən, bu API ilk dəfə 5.5 versiyada təqdim edildiyi üçün) qonaq maşınları ilə işləmək üçün istifadə olunur və demək olar ki, hər yerdə VIX-i əvəz etmişdir. Əslində, bu, vSphere-i idarə etmək üçün başqa bir API-dir. Maraqlananlara oxumağı tövsiyə edirəm təlimat.
VDDK (Virtual Disk İnkişafı Dəsti). Bunda qismən bəhs edilən kitabxana . Virtual diskləri oxumaq üçün istifadə olunur. Bir zamanlar VIX-in bir hissəsi idi, lakin zaman keçdikcə ayrı bir məhsula köçürüldü. Lakin varis olaraq VIX ilə eyni səhv kodlarından istifadə edir. Ancaq nədənsə SDK-nın özündə bu səhvlərin təsviri yoxdur. Buna görə də empirik olaraq məlum oldu ki, digər kodlarla VDDK səhvləri sadəcə ikilik koddan onluq koda tərcümədir. O, iki hissədən ibarətdir - birinci yarı kontekst haqqında sənədsiz məlumat, ikinci hissə isə ənənəvi VIX / VDDK səhvləridir. Məsələn, görsək:
VDDK error: 21036749815809.Unknown error
Sonra biz cəsarətlə bunu hex-ə çeviririk və 132200000001 əldə edirik. Biz sadəcə olaraq 132200-ün qeyri-informativ başlanğıcını ləğv edirik, qalanı isə səhv kodumuz olacaq (VDDK 1: Naməlum xəta). Ən tez-tez VDDK səhvləri haqqında, bu yaxınlarda ayrı bir səhv var idi .
İndi baxaq Pəncərələr.
Burada bizim üçün ən zəruri və vacib olan hər şeyi standartda tapmaq olar Hadisə Viewer. Ancaq bir şey var: uzun bir ənənəyə görə, Windows səhvin tam mətnini deyil, yalnız nömrəsini qeyd edir. Məsələn, 5-ci xəta “Giriş rədd edildi” və 1722 “RPC serveri əlçatan deyil” və 10060 “Bağlantı vaxtı bitdi”dir. Ən məşhurlarını xatırlasanız, əlbəttə ki, əla olar, bəs indiyədək görünməmişlər?
Həyatın ümumiyyətlə bal kimi görünməməsi üçün səhvlər 0x8007 prefiksi ilə onaltılıq formada da saxlanılır. Məsələn, 0x8007000e əslində 14, Yaddaşda Yoxdur. Bunun nə üçün və kim üçün edildiyi qaranlıqda gizlənmiş bir sirr olaraq qalır. Bununla belə, səhvlərin tam siyahısı pulsuz və SMS olmadan yüklənə bilər .
Yeri gəlmişkən, bəzən yalnız 0x8007 deyil, başqa prefikslər də var. Belə bir kədərli vəziyyətdə, HRESULT (“nəticə tutumu”) başa düşmək üçün daha da dərinə getməlisiniz. tərtibatçılar üçün. Adi həyatda sizə bunu etməyi məsləhət görmürəm, amma birdən divara sıxışsanız və ya sadəcə maraqlanırsınızsa, indi nə edəcəyinizi bilirsiniz.
Ancaq Microsoft-dakı yoldaşlar bizə bir az rəhm etdilər və dünyaya bir fayda göstərdilər . Bu, Google-dan istifadə etmədən səhv kodlarını insan dilinə çevirə bilən kiçik bir konsol xoşbəxtliyidir. Bu belə işləyir.
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"Qanuni sual yaranır: niyə biz dərhal deşifrəni jurnallara yazmırıq, amma bu sirli kodları tərk edirik? Cavab üçüncü tərəf proqramlarındadır. Bəzi WinAPI çağırışlarını özünüzə çəkdiyiniz zaman onun cavabını deşifrə etmək çətin deyil, çünki bunun üçün hətta xüsusi WinAPI çağırışı da var. Ancaq artıq qeyd edildiyi kimi, yalnız bizə cavab olaraq gələn hər şey jurnallarımıza daxil olur. Və burada, onun şifrəsini açmaq üçün bu şüur axınını daim izləmək, ondan Windows səhvləri olan parçaları çıxarmaq, şifrələrini açmaq və geri yapışdırmaq lazımdır. Dürüst olaq, ən maraqlı fəaliyyət deyil.
Windows Fayl İdarəetmə API fayllarla işləyərkən hər cür istifadə olunur. Faylların yaradılması, silinməsi, yazmaq üçün açılması, atributlarla işləmək və s.
Yuxarıda göstərilib PowerShell Direct Hyper-V dünyasında VIX API-nin analoqu kimi. Təəssüf ki, o qədər də çevik deyil: funksionallıqda bir çox məhdudiyyət, o, ev sahibinin hər versiyası ilə işləmir və bütün qonaqlarla deyil.
RPC (Uzaqdan Prosedur Çağırışı) Düşünürəm ki, RPC ilə bağlı səhvləri görməmiş WIndows ilə işləyən bir nəfər də yoxdur. Populyar yanlış təsəvvürə baxmayaraq, bu, tək bir protokol deyil, bir sıra parametrləri təmin edən istənilən müştəri-server protokoludur. Bununla belə, qeydlərimizdə RPC xətası varsa, 90% hallarda bu, DCOM-un (Paylanmış Komponent Obyekt Modeli) bir hissəsi olan Microsoft RPC-nin xətası olacaq. Şəbəkədə bu mövzuda çox sayda sənəd tapa bilərsiniz, lakin onun aslan payı olduqca köhnəlmişdir. Ancaq mövzunu öyrənmək üçün kəskin istək varsa, məqalələri tövsiyə edə bilərəm , və uzun siyahı .
Qeydlərimizdə RPC xətalarının əsas səbəbləri VBR komponentləri (məsələn, server > proksi) arasında uğursuz ünsiyyət cəhdləri və çox vaxt rabitə problemləri ilə bağlıdır.
Bütün zirvələr arasında ən yaxşısı RPC serveri əlçatan deyil (1722) xətasıdır. Sadə dillə desək, müştəri serverlə əlaqə qura bilmədi. Necə və niyə - vahid cavab yoxdur, lakin adətən bu, autentifikasiya və ya 135-ci porta şəbəkə girişi ilə bağlı problemdir. Sonuncu dinamik port təyinatı olan infrastrukturlar üçün xarakterikdir. Bu mövzuda hətta var . Microsoft da var uğursuzluğun səbəbini tapmaq üçün.
İkinci ən populyar xəta: Son nöqtə xəritəçisindən (1753) artıq son nöqtə yoxdur. RPC müştəri və ya server özünə port təyin edə bilmədi. Adətən server (bizim vəziyyətimizdə qonaq maşını) bitmiş dar diapazondan portları dinamik şəkildə ayırmaq üçün konfiqurasiya edildikdə baş verir. Əgər siz müştəri tərəfdən daxil olursunuzsa (bizim vəziyyətimizdə VBR serveri), bu o deməkdir ki, VeeamVssAgent ya işə salınmayıb, ya da RPC interfeysi kimi qeydiyyatdan keçməyib. Bu mövzuda da var .
Ən yaxşı 3 RPC səhvini tamamlamaq üçün RPC funksiyası çağırışının uğursuz olduğunu xatırlayaq (1726). Bağlantı qurulduqda görünür, lakin RPC sorğuları işlənmir. Məsələn, biz VSS-nin statusu haqqında məlumat tələb edirik (birdən elə indi orada kölgə minası hazırlanır və biz qalxmağa çalışırıq) və bizə cavab olaraq susub məhəl qoymuruq.
Windows Tape Backup API lent kitabxanaları və ya sürücülərlə işləmək üçün lazımdır. Başlanğıcda qeyd etdiyim kimi: öz sürücülərimizi yazıb, sonra hər cihazın dəstəyi ilə əziyyət çəkməkdən zövq almırıq. Buna görə də, vim-in heç bir sürücüsü yoxdur. Dəstəyi aparat təchizatçılarının özləri tərəfindən həyata keçirilən standart API vasitəsilə. Daha məntiqli, elə deyilmi?
SMB / CIFS CIFS-in (Ümumi İnternet Fayl Sistemi) SMB-nin (Server Mesaj Bloku) sadəcə şəxsi versiyası olduğunu hamı xatırlamasa da, vərdişdən kənar hər kəs onları yan-yana yazır. Deməli, bu anlayışları ümumiləşdirməkdə heç bir qəbahət yoxdur. Samba artıq LinuxUnix tətbiqidir və onun özünəməxsus xüsusiyyətləri var, amma mən kənara çəkilirəm. Burada vacib olan: Veeam UNC yoluna (serverdirectory) nəsə yazmağı xahiş etdikdə server topa yazmaq üçün mup və mrxsmb daxil olmaqla fayl sistemi sürücülərinin iyerarxiyasından istifadə edir. Müvafiq olaraq, bu sürücülər də səhvlər yaradacaqlar.
Onsuz edə bilməz Winsock API. Şəbəkə üzərindən bir şey etmək lazımdırsa, VBR xalq arasında Winsock kimi tanınan Windows Socket API vasitəsilə işləyir. Beləliklə, əgər logda bir dəstə IP:Port görsək, budur. Rəsmi sənədlərdə mümkün olanların yaxşı siyahısı var .
Yuxarıda göstərilib WMI (Windows İdarəetmə Alətləri) Windows dünyasında hər şeyi və hər kəsi idarə etmək üçün bir növ qüdrətli API-dir. Məsələn, Hyper-V ilə işləyərkən, demək olar ki, hosta edilən bütün sorğular ondan keçir. Bir sözlə, şey tamamilə əvəzolunmazdır və imkanlarına görə çox güclüdür. Harada və nəyin pozulduğunu öyrənməyə kömək etmək üçün daxili WBEMtest.exe aləti çox kömək edir.
Və siyahıda sonuncu, lakin əhəmiyyəti baxımından ən azı - VSS (Həcmi kölgə saxlama). Mövzu haqqında nə qədər sənəd yazılsa, o qədər də tükənməz və sirlidir. Kölgə nüsxəsi ən sadə şəkildə xüsusi bir şəkil növü kimi başa düşülür, mahiyyət etibarilə budur. Onun sayəsində siz VMware-də və Hyper-V-də demək olar ki, hər şeyin proqrama uyğun ehtiyat nüsxələrini edə bilərsiniz. VSS-də bir az sıxışdırmaqla ayrıca məqalə hazırlamaq planlarım var, amma hələlik oxumağa cəhd edə bilərsiniz. . Sadəcə diqqətli olun, çünki. VSS-ni bir anda anlamağa çalışmaq beyin zədələnməsinə səbəb ola bilər.
Bununla bağlı, bəlkə də, dayana bilərik. Ən əsas şeyləri izah etmək tapşırığını tamamlanmış hesab edirəm, buna görə də növbəti fəsildə biz artıq qeydlərə baxacağıq. Ancaq hər hansı bir sualınız varsa, şərhlərdə onlardan soruşmaqdan çekinmeyin.
Mənbə: www.habr.com