VMware vCenter Site Recovery Manager 5.0.2 | 20. Dezember 2012 | Build 919478

Letzte Aktualisierung: 21. Oktober 2013

Überprüfen Sie, ob Erweiterungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

VMware vCenter Site Recovery Manager 5.0.2 bietet die folgenden Verbesserungen:

  • Der vSphere Replication-Verwaltungsserver akzeptiert MD5-Zertifikate. Siehe Probleme und Einschränkungen.
  • Upgrade von OpenSSL 0.9.8m auf 0.9.8t zur Erhöhung der Sicherheit. Dies bezieht sich auf die Sicherheitsempfehlung, die für OpenSSL im Januar 2012 ausgegeben wurde.
  • Automatisch generierte Zertifikate verwenden RSA-Schlüssel mit 2048 Bit.
  • Fehlerbehebungen, die in Behobene Probleme beschrieben sind.

Lokalisierung

VMware vCenter Site Recovery Manager 5.0.2 ist in den folgenden Sprachen verfügbar:

  • Englisch
  • Französisch
  • Deutsch
  • Japanisch
  • Vereinfachtes Chinesisch

Kompatibilität

SRM-Kompatibilitätstabelle

Aktuelle Interoperabilitäts- und Produktkompatibilitätsinformationen finden Sie in den Kompatibilitätslisten für VMware vCenter Site Recovery Manager.

Kompatible Speicher-Arrays und Speicherreplizierungsadapter

Eine aktuelle Liste der unterstützten kompatiblen Storage-Arrays und SRAs finden Sie im Kompatibilitätsleitfaden für VMware.

VMware VSA-Unterstützung

Virtuelle Maschinen, die sich auf der vSphere Storage Appliance (VSA) befinden, können durch SRM 5.0.2 unter Verwendung von vSphere Replication geschützt werden. VSA benötigt für das Zusammenspiel mit SRM 5.0.2 keinen Speicherreplizierungsadapter (SRA).

Installation und Upgrade

SRM 5.0.2 kann nur dann mit ESXi Server 4.0 und 4.1 sowie mit Virtual Infrastructure 3.5 ausgeführt werden, wenn Sie die Array-basierte Replizierung verwenden. Wenn Sie vSphere Replication verwenden, entweder allein oder in Verbindung mit der Array-basierten Replizierung, müssen Sie als Teil des Upgrade-Vorgangs die ESXi Server-Hosts auf Version 5.0, 5.0 Update 1 oder 5.0 Update 2 aktualisieren.

Um SRM 5.0.2 ohne Upgrade von einer früheren Version zu installieren, finden Sie Informationen im Administrationshandbuch zu Site Recovery Manager unter Installieren und Aktualisieren von Site Recovery Manager.

Upgrade von SRM 5.0 oder 5.0.1 auf SRM 5.0.2

Sie können ein In-Place-Upgrade von SRM 5.0 oder 5.0.1 auf SRM 5.0.2 durchführen. Es wird empfohlen, statt Neuinstallationen In-Place-Upgrades durchzuführen, da bei diesem Vorgang alle Verlaufsberichte, Wiederherstellungspläne, Schutzgruppen und Anpassungen der Wiederherstellungspläne beibehalten werden. Sie müssen den Upgrade-Vorgang sowohl auf der geschützten Site als auch auf der Wiederherstellungs-Site durchführen.

  1. Melden Sie sich bei der Maschine an, auf der Sie den SRM-Server auf der geschützten Site ausführen.
  2. Sichern Sie die SRM-Datenbank mit den Tools der Datenbanksoftware.
  3. Laden Sie VMware-srm-5.0.2-919478.exe herunter und führen Sie die Datei aus.
  4. Klicken Sie auf Ja, wenn Sie zur Bestätigung des Upgrades von SRM aufgefordert werden.
  5. Klicken Sie auf Weiter, um SRM 5.0.2 mit den Einstellungen der vorherigen SRM-Installation zu verwenden.
  6. Klicken Sie auf Ja, um zu bestätigen, dass Sie die SRM-Datenbank gesichert haben.
  7. Klicken Sie auf Fertigstellen, wenn die Installation beendet ist.
  8. Wiederholen Sie den Upgrade-Vorgang auf der Wiederherstellungs-Site.

Nach dem Upgrade des SRM-Servers müssen Sie das SRM-Client-Plug-In neu installieren.

  1. Deinstallieren Sie das SRM 5.0- oder 5.0.1-Client-Plug-In.
  2. Melden Sie sich bei einer vSphere-Client-Instanz an und stellen Sie eine Verbindung zu dem vCenter Server her, mit dem der SRM-Server verbunden ist.
  3. Wählen Sie Plug-Ins > Plug-Ins verwalten aus.
  4. Klicken Sie auf Herunterladen und Installieren, um das SRM 5.0.2-Client-Plug-In zu installieren.
  5. Wenn die Installation des Plug-Ins abgeschlossen ist, melden Sie sich bei SRM an und stellen Sie sicher, dass die Konfiguration der vorherigen Version beibehalten wurde.
  6. Wiederholen Sie den Vorgang für alle vSphere-Client-Instanzen, mit denen Sie eine Verbindung zum SRM-Server herstellen.

