Biz jurnallar orqali muammolarni bartaraf etish ... taxmin qilishning ajoyib olamiga sho'ng'ishda davom etamiz. IN biz asosiy atamalarning ma'nosi bo'yicha kelishib oldik va Veeamning umumiy tuzilishini bir ko'z bilan yagona dastur sifatida ko'rib chiqdik. Buning vazifasi jurnal fayllari qanday tuzilganligini, ularda qanday ma'lumotlar ko'rsatilishini va nima uchun ular tashqi ko'rinishini aniqlashdir.
Sizningcha, bu "jurnallar" nima? Ko'pchilikning fikriga ko'ra, har qanday dasturning jurnallariga ko'pincha orqa hovlida o'simliklar o'sadigan, ammo kerakli vaqtda hech qanday joydan tashqarida porlab turgan zirhlarda paydo bo'ladigan va hammani qutqaradigan qudratli mavjudotning roli berilishi kerak. Ya'ni, ular har bir komponentdagi eng kichik xatolardan tortib ma'lumotlar bazasi tranzaktsiyalarigacha bo'lgan hamma narsani o'z ichiga olishi kerak. Shunday qilib, xatolikdan so'ng darhol uni qanday tuzatish kerakligi yozildi. Va bularning barchasi bir necha megabaytga to'g'ri kelishi kerak, ortiq emas. Bu shunchaki matn! Matn fayllari o'nlab gigabaytni olmaydi, men buni qaerdadir eshitdim!
Shunday qilib, jurnallar
Haqiqiy dunyoda jurnallar faqat diagnostika ma'lumotlarining arxividir. Va u erda nimani saqlash kerak, saqlash uchun ma'lumotni qaerdan olish kerak va u qanchalik batafsil bo'lishi kerak, ishlab chiquvchilarning o'zlari hal qiladilar. Kimdir ON / OFF darajasidagi yozuvlarni saqlab, minimalizm yo'lidan boradi va kimdir erisha oladigan hamma narsani sinchkovlik bilan ta'kidlaydi. Ro'yxatga olish darajasi deb ataladigan oraliq variantni tanlash imkoniyati mavjud bo'lsa-da, siz o'zingiz qanchalik batafsil ma'lumot saqlamoqchi ekanligingizni va qancha qo'shimcha disk maydoni borligini ko'rsatsangiz =) VBR, aytmoqchi, oltita shunday darajaga ega. Va, menga ishoning, siz diskda bo'sh joy bilan eng batafsil ro'yxatga olish bilan nima sodir bo'lishini ko'rishni xohlamaysiz.
Yaxshi. Biz nimani saqlamoqchi ekanligimizni taxminan tushundik, lekin qonuniy savol tug'iladi: bu ma'lumotni qaerdan olish kerak? Albatta, biz o'z ichki jarayonlarimiz orqali o'zimizni qayd qilish uchun tadbirlarning bir qismini tashkil qilamiz. Ammo tashqi muhit bilan o'zaro ta'sir mavjud bo'lganda nima qilish kerak? Veeam qo'ltiq tayoqchalari va velosipedlar jahannamiga sirpanib ketmaslik uchun allaqachon ixtiro qilingan ixtirolarni ixtiro qilishga moyil emas. Har doim tayyor API, o'rnatilgan funksiya, kutubxona va boshqalar mavjud bo'lganda, biz o'z qarama-qarshiliklarimizni to'sib qo'yishni boshlashdan oldin tayyor variantlarga ustunlik beramiz. Garchi ikkinchisi ham etarli. Shuning uchun, jurnallarni tahlil qilganda, xatolarning asosiy ulushi uchinchi tomon API-lari, tizim qo'ng'iroqlari va boshqa kutubxonalardan kelgan xabarlarga to'g'ri kelishini tushunish kerak. Bunday holda, VBR ning roli ushbu xatolarni jurnal fayllari kabi yo'naltirishga tushadi. Va foydalanuvchining asosiy vazifasi - qaysi chiziq kimdan ekanligini va bu "kim" nima uchun javobgar ekanligini tushunishni o'rganishdir. Shunday qilib, agar VBR jurnalidagi xato kodi sizni MSDN sahifasiga olib borsa, bu yaxshi va to'g'ri.
Oldin kelishib olganimizdek: Veeam - bu SQL-ga asoslangan dastur. Bu shuni anglatadiki, barcha sozlamalar, barcha ma'lumotlar va umuman, faqat normal ishlash uchun zarur bo'lgan hamma narsa - hamma narsa uning ma'lumotlar bazasida saqlanadi. Shunday qilib, oddiy haqiqat: jurnallarda bo'lmagan narsa ma'lumotlar bazasida bo'lishi mumkin. Ammo bu ham kumush o'q emas: ba'zi narsalar Veeam komponentlarining mahalliy jurnallarida ham, uning ma'lumotlar bazasida ham yo'q. Shuning uchun siz xost jurnallarini, mahalliy mashinaning jurnallarini va zaxiralash va tiklash jarayonida ishtirok etadigan barcha narsalarning jurnallarini qanday o'rganishni o'rganishingiz kerak. Va shunday bo'ladiki, kerakli ma'lumotlar hech qanday joyda mavjud emas. Bu yo'l.
Bunday APIlarning ba'zi misollari
Ushbu ro'yxat mutlaqo to'liq bo'lishni maqsad qilmaydi, shuning uchun undan yakuniy haqiqatni izlashning hojati yo'q. Uning maqsadi faqat mahsulotlarimizda ishlatiladigan eng keng tarqalgan uchinchi tomon API va texnologiyalarini ko'rsatishdir.
dan boshlaylik VMware.
Ro'yxatda birinchi bo'ladi vSphere API. Autentifikatsiya qilish, ierarxiyani o'qish, suratlarni yaratish va o'chirish, mashinalar haqida ma'lumot so'rash va boshqa ko'p (juda ko'p) uchun ishlatiladi. Yechimning funksionalligi juda keng, shuning uchun men versiya uchun VMware vSphere API Reference-ni tavsiya qilishim mumkin. ΠΈ . Ko'proq joriy versiyalar uchun hamma narsa faqat Google orqali topilgan.
VIX API. Gipervisorning qora sehri, buning uchun alohida mavjud . Xostdagi fayllar bilan tarmoq orqali ulanmasdan ishlash uchun VMware API. Yaxshiroq aloqa kanali bo'lmagan mashinaga fayl qo'yish kerak bo'lganda oxirgi chora varianti. Agar fayl katta bo'lsa va xost yuklangan bo'lsa, bu og'riq va azob. Ammo bu erda qoida ishlaydi, hatto 56,6 Kb / s 0 Kb / s dan yaxshiroq. Hyper-V-da bu narsa PowerShell Direct deb ataladi. Ammo bu faqat oldin edi
vSpehere Web Services API vSphere 6.0 dan boshlab (taxminan, ushbu API birinchi marta 5.5 versiyasida taqdim etilganidan beri) u mehmon mashinalari bilan ishlash uchun ishlatiladi va deyarli hamma joyda VIX ni almashtirdi. Aslida, bu vSphere-ni boshqarish uchun yana bir API. Qiziqqanlar uchun o'qishni tavsiya qilaman qo'llanma.
VDDK (Virtual diskni ishlab chiqish to'plami). Bu qisman muhokama qilingan kutubxona . Virtual disklarni o'qish uchun ishlatiladi. Bir vaqtlar u VIXning bir qismi edi, ammo vaqt o'tishi bilan u alohida mahsulotga ko'chirildi. Ammo merosxo'r sifatida u VIX kabi bir xil xato kodlaridan foydalanadi. Lekin negadir SDK ning o'zida bu xatolarning tavsifi yo'q. Shuning uchun, boshqa kodlar bilan VDDK xatolar ikkilik koddan o'nlik kodga tarjima ekanligi empirik tarzda aniqlandi. U ikki qismdan iborat - birinchi yarmi kontekst haqida hujjatsiz ma'lumot, ikkinchi qism esa an'anaviy VIX / VDDK xatolaridir. Misol uchun, agar biz ko'rsak:
VDDK error: 21036749815809.Unknown error
Keyin biz buni jasorat bilan hexga aylantiramiz va 132200000001 ni olamiz. Biz shunchaki 132200 ning noan'anaviy boshini o'chirib tashlaymiz, qolgani bizning xato kodimiz bo'ladi (VDDK 1: Noma'lum xato). Eng tez-tez uchraydigan VDDK xatolar haqida, yaqinda alohida edi .
Endi ko'rib chiqaylik WINDOWS.
Bu erda biz uchun eng zarur va muhim bo'lgan hamma narsani standartda topish mumkin Voqeani ko'rish vositasi. Ammo bir narsa bor: uzoq an'anaga ko'ra, Windows xatoning to'liq matnini emas, balki faqat uning raqamini kiritadi. Masalan, 5-xato "Kirish taqiqlandi" va 1722 - "RPC serveri mavjud emas" va 10060 - "Ulanish vaqti tugadi". Albatta, agar siz eng mashhurlarini eslasangiz juda yaxshi, lekin hozirgacha ko'rilmaganlar haqida nima deyish mumkin?
Va hayot umuman asalga o'xshamasligi uchun xatolar 0x8007 prefiksi bilan o'n oltilik shaklda saqlanadi. Misol uchun, 0x8007000e aslida 14, Xotirada yo'q. Bu nima uchun va kim uchun qilinganligi zulmatga o'ralgan sirdir. Biroq, xatolarning to'liq ro'yxatini bepul va SMSsiz yuklab olish mumkin .
Aytgancha, ba'zida faqat 0x8007 emas, balki boshqa prefikslar ham mavjud. Bunday qayg'uli vaziyatda HRESULT ("natija dastagi") ni tushunish uchun siz yanada chuqurroq o'rganishingiz kerak. ishlab chiquvchilar uchun. Oddiy hayotda men sizga buni qilishni maslahat bermayman, lekin agar siz to'satdan devorga bossangiz yoki shunchaki qiziqsangiz, endi nima qilish kerakligini bilasiz.
Ammo Microsoftdagi o'rtoqlar bizga ozgina rahm qilishdi va dunyoga foydali dasturni ko'rsatishdi . Bu Google-dan foydalanmasdan xato kodlarini insonga tarjima qila oladigan konsol baxtining kichik qismidir. Bu shunday ishlaydi.
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"To'g'ri savol tug'iladi: nega biz shifrni ochishni darhol jurnallarga yozmaymiz, lekin bu sirli kodlarni qoldiramiz? Javob uchinchi tomon ilovalarida. O'zingizga bir nechta WinAPI qo'ng'iroqlarini jalb qilganingizda, uning javobini tushunish qiyin emas, chunki buning uchun maxsus WinAPI chaqiruvi ham mavjud. Ammo yuqorida aytib o'tilganidek, bizga javob sifatida kelgan hamma narsa bizning jurnallarimizga kiradi. Va bu erda, uni parolini ochish uchun, bu ong oqimini doimiy ravishda kuzatib borish, undan Windows xatolari bo'lgan qismlarni chiqarib tashlash, ularni parolini ochish va ularni qayta joylashtirish kerak edi. Keling, eng qiziqarli faoliyat emas, balki halol bo'laylik.
Windows fayllarni boshqarish API fayllar bilan ishlashda har tomonlama qo'llaniladi. Fayllarni yaratish, o'chirish, yozish uchun ochish, atributlar bilan ishlash va hokazo.
yuqorida aytib o'tilgan PowerShell Direct Hyper-V dunyosida VIX API ning analogi sifatida. Afsuski, unchalik moslashuvchan emas: funksionallikda juda ko'p cheklovlar, u uy egasining har bir versiyasi bilan ishlamaydi va barcha mehmonlar bilan emas.
CPR (Masofadan protsedura chaqiruvi) Menimcha, RPC bilan bog'liq xatolarni ko'rmagan WIndows bilan ishlagan bitta odam yo'q. Ommabop noto'g'ri tushunchaga qaramasdan, bu bitta protokol emas, balki bir qator parametrlarni qondiradigan har qanday mijoz-server protokoli. Biroq, agar bizning jurnallarimizda RPC xatosi bo'lsa, 90% hollarda bu DCOM (Distributed Component Object Model) tarkibiga kiruvchi Microsoft RPC xatosi bo'ladi. Tarmoqda siz ushbu mavzu bo'yicha juda ko'p hujjatlarni topishingiz mumkin, ammo uning asosiy ulushi juda eskirgan. Ammo agar mavzuni o'rganish istagi bo'lsa, men maqolalarni tavsiya qilishim mumkin , va uzoq ro'yxat .
Jurnallarimizdagi RPC xatolarining asosiy sabablari VBR komponentlari (masalan, server > proksi) o'rtasida va ko'pincha aloqa muammolari bilan bog'lanishning muvaffaqiyatsiz urinishlaridir.
Barcha toplar orasida eng yuqorisi xato RPC serveri mavjud emas (1722). Oddiy qilib aytganda, mijoz server bilan aloqa o'rnatolmadi. Qanday qilib va ββnima uchun - bitta javob yo'q, lekin odatda bu autentifikatsiya yoki 135-portga tarmoqqa kirish bilan bog'liq muammo. Ikkinchisi dinamik port tayinlangan infratuzilmalar uchun odatiy hisoblanadi. Bu mavzu bo'yicha, hatto bor . Va Microsoft bor muvaffaqiyatsizlik sababini topish uchun.
Ikkinchi eng mashhur xato: so'nggi nuqta mapper (1753) dan boshqa so'nggi nuqtalar mavjud emas. RPC mijozi yoki serveri o'ziga port tayinlay olmadi. Odatda server (bizning holimizda mehmon mashinasi) tugagan tor diapazondan portlarni dinamik ravishda ajratish uchun sozlanganida sodir bo'ladi. Agar siz mijoz tomonidan tizimga kirsangiz (bizning holimizda VBR serveri), bu bizning VeeamVssAgent ishga tushmagan yoki RPC interfeysi sifatida roβyxatdan oβtmaganligini anglatadi. Bu mavzuda ham bor .
Eng yaxshi 3 ta RPC xatolarini yakunlash uchun RPC funksiyasi chaqiruvi bajarilmaganini eslaylik (1726). Agar ulanish o'rnatilgan bo'lsa, lekin RPC so'rovlari qayta ishlanmasa paydo bo'ladi. Masalan, biz VSS holati to'g'risida ma'lumot so'raymiz (to'satdan hozir u erda soyali mina qilinmoqda va biz ko'tarilishga harakat qilmoqdamiz) va bizga javoban jim bo'ling va e'tibor bermang.
Windows tasmasini zaxiralash API lenta kutubxonalari yoki drayvlar bilan ishlash uchun kerak. Avval aytib o'tganimdek: biz o'z drayverlarimizni yozib, keyin har bir qurilmaning yordami bilan azob chekishdan zavqlanmaymiz. Shuning uchun, vim-ning o'ziga xos drayverlari yo'q. Hammasi standart API orqali, uni qo'llab-quvvatlash apparat sotuvchilari tomonidan amalga oshiriladi. Juda ham mantiqiy, to'g'rimi?
SMB / CIFS Odatdagidek, hamma ularni yonma-yon yozadi, ammo CIFS (Common Internet File System) SMB (Server Message Block) ning shunchaki shaxsiy versiyasi ekanligini hamma ham eslamaydi. Demak, bu tushunchalarni umumlashtirishda xatolik yoβq. Samba allaqachon LinuxUnix ilovasi bo'lib, uning o'ziga xos xususiyatlari bor, lekin men chekinaman. Bu erda muhim narsa: Veeam UNC yo'liga (server katalogiga) biror narsa yozishni so'raganda, server to'pga yozish uchun fayl tizimi drayverlari, shu jumladan mup va mrxsmb ierarxiyasidan foydalanadi. Shunga ko'ra, bu drayverlar ham xatolarni keltirib chiqaradi.
Busiz qila olmayman Winsock API. Agar tarmoq orqali biror narsa qilish kerak bo'lsa, VBR keng tarqalgan Winsock sifatida tanilgan Windows Socket API orqali ishlaydi. Shunday qilib, agar biz jurnalda bir nechta IP: Portni ko'rsak, bu shunday. Rasmiy hujjatlarda mumkin bo'lganlarning yaxshi ro'yxati mavjud .
yuqorida aytib o'tilgan WMI (Windows Management Instrumentation) - bu Windows dunyosidagi hamma narsani va hamma narsani boshqarish uchun o'ziga xos qudratli API. Misol uchun, Hyper-V bilan ishlashda xostga deyarli barcha so'rovlar u orqali o'tadi. Bir so'z bilan aytganda, narsa mutlaqo almashtirib bo'lmaydigan va o'z imkoniyatlarida juda kuchli. Qayerda va nima buzilganligini aniqlashga yordam berish uchun o'rnatilgan WBEMtest.exe vositasi juda ko'p yordam beradi.
Va ro'yxatda oxirgi, lekin hech qanday ahamiyatga ega emas - VSS (Ovoz balandligi soyasini saqlash). Mavzu bitmas-tuganmas va sirli bo'lib, u haqida qancha hujjatlar yozilgan bo'lsa. Soya nusxasi eng sodda tarzda oniy tasvirning maxsus turi sifatida tushuniladi, aslida u shunday. Unga rahmat, siz VMware-da va Hyper-V-da deyarli hamma narsani ilovalarga mos keladigan zaxira nusxalarini yaratishingiz mumkin. Men VSS-ni biroz siqib, alohida maqola qilishni rejalashtirmoqdaman, ammo hozircha siz o'qishga harakat qilishingiz mumkin . Faqat ehtiyot bo'ling, chunki. VSSni bir lahzada tushunishga urinish miya shikastlanishiga olib kelishi mumkin.
Bu borada, ehtimol, biz to'xtashimiz mumkin. Men eng asosiy narsalarni tushuntirish vazifasini tugallangan deb hisoblayman, shuning uchun keyingi bobda biz allaqachon jurnallarni ko'rib chiqamiz. Ammo agar sizda biron bir savol bo'lsa, ularni sharhlarda so'rang.
Manba: www.habr.com