Nous continuons notre immersion dans le monde fascinant du dépannage... des journaux. En nous avons convenu de la signification des termes de base et avons jeté un coup d'œil à la structure générale de Veeam en tant qu'application unique. La tâche maintenant est de comprendre comment les fichiers journaux sont générés, quelles informations sont affichées et pourquoi ils ont cet aspect.
Que pensez-vous que soient ces « journaux » ? La plupart des gens estiment qu’un journal d’application doit jouer le rôle d’une entité omnipotente, qui passe la majeure partie du temps dans l’ombre, mais qui, au moment voulu, apparaît de nulle part dans une armure éclatante pour sauver la situation. Cela signifie qu'ils devraient contenir tout, depuis les plus petites erreurs dans chaque composant, jusqu'à des transactions individuelles de la base de données. Et après une erreur, il devrait immédiatement indiquer comment corriger le tir. Tout cela devrait tenir dans quelques mégaoctets, pas plus. Après tout, ce n'est que du texte ! Les fichiers texte ne peuvent pas occuper des dizaines de gigaoctets, j'ai entendu cela quelque part !
Alors, les journaux
Dans le monde réel, les journaux ne sont rien d'autre qu'une archive d'informations diagnostiques. Et ce que l'on y conserve, d'où l'on tire les informations à conserver et à quel niveau de détail, cela revient aux développeurs eux-mêmes. Certains optent pour le minimalisme en ne conservant que les enregistrements de type ON/OFF, tandis que d'autres rassemblent tout ce qu'ils peuvent atteindre. Cependant, il existe aussi une option intermédiaire avec la possibilité de choisir ce que l'on appelle le Logging Level, où vous indiquez vous-même à quel point vous souhaitez conserver des informations détaillées et combien d'espace disque vous avez à votre disposition =) Chez VBR, il existe pas moins de six niveaux, d'ailleurs. Et croyez-moi, vous ne souhaitez pas voir ce qui se passe lors d'une journalisation extrêmement détaillée avec l'espace libre de votre disque.
Bien. Nous avons à peu près compris ce que nous souhaitons conserver, mais une question légitime se pose : d'où obtenir ces informations ? Une partie des événements à enregistrer est bien sûr générée par nos propres processus internes. Mais que faire lorsque des interactions avec un environnement externe se produisent ? Pour ne pas tomber dans un véritable cauchemar d'astuces et de solutions bricolées, Veeam a tendance à ne pas réinventer la roue. Chaque fois qu'il existe déjà une API prête à l'emploi, une fonction intégrée au système, une bibliothèque, etc., nous privilégierons ces options prêtes, avant de commencer à développer nos propres solutions astucieuses. Bien que nous en ayons aussi beaucoup. C'est pourquoi, en analysant les journaux, il est important de comprendre que la majorité des erreurs proviennent des messages des API tierces, des appels systèmes et d'autres bibliothèques. Dans ce cas, le rôle de VBR se limite à faire passer ces erreurs dans les fichiers journaux tels quels. Et la tâche principale de l'utilisateur est d'apprendre à comprendre quelle ligne vient de qui, et pour quoi ce « qui » est responsable. Donc, si le code d'erreur dans le journal VBR vous dirige vers une page MSDN, c'est normal et correct.
Comme convenu précédemment : Veeam est une application dite basée sur SQL. Cela signifie que tous les réglages, toutes les informations et en fait tout ce qui est nécessaire pour un fonctionnement normal est stocké dans sa base de données. D'où la simple vérité : si ce n'est pas dans les journaux, c'est probablement dans la base de données. Mais cela n'est pas une solution miracle : certaines choses ne se trouvent ni dans les journaux locaux des composants de Veeam, ni dans sa base. Par conséquent, il faut apprendre à étudier les journaux de l'hôte, les journaux de la machine locale et tous les journaux de tout ce qui participe au processus de sauvegarde et de restauration. Et il arrive parfois que l'information nécessaire ne soit nulle part. C'est le chemin.
Quelques exemples de telles API
Cette liste n'a pas pour objectif d'être exhaustive, donc ne cherchez pas la vérité ultime dedans. Son but est simplement de montrer les API tierces et les technologies les plus couramment utilisées dans nos produits.
Commençons par VMware.
Le premier de la liste sera vSphere API. Utilisé pour l'authentification, la lecture de la hiérarchie, la création et la suppression de snapshots, la demande d'informations sur les machines et beaucoup (beaucoup) d'autres choses encore. La fonctionnalité de cette solution est très large, donc à tous ceux qui le souhaitent, je recommande la référence de l'API VMware vSphere pour la version et . Pour les versions plus récentes, cela se recherche facilement sur Google.
VIX API. La magie noire de l'hyperviseur, pour laquelle il existe une liste d'erreurs distincte API VMware pour travailler avec des fichiers sur l'hôte sans connexion réseau. C'est une dernière solution de recours, lorsque l'on doit placer un fichier sur une machine sans meilleure option de communication. Cela devient une source de douleur et de souffrance si le fichier est volumineux et que l'hôte est chargé. Mais ici, il existe une règle : même 56,6 Ko/s c'est mieux que 0 Ko/s. Dans Hyper-V, un équivalent s'appelle PowerShell Direct. Cela n'était valable que jusqu'à l'apparition de
vSphere Web Services API . À partir de vSphere 6.0 (en gros, car ce API a été introduit pour la première fois dans la version 5.5) est utilisé pour travailler avec des machines virtuelles et a pratiquement remplacé VIX partout. En fait, c'est un autre API pour la gestion de vSphere. Pour ceux qui sont intéressés, je recommande d'explorer manuel.
VDDK (Virtual Disk Development Kit). Librairie dont on a parlé en partie dans cette . Utilisé pour lire des disques virtuels. Il y a longtemps, il faisait partie de VIX, mais avec le temps, il a été séparé dans un produit autonome. En tant qu'héritier, il utilise les mêmes codes d'erreur que VIX. Cependant, pour une raison quelconque, il n'y a aucune description de ces erreurs dans le SDK lui-même. Il a donc été découvert par expérience que les erreurs VDDK avec d'autres codes ne sont en réalité qu'une traduction d'un code binaire en décimal. Il se compose de deux parties : la première moitié est une information non documentée sur le contexte, et la seconde partie — les erreurs traditionnelles VIX/VDDK. Par exemple, si nous voyons :
Erreur VDDK : 21036749815809. Erreur inconnue
Il faut alors le convertir en hexadécimal et obtenir 132200000001. Le début non informatif 132200 est simplement ignoré, et le reste sera notre code d'erreur (VDDK 1 : Erreur inconnue). Récemment, un document séparé était consacré aux erreurs VDDK les plus courantes .
. Maintenant, examinons Windows.
. Ici, tout ce dont nous avons besoin et qui est important peut être trouvé dans le Visionneur d'événements. Mais il y a un petit problème : par une ancienne tradition, Windows ne journalise pas le texte intégral de l'erreur, mais uniquement son numéro. Par exemple, l'erreur 5 est « Accès refusé », 1722 est « Le serveur RPC n'est pas disponible », et 10060 est « Délai d'attente de connexion dépassé ». Bien sûr, c'est super si tu te souviens des plus courantes, mais comment faire face à celles qui n'ont jamais été vues auparavant ?
Et pour que la vie ne semble pas trop douce, les erreurs sont également stockées en format hexadécimal, avec le préfixe 0x8007. Par exemple, 0x8007000e correspond en réalité à 14, Out of Memory. Pourquoi et pour qui cela a été fait reste un mystère. Cependant, vous pouvez télécharger la liste complète des erreurs gratuitement et sans SMS depuis .
D'ailleurs, on rencontre parfois d'autres préfixes, pas seulement 0x8007. Dans une telle situation triste, pour comprendre le HRESULT (« handle de résultat »), il faut encore approfondir pour les développeurs. Dans la vie quotidienne, je ne vous conseille pas de faire ça, mais si vous êtes pressé ou simplement curieux, maintenant vous savez quoi faire.
Mais les amis chez Microsoft ont montré un certain pardon envers nous en présentant l'outil . C'est un petit morceau de bonheur en console, capable de traduire les codes d'erreur en termes humains sans utiliser Google. Il fonctionne à peu près comme ceci.
C:UsersrootDesktop>err.exe 0x54f
# pour hex 0x54f / décimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Une erreur interne s'est produite.
# en tant qu'HRESULT : Sévérité : SUCCES (0), FACILITY_NULL (0x0), Code 0x54f
# pour hex 0x54f / décimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Une erreur interne s'est produite.
# 2 correspondances trouvées pour "0x54f"La question légitime se pose : pourquoi n'écrivons-nous pas tout de suite les décryptages dans les logs, mais laissons-nous ces codes mystérieux ? La réponse se trouve dans des applications tierces. Lorsque vous déclenchez vous-même un appel WinAPI, déchiffrer sa réponse n'est pas un problème, car il existe même un appel WinAPI spécial à cet effet. Mais comme déjà dit, tous les logs que nous recevons contiennent des réponses. Et pour le décryptage, il faudrait surveiller en permanence ce flux de conscience, en extirpant des morceaux avec des erreurs Windows, les déchiffrer et les réinsérer. Disons-le honnêtement, ce n'est pas l'activité la plus passionnante.
Windows File Management API est utilisé dans toutes sortes d'opérations sur les fichiers. Création de fichiers, suppression, ouverture en écriture, gestion des attributs, et bien d'autres.
Le mentionné ci-dessus PowerShell Direct est l'équivalent de l'API VIX dans le monde de Hyper-V. Malheureusement, il n'est pas aussi flexible : de nombreuses restrictions fonctionnelles, il ne fonctionne pas avec chaque version d'hôte et loin d'être compatible avec tous les invités.
RPC (Remote Procedure Call) Je pense qu'il n'y a pas une seule personne ayant travaillé avec Windows qui n'ait jamais vu d'erreurs liées au RPC. Contrairement à la croyance populaire, ce n'est pas un protocole unique, mais tout protocole client-serveur répondant à certains critères. Cependant, si nous avons une erreur RPC dans nos logs, dans 90 % des cas, il s'agira d'une erreur provenant de Microsoft RPC, qui fait partie de DCOM (Distributed Component Object Model). On peut trouver une vaste documentation sur le sujet sur Internet, mais une grande partie est assez obsolète. Mais si vous souhaitez vraiment étudier le sujet, je peux recommander des articles , et une longue liste .
Les principales raisons de l'apparition des erreurs RPC dans nos logs sont des tentatives infructueuses d'interaction entre les composants VBR (serveur > proxy, par exemple) et le plus souvent en raison de problèmes de communication.
En première position, nous avons l'erreur Le serveur RPC est indisponible (1722). En termes simples, cela signifie que le client n'a pas pu établir de connexion avec le serveur. Il n'y a pas de réponse unique quant à la manière et à la raison, mais cela est généralement dû à un problème d'authentification ou d'accès réseau au port 135. Cela est caractéristique des infrastructures avec attribution dynamique des ports. À ce sujet, il existe même . Et chez Microsoft, il y a pour diagnostiquer les causes de la défaillance.
La deuxième erreur la plus courante est : Il n'y a plus de points de terminaison disponibles à partir du gestionnaire de points de terminaison (1753). Le client ou le serveur RPC n'a pas pu s'attribuer un port. Cela se produit généralement lorsque le serveur (dans notre cas, la machine virtuelle hôte) a été configuré pour une allocation dynamique des ports à partir d'une plage étroite qui est épuisée. Et si l'on considère cela du 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 existe également .
Et pour terminer notre Top 3 des erreurs RPC, rappelons-nous de l'erreur RPC function call failed (1726). Cela apparaît lorsque la connexion a été établie, mais que les requêtes RPC ne sont pas traitées. Par exemple, nous demandons des informations sur l'état du VSS (au cas où une copie de l'ombre serait en cours, et que nous essayons d'y accéder), et en retour, il n'y a rien et nous sommes ignorés.
API de sauvegarde de bande Windows nécessaire pour travailler avec des bibliothèques ou des lecteurs à bande. Comme je l'ai mentionné au début : écrire ses propres pilotes et souffrir ensuite du support de chaque appareil n'est pas du tout un plaisir. C'est pourquoi Veeam n'a pas de pilotes propres. Tout passe par l'API standard, dont le support est assuré par les fournisseurs de matériel. C'est beaucoup plus logique, n'est-ce pas ?
SMB/CIFS Tout le monde a l'habitude de les écrire ensemble, bien que peu de gens se souviennent que CIFS (Common Internet File System) est simplement une version privée de SMB (Server Message Block). Donc, il n'y a rien de mal à généraliser ces concepts. Samba est déjà une implémentation LinuxUnix, et il a ses propres particularités, mais je m'égare. Ce qui est important ici : lorsque Veeam demande d'écrire quelque chose par un chemin UNC (serveur/dossier), le serveur utilise la hiérarchie des pilotes du système de fichiers, y compris mup et mrxsmb, pour écrire sur le partage. Par conséquent, les erreurs seront également générées par ces pilotes.
Il est absolument impossible de se passer de Winsock API. Si quelque chose doit être fait sur le réseau, VBR fonctionne via l'API Windows Socket, communément appelé Winsock. Donc, si nous voyons dans le journal la paire IP:Port, c'est ça. La documentation officielle contient une bonne liste des options possibles. .
Le mentionné ci-dessus WMI (Windows Management Instrumentation) est une API omnipotente pour gérer tout et n'importe quoi dans le monde Windows. Par exemple, lors de l'utilisation d'Hyper-V, presque toutes les requêtes vers l'hôte passent justement par elle. En d'autres termes, c'est une chose tout à fait indispensable et très puissante dans ses possibilités. Dans les tentatives d'aider à déterminer où et quoi s'est cassé, l'outil intégré WBEMtest.exe est très utile.
Et le dernier, mais sûrement pas le moindre, est VSS (Volume Shadow Storage). Ce sujet est aussi infini et mystérieux que la quantité de documentation écrite à son sujet. La copie de sécurité peut être comprise comme un type spécial de snapshot, qui est en fait ce qu'il est. Grâce à elle, il est possible de réaliser des sauvegardes cohérentes des applications dans VMware, et dans Hyper-V, presque tout peut l'être. J'ai l'intention de rédiger un article distinct avec un résumé sur VSS, mais en attendant, vous pouvez essayer de lire . Soyez juste prudent, car essayer de comprendre VSS à la hâte peut entraîner des blessures cérébrales.
Cela suffit, je suppose. Je considère que la tâche d'expliquer les choses les plus basiques est accomplie, donc dans le prochain chapitre, nous examinerons les logs. Mais si vous avez des questions, n'hésitez pas à les poser dans les commentaires.
Source : habr.com