HINWEIS: Microsoft hat ein Sicherheits-Update herausgegeben, das zu einer Zurückweisung von Zertifikaten mit RSA-Schlüsseln von weniger als 1024 Bit führt. Siehe http://support.microsoft.com/kb/2661254. Dieser Standard wird Ende 2013 auf 2048 Bit erhöht. Folglich generiert SRM 5.0.2 automatisch Zertifikate mit 2048-Bit-RSA-Schlüsseln. SRM 5.0 und 5.0.1 generieren automatisch Zertifikate mit 512-Bit-RSA-Schlüsseln. Beim Upgrade von SRM 5.0 oder 5.0.1 auf 5.0.2 behält SRM die Zertifikate der früheren Installation bei. Wenn Sie das Microsoft-Sicherheitsupdate installieren, müssen Sie daher ein Upgrade der SRM-Zertifikate durchführen, damit diese RSA-Schlüssel mit einer Mindestgröße von 1024 Bit, oder besser noch, 2048 Bit verwenden.

  • Wenn Sie automatisch generierte Zertifikate mit SRM 5.0 oder 5.0.1 verwendet haben, können Sie nach dem Upgrade auf SRM 5.0.2 ein Upgrade der Zertifikate durchführen, indem Sie das SRM 5.0.2-Installationsprogramm im Änderungsmodus erneut ausführen und die Option zum Generieren eines neuen 2048-Bit-Zertifikats wählen.
  • Falls Sie Zertifikate verwendet haben, die von einer Zertifizierungsstelle in SRM 5.0 oder 5.0.1 signiert wurden, müssen Sie Upgrade und Import des Zertifikats manuell vornehmen und sicherstellen, dass RSA-Schlüssel mit einer Mindestgröße von 1024 Bit, oder besser noch, 2048 Bit verwendet werden.

Upgrade von vSphere Replication 1.0 oder 1.0.1 auf vSphere Replication 1.0.2

SRM 5.0 enthält vSphere Replication 1.0. SRM 5.0.1 enthält vSphere Replication 1.0.1. SRM 5.0.2 enthält vSphere Replication 1.0.2. Beim Upgrade von SRM 5.0 oder 5.0.1 auf SRM 5.0.2 wird nicht automatisch ein Upgrade von vSphere Replication 1.0 oder 1.0.1 auf vSphere Replication 1.0.2 durchgeführt. vSphere Replication 1.0.2 ist funktional identisch mit vSphere Replication 1.0 oder 1.0.1, enthält aber zudem Bugfixes. Sie können mit dem vSphere Update Manager ein Update des VRM-Servers und der VR-Server durchführen. Alternativ dazu können Sie das Virtual Appliance Management Interface (VAMI) für den VRM-Server und die VR-Server verwenden, um das Update durchzuführen.

WICHTIG: Wählen Sie nicht die Option unter Aktualisieren > Einstellungen im VAMI aus, um vSphere Replication automatisch zu aktualisieren. Wenn Sie automatische Aktualisierungen auswählen, aktualisiert das VAMI vSphere Replication auf die neueste 5.x-Version, die jedoch mit SRM und vCenter Server 5.0.x inkompatibel ist. Behalten Sie daher die Aktualisierungseinstellung Keine automatischen Aktualisierungen bei.

So aktualisieren Sie die VRM-Server mithilfe des VAMI:

  1. Upgrade des SRM-Servers und -Clients auf SRM 5.0.2.
  2. Gehen Sie zur VRM-Serverkonfigurationsschnittstelle unter https:// VRM_server_address:8080.
  3. Melden Sie sich bei der VRM-Server-Konfigurationsbenutzeroberfläche als "root" an.
  4. Klicken Sie auf die Registerkarte Aktualisieren.
  5. Klicken Sie auf Einstellungen.
  6. Wählen Sie Angegebenes Repository verwenden aus und fügen Sie die Update-URL in das Textfeld Repository-URL ein:
    http://vapp-updates.vmware.com/vai-catalog/valm/vmw/05d561bc-f3c8-4115-bd9d-22baf13f7178/1.0.2.0
  7. Klicken Sie auf Status.
  8. Klicken Sie auf Auf Updates prüfen. Die Update-Prüfung zeigt an, dass Version 1.0.2.0 verfügbar ist.
    HINWEIS: Sie können VRM-Server 5.1.0.1 nicht mit SRM 5.0.2 verwenden.
  9. Klicken Sie auf Updates installieren und anschließend auf OK.
  10. Wenn das Update abgeschlossen ist, wählen Sie die Registerkarte VRM aus, klicken Sie auf Konfiguration und auf Neustart, um den VRM-Server erneut zu starten.
  11. Wiederholen Sie den Vorgang für den VRM-Server auf der Wiederherstellungs-Site.

