HPE Matrix Operating Environment 7.5 Recovery Management

Transcrição

HPE Matrix Operating Environment
7.5 Recovery Management
Benutzerhandbuch
Zusammenfassung
Das HPE Matrix Operating Environment Recovery Management Benutzerhandbuch enthält Informationen zur Installation,
Konfiguration, Prüfung und Fehlerbehebung von HPE Matrix Operating Environment Recovery Management (Matrix Recovery
Management).
Teilenummer: 5900-4386R
Ausgabedatum: Februar 2016
Ausgabe: 2
© Copyright 2015, 2016 Hewlett Packard Enterprise Development LP
Inhaltliche Änderungen dieses Dokuments behalten wir uns ohne Ankündigung vor. Die Garantien für Hewlett Packard Enterprise Produkte und
Services werden ausschließlich in der entsprechenden, zum Produkt bzw. Service gehörigen Garantieerklärung beschrieben. Aus dem vorliegenden
Dokument sind keine weiter reichenden Garantieansprüche abzuleiten. Hewlett Packard Enterprise haftet nicht für technische oder redaktionelle
Fehler oder Auslassungen in diesem Dokument.
Vertrauliche Computersoftware. Für Besitz, Nutzung und Kopieren ist eine gültige Lizenz von Hewlett Packard Enterprise erforderlich. In
Übereinstimmung mit FAR 12.211 und 12.212 sind kommerzielle Computersoftware, Computersoftware-Dokumentation und technische Daten
für kommerzielle Komponenten für die US-Regierung mit der Standardlizenz des Herstellers lizenziert.
Über Links zu Drittanbieter-Websites verlassen Sie die Hewlett Packard Enterprise Website. Hewlett Packard Enterprise hat keine Kontrolle über
und ist nicht verantwortlich für Informationen außerhalb der Hewlett Packard Enterprise Website.
Marken
Microsoft® und Windows® sind in den USA und/oder anderen Ländern entweder eingetragene Marken oder Marken der Microsoft Corporation.
Java® und Oracle® sind eingetragene Marken von Oracle und/oder seiner Tochtergesellschaften.
VMware, VMware Server, GSX Server, ESX Server und VMotion sind Marken von VMware, Inc.
Adobe® und Acrobat® sind Marken von Adobe Systems Incorporated.
Bisherige Änderungen
Unterstützte Betriebssysteme finden Sie in der HPE Insight Management Support Matrix in der Hewlett Packard Enterprise
Enterprise-Informationsbibliothek.
Dokument-Teilenummer
Softwareversion
Dokumentationsausgabe
Veröffentlichungsdatum
5900–4386R
7.5
2
Februar 2016
5900–4386
7.5
1
August 2015
5900-4385
7.5
1
August 2015
5900-3777
7.3.0
1
Dezember 2013
5900-2606
7.2.0
1
März 2013
5900-2276
7.1.0
4
September 2012
5900-2276
7.1.0
3
August 2012
5900-2276
7.1.0
2
Juli 2012
5900-2276
7.1.0
1
Juni 2012
5900-2035
7.0.0
1
Februar 2012
Inhalt
1 Übersicht über Matrix Recovery Management....................................................6
2 Installieren und Konfigurieren von Matrix Recovery Management......................9
Installations- und Konfigurationsübersicht............................................................................................9
Installations- und Konfigurationsvoraussetzungen...............................................................................9
Installieren und Lizenzieren von Matrix Recovery Management........................................................10
Deinstallieren von Matrix Recovery Management.........................................................................10
Einrichten eines Netzwerks................................................................................................................10
Einrichten des Speichers....................................................................................................................12
Allgemeine Hinweise zur Speichereinrichtung..............................................................................13
Hinweise zur HPE P6000 Speichereinrichtung.............................................................................13
Hinweise zur HPE P9000 Speichereinrichtung.............................................................................14
Hinweise zur Einrichtung von HPE 3PAR StoreServ-Speicher.....................................................15
Erstellen und Installieren eines benutzerdefinierten Speicheradapters........................................16
Einrichten logischer Server am lokalen Standort................................................................................18
Einrichten logischer Server am Remote-Standort..............................................................................19
Konfigurieren von Matrix Recovery Management..............................................................................20
Übersicht über die Matrix Recovery Management-GUI.................................................................20
Matrix Recovery Management-Konfigurationsschritte...................................................................21
Export- und-Importvorgänge von Matrix Recovery Management..................................................22
Importieren von Wiederherstellungsgruppen mit physischen IO-Diensten, physischen logischen
Servern und virtuellen logischen Servern mit RAW-Datenträgern................................................26
Importauftragsstatus................................................................................................................27
Importieren von Wiederherstellungsgruppen mit virtuellen IO-Diensten..................................29
DR-Schutz für IO-Dienste...................................................................................................................30
Überblick über die Konfiguration von DR-geschützten IO-Diensten.............................................30
Konfigurieren von IO-Eigenschaften.............................................................................................31
DR-Schutz der den IO-Diensten zugrunde liegenden logischen Server.......................................33
Konfigurieren des OO-Arbeitsablaufs für optionale E-Mail-Benachrichtigungen..........................34
Netzwerkkonfiguration...................................................................................................................35
3 Testen und Failover-Vorgänge..........................................................................36
Testen von Wiederherstellungsgruppen.............................................................................................36
Aktivieren und Deaktivieren des Wartungsmodus..............................................................................38
Failover-Vorgänge..............................................................................................................................38
Geplantes Failover........................................................................................................................39
Nicht geplantes Failover................................................................................................................40
Zielauswahl und Parallelismus während eines Aktivierungsvorgangs...............................................42
4 Befehlszeilentools..............................................................................................44
Tool drsync..........................................................................................................................................44
CMS-Konfigurationsanforderungen zur Verwendung mit drsync........................................................44
Konfigurieren der Datei dr.properties für drsync.................................................................................45
Globbing-Ausdrücke...........................................................................................................................47
Verwenden des Befehlszeilentools drsync.........................................................................................47
5 Dynamische Arbeitsauslastungs-Verschiebung mit CloudSystem Matrix.........49
Fähigkeiten und Einschränkungen.....................................................................................................50
Unterstützte Plattformen................................................................................................................53
Übersicht über die physisch-virtuelle technologieübergreifende Konfiguration..................................53
Konfigurieren logischer Server für die Verschiebung zwischen physischen und virtuellen
Zielen.............................................................................................................................................53
Konfigurieren logischer Server für die Verschiebung zwischen unterschiedlichen physischen
Servern..........................................................................................................................................56
Inhalt
3
Konfigurieren und Verwalten von portierbaren Betriebssystemabbildern...........................................56
Portable Images Storage Assistant (PISA)...................................................................................57
Portable Images Network Tool (PINT)...........................................................................................58
Konfigurieren und Verwalten von technologieübergreifenden logischen Servern..............................58
Portabilitätsgruppen.......................................................................................................................58
Definieren von technologieübergreifenden logischen Servern......................................................60
Platzieren eines logischen Servers in einer Portabilitätsgruppe..............................................60
Speicherdefinition.....................................................................................................................62
Verschieben zwischen Technologien.............................................................................................63
Zielattribute....................................................................................................................................64
Verschieben zwischen Blade-Typen..............................................................................................65
Verwalten von DR-geschützten technologieübergreifenden logischen Servern in einer Matrix
Recovery Management-Konfiguration................................................................................................65
Festlegen des bevorzugten Failover-Zieltyps................................................................................66
6 Probleme, Einschränkungen und vorgeschlagene Maßnahmen.......................68
Einschränkungen................................................................................................................................68
Eingeschränkter Hyper-V-Support für bidirektionale Konfiguration...............................................68
Keine automatische Synchronisation der Konfiguration zwischen Standorten.............................68
Matrix Recovery Management-Auftragsinformationen werden unter bestimmten Umständen
nicht beibehalten...........................................................................................................................69
Kleinere Probleme..............................................................................................................................69
Firefox-Browser kann nicht für Standort-Exportvorgänge verwendet werden...............................69
Erforderliche ESX-Konfigurationseinstellung, damit VMFS-Datenspeicher von durch Matrix
Recovery Management verwalteten logischen Servern am Remote-Standort sichtbar sind........69
Aktivierungs- oder Deaktivierungsauftrag bleibt hängen...............................................................69
Identische Konfiguration von logischen Servern zwischen Standorten.........................................70
Eine RAID Manager-Instanz pro HPE P9000 Storage Management Server und eine RAID
Manager-Instanz pro HPE P9000 Gerätegruppe..........................................................................70
Die CLX/HPE P9000 Software muss auf einem separaten Windows-System installiert werden...71
Nur jeweils ein aktiver Matrix Recovery Management-Konfigurationsvorgang.............................71
Der Vorgang zum Löschen von Standorten in Matrix Recovery Management entfernt keine HPE
SIM-Tools.......................................................................................................................................71
Verwenden von SPM mit Remotekopie-Gruppenanforderung......................................................71
7 Fehlerbehebung................................................................................................72
Fehlerbehebung der Konfiguration.....................................................................................................72
Konfigurationsfehlermeldungen..........................................................................................................75
Warnmeldungen..................................................................................................................................79
Fehlerbehebung bei Matrix Recovery Management-Aufträgen..........................................................79
Failover-Fehlermeldungen..................................................................................................................83
Matrix Recovery Management-Protokolldateien.................................................................................84
Fehlerbehebung bei DR-geschützten IO-Diensten.............................................................................85
Fehlerbehebung bei der Konfiguration von DR-geschützten IO-Diensten....................................85
Fehlerbehebung beim Failover DR-geschützter IO-Dienste.........................................................87
Hyper-V-basierte IO-Dienste oder logische Server konnten nicht aktiviert werden............................88
8 Support und weitere Ressourcen......................................................................89
Anfordern von Hewlett Packard Enterprise Support...........................................................................89
Zugreifen auf Aktualisierungen...........................................................................................................89
Sicherheitsbulletin und Richtlinie für Warnhinweise zu Softwarekomponenten nicht im
Besitz von Hewlett Packard Enterprise...............................................................................................90
Registrieren für Technischen Support für die Software und für den Aktualisierungsservice..............90
Wie Technischer Support und Aktualisierungsservice für Ihre Software in Anspruch genommen
werden...........................................................................................................................................90
Hewlett Packard Enterprise Partner...................................................................................................91
4
Inhalt
Matrix Recovery Management-Dokumentation..................................................................................91
Websites.............................................................................................................................................92
Customer Self Repair (Reparatur durch den Kunden).......................................................................92
Remote-Support.................................................................................................................................92
Rückmeldungen zur Dokumentation...................................................................................................92
A Wiederherstellen eines CSV aus dem Zustand online pending........................93
Glossar.................................................................................................................94
Stichwortverzeichnis.............................................................................................98
Inhalt
5
1 Übersicht über Matrix Recovery Management
Matrix Recovery Management ist eine Komponente der HPE Matrix Operating Environment, die
Wiederherstellungsschutz für logische Server und für Matrix Infrastructure Orchestration-Dienste
bereitstellt. Logische Server und Matrix Infrastructure Orchestration-Dienste (IO-Dienste), die in
einer Matrix Recovery Management-Konfiguration enthalten sind, werden als DR-geschützte
logische Server und IO-Dienste bezeichnet. Ein DR-geschützter logischer Server kann auf einem
physischen Gerät (C-Class-Blade) oder auf einer durch einen Hypervisor gehosteten Virtual
Machine ausgeführt werden. Wird ein DR-geschützter logischer Server auf einem C-Class-Blade
ausgeführt, der mit HPE Virtual Connect ausgestattet ist, wird er als VC-gehosteter logischer
Server bezeichnet. Ein DR-geschützter logischer Server, der auf einer Virtual Machine unter
Steuerung eines Hypervisors ausgeführt wird, wird als VM-gehosteter logischer Server bezeichnet.
Eine Matrix Recovery Management-Konfiguration besteht aus zwei Standorten. Jede davon wird
von Matrix Operating Environment verwaltet. Der Standort, an dem sich der Central Management
Server (CMS) befindet, bei dem Sie angemeldet sind, wird als lokaler Standort bezeichnet, und
der andere Standort in der Matrix Recovery Management-Konfiguration wird als Remote-Standort
bezeichnet. Matrix Recovery Management verwendet über zwei Standorte hinweg paarweise
symmetrisch konfigurierte logische Server oder IO-Dienste. Ein logischer Server oder IO-Dienst
des Paars wird an einem Standort aktiviert, der andere (der logische Peer-Server oder
Peer-IO-Dienst) wird am anderen Standort deaktiviert. Die Startabbilder bzw. -Images der
DR-geschützten logischen Server und IO-Dienste, einschließlich Anwendungscode und -daten,
befinden sich auf Laufwerksarray-Volumes. Die Quell-Volumes an dem Standort, an dem einer
der logischen Server oder IO-Dienste des Paars aktiviert ist, werden an dem anderen Standort
repliziert, an dem der logische Peer-Server oder Peer-IO-Dienst deaktiviert ist. Diese Volumes
sind Teil einer Speicher-Replizierungsgruppe, die eine Speicherarray-unterstützte Replizierung
nutzt. Ein oder mehrere logische Server oder IO-Dienste können mit einer einzelnen
Speicher-Replikationsgruppe verknüpft sein. Dies wird als eine Wiederherstellungsgruppe
bezeichnet.
In einer Matrix Recovery Management-Konfiguration hat jede Wiederherstellungsgruppe einen
bevorzugten Standort, an dem sie vorrangig aktiviert wird, sowie einen sekundären Standort, an
dem sie vorrangig deaktiviert wird. Eine Wiederherstellungsgruppe kann jeweils nur an einem
Standort aktiviert werden. Ein Satz von Wiederherstellungsgruppen, die alle die gleichen
bevorzugten und sekundären Standorte gemeinsam nutzen, wird als
Wiederherstellungsgruppensatz bezeichnet (siehe
Abbildung 1, „Wiederherstellungsgruppensätze“). Wiederherstellungsgruppensätze können zur
Aktivierung oder Deaktivierung am lokalen Standort ausgewählt werden.
Für Wiederherstellungsgruppensätze kann in einer Matrix Recovery Management-Konfiguration
ein Failover von einem Standort zum anderen Standort durchgeführt werden. Tritt z. B. am lokalen
Standort ein Notfall ein, dann kann der Administrator am Remote-Standort ein Failover für alle
Wiederherstellungsgruppen auslösen, die am lokalen Standort aktiviert waren, indem er sie am
Remote-Standort aktiviert. Dadurch wird der Speicher, der den deaktivierten, DR-geschützten
logischen Servern und IO-Diensten zugeordnet ist, auf Lese-/Schreibzugriff am Remote-Standort
vorbereitet, und diese logischen Server und IO-Dienste werden aktiviert.
6
Übersicht über Matrix Recovery Management
Abbildung 1 Wiederherstellungsgruppensätze
Funktionen und Vorteile von Matrix Recovery Management
•
Bietet einen automatisierten Failover-Mechanismus für DR-geschützte logische Server,
DR-geschützte IO-Dienste und den zugehörigen Speicher.
•
Unterstützt Standalone-Hyper-V.
•
Unterstützt Microsoft Hyper-V-VMs in einer Clusterkonfiguration mit freigegebenen
Clustervolumes (Cluster Shared Volumes, CSV).
•
Unterstützt eine Online-Konfiguration mittels des Matrix Recovery
Management-Importvorgangs.
•
Unterstützt ESXi-VMs.
•
Unterstützt flexible technologieübergreifende logische Server. VC-gehostete logische Server
können durch ein Failover zu VM-gehosteten logischen Servern werden, und VM-gehostete
logische Server können durch ein Failover zu VC-Hosts werden.
HINWEIS: Technologieübergreifende Servern sind auf logische Server eingeschränkt,
die mit Matrix OE Visualization Manager erstellt wurden. Unterstützt keine Matrix Infrastructure
Orchestration-Dienste.
•
Unterstützt mehrere logische Server und IO-Dienste in getrennten
Wiederherstellungsgruppen. In einer einzelnen Wiederherstellungsgruppe können sich
jedoch nicht sowohl logische Server als auch IO-Dienste befinden.
•
Unterstützt ein bidirektionales Failover der Wiederherstellungsgruppensätze zwischen zwei
Standorten, sodass sowohl aktivierte als auch deaktivierte Wiederherstellungsgruppen
gleichzeitig vorhanden sein können.
•
Unterstützt die Speicherreplikation der HPE P6000 Continuous Access Software im
synchronen und im asynchronen Modus.
•
Unterstützt die Speicherreplikation der HPE P9000 Continuous Access Software im
synchronen und asynchronen Modus sowie im asynchronen Journal-Modus.
•
Unterstützt die synchrone und asynchrone Datenreplikation für HPE 3PAR StoreServ.
•
Unterstützt bei anderen installierten Speicherreplikationsprodukten als HPE P6000, HPE
P9000 oder 3PAR StoreServ, die von Matrix OE unterstützt werden, eine Integration in die
7
Remote-Failover-Funktionen. Eine Integration dieser Speicherreplikationsprodukte wird über
die benutzerdefinierte Speicheradapter-Schnittstelle unterstützt.
•
Beinhaltet Einstellungen für die Wiederherstellungsgruppen-Startreihenfolge, mit denen Sie
bestimmen können, welche Wiederherstellungsgruppen während eines Standort-Failovers
zuerst wiederhergestellt werden.
•
Umfasst eine Kopierfunktion, womit sich leicht mehrere Speicher-Replikationsgruppen mit
den gleichen Konfigurationsparametern erstellen lassen.
•
Enthält drsync, ein Befehlszeilentool, das logische Server zwischen lokalen und
Remote-Standorten synchronisiert. Weitere Informationen zu diesem Tool finden Sie unter
„Befehlszeilentools“ (Seite 44).
•
Wird in die (durch HPE Storage Provisioning Manager gebotene)
Speicherreplikationsunterstützung und in die Matrix OE-Konfiguration der
Speicherpooleinträge integriert (umfasst bestimmte Flags, mit denen kennzeichnet wird,
dass der Speicherpooleintrag Disaster Recovery-fähig ist und einzelne Volumes für die
Notfallwiederherstellung konfiguriert sind).
•
Unterstützt die automatische Konfiguration des Speichers während der Erstellung und/oder
Synchronisierung logischer Server bei Verwendung von SPM und der 3PAR
StoreServ-Speicherreplikationsfunktion.
•
Unterstützt bis zu 3500 DR-geschützte logische Server, aus denen eine Kombination aus
möglicherweise 500 (physischen) logischen Virtual Connect-Servern, 1500 logischen
Hyper-V-VM-Servern oder bis zu 3500 logischen ESXi-VM-Servern konfiguriert werden
kann. Die Gesamtzahl von 3500 logischen Servern darf jedoch nicht überschritten werden.
Beispiele:
1. 3000 ESX VM-gehostete logische Server und 500 VC-gehostete logische Server
2. 3200 ESX VM-gehostete logische Server und 300 VC-gehostete logische Server
3. 3500 ESX VM-gehostete logische Server
4. 1500 Hyper-V VM-gehostete logische Server
5. 750 Hyper-V-IO-Dienste mit je 2 logischen Servern, 750 VMware IO-Dienste mit je
2 logischen Servern und 500 VC-gehostete logische Server.
•
Unterstützt mehrere Datenspeicher innerhalb derselben Replikationsgruppe.
Dieses HPE Matrix Operating Environment Recovery Management Benutzerhandbuch macht
Sie besser mit den Konzepten und der Konfigurationsprüfung von Matrix Recovery Management
vertraut. Die grafische Benutzeroberfläche (GUI), Onlinehilfe und QuickInfos von Matrix Recovery
Management bieten eine aufgabenorientierte Anleitung.
8
Übersicht über Matrix Recovery Management
2 Installieren und Konfigurieren von Matrix Recovery
Management
Dieses Kapitel beinhaltet Abschnitte zu den Matrix Recovery
Management-Installationsvoraussetzungen, zur Netzwerkeinrichtung, zur Speichereinrichtung,
zur Einrichtung logischer Server, zur Konfiguration von Matrix Recovery Management, zu Exportund Import-Vorgängen sowie zum DR-Schutz für IO-Dienste.
WICHTIG: Wenn Sie DR-geschützte IO-Dienste erstellen möchten, lesen Sie unter „DR-Schutz
für IO-Dienste“ nach, bevor Sie den Installations- und Konfigurationsvorgang in Matrix Recovery
Management starten.
Installations- und Konfigurationsübersicht
Die folgende Installations- und Konfigurationsübersicht für Matrix Recovery Management enthält
Links zu Informationen in jedem Schritt des Verfahrens.
1. Bestätigen Sie, dass alle Installations- und Konfigurationsvoraussetzungen für Matrix
Recovery Management erfüllt wurden. Siehe „Installations- und
Konfigurationsvoraussetzungen“ (Seite 9).
2. Installieren und lizenzieren Sie Matrix Recovery Management. Siehe „Installieren und
Lizenzieren von Matrix Recovery Management“ (Seite 10).
3. Bestätigen Sie, dass Ihre Netzwerkkonfiguration unterstützt wird. Siehe „Einrichten eines
Netzwerks“ (Seite 10).
4. Konfigurieren Sie den Speicher. Siehe „Einrichten des Speichers“ (Seite 12).
5. Konfigurieren Sie den DR-Schutz. Siehe „Einrichten logischer Server am lokalen Standort“
(Seite 18).
6. Konfigurieren Sie logische Server am Remote-Standort. Siehe „Einrichten logischer Server
am Remote-Standort“ (Seite 19).
7. Konfigurieren Sie Matrix Recovery Management. Siehe „Konfigurieren von Matrix Recovery
Management“ (Seite 20).
8. Konfigurieren Sie den DR-Schutz für IO-Dienste. Siehe „DR-Schutz für IO-Dienste“ (Seite 30)
Installations- und Konfigurationsvoraussetzungen
Matrix Recovery Management ist die Matrix Operating Environment-Komponente, die die
Wiederherstellungsverwaltung ermöglicht. Matrix Operating Environment und die abhängige
Software müssen zuerst auf dem Central Management Server am lokalen Standort und am
Remote-Standort installiert werden, bevor Matrix Recovery Management installiert werden kann.
Weitere Informationen finden Sie imHPE Insight Management Installations- und
Konfigurationshandbuch in der Hewlett Packard Enterprise Enterprise-Informationsbibliothek.
Bestätigen Sie, dass der lokale Standort und der Remote-Standort die für Matrix Recovery
Management in der HPE Insight Management Support Matrix angegebenen
Unterstützungsanforderungen erfüllen, einschließlich unterstützter Server, Speicher, Browser,
Betriebssysteme, Datenbanken und Hypervisoren. DieInsight Management Support Matrix ist in
der Hewlett Packard Enterprise Enterprise Management-Informationsbibliothek verfügbar:
Installations- und Konfigurationsübersicht
9
HINWEIS:
Es gelten die folgenden Annahmen:
•
Zwischen dem lokalen Standort und dem Remote-Standort sind Netzwerk- und
Speicherreplikations-Links vorhanden.
•
Bei der Planung einer Lösung für die Notfallwiederherstellung unter Verwendung von Matrix
Recovery Management mit VMware Hypervisor-basierten IO-Diensten müssen Sie
sicherstellen, dass die Hosts im primären Datenzentrum und im DR-Datenzentrum
übereinstimmen. Die Hosts, die vom replizierten Volume, von dem der IO-Dienst Gebrauch
macht, erkannt werden, können zum Aktivieren der Dienstreplikate im DR-Datenzentrum
ausgewählt werden. Die auf den Hosts ausgeführte Version muss gleich oder höher als die
Version des primären Hosts sein, auf dem der ursprüngliche IO-Dienst erstellt wurde. Wenn
der IO-Dienst des primären Datenzentrums auf einem ESX 5.5-Host erstellt wurde, müssen
die ESX-Hosts am DR-Standort, denen der replizierte Datenspeicher zugeordnet ist, ESX
5.5 oder höher ausführen.
Installieren und Lizenzieren von Matrix Recovery Management
1.
Installieren Sie Matrix Operating Environment und abhängige Software auf dem Central
Management Server (CMS) am lokalen und Remote-Standort.
2. Ermitteln Sie die verwaltete Infrastruktur an jedem Standort über HPE Systems Insight
Manager.
3. Wenden Sie die Lizenz für Matrix Recovery Management mithilfe des Insight Managed
System Setup Wizard an.
Weitere Informationen finden Sie in derMatrix Operating Environment Einstiegshilfe und in
derInsight Managed System Setup Wizard Einstiegshilfe in der Hewlett Packard Enterprise
Deinstallieren von Matrix Recovery Management
Verwenden Sie die Windows-Funktion Software folgendermaßen:
1. Wählen Sie recovery management, und klicken Sie dann auf Remove (Entfernen).
2. Warten Sie, bis das Matrix Recovery Management-Produkt nicht mehr in der Liste
angezeigt wird.
Einrichten eines Netzwerks
Es wird angenommen, dass zwischen dem lokalen Standort und dem Remote-Standort
Netzwerklinks vorhanden sind. Sie können Matrix Recovery Management in einer Vielzahl von
Netzwerkkonfigurationen verwenden. Es ist jedoch wichtig, die folgenden
Netzwerkkonfigurationsparameter von Matrix Recovery Management zu beachten:
•
10
In einer Matrix Recovery Management-Konfiguration können auf DR-geschützten logischen
Servern an beiden Standorten Arbeitsauslastungen ausgeführt werden. Eine
Wiederherstellungsgruppe kann nur an jeweils einem Standort aktiviert werden
(Arbeitsauslastungen ausführen), die Aktivierung kann jedoch auf beiden Seiten
vorgenommen werden, sodass Arbeitsauslastungen, die mit verschiedenen
Wiederherstellungsgruppen verknüpft sind, an beiden Standorten gleichzeitig ausgeführt
werden können. Aus diesem Grund müssen Netzwerkdienste wie DNS, DHCP, WINS und
AD lokal an beiden Standorten verfügbar sein. Sollte ein Standort aufgrund eines Notfalls
inoperativ werden, sind die Netzwerkdienste je nach den systemeigenen
Notfallwiederherstellungsfunktionen dieser Dienste am anderen Standort weiterhin verfügbar.
Dadurch wird sichergestellt, dass ein Failover von Arbeitsauslastungen von einem
ausgefallenen Standort zu einem anderen Standort in der Matrix Recovery
Management-Konfiguration möglich ist. Matrix Recovery Management darf nicht zum Failover
von Netzwerkdiensten verwendet werden.
Installieren und Konfigurieren von Matrix Recovery Management
HINWEIS: Die Startreihenfolge-Funktion von Matrix Recovery Management ist dazu
bestimmt, kritische Anwendungen zuerst zu starten, und nicht um sicherzustellen, dass
Startabhängigkeiten zwischen Anwendungen und Infrastrukturdiensten wie Netzwerken
erfüllt werden.
•
Matrix Recovery Management führt während eines Failovers keine DNS-Aktualisierungen
oder Aktualisierung der IP-Konfiguration wiederhergestellter logischer Server durch. Ihr
Netzwerkadministrator ist dafür verantwortlich, durch Vornahme der erforderlichen
Änderungen die Verfügbarkeit der Netzwerkdienste sicherzustellen, wenn Sie an jedem
Standort in der Matrix Recovery Management-Konfiguration einen logischen Server zur
Verwendung einer anderen IP-Adresse oder eines anderen Subnetzes konfigurieren.
•
Bei Ausführung auf physischen (VC-gehosteten) Zielen stellt Matrix Recovery Management
nicht sicher, dass logische Server an beiden Standorten die gleiche MAC-Adresse verwenden.
Bei der Ausführung auf VMware ESXi-gehosteten virtuellen Zielen stellt Matrix Recovery
Management sicher, dass logische Server an beiden Standorten die gleiche MAC-Adresse
verwenden. Ihr Netzwerkadministrator muss in der Netzwerkkonfiguration für DR-geschützte
logische Server entsprechend planen, wenn Sie DHCP für feste IP-Adressen verwenden.
HINWEIS: Einzelheiten zu MAC-Adressen für technologieübergreifende logische Server
(logische Server, die auf VC-Hosts und VM-Hosts ausgeführt werden können), finden Sie
unter Dynamische Arbeitsauslastungs-Verschiebung mit CloudSystem Matrix.
•
Bei der Ausführung von durch Virtual Connect gehosteten physischen Zielen muss das
Server-Abbild mit dem Portable Images Network Tool (PINT) auf die Ausführung auf Zielen
mit unterschiedlichen Netzwerkschnittstellen-Konfigurationen und MAC-Adressen vorbereitet
werden. Zur Verwendung von PINT müssen sich die lokalen und Remote-Standorte im
gleichen Netzwerk befinden und das Betriebssystemabbild muss eine Windows- oder
Linux-Version sein, die von Matrix Recovery Management und PINT unterstützt wird. PINT
stellt sicher, dass die statische Netzwerkkonfiguration trotz der unterschiedlichen Umgebung
erfolgreich vom Quellserver auf die Zielserver-Netzwerkschnittstellen übertragen wird. Die
ausführbaren Dateien und die README-Datei befinden sich im Ordner C:\Programme\HP\
Insight Control Service Migration\PI\PINT, wobei <SMP> der Ordner ist, in
dem HPE Insight Control Server Migration installiert ist. Kopieren Sie die ausführbare Datei
cp011231.exe auf den physischen Server, auf dem das Abbild derzeit ausgeführt wird.
Führen Sie cp011231.exe aus, um PINT zu installieren und den PINT-Dienst zu starten.
Weitere Informationen zu unterstützten Windows- oder Linux-Versionen und Insight Control
Server Migration finden Sie in derInsight Management Einstiegshilfe in der Hewlett Packard
Enterprise Enterprise-Informationsbibliothek.
•
Wenn die verwalteten Server am lokalen Standort und die entsprechenden verwalteten
Server am Remote-Standort ein Subnetz gemeinsam nutzen, müssen Sie sicherstellen,
dass kein Konflikt zwischen den von Virtual Connect Enterprise Manager (VCEM)
zugewiesenen MAC-Adressen vorliegt. Wird an beiden Standorten beispielsweise der von
VCEM vorgegebene Standard-Adressbereich verwendet, lässt sich ein Konflikt durch
Verwenden der 'Ausschlussbereiche' von VCEM vermeiden. So können Sie auf dem CMS
am lokalen Standort z. B. die Adressen von 00-21-5A-9B-00-00 bis 00-21-5A-9B-FF-FF und
auf dem CMS am Remote-Standort die Adressen von 00-21-5A-9C-00-00 bis
00-21-5A-9C-FF-FF ausschließen.
•
Bei DR-geschützten logischen Servern und IO-Diensten müssen ESX-Portgruppennamen
und Namen virtueller Hyper-V-Netzwerke am lokalen und am Remote-Standort identisch
sein.
Einrichten eines Netzwerks
11
Einrichten des Speichers
Matrix Recovery Management ermöglicht über eine Speicherarray-Replikation das Failover
logischer Server. Zwischen dem lokalen Standort und dem Remote-Standort sind
Speicherreplikations-Links vorhanden.
So richten Sie die Speicherreplikationsgruppen von Matrix Recovery Management ein:
1. Start- und Daten-LUNs für VC- oder VM-gehostete logische Server, die DR-geschützt werden
sollen, müssen mittels unterstützter Speicherreplikationsmethoden, z. B. P6000 Continuous
Access, P9000 Continuous Access oder 3PAR StoreServ-Remotekopie-Gruppen repliziert
werden. Wenn Sie anderen unterstützten Matrix-OE-Speicher als P6000, P9000 oder 3PAR
StoreServ verwenden, können Sie die benutzerdefinierte Speicheradapter-Schnittstelle
für die Integration von Speicher in die Matrix Recovery Management-GUI verwenden. Die
Integration hat zur Folge, dass der neu hinzugefügte Speicher in der Server-Dropdown-Liste
„Storage“ (Speicher) angezeigt wird.
HINWEIS: Speicherreplikationsgruppen müssen mit der Replikationssoftware der
spezifischen Speicherlösungen eingerichtet werden. Weitere Informationen finden Sie unter
„Erstellen und Installieren eines benutzerdefinierten Speicheradapters“.
•
Wenn ein DR-geschützter logischer Server am lokalen Standort VC-gehostet ist, dann
müssen die replizierten Start- und Daten-LUNs auf dem Array am Remote-Standort
dem betreffenden logischen Wiederherstellungsserver präsentiert werden.
•
Wenn ein DR-geschützter logischer Server am lokalen Standort VM-gehostet ist, dann
müssen die replizierten Start- und Daten-LUNs auf dem Array am Remote-Standort
dem VM-Host (z. B. ESX oder Hyper-V) an dem Remote-Standort bereitgestellt werden,
auf dem der logische Wiederherstellungsserver (z. B. ESX-Gastsystem oder Hyper-V)
ausgeführt werden soll.
HINWEIS:
•
Jede Wiederherstellungsgruppe verfügt über eine einzelne
Speicherreplikationsgruppe, die nur von logischen Servern in der betreffenden
Wiederherstellungsgruppe verwendet wird.
WICHTIG: Alle von diesen logischen Servern verwendeten Start- und Daten-LUNs
müssen in der gleichen Speicherreplikationsgruppe enthalten sein.
•
2.
3.
Erstellen Sie für jeden Satz logischer Server, der in eine Wiederherstellungsgruppe
eingeschlossen werden soll, eine Speicherreplikationsgruppe.
Zeichnen Sie die folgenden Details zur Konfiguration der Speicherreplikationsgruppe auf.
Diese Angaben werden beim Konfigurieren von Matrix Recovery Management für replizierten
Speicher benötigt:
•
12
Eine Speicherreplikationsgruppe ist ein Satz von Speicher-LUNs auf einem bestimmten
Festplatten-Array, der mit unveränderter Schreibreihenfolge repliziert wurde. Dies
entspricht dem P6000 Continuous Access-DR-Gruppenkonzept, dem P9000 Continuous
Access-Konsistenzgruppen-Konzept und den 3PAR
StoreServ-Remotekopie-Replikationskonzepten.
Speicherbezeichner des lokalen und des Remote-Standorts, z. B. ein P6000
Speicherarray-WWN oder eine P9000 Array-Seriennummer oder die 3PAR
StoreServ-Speicherarray-Seriennummer.
HINWEIS: Genauso, wie ein Konfigurationskonflikt der MAC-Adressen an den lokalen
und Remote-Standorten im Abschnitt „Einrichten eines Netzwerks“ (Seite 10) vermieden
wird, muss bei der Konfiguration der WWNs ein Konflikt vermieden werden, wenn die
WWNs für ihre betreffenden Standorte nicht privat sind. Die gleiche Methode, bei der
VCEM-Ausschlussbereiche genutzt werden, ist für die Array-WWN-Konfiguration
verfügbar.
•
FQDN-Namen und -Anmeldedaten des Speicherverwaltungsservers für die lokalen und
Remote-Standorte, z. B. HPE P6000 Command View-Servername und -Anmeldedaten
zum Zugriff auf den Command View-Server.
•
Name der Speicherreplikationsgruppe, der den Start- und Daten-LUNs der logischen
Server zugewiesen wird, die der gleichen Wiederherstellungsgruppe angehören werden,
z. B. der P6000 DR-Gruppenname.
HINWEIS:
•
◦
P6000, P9000 und benutzerdefinierte Speicherreplikationsgruppen müssen den
gleichen Speicherreplikationsgruppennamen am lokalen Standort und am
Remote-Standort verwenden.
◦
3PAR StoreServ-Remotekopie-Speicherreplikationsgruppen haben am lokalen
Standort andere Namen als am Remote-Standort.
Speicher-Port-WWN und -LUN für die replizierten Volumes, falls von DR-geschützten
logischen Servern unverarbeitete LUNs verwendet werden.
Allgemeine Hinweise zur Speichereinrichtung
•
Informationen zur Speichereinrichtung von technologieübergreifenden logischen Servern
(logische Server, die VC-gehostet oder VM-gehostet sein können) finden Sie unter:
Dynamische Arbeitsauslastungs-Verschiebung mit CloudSystem Matrix.
•
Eine Liste der unterstützten Betriebssysteme finden Sie in derInsight Management Support
Matrix in der Hewlett Packard Enterprise Enterprise-Informationsbibliothek.
•
Hyper-V-Virtual Machines in Cluster-Umgebungen müssen auf Cluster-Freigabe-Volumes
gespeichert werden.
Hinweise zur HPE P6000 Speichereinrichtung
•
Wenn bei der Speicherreplikation mit der P6000 Continuous Access Software eine
asynchrone Replikationsgruppe in einer Wiederherstellungsgruppe verwendet wird und ein
nicht geplantes Failover der Wiederherstellungsgruppe vollzogen wird, wird automatisch
eine komplette Kopie der neuen Quell-vDisks auf den neuen Ziel-vDisks dupliziert, wenn
der ausgefallene Standort wiederhergestellt wird. Sollte inmitten dieses vollständigen
Kopiervorgangs ein Fehler auftreten, könnten die Daten auf den neuen Ziel-vDisks beschädigt
sein. Zum Schutz der neuen Ziel-vDisks müssen Sie P6000 Command View so einstellen,
dass das automatische Anhalten aktiviert wird, um den automatischen kompletten
Kopiervorgang zu verhindern. Außerdem müssen Sie die Daten auf den neuen Ziel-vDisks
sichern, bevor Sie den kompletten Kopiervorgang manuell durchführen.
Um nach dem Failover von asynchronen Speicherreplikationsgruppen ein vollständiges
Kopieren der neuen Quell-vDisks auf die neuen Ziel-vDisks zu vermeiden, stellt Matrix
Recovery Management den Modus aller asynchronen Replikationsgruppen vor dem
Speicher-Failover automatisch auf synchron ein und macht diese Umstellung nach Abschluss
des Speicherfailovers wieder rückgängig. Der Speicherlink muss aktiv sein, und die Arrays
13
am lokalen und am Remote-Standort müssen beide vom selben Command View-Server
verwaltet werden, damit Matrix Recovery Management diesen Vorgang durchführen kann.
Unter seltenen Ausnahmebedingungen kann der synchrone Modus einer
Speicherreplikationsgruppe beibehalten werden, was dann einen manuellen Eingriff erfordert,
um den Modus auf asynchron zurückzusetzen.
Weitere Informationen finden Sie hier:
•
◦
Klicken Sie auf die Registerkarte Manuals (Handbücher), um die Dokumentation zur
P6000 Continuous Access-Software anzuzeigen, die unter http://www.hpe.com/info/
P6000-ContinuousAccess-manuals verfügbar ist.
◦
P6000 Command View Software anzuzeigen, die unter http://www.hpe.com/info/
P6000-CommandView-manuals verfügbar ist.
Wenn das Kennwort für einen Speicherverwaltungsserver geändert wird, verfahren Sie wie
folgt, um das Kennwort des Speicherverwaltungsservers auf dem CMS und in der Matrix
Recovery Management-Konfiguration zu aktualisieren:
1. Wählen Sie im Menü „Tools“ Discover (Ermitteln), um den Speicherverwaltungsserver
mit dem geänderten Kennwort zu ermitteln.
2. Rufen Sie auf der Matrix Recovery Management-Benutzeroberfläche die Registerkarte
Storage Management Servers (Speicherverwaltungsserver) auf.
3. Wählen Sie den Speicherverwaltungsserver mit dem geänderten Kennwort aus, und
klicken Sie auf Edit (Bearbeiten).
4. Aktivieren Sie das Kontrollkästchen Refresh SIM Password (SIM-Kennwort
aktualisieren), und klicken Sie auf Save (Speichern).
Hinweise zur HPE P9000 Speichereinrichtung
•
•
14
Wenn die Speicherreplikation der P9000 Continuous Access Software verwendet wird, ist
Matrix Recovery Management zur Verwaltung der Speicherreplikation auf die
Befehlszeilenschnittstelle (CLI) der P9000 Cluster Extension Software angewiesen: Die
P9000 Cluster Extension Software-CLI muss auf einem Standalone-Windows-System
installiert sein. Die P9000 Cluster Extension Software ist zur Verwaltung der
P9000-Speicherreplikation auf die P9000 RAID Manager Software angewiesen. Instanzen
und Konfigurationsdateien der P9000 RAID Manager Software müssen zur Verwaltung
verschiedener Gerätegruppen konfiguriert sein, die in Matrix Recovery Management
konfiguriert sind. Weitere Informationen finden Sie hier:
◦
P9000 Cluster Extension Software anzuzeigen, die unter http://www.hpe.com/info/
ClusterExtension-manuals verfügbar ist.
◦
P9000 RAID Manager Software anzuzeigen, die unter http://www.hpe.com/info/
XPRaidManager-manuals verfügbar ist.
Wenn das Kennwort für einen Speicherverwaltungsserver geändert wird, verfahren Sie wie
folgt, um das Kennwort des Speicherverwaltungsservers auf dem CMS und in der Matrix
Recovery Management-Konfiguration zu aktualisieren:
Wählen Sie im Menü „Tools“ Discover (Ermitteln), um den Speicherverwaltungsserver mit
dem geänderten Kennwort zu ermitteln.
1. Rufen Sie auf der Matrix Recovery Management-Benutzeroberfläche die Registerkarte
Storage Management Servers (Speicherverwaltungsserver) auf.
2. Wählen Sie den Speicherverwaltungsserver mit dem geänderten Kennwort aus, und
klicken Sie auf Edit (Bearbeiten).
3.
Aktivieren Sie das Kontrollkästchen Refresh SIM Password (SIM-Kennwort
aktualisieren), und klicken Sie auf Save (Speichern).
Hinweise zur Einrichtung von HPE 3PAR StoreServ-Speicher
•
Wenn die 3PAR StoreServ-Remotekopie-Replikation verwendet wird, ist Matrix Recovery
Management zur Verwaltung der Speicherreplikation auf die Befehlszeilenschnittstelle (CLI)
der 3PAR StoreServ Cluster Extension Software angewiesen. Die 3PAR StoreServ Cluster
Extension-CLI ist wiederum auf die HPE 3PAR StoreServ InForm Command Line Software
angewiesen. Beide müssen auf den Central Management Servern installiert sein, auf denen
Matrix Recovery Management installiert ist. Weitere Informationen finden Sie hier:
◦
3PAR StoreServ Cluster Extension Software anzuzeigen, die unter http://www.hpe.com/
info/ClusterExtension-manuals verfügbar ist.
◦
3PAR StoreServ InForm Command Line Software anzuzeigen, die unter http://
www.hpe.com/info/3Par-InformOS-manuals verfügbar ist.
•
Zur Verwaltung einer Speicherreplikation auf einem 3PAR StoreServ-Speichersystem wird
eine verschlüsselte Kennwortdatei benötigt. Eine verschlüsselte Kennwortdatei kann durch
Ausführen der Befehle der 3PAR StoreServ InForm Command Line Software erstellt werden.
Weitere Informationen finden Sie unter dem Befehl setpassword in der Referenz zur 3PAR
InForm Command Line. Das verschlüsselte Kennwort für jedes Speicherarray muss auf
beiden CMSs im Verzeichnis C\Programme\HP\Insight Recovery\STORAGE\3PAR\
conf vorhanden sein, in dem Matrix Recovery Management installiert ist. Die verschlüsselte
Kennwortdatei macht Benutzernamen, Domänennamen und Kennwort überflüssig, die bei
anderen Arten von Speicherverwaltungsservern erforderlich sind.
•
Die verschlüsselte Kennwortdatei für Inserv-Speicherserver am lokalen und am
Remote-Standort muss an jedem Standort auf dem CMS verfügbar sein, und der Name der
Kennwortdatei muss auf dem CMS eines jeden Standorts gleich sein.
•
Wenn Sie die 3PAR StoreServ InForm Command Line Software auf dem CMS mit einer
Softwareversion aktualisieren, die von Matrix OE und 3PAR StoreServ Cluster Extension
Software unterstützt wird, dann müssen Sie eine Eigenschaft in der Matrix Recovery
Management-Eigenschaftsdatei aktualisieren. Ändern Sie die Eigenschaft
INFORM_CLI_VERSION in conf\hp_ir.properties im Matrix Recovery
Management-Installationsverzeichnis auf dem CMS. Der Standardwert der Eigenschaft ist
auf 3.1.2 eingestellt.
•
Wenn Sie die 3PAR StoreServ clx/cli aktualisieren, müssen Sie cli.exe und
clx3parconfig.exe ausführen, um die Zertifikate zu akzeptieren oder sie wieder der
Ausschlussliste hinzuzufügen. Weitere Informationen zum Hinzufügen von Zertifikaten finden
Sie unter „Fehlerbehebung“ (Seite 72).
•
Ab Version 7.5 unterstützt Matrix Recovery Management die automatische
Speicherkonfiguration mit Storage Provisioning Manager (SPM)-Vorlagen mit Remote Copy
(Remotekopie)-Anforderungen, wenn 3PAR StoreServ-Speichersysteme verwendet werden.
Weitere Informationen zu SPM-Vorlagen finden Sie im Storage Provisioning Manager (SPM)
Benutzerhandbuch.
HINWEIS: Bei regelmäßigen (asynchronen) 3PAR-Remotekopien werden beim manuellen
Failover die Daten in den Remotekopie-Gruppenvolumes nicht synchronisiert. Um einen
Datenverlust zu vermeiden, synchronisieren Sie die Remotekopie-Gruppen, bevor Sie Stoppund Failover-Vorgänge daran durchführen.
15
Erstellen und Installieren eines benutzerdefinierten Speicheradapters
Matrix Recovery Management bietet eine benutzerdefinierte
Speicheradapter-Schnittstellenspezifikation, um das Matrix Recovery Management-Failover in
einem Schritt für Speichertypen zu ermöglichen, die von Matrix OE unterstützt werden, aber
noch nicht in Matrix Recovery Management integriert wurden.
Übersicht
Matrix Recovery Management kann zum Aufruf von Speicherreplikationsverwaltungsbefehlen
für nicht integrierten Speicher konfiguriert werden, wenn verschiedene Speicherkonfigurationsoder Failover-Vorgänge aufgerufen werden. Die benutzerdefinierte Speicheradapter-Spezifikation
für nicht integrierten Speicher definiert Befehle zum:
•
Validieren der Speicherverwaltungsserver-Informationen, wenn Speicherverwaltungsserver
für nicht integrierten Speicher über die Matrix Recovery Management-GUI konfiguriert
werden.
•
Validieren der Speicherreplikationsgruppen-Informationen, wenn Speicherreplikationsgruppen,
die nicht integrierten Speicher verwenden, über die Matrix Recovery Management-GUI
konfiguriert werden.
•
Durchführen eines Failovers von Speicherreplikationsgruppen, wenn ein Failover logischer
Server, die nicht integrierten Speicher verwenden, über den Vorgang Activate (Aktivieren)
in Matrix Recovery Management ausgeführt wird.
Verwalten von nicht integriertem Speicher mit Matrix Recovery Management
Wenn Ihre DR-geschützten logischen Server ein nicht integriertes Speichersystem verwenden,
das von Matrix OE unterstützt wird, und Sie möchten, dass Matrix Recovery Management bei
nicht integriertem Speicher automatisch ein Speicher-Failover über den Vorgang Activate
(Aktivieren) in Matrix Recovery Management aufruft, müssen Sie folgende Schritte durchführen:
1. Implementieren und testen Sie eingehend drei in „Benutzerdefinierte
Speicheradapter-Schnittstellenspezifikation“ definierte Befehle. Führen Sie das Testen dann
am lokalen Standort und am Remote-Standort durch.
2. Erstellen Sie ein neues Unterverzeichnis unter dem Verzeichnis STORAGE im Matrix Recovery
Management-Installationsverzeichnis. Geben Sie dem Unterverzeichnis einen Namen, durch
den der verwaltete Speichertyp identifiziert wird. Dieser Name wird in Dropdown-Menüs auf
der Matrix Recovery Management-GUI angezeigt. Führen Sie diesen Schritt am lokalen und
am Remote-Standort durch.
HINWEIS: Der Name des Unterverzeichnisses muss am lokalen Standort und am
Remote-Standort genau gleich sein.
3.
4.
5.
6.
16
Platzieren Sie Ihre Implementierung der benutzerdefinierten Speicheradapterbefehle in dem
für den betreffenden Speichertyp erstellten Unterverzeichnis. Führen Sie diesen Schritt am
lokalen und am Remote-Standort durch.
Definieren Sie lokale und Remote-Speicherverwaltungsserver für den nicht integrierten
Speicher. Wählen Sie dazu den Speichertyp aus dem Dropdown-Menü auf der Registerkarte
Storage Management Servers (Speicherverwaltungsserver) auf der Matrix Recovery
Management-GUI aus. Der Speichertyp im Dropdown-Menü hat den gleichen Namen wie
das in Schritt 2 erstellte Unterverzeichnis.
Erstellen Sie mit Verwaltungstools für das nicht integrierte Speichersystem eine
Speicherreplikationsgruppe für den Speicher, der von den logischen Servern verwendet
wird, die DR-geschützt sein werden.
Erstellen Sie über die Matrix Recovery Management-GUI eine Speicherreplikationsgruppe
für den nicht integrierten Speicher. Der Speichertyp im Dropdown-Menü hat den gleichen
Namen wie das in Schritt 2 erstellte Unterverzeichnis.
7.
8.
Erstellen Sie über die Matrix Recovery Management-GUI eine Wiederherstellungsgruppe,
und verknüpfen Sie die betreffende Wiederherstellungsgruppe mit der
Speicherreplikationsgruppe für den nicht integrierten Speicher.
Führen Sie am lokalen Standort einen Matrix Recovery Management-Export-Vorgang durch,
um eine exportconfig-Datei zu generieren. Führen Sie dann am Remote-Standort einen
Import-Vorgang durch, um die betreffende exportconfig-Datei am Remote-Standort zu
importieren.
Benutzerdefinierte Speicheradapter-Schnittstellenspezifikation
Die folgenden Befehle werden in der benutzerdefinierten
Speicheradapter-Schnittstellenspezifikation definiert:
•
validatesms.cmd: Validiert einen Speicherverwaltungsserver während der Konfiguration
•
validatesrg.cmd: Validiert eine Speicherreplikationsgruppe während der Konfiguration
•
failoversrg.cmd: Führt während der Aktivierung der Wiederherstellungsgruppe ein
Failover einer Speicherreplikationsgruppe durch
Befehlszeilenargumente
•
Für validatesms.cmd:
sms_name=<Name eines Speicherverwaltungsservers>
sms_username=<Anmeldename eines Speicherverwaltungsservers>
•
Für validatesrg.cmd:
sms_name=<Name des Speicherverwaltungsservers am lokalen Standort>
sms_username=<Anmeldename eines Speicherverwaltungsservers am lokalen Standort>
srg_name=<Name der zu validierenden Speicherreplikationsgruppe>
local_storage_id=<eindeutiger Bezeichner des Speichersystems am lokalen Standort>
remote_storage_id=<eindeutiger Bezeichner des Speichersystems am Remote-Standort>
HINWEIS: Volumes in der Speicherreplikationsgruppe (durch srg_name identifiziert)
werden zwischen dem lokalen Speichersystem (durch local_storage_id identifiziert) und
dem Remote-Speichersystem (durch remote_storage_id identifiziert) repliziert.
•
Für failoversrg.cmd:
local_sms_name=<Name des Speicherverwaltungsservers am lokalen Standort>
local_sms_username=<Benutzername des Speicherverwaltungsservers am lokalen Standort>
local_storage_id=<eindeutiger Bezeichner des Speichersystems am lokalen Standort>
remote_sms_name=<Name des Speicherverwaltungsservers am Remote-Standort>
remote_sms_username=<Benutzername des Speicherverwaltungsservers am Remote-Standort>
remote_storage_id=<eindeutiger Bezeichner des Speichersystems am Remote-Standort>
srg_name=<Name der Speicherreplikationsgruppe, für die das Failover durchgeführt werden soll>
use_non_current_data=<yes oder no>
HINWEIS: Bei dem Wert yes wird ein Failover der Speicherreplikationsgruppe auch in
Fällen vorgeschrieben, bei denen die Daten am Ziel-Standort nicht aktuell sind. Bei dem
Wert no wird veranlasst, dass ein Speicher-Failover fehlschlägt, wenn die Daten am Ziel
nicht aktuell sind.
Beispielaufrufe der Matrix Recovery Management-Implementierung benutzerdefinierter
Adapter
•
Während der Konfiguration des Speicherverwaltungsservers in Matrix Recovery Management:
<Matrix Recovery Management-Installationsverzeichnis>/STORAGE/EMC/validatesms.cmd sms_name=EMC_SMS1
sms_username=admin
•
Während der Konfiguration der Speicherreplikationsgruppe in Matrix Recovery Management:
<Matrix Recovery Management-Installationsverzeichnis>/STORAGE/EMC/validatesrg.cmd sms_name=EMCSE1
sms_username=admin local_storage_id=emc_id1 remote_storage_id=emc_id2 srg_name=SRG1
•
Während eines Aktivierungsvorgangs in Matrix Recovery Management:
<Matrix Recovery Management-Installationsverzeichnis>/STORAGE/EMC/failoversrg.cmd local_sms_name=EMC_SMS1
local_sms_username=admin local_storage_id=emc_id1 remote_sms_name=EMC_SMS2 remote_user_name=admin
remote_storage_id=emc_id2 srg_name=SRG1 use_non_current_data=yes
17
Befehlsrückgabecode
Befehle müssen bei einer erfolgreichen Ausführung 0 zurückgeben. Bei fehlgeschlagener
Ausführung wird ein Fehlercode ungleich Null angezeigt.
Mehrere benutzerdefinierte Speicheradapter
Matrix Recovery Management unterstützt gleichzeitig mehrere benutzerdefinierte Speicheradapter
in einer Matrix Recovery Management-Konfiguration. Für jeden benutzerdefinierten
Speicheradaptertyp können Sie ein neues Unterverzeichnis erstellen und darin Ihre
Implementierung der drei Befehle für den betreffenden Speichertyp platzieren. Um beispielsweise
einen Speicheradapter namens EMC hinzuzufügen, erstellen Sie ein EMC-Unterverzeichnis
unter <Matrix Recovery Management-Installationsverzeichnis>/STORAGE, und
kopieren alle drei Befehle in das neu erstellte Verzeichnis:
•
<Matrix Recovery
Management-Installationsverzeichnis>/STORAGE/EMC/validatesms.cmd
•
<Matrix Recovery
Management-Installationsverzeichnis>/STORAGE/EMC/validatesrg.cmd
•
<Matrix Recovery
Management-Installationsverzeichnis>/STORAGE/EMC/failoversrg.cmd
Wenn für Ihre Implementierung der Speicheradapterbefehle Kennwörter zum Verwalten der
Speicherreplikation erforderlich sind, muss die Implementierung der Speicheradapterbefehle
sicher mit Kennwörtern umgehen. Sie sind dafür verantwortlich, Kennwörter beim Speichern und
Abrufen zu verschlüsseln bzw. entschlüsseln.
Einrichten logischer Server am lokalen Standort
Die folgenden Bedingungen müssen erfüllt sein, bevor Sie einen logischen Server für den
DR-Schutz konfigurieren können:
1. Stellen Sie sicher, dass der logische Servern mit einem SAN-basierten Speicher verknüpft
ist.
2. Ein logischer Servers muss bereits mindestens einmal aktiviert gewesen sein.
3. Auf einem logischen Server müssen ein Betriebssystem und Anwendungen installiert sein.
Logische Server, die diese Bedingungen erfüllen, werden am lokalen Standort in der Liste
Available LS(s) (Verfügbare LS(s)) auf der Konfigurations-GUI in Matrix Recovery Management
angezeigt, auch wenn sie nach der erstmaligen Aktivierung deaktiviert wurden.
Bei Standorten mit einer großen Anzahl logischer Server kann die Aktivierungszeit während
eines Failovers durch Partitionieren logischer Server in Portabilitätsgruppen verkürzt werden.
Um die Aktivierungszeit zu verbessern, wird empfohlen, auf Clustern basierende
Portabilitätsgruppen zu erstellen. Bei 5 ESXi-Clustern mit je 10 Hosts können Sie beispielsweise
eine Portabilitätsgruppe für jeden der 5 Cluster erstellen, wodurch die Aktivierungszeit verbessert
wird. Hewlett Packard Enterprise empfiehlt, die mit logischen Servern verknüpfte
Portabilitätsgruppe am lokalen und am Remote-Standort auf einen Teilsatz der Virtual
Machine-Hosts und Virtual Connect-Blades einzuschränken, die zum Hosten dieser logischen
Server fähig sind. Weitere Informationen zum Konfigurieren von Portabilitätsgruppen finden Sie
unter Logical servers (Logische Server)→Menus & screens (Menüs und
Bildschirme)→Manage portability groups (Portabilitätsgruppen verwalten) in der Online-Hilfe
zu HPE Matrix OE Visualization und logische Server.
18
HINWEIS: Der Datenspeicher eines VM-gehosteten logischen Servers kann nicht geändert
werden, solange er von Matrix Recovery Management verwaltet wird. Wenn Sie den Datenspeicher
ändern möchten, entfernen Sie zuerst den VM-gehosteten logischen Server aus der Matrix
Recovery Management-Konfiguration. Ändern Sie den Datenspeicher dann mittels des Vorgangs
Logical Servers Activate (Logische Server aktivieren) im Menü Tools auf der Registerkarte
Visualization (Visualisierung). Nachdem die Datenspeicherung geändert wurde, befolgen Sie
die Schritte unter „Einrichten des Speichers“, „Einrichten eines Netzwerks“ und „Einrichten
logischer Server am Remote-Standort“, um den logischen Server der Matrix Recovery
Management-Konfiguration erneut hinzuzufügen.
Einrichten logischer Server am Remote-Standort
Ab Version 7.5 erstellt der Importvorgang von Matrix Recovery Management automatisch logische
Remote-Standort-(Peer)-Server, ohne dass der lokale Standort manuell deaktiviert werden und
ein manuelles Failover der Speicherreplikationsgruppe durchgeführt werden muss. Es wird zu
einem regelmäßigen DR-Probelauf geraten, um die Aktivierung des logischen Servers und des
IO-Dienstes, einschließlich der Verfügbarkeit von Ressourcen am Wiederherstellungsstandort,
zu testen. Weitere Informationen finden Sie unter „Testen und Failover-Vorgänge“ (Seite 36).
Es wird nach Namen logischer Server gesucht, um zu bestimmen, ob sie Namen logischer Server
in den importierten Wiederherstellungsgruppen entsprechen.
•
Wenn Übereinstimmungen gefunden werden, werden diese logischen Server automatisch
den logischen Servern gleichen Namens zugeordnet.
•
Wenn für den Namen des importierten logischen Servers keine Entsprechung gefunden
wird, können Sie aus der Dropdown-Liste den Namen eines anderen logischen Servers
auswählen, der dem logischen Server aus der Exportdatei zugeordnet werden soll.
•
Wenn IMPORT_STRATEGIES in der Datei dr.properties auf COPY_LS eingestellt ist,
können Sie die leere Option aus der Dropdown-Liste auswählen. Matrix Recovery
Management erstellt dann einen logischen Server desselben Namens am Remote-Standort.
HINWEIS:
•
Um Verwirrungen zu vermeiden, empfiehlt Hewlett Packard Enterprise als beste
Vorgehensweise, den gleichen Namen für einen logischen Server am Remote-Standort zu
verwenden, der für den zugehörigen logischen Server am lokalen Standort verwendet wurde.
•
Informationen zu technologieübergreifenden logischen Servern (logische Server, die
VC-gehostet oder VM-gehostet sein können) finden Sie unter Dynamische
Arbeitsauslastungs-Verschiebung mit CloudSystem Matrix.
WICHTIG: Bei Standorten mit einer großen Anzahl logischer Server kann die
Aktivierungszeit während eines Failovers durch Partitionieren logischer Server in
Portabilitätsgruppen verkürzt werden. Hewlett Packard Enterprise empfiehlt, die mit logischen
Servern verknüpfte Portabilitätsgruppe am lokalen und am Remote-Standort auf einen
Teilsatz der Virtual Machine-Hosts und Virtual Connect-Blades einzuschränken, die zum
Hosten dieser logischen Server fähig sind. Um die Aktivierungszeit zu verbessern, ist es
ratsam, auf Clustern basierende Portabilitätsgruppen zu erstellen. Bei 5 ESXi-Clustern mit
je 10 Hosts können Sie beispielsweise eine Portabilitätsgruppe für jeden der 5 Cluster
erstellen, wodurch die Aktivierungszeit verbessert wird. Weitere Informationen zum
Konfigurieren von Portabilitätsgruppen finden Sie unter Logical servers (Logische
Server)→Menus & screens (Menüs und Bildschirme)→Manage portability groups
(Portabilitätsgruppen verwalten) in der Online-Hilfe zu Matrix OE Visualization und logische
Server.
Einrichten logischer Server am Remote-Standort
19
Konfigurieren von Matrix Recovery Management
Nachdem Matrix Recovery Management installiert wurde, können Sie die grafische
Benutzeroberfläche (GUI) von Matrix Recovery Management über die Startseite von Matrix
Operating Environment durch Auswahl von Tools und Matrix recovery management... starten.
Über die Matrix Recovery Management-GUI können Sie Matrix Recovery Management
konfigurieren, DR-geschützte logische Server und IO-Dienste verwalten sowie die
Failover-Funktion testen.
Übersicht über die Matrix Recovery Management-GUI
Auf dem Startbildschirm der Benutzeroberfläche von Matrix Recovery Management befinden
sich Registerkarten für Konfigurations- und Verwaltungsaufgaben. Siehe Abbildung 2, „Matrix
Recovery Management-Startbildschirm“.
Abbildung 2 Matrix Recovery Management-Startbildschirm
Registerkarten der Matrix Recovery Management-Benutzeroberfläche
•
Home (Startseite)
Informationen zum neuesten Job (Auftrag) in Matrix Recovery Management werden oben
auf dem Matrix Recovery Management-Bildschirm Home (Startseite) angezeigt. Dort sehen
Sie auch Latest Job status: (Status des letzten Auftrags), Job Id: (Auftragskennung), Start
Time: (Startzeit) (wenn der Auftrag noch läuft) oder End Time: (Endzeit) (wenn der Auftrag
bereits abgeschlossen wurde). Es folgt dann eine Liste der anderen
Konfigurationsregisterkarten in Matrix Recovery Management, neben denen jeweils das
Symbol für Configured (Konfiguriert) oder Not configured (Nicht konfiguriert) angezeigt
wird. So sehen Sie, für welche Registerkarte die Konfigurationsaufgaben bereits
abgeschlossen wurden.
•
Sites (Standorte)
Konfigurieren Sie bevorzugte und sekundäre Standorte. Aktivieren oder deaktivieren Sie
Wiederherstellungsgruppen. Bearbeiten oder löschen Sie bestehende
Standortkonfigurationen. Exportieren oder importieren Sie Standortkonfigurationen.
•
Storage Management Servers (Speicherverwaltungsserver)
Definieren Sie neue Speicherverwaltungsserver. Zeigen Sie Speicherverwaltungsserver an,
bearbeiten oder löschen Sie sie.
20
•
Storage Replication Groups (Speicherreplikationsgruppen)
Erstellen Sie neue Speicherreplikationsgruppen. Zeigen Sie Konfigurationsdetails für
Speicherreplikationsgruppen an. Kopieren, bearbeiten oder löschen Sie
Speicherreplikationsgruppen.
•
Recovery Groups (Wiederherstellungsgruppen)
Erstellen Sie neue Wiederherstellungsgruppen. Zeigen Sie Konfigurationsdetails für
Wiederherstellungsgruppen an. Importieren, bearbeiten oder löschen Sie
Wiederherstellungsgruppen. Aktivieren oder deaktivieren Sie den Wartungsmodus in
Wiederherstellungsgruppen.
•
Jobs (Aufträge)
Überwachen Sie den Auftrag sfortschritt, und zeigen Sie die Auftragsdetails an. Brechen
Sie laufende Aufträge ab. Starten Sie fehlgeschlagene Aufträge neu. Zeigen Sie Protokolle
für Aufträge und untergeordnete Aufträge an. Löschen Sie Auftragsinformationen.
Die Online-Hilfe und die QuickInfos zu Matrix Recovery Management bieten Antworten auf
Fragen, die sich Ihnen beim Verwenden der grafischen Benutzeroberfläche möglicherweise
stellen.
Matrix Recovery Management-Konfigurationsschritte
Abbildung 3, „Konfigurationsschritte“ veranschaulicht den aus sechs Schritten bestehenden
Matrix Recovery Management-Konfigurationsvorgang. Nachdem der Matrix Recovery
Management-Konfigurationsvorgang am lokalen Standort abgeschlossen wurde, muss Matrix
Recovery Management am Remote-Standort konfiguriert werden. Um den Konfigurationsvorgang
am Remote-Standort zu vereinfachen und eine synchronisierte Konfiguration an beiden Standorten
sicherzustellen, muss die Konfiguration über einen einzelnen CMS erfolgen. Sie können die
Konfiguration in eine Datei exportieren und sie auf den Remote-CMS kopieren, über den Sie
dann einen Importvorgang ausführen können.
Abbildung 3 Konfigurationsschritte
21
Tabelle 1 (Seite 22) listet die sechs Schritte im Matrix Recovery Management-Vorgang auf.
Tabelle 1 Der Matrix Recovery Management-Vorgang
Schrittnummer Beschreibung
1
In diesem Schritt werden lokale und Remote-Standorte definiert, einschließlich Benennung der
Standorte, Designieren von Central Management Server und Designieren bevorzugter Zieltypen
(physische Server oder Virtual Machines).
2
Lokale und Remote-Speicherverwaltungsserver werden in diesem Schritt definiert. Diese Server
verwalten die Speicherreplikationsgruppen am lokalen und Remote-Standort.
3
Informationen zur Speicherreplikationsgruppe werden in diesem Schritt konfiguriert. In Matrix Recovery
Management ist eine Speicherreplikationsgruppe ein Obergriff für eine sogenannte DR-Gruppe in
der Terminologie von P6000 Continuous Access bzw. eine Gerätegruppe in der Terminologie von
P9000.
4
Wiederherstellungsgruppen werden in diesem Schritt konfiguriert. Eine Wiederherstellungsgruppe
ist ein Konzept in Matrix Recovery Management, das einen oder mehrere logische Server oder
IO-Dienste mit einer einzelnen Speicherreplikationsgruppe paart. Wiederherstellungsgruppensätze
können zwischen lokalen und Remote-Standorten umgeschaltet werden. Ein
Wiederherstellungsgruppensatz umfasst alle Wiederherstellungsgruppen, die die gleichen bevorzugten
und sekundären Standorte verwenden.
5
Exportieren Sie die Matrix Recovery Management-Konfiguration in eine Datei am lokalen Standort.
6
Importieren Sie die Datei.
1.
2.
3.
4.
Konfigurieren Sie über die Registerkarte Sites (Standorte) den lokalen Standort.
Konfigurieren Sie über die Registerkarte Storage Management Servers
(Speicherverwaltungsserver) die Speicherverwaltungsserver am lokalen Standort.
Konfigurieren Sie über die Registerkarte Storage Replication Groups
(Speicherreplikationsgruppen) die Speicherreplikationsgruppen am lokalen Standort.
Konfigurieren Sie über die Registerkarte Recovery Groups (Wiederherstellungsgruppen)
die Wiederherstellungsgruppen am lokalen Standort.
HINWEIS: Matrix Recovery Management ermöglicht ein Failover der logischen Server
oder der IO-Dienste in einer Wiederherstellungsgruppe, unabhängig von den zugeordneten
Speicherreplikationsgruppen. Diese Funktion wird als Speicherentkopplung bezeichnet.
5.
6.
7.
Erstellen Sie über die Registerkarte Sites (Standorte) eine Exportdatei am lokalen Standort.
Informationen zu Import- und Exportparametern finden Sie unter „Export- und-Importvorgänge
von Matrix Recovery Management“.
Importieren Sie über die Registerkarte Sites (Standorte) am Remote-Standort die Matrix
Recovery Management-Konfiguration des lokalen Standorts. Weitere Informationen finden
Sie unter „Export- und-Importvorgänge von Matrix Recovery Management“.
Hewlett Packard Enterprise empfiehlt, die logischen Wiederherstellungsserver nach dem
Importvorgang zu testen. Weitere Informationen finden Sie unter „Testen von
Wiederherstellungsgruppen“ (Seite 36).
Export- und-Importvorgänge von Matrix Recovery Management
Dieser Abschnitt geht auf die Schlüsselpunkte bezüglich des Export- und Importverhaltens von
Matrix Recovery Management ein.
Export
•
22
Die Matrix Recovery Management-Konfiguration am exportierenden Standort wird in Datei
exportconfig eingeschlossen, die am exportierenden Standort generiert wird. Die
Konfigurationsexportdatei von Matrix Recovery Management erhält standardmäßig den
Namen exportconfig. Die Datei exportconfig wird an einem Standardspeicherort
gespeichert, der vom Browser im System des Administrators festgelegt wird. Sie können
den Standardnamen der Exportkonfigurationsdatei ändern, wenn Sie beispielsweise mehrere
Matrix Recovery Management-Konfigurationsexportdateien speichern möchten. Sie können
auch den Speicherort für die Exportkonfigurationsdatei ändern, bevor Sie den
Speichervorgang abschließen.
•
Alle Wiederherstellungsgruppen, die Sie vom lokalen Standort exportieren und zum
Remote-Standort importieren möchten, müssen auf dem lokalen Standort aktiviert werden.
Wiederherstellungsgruppen, die beim Durchführen des Exportvorgangs am lokalen Standort
deaktiviert sind, werden am Remote-Standort nicht importiert. Befinden sich am
exportierenden Standort keine aktivierten Wiederherstellungsgruppen, kann die generierte
exportconfig-Datei am importierenden Standort nicht verwendet werden.
•
DR-geschützte IO-Dienste, die Wiederherstellungsgruppen angehören, werden exportiert
und können an einem Remote-Standort importiert werden. Ein IO-Dienstreplikat kann jedoch
weder exportiert noch importiert werden.
•
Am sekundären Standort sind bei der Verwendung von Storage Provisioning Manager
(SPM)-Speichervorlagen mit Remote Copy (Remotekopie)-Anforderungen die folgenden
Gesichtspunkte zu berücksichtigen:
◦
Vorgang zum Hinzufügen von Datenträgern und Speichersynchronisierung mit der
Export-/Importfunktion von Matrix Recovery Management oder dem Befehl drsync
–
◦
◦
Wird nur über den bevorzugten Standort unterstützt: Sie können einen
Datenträger zum Speicherpooleintrag eines logischen Servers am bevorzugten
Standort hinzufügen und die Änderung mit dem Export-/Importvorgang von Matrix
Recovery Management oder durch Ausführen des Befehls drsync auf den
logischen Peer-Server am sekundären Standort übertragen. Es ist nicht möglich,
den Vorgang zum Hinzufügen eines Datenträgers am sekundären Standort
auszuführen und die Änderung auf den logischen Peer-Server am bevorzugten
Standort zu übertragen.
Für jeden Schritt der folgenden Vorgänge muss ein Failover des Speichers auf den
bevorzugten Standort durchgeführt werden:
–
Hinzufügen eines Datenträgers zum logischen Server am bevorzugten Standort.
–
Exportieren am bevorzugten Standort und Importieren am sekundären Standort.
–
Synchronisieren logischer Server mit dem Befehl drsync.
Vor dem Hinzufügen eines Datenträgers oder vor einer Speichersynchronisierung,
jedoch erst nach dem Speicher-Failover, sind eine SPM-Resynchronisierung und eine
Aktualisierung des logischen Servers sowohl am bevorzugten als auch am sekundären
Standort erforderlich.
–
Führen Sie die Resynchronisierung des SPM-Volume mit der Option
Resync→Volume über die Volumes-GUI von HPE SPM aus.
–
Führen Sie die Aktualisierung des logischen Servers über Matrix OE Visualization
mit der Option Tools→Logical Servers (Logische Server)→Refresh
(Aktualisieren) aus. Aktivieren Sie das Kontrollkästchen Storage Pool Entries
(Speicherpooleinträge), und klicken Sie auf Refresh (Aktualisieren).
Import (Importieren)
Es gibt zwei Typen von Matrix Recovery-Importvorgängen:
•
Site import (Import des Standorts): Erfolgt während der anfänglichen Konfiguration.
•
Single Recovery Group import (Import einer einzelnen Wiederherstellungsgruppe): Dient
nach der erstmaligen Konfiguration zum Importieren neuer Wiederherstellungsgruppen und
zum erneuten Importieren abgewandelter Wiederherstellungsgruppen.
23
HINWEIS: Vorhandene Wiederherstellungsgruppen müssen vor dem erneuten Importieren
gelöscht werden.
•
Nur Wiederherstellungsgruppen, die am exportierenden Standort aktiviert sind, werden in
die Exportdatei aufgenommen.
•
Der Importvorgang von Matrix Recovery Management durchsucht das lokale System nach
Namen logischer Server, die den Namen logischer Server in den zu importierenden
Wiederherstellungsgruppen entsprechen. Wenn Übereinstimmungen gefunden werden,
werden diese logischen Server automatisch den logischen Servern gleichen Namens
zugeordnet. Wenn für den Namen eines importierten logischen Servers keine Entsprechung
gefunden wird, müssen Sie aus der Dropdown-Liste den Namen eines anderen logischen
Servers auswählen, der dem logischen Server aus der Exportdatei zugeordnet werden soll.
Wenn IMPORT_STRATEGIES in der Datei dr.properties auf COPY_LS eingestellt ist,
können Sie die leere Option aus der Dropdown-Liste auswählen. Matrix Recovery
Management erstellt dann einen logischen Server desselben Namens am Remote-Standort.
Weitere Informationen zu dr.properties finden Sie unter dr.properties (Seite 32).
•
Beim Matrix Recovery Management-Importvorgang wird automatisch für jeden IO-Dienst,
der einer zu importierenden Wiederherstellungsgruppe von IO-Diensten angehört, ein
IO-Dienstreplikat erstellt.
HINWEIS:
◦
IO-Dienstreplikate von einem Remote-Standort können nicht mittels eines Matrix
Recovery Management-Importvorgangs importiert werden. Folglich müssen alle
Änderungen an einem IO-Dienst über den bevorzugter Standort vorgenommen werden,
die dann in Form einer neu erstellten Exportdatei am sekundären Standort importiert
werden können.
•
Wenn virtuelle (VM-gehostete) IO-Dienste, die mit einer wiederherstellbaren IO-Vorlage
erstellt wurden, importiert werden sollen, muss der Standort deaktiviert werden, nachdem
die Exportdatei erstellt wurde. Vor dem Import muss ein manuelles Failover der
Speicherreplikationsgruppe am Remote-Standort durchgeführt werden.
•
Sollte eine Deaktivierung am lokalen (bevorzugten) Standort nicht gestattet sein, können
Sie eine nicht wiederherstellbare IO-Vorlage für die Bereitstellung verwenden und den
zugrunde liegenden logischen Server durch DR schützen. Dieser kann dann automatisch
während des Importvorgangs importiert und erstellt werden, ohne dass ein Speicherfailover
erforderlich ist. Weitere Informationen finden Sie unter „DR-Schutz der den IO-Diensten
zugrunde liegenden logischen Server“ (Seite 33).
HINWEIS: Wenn sich in der Matrix Recovery Management-Konfiguration logische
Hyper-V-Server oder IO-Dienste befinden, dann schalten Sie die zur Speicherung logischer
Server oder IO-Dienste verwendete Cluster-Datenträger-Ressource offline, bevor Sie das
Speicherfailover zum Remote-Standort durchführen. Wenn das CSV nicht offline ist, finden
Sie unter „Wiederherstellen eines CSV aus dem Zustand online pending“ (Seite 93)
weitere Informationen zur Vorgehensweise bei der Wiederherstellung.
•
Import des Standorts: Speicherverwaltungsserver-Informationen werden importiert, wenn
am importierenden Standort keine Speicherverwaltungsserver konfiguriert sind. Wenn sich
am importierenden Standort bereits Speicherverwaltungsserver-Informationen befinden:
◦
24
Die physische Standort eines jeden am importierenden Standort konfigurierten
Speicherverwaltungsservers muss mit dem physischen Standort eines
Speicherverwaltungsservers in der Datei exportconfig übereinstimmen.
◦
Der Typ des Speicherverwaltungsservers muss übereinstimmen, wenn der Name
übereinstimmt.
◦
Bei P6000 müssen die Einträge für Benutzername und Portnummer übereinstimmen.
◦
Bei P9000 müssen die Einträge für Benutzername und RAID-Instanz übereinstimmen.
◦
Bei einem 3PAR Store-Speichersystem muss die Kennwortdatei übereinstimmen.
Wenn einer der obigen Einträge zwischen dem exportierenden Standort und dem
importierenden Standort nicht übereinstimmt, schlägt der Importvorgang fehl.
HINWEIS: Um eine 3PAR StoreServ-Remotekopie verwalten zu können, muss die
verschlüsselte Kennwortdatei für Inserv-Speicherserver am lokalen und am Remote-Standort
auf dem CMS an jedem Standort verfügbar sein, und der Name der Kennwortdatei muss
auf dem CMS an jedem Standort gleich sein.
•
Informationen zur Speicherreplikationsgruppe, die den aktivierten Wiederherstellungsgruppen
in der Datei exportconfig zugeordnet ist, werden importiert, sofern sie am Remote-Standort
nicht bereits vorhanden sind.
•
Wiederherstellungsgruppen desselben Namens müssen sich in unterschiedlichen
Wiederherstellungsgruppensätzen befinden, da der Importvorgang andernfalls fehlschlägt.
•
Speicherverwaltungsserver und Speicherreplikationsgruppen, auf die durch die importierten
Wiederherstellungsgruppen nicht verwiesen wird, werden nicht importiert.
•
Wenn die Wiederherstellungsgruppen in der Datei exportconfig am importierenden
Standort bereits vorhanden sind (Wiederherstellungsgruppen mit dem gleichen Namen am
importierenden Standort), werden sie gelöscht und durch die importierten
Wiederherstellungsgruppen ersetzt. Die Speicherverwaltungsgruppen, auf die durch
Wiederherstellungsgruppen verwiesen wird, die gelöscht werden, werden ebenfalls gelöscht.
Import einer einzelnen Wiederherstellungsgruppe
Wenn Sie eine Wiederherstellungsgruppe an einem Matrix Recovery-Standort hinzufügen oder
ändern (bearbeiten) möchten, steht dazu eine Funktion zum Importieren einer einzelnen
Wiederherstellungsgruppe zur Verfügung. Durch Auffüllen dieser Änderungen am anderen
Standort, ohne einen Standort-Importvorgang durchzuführen, lässt sich Zeit einsparen. Es wird
empfohlen, diese Methode zu verwenden, nachdem der erstmalige Standort-Importvorgang
durchgeführt wurde. Stellen Sie sicher, dass die der neuen Wiederherstellungsgruppe zugeordnete
Speicherreplikationsgruppe bereits vorhanden ist; andernfalls müssen Sie sie am DR-Standort
manuell erstellen, bevor Sie den Import durchführen.
Wenn Sie z. B. eine Wiederherstellungsgruppe am lokalen Standort hinzufügen oder ändern
(bearbeiten), können Sie die neue oder geänderte Wiederherstellungsgruppe importieren, um
am Remote-Standort die Peer-Wiederherstellungsgruppe zu erstellen, ohne dass Sie dazu die
gesamte Konfiguration des lokalen Standorts importieren müssen. Das Verfahren am lokalen
Standort ist dasselbe wie das Standort-Exportverfahren. Sie exportieren die Matrix Recovery
Management-Konfiguration über die Registerkarte Sites (Standorte) am lokalen Standort in eine
exportconfig-Datei, und übertragen diese Datei zum Remote-Standort. Am Remote-Standort
navigieren Sie zur Registerkarte „Speicherreplikationsgruppen“ und vergewissern sich, dass die
Speicherreplikationsgruppe bereits vorhanden ist oder erstellen sie manuell. Klicken Sie am
Remote-Standort auf der Registerkarte Recovery Groups (Wiederherstellungsgruppen) auf
import... (Importieren…)→Select import file... (Importdatei auswählen…). Das Fenster Import
Wizard (Importassistent) wird angezeigt. Darin können Sie eine Wiederherstellungsgruppe
auswählen, die aus der Datei exportconfig importiert werden soll. Weitere Informationen zum
Importvorgang für einzelne Wiederherstellungsgruppen finden Sie in der Onlinehilfe von Matrix
Recovery Management.
25
HINWEIS:
•
Wiederherstellungsgruppen können immer nur einzeln importiert werden. Sie müssen für
jede zu importierende Wiederherstellungsgruppe erneut die Optionen import...
(Importieren…)→Select import file... (Importdatei auswählen…) wählen.
•
Wenn eine Wiederherstellungsgruppe in der Datei exportconfig den gleichen Namen
wie eine Wiederherstellungsgruppe am importierenden Standort besitzt, wird sie nicht
importiert. Wenn Sie eine Wiederherstellungsgruppe importieren, die in der Matrix Recovery
Management-Konfiguration bereits vorhanden ist, jedoch geändert wurde, müssen Sie die
Wiederherstellungsgruppe desselben Namens am importierenden Standort löschen, bevor
Sie die abgewandelte Version der Wiederherstellungsgruppe importieren können.
•
Wenn eine Wiederherstellungsgruppe in der Datei exportconfig auf eine
Speicherreplikationsgruppe verweist, die von einer anderen Wiederherstellungsgruppe am
importierenden Standort verwendet wird, dann schlägt der Importvorgang fehl.
Während des erneuten Importierens einer Wiederherstellungsgruppe, die physische IO-Dienste
mit gelöschten VC-gehosteten logischen Servern enthält, werden die physischen logischen
Server am Remote-Standort nicht gelöscht. Dies hat zur Folge, dass in Matrix OE Visualization
verwaiste logische Server erstellt werden. Diese verwaisten logischen Server müssen aus Matrix
OE Visualization gelöscht werden.
HINWEIS: Ein verwaister logischer Server kann nicht erkennen, dass er einem IO-Dienst
angehört. Zum Löschen des verwaisten logischen Servers müssen Sie in dem in Abbildung 4
(Seite 26) dargestellten Textfeld zur Bestätigung YES eingeben. Dieser Bestätigung ist trotz der
Warnmeldung, dass der Server von HPE Matrix OE Infrastructure Orchestrationverwaltet
wird, erforderlich.
Abbildung 4 Verwaister logischer Server
Importieren von Wiederherstellungsgruppen mit physischen IO-Diensten, physischen
logischen Servern und virtuellen logischen Servern mit RAW-Datenträgern
Nachdem eine Wiederherstellungsgruppe mit physischen IO-Diensten, physischen logischen
Servern oder virtuellen logischen Servern mit physischen Volumen am Wiederherstellungsstandort
erfolgreich importiert wurden, wird als Status auf der Registerkarte Jobs (Aufträge) entweder
Completed oder Completed – Storage Configuration Required angezeigt. Als
Ergebnis eines Importauftrags wird ein neues IO-Dienstreplikat oder ein neuer logischer Server
erstellt oder ein neuer physischer Speicher hinzugefügt.
26
Importauftragsstatus
Nachdem ein Importvorgang durchgeführt wurde, zeigt die Registerkarte Jobs (Aufträge) einen
der folgenden Stati an:
•
Importauftragsstatus Completed
•
Importauftragsstatus Completed — Storage Configuration Required
Importauftragsstatus Completed
Dieser Status wird angezeigt, wenn die Speicherkonfiguration am bevorzugten Standort mit
einem Speicherpooleintrag (SPE), mit einer SPM-Speichervorlage mit Remotekopie-Anforderungen
und mit einem fehlerfreien SPM-Auftrag durchgeführt wird.
Unter diesen Bedingungen wird die erforderliche Speicherkonfiguration automatisch mit SPM
vorgenommen, wobei das SPE-Kontrollkästchen Disaster Recovery Enabled (Disaster
Recovery-fähig) und das Volume-Kontrollkästchen Disaster Recovery Ready (Disaster
Recovery-bereit) automatisch aktiviert werden.
Die importierten Wiederherstellungsgruppen befinden sich auf der Registerkarte Recovery
Groups (Wiederherstellungsgruppen) im Maintenance Mode (Wartungsmodus), wenn für alle
logischen Server in der Wiederherstellungsgruppe mit Speicherpooleinträgen das Flag Disaster
Recovery Enabled (Disaster Recovery-fähig) und für alle ihre Volumes das Flag Disaster
Recovery Ready (Disaster Recovery-bereit) aktiviert ist.
Importauftragsstatus Completed - Storage Configuration Required
Dieser Status wird unter den folgenden Bedingungen bei der Speicherkonfiguration am
bevorzugten Standort angezeigt:
•
Bei Verwendung eines SAN-Speichereintrags des Typs SPE
Disaster Recovery Enabled (Disaster Recovery-fähig) ist aktiviert, aber das Flag Disaster
Recovery Ready (Disaster Recovery-bereit) ist für Volumes nicht aktiviert.
•
Bei einem SAN-Katalog-Speichereintrag vom Typ SPE unter Verwendung einer SPM-Vorlage
ohne Remotekopie-Anforderungen
Disaster Recovery Enabled (Disaster Recovery-fähig) ist aktiviert und für Volumes ist das
Flag Disaster Recovery Ready (Disaster Recovery-bereit) aktiviert.
•
Bei einem SAN-Katalog-Speichereintrag-SPE mit SPM unter Verwendung einer SPM-Vorlage
mit Remotekopie-Anforderungen, aber fehlerhaftem SPM-Auftrag am
Wiederherstellungsstandort
Disaster Recovery Enabled (Disaster Recovery-fähig) ist aktiviert, aber das Flag Disaster
Recovery Ready (Disaster Recovery-bereit) ist für Volumes nicht aktiviert. Außerdem wird
im SPE ein Fehler (rotes X) angezeigt.
Auf der Registerkarte Recovery Groups (Wiederherstellungsgruppen) lautet der Zustand der
importierten Wiederherstellungsgruppen Maintenance Mode – Storage Configuration
Required.
Eine Wiederherstellungsgruppe befindet sich nach einem Importauftrag im Wartungsmodus,
wenn für die SPEs aller seiner logischen Server das Flag Disaster Recovery Enabled (Disaster
Recovery-fähig) aktiviert ist und für mindestens ein Volume eines SPE das Flag Disaster
Recovery Ready (Disaster Recovery-bereit) nicht aktiviert ist.
Überprüfen Sie unter den oben dargelegten Bedingungen die Registerkarte Jobs (Aufträge) in
Matrix Recovery Management auf IO-Dienste oder logische Server, die eine Speicherkonfiguration
benötigen.
27
Verfahren Sie für jedes Mitglied der Wiederherstellungsgruppe, für das eine Speicherkonfiguration
erforderlich ist, wie folgt:
•
Bei SAN-Speichereintrag und SAN-Katalog-Speichereintrag des Typs SPE unter
Verwendung einer SPM-Vorlage ohne Remotekopie-Anforderungen
1. Rufen Sie die Speicherpooleinträge des Wiederherstellungsgruppenmitglieds auf, und
konfigurieren Sie die Volumes manuell.
2. Nachdem jedes Volume konfiguriert wurde, aktivieren Sie das Volume-Kontrollkästchen
Disaster Recovery Ready (Disaster Recovery-fähig).
3. Vergewissern Sie sich, dass die voranstehenden Schritte durchgeführt wurden, bevor
Sie den Speicherpooleintrag auf das Flag Disaster Recovery Enabled (Disaster
Recovery-aktiviert) überprüfen.
•
Für SAN-Katalog-Speichereintrag des Typs SPE unter Verwendung einer SPM-Vorlage
mit Remotekopie-Anforderungen
•
Identifizieren Sie den Fehler.
1. Verfahren Sie bei einem SPM-bedingten Fehler wie folgt:
a. Beheben Sie die SPM-Konfigurationsprobleme.
b. Aktivieren Sie den Speicherdienst mit SPM.
c. Verwenden Sie zum Aktualisieren der Speicherpooleinträge Matrix OE
Visualization→Tools→Logical Server (Logischer Server)→Activate
(Aktivieren), wählen Sie Storage Pool Entries (Speicherpooleinträge) aus,
und klicken Sie auf Refresh (Aktualisieren).
2.
•
Wenn SPM das zu importierende Volume nicht finden kann, korrigieren Sie die
Konfiguration von Remote Copy Group (Remotekopie-Gruppe), und wiederholen
Sie den Importvorgang.
Deaktivieren des Wartungsmodus
Nachdem die Speicherkonfiguration für alle Mitglieder der Wiederholungsgruppe durchgeführt
wurde, klicken Sie auf Refresh (Aktualisieren), um den Status der Speicherkonfiguration
der Wiederherstellungsgruppe(n) auf der Registerkarte Recovery Groups
(Wiederholungsgruppen) zu aktualisieren. Wenn sich der Status der
Wiederherstellungsgruppe von Maintenance Mode – Storage Configuration
Required in Maintenance Mode ändert, klicken Sie auf Disable Maintenance Mode
(Wartungsmodus deaktivieren), um den Wartungsmodus für die betreffende
Wiederherstellungsgruppe zu deaktivieren. Weitere Informationen finden Sie unter „Aktivieren
und Deaktivieren des Wartungsmodus“ (Seite 38).
28
HINWEIS:
•
Es ist nicht erforderlich, die Flags Disaster Recovery Enabled (Disaster Recovery-fähig)
und Disaster Recovery Ready (Disaster Recovery-bereit) in den Speicherpooleinträgen
am bevorzugten Standort auszuwählen.
•
Wenn für alle SPEs aller logischen Server einer Wiederherstellungsgruppe das Flag Disaster
Recovery Enabled (Disaster Recovery-fähig) nicht aktiviert ist, ignoriert Matrix Recovery
Management den Status des Flag Disaster Recovery Ready (Disaster Recovery-bereit)
der SPE-Volumes. Die Wiederherstellungsgruppe befindet sich immer im Wartungsmodus.
•
Ab Version 7.5 ist nach einer Aktualisierung von einer Version niedriger als 7.5 das neue
Flag Disaster Recovery Enabled (Disaster Recovery-fähig) für alle bereits vorhanden SPEs
nicht aktiviert.
•
Nachdem ein Importauftrag durchgeführt wurde, wird empfohlen, anhand eines DR-Probelaufs
zu überprüfen, ob alle importierten logischen Servern und IO-Dienste ordnungsgemäß
aktiviert werden.
•
Der Wartungsmodus kann erst deaktiviert werden, nachdem für alle Speicherpooleinträge
aller logischen Server oder IO-Dienste innerhalb einer Wiederherstellungsgruppe Disaster
Recovery Enabled (Disaster Recovery-fähig) und für alle ihre zugehörigen Volumes Disaster
Recovery Ready (Disaster Recovery-bereit) aktiviert wurde.
•
Nachdem die Speicherkonfiguration durchgeführt wurde, klicken Sie auf Refresh
(Aktualisieren), um den Status der Speicherkonfiguration der Wiederherstellungsgruppe(n)
auf der Registerkarte Recovery Groups (Wiederherstellungsgruppen) zu aktualisieren.
•
IO bietet Informationen zur Speicherkonfiguration innerhalb des Protokolls der
IO-Replikatserstellung auf der Registerkarte IO Requests (IO-Anforderungen) und durch
automatische E-Mail-Benachrichtigung, sofern diese in IO konfiguriert ist.
Importieren von Wiederherstellungsgruppen mit virtuellen IO-Diensten
Im Gegensatz zu physischen IO-Diensten oder physischen logischen Servern und virtuellen
logischen Servern erfordern virtuelle IO-Dienste vor dem Importvorgang ein Speicherfailover.
Verfahren Sie beim Importieren von Wiederherstellungsgruppen, die virtuelle IO-Dienste enthalten,
wie folgt, nachdem die Matrix Recovery Management-Konfigurationsdatei am bevorzugten
Standort exportiert wurde:
1. Deaktivieren Sie den bevorzugten Standort.
2. Führen Sie ein manuelles Failover des Speichers am Wiederherstellungsstandort durch.
Speicherfailover zum Remote-Standort durchführen. Wenn CSV nicht offline ist, finden Sie
unter „Wiederherstellen eines CSV aus dem Zustand online pending“ (Seite 93) die
Vorgehensweise zur Wiederherstellung.
3.
Stellen Sie durch erneutes Scannen des Speichers mit VM-Host-Verwaltungstools, wie z. B.
VMware Virtual Center oder Microsoft Hyper-V Management Console, sicher, dass der
VM-Host den Speicher nach dem Failover erkennt.
Der replizierte Datenträger auf dem Hyper-V-Host am Remote-Standort muss mit dem
gleichen Laufwerksbuchstaben konfiguriert sein, der dem Datenträger am lokalen Standort
zugewiesen ist, von dem er repliziert wurde.
•
Im Falle eines Cluster-Freigabe-Volumes muss der replizierte Datenträger auf dem
Hyper-V-Host am Remote-Standort mit dem gleichen Volume-Pfad konfiguriert sein,
der dem Datenträger am lokalen Standort zugewiesen ist, von dem er repliziert wurde.
29
•
4.
5.
6.
7.
8.
Im Falle eines Cluster-Freigabe-Volumes oder von freigegebenen Cluster-Datenträgern
muss der replizierte Datenträger auf dem Hyper-V-Host am Remote-Standort mit dem
gleichen Cluster-Ressourcennamen konfiguriert sein, der dem Datenträger am lokalen
Standort zugewiesen ist, von dem er repliziert wurde.
Aktualisieren Sie Virtual Machine-Ressourcen über den Vorgang Refresh (Aktualisieren)
für logische Server unter Tools auf der Registerkarte Visualization (Visualisierung) in Matrix
OE Visualization.
Importieren Sie eine Site (Standort) oder eine Recovery Group (Wiederherstellungsgruppe).
Führen Sie einen Probelauf durch, indem Sie IO-Dienstreplikate aktivieren und deaktivieren.
Deaktivieren Sie den Wartungsmodus.
Aktivieren Sie den bevorzugten Standort.
DR-Schutz für IO-Dienste
Matrix Infrastructure Orchestration (IO) bietet eine schnelle Bereitstellung und Zweckänderung
von Infrastrukturdiensten aus gemeinsam genutzten Ressourcenpools über ein Self-Service-Portal.
IO ermöglicht auf Basis von ausgereiften Vorlagen den Entwurf, die Bereitstellung und den
laufenden Betrieb von Infrastrukturdiensten auf mehreren Knoten und Schichten.
Ab Matrix Operating Environment 7.1 wird IO in Matrix Recovery Management integriert, um
DR-Schutz für IO-Dienste zu bieten. IO-Dienste können unter den folgenden Bedingungen in
einer Matrix Recovery Management-Konfiguration DR-geschützt werden:
•
Sie werden über eine IO-Vorlage bereitgestellt.
•
Sie müssen mit einem Speicher verknüpft sein, der von Matrix Recovery Management
unterstützt wird. Dazu zählt auch benutzerdefinierter Speicher. Weitere Informationen finden
Sie unter „Erstellen und Installieren eines benutzerdefinierten Speicheradapters“.
IO-Dienste, die in einer Matrix Recovery Management-Konfiguration DR-geschützt werden
können, werden als wiederherstellbare IO-Dienste bezeichnet.
Wiederherstellbare IO-Dienste können beim Konfigurieren von Wiederherstellungsgruppen für
IO-Dienste aus einem Dropdown-Menü in Matrix Recovery Management ausgewählt werden.
Nachdem die Wiederherstellungsgruppen der IO-Dienste konfiguriert wurden, sind die darin
enthaltenen IO-Dienste DR-geschützt. Sie können OO-Arbeitsabläufe so konfigurieren, dass
Systemadministratoren automatisch per E-Mail benachrichtigt werden, wenn an DR-geschützten
IO-Diensten IO-Vorgänge durchgeführt werden, für die Konfigurationsänderungen in Matrix
Recovery Management erforderlich sind (z. B. Dienst erstellen, Dienst löschen, Datenträger
hinzufügen, Server hinzufügen, Lease ändern).
Wenn Matrix Recovery Management und IO auf demselben CMS installiert sind und
wiederherstellbare IO-Dienste konfiguriert wurden, können Sie Wiederherstellungsgruppen
DR-geschützter IO-Dienste als Teil des erstmaligen Matrix Recovery
Management-Konfigurationsvorgangs erstellen, oder Sie können Wiederherstellungsgruppen
DR-geschützter IO-Dienste zu einer bestehenden Matrix Recovery Management-Konfiguration
hinzufügen. Das Konfigurationsverfahren ist dasselbe.
Überblick über die Konfiguration von DR-geschützten IO-Diensten
Wiederherstellbare IO-Dienste werden folgendermaßen konfiguriert:
1. Konfigurieren Sie die IO-Eigenschaften auf dem CMS am lokalen und am Remote-Standort.
Weitere Informationen finden Sie unter „Konfigurieren von IO-Eigenschaften“.
2. Konfigurieren Sie die OO-Arbeitsabläufe. Weitere Informationen finden Sie unter
„Konfigurieren des OO-Arbeitsablaufs für optionale E-Mail-Benachrichtigungen“.
3. Konfigurieren Sie das Netzwerk für DR-geschützte IO-Dienste. Weitere Informationen finden
Sie unter „Netzwerkkonfiguration“.
30
4.
5.
Erstellen Sie Vorlagen für wiederherstellbare IO-Dienste. Weitere Informationen finden Sie
imMatrix Operating Environment Infrastructure Orchestration Benutzerhandbuch in der
Hewlett Packard Enterprise Enterprise-Informationsbibliothek.
Konfigurieren Sie wiederherstellbare IO-Dienste mit Hilfe von IO. Weitere Informationen
finden Sie imMatrix Operating Environment Infrastructure Orchestration Benutzerhandbuch
in der Hewlett Packard Enterprise Enterprise-Informationsbibliothek.
HINWEIS:
6.
7.
8.
•
Wenn Sie Matrix Recovery Management für den DR-Schutz VMware ESX-basierter
IO-Dienste verwenden, die über eine IO-Vorlage unter Verwendung einer ICVirt-Vorlage
oder einer VM-Vorlage auf dem vCenter-Server am lokalen Standort bereitgestellt
werden, muss eine ICVirt- oder VM-Vorlage desselben Namens am Remote-Standort
verfügbar sein, bevor Sie einen Matrix Recovery Management-Importvorgang zum
Importieren der Standortkonfiguration durchführen können. Wenn keine ICVirt- oder
VM-Vorlage desselben Namens am Remote-Standort vorhanden ist, werden keine
DR-geschützten IO-Dienste importiert.
•
Wenn Sie Matrix Recovery Management für den DR-Schutz von Microsoft
Hyper-V-basierten IO-Diensten verwenden, die über eine IO-Vorlage unter Verwendung
einer ICVirt-Vorlage auf dem CMS am lokalen Standort bereitgestellt werden, muss
eine ICVirt-Vorlage desselben Namens am Remote-Standort verfügbar sein, bevor Sie
einen Matrix Recovery Management-Importvorgang zum Importieren der
Standortkonfiguration durchführen können. Wenn keine ICVirt-Vorlage desselben
Namens am Remote-Standort vorhanden ist, werden keine DR-geschützten IO-Dienste
importiert.
•
Wenn Sie Matrix Recovery Management für den DR-Schutz von IO-Diensten verwenden,
die über eine IO-Vorlage unter Verwendung einer ICVirt-Vorlage, einer VM-Vorlage
oder einer SCVMM-Vorlage bereitgestellt werden, darf die Vorlage nur einen einzelnen
Datenträger umfassen.
•
Bei Verwendung von Matrix Recovery Management für den DR-Schutz von physischen
IO-Services, die über eine IO-Vorlage mit automatischer Softwarebereitstellung
bereitgestellt werden, muss am Remote-Standort ein Bereitstellungsserver desselben
Typs verfügbar sein, der am lokalen Standort verwendet wird, bevor Sie einen
Importvorgang in Matrix Recovery Management durchführen. Sollten am
Remote-Standort nicht derselbe Typ des Bereitstellungsservers oder der Software
verfügbar sein, müssen DR-geschützte IO-Dienste importiert werden.
Fügen Sie die IO-Dienste zu Matrix Recovery Management-Wiederherstellungsgruppen
hinzu. Die hinzugefügten IO-Dienste müssen im Feld Available Services (Verfügbare
Dienste) auf der Registerkarte Recovery Groups (Wiederherstellungsgruppen) vorhanden
sein, wenn Sie als Wiederherstellungsgruppe New (Neu) auswählen.
Exportieren Sie die Standortkonfiguration am lokalen Standort. Weitere Informationen finden
Importieren Sie die Standortkonfiguration am Remote-Standort. Weitere Informationen finden
Konfigurieren von IO-Eigenschaften
Um den DR-Schutz für IO-Dienste zu aktivieren, bearbeiten Sie die Dateien in den Verzeichnissen
C:\Programme Files\HP\Matrix infrastructure orchestration\conf\
hpio.properties und C:\Programme\HP\Insight Recovery\conf\dr.properties.
hpio.properties
•
Aktivieren Sie den DR-Schutz für IO-Dienste: enable.dr.protection = true
31
•
Für den DR-Schutz in einer Mehrinstanzenumgebung müssen alle IO-Dienste über alle
Organisationen hinweg eindeutige Namen haben. Setzen Sie diese Einschränkung durch,
indem Sie die Eigenschaft
force.unique.service.names.across.organizations=true einstellen.
•
Geben Sie den Datenspeicher an, der für die Bereitstellung DR-geschützter virtueller
IO-Dienste verwendet wird:
HINWEIS: DR-Schutz für physische IO-Dienste wird in einer Mehrinstanzenumgebung
nicht unterstützt.
◦
Geben Sie am lokalen Standort die Volumes an, die für DR-geschützte IO-Dienste
verwendet werden sollen, z. B.:
volume.dr.list = /vmfs/volumes/ds_1;C:\\ClusterStorage\\Volume3;C:\\ClusterStorage\\Volume4
◦
Geben Sie am Remote-Standort die Volumes an, die für IO-Dienstreplikate verwendet
werden sollen, z. B.:
volume.dr.replica.list = /vmfs/volumes/ds_1;C:\\ClusterStorage\\Volume3;C:\\ClusterStorage\\Volume4
HINWEIS: Wenn in volume.dr.list ein Datenspeicher angegeben wird, werden die
DR-geschützten virtuellen IO-Dienste im angegebenen Datenspeicher bereitgestellt.
Wenn in volume.dr.list mehrere Datenspeicher angegeben werden, werden die
DR-geschützten virtuellen IO-Dienste in dem Datenspeicher in volume.dr.list
bereitgestellt, der sowohl für den Serverpool verfügbar ist als auch den meisten freien
Speicherplatz aufweist.
Wenn in volume.dr.list mehrere Datenspeicher angegeben sind und in der IO-Vorlage
einer der Datenspeicher in volume.dr.list angegeben wird, dann werden die
DR-geschützten virtuellen IO-Dienste in dem Datenspeicher bereitgestellt, der in der
IO-Vorlage angegeben wird.
•
Stellen Sie die Eigenschaft static.ip.replica.list so ein, dass am Remote-Standort
statische IP-Adressen für IO-Dienstreplikate reserviert werden. Der Replikats-IP-Bereich
kann ein Unterbereich des IP-Adressbereichs auf IO-Netzwerk-UIs sein. Der in der
Eigenschaftsdatei konfigurierte, für Replikatslisten reservierte IP-Adressbereich kann nicht
verwendet werden, wenn lokale Dienste am DR-Standort erstellt werden. Wenn z. B. die
am Remote-Standort in IO konfigurierten Netzwerke subnetX und subnetY sind, dann können
ein oder mehrere dieser IP-Adressen für Replikatsdienste reserviert werden: Reservieren
Sie z. B. einen neuen IP-Adressbereich für DR-geschützte Server, indem Sie in der Datei
hpio.properties wie folgt die Eigenschaft festlegen:
static.ip.replica.list =
subnetX:192.16.0.10;subnetX:192.16.0.15-192.16.0.20;subnetY:192.16.0.30-192.16.0.40;
subnetX:1024:3143::c425:b0e1:e1c0-1024::3143:c425:b0e1:e1cf;
dr.properties
32
•
Geben Sie im CMS am lokalen Standort und am Remote-Standort in der Datei
dr.properties einen Namen an, durch den der zugehörige Standort identifiziert wird, an
dem IO ausgeführt wird, so z. B. local.site = siteA am lokalen Standort und
local.site = siteB am Remote-Standort. Der Name in der Datei dr.properties
kann anders lauten als der in Matrix Recovery Management konfigurierte Standortname.
•
Wenn Domänenname und Benutzername des Diensteigentümers am lokalen und am
Remote-Standort nicht gleich lauten, dann stellen Sie die Eigenschaft
owner.username.site_a>.owner_domain_a\\username_a> =
owner.username.site_b>.owner_domain_b\\username_b> so ein, dass die
Netzwerkzuordnung zwischen Domänenname und Benutzername des Diensteigentümers
angegeben wird. Wenn z. B. der für IO konfigurierte Domänenname und Benutzername des
Diensteigentümers am lokalen und am Remote-Standort domainA\userA und domainB\userB
lauten:
owner.username.siteA.domainA\\userA = owner.username.siteB.domainB\\userB
Richten Sie weitere Eigentümer-Benutzernamen-Abgleiche durch Hinzufügen zur Datei
dr.properties ein. Beispiel:
owner.username.siteA.ARCMS9671v\\Administrator = owner.username.siteB.ARCMS9771V\\Administrator
owner.username.siteA.ARCMS9671v\\svcuser = owner.username.siteB.ARCMS9771V\\svcuser
•
Wenn die Domänennamen am lokalen und am Remote-Standort nicht gleich lauten, dann
stellen Sie die Eigenschaft owner.domain.site_a>.owner_domain_a> =
owner.domain.site_b>.owner_domain_b> so ein, dass die Netzwerkzuordnung
zwischen den Domänennamen angegeben wird. Wenn z. B. die für IO konfigurierten
Domänennamen am lokalen und am Remote-Standort domainA und domainB lauten:
owner.domain.siteA.domainA = owner.domain.siteB.domainB
•
Ordnen Sie den Organisationsadministrator in der Datei dr.properties zu, indem Sie
die Eigenschaft owner.username.<site_a>.<domain_a>\\<org_admin> =
owner.username.<site_b>.<domain_b>\\<org_admin> festlegen. Zum Beispiel:
Wenn der Organisationsadministrator für IO am lokalen und Remote-Standort userA ist:
owner.username.siteA.domainA\\userA = owner.username.siteB.domainB\\userA
•
Wenn die HPIO-Eigenschaft federated.io in der Datei hpio.props auf true gesetzt
ist, muss die Datei dr.props einen entsprechenden Zuordnungseintrag enthalten:
federated.siteA.<primary_CMS_siteA> = federated.siteB.<primary_CMS_siteB>
Zum Beispiel: Wenn der CMS-Name am lokalen Standort hostA.test.net und am
Remote-Standort hostB.test.net ist, lautet die Zuordnungszeile:
federated.siteA.hostA.test.net = federated.siteB.hostB.test.net
HINWEIS:
◦
Verwenden Sie diese Zuordnung immer dann, wenn federated.io auf true gesetzt
wird, selbst wenn keine Föderierung verwendet wird.
◦
Matrix Recovery Management-Zuordnungen in der Datei dr.properties dürfen bei
der Angabe von Eigenschaftswerten (wie z. B. test.user) keine Punkte enthalten.
Die Verwendung von „.“ in einer Zuordnung hat zur Folge, dass IO fehlerhaft zuordnet
und Importvorgänge am sekundären Standort fehlschlagen.
Weitere Informationen finden Sie imMatrix Operating Environment Infrastructure Orchestration
Benutzerhandbuch in der Hewlett Packard Enterprise Enterprise-Informationsbibliothek.
DR-Schutz der den IO-Diensten zugrunde liegenden logischen Server
Unter den folgenden Bedingungen ist es ratsam, die über eine IO-Vorlage erstellten zugrunde
liegenden logischen Server mit DR-Schutz zu belegen:
•
Wenn ein IO-Dienst über eine nicht wiederherstellbare IO-Vorlage erstellt wird, für den
möglicherweise DR-Schutz benötigt wird.
•
Wenn virtuelle IO-Dienste konfiguriert werden, sind selbst kurze Ausfallzeiten zum
Konfigurieren des Remote-Standorts nicht zulässig. In diesem Fall können Sie eine nicht
wiederherstellbare IO-Vorlage erstellen und den zugrunde liegenden logischen Server unter
DR-Schutz stellen.
•
Wenn Sie zum DR-Schutz von IO-Diensten, die über eine IO-Vorlage unter Verwendung
einer ICVirt-, VM- oder SCVMM-Vorlage mit mehr als einem Datenträger bereitgestellt
werden, Matrix Recovery Management verwenden.
33
HINWEIS:
•
Bei der Verwendung einer nicht wiederherstellbaren IO-Vorlage unterstützt IO keine
SPM-Vorlagen mit Remotekopie-Anforderungen.
•
Für nicht wiederherstellbare IO-Vorlagen werden keine Datenspeicher verwendet, die in der
Eigenschaft dr.volumes.list der Datei hpio.properties aufgelistet werden. Wenn
Sie einen oder mehrere Datenspeicher zur Nutzung durch nicht wiederherstellbare
IO-Vorlagen reservieren möchten, können Sie die übrigen Datenspeicher zu
volumes.exclusion.list innerhalb der gleichen Eigenschaftsdatei hinzufügen. Anders
ausgedrückt fügen Sie die Volumes, die in dr.volumes.list nicht aufgelistet werden und
von den neuen IO-Diensten benötigt werden, zu volumes.exclusion.list hinzu. Starten
Sie den IO-Dienst nach der Aktualisierung von volumes.exclusion.list neu. Sie können
für virtuelle IO-Dienste optional die gewünschten Datenspeicher in der IO-Vorlage angeben,
indem Sie in der IO-Vorlage auf Volume doppelklicken und wie unter Abbildung 5 (Seite 34)
dargestellt eine Eingabe im Feld „Storage Volume Name(s)“ (Speichervolume-Name)
vornehmen.
Abbildung 5 Speichervolume-Namen
•
Wählen Sie nicht das Flag Disaster Ready Enabled (Disaster Ready-fähig) in den SPEs
logischer Server für einen IO-Dienst, der mit einer nicht wiederherstellbaren IO-Vorlage
erstellt wurde.
•
Am Remote-Standort müssen keine IO-Dienste installiert sein, wenn die zugrunde liegenden
logischen Server geschützt werden.
Konfigurieren des OO-Arbeitsablaufs für optionale E-Mail-Benachrichtigungen
Sie können OO-Arbeitsabläufe so konfigurieren, dass Systemadministratoren automatisch per
E-Mail benachrichtigt werden, wenn an DR-geschützten IO-Diensten IO-Vorgänge durchgeführt
werden, für die Konfigurationsänderungen in Matrix Recovery Management erforderlich sind
(z. B. Dienst erstellen, Dienst löschen, Datenträger hinzufügen, Server hinzufügen, Lease ändern).
IR stellt die Dateien IRWorkflow.zip und Send DR Config Email.xsl bereit, um die
automatische E-Mail-Benachrichtigung zu aktivieren. Sie finden diese beiden Dateien im Ordner
C:\Program Files\HP\Insight Recovery\conf\OO\repo auf dem CMS. Die Datei
IRWorkflow.zip ist die OO-Repository-Export-Zipdatei, die den IR-Arbeitsablauf und die neue
OO-Systemeigenschaft mit dem Namen HpioDrServiceActionRecipients enthält. Die
34
Datei Send DR Config Email.xsl wird vom IR-Arbeitsablauf verwendet, um den Text der
DR-E-Mail-Benachrichtigung zu erstellen.
1. Importieren Sie unter Verwendung von OO Studio den Arbeitsablauf aus der Datei
IRWorkflow.zip auf den CMS am lokalen Standort und am Remote-Standort. Der
Arbeitsablauf wird als DR Global Service End Action im Ordner Library/
Hewlett-Packard/Infrastructure orchestration/Service Actions/DR im
OO-Repository importiert.
2. Kopieren Sie die Datei Send DR Config Email.xsl in das Verzeichnis C:\Program
Files\HP\Matrix infrastructure orchestration\conf\OO auf dem CMS.
3. Konfigurieren Sie OO zum Einrichten der E-Mail-Benachrichtigung. Informationen zum
Einrichten von E-Mail-Benachrichtigungen finden Sie imMatrix Operating Environment
Infrastructure Orchestration Benutzerhandbuch in der Hewlett Packard Enterprise
4. Bearbeiten Sie die OO-Systemeigenschaft HpioDrServiceActionRecipients so, dass
die Empfänger angegeben werden, die E-Mail-Benachrichtigungen über Änderungen an
DR-geschützten Diensten erhalten sollen.
5. Ändern Sie die folgende Eigenschaft in der Datei C:\Program Files\HP\Matrix
infrastructure orchestration\conf\hpio.properties, damit diese auf den
IR-Arbeitsablauf verweist:
oo.global.service.end.action.path = Service Actions/DR/DR Global
Service End Action
6.
Starten Sie Matrix Infrastructure Orchestration neu.
Netzwerkkonfiguration
Auf folgende Weise wird ermöglicht, dass IO-Dienste am bevorzugten Standort und
IO-Dienstreplikate am sekundären Standort dieselben IP-Adressen verwenden, wenn sich das
Subnetz über den lokalen und den Remote-Standort erstreckt:
•
Der lokale und der Remote-Standort müssen den gleichen statischen IP-Adressbereich
definieren. Der IO-Administrator muss in der Datei hpio.properties eine
IP-Ausschlussliste angeben, um IP-Adresskonflikte zu vermeiden. Diese IP-Adressen werden
ausschließlich für IO-Dienstreplikate reserviert und können von keinem anderen IO-Dienst
verwendet werden.
Wenn das Subnetz sich nicht über den lokalen und den Remote-Standort erstreckt, können dem
IO-Dienst am bevorzugten Standort und den IO-Dienstreplikaten am sekundären spezifische
IP-Adressen für den jeweiligen Standort zugewiesen werden.
HINWEIS: Matrix Recovery Management führt während eines Failovers keine
DNS-Aktualisierungen oder Aktualisierung der IP-Konfiguration logischer Server durch, die mit
IO-Diensten verknüpft sind. Ihr Netzwerkadministrator ist dafür verantwortlich, durch Vornahme
der erforderlichen Änderungen die Verfügbarkeit der Netzwerkdienste sicherzustellen, wenn Sie
einen logischen Server zur Verwendung einer anderen IP-Adresse oder eines anderen Subnetzes
an jedem Standort in der Matrix Recovery Management-Konfiguration konfigurieren. Matrix
Recovery Management passt die IP-Adresse der NIC somit nicht an die des Betriebssystems
an. Sie müssen die IP-Adresse des Betriebssystems manuell anpassen. Wenn als IP-Adresse
der VM am bevorzugten Standort beispielsweise 10.10.10.1 konfiguriert ist, die Subnetzmaske
des sekundären Standorts jedoch 12.12.12.0 lautet, weist Matrix IO dem Dienstreplikat die
IP-Adresse 12.12.12.X zu. Wenn aber das Betriebssystem gestartet wird, müssen Sie als
IP-Adresse der NIC manuell 12.12.12.X konfigurieren, da die IP-Adresse am primären Standort
weiterhin 10.10.10.X lautet.
35
3 Testen und Failover-Vorgänge
In diesem Kapitel werden das Testen von Wiederherstellungsgruppen, geplante Failovers und
nicht geplante Failovers mittels der Vorgänge Activate (Aktivieren) und Deactivate (Deaktivieren)
in Matrix Recovery Management beschrieben.
Testen von Wiederherstellungsgruppen
Wiederherstellungsgruppen können auf zwei Arten getestet werden:
•
Verwenden des Wartungsmodus zum Testen einzelner logischer Server in einer bestimmten
Wiederherstellungsgruppe.
HINWEIS: Wenn Wiederherstellungsgruppen mit VC-gehosteten logischen Servern am
Remote-Standort importiert werden, müssen die logischen Server zuerst mit Matrix OE
Visualization aktiviert und dann deaktiviert werden, damit der Wartungsmodus in Matrix
Recovery Management deaktiviert werden kann.
•
Durchführen eines geplanten Failovers zum Testen aller Wiederherstellungsgruppen. Unter
„Geplantes Failover“ (Seite 39) finden Sie weitere Informationen.
Dieser Abschnitt befasst sich mit dem Testen einzelner Wiederherstellungsgruppen im
Wartungsmodus.
Sie können eine Wiederherstellungsgruppe für Testzwecke manuell in den Wartungsmodus
versetzen und dann die deaktivierten logischen Server oder inaktiven Dienste der betreffenden
Wiederherstellungsgruppe mit Matrix Operating Environment aktivieren. Voraussetzung dafür
ist, dass sich die Speicherreplikationsgruppe für die Wiederherstellungsgruppe am getesteten
Standort im RW-Modus befindet.
Im Wartungsmodus wird Matrix Recovery Management vorübergehend an der Verwaltung von
DR-geschützten logischen Servern oder DR-geschützten IO-Diensten gehindert.
Am Remote-Standort werden die logischen Server, die von Matrix Recovery Management
verwaltet werden, als logische Wiederherstellungsserver bezeichnet. Normalerweise kann ein
logischer Wiederherstellungsserver nur durch Aufruf des Vorgangs Activate (Aktivieren) über
die Matrix Recovery Management-Benutzeroberfläche am Remote-Standort aktiviert werden.
So verwenden Sie den Wartungsmodus zum Testen von Wiederherstellungsgruppen oder
logischen Servern:
1. Versetzen Sie die Wiederherstellungsgruppen an dem lokalen Standort, wo sie erstmalig
konfiguriert wurden, in den Wartungsmodus. Fahren Sie die logischen Server in der
Wiederherstellungsgruppe mit dem Vorgang Logical Servers Deactivate (Logische Server
deaktivieren) im Menü Tools auf der Registerkarte Visualization (Visualisierung) in der
Matrix Operating Environment ordnungsgemäß herunter. Verwenden Sie für IO-Dienste den
IO-Dienstvorgang Deactivate Servers (Server deaktivieren) im Matrix Infrastructure-Dienst,
um die IO-Dienste in der Wiederherstellungsgruppe herunterzufahren.
Speicherfailover zum Remote-Standort durchführen. Wenn das CSV nicht offline ist, vgl.
„Wiederherstellen eines CSV aus dem Zustand online pending“ (Seite 93) für die
2.
36
Melden Sie sich an dem Remote-Standort an, an dem der Importvorgang durchgeführt
wurde, und führen Sie mittels angemessener Speicherverwaltungstools (wie z. B. P6000
Continuous Access Software) ein Failover des mit der Wiederherstellungsgruppe am
Remote-Standort verknüpften Speichers durch.
Testen und Failover-Vorgänge
3.
Wenn sich in der Speicherreplikationsgruppe logische Server und IO-Dienste befinden, die
während des Tests auf VM-Hosts aktiviert werden:
a. Scannen Sie den Speicher erneut mit VM-Host-Verwaltungstools, wie z. B. VMware
Virtual Center, um sicherzustellen, dass der VM-Host den Speicher nach dem Failover
erkennt.
b. Aktualisieren Sie Virtual Machine-Ressourcen mit dem Vorgang Logical Servers
Refresh (Logische Server aktualisieren) im Menü Tools auf der Registerkarte
Visualization (Visualisierung) in Matrix OE Visualization.
4.
Versetzen Sie die Wiederherstellungsgruppe am Remote-Standort mit der Schaltfläche
Enable Maintenance Mode (Wartungsmodus aktivieren) auf der Registerkarte Recovery
Groups (Wartungsgruppen) in Matrix Recovery Management in den Wartungsmodus.
Aktivieren Sie bei logischen Servern mit dem Vorgang Logical Servers Activate (Logische
Server aktivieren) im Menü Tools auf der Registerkarte Visualization (Visualisierung) in
Matrix OE Visualization die logischen Server in der Wiederherstellungsgruppe am
Remote-Standort. Je nach dem Typ des logischen Servers kann die Aktivierung auf
VC-Blades, VM-Hosts oder beidem erfolgen. Wählen Sie für IO-Dienste den IO-Dienst aus
der Liste der Dienste im oberen Teil der Registerkarte „IO Services“ (IO-Dienste) aus. Wählen
Sie aus dem Dropdown-Menü „Server Actions“ (Serveraktionen) dann Activate Servers
(Server aktivieren) aus, um die IO-Dienste in der Wiederherstellungsgruppe zu aktivieren.
Nachdem der Test abgeschlossen wurde, fahren Sie die Betriebssysteme ordnungsgemäß
herunter, und deaktivieren Sie dann die logischen Server oder IO-Dienste.
Speicherfailover durchführen. Wenn das CSV nicht offline ist, vgl. „Wiederherstellen eines
CSV aus dem Zustand online pending“ (Seite 93) für die Vorgehensweise zur
Wiederherstellung.
5.
6.
Melden Sie sich am CMS des Remote-Standorts an. Beenden Sie mit der Schaltfläche
Disable Maintenance Mode (Wartungsmodus deaktivieren) auf der Registerkarte Recovery
Groups (Wiederherstellungsgruppen) in Matrix Recovery Management den Wartungsmodus.
Melden Sie sich beim CMS am lokalen Standort an, und wiederholen Sie die Speicherfailover-,
Neueinlesungs- und Aktualisierungsabfolgen (sofern erforderlich). Aktivieren Sie dann die
logischen Server in der Wiederherstellungsgruppe mit Matrix OE Visualization, oder aktivieren
Sie den Standort, wenn der vollständige Satz von Wiederherstellungsgruppen aktiviert
werden soll.
Wenn eine Matrix Recovery Management-Konfiguration am Remote-Standort importiert wird, ist
für alle importierten Wiederherstellungsgruppen standardmäßig der Wartungsmodus aktiviert
oder lautet der Status Maintenance Mode – Storage Configuration Required. Weiter
unten muss die Speicherkonfiguration vor dem Testen oder Deaktivieren des Wartungsmodus
zuerst abgeschlossen werden. Gleichermaßen ist bei einer am Remote-Standort erstellten
Wiederherstellungsgruppe der Wartungsmodus standardmäßig aktiviert. Nachdem das Testen
für alle importierten Wiederherstellungsgruppen, logischen Server und/oder IO-Dienstreplikate
am Remote-Standort abgeschlossen wurde, deaktivieren Sie die logischen
Wiederherstellungsserver oder IO-Dienstreplikate, die jeder Wiederherstellungsgruppe angehören.
Deaktivieren Sie dann den Wartungsmodus für jede Wiederherstellungsgruppe.
Wiederherstellungsgruppen, für die der Wartungsmodus aktiviert ist, werden nicht in den Vorgang
Activate (Aktivieren) aufgenommen. Der Wartungsmodus kann nach einem Import nicht ohne
Testen deaktiviert werden. Hewlett Packard Enterprise empfiehlt jedoch, die Aktivierung der
logischen Server und der IO-Dienste wie in den voranstehenden Schritten zu testen, bevor der
Wartungsmodus deaktiviert wird.
Testen von Wiederherstellungsgruppen
37
Aktivieren und Deaktivieren des Wartungsmodus
Alle importierten Wiederherstellungsgruppen befinden sich standardmäßig im Wartungsmodus
oder besitzen den Status Maintenance Mode – Storage Configuration Required.
•
Sie können den bzw. die logischen Server oder IO-Dienste, die den importierten
Wiederherstellungsgruppen im Wartungsmodus angehören, manuell aktivieren. Wenn eine
Wiederherstellungsgruppe den Status Maintenance Mode — Storage Configuration
Required anzeigt, müssen Sie zuerst die Speicherkonfiguration abschließen, bevor Sie
die Aktivierung der logischen Server oder IO-Dienste testen können.
•
Sie können die importierte Wiederherstellungsgruppe im Wartungsmodus oder mit dem
Status Maintenance Mode – Storage Configuration Required nur zum Testen
der logischen Server oder IO-Dienste, die der Wiederherstellungsgruppe angehören, manuell
aktivieren.
•
Der Wartungsmodus kann nur für Wiederherstellungsgruppen aktiviert werden, die
deaktiviert sind.
•
Der Wartungsmodus kann nur für Wiederherstellungsgruppen deaktiviert werden, wenn
deren logische Server und IO-Dienste alle deaktiviert sind. Wenn der Status der
Wiederherstellungsgruppe Maintenance Mode – Storage Configuration Required
lautet, muss vor dem Deaktivieren des Wartungsmodus auch noch die Speicherkonfiguration
der Wiederherstellungsgruppenmitglieder abgeschlossen werden.
Mit der Schaltfläche Refresh (Aktualisieren) können Sie den Status der Speicherkonfiguration
neu laden. Anhand des Zeitstempels des zuletzt aktualisierten Status der Speicherkonfiguration,
der links unten in der Tabelle „Recovery Group“ (Wiederherstellungsgruppe) angezeigt wird,
kann überprüft werden, wann der Status zuletzt neu geladen wurde. Abhängig davon, wie viel
Speicher aktualisiert wird, kann die Aktualisierung längere Zeit in Anspruch nehmen.
HINWEIS: Sie müssen alle Probleme auf dem Bildschirm des Matrix OE
Visualization-Speicherpooleintrags beheben und/oder die Speicherkonfiguration abschließen
(wie z. B. Erstellen von Replikaten, Durchführen der Bereitstellung und Zonenzuweisung) und
durch Bearbeiten des Speicherpooleintrags angeben, ob die Volumes Disaster Recovery Ready
(Disaster Recovery-bereit) sind. Wenn die Wiederherstellungsgruppe als ein Matrix-IO-Dienst
konfiguriert ist, müssen Sie die Registerkarte Matrix Infrastructure Orchestration Requests
(Matrix Infrastructure Orchestration-Anforderungen) auf ausführliche Informationen zur Anforderung
Create Replica (Replikat erstellen) und erforderliche Maßnahmen überprüfen.
Weitere Informationen zur Matrix-Speicherkonfiguration, darunter die automatische Konfiguration
der Replikation für bestimmte Umgebungen, finden Sie im Storage Provisioning Manager (SPM)
Benutzerhandbuch, Matrix Operating Environment Infrastructure Orchestration
Benutzerhandbuch,Matrix Operating Environment Logical Server Management Benutzerhandbuch
undStorage Provisioning Manager Benutzerhandbuch in der Hewlett Packard Enterprise
Failover-Vorgänge
Dieser Abschnitt geht auf den Unterschied zwischen geplanten und nicht geplanten Failovers
ein und beschreibt das in beiden Fällen durchzuführende Verfahren.
Ein Hinweis zum Microsoft Hyper-V Server-Failover:
Matrix Recovery Management unterstützt nur VM-Failover zwischen äquivalenten Versionen von
Microsoft Hyper-V Server oder von früheren zu aktuellen Versionen.
Failover von einer aktuellen zu einer früheren Version, wie etwa von Hyper-V Server 2012 zu
Hyper-V Server 2008 R2, wird nicht unterstützt.
38
Geplantes Failover
Ein geplantes Failover bezieht sich gewöhnlich auf einen erwarteten Ausfall. So könnte ein
geplantes Failover beispielsweise zum Durchführen einer planmäßigen Wartung oder als Reaktion
auf vorhergesagte ungünstige Wetterbedingungen erforderlich sein. Im folgenden Abschnitt
werden die erforderlichen Schritte zur Durchführung eines geplanten Failovers mit Hilfe von
Matrix Recovery Management beschrieben. Bei einem geplanten Failover werden verschiedene
Schritte am lokalen Standort sowie am Remote-Standort durchgeführt.
Ein geplantes Failover umfasst eine Reihe von Schritten, die zuerst an dem Standort durchgeführt
werden, der heruntergefahren werden soll, und dann am anderen Standort in der Matrix Recovery
Management-Konfiguration.
An dem Standort, der heruntergefahren werden soll:
1. Fahren Sie die Anwendungen und das Betriebssystem auf jedem mit Matrix Recovery
Management DR-geschützten logischen Server und jedem Server, der mit DR-geschützten
IO-Diensten verknüpft ist, herunter.
2. Klicken Sie auf der Registerkarte Sites (Standorte) auf der Matrix Recovery Management-GUI
auf die Schaltfläche Deactivate (Deaktivieren). Nun erscheint das Fenster Deactivate
Recovery Groups at the Standortname (Wiederherstellungsgruppen am Standortname
deaktivieren).
Weitere Information zu den Wiederherstellungsgruppen, die in einem
Wiederherstellungsgruppensatz enthalten sind, erhalten Sie, wenn Sie das entsprechende
Wiederherstellungsgruppensatz auswählen und auf View Recovery Group
(Wiederherstellungsgruppe anzeigen) klicken. Es wird ein Fenster angezeigt, in dem Sie
folgende Parameter für jede Wiederherstellungsgruppe in einem
Wiederherstellungsgruppensatz sehen:
3.
4.
•
Name
•
Status (Zustand)
•
Typ
•
Preferred Site (Bevorzugter Standort)
•
Secondary Site (Sekundärer Standort)
•
Storage Replication Group Name (Name der Speicherreplikationsgruppe)
•
Start Order (Startreihenfolge)
•
Power-Up Delay (Einschaltverzögerung)
Wählen Sie die Wiederherstellungsgruppensätze aus, die deaktiviert werden sollen, und
klicken Sie auf Deactivate (Deaktivieren). Bei einem vollständigen Ausfall wären das
beide Sätze.
Klicken Sie auf Deactivate Recovery Groups (Wiederherstellungsgruppen deaktivieren),
um den Deaktivierungsvorgang zu starten. Es wird ein Fenster angezeigt, in dem Sie gefragt
werden, ob der Vorgang fortgesetzt werden soll. Klicken Sie auf OK, um auf die Registerkarte
Jobs (Aufträge) weitergeleitet zu werden, wo Sie den Fortschritt des Deaktivierungsauftrags
überwachen können.
Server oder IO-Dienste verwendete Cluster-Datenträger-Ressource offline, bevor Sie die
Aktivierung am Remote-Standort durchführen. Wenn das CSV nicht offline ist, vgl.
„Wiederherstellen eines CSV aus dem Zustand online pending“ (Seite 93) für die
So führen Sie einen Failover am Remote-Standort durch:
Failover-Vorgänge
39
1.
2.
Melden Sie sich am Remote-CMS an, und vergewissern Sie sich, dass eine ausreichende
Anzahl von Ressourcen zur Ausführung der logischen Server vorhanden sind, die an diesem
Standort aktiviert werden.
Klicken Sie auf die Schaltfläche Activate... (Aktivieren...). Das Fenster Activate Recovery
Groups at the Standortname (Wiederherstellungsgruppen am Standortname aktivieren)
wird angezeigt.
3.
4.
•
Name
•
Status (Zustand)
•
Typ
•
•
•
•
•
Wählen Sie die zu aktivierenden Wiederherstellungsgruppensätze einzeln aus, oder aktivieren
Sie das Kontrollkästchen auf der linken Seite des Banners im Fenster Activate Recovery
Groups at the Standortname (Wiederherstellungsgruppen am Standortname aktivieren),
um alle Wiederherstellungsgruppensätze zum Aktivieren auszuwählen.
Klicken Sie auf Activate Recovery Groups (Wiederherstellungsgruppen aktivieren), um
den Aktivierungsvorgang zu starten. Es wird ein Fenster angezeigt, in dem Sie gefragt
Jobs (Aufträge) weitergeleitet zu werden, wo Sie den Fortschritt des Aktivierungsauftrags
HINWEIS: Durch einen erfolgreichen Aktivierungs- oder Deaktivierungsvorgang wird
sichergestellt, dass alle Wiederherstellungsgruppen innerhalb eines
Wiederherstellungsgruppensätze sich im gleichen Zustand befinden (aktiviert oder deaktiviert).
Bestimmte Vorgänge (z. B. eine Änderung des bevorzugten Standorts einer
Wiederherstellungsgruppe) können dazu führen, dass einige Wiederherstellungsgruppen innerhalb
eines Wiederherstellungsgruppensätze aktiviert und andere deaktiviert werden. Sie müssen für
ein Wiederherstellungsgruppensatz einen Activate- (Aktivieren) oder Deactivate- (Deaktivieren)
Vorgang ausführen, um sicherzustellen, dass sich alle Wiederherstellungsgruppen im betreffenden
Wiederherstellungsgruppensatz im gleichen Zustand befinden (alle aktiviert oder alle deaktiviert).
Nicht geplantes Failover
Ein nicht geplantes Failover bezieht sich gewöhnlich auf ein standortweit ohne Vorwarnung
aufgetretenes Ereignis. Bei diesem Ereignis kann es sich um eine regionale Katastrophe
(Erdbeben und massive Überschwemmung) oder um ein lokales Problem (Stromausfall oder
Wasserleck im Rechenzentrum) handeln.
Ein nicht geplantes Failover umfasst eine Reihe von Schritten, die an beiden Standorten in der
Matrix Recovery Management-Konfiguration durchgeführt werden. Das folgende Verfahren geht
davon aus, dass der CMS und die verwalteten Ressourcen, auf denen DR-geschützte logische
Server ausgeführt werden, ein nicht geplantes lokales Ereignis (z. B. einen Stromausfall)
40
unbeschadet überstanden haben. Bei schwerwiegenderen Ereignissen, die zu einem permanenten
Verlust des CMS oder der verwalteten Ressourcen führen, muss der Standort möglicherweise
neu aufgebaut werden.
An dem Standort, an dem das standortweite Ereignis aufgetreten ist:
1. Stellen Sie sicher, dass die DR-geschützten logischen Server nicht mehr ausgeführt werden,
um eine Split-Brain-Situation zu vermeiden. Solange die Ausführung der DR-geschützten
logischen Server gestoppt ist, verhindert Matrix Recovery Management, dass sie automatisch
gestartet werden, wenn die Stromzufuhr wiederhergestellt wird.
Matrix Recovery Management kann verhindern, dass während eines nicht geplanten Failovers
eine Split-Brain-Situation eintritt. Dazu wird die Konfiguration für das automatische Einschalten
verwalteter Knoten (egal ob virtuell oder physisch), die DR-geschützten logischen Servern
zugewiesen sind, so reguliert, dass sie nach einem Stromausfall nicht automatisch
eingeschaltet werden. Angenommen, an einem Standort tritt ein Stromausfall auf und das
Standort-Failover wird aufgerufen. In diesem Fall wird an dem Standort, an dem der
Stromausfall aufgetreten ist, die Ausführung der DR-geschützten logischen Server nicht
fortgesetzt, wenn die Stromzufuhr wiederhergestellt wird. Die verwalteten Knoten (egal ob
VC-Blades oder Virtual Machines), die DR-geschützten logischen Servern zugewiesen sind,
bleiben ausgeschaltet (und die Ressourcen werden nicht zugewiesen), bis der Vorgang
Activate (Aktivieren) aufgerufen wird.
Am Failover-Zielort (Wiederherstellungsspeicherort):
1. Stellen Sie sicher, dass eine ausreichende Anzahl von Ressourcen zur Ausführung der
logischen Wiederherstellungsserver vorhanden sind.
2. Klicken Sie auf der Registerkarte Sites (Standorte) in Matrix Recovery Management auf die
Schaltfläche Activate... (Aktivieren...). Das Fenster Activate Recovery Groups at the
Local Site (Wiederherstellungsgruppen am lokalen Standort aktivieren) wird angezeigt.
3.
4.
•
Name
•
Status (Zustand)
•
Typ
•
•
•
•
•
Wählen Sie die Wiederherstellungsgruppensätze, die am Wiederherstellungsstandort aktiviert
werden sollen, einzeln aus. Ziel ist es, alle Wiederherstellungsgruppensätze, die zuvor an
dem Standort aktiviert waren, an dem das standortweite Ereignis aufgetreten ist, am
Wiederherstellungsstandort zu aktivieren.
Klicken Sie auf Activate Recovery Groups (Wiederherstellungsgruppen aktivieren), um
den Aktivierungsvorgang zu starten. Es wird ein Fenster angezeigt, in dem Sie gefragt
Jobs (Aufträge) weitergeleitet zu werden, wo Sie den Fortschritt des Aktivierungsauftrags
Failover-Vorgänge
41
HINWEIS:
•
Wurde die Matrix Recovery Management-Konfiguration seit dem eingetretenen Failover
geändert (es wurde z. B. eine neue Wiederherstellungsgruppe erstellt), müssen die Standorte
durch Vornahme entsprechender Konfigurationsänderungen miteinander synchronisiert
werden. Zu diesem Zweck können die Matrix Recovery Management-Vorgänge zum
Exportieren und Importieren der Standortkonfiguration verwendet werden.
•
Durch einen erfolgreichen Aktivierungs- oder Deaktivierungsvorgang wird sichergestellt,
dass alle Wiederherstellungsgruppen innerhalb eines Wiederherstellungsgruppensätze sich
im gleichen Zustand befinden (aktiviert oder deaktiviert). Bestimmte Vorgänge (z. B. eine
Änderung des bevorzugten Standorts einer Wiederherstellungsgruppe) können dazu führen,
dass einige Wiederherstellungsgruppen innerhalb eines Wiederherstellungsgruppensätze
aktiviert und andere deaktiviert werden. Sie müssen für ein Wiederherstellungsgruppensatz
einen Aktivierungs- oder Deaktivierungsvorgang ausführen, um sicherzustellen, dass
sich alle Wiederherstellungsgruppen im betreffenden Wiederherstellungsgruppensatz im
gleichen Zustand befinden (aktiviert oder deaktiviert).
Zielauswahl und Parallelismus während eines Aktivierungsvorgangs
Die Komponente HPE Matrix OE Logical Server Management (Logical Server Management) in
Matrix Operating Environment unterstützt das Konzept von Zielen, die zum Aktivieren eines
logischen Servers basierend auf verschiedenen Kriterien am besten geeignet sind. Zu solchen
Kriterien können z. B. Anwendungen gehören, die nur auf VC-gehosteten logischen Servern
ausgeführt werden sollten, um eine Leistungsanforderung zu erfüllen.
DR-geschützte logische Server, die auf physischen und virtuellen Zielen ausgeführt werden
können (technologieübergreifende logische Server), werden je nach Verfügbarkeit auf dem Zieltyp
platziert, der in der Standortkonfiguration als bevorzugt angegeben wird (P steht für physisch
und V steht für virtual). Wenn der bevorzugte Zieltyp nicht verfügbar ist, ignoriert Matrix Recovery
Management den Zieltypvorzug und platziert technologieübergreifende logische Server auf
verfügbaren unterstützten Zielen.
Matrix OE Logical Server Management ermöglicht die parallele Aktivierung von logischen Servern
und nutzt so den Parallelismus der verwalteten Infrastruktur. Beim Durchführen eines Activate
(Aktivieren)-Vorgangs nutzt Matrix Recovery Management den Parallelismus der Aktivierung,
der mit Logical Server Management verfügbar ist, um die Failover-Zeit zu verkürzen. Zur
Beeinflussung der Verwaltung von Matrix Recovery Management in diesem Bereich stehen dem
Benutzer zwei Einstellungen zur Verfügung:
•
Mit dem Werten unter Recovery Group Start Order (Startreihenfolge der
Wiederherstellungsgruppen) können Sie die Arbeitauslastungen festlegen, die beim
Failover-Vorgang zuerst hochgefahren werden.
Wenn Sie während des Failover-Vorgangs bestimmte Arbeitslasten zuerst aufrufen möchten,
können Sie die Werte Recovery Group Start Order für die zugeordneten
Wiederherstellungsgruppen niedriger setzen als die Werte für Arbeitslasten, die im späteren
Verlauf des Failover-Vorgangs aufgerufen werden können. Matrix Recovery Management
stellt sicher, dass logische Server in einer Wiederherstellungsgruppe mit einem niedrigeren
Wert für Recovery Group Start Order (Startreihenfolge der Wiederherstellungsgruppen)
vor logischen Servern in der Wiederherstellungsgruppe mit einem höheren Wert für Recovery
Group Start Order (Startreihenfolge der Wiederherstellungsgruppen) aktiviert werden.
•
42
Mit dem Parameter Recovery Group Power-Up Delay (Einschaltverzögerung von
Wiederherstellungsgruppen) können Sie sicherstellen, dass die logischen Server in einer
Wiederherstellungsgruppe während eines Failover-Vorgangs auf gestaffelte Weise gestartet
werden. Der Parameter Recovery Group Power-Up Delay (Einschaltverzögerung von
Wiederherstellungsgruppen) stellt eine minimale zeitliche Verzögerung zwischen den
Zeitpunkten ein, an denen ein logischer Server und der nächste logische Server ihre
Startvorgänge beginnen.
Zielauswahl und Parallelismus während eines Aktivierungsvorgangs
43
4 Befehlszeilentools
Ab Version 7.5 wird das neue Befehlszeilentool drsync unterstützt, das Administratoren
ermöglicht, Änderungen an logischen Servern zwischen dem lokalen und dem Remote-Standort
zu synchronisieren, ohne dass ein Speicherfailover erforderlich ist. Es liest Informationen aus
einer Matrix-Instanz und überträgt sie mithilfe von Push wie durch die Befehlszeilensyntax definiert
auf eine zweite Matrix-Zielinstanz derselben Hauptversion.
Tool drsync
Die wichtigsten Funktionen des Befehlszeilentools drsync sind:
•
Erstellt einen logischen Peer-Server am Remote-Standort, falls zuvor noch keiner erstellt
wurde, ohne dass ein Speicherfailover durchgeführt oder der logische Peer-Server manuell
erstellt werden muss. Dadurch kann Zeit eingespart und ein kontinuierlichen Dienst am
lokalen Standort aufrechterhalten werden.
•
Kann auf jedem Standort – bevorzugt oder sekundär – ausgeführt werden.
•
Änderungen an logischen Servern können von jedem Standort ausgehen und in beiden
Richtungen synchronisiert werden, unabhängig davon, an welchen Standort der Befehl
ausgeführt wird.
•
Obwohl mit dem Tool drsync logische Peer-Server erstellt werden können, wird sehr dazu
geraten, stattdessen den Importvorgang in Matrix Recovery Management zu verwenden.
Sie können mit drsync die Änderungen an vorhandenen logischen Peer-Servern
synchronisieren. Mit dem Importvorgang von Matrix Recovery Management werden
Wiederherstellungsgruppen synchronisiert. Dies ist bei drsync nicht der Fall. Folglich
werden keine der mit drsync erstellten logischen Server zu einer Wiederherstellungsgruppe
hinzugefügt.
CMS-Konfigurationsanforderungen zur Verwendung mit drsync
Für die Querkommunikation von drsync zwischen CMSs muss zuerst ein x509-Zertifikat
ausgetauscht werden, bevor das Tool ausgeführt wird. Für diesen Austausch wird die HPE
SIM-Option Federated CMS Configure (CMS-Verbund konfigurieren) verwendet, wie im folgenden
Beispiel anhand eines lokalen CMS (CMS A) und eines Remote-CMS (CMS B) veranschaulicht.
44
Befehlszeilentools
Beispiel 1 Konfiguration von CMS A
Verfahren Sie zum Konfigurieren von CMS A am lokalen Standort wie folgt:
1. Führen Sie an der Eingabeaufforderung den folgenden Befehl aus:
c:\ mxglobalsettings -ld managed_cms_list
2.
3.
Die Befehlsausgabe zeigt den FQDN von CMS A an.
Navigieren Sie mit dem Browser zur SIM-GUI, und wählen Sie Options
(Optionen)→Federated CMS configuration… (CMS-Verbundkonfiguration) aus.
a. Klicken Sie auf Add CMS… (CMS hinzufügen), und geben Sie die IP-Adresse oder den
FQDN des Ziel-/Remote-CMS ein, und klicken Sie auf Next (Weiter).
b. Geben Sie den Benutzernamen und das Kennwort für einen Benutzer mit
Administratorrechten auf dem Ziel-/Remote-CMS ein, und klicken Sie auf Finish (Fertig
stellen).
4.
Kehren Sie auf dem lokalen CMS zur Eingabeaufforderung zurück, und führen Sie den
folgenden Befehl erneut aus:
c:\ mxglobalsettings -ld managed_cms_list
5.
6.
Die Befehlsausgabe muss sowohl den lokalen (CMS-A) als auch den Remote-CMS (CMS-B)
anzeigen.
Führen Sie über die Befehlszeile den folgenden Befehl aus:
c:\mxglobalsettings -s -f
managed_cms_list=<IN_AUSGABE_VON_SCHRITT_EINS_AUFGELISTETER_CMS>
HINWEIS: Der FQDN für den lokalen CMS lautet C:\mxglobalsettings -s -f
managed_cms_list=cmsa.x.y.com
7.
Bearbeiten Sie die Datei lsaclient.properties im VSE-Installationsverzeichnis, um
die IP-Adresse des lokalen Hosts anzugeben.
HPSIM_CMS_TCPIP_HOSTNAME=<VON_DRSYNC_ZUR_KOMMUNIKATION_MIT_DIESEM_CMS_VERWENDETE_IP-ADRESSE>
Beispiel: HPSIM_CMS_TCPIP_HOSTNAME=10.0.0.101
10.0.0.101 ist die IP-Adresse von CMS A.
8.
Sie können entweder den CMS oder alle Hewlett Packard Enterprise Dienste neu starten.
Beispiel 2 Konfiguration von CMS B
Verfahren Sie zum Konfigurieren von CMS B am Remote-Standort wie folgt:
1. Bearbeiten Sie die Datei lsaclient.properties im VSE-Installationsverzeichnis, um
die IP-Adresse des lokalen Hosts anzugeben.
HPSIM_CMS_TCPIP_HOSTNAME=<VON_DRSYNC_ZUR_KOMMUNIKATION_MIT_DIESEM_CMS_VERWENDETE_IP-ADRESSE>
Beispiel: HPSIM_CMS_TCPIP_HOSTNAME=10.0.0.102
10.0.0.102 ist die IP-Adresse von CMS B.
2.
Sie können entweder den CMS oder alle Hewlett Packard Enterprise Dienste neu starten.
Konfigurieren der Datei dr.properties für drsync
Die Datei dr.properties, die Standarddatei zum Ändern der Konfigurationsparameter des
Tools drsync, ist unter <Matrix Recovery Management-Installationsverzeichnis>\
conf directory verfügbar. Optional können Sie zusätzliche Konfigurationsdateien definieren
und mit drsync mit der Option configFile zusätzliche Konfigurationsdateien definieren.
Tabelle 2 (Seite 46) listet die Eigenschaften auf, die in der Datei dr.properties festgelegt
werden können.
Konfigurieren der Datei dr.properties für drsync
45
Tabelle 2 dr.properties-Optionen
Eigenschaft
Beschreibung
SYNC_STRATEGIES Strategien für die
Synchronisierung logischer
Server für drsync.
Werte
Beispiel
COPY_LS
SYNC_STRATEGIES=COPY_LS,
COPY_CPU, COPY_MEMORY,
COPY_NETWORK, COPY_STORAGE
COPY_NETWORK
COPY_STORAGE
Hiermit können Sie definieren,
COPY_MEMORY
welche Aspekte für logische
Server zwischen Quell- und
COPY_CPU
Ziel-CMS synchronisiert
werden. Bei Angabe der Option
COPY werden CPU-,
Arbeitsspeicher-, Netzwerkund Speichereigenschaften des
logischen Remote-Servers mit
den Eigenschaften des
logischen Quellserver
aktualisiert.
SYNC_EXCLUSION_LIST Auf diese Weise können Sie
über den Quell-CMS eine Liste
der logischen Server (durch
Kommas getrennt) definieren,
die aus dem
Synchronisierungsvorgang
ausgeschlossen werden.
SYNC_EXCLUSION_LIST= LS01,
LS?2, LS*3, LS?[Aa]*
Diese Eigenschaft unterstützt
die Verwendung von
Globbing-Mustern
(Platzhaltern) zur Abstimmung
der Namen logischer Server.
Weitere Informationen finden
Sie unter „Globbing-Ausdrücke“
(Seite 47).
SYNC_LS_MAPPING Diese Eigenschaft ermöglicht
die Zuordnung von logischen
Servern, die über die Standorte
hinweg unterschiedliche
Namen haben. Wenn die
Namen der logischen Server
auf beiden Seiten
übereinstimmen, muss der
logische Server nicht zur
Zuordnung hinzugefügt werden.
Syntax der Eigenschaft: Die
Elemente eines jeden Paars
müssen durch Doppelpunkte
voneinander getrennt werden.
Die Paare müssen durch
Kommas getrennt werden. Bei
dieser Eigenschaft kann der
Inhalt durch einen
Rückwärtsschrägstrich (\) am
Ende jeder Zeile in mehrere
Zeilen aufgeteilt sein.
46
Befehlszeilentools
SYNC_LS_MAPPING
=LS_source_1:LS_target_1,
\LS_source_2:LS_target_2,
\LS_source_3:LS_target_3
Globbing-Ausdrücke
Bei der Verwendung von Globbing-Ausdrücken werden die folgenden Zeichen unterstützt:
•
Unterstützte Zeichen
◦
Ein Fragezeichen steht für ein einzelnes Zeichen.
So bewirkt ls? beispielsweise, dass drsync nach allen logischen Servern sucht, deren
Namen mit ls beginnen und mit einem einzelnen Zeichen enden, lsa, lsb, ls1 usw.
◦
Ein Sternchen steht für eine beliebige Anzahl von Zeichen.
So bewirkt ls* beispielsweise, dass drsync nach allen logischen Servern sucht, deren
Namen mit ls beginnen und mit einer beliebigen Anzahl von Zeichen enden,
einschließlich Namen logischer Server ohne zusätzliche Zeichen, wie z. B. ls, lsa,
lsbc, ls123 usw.
◦
Mit eckigen Klammern kann ein Bereich festgelegt werden.
So bewirkt die Eingabe von my[123]ls beispielsweise, dass drsync nach my1ls,
my2ls und my3ls sucht.
Die folgenden Regeln gelten bei der Verwendung von Globbing- Ausdrücken:
•
Bei der Eigenschaft sind Groß- und Kleinschreibung bedeutsam.
•
In Globbing-Ausdrücken sind Sonderzeichen wie z. B. ?, *, [ ] zulässig.
Es wird nicht empfohlen, Sonderzeichen als Buchstaben und nicht als Operatoren zu
verwenden.
Beispiel:
* muss in der Datei drsync.properties als \\* und in der Befehlszeile als \* eingegeben
werden.
Um einen logischen Server namens LS? einzuschließen, müssen Sie –ls LS\? verwenden.
Um die logischen Server LS1,LS2 einzuschließen, müssen Sie -ls LS? verwenden.
•
In Globbing-Mustern werden keine Kommas akzeptiert.
Verwenden des Befehlszeilentools drsync
Zur Verwendung des Befehlszeilentools drsync müssen der Quell- und der Ziel-CMS, die
synchronisiert werden sollen, die gleiche Hauptversion von Matrix Operating Environment besitzen.
drsync filtert standardmäßig alle logischen Server heraus. Während das Tool ausgeführt wird,
müssen Sie mit den Optionen -virtual und/oder -physical des Befehls eine Mindestdefinition
vornehmen. Mit drsync wird die Synchronisierung zudem simuliert. Zum Festschreiben der
Synchronisierung können Sie die Option -execute verwenden.
Tabelle 3 (Seite 47) listet die verschiedenen drsync-Optionen auf:
Tabelle 3 drsync-Optionen
Option
Beschreibung
-s
FQDN oder IP-Adresse des Quell-CMS.
-t
FQDN oder IP-Adresse des Ziel-CMS.
-execute
Standardmäßig findet nur eine Simulierung der Änderungen statt. Mit dieser
Option können Sie die Änderungen festschreiben.
-virtual
Virtuelle logische Servern in den Synchronisierungsvorgang einschießen.
-physical
Physische logische Server in der Synchronisierungsvorgang einschließen.
Globbing-Ausdrücke
47
Tabelle 3 drsync-Optionen (Fortsetzung)
Option
Beschreibung
-ls
Gibt die Namen der logischen Server an, die bei der Synchronisierung
berücksichtigt werden sollen. Wenn keine Namen angegeben werden, werden
alle DR-geschützten logischen Server bei der Synchronisierung berücksichtigt.
Diese Option bestimmt anhand der Optionen –physical und –virtual,
welche der in Betracht gezogenen logischen Server Teil des
Synchronisierungsvorgangs sind. Diese Option unterstützt die Verwendung von
Platzhaltern zur Abstimmung der Namen logischer Server.
-configFile <Dateiname>
Konfigurationsdatei, mit der definiert wird, welche Eigenschaften zwischen
logischen Servern synchronisiert werden sollen. Wenn keine Datei angegeben
wird, verwendet das Tool die Standardkonfigurationsdatei unter <Matrix
Recovery Management-Installationsverzeichnis>\conf\
dr.properties.
-c <Parallelitätsanzahl>
Gibt an, wie viele logische Server gleichzeitig synchronisiert werden sollen.
Standardmäßig lautet dieser Wert 1. Durch Erhöhen dieser Anzahl kann die
Leistung verbessert werden. Allerdings wird die Last auf dem CMS ebenfalls
erhöht. Die Anzahl der CPUs des CMS und die Netzwerkbandbreite müssen
ebenfalls sorgfältig gewählt werden. Der unterstützte Höchstwert ist 25.
-verbose
Zeigt die folgenden zusätzlichen Informationen an:
• Name der geladenen Konfigurationsdatei.
• Die für die Eigenschaft SYNC_STRATEGIES geladenen Werte.
• Aus welchem Grund ein logischer Server übersprungen wurde.
• Anzahl der geladenen logischen Server.
Rückgabewerte
Als Rückgabewerte für drsync sind 0 oder –1 möglich.
Tabelle 4 Rückgabewerte
Option
Beschreibung
0
Der Vorgang wurde erfolgreich abgeschlossen.
–1
Während des Vorgangs ist ein Fehler aufgetreten.
drsync-Datei und Speicherorte
Dies sind die drsync-Dateien mit ihrem jeweiligen Speicherort:
48
•
drsync executable file befindet sich unter <Matrix Recovery
Management-Installationsverzeichnis>\bin\drsync.bat
•
drsync configuration file befindet sich unter <Matrix Recovery
Management-Installationsverzeichnis>\conf\dr.properties
•
drsync log file befindet sich unter <Matrix Recovery
Management-Installationsverzeichnis>\logs\lsdt_sync.log
Befehlszeilentools
5 Dynamische Arbeitsauslastungs-Verschiebung mit
CloudSystem Matrix
In diesem Kapitel wird die Konfiguration von technologieübergreifenden logischen Servern
beschrieben, die mit Matrix Recovery Management verwaltet werden können.
HINWEIS:
Technologieübergreifende logische Server werden für IO-Dienste nicht unterstützt.
Die Matrix Operating Environment ermöglicht eine fließende Verschiebung der Arbeitsauslastungen
zwischen unterschiedlichen Servern innerhalb eines Standorts und über verschiedene Standorte
hinweg. Arbeitsauslastungen können zwischen physischen Servern und Virtual Machines und
zwischen unterschiedlichen physischen Servern verschoben werden.
Eine der Haupttendenzen der IT-Rechenzentrumsverwaltung besteht derzeit darin, eine höhere
Effizienz in der Verwendung der Rechen-, Netzwerk- und Speicherressourcen im Datenzentrum
zu erreichen. Diese Ressourcen werden dabei wie ein gemeinsamer Pool behandelt, aus dem
die Ressourcen-Anforderungen verschiedener Anwendungen, Abteilungen und Organisationen
gedeckt werden. Von zentraler Bedeutung für dieses Konzept des Infrastrukturverbunds ist die
Fähigkeit, bei Bedarf schnell und automatisch Arbeitsauslastungen zu erstellen, zu verschieben
und zu entfernen.
Bei einem typischen implementierten Infrastrukturverbund kann ein Kunde mithilfe von Matrix
Operating Environment, das auf einem Central Management Server (CMS) ausgeführt wird, die
Arbeitsauslastungen ganz nach Bedarf erstellen, verschieben und entfernen. Die
Arbeitsauslastung, in der das Betriebssystem enthalten ist, auf dem die Benutzeranwendung
ausgeführt wird, kann entweder direkt auf einem Blade oder auf einer Virtual Machine ausgeführt
werden, die von einem Hypervisor, wie z. B. VMware ESX oder Integrity Virtual Machines,
verwaltet wird.
Die in diesem Kapitel angesprochenen Funktionen von Matrix Operating Environment ermöglichen
eine fließende Verschiebung der Arbeitsauslastungen in dieser Art von heterogener Umgebung.
Zu diesen Funktionen gehören:
•
Tools zur Vorbereitung des Arbeitsauslastungs-Betriebssystems als portierbares
Systemabbild, das in verschiedenen Serverumgebungen ausgeführt werden kann.
•
Differenzierte Benutzerkontrolle über den Satz spezifischer physischer Server und Virtual
Machine-Hosts, auf denen Matrix Operating Environment die Arbeitsauslastung ausführen
kann.
Die in diesem Kapitel beschriebene fließende Verschiebung von Arbeitsauslastungen über
unterschiedliche Server hinweg unterscheidet sich von der durch herkömmliche Migrationstools
ermöglichten Verschiebung. Herkömmliche Tools sind darauf ausgelegt, eine permanente oder
semi-permanente Migration zwischen physischen und virtuellen oder zwischen unterschiedlichen
physischen Servern in einer Richtung zu ermöglichen. Diese Art von Verschiebung erfordert
gewöhnlich einen manuellen Eingriff und dauert relativ lange, bis sie vollzogen ist.
Wie wichtig es ist, eine Arbeitsauslastung fließend von einem physischen Server zu einer Virtual
Machine und zurück verschieben zu können, wird anhand der folgenden Beispiele veranschaulicht:
•
Angenommen, Sie möchten eine Online-Arbeitsauslastung, die auf einem physischen Server
ausgeführt wird, während täglicher Nebenzeiten auf einen Virtual Machine-Host verschieben,
um den physischen Server zum Ausführen einer Stapel-Arbeitsauslastung zu entlasten.
Wenn die Nebenzeiten vorüber sind, wird die Stapel-Arbeitsauslastung in diesem Fall
deaktiviert und die Online-Arbeitsauslastung wird wieder in ihre
Original-Ausführungsumgebung verschoben.
Während die Online-Arbeitsauslastung auf einem Virtual Machine-Host 'geparkt' ist, nimmt
sie nur minimal Ressourcen in Anspruch und beeinträchtigt somit andere Arbeitsauslastungen,
die möglicherweise derzeit auf dem betreffenden Host ausgeführt werden, nur geringfügig.
49
Da sich dieses Muster tagtäglich wiederholt, muss die Verschiebung von physisch zu virtuell
und von virtuell zu physisch schnell und automatisch erfolgen (innerhalb von Minuten anstatt
von Stunden).
•
Angenommen, Sie besitzen zwei Rechenzentren an zwei verschiedenen Standorten. Die
Produktions-Arbeitsauslastungen werden an einem Standort auf physischen Servern
ausgeführt und sind so konfiguriert, dass im Notfall ein Failover von ihnen auf den anderen
(Wiederherstellungs-) Standort erfolgt. Der Wiederherstellungs-Standort ist mit einem Satz
von als Virtual Machine-Hosts konfigurierten Servern ausgestattet. In diesem Fall erfordern
geplante oder nicht geplante Failovers physische zu virtuelle und virtuelle zu physische
Verschiebungen über Standorte hinweg.
Die Konfiguration des Wiederherstellungs-Standorts als Satz von Virtual Machine-Hosts ist
möglicherweise durch erforderliche Test- und Entwicklungsaktivitäten bedingt, die am
betreffenden Standort ausgeführt werden. Oder sie lässt sich auf Sparmaßnahmen bei der
Notfallwiederherstellung zurückführen, indem Arbeitsauslastungen auf durch einen kleineren
Satz von Servern gehosteten Virtual Machines ausgeführt werden. Zielsetzungen bezüglich
der Wiederherstellungszeit erfordern wie bei dem vorherigen Beispiel, dass die
Verschiebungen schnell und automatisch erfolgen.
Fähigkeiten und Einschränkungen
Mittels der in diesem Kapitel beschriebenen Tools und Verfahren ist Folgendes möglich:
•
Konfigurieren und Verwalten eines logischen Servers, der zu physischen zu virtuellen
Verschiebungen über verschiedene Technologien hinweg innerhalb des Rechenzentrums
fähig ist.
•
Konfigurieren und Verwalten eines DR-geschützten logischen Servers, für den ein Failover
über verschiedene Rechenzentren hinweg als technologieübergreifende Verschiebung
möglich ist.
Die folgenden Einschränkungen sind zu beachten:
50
•
Matrix Recovery Management erweitert die Unterstützung nur auf ESX-Virtual Machines für
P2V. Vergewissern Sie sich hierfür davon, dass sich alle Quellen und Ziele in derselben
Portabilitätsgruppe befinden.
•
Bei der Konfiguration eines technologieübergreifenden logischen Servers fallen zusätzliche
Schritte an (bei der Verschiebung innerhalb eines oder zwischen verschiedenen Standorten
sind jedoch keine zusätzlichen Schritte erforderlich).
•
Technologieübergreifende logische Server werden für physische oder virtuelle IO-Dienste
nicht unterstützt.
•
Virtuelle Systeme mit Windows 2008 und höher werden unterstützt. Weitere Informationen
finden Sie in derInsight Management Support Matrix in der Hewlett Packard Enterprise
Enterprise-Informationsbibliothek. Virtuelle Systeme müssen zum Emulieren des LSI Logic
Parallel-Speichertyps konfiguriert werden.
•
VMware ESX-Guest-Tools werden nicht automatisch installiert.
•
Es gibt keine explizite Unterstützung für NPIV.
•
Die Vorbereitung des portierbaren Systemabbilds, sodass es auf physischen und virtuellen
Servern ausgeführt werden kann, erfolgt über ein auf einem physischen Server installiertes
Betriebssystem. Es ist nicht möglich, das portierbare Systemabbild über ein auf einer Virtual
Machine installiertes Betriebssystem vorzubereiten.
•
Virtual Machines müssen zur Verwendung des Raw Device Mapped (RDM) Fibre Channel
SAN-Speichers konfiguriert werden, der dem VM-Host für Start- und Daten-Speicher
präsentiert wird. Dies ist der gleiche Speicher, den ein logischer Server bei Ausführung auf
einem physischen Server verwendet.
Dynamische Arbeitsauslastungs-Verschiebung mit CloudSystem Matrix
•
Verwenden Sie beim Präsentieren jeder Start- und Daten-LUN über die physischen und
virtuellen Ziele eines logischen Servers hinweg jeweils die gleiche LUN-Nummer (siehe
Abbildung Abbildung 6, „Die gleiche LUN-Nummer über physische und virtuelle Ziele hinweg“).
Abbildung 6 Die gleiche LUN-Nummer über physische und virtuelle Ziele hinweg
•
Die zum Präsentieren der logischen Einheit verwendeten Ziel-WWN-Werte müssen über
virtuelle und physische Ziele hinweg gleich sein.
HINWEIS: Der logische Wiederherstellungs-Server, der für DR-Schutz am Remote-Standort
sorgt, besitzt einen eigenen Satz von Ziel-WWN/LUN-Werten, die sich von den
WWN/LUN-Zielwerten für den logischen Server am lokalen Standort unterscheiden.
•
Der von einem ESX-Host verwendete Netzwerkname muss mit dem Netzwerknamen
übereinstimmen, der in der Virtual Connect Enterprise Manager-Konfiguration verwendet
wird, wie in Abbildung 7, „ESX-Host-Netzwerkname“ und Abbildung 8, „HPE Virtual Connect
Enterprise Manager-Netzwerkname“ veranschaulicht:
Fähigkeiten und Einschränkungen
51
Abbildung 7 ESX-Host-Netzwerkname
Abbildung 8 HPE Virtual Connect Enterprise Manager-Netzwerkname
•
•
52
Wenn ein logischer Server zwischen physischen und virtuellen Servern innerhalb eines
Standorts verschoben wird, werden die folgenden Server-IDs nicht beibehalten:
◦
Netzwerk-MAC-Adressen
◦
Server-/Initiator-WWNs (auf der Virtual Machine ist der Speicheradapter ein virtueller
SCSI-Controller)
◦
Logische Seriennummer
◦
Logische UUID
Bei einer DR-Konfiguration müssen auf dem von Ihnen zuerst konfigurierten Standort
physische Server und Virtual Machine-Hosts verfügbar sein, damit ein logischer Server zur
Ausführung auf beiden Arten von Servern konfiguriert und getestet werden kann. Der
Wiederherstellungs-Standort kann über eine Kombination aus physischen und virtuellen
Geräten oder nur über Virtual Machine-Hosts verfügen.
Unterstützte Plattformen
Die in diesem Kapitel beschriebenen Verfahren, durch die die Verschiebung zwischen physischen
und virtuellen Servern ermöglicht wird, gelten für physische Server, Hypervisoren und
Arbeitsauslastungs-Betriebssysteme, die von Matrix Recovery Management unterstützt werden.
Weitere Informationen finden Sie im White PaperHewlett Packard Enterprise in Insight
Management in der Hewlett Packard Enterprise Enterprise-Informationsbibliothek.
•
Unterstützte Hypervisoren finden Sie in den VMware Hypervisor-Versionen, die als von
Matrix Operating Environment auf verwalteten Systemen unterstützt angegeben werden.
•
Informieren Sie sich bezüglich unterstützter Arbeitsauslastungs-Betriebssysteme in der
Hewlett Packard Enterprise Enterprise-Informationsbibliothek darüber, welche Windows
2008-Versionen als von Matrix Operating Environment auf verwalteten Systemen unterstützt
angegeben werden.
Die Matrix Recovery Management-Verfahren, durch die die Verschiebung zwischen physischen
und virtuellen Servern ermöglicht wird, werden auf Integrity-verwalteten Knoten nicht unterstützt.
•
Matrix Recovery Management, die Komponente von Matrix Operating Environment, die
standortübergreifend Notfallwiederherstellung bietet, unterstützt keine Integrity-verwalteten
Knoten.
Die in diesem Kapitel beschriebenen Verfahren, durch die die Verschiebung über verschiedene
physische Server hinweg ermöglicht wird, werden für verwaltete Systeme unterstützt, die von
der Matrix Operating Environment als unterstützt angegeben werden, mit der folgenden
Einschränkung:
Ein physisches Serverziel, das für technologieübergreifende Verschiebungen konfiguriert wird,
muss ein HPE C-class Blade mit Virtual Connect sein.
Übersicht über die physisch-virtuelle technologieübergreifende
Konfiguration
Dieser Abschnitt bietet eine Übersicht über die erforderlichen Schritte zum Konfigurieren von
technologieübergreifenden logischen Servern für die Verschiebung zwischen physischen und
virtuellen Zielen zwischen unterschiedlichen physischen Servern.
Konfigurieren logischer Server für die Verschiebung zwischen physischen und
virtuellen Zielen
1.
Vorbereiten eines logischen Servers mit einem portierbaren Abbild
Beginnen wir mit einem logischen Server, der zur Ausführung auf einem physischen Server
konfiguriert ist, und bereiten sein Systemabbild auf die Verschiebung zwischen physischen
und virtuellen Servern vor.
a. Speicher-Konfiguration
Das PISA- Tool (Portable Images Storage Assistant) bereitet die Speicherkonfiguration
des Server-Abbilds vor, so dass es in physischen und virtuellen Umgebungen starten
kann. PISA ist Teil des Produkts Insight Control Server Migration auf der HPE Insight
Management-DVD. Die ausführbare Datei und die README-Datei befinden sich im
Ordner <SMP>\PI\PISA, wobei <SMP> das Verzeichnis ist, in dem Insight Control
Server Migration installiert ist (das Standard-Installationsverzeichnis ist C:\Programme
Files\HP\Insight Control server migration).
i. Kopieren Sie die ausführbare Datei hppisa.exe (unter PI\PISA) auf den
physischen Server, auf dem das Abbild derzeit ausgeführt wird.
Übersicht über die physisch-virtuelle technologieübergreifende Konfiguration
53
ii.
Geben Sie im Befehlszeilen-Fenster Folgendes ein: > hppisa –e
Weitere Informationen finden Sie unter „Portable Images Storage Assistant (PISA)“.
b.
Netzwerkkonfiguration
Das PINT-Tool (Portable Images Network Tool) bereitet das Abbild auf die Ausführung
auf Zielen mit unterschiedlichen Netzwerkkonfigurationen und MAC-Adressen vor. Es
stellt sicher, dass die statische Netzwerkkonfiguration trotz der unterschiedlichen
Umgebung erfolgreich vom Quellserver auf die Zielserver-Netzwerkschnittstellen
übertragen wird. Die ausführbaren Dateien und die README-Datei befinden sich im
Ordner <SMP>\PI\PINT.
i. Kopieren Sie die ausführbare Datei cp011231.exe auf den physischen Server,
auf dem das Abbild derzeit ausgeführt wird.
ii. Führen Sie cp011231.exe aus, um PINT zu installieren und den PINT-Dienst zu
starten.
Weitere Informationen finden Sie unter „Konfigurieren und Verwalten von portierbaren
Betriebssystemabbildern“.
2.
Erstellen einer Portabilitätsgruppe mit allen potenziellen physischen und
VM-Host-Zielen
Mit diesem Schritt wird die Portabilitätsgruppe eingerichtet, über die die Liste potenzieller
Ziele für den logischen Server definiert wird. Die Gruppe sollte als Ziele sowohl physische
Server als auch VM-Hosts enthalten. Siehe Abbildung 9, „Erstellen einer Portabilitätsgruppe“.
Abbildung 9 Erstellen einer Portabilitätsgruppe
Weitere Informationen finden Sie unter „Portabilitätsgruppen“.
3.
Konfigurieren des logischen Servers für die Aktivierung auf sowohl physischen als
auch VM-Host-Zielen
Ändern Sie die Konfiguration des logischen Servers folgendermaßen:
•
54
Legen Sie auf dem Bildschirm Create logical server: identity (Logischer Server
erstellen: Identität) als Portabilitätsgruppe des logischen Servers die in Schritt 2 erstellte
Portabiliätsgruppe fest.
•
Wählen Sie auf dem Bildschirm Create logical server: storage (Logischen Server
erstellen: Speicher) einen VM-Datenspeicher aus (in diesem Datenspeicher werden
die VM-Konfigurationsdaten gespeichert).
Weitere Informationen finden Sie unter „Definieren von technologieübergreifenden
logischen Servern“.
•
4.
Präsentieren Sie den Start-/Datenspeicher unter Verwendung der gleichen LUN- und
WWN-Werte den VM-Hosts in der Portabilitätsgruppe. Weitere Informationen finden
Sie unter „Speicherdefinition“.
Durchführen von physischen zu virtuellen und virtuellen zu physischen
Verschiebungen zur Überprüfung der Betriebssystemkonfiguration
Verschieben Sie den logischen Server von physisch zu virtuell und wieder zurück. Stellen
Sie nach jeder Verschiebung sicher, dass der logische Server erfolgreich gestartet wurde
und die statischen Netzwerkkonfigurationen wie erwartet auf die in der neuen Umgebung
vorhandenen Netzwerkschnittstellen angewandt werden. Weitere Informationen finden Sie
unter „Verschieben zwischen Technologien“.
HINWEIS: Wenn der logische Server zuerst zu einer Virtual Machine verschoben wird,
kann der Benutzer auf Wunsch zusätzliche Tools wie z. B. VMware-Tools zum Server
hinzufügen. In der Matrix Operating Environment enthält die erstellte VM-Konfiguration kein
virtuelles CD/DVD-Laufwerk. Sie können die VM-Konfiguration über die
VM-Verwaltungskonsole so abändern, das sie ein virtuelles CD/DVD-Laufwerk enthält.
5.
Konfigurieren der standortübergreifenden Verschiebung zwischen physischen und
virtuellen Zielen (Anwendungsbeispiel für die Notfall-Wiederherstellung)
Bei diesem Schritt wird mittels Matrix Recovery Management-Funktionen die
standortübergreifende Verschiebung zwischen physischen und virtuellen Zielen eingerichtet.
a. Erstellen Sie am lokalen Standort eine Array-Replikationsgruppe mit den vom logischen
Server für den Start-/Datenspeicher verwendeten logischen Einheiten und mit der
logischen Einheit, in der der VM-Datenspeicher enthalten ist (siehe Abbildung
Abbildung 10, „Erstellen einer Array-Replikationsgruppe“). Der VM-Datenspeicher kann
ausschließlich zum Speichern der VM-Konfiguration des logischen Servers verwendet
werden.
Abbildung 10 Erstellen einer Array-Replikationsgruppe
b.
Erstellen Sie am lokalen Standort eine Wiederherstellungsgruppe mit dem logischen
Server. Exportieren Sie die Matrix Recovery Management-Konfiguration in eine Datei.
Übersicht über die physisch-virtuelle technologieübergreifende Konfiguration
55
c.
d.
e.
f.
g.
h.
i.
Deaktivieren Sie den logischen Server am lokalen Standort, und führen Sie ein Failover
der Array-Replikationsgruppe am Remote-Standort durch.
Stellen Sie durch Durchführen der Verfahren zum Neuscannen des VM-Hosts und zum
Aktualisieren von Matrix OE Visualization sicher, dass der
VM-Konfigurationsdatenspeicher für die Konfiguration des logischen Servers zugänglich
ist.
Erstellen Sie eine Portabilitätsgruppe am lokalen Standort. Die Portabilitätsgruppe kann
physische Server, VMs oder eine Kombination aus beiden enthalten.
Erstellen Sie den logischen Wiederherstellungsserver mit den gleichen
Konfigurationswerten, die am lokalen Standort verwenden werden. Wandeln Sie die
Werte jedoch so ab, dass auf die LUN-/WWN-Werte des Remote-Speichers verwiesen
wird. Aktivieren Sie den logischen Server zu diesem Zeitpunkt nicht.
Importieren Sie mittels der exportierten Konfiguration von dem lokalen Standort die
Wiederherstellungsgruppe, die am lokalen Standort zur Aufnahme des logischen
Wiederherstellungsservers erstellt wurde.
Die Wiederherstellungsgruppe befindet sich im Wartungsmodus. Aktivieren Sie den
logischen Server auf einem VM-Host. Wenn in der Portabilitätsgruppe ein oder mehrere
physische Server verfügbar sind, führen Sie virtuelle zu physische und physische zu
virtuelle Verschiebungen durch. Überprüfen Sie in jeder Phase, ob der Startvorgang
erfolgreich war, und überprüfen Sie die Netzwerkkonfiguration wie in Schritt 4
beschrieben. Deaktivieren Sie den logischen Server, und verlassen Sie den
Wartungsmodus. Führen Sie ein Failover der Array-Replikationsgruppe zurück zum
lokalen Standort durch.
Führen Sie am lokalen Standort Verfahren zum erneuten Scannen und Aktualisieren
durch, und aktivieren Sie die logischen Server.
HINWEIS: Die Matrix Recovery Management-Standortkonfiguration kann so eingerichtet
werden, dass der logische Server auf Wunsch an einem Standort auf einem physischen
Server und am anderen Standort auf einem VM-Host aktiviert wird. Weitere Informationen
finden Sie unter „Festlegen des bevorzugten Failover-Zieltyps“.
Konfigurieren logischer Server für die Verschiebung zwischen unterschiedlichen
physischen Servern
Die Matrix Operating Environment ermöglicht eine Feinabstimmung der Liste von Failover-Zielen,
die als am geeignetsten für die Aktivierung eines DR-geschützten logischen Servers angesehen
werden. Die Fähigkeit zum Ändern von Zielattributen ist zur Sicherstellung eines erfolgreichen
Failovers hilfreich. Zielattribute befinden sich in den Daten, die von der Matrix Recovery
Management-Export/Import-Sequenz übertragen werden. Eine Erweiterung in der Zielliste am
exportierenden Standort wird am importierenden Standort reflektiert. Weitere Informationen
finden Sie unter „Zielattribute“.
Konfigurieren und Verwalten von portierbaren Betriebssystemabbildern
Die Mobilität von Server-Arbeitsauslastungen wird dadurch eingeschränkt, dass die meisten
Betriebssysteme zum Zeitpunkt der Installation für die spezifische Plattform konfiguriert werden,
auf der sie installiert werden. Es folgen einige Beispiele:
56
•
Installiert und konfiguriert werden nur die Gerätetreiber, die für die Zielplattform erforderlich
sind. Bei dem Versuch, die gleiche Betriebssysteminstanz auf einem anderen Server zu
starten, können Gerätefehler oder Systemausfälle auftreten.
•
Konfigurationseinstellungen, wie z. B. IP-Adressen oder Speicherbezeichner, sind
möglicherweise an bestimmte Geräten gebunden, deren Namen sich ändern können. So
kann das gleiche Subnetz z. B. auf einem Server an dem ersten NIC-Anschluss
angeschlossen sein, während es auf einem anderen Server am dritten NIC-Anschluss
angeschlossen ist.
Matrix Operating Environment unterstützt Mechanismen, mit denen ein Server-Abbild (logischer
Server) so vorbereitet werden kann, dass es auch bei Verschieben auf einen anderen physischen
oder virtuellen Server weiterhin funktioniert. Die folgenden Bereiche sind als Schlüssel zum
Erreichen dieses Ziels bestimmt worden:
•
Treiberinstallation
•
HBA-Konfiguration
•
NIC-Konfiguration
Zu diesem Zweck wurden folgende Tools entwickelt:
•
Portable Images Storage Assistant (PISA)
•
Portable Images Network Tool (PINT)
Portable Images Storage Assistant (PISA)
Wenn Windows auf einer an einem Server angeschlossenen SAN-LUN installiert wird, wird auf
dem betreffenden Server ein spezifischer Treiber für den HBA-Controller installiert. Wenn diese
LUN anschließend einer Virtual Machine auf einem Server neu zugewiesen wird, auf dem VMware
ESX ausgeführt wird, dann präsentiert ESX der Virtual Machine nur direkt angeschlossene
SCSI-Geräte. Windows ist aber weiterhin zur Verwendung des HBA-Controllers für den
Original-Server konfiguriert und kann daher nicht starten. PISA aktiviert die entsprechenden
Windows-Treiber, so dass Windows auf der Virtual Machine starten kann.
PISA erfordert, dass die Virtual Machine konfigurationsgemäß mittels der Raw Device
Mapping-Funktion in ESX eine LUN auf einem SAN als für die Virtual Machine verfügbares
Datenträgerlaufwerk konfiguriert. Das virtuelle System muss auch zum Emulieren des LSI Logic
Parallel-Speichertyps konfiguriert werden.
Der Treiber, der für einen ordnungsgemäßen Betrieb der virtuellen Version des LSI-Controllers
benötigt wird, ist in allen Versionen von Windows installiert, jedoch deaktiviert.
PISA wird zum Aktivieren der LSI-Unterstützung im Windows-Abbild verwendet.
PISA ist ein einfaches Befehlszeilen-Tool, das nur wenige Befehlszeilenoptionen akzeptiert. Es
muss nur einmal ausgeführt werden, nachdem Windows auf einem physischen Server installiert
wurde. Die vorgenommenen Änderungen sind beständig und müssen nicht wiederholt oder
zurückgesetzt werden. Eine wiederholte Ausführung von PISA hat jedoch keine negativen Folgen.
Mit PISA kann auch der von der Virtual Machine verwendete Treiber deaktiviert werden.
Die Befehlszeilen-Schnittstelle für PISA wird unten beschrieben. Die Optionen schließen sich
gegenseitig aus.
PISA wird nur auf unterstützten Versionen von Windows ausgeführt und erfordert, dass der
Benutzer der Benutzergruppe „Administrator“ angehört.
Verwendung: hppisa
-h, -?, -help Diese Information anzeigen
-e, -enable LSI-Treiber aktivieren
-d, -disable LSI-Treiber deaktivieren
Nachdem diese Änderungen vorgenommen wurden, kann das Betriebssystemabbild zwischen
physischen Servern und Virtual Machines verschoben werden.
Weitere Informationen zur Installation von PISA, den unterstützten Betriebssystemen und der
Betriebsanleitung finden Sie in der readme auf der Insight Control DVD unter C:\Program
Files\HP\Insight Control server migration\PI\PISA.
Konfigurieren und Verwalten von portierbaren Betriebssystemabbildern
57
Portable Images Network Tool (PINT)
PINT dient zur Behebung von Netzwerkproblemen, wenn ein Betriebssystemabbild von einem
physischen Server auf einen anderen oder von einem physischen Server auf eine VMware
ESX-Virtual Machine verschoben wird. Wenn ein Betriebssystem nach der Aktivierung eines
VC-gehosteten Servers am DR-Standort gestartet wird, kann es sein, dass PINT dem intendierten
NIC nicht die korrekte IP-Adresse zuweist. Wenn dies geschieht, konfigurieren Sie die
NIC-IP-Adresse manuell.
PINT pflegt eine Netzwerkkonfigurationsdatei, in der das Tool Informationen zu jeder
Netzwerkschnittstelle und deren Konfiguration auf einem Server erfasst. PINT verbleibt in einem
angehaltenen Zustand und wird nur bei Empfang eines der folgenden Ereignisse ausgeführt:
•
IP-Konfigurationsänderungs-Ereignis
PINT geht davon aus, dass alle Änderungen, die vorgenommen werden, während der Server
eingeschaltet ist und ausgeführt wird, vom Benutzer vorgenommene beabsichtigte
Änderungen sind. PINT zeichnet die Änderungen auf und aktualisiert seine
Konfigurationsdatei.
•
Stopp-Ereignis
Wenn der Benutzer den PINT-Dienst stoppt, empfängt PINT ein Ereignis, das es zum
Herunterfahren auffordert.
•
Benutzerbefehls-Ereignis
Wenn ein Benutzer Änderungen über die PINT-Befehlszeile vornimmt, wird PINT
benachrichtigt und verhält sich entsprechend.
HINWEIS: Wenn für eine NIC im Zielserver ein anderer Satz von Treibern benötigt wird, als
die auf dem Quellserver, müssen Sie die neuen Treiber installieren, bevor PINT auf dem Zielserver
verwendet wird.
Weitere Informationen zum PINT, einschließlich Installations- und Betriebsanleitungen, finden
Sie in der DateiPortable Images Network Tool (PINT) Windows readme oderPortable Images
Network Tool (PINT) Linux readme im PINT-Verzeichnis auf der Insight Control-DVD unter C:\
Programme Files\HP\Insight Control server migration\PI\PINT.
Konfigurieren und Verwalten von technologieübergreifenden logischen
Servern
Dieser Abschnitt geht auf Konfigurationsaufgaben und die Verwaltung technologieübergreifender
logischer Server in Matrix Operating Environment ein.
Portabilitätsgruppen
Beim Erstellen eines logischen Servers müssen Sie die Portabilität des logischen Servers
angeben. Hierzu wählen Sie eine Portabilitätsgruppe über die Identitätsseite des
Konfigurationsassistenten des logischen Servers aus. Nachdem ein logischer Server mit einer
bestimmten Portabilitätsgruppe verknüpft wurde, kann er auf ein beliebiges Zielsystem (physischer
Virtual Connect-Server oder Virtual Machine-Hypervisor) innerhalb der betreffenden
Portabilitätsgruppe verschoben werden. Die Ressourcen-Einschränkungen für logische Server,
wie z. B. CPU- und Speicheranforderungen sowie Netzwerk-/SAN-Konnektivität, werden nur in
Zusammenhang mit der Portabilitätsgruppe bewertet, der der logische Server zugeordnet ist.
Portabilitätsgruppen sind in zwei Klassen unterteilt: Standard und Benutzerdefiniert. Matrix
Operating Environment stellt je nach den innerhalb Ihres Rechenzentrums zu findenden
Ressourcen Standardportabilitätsgruppen bereit. Die Standardportabilitätsgruppen sind:
58
•
ESX: Alle ESX Hypervisoren
•
HYPERV: Alle Hyper-V Hypervisoren
•
Jede Virtual Connect-Domänengruppe: Jede VCDG verfügt über ihre eigene
Standardportabilitätsgruppe.
Sie können zudem benutzerdefinierte Portabilitätsgruppen erstellen, die die Portabilität eines
logischen Servers auf unähnliche Technologien ausweitet. So beispielsweise das Verschieben
von logischen Servern zwischen einem physischen Virtual Connect-Server und einem VMware
ESX-Virtual Machine-Host.
Benutzerdefinierte Portabilitätsgruppen werden durch Auswahl von Modify (Ändern)→Logical
Server Portability Groups (Portabilitätsgruppen für logische Server) in Matrix OE Visualization
(siehe Abbildung 11, „Portabilitätsgruppen für logische Server ändern“) definiert.
Abbildung 11 Portabilitätsgruppen für logische Server ändern
Wurden ein oder mehrere Ziele in Matrix OE Visualization ausgewählt, werden sie als potenzielle
Ziele bereitgestellt. Andernfalls werden alle Ressourcen präsentiert. Abbildung 12, „Auswählen
von Gruppenmitgliedern und -zielen“ enthält ein Beispiel des Bildschirms Modify Portability
Group (Portabilitätsgruppe ändern).
Konfigurieren und Verwalten von technologieübergreifenden logischen Servern
59
Abbildung 12 Auswählen von Gruppenmitgliedern und -zielen
Stellen Sie einen Namen und eine optionale Beschreibung für die Portabilitätsgruppe bereit. Der
Name wird zum Definieren der logischen Server verwendet. Der Satz von Gruppentypen wird
automatisch basierend auf den in der Portabilitätsgruppe eingefügten Zielen ausgewählt. Zu
gültigen Kombinationen der Ziele gehören:
•
Eine einzelne Virtual Connect Domain Group (VCDG).
•
Ein Satz von ESX-Hypervisoren.
•
Ein Satz von Hyper-V-Hypervisoren.
•
Ein Satz, der aus einem einzelnen VCDG plus einem Satz von ESX-Hypervisoren besteht.
Definieren von technologieübergreifenden logischen Servern
Zum Definieren eines technologieübergreifenden logischen Servers müssen Sie einen logischen
Server in einer Portabilitätsgruppe platzieren und dann den Speicher für den betreffenden
logischen Server definieren.
Platzieren eines logischen Servers in einer Portabilitätsgruppe
Ein logischer Server wird auf der Identitätsseite des logischen Servers in einer Portabilitätsgruppe
platziert. Die Platzierung kann während der Erstellung oder einer nachfolgenden Änderung des
logischen Servers erfolgen. Treffen Sie in der Liste Portability Group (Portabilitätsgruppe) eine
Auswahl (siehe Abbildung Abbildung 13, „Auswählen einer Portabilitätsgruppe“). Diese Liste
enthält die Standardportabilitätsgruppen sowie ggf. benutzerdefinierte Portabilitätsgruppen.
60
Abbildung 13 Auswählen einer Portabilitätsgruppe
Zum Anzeigen der Portabilitätsgruppe für einen logischen Server klicken Sie auf das Symbol
View movable logical server details (Details des verschiebbaren logischen Servers anzeigen)
in Matrix OE Visualization (siehe Abbildung 14, „Symbol „View movable logical server details“
(Details des verschiebbaren logischen Servers anzeigen)“).
Abbildung 14 Symbol „View movable logical server details“ (Details des verschiebbaren
logischen Servers anzeigen)
Die Details für diesen logischen Server erden wie in Abbildung Abbildung 15, „View logical server
details (Details zu logischen Servern anzeigen)“ dargestellt.
61
Abbildung 15 View logical server details (Details zu logischen Servern anzeigen)
Logische Server können mittels der in „Portabilitätsgruppen“ beschriebenen Methoden portierbar
gemacht werden.
HINWEIS: Sie müssen bestimmen, ob das innerhalb eines logischen Servers bereitgestellte
Betriebssystem auf einer Vielzahl von Plattformen wie gewünscht funktioniert. Wenn ein logischer
Server auf einem Plattformtyp bisher noch nicht aktiv war, zeigt Matrix Operating Environment
bei Verschiebungen und Aktivierungen für jedes Ziel dieses Typs auf der Seite „Target Selection“
(Zielauswahl) eine Warnung an. Sie müssen bestimmen, ob das Ziel gültig ist.
Speicherdefinition
Speicher kann über direkt an einen logischen Server gebundene Speicherpooleinträge oder
Speichereinträge definiert werden. Bei technologieübergreifenden logischen Servern muss der
Speicher auf SAN basieren. Dieser Ansatz verwendet die normale SAN-Start-Methode innerhalb
von Virtual Connect und nutzt die ESX Raw Disk Mapping (RDM)-Technologie, mit der Startund Daten-LUNs der Virtual Machine direkt präsentiert werden. Ein Beispiel finden Sie unter
Abbildung 16, „Speicherpooleinträge“ und Abbildung 17, „Speichereinträge“.
Abbildung 16 Speicherpooleinträge
62
Abbildung 17 Speichereinträge
Beim Definieren von Speicher für einen portierbaren logischen Server müssen Sie SAN Storage
Entry (SAN-Speichereintrag) auswählen. Um Flexibilität und eine Verschiebung zwischen
zugrunde liegenden Technologietypen zu ermöglichen, muss den an das Virtual
Connect-Serverprofil gebundenen WWNs sowie allen ESX VM-Hosts, die potenzielle Ziele für
den logischen Server sind, Speicher bereit gestellt werden. Speicherpooleinträge müssen in der
gleichen Portabilitätsgruppe erstellt werden, denen der bzw. die logischen Server angehören,
die den Speicher verwenden werden (siehe Abbildung Abbildung 18, „Verwalten von
Speicherpools“).
Abbildung 18 Verwalten von Speicherpools
Verschieben zwischen Technologien
Die Aktivierung und Verschiebung von technologieübergreifenden Servern wird auf die gleiche
Weise vollzogen, wie bei logischen Standard-Servern. Der Vorgang Unlike Move (Andersartige
Verschiebung) wird bei technologieübergreifenden logischen Servern verwendet, wenn auf einem
Server mit einer anderen zugrunde liegenden Technologie als der des vorherigen Zielhosts ein
63
Aktivierungs- (Activate) oder Verschiebungsvorgang (Move) ausgeführt werden soll. Der Betrieb
Unlike Move (Andersartige Verschiebung) wird in Abbildung 19, „Assign Logical Servers to
Target Hosts (Logische Server zu Zielhosts zuweisen)“ dargestellt.
Abbildung 19 Assign Logical Servers to Target Hosts (Logische Server zu Zielhosts
zuweisen)
Ziele für einen logischen Server werden aus der Portabilitätsgruppe des betreffenden logischen
Servers ausgewählt. Die Mitglieder der Portabilitätsgruppe werden dann weiter basierend auf
der Ressourcen-Verfügbarkeit gefiltert, einschließlich CPU- und Speicher-Ressourcen sowie
Netzwerk- und SAN-Konnektivität.
HINWEIS: Netzwerke in Virtual Connect müssen identisch nach ihren entsprechenden
Netzwerken (Port-Gruppen) auf ESX-Hypervisoren benannt werden. Durch Unterschiede im
Namen wird der Vorgang Unlike Move (Andersartige Verschiebung) an der Identifizierung von
Netzwerken mit ähnlicher Konnektivität gehindert.
Zielattribute
Mit Zielattributen für logische Server können Sie verfolgen, wo ein logischer Server aktiviert oder
wohin er verschoben wurde. Zielattribute bieten eine größere Anzahl von „am besten geeigneten“
Zielen, wo logische Server aktiviert oder verschoben werden können. Sie können die Zielattribute
auf einem logischen Server anzeigen oder ändern, indem Sie zuerst den logischen Server
auswählen und dann auf Modify (Ändern)→Logical Server Target Attributes (Zielattribute
für logische Server)→Manage (Verwalten) klicken (siehe Abbildung Abbildung 20, „Ändern
der Zielattribute von logischen Servern“).
64
Abbildung 20 Ändern der Zielattribute von logischen Servern
Zieltypen können ausgewählt und zu den Zielattributen des logischen Servers hinzugefügt oder
daraus entfernt werden. Durch Auswahl eines Servers aus der Liste unten und Klicken auf Add
(Hinzufügen) wird der mit den Ressourcen verknüpfte Servertyp der Liste der „am besten
geeigneten“ Ziele für den logischen Server hinzugefügt. Durch Auswahl eines Servertyps aus
der Liste Target Attributes Available to Remove (Zum Entfernen verfügbare Zielattribute)
und Klicken auf Remove (Entfernen) wird der angegebene Servertyp nicht mehr als „am besten
geeignet“ aufgeführt. Abbildung 21, „Zielattribute von einem logischen Server verwalten“ zeigt
den Bildschirm zur Verwaltung logischer Server-Zielattribute.
Abbildung 21 Zielattribute von einem logischen Server verwalten
Verschieben zwischen Blade-Typen
Logische Server mit Zielattributen bieten den Vorteil, dass die Logical Server
Management-Software beim Verschieben oder Aktivieren eines Servers mehr mögliche Ziele
identifizieren kann. Wie bei allen technologieübergreifenden logischen Servern sind Sie dafür
verantwortlich, die angemessene Funktionalität des logischen Servers auf verschiedenen
Plattformen sicherzustellen. Falls sich ein bestimmtes Ziel als nicht geeignet erweisen sollte, ist
es ohne Weiteres möglich, den betreffenden Zieltyp zu entfernen, um die Portabilität des logischen
Servers genauer zu beschreiben.
Verwalten von DR-geschützten technologieübergreifenden logischen
Servern in einer Matrix Recovery Management-Konfiguration
In diesem Abschnitt wird beschrieben, wie Sie Einstellungen für den Failover-Zieltyp für
DR-geschützte technologieübergreifende logische Server in einer Matrix Recovery
Management-Konfiguration festlegen.
Verwalten von DR-geschützten technologieübergreifenden logischen Servern in einer Matrix Recovery
Management-Konfiguration
65
Festlegen des bevorzugten Failover-Zieltyps
Während eines Standort-Failovers aktiviert Matrix Recovery Management für jeden logischen
Server, der mit Notfallschutz konfiguriert ist, einen ähnlich konfigurierten logischen Peer-Server
am Wiederherstellungsstandort. Zu diesem Zweck interagiert Matrix Recovery Management mit
der Matrix OE Logical Server Management-Funktion, um eine Liste geeigneter verfügbarer Ziele
zu bestimmen, und wählt das am besten geeignete Ziel zum Aktivieren des logischen Servers
aus.
Für einen technologieübergreifenden logischen Server kann die korrekte Liste verfügbarer Ziele
sowohl physikalische Server als auch VM-Host-Server enthalten. Matrix Recovery Management
besitzt die Einstellung Target type preferred (Bevorzugter Zieltyp) auf der
Konfigurationsregisterkarte Sites (Standorte). Dort können Sie den bevorzugten Zieltyp für die
einzelnen Standorte konfigurieren (siehe Abbildung 22, „Konfigurationsbildschirm „Sites
configuration“ (Standortkonfiguration) in Matrix Recovery Management“).
Abbildung 22 Konfigurationsbildschirm „Sites configuration“ (Standortkonfiguration) in
Matrix Recovery Management
Sie müssen auf dem CMS an jedem Standort den für alle Standorte bevorzugten Zieltyp angeben:
•
Wenn Sie als den für einen Standort bevorzugten Zieltyp Virtual (Virtuell) angeben, dann
werden alle technologieübergreifenden logischen Server, deren Wiederherstellungsgruppen
den betreffenden Standort vorziehen, während eines Aktivierungsvorgangs Activate am
betreffenden Standort auf VM-Hosts aktiviert. Ein physischer Server wird nur gewählt, wenn
keine VM-Hosts verfügbar sind.
•
Wenn Sie als den für einen Standort bevorzugten Zieltyp Physical (Physisch) angeben,
dann werden alle technologieübergreifenden logischen Server, deren
Wiederherstellungsgruppen den betreffenden Standort vorziehen, während eines
Aktivierungsvorgangs Activate am betreffenden Standort auf physischen Servern aktiviert.
Ein VM-Host wird nur gewählt, wenn keine physischen Server verfügbar sind.
Durch Angabe entsprechender bevorzugter Ziele für Standorte können Sie eine Konfiguration
einrichten, bei der DR-geschützte technologieübergreifende logische Server an einem Standort
66
auf physischen Servern und am anderen Standort auf VM-Hosts ausgeführt werden. So möchten
Sie vielleicht, dass am bevorzugten Standort DR-geschützte technologieübergreifende logische
Server auf physischen Servern ausgeführt werden, bei einem Failover auf den sekundären
Standort aber auf VM-Hosts.
Verwalten von DR-geschützten technologieübergreifenden logischen Servern in einer Matrix Recovery
Management-Konfiguration
67
6 Probleme, Einschränkungen und vorgeschlagene
Maßnahmen
In diesem Kapitel werden die Probleme und Einschränkungen dieser Version in folgenden
Kategorien aufgeführt:
Einschränkungen
Einschränkungen der implementierten Funktionen und
Leistungsmerkmale dieser Version
Bedeutende Probleme
Probleme, die sich erheblich auf die Funktionalität und
Brauchbarkeit dieser Version auswirken können.
Kleinere Probleme
Probleme, die möglicherweise erkennbar sind, sich aber nicht
wesentlich auf die Funktionalität oder Brauchbarkeit auswirken.
Einschränkungen
•
Für das Importieren von virtuellen (VM-gehosteten) IO-Diensten ist zuvor ein manuelles
Failover des Speichers erforderlich.
•
Eine Wiederherstellungsgruppe kann aus ausschließlich logischen Servern oder IO-Diensten,
jedoch nicht aus einer Kombination aus logischen Servern und IO-Diensten bestehen.
•
IO-Dienste mit einer Kombination aus physischen (VC-gehosteten) und virtuellen
(VM-gehosteten) logischen Servern werden nicht unterstützt.
•
IO-Dienstreplikate sind nicht flexibel anpassbar (Hinzufügen von Datenträgern, Hinzufügen
und Entfernen von Servern).
•
IO-Dienstreplikate können nicht importiert werden, um primäre IO-Dienste am bevorzugten
Standort in einer Matrix Recovery Management-Konfiguration zu erstellen.
Eingeschränkter Hyper-V-Support für bidirektionale Konfiguration
Für bidirektionale Failover-Konfigurationen müssen die in Wiederherstellungsgruppen
konfigurierten logischen Server und IO-Dienste, deren lokaler Standort als bevorzugter Standort
definiert ist, über Lese-/Schreibzugriff für den am lokalen Standort verknüpften Speicher verfügen.
Die in Wiederherstellungsgruppen konfigurierten logischen Server und IO-Dienste, deren
Remote-Standort als bevorzugter Standort definiert ist, können über Schreibzugriff für den am
lokalen Standort verknüpften Speicher verfügen. Microsoft setzt voraus, dass der gesamte
Speicher (Cluster-Freigabe-Volume-Datenträger oder Cluster-Datenträger) in den Clustern, in
denen die logischen Server aktiviert werden, über Lese-/Schreibzugriff verfügt.
Vorgeschlagene Maßnahme
Microsoft hat einen Hotfix bereitgestellt. Lesen Sie den Microsoft Knowledge Base-Artikel, und
laden Sie den Hotfix unter http://support.microsoft.com/?id=2720218 herunter.
Keine automatische Synchronisation der Konfiguration zwischen Standorten
Die Konfiguration von Matrix Recovery Management an zwei separaten Standorten wird nicht
automatisch synchronisiert. Matrix Recovery Management stellt jedoch Funktionen zum
Exportieren und Importieren der Konfiguration zur Verfügung, mit denen diese Aufgabe erleichtert
wird.
Vorgeschlagene Maßnahmen
Die Matrix Recovery Management-Onlinehilfe leitet Sie bei den Export- und Importvorgängen
an.
68
Probleme, Einschränkungen und vorgeschlagene Maßnahmen
Matrix Recovery Management-Auftragsinformationen werden unter bestimmten
Umständen nicht beibehalten
Informationen zu bereits ausgeführten Matrix Recovery Management-Aufträgen werden nicht
beibehalten, wenn die Matrix Recovery Management-Konfiguration mit dem Dienstprogramm
Insight mxsync wiederhergestellt wird.
Kleinere Probleme
Firefox-Browser kann nicht für Standort-Exportvorgänge verwendet werden
Der Firefox-Browser kann aufgrund eines Fehlers in Adobe Flash Player 10.3 nicht zum Ausführen
der Exportvorgänge für Matrix Recovery Management-Standortkonfigurationen verwendet werden.
Weitere Informationen finden Sie unter Fehler 2980517 auf der Adobe-Website.
Verwenden Sie Internet Explorer 8 oder höher zum Ausführen von Exportvorgängen für Matrix
Recovery Management-Standortkonfigurationen.
Erforderliche ESX-Konfigurationseinstellung, damit VMFS-Datenspeicher von durch
Matrix Recovery Management verwalteten logischen Servern am Remote-Standort
sichtbar sind
Unter den folgenden Bedingungen erfordert Matrix Recovery Management eine bestimmte
ESX-Konfigurationseinstellung, damit die Signatur eines VMFS-Datenspeichers beibehalten wird
und am Remote-Standort sichtbar ist:
•
Am lokalen oder am Remote-Standort befinden sich asymmetrische P6000 Continuous
Access Software-Array-Modelle.
•
Am lokalen oder am Remote-Standort verwenden Sie P9000 Continuous Access
Software-Speicherarrays.
•
Sie verwenden 3PAR StoreServ-Speichersysteme.
•
Stellen Sie für ESX3.X Hosts Lvm.DisallowSnapshotLun über Configuration
(Konfiguration) Advanced Settings (Erweiterte Einstellungen) auf 0 ein.
•
Um bei ESX4.X Hosts den Datenspeicher des lokalen Standorts mit einer vorhandenen
Signatur bereitzustellen, beziehen Sie sich auf das Kapitel „Mount a VMFS Datastore with
an Existing Signature“ im ESX Configuration Guide Update 1, ESX 4.0, vCenter Server 4.0,
verfügbar unter http://www.vmware.com/pdf/vsphere4/r40_u1/
vsp_40_u1_esx_server_config.pdf. Zusätzliche Informationen finden Sie in der VMware
Knowledge Base unter http://kb.vmware.com/kb/1015986.
Aktivierungs- oder Deaktivierungsauftrag bleibt hängen
Wenn Matrix OE Logical Server Management eine Aufgabe, die durch einen Activate (Aktivieren)oder Deactivate (Deaktivieren)-Vorgang in Matrix Recovery Management eingeleitet wurde,
aufgrund von zugrunde liegenden Stapelproblemen nicht durchführen kann, bleibt der Matrix
Recovery Management-Betrieb hängen.
Vorgeschlagene Maßnahmen:
Starten Sie den Logical Server Automation-Dienst über den CMS neu
(Windows-Verwaltungsprogramme→Dienste und Anwendungen→Dienste), und führen Sie
den Matrix Recovery Management-Vorgang erneut durch.
Kleinere Probleme
69
Identische Konfiguration von logischen Servern zwischen Standorten
Logische lokale und logische Wiederherstellungsserver müssen mittels Matrix OE Visualization
(bis auf den Namen des logischen Servers) mit identischen Parametern konfiguriert werden. Die
Werte der Attribute, die sich nicht auf den Konfigurationsbildschirmen der Matrix Recovery
Management-Benutzeroberfläche befinden, stimmen zwischen dem lokalen und dem
Remote-Standort möglicherweise nicht überein.
Beispiele für eine identische Konfiguration von logischen Servern zwischen Standorten sind:
•
MAC-Adresse: Bei VC-gehosteten logischen Servern wird die MAC-Adresse über Virtual
Connect oder Virtual Connect Enterprise Manager zugewiesen. Da am lokalen Standort und
am Remote-Standort unzusammenhängende Adressbereiche verwendet werden müssen,
ist die MAC-Adresse für einen logischen Server am lokalen Standort eine andere als die für
den entsprechenden logischen Sever am Wiederherstellungsstandort.
•
HBA WWN: Bei einem VC-gehosteten logischen Server wird die HBA WWN-Adresse durch
Virtual Connect oder Virtual Connect Enterprise Manager zugewiesen. Da am lokalen
Standort und am Remote-Standort unzusammenhängende Adressbereiche verwendet
werden müssen, ist die HBA-WWN-Adresse für einen logischen Server am lokalen Standort
eine andere als die für den entsprechenden logischen Server am Wiederherstellungsstandort.
•
BIOS UUID: Es ist kein unterstützter Mechanismus zur Beibehaltung der UUID für einen
VC-gehosteten logischen Server vorhanden, während er über Standorte hinweg verschoben
wird (anders als bei standortinternen Verschiebungen).
•
BIOS-Seriennummer: Es ist kein unterstützter Mechanismus zur Beibehaltung der
Seriennummer für einen VC-gehosteten logischen Server vorhanden, während er über
Standorte hinweg verschoben wird (anders als bei standortinternen Verschiebungen).
•
Array LUNs: Auf einem VC-gehosteten logischen Server ist das Windows- oder
Linux-Betriebssystem dafür zuständig, dass die ihnen präsentierten LUNs korrekt den auf
dem Betriebssystem konfigurierten Volumes und Dateisystemen zugeordnet werden. Bei
einem VM-gehosteten logischen Server muss das ESX-Betriebssystem auf dem Host die
präsentierten LUNs dem durch den VM-gehosteten logischen Server verwendeten VMFS
zugeordnet werden. Obwohl die Betriebssysteme über entsprechende integrierte
Mechanismen verfügen, empfiehlt Hewlett Packard Enterprise als beste Vorgehensweise,
die LUN-Nummern für über Standorte hinweg übereinstimmende Datenträger gleich zu
halten.
Beurteilen Sie die Auswirkung dieser Diskrepanzen auf laufende Lizenzierungsabkommen, die
für das Betriebssystem und Anwendungen, die auf DR-geschützten logischen Servern ausgeführt
werden.
Eine RAID Manager-Instanz pro HPE P9000 Storage Management Server und eine
RAID Manager-Instanz pro HPE P9000 Gerätegruppe
Jeder in Matrix Recovery Management konfigurierte P9000 Continuous Access
Software-Speicherverwaltungsserver verfügt über nur eine P9000 RAID Manager Software-Instanz
zur Verwaltung der P9000-Gerätegruppen. Jede in Matrix Recovery Management konfigurierte
P9000 Continuous Access Software-Speicherreplikationsgruppe wird von nur einer P9000 RAID
Manager Software-Instanz an jedem Standort verwaltet.
Vorgeschlagene Maßnahmen:
Für dieses Problem ist keine Abhilfe vorhanden.
70
Probleme, Einschränkungen und vorgeschlagene Maßnahmen
Die CLX/HPE P9000 Software muss auf einem separaten Windows-System installiert
werden
Zusätzlich zu dem Central Management Server sollte ein separates Windows-System mit
CLX/HPE P9000 und kompatibler P9000 RAID Manager Software zur Verwaltung der
verschiedenen P9000-Gerätegruppen konfiguriert werden, die in eine Matrix Recovery
Management-Konfiguration eingeschlossen werden sollen.
Nur jeweils ein aktiver Matrix Recovery Management-Konfigurationsvorgang
Wenn mehrere Benutzer versuchen, Konfigurationsvorgänge in Matrix Recovery Management
auszuführen, ist nur ein Vorgang erfolgreich. Alle anderen Konfigurationsvorgänge erhalten eine
Fehlermeldung, die besagt, dass derzeit ein anderer Konfigurationsvorgang läuft.
Der Vorgang zum Löschen von Standorten in Matrix Recovery Management entfernt
keine HPE SIM-Tools
Wenn ein Standort-Löschvorgang bei konfigurierten P9000 Continuous
Access-Speicherverwaltungsservern durchgeführt wird, dann werden die SIM-Tools zur Verwaltung
der P9000-Speicherreplikation auf dem lokalen Speicherverwaltungsserver nicht gelöscht.
Der Befehl mxtool kann zum Entfernen der SIM-Tools manuell ausgeführt werden. Die Namen
der Tools sind Insight Recovery_Failover und Insight Recovery_Group validation.
Wenn der Name des Speicherverwaltungsservers beispielsweise stgmgmtA.cup.hp.com
lautet, dann ergeben sich für die Tools die Namen STGMGMTA_CUP_HP_COM_Insight
Recovery_Failover und STGMGMTA_CUP_HP_COM_Insight Recovery_Group
validation.
Verwenden von SPM mit Remotekopie-Gruppenanforderung
Wenn Sie SPM mit Remotekopie-Gruppenanforderung verwenden, um Speicher zu erstellen,
kann der Speicher nur am lokalen Standort bearbeitet werden, wenn er primär ist
(Lese-/Schreibzugriff auf Speicher). Speicher kann nur vom lokalen Standort exportiert werden,
wenn er primär ist, und kann nur am Remote-Standort importiert werden, wenn es sich um eine
Sicherungskopie handelt (Datenträger sind schreibgeschützt).
Kleinere Probleme
71
7 Fehlerbehebung
Dieses Kapitel enthält Informationen zur Fehlerbehebung in den folgenden Kategorien:
•
„Fehlerbehebung der Konfiguration“ (Seite 72)
•
„Konfigurationsfehlermeldungen“ (Seite 75)
•
„Warnmeldungen“ (Seite 79)
•
„Fehlerbehebung bei Matrix Recovery Management-Aufträgen“ (Seite 79)
•
„Failover-Fehlermeldungen“ (Seite 83)
•
„Matrix Recovery Management-Protokolldateien“ (Seite 84)
•
„Fehlerbehebung bei DR-geschützten IO-Diensten“ (Seite 85)
Fehlerbehebung der Konfiguration
Notieren Sie sich zur Fehlerbehebung von Matrix Recovery Management-Konfigurationsvorgängen
alle angezeigten Fehlermeldungen, und schlagen Sie in diesem Kapitel relevante Informationen
nach. Zusätzliche Informationen sind auch den lsdt_web.log-Protokolldateien zu entnehmen.
In diesem Abschnitt werden die folgenden zu behebenden Fehler angesprochen:
•
Standort-Informationen können nicht hinzugefügt oder bearbeitet werden
Mögliche Ursachen sind:
•
◦
Der angegebene Name des lokalen oder Remote-CMS ist nicht gültig (kein
vollqualifizierter Domänenname oder nicht im DNS auffindbar).
◦
Der Name des lokalen oder Remote-CMS enthält keinen vollqualifizierten Namen, der
mit dem lokalen Host verknüpft ist.
Informationen des Speicherverwaltungsservers können nicht hinzugefügt oder
bearbeitet werden
◦
Der Speicherverwaltungsserver wird auf der Matrix Operating
Environment-Benutzeroberfläche nicht erkannt.
◦
Die auf der Matrix Operating Environment-Benutzeroberfläche zum
Speicherverwaltungsserver gehörigen Anmeldedaten enthalten nicht den
Benutzernamen, der als Teil einer hinzugefügten oder bearbeiteten
Speicherverwaltungsserver-Konfiguration bereitgestellt wurde.
◦
Die Matrix Operating Environment-Benutzeroberfläche kann nicht mit dem
Speicherverwaltungsserver kommunizieren.
Ein Kommunikationsfehler mit Speicherverwaltungsservern lässt sich möglicherweise darauf
zurückführen, dass Open-SSH nicht auf dem Zielsystem installiert oder konfiguriert ist.
•
HPE P6000 Storage Management Server kann nicht hinzugefügt oder geändert
werden
72
◦
Der CIMOM Server wird auf dem Speicherverwaltungsserver nicht ausgeführt.
◦
Der CIMON Server ist zur Verwendung mit einem anderen Port als dem Port konfiguriert,
der für Verfahren zum Hinzufügen oder Bearbeiten angegeben wurde.
◦
Der angegebene Benutzer besitzt keine gültige Anmeldung auf dem
Speicherverwaltungsserver mit angemessenen Berechtigungen.
Fehlerbehebung
•
HPE P6000 Storage Replication Group kann nicht hinzugefügt oder bearbeitet
werden
◦
•
Matrix Recovery Management kann keine Speicherreplikationsgruppen-Informationen
von Command View-Servern zum Validieren der vom Benutzer bereitgestellten
Speicherreplikationsgruppen-Informationen anfordern.
HPE P9000 Storage Replication Group kann nicht hinzugefügt oder bearbeitet
werden
•
◦
Die Speicherreplikationsgruppe ist nicht zur Verwaltung durch RAID-Manager-Instanzen
konfiguriert.
◦
Der RAID Manager-Dienst wird auf lokalen Speicherverwaltungsserver nicht ausgeführt.
◦
Die für die Speicherreplikationsgruppe eingegebenen Parameter (lokales Array,
Remote-Array, Seriennummer und Replikationsmodus) stimmen nicht mit den
Speicherreplikationsgruppen-Informationen auf dem Datenträger überein.
HPE 3PAR Storage StoreServ-Speicherverwaltungsserver kann nicht hinzugefügt
oder geändert werden
•
◦
Die Kennwortdatei für das 3PAR StoreServ-Speichersystem fehlt im Verzeichnis
/storage/3par/conf im Matrix Recovery Management-Installationsverzeichnis.
◦
Das Kennwort für das 3PAR StoreServ-Speichersystem wurde seit dem Erstellen der
Kennwortdatei geändert.
◦
Der Hostname auf der Registerkarte „Storage Management Server“
(Speicherverwaltungsserver) im Matrix Recovery Management ist nicht der FQDN.
Matrix Recovery Management stürzt ab, wenn nach einer Aktualisierung der HPE
3PAR StoreServ-CLI- und/oder CLX-Versionen Speicherverwaltungsserver
hinzugefügt werden
Zu den möglichen Ursachen gehören:
Wenn ein neues Zertifikat nach einer Aktualisierung nicht akzeptiert wurde, kann CLI.exe
oder CLX3PARCONFIG.exe hängen bleiben.
Für die HPE 3PAR StoreServ-CLI
Verfahren Sie zur Behebung des voranstehenden Problems bei der 3PAR-CLI wie folgt:
1. Brechen Sie den cli-Vorgang in Windows ab.
2. Öffnen Sie die 3PAR-CLI manuell in Windows.
3. Akzeptieren Sie das Zertifikat, das in die CLI-Ausnahmeliste aufgenommen werden
soll, und fügen Sie es hinzu.
Für HPE 3PAR StoreServ-CLX:
Öffnen Sie die 3PAR-CLX/-CLI manuell, und fügen Sie die Speicherarrays hinzu. Mit dem
folgenden Befehl können Sie alle Arrays auf einmal hinzufügen:
CLX3PARCONFIG ARRAY <Optionen>
wobei <Optionen> =
/ADD
Fehlerbehebung der Konfiguration
73
[{NAME=<Array-Netzwerkname|Array-IP-Adresse> PWF=<Pfad der
Kennwortdatei>}] [{NAME=<Array-Netzwerkname|Array-IP-Adresse>
PWF=<Pfad der Kennwortdatei>}...]
/REMOVE
[{NAME=<Array-Netzwerkname|Array-IP-Adresse>}]
[{NAME=<Array-Netzwerkname|Array-IP-Adresse>}...]
/MODIFY
[{NAME=<Array-Netzwerkname|Array-IP-Adresse>}] [PWF=<abgeänderter
Standort der Kennwortdatei>]
•
HPE 3PAR StoreServ-Speicherreplikationsgruppe kann nicht hinzugefügt oder
bearbeitet werden
•
◦
Die Speicherreplikationsgruppe ist nicht zur Verwaltung mit 3PAR
StoreServ-Remotekopie konfiguriert.
◦
Die folgenden für die Speicherreplikationsgruppe eingegebenen Informationen können
mit der 3PAR StoreServ-Speichersystemkonfiguration nicht validiert werden:
–
Volume-Gruppenname auf dem lokalem 3PAR StoreServ-Speichersystem
–
Volume-Gruppenname auf 3PAR StoreServ-Remote-Speichersystem
–
Remotekopie-Gruppenname des lokalen Arrays
–
Remotekopie-Gruppenname des Remote-Arrays
–
Seriennummer des lokalen 3PAR StoreServ-Speichersystems
–
Seriennummer des 3PAR StoreServ-Remote-Speichersystems
–
Replikationsmodus
Die Konfiguration logischer Server in Matrix Recovery Management ist nicht
einheitlich mit der Konfiguration logischer Server in Matrix OE Logical Server
Management
•
◦
Der HPE Logical Server Automation-Dienst wurde nicht ausgeführt, als die
Wiederherstellungsgruppen in Matrix Recovery Management konfiguriert wurden.
◦
Der logische Server wurde aktiv verwaltet, als die Matrix Recovery
Management-Konfiguration aufgerufen wurde (Änderung logischer Server, Aktivierung
logischer Server und Deaktivierung logischer Server war im Gange).
Kein Konfigurationsvorgang kann ausgeführt werden
•
◦
Der Vorgang Activate (Aktivieren), Deactivate (Deaktivieren) oder Import (Importieren)
wird durchgeführt.
◦
Möglicherweise wird derzeit ein anderer Konfigurationsvorgang durchgeführt.
Speicherverwaltungsserver können nicht im Rahmen eines Importvorgangs importiert
werden
◦
74
Der Speicherverwaltungsserver wurde auf der Matrix Operating
Environment-Benutzeroberfläche nicht erkannt.
Fehlerbehebung
•
◦
Die mit dem Speicherverwaltungsserver verknüpften Anmeldedaten enthalten nicht den
in der Matrix Recovery Management-Konfiguration am lokalen Standort angegebenen
Benutzernamen.
◦
Die Matrix Operating Environment-Benutzeroberfläche kann nicht mit dem in der Matrix
Recovery Management-Konfiguration am lokalen Standort angegebenen
Speicherverwaltungsserver kommunizieren.
Importvorgang fehlgeschlagen
•
◦
Die Importdatei ist nicht gültig.
◦
Der Logical Server Automation-Dienst wird nicht ausgeführt.
◦
Es befanden sich keine logischen Wiederherstellungsserver zum Zeitpunkt des Imports
in einem aktiven Zustand.
Bei der Verwendung von nicht wiederherstellbaren IO-Diensten schlagen
Flex-Up-Server-/Flex-Up-Datenträger-Anforderungen und Anforderungen zum
Hinzufügen von Datenträgern fehl und werden angehalten, und der Vorgang kann
nicht abgeschlossen werden
Zu den möglichen Ursachen gehören:
Sie haben das Flag Disaster Recovery Enabled (Disaster Recovery-fähig) möglicherweise
manuell für automatisch erstellte SPEs aktiviert. Deaktivieren Sie das Flag Disaster Recovery
Enabled (Disaster Recovery-fähig), und versuchen Sie es erneut.
Konfigurationsfehlermeldungen
Dieser Abschnitt listet Fehlermeldungen bezüglich der Konfiguration von Matrix Recovery
Management auf.
Fehlermeldung
Fehler: Matrix Recovery Management wird gerade stillgelegt. Derzeit
ausgeführte Vorgänge können abgeschlossen werden. Zu diesem Zeitpunkt
sind keine Konfigurationsänderungen erlaubt.
Ursache
Der Benutzer versucht, die Konfiguration von Matrix Recovery Management zu ändern, während
das System stillgelegt wird.
Aktion
Warten Sie, bis die Stilllegung von Matrix Recovery Management aufgehoben wurde, und
versuchen Sie die Konfigurationsänderung erneut.
Fehlermeldung
Fehler: Matrix Recovery Management ist stillgelegt. Zu diesem Zeitpunkt
sind keine Konfigurationsänderungen erlaubt.
Ursache
Der Benutzer versucht, die Konfiguration von Matrix Recovery Management zu ändern, nachdem
das System stillgelegt wurde.
Aktion
Warten Sie, bis die Stilllegung von Matrix Recovery Management aufgehoben wurde, und
versuchen Sie die Konfigurationsänderung erneut.
Fehlermeldung
You are not authorized to access this page.
Ursache
Der Benutzer ist nicht zur Verwendung von Matrix Recovery Management befugt oder der lokale
CMS-Hostname kann nicht nach DNS aufgelöst werden.
Aktion
Überprüfen Sie die SIM- und Matrix Recovery-Protokolldateien auf Details. Wenden Sie sich dann
an den Netzwerkadministrator, um den lokalen CMS-Hostnamen zum DNS hinzuzufügen.
75
76
Fehlermeldung
Cannot verify the host name specified.
Ursache
Der für den CMS am lokalen oder am Remote-Standort angegebene hostname befindet sich
nicht auf dem DNS.
Aktion
Vergewissern Sie sich, dass für jeden CMS ein gültiger DNS-Eintrag mit einem vollqualifizierten
Domänennamen vorhanden ist.
Fehlermeldung
Cannot create/edit the site information.
Ursache
Der für den CMS angegebene hostname enthält keinen vollqualifizierten Domänennamen, der
mit dem lokalen CMS verknüpft ist.
Aktion
Stellen Sie sicher, dass der CMS für den lokalen Standort die vollqualifizierte Domäne des lokalen
Hosts besitzt.
Fehlermeldung
Storage Management Server not discovered by CMS. Discover server and
retry.
Ursache
Jeder in Matrix Recovery Management zu konfigurierende Speicherverwaltungsserver muss auf
der Matrix Operating Environment-Benutzeroberfläche mit entsprechenden angegebenen
Anmeldedaten ermittelt werden.
Aktion
Stellen Sie sicher, dass der Speicherverwaltungsserver auf der Matrix Operating
Environment-Benutzeroberfläche ermittelt wird. Ermitteln Sie den Server andernfalls über Options
(Optionen)→Discovery (Ermittlung) auf der Matrix Operating Environment-Benutzeroberfläche.
Fehlermeldung
Fehler: Ungültiger Benutzername und/oder Domänenname der
Speicherverwaltung.
Ursache
Die auf der Matrix Operating Environment-Benutzeroberfläche gespeicherten Anmeldedaten für
den Server enthalten nicht den Benutzernamen, der im Rahmen des Vorgangs zur Konfiguration
des Speicherverwaltungsservers in Matrix Recovery Management angegeben wurde.
Aktion
Stellen Sie für den angegebenen Server sicher, dass die auf der Matrix Operating
Environment-Benutzeroberfläche gespeicherten Anmeldedaten die Anmeldedaten für den
angegebenen Benutzernamen enthalten.
Fehlermeldung
Fehler: Failed to add/modify EVA Storage Management Server. Credential
for Storage Management Server does not exist. Check input and retry.
Ursache
Die Angaben für hostname, Portnummer und Benutzernamen können nicht überprüft werden.
Aktion
Stellen Sie sicher, dass es sich bei dem durch hostname identifizierten Server um einen P6000
Command View-Server handelt. Vergewissern Sie sich, dass CIMOM auf dem Command
View-Server zur Verwendung der angegebenen Portnummer konfiguriert ist und dass der
angegebene Benutzername ein gültiger Benutzer auf dem betreffenden Server ist.
Fehlermeldung
Unable to add/edit Storage Management Server
Ursache
Der Server ist nicht korrekt zur Verwendung durch die Matrix Operating
Environment-Benutzeroberfläche konfiguriert.
Aktion
Stellen Sie sicher, dass Open SSH auf dem Server installiert und konfiguriert ist und dass die
verwalteten Knoten und CMS vertrauenswürdig sind. Dazu kann Configure
(Konfigurieren)→Configure or Repair Agents (Agents konfigurieren oder reparieren) auf
der Matrix Operating Environment-Benutzeroberfläche ausgeführt werden.
Fehlerbehebung
Fehlermeldung
Unable to add/edit EVA Storage Replication Group
Ursache
Es können keine Informationen zur Speicherreplikationsgruppe vom P6000 Command View-Server
abgerufen werden.
Aktion
Bestätigen Sie, dass die Speicherreplikationsgruppe auf Arrays vorhanden ist, die beim Hinzufügen
oder Bearbeiten der Konfiguration der P6000-Speicherreplikationsgruppe in Matrix Recovery
Management aufgelistet wurden. Stellen Sie sicher, dass die P6000 Arrays durch P6000 Command
View-Server verwaltet werden.
1. Bestätigen Sie, dass die SIM-S-Komponente von P6000 Command View auf dem P6000
Command View-Server installiert ist. Informationen zum Installieren von SMI-S finden Sie
imP6000 Command View Software Installationshandbuch unter http://www.hpe.com/info/
P6000-CommandView-manuals.
2. Überprüfen Sie, ob die während der Konfiguration des Speicherverwaltungsservers in Matrix
Recovery Management angegebene Portnummer der auf dem P6000 Command View-Server
konfigurierten WBEM-Portnummer entspricht (z. B. 5989). Weitere Informationen finden Sie
im CIMOM-Serverkonfigurationsabschnitt imP6000 Command View Software Installation Guide
( P6000 Command View Software Installationshandbuch).
3. Aktualisieren Sie die CIM-Datenbank des P6000 Command View-Servers durch Ausgabe des
Aktualisierungsbefehls. Details zum Befehl Discoverer finden Sie im Abschnitt „Configuring
SMI-S EVA to Discover Command View EVA Arrays“ imP6000 Command View Software
Installation Guide (P6000 Command View Software Installationshandbuch).
4. Stellen Sie sicher, dass der P6000 Command View Software-Dienst und der CIMOM-Dienst
ausgeführt werden. Starten Sie bzw. führen Sie einen Neustart dieser Dienste durch.
Fehlermeldung
Unable to add/edit XP Storage Replication Group
Ursache
Matrix Recovery Management kann keine Informationen zur Speicherreplikationsgruppe über
den RAID-Manager abrufen, oder die abgerufenen Informationen stimmen nicht mit den
Informationen überein, die beim Hinzufügen oder Bearbeiten der Konfiguration der
P9000-Speicherreplikationsgruppe in Matrix Recovery Management bereitgestellt wurden.
Aktion
Stellen Sie sicher, dass die RAID-Manager-Instanz auf dem lokalen Speicherverwaltungsserver
ausgeführt wird. Führen Sie im Installationsverzeichnis des RAID Manager pairdisplay –g
<Gruppenname> aus (wobei <Gruppenname> der Name der hinzuzufügenden oder zu
bearbeitenden Speicherreplikationsgruppe ist). Auf diese Weise können Sie feststellen, ob die
Speicherreplikationsgruppe konfiguriert ist und ob die lokale Array-Seriennummer, die
Remote-Array-Seriennummer und der Speicherreplikationstyp mit den Daten übereinstimmen,
die beim Hinzufügen oder Bearbeiten der Konfiguration der P9000-Speicherreplikationsgruppe
in Matrix Recovery Management bereitgestellt wurden.
Fehlermeldung
Unable to add CLX credentials for this HP 3PAR Storeserv Storage system.
Ursache
Die verschlüsselte Kennwortdatei für das entsprechende 3PAR StoreServ-Speichersystem ist
inkorrekt oder das Kennwort für das Speichersystem wurde geändert und kann daher nicht anhand
der bestehenden Kennwortdatei authentifiziert werden.
Aktion
Stellen Sie sicher, dass die korrekte Kennwortdatei im Verzeichnis /storage/3par/conf
vorhanden ist, in dem Matrix Recovery Management für das lokale und das 3PAR
StoreServ-Remote-Speichersystem installiert ist. Erstellen Sie die Kennwortdateien gegebenenfalls
neu. Wiederholen Sie den Vorgang zum Hinzufügen (Add) des Speicherverwaltungsservers.
Fehlermeldung
Fehler: Unable to locate CLX/3PAR install path. Check if CLX/3PAR is
installed on the system.
Ursache
Die erforderliche3PAR StoreServ Cluster Extension Software ist nicht installiert bzw. die
CLI-Version stimmt nicht mit der CLI-Version in der Datei hp_ir.properties überein.
Aktion
Installieren Sie nur die CLI-Komponente der 3PAR StoreServ Cluster Extension Software, indem
Sie die benutzerdefinierten Installationsoptionen verwenden, oder aktualisieren Sie die Eigenschaft
INFORM_CLI_VERSION in conf\hp_ir.properties im Matrix Recovery
Management-Installationsverzeichnis auf dem CMS.
77
78
Fehlermeldung
Unable to validate this 3PAR Storage Replication Group.
Ursache
Die eingegebenen Parameter können nicht anhand der auf dem 3PAR StoreServ-Speichersystem
konfigurierten Parameter überprüft werden.
Aktion
Überprüfen und korrigieren Sie die Parameter (einschließlich Volume-Gruppenname auf dem
lokalen 3PAR StoreServ-Speichersystem, Volume-Gruppenname auf dem 3PAR
StoreServ-Remote-Speichersystem, Remotekopie-Gruppenname des lokalen Arrays,
Remotekopie-Gruppenname des Remote-Arrays, Seriennummern des lokalen und des 3PAR
StoreServ-Remote-Speichersystems und Replikationsmodus), und wiederholen Sie den Vorgang.
Fehlermeldung
Matrix Recovery Management-Vorgänge können nicht ausgeführt werden, da
derzeit ein Matrix Recovery Management-Auftrag läuft oder ein anderer
Matrix Recovery Management-Vorgang im Gange ist.
Ursache
Wenn der Vorgang Activate (Aktivieren) oder Deactivate (Deaktivieren) derzeit ausgeführt wird,
ist kein Konfigurationsvorgang zulässig, da der Auftrag derzeit läuft. Während ein Vorgang zur
Konfiguration von Matrix Recovery Management ausgeführt wird, sind in Matrix Recovery
Management keine anderen Konfigurationsvorgänge zulässig.
Aktion
Stellen Sie sicher, dass der Failover-Vorgang nicht länger als gewöhnlich dauert und dass der
Back-End-Aufragsvorgang hp_lsdt_automation.exe derzeit ausgeführt wird. Warten Sie,
bis der Vorgang Activate (Aktivieren) oder Deactivate (Deaktivieren) abgeschlossen ist.
Fehlermeldung
Unable to import Storage Management Servers.
Ursache
Ein Speicherverwaltungsserver ist auf der Matrix Operating Environment-Benutzeroberfläche
nicht ordnungsgemäß konfiguriert.
Aktion
Stellen Sie sicher, dass der Speicherverwaltungsserver auf der Matrix Operating
Environment-Benutzeroberfläche ermittelt wird. Stellen Sie sicher, dass auf dem
Speicherverwaltungsserver Open SSH installiert und konfiguriert ist. Andernfalls kann Configure
(Konfigurieren)→Configure or Repair Agents (Agenten konfigurieren oder reparieren) über
die Matrix Operating Environment-Benutzeroberfläche ausgeführt werden. Vergewissern Sie
sich, dass es sich bei den Anmeldedaten für den Benutzer auch um die Anmeldedaten für den
Server auf der Matrix Operating Environment-Benutzeroberfläche handelt.
Fehlermeldung
Import Failed.
Ursache
Mögliche Ursachen sind: Die Importdatei ist ungültig, der Logical Server Automation-Dienst wird
nicht ausgeführt oder ein oder mehrere logische Wiederherstellungsserver befinden sich in einem
aktiven Zustand.
Aktion
Vergewissern Sie sich, dass zum Importieren der Matrix Recovery Management-Konfiguration
am Remote-Standort eine gültige vom lokalen Standort exportierte Datei verwendet wird. Bestätigen
Sie, ob der Logical Server Automation-Dienst auf dem CMS ausgeführt wird. Vergewissern Sie
sich, dass alle logischen Wiederherstellungsserver, die von Matrix Recovery Management verwaltet
werden sollen, sich zum Zeitpunkt des Matrix Recovery Management-Konfigurationsimports in
einem deaktivierten Zustand befinden.
Fehlermeldung
Import succeeded but not all storage managers have been fully configured.
Check Matrix recovery management log files for details.
Ursache
Für einen oder mehrere Remote-Speicherverwaltungsserver wurden keine Anmeldedaten
konfiguriert.
Aktion
1. Suchen Sie in der Datei lsdt.log und lsdt_web.log nach den
Remote-Speicherverwaltungsservern mit nicht konfigurierten Anmeldedaten.
2. Stellen Sie sicher, dass die Speicherverwaltungsserver hochgefahren wurden und
ordnungsgemäß funktionieren.
3. Ermitteln Sie die Speicherverwaltungsserver auf dem CMS.
4. Klicken Sie auf der Matrix Recovery Management -Benutzeroberfläche auf die Registerkarte
Storage Management Servers (Speicherverwaltungsserver).
Fehlerbehebung
5. Wählen Sie den Speicherverwaltungsserver aus, der konfiguriert werden soll, und klicken Sie
auf Edit (Bearbeiten).
6. Aktivieren Sie das Kontrollkästchen Refresh SIM Password (SIM-Kennwort aktualisieren),
und klicken Sie auf Save (Speichern).
Warnmeldungen
Dieser Abschnitt listet Matrix Recovery Management-Warnmeldungen auf.
Warnmeldung
Warning: Matrix recovery management is being quiesced. Currently running
operations will be allowed to complete. No new operations can be started.
Ursache
Matrix Recovery Management wird gerade stillgelegt. Alle Konfigurationsschaltflächen (Create
(Erstellen), Edit (Bearbeiten), Delete (Löschen) usw.) werden deaktiviert.
Aktion
Warten Sie, bis Matrix Recovery Management stillgelegt wurde.
Warnmeldung
Warning: Matrix recovery management is quiesced. No new operations will
be allowed.
Ursache
Matrix Recovery Management wurde stillgelegt. Alle Konfigurationsschaltflächen (Create
(Erstellen), Edit (Bearbeiten), Delete (Löschen) usw.) werden deaktiviert.
Aktion
Warten Sie, bis Matrix Recovery Management stillgelegt wurde.
Warnmeldung
Warning: Unable to remove CLX credentials for
<Name_des_Speicherverwaltungsservers> (these server credentials may not
exist in CLX). Matrix recovery management will continue to delete
<Name_des_Speicherverwaltungsservers>. HP recommends that you check and
manually remove the CLX credentials.
Ursache
CLX-Anmeldedaten konnten nach dem Löschen eines Speicherverwaltungsservers nicht bereinigt
werden.
Aktion
Zum Überprüfen und Bereinigen von CLX-Anmeldedaten öffnen Sie ein
Eingabeaufforderungsfenster im CMS:
• Wechseln Sie zum Verzeichnis „CLX bin“. Beispiel: cd c:\Program
Files\Hewlett-Packard\Cluster Extension 3PAR\bin
• Führen Sie folgende Datei aus: CLX3PARCONFIG array /remove
name=storage_management_server_name>
• Überprüfen Sie die Befehlsausgabemeldung.
Fehlerbehebung bei Matrix Recovery Management-Aufträgen
Der Matrix Recovery Management-Auftrag Activate (Aktivieren), Deactivate (Deaktivieren),
Recovery Group import (Import der Wiederherstellungsgruppe) oder Site import (Import des
Standorts) kann aufgrund einer vorübergehenden Fehlerbedingung zwischen den
Softwarekomponenten zeitweise fehlschlagen.
Standardmäßig wiederholt Matrix Recovery Management ausgefallene Aktivierungs- und
Deaktivierungsvorgänge auf logischen Servern. Wenn der Import einer Wiederherstellungsgruppe
oder eines Standorts fehlschlägt, erfolgt kein automatischer Neuversuch und die Option restart
(Neustart) ist nicht verfügbar.
Die Details jedes fehlgeschlagenen Auftrags werden in der Datei lsdt.log im Matrix Recovery
Management-Installationsverzeichnis protokolliert, zum Beispiel C:\Programme\HP\Insight
Recovery\logs. Wenn die Datei lsdt.log angibt, dass ein Standortimport aufgrund einer
oder mehrerer unzureichend importierter Wiederherstellungsgruppen fehlgeschlagen ist, können
Sie versuchen, den Standort abzuschließen, indem Sie die einzelnen nicht erfolgreich importierten
Wiederherstellungsgruppen erneut importieren. Einzelne Wiederherstellungsgruppen können
Warnmeldungen
79
über die Registerkarte Recovery Groups (Wiederherstellungsgruppen) importiert werden. Falls
die Ursache des fehlgeschlagenen Standortimportauftrags komplex ist, müssen Sie zur
Registerkarte Sites (Standorte) zurückkehren und den gesamten Standortimport erneut
durchführen. Wenn Sie die automatische Wiederholung deaktivieren möchten, können Sie die
Eigenschaft MAX_RETRY_ATTEMPTS in der Datei hp_ir.properties im Verzeichnis conf im
Matrix Recovery Management-Installationsverzeichnis bearbeiten. Stellen Sie zum Deaktivieren
der automatischen Wiederholung die Eigenschaft MAX_RETRY_ATTEMPTS auf 0 ein. Wenn Sie
die automatische Wiederholung fehlgeschlagener Vorgänge durch Matrix Recovery Management
wieder aktivieren möchten, stellen Sie die Eigenschaft MAX_RETRY_ATTEMPTS auf 1 ein.
HINWEIS:
•
Fehlgeschlagene Aktivierungs- und Deaktivierungsaufträge werden nur wiederholt, nachdem
der Vorgang auf allen logischen Servern in der Konfiguration versucht wurde.
•
Bei Aufträgen für logische Server und Wiederholungsgruppen wird der Auftrag nicht als
fehlgeschlagen markiert, während eine Wiederholung des Vorgangs ansteht.
Zur Identifizierung des Subsystems, in dem der Fehler aufgetreten ist, werden Sie im
verbleibenden Teil dieses Abschnitts auf die einzusehenden Protokolldateien und die zugreifenden
Maßnahmen verwiesen. Für zusätzliche Informationen können Sie die Datei lsdt.log im
Verzeichnis „logs“ im Matrix Recovery Management-Installationsverzeichnis auf dem System
einsehen.
Ein Auftrag in Matrix Recovery Management ist ein automatisierter, in mehrere Schritte unterteilter
Prozess, der ausgewählte Wiederherstellungsgruppensätze an einem Standort aktiviert bzw.
deaktiviert, eine bestimmte Wiederherstellungsgruppe importiert oder eine Standortkonfiguration
importiert. Der Auftrag mit der Auftrags-ID 3288 (siehe Abbildung 23, „Bildschirm „Jobs“
(Aufträge)“) ist beispielsweise ein Aktivierungsauftrag (Activate). Als Entity (Entität) wird für ihn
der Typ site (Standort) und als Operation (Betrieb) wird für ihn der Typ activate (Aktivieren)
angegeben. Außerdem ist in der Spalte Status das Symbol „Failed“ (Fehlgeschlagen) zu sehen,
an dem zu erkennen ist, dass Auftrag 3288 fehlgeschlagen ist.
Abbildung 23 Bildschirm „Jobs“ (Aufträge)
Klicken Sie bei einem fehlgeschlagenen Auftrag auf das Kontrollkästchen neben Job Id
(Auftrags-ID), um detaillierte Informationen zu den zugehörigen untergeordneten Aufträgen (Sub
Jobs) anzuzeigen.
Der Auftrag site (Standort) enthält für jede Wiederherstellungsgruppe einen untergeordneten
Auftrag. Gleichermaßen besitzt jede Wiederherstellungsgruppe untergeordnete Aufträge für ihre
Speicherreplikationsgruppe bzw. ihren logischen Server.
Zur Fehlerbehebung eines Standortauftrags (site) und zum Identifizieren der Quelle des Fehlers,
führen Sie einen Drilldown zu jedem der zugehörigen ausgefallenen untergeordneten Aufträge
durch, um den ausgefallenen Vorgang sowie den Grund für den Ausfall zu bestimmen, wie in
Abbildung 24, „Erweiterter Bildschirm „Jobs“ (Aufträge)“ angezeigt:
80
Fehlerbehebung
Abbildung 24 Erweiterter Bildschirm „Jobs“ (Aufträge)
Weitere Informationen zur Fehlerbeseitigung finden Sie imMatrix Operating Environment Logical
Server Management Benutzerhandbuch und imMatrix Operating Environment Infrastructure
Orchestration Benutzerhandbuch in der Hewlett Packard Enterprise
Nachdem das Problem korrigiert wurde, können Sie den Auftrag über den Bildschirm Jobs
(Aufträge) neu starten, indem Sie in der Spalte Status für den ausgefallenen Auftrag auf restart
(Neustarten) klicken (siehe Abbildung 25, „Neustarten eines fehlgeschlagenen Auftrags“).
Fehlerbehebung bei Matrix Recovery Management-Aufträgen
81
Abbildung 25 Neustarten eines fehlgeschlagenen Auftrags
HINWEIS: Durch Neustarten des Auftrags werden nur die untergeordneten Aufträge wiederholt,
die zuvor ausgefallen sind. Server mit ausgeführten Aufträgen oder Unteraufträgen sind nicht
betroffen.
WICHTIG: Wenn zur Korrektur des Problems, aufgrund dessen der Auftrag fehlgeschlagen
ist, eine Neukonfiguration des bzw. der logischen Server gehört, bevor der Auftrag neu gestartet
wird, dann löschen Sie auf der Registerkarte Recovery Groups (Wiederherstellungsgruppen)
die Wiederherstellungsgruppe(n), die den bzw. die neu konfigurierten logischen Server enthalten.
Wiederherstellungsgruppen, die aufgrund der Neukonfiguration von logischen Servern gelöscht
wurden, können mit den neu konfigurierten Servern neu erstellt werden, nachdem der Auftrag
erfolgreich abgeschlossen wurde.
In diesem Abschnitt werden die folgenden zu behebenden Fehler angesprochen:
•
Failover-Auftrag aufgrund eines Speicher-Failovers fehlgeschlagen
◦
•
Zum Zeitpunkt des Failovers waren keine Speicherverwaltungsserver verfügbar.
Der Failover-Auftrag war erfolgreich, die logischen Wiederherstellungsserver wurden
jedoch nicht aktiviert
◦
82
Wiederherstellungsgruppen mit logischen Servern, die sich am Remote-Standort im
Wartungsmodus befinden.
Fehlerbehebung
•
Failover-Auftrag ist fehlgeschlagen, da keine ausreichend lizenzierten physischen
Server oder Virtual Machines zum Hosten der logischen Server vorhanden waren
•
◦
Physische Server führen andere Arbeitsauslastungen aus.
◦
Am Remote-Standort wird keine Hypervisor-Verwaltungssoftware (z. B. VMware vCenter
Server) ausgeführt.
Der Matrix Recovery Management-Auftrag ist aufgrund eines nicht auffindbaren
logischen Servers in Matrix OE Logical Server Management fehlgeschlagen
◦
•
Ein von Matrix Recovery Management verwalteter logischer Server wurde aus Matrix
OE Logical Server Management entfernt, bevor er in Matrix Recovery Management aus
der Verwaltung entfernt wurde.
Matrix Recovery Management-Auftrag ist fehlgeschlagen, weil in Matrix OE Logical
Server Management ein Vorgang für den logischen Server fehlgeschlagen ist
◦
Der logische Server wurde möglicherweise nicht eingeschaltet.
Failover-Fehlermeldungen
Dieser Abschnitt enthält Failover-Fehlermeldungen von Matrix Recovery Management.
Fehlermeldung
Failover job fails because storage failover of Storage Replication Groups
failed
Ursache
Mögliche Ursachen sind, dass der Speicherverwaltungsserver während des Failovers nicht
zugänglich war oder dass der Status der Speicherreplikationsgruppen keinen Speicher-Failover
zulässt.
Aktion
Stellen Sie sicher, dass zumindest der lokale Speicherverwaltungsserver zugänglich ist und eines
der Arrays aktiv verwaltet. Um das Problem weiter zu sichten:
• Sehen Sie bei Einsatz von P6000-Laufwerksarrays die Datei clxevarun.log im
Unterverzeichnis STORAGE/EVA/log ein, das sich im Matrix Recovery
Management-Installationsverzeichnis auf dem CMS befindet.
• Sehen Sie bei Einsatz der P9000-Festplatten-Arrays die Datei clxrun.log im Unterverzeichnis
„logs“ im Installationsverzeichnis von CLX für P9000 auf dem lokalen Speicherverwaltungsserver
ein.
• Sehen Sie bei Einsatz der 3PAR StoreServ-Speichersysteme die Datei clx3parrun.log im
Unterverzeichnis „logs“ im Installationsverzeichnis der 3PAR StoreServ Cluster Extension
Software auf dem CMS ein.
Fehlermeldung
Failover job fails because of unlocatable logical server in LSM
Ursache
Möglicherweise wurde ein logischer Server mit Matrix OE Visualization gelöscht, ohne die
Wiederherstellungsgruppe, in der der logische Server enthalten ist, aus Matrix Recovery
Management zu entfernen.
Aktion
Entfernen Sie den logischen Server aus der Wiederherstellungsgruppe in Matrix Recovery
Management, und führen Sie den Failover-Auftrag erneut aus. Sehen Sie auch die Datei lsdt.log
ein, die sich im Unterverzeichnis „logs“ im Matrix Recovery Management-Installationsverzeichnis
befindet.
Failover-Fehlermeldungen
83
Fehlermeldung
Failover job succeeds but certain logical servers are not activated
Ursache
Wiederherstellungsgruppen mit diesen logischen Servern können sich im Wartungsmodus befinden.
Aktion
Deaktivieren Sie den Wartungsmodus für die Wiederherstellungsgruppen, und wiederholen Sie
den Failover-Vorgang. Sehen Sie auch die Datei lsdt.log ein, die sich im Unterverzeichnis
„logs“ im Matrix Recovery Management-Installationsverzeichnis befindet.
Fehlermeldung
Failover job fails because of insufficient servers
Ursache
Möglicherweise sind nicht genug lizenzierte physische Ressourcen vorhanden, die zum Hosten
der logischen Server fähig sind.
Aktion
Vergewissern Sie sich, dass genug für Matrix Operating Environment lizenzierte physische Server
zum Hosten der durch Matrix Recovery Management verwalteten logischen Server verfügbar
sind. Sehen Sie auch die Datei lsdt.log ein, die sich im Unterverzeichnis „logs“ im Matrix
Recovery Management-Installationsverzeichnis befindet.
Matrix Recovery Management-Protokolldateien
Es sind mehrere Protokolldateien mit detaillierten Informationen verfügbar, die Sie einsehen
können, um die Ursachen des Matrix Recovery Management-Failovers oder von
Failover-Problemen aufzudecken:
•
Für Fehler, die während der erstmaligen Konfiguration von Matrix Recovery Management
aufgetreten sind, können Sie die Dateien lsdt.log und lsdt_web.log einsehen, die
sich im Verzeichnis lsdt im Installationsverzeichnis von Systems Insight Manager auf dem
System befinden.
•
Überprüfen Sie für Fehler, die während eines Failover-Vorgangs auftreten, die Datei
lsdt.log im Unterverzeichnis „logs“ im Matrix Recovery
Management-Installationsverzeichnis auf Details zu einem bestimmten fehlgeschlagenen
Vorgang.
•
Fehler im Zusammenhang mit einem P6000-Speicher-Failover werden in die Datei
clxevarun.log im Unterverzeichnis STORAGE/EVA/log im Matrix Recovery
Management-Installationsverzeichnis auf dem System geschrieben.
Eine Liste der Protokolldateien zur Fehlerbehebung von P9000-Speicher-Failover-Problemen
finden Sie imP9000 Cluster Extension Software Administrator Guide (P9000 Cluster Extension
Software Administratorhandbuch).
•
Fehler im Zusammenhang mit einem P9000-Speicher-Failover werden in die Datei
clxrun.log im Unterverzeichnis Cluster Extension XP\log des
Speicherverwaltungsservers geschrieben, auf den die Matrix-Wiederherstellungsverwaltung
zum Durchführen des Speicher-Failover-Vorgangs zugreift.
Zusätzliche Informationen zu Problemen mit der Aktivierung und Deaktivierung logischer
Server, die anfänglich auf dem Matrix Recovery Management-Bildschirm Jobs (Aufträge)
gemeldet werden, sind auf dem Matrix OE Visualization-Bildschirm Logical Server Job
Status (Auftragsstatus für logische Server) zu finden. Wählen Sie einen Auftrag für logische
Server basierend auf seinem Job Title (Auftragstitel) aus, und zeigen Sie seine Job Details
(Auftragsdetails) an.
•
84
Eine Liste der Protokolldateien zur Fehlerbehebung von 3PAR
StoreServ-Speicherfailover-Problemen finden Sie im 3PAR StoreServ Cluster Extension
Software Administratorhandbuch, verfügbar unter http://www.hpe.com/info/
ClusterExtension-manuals.
Fehlerbehebung
Fehlerbehebung bei DR-geschützten IO-Diensten
Für Fehler, die während Matrix Recovery Management-Vorgängen in Wiederherstellungsgruppen
von IO-Diensten auftreten, gelten folgende Schritte zur Fehlerbehebung:
1. Überprüfen Sie die Datei lsdt.log im Verzeichnis „logs“ im Matrix Recovery
Management-Installationsverzeichnis auf Details zu einem bestimmten fehlgeschlagenen
Vorgang.
2. Überprüfen Sie den Status der IO-Dienste auf der Matrix IO-Seite Services (Dienste), um
zu überprüfen, ob die IO-Dienste den richtigen Status für den jeweiligen fehlgeschlagenen
Vorgang haben.
3. Überprüfen Sie die hpio.properties-Dateien und die dr.properties-Dateien am
lokalen und Remote-Standort für die CMS, um sicherzustellen, dass sie richtig eingestellt
sind. Weitere Informationen finden Sie in „DR-Schutz für IO-Dienste“.
4. Falls ein Aktivierungs-, Deaktivierungs- oder Importvorgang fehlschlägt, wechseln Sie zum
Bildschirm Jobs (Aufträge) in Matrix Recovery Management, um die Auftragsdetails zu
überprüfen.
5. Falls erforderlich, wechseln Sie zum IO-Bildschirm Requests (Anforderungen), um die
Anforderungen der im fehlgeschlagenen Matrix Recovery Management-Vorgang involvierten
IO-Dienste anzuzeigen.
6. Falls erforderlich, überprüfen Sie die Datei hpio-controller.log im Verzeichnis „logs“
im Matrix Recovery Management-Installationsverzeichnis auf Details zum jeweiligen
fehlgeschlagenen IO-Vorgang.
7. Weitere Informationen zur Fehlerbeseitigung bei IO-Diensten finden Sie im Bereich
„Fehlerbeseitigung“ imMatrix Operating Environment Infrastructure Orchestration
Benutzerhandbuch in der Hewlett Packard Enterprise Enterprise-Informationsbibliothek.
Fehlerbehebung bei der Konfiguration von DR-geschützten IO-Diensten
Zusätzlich zu den in diesem Benutzerhandbuch behandelten Konfigurationsproblemen, die häufig
sowohl bei logischen Servern als auch bei IO-Diensten auftreten, gelten die folgenden
Konfigurationsprobleme für IO-Dienste:
•
Es konnte keine Liste der IO-Dienste zur Einbeziehung in eine
Wiederherstellungsgruppe abgerufen werden
Mögliche Ursachen:
•
◦
Windows-Dienst von Matrix Infrastructure Orchestration wird nicht ausgeführt.
◦
Es sind keine DR-fähigen IO-Dienste vorhanden.
◦
Alle DR-fähigen IO-Dienste sind bereits in den Wiederherstellungsgruppen der IO-Dienste
konfiguriert.
◦
Kommunikationsfehler mit IO.
Fehler beim Importieren eines IO-Dienstes
Mögliche Ursachen:
◦
Die Importdatei ist ungültig.
◦
Der zu erstellende Dienstreplikat besteht bereits und wird lokal ausgeführt.
◦
Ein primärer Dienst mit dem gleichen Namen besteht bereits.
◦
Die Werte der Eigenschaften in den Dateien hpio.properties und dr.properties
sind nicht richtig eingestellt.
–
DR-Schutz ist nicht aktiviert (enable.dr.protection = false).
85
•
–
Der in volume.dr.replica.list angegebene Datenspeicher stimmt nicht mit
den Datenspeichern für den IO-Dienst am Remote-Standort überein.
–
Die Zuordnung für den Benutzernamen und den Domänennamen ist nicht
angegeben.
◦
Ressourcen (Netzwerk und Speicher) sind nicht verfügbar.
◦
Der Windows-Dienst von Matrix Infrastructure Orchestration wird nicht ausgeführt.
◦
Es liegt ein Kommunikationsfehler mit IO vor.
Eine oder mehrere Wiederherstellungsgruppen in der Konfiguration von Matrix
Recovery Management stimmten mit der Konfiguration von Matrix OE Logical Serer
Management oder von IO nicht überein
◦
Der Matrix OE Logical Server Management-Dienst, der Windows-Dienst von Matrix
Infrastructure Orchestration oder beide dieser Dienste wurden nicht ausgeführt, als
Wiederherstellungsgruppen in Matrix Recovery Management konfiguriert wurden.
◦
Der logische Server oder der IO-Dienst wurde beim Aufrufen der Matrix Recovery
Management-Konfiguration (Änderung, Aktivierung oder Deaktivierung) aktiv verwaltet.
Fehlermeldungen bei der Konfiguration von IO-Diensten
86
Fehlermeldung
Der IO-Dienst kann nicht abgerufen werden.
Ursache
Der IO-Dienst ist nicht vorhanden, oder Matrix Recovery Management konnte die Informationen
zum IO-Dienst nicht von der Matrix-Infrastruktur abrufen.
Aktion
Weitere Informationen zu diesem Fehler finden Sie in den Matrix Recovery Management- und
IO-Protokolldateien. Falls der IO-Dienst nicht in IO vorhanden ist, wurde der IO-Dienst
möglicherweise entfernt. Ist der IO-Dienst vorhanden, starten Sie IO erneut, und führen Sie den
Vorgang erneut durch.
Fehlermeldung
Fehler: HP Matrix Infrastructure Orchestration ist nicht aktiv. Dies
führt entweder zu einer leeren Liste der Dienste oder zu einer
ungefilterten Liste verfügbarer logischer Server (einschließlich der
von Matrix-IO-Dienste verwalteten logischen Server). Starten Sie
HP Matrix Infrastructure Orchestration erneut, und versuchen Sie es
erneut.
Ursache
Als eine Wiederherstellungsgruppe der IO-Dienste über die Matrix Recovery Management-GUI
erstellt oder geändert wurde, konnte Matrix Recovery Management keine Kommunikation mit IO
herstellen, um eine Liste verfügbarer IO-Dienste für die Wiederherstellungsgruppe abzurufen.
Aktion
Starten Sie den Windows-Dienst von Matrix Infrastructure Orchestration neu, und wiederholen
Sie den Vorgang.
Fehlermeldung
Fehler: Von Matrix-IO-Dienste verwaltete logische Server konnten nicht
herausgefiltert werden. Starten Sie Matrix IO erneut, und versuchen Sie
es erneut.
Ursache
Als eine Wiederherstellungsgruppe der IO-Dienste über die Matrix Recovery Management-GUI
erstellt oder geändert wurde, konnte Matrix Recovery Management keine Kommunikation mit IO
herstellen, um eine Liste der IO-Dienste zum Herausfiltern der logischen VM-Server abzurufen,
die nicht bereits Bestandteil eines IO-Dienstes mit aktiviertem DR-Schutz sind.
Aktion
Starten Sie den Windows-Dienst von Matrix Infrastructure Orchestration neu, und wiederholen
Sie den Vorgang.
Fehlerbehebung
Fehlermeldung
Fehler: Matrix-IO-Dienst konnte nicht importiert werden. Ein primärer
Dienst mit dem gleichen Namen besteht bereits.
Ursache
Während des Imports ist ein primärer IO-Dienst mit dem gleichen Namen wie das importierte
IO-Dienstreplikat in IO vorhanden.
Aktion
Löschen Sie entweder den primären IO-Dienst am lokalen Standort, oder erstellen Sie den
primären IO-Dienst mit einem anderen Namen erneut.
Fehlermeldung
Fehler: Eine oder mehrere Wiederherstellungsgruppen in der Konfiguration
von Matrix Recovery Management waren inkonsistent mit der Konfiguration
der LSM oder Matrix Infrastructure Orchestration. Löschen Sie diese
Wiederherstellungsgruppen. Überprüfen Sie die Protokolldateien von Matrix
Recovery Management, um die Inkonsistenz zu ermitteln, die den Fehler
verursacht hat.
Ursache
Matrix Recovery Management konnte nicht mit Matrix Operating Environment oder IO
kommunizieren, um zu bestätigen, ob ein logischer Server oder IO-Dienst von Matrix Recovery
Management verwaltet wird.
Aktion
Löschen Sie die Wiederherstellungsgruppe mit dem logischen Server oder IO-Dienst aus Matrix
Recovery Management. Vergewissern Sie sich, dass der Matrix OE Logical Server
Management-Dienst und der IO-Dienst ausgeführt werden. Stellen Sie sicher, dass der logische
Server und der IO-Dienst derzeit nicht aktiv von einem Benutzer geändert werden. Wiederholen
Sie das Hinzufügen der Wiederherstellungsgruppe in Matrix Recovery Management.
Fehlerbehebung beim Failover DR-geschützter IO-Dienste
Zusätzlich zu den in diesem Benutzerhandbuch behandelten Failover-Problemen, die logischen
Servern und IO-Diensten gemeinsam sind, beziehen sich die folgenden Failover-Probleme nur
auf IO-Dienste:
•
Aktivierung des IO-Dienstes in einer Wiederherstellungsgruppe fehlgeschlagen
Mögliche Ursachen:
•
◦
Es sind keine Speicherressourcen verfügbar.
◦
Der IO-Dienst befindet sich in einem ungültigen Status für die Aktivierung.
◦
Der IO-Dienst ist nicht vorhanden.
◦
◦
Deaktivierung des IO-Dienstes in einer Wiederherstellungsgruppe fehlgeschlagen
Mögliche Ursachen:
◦
◦
Der IO-Dienst ist nicht vorhanden.
◦
Der IO-Dienst befindet sich in einem ungültigen Status für die Deaktivierung.
◦
87
Fehlermeldungen von Matrix Recovery Management speziell für IO-Dienste
Fehlermeldung
Der IO-Dienst kann nicht abgerufen werden.
Ursache
Matrix Recovery Management konnte keine Informationen zum IO-Dienst von IO abrufen.
Aktion
Überprüfen Sie die Matrix Recovery Management- und IO-Protokolldateien auf weitere Einzelheiten
zu diesem Fehler. Starten Sie den Windows-Dienst von Matrix Infrastructure Orchestration neu,
und wiederholen Sie den Vorgang.
Fehlermeldung
Dienstaktivierung/-deaktivierung kann zu diesem Zeitpunkt nicht
durchgeführt werden, da der Dienst den Status IN_PROGRESS hat.
Ursache
Der IO-Dienst war in Bearbeitung, als der Matrix Recovery Management-Aktivierungs- bzw.
Deaktivierungsvorgang durchgeführt wurde (Änderung, Aktivierung oder Deaktivierung war in
Bearbeitung).
Aktion
Warten Sie, bis der IO-Dienst den Status IN_PROGRESS beendet hat, und führen Sie den
Aktivierungs- bzw. Deaktivierungsvorgang erneut durch.
Hyper-V-basierte IO-Dienste oder logische Server konnten nicht aktiviert
werden
Symptom: Die Aktivierung des Hyper-V-basierten Matrixdiensts oder logischen Servers ist mit
der folgenden Fehlermeldung für Matrix Infrastructure Orchestration oder Matrix OE
Visualization-Jobs fehlgeschlagen:
Ressourcen konnten nicht aktiviert werden. (Virtual Machine Management-Fehlercode:-1)
Mögliche Ursache: Der Gerätemanager im Hyper-V-Clusterknoten führt die Datenträger, für die
ein Failover zum Remote-Standort durchgeführt wurde, als Pseudogeräte auf. Dies kann dazu
führen, dass die Windows-Datenträgerverwaltung Geräte nicht erkennt, die aufgrund des
Speicherfailovers mit Lese-Schreib-Zugriff bereitgestellt werden. Eine mögliche Ursache für
dieses Symptom kann die Art sein, auf die Multipath-I/O (MPIO) dieselbe LUN nach einem
Failover und Failback darstellt.
Empfohlene Maßnahmen: Folgende zwei Workarounds:
•
Um das Problem zu beheben, starten Sie die Clusterknoten, auf denen die Laufwerke nicht
erkannt werden, neu, auch wenn für die Speicherreplikationsgruppe ein Failover zum lokalen
Standort (im Rahmen des Matrix RM-Failovers) durchgeführt wurde. Überprüfen Sie nach
dem Neustart die in der Microsoft Failover Cluster Manager-Schnittstelle sichtbaren
Clusterlaufwerke, und starten Sie den Matrix RM-Aktivierungsvorgang neu.
•
Deinstallieren Sie die ghosted-Pseudogeräte, die nach dem Speicherfailover zum
Remote-Standort übrig sind, und suchen Sie erneut nach Speichergeräten. Diese
Pseudogeräte werden in den Device Manager-Laufwerken angezeigt. Achten Sie darauf,
dass ausgeblendete Geräte nur sichtbar sind, wenn die Option „View“ (Anzeigen) ausgewählt
ist.
HINWEIS: Gehen Sie bei der Deinstallation umsichtig vor, um sicherzustellen, dass nur
ghosted-Laufwerke und keine gültigen Laufwerke deinstalliert werden.
88
Fehlerbehebung
8 Support und weitere Ressourcen
Anfordern von Hewlett Packard Enterprise Support
•
Um Echtzeit-Support zu anzufordern, navigieren Sie zur Website mit weltweiten
Kontaktinformationen für Hewlett Packard Enterprise:
www.hpe.com/assistance
•
Um auf die Dokumentation und Supportservices zuzugreifen, navigieren Sie zur Hewlett
Packard Enterprise Support Center-Website:
www.hpe.com/support/hpesc
Informationen, die zur Hand sein sollten
•
Registrierungsnummer beim Technischen Support (sofern zutreffend)
•
Name, Modell oder Version des Produkts und Seriennummer
•
Name und Version des Betriebssystems
•
Firmwareversion
•
Fehlermeldungen
•
Produktspezifische Berichte und Protokolle
•
Zusatzprodukte oder -komponenten
•
Produkte oder Komponenten von Drittanbietern
Zugreifen auf Aktualisierungen
•
Einige Softwareprodukte bieten eine Methode zum Zugriff auf Softwareaktualisierungen
über die Benutzeroberfläche des Produkts. Sie können der Dokumentation Ihres Produkts
die empfohlene Methode für Softwareaktualisierungen entnehmen.
•
Sie können Produktaktualisierungen von einer der folgenden Websites herunterladen:
◦
Hewlett Packard Enterprise Support Center-Seite Get connected with updates
(Zugreifen auf Aktualisierungen):
www.hpe.com/support/e-updates-de
◦
Software Depot-Website:
www.hpe.com/support/softwaredepot
•
Wenn Sie Ihre Ansprüche anzeigen und aktualisieren und Ihre Verträge und Garantien mit
Ihrem Profil verknüpfen möchten, rufen Sie die Hewlett Packard Enterprise Support
Center-Seite More Information on Access to Support Materials (Weitere Informationen
zum Zugriff auf Support-Materialien auf):
www.hpe.com/support/AccessToSupportMaterials
WICHTIG: Für den Zugriff auf bestimmte Aktualisierungen über das Hewlett Packard
Enterprise Support Center ist möglicherweise ein Produktanspruch erforderlich. Sie müssen
einen HP Passport mit zutreffenden Ansprüchen eingerichtet haben.
Anfordern von Hewlett Packard Enterprise Support
89
Sicherheitsbulletin und Richtlinie für Warnhinweise zu
Softwarekomponenten nicht im Besitz von Hewlett Packard Enterprise
Manchmal sind in Hewlett Packard Enterprise Produkten Open Source Software (wie z. B.
OpenSSL) oder Software von Fremdherstellern (wie z. B. Java) enthalten. Hewlett Packard
Enterprise legt offen, dass sich die in der Insight Management-Endbenutzervereinbarung (EULA)
aufgelisteten und nicht Hewlett Packard Enterprise gehörenden Softwarekomponenten im
Lieferumfang von Insight Management befinden. Die EULA befindet sich im Insight Management
Installer auf der Insight Management DVD #1.
Hewlett Packard Enterprise sendet Sicherheitsbulletins für die in der EULA aufgelisteten
Softwarekomponenten mit dem gleichen Maß an Unterstützung, das Hewlett Packard Enterprise
Produkten geboten wird. Hewlett Packard Enterprise verpflichtet sich, Sicherheitsmängel zu
reduzieren und Ihnen bei der Abschwächung der mit Sicherheitsmängeln verbundenen Risiken
zu helfen.
Wenn ein Sicherheitsmangel gefunden wird, folgt Hewlett Packard Enterprise einem klar
umrissenen Ablauf, der schließlich zur Veröffentlichung eines Sicherheitsbulletins führt. Das
Sicherheitsbulletin bietet Ihnen eine detaillierte Beschreibung des Problems und erklärt, wie
diesem Sicherheitsmangel abgeholfen werden kann.
Registrieren für Technischen Support für die Software und für den
Aktualisierungsservice
Insight Management-Komponenten und -Softwareprodukte beinhalten ein Jahr lang rund um die
Uhr den Technischen Support- und Updateservice für Hewlett Packard Enterprise Software.
Dieser Service bietet Zugriff auf technische Hewlett Packard Enterprise Ressourcen zur Hilfe
beim Lösen von Problemen mit der Implementierung oder dem Betrieb der Software.
Dieser Dienst gewährt zudem Zugriff auf Softwareaktualisierungen und Referenzhandbücher in
elektronischer Form oder auf physische Medien, wenn diese von Hewlett Packard Enterprise
angeboten werden. Kunden, die eine elektronische Lizenz erwerben, sind nur für elektronische
Aktualisierungen berechtigt.
Mit diesem Service profitieren Insight Management-Kunden sowohl von Problemlösungen als
auch von proaktiven Benachrichtigungen zur Bereitstellung von Softwareaktualisierungen. Weitere
Informationen über diesen Dienst finden Sie auf der folgenden Website: http://www.hpe.com/
services/insight.
Die Registrierung für diesen Service erfolgt nach der Online-Rücknahme des Lizenzzertifikats.
Für die Registrierung stehen Ihnen zwei Methoden zur Verfügung:
•
Wenn Sie ein Lizenzberechtigungszertifikat erhalten haben, erfolgt die Registrierung zu
diesem Service automatisch bei der Onlinebereitstellung des Lizenzzertifikats bzw. des
Lizenzschlüssels.
•
Wenn aus den mit Ihrem Produkt gelieferten Lizenzinformationen hervorgeht, dass Sie sich
selbst für den Technischen Support- und Updateservice für Hewlett Packard Enterprise
Software registrieren müssen, befolgen Sie die entsprechenden Anweisungen, um
Telefonsupport und Produktupdates in Anspruch nehmen zu können.
Wie Technischer Support und Aktualisierungsservice für Ihre Software in Anspruch
genommen werden
Wenn Hewlett Packard Enterprise Softwareaktualisierungen freigibt, werden Ihnen die aktuellen
Versionen von Software und Dokumentation zur Verfügung gestellt. Das Portal „Software Updates
and Licensing“ ermöglicht den Zugriff auf Software, Dokumentation und Lizenzaktualisierungen
für Produkte, die Teil Ihres Supportvertrags für Hewlett Packard Enterprise Software sind.
Dieses Portal ist über den Hewlett Packard Enterprise Support Center zugänglich:
90
Support und weitere Ressourcen
http://www.hpe.com/info/hpesc
Nach dem Erstellen Ihres Profils und der Verknüpfung Ihrer Supportverträge mit dem Profil
können Sie Software, Dokumentationen und Lizenzaktualisierungen aus dem Portal „Software
Updates and Licensing“ (Softwareaktualisierungen und Lizenzierung) unter http://www.hpe.com/
info/hpesoftwareupdatesupport abrufen.
Hewlett Packard Enterprise Partner
Den Namen eines Hewlett Packard Enterprise Partners in Ihrer Nähe finden Sie in den folgenden
Quellen:
•
Rufen Sie in den USA die Website zur Suche nach Hewlett Packard Enterprise
US-Kundendienststellen auf:
http://www.hpe.com/support/service_locator
•
Rufen Sie an anderen Orten die Website „Contact Hewlett Packard Enterprise Worldwide“
auf:
http://www.hpe.com/contact
Matrix Recovery Management-Dokumentation
Weitere Informationen zu Matrix Recovery Management finden Sie in den folgenden Quellen:
•
HPE Insight Management Support-Matrix
Enthält Matrix Recovery Management-Support-Informationen zusammen mit anderen HPE
Insight Hardware-, Software- und Firmware-Support-Informationen. Verfügbar in der Hewlett
Packard Enterprise Enterprise-Informationsbibliothek.
•
Matrix Operating Environment Versionshinweise
HPE Insight Control Erste Schritte
Informiert über neue Funktionen und Änderungen in Matrix Recovery Management und
anderen Komponenten von Matrix Operating Environment in dieser Version. Verfügbar in
der Hewlett Packard Enterprise Enterprise-Informationsbibliothek.
•
HPE Matrix Operating Environment Einstiegshilfe
Enthält Installationsinformationen für Matrix Recovery Management und andere Komponenten
von Matrix Operating Environment. Verfügbar in der Hewlett Packard Enterprise
•
HPE Matrix Operating Environment Recovery Management Benutzerhandbuch
Enthält Informationen zur Installation, Konfiguration, Testverfahren und Fehlerbehebung
von Matrix Recovery Management. Verfügbar in der Hewlett Packard Enterprise
•
White Papers zu Matrix Recovery Management
White Papers zu Matrix Recovery Management sind in der Hewlett Packard Enterprise
Enterprise-Informationsbibliothek verfügbar.
•
Onlinehilfe für Matrix Recovery Management
Die Onlinehilfe für Matrix Recovery Management enthält Informationen zu Vorgängen, die
über die Benutzeroberfläche von Matrix Recovery Management ausgeführt werden. Die
Benutzeroberfläche und das Hilfemenü von Matrix Recovery Management sind über die
Startseite von Matrix Operating Environment zugänglich.
Hewlett Packard Enterprise Partner
91
Websites
Website
Link
Hewlett Packard Enterprise Informationsbibliothek
www.hpe.com/info/enterprise/docs
Hewlett Packard Enterprise Support Center
www.hpe.com/support/hpesc
Weltweite Kontaktinformationen für Hewlett Packard
Enterprise
www.hpe.com/assistance
Abonnementservice/Support-Benachrichtigungen
www.hpe.com/support/e-updates-de
Software Depot
www.hpe.com/support/softwaredepot
Customer Self Repair (Reparatur durch den Kunden)
www.hpe.com/support/selfrepair
Insight Remote Support
www.hpe.com/info/insightremotesupport/docs
Serviceguard Solutions für HP-UX
www.hpe.com/info/hpux-serviceguard-docs
Single Point of Connectivity Knowledge (SPOCK)
Speicher-Kompatibilitätsmatrix
www.hpe.com/storage/spock
Speicher-White Papers und Analystenstudien
www.hpe.com/storage/whitepapers
nl
Customer Self Repair (Reparatur durch den Kunden)
Hewlett Packard Enterprise Customer Self Repair (CSR)-Programme ermöglichen Ihnen, Ihr
Produkt zu reparieren. Wenn ein CSR-Teil ersetzt werden muss, wird es direkt an Sie geschickt,
sodass Sie es installieren können, wenn es am besten in Ihren Zeitablauf passt. Einige Teile
entsprechen nicht den CSR-Kriterien. Ihr Hewlett Packard Enterprise Servicepartner kann Ihnen
mitteilen, ob eine Reparatur im Rahmen des CSR-Programms vorgenommen werden kann.
Weitere Informationen zum CSR-Programm erhalten Sie von Ihrem Servicepartner oder auf der
CSR-Website:
www.hpe.com/support/selfrepair
Remote-Support
Remote-Support ist bei unterstützten Geräten im Rahmen Ihrer Garantie oder Ihres
Supportvertrags verfügbar. Remote-Support ermöglicht eine intelligente Ereignisdiagnose und
automatische, sichere Übermittlung von Hardware-Ereignisbenachrichtigungen an Hewlett
Packard Enterprise. Hewlett Packard Enterprise leitet dann eine schnelle und akkurate Lösung
des Problems basierend auf dem Service-Level des Produkts in die Wege. Hewlett Packard
Enterprise rät Ihnen sehr dazu, Ihr Gerät für Remote-Support zu registrieren.
Weitere Informationen und Einzelheiten zur Unterstützung des Geräts finden Sie auf der folgenden
Website:
www.hpe.com/info/insightremotesupport/docs
Rückmeldungen zur Dokumentation
Hewlett Packard Enterprise bemüht sich, an Ihren Bedürfnissen orientierte Dokumentation
bereitzustellen. Helfen Sie uns, die Dokumentation zu verbessern, indem Sie uns Hinweise zu
Fehlern, Anregungen, Kommentare oder Rückmeldungen zur Dokumentation zusenden
([email protected]). Schließen Sie in Ihre Rückmeldungen den Titel des Dokuments,
die Teilenummer, die Ausgabe und das Veröffentlichungsdatum ein, die auf der Umschlagseite
des Dokuments angegeben werden. Schließen Sie bezüglich des Inhalts der Onlinehilfe den
Produktnamen, die Produktversion, die Ausgabe der Hilfe und das Veröffentlichungsdatum ein,
die auf der Seite mit den rechtlichen Hinweisen angegeben werden.
92
Support und weitere Ressourcen
A Wiederherstellen eines CSV aus dem Zustand online
pending
Wenn Sie am Remote-Standort einen Aktivierungsvorgang durchführen, ohne das CSV am
lokalen Standort in den Offline-Zustand zu versetzen, kann es sein, dass am lokalen Standort
die folgenden Symptome auftreten:
•
Es sind keine Speicherinformationen verfügbar, wenn Sie zur Speicheransicht im Windows
Failover Cluster Management-Tool navigieren.
•
Das CSV befindet sich im Zustand online pending.
Gehen Sie wie folgt vor, um diese Symptome abzustellen:
1. Führen Sie mit dem Speicherverwaltungstool Ihrer Wahl die folgenden Schritte durch:
1. Machen Sie den Export des virtuellen CSV-Volumes vom Hyper V-Cluster rückgängig.
Notieren Sie sich die LUN-Nummer. Lassen Sie das virtuelle Volume unexportiert bis
zu einem geeigneten Wartungszeitpunkt.
2. Deaktivieren Sie während des Wartungszeitraums die Wiederherstellungsgruppe an
dem anderen Standort, wo sie derzeit möglicherweise aktiv ist, und versetzen Sie das
CSV in den Offline-Zustand.
3. Führen Sie ein Speicherfailover durch, um das virtuelle CSV-Volume in den
Lesen-/Schreiben-Modus zu versetzen.
4. Exportieren Sie das virtuelle CSV-Volume zum Hyper V-Cluster; verwenden Sie dabei
die gleiche LUN-Nummer wie beim ursprünglichen Export des LUN.
2. Versetzen Sie das CSV mit dem Hyper V Cluster Manager wieder in den Online-Zustand.
3. Geben Sie dem CSV-Ordner wieder den ursprünglichen Ordnernamen.
4. Führen Sie Logical Server-Aktualisierungsressourcen im Matrix OE Visualization GUI aus.
5. Aktivieren Sie die Wiederherstellungsgruppen auf dem CMS.
93
Glossar
Auftrag
Ein automatisierter, in mehrere Schritte unterteilter Prozess, der mit folgenden Vorgängen
verknüpft ist:
•
Ein Activate (Aktivieren)- oder Deactivate (Deaktivieren)-Vorgang in Matrix Recovery
Management.
•
Ein Vorgang zum Importieren eines Standorts in Matrix Recovery Management.
•
Ein Vorgang zum Importieren einer Wiederherstellungsgruppe in Matrix Recovery
Management.
Benutzerdefinierte Speicherverwaltungsserver
Wenn Sie in Ihrer Matrix Recovery Management -Konfiguration für einen Speichertyp, bei dem
es sich nicht um 3PAR StoreServ, P6000 oder P9000 handelt, einen Speicheradapter installieren,
können Sie Speicherverwaltungsserver basierend auf diesem Speicheradapter definieren (und
bearbeiten). Diese werden in einer Matrix Recovery Management-Konfiguration als
benutzerdefinierte Speicherverwaltungsserver bezeichnet. Wenn Sie z. B. einen Speicheradapter
namens EMC erstellen und installieren, können Sie im Dropdown-Menü Storage server type
(Speicherservertyp) zum Konfigurieren eines Speicherverwaltungsservers als Speicherservertyp
EMC auswählen. Weitere Informationen finden Sie in derMatrix Operating Environment
Einstiegshilfe in der Hewlett Packard Enterprise Enterprise-Informationsbibliothek.
Benutzerdefinierter Speicher
Matrix Recovery Management bietet eine benutzerdefinierte
Speicheradapter-Schnittstellenspezifikation, um das Matrix Recovery Management-Failover in
einem Schritt für Speichertypen zu ermöglichen, die von Matrix OE unterstützt werden, aber
noch nicht in Matrix Recovery Management integriert wurden.
Bidirektionales
Failover
Eine Matrix Recovery Management-Funktion, die die Aktivierung bzw. Deaktivierung am lokalen
Standort oder Remote-Standort ermöglicht. Wiederherstellungsgruppensätze können an beiden
Standorten zu jedem beliebigen Zeitpunkt aktiviert bzw. deaktiviert werden. Bei einem Notfall
oder zur Ermöglichung der Standortwartung können alle Wiederherstellungsgruppensätze in
der Matrix Recovery Management-Konfiguration an einem Standort deaktiviert und am anderen
Standort aktiviert werden.
CMS
Systems Insight Manager (SIM) Central Management Server: Ein System in der
Verwaltungsdomäne, das die SIM-Software ausführt. Alle zentralen Operationen innerhalb von
SIM werden von diesem System initiiert.
CSV
Cluster Shared Volumes.
DR-geschützt
Logische Server und Matrix Infrastructure Orchestration-Dienste, die von Matrix Recovery
Management verwaltet werden, werden als DR-geschützte (Disaster Recovery-geschützte)
logische Server und IO-Dienste bezeichnet.
DR-Gruppe
(Disaster Recovery Group, Notfallwiederherstellungsgruppe) Der in der P6000 Continuous
Access Software verwendete Begriff für eine Speicherreplikationsgruppe.
Erkennung
Eine Funktion innerhalb einer Verwaltungsanwendung, mit der Netzwerkobjekte gefunden und
identifiziert werden. Mit Hewlett Packard Enterprise Verwaltungsanwendungen werden alle
Hewlett Packard Enterprise Netzwerke innerhalb eines angegebenen Netzwerkbereichs gefunden
und identifiziert.
Geplantes
Failover
Ein Failover aller Wiederherstellungsgruppensätze von einem Standort zu einem anderen
Standort, das in Erwartung eines drohenden Notfalls oder einer geplanten Ausfallzeit am lokalen
Standort gestartet wird.
HPE Matrix OE
Logical Server
Management
Eine Komponente der Matrix Operating Environment-Software, mit der mit logischen Servern
zusammenhängende Vorgänge verwaltet und automatisiert werden, einschließlich Bereitstellung,
Starten und Herunterfahren von Ressourcen.
HPE SIM
Systems Insight Manager
IO Services
Matrix Operating Environment Infrastructure Orchestration-Dienste.
94
Glossar
IO-Dienstreplikat
Ein IO-Dienstreplikat ist ein Dienst, der von Matrix Recovery Management während eines
Importvorgangs an einem Wiederherstellungsstandort basierend auf der Definition des
exportierten IO-Dienstes in der Matrix Recovery Management-Exportdatei erstellt wird.
Konsistenzgruppe
Konsistenzgruppen sind eine wichtige Eigenschaft von Volumes im asynchronen Modus. Eine
Konsistenzgruppe ist eine Gruppe von LUNs, die von der Perspektive der Datenkonsistenz aus
gesehen (I/O-Sortierreihenfolge) gleich behandelt werden müssen. Eine Konsistenzgruppe
entspricht in der Raid Manager-Konfigurationsdatei einer Gerätegruppe.
Logische Server
für
IO-Dienstreplikate
Mit IO-Dienstreplikaten verknüpfte logische Server.
Logische Server
mit
Mischtechnologie
Logische Server, die zwischen physischen Servern (VC-Host) oder Virtual Machines (VM-Host)
hin und her verschoben werden können. Unter VC-gehosteter logischer Server und
VM-gehosteter logischer Server finden Sie weitere Informationen.
Logische Wiederherstellungsserver
Logische Server am Remote-Standort, die in einer Wiederherstellungsgruppe enthalten sind.
Sie sind mit logischen Servern am lokalen Standort verknüpft, die in der gleichen
Wiederherstellungsgruppe enthalten sind. Gewöhnlich sind sie deaktiviert. Sie werden bei einem
Standort-Failover aktiviert.
Logischer Server
Logische Server sind Verwaltungsabstraktionen, mit denen die Bereitstellung, Verwaltung und
Verschiebung von Servern, egal ob von physischen Servern oder Virtual Machines, erleichtert
und optimiert werden. Ein logischer Server ist das vollständige Softwareabbild eines Servers,
inklusive Betriebssystem, Anwendungen, Konfigurationsdaten und Metadaten. Es wird von
Ihnen erstellt und zur Ausführung auf einem physischen Server oder einem virtuellen System
zugewiesen. Logische Server werden durch mit Matrix OE Visualization verwaltet.
Logischer Server
der IO-Dienste
Ein logischer Server, der mit IO-Diensten verknüpft ist.
Lokaler Standort
In einer Matrix Recovery Management-Konfiguration ist dies der Satz verwalteter Knoten und
zugehöriger CMS, mit dem Ihr Browser interagiert.
Matrix Infrastructure Orchestration-Dienste
Matrix Infrastructure Orchestration-Dienste (IO-Dienste) ermöglichen eine schnelle Bereitstellung
der Infrastruktur zum automatischen Aktivieren physischer und virtueller Server, Speicher und
Netzwerke über Pools gemeinsam genutzter Ressourcen. Weitere Informationen über Matrix
Infrastructure Orchestration sind verfügbar unter http://www.hpe.com/info/insightorchestration.
Nicht geplantes
Failover
Ein Failover aller Wiederherstellungsgruppensätze von einem Standort zu einem anderen
Standort, das als Antwort auf ein unvorhergesehenes Ereignis durchgeführt wird, welches an
dem Standort, an dem die Wiederherstellungsgruppensätze aktiviert wurden, einen Ausfall
verursachte.
NPIV
N_Port ID Virtualization (N_Port-ID-Virtualisierung)
Portabilitätsgruppe
Eine Portabilitätsgruppe ist eine Gruppe aus Virtual Machines oder c-Class-Blades, die mit
Virtual Connect (oder einer Kombination aus Virtual Machines und c-Class-Blades) ausgestattet
sind, zwischen denen ein logischer Server verschoben werden kann.
Eine Konfigurationseinstellung der Wiederherstellungsgruppe, mit der die minimale zeitliche
Verzögerung (in Minuten) zwischen dem Einschalten von zwei logischen Servern in einer
Wiederherstellungsgruppe festgelegt wird. Die tatsächliche Verzögerungszeit kann die
angegebene Mindestzeit überschreiten.
Preferred Site
(Bevorzugter
Standort)
Der bevorzugte Standort ist der Standort, an dem die Wiederherstellungsgruppe aktiviert werden
soll, vorausgesetzt, die Umstände erfordern keine Aktivierung der Wiederherstellungsgruppe
am sekundären Standort.
Primärer
IO-Dienst
Ein primärer IO-Dienst ist die erste Instanz eines IO-Dienstes, den Sie für den DR-Schutz in
einer Matrix Recovery Management-Konfiguration auswählen. Ein IO-Dienstreplikat ist ein
Dienst, der von Matrix Recovery Management während eines Importvorgangs an einem
95
Wiederherstellungsstandort basierend auf der Definition des primären IO-Dienstes in der Matrix
Recovery Management-Exportdatei erstellt wird.
Privat
Ein Subnetz, das nicht außerhalb des Rechenzentrums geroutet ist und typischerweise nur
Adressen in den Bereichen 192.x.x.x oder 10.x.x.x enthält. Ein Subnetz, auf das vom Internet
aus zugegriffen werden kann, und das keine IP-Adressen in den Bereichen 192.x.x.x oder
10.x.x.x enthalten kann.
RDM
Raw Device Mapping
Redundantes
SAN
Die Duplizierung von Komponenten, um einen Ausfall der SAN-Lösung zu verhindern.
Remote-Standort
Ein Standort in einer Matrix Recovery Management-Konfiguration, bei dem es sich nicht um
den lokalen Standort handelt.
SAN
Ein Storage Area Network (oder Subnetzwerk), das die Datenspeichergeräte mit zugehörigen
Datenservern verbindet. Ein SAN ist gewöhnlich Teil eines Gesamtnetzwerks von
Rechner-Ressourcen.
Secondary Site
(Sekundärer
Standort)
Der sekundäre Standort ist der Standort, an dem Sie die Wiederherstellungsgruppe im
Standby-Modus (in einem deaktivierten Zustand) haben möchten, vorausgesetzt, die Umstände
erfordern keine Aktivierung der Wiederherstellungsgruppe am sekundären Standort.
Speicherentkoppelung
Eine Matrix Recovery Management-Funktion, die ein Failover der logischen Server oder
IO-Dienste in einer Wiederherstellungsgruppe ermöglicht, ohne ein Failover der
Speicherwiederherstellungsgruppen durchzuführen, die mit diesen logischen Servern oder
IO-Diensten verknüpft sind.
Speicherreplikationsgruppe
Ein Satz von LUNs, über den hinweg die Speicherreplikation die Schreibreihenfolge auf dem
Replikations-Zielspeicher-Array beibehält. In der P6000 Continuous Access
Software-Terminologie wird dies als DR-Gruppe bezeichnet. In der P9000 Continuous Access
Software-Terminologie wird dies als Konsistenzgruppe bezeichnet.
Speicherverwaltungsserver
Im Rahmen des Matrix Recovery Management-Konfigurationsvorgangs müssen Server definiert
werden, die P6000, P9000, 3PAR StoreServ oder benutzerdefinierte Speichergeräte verwalten.
Diese Server werden als Speicherverwaltungsserver bezeichnet.
Split-Brain
Zu einem Split-Brain kommt es, wenn zwei oder mehr Instanzen der gleichen Anwendung
gleichzeitig aktiv sind und möglicherweise zu einer Datenbeschädigung führen.
Unterauftrag
Ein Unterauftrag ist die Komponente eines von Matrix Recovery Management durchgeführten
Aktivierungs- oder Deaktivierungsauftrags bzw. eines Auftrags zum Importieren einer
Wiederherstellungsgruppe oder eines Standorts. Ein Standortaktivierungsauftrag würde
beispielsweise einen Unterauftrag zur Wiederherstellungsgruppenaktivierung für jede an diesem
Standort aktivierte Wiederherstellungsgruppe umfassen, und ein Unterauftrag zur
Wiederherstellungsgruppenaktivierung würde einen Unterauftrag zur Aktivierung logischer
Server für jeden logischen Server in dieser Wiederherstellungsgruppe umfassen.
VC-gehosteter
logischer Server
Ein logischer Server, der auf einem mit Virtual Connect ausgestatteten C-class Blade
ausgeführt wird.
VM-gehosteter
logischer Server
Ein logischer Server, der auf einer Virtual Machine unter der Kontrolle eines Hypervisors
ausgeführt wird.
Wartungsmodus
Im Wartungsmodus werden Wiederherstellungsgruppen getestet, um sicherzustellen, dass sie
beim Durchführen des Vorgangs Activate (Aktivieren) ordnungsgemäß funktionieren. Im
Wartungsmodus wird Matrix Recovery Management vorübergehend an der Verwaltung eines
DR-geschützten logischen Servers oder IO-Dienstes gehindert. Ein Zweck des Wartungsmodus
besteht darin, das Failover zu üben. Wenn der Wartungsmodus für eine
Wiederherstellungsgruppe eingestellt wird, dann können alle logischen Server und IO-Dienste
in der betreffenden Wiederherstellungsgruppe über Matrix Operating Environment aktiviert
werden. Wenn Sie mit der Failover-Übung zufrieden sind, können die Wiederherstellungsgruppe
und ihre zugehörigen logischen Server oder IO-Dienste wieder unter die Kontrolle von Matrix
Recovery Management gebracht werden.
96
Glossar
Wiederherstellbare
IO-Dienste
Matrix Infrastructure Orchestration-Dienste, die so konfiguriert wurden, dass Sie in einer
DR-geschützten Wiederherstellungsgruppe mit Matrix Recovery Management-IO-Diensten
aufgenommen werden können.
Wiederherstellungsgruppe
Eine Kombination aus einem oder mehreren logischen Servern und einer einzelnen
Replikationsgruppe. Mit einer Wiederherstellungsgruppe ist eine
„Wiederherstellungsgruppen-Startreihenfolgen“-Nummer verknüpft. Während eines
Standort-Failovers wird das Failover der Wiederherstellungsgruppen in der angegebenen
Reihenfolge von einem Standort zu einem anderen Standort vollzogen.
Wiederherstellungsgruppen-Startreihenfolge
Eine optionale Nummer, durch die die Reihenfolge angegeben wird, in der eine
Wiederherstellungsgruppe während eines Standort-Failovers gestartet wird.
Wiederherstellungsgruppen ohne Startreihenfolgen-Nummer werden nach allen
Wiederherstellungsgruppen mit zugehöriger Startreihenfolgen-Nummer gestartet.
Wiederherstellungsgruppensatz
Eine Gruppe von Wiederherstellungsgruppen, die die gleichen bevorzugten und sekundären
Standorte verwenden. Wiederherstellungsgruppen können nicht einzeln aktiviert bzw. deaktiviert
werden. Hingegen müssen Wiederherstellungsgruppen, die den gleichen bevorzugten und
sekundären Standort verwenden, als Gruppe aktiviert bzw. deaktiviert werden.
Wiederherstellungsgruppensätze können zur Aktivierung oder Deaktivierung am lokalen Standort
ausgewählt werden.
97
Stichwortverzeichnis
technologieübergreifende logische Server , 49
Übersicht, 6
unterstützte Plattformen, 53
B
Befehlszeile
drsync, 44
Benutzerdefiniert
Erstellen, 16
Installieren, 16
R
D
S
Dokumentation
Einsenden von Rückmeldungen zur, 92
DR-geschützt
IO-Dienste, 30
Konfigurieren von IO-Diensten, 31
technologieübergreifende logische Server , 65
drsync
dr.properties, 45
Globbing-Ausdrücke, 47
Support
Hewlett Packard Enterprise, 89
Remote-Support, 92
Reparatur durch den Kunden, 92
T
Technologieübergreifende logische Server
physisch, 53
virtuell, 53
Tools
PINT , 58
PISA , 57
E
Einrichten
HPE 3PAR StoreServ-Speicher, 15
HPE P6000, 13
HPE P9E000, 14
logische Server am lokalen Standort, 18
logische Server am Remote-Standort, 19
Network, 10
Speicher, 12
F
Fehlerbehebung
Aufträge, 79
DR-geschützte IO-Dienste, 85
Failover, 83
Fehlermeldungen, 75
Warnmeldungen, 79
Fehlerbeseitigung, 72
updates
Zugreifen, 89
W
Websites, 92
Reparatur durch den Kunden, 92
Wiederherstellungsgruppe
Aktivieren des Wartungsmodus, 38
Deaktivieren des Wartungsmodus, 38
geplantes Failover, 39
nicht geplantes Failover, 40
Testen, 36
Wiederherstellungsgruppen
Failover, 36
Z
Zugreifen
Aktualisierungen, 89
I
Importieren
Auftrag, 27
Wiederherstellungsgruppen, 26
K
Kontaktieren von Hewlett Packard Enterprise, 89
M
Matrix Recovery Management
Deinstallieren, 10
Dokumentation, 91
Exportvorgang, 22
Importvorgang, 22
Installation, 9
Konfiguration, 9
Konfigurationsschritte, 21
Lizenzieren, 10
Protokolldateien, 84
98
U
Stichwortverzeichnis

HPE Matrix Operating Environment 7.5 Recovery Management

Transcrição

Documentos relacionados

Flyer A6 2014 GzD (PDF-Datei/256KB)

Produktinfo 6_2008.pmd

your professional partner in the heart of europe

Matrix 7.5 Installationsanleitung

Broschüre Clickstream

Netzwerktechnik CHS Villach Mag. Rainer Swatek Dauer: 2

Übung 5

Boris Prach

Astrologie und Matrix Transformation

lambrex wp-g - Austin Powder GmbH