VMware vCenter Site Recovery Manager 5.0 | 14. September 2011 | Build 474459

Letzte Aktualisierung: 16. September 2011

Ü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 unterstützt Sie bei der Aufstellung, Verwaltung und Ausführung zuverlässiger Notfallwiederherstellungspläne für Ihre virtuelle Umgebung. Mit der Freigabe der Version 5.0 hat VMware die Funktionen von Site Recovery Manager erweitert, um einen beispiellosen Schutz zu bieten. Neue Anwendungsfälle wurden durch das Hinzufügen der folgenden Funktionen ermöglicht:

  • vSphere Replication. Bei der gemeinsamen Verwendung mit VMware vSphere 5.0 bietet Site Recovery Manager 5.0 eine neue Funktionalität, bei der mithilfe des vSphere 5.0-Hosts eine Replizierung von eingeschalteten virtuellen Maschinen über das Netzwerk auf einen anderen vSphere 5.0-Host durchgeführt werden kann, ohne dass dafür eine auf einem Speicher-Array basierende Replizierung erforderlich ist. Da sich die virtuellen Maschinen beim Einsatz ändern, werden die geänderten Blöcke auf eine Schattenkopie der virtuellen Maschine repliziert, die sich auf der Wiederherstellungs-Site befindet. Dies geschieht in Übereinstimmung mit einem Wiederherstellungspunkt, der als Eigenschaft der virtuellen Maschine selbst festgelegt wurde.

  • Geplante Migration. Es wurde ein neuer Workflow entwickelt, mit dem die Migration bei minimalem Datenverlustrisiko durchgeführt wird. Wenn ein Fehler auftritt, hält die geplante Migration den Workflow an, damit das Problem behoben werden kann. Hierbei wird sichergestellt, dass die Systeme ordnungsgemäß stillgelegt werden und dass alle Datenänderungen vollständig repliziert wurden.

  • Automatisierter erneuter Schutz. Der erneute Schutz ist eine neue Erweiterung für Wiederherstellungspläne, die nur mit der Array-basierten Replizierung verwendet werden kann. Der automatisierte erneute Schutz ermöglicht der Umgebung auf der Wiederherstellungs-Site mit einem Klick den Schutz und das Replizieren der Umgebung zurück auf die ursprüngliche Schutz-Site.

  • Automatisiertes Failback. Das automatisierte Failback setzt die gesamte Umgebung auf die ursprünglich geschützte primäre Site zurück. Dies kann nur geschehen, nachdem der erneute Schutz sichergestellt hat, dass die Datenreplizierung und -synchronisierung auf der ursprünglichen primären Site eingerichtet wurden. Das Failback führt denselben Workflow aus, der zum Migrieren der Umgebung auf die Schutz-Site verwendet wurde, und stellt sicher, dass die kritischen Systeme, die der Wiederherstellungsplan umfasst, auf ihre ursprüngliche Umgebung zurückgesetzt werden. Ebenso wie der erneute Schutz steht das automatisierte Failback nur für die Verwendung mit der Array-basierten Replizierung von geschützten virtuellen Maschinen zur Verfügung.

  • Erweiterte Abhängigkeit - Definition. Dies umfasst das Hinzufügen von weiteren (5) Prioritätsgruppen und die Möglichkeit, Abhängigkeiten von virtuellen Maschinen innerhalb einer Prioritätsgruppe festzulegen. Abhängigkeiten virtueller Maschinen können festgelegt werden, um sicherzustellen, dass erforderliche Systeme verfügbar sind, bevor abhängige virtuelle Maschinen eingeschaltet werden. Dies ermöglicht eine hochorganisierte Workflow-Steuerung, bei der sichergestellt wird, dass erforderliche Dienste verfügbar sind, bevor abhängige virtuelle Maschinen eingeschaltet werden.

Internationalisierung

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

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

Kompatibilität

SRM-Kompatibilitätsmatrix

Informationen über die aktuelle Interoperabilität und die Produktkompatibilitätstabelle 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 Kompatibilitätstabelle für Site Recovery Manager Storage Partner.

VMware VSA-Unterstützung

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

Hinweise zu Installation und Upgrade

Die Dokumentation zu Verwaltung, Installation und Upgrade finden Sie im Administratorhandbuch für Site Recovery Manager.

Das Evaluierungshandbuch zur Unterstützung mit einer technischen Komplettlösung der wichtigsten Funktionen und Möglichkeiten von Site Recovery Manager 5.0 finden Sie unter VMware vCenter Site Recovery Manager-Ressourcen für Business Continuity.

Aktualisieren von einer vorherigen Version:

Ein In-Place-Upgrade von SRM 5.0 ist nur von SRM 4.1 aus möglich. In-Place-Upgrades werden anstelle von Neuinstallationen empfohlen, da hierbei alle Verlaufsberichte, Wiederherstellungspläne, Schutzgruppen und Anpassungen der Wiederherstellungspläne beibehalten werden.

SRM 5.0 kann nur dann mit vorherigen Versionen von vSphere (4.0, 4.1) und Virtual Infrastructure (3.5) ausgeführt werden, wenn die Array-basierte Replizierung verwendet wird. Wenn vSphere Replication verwendet werden soll (entweder alleine oder zusammen mit Array-basierter Replizierung), müssen vSphere-Hosts als Teil des Upgrade-Prozesses auf Version 5.0 aktualisiert werden.

Dies sind die allgemeinen Upgrade-Schritte für SRM 5.0:

  1. Deinstallieren Sie das SRM-Plug-In vom vSphere Client.
  2. Halten Sie den vCenter Server-Dienst der Schutz-Site an und aktualisieren Sie ihn auf Version 5.0.
  3. Wenn Sie beabsichtigen, vSphere Replication zu verwenden, müssen Sie zu diesem Zeitpunkt vSphere-Hosts auf ESXi 5.0 aktualisieren.
  4. Halten Sie den SRM-Dienst der Schutz-Site an und aktualisieren Sie ihn auf Version 5.0.
  5. Aktualisieren oder installieren Sie den Speicherreplizierungsadapter, der kompatibel mit SRM 5.0 ist. Dieser SRA muss für die Verwendung mit SRM 5.0 durch VMware zertifiziert sein.
  6. Wiederholen Sie diesen Prozess für die Wiederherstellungs-Site, nachdem Sie sichergestellt haben, dass die Basis-vSphere- und vCenter Server-Funktionalität ordnungsgemäß funktioniert. SRM funktioniert erst dann, wenn beide Sites vollständig aktualisiert wurden.
  7. Laden Sie das SRM-Plug-In auf den vSphere-Client herunter und installieren Sie es.
  8. Starten Sie SRM und stellen Sie sicher, dass das SRA ordnungsgemäß aktualisiert wird.
  9. Koppeln Sie die Sites, Array-Manager und Geräte. Aktivieren Sie die Array-Paare.
  10. Führen Sie das Befehlszeilen-Dienstprogramm srm-migration aus, um vorherige Wiederherstellungspläne, Schutzgruppen, Verlaufsberichte, Skripts und IP-Anpassungen zu importieren.

Eine vollständige Dokumentation des Upgrade-Prozesses finden Sie auf den Seiten 33-37 im Administratorhandbuch für Site Recovery Manager.

SRM SDKs

SRM 5.0 enthält 33 neue API-Vorgänge, von denen viele Site-spezifisch sind und eine Automatisierung der Prozesse ermöglichen, die eindeutig für jede Site sind. Neue API-Vorgänge in SRM 5.0 sind:

  • ListProtectionGroups
  • ListInventoryMappings
  • GetInfo
  • GetPeer
  • ListProtectedVms
  • ListProtectedDatastores
  • ListAssociatedVms
  • GetProtectionState
  • ProtectionGroupListRecoveryPlans
  • ProtectionGroupQueryVmProtection
  • ProtectVms
  • UnprotectVms
  • AssociateVms
  • UnassociateVms
  • GetTasks
  • IsComplete
  • GetProtectionStatus
  • ListPlans
  • GetHistory
  • RecoveryPlanGetInfo
  • RecoveryPlanGetPeer
  • Start
  • Cancel
  • ListPrompts
  • AnswerPrompt
  • GetResultCount
  • GetRecoveryResult
  • GetResultLength
  • RetrieveStatus
  • RetrieveContent
  • SrmLoginLocale
  • SrmLoginSites
  • SrmLogoutLocale

Beachten Sie, dass VMware ein aktualisiertes ausführliches Handbuch zur Verwendung der SRM SOAP-basierten API herausgeben wird. Sie finden es unter VMware vCenter Site Recovery Manager API.

Open Source-Komponenten

Informationen über Copyright und Lizenzen für die Open Source-Softwarekomponenten, die im Lieferumfang von vCenter Site Recovery Manager 5.0 enthalten sind, finden Sie unter Download VMware vCenter Site Recovery Manager for IT Disaster Recovery. 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 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.

  • Interoperabilität mit vCloud Director
    Site Recovery Manager 5.0 wird nicht zum Schutz von vCloud Director-Umgebungen oder virtuellen Maschinen unterstützt, die sich innerhalb einer vCloud Director-Umgebung befinden.

  • 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.

  • Lizenzanzahl bei der SRM-Konvertierung von pro-CPU in pro-VM ist falsch
    Einige Kunden, die SRM 1.x und SRM 4.0 erworben haben, verwenden möglicherweise immer noch pro-CPU zugeteilte Lizenzen. Es liegt ein bekanntes Problem beim Konvertieren dieser älteren pro-CPU-Lizenzen in pro-VM-Lizenzen für SRM 5.0 vor, bei dem die Formel zum Zählen der verwendeten CPU-Lizenzen zu großzügig ist. In diesem Szenario ist es möglich, dass bei der Konvertierung fälschlicherweise zu viele pro-VM-Lizenzen für SRM 5.0 zugeteilt werden. Dieses Verhalten ist falsch und wird im Rahmen eines Patches für SRM behoben. Überwachen Sie Ihren Lizenzkonvertierungszähler genau, um sicherzustellen, dass Sie den Vertragsbedingungen Ihrer Lizenzvereinbarung entsprechen und die Anzahl der geschützten VMs nicht überschreiten, für die Sie lizenziert sind.

  • Skalierbarkeitsgrenzwerte der Array-basierten Replizierung (ABR) und von vSphere Replication (VR)

    Die im Administratorhandbuch von Site Recovery Manager aufgeführten Skalierbarkeitsgrenzwerte sind falsch, werden jedoch demnächst aktualisiert. Dies sind die richtigen Skalierbarkeitsgrenzwerte:

    Skalierbarkeitsgrenzwerte der Array-basierten Replizierung (ABR)

    Geschützte VMs pro Schutzgruppe 500
    Geschützte VMs 1000
    Schutzgruppen pro Wiederherstellungsplan 150
    Datenspeichergruppen 150
    Gleichzeitige Wiederherstellungen 10

    Skalierbarkeitsgrenzwerte der vSphere Replication (VR)

    Geschützte VMs pro einzelner Schutzgruppe 500
    Geschützte VMs 500
    Schutzgruppen pro einzelnem Wiederherstellungsplan 250
    Datenspeichergruppen 250
    Gleichzeitige Wiederherstellungen 10

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.

  • Es treten bei SRM möglicherweise Fehler beim Mounten von Datenspeichern während Wiederherstellungen auf

    Während eines Test- oder eines tatsächlichen Failovers wartet SRM darauf, dass wiederhergestellte Datenspeicher verfügbar werden. Sobald die Datenspeicher verfügbar werden, versucht SRM, alle nicht gemounteten Datenspeicher zu mounten. In seltenen Fällen werden diese Datenspeicher automatisch gemountet, bevor SRM sie mounten kann. Falls dies während eines Test-Failovers erfolgt, wird das Failover nicht abgeschlossen. Tritt dies während eines tatsächlichen Failovers auf, wird das Failover mit einem Fehler abgeschlossen. Wiederholen Sie das Failover, um dieses Problem zu beheben.

  • Beim Replizieren von virtuellen Maschinen in Unterordner werden unerwartete Ordner erstellt

    Beim Konfigurieren von vSphere Replication (VR) für eine virtuelle Maschine ist es möglich, die virtuelle Maschine so zu konfigurieren, dass sie in ein beliebiges Verzeichnis auf einem Datenspeicher auf der Wiederherstellungs-Site repliziert werden kann. Falls es sich bei dem ausgewählten Verzeichnis um das Wurzelverzeichnis handelt, wird die Replizierung wie erwartet abgeschlossen. Falls es sich bei dem ausgewählten Verzeichnis um ein Verzeichnis unterhalb des Wurzelverzeichnisses handelt, wird die virtuelle Maschine nicht in das angegebene Verzeichnis repliziert. Stattdessen wird ein neues Verzeichnis erstellt, dessen Name sich aus den verschiedenen Ordner- und Unterordnernamen zusammensetzt. Beispielsweise wird /Pfad1/Pfad2/Pfad3zu /Pfad1Pfad2Pfad3. Die virtuelle Maschine wird repliziert, jedoch nicht in das beabsichtigte Verzeichnis. Um dieses Problem zu vermeiden, replizieren Sie virtuelle Maschinen in Ordner auf der obersten Verzeichnisebene.

  • Das Anhalten des SRM-Diensts während des Zuordnens von Ressourcen führt zu einem Ausfall des vSphere-Clients

    Wenn der SRM-Dienst angehalten wird, während ein Benutzer mithilfe des vSphere-Clients Ressourcenzuordnungen konfiguriert, sollte der Client eine Verbindungsfehlermeldung anzeigen. Stattdessen antwortet der Client nicht mehr. Um dieses Problem zu beheben, beenden Sie mithilfe des Windows Task-Managers den vSphere-Client-Prozess. Stellen Sie zum Vermeiden dieses Problems sicher, dass während des Zuordnens von Ressourcen der SRM-Dienst ausgeführt wird.

  • Benutzer mit nicht ausreichenden Berechtigungen können beim Replizieren irreführende Zustände herbeiführen

    Der vSphere Replication-Assistent kann zum Konfigurieren der Replizierung für virtuelle Maschinen verwendet werden. Nur Benutzer mit den entsprechenden Berechtigungen dürfen diesen Assistenten verwenden. Falls ein Benutzer ohne die entsprechenden Berechtigungen versucht, mithilfe des vSphere Replication-Assistenten die Replizierung neu zu konfigurieren, wird zum Abschluss des Assistenten eine Fehlermeldung angezeigt, die darauf hinweist, dass der Vorgang nicht zulässig ist. Die folgende Fehlermeldung erscheint:

    Der Kontrollertyp für die Festplatte '[Festplattenname] VMDK-Name' konnte nicht festgestellt werden. Die Berechtigung zur Durchführung dieses Vorgangs wurde verweigert.

    Die Replizierung dieser virtuellen Maschine wird wie erwartet durchgeführt, obwohl der vSphere-Client auf Probleme hinweist. Zum Beheben dieses Problems kann ein Benutzer mit ausreichenden Berechtigungen den Vorgang erneut durchführen, um die vom Client gemeldeten Fehler zu beheben.

  • Das Koppeln oder die Unterbrechung der Koppelung von vSphere Replication Management Server (VRMS) schlägt mit der Ausnahme "LockingFailedException" fehl

    Bei der Koppelung oder der Unterbrechung der Koppelung zwischen VRMS-Servern schlägt der Vorgang in seltenen Fällen mit der folgenden Ausnahme fehl, wenn der vSphere-Dienst zur selben Zeit angehalten wird:

    LockingFailedException: Fehlgeschlagenes Schreibschutzobjekt: com.vmware.hms.db.entities.HmsLocalServerEntity: VRM Server GUID

    Starten Sie VRMS neu, um dieses Problem zu beheben.

  • Der vorübergehende Verlust von vCenter Server-Verbindungen kann zu Wiederherstellungsproblemen bei virtuellen Maschinen mit Raw-Festplattenzuordnungen führen

    Falls die Verbindung mit vCenter Server während eines Failovers verloren geht, kann einer der folgenden Zustände eintreten:

    • vCenter Server bleibt weiterhin nicht verfügbar und das Failover schlägt fehl. Um dieses Problem zu beheben, stellen Sie die Verbindung mit vCenter Server wieder her und führen Sie die Wiederherstellung erneut durch.
    • In seltenen Fällen steht vCenter Server erneut zur Verfügung und die virtuelle Maschine wurde wiederhergestellt. Sofern die virtuelle Maschine über Raw-Festplattenzuordnungen verfügt, werden diese in einem solchen Fall möglicherweise nicht ordnungsgemäß zugeordnet. Da die Raw-Festplattenzuordnungen nicht ordnungsgemäß zugeordnet wurden, kann es vorkommen, dass die virtuelle Maschine nicht eingeschaltet werden kann oder Fehler im Zusammenhang mit dem Gastbetriebssystem oder Anwendungen auf dem Gastbetriebssystem auftreten können.
      • Falls es sich um ein Test-Failover handelt, führen Sie einen Bereinigungsvorgang durch und wiederholen Sie den Test.
      • Handelt es sich um ein tatsächliches Failover, müssen Sie die richtige Raw-Festplattenzuordnung manuell zur wiederhergestellten virtuellen Maschine hinzufügen.

    Weitere Informationen über das Hinzufügen von Raw-Festplattenzuordnungen finden Sie in der vSphere-Dokumentation über das Bearbeiten von VM-Einstellungen.

  • Abbrechen des Wiederherstellungsplans nicht abgeschlossen

    Beim Ausführen eines Wiederherstellungsplans wird versucht, virtuelle Maschinen zu synchronisieren. Es ist möglich, den Wiederherstellungsplan abzubrechen. Allerdings wird die Planausführung nur nach Abschluss bzw. Ablauf der Synchronisierung abgebrochen. Die Standardeinstellung für den Ablauf beträgt 60 Minuten. Die folgenden Optionen können zum Abbrechen des Wiederherstellungsplans verwendet werden:

    • Unterbrechen der vSphere Replication, was dazu führt, dass die Synchronisierung fehlschlägt. Verwenden Sie, sobald Failover einen Fehlerzustand aufweist, den vSphere-Client, um auf der gleichnamigen Registerkarte vSphere Replication neu zu starten. Nach dem Neustart der Replizierung kann bei Bedarf der Wiederherstellungsplan erneut ausgeführt werden.
    • Warten Sie, bis die Synchronisierung abgeschlossen ist oder eine Zeitüberschreitung eintritt. Dies kann einige Zeit dauern, wird jedoch irgendwann beendet. Nachdem die Synchronisierung beendet oder abgelaufen ist, wird der Abbruch des Wiederherstellungsplans fortgesetzt.

     

  • Gültige Zertifikate führen zu Warnungen

    Beim Hochladen und Installieren von Zertifikaten auf den vSphere Replication Management Server (VRMS) tritt der folgende Fehler auf:

    Das Zertifikat wurde mit Warnungen installiert. Remote-VRM-Systeme, bei denen die Option "Nur von einer vertrauenswürdigen Zertifizierungsstelle signiertes SSL-Zertifikat annehmen" aktiviert ist, können möglicherweise aus dem folgenden Grund keine Verbindung mit dieser Site herstellen: Das Zertifikat wurde nicht zur Verwendung mit dem angegebenen Hostnamen ausgegeben: VRM-Hostname

    Dieser Fehler kann ignoriert werden oder Sie können diesen Fehler vermeiden, indem Sie einen anderen unterstützten Browser als Internet Explorer verwenden.

  • Gültige Zertifikate führen zu Warnungen

    Bei vSphere Replication Management Server (VRMS) schlägt die Koppelung wegen Problemen mit Zertifikaten fehl, wenn die folgenden Voraussetzungen beide zutreffen:

     

    • Das Zertifikat des Servers enthält einen Wert für den Hostnamen, der nicht mit der VRMS-Adresse übereinstimmt.
      Der Wert für den Hostnamen enthält möglicherweise einen Objektnamen oder alternative Objektnamen. Die VRMS-Adresse wird bei der Anwendungskonfiguration in der Virtual Appliance Management Infrastructure (VAMI) angegeben.
    • Der Peer-VRMS-Server verfügt über eine gültige Vertrauenskette zu einer Zertifizierungsstelle (CA) für das Zertifikat.
      Dies geschieht, wenn das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle, wie z. B. Verisign oder Go Daddy, oder von einer unbekannten Zertifizierungsstelle ausgegeben wurde, deren Zertifikat zur Datei hms-truststore.jksdes Peer-VRMS-Servers hinzugefügt wurde, wodurch die Vertrauenswürdigkeit hergestellt wurde.

     

    Um dieses Problem zu beheben, verwenden Sie eine der folgenden Techniken:

     

    • Verwenden Sie die VAMI-Funktionalität Generieren und installieren, um ein neues Zertifikat zu erstellen und zu verwenden.
    • Verwenden Sie VAMI, um ein Zertifikat mit Werten für Hostnamen hochzuladen, die mit dem VRMS-Server übereinstimmen.
    • Entfernen Sie das Zertifikat der Zertifizierungsstelle für selbstsignierte Zertifikate aus der Datei hms-truststore.jksdes Peer-VRMS.

     

  • Die Option zum Ignorieren des VMware Tools-Taktsignals pro Wiederherstellungsplan steht nicht mehr zur Verfügung

    In der Regel warten Wiederherstellungspläne darauf, dass virtuelle Maschinen VMware Tools-Taktsignale senden. In früheren Versionen von SRM war es möglich, diese Prüfung pro Wiederherstellungsplan zu deaktivieren. Das Aktivieren bzw. Deaktivieren dieser Option auf Wiederherstellungsplanebene ist nicht mehr möglich. Das Warten auf VMware Tools-Taktsignale kann jetzt mithilfe von erweiterten Einstellungen für das gesamte System oder für einzelne virtuelle Maschinen deaktiviert werden.

  • Das Installieren mehrerer vSphere-Client-SRM-Plug-Ins schafft Probleme

    Nur eine Version des vSphere-Client-SRM-Plug-Ins sollte zu einem gegebenen Zeitpunkt installiert sein. Benutzer werden nicht daran gehindert, das Client-Plug-In für Version 4.0.x oder 4.1.0 über das Plug-In für SRM 5.0 zu installieren. Bevor Sie eine neue Version des Client-Plug-Ins installieren, deinstallieren Sie die bestehenden SRM-Plug-Ins. Falls mehrere vSphere-Client-Plug-Ins installiert wurden, deinstallieren Sie alle Client-Plug-Ins, laden Sie das Plug-In von dem zu verwalteten Server herunter und installieren Sie es neu.

  • Schutzgruppen melden Fehler, wenn virtuelle Maschinen nicht synchronisiert werden

    Wenn eine virtuelle Maschine von vSphere Replication geschützt wird, wird diese virtuelle Maschine auf die Wiederherstellungs-Site repliziert. Replizierungsvorgänge verfügen über Zeitüberschreitungswerte, die dafür sorgen, dass Vorgänge, die anscheinend keine Fortschritte machen, abgebrochen werden. Wenn eine virtuelle Maschine nicht repliziert wird, weist die Schutzgruppe, der sie angehört, einen Fehlerzustand auf. In einigen Fällen können virtuelle Maschinen nicht vor der Zeitüberschreitung repliziert werden, obwohl der Vorgang erwartungsgemäß verläuft. Wenn beispielsweise eine große virtuelle Maschine erstellt wird oder viele Änderungen an einer virtuellen Maschine vorgenommen wurden, kann der Replizierungsvorgang möglicherweise länger dauern als die dafür vorgesehene Zeit. So beheben Sie das Problem:

     

    • Erhöhen Sie das RPO (Recovery Point Objective), bis die Replizierung abgeschlossen wird.
    • Erhöhen Sie den Zeitüberschreitungswert in der SRM-Konfigurationsdatei.

     

    Um beispielsweise den Zeitüberschreitungswert für die Replizierung auf zwei Stunden (7200 Sekunden) zu ändern, wird die Konfigurationsdatei wie folgt geändert:

    <config>
    ...
    <hbrProvider>
    <synchronizationTimeout>7200</synchronizationTimeout>
    </hbrProvider>
    ...
    </config>

     

  • SRM-Dienst wird nach dem Warten auf die Datenbankantwort angehalten

    SRM wartet auf Antworten zu Datenbankabfragen. Wenn die Netzwerkbandbreite ungenügend oder die Datenbank überlastet ist, wird möglicherweise keine Antwort zurückgegeben, bevor eine Zeitüberschreitung auftritt. In solchen Fällen wird einer der folgenden Fehler in das SRM-Protokoll eingetragen:

    • Panic: Timed out while waiting for 'DrReplicationProviderInterface' (300 seconds)
    • Panic: Timed out while waiting for 'DrReplicationRecoveryInterface' (300 seconds)
    • Panic: Timed out while waiting for 'DrStorageManager' (300 seconds)

    Um dieses Problem zu vermeiden, können Sie die Zeit erhöhen, die SRM auf Antworten zu Abfragen wartet. Um beispielsweise den Zeitüberschreitungswert auf fünfzehn Minuten oder 900 Sekunden zu ändern, wird die Konfigurationsdatei vmware-dr.xml wie folgt geändert:

    <config>
    ...
    <waitForObjectTimeout>900</waitForObjectTimeout>
    ...
    </config>

     

  • Lizenzierung für den Testmodus - SRM zeigt falsche Informationen an

    Lizenzen können mithilfe des Assistenten zum Verwalten von vSphere-Lizenzen verwaltet werden. Wenn Sie diesen Assistenten in einer SRM-Installation verwenden, die im Testmodus ausgeführt wird, wird die Information über die Anzahl der Lizenzen möglicherweise falsch angezeigt. Im Testmodus meldet der vSphere-Client möglicherweise, dass unbegrenzt viele Lizenzen zur Verfügung stehen. vCenter Server zeichnet die Anzahl der verfügbaren und verwendeten Lizenzen auf und schränkt die Lizenzierung entsprechend ein.

  • Der vSphere-Client zeigt einen veralteten Wiederherstellungsstatus für virtuelle Maschinen an

    Beim Ausführen eines Wiederherstellungsplans werden die Wiederherstellungsstatuswerte einer virtuellen Maschine nicht automatisch im vSphere-Client widergespiegelt. Klicken Sie zum Beheben dieses Problems auf Aktualisieren.

  • Benutzer werden über abgelehnte Vorgänge nicht benachrichtigt

    Wenn ein Benutzer versucht, eine virtuelle Maschine aus einer Schutzgruppe zu entfernen, ohne über die ausreichenden Berechtigungen zu verfügen, schlägt der Vorgang fehl. Der Benutzer wird jedoch nicht über diesen Fehlschlag benachrichtigt. Das System funktioniert wie erwartet. Wenn jedoch keine Fehlermeldung erscheint, könnten einige Benutzer glauben, dass die Aufgabe fehlerfrei abgeschlossen wurde.

  • Beim erneuten Schützen können Benutzer möglicherweise unzulässige Aufgaben durchführen

    Wenn Benutzer einen Vorgang zum erneuten Schützen durchführen, können sie möglicherweise Aufgaben durchführen, für deren Durchführung sie nicht über die entsprechenden Rechte verfügen. Zu den Aufgaben, die Benutzer möglicherweise durchführen können, obwohl sie nicht über die entsprechenden Rechte verfügen, gehören das Erstellen von virtuellen Maschinen auf der Zielsite für das erneute Schützen oder das Schützen neuer Geräte auf der Quellsite für das erneute Schützen. Dies kann eintreten, wenn der Vorgang des erneuten Schützens initiiert wird, nachdem andere Benutzer virtuelle Maschinen auf dem alten Produktionsstandort gelöscht oder jene virtuellen Maschinen geändert haben, die beim Durchführen eines Failovers als Ziele für virtuelle Maschinen dienten.

  • Die Benutzerschnittstelle ändert sich unerwartet während einer geplanten Migration

    Während einer geplanten Migration werden virtuelle Maschinen deaktiviert und mit der Wiederherstellungs-Site synchronisiert. Während dieses Vorgangs werden Schutzgruppen und deren virtuellen Maschinen vorübergehend mit dem Status Teilweise wiederhergestellt angezeigt. Der vSphere-Client aktiviert die passenden Schaltflächen für diese Zustände, wie z. B. Schutzgruppe bearbeiten und Schutzgruppe entfernen, aber die von diesen Schaltflächen ausgelösten Vorgänge schlagen fehl. Diese unterschiedlichen Zustände und die Schaltflächenverfügbarkeit können für Benutzer verwirrend sein. Diese Änderungen sind normal und sollten während einer geplanten Migration erwartet werden. Sie können ignoriert werden.

  • Wiederherstellungsverläufe können nach einem Upgrade auf SRM 5.0 verloren gehen

    Während eines Server-Migrations-Upgrades schlägt das Installationsprogramm den Standard-Site-Namen anstelle des momentan verwendeten Site-Namens vor. Wenn Sie den Standard-Site-Namen nicht durch den aktuellen Site-Namen ersetzen, gehen die Wiederherstellungsverläufe möglicherweise verloren. Um dieses Problem zu umgehen, ändern Sie den Site-Namen in den Namen, der in Ihrer Bereitstellung verwendet wird. Wenn Sie ein Upgrade mit dem Standard-Site-Namen abschließen und der Wiederherstellungsverlauf verloren geht, können Sie die 4.1-Datenbank aus der Sicherung wiederherstellen und anschließend das Upgrade erneut durchführen, wobei Sie dann jedoch den richtigen Wert für den Site-Namen angeben müssen.

  • VRM-Server unterstützt keine PKCS#12-Dateien, die nicht kennwortgeschützt sind

    PKCS#12-Dateien sind in der Regel kennwortgeschützt. VRM-Server unterstützt keine Zertifikate, die nicht kennwortgeschützt sind. Es ist zwar möglich, eine nicht kennwortgeschützte Datei auszuwählen, die Zertifikate werden dennoch nicht installiert. Verwenden Sie kennwortgeschützte PKCS#12-Dateien, um dieses Problem zu vermeiden.

  • Lizenzhinweise ohne informativen Inhalt bei der Verwendung von Standard-Sitenamen

    SRM-Lizenzhinweise werden in vCenter anhand des SRM-Sitenamens bezeichnet. Wenn der Standard-Sitename verwendet wird und mehrere SRM-Server in derselben vCenter-Gruppe registriert sind, sorgt die Benennung der SRM-Server dafür, dass die Lizenzhinweise ununterscheidbar sind. Geben Sie während der Installation eindeutige Site-Namen an, um dieses Problem zu vermeiden.

  • Die "Erste Schritte"-Seiten sind nicht erkennbar

    Die "Erste Schritte"-Seiten enthalten Links und Informationen, die Ihnen beim Konfigurieren von SRM und VR behilflich sind. Falls Sie zuvor alle Registerkarten "Erste Schritte" geschlossen haben, können Sie diese durch Auswahl der Option im Dialogfeld "Clienteinstellungen" unter dem Menü "Bearbeiten" wiederherstellen.

  • Installation von SRM auf Maschinen mit Nicht-ASCII-Zeichen führt zu Zugriffsproblemen

    Wenn SRM auf einer Maschine installiert wird, deren Name Nicht-ASCII-Zeichen enthält, können Probleme beim Benutzerzugriff auftreten. Da der Maschinenname zur Generierung von URLs verwendet wird, sind die URLs, die Nicht-ASCII-Zeichen enthalten, möglicherweise nicht gültig. Um dieses Problem zu vermeiden, installieren Sie SRM auf Maschinen, deren Namen vollständig aus ASCII-Zeichen bestehen.

  • Nicht-ASCII-Kennwörter werden zum Anmelden bei VAMI (Virtual Appliance Management Infrastructure) nicht angenommen

    Benutzer können den vSphere Replication Management Server (VRMS) mithilfe von VAMI verwalten. Versuche, sich bei VAMI mittels eines Kontos mit einem Kennwort mit Nicht-ASCII-Zeichen anzumelden, schlagen fehl. Dies geschieht auch dann, wenn die richtigen Authentifizierungsinformationen angegeben werden. Dieses Problem tritt in allen Fällen auf, bei denen Nicht-ASCII-Kennwörter mit VAMI verwendet werden. Verwenden Sie ASCII-Kennwörter oder stellen Sie die Verbindung über SSH her, um dieses Problem zu vermeiden.

  • Nicht-ASCII-DNS-Suffixe werden nach dem Anpassen von Windows XP und Windows 2003 nicht ordnungsgemäß festgelegt

    Wenn Sie ein Nicht-ASCII-DNS-Suffix auf die Registerkarte "DNS" des Abschnitts "IP-Einstellungen" des Dialogfelds "Eigenschaften für die VM-Wiederherstellung" eingeben, um Windows XP oder Windows 2003 anzupassen, wird die Anpassung als erfolgreich gemeldet, aber das Nicht-ASCII-DNS-Suffix wird nicht ordnungsgemäß festgelegt. Um dieses Problem zu vermeiden, legen Sie unter Windows XP und Windows 2003 das DNS-Suffix manuell fest.

  • Benutzerdefinierte Wiederherstellungsschritte mit der Ausgabe von Nicht-ASCII-Zeichen führen zu einem Absturz des SRM-Servers

    Erstellen Sie keine benutzerdefinierten Wiederherstellungsschritte, die eine Nicht-ASCII-Ausgabe erzeugen. Wenn Sie solche Schritte zu einem Plan hinzufügen und anschließend einen Test oder eine Wiederherstellung ausführen, stürzt der SRM-Server ab. Wenn ein Plan verwendet wird, der einen Schritt enthält, der Nicht-ASCII-Ausgaben erzeugt, wechselt der Plan in einen Zustand, bei dem er nicht geändert oder gelöscht werden kann. Erstellen Sie einen neuen Plan, der keine Nicht-ASCII-Ausgabe erzeugt, verwenden Sie diesen Wiederherstellungsplan für Schutzgruppen und achten Sie darauf, den Nicht-ASCII-Plan künftig nicht für Tests oder Wiederherstellungen zu verwenden. Starten Sie alle Server neu, die wegen der Ausgabe von Nicht-ASCII-Zeichen abgestürzt waren.

  • Das Ausschalten virtueller Maschinen während einer Testbereinigung schlägt fehl

    Virtuelle Maschinen werden während einer Testbereinigung ausgeschaltet, was ein sehr speicherintensiver Vorgang sein kann. In seltenen Fällen kann der Ausschaltvorgang 30 Minuten oder mehr dauern. Dies ist mehr als die 15 Minuten, die SRM auf das Ausschalten von virtuellen Maschinen wartet. Wenn die Zeitüberschreitung von 15 Minuten eintritt, erscheint die Meldung Fehler - Zeitüberschreitung beim Vorgang: 900 Sekunden. Warten Sie zum Beheben dieses Problems, bis der Ausschaltvorgang abgeschlossen wurde, und führen Sie dann die Bereinigung erneut durch. Sie können die Test-VMs auch manuell ausschalten.

  • Ausgeführte vSphere-Clients sind nicht in der Lage, nach der Installation vSphere Replication-Server zu verwalten

    Der vSphere Replication-Server (VR-Server) wird zur Verwendung des vSphere-Clients verwaltet. vSphere-Clients aktivieren VR-Management für installierte VR-Server, wenn das SRM-Plug-In aktiviert wird. Wenn ein vSphere-Client mit dem SRM-Plug-In gestartet wird, findet er alle verfügbaren VR-Server und zeigt sie als mögliche zu verwaltende Auswahl an. Wenn VR-Server konfiguriert werden, nachdem ein vSphere-Client gestartet wurde, werden diese neu konfigurierten Server nicht automatisch erkannt. Um sicherzustellen, dass alle verfügbaren VR-Server als Auswahl zur Verwaltung von VR dargestellt werden, gehen Sie nach der Installation oder Konfiguration eines VR-Servers folgendermaßen vor:

     

    • Aktivieren Sie das SRM-Plug-In.
    • Starten Sie den Client neu.

     

    Jede dieser Möglichkeiten führt dazu, dass der Client die Liste der verfügbaren VR-Server aktualisiert.

  • Konfigurationsbenutzeroberfläche des Wiederherstellungsplans zeigt ungültige Netzwerkoptionen an

    Bei der Konfiguration eines Wiederherstellungsplans müssen Netzwerke für die Zuordnung mit virtuellen Maschinen ausgewählt sein. Die Benutzeroberfläche des Wiederherstellungsplans zeigt DVS-Uplink-Portgruppen als mögliche Auswahl an, auch wenn dies keine gültigen Optionen sind. Wählen Sie keine DVS-Uplink-Portgruppen aus.

  • Anzeige von veraltetem Replizierungsstatus, wenn Datenspeicher nicht mehr verfügbar ist

    Es ist möglich, dass der Zieldatenspeicher nach dem Start der Synchronisierung der virtuellen Maschine nicht mehr verfügbar ist. In einem solchen Fall sollte der Gruppenstatus Informationen über diesen Fehler anzeigen, der Status bleibt jedoch unverändert. Um Probleme in Verbindung mit nicht verfügbaren Datenspeichern zu erkennen, verwenden Sie die Ereignisse, die vom Zieldatenspeicher generiert werden. Die folgenden Ereignisse werden in einem solchen Fall generiert:

     

    • Der VR-Server kann nicht auf den Datenspeicher zugreifen...Wird sofort generiert, nachdem nicht mehr auf den Datenspeicher zugegriffen werden kann
    • Es wurde gegen das vSphere Replication-RPO der VM verstoßen...Replik kann nicht innerhalb des angegebenen Wiederherstellungspunkts (RPO) generiert werden

     

  • Status der virtuellen Maschine wird nach der Trennung der Verbindung zu vSphere Replication Management Server nicht aktualisiert

    vSphere Replication Management Server (VRMS) tauschen zwischen Sites Informationen über die Replizierung virtueller Maschinen aus. Wenn die VRMS-Verbindung durch die Option VRMS-Verbindung unterbrechen getrennt wird, wird der Informationsaustausch über replizierte virtuelle Maschinen nicht automatisch neu eingerichtet, wenn Sie die VRMS-Verbindung neu konfigurieren. Dies kann zu unvollständigen Informationen über die Replizierung virtueller Maschinen führen, einschließlich der Informationen, welche virtuelle Maschinen zum Hinzufügen zu Schutzgruppen verfügbar sind. Starten Sie zum Beheben dieses Problems den SRM-Dienst neu.

  • In vSphere-Client angezeigte Informationen sind möglicherweise veraltet

    Während des Änderns von SRM-Daten, z. B. von Inhalten von Wiederherstellungsplänen, werden die angezeigten Informationen möglicherweise nicht aktualisiert, sobald die SRM-Informationen geändert werden. So werden zum Beispiel nach dem Hinzufügen einer nicht kritischen virtuellen Maschine zum Anhalten eines Wiederherstellungsplans die Informationen über diese Änderung nicht automatisch angezeigt. Um solche Probleme zu beheben, klicken Sie auf Aktualisieren, falls verfügbar, oder verlassen Sie die Seite mit den veralteten Informationen und navigieren Sie anschließend wieder zurück. Dadurch wird der Inhalt des Bildschirms aktualisiert und es werden die neuesten Informationen angezeigt.

  • Beenden der Datenspeicherreplizierung für geschützte virtuelle Maschinen führt zu falschen Fehlermeldungen

    Es ist möglich, eine virtuelle Maschine zu schützen, die über Festplatten auf mehreren Datenspeichern verfügt, und anschließend die Replizierung für einen der Datenspeicher zu deaktivieren. In einem solchen Fall wechselt der Status der virtuellen Maschine in der Schutzgruppe zu Ungültig: Die virtuelle Maschine 'VM' wird nicht mehr geschützt. Interner Fehler: Es kann kein Locator für Festplatte'2001' erstellt werden...Diese Informationen sind falsch. Der Status sollte geändert werden zu Der Datenspeicher '[ Datenspeichername]' wird nicht mehr repliziert.

  • Ungültige Zertifikate werden während der Authentifizierung abgelehnt

    SRM unterstützt die zertifikatsbasierte Authentifizierung. Falls ein SRM-Server über ein ungültiges Zertifikat verfügt, wenn der vSphere-Client das SRM-Plug-In verwendet, um eine Verbindung zum SRM-Server herzustellen, treten Fehler auf. Ungültige Zertifikate können auftreten, wenn ein Zertifikat in der Zertifikatskette abgelaufen oder noch nicht gültig ist. In einem solchen Fall wird die folgende Meldung angezeigt: Die SSL-Verbindung zum Remotehost wurde beendet. Das Remotehostzertifikat weist folgende Probleme auf: Ein Zertifikat in der Hostzertifikatskette ist zeitlich nicht gültig.Installieren Sie zum Beheben dieses Problems ein gültiges Zertifikat auf dem SRM-Server.

  • Schnelles Löschen und Neuerstellen von Platzhaltern sorgt für Probleme

    Wenn Sie alle Platzhalter-VMs aus einem Datenspeicher löschen, den Datenspeicher unmounten und anschließend den Datenspeicher erneut mounten, müssen Sie möglicherweise 10 Minuten warten, bevor Sie die Platzhalter-VMs neu erstellen. Die Neuerstellung der Platzhalter innerhalb von 10 Minuten nach dem Unmounten des Datenspeichers kann dazu führen, dass der Vorgang fehlschlägt und der Fehler NoCompatibleHostFoundangezeigt wird. Um dieses Problem zu beheben oder zu vermeiden, warten Sie mehr als 10 Minuten, bevor Sie versuchen, die Platzhalter-VMs neu zu erstellen.

  • Installation schlägt wegen Richtlinieneinschränkungen fehl

    Die Installation von SRM kann mit dem Fehler Der Systemadministrator hat Richtlinien festgelegt, die diese Installation verhindernfehlschlagen. Dies hängt in der Regel damit zusammen, dass neue Einstellungen entweder während eines Betriebssystem-Upgrades oder während des Aufspielens von Patches angewendet wurden. Beheben Sie dieses Problem mithilfe der Lösung, die Ihrer Situation entspricht:

    • Wenn Windows-Updates zu erhöhten Einschränkungen geführt haben, die die Installation verhindern, führen Sie die Installation unter einem Konto mit ausreichend Berechtigungen durch. Sie können die erforderlichen Berechtigungen dadurch erhalten, dass Sie sich bei einem Konto mit ausreichend Berechtigungen anmelden und entweder die Installation mithilfe dieses Kontos abschließen oder indem Sie einem anderen Konto Berechtigungen erteilen, das dann zum Abschließen der Installation verwendet wird.
    • Wenn Fehler auftreten, weil die Datei aufgrund der Richtlinie für digitale Signaturen abgelehnt wird, installieren Sie den Hotfix 925336.

     

  • Versuche, benutzergenerierte Zertifikate während eines Änderungsvorgangs zu verwenden, schlagen fehl

    Versuche, einen Änderungsvorgang einer Installation durchzuführen, schlagen fehl, wenn ein Zertifikat mit einem alternativen Antragstellernamen (SAN) verwendet wird, der nicht der SRM-Maschinenadresse entspricht, die während der ursprünglichen Installation verwendet wurde. Die SRM-Maschinenadresse, die im SAN des Zertifikats verwendet wird, muss exakt dem Wert entsprechen, der bei der SRM-Installation eingegeben wurde. Der Wert kann der Maschinenname, ein FQDN oder eine IP-Adresse sein.

    Wenn dieses Problem auftritt, generieren Sie ein Zertifikat mit einem SAN, das dem Wert entspricht, der während der ursprünglichen Installation verwendet wurde, und verwenden Sie anschließend dieses Zertifikat während des Änderungsvorgangs der Installation. Wenn kein Zertifikat mit einem übereinstimmenden Wert generiert werden kann, müssen Sie den Server neu installieren und dabei den Datenbankinhalt beibehalten.

  • Das Wiederherstellen ausgeschalteter virtueller Maschinen schlägt möglicherweise fehl

    Bevor Sie eine virtuelle Maschine wiederherstellen können, muss SRM diese virtuelle Maschine von der Schutz-Site auf die Wiederherstellungs-Site replizieren. In bestimmten Fällen werden von vSphere Replication (VR) geschützte virtuelle Maschinen nicht repliziert. Als Folge dessen ist eine Testwiederherstellung nicht möglich. Dies sind die Fälle, in denen dies auftritt:

    • Wenn die Replizierung erstmalig eingerichtet wird, gibt es eine kurze Zeit, bevor die Replizierung abgeschlossen ist. Wenn vor dem Replizieren der virtuellen Maschine ein Notfall eintritt, ist es nicht möglich, die virtuelle Maschine wiederherzustellen. Es gibt keine Möglichkeit, dieses Problem zu verhindern.
    • Während einer Testwiederherstellung werden nur eingeschaltete virtuelle Maschinen synchronisiert, wenn die Option Neueste Änderungen an der Wiederherstellungs-Site replizieren aktiviert ist. Dies bedeutet, dass virtuelle Maschinen, die seit der Einrichtung des VR-Schutzes nicht eingeschaltet wurden oder deren erstmalige Synchronisierung nicht abgeschlossen wurde, mithilfe einer Testwiederherstellung nicht wiederhergestellt werden können. Um dieses Problem zu vermeiden, stellen Sie sicher, dass die erstmalige Synchronisierung abgeschlossen ist, bevor Sie eine Testwiederherstellung ausführen.
    • Wenn bei einer ausgeschalteten virtuellen Maschine, deren erstmalige Synchronisierung noch nicht abgeschlossen ist, geplante Migrationen ohne die aktivierte Option Neueste Änderungen an der Wiederherstellungs-Site replizieren ausgeführt werden, schlägt diese geplante Migration fehl, weil sich keine Daten virtueller Maschinen auf der Wiederherstellungs-Site befinden. Um dieses Problem zu verhindern, aktivieren Sie für diese virtuellen Maschinen während der geplanten Migration immer die Option Neueste Änderungen an der Wiederherstellungs-Site replizieren.

     

  • Die Wiederherstellung virtueller Maschinen schlägt aufgrund eines Fehlers bei der Festplattenkonfiguration fehl

    Es ist möglich, verschiedene Festplatten und Konfigurationsdateien für eine einzelne geschützte virtuelle Maschine auf mehreren Datenspeichern zu platzieren. Während der Wiederherstellung muss SRM Zugriff auf die Raw-Festplattenzuordnung und die übergeordneten Festplattendateien haben. Ohne diesen Zugriff kann SRM während der Wiederherstellung nicht die Festplattentypen ermitteln. In solch einem Fall erkennt SRM möglicherweise eine RDM-Festplatte nicht als solche, was dazu führt, dass die Neukonfiguration fehlschlägt. Um dieses Problem zu verhindern, stellen Sie sicher, dass alle Hosts, die auf die Konfigurationsdateien von wiederhergestellten virtuellen Maschinen zugreifen können, auch auf die RDM-Zuordnungsdateien und alle übergeordneten Festplatten zugreifen können, falls solche Festplatten vorhanden sind.

  • Von Benutzern bereitgestellte Zertifikate für VRMS müssen einen "Subject Alternative Name" enthalten, bei dem es sich um den FQDN des VRMS handelt

    Bei Verwendung eines von einem Benutzer bereitgestellten Zertifikats muss der "Subject Alternative Name" ein voll qualifizierter Domänenname (FQDN) des vSphere Replication Management Server (VRMS) sein. Wenn eine OpenSSL-Zertifizierungsstelle verwendet wird, fügen Sie der OpenSSL-Konfigurationsdatei diese Informationen bei. Hier ein Beispiel für diese erforderlichen Konfigurationsinformationen:

    subjectAltName = DNS:VRMS.example.com

  • SRM-Server kann nach einer Neukonfiguration des Netzwerks nicht gestartet werden

    Das Ändern des Namens des SRM-Servers oder der IP-Adresse wird nicht unterstützt. Der Maschinenname und die IP-Adresse des SRM-Servers wird bei der erstmaligen Installation gespeichert und dieser Wert kann innerhalb des SRM-Systems nicht geändert werden. Um dieses Problem zu beheben, deinstallieren Sie SRM, stellen Sie sicher, dass die SRM-Datenbankinhalte beibehalten werden, und installieren Sie dann SRM unter Verwendung des aktuellen Maschinennamens, der Adresse und der gespeicherten Datenbank neu.

  • Koppeln der Sites aufgrund unterschiedlicher Zertifikatsvertrauensmethoden fehlgeschlagen

    Beim Koppeln von SRM-Sites wird der Fehler Lokale und Remoteserver verwenden unterschiedliche Zertifikatvertrauensmethodenangezeigt. Dieses Problem tritt auf, wenn das Rootzertifikat für die Zertifizierungsstelle (CA), die das Zertifikat signiert, auf dem SRM-Server fehlt. Um dieses Problem zu beheben, installieren Sie das Rootzertifikat für die signierende Zertifizierungsstelle des SRM-Zertifikats mithilfe der Microsoft Management Console. Führen Sie nach der Installation des Zertifikats einen Änderungsvorgang für die SRM-Installation durch, um das benutzergenerierte Zertifikat erneut anzugeben.

  • Vorgänge schlagen möglicherweise fehl, wenn viele vSphere-Clients eine Verbindung zu SRM herstellen

    SRM verwendet einen großen Pool an Verbindungen mit fester Größe, um mit vCenter Server und dem SRM-Server am anderen Standort zu kommunizieren, um Aufgaben auszuführen. Die Anzahl an verfügbaren Verbindungen verringert sich, wenn sich die Anzahl an verbundenen vSphere-Clients erhöht. In vielen Fällen wirkt sich dies nicht negativ auf die Systemleistung aus, aber im Falle vieler gleichzeitiger Vorgänge, wie z. B. dem Schützen und Aufheben des Schutzes einer großen Anzahl an virtuellen Maschinen oder dem Ausführen und Testen vieler Wiederherstellungspläne, können Probleme auftreten. Bei Vorgängen kann es zu Zeitüberschreitungen kommen oder sie schlagen aus verschiedenen Gründen fehl. Dieses Problem kann behoben werden, indem überflüssige Clientverbindungen zum SRM-Server geschlossen werden. Beachten Sie, dass abgebrochene Verbindungen, die nicht sauber geschlossen wurden, zu bis zu 30 Minuten andauernden Zeitüberschreitungen führen können. Um abgebrochene Verbindungen schneller zu beenden, starten Sie den SRM-Server neu.

  • Für eine Platzhalter-VM wird möglicherweise ein falsches Symbol verwendet

    Unter einigen Bedingungen kann der vSphere-Client das Symbol für die Platzhalter-VM nicht herunterladen. Falls dies passiert, wird stattdessen ein generisches Symbol für eine virtuelle Maschine angezeigt. Ein Neustart des vSphere-Clients behebt möglicherweise das Problem.

  • Die Wiederherstellung wird nicht weiter ausgeführt, nachdem eine Verbindung zur Schutz-Site ausgefallen ist

    Falls die Schutz-Site während eines Deaktivierungsvorgangs oder während RemoteOnlineSync bzw. RemotePostReprotectCleanup nicht mehr erreichbar ist (und beide treten während des erneuten Schützens auf), wird der Wiederherstellungsplan möglicherweise nicht weiter ausgeführt. In solch einem Falle wartet das System darauf, dass die virtuellen Maschinen oder Gruppen, die Teil der Schutz-Site waren, diese unterbrochenen Aufgaben fortführen und beenden. Falls dieses Problem während des erneuten Schutzes auftritt, müssen Sie die Verbindung zur ursprünglichen Schutz-Site erneut herstellen und den Wiederherstellungsplan dann abbrechen und neu starten. Falls dieses Problem bei einem Failover auftritt, reicht es aus, den Wiederherstellungsplan abzubrechen und neu zu starten.

  • Versuche, Wiederherstellungspläne im gemischten Modus erneut zu schützen, führen zum Zustand "Erneuter Schutz unvollständig"

    Schutzgruppen können SAN- oder vSphere Replication-basiert sein und Wiederherstellungspläne können sich aus beiden Schutzgruppentypen zusammensetzen. Der erneute Schutz kann nicht auf einem Plan ausgeführt werden, der einen Mix aus SAN- und VR-basierten Schutzgruppen enthält. Der erneute Schutz stellt nicht sicher, dass die Schutzgruppen nicht nur SAN- oder nur VR-basiert sind. Wenn versucht wird, Schutzgruppen erneut zu schützen, die aus einem Mix aus Schutzgruppentypen zusammengesetzt sind, schlägt der Vorgang fehl und der Wiederherstellungsplan bleibt im Zustand "Erneuter Schutz unvollständig" zurück. Um dieses Problem zu vermeiden, erstellen Sie keine Wiederherstellungspläne, die verschiedene Schutztypen enthalten. Entfernen Sie zudem vor Anwendung des erneuten Schutzes die VR-basierte Schutzgruppe.

  • Generischer Fehler beim VRM-Server

    Die folgende Fehlermeldung wird möglicherweise angezeigt: VRM-Server - generischer Fehler. Suchen Sie in der Dokumentation nach Informationen zur Fehlerbehebung. Die detaillierte Ausnahme ist: Hostname. Dieser Fehler tritt auf, wenn der vSphere Replication Management Server die IP-Adresse des Hosts, der in der Fehlermeldung genannt wird, nicht auflösen kann. Um dieses Problem zu beheben, vergewissern Sie sich, ob es etwaige DNS-Konfigurationsprobleme gibt, die behoben werden können. Überprüfen Sie alternativ, ob FQDN-Namen erforderlich sind, jedoch keine voll qualifizierten Domänennamen (Nicht-FQDN) verwendet werden.

  • Vom Benutzer aktivierter Alarm wird niemals ausgelöst

    Benutzer können den Alarm Neu konfigurierte Schutzeinstellungen für VMaktivieren, aber dieser Alarm wird niemals ausgelöst. Das Problem liegt darin, dass Benutzer in dieser Version keine Schutzeinstellungen bearbeiten können. Um vom Benutzer initiierte Änderungen an Einstellungen virtueller Maschinen in SRM zu verfolgen, müssen Administratoren den Alarm Neu konfigurierte Einstellungen des Wiederherstellungsspeicherorts für VMaktivieren.

  • Versuche des Benutzers zum Konfigurieren von vSphere Replication schlagen fehl

    Benutzer mit Administratorrechten können vSphere Replication möglicherweise immer noch nicht konfigurieren. Die Ursache hierfür liegt oft darin, dass Benutzern nicht das Recht VRM-Datenspeicher-Mapper > Ansichterteilt wurde. Um dieses Problem zu beheben, gewähren Sie den entsprechenden Benutzerkonten auf der Schutz-Site dieses Recht.

  • Die Unterstützung von vSphere Replication Management Server (VRMS) für gültige ESX-Hosts schlägt fehl

    Wenn während der VR-Konfiguration für eine unterstützte ESX-Version ein Datenspeicher ausgewählt wird, wird die Meldung Der VR-Server Servername verfügt über keine Hosts, über die auf den Zieldatenspeicher ... in der Gruppe ... zugegriffen werden kannangezeigt. Dies tritt auf, wenn ein gültiger Host als UNSUPPORTED (nicht unterstützt) gekennzeichnet wird, obwohl es sich bei dem Host um eine gültige Auswahl handelt. Bei einer Registrierung des VR-Servers wird das Ereignis Der Host ist für vSphere Replication konfiguriertnicht auf dem Host ausgelöst. Das Kennzeichnen von Hosts als "Nicht unterstützt" tritt bei der Registrierung des VR-Servers aufgrund eines Fehlers bei oder einer Unterbrechung der Kommunikation zwischen VRM-Servern und VR-Servern auf oder wenn ein neuer Host mit der vCenter Server-Bestandsliste verbunden wird. Die Kommunikationsprobleme treten in der Regel auf, weil die Verbindung vorübergehend verloren geht oder die Serverdienste gestoppt werden.

    Um dieses Problem zu beheben und die Hosts zur Verwendung mit VR zu aktivieren, müssen Sie die folgenden Schritte ausführen:

     

    1. Suchen Sie die VRM-Datenbank an der Wiederherstellungs-Site.
    2. Entfernen Sie darin alle Datensätze aus der HostEntity-Tabelle mit Status 4 (UNSUPPORTED - Nicht unterstützt), die von der HbrHostEntity-Tabelle (vcMoId-Wert) nicht referenziert werden. Wenn es vorhandene Referenzen von der HbrHostEntity-Tabelle (den vcMoId-Wert) gibt, entfernen Sie den Datensatz nicht. Aktualisieren Sie stattdessen den Statuswert von 4 auf 1 (ACTIVE - Aktiv).
    3. Trennen Sie den Host von der vCenter-Bestandsliste und verbinden Sie ihn neu.
    4. Stellen Sie sicher, dass das Ereignis Der Host ist für vSphere Replication konfiguriertauf dem Host ausgelöst wird.

     

    Ein Beispiel für diese Art von Abfragen, die Sie möglicherweise zum Beheben dieses Problems in der Datenbank des VRM-Servers verwenden, lautet wie folgt:

     

    1. Abfragen
      • So fragen Sie alle Hosts ab, die mit UNSUPPORTED gekennzeichnet und keinem VR-Server zugewiesen sind:
        select * from HostEntity h where state=4 and not exists (select * from HbrHostEntity where h.vcMoId=HbrHostEntity.vcHost_vcMoId).
      • So fragen Sie alle Hosts ab, die mit UNSUPPORTED gekennzeichnet und einem VR-Server zugewiesen sind: select * from HostEntity h where state=4 and exists (select * from HbrHostEntity where h.vcMoId=HbrHostEntity.vcHost_vcMoId).
    2. Löschen und Ändern
      • So löschen Sie UNSUPPORTED-Datensätze für Hosts, die keinem VR-Server zugewiesen sind:
        delete from HostEntity where state=4 and not exists (select * from HbrHostEntity where vcMoId=HbrHostEntity.vcHost_vcMoId).
      • So ändern Sie den Status von mit UNSUPPORTED gekennzeichneten Hosts, die einem VR-Server zugewiesen sind, auf ACTIVE:
        update HostEntity set state=1 where state=4 and exists (select * from HbrHostEntity where vcMoId=HbrHostEntity.vcHost_vcMoId).

     

  • Beim Beenden und Neustarten der Replizierung für Festplatten virtueller Maschinen bleiben Festplatten unrepliziert

    Nach dem schnellen Deaktivieren und Aktivieren der Replizierung für durch vSphere Replication geschützte Festplatten auf einer virtuellen Maschine lautet deren Replizierungsstatus möglicherweise Nicht aktiv. Um dieses Problem zu beheben, heben Sie die Konfiguration der Replizierung für die virtuelle Maschine auf und konfigurieren Sie sie neu.

  • Vom Benutzer angepasste erweiterte Einstellung geht beim Upgrade verloren

    Beim Upgrade von SRM 4.1 auf SRM 5.0 werden alle vom Benutzer angepassten erweiterten Einstellungen durch die anfänglichen Standardwerte ersetzt. Wenden Sie zum Beheben dieses Problems die benutzerdefinierten Einstellungen nach dem Upgrade neu an. Für In-Place-Upgrades finden Sie Referenzinformationen zu benutzerdefinierten Vor-Upgrade-Einstellungen in C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\vmware-dr.xml.bak.

  • NFS-Volumes, die auf verschiedene Art und Weise identifiziert werden, bieten keinen dauerhaften Schutz

    NFS-Volumes werden als Datenspeicher mit einer IP-Adresse oder einem Hostnamen gemountet. vCenter verwendet die IP-Adresse oder den Hostnamen, um herauszufinden, welches NFS-Mount welchen Datenspeichern zugeordnet ist. Als Ergebnis kann dasselbe Volume von demselben NFS-Host als unterschiedlicher Datenspeicher registriert werden, wenn es mit einer anderen IP-Adresse oder einem anderen Hostnamen gemountet wird.

    Storage Replication Adapters (SRAs) geben während der Geräteerkennung eine Liste mit Adressen zurück. SRM versucht nach besten Kräften, die Adressen abzugleichen, die der SRA mit Mounts und Datenspeichern bereitstellt. SRAs geben dem SRM eine Gruppe mit Einstellungen zurück. SRM bietet diese Werte als Elemente der Array-Konfiguration an, überprüft diese Einstellungen jedoch nicht. Die Speicheradresse bzw. der Speicherport ist einer dieser Werte und dieser Wert wird beim Konfigurieren und Erkennen der Mount-Punkte verwendet. Wenn ein SRA nur einen Speicherportwert angibt, verwendet SRM nur diesen Portwert bei der Suche nach Übereinstimmungen, aber es gibt möglicherweise noch andere gültige Werte.

    Für den Fall, dass der von einem Array-Manager verwendete Bezeichner nicht mit dem von SRM verwendeten Bezeichner übereinstimmt, werden die Datenspeicher nicht wie erwartet geschützt. Virtuelle Maschinen auf solchen Freigaben werden nicht geschützt und beim Failover nicht heruntergefahren.

    Um dieses Problem zu vermeiden, verwenden Sie immer dieselbe IP-Adresse bzw. denselben Hostnamen zum Mounten der NFS-Datenspeicher und für das Filtern der Speicherports durch den Array-Manager.

  • Netzwerkinformationsfelder enthalten keine gültigen Informationen, wenn IPv6 erforderlich ist

    Wenn der vSphere Replication Management Server (VRMS) für die alleinige Verwendung von IPv6 konfiguriert ist, treten folgende Probleme auf:

     

    • Auf der Startseite der Virtual Appliance Management Infrastructure (VAMI) ist das vCenter Server-Adressfeld vorab mit einer literalen IPv4-Adresse gefüllt. Diese Adresse ist für reine IPv6-Appliances unbrauchbar. Um dieses Problem zu beheben, bearbeiten Sie das Feld und geben Sie einen gültigen DNS-Namen oder eine gültige literale IPv6-Adresse ein.
    • Das Feld "Site-Name" wird nicht vorab gefüllt. Dieses Feld ist in der Regel vorab gefüllt mit dem Namen der virtuellen Maschine der Appliance in der vCenter Server-Bestandsliste. Um dieses Problem zu beheben, geben Sie einen gültigen Site-Namen ein. Ein gültiger Site-Name unterscheidet sich von dem Site-Namen der Peer-Site.

     

  • Das Unmounten von Datenspeichern schlägt auf DPM-aktivierten Clustern fehl

    Geplante Migrationen und Notfallwiederherstellungen können keine Datenspeicher von an einen DPM-Cluster angehängten Hosts unmounten, wenn der Host in den Standby-Modus wechselt. Folgender Fehler wird möglicherweise angezeigt: Fehler: Es kann kein Unmounten des Datenspeichers Datenspeichername vom Host Hostname durchgeführt werden. Kommunikation mit dem Remotehost nicht möglich, da er getrennt ist. Um dieses Problem zu beheben, schalten Sie DPM an der Schutz-Site aus, bevor Sie die geplanten Migrationen bzw. die Notfallwiederherstellungen durchführen. Sie können DPM nach Abschluss der Wiederherstellungsaufgaben wieder einschalten.

  • Das Synchronisieren von Speicher während einer Wiederherstellung führt zu Fehlern

    In seltenen Fällen tritt bei aktivierter Synchronisierung während der Ausführung des Schritts Speicher synchronisieren möglicherweise der folgende Fehler auf: VR-Synchronisierung für die VRM-Gruppe Gruppenname fehlgeschlagen. VRM-Server - generischer Fehler. Suchen Sie in der Dokumentation nach Informationen zur Fehlerbehebung. Die detaillierte Ausnahme ist: 'Fehler bei optimistischen Sperren'. Dieses Problem tritt eher auf, wenn bei der Ausführung eines Wiederherstellungsplans eine große Datenmenge übertragen wird, z. B. wenn es eine größere Anzahl an virtuellen Maschinen und eine größere Menge an zu synchronisierenden Daten gibt. Trotz des Fehlers verläuft die Synchronisierung erfolgreich. Das erneute Ausführen des Wiederherstellungsplans sollte ohne Fehler abgeschlossen werden.

  • Das Herstellen einer Verbindung mit NFC schlägt fehl oder Kopierfehler bei der Wiederherstellung

    Bei einer Wiederherstellung können die folgenden Fehlermeldungen auftreten:

     

    • Es konnte keine Verbindung zum NFC-Dienst unter Hosthergestellt werden.
    • Kopieren der Datei Dateipfad nach Neuer_Dateipfad fehlgeschlagen: Fehlercode - Fehlermeldung.

     

    Dieses Problem tritt auf, wenn eine große Anzahl an gleichzeitigen Vorgängen durchgeführt wird. Das Problem tritt in der Regel unter folgenden Bedingungen auf:

     

    • Beim Wiederherstellen von 40 oder mehr virtuellen Maschinen, die mit vSphere Replication (VR) geschützt sind.
    • Beim Wiederherstellen von 10 oder mehr Datenspeichern auf einem ESX 3.5-Host.
    • Beim Ausführen einer großen Anzahl an Wiederherstellungsplänen, wenn die Wiederherstellungspläne virtuelle Maschinen beeinträchtigen, die über Festplatten mit Raw-Festplattenzuordnung (RDM) verfügen. Dieses Problem tritt in der Regel auf, wenn auf 4.x-Hosts mindestens 20 oder auf 5.0-Hosts mindestens 40 Wiederherstellungspläne ausgeführt werden.

     

    Um dieses Problem zu beheben, führen Sie die betroffenen Wiederherstellungspläne erneut aus.

  • Die Schaltfläche "Weiter" im Assistenten "Replizierung konfigurieren" funktioniert möglicherweise nicht

    Der Assistent "Replizierung konfigurieren" enthält eine Seite mit dem Titel "VR-Server". Diese Seite enthält eine Schaltfläche Weiter, die immer aktiviert ist, aber mit der man nicht zur nächsten Seite des Assistenten gelangen kann. Dies tritt auf, wenn SRM mit einem einzelnen VR-Server konfiguriert und dieser Server nicht verbunden ist. Um dieses Problem zu beheben, registrieren Sie einen anderen VR-Server oder ändern Sie den Status des aktuellen Servers in Verbunden.

  • vSphere Replication-Server verfügen nicht über angegebene IPv6-Adressen

    Bei der Bereitstellung des VR-Servers und des VRM-Servers können Benutzer IPv6-Adressen angeben, die von diesen Servern verwendet werden. Falls diese Adressen in Klammern eingeschlossen sind, werden sie nicht ordnungsgemäß angewendet. Um dieses Problem zu beheben, geben Sie die IPv6-Adressen ohne Klammern an.

  • Der vSphere Replication Management Server (VRM-Server) unterstützt nicht das Replizieren von Vorlagen virtueller Maschinen

    Der VRM-Server unterstützt nicht das Replizieren von Vorlagen virtueller Maschinen. Die Option zum Konfigurieren der Replizierung für Vorlagen ist nicht verfügbar. Virtuelle Maschinen, die von VR repliziert, aber anschließend in Vorlagen konvertiert werden, werden nicht weiter repliziert. Um fortlaufende Replizierungsprobleme für virtuelle Maschinen zu verhindern, die in Vorlagen konvertiert werden, führen Sie den folgenden Vorgang aus:

    1. Verbinden Sie den vSphere-Client mit vCenter Server und klicken Sie auf das Site Recovery Manager-Plug-In.
    2. Wählen Sie im linken Bereich vSphere Replication, wählen Sie den Remote-VRM-Server aus und klicken Sie auf die Registerkarte Virtuelle Maschinen.
    3. Wählen Sie die virtuelle Maschine aus, die in eine Vorlage konvertiert wurde, klicken Sie auf Replizierung entfernen und bestätigen Sie die Auswahl.

     

  • Nach der Replizierung auswählbare virtuelle Maschinen sind nicht konfiguriert

    Wenn der Assistent zum Konfigurieren der Replizierung für mehrere virtuellen Maschinen verwendet wird, werden einige virtuelle Maschinen möglicherweise nicht erfolgreich konfiguriert. Obwohl deren Konfiguration fehlgeschlagen ist, werden die virtuellen Maschinen im Assistenten Schutzgruppe erstellen als Auswahlmöglichkeiten aufgelistet. Dies liegt daran, dass das Fehlschlagen der Konfiguration nicht kommuniziert wurde. Um dieses Problem zu beheben, starten Sie den SRM-Server an der Schutz-Site neu.

  • Ausführung des Startbefehls bei einem benutzerdefinierten Wiederherstellungsschritt schlägt fehl

    Benutzerdefinierte Wiederherstellungsschritte können Befehle ausführen. Wenn ein benutzerdefinierter Wiederherstellungsschritt den Befehl Startohne Parameter ausführt, kann der Befehl nicht vollständig ausgeführt werden. Beispielsweise wird der Befehl c:\windows\system32\cmd.exe /C startnicht ausgeführt. Um dieses Problem zu beheben, schließen Sie das Befehlsfenster mit dem Befehl Startmanuell.

  • Fehlfunktion bei vSphere Replication-Servern (VR-Servern), die mit einer nicht spezifizierten Netzwerkkonfiguration bereitgestellt werden

    VR-Server werden mithilfe des OVF-Bereitstellungsassistenten von einer OVF-Datei bereitgestellt. Der Bereitstellungsassistent enthält eine Seite zum Angeben der Netzwerkkonfiguration des VR-Servers. Falls für die Netzwerkkonfiguration keine Netzwerkeinstellungen angegeben sind, wird die DHCP-Adressierung verwendet, die aber von VR-Servern nicht unterstützt wird. Um dieses Problem zu vermeiden, geben Sie bei der Bereitstellung gültige Netzwerkeinstellungen für den VR-Server an.

  • 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. Um dieses Problem zu vermeiden, verwenden Sie kleinere Festplatten.

  • Der Wiederherstellungsplan wird nicht abgeschlossen, wenn die Verbindung zum Speicher getrennt wurde

    Beim Testen bzw. Ausführen eines Wiederherstellungsplans wird dieser möglicherweise bei den Schritten, bei denen virtuelle Maschinen eingeschaltet werden, mit dem Fehler Fehler beim Erstellen des 'Test-Bubble'-Images aus der Gruppeninstanz...abgebrochen. Dieser Fehler tritt auf, nachdem die Verbindung einer LUN, auf der replizierte Daten gespeichert sind, zum ESX Server getrennt und dann neu hergestellt wird. Nach dem erneuten Herstellen der Verbindung wird die Replizierung wie zuvor fortgesetzt, aber der LUN wird ein neuer interner Bezeichner zugewiesen. Dieser neue Bezeichner ist keinen geschützten virtuellen Maschinen zugeordnet. Deshalb kann SRM weder den Speicher synchronisieren noch ein Image der replizierten virtuellen Maschine erstellen. Als Ergebnis schlägt der gesamte Einschaltschritt fehl. Um dieses Problem zu beheben, müssen Sie die Replizierung anhand des folgenden Verfahrens neu konfigurieren:

    1. Bereinigen Sie den Wiederherstellungsplan, der gerade fehlgeschlagen ist.
    2. Starten Sie den Neukonfigurations-Assistenten für die betroffene Schutzgruppe.
    3. Ändern Sie den Speicherort der Dateien, die sich auf dem Datenspeicher befinden, dessen Verbindung getrennt wurde. Wählen Sie dieselben Datenspeicher- und Ordnerspeicherorte aus.
    4. Stimmen Sie der Verwendung der vorhandenen Festplatten zu, wie vom Assistenten vorgeschlagen. Konfigurieren Sie die virtuelle Maschine neu.
    5. Die Schutzgruppe wechselt in den Zustand der vollständigen Synchronisierung, in dem die Datenkonsistenz überprüft wird. Warten Sie, bis der Vorgang abgeschlossen ist.

  • 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. Um diese Probleme zu beheben, starten Sie den ESX-Host neu.

  • Fehlgeschlagene Wiederherstellung sorgt für wiederholte Ausfälle des SRM-Servers

    Falls ein Wiederherstellungsplan keine Fortschritte erzielt, können Benutzer wählen, ob sie den Plan erneut ausführen möchten. In seltenen Fällen kann eine erneute Ausführung des Wiederherstellungsplans zu einem Ausfall des SRM-Servers führen. Nach dem Neustart des Servers sorgt der Wiederherstellungsplan weiterhin dafür, dass der Server ausfällt. Um dieses Problem zu beheben, überprüfen Sie die Inhalte der Protokolldateien, um die virtuelle Maschine ausfindig zu machen, die kurz vor dem Absturz angepasst wurde. Der Eintrag sieht in der Regel so aus: IP customization succeeded for VM Name der virtuellen Maschine. Nachdem Sie die virtuelle Maschine identifiziert haben, für die kurz vor dem Absturz die IP-Anpassung abgeschlossen wurde, führen Sie einen der folgenden Schritte aus:

    • Falls dieser Ausfall während eines Tests erfolgt ist, heben Sie die Registrierung der betroffenen Platzhalter-VM auf.
    • Falls dieser Ausfall während einer echten Wiederherstellung eingetreten ist, heben Sie die Registrierung der wiederhergestellten virtuellen Maschine auf und passen Sie anschließend die Netzwerkeinstellungen manuell an.

    Nachdem Sie das Problem der virtuellen Maschine behoben haben, starten Sie den SRM-Server neu und führen Sie den Wiederherstellungsplan erneut aus. In seltenen Fällen befinden sich auch andere virtuelle Maschinen in demselben Zustand, sodass, selbst nachdem eine virtuelle Maschine repariert wurde, weitere Ausfälle möglich und weitere Eingriffe erforderlich sind. Falls es weitere Ausfälle gibt, überprüfen Sie erneut die Protokolldateien, identifizieren Sie die jeweils betroffenen virtuellen Maschinen und beheben Sie die Probleme. Falls während des Bereinigungsvorgangs Fehler auftreten, aktivieren Sie das Kontrollkästchen Bereinigung erzwingen, um das System zurück in den Zustand "Bereit" zu versetzen.

  • 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äß des Gebietsschemas aus. Wenn der vSphere-Client auf einem koreanischen Betriebssystem installiert ist, fordert der Client Meldungen aus dem Ordner koder vCenter Server-Installation an, weil 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- statt SRM-Servermeldungen angezeigt. Um dieses Problem zu beheben, erstellen Sie eine Kopie des Ordners en, der sich im folgenden Verzeichnis befindet: C:\Programme\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.

  • Generische Fehlermeldung wird angezeigt, wenn aufgrund strenger Zertifikatsrichtlinien die Serverkoppelung fehlschlägt

    Versuche, Server zwischen Sites zu koppeln, schlagen möglicherweise fehl und die folgende Fehlermeldung wird angezeigt: Das Koppeln von Sites oder der Unterbrechungsvorgang ist fehlgeschlagen. Details: VRM-Server - generischer Fehler.Dieser Fehler tritt möglicherweise auf, wenn eine Site für die Verwendung einer strengen Zertifikatsrichtlinie und die andere Site für die Verwendung einer großzügigen Zertifikatsrichtlinie konfiguriert wird. In einem solchen Fall sollte die Koppelung fehlschlagen, wie dies tatsächlich der Fall ist. Ändern Sie nach einem solchen Fehler die großzügige in eine strenge Zertifikatsrichtlinie und stellen Sie ein gültiges Zertifikat bereit.

  • Die Verwendung von SRM 5.0 mit älteren Versionen von ESX kann zu dauerhaftem Geräteverlust führen

    Bei geplanten Migrationen und Failover-Tests kann es zu einem dauerhaften Verlust von Geräten kommen (Permanent Device Loss, PDL). Wenn SRM virtuelle Maschinen schützt, die auf ESX 5.0-Hosts ausgeführt werden, werden viele Fälle, bei denen es zu dauerhaftem Verlust von Geräten kommen kann, ordnungsgemäß gehandhabt, d. h., der Verlust wird verhindert.