Биз логдор аркылуу көйгөйлөрдү аныктоонун ... кызыктуу дүйнөсүнө чөмүлүүнү улантабыз. IN биз негизги терминдердин мааниси боюнча макулдаштык жана Veeamдин жалпы структурасын бир көз менен бир тиркеме катары карадык. Мунун милдети лог файлдары кантип түзүлөөрүн, аларда кандай маалымат көрсөтүлөрүн жана эмне үчүн алар кандай көрүнөрүн аныктоо болуп саналат.
Сиздин оюңузча, бул "журналдар" эмне? Көпчүлүктүн пикири боюнча, ар кандай тиркеменин журналдарына көбүнчө короонун бир жеринде өскөн, бирок керектүү учурда күтүлбөгөн жерден жаркыраган соот менен пайда болуп, бардыгын сактап кала турган кудуреттүү объекттин ролу берилиши керек. Башкача айтканда, алар ар бир компоненттеги кичинекей каталардан тартып жеке маалыматтар базасынын транзакцияларына чейин бардыгын камтышы керек. Ошентип, ката кеткенден кийин, аны дагы кантип оңдоо керектиги дароо жазылган. Мунун баары бир нече мегабайтка туура келиши керек, андан ашык эмес. Бул жөн гана текст! Текст файлдары ондогон гигабайттарды ала албайт, мен аны бир жерден уктум!
Ошентип, журналдар
Чыныгы дүйнөдө журналдар диагностикалык маалыматтын архиви гана. Ал эми ал жерде эмнени сактоо керек, сактоо үчүн маалыматты кайдан алуу керек жана ал канчалык деталдуу болушу керек, аны иштеп чыгуучулардын өздөрү чечет. Кимдир бирөө ON / OFF деңгээлинде жазууларды жүргүзүү менен минимализм жолу менен барат, ал эми кимдир бирөө колунан келгендин баарын кылдаттык менен тырмалайт. Каттоо деңгээли деп аталган нерсени тандоо мүмкүнчүлүгү менен ортоңку вариант бар болсо да, сиз өзүңүз канчалык деталдуу маалыматты сактагыңыз келгенин жана сизде канча кошумча диск мейкиндиги бар экенин көрсөткөнүңүздө =) VBR мындай алты деңгээлге ээ. Жана, мага ишениңиз, сиз дискиңизде бош орун менен эң деталдуу каттоо менен эмне болорун көргүңүз келбейт.
Жакшы. Биз эмнени сактап калгыбыз келет деп болжолдуу түрдө түшүндүк, бирок мыйзамдуу суроо туулат: бул маалыматты кайдан алуу керек? Албетте, биз өзүбүздү ички процесстерибиз менен каттоо үчүн иш-чаралардын бир бөлүгүн түзөбүз. Бирок тышкы чөйрө менен өз ара аракеттенүү болгондо эмне кылуу керек? Балдактардын жана велосипеддердин тозогуна тайып калбоо үчүн, Veeam буга чейин ойлоп табылган ойлоп табууларды ойлоп чыгарбайт. Качан даяр API, орнотулган функция, китепкана ж. Акыркысы да жетиштүү болсо да. Ошондуктан, журналдарды талдоодо, каталардын негизги үлүшү үчүнчү тараптын API'леринен, системалык чалуулардан жана башка китепканалардан келген билдирүүлөргө туура келерин түшүнүү керек. Бул учурда, VBR ролу бул каталарды журнал файлдарына жөнөтүү үчүн төмөндөйт. Ал эми колдонуучунун негизги милдети - бул кайсы линия кимден экенин жана бул "ким" эмне үчүн жооптуу экенин түшүнүүнү үйрөнүү. Демек, VBR журналындагы ката коду сизди MSDN барагына алып барса, бул жакшы жана туура.
Биз мурда макулдашылгандай: Veeam бул SQL негизиндеги тиркеме деп аталган. Бул бардык жөндөөлөр, бардык маалымат жана жалпысынан нормалдуу иштеши үчүн гана зарыл болгон нерселердин бардыгы - анын маалымат базасында сакталат дегенди билдирет. Демек, жөнөкөй чындык: журналдарда жок нерсе маалымат базасында болушу мүмкүн. Бирок бул да күмүш ок эмес: кээ бир нерселер Veeam компоненттеринин жергиликтүү журналдарында да, анын маалымат базасында да жок. Ошондуктан, сиз хост журналдарын, жергиликтүү машинанын журналдарын жана резервдик көчүрүү жана калыбына келтирүү процессине катышкан бардык нерселердин журналдарын изилдөөнү үйрөнүшүңүз керек. Жана ошондой эле зарыл болгон маалымат эч жерде жок болуп калат. Бул жол.
Мындай API'лердин кээ бир мисалдары
Бул тизме өзгөчө толук болууну максат кылбайт, ошондуктан андан акыркы чындыкты издөөнүн кереги жок. Анын максаты - биздин өнүмдөрүбүздө колдонулган эң кеңири таралган үчүнчү жактын API'лерин жана технологияларын көрсөтүү.
менен баштайлы VMware.
Тизмеде биринчи болот vSphere API. Аутентификация, иерархияны окуу, снапшотторду түзүү жана жок кылуу, машиналар жөнүндө маалыматты суроо жана башка көптөгөн нерселер үчүн колдонулат. Чечимдин функционалдуулугу абдан кенен, ошондуктан мен версияга VMware vSphere API шилтемесин сунуш кыла алам и . Көбүрөөк азыркы версиялар үчүн баары жөн гана гуглдан изделген.
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 (Virtual Disk Development Kit). Бул жарым-жартылай талкууланган китепкана . Виртуалдык дисктерди окуу үчүн колдонулат. Бир жолу ал VIXтин бир бөлүгү болгон, бирок убакыттын өтүшү менен ал өзүнчө буюмга көчүрүлгөн. Бирок мураскор катары, ал VIX сыяктуу эле ката коддорун колдонот. Бирок, кандайдыр бир себептерден улам, SDK өзүндө бул каталардын сүрөттөлүшү жок. Демек, башка коддор менен VDDK каталары экилик коддон ондук кодго которуу гана экени эмпирикалык түрдө аныкталган. Ал эки бөлүктөн турат - биринчи жарым контекст жөнүндө документтештирилбеген маалымат, ал эми экинчи бөлүгү салттуу VIX/VDDK каталары. Мисалы, эгерде биз көрө турган болсок:
VDDK error: 21036749815809.Unknown error
Андан кийин биз тайманбастык менен аны он алтылыкка айландырабыз жана 132200000001 алабыз. Биз жөн гана 132200дүн маалыматсыз башталышын жокко чыгарабыз, ал эми калганы биздин ката коду болот (VDDK 1: Белгисиз ката). Көпчүлүк VDDK каталары жөнүндө, жакында эле өзүнчө болгон .
Эми карап көрөлү Windows.
Бул жерде биз үчүн эң керектүү жана маанилүү нерселердин бардыгын стандарттан тапса болот окуя дареги. Бирок бир нерсе бар: көптөн бери келе жаткан салт боюнча, 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 File Management API файлдар менен иштөөдө мүмкүн болгон бардык жолдор менен колдонулат. Файлдарды түзүү, жок кылуу, жазуу үчүн ачуу, атрибуттар менен иштөө ж.б.у.с.
жогоруда айтылган PowerShell Direct Hyper-V дүйнөсүндө VIX API аналогу катары. Тилекке каршы, анчалык ийкемдүү эмес: функциялык чектөөлөр көп, ал бардык коноктор менен эмес, хосттун ар бир версиясы менен иштебейт.
RPC (Алыскы процедураларды чакыруу) Мен RPC менен байланышкан каталарды көрбөгөн WIndows менен иштеген бир дагы адам жок деп ойлойм. Популярдуу туура эмес түшүнүккө карабастан, бул бир эле протокол эмес, бир катар параметрлерди канааттандырган ар кандай кардар-сервер протоколу. Бирок, биздин журналдарыбызда RPC катасы бар болсо, 90% учурда бул DCOM (Distributed Component Object Model) бөлүгү болгон 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 аркылуу, анын колдоосу аппараттык камсыздоочулар тарабынан ишке ашырылат. Логикалуураак, туурабы?
КОИ / CIFS Адаттан тышкары, ар бир адам аларды жанаша жазат, бирок баары CIFS (Жалпы Интернет Файл системасы) SMB (Server Message Block) жеке версиясы экенин эстей бербейт. Демек, бул түшүнүктөрдү жалпылоонун эч кандай жаман жери жок. Samba мурунтан эле LinuxUnix ишке ашыруу болуп саналат жана анын өзүнүн өзгөчөлүктөрү бар, бирок мен чегиндим. Бул жерде эмне маанилүү: Veeam UNC жолуна (serverdirectory) бир нерсе жазууну суранганда, сервер топко жазуу үчүн файл тутумунун драйверлеринин, анын ичинде mup жана mrxsmb иерархиясын колдонот. Демек, бул айдоочулар да каталарды жаратат.
Ансыз кыла албайт Winsock API. Тармак аркылуу бир нерсе кылуу керек болсо, VBR эл арасында Winsock деп аталган Windows Socket API аркылуу иштейт. Ошентип, журналдан бир топ IP: Портту көрсөк, бул. Расмий документтерде мүмкүн болгон жакшы тизме бар .
жогоруда айтылган Екатеринбург (Windows Management Instrumentation) – бул Windows дүйнөсүндөгү бардыгын жана бардыгын башкаруу үчүн кудуреттүү API түрү. Мисалы, Hyper-V менен иштөөдө, хостко келген дээрлик бардык суроо-талаптар ал аркылуу өтөт. Бир сөз менен айтканда, бул нерсе таптакыр алмаштырылгыс жана анын мүмкүнчүлүктөрү боюнча абдан күчтүү. Кайда жана эмне бузулганын табууга жардам берүү үчүн, орнотулган WBEMtest.exe куралы көп жардам берет.
Ал эми тизмеде акыркы, бирок эч кандай мааниге ээ эмес - VSS (Көлөмдүн көлөкөсү). Тема ага көп документтер жазылгандай түгөнгүс жана сырдуу. Shadow Copy эң жөнөкөй сүрөттүн өзгөчө түрү катары түшүнүлөт, чындыгында бул. Анын аркасы менен сиз VMwareде тиркемеге ылайыктуу камдык көчүрмөлөрдү жана Hyper-Vде дээрлик бардыгын жасай аласыз. Мен VSS боюнча бир аз кысып өзүнчө макала жасоону пландап жатам, бирок азыр сиз окууга аракет кылсаңыз болот . Болгону сак бол, анткени. жарк-жылы VSS түшүнүүгө аракет мээнин жаракат алып келиши мүмкүн.
Бул боюнча, балким, биз токтото алабыз. Мен эң негизги нерселерди түшүндүрүү тапшырмасын аяктады деп эсептейм, ошондуктан кийинки бөлүмдө биз журналдарды карап чыгабыз. Бирок кандайдыр бир суроолоруңуз болсо, аларды комментарийлерде сураңыз.
Source: www.habr.com