So aktualisieren Sie die VR-Server mithilfe des VAMI:

  1. Führen Sie ein Upgrade des VRM-Servers durch.
  2. Gehen Sie zur VR-Serverkonfigurationsschnittstelle unter https:// VR_address:5480.
  3. Melden Sie sich bei der VR-Server-Konfigurationsbenutzeroberfläche als "root" an.
  4. Klicken Sie auf die Registerkarte Aktualisieren.
  5. Klicken Sie auf Einstellungen.
  6. Wählen Sie Angegebenes Repository verwenden aus und fügen Sie die Update-URL in das Textfeld Repository-URL ein:
    http://vapp-updates.vmware.com/vai-catalog/valm/vmw/9f73d994-d8b5-11df-ace9-18a9053dae02/1.0.2.2957
  7. Klicken Sie auf Status.
  8. Klicken Sie auf Auf Updates prüfen. Die Update-Prüfung zeigt an, dass Version 1.0.2 verfügbar ist.
  9. Klicken Sie auf Updates installieren und anschließend auf OK.
  10. Wenn das Update abgeschlossen ist, wählen Sie die Registerkarte System aus, klicken Sie auf Information und auf Neustart, um den VR-Server erneut zu starten.
  11. Wiederholen Sie den Vorgang für alle VR-Server auf der Schutz- und der Wiederherstellungs-Site.

Upgrade von SRM 4.1.2 auf SRM 5.0.2

Sie können ein In-Place-Upgrade von SRM 4.1.2 auf SRM 5.0.2 durchführen. Es wird empfohlen, statt Neuinstallationen In-Place-Upgrades durchzuführen, da bei diesem Vorgang alle Verlaufsberichte, Wiederherstellungspläne, Schutzgruppen und Anpassungen der Wiederherstellungspläne beibehalten werden. Um ein Upgrade des SRM-Clients auf Version 5.0.2 durchzuführen, müssen Sie zunächst den SRM 4.1.2-Client deinstallieren.

HINWEIS: Ein Upgrade von SRM 4.1 oder SRM 4.1.1 auf SRM 5.0.2 wird nicht unterstützt.

Um das Upgrade von SRM 4.1.2 auf SRM 5.0.2 durchzuführen, befolgen Sie die Verfahrensanleitung für das Upgrade von SRM 4.1 oder 4.1.1 auf SRM 5.0 im Administrationshandbuch zu Site Recovery Manager unter Upgrade von SRM. Hinweise finden Sie auch im Blog SRM 5 Upgrade Process .

Open Source-Komponenten

Die Urheberrechtsverweise und Lizenzen, die auf Open Source-Softwarekomponenten anzuwenden sind, die mit vCenter Site Recovery Manager 5.0.2 mitgeliefert werden, stehen auf der SRM Downloads-Website zur Verfügung. Sie können auch die Quelldateien für jede GPL-, LGPL- oder vergleichbare Lizenz herunterladen, die es erfordert, den Quellcode oder Änderungen des Quellcodes für die neueste allgemein verfügbare Version von vCenter Site Recovery Manager zur Verfügung zu stellen.

