Біз журналдар арқылы ақауларды жою ... болжаудың қызықты әлеміне енуді жалғастырамыз. IN біз негізгі терминдердің мағынасына келістік және Veeam-тің жалпы құрылымын бір көзбен бір қолданба ретінде қарастырдық. Бұл тапсырма журнал файлдары қалай құрылатынын, оларда қандай ақпарат көрсетілетінін және неге олар сыртқы түрін көрсететінін анықтау болып табылады.
Сіздің ойыңызша, бұл «бөренелер» не? Көпшіліктің пікірінше, кез-келген қосымшаның журналдары көбінесе ауланың бір жерінде өсетін, бірақ қажетті сәтте жарқыраған құрышта пайда болатын және барлығын құтқаратын құдіретті тұлғаның рөлін тағайындауы керек. Яғни, оларда әрбір құрамдастағы ең аз қателерден бастап жеке дерекқор транзакцияларына дейін барлығы болуы керек. Қатеден кейін оны қалай түзетуге болатыны бірден жазылды. Мұның бәрі бір-екі мегабайтқа сыйуы керек, артық емес. Бұл жай ғана мәтін! Мәтіндік файлдар ондаған гигабайтты алмайды, мен оны бір жерден естідім!
Сонымен журналдар
Нақты әлемде журналдар тек диагностикалық ақпараттың мұрағаты болып табылады. Ал ол жерде нені сақтау керек, сақтау үшін ақпаратты қайдан алу керек және ол қаншалықты егжей-тегжейлі болуы керек, әзірлеушілердің өздері шешеді. Біреу ҚОСУ / ӨШІРУ деңгейіндегі жазбаларды жүргізу арқылы минимализм жолымен жүреді, ал біреу қол жеткізе алатын барлық нәрсені мұқият тырмалайды. Журнал жүргізу деңгейі деп аталатын таңдау мүмкіндігі бар аралық опция бар болса да, сіз қаншалықты егжей-тегжейлі ақпаратты сақтағыңыз келетінін және қанша дискілік кеңістік бар екенін көрсеткен кезде =) 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 Кб / с 0 Кб / с қарағанда жақсы. 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 қателері туралы жақында ғана бөлек болды .
Енді қарайық Желілер.
Мұнда біз үшін ең қажетті және маңыздының барлығын стандарттан табуға болады Оқиға көру құралы. Бірақ бір тосынсый бар: бұрыннан келе жатқан дәстүр бойынша 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 аналогы ретінде. Өкінішке орай, соншалықты икемді емес: функционалдылыққа көптеген шектеулер, ол хосттың әрбір нұсқасымен жұмыс істемейді және барлық қонақтармен емес.
RPC (Қашықтан процедураны шақыру) Менің ойымша, RPC-қа қатысты қателерді көрмеген WIndows-пен жұмыс істеген бірде-бір адам жоқ. Танымал қате пікірге қарамастан, бұл бір ғана хаттама емес, бірқатар параметрлерді қанағаттандыратын кез келген клиент-сервер протоколы. Дегенмен, журналдарымызда RPC қатесі болса, уақыттың 90% -ы DCOM бөлігі болып табылатын Microsoft RPC қатесі болады (таратылған құрамдас нысан үлгісі). Желіде сіз осы тақырып бойынша құжаттаманың үлкен көлемін таба аласыз, бірақ оның арыстандық үлесі өте ескірген. Бірақ егер тақырыпты зерделеуге деген ықылас болса, мен мақалаларды ұсына аламын , және ұзақ тізім .
Біздің журналдардағы RPC қателерінің негізгі себептері - VBR құрамдастары (мысалы, сервер > прокси) арасында және көбінесе байланыс ақауларына байланысты сәтсіз байланысу әрекеттері.
Барлық топтардың ішіндегі ең жоғарғысы RPC сервері қолжетімді емес (1722) қатесі. Қарапайым тілмен айтқанда, клиент сервермен байланыс орната алмады. Қалай және неге - жалғыз жауап жоқ, бірақ әдетте бұл аутентификациямен немесе 135-ші портқа желіге қол жеткізумен байланысты мәселе. Соңғысы динамикалық порт тағайындалған инфрақұрылымға тән. Бұл тақырып бойынша тіпті бар . Ал Microsoft бар сәтсіздіктің себебін табу.
Екінші ең танымал қате: Соңғы нүкте салыстырушысынан (1753) қол жетімді соңғы нүктелер жоқ. RPC клиенті немесе сервері өзіне портты тағайындай алмады. Әдетте сервер (біздің жағдайда қонақ машинасы) аяқталған тар диапазондағы порттарды динамикалық түрде бөлуге теңшелген кезде орын алады. Егер сіз клиенттік жағынан кірсеңіз (біздің жағдайда, VBR сервері), бұл біздің VeeamVssAgent іске қосылмағанын немесе RPC интерфейсі ретінде тіркелмегенін білдіреді. Бұл тақырыпта да бар .
Ең жақсы 3 RPC қатесін аяқтау үшін RPC функциясын шақыру сәтсіз аяқталды (1726). Байланыс орнатылған болса, бірақ RPC сұраулары өңделмесе пайда болады. Мысалы, біз VSS күйі туралы ақпаратты сұраймыз ( кенет дәл қазір сол жерде көлеңкелі мина жасалып жатыр, біз көтерілуге тырысамыз ) және бізге жауап ретінде үндемеңіз және елемейміз.
Windows Tape Backup API таспа кітапханаларымен немесе дискілермен жұмыс істеу үшін қажет. Бастапқыда айтып өткенімдей: біз өз драйверлерімізді жазып, кейін әр құрылғының қолдауымен қиналудан рахат алмаймыз. Сондықтан, vim-де өз драйверлері жоқ. Барлығы стандартты API арқылы, оның қолдауын аппараттық жабдықтаушылардың өздері жүзеге асырады. Одан да логикалық, солай емес пе?
SMB / CIFS Әдеттегідей, барлығы оларды қатар жазады, дегенмен CIFS (жалпы Интернет файлдық жүйесі) SMB (Сервер хабарлама блогы) жай ғана жеке нұсқасы екенін бәрі есте сақтамайды. Ендеше бұл ұғымдарды жалпылаудың еш айыбы жоқ. Samba қазірдің өзінде 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