Nous poursuivons notre immersion dans le monde fascinant des devinettes... dépannage par logs. DANS nous nous sommes mis d'accord sur la signification des termes de base et avons considéré la structure globale de Veeam comme une seule application avec un seul œil. La tâche de celui-ci est de comprendre comment les fichiers journaux sont formés, quel type d'informations y sont affichés et pourquoi ils ressemblent à ça.
Que pensez-vous de ces "journaux" ? Selon la plupart, les journaux de toute application devraient se voir attribuer le rôle d'une sorte d'entité omnipotente qui végète la plupart du temps quelque part dans l'arrière-cour, mais au bon moment apparaît de nulle part dans une armure brillante et sauve tout le monde. Autrement dit, ils doivent tout contenir, des moindres erreurs dans chaque composant aux transactions de base de données individuelles. Et pour qu'après l'erreur, il ait été immédiatement écrit comment le réparer autrement. Et tout cela devrait tenir dans quelques mégaoctets, pas plus. Ce n'est que du texte ! Les fichiers texte ne peuvent pas prendre des dizaines de gigaoctets, je l'ai entendu quelque part !
Alors les journaux
Dans le monde réel, les journaux ne sont qu'une archive d'informations de diagnostic. Et ce qu'il faut y stocker, où obtenir des informations pour le stockage et à quel point elles doivent être détaillées, c'est aux développeurs eux-mêmes de décider. Quelqu'un suit la voie du minimalisme en gardant des enregistrements du niveau ON / OFF, et quelqu'un ratisse avec diligence tout ce qu'il peut atteindre. Bien qu'il existe également une option intermédiaire avec la possibilité de sélectionner le soi-disant niveau de journalisation, lorsque vous indiquez vous-même les informations détaillées que vous souhaitez stocker et la quantité d'espace disque supplémentaire dont vous disposez =) VBR a six niveaux de ce type, soit dit en passant. Et, croyez-moi, vous ne voulez pas voir ce qui se passe avec la journalisation la plus détaillée avec de l'espace libre sur votre disque.
Bien. Nous avons à peu près compris ce que nous voulons sauver, mais une question légitime se pose : d'où puiser ces informations ? Bien sûr, nous faisons partie des événements pour nous connecter par nos processus internes. Mais que faire lorsqu'il y a une interaction avec l'environnement extérieur ? Pour ne pas glisser dans un enfer de béquilles et de vélos, Veeam a tendance à ne pas inventer des inventions déjà inventées. Chaque fois qu'il y a une API prête à l'emploi, une fonction intégrée, une bibliothèque, etc., nous donnerons la préférence aux options prêtes à l'emploi avant de commencer à clôturer nos engins. Bien que ce dernier soit également suffisant. Par conséquent, lors de l'analyse des journaux, il est important de comprendre que la part du lion des erreurs tombe sur les messages provenant d'API tierces, d'appels système et d'autres bibliothèques. Dans ce cas, le rôle de VBR se résume à transmettre ces erreurs aux fichiers journaux tels quels. Et la tâche principale de l'utilisateur est d'apprendre à comprendre quelle ligne provient de qui et de quoi ce « qui » est responsable. Donc, si un code d'erreur du journal VBR vous amène à une page MSDN, c'est bien et correct.
Comme convenu précédemment : Veeam est une application dite basée sur SQL. Cela signifie que tous les paramètres, toutes les informations et en général tout ce qui n'est nécessaire qu'au fonctionnement normal - tout est stocké dans sa base de données. D'où la simple vérité : ce qui n'est pas dans les journaux est très probablement dans la base de données. Mais ce n'est pas non plus une solution miracle : certaines choses ne sont pas dans les logs locaux des composants de Veeam, ni dans sa base de données. Par conséquent, vous devez apprendre à étudier les journaux de l'hôte, les journaux de la machine locale et les journaux de tout ce qui est impliqué dans le processus de sauvegarde et de restauration. Et il arrive aussi que les informations nécessaires ne soient disponibles nulle part. C'est le chemin.
Quelques exemples de telles API
Cette liste ne vise pas à être exceptionnellement complète, il n'est donc pas nécessaire d'y chercher la vérité ultime. Son but est uniquement de montrer les API et technologies tierces les plus courantes utilisées dans nos produits.
Commençons par VMware.
Le premier sur la liste sera API vSphere. Utilisé pour l'authentification, la lecture de la hiérarchie, la création et la suppression d'instantanés, la demande d'informations sur les machines, et bien (beaucoup) plus. La fonctionnalité de la solution est très large, je peux donc recommander la référence de l'API VMware vSphere pour la version и . Pour les versions plus récentes, tout est simplement googlé.
API VIX. La magie noire de l'hyperviseur, pour laquelle il existe une . API VMware pour travailler avec des fichiers sur l'hôte sans s'y connecter via le réseau. Une option de dernier recours lorsque vous avez besoin de mettre un fichier dans une machine vers laquelle il n'y a pas de meilleur canal de communication. C'est douloureux et douloureux si le fichier est volumineux et que l'hôte est chargé. Mais ici, la règle fonctionne que même 56,6 Kb / s est meilleur que 0 Kb / s. Dans Hyper-V, cette chose s'appelle PowerShell Direct. Mais ce n'était qu'avant
API de services Web vSphere À partir de vSphere 6.0 (approximativement, depuis que cette API a été introduite pour la première fois sur la version 5.5), elle est utilisée pour fonctionner avec des machines invitées et a supplanté VIX presque partout. En fait, il s'agit d'une autre API pour gérer vSphere. Pour ceux qui sont intéressés, je recommande d'étudier manuel.
VDDKName (Kit de développement de disque virtuel). La bibliothèque, dont il a été question en partie dans ce . Utilisé pour lire les disques virtuels. Il était une fois une partie du VIX, mais au fil du temps, il a été déplacé dans un produit distinct. Mais en tant qu'héritier, il utilise les mêmes codes d'erreur que VIX. Mais pour une raison quelconque, il n'y a aucune description de ces erreurs dans le SDK lui-même. Par conséquent, il a été découvert empiriquement que les erreurs VDDK avec d'autres codes ne sont qu'une traduction du code binaire au code décimal. Il se compose de deux parties - la première moitié est constituée d'informations non documentées sur le contexte et la seconde partie est constituée des erreurs VIX / VDDK traditionnelles. Par exemple, si nous voyons :
VDDK error: 21036749815809.Unknown error
Ensuite, nous convertissons hardiment cela en hexadécimal et obtenons 132200000001. Nous supprimons simplement le début non informatif de 132200, et le reste sera notre code d'erreur (VDDK 1 : erreur inconnue). À propos des erreurs VDDK les plus fréquentes, il y a eu récemment un autre .
Voyons maintenant Les fenêtres.
Ici, tout ce qui est le plus nécessaire et important pour nous se trouve dans la norme Observateur d'événements. Mais il y a un hic : selon une longue tradition, Windows n'enregistre pas le texte complet de l'erreur, mais seulement son numéro. Par exemple, l'erreur 5 est "Accès refusé", et 1722 est "Le serveur RPC n'est pas disponible" et 10060 est "Expiration de la connexion". Bien sûr, c'est bien si vous vous souvenez des plus célèbres, mais qu'en est-il des inédits ?
Et pour que la vie ne ressemble pas du tout à du miel, les erreurs sont également stockées sous forme hexadécimale, avec le préfixe 0x8007. Par exemple, 0x8007000e est en fait 14, mémoire insuffisante. Pourquoi et pour qui cela a été fait est un mystère enveloppé de ténèbres. Cependant, une liste complète des erreurs peut être téléchargée gratuitement et sans SMS à partir de .
Soit dit en passant, il existe parfois d'autres préfixes, pas seulement 0x8007. Dans une situation aussi triste, pour comprendre HRESULT ("result handle"), vous devez approfondir encore plus pour les développeurs. Dans la vie ordinaire, je ne vous conseille pas de faire cela, mais si vous vous êtes soudainement appuyé contre le mur ou êtes simplement curieux, maintenant vous savez quoi faire.
Mais les camarades de Microsoft ont eu un peu pitié de nous et ont montré au monde un utilitaire . C'est un petit morceau de bonheur de console qui peut traduire les codes d'erreur en humain sans utiliser Google. Cela fonctionne comme ça.
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"Une question légitime se pose : pourquoi n'écrit-on pas immédiatement le déchiffrement dans les logs, mais laisse-t-on ces codes mystérieux ? La réponse se trouve dans les applications tierces. Lorsque vous tirez vous-même un appel WinAPI, il n'est pas difficile de déchiffrer sa réponse, car il existe même un appel WinAPI spécial pour cela. Mais comme déjà mentionné, tout ce qui ne nous parvient que dans les réponses entre dans nos journaux. Et ici, pour le décrypter, il faudrait surveiller en permanence ce flux de conscience, en extraire des morceaux contenant des erreurs Windows, les décrypter et les recoller. Soyons honnêtes, ce n'est pas l'activité la plus excitante.
API de gestion de fichiers Windows utilisé de toutes les manières possibles lorsque vous travaillez avec des fichiers. Créer des fichiers, supprimer, ouvrir en écriture, travailler avec des attributs, etc.
Mentionné ci-dessus PowerShell direct comme un analogue de l'API VIX dans le monde Hyper-V. Malheureusement, pas si flexible : beaucoup de restrictions sur les fonctionnalités, cela ne fonctionne pas avec toutes les versions de l'hôte et pas avec tous les invités.
RPC (Appel de procédure à distance) Je ne pense pas qu'il y ait une seule personne qui ait travaillé avec WIndows qui n'ait pas vu les erreurs liées au RPC. Malgré l'idée fausse répandue, il ne s'agit pas d'un protocole unique, mais de tout protocole client-serveur qui satisfait un certain nombre de paramètres. Cependant, s'il y a une erreur RPC dans nos journaux, 90 % du temps, il s'agira d'une erreur de Microsoft RPC, qui fait partie de DCOM (Distributed Component Object Model). Vous pouvez trouver une énorme quantité de documentation sur ce sujet sur le net, mais la part du lion est assez obsolète. Mais s'il y a un vif désir d'étudier le sujet, alors je peux recommander des articles , et longue liste .
Les principales causes d'erreurs RPC dans nos logs sont des tentatives infructueuses de communication entre composants VBR (serveur > proxy, par exemple) et le plus souvent dues à des problèmes de communication.
Le top top parmi tous les tops est l'erreur Le serveur RPC n'est pas disponible (1722). En termes simples, le client n'a pas pu établir de connexion avec le serveur. Comment et pourquoi - il n'y a pas de réponse unique, mais il s'agit généralement d'un problème d'authentification ou d'accès réseau au port 135. Ce dernier est typique des infrastructures avec attribution de port dynamique. Sur ce sujet, il y a même . Et Microsoft a pour trouver la cause de la panne.
Deuxième erreur la plus courante : il n'y a plus de points de terminaison disponibles à partir du mappeur de point de terminaison (1753). Le client ou le serveur RPC n'a pas réussi à s'attribuer un port. Se produit généralement lorsque le serveur (dans notre cas, la machine invitée) a été configuré pour allouer dynamiquement des ports à partir d'une plage étroite qui s'est terminée. Et si vous vous connectez depuis le côté client (dans notre cas, le serveur VBR), cela signifie que notre VeeamVssAgent n'a pas démarré ou n'a pas été enregistré en tant qu'interface RPC. Il y a aussi sur ce sujet .
Eh bien, pour compléter le Top 3 des erreurs RPC, rappelons-nous que l'appel de la fonction RPC a échoué (1726). Apparaît si la connexion a été établie, mais les requêtes RPC ne sont pas traitées. Par exemple, nous demandons des informations sur l'état de VSS (soudain, en ce moment, une mine fantôme y est fabriquée et nous essayons de grimper), et en réponse à nous, silence et ignorance.
API de sauvegarde sur bande Windows nécessaire pour travailler avec des bibliothèques de bandes ou des lecteurs. Comme je l'ai mentionné au début : nous n'avons aucun plaisir à écrire nos propres pilotes et ensuite à souffrir du support de chaque appareil. Par conséquent, vim n'a pas de pilotes propres. Le tout via une API standard, dont le support est mis en œuvre par les fournisseurs de matériel eux-mêmes. Tellement plus logique, non ?
SMB / CIFS Par habitude, tout le monde les écrit côte à côte, même si tout le monde ne se souvient pas que CIFS (Common Internet File System) n'est qu'une version privée de SMB (Server Message Block). Il n'y a donc rien de mal à généraliser ces concepts. Samba est déjà une implémentation LinuxUnix, et elle a ses propres particularités, mais je m'égare. Ce qui est important ici : lorsque Veeam demande d'écrire quelque chose dans le chemin UNC (répertoire du serveur), le serveur utilise la hiérarchie des pilotes du système de fichiers, y compris mup et mrxsmb, pour écrire dans la boule. En conséquence, ces pilotes généreront également des erreurs.
Je ne peux pas m'en passer API Winsock. Si quelque chose doit être fait sur le réseau, VBR fonctionne via l'API Windows Socket, connue sous le nom de Winsock. Donc, si nous voyons un tas d'IP:Port dans le journal, c'est tout. La documentation officielle contient une bonne liste de possibilités .
Mentionné ci-dessus WMI (Windows Management Instrumentation) est une sorte d'API toute-puissante pour gérer tout et tout le monde dans le monde Windows. Par exemple, lorsque vous travaillez avec Hyper-V, presque toutes les requêtes adressées à l'hôte passent par lui. En un mot, la chose est absolument irremplaçable et très puissante dans ses capacités. Dans une tentative d'aider à trouver où et ce qui est cassé, l'outil intégré WBEMtest.exe aide beaucoup.
Et le dernier sur la liste, mais non le moindre en importance - VSS (Stockage d'ombre de volume). Le sujet est aussi inépuisable et mystérieux que beaucoup de documentation a été écrite à ce sujet. Shadow Copy est plus simplement compris comme un type spécial d'instantané, ce qu'il est essentiellement. Grâce à lui, vous pouvez effectuer des sauvegardes cohérentes avec les applications dans VMware, et presque tout dans Hyper-V. J'ai l'intention de faire un article séparé avec quelques pressions sur VSS, mais pour l'instant vous pouvez essayer de lire . Faites juste attention, parce que. essayer de comprendre VSS en un éclair peut entraîner des lésions cérébrales.
Là-dessus, on peut peut-être s'arrêter. Je considère que la tâche d'expliquer les choses les plus élémentaires est terminée, donc dans le chapitre suivant, nous examinerons déjà les journaux. Mais si vous avez des questions, n'hésitez pas à les poser dans les commentaires.
Source: habr.com