Probleme und Einschränkungen

  • vCenter Server 5.0u2 unterstützt Windows Server 2012 als Hostbetriebssystem. SRM 5.0.2 unterstützt Windows Server 2012 nicht als Hostbetriebssystem für SRM Server.

  • Interoperabilität mit Storage vMotion und Storage DRS
    Aufgrund einiger spezifischer und begrenzter Fälle, bei denen die Wiederherstellbarkeit während der Storage-Bewegung beeinträchtigt werden kann, wird Site Recovery Manager 5.0.2 weder für die Verwendung mit Storage vMotion (SVmotion) noch für die Verwendung mit dem Storage Distributed Resource Scheduler (SDRS) unterstützt. Dies gilt auch für die Verwendung von Datenspeicher-Clustern. Wenn Sie SVMotion zum Verschieben einer geschützten virtuellen Maschine aus einem Datenspeicher in einer Schutzgruppe zu einem nicht geschützten Datenspeicher verwenden, müssen Sie den Schutz dieser virtuellen Maschine manuell neu konfigurieren.

  • Network Address Translation (NAT) mit SRM nicht unterstützt
    Beim Konfigurieren von vSphere Replication müssen Sie den vSphere Replication Server (VR-Server) mit einer IP-Adresse einrichten, die sowohl für den geschützten vSphere Replication Management Server (VRM-Server) als auch für den Wiederherstellungs-VRM-Server sichtbar ist.

  • Interoperabilität mit vCloud Director
    Site Recovery Manager 5.0.2 bietet begrenzte Unterstützung für vCloud Director-Umgebungen. Die Verwendung von SRM, um virtuelle Maschinen innerhalb von vCloud-Ressourcenpools (virtuelle Maschinen, die für eine Organisation bereitgestellt wurden) zu schützen, wird nicht unterstützt. Die Verwendung von SRM zum Schützen der Verwaltungsstruktur von vCD wird unterstützt. Hinweise zur Verwendung von SRM zum Schutz der vCD Server-Instanzen, vCenter Server-Instanzen und Datenbanken, die die Managementinfrastruktur für vCloud Director bilden, finden Sie in der Dokumentation VMware vCloud Director-Infrastrukturflexibilitäts-Fallstudie.

  • Mit vSphere Replication werden der erneute Schutz und das automatische Failback nicht unterstützt.
    Der erneute Schutz und das automatische Failback werden nur mit Array-replizierten virtuellen Maschinen unterstützt. Für virtuelle Maschinen, die mit vSphere Replication konfiguriert werden, kann mithilfe von vorhandenen Wiederherstellungsplänen kein automatisches Failback auf die ursprüngliche Site durchgeführt werden.

  • Bestimmte vSphere-Funktionen und RDM bei vSphere Replication nicht unterstützt
    vSphere Replication kann nicht in Kombination mit vSphere Fault Tolerance, Vorlagen für virtuelle Maschinen, Linked Clones oder physischer Raw-Festplattenzuordnung (RDM) verwendet werden.

  • Interoperabilität mit vSphere Replication
    vSphere Replication unterstützt eine maximale Festplattengröße von 2032 GB.

  • Schutz und Wiederherstellung von virtuellen Maschinen mit Arbeitsspeicherzustands-Snapshots
    Beim Schützen von virtuellen Maschinen mit Arbeitsspeicherzustands-Snapshots müssen die ESX-Hosts der Schutz- und Wiederherstellungs-Sites über kompatible CPUs verfügen, wie dies in den VMware-Knowledgebase-Artikeln vMotion CPU-Kompatibilitätsanforderungen für Intel-Prozessoren und vMotion CPU-Kompatibilitätsanforderungen für AMD-Prozessoren definiert wird. Auf den Hosts müssen außerdem dieselben BIOS-Funktionen aktiviert sein. Wenn die BIOS-Konfigurationen der Server nicht übereinstimmen, wird eine Kompatibilitätsfehlermeldung angezeigt, auch wenn sie ansonsten identisch sind. Die beiden häufigsten Funktionen, die überprüft werden sollten, sind „Non-Execute Memory Protection“ (NX/XD) und „Virtualization Technology“ (VT/AMD-V). Weitere Informationen über den Schutz und die Wiederherstellung von virtuellen Maschinen mit Snapshots finden Sie unter Einschränkungen für den Schutz und die Wiederherstellung virtueller Maschinen im Administrationshandbuch zu Site Recovery Manager .

  • Maximale Anzahl von Wiederherstellungsplänen pro SRM-Server-Instanz
    Sie können die folgende maximale Anzahl von Wiederherstellungsplänen pro SRM-Server-Instanz erstellen:

    • Array-basierte Replizierung: 150 Wiederherstellungspläne
    • vSphere Replication: 250 Wiederherstellungspläne

    Hinweise über die Anzahl der Wiederherstellungspläne, die Sie gleichzeitig ausführen können, und andere operationelle Beschränkungen von SRM finden Sie im Administrationshandbuch zu Site Recovery Manager .

  • Verwendung von MD5-Zertifikaten mit vSphere Replication-Verwaltungsserver
    SRM 5.0.2 und vSphere Replication 1.0.2 ermöglichen die Konfiguration des vSphere Replication-Verwaltungsservers zur Verwendung der MD5-Zertifikate. Da der MD5-Zertifikat-Signaturalgorithmus allerdings anfällig für Angriffe ist, sollten Sie, falls möglich, mindestens SHA-1 als Zertifikat-Signaturalgorithmus verwenden. Sie können MD5-Zertifikate mit SRM 5.0.2 und vSphere Replication 1.0.2 verwenden, aber Sie sollten den Übergang Ihrer Infrastruktur zur Verwendung von mindestens SHA-1 als Zertifikat-Signaturalgorithmus so bald wie möglich einleiten.

Behobene Probleme

