none
Der E/A-Vorgang an der logischen Blockadresse xxxxx für den Datenträger xxx (PDO-Name: \Device\00000032) wurde wiederholt. RRS feed

  • Frage

  • Hallo liebe Gemeinde,

    ich habe eine Hyper-V Umgebung, welche unter Server 2016 läuft.
    Des Weiteren habe ich vor einigen Monaten Veeam Backup&Replication 9.5 als neue Backupsoftware eingeführt.

    Vor kurzen fiel mir auf, dass auf einigen, aber eben nicht allen, Servern das Eventlog voll mit der im Betreff des Beitrages angegeben Warnung ist.

    Hier ein genauer Auszug:

    - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    - <System>
      <Provider Name="disk" />
      <EventID Qualifiers="32772">153</EventID>
      <Level>3</Level>
      <Task>0</Task>
      <Keywords>0x80000000000000</Keywords>
      <TimeCreated SystemTime="2017-09-20T07:12:05.817913400Z" />
      <EventRecordID>219023</EventRecordID>
      <Channel>System</Channel>
      <Computer>PANT-OASIS-PROD.pantaenius.group</Computer>
      <Security />
      </System>
    - <EventData>
      <Data>\Device\Harddisk1\DR1</Data>
      <Data>0x811a5e0</Data>
      <Data>1</Data>
      <Data>\Device\00000032</Data>
      <Binary>0F01040004002C00000000009900048000000000000000000000000000000000000000000000000000020488</Binary>
      </EventData>
      </Event>

    Beim Backupvorgang erstellt Hyper-V einen Prüfpunkt für die VM. Ich konnte beobachten, dass diese Warnung immer dann geloggt wird, wenn der Prüfpunkt zusammengeführt wird und genau zu dem Zeitpunkt des Umschalten von der AVHDX zu der VDHX.

    Wenn man die Warnung 153 googelt, findet man zahlreiche Beiträge. Doch die meisten umschiffen das Problem bzw. sorgen dafür, dass die Warnung nicht mehr geloggt wird. Dies behebt natürlich das Problem nicht.

    Veeam habe ich bereits ins Boot geholt. Diese verwiesen mich allerdings nur auf zwei Links im WWW. Einer von MS, der die Warnung beschreibt und einen, der einen Workaround aufgibt. Ebenfalls holte ich Dell ins Boot, unseren Storage (Compellent) Anbieter. Aber auch hier stellte sich nur heraus, dass unser Storage fehlerfrei arbeitet.

    Mir gehen nun langsam die Ideen aus, was ich noch checken kann, um herauszufinden, was die Warnung verursacht. Daher hoffe ich, dass vielleicht einer von euch noch eine Idee hat!?

    Es könnte ja auch gut sein, dass diese Warnung wirklich ignoriert werden kann, da es sich um ein "normales" Verhalten handelt. Dahingehend konnte ich aber noch keine Sicherheit bekommen und möchte natürlich Folgefehler im Zuge dessen ausschließen.

    In dem obigen angegeben Workaround ist angegeben, dass man, indem mal dynamictick deaktiviert, die Warnung deaktivieren kann.
    Wenn ich dem folgen möchte und den Befehl "bcdedit /set disabledynamicktick yes" absetze, bekomme ich die Ausgabe, dass der angegebene Elementdatentyp nicht erkannt wird oder passt nicht zum angegeben Eintrag.
    Hat dazu auch jemand eine Idee?

    Sollte ich euch wichtige Info´s unterschlagen haben, fragt mich bitte.
    Ich danke euch vielmals im Voraus und beste Grüße
    Sebastian 

    Freitag, 22. September 2017 05:58

