Folytatjuk elmerülésünket a találgatások ... a naplók általi hibaelhárítás lenyűgöző világában. BAN BEN megegyeztünk az alapfogalmak jelentésében, és fél szemmel a Veeam általános felépítését egyetlen alkalmazásként néztük meg. Ennek az a feladata, hogy kitaláljuk, hogyan jönnek létre a naplófájlok, milyen információk jelennek meg bennük, és miért néznek ki úgy, ahogy kinéznek.
Szerinted mik ezek a "naplók"? A legtöbbek szerint minden alkalmazás naplójába egyfajta mindenható entitás szerepét kellene beosztani, amely legtöbbször valahol a hátsó udvarban vegetál, de a megfelelő pillanatban a semmiből felbukkan fénylő páncélban, és megment mindenkit. Vagyis az egyes összetevők legkisebb hibáitól kezdve az egyes adatbázis-tranzakciókig mindent tartalmazniuk kell. És úgy, hogy a hiba után egyből ki lett írva, hogyan lehetne másképp javítani. És mindez belefér pár megabájtba, nem több. Ez csak szöveg! A szöveges fájlok nem bírnak több tíz gigabájttal, valahol hallottam!
Tehát a rönkök
A valós világban a naplók csak a diagnosztikai információk archívumát jelentik. És hogy mit kell ott tárolni, honnan szerezhető be a tároláshoz szükséges információ, és mennyire legyen részletes, azt maguk a fejlesztők dönthetik el. Valaki a minimalizmus útját követi az ON / OFF szint nyilvántartásával, valaki pedig szorgalmasan gereblyéz mindent, amit elérhet. Bár van egy köztes opció is az úgynevezett Logging Level kiválasztásával, amikor Ön maga jelzi, hogy milyen részletes információkat szeretne tárolni és mennyi extra lemezterülete van =) A VBR-nek egyébként hat ilyen szintje van. És higgyétek el, nem akarja látni, hogy mi történik a legrészletesebb naplózással, szabad tárhellyel a lemezen.
Bírság. Nagyjából megértettük, hogy mit akarunk megmenteni, de felmerül egy jogos kérdés: honnan szerezzük ezt az információt? Természetesen a belső folyamataink által önmagunk naplózására szolgáló események részét képezzük. De mi a teendő, ha interakció van a külső környezettel? Annak érdekében, hogy ne csússzon a mankók és kerékpárok poklába, a Veeam hajlamos nem találni olyan találmányokat, amelyeket már feltaláltak. Valahányszor van kész API, beépített funkció, könyvtár stb., akkor előnyben részesítjük a kész opciókat, mielõtt elkezdjük elkeríteni csapdáinkat. Bár ez utóbbi is elég. Ezért a naplók elemzésekor fontos megérteni, hogy a hibák oroszlánrésze a harmadik féltől származó API-któl, rendszerhívásoktól és más könyvtáraktól érkező üzenetekre esik. Ebben az esetben a VBR szerepe abban rejlik, hogy ezeket a hibákat a naplófájlokba továbbítsa. A felhasználó fő feladata pedig az, hogy megtanulja megérteni, hogy melyik vonal kitől származik, és miért felelős ez a „ki”. Tehát ha egy hibakód a VBR-naplóból egy MSDN-oldalra visz, az rendben van és helyes.
Ahogy korábban megbeszéltük: Veeam egy úgynevezett SQL-alapú alkalmazás. Ez azt jelenti, hogy minden beállítás, minden információ és általában minden, ami csak a normál működéshez szükséges - mindent az adatbázisában tárol. Innen az egyszerű igazság: ami nincs a naplókban, az nagy valószínűséggel az adatbázisban van. De ez sem egy ezüstgolyó: vannak dolgok, amelyek nem szerepelnek a Veeam komponensek helyi naplójában, sem az adatbázisában. Ezért meg kell tanulnia, hogyan tanulmányozza a gazdagép naplóit, a helyi gép naplóit és minden olyan naplót, amely részt vesz a biztonsági mentési és visszaállítási folyamatban. És az is előfordul, hogy a szükséges információk egyáltalán nem állnak rendelkezésre sehol. Ez az út.
Néhány példa az ilyen API-kra
Ennek a listának nem az a célja, hogy kivételesen teljes legyen, ezért nem kell a végső igazságot keresni benne. Célja csak a termékeinkben használt leggyakoribb harmadik féltől származó API-k és technológiák bemutatása.
Kezdjük VMware.
Első lesz a listán vSphere API. Hitelesítésre, a hierarchia olvasására, pillanatképek készítésére és törlésére, gépekkel kapcsolatos információk lekérésére és még sok másra (nagyon) használják. A megoldás funkcionalitása nagyon széles, ezért a verzióhoz a VMware vSphere API Reference-t tudom ajánlani и . Aktuálisabb verzióknál minden csak a google-ban van.
VIX API. A hypervisor fekete mágiája, amelyre külön van . VMware API a gazdagépen lévő fájlokkal való munkavégzéshez anélkül, hogy hálózaton keresztül csatlakozna hozzájuk. Utolsó megoldás, amikor egy fájlt olyan gépre kell helyezni, amelyhez nincs jobb kommunikációs csatorna. Fájdalom és szenvedés, ha a fájl nagy, és a gazdagép be van töltve. De itt működik az a szabály, hogy még az 56,6 Kb / s is jobb, mint a 0 Kb / s. A Hyper-V-ben ezt a dolgot PowerShell Directnek hívják. De ez csak korábban volt
vSpehere Web Services API A vSphere 6.0-tól kezdődően (körülbelül, mióta ezt az API-t először az 5.5-ös verzióban vezették be) vendéggépekkel működik, és szinte mindenhol kiszorította a VIX-et. Valójában ez egy másik API a vSphere kezelésére. Akit érdekel, annak ajánlom a tanulást kézikönyv.
VDDK (Virtual Disk Development Kit). A könyvtár, amely ebben részben szóba került . Virtuális lemezek olvasására szolgál. Valamikor a VIX része volt, de idővel egy külön termékbe került. De örökösként ugyanazokat a hibakódokat használja, mint a VIX. De valamiért magában az SDK-ban nincs leírás ezekről a hibákról. Emiatt tapasztalati úton kiderült, hogy a VDDK hibák más kódokkal csak egy fordítást jelentenek binárisról decimális kódra. Két részből áll - az első fele a kontextusra vonatkozó dokumentálatlan információ, a második rész pedig a hagyományos VIX / VDDK hibák. Például, ha látjuk:
VDDK error: 21036749815809.Unknown error
Aztán ezt bátran átkonvertáljuk hexadecimálissá, és 132200000001-et kapunk. A 132200 nem informatív elejét egyszerűen eldobjuk, a maradék pedig a mi hibakódunk lesz (VDDK 1: Ismeretlen hiba). A leggyakrabban előforduló VDDK hibákról nemrég volt egy külön .
Most nézzük Ablakok.
Itt minden megtalálható a szabványban, ami számunkra a legszükségesebb és legfontosabb Eseménynapló. De van egy fogás: a Windows a nagy hagyományoknak megfelelően nem a hiba teljes szövegét naplózza, hanem csak a számát. Például az 5-ös hiba a „Hozzáférés megtagadva”, az 1722-es pedig „Az RPC-kiszolgáló nem elérhető”, az 10060-as pedig „A kapcsolat időtúllépése”. Persze jó, ha emlékszel a leghíresebbekre, de mi van az eddig nem látottakkal?
És hogy az élet egyáltalán ne tűnjön méznek, a hibákat hexadecimális formában is tárolják, 0x8007 előtaggal. Például a 0x8007000e valójában 14, elfogyott a memória. Hogy miért és kiért tették ezt, az sötétségbe burkolt rejtély. A hibák teljes listája azonban ingyenesen és SMS nélkül letölthető innen .
Egyébként néha más előtagok is vannak, nem csak a 0x8007. Egy ilyen szomorú helyzetben a HRESULT (eredménykezelő) megértéséhez még mélyebbre kell ásni fejlesztők számára. A hétköznapi életben nem javaslom, hogy ezt tegye, de ha hirtelen a falnak nyomta magát, vagy csak kíváncsi, most már tudja, mit kell tennie.
De a Microsoft elvtársak egy kicsit megsajnáltak minket, és hasznosságot mutattak a világnak . Ez egy kis darab konzol boldogság, amely képes lefordítani a hibakódokat emberre a Google használata nélkül. Ez így működik.
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"Jogos kérdés merül fel: miért nem írjuk be azonnal a visszafejtést a naplókba, hanem hagyjuk meg ezeket a rejtélyes kódokat? A válasz a harmadik féltől származó alkalmazásokban van. Ha magad húzol valamilyen WinAPI hívást, nem nehéz megfejteni a válaszát, mert erre még egy speciális WinAPI hívás is létezik. De ahogy már említettük, minden, ami csak válaszként érkezik hozzánk, bekerül a naplóinkba. És itt a visszafejtéshez folyamatosan figyelni kellene ezt a tudatfolyamot, ki kell húzni belőle a Windows hibás darabokat, dekódolni és visszailleszteni. Legyünk őszinték, nem a legizgalmasabb tevékenység.
Windows fájlkezelő API minden lehetséges módon használható a fájlokkal való munka során. Fájlok létrehozása, törlés, megnyitás írásra, munka attribútumokkal stb., stb.
fent emlitett PowerShell Direct mint a VIX API analógja a Hyper-V világában. Sajnos nem annyira rugalmas: sok a funkcionalitás korlátozása, nem működik a gazdagép minden verziójával és nem minden vendéggel.
RPC (Remote Procedure Call) Szerintem nincs olyan ember, aki dolgozott volna a WIndows-szal, aki ne látott volna RPC-vel kapcsolatos hibákat. A közkeletű tévhit ellenére ez nem egyetlen protokoll, hanem bármely olyan kliens-szerver protokoll, amely számos paramétert kielégít. Ha azonban RPC hiba található a naplóinkban, az esetek 90%-ában a Microsoft RPC hibája lesz, amely a DCOM (Distributed Component Object Model) része. Erről a témáról hatalmas mennyiségű dokumentációt lehet találni a neten, de ennek oroszlánrésze meglehetősen elavult. De ha éles vágy van a téma tanulmányozására, akkor tudok cikkeket ajánlani , és hosszú lista .
A naplóinkban előforduló RPC-hibák fő okai a VBR-összetevők (például kiszolgáló > proxy) közötti kommunikációs kísérletek sikertelenségei, és leggyakrabban kommunikációs problémák.
Az összes csúcs között a legfelső hiba az RPC-kiszolgáló nem érhető el (1722). Egyszerűen fogalmazva, az ügyfél nem tudott kapcsolatot létesíteni a szerverrel. Hogyan és miért - nincs egyértelmű válasz, de általában a hitelesítéssel vagy a 135-ös porthoz való hálózati hozzáféréssel van probléma. Ez utóbbi jellemző a dinamikus portkiosztással rendelkező infrastruktúrákra. Ebben a témában még van . És a Microsoftnak van hogy megtalálja a hiba okát.
A második legnépszerűbb hiba: Nincs több végpont a végpontleképezőből (1753). Az RPC-kliens vagy -kiszolgáló nem tudott portot rendelni magának. Általában akkor fordul elő, amikor a szerver (esetünkben a vendéggép) úgy van beállítva, hogy dinamikusan lefoglalja a portokat egy szűk tartományból, amely véget ért. Ha pedig kliens oldalról (esetünkben a VBR szerverről) jelentkezik be, az azt jelenti, hogy a VeeamVssAgentünk vagy nem indult el, vagy nem volt regisztrálva RPC felületként. Van is ebben a témában .
Nos, a 3 leggyakoribb RPC hiba befejezéséhez emlékezzünk arra, hogy az RPC függvényhívás sikertelen volt (1726). Akkor jelenik meg, ha a kapcsolat létrejött, de az RPC-kéréseket nem dolgozzák fel. Például információt kérünk a VSS állapotáról (hirtelen éppen most készül egy árnyékbánya, és próbálunk felmászni), válaszul pedig csendet és figyelmen kívül hagyást.
Windows Tape Backup API szalagos könyvtárakkal vagy meghajtókkal való munkához szükséges. Ahogy az elején említettem: nincs örömünk saját meghajtóprogramokat írni, majd szenvedni az egyes eszközök támogatásától. Ezért a vimnek nincs saját illesztőprogramja. Mindezt egy szabványos API-n keresztül, amelynek támogatását maguk a hardvergyártók valósítják meg. Sokkal logikusabb, nem?
SMB / CIFS Megszokásból mindenki egymás mellé írja őket, bár nem mindenki emlékszik arra, hogy a CIFS (Common Internet File System) csak az SMB (Server Message Block) privát változata. Nincs tehát semmi baj, ha ezeket a fogalmakat általánosítjuk. A Samba már egy LinuxUnix implementáció, és megvannak a maga sajátosságai, de kitérek. Ami itt fontos: amikor a Veeam azt kéri, hogy írjunk valamit az UNC elérési útjába (szerverkönyvtárba), a szerver a fájlrendszer-illesztőprogramok hierarchiáját használja, beleértve a mup-ot és az mrxsmb-t, hogy a labdába írjon. Ennek megfelelően ezek az illesztőprogramok is hibákat generálnak.
Nem lehet nélküle Winsock API. Ha valamit a hálózaton keresztül kell tenni, a VBR a Windows Socket API-n keresztül működik, amelyet Winsock néven ismertek. Tehát ha egy csomó IP:Portot látunk a naplóban, akkor ez az. A hivatalos dokumentáció jó listát tartalmaz a lehetséges lehetőségekről .
fent emlitett WMI (Windows Management Instrumentation) egyfajta mindenható API, amely mindent és mindenkit kezel a Windows világában. Például, amikor a Hyper-V-vel dolgozik, szinte minden, a gazdagéphez intézett kérés átmegy rajta. Egyszóval a dolog abszolút pótolhatatlan és képességeiben nagyon erős. A beépített WBEMtest.exe eszköz sokat segít abban, hogy segítsen kideríteni, hol és mi tört el.
És az utolsó a listán, de semmiképpen sem a legkevésbé fontos - VSS (Volume Shadow Storage). A téma éppoly kimeríthetetlen és titokzatos, mint amennyi dokumentációt írtak róla. A Shadow Copy a legegyszerűbben a pillanatfelvételek egy speciális típusa, ami lényegében az is. Neki köszönhetően a VMware-ben alkalmazáskonzisztens biztonsági mentéseket készíthet, a Hyper-V-ben pedig szinte mindent. Tervezek egy külön cikket készíteni a VSS-ről némi szorítással, de egyelőre megpróbálhatod elolvasni . Csak óvatosan, mert. a VSS villámgyors megértése agysérüléshez vezethet.
Ezen talán megállhatunk. A legalapvetőbb dolgok kifejtésének feladatát befejezettnek tekintem, így a következő fejezetben már a naplókat nézzük. De ha bármilyen kérdésed van, nyugodtan tedd fel a megjegyzésekben.
Forrás: will.com