Die folgenden Probleme wurden in SRM 5.0.2 behoben.

  • Die Einstellungen der Netzwerkkarteneigenschaften werden während der Anpassung des Gastbetriebssystems nicht angewendet

    Wenn Sie eine Test- oder eine echte Wiederherstellung ausführen und Netzwerkkarteneigenschaften konfigurieren und es dabei zwei Adapter für die angegebene MAC-Adresse gibt, werden die Netzwerkkarteneigenschaften in der wiederhergestellten virtuellen Maschine nicht aktualisiert. Dieses Problem tritt meistens dann auf, wenn die Netzwerkkarte mit der angegebenen MAC-Adresse über einen Antivirus-Miniportadapter sowie über einen physischen Adapter verfügt. Dies wurde behoben.

  • Der vCenter-Dienststatus gibt für den VR-Verwaltungsdienst einen roten Alarm an

    Nach der erfolgreichen Registrierung eines vSphere Replication-Verwaltungsservers (VRM-Servers) bei vCenter Server wird in der Ansicht Home > vCenter - Dienststatus für den VR-Verwaltungsdienst ein roter Alarm mit einer Fehlermeldung angezeigt, die angibt, dass vCenter Server keine Informationen zum Systemzustand vom VRM-Server abrufen kann. Dies wurde behoben.

  • Testwiederherstellungen schlagen manchmal bei der Speicherkonfiguration fehl

    Eine Wettlaufsituation kann dazu führen, dass Testwiederherstellungen fehlschlagen, während SRM Speicher konfiguriert. Der Testplan gibt an, dass die Wiederherstellung unterbrochen wurde, aber Sie können den Testplan nicht abbrechen oder entfernen. Dieses Problem kann bei Verwendung mehrerer gemeinsam genutzter RDM-Geräte (Raw Disk Mapping) auftreten, wie in KB 2020532 beschrieben. Dies wurde behoben.

  • SRM schlägt manchmal beim Entfernen einer Schutzgruppe fehl, die mehrere Datenspeicher enthält

    Wenn Sie nacheinander mehrere Schutzgruppen löschen, schlägt SRM manchmal fehl. Nach einem Neustart von SRM schlägt SRM an derselben Stelle erneut fehl. Die Protokolle zeigen die Meldung Panic: Assert Failed: "1 == count" @ path/datastoreGroupData.cpp:398 an. Dies wurde behoben.

  • SRM schlägt während der Wiederherstellung beim Vorbereiten der virtuellen Maschinen für die Migration auf der geschützten Site fehl

    Wenn sich eine geschützte virtuelle Maschine in einem Datenspeicher befindet, der von mehreren Hosts gemeinsam genutzt wird, und sich diese Hosts in unterschiedlichen Datencentern befinden, kann SRM während einer Wiederherstellung beim Schritt VMs auf der Schutz-Site für die Migration vorbereiten fehlschlagen. Die Protokolle zeigen die Meldung SRM Panic: Assert Failed: "ok" @ path/deactivateStorage.cpp:1170 an. Dies wurde behoben.

  • SRM wartet für unbegrenzte Zeit auf eine Verbindung zu einer wiederhergestellten virtuellen Maschine, um im Gastbetriebssystem ein Post-Power-On-Skript auszuführen

    Wenn in früheren Versionen SRM keine Verbindung zu einer wiederhergestellten virtuellen Maschine herstellen konnte, um ein Skript im Gastbetriebssystem der virtuellen Maschine nach deren Einschalten auszuführen, wartete SRM für unbegrenzte Zeit. SRM wartet nicht mehr unbegenzt lange auf eine Verbindung zu einer wiederhergestellten virtuellen Maschine. Die Anforderung führt standardmäßig nach 20 Sekunden zu einer Zeitüberschreitung. Wenn das Zeitlimit einen Fehler von Testwiederherstellungen mit der Meldung Zeitüberschreitung beim Vorgang: 20 Sekunden anzeigt, können Sie das Zeitlimit erhöhen.

    1. Öffnen Sie die Datei C:\Programme\VMware\VMware Site Recovery Manager\config\vmware-dr.xml in einem Texteditor.
    2. Fügen Sie den Knoten vixOpenVmTimeout mit einem neuen Zeitlimit (in Sekunden) hinzu. Beispiel:
      <connections>
         <vixOpenVmTimeout>30</vixOpenVmTimeout>
      </connections>
                        
    3. Starten Sie den SRM-Dienst neu.
    4. Wiederholen Sie die Konfiguration auf dem SRM-Server auf der anderen Site.

  • Eine SRM-Installation kann nicht geändert werden, wenn bei der Erstinstallation eine IPv6-Adresse für den SRM-Server verwendet wurde.

    Wenn Sie bei der Installation von SRM Server eine IPv6-Adresse verwendet haben und danach versuchen, die Installation durch Ausführung des SRM-Installationsprogramms im Änderungsmodus zu ändern, schlägt der Änderungsversuch mit folgendem Fehler fehl: Fehler beim VMware vCenter Site Recovery Manager-Setup. Dies wurde behoben.

Bekannte Probleme

Die folgenden bekannten Probleme wurden beim Testen der Software erkannt. Sie helfen Ihnen, das Verhalten, auf das Sie in dieser Version treffen, besser zu verstehen.

  • Bei großen Festplatten wird unnötigerweise eine vollständige Synchronisierung durchgeführt

    Wenn Festplatten, die größer als 256 GB sind, mit vSphere Replication (VR) geschützt werden, wird bei jedem Vorgang, der zu einem internen Neustart des virtuellen Festplattengeräts führt, eine vollständige Synchronisierung der Festplatte durchgeführt. Interne Neustarts treten in den folgenden Fällen auf:

    • Eine virtuelle Maschine wird neu gestartet
    • Eine virtuelle Maschine wird mit vMotion verschoben
    • Eine virtuelle Maschine wird neu konfiguriert
    • Von einer virtuellen Maschine wird ein Snapshot erstellt
    • Die Replizierung wird angehalten und fortgesetzt

    Die vollständige Synchronisierung wird von ESX initiiert und jede Lösung dieses Problems würde ein Update auf ESX erfordern. Diese Synchronisierungen umfassen zusätzliche E/A für die Festplatten der Schutz- und der Wiederherstellungs-Site, was oft länger dauert als die Recovery Point Objective (RPO) und zur Folge hat, dass das RPO-Ziel verfehlt wird. Dieses Problem besteht in ESXi Server 5.0, wurde aber in ESXi Server 5.0 Update 1 behoben.

    Problemumgehung: Führen Sie ein Upgrade von ESXi Server auf Version 5.0 Update 1 durch.

  • Die Einstellung von LVM.enableResignature auf 1 bleibt nach einem Test-Failover bestehen

    SRM unterstützt keine ESX-Umgebungen, bei denen der Parameter LVM.enableResignature auf 0 gesetzt ist. Während eines Test-Failovers oder eines echten Failovers setzt SRM LVM.enableResignature automatisch auf 1, wenn der Parameter nicht bereits gesetzt ist. SRM legt dieses Flag fest, um die Snapshot-Volumes neu zu signieren, und mountet sie zur Wiederherstellung auf ESX-Hosts. Nachdem der Vorgang abgeschlossen ist, bleibt der Parameter auf 1. Weitere Informationen finden Sie in KB 2010051.

  • Rekonfiguration von vSphere Replication auf einer virtuellen Maschine war nach dem Empfang von Fehler beim Festschreiben der Transaktion während der Konfiguration nicht möglich

    Wenn Sie die Meldung Fehler beim Festschreiben der Transaktion während der Konfiguration der Replizierung auf einer virtuellen Maschine erhalten, schlägt jeder Versuch, die Replizierung auf der virtuellen Maschine erneut zu konfigurieren, fehl. Dieses Problem tritt auf, weil vSphere Replication nach dem Konfigurationsversuch die Konfigurationsdaten nicht ordnungsgemäß bereinigt. Folglich scheint die Replizierung der virtuellen Maschine für vSphere Replication konfiguriert zu sein, sie ist es aber nicht.

    Problemumgehung: Um die Konfigurationsdaten korrekt zu bereinigen, deaktivieren Sie die Replizierung der virtuellen Maschine über die Befehlszeile.

    1. Melden Sie sich bei der ESXi-Konsole an.
    2. Führen Sie einen Befehl aus, um die ID der virtuellen Maschine im ESXi-Host nachzuschlagen.
      # vim-cmd vmsvc/getallvms | grep 
      virtual_machine_name 
                        
      Die ID der virtuellen Maschine ist die Nummer in der ersten Spalte.
    3. Führen Sie einen Befehl aus, um die Replizierung für die virtuelle Maschine mit der ID, die Sie zuvor ermittelt haben, zu deaktivieren.
      # vim-cmd hbrsvc/vmreplica.disable 
      virtual_machine_ID
                        
  • Das Kontrollkästchen für das erzwungene Failover bleibt ausgewählt, nachdem Sie die geplante Migration aktiviert haben

    Wenn Sie einen Wiederherstellungsplan ausführen, die Option „Erzwungener Failover“ ausgewählt ist und Sie danach zur geplanten Migration zurück wechseln, indem Sie Geplante Migration auswählen, bleibt das Kontrollkästchen „Erzwungener Failover“ ausgewählt und wird im Assistenten „Wiederherstellungsplan ausführen“ abgeblendet dargestellt. Dieses Problem betrifft nur die Benutzeroberfläche und SRM funktioniert ordnungsgemäß.

    Problemumgehung: Schließen Sie den Assistenten „Wiederherstellungsplan ausführen“ und öffnen Sie ihn wieder, nachdem Sie die Option „Erzwungener Failover“ deaktiviert haben.

  • Wiederherstellungs- bzw. Migrationsvorgänge können fehlschlagen, wenn Platzhalterdatenspeicher nicht für alle Hosts in einem geschützten Cluster sichtbar sind

    Während der Wiederherstellung und Migration werden Platzhalter-VMs durch wiederhergestellte virtuelle Maschinen ersetzt. Wenn Sie über einen Cluster mit mehreren Hosts auf der Wiederherstellungs-Site verfügen, müssen alle Platzhalterdatenspeicher für alle Hosts im Cluster verfügbar sein, anderenfalls kann das Auslagern virtueller Maschinen fehlschlagen. SRM hindert Sie nicht daran, Platzhalterdatenspeicher auszuwählen, die nicht allen Hosts im Cluster zur Verfügung stehen. Wenn Platzhalterdatenspeicher nicht für alle Hosts sichtbar sind, schlägt der Wiederherstellungsplan mit der Fehlermeldung Fehler – Auf Datei [Datenspeicher] kann nicht zugegriffen werden – Registrierung der geschützten VMs konnte nicht aufgehoben werden fehl. Hosts müssen Zugriff auf die Datenspeicher haben, die sowohl die Platzhalter-VMs als auch die wiederhergestellten virtuellen Maschinen enthalten.

    Problemumgehung: Prüfen Sie manuell, ob die Datenspeicher für die als Platzhalter dienenden virtuellen Maschinen und die wiederhergestellten virtuellen Maschinen für alle Hosts in einem geschützten Cluster sichtbar sind.

  • Nach dem Upgrade werden VRM-Server- und VR-Server-Versionen auf der Registerkarte "Übersicht" der virtuellen Maschine nicht aktualisiert

    Wenn Sie ein Upgrade einer vorhandenen Installation der vSphere Replication Manager Server-Appliance (VRM-Server) von Version 1.0 auf Version 1.0.1 durchführen, werden die Versionsnummern von VRM-Server und VR-Server auf der Registerkarte "Übersicht" der virtuellen Maschine nicht aktualisiert. Wenn Sie in der vCenter Server-Bestandsliste den VRM-Server bzw. einen VR-Server auswählen, wird auf der Registerkarte "Übersicht" selbst dann weiterhin Version 1.0.0.0 angezeigt, wenn der VRM-Server auf Version 1.0.1 aktualisiert wurde. Wenn Sie eine Neuinstallation von VRM-Server-Version 1.0.1 durchführen, wird auf der Registerkarte "Übersicht" die korrekte Versionsnummer angezeigt.

    Problemumgehung: Prüfen Sie die Versionsnummer in der Virtual Appliance Management Interface für den VRM-Server:

    1. Melden Sie sich bei https:// VRM_server_IP_address:8080 an.
    2. Wählen Sie die Registerkarte Aktualisieren.
    3. Klicken Sie auf Status. Die Versionsnummer ist 1.0.1.0.

    Im vSphere-Client wird in der Konsole für den VRM-Server bzw. VR-Server jedoch die korrekte Versionsnummer angezeigt.

  • Die Verwendung nicht unterstützter Datenbanken mit dem vSphere Replication-Verwaltungsserver ist möglich

    Sie können den vSphere Replication-Verwaltungsserver (VRM-Server) zur Verwendung mit Datenbanken konfigurieren, die nicht unterstützt werden, und die VRM-Server-Konfiguration verläuft erfolgreich ohne Warnungen zur Datenbankunterstützung. Allerdings kann die Verwendung einer nicht unterstützten Datenbank zu unvorhersehbarem Verhalten führen. Die folgenden Datenbanken wurden vollständig getestet und werden zur Verwendung mit dem VRM-Server unterstützt:

    • SQL Server 2005 SP4 64-Bit
    • SQL Server 2008 R2 SP1 64-Bit
    • SQL Server 2008 R2 64-Bit

  • Einige SRAs behandeln beim Failover bestimmte Zeitzonen nicht ordnungsgemäß

    Test-Failover und echte Failover können mit der Fehlermeldung Erstellen von Snapshots von Replikat-Geräten für 'protection-group-999' mit einem Array-Paar 'array-pair-999': Vmacore::SystemException – „Der Parameter ist falsch.“ gestoppt werden. “ (87) fehlschlagen. Dieser Fehler beruht auf einer fehlerhaften Handhabung der Zeitzone, die vom Speicher-Array an den SRA zurückgegeben wird. Dieses Problem tritt bei allen Zeitangaben vor dem 1. Januar 1970 auf. Hinweise zu Details und Problemumgehungen finden Sie in KB 2018597.

  • Während eines Upgrades von SRM 4.1.2 auf SRM 5.0.2 schlägt der Befehl srm-migration importConfig aufgrund von Änderungen der Datenspeicher-Objekt-IDs fehl

    Der Upgrade-Vorgang für SRM 5.0.2 wird ohne Fehler durchgeführt, vCenter Server startet neu und die Hosts, Gäste und Speicher werden alle in demselben Zustand online geschaltet, als ob der vCenter Server-Dienst angehalten worden wäre. Allerdings schlagen während der SRM-Migration die Importvorgänge der Schutzgruppe mit folgendem Fehler fehl:

    Überspringen des VM-Schutzes für alle VMs in der Gruppe ( Gruppe) aufgrund eines Fehlers: Mindestens ein Datenspeicher ist bereits in einer anderen Gruppe geschützt oder wird derzeit nicht repliziert.

    Die Datenspeicher-Objekt-IDs, die in der SRM-Datei exportConfig.xml aufgelistet werden, unterscheiden sich von denselben Datenspeicher-Objekt-IDs, die im MOB-Browser angezeigt werden. Dieses Problem hängt mit dem in KB 2007404 beschriebenen Problem zusammen.

    Problemumgehung: Bearbeiten Sie exportConfig.xml, um die Datenspeicher-Objekt-IDs aus dem MOB-Browser zu verwenden, und führen Sie den Befehl srm-migration importConfig erneut durch.

  • Ereignisse werden auf koreanischen Betriebssystemen nicht ordnungsgemäß angezeigt

    Wenn der vSphere-Client gestartet wird, ermittelt er das Gebietsschema, auf dem er ausgeführt wird, und wählt die anzuzeigenden Meldungen gemäß dem Gebietsschema aus. Wenn der vSphere Client auf einem koreanischen Betriebssystem installiert ist, fordert der Client Nachrichten aus dem ko-Ordner in der vCenter Server-Installation an, weil der vCenter Server und der vSphere Client für die koreanische Sprache lokalisiert sind. vCenter Server und der vSphere-Client sind für die koreanische Sprache lokalisiert, SRM aber nicht. Daher werden XXX-Meldungen anstelle von SRM Server-Meldungen angezeigt. Um dieses Problem zu lösen, erstellen Sie eine Kopie des Ordners enin C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vcDr\locale\. Benennen Sie den Ordner von enin koum und starten Sie die vCenter Server- und SRM-Dienste neu.

  • Auf der Registerkarte "Geräte" werden in der Ansicht "Array-Manager" der SRM-Benutzeroberfläche doppelte Volumes angezeigt

    Dieses Problem tritt auf, wenn die Zielnummer einer LUN mit der Quellnummer einer anderen LUN identisch ist. Dies ist ein UI-Problem und betrifft Test- bzw. echte Wiederherstellungen nicht.

  • Ein Wiederherstellungs- oder Test-Workflow schlägt für eine virtuelle Maschine mit der folgenden Meldung fehl: Fehler – Unerwarteter Fehler '3008' bei der Kommunikation mit ESX oder der Gast-VM: Verbindung mit der virtuellen Maschine nicht möglich.

    Unter seltenen Umständen kann dieser Fehler auftreten, wenn Sie die IP-Anpassung oder einen Callout-Befehl im Gast für die virtuelle Maschine konfigurieren und der Wiederherstellungs-Site-Cluster im vollautomatischen DRS-Modus ist. Ein unerwarteter vMotion-Befehl kann einen vorübergehenden Kommunikationsfehler mit der virtuellen Maschine bewirken, wodurch ein Fehler im Anpassungsskript entsteht.

    Problemumgehung: Wiederherstellungsplan erneut ausführen. Wenn der Fehler weiter auftritt, konfigurieren Sie Wiederherstellungs-Site-Cluster-DRS auf den manuellen Modus und führen Sie den Wiederherstellungsplan erneut aus.

  • Wiederherstellung schlägt mit der Meldung Fehler beim Erstellen des Test-Bubble-Images für die Gruppe ... fehl. Die genaue Ausnahmebedingung lautet: Fehler beim Abrufen der Host-Mounts für den Datenspeicher: managed-object-id...oder Das Objekt wurde bereits gelöscht oder wurde nicht vollständig erstellt.

    Wenn Sie eine Testwiederherstellung oder eine geplante Wiederherstellung vornehmen und der Wiederherstellungsplan mit der spezifischen Ausnahmebedingung fehlschlägt, wurde die LUN, die für das Speichern der Replizierungsdaten verwendet wird, vorübergehend von ESXi getrennt. Wenn die Verbindung wieder aufgenommen wird, läuft die Replizierung normal weiter und es gehen keine Replizierungsdaten verloren. Die Ausnahmebedingung tritt während dieser Szenarien auf:

    • vSphere Replication kann die LUN nicht finden, weil die LUN ihre interne ID geändert hat.
    • Die interne ID des Zieldatenspeichers ändert sich, wenn der Host, der den Zieldatenspeicher enthält, aus der vCenter-Bestandsliste entfernt und später hinzugefügt wird.

    Sie müssen die Replizierung manuell neu konfigurieren, um die neue ID zu aktualisieren.

    Problemumgehung: Wenn die primäre Site nicht mehr verfügbar ist, kontaktieren Sie den VMware Support, um Anweisungen für das manuelle Aktualisieren der VRMS-Datenbank mit der neuen verwalteten Objekt-ID für den neuen Datenspeicher zu erhalten. Wenn die primäre Site immer noch verfügbar ist:

    1. Führen Sie einen Bereinigungsvorgang für den fehlgeschlagenen Wiederherstellungsplan aus.
    2. Klicken Sie in der Ansicht vSphere Replication auf der Registerkarte Virtuelle Maschinen mit der rechten Maustaste auf eine virtuelle Maschine und wählen Sie Replizierung konfigurieren aus.
    3. Klicken Sie auf Weiter und auf Durchsuchen, um den Standort der Dateien im Datenspeicher zu ändern, der getrennt und wieder verbunden wurde, und wählen Sie denselben Standort für Datenspeicher und Ordner aus wie vorher.
    4. Verwenden Sie die bestehenden Festplatten wieder und konfigurieren Sie die Replizierung der virtuellen Maschine neu. Der vSphere Replication-Managementserver übernimmt die Identität des geänderten Datenspeichers (ID des verwalteten Objekts) in vCenter Server.
    5. Warten Sie, bis die anfängliche Synchronisierung beendet ist. Diese Synchronisierung verwendet bestehende Festplatten für die Datenkonsistenz.