Alle Antworten

  • Ich kann da auch nur raten, denn vergleichbares passiert unserer Anwendung auch schon mal.
    Während der Sicherung läuft die VM ja weiter und alle Änderungen an der logischen Disk werden in einer separaten Datei geloggt, was dann nach der Sicherung halt wieder zusammengeführt werden muss.
    Die Frage stellt sich dann, was zur Zeit der Erstellung des Prüfpunktes auf der VM aktiv ist und ebenso zum Zeitpunkt der Zusammenführung, da dieses ja durchaus mal etwas länger dauern kann.

    Hinzu kommt, dass durch die DB-Transaktionen (konsistente Datenbank) nun auf einmal zusammengehörende Daten sowohl auf der Haupt-Disk als auch auf der Differenz-Disk liegen.

    Bei unserer Anwendung wurde regelmäßig die Datenbank auf der VM korrumpiert, da der DB-Server mit dem obigen Verfahren nicht zurecht kommt. Zumindest während der Zusammenführung darf der Server nicht wirklich aktiv sein, da ggf. die Umleitung von Schreibzugriffen zu Problemen führen kann.
    Erst nach Synchronisation der Abläufe (beenden des DB-Dienstes während der Sicherung) blieb auch unsere Anwendung stabil.

    Auch eine ggf. mal erforderliche Wiederherstellung der Disk aus der Datensicherung hat für die Datenbank dann einen konsistenten Stand, da ja alle Transaktionen zum Zeitpunkt des Prüfpunktes abgeschlossen waren. Ansonsten wäre die Datenbank danach auf jeden Fall korrupt, da ja Teile der Transaktionen auf der nicht gesicherten bzw. nicht mehr vorhandenen Differenzdisk liegen.
    Freitag, 22. September 2017 07:16
  • Hallo und danke für deine Antwort.

    Ich muss aber leider gestehen, dass mich deine Antwort nicht wirklich schlau macht.
    Der Zustand, den du erläuterst, ist plausibel. Aber wie soll mir das jetzt weiterhelfen? :-)

    Danke und viele Grüße


    • Bearbeitet Lehry Freitag, 22. September 2017 07:29
    Freitag, 22. September 2017 07:29
  • Bei den Abläufen während der Sicherung eben sicherstellen, dass bei den betroffenen Disks (die ja identifizierbar sind) der beschriebene Zustand nicht eintritt.
    Ggf. kann man die betroffenen VM's (Versuch macht kluch) einfach mal suspendieren und danach weiterlaufen lassen. Wenn der Fehler dann nicht beseitigt ist, wird wohl ein Runterfahren der VM vor und Hochfahren nach der Sicherung erforderlich sein.
    Freitag, 22. September 2017 07:33
  • Wäre ein Versuch wert.
    Aber bei welchem Backupsystem ist ein Herunterfahren einer VM nötig um diese sichern zu können!? Sorry, aber macht überhaupt keinen Sinn. Dies würde bedeuten, dass ich unsere betriebskritischen VM´s (SQL, Exchange Bestandsführungssystem usw.) zum Sichern ausgeschaltet haben muss. Gänzlich ungünstig bei einem 24/7 Betrieb und sicher nicht Sinn der Sache, egal welches Backupsystem genutzt wird!

    Freitag, 22. September 2017 07:40
  • Das liegt z.T. halt an den Anwendungen, die auf einem Server liegen.
    Nicht jede Anwendung unterstützt dieses Verfahren oder kommt dann halt damit nicht zurecht.

    Was passiert denn nun genau bei einem Prüfpunkt?
    Alle Diskoperationen, die nach dem Prüfpunkt passieren, werden auf der Differenzdisk geparkt.
    Nun sind hier gerade Datenbankoperationen kritisch.
    Eine DB-Operation läuft in einer Transaktion und umfasst durchaus mehrere Disk-Operationen.
    Erst wenn die Transaktion abgeschlossen ist, ist die DB wieder konsistent.

    Wird nun ein Prüfpunkt gesetzt während Transaktionen aktiv sind, werden alle nachfolgenden Diskoperationen zur selben Transaktion auf eine andere Disk geschrieben und somit nicht mit gesichert.
    Bei einer evtl. nötigen Wiederherstellung der DB wird diese dann korrupt, da Teile des Transaktionslogs, Verkettungen von DB-Seiten u.ä. einfach weg sind.
    Dies führt u.U. dann zu Zugriffsfehlern auf nicht vorhandene Disk-Seiten.

    Nun ist es ja auch so, dass i.d.R. die VM-Disks nicht in ihrer vollständigen Größe angelegt sind sondern sich dynamisch erweitern. Auch diese Erweiterungen finden dann real erst bei der Zusammenführung statt.

    Wenn man sich vorstellt, ein Dokument über mehrere MB (Word mit Bildern) wird gesichert. Während der Hälfte des Vorganges wird ein Snapshot erstellt. Der Rest geht dann auf die Differenzdisk.

    Je nach Art und Weise der Sicherung wird dies auch z.B. mit dem Volumeschattenkopie-Dienst durchgeführt. Hierbei muss ebenso sichergestellt werden, dass jede Anwendung dieses dann auch unterstützt.
    Mit einzelnen Dokumenten ist das kein Problem. Datenbanken arbeiten aber häufig mit sog. Memory-Mapped-Files, die eine Volumeschattenkopie nicht vertragen.

    Für die Datensicherung einer Datenbank gibt es die DB-eignen Sicherungen, die genau das Problem der Transaktionssicherheit berücksichtigen und immer eine konsistente Sicherung erstellen.
    Dies bietet sich dann für 24/7-Dienste dann eher an, als eine externe Sicherung außerhalb der Anwendung.
    Ich käme ich auch nicht auf die Idee, während des laufenden Betriebes geöffnete Dateien einfach so über den Explorer zu kopieren.

    Fazit:
    Jede 24/7-Anwendung sollte über ein eigenes Sichererungsverfahren bzgl. der Daten verfügen.
    Hier können die Datenbanken durchaus auf ein anderes virtuelles Medium im laufenden betrieb gesichert werden dass dann in einem weiteren späteren Schritt auf externe Medien übertragen werden kann.


    Freitag, 22. September 2017 08:04