Continuem la nostra immersió en el fascinant món de les endevinalles... la resolució de problemes mitjançant registres. EN vam coincidir en el significat dels termes bàsics i vam mirar l'estructura general de Veeam com una única aplicació amb un sol ull. La tasca d'aquest és esbrinar com es formen els fitxers de registre, quin tipus d'informació es mostra en ells i per què es veuen com es veuen.
Què creus que són aquests "logs"? Segons la majoria, els registres de qualsevol aplicació s'haurien d'assignar el paper d'una mena d'entitat omnipotent que la majoria de les vegades vegeta en algun lloc del pati del darrere, però en el moment adequat apareix del no-res amb una armadura brillant i salva a tothom. És a dir, haurien de contenir tot, des dels més mínims errors de cada component fins a transaccions individuals de bases de dades. I de manera que després de l'error es va escriure immediatament com solucionar-lo. I tot això hauria de cabre en un parell de megabytes, no més. Només és text! Els fitxers de text no poden tenir desenes de gigabytes, ho he sentit en algun lloc!
Així els registres
Al món real, els registres són només un arxiu d'informació de diagnòstic. I què emmagatzemar allà, on obtenir informació per a l'emmagatzematge i el detall que hauria de ser, depèn dels mateixos desenvolupadors. Algú segueix el camí del minimalisme mantenint registres del nivell ON / OFF i algú rastreja amb diligència tot el que pot arribar. Tot i que també hi ha una opció intermèdia amb la possibilitat de seleccionar l'anomenat Nivell de registre, quan tu mateix indiques la informació detallada que vols emmagatzemar i quant espai de disc addicional tens =) VBR té sis nivells, per cert. I, creieu-me, no voleu veure què passa amb el registre més detallat amb espai lliure al vostre disc.
Bé. Vam entendre aproximadament què volem estalviar, però sorgeix una pregunta legítima: d'on aconseguir aquesta informació? Per descomptat, formem part dels esdeveniments per registrar-nos pels nostres processos interns. Però què fer quan hi ha una interacció amb l'entorn extern? Per no caure en un infern de crosses i bicicletes, Veeam acostuma a no inventar invents que ja s'han inventat. Sempre que hi hagi una API preparada, una funció integrada, una biblioteca, etc., donarem preferència a les opcions ja fetes abans de començar a tancar els nostres enginys. Encara que amb això últim també n'hi ha prou. Per tant, a l'hora d'analitzar els registres, és important entendre que la major part d'errors recau en missatges d'API de tercers, trucades al sistema i altres biblioteques. En aquest cas, el paper de VBR es redueix a reenviar aquests errors als fitxers de registre tal com estan. I la tasca principal de l'usuari és aprendre a entendre quina línia és de qui i de què és responsable aquest "qui". Per tant, si un codi d'error del registre VBR us porta a una pàgina MSDN, està bé i correcte.
Com vam acordar anteriorment: Veeam és una anomenada aplicació basada en SQL. Això vol dir que tota la configuració, tota la informació i, en general, tot el que només és necessari per al funcionament normal: tot s'emmagatzema a la seva base de dades. D'aquí la simple veritat: el que no està als registres és més probable que estigui a la base de dades. Però això tampoc és una bala de plata: algunes coses no es troben als registres locals dels components de Veeam, ni a la seva base de dades. Per tant, cal aprendre a estudiar els registres de l'amfitrió, els registres de la màquina local i els registres de tot el que està implicat en el procés de còpia de seguretat i restauració. I també passa que la informació necessària no està disponible enlloc. Aquest és el camí.
Alguns exemples d'aquestes API
Aquesta llista no pretén ser excepcionalment completa, de manera que no cal buscar-hi la veritat definitiva. El seu propòsit és només mostrar les API i tecnologies de tercers més habituals que s'utilitzen als nostres productes.
Comencem VMware.
El primer de la llista serà API de vSphere. S'utilitza per a l'autenticació, llegir la jerarquia, crear i suprimir instantànies, sol·licitar informació sobre màquines i molt (molt) més. La funcionalitat de la solució és molt àmplia, així que puc recomanar la VMware vSphere API Reference per a la versió и . Per a les versions més actuals, tot es cerca a Google.
API VIX. La màgia negra de l'hipervisor, per a la qual hi ha una separació . API de VMware per treballar amb fitxers a l'amfitrió sense connectar-s'hi a través de la xarxa. Una variant d'últim recurs quan cal posar un fitxer en una màquina a la qual no hi ha millor canal de comunicació. És dolor i patiment si el fitxer és gran i l'amfitrió està carregat. Però aquí funciona la regla que fins i tot 56,6 Kb/s és millor que 0 Kb/s. A Hyper-V, aquesta cosa s'anomena PowerShell Direct. Però això només era abans
API de serveis web de vSpehere A partir de vSphere 6.0 (aproximadament, des que aquesta API es va introduir per primera vegada a la versió 5.5) s'utilitza per treballar amb màquines convidades i ha suplantat a VIX gairebé a tot arreu. De fet, aquesta és una altra API per gestionar vSphere. Als que hi estiguin interessats, recomano estudiar manual.
VDDK (Kit de desenvolupament de disc virtual). La biblioteca, que es va parlar parcialment en aquest . S'utilitza per llegir discos virtuals. Hi havia una vegada que formava part del VIX, però amb el temps es va traslladar a un producte separat. Però com a hereu, utilitza els mateixos codis d'error que VIX. Però per alguna raó, no hi ha cap descripció d'aquests errors al mateix SDK. Per tant, es va descobrir empíricament que els errors VDDK amb altres codis són només una traducció del codi binari al decimal. Consta de dues parts: la primera meitat és informació no documentada sobre el context i la segona part són els errors tradicionals de VIX / VDDK. Per exemple, si veiem:
VDDK error: 21036749815809.Unknown error
Aleshores ho convertim a hexadecimal i obtenim 132200000001. Simplement descartem l'inici no informatiu de 132200, i la resta serà el nostre codi d'error (VDDK 1: error desconegut). Sobre els errors VDDK més freqüents, recentment hi ha hagut un separat .
Ara mirem-ho Finestres.
Aquí, tot el que és més necessari i important per a nosaltres es pot trobar a la norma Visor de successos. Però hi ha un problema: segons una llarga tradició, Windows no registra el text complet de l'error, sinó només el seu número. Per exemple, l'error 5 és "Accés denegat" i 1722 és "El servidor RPC no està disponible" i 10060 és "Connexió esgotada". Per descomptat, està molt bé si recordes les més famoses, però què passa amb les inèdites?
I perquè la vida no sembli gens mel, els errors també s'emmagatzemen en forma hexadecimal, amb el prefix 0x8007. Per exemple, 0x8007000e és en realitat 14, sense memòria. Per què i per a qui es va fer això és un misteri envoltat de foscor. No obstant això, una llista completa d'errors es pot descarregar de forma gratuïta i sense SMS .
Per cert, de vegades hi ha altres prefixos, no només 0x8007. En una situació tan trista, per entendre HRESULT ("control de resultats"), cal aprofundir encara més en per a desenvolupadors. A la vida normal, no t'aconsello que facis això, però si de sobte et pressiones contra la paret o només tens curiositat, ara ja saps què fer.
Però els companys de Microsoft es van apiadar una mica de nosaltres i van mostrar al món una utilitat . Aquesta és una petita part de la felicitat de la consola que pot traduir codis d'error en humans sense utilitzar Google. Funciona així.
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"Sorgeix una pregunta legítima: per què no escrivim immediatament el desxifrat als registres, sinó que deixem aquests codis misteriosos? La resposta es troba en aplicacions de tercers. Quan feu una trucada WinAPI vosaltres mateixos, no és difícil desxifrar-ne la resposta, perquè fins i tot hi ha una trucada WinAPI especial per a això. Però, com ja s'ha esmentat, tot el que només ens arriba a les respostes entra als nostres registres. I aquí, per desxifrar-lo, caldria controlar constantment aquest corrent de consciència, treure'n peces amb errors de Windows, desxifrar-los i tornar-los a enganxar. Siguem sincers, no és l'activitat més emocionant.
API de gestió de fitxers de Windows utilitzat de totes les maneres possibles quan es treballa amb fitxers. Crear fitxers, suprimir, obrir per escriure, treballar amb atributs, etc., etc.
esmentat més amunt PowerShell Direct com a anàleg de l'API VIX al món Hyper-V. Malauradament, no és tan flexible: moltes restriccions sobre la funcionalitat, no funciona amb totes les versions de l'amfitrió i no amb tots els convidats.
RPC (Trucada de procediment remot) No crec que hi hagi una sola persona que hagi treballat amb WIndows que no hagi vist errors relacionats amb RPC. Malgrat la concepció errònia popular, no es tracta d'un protocol únic, sinó de qualsevol protocol client-servidor que compleixi una sèrie de paràmetres. Tanmateix, si hi ha un error RPC als nostres registres, el 90% del temps serà un error de Microsoft RPC, que forma part de DCOM (Distributed Component Object Model). Podeu trobar una gran quantitat de documentació sobre aquest tema a la xarxa, però la part del lleó està força obsoleta. Però si hi ha un agut desig d'estudiar el tema, puc recomanar articles , i llarga llista .
Les principals causes dels errors RPC als nostres registres són els intents fallits de comunicar-se entre components de VBR (servidor > proxy, per exemple) i sovint a causa de problemes de comunicació.
La part superior entre totes les primeres és l'error El servidor RPC no està disponible (1722). En termes simples, el client no podria establir una connexió amb el servidor. Com i per què: no hi ha una única resposta, però normalment es tracta d'un problema d'autenticació o d'accés a la xarxa al port 135. Aquest últim és típic per a infraestructures amb assignació de port dinàmica. Sobre aquest tema, fins i tot n'hi ha . I Microsoft ho té per trobar la causa del fracàs.
Segon error més popular: no hi ha més punts finals disponibles des del mapeador de punts finals (1753). El client o servidor RPC no s'ha pogut assignar un port. Normalment es produeix quan el servidor (en el nostre cas, la màquina convidada) s'ha configurat per assignar dinàmicament ports d'un rang reduït que ha acabat. I si inicieu sessió des del costat del client (en el nostre cas, el servidor VBR), això vol dir que el nostre VeeamVssAgent no es va iniciar o no estava registrat com a interfície RPC. També n'hi ha sobre aquest tema .
Bé, per completar els 3 errors RPC principals, recordem que la trucada a la funció RPC ha fallat (1726). Apareix si la connexió s'ha establert, però les sol·licituds RPC no es processen. Per exemple, demanem informació sobre l'estat del VSS (de sobte ara mateix s'hi està fent una mina d'ombra, i estem intentant escalar), i en resposta a nosaltres, silenci i ignorem.
API de còpia de seguretat de cinta de Windows necessari per treballar amb biblioteques de cintes o unitats. Com he comentat al principi: no tenim cap plaer a escriure els nostres propis controladors i després patir amb el suport de cada dispositiu. Per tant, vim no té cap controlador propi. Tot a través d'una API estàndard, el suport de la qual és implementat pels mateixos venedors de maquinari. Molt més lògic, oi?
SMB / CIFS Per costum, tothom les escriu una al costat de l'altra, encara que no tothom recorda que CIFS (Common Internet File System) és només una versió privada de SMB (Server Message Block). Per tant, no hi ha res dolent a generalitzar aquests conceptes. Samba ja és una implementació de LinuxUnix i té les seves pròpies peculiaritats, però em digresso. El que és important aquí: quan Veeam demana que escrigui alguna cosa al camí UNC (directori del servidor), el servidor utilitza la jerarquia dels controladors del sistema de fitxers, inclosos mup i mrxsmb, per escriure a la bola. En conseqüència, aquests controladors també generaran errors.
No es pot prescindir API Winsock. Si cal fer alguna cosa a la xarxa, VBR funciona mitjançant l'API de Windows Socket, coneguda popularment com Winsock. Per tant, si veiem un munt d'IP:Port al registre, això és tot. La documentació oficial té una bona llista de possibles .
esmentat més amunt WMI (Windows Management Instrumentation) és una mena d'API totpoderosa per gestionar-ho tot i tothom al món Windows. Per exemple, quan es treballa amb Hyper-V, gairebé totes les sol·licituds a l'amfitrió hi passen. En una paraula, la cosa és absolutament insubstituïble i molt potent en les seves capacitats. En un intent d'ajudar a esbrinar on i què està trencat, l'eina integrada WBEMtest.exe ajuda molt.
I l'últim de la llista, però no menys important en importància: VSS (emmagatzematge d'ombres de volum). El tema és tan inesgotable i misteriós com molta documentació s'hi ha escrit. La còpia d'ombra s'entén més simplement com un tipus especial d'instantània, que en essència és. Gràcies a ell, podeu fer còpies de seguretat coherents amb les aplicacions a VMware i gairebé tot a Hyper-V. Tinc plans per fer un article separat amb una mica de pressió sobre VSS, però de moment podeu provar de llegir . Només aneu amb compte, perquè. tractar d'entendre el VSS en un instant pot provocar una lesió cerebral.
En això, potser, podem aturar-nos. Considero finalitzada la tasca d'explicar les coses més bàsiques, així que en el proper capítol ja mirarem els registres. Però si teniu cap pregunta, no dubteu a fer-les als comentaris.
Font: www.habr.com