VMware

VMware vCenter Site Recovery Manager 5.0.1 | 15. MÄRZ 2012 | Build 633117

Letzte Aktualisierung: 26. MÄRZ 2012

Ü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.1 bietet die folgenden Verbesserungen:

  • Erzwungenes Failover zum Wiederherstellen virtueller Maschinen in den Fällen, wo Speicher-Arrays an der geschützten Site ausfallen und infolgedessen geschützte virtuelle Maschinen nicht mehr verwaltet und heruntergefahren bzw. ausgeschaltet werden können sowie die Registrierung nicht aufgehoben werden kann.
  • Unterstützung für die IP-Anpassung bei Ubuntu 10.04, 10.10 11.04 und 11.10.
  • Bugfixes, die unter Behobene Probleme beschrieben werden.

Lokalisierung

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

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

Kompatibilität

SRM-Kompatibilitätstabelle

Informationen über die aktuelle Interoperabilität und die Produktkompatibilität finden Sie unter Kompatibilitätstabellen für VMware vCenter Site Recovery Manager.

Kompatible Speicher-Arrays und Speicherreplizierungsadapter

Die aktuelle Liste der unterstützten kompatiblen Speicher-Arrays und SRAs finden Sie unter Site Recovery Manager-Speicherpartner-Kompatibilitätstabelle.

VMware VSA-Unterstützung

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

Installation und Upgrade

SRM 5.0.1 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 Upgrades die ESXi-Server-Hosts auf Version 5.0 oder ESXi Server 5.0 Update 1 aktualisieren.

Weitere Informationen dazu, wie Sie SRM 5.0.1 ohne ein Upgrade von einer vorherigen Version installieren, finden Sie unter Installieren und Aktualisieren von Site Recovery Manager im Administratorhandbuch für Site Recovery Manager .

Upgrade von SRM 5.0 auf SRM 5.0.1

Sie können ein In-Place-Upgrade von SRM 5.0 auf SRM 5.0.1 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.1- buildnumber.exe herunter und führen Sie die Datei aus.
  4. Klicken Sie auf Ja, um das Upgrade von SRM zu bestätigen.
  5. Klicken Sie auf Weiter, um SRM 5.0.1 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 Beenden, wenn die Installation abgeschlossen 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-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.
  4. Klicken Sie auf Herunterladen und installieren, um das SRM 5.0.1-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.

Upgrade von vSphere Replication 1.0 auf vSphere Replication 1.0.1

SRM 5.0 enthielt vSphere Replication 1.0. SRM 5.0.1 enthält vSphere Replication 1.0.1. Beim Upgrade von SRM 5.0 auf SRM 5.0.1 wird nicht automatisch ein Upgrade von vSphere Replication 1.0 auf vSphere Replication 1.0.1 durchgeführt. vSphere Replication 1.0.1 ist funktional identisch mit vSphere Replication 1.0, enthält aber zudem Bugfixes.

Sie können SRM 5.0.1 mit vSphere Replication 1.0 ausführen oder Sie können ein Upgrade von vSphere Replication auf Version 1.0.1 durchführen, um von den Bugfixes in Version 1.0.1 zu profitieren. Sie führen getrennte Upgrades von vSphere Replication Management Server (VRM-Server) und vSphere Replication Server (VR) durch.

Upgrade des VRM-Servers:

  1. Upgrade des SRM-Servers und Clients auf SRM 5.0.1.
  2. Wechseln Sie zur Konfigurationsbenutzeroberfläche des VRM-Servers unter https:// VRMS-IP-Adresse:8080.
  3. Melden Sie sich bei der VRM-Server-Konfigurationsbenutzeroberfläche als "root" an.
  4. Wählen Sie die Registerkarte Update aus.
  5. Klicken Sie auf Updates überprüfen. Die Update-Prüfung zeigt an, dass Version 1.0.1 verfügbar ist.
  6. Klicken Sie auf Update installieren.
  7. Wählen Sie die Registerkarte VRM > Konfiguration aus und klicken Sie auf die Schaltfläche Neustart unter dem Status des VRM-Servers, um den VRM-Server neu zu starten.
  8. Wiederholen Sie den Vorgang für den VRM-Server auf der Wiederherstellungs-Site.

Upgrade des VR-Servers:

  1. Führen Sie ein Upgrade des VRM-Servers durch.
  2. Wechseln Sie zur Konfigurationsbenutzeroberfläche des VR-Servers unter https:// VR-IP-Adresse:5480.
  3. Melden Sie sich bei der VR-Server-Konfigurationsbenutzeroberfläche als "root" an.
  4. Wählen Sie die Registerkarte Update aus.
  5. Klicken Sie auf Updates überprüfen. Die Update-Prüfung zeigt an, dass Version 1.0.1 verfügbar ist.
  6. Klicken Sie auf Updates installieren.
  7. Wählen Sie die Registerkarte System > Information und klicken Sie auf Neu starten, um den VR-Server neu zu starten.
  8. Wiederholen Sie den Vorgang für die VR-Server auf der Wiederherstellungs-Site.

Upgrade von SRM 4.1.2 auf SRM 5.0.1

Sie können ein In-Place-Upgrade von SRM 4.1.2 auf SRM 5.0.1 durchführen. Es wird empfohlen, statt Neuinstallationen In-Place-Upgrades zu verwenden, 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.1 durchzuführen, müssen Sie zunächst den SRM 4.1.2-Client deinstallieren.

Hinweis: Das Upgrade von SRM 4.1 oder SRM 4.1.1 auf SRM 5.0.1 wird nicht unterstützt.

Um ein Upgrade von SRM 4.1.2 auf SRM 5.0.1 durchzuführen, führen Sie die Schritte zum Upgrade von SRM 4.1 bzw. 4.1.1 auf SRM 5.0 unter Aktualisieren von SRM im Administratorhandbuch für Site Recovery Manager durch. Weitere Informationen hierzu finden Sie auch im Blog SRM 5 Upgrade Process .

Open Source-Komponenten

Informationen über Copyright und Lizenzen für die Open Source-Softwarekomponenten, die im Lieferumfang von vCenter Site Recovery Manager 5.0.1 enthalten sind, finden Sie auf der SRM-Downloads-Site. 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

  • Interoperabilität mit Storage vMotion und Speicher-DRS
    Wegen einiger bestimmter und eingeschränkter Fälle, bei denen die Wiederherstellbarkeit während der Speicherverschiebung beeinträchtigt werden kann, wird Site Recovery Manager 5.0.1 weder für die Verwendung mit Storage vMotion (SVmotion) noch für die Verwendung mit SDRS (Storage Distributed Resource Scheduler), einschließlich der Verwendung von Datenspeicher-Clustern, unterstützt. 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.

  • Die Netzwerkadressübersetzung (NAT) wird von SRM nicht unterstützt
    Beim Konfigurieren von vSphere Replication müssen Sie den vSphere Replication Server (VR-Server) mit einer IP-Adresse konfigurieren, 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.1 bietet nur eingeschränkte 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. Informationen dazu, wie SRM zum Schützen der vCD-Serverinstanzen, vCenter Server-Instanzen und Datenbanken verwenden, die die Verwaltungsinfrastruktur für vCloud Director bereitstellen, finden Sie in der VMware vCloud Director-Infrastrukturflexibilitäts-Fallstudie.

  • Erneuter Schutz und automatisiertes Failback wird nicht durch vSphere Replication unterstützt
    Der erneute Schutz und das automatisierte Failback werden nur bei 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 werden von vSphere Replication nicht unterstützt
    Sie können vSphere Replication nicht in Verbindung mit vSphere Fault Tolerance, Vorlagen virtueller Maschinen, verknüpften Klonen oder mit der physischen Raw-Festplattenzuordnung (RDM) verwenden.

  • Schutz und Wiederherstellung von virtuellen Maschinen mit Arbeitsspeicherzustand-Snapshots
    Beim Schützen von virtuellen Maschinen mit Arbeitsspeicherzustand-Snapshots müssen die ESX-Hosts der Schutz- und Wiederherstellungs-Sites über kompatible CPUs verfügen, wie dies in den folgenden VMware-Knowledgebase-Artikeln beschrieben ist: vMotion-CPU-Kompatibilitätsanforderungen für Intel-Prozessoren und vMotion-CPU-Kompatibilitätsanforderungen für AMD-Prozessoren. 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 Einschränkungen beim Schutz und der Wiederherstellung von virtuellen Maschinen mit Snapshots finden Sie unter Einschränkungen beim Schutz und der Wiederherstellung von virtuellen Maschinen im Administratorhandbuch für Site Recovery Manager .

  • Maximale Anzahl der Wiederherstellungspläne pro SRM-Serverinstanz
    Sie können maximal die folgende Anzahl von Wiederherstellungsplänen pro SRM-Serverinstanz erstellen:

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

    Informationen über die Anzahl der Wiederherstellungspläne, die Sie gleichzeitig ausführen können, sowie andere Einschränkungen beim Betrieb von SRM finden Sie im Administratorhandbuch für Site Recovery Manager .

