none
Anwendungs konsistente Replica lösen vss writer Fehler aus RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    Ich habe leider zwei zuvor perfekt funktionierende 2012 Server (Primary+Replica Server) auf 2012 R2 upgedatet. Jetzt habe ich leider mehrere Probleme. Eines davon ist folgendes:

    Der Primary hostet nun einen "Server 2012 R2" und zwei "Server 2008" VMs. Auf der "Server 2012 R2" VM schlagen mehrere VSS Writers fehl:

    Status: [9] Fehler
       Letzter Fehler: Zeitüberschreitung

    Ein Neustart der VM löst das Problem temporär. Nachdem die erste anwendungskonsistente Replica erstellt wurde sind die writer wieder auf "Status: [9] Fehler, Zeitüberscheitung". Der Test Failover auf dem Replica Server zeigt mir aber völlig korrekt mehrere anwendungskonsistente Wiederherstellungspunkte an.

    Die zwei "Server 2008" VMs hatten bis zu diesem Zeitpunkt keinerlei Writer Fehler. ABER nachdem ich dort die Integrationsdienste auf die neueste Version upgedatet habe, zeigen diese dann einen ganz ähnlichen Fehler:

    State: [9] Fehlgeschlagen
       Letzter Fehler: Kein Fehler

    Aus diesem Grunde nehme ich an, das auch dieses Problem auf die Integrationsdienste von 2012 R2 zurückzuführen sind.

    Das 2008er Problem könnte folgendes sein: http://support.microsoft.com/kb/2952783/de

    Aber was ist mit der 2012 R2 VM? Eine 2012 R2 VM sollte keinen Fehler mit einem 2012 R2 Primary Host verursachen.

    Zusätzliche Information: Der BPA Test zeigt RuleId 44. Ich soll in den VMs VSS für anwendungskonsistente Replica konfigurieren. Z.B. indem ich die Integrationsdienste aktualisiere. Aber diese SIND aktuell!!

    LG Gregor



    Dienstag, 27. Mai 2014 16:08
    |

Alle Antworten

  • Discussion
    Anmelden
    0
    Anmelden

    Moin,

    du könntest die Versionen der Integrationsdienste auf Host und VM noch mal manuell vergleichen. Es ist schon öfter vorgekommen, dass die Host-Dienste durch Updates sozusagen stillschweigend aktualisiert wurden und die VMs dann nicht auf dem passenden Stand sind.

    Für die VMs auf dem Host ausführen:

    Get-VM | ft Name,IntegrationServicesVersion

    Die Versionen auf dem Host findest du in der Registry:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\GuestInstaller\Version\ Microsoft-Hyper-V-Guest-Installer

    Gruß, Nils

    Nils Kaczenski
    MVP Hyper-V
    Hannover, Germany

    Mittwoch, 28. Mai 2014 14:35
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Danke für deine Antwort. Hab es nochmal mit deinem Tipp überprüft. Ist aber exakt gleich. Das Setup von der virtuellen DVD irrt sich also auch nicht.

    Um mal genau zu sein, es handelt sich um folgende writer, die dieses Problem aufweisen:

    • System Writer
    • ASR Writer
    • MSSearch Service Writer
    • WMI Writer
    • Registry Writer
    • COM+ REGDB Writer

    Stabil sind:

    • Task Scheduler Writer
    • VSS Metadata Store Writer
    • Performance Counters Writer

    Ich bin natürlich um jede Hilfe froh. Nicht falsch verstehen. Aber auch im englischsprachigen Forum hat man sich gleich auf meine Randnotiz gestürzt, dass der BPA einen Fehler wirft. Gerade der BPA, so ist meine Erfahrung, wirft öfters mal gerne falsche oder missverständliche Fehler und Warnungen. Das liegt oft daran, dass er aus bestimmten Phänomenen einfach falsche Schlüsse zieht. In diesem Fall würde ich sagen, er sieht, dass einfach ein Problem mit den ICs und den Writern in der VM vorliegt. Aber egal...

    Hast du noch eine Idee? Sowohl bei Host als auch bei Guest handelt es sich um ein auf R2 upgegradetes System. Ich hab allerdings weder Zeit noch Lust erst den Guest und dann den Host nochmal komplett neu aufzusetzen, nur um zu sehen, ob es an Host oder Guest liegt und ob es was mit dem Upgrade zu tun hat...

    Ich folge jeder Spur. Jede Idee ist willkommen!


    Freitag, 30. Mai 2014 10:24
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Moin,

    najaaaa ... es hat schon seinen Grund, warum man von Server-Upgrades eher abrät ...

    Je nachdem, wie wichtig die Umgebung ist, würde ich an einem gewissen Punkt an eine Neuinstallation gehen. Dafür habe ich einfach schon zu viele Upgrades gesehen, die eigentlich hätten funktionieren müssen ...

    Mehr Ideen habe ich dazu leider hier nicht.

    Gruß, Nils

    Nils Kaczenski
    MVP Hyper-V
    Hannover, Germany

    Sonntag, 1. Juni 2014 20:26
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Ja, so ein Antwort in der Art hab ich leider erwartet :) Ist auch das erste Upgrade, welches ich gemacht habe. Bisher habe ich immer neu installiert. Dass es mich aber beim ersten mal gleich abschießt, bedeutet aus meiner Sicht eine Misserfolgsquote von 100% bezüglich Serverupgrades. Very sad...

    Unsere "Backupsoftware", wenn man denn sie so nennen möchte, HVBACKUP, ein super Kommandozeilen Tool, macht jede Nacht erfolgreich ein "child partition snapshot" Backup. Auch der Export im laufenden Betrieb, welchen ich ab R2 als Sicherungsalternative in Betracht ziehe, funktioniert tadellos.

    Allerdings: Bei Beginn der Sicherung, während des VSS Vorgangs, habe ich Ereignisprotokoll Einträge gefunden, die da nicht hingehören, und vor dem Upgrade auch nicht auftraten:

    partmgr id 58 - Die Datenträgersignatur von Datenträger "5" ist mit der Datenträgersignatur von Datenträger "2" identisch.

    + 30 sekunden später:
    disk id 157 - Der Datenträger "5" wurde überraschend entfernt.

    Verweiste Volumen Schattenkopien? Wenn ich dieses Problem gelöst habe, löst sich mein post hier vielleicht automatisch mit. (Die Hoffnung stirbt zuletzt)



    Montag, 2. Juni 2014 13:59
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    das ist nicht auszuschließen, hier eine Anleitung um Sie zu entfernen:

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/e999a0b2-a79b-49db-88dc-bd9d671ce507/cannot-delete-shadows-vssadmin

    Beste Grüße,

    BB

    Freitag, 13. Juni 2014 21:39
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Danke für deine Antwort. Kannst Du mir das kurz erläutern? Ich kriege deinen Link und das Problem, das dahinter steht, nicht ganz mit meinem Problem zur Deckung.

    In der VM sind 3 VHDX. System, Swap und Daten. Daten wird jeden Mittag erfolgreich gesnapshottet. Die komplette VM wird jeden Abend erfolgreich gesichert. Bis auf die event log Warnungen eben. Ich habe inzwischen in der c't einen Artikel entdeckt, der besagt, dass man speziell "disk id 157" während des Sicherungsvorgangs ignorieren kann. Ich hoffe c't behält recht.

    Dann könnte man dieses "Problem" als Ursache meines ursprünglichen Problems "Anwendungskonsistente Replica lösen vss writer Fehler aus" ausschließen, welches übrigens nach wie vor existiert.

    Montag, 16. Juni 2014 08:26
    |