Folytatjuk merülésünket az izgalmas hibaelhárítás világába a naplókon keresztül. A megegyeztünk az alapvető fogalmak jelentésében, és egy röpke pillantást vetettünk a Veeam általános felépítésére, mint egységes alkalmazásra. A feladat ebben az esetben kideríteni, hogyan állnak össze a naplófájlok, milyen információk találhatók bennük, és miért néznek ki így.
Mit gondol, mi is az a "napló"? A legtöbb véleménye szerint a bármely alkalmazás naplójának olyasvalaminek kell lennie, ami szinte minden időben a háttérben pihen, de a szükséges pillanatban előbukkan a semmiből fénylő páncélban, és mindenkit megment. Tehát tartalmaznia kell mindent, a legkisebb hibáktól minden egyes komponensben, egészen az adatbázis egyedi tranzakcióiig. És ha hiba történik, azonnal ki kell írni, hogyan lehet azt kijavítani. Ennek az egésznek pedig pár megabájtba kellene beleférnie, nem többre. Ez csak szöveg! Nem lehet, hogy a szöveges fájlok évtizedekig tartó gigabájtokat foglaljanak el; valahol ezt hallottam!
Tehát a naplók
a valóságban csak diagnosztikai információk archívuma. Hogy mit tároljunk benne, honnan szerezzük be a tárolandó információkat, és mennyire részletesnek kell lennie, azt maguk a fejlesztők döntik el. Valaki a minimalizmus útján jár, és csak a BE / KI szintű feljegyzéseket tárolja, míg mások mindent gondosan összegyűjtenek, amihez csak hozzáférhetnek. Van egy köztes lehetőség is, ahol választható a „naplózási szint”, amikor saját magad határozod meg, mennyire részletes információt szeretnél tárolni, és mennyi felesleges hely áll rendelkezésedre a merevlemezen =) A VBR-nél egyébként hat ilyen szint van. És hidd el, nem szeretnéd látni, mi történik maximális részletességgel történő naplózáskor, miközben szabad helyed van a merevlemezeden.
Jól van. Körülbelül megértettük, mit szeretnénk megőrizni, de felmerül a jogszerű kérdés: honnan szerezzük ezt az információt? Néhány eseményt a naplózás érdekében természetesen mi magunk formálunk a belső folyamataink révén. De mit tegyünk, amikor kölcsönhatásba lépünk a külső környezettel? Hogy elkerüljük a rémálmot, ami a trükkös megoldásokból és a kezdetleges eszközökből adódik, a Veeam hajlamos nem újra feltalálni a már létező megoldásokat. Mindig, amikor elérhető már kész API, a rendszerbe beépített funkció, könyvtár stb. van, mi előnyben részesítjük a kész változatokat, mielőtt elkezdenénk a saját kifinomult megoldásunkat kidolgozni. Bár ebből is van bőven. Ezért a naplók elemzésekor fontos megérteni, hogy a hibák többsége a harmadik felektől származó API-k, rendszerhívások és egyéb könyvtárak üzeneteiből ered. Ebben az esetben a VBR szerepe, hogy ezeket a hibákat a naplófájlokba továbbítsa, ahogyan vannak. A felhasználó fő feladata pedig, hogy megtanulja, melyik sor kihez tartozik, és kiért felel az az “aki”. Ezért ha a VBR naplóban szereplő hiba kódja az MSDN oldalára vezet, az normális és helyes.
Ahogy korábban megbeszéltük: a Veeam egy úgynevezett SQL-alapú alkalmazás. Ezért minden beállítás, minden információ és igazából minden, ami a normális működéshez szükséges - mindez az adatbázisában tárolódik. Ebből egy egyszerű igazság következik: amit a naplókban nem találunk, azt valószínűleg az adatbázisban megtaláljuk. De ez semmiféle ezüst töltény: vannak olyan dolgok, amelyeknek se a Veeam komponenseinek helyi naplóiban, se az adatbázisában nincsen nyoma. Ezért meg kell tanulni elemzni a gazdagépek naplóit, a helyi gép naplóit és mindent, ami részt vesz a biztonsági mentés és restaurálás folyamatában. Néha pedig előfordul, hogy a szükséges információ sehol sincs. Ilyen az út.
Néhány példa az ilyen API-kra
Ez a lista nem célozza meg, hogy teljeskörű legyen, ezért ne keressük benne az utolsó instanciában lévő igazságot. Célja csupán annyi, hogy megmutassa a leggyakrabban használt harmadik féltől származó API-kat és technológiákat, amelyeket a termékeinkben alkalmazunk.
Kezdjük a VMware..
Az első a listán vSphere API. A hitelesítésre, a hierarchia olvasására, pillanatképek létrehozására és törlésére, gépinformációk lekérésére és sok (nagyon sok) más dologra használják. A megoldás funkciói nagyon széleskörűek, ezért mindenkinek, akit érdekel, ajánlom a VMware vSphere API Reference-t a következő verzióhoz és . Az aktuális verziók egyszerűen kereshetőek a neten.
VIX API. A hipervizor fekete mágiája, amelyhez külön listája van a hibáknak. . VMware API, amely lehetővé teszi a fájlok kezelését a hoszton anélkül, hogy csatlakozni kellene hozzájuk a hálózaton. Az utolsó lehetőség, amikor fájlt kell elhelyezni egy gépen, amelyhez nincs jobb kapcsolat. Fájdalmat és szenvedést okoz, ha a fájl nagy, és a hoszt leterhelt. De itt működik az a szabály, hogy még a 56,6 Kb/s is jobb, mint a 0 Kb/s. A Hyper-V-ben ezt PowerShell Directnek hívják. De ez csak addig volt így, amíg megjelent a
vSphere Web Services API A vSphere 6.0-tól (kb., mivel ezt az API-t először az 5.5-ös verzióban mutatták be) használják a vendéggépek kezelésére, és szinte teljesen kiszorította a VIX-et. Lényegében ez egy újabb API a vSphere kezelésére. Akik érdeklődnek, ajánlom, hogy tanulmányozzák a kézikönyvet.
VDDK (Virtual Disk Development Kit). Könyvtár, amelyről részben szó volt ebben a . Virtuális lemezek olvasására használják. Valaha a VIX része volt, de idővel külön termékké vált. Az örököseként a VIX kódjait használja, 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 csupán a bináris és a tizedestengelyes kód közötti átkonvertálás. Két részből áll – az első felében dokumentálatlan információ található a kontextusról, a második rész pedig a hagyományos VIX/VDDK hibák. Például, ha ezt látjuk:
VDDK error: 21036749815809.Unknown error
Akkor nyugodtan konvertáljuk hexbe, és megkapjuk a 132200000001-et. Az 132200-hoz tartozó nem tájékoztató kezdő részét elvetjük, a maradék pedig a hibakódunk lesz (VDDK 1: Ismeretlen hiba). A leggyakoribb VDDK hibákról nemrégiben külön jelent meg egy .
Most nézzük meg a Windows.
Itt minden szükséges és fontos dolgot megtalálhatunk az alapértelmezett Eseménynaplóban. De van egy bökkenő: a régi hagyomány szerint a Windows nem a teljes hibaüzenetet naplózza, hanem csak a számát. Például, az 5-ös hiba – ez az „Hozzáférés megtagadva”, a 1722 – ez a „Az RPC szerver nem érhető el”, a 10060 pedig a „Kapcsolatidőtúllépés”. Természetesen jó, ha az ember emlékszik a legismertebbekre, de mi a helyzet a korábban még nem látottakkal?
És hogy az élet ne tűnjön túlságosan édesnek, a hibák hexadecimális formában is tárolódnak, 0x8007 előtaggal. Például, 0x8007000e — ez valójában 14, Memória kifogás. Hogy miért és kinek így készült — titok, amelyet a sötétség borít. Azonban a teljes hibalista ingyenesen és SMS nélkül letölthető a .
Egyébként néha más előtagokkal is találkozhatunk, nemcsak a 0x8007-tel. Egy ilyen szomorú helyzetben a HRESULT („result handle”) megértéséhez még mélyebbre kell ásnunk a fejlesztők számára. A normális életben nem tanácsolnám, hogy ilyet csináljon, de ha esetleg sarokba szorult vagy egyszerűen csak érdekli, most már tudja, mit tegyen.
De a Microsoft barátaink kissé megszámták magukat, és bemutattak egy segédprogramot . Ez egy kis darab konzolos boldogság, amely képes a hiba kódokat emberi nyelvre fordítani Google használata nélkül. Így működik körülbelül.
C:UsersrootDesktop>err.exe 0x54f
# hex 0x54f / decimális 1359
ERROR_INTERNAL_ERROR winerror.h
# Belső hiba történt.
# HRESULT: Súlyosság: SIKER (0), FACILITY_NULL (0x0), Kód 0x54f
# hex 0x54f / decimális 1359
ERROR_INTERNAL_ERROR winerror.h
# Belső hiba történt.
# "0x54f"-re 2 találat találhatóJoggal merül fel a kérdés: miért nem írjuk a naplókba azonnal a dekódolást, és hagyjuk ezeket a titokzatos kódokat? A válasz a harmadik féltől származó alkalmazásokban rejlik. Amikor te magad hívsz meg egy WinAPI függvényt, akkor a válaszának dekódolása nem nehéz, hiszen van egy speciális WinAPI hívás erre. De ahogy már említettem, a napjainkban bejövő válaszokból mindent rögzítünk. Itt már a dekódoláshoz folyamatosan figyelni kellene ezt a tudatfolyamot, és ki kellene választani belőle a Windows hibakódokat, dekódolni őket, és visszailleszteni. Mondjuk ki őszintén, nem a legizgalmasabb tevékenység.
Windows File Management API mindenféleképpen használva van a fájlokkal való munka során. Fájlok létrehozása, törlése, írásra való megnyitás, attribútumokkal való munka és még sok egyéb.
A fent említett PowerShell Direct mint a VIX API megfelelője a Hyper-V világában. Sajnos nem annyira rugalmas: számos funkcionális korlátozás, nem minden gazdagépen működik, és nem minden vendég esetében.
RPC (Remote Procedure Call) Azt gondolom, hogy nincs olyan ember, aki Windows-on dolgozott volna, és ne tapasztalta volna meg az RPC-vel kapcsolatos hibákat. A népszerű tévhittel ellentétben ez nem egyetlen protokoll, hanem bármilyen kliens-szerver protokoll, amely megfelel bizonyos paramétereknek. Ha azonban a naplóinkban RPC hiba található, 90%-ban ez a Microsoft RPC hibája, ami a DCOM (Distributed Component Object Model) része. Az interneten hatalmas mennyiségű dokumentáció található erről a témáról, de jelentős része már elavult. De ha van egy égető vágy a téma tanulmányozására, javasolhatom a cikkeket , és egy hosszú lista .
Az RPC hibák legfőbb okai a naplóinkban a VBR komponensei (szerver > proxy, például) közötti interakciók sikertelen kísérletei, és leggyakrabban a kommunikációs problémák miatt.
A legelterjedtebb hiba a The RPC server is unavailable (1722). Egyszerűen fogalmazva, a kliens nem tudott kapcsolatot létesíteni a szerverrel. Az okok és a miértje nincs egységes válasz, de általában hitelesítési vagy 135-ös porti hálózati hozzáférési problémák állnak a háttérben. Ez utóbbi jellemző a dinamikusan portokat kiosztó infrastruktúrákra. Erről még A Microsoftnál pedig van egy a hibák okainak kereséséhez.
A második leggyakoribb hiba: There are no more endpoints available from the endpoint mapper (1753). Az RPC kliens vagy szerver nem tudott portot kiosztani magának. Ez általában akkor fordul elő, amikor a szerver (esetünkben a vendéggép) dinamikus portkiosztásra volt beállítva, de a kiosztáskor a portok véget értek. Ha a kliens oldaláról nézzük (esetünkben a VBR szerver), akkor ez jelenti, hogy a VeeamVssAgent vagy nem indult el, vagy nem lett regisztrálva RPC interfészként. Ezzel kapcsolatban is van .
És hogy befejezzük az RPC hibák Top-3 listáját, említsük meg az RPC function call failed (1726). Ez akkor jelentkezik, ha a kapcsolat már létrejött, de az RPC kérések nem működnek. Például információt kérünk a VSS állapotáról (ki tudja, lehet, éppen most készül a shadow copy, és mi próbálkozunk), és a válasz csend és figyelmen kívül hagyás.
Windows Tape Backup API szükséges a szalagos könyvtárakkal vagy meghajtókkal való munkához. Ahogy az elején említettem: nem okoz örömet saját meghajtókat írni és később szenvedni a különböző eszközök támogatásával. Ezért a Veeam nem rendelkezik saját meghajtókkal. Minden az alapértelmezett API-n keresztül történik, amelyet a hardvergyártók valósítanak meg. Logikusabb, nem igaz?
SMB/CIFS Mindenki szokás szerint közel írja őket, bár nem mindenki emlékszik arra, hogy a CIFS (Common Internet File System) valójában csak a SMB (Server Message Block) egy privát verziója. Szóval semmi rossz nincs ezeknek a fogalmaknak az általánosításában. A Samba már a Linux/Unix megvalósítása, és ott vannak saját jellemzői, de ezzel elkalandoztam. Ami fontos itt: amikor a Veeam kér valamit UNC úton (szerverkönyvtár), a szerver a fájlrendszer meghajtóinak hierarchiáját használja, beleértve a mup-ot és a mrxsmb-t, a megosztásra való íráshoz. Következésképpen ezek a meghajtók generálnak hibákat is.
Nem lehet megkerülni Winsock API. Ha valamit a hálózaton kell megtenni, a VBR a Windows Socket API-n keresztül működik, amely a népnyelvben Winsock néven ismert. Tehát ha egy IP:Port kapcsolódást látunk a naplóban, az ez. A hivatalos dokumentációban van egy meglehetősen jó lista a lehetőségekről. .
A fent említett WMI (Windows Management Instrumentation) — ez egyfajta mindenható API, amely a Windows világában minden és minden irányításhoz szükséges. Például a Hyper-V esetében szinte minden kérés a gazdagéphez rajta keresztül történik. Egyszóval, teljesen nélkülözhetetlen és nagyon erőteljes lehetőségekkel rendelkezik. Azokban a próbálkozásokban, hogy kiderítsük, hol és mi romlott el, nagy segítséget nyújt a beépített eszköz, a WBEMtest.exe.
És a lista végén, de korántsem a legkisebb jelentőséggel bíró — VSS (Volume Shadow Storage). A téma annyira kimeríthetetlen és rejtélyes, ahány dokumentációt írtak róla. A Shadow Copy legkönnyebben úgy érthető, mint egy különleges típusú pillanatkép, ami lényegében az is. Ennek köszönhetően a VMware-ben alkalmazáskonzisztens biztonsági mentéseket lehet készíteni, a Hyper-V-ben pedig szinte mindent. Tervem van, hogy készítsek egy külön cikket a VSS-ről, de addig is megpróbálhatják elolvasni . Csak óvatosan, mert a VSS hirtelen megértése agysérülést okozhat.
Ezen a ponton valószínűleg meg is állhatunk. A legfontosabb alapvető dolgok magyarázatát teljesítve, a következő fejezetben már a naplókra fogunk koncentrálni. De ha maradtak kérdései, ne habozzon feltenni őket a megjegyzésekben.
Forrás: habr.com