Behobene Probleme

  • Die geplante Migration führt möglicherweise zu einer Verlangsamung der ESX-Hosts

    Während der geplanten Migration instruiert SRM zuerst die ESX-Hosts, ein Unmounten der replizierten Datenspeicher durchzuführen und die LUNs zu trennen, die für ein Backing dieser Datenspeicher sorgen. Dann instruiert SRM die Speicher-Array-Software, die getrennten LUNs vor Schreibzugriffen zu schützen. Dieser Vorgang stellt sicher, dass bei Geräten auf ESX-Hosts kein Zustand des Typs "Keine Pfade verfügbar" (All Paths Down, APD) für die Datenspeicher und LUNs eintritt, die migriert werden. Das Migrieren einer virtuellen Maschine mit RDMs führt möglicherweise dazu, dass bei RDM LUNs ein APD-Zustand eintritt. Nachdem bei RDMs ein APD-Zustand eingetreten ist, versuchen ESX-Hosts weiterhin, eine neue Verbindung zu den verloren gegangenen RDM LUNs herzustellen. Da sich die Anzahl der nicht verfügbaren RDMs erhöht, erhöht sich entsprechend die Anzahl der Versuche des ESX-Hosts, eine neue Verbindung zu den verloren gegangenen RDMs herzustellen. Wenn dieser Prozess fortschreitet, antwortet der ESX-Host möglicherweise langsamer und vCenter Server kommt letztendlich zu dem Ergebnis, dass die Hosts nicht mehr reagieren. Dies tritt eher bei bestimmten Speicher-Arrays auf. Beispielsweise tritt dies eher auf, wenn ein SRA ein ISCSI-Ziel pro LUN unterstützt. Dies ist nun behoben.

  • SRM-Aufgaben, die zu schnell bereinigt werden, lösen eine ManagedObjectNotFound-Ausnahme aus

    SRM-Aufgaben werden eine Minute, nachdem die Aufgaben abgeschlossen sind, aus dem Dienst vmware-dr entfernt. Wenn sich SRM auf ein Aufgabenobjekt bezieht, das entfernt wurde, wird die Ausnahme ManagedObjectNotFound zurückgegeben und die Fehlermeldung Das Objekt wurde bereits gelöscht oder noch nicht vollständig erstellt angezeigt. Die Standardzeit zum Bereinigen von Aufgaben beträgt eine Minute. Falls dieses Verhalten auftritt, können Sie die Bereinigungszeit konfigurieren, indem Sie den Parameter Topology.drTaskCleanupTime in der Datei config.xml festlegen.

    <topology>
    <drTaskCleanupTime>300</drTaskCleanupTime>
    </topology>

  • Die Anzahl der Pro-CPU-Lizenzen ist nicht korrekt

    Einige Kunden, die SRM 1.x und SRM 4.0 erworben haben, verwenden möglicherweise immer noch Pro-CPU-Lizenzen. Mit diesen Pro-CPU-Lizenzen können sie SRM 5.0.1 weiterhin verwenden. In SRM 5.0 ist die Formel zum Berechnen der Anzahl der verwendeten CPU-Lizenzen allerdings zu großzügig. In diesem Szenario ist es möglich, dass bei der Konvertierung fälschlicherweise zu viele Pro-CPU-Lizenzen für SRM 5.0 zugeteilt werden. Dieses Problem wurde in SRM 5.0.1 behoben und es gibt jetzt strengere Warnmeldungen bei nicht ausreichender Anzahl an Lizenzen.

  • Das Schützen einer virtuellen Maschine in einem replizierten Datenspeicher, der sich über zwei Festplattenpartitionen erstreckt, führt dazu, dass SRM unerwartet beendet wird und nicht neu gestartet werden kann

    Wenn Sie eine virtuelle Maschine schützen, die sich in einem replizierten Datenspeicher befindet, der sich über zwei Festplattenpartitionen desselben Geräts erstreckt, wird SRM beim Neuberechnen der Datenspeichergruppe unerwartet beendet. In den SRM-Protokollen steht der Fehler Panic: Assert Failed: "ok" @ d:\build\ob\bora-474459\srm\public\persistence/saveLoadUtils.h:329. Der Neustart des SRM-Servers schlägt dann fehl. Dieses Problem wurde behoben.

  • Kurze Unterbrechungen der Netzwerkkommunikation können dazu führen, dass der SRM-Server unendlich lange wartet

    Wenn die Netzwerkkommunikation zwischen der geschützten und der Wiederherstellungs-Site für weniger als fünf Minuten unterbrochen wird, antwortet der SRM-Server möglicherweise nicht mehr. Das Problem wird während der Netzwerkunterbrechung durch das Fehlen von Update-Ergebnissen und die serverseitige Zeitüberschreitung beim Aufrufen von waitforupdate durch die Remote-Site verursacht. Dieses Problem wurde dadurch behoben, dass clientseitige Zeitüberschreitungen für den Aufruf von waitforupdate eingeführt wurden. Die standardmäßige clientseitige Zeitüberschreitung beträgt 5 Minuten.

  • Neuaktivierung von erneuten Hostprüfungen während des Testens und der Wiederherstellung

    Bei SRM 4.1 gab es die konfigurierbare Option storageProvider.hostRescanCnt, die es Ihnen ermöglichte, Hosts während des Testens und der Wiederherstellung wiederholt zu prüfen. Diese Option fehlte in SRM 5.0, wurde jedoch im Menü Erweiterte Einstellungen von SRM 5.0.1 wiederhergestellt. Klicken Sie dazu mit der rechten Maustaste auf eine Site in der Ansicht Sites und wählen Sie Erweiterte Einstellungen und anschließend storageProvider aus. Weitere Informationen finden Sie unter .

  • Die Anpassungsspezifikation konfiguriert nicht das Gateway für Red Hat Enterprise Linux 5.x

    Das Anpassen von Images von virtuellen Red Hat Enterprise Linux 5.x-Maschinen sorgt nicht dafür, dass das Gateway ordnungsgemäß konfiguriert wird. Wenn Sie folglich während der Anpassung der wiederherzustellenden virtuellen RHEL 5.x-Maschine ein neues Gateway zuweisen, wird der neue Gateway-Eintrag an die Datei /etc/sysconfig/network-scripts/route-ethX angehängt. Der RHEL-Netzwerkdienst liest den ersten Eintrag in dieser Datei, d. h. die alte Gateway-Einstellung auf der Schutz-Site, und ignoriert die vom Benutzer bei der Anpassung vorgenommenen Änderungen am Gateway. Dies wurde behoben.

  • Der Wiederherstellungs-SRM-Server wird nach dem Anhalten unerwartet beendet und eine Fehlermeldung wird angezeigt, die besagt, dass der falsche Kontext für den Wiederherstellungsplan vorliegt

    Nach dem Anhalten sowohl der geschützten als auch der Wiederherstellungs-Site wird der SRM-Server auf der Wiederherstellungs-Site unerwartet beendet, wenn Sie ihn neu starten, und die folgende Fehlermeldung wird angezeigt: Falscher Kontext für CreateRemoteSuspendVmListViewAndCallback für Plan "Wiederherstellungsplan". Dies wurde behoben.

  • Das Konfigurieren von vSphere Replication führt zu einem Fehler des Typs "Ungültiges Gebietsschema", wenn bei SRM das Gebietsschema "Chinesisch (vereinfacht)" mit der vCenter Server-Appliance verwendet wird

    Wenn bei SRM das Gebietsschema "Chinesisch (vereinfacht)" mit der vCenter Server-Appliance verwendet wird, schlägt der Versuch, vSphere Replication auf einer virtuellen Maschine zu konfigurieren, mit einem Fehler des Typs "Ungültiges Gebietsschema" fehl. Dies wurde behoben.

  • Während des Startvorgangs wird SRM unerwartet beendet, wenn die Prüfung der CPU-Lizenznutzung gestartet wird

    Unter bestimmten Bedingungen wird während des Startvorgangs SRM unerwartet beendet, wenn die Prüfung der CPU-Lizenznutzung gestartet wird, und die folgende Fehlermeldung wird angezeigt: Unerwartetes Objekt in Ergebnissen: vim.VirtualMachine. Dies wurde behoben.

  • Durch das Ausführen des SRM-Installationsprogramms im Reparaturmodus wird die Datei "exportConfig.xml" gelöscht

    Bei der Durchführung eines In-Place-Upgrades von SRM 4.1.x auf 5.0.x erstellt SRM die Datei exportConfig.xml, die Details zu Bestandslistenzuordnungen, Datenspeicherzuordnungen, geschützten virtuellen Maschinen und Gruppen, Wiederherstellungsplänen usw. enthält. Sie können diese Datei verwenden, um nach dem Upgrade Daten in die SRM-Datenbank zu migrieren. Wenn Sie jedoch das SRM-Installationsprogramm im Reparaturmodus ausführen, bevor Sie die Daten in die Datenbank migrieren, wird die Datei exportConfig.xml durch das Installationsprogramm gelöscht. Dieses Problem wurde behoben. Beim Ausführen des Installationsprogramms im Reparaturmodus wird die Datei exportConfig.xml nicht gelöscht.

  • Die IP-Anpassung von virtuellen Maschinen schlägt mit dem Fehlercode 14010 fehl

    Die IP-Anpassung von virtuellen Maschinen schlägt mit dem Fehler "Bei der Kommunikation trat ein Fehler auf" Fehlercode: '14010' fehl, wenn versucht wird, Adapter zu konfigurieren, die nicht spezifisch für VMware sind. Dies wurde behoben. Die IP-Anpassung überspringt jetzt nicht standardmäßige Netzwerkadapter und konfiguriert nur den physischen Adapter.

  • Die Testwiederherstellung kann fehlschlagen, wenn SRA doppelte Snapshot-IDs von mehreren Speichergeräten erhält

    Die Ausführung einer Testwiederherstellung kann mit dem Fehler Panic: Assert Failed: "runtimeInfo._results != 0 (Missing results in plan: recovery-plan-10257)" @ d:/build/ob/bora-474459/srm/src/recovery/engine/manager.cpp:1300^M fehlschlagen. Dieses Problem tritt auf, weil es Speicherreplizierungsadapter (SRA) ermöglichen, dass die Snapshot-IDs auf den verschiedenen Speichergeräten identisch sein können, aber SRM benötigt eindeutige Snapshot-IDs. Dies betrifft nur Testwiederherstellungen, nicht tatsächliche Wiederherstellungen. Das Problem wurde behoben und SRM akzeptiert jetzt doppelte Snapshot-IDs.

  • Das Blättern nach unten in der Netzwerkliste für Wiederherstellungspläne ist nicht möglich, wenn viele Netzwerke verfügbar sind

    Wenn in der SRM-Umgebung mehr als 30 Netzwerke zur Verfügung stehen, ist die vollständige Liste der verfügbaren Netzwerke, die Sie beim Erstellen eines Wiederherstellungsplans auswählen können, nicht sichtbar. Dieses Problem wurde behoben und Sie können jetzt die komplette Liste durchblättern.

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.

    Umgehung: 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, in denen das Flag LVM.enableResignature auf 0 festgelegt ist. Während eines Test-Failovers oder eines tatsächlichen Failovers legt SRM LVM.enableResignature automatisch auf 1 fest, wenn das Flag nicht bereits festgelegt wurde. SRM legt dieses Flag fest, um die Snapshot-Volumes neu zu signieren, und mountet sie zur Wiederherstellung auf ESX-Hosts. Nach Abschluss des Vorgangs ist das Flag weiterhin auf 1 festgelegt. Weitere Informationen dazu finden Sie unter KB 2010051.

  • vSphere Replication kann auf einer virtuellen Maschine nicht neu konfiguriert werden, nachdem während der Konfiguration der Fehler Fehler beim Übergeben von Transaktionen aufgetreten ist

    Wenn Sie während des Konfigurierens der Replizierung einer virtuellen Maschine den Fehler Fehler beim Übergeben von Transaktionen erhalten, schlagen alle Versuche fehl, die Replizierung auf der virtuellen Maschine neu zu konfigurieren. 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.

    Umgehung: Damit die Konfigurationsdaten ordnungsgemäß bereinigt werden, 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, wobei die Option für das erzwungene Failover ausgewählt ist, und Sie dann die geplante Migration aktivieren, indem Sie die Option Geplante Migration wählen, bleibt das Kontrollkästchen für das erzwungene Failover im Assistenten "Wiederherstellungsplan ausführen" ausgewählt und grau dargestellt. Dieses Problem betrifft nur die Benutzeroberfläche und SRM funktioniert ordnungsgemäß.

    Umgehung: Schließen und öffnen Sie den Assistenten "Wiederherstellungsplan ausführen" neu, nachdem Sie die Option für das erzwungene 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 dem Fehler Fehler - Zugriff auf die Datei [Datenspeicher] nicht möglich. Die Registrierung der geschützten VMs wurde aufgehoben fehl. Hosts müssen Zugriff auf die Datenspeicher haben, die sowohl die Platzhalter-VMs als auch die wiederhergestellten virtuellen Maschinen enthalten.

    Umgehung: Überprüfen Sie manuell, dass die Datenspeicher sowohl für die Platzhalter-VMs als auch für die wiederhergestellten virtuellen Maschinen allen 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 (VRMS-Appliance) 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.

    Umgehung: Überprüfen Sie die Versionsnummer in der Verwaltungsschnittstelle der virtuellen VRMS-Appliance:

    1. Melden Sie sich bei https:// VRMS-IP-Adresse:8080 an.
    2. Wählen Sie die Registerkarte Update aus.
    3. Klicken Sie auf Status. Die Versionsnummer ist 1.0.1.0.

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

  • Die Verwendung nicht unterstützter Datenbanken mit vSphere Replication Management Server ist möglich

    Sie können vSphere Replication Management Server (VRMS) zur Verwendung mit Datenbanken konfigurieren, die nicht unterstützt werden, und die VRMS-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 VRMS unterstützt:

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