Das Schöne und Schrecken an VDDK-Fehlern ist, dass einerseits absolut klar ist, wo sie kaputt gegangen sind, und andererseits völlig unverständlich ist, warum und wie sie jetzt behoben werden können. Es ist, als ob die RPC-Aufruffunktion in der Windows-Welt fehlgeschlagen ist.
Obwohl natürlich nicht alles so schrecklich ist. Einige Fehler haben sehr spezifische Ursachen und Behandlungen. Und einige - eine seit langem bekannte Liste der häufigsten Ursachen und Möglichkeiten, diese zu beheben.
Unser technischer Support von Veeam sammelt dieses Wissen natürlich an, und heute werden wir uns ihre Einträge ansehen. Daher freue ich mich sehr, Ihnen die häufigsten VDDK-Fehler und Methoden zu ihrer Beseitigung vorstellen zu können.
VDDK-Fehler. Was ist das und wie werden sie erhalten?
Wie Sie dem Namen entnehmen können, handelt es sich hierbei um Probleme auf der Ebene der VDDK-API (Virtual Disk Development Kit) - der beste Weg, um mit der vSphere-Infrastruktur zu interagieren. Es spielt keine Rolle, ob es sich um einen separaten ESXi-Host oder ein weitläufiges vCenter handelt. Wenn wir jedoch etwas aus unserer Infrastruktur schreiben oder lesen müssen, ist das kostenlose VDDK der beste Weg, dies zu tun.
Um dies so weit wie möglich zu vereinfachen, sieht diese Interaktion ungefähr so aus: Der Veeam-Server möchte beispielsweise etwas vom Host lesen (oder schreiben) und ihm eine Anfrage senden. Es wird ein Leseaufruf erstellt, der angibt, von welcher Festplatte, wie viel Sie lesen möchten, von welchem Offset und zu welchem Puffer im Speicher. Oder schreiben Sie ähnlich aus dem angegebenen Puffer. Es ist einfach.
Aber das ist in einer perfekten Welt.
Im wirklichen Leben treten manchmal Fehler auf dem Weg dieses einfachen Algorithmus auf, aufgrund derer es unmöglich ist, die Anforderung abzuschließen. Und anstelle der erwarteten Antwort kommt eine Fehlernummer zu uns, die sorgfältig in den Protokollen aufgezeichnet wird.
Heute werden wir über die häufigsten derartigen Fehler sprechen.
Wichtiger Haftungsausschluss!
Nicht sicher - nicht! Drücken Sie nicht und berühren Sie überhaupt nichts! Das Anrufen oder Schreiben an den Veeam-Support ist immer besser als das Experimentieren mit Ihrem Produkt. Glücklicherweise ist unsere Unterstützung russischsprachig und äußerst technisch.
Wenn Sie den geringsten Zweifel haben, rufen Sie an und fragen Sie: "Ich habe ein solches Problem. Ich habe diese Lösung im Netzwerk gefunden. Wird es mir helfen, es zu lösen?" - normal und korrekt. Was nicht normal und nicht richtig ist, ist, sich Ihrer Handlungen nicht sicher zu sein, viele Dinge zu tun und dann zu bitten, in fünf Minuten alles aus den Ruinen wiederherzustellen, damit nichts verloren geht.
Ja, wir werden in diesem Fall natürlich helfen, aber der beste Kampf ist der, den es nicht gab. Versuchen Sie daher immer, Ihre Aktionen und die große Betriebszeit kritisch zu bewerten.
VDDK-Fehler 1: Unbekannter Fehler
Tatsächlich haben wir einen ganzen HF-Artikel über diesen Fehler . Und wie es heißt, tritt dieser Fehler meistens auf, wenn Sie zu viele Leistungsindikatoren installiert haben - und einen Patch von VMware herunterladen, der alles für Sie behebt.
Einerseits gibt es sogar nichts zu kommentieren. Hier ist das Problem, hier ist eine Beschreibung (auch wenn es nicht sehr klar ist) und vor allem hier ein Link zur Medizin. Allerdings nicht alles so einfach. Nach unseren Beobachtungen kann dieser Fehler nicht nur aufgrund eines langweiligen Problems mit Zählern auftreten, sondern auch aufgrund von:
- VMDK . , , . — — . , . , , .
- datastore. . , .
- HBA . , . . ?
- , : ESXi vCenter.
Nun, ich habe es eingeholt, sagst du? Und dann was? Wie kann man verstehen, dass es Zeit ist, dringend nach neuen Discs zu suchen - oder reicht es aus, einen Patch anzulegen und auszuatmen?
Und ich werde Ihnen antworten - führen Sie eine Reihe einfacher Tests durch, die Ihnen helfen, die richtige Entscheidung zu treffen, wenn etwas passiert.
- Wir starten Storage vMotion oder klonen einfach einen verdächtigen Computer in einen anderen Datenspeicher und versuchen dann, eine Sicherung zu starten. Wenn das Klonen fehlschlägt, liegt definitiv irgendwo im Festplattensubsystem ein Problem vor. Paranoia-Modus maximal - und überprüfen Sie alles von Festplatten bis zu Controllern.
Wenn es erfolgreich geklont und gespeichert wurde, bedeutet dies, dass das VMDK beschädigt wurde, da VMware beim Klonen seinen Inhalt neu erstellt und jetzt definitiv keine Fehler mehr vorhanden sind.
- , . , . « — » .
- , , , — VMware.
- , . , .
VDDK error 2: Value: 0x0000000000000002
Fast immer geht Hand in Hand mit VDDK-Fehler 1. Laut unserer Statistik ist das Auftreten eines Fehlers normalerweise mit bestimmten Versionen des vCenter / ESXi-Bundles verbunden. Daher ist es hier am besten, auf mindestens Version 6.7 zu aktualisieren. Und besser und 7.0.
Wenn dies nicht hilft, fahren Sie mit Plan B fort.
Der Fehler selbst wird angezeigt, wenn dem ESXi-Host der für den NFC-Lesepuffer zugewiesene Speicher ausgeht. Standardmäßig arbeitet Veeam im asynchronen NBD / NFC-Lesemodus, der unter normalen Bedingungen möglicherweise eine Erweiterung dieses Puffers erfordert. Dies ist jedoch nicht immer der Fall. Um diesen Modus zu deaktivieren, gibt es daher einen speziellen Schlüssel:
Name: VMwareDisableAsyncIo
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Type: REG_DWORD
Value: 1
Nach dem Erstellen müssen Sie den Veeam Backup Service neu starten und auf eine um etwa 10% gesunkene Leistung vorbereitet sein.
Eine weitere Option besteht darin, sich von der Hostseite aus anzumelden und die Verwaltungsagenten neu zu starten:
/etc/init.d/hostd restart
/etc/init.d/vpxa restart
Das Verfahren wird in der KB von VMware ausführlich beschrieben , sodass wir es nicht neu schreiben.
Und eine Reihe von Standardoptionen, die während des Diagnoseprozesses nicht überflüssig sind:
- Migrieren Sie fehlerhafte Computer auf einen anderen Host.
- Versuchen Sie es mit einem anderen Transportmodus - HotAdd mit virtuellem Proxy oder DirectSAN.
VDDK-Fehler 3: Einer der Parameter ist ungültig
Ein Fehler, der fast immer auftritt, wenn der Virtual Appliance-Modus (auch als HotAdd-Modus bezeichnet) verwendet wird.
Hier gibt es nichts Besonderes zu erzählen. Ich werde nur Links zu zwei unserer KBs geben, in denen viele Optionen beschrieben werden. Selbst wenn Sie sofort zum Support kommen, werden Sie aufgefordert, alles zu tun, was dort geschrieben steht.
KB1218 - Allgemeine Beschreibung möglicher Probleme und Methoden zu ihrer Beseitigung.
KB1332 - Wenn Ihr Veeam-Server als Proxy für den HotAdd-Modus fungiert
VDDK-Fehler 13: Sie haben keine Zugriffsrechte auf diese Datei
Und für diesen Fall haben wir KB2008 . Ja, es gibt viele Möglichkeiten, um dieses Problem zu beheben, aber ein solcher Fehler. Es ist fast unmöglich, eindeutig zu sagen, was genau in Ihrem Fall passiert ist, daher müssen Sie die gesamte Liste durchgehen und durchlaufen.
Was ich zusätzlich sagen möchte. Seien Sie sehr vorsichtig mit dem Abschnitt Zusätzliche Fehlerbehebung. Ja, es sind geschrieben, vielleicht zu offensichtlich für viele Dinge. Aber selbst solche Plattitüden entziehen sich den professionellsten Fachleuten. Es gibt oft Fälle, in denen sie nach einer Woche, wenn sie versuchen, alles selbst zu lösen, zum Support kommen, nur um herauszufinden, dass sie die Liste der technischen Anforderungen oder ähnliches nicht sorgfältig gelesen haben. Und es ist eine Schande und schade für die verbrachte Zeit.
Und zwei Tipps für alle Zeiten:
- Veeam proxy , UUID . - , . , , .
- ( — ), , VDDK .
VDDK error 18000: Cannot connect to the host
In den meisten Fällen liegt der Fehler für diesen Fehler in einem Fehler im VDDK selbst. Insbesondere die Bibliothek gvmomi.dll ist schuld. Und er zeigt sich nur unter schwerer Last. Wenn beispielsweise viele Computer parallel gesichert werden, wird eine der Funktionen zu 0, und die Bibliothek kann zusammenbrechen. Und dann fällt alles andere.
Das ist die traurige Geschichte.
Das Schlimmste an dieser Geschichte ist jedoch, dass es unmöglich ist, die Bedingungen des Fehlers genau zu reproduzieren. Dies nennen Tester Floating Bugs. Daher ist es unmöglich, genau zu sagen, wie viele parallele Maschinen den Absturz verursachen.
Laut offiziellen VersionshinweisenDieser Fehler wurde vollständig behoben. Der richtige Ausweg ist also, Ihren Host zu aktualisieren. Wenn dies jedoch aus irgendeinem Grund nicht möglich ist, können wir Ihnen nur helfen, indem wir Ihnen raten, die Anzahl der gleichzeitig verarbeiteten Maschinen zu verringern.
Kein anderer Weg.
VDDK-Fehler 14008: Der angegebene Server konnte nicht kontaktiert werden
Wenn Sie von diesem Problem betroffen sind, müssen Sie zunächst das Netzwerk überprüfen. Höchstwahrscheinlich ist die Kommunikation zwischen vCenter und Veeam-Proxy unterbrochen. Überprüfen Sie, ob alle Ports geöffnet und zugänglich sind und ob alle DNS-Namen korrekt in die erwarteten IP-Adressen aufgelöst wurden. Darüber hinaus müssen Sie den spezifischen Proxy überprüfen, der an dem fehlgeschlagenen Job beteiligt ist, und nicht den, der daneben steht, genau gleich (es gibt Fälle).
95% der Fälle mit diesem Fehler werden mit der Markierung „Problem mit DNS / Ports in der Client-Infrastruktur“ abgeschlossen.
Daher fordere ich Sie erneut auf, sehr sorgfältig zu prüfen, ob überall der richtige DNS-Server angezeigt wird, ob geschlossene Ports vorhanden sind und in welche IPs die FQDN-Namen aufgelöst werden.
In älteren Versionen von VDDK gab es einen ähnlichen Fehler bei der Verwendung eines nicht standardmäßigen Ports für die Arbeit mit vCenter, der die restlichen 5% ausmachte. Jetzt hat VMware die KB mit ihrer Beschreibung ausgeblendet, was wahrscheinlich bedeutet, dass die KB nicht mehr relevant ist. Sie können jedoch in den Internetarchiven unter 2108658 danach suchen (die Sicherung schlägt fehl, wenn für VMware vCenter Server ein nicht standardmäßiger Port angegeben ist).
VDDK-Fehler 14009: Der Server hat die Verbindung abgelehnt
Und der letzte Fehler in unserer heutigen Top ist, dass der Server die Verbindung verweigert hat. Hier ist alles absolut banal: Etwas verhindert die Verbindung zwischen Host und Proxy. In den meisten Fällen ist die Firewall schuld. Aber - ein subtiler Punkt - nicht wegen geschlossener Ports, sondern wegen eingeführter Verzögerungen. Zuerst überprüfen wir die Offenheit von Port 443 und dann die Zeitüberschreitungen.
Wenn beide Optionen nichts ergeben haben, wenden Sie sich an den Support. Wir müssen den Host selbst überprüfen. Vielleicht ist er einfach zu beschäftigt und hat keine Zeit, rechtzeitig zu antworten, und vielleicht etwas anderes.
Und zum Schluss noch einige nützliche Links:
- Portal unseres preisgekrönten technischen Supports.
- Veeam Support Knowledge Base