Wir tauchen weiter in die faszinierende Welt des Ratens ein ... Fehlerbehebung durch Protokolle. IN Wir waren uns über die Bedeutung der Grundbegriffe einig und betrachteten die Gesamtstruktur von Veeam als einzelne Anwendung mit einem Auge. Die Aufgabe besteht darin, herauszufinden, wie Protokolldateien erstellt werden, welche Art von Informationen darin angezeigt werden und warum sie so aussehen, wie sie aussehen.
Was sind Ihrer Meinung nach diese „Protokolle“? Nach Ansicht der meisten sollte den Protokollen jeder Anwendung die Rolle einer Art allmächtiger Entität zugeschrieben werden, die die meiste Zeit irgendwo im Hinterhof vor sich hin vegetiert, aber im richtigen Moment aus dem Nichts in glänzender Rüstung auftaucht und alle rettet. Das heißt, sie sollten alles enthalten, vom kleinsten Fehler in jeder Komponente bis hin zu einzelnen Datenbanktransaktionen. Und so wurde nach dem Fehler sofort geschrieben, wie man ihn sonst beheben kann. Und das alles sollte in ein paar Megabyte passen, nicht mehr. Es ist nur Text! Textdateien können nicht mehrere zehn Gigabyte groß sein, das habe ich irgendwo gehört!
Also die Protokolle
In der realen Welt sind Protokolle lediglich ein Archiv mit Diagnoseinformationen. Und was dort gespeichert wird, woher die Informationen zur Speicherung kommen und wie detailliert diese sein sollen, bleibt den Entwicklern selbst überlassen. Jemand folgt dem Weg des Minimalismus, indem er Aufzeichnungen über den EIN/AUS-Pegel führt, und jemand harkt fleißig alles, was er erreichen kann. Es gibt zwar auch eine Zwischenoption mit der Möglichkeit, den sogenannten Logging-Level auszuwählen, wenn Sie selbst angeben, wie detaillierte Informationen Sie speichern möchten und wie viel zusätzlicher Speicherplatz Sie haben =) VBR hat übrigens sechs solcher Level. Und glauben Sie mir, Sie möchten nicht sehen, was mit der detailliertesten Protokollierung mit freiem Speicherplatz auf Ihrer Festplatte passiert.
Bußgeld. Wir haben ungefähr verstanden, was wir speichern wollen, aber es stellt sich die berechtigte Frage: Woher bekommen wir diese Informationen? Selbstverständlich beteiligen wir uns an den Ereignissen zur Protokollierung selbst durch unsere internen Prozesse. Doch was tun, wenn es zu einer Interaktion mit der äußeren Umgebung kommt? Um nicht in die Hölle aus Krücken und Fahrrädern abzurutschen, neigt Veeam dazu, keine Erfindungen zu erfinden, die bereits erfunden wurden. Wann immer es eine fertige API, integrierte Funktion, Bibliothek usw. gibt, werden wir vorgefertigten Optionen den Vorzug geben, bevor wir mit der Eingrenzung unserer Geräte beginnen. Obwohl Letzteres auch ausreicht. Daher ist es bei der Analyse von Protokollen wichtig zu verstehen, dass der Löwenanteil der Fehler auf Nachrichten von Drittanbieter-APIs, Systemaufrufen und anderen Bibliotheken zurückzuführen ist. In diesem Fall besteht die Rolle von VBR darin, diese Fehler an die unveränderten Protokolldateien weiterzuleiten. Und die Hauptaufgabe des Benutzers besteht darin, zu verstehen, welche Zeile von wem stammt und wofür dieses „Wer“ verantwortlich ist. Wenn Sie also über einen Fehlercode aus dem VBR-Protokoll zu einer MSDN-Seite weitergeleitet werden, ist das in Ordnung und richtig.
Wie wir uns bereits vorher einig waren: Veeam ist eine sogenannte SQL-basierte Anwendung. Das bedeutet, dass alle Einstellungen, alle Informationen und generell alles, was nur für den normalen Betrieb notwendig ist – alles in seiner Datenbank gespeichert ist. Daher die einfache Wahrheit: Was nicht in den Protokollen steht, befindet sich höchstwahrscheinlich in der Datenbank. Aber auch das ist kein Allheilmittel: Einige Dinge sind weder in den lokalen Protokollen der Veeam-Komponenten noch in deren Datenbank enthalten. Daher müssen Sie lernen, die Host-Protokolle, die Protokolle des lokalen Computers und die Protokolle aller am Sicherungs- und Wiederherstellungsprozess beteiligten Elemente zu studieren. Und es kommt auch vor, dass die notwendigen Informationen nirgendwo verfügbar sind. Das ist der Weg.
Einige Beispiele für solche APIs
Diese Liste erhebt keinen Anspruch auf Vollständigkeit, sodass es nicht nötig ist, darin nach der ultimativen Wahrheit zu suchen. Ihr Zweck besteht lediglich darin, die gängigsten APIs und Technologien von Drittanbietern anzuzeigen, die in unseren Produkten verwendet werden.
Beginnen wir mit VMware.
Der erste auf der Liste wird sein vSphere-API. Wird für die Authentifizierung, das Lesen der Hierarchie, das Erstellen und Löschen von Snapshots, das Anfordern von Informationen über Maschinen und vieles mehr verwendet. Der Funktionsumfang der Lösung ist sehr umfangreich, daher kann ich für die Version die VMware vSphere API Reference empfehlen и . Für aktuellere Versionen wird einfach alles gegoogelt.
VIX-API. Die schwarze Magie des Hypervisors, für den es einen eigenen gibt . VMware-API zum Arbeiten mit Dateien auf dem Host, ohne über das Netzwerk eine Verbindung zu ihnen herzustellen. Ein letzter Ausweg, wenn Sie eine Datei auf einem Computer ablegen müssen, zu dem es keinen besseren Kommunikationskanal gibt. Es ist schmerzhaft und leidvoll, wenn die Datei groß ist und der Host geladen ist. Aber hier gilt die Regel, dass sogar 56,6 Kb/s besser sind als 0 Kb/s. In Hyper-V heißt dieses Ding PowerShell Direct. Aber das war nur vorher
vSpehere Web Services-API Ab vSphere 6.0 (ungefähr seit der Einführung dieser API in Version 5.5) wird sie für die Arbeit mit Gastmaschinen verwendet und hat VIX fast überall verdrängt. Tatsächlich handelt es sich hierbei um eine weitere API zur Verwaltung von vSphere. Interessierten empfehle ich ein Studium Handbuch.
VDDK (Virtual Disk Development Kit). Die Bibliothek, die hier teilweise besprochen wurde . Wird zum Lesen virtueller Festplatten verwendet. Früher war es Teil des VIX, aber im Laufe der Zeit wurde es in ein separates Produkt verschoben. Als Erbe verwendet es jedoch dieselben Fehlercodes wie VIX. Aber aus irgendeinem Grund gibt es im SDK selbst keine Beschreibung dieser Fehler. Daher wurde empirisch herausgefunden, dass VDDK-Fehler bei anderen Codes lediglich eine Übersetzung vom Binär- in den Dezimalcode sind. Es besteht aus zwei Teilen – die erste Hälfte enthält undokumentierte Informationen über den Kontext und der zweite Teil enthält die traditionellen VIX/VDDK-Fehler. Wenn wir zum Beispiel sehen:
VDDK error: 21036749815809.Unknown error
Dann wandeln wir dies mutig in Hex um und erhalten 132200000001. Wir verwerfen einfach den nicht aussagekräftigen Anfang von 132200 und der Rest wird unser Fehlercode sein (VDDK 1: Unbekannter Fehler). Zu den häufigsten VDDK-Fehlern gab es erst kürzlich eine eigene .
Schauen wir uns jetzt an Windows.
Hier findet sich in der Norm alles, was für uns am notwendigsten und wichtigsten ist Ereignisanzeige. Doch es gibt einen Haken: Einer langen Tradition zufolge protokolliert Windows nicht den vollständigen Text des Fehlers, sondern nur dessen Nummer. Beispiel: Fehler 5 lautet „Zugriff verweigert“, 1722 lautet „Der RPC-Server ist nicht verfügbar“ und 10060 lautet „Zeitüberschreitung der Verbindung“. Natürlich ist es toll, wenn man sich an die berühmtesten erinnert, aber was ist mit den bisher Ungesehenen?
Und damit das Leben überhaupt nicht wie Honig aussieht, werden Fehler auch in hexadezimaler Form mit dem Präfix 0x8007 gespeichert. Beispielsweise ist 0x8007000e tatsächlich 14, nicht genügend Speicher. Warum und für wen dies geschah, ist ein in Dunkelheit gehülltes Geheimnis. Eine vollständige Fehlerliste kann jedoch kostenlos und ohne SMS heruntergeladen werden von .
Übrigens gibt es manchmal auch andere Präfixe, nicht nur 0x8007. Um HRESULT („Ergebnishandle“) zu verstehen, müssen Sie in solch einer traurigen Situation noch tiefer eintauchen für Entwickler. Im normalen Leben rate ich Ihnen davon ab, aber wenn Sie sich plötzlich an die Wand drücken oder einfach nur neugierig sind, wissen Sie jetzt, was zu tun ist.
Aber die Genossen bei Microsoft hatten ein wenig Mitleid mit uns und zeigten der Welt einen Nutzen . Dies ist ein kleines Stück Konsolenglück, mit dem Fehlercodes ohne Verwendung von Google in Menschen übersetzt werden können. Es funktioniert so.
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"Es stellt sich die berechtigte Frage: Warum schreiben wir die Entschlüsselung nicht sofort in die Protokolle, sondern belassen diese mysteriösen Codes? Die Antwort liegt in Anwendungen von Drittanbietern. Wenn Sie selbst einen WinAPI-Aufruf abrufen, ist es nicht schwer, dessen Antwort zu entschlüsseln, da es dafür sogar einen speziellen WinAPI-Aufruf gibt. Aber wie bereits erwähnt, landet alles, was nur an Antworten zu uns kommt, in unseren Protokollen. Und hier müsste man, um es zu entschlüsseln, diesen Bewusstseinsstrom ständig überwachen, Teile mit Windows-Fehlern daraus herausziehen, entschlüsseln und wieder einfügen. Seien wir ehrlich, nicht die aufregendste Aktivität.
Windows-Dateiverwaltungs-API wird bei der Arbeit mit Dateien auf jede erdenkliche Weise verwendet. Dateien erstellen, löschen, zum Schreiben öffnen, mit Attributen arbeiten und so weiter und so weiter.
Oben erwähnt PowerShell Direct als Analogon der VIX-API in der Hyper-V-Welt. Leider nicht so flexibel: viele Einschränkungen in der Funktionalität, es funktioniert nicht mit jeder Version des Hosts und nicht mit allen Gästen.
RPC (Remote Procedure Call) Ich glaube nicht, dass es eine einzige Person gibt, die mit Windows gearbeitet hat und nicht RPC-bezogene Fehler gesehen hat. Trotz des weit verbreiteten Missverständnisses handelt es sich hierbei nicht um ein einzelnes Protokoll, sondern um ein beliebiges Client-Server-Protokoll, das eine Reihe von Parametern erfüllt. Wenn in unseren Protokollen jedoch ein RPC-Fehler auftritt, handelt es sich in 90 % der Fälle um einen Fehler von Microsoft RPC, das Teil von DCOM (Distributed Component Object Model) ist. Zu diesem Thema findet man im Internet eine Menge Dokumentation, der Löwenanteil davon ist jedoch ziemlich veraltet. Wenn jedoch ein akuter Wunsch besteht, sich mit dem Thema zu befassen, kann ich Artikel empfehlen , und lange Liste .
Die Hauptursachen für RPC-Fehler in unseren Protokollen sind fehlgeschlagene Kommunikationsversuche zwischen VBR-Komponenten (z. B. Server > Proxy) und meist Kommunikationsprobleme.
Das Top-Top unter allen Tops ist der Fehler Der RPC-Server ist nicht verfügbar (1722). Vereinfacht ausgedrückt konnte der Client keine Verbindung zum Server herstellen. Wie und warum – darauf gibt es keine einheitliche Antwort, meist handelt es sich jedoch um ein Problem bei der Authentifizierung oder beim Netzwerkzugriff auf Port 135. Letzteres ist typisch für Infrastrukturen mit dynamischer Portzuweisung. Zu diesem Thema gibt es sogar . Und Microsoft hat um die Ursache des Fehlers zu finden.
Zweithäufigster Fehler: Im Endpoint Mapper sind keine Endpunkte mehr verfügbar (1753). Der RPC-Client oder -Server konnte sich keinen Port zuweisen. Tritt normalerweise auf, wenn der Server (in unserem Fall der Gastcomputer) so konfiguriert wurde, dass er Ports aus einem engen, abgelaufenen Bereich dynamisch zuweist. Und wenn Sie sich von der Client-Seite (in unserem Fall vom VBR-Server) anmelden, bedeutet dies, dass unser VeeamVssAgent entweder nicht gestartet wurde oder nicht als RPC-Schnittstelle registriert war. Gibt es auch zu diesem Thema .
Um die Top 3 der RPC-Fehler zu vervollständigen, erinnern wir uns an den fehlgeschlagenen RPC-Funktionsaufruf (1726). Erscheint, wenn die Verbindung hergestellt wurde, RPC-Anfragen jedoch nicht verarbeitet werden. Zum Beispiel bitten wir um Informationen über den Status von VSS (plötzlich wird dort gerade eine Schattenmine gebaut, und wir versuchen aufzusteigen) und antworten uns mit Schweigen und Ignorieren.
Windows-Bandsicherungs-API Wird für die Arbeit mit Bandbibliotheken oder Laufwerken benötigt. Wie ich eingangs erwähnt habe: Wir haben keine Freude daran, unsere eigenen Treiber zu schreiben und dann unter der Unterstützung jedes einzelnen Geräts zu leiden. Daher verfügt vim über keine eigenen Treiber. Alles über eine Standard-API, deren Unterstützung von den Hardware-Anbietern selbst implementiert wird. So viel logischer, oder?
SMB / CIFS Aus Gewohnheit schreibt sie jeder nebeneinander, obwohl sich nicht jeder daran erinnert, dass CIFS (Common Internet File System) nur eine private Version von SMB (Server Message Block) ist. Es ist also nichts Falsches daran, diese Konzepte zu verallgemeinern. Samba ist bereits eine LinuxUnix-Implementierung und hat seine eigenen Besonderheiten, aber ich schweife ab. Was hier wichtig ist: Wenn Veeam auffordert, etwas in den UNC-Pfad (Serververzeichnis) zu schreiben, verwendet der Server die Hierarchie der Dateisystemtreiber, einschließlich mup und mrxsmb, um auf den Ball zu schreiben. Dementsprechend werden auch diese Treiber Fehler erzeugen.
Ohne geht es nicht Winsock-API. Wenn etwas über das Netzwerk erledigt werden muss, funktioniert VBR über die Windows-Socket-API, im Volksmund als Winsock bekannt. Wenn wir also eine Reihe von IP:Ports im Protokoll sehen, ist dies der Fall. Die offizielle Dokumentation enthält eine gute Liste möglicher .
Oben erwähnt WMI (Windows Management Instrumentation) ist eine Art allmächtige API zur Verwaltung von allem und jedem in der Windows-Welt. Wenn beispielsweise mit Hyper-V gearbeitet wird, laufen fast alle Anfragen an den Host über diesen. Mit einem Wort, das Ding ist absolut unersetzlich und in seinen Fähigkeiten sehr mächtig. Um herauszufinden, wo und was defekt ist, hilft das integrierte Tool WBEMtest.exe sehr.
Und als letztes auf der Liste, aber keineswegs unwichtig: VSS (Volumenschattenspeicher). Das Thema ist so unerschöpflich und geheimnisvoll, wie viele Dokumentationen darüber geschrieben wurden. Unter Schattenkopie versteht man ganz einfach eine besondere Art von Schnappschuss, was es im Grunde auch ist. Dank ihm können Sie anwendungskonsistente Backups in VMware und fast alles in Hyper-V erstellen. Ich habe vor, einen separaten Artikel zu VSS zu verfassen, aber jetzt können Sie versuchen, ihn zu lesen . Seien Sie einfach vorsichtig, denn. Der Versuch, VSS blitzschnell zu verstehen, kann zu Hirnverletzungen führen.
Damit können wir vielleicht aufhören. Ich betrachte die Aufgabe, die grundlegendsten Dinge zu erklären, als erledigt, daher werden wir uns im nächsten Kapitel bereits mit den Protokollen befassen. Wenn Sie jedoch Fragen haben, können Sie diese gerne in den Kommentaren stellen.
Source: habr.com