Бид тааварт ... бүртгэлээр алдааг олж засварлах сонирхолтой ертөнцөд умбасаар байна. IN Бид үндсэн нэр томъёоны утгыг тохиролцож, Veeam-ийн ерөнхий бүтцийг нэг нүдээр нэг хэрэглээ болгон авч үзсэн. Үүний даалгавар бол лог файлууд хэрхэн үүсдэг, тэдгээрт ямар мэдээлэл агуулагддаг, яагаад тэдгээр нь харагдах байдлаараа харагддагийг олж мэдэх явдал юм.
Та эдгээр "логууд" гэж юу гэж бодож байна вэ? Ихэнх хүмүүсийн үзэж байгаагаар аливаа програмын бүртгэлд ихэвчлэн арын хашааны хаа нэгтээ ургамал ургадаг, гэхдээ зөв мөчид хаанаас ч юм гялалзсан хуяг дуулгатай гарч ирэн, хүн бүрийг авардаг нэгэн төрлийн бүхнийг чадагч этгээдийн үүрэг гүйцэтгэх ёстой. Өөрөөр хэлбэл, бүрэлдэхүүн хэсэг бүрийн өчүүхэн алдаанаас эхлээд мэдээллийн сангийн гүйлгээ хүртэл бүгдийг агуулсан байх ёстой. Тиймээс алдаа гарсны дараа үүнийг хэрхэн яаж засах талаар шууд бичсэн болно. Энэ бүхэн хэд хэдэн мегабайтад багтах ёстой, үүнээс илүүгүй. Энэ бол зүгээр л текст! Текст файлууд хэдэн арван гигабайт багтаамжгүй, би хаа нэгтээ сонссон!
Тиймээс бүртгэлүүд
Бодит амьдрал дээр бүртгэлүүд нь зөвхөн оношлогооны мэдээллийн архив юм. Тэнд юу хадгалах, хадгалах мэдээллийг хаанаас авах, хэр нарийвчлалтай байх нь хөгжүүлэгчид өөрсдөө шийднэ. Хэн нэгэн нь ON / OFF түвшний бүртгэл хөтөлж, минимализмын замыг дагаж, хэн нэгэн хүрч болох бүх зүйлээ хичээнгүйлэн тармуурдаг. Бүртгэлийн түвшин гэж нэрлэгддэг завсрын сонголт байдаг боловч та хэр дэлгэрэнгүй мэдээлэл хадгалахыг хүсч байгаагаа, мөн дискний нэмэлт зайг зааж өгөх үед =) VBR нь ийм зургаан түвшинтэй байдаг. Надад итгээрэй, та дискэн дээрх хоосон зайтай хамгийн дэлгэрэнгүй бүртгэлд юу тохиолдохыг харахыг хүсэхгүй байна.
Сайн байна. Бид юу хэмнэхийг хүсч байгаагаа бараг л ойлгосон боловч хууль ёсны асуулт гарч ирдэг: энэ мэдээллийг хаанаас авах вэ? Мэдээжийн хэрэг, бид дотоод үйл явцаараа өөрийгөө бүртгэх арга хэмжээний нэг хэсэг юм. Гэхдээ гадаад орчинтой харилцан үйлчлэлцэх үед яах вэ? Таяг, унадаг дугуйны там руу гулсахгүйн тулд Veeam аль хэдийн зохион бүтээсэн шинэ бүтээлүүдийг зохион бүтээхгүй байх хандлагатай байдаг. Бэлэн API, суурилуулсан функц, номын сан гэх мэт зүйлс байгаа тохиолдолд бид төхөөрөмжөө хашиж эхлэхээсээ өмнө бэлэн сонголтуудыг илүүд үзэх болно. Хэдийгээр сүүлийнх нь бас хангалттай. Тиймээс бүртгэлд дүн шинжилгээ хийхдээ алдааны арслангийн хувь нь гуравдагч талын API, системийн дуудлага болон бусад номын сангаас ирсэн мессежүүд дээр ногддог гэдгийг ойлгох нь чухал юм. Энэ тохиолдолд VBR-ийн үүрэг нь эдгээр алдааг лог файлууд руу дамжуулах явдал юм. Хэрэглэгчийн гол ажил бол аль шугам нь хэнээс ирсэн, энэ "хэн" юуг хариуцаж байгааг ойлгож сурах явдал юм. Хэрэв VBR бүртгэлийн алдааны код таныг MSDN хуудас руу аваачвал энэ нь зөв бөгөөд зөв юм.
Бид өмнө нь тохиролцсончлан: Veeam бол SQL-д суурилсан програм гэж нэрлэгддэг програм юм. Энэ нь бүх тохиргоо, бүх мэдээлэл, ерөнхийдөө зөвхөн хэвийн ажиллахад шаардлагатай бүх зүйл - бүх зүйл түүний мэдээллийн санд хадгалагддаг гэсэн үг юм. Эндээс энгийн үнэн: бүртгэлд байхгүй зүйл мэдээллийн санд байх магадлалтай. Гэхдээ энэ нь мөнгөн сум биш: зарим зүйл нь Veeam бүрэлдэхүүн хэсгүүдийн локал бүртгэлүүд болон мэдээллийн санд байдаггүй. Тиймээс, та хостын бүртгэл, локал машины бүртгэл, нөөцлөх, сэргээх үйл явцад оролцдог бүх зүйлийн бүртгэлийг хэрхэн судлах талаар сурах хэрэгтэй. Мөн шаардлагатай мэдээлэл хаана ч байхгүй байх тохиолдол гардаг. Ийм л зам.
Ийм API-ийн зарим жишээ
Энэ жагсаалт нь онцгой бүрэн гүйцэд байх зорилгогүй тул үүнээс эцсийн үнэнийг хайх шаардлагагүй юм. Үүний зорилго нь зөвхөн манай бүтээгдэхүүнд хэрэглэгддэг гуравдагч талын API болон технологийг харуулах явдал юм.
-ээс эхэлье VMware.
Жагсаалтын эхнийх нь байх болно vSphere API. Баталгаажуулалт, шатлалыг унших, агшин зуурын зураг үүсгэх, устгах, машинуудын тухай мэдээлэл хүсэх болон бусад олон (маш их) зүйлд ашигладаг. Шийдлийн функц нь маш өргөн тул би хувилбарт VMware vSphere API лавлагааг санал болгож чадна. и . Илүү одоогийн хувилбаруудын хувьд бүх зүйлийг зүгээр л google-ээр хайж байна.
VIX API. Тусдаа байдаг гипервизорын хар ид шид . Сүлжээгээр холбогдохгүйгээр хост дээрх файлуудтай ажиллах VMware API. Харилцаа холбооны илүү сайн суваг байхгүй машинд файл оруулах шаардлагатай бол хамгийн сүүлчийн сонголт. Хэрэв файл том, хост ачаалагдсан бол энэ нь өвдөлт, зовлон юм. Гэхдээ энд дүрэм нь 56,6 Kb / s ч гэсэн 0 Kb / s-ээс илүү сайн байдаг. Hyper-V дээр энэ зүйлийг PowerShell Direct гэж нэрлэдэг. Гэхдээ энэ нь зөвхөн өмнө нь байсан
vSpehere Web Services API vSphere 6.0-аас эхлэн (ойролцоогоор энэ API-г 5.5 хувилбар дээр анх нэвтрүүлсэн) зочны машинуудтай ажиллахад ашигладаг бөгөөд VIX-ийг бараг хаа сайгүй орлуулсан. Үнэн хэрэгтээ энэ бол vSphere-г удирдах өөр нэг API юм. Сонирхсон хүмүүст сурахыг зөвлөж байна гарын авлага.
VDDK (Виртуал диск хөгжүүлэх хэрэгсэл). Энэ талаар хэсэгчлэн хэлэлцсэн номын сан . Виртуал дискийг уншихад ашигладаг. Нэгэн цагт энэ нь VIX-ийн нэг хэсэг байсан боловч цаг хугацаа өнгөрөхөд энэ нь тусдаа бүтээгдэхүүн болж шилжсэн. Гэхдээ өв залгамжлагчийн хувьд VIX шиг алдааны кодыг ашигладаг. Гэхдээ зарим шалтгааны улмаас SDK-д эдгээр алдааны тайлбар байхгүй байна. Тиймээс бусад кодтой VDDK алдаа нь хоёртын кодоос аравтын код руу орчуулах төдий гэдгийг эмпирик байдлаар олж мэдсэн. Энэ нь хоёр хэсгээс бүрдэнэ - эхний хагас нь контекстийн талаархи баримтгүй мэдээлэл, хоёр дахь хэсэг нь уламжлалт VIX / VDDK алдаа юм. Жишээлбэл, хэрэв бид харвал:
VDDK error: 21036749815809.Unknown error
Дараа нь бид үүнийг зоригтойгоор зургаан өнцөгт хөрвүүлээд 132200000001-ийг авна. Бид 132200-ын мэдээлэлгүй эхлэлийг зүгээр л хаяад үлдсэн нь бидний алдааны код болно (VDDK 1: Үл мэдэгдэх алдаа). Хамгийн их тохиолддог VDDK алдааны талаар саяхан тусдаа гарсан .
Одоо харцгаая Цонхнууд.
Эндээс бидний хувьд хамгийн хэрэгтэй, чухал бүх зүйлийг стандартаас олж болно Үйл явдлын Viewer. Гэхдээ нэг алдаа бий: эртний уламжлалын дагуу Windows алдааны бүрэн текстийг бүртгэдэггүй, харин зөвхөн дугаарыг нь бүртгэдэг. Жишээлбэл, 5-р алдаа нь "Хандалтыг хориглосон", 1722 нь "RPC сервер ашиглах боломжгүй", 10060 нь "Холболтын хугацаа дууссан" гэсэн үг юм. Мэдээжийн хэрэг, та хамгийн алдартайг нь санаж байвал сайхан байх болно, гэхдээ өнөөг хүртэл хараагүй байсан бол яах вэ?
Амьдрал зөгийн бал шиг санагдахгүй байхын тулд алдаанууд нь 0x8007 угтвартай арван арван тоот хэлбэрээр хадгалагддаг. Жишээлбэл, 0x8007000e нь үнэндээ 14, Санах ойгүй байна. Үүнийг яагаад, хэний төлөө хийсэн нь харанхуйд бүрхэгдсэн нууцлаг хэвээр байна. Гэсэн хэдий ч алдааны бүрэн жагсаалтыг үнэгүй, SMSгүйгээр татаж авах боломжтой .
Дашрамд хэлэхэд, заримдаа зөвхөн 0x8007 биш өөр угтварууд байдаг. Ийм гунигтай нөхцөл байдалд HRESULT (“үр дүнгийн бариул”)-ыг ойлгохын тулд та бүр гүнзгийрүүлэн судлах хэрэгтэй. хөгжүүлэгчдэд зориулсан. Энгийн амьдралд би танд үүнийг хийхийг зөвлөдөггүй, гэхдээ хэрэв та гэнэт хананд дарагдсан эсвэл зүгээр л сониуч зантай бол одоо юу хийхээ мэдэж байна.
Гэвч Майкрософт дахь нөхдүүд биднийг бага зэрэг өрөвдөж, дэлхий дахинд ашиг тусаа өгсөн . Энэ бол 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 Hyper-V ертөнцөд VIX API-ийн аналог болгон. Харамсалтай нь тийм ч уян хатан биш: функциональд маш их хязгаарлалт тавьдаг, энэ нь хостын хувилбар бүртэй ажиллахгүй бөгөөд бүх зочдод тохирохгүй.
CPR (Remote Procedure Call) WIndows-тэй ажиллаж байсан, RPC-тэй холбоотой алдааг олж хараагүй ганц ч хүн байхгүй гэж бодож байна. Түгээмэл буруу ойлголтыг үл харгалзан энэ нь нэг протокол биш, харин олон тооны параметрүүдийг хангасан аливаа үйлчлүүлэгч-серверийн протокол юм. Гэсэн хэдий ч, хэрэв манай бүртгэлд RPC алдаа байгаа бол 90% нь DCOM (Tarafed Component Object Model)-ийн нэг хэсэг болох Microsoft RPC-ийн алдаа байх болно. Та энэ сэдвээр асар их хэмжээний баримт бичгийг сүлжээнээс олж болно, гэхдээ үүний арслангийн хувь нь нэлээд хуучирсан байна. Гэхдээ энэ сэдвийг судлах хүсэл эрмэлзэл байгаа бол би нийтлэл санал болгож болно , ба урт жагсаалт .
Манай логууд дахь RPC алдааны гол шалтгаан нь VBR бүрэлдэхүүн хэсгүүдийн (жишээ нь сервер > прокси) хооронд харилцах оролдлого бүтэлгүйтсэн бөгөөд ихэнхдээ харилцааны асуудлаас болдог.
Хамгийн шилдэг нь RPC сервер ажиллах боломжгүй (1722) алдаа юм. Энгийнээр хэлбэл, үйлчлүүлэгч сервертэй холбогдож чадаагүй. Хэрхэн, яагаад гэсэн ганц хариулт байдаггүй, гэхдээ ихэнхдээ энэ нь нэвтрэлт танилт эсвэл 135-р порт руу сүлжээний хандалттай холбоотой асуудал юм. Сүүлийнх нь динамик порт хуваарилалттай дэд бүтцийн хувьд ердийн зүйл юм. Энэ сэдвээр, тэр ч байтугай байдаг . Мөн Майкрософт бий бүтэлгүйтлийн шалтгааныг олохын тулд.
Хоёр дахь хамгийн түгээмэл алдаа: Төгсгөлийн цэгийн зураглагчаас (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)-ийн хувийн хувилбар гэдгийг хүн бүр санадаггүй ч зуршлаасаа болж хүн бүр тэдгээрийг зэрэгцүүлэн бичдэг. Тэгэхээр эдгээр ойлголтуудыг ерөнхийд нь дүгнэхэд буруудах зүйлгүй. Самба бол аль хэдийн LinuxUnix хэрэглүүр бөгөөд энэ нь өөрийн гэсэн онцлогтой, гэхдээ би ухарч байна. Энд юу чухал вэ: Veeam-аас UNC замд (серверийн лавлах) ямар нэг зүйл бичихийг хүсэхэд сервер нь файлын системийн драйверуудын шатлалыг ашигладаг бөгөөд үүнд mup болон mrxsmb-г оруулдаг. Үүний дагуу эдгээр драйверууд бас алдаа гаргах болно.
Үүнгүйгээр хийж чадахгүй Winsock API. Хэрэв сүлжээгээр ямар нэг зүйл хийх шаардлагатай бол VBR нь Winsock гэгддэг Windows Socket API-ээр дамжуулан ажилладаг. Хэрэв бид лог дээр олон тооны IP:Port харагдвал ийм байна. Албан ёсны баримт бичигт боломжит сайн жагсаалт байдаг .
дээр дурьдсан WMI (Windows Management Instrumentation) нь Windows ертөнц дэх бүх зүйлийг болон хүн бүрийг удирдахад зориулагдсан нэгэн төрлийн хүчирхэг API юм. Жишээлбэл, Hyper-V-тэй ажиллах үед хост руу илгээсэн бараг бүх хүсэлтүүд түүгээр дамждаг. Нэг үгээр бол энэ зүйл үнэхээр орлуулашгүй бөгөөд чадвараараа маш хүчтэй юм. Хаана, юу эвдэрсэнийг олж мэдэхийн тулд WBEMtest.exe-д суурилуулсан хэрэгсэл нь маш их тусалдаг.
Жагсаалтын хамгийн сүүлд, гэхдээ чухал ач холбогдолтой зүйл биш - VSS (Эзлэхүүн сүүдэр хадгалах). Энэ сэдэв нь үүн дээр олон баримт бичиг бичсэнтэй адил барагдашгүй, нууцлаг юм. Сүүдрийн хуулбарыг хамгийн энгийнээр тусгай төрлийн хормын хувилбар гэж ойлгодог бөгөөд энэ нь мөн чанартаа ийм юм. Түүний ачаар та VMware болон Hyper-V дээр бараг бүх зүйлийг програмд нийцүүлэн нөөцлөх боломжтой. Би VSS дээр бага зэрэг шахаж тусдаа нийтлэл гаргах төлөвлөгөөтэй байгаа, гэхдээ та одоо уншихыг оролдож болно. . Зөвхөн болгоомжтой байгаарай, учир нь. VSS-ийг хурдан ойлгохыг оролдох нь тархины гэмтэлд хүргэдэг.
Энэ талаар бид зогсоож магадгүй юм. Би хамгийн үндсэн зүйлсийг тайлбарлах ажлыг дуусгасан гэж үзэж байгаа тул дараагийн бүлэгт бид бүртгэлийг аль хэдийн үзэх болно. Гэхдээ танд асуух зүйл байвал сэтгэгдэл дээр асуугаарай.
Эх сурвалж: www.habr.com