Kapitel 4 Fragen und Antworten

Dieses Kapitel enthält die häufig gestellten Fragen zum Sun Cluster-System. Die Fragen sind nach Thema geordnet.

FAQs zur hohen Verfügbarkeit

Was genau ist ein hoch verfügbares System?

Das Sun Cluster-System definiert hohe Verfügbarkeit (HA) als die Fähigkeit eines Clusters, eine Anwendung kontinuierlich auszuführen. Die Anwendung wird auch dann ausgeführt, wenn ein Fehler auftritt, nach dem ein Serversystem in der Regeln nicht mehr verfügbar ist.

Mit welchem Prozess sorgt der Cluster für Hochverfügbarkeit?

Mit einem Prozess, der als Failover bezeichnet wird, sorgt das Cluster-Framework für eine hoch verfügbare Umgebung. Ein Failover ist eine Reihe von Schritten, mit denen der Cluster Datendienstressourcen von einem versagenden Knoten auf einen anderen funktionsfähigen Knoten im Cluster migriert.

Was ist der Unterschied zwischen einem Failover- und einem Scalable-Datendienst?

Es gibt zwei Typen von hoch verfügbaren Datendiensten:

• Failover

• Scalable

Ein Failover-Datendienst führt eine Anwendung jeweils nur auf einem Primärknoten im Cluster aus. Andere Knoten können andere Anwendungen ausführen, aber jede Anwendung wird nur einmal auf einem einzigen Knoten ausgeführt. Wenn ein Primärknoten ausfällt, werden die auf dem ausgefallenen Knoten ausgeführten Anwendungen mit einem Failover auf einen anderen Knoten verschoben und dort weiter ausgeführt.

Ein Scalable-Dienst verteilt eine Anwendung auf mehrere Knoten, um einen einzigen logischen Dienst zu erstellen. Scalable-Dienste setzen die Anzahl der Knoten und Prozessoren auf dem ganzen Cluster, auf dem sie durchgeführt werden, wirksam ein.

Für jede Anwendung hostet ein Knoten die reale Schnittstelle zum Cluster. Dieser Knoten wird als globaler Schnittstellenknoten (GIF-Knoten) bezeichnet. Im Cluster können mehrere GIF-Knoten vorhanden sein. Jeder GIF-Knoten hostet eine oder mehr logische Schnittstellen, die von Scalable-Diensten genutzt werden können. Diese logischen Schnittstellen werden als globale Schnittstellen bezeichnet. Ein GIF-Knoten hostet eine globale Schnittstelle für alle Anforderungen einer bestimmten Anwendung und sendet sie an mehrere Knoten, auf denen der Anwendungsserver läuft. Wenn der GIF-Knoten ausfällt, wird die globale Schnittstelle auf einen auch weiterhin laufenden Knoten umgeleitet.

Wenn einer der Knoten ausfällt, auf denen die Anwendung ausgeführt wird, wird sie weiterhin auf den anderen Knoten mit leich verminderter Leistung ausgeführt. Dieser Prozess wird fortgesetzt, bis der ausgefallene Knoten wieder zum Cluster hinzukommt.

FAQs zu Dateisystemen

Kann mindestens ein Cluster-Knoten als hoch verfügbarer NFS-Server mit anderen Cluster-Knoten als Client konfiguriert werden?

Nein, schaffen Sie keine Schleifeneinhängung.

Kann ein Cluster-Dateisystem für Anwendungen verwendet werden, die nicht von Ressourcengruppen-Manager gesteuert werden?

Ja. Allerdings müssen die Anwendungen ohne Steuerung durch den RGM nach dem Ausfall des Knotens, auf dem sie ausgeführt werden, manuell neu gestartet werden.

Müssen alle Cluster-Dateisysteme einen Einhängepunkt unter dem /global-Verzeichnis haben

Nein. Aber Cluster-Dateisysteme mit demselben Einhängepunkt (wie zum Beispiel /global) ermöglichen eine bessere Organisation und Verwaltung dieser Dateisysteme.

Welches sind die Unterschiede zwischen der Verwendung eines Cluster-Dateisystems und dem Exportieren von NFS-Dateisystemen?

Es gibt mehrere Unterschiede:

1. Das Cluster-Dateisystem unterstützt globale Geräte. NFS unterstützt keinen Remote-Zugriff auf Geräte.

2. Das Cluster-Dateisystem hat einen globalen Namensraum. Nur ein einziger Einhängebefehl ist erforderlich. Bei NFS müssen Sie das Dateisystem auf jedem Knoten einhängen.

3. Das Cluster-Dateisystem speichert die Dateien in mehr Fällen als NFS im Cache. Das Cluster-Dateisystem speichert beispielsweise Dateien, wenn auf eine Datei von mehreren Knoten aus zum Lesen, Schreiben, für Dateisperren oder asynchronen E/A zugegriffen wird.

4. Das Cluster-Dateisystem ist auf die Nutzung zukünftiger schneller Cluster-Interconnects ausgelegt, die DMA-Funktionen und Funktionen ohne Zwischenspeicherung (Zero-Copy) im Fernzugriff zur Verfügung stellen.

5. Wenn Sie die Attribute für eine Datei (zum Beispiel mit chmod(1M) ) in einem Cluster-Dateisystem ändern, wird diese Änderung sofort auf alle Knoten gespiegelt. Bei einem exportierten NFS-Dateisystem kann das wesentlich mehr Zeit in Anspruch nehmen.

TDas Dateisystem /global/.devices/node@nodeID wird auf den Cluster-Knoten angezeigt. Kann dieses Dateisystem zum Speichern von Daten verwendet werden, die hoch verfügbar und global sein sollen?

Diese Dateisysteme speichern den Namensraum für globale Geräte. Diese Dateisysteme sind nicht zum allgemeinen Gebrauch vorgesehen. Sie sind zwar global, aber der Zugriff auf sie erfolgt niemals global – jeder Knoten kann nur auf seinen eigenen Namensraum für globale Geräte zugreifen. Wenn ein Knoten ausgefallen ist, können andere Knoten nicht auf den Namensraum für den ausgefallenen Knoten zugreifen. Diese Dateisysteme sind nicht hoch verfügbar. Sie sollten nicht zum Speichern von Daten verwendet werden, die global zugänglich oder hoch verfügbar sein müssen.

FAQs zur Datenträgerverwaltung

Müssen alle Plattengeräte gespiegelt werden?

Damit ein Plattengerät als hoch verfügbar gilt, muss es gespiegelt werden oder RAID-5-Hardware verwenden. Alle Datendienste sollten entweder hoch verfügbare Plattengeräte oder Cluster-Dateisysteme verwenden, die auf hoch verfügbaren Plattengeräten eingehängt sind. Solche Konfigurationen tolerieren einzelne Plattenausfälle.

Kann ein Datenträger-Manager für die lokalen Platten (Boot-Platte) und ein anderer für die Multihostplatten verwendet werden?

SPARC: Diese Konfiguration wird von der Solaris Volume Manager-Software zur Verwaltung der lokalen Platten und von VERITAS Volume Manager zur Verwaltung der Multihostplatten unterstützt. Keine andere Kombination wird unterstützt.

x86:Diese Konfiguration wird nicht unterstützt, da in x86-basierten Clustern nur Solaris Volume Manager unterstützt wird.

FAQs zu Datendiensten

Welche Sun Cluster-Datendienste sind verfügbar?

Die Liste der unterstützten Datendienste finden Sie unter Unterstützte Produkte in Sun Cluster 3.1 8/05 Versionshinweise für Solaris OS.

Welche Anwendungsversionen werden von den Sun Cluster-Datendiensten unterstützt?

Die Liste der unterstützten Anwendungsversionen finden Sie unter Unterstützte Produkte in Sun Cluster 3.1 8/05 Versionshinweise für Solaris OS.

Können eigene Datendienste geschrieben werden?

Ja. Weitere Informationen finden Sie in Kapitel 11, DSDL-API-Funktionen in Sun Cluster Entwicklerhandbuch Datendienste für Solaris OS.

Müssen beim Erstellen von Netzwerkressourcen numerische IP-Adressen oder Hostnamen angegeben werden?

Die bevorzugte Methode zur Angabe von Netzwerkressourcen ist die Verwendung des UNIX-Hostnamens anstelle der numerischen IP-Adresse.

Was ist beim Erstellen von Netzwerkressourcen der Unterschied zwischen der Verwendung eines logischen Hostnamens (LogicalHostname-Ressource) und einer gemeinsam genutzten Adresse (SharedAddress-Ressource)?

Wenn in der Dokumentation die Verwendung einer LogicalHostname-Ressource in einer Ressourcengruppe im Failover-Modus empfohlen wird, kann wahlweise eine SharedAddress-Ressource oder eine LogicalHostname-Ressource verwendet werden. Die einzige Ausnahme bildet Sun Cluster HA für NFS. Die Verwendung einer SharedAddress-Ressource sorgt für zusätzlichen Überlauf weil die Cluster-Netzwerksoftware für eine SharedAddress, aber nicht für einen LogicalHostname konfiguriert ist.

Der Vorteil einer SharedAddress wird deutlich, wenn Sie sowohl Scalable- als auch Failover-Datendienste konfigurieren und möchten, dass Clients mithilfe desselben Hostnamens auf beide Dienste zugreifen können. In diesem Fall ist bzw. sind die SharedAddress-Ressource(n) zusammen mit der Failover-Anwendungsressource in einer Ressourcengruppe enthalten. Die Scalable-Dienstressource ist in einer separaten Ressourcengruppe untergebracht und für die Verwendung der SharedAddress-Ressource konfiguriert . Sowohl Scalable- als auch Failover-Dienste können denselben Satz von Hostnamen/Adressen verwenden, der in der SharedAddress-Ressource konfiguriert ist.

FAQs zum öffentlichen Netzwerk

Welche öffentlichen Netzwerkadapter werden vom Sun Cluster-System unterstützt?

Derzeit unterstützt das Sun Cluster-System öffentliche Netzwerkadapter für Ethernet (10/100BASE-T und 1000BASE-SX Gb). Zukünftig werden ggf. neue Schnittstellen unterstützt. Aktuelle Informationen erhalten Sie von Ihrem Sun-Vertreter.

Welche Rolle spielt die MAC-Adresse beim Failover?

Bei einem Failover werden neue ARP-Pakete (Address Resolution Protocol-Pakete) generiert und an alle gesendet. Diese ARP-Pakete enthalten die neue MAC-Adresse (des neuen tatsächlichen Adapters, zu dem der Knoten gewechselt ist) und die alte IP-Adresse. Wenn ein anderer Rechner im Netzwerk eines dieser Pakete erhält, löscht er die alte MAC-IP-Zuordnung aus seinem ARP-Cache und verwendet die neue.

Unterstützt das Sun Cluster-System die Einstellung local-mac-address?=true ?

Ja. Tatsächlich erfordert IP Network Multipathing, dass local-mac-address? auf true gesetzt sein muss.

Sie können local-mac-address? mit eeprom(1M) an der Eingabeaufforderung ok in einem SPARC-basierten Cluster einstellen. Alternativ können Sie die MAC-adresse mit dem SCSI-Dienstprogramm einstellen, das Sie optional nach dem Starten der BIOS in einem x86-basierten Cluster ausführen.

Welche Verzögerung ist zu erwarten, wenn Internet Protocol (IP) Network Multipathing ein Switchover zwischen Adaptern ausführt?

Die Verzögerung kann mehrere Minuten betragen. Der Grund dafür ist, dass ein Internet Protocol (IP) Network Multipathing-Switchover das Senden eines freien ARP beinhaltet. Sie können jedoch nicht sicher sein, dass der Router zwischen Client und Cluster dieses freie ARP auch verwendet. Bis zum Ablauf der Gültigkeit des ARP-Cache-Eintrags für diese IP-Adresse auf dem Router wird für den Eintrag möglicherweise die veraltete MAC-Adresse verwendet.

Wie schnell werden Fehler an einem Netzwerkadapter erkannt?

Die Standard-Fehlererkennungszeit beträgt 10 Sekunden. Der Algorithmus versucht, die Fehlererkennungszeit einzuhalten, doch die tatsächlich benötigte Zeit hängt von der Netzwerklast ab.

FAQs zu Cluster-Mitgliedern

Muss das Root-Passwort für alle Cluster-Mitglieder gleich sein?

Sie sind nicht gezwungen, dasselbe Root-Passwort für jedes Cluster-Mitglied zu verwenden. Sie können jedoch die Cluster-Verwaltung vereinfachen, wenn Sie auf allen Knoten dasselbe Root-Passwort verwenden.

Ist es wichtig, in welcher Reihenfolge die Knoten gebootet werden?

In den meisten Fällen nicht. Die Boot-Reihenfolge ist jedoch wichtig, um Amnesie zu verhindern. Wenn Knoten Zwei zum Beispiel der Eigentümer des Quorum-Geräts war, Knoten Eins nicht aktiv ist und Sie dann Knoten Zwei herunterfahren, müssen Sie Knoten Zwei vor Knoten Eins wieder hochfahren. Mit dieser Reihenfolge wird verhindert, dass Sie versehentlich einen Knoten mit veralteten Cluster-Konfigurationsinformationen starten. Details zu Amnesie finden Sie unter Informationen zum Fehlerschutz .

Müssen lokale Platten in einem Cluster-Knoten gespiegelt werden?

Ja. Diese Spiegelung ist zwar keine Voraussetzung, aber das Spiegeln der Platten der Cluster-Knoten beugt einem Ausfall einer nicht gespiegelten Platte vor, der einen Knotenausfall nach sich zieht. Der Nachteil beim Spiegeln lokaler Platten eines Cluster-Knotens ist ein erhöhter Systemverwaltungsaufwand.

Welche Sicherungslösungen gibt es für Cluster-Mitglieder?

Sie können mehrere Sicherungsmethoden für einen Cluster verwenden. Eine Methode besteht darin, einen Knoten als Sicherungsknoten mit angeschlossenem Bandlaufwerk/Bibliothek zu verwenden. Dann sichern Sie die Daten mit dem Cluster-Dateisystem. Verbinden Sie diesen Knoten nicht mit den gemeinsam genutzten Platten.

Weitere Informationen zum Sichern und Wiederherstellen von Daten erhalten Sie in Kapitel 9, Sichern und Wiederherstellen eines Clusters in Sun Cluster Handbuch Systemverwaltung für Solaris OS.

Wann ist ein Knoten stabil genug, um als Sekundärknoten eingesetzt zu werden?

Solaris 8 und Solaris 9:

Nach dem erneuten Booten ist ein Knoten stabil genug, um als Sekundärknoten eingesetzt zu werden, wenn der Knoten die Anmelde-Eingabeaufforderung anzeigt.

Solaris 10:

Ein Knoten ist stabil genug, um als sekundärer Knoten zu fungieren, wenn der Meilenstein multi-user-server ausgeführt wird.

# svcs -a | grep multi-user-server:default

FAQs zum Cluster-Speicher

Was macht den Multihost-Speicher hoch verfügbar?

Multihost-Speicher ist hoch verfügbar, weil er den Verlust einer Einzelplatte dank der Spiegelung (oder dank hardwarebasierter RAID-5-Controller) übersteht. Ein Multihost-Speichergerät hat mehr als eine Hostverbindung. Deswegen widersteht es dem Verlust eines einzelnen Knotens, an den es angeschlossen ist. Zudem sorgen redundante Pfade von jedem Knoten zum angeschlossenen Speicher dafür, dass ein Versagen eines Hostbusadapters, Kabels oder Platten-Controllers toleriert wird.

FAQs zum Cluster-Interconnect

Welche Cluster-Interconnect werden vom Sun Cluster-System unterstützt?

Derzeit unterstützt das Sun Cluster-System die folgenden Cluster-Interconnects:

• Ethernet (100BASE-T Fast Ethernet und 1000BASE-SX Gb) sowohl in SPARC-basierten als auch in x86-basierten Clustern

• Infiniband in SPARC-basierten und x86-basierten Clustern

• SCI nur in SPARC-basierten Clustern

Was ist der Unterschied zwischen einem "Kabel" und einem "Transportpfad" ?

Cluster-Transportkabel werden unter Verwendung von Transportadaptern und Schaltern konfiguriert. Kabel verbinden Adapter und Schalter auf einer Komponente-zu-Komponenten-Basis. Der Cluster-Topologie-Manager setzt die verfügbaren Kabel ein, um durchgehende (von Ende zu Ende) Transportpfade zwischen den Knoten aufzubauen. Ein Kabel ist einem Transportpfad nicht direkt zugeordnet.

Kabel werden von einem Verwalter statisch "aktiviert" und "deaktiviert". Bei Kabeln gibt es einen "Zustand" (aktiv oder inaktiv), aber keinen "Status". Ein inaktives Kabel ist wie ein nicht konfiguriertes Kabel. Inaktive Kabel können nicht als Transportpfade eingesetzt werden. Diese Kabel werden nicht getestet und deshalb ist ihr Status nicht bekannt. Den Status des Kabels können Sie über den Befehl scconf -p abrufen.

Transportpfade werden dynamisch durch den Cluster-Topologie-Manager festgelegt. Der "Status" eines Transportpfades wird vom Topologie-Manager bestimmt. Ein Pfad kann den Status "online" oder "offline" haben. Den Status des Transportpfades können Sie mit dem Befehl scstat(1M) abrufen.

Betrachten Sie das folgende Beispiel eines Zwei-Knoten-Clusters mit vier Kabeln.

node1:adapter0      to switch1, port0
node1:adapter1      to switch2, port0
node2:adapter0      to switch1, port1
node2:adapter1      to switch2, port1

Zwei mögliche Transportpfade können aus diesen vier Kabeln gebildet werden.

node1:adapter0    to node2:adapter0
node2:adapter1    to node2:adapter1

FAQs zu Client-Systemen

Müssen bei der Verwendung eines Clusters besondere Client-Anforderungen oder Einschränkungen berücksichtigt werden?

Client-Systeme stellen mit dem Cluster die Verbindung auf dieselbe Weise wie mit einem anderen Server her. Bei manchen Instanzen kann es je nach Datendienstanwendung erforderlich sein, clientseitige Software zu installieren oder sonstige Änderungen an der Konfiguration vorzunehmen, damit der Client eine Verbindung mit der Datendienstanwendung herstellen kann. Weitere Informationen zu clientseitigen Konfigurationsanforderungen finden Sie in Kapitel 1, Planning for Sun Cluster Data Services in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

FAQs zur Verwaltungskonsole

Ist für das Sun Cluster-System eine Verwaltungskonsole erforderlich?

Ja.

Muss die Verwaltungskonsole dem Cluster zugewiesen werden oder kann sie auch für andere Aufgaben eingesetzt werden?

Das Sun Cluster-System benötigt keine dedizierte Verwaltungskonsole, die Verwendung einer solchen Konsole bietet jedoch folgende Vorteile:

• Sie ermöglicht eine zentralisierte Cluster-Verwaltung durch das Gruppieren von Konsolen- und Verwaltungstools auf demselben Rechner.

• Sie sorgt für eine potenziell schnellere Problemlösung durch Ihren Hardware-Dienstleister.

Muss sich die Verwaltungskonsole in der "Nähe" des Clusters befinden, zum Beispiel in demselben Raum?

Fragen Sie bei Ihrem Hardware-Dienstleister nach. Der Dienstleister kann ggf. die räumliche Nähe der Konsole zum eigentlichen Cluster vorschreiben. Es gibt keine technischen Gründe, die eine Unterbringung der Konsole in demselben Raum erforderlich machen.

Können Verwaltungskonsolen mehr als einen Cluster verwalten, wenn ggf. vorhandene Abstandsvorgaben eingehalten werden?

Ja. Sie können von einer einzigen Verwaltungskonsole aus mehrere Cluster steuern. Sie können auch einen einzigen Terminal-Konzentrator zwischen den Clustern teilen.

FAQs zu Terminal-Konzentrator und System Service Processor

Erfordert das Sun Cluster-System einen Terminal-Konzentrator?

Softwareversionen ab Sun Cluster 3.0 benötigen keinen Terminal-Konzentrator. Anders als das Produkt Sun Cluster 2.2, das einen Terminal-Konzentrator als Fehlerschutz benötigte, hängen neuere Produkte nicht vom Terminal-Konzentrator ab.

Die meisten Sun Cluster-Server verwenden einen Terminal-Konzentrator, aber der Sun Enterprise E1000-Server nicht. Weshalb nicht?

Der Terminal-Konzentrator ist für die meisten Server tatsächlich ein Seriell-zu-Ethernet-Konverter. Der Port der Konsole für den Terminal-Konzentrator ist ein serieller Port. Der Sun Enterprise E1000-Server verfügt nicht über eine serielle Konsole. Der System Service Processor (SSP) ist die Konsole, entweder über einen Ethernet- oder einen jtag-Port. Bei Sun Enterprise E1000-Servern verwenden Sie immer den SSP als Konsole.

Welches sind die Vorteile eines Terminal-Konzentrators?

Mit einem Terminal-Konzentrator können Sie auf Konsolenebene von einer Remote-Workstation an einer beliebigen Stelle im Netzwerk auf jeden Knoten zugreifen. Dieser Zugriff ist selbst dann möglich, wenn sich der Knoten am OpenBoot PROM (OBP) in einem SPARC-basierten Knoten oder einem Boot-Teilsystem in einem x86-basierten Knoten befindet.

Welches sind die für die Qualifizierung eines nicht von Sun unterstützten Terminal-Konzentrators erforderlichen Kenntnisse?

Der Hauptunterschied zwischen dem von Sun unterstützen Terminal-Konzentrator und anderen Konsolengeräten besteht darin, dass der Terminal-Konzentrator von Sun mit spezieller Firmware ausgestattet ist. Diese Firmware hindert den Terminal-Konzentrator daran, einen Abbruch an die bootende Konsole zu senden. Der Knoten wird durch ein Konsolengerät heruntergefahren, wenn das Gerät einen Abbruch oder ein von der Konsole als Abbruch interpretiertes Signal senden kann.

Kann ein gesperrter Port am von Sun unterstützten Terminal-Konzentrator freigeschaltet werden, ohne ihn neu zu booten?

Ja. Beachten Sie, dass die Port-Nummer neu eingestellt werden muss, und geben Sie folgende Befehle ein:

telnet tc
Enter Annex port name or number: cli
annex: su -
annex# admin
admin : reset port_number
admin : quit
annex# hangup
#

Weitere Informationen zur Konfiguration und Verwaltung des von Sun unterstützten Terminal-Konzentrators erhalten Sie in den folgenden Handbüchern:

• Überblick über die Verwaltung von Sun Cluster in Sun Cluster Handbuch Systemverwaltung für Solaris OS

• Kapitel 2, Installing and Configuring the Terminal Concentrator in Sun Cluster 3.0-3.1 Hardware Administration Manual for Solaris OS

Was geschieht, wenn der Terminal-Konzentrator selbst ausfällt? Ist ein zweiter als Standby-Gerät erforderlich?

Nein. Bei einem Versagen des Terminal-Konzentrators geht keine Cluster-Verfügbarkeit verloren. Sie können erst dann wieder eine Verbindung mit den Knotenkonsolen herstellen, wenn der Konzentrator wieder arbeitet.

Wenn sieht es bei einem Terminal-Konzentrator in puncto Sicherheit aus?

Im Allgemeinen ist der Terminal-Konzentrator mit einem kleinen Netzwerk verbunden, das von Systemverwaltern verwendet wird, und nicht mit einem Netzwerk, das für sonstigen Client-Zugriff eingesetzt wird. Sie können die Sicherheit durch einen beschränkten Zugriff auf dieses Netzwerk steuern.

SPARC: Wie wird die dynamische Rekonfiguration für ein Band- oder Plattenlaufwerk eingesetzt?

Führen Sie folgende Schritte durch:

• Stellen Sie fest, ob das Platten- oder Bandlaufwerk zu einer aktiven Gerätegruppe gehört. Wenn das Laufwerk zu keiner aktiven Gerätegruppe gehört, können Sie den DR-Entfernungsvorgang ausführen.

• Wenn der DR-Vorgang zur Board-Entfernung ein aktives Platten- oder Bandlaufwerk betrifft, lehnt das System den Vorgang ab und identifiziert die betroffenen Laufwerke. Wenn das Laufwerk zu einer aktiven Gerätegruppe gehört, erhalten Sie weitere Informationen unter SPARC: Erwägungen zur DR von Platten- und Bandlaufwerken im Cluster .

• Stellen Sie fest, ob das Laufwerk eine Komponente des Primär- oder Sekundärknotens ist. Wenn das Laufwerk eine Komponente des Sekundärknotens ist , können Sie den DR-Entfernungsvorgang ausführen.

• Wenn das Laufwerk eine Komponente des Primärknotens ist, müssen Sie vom Primär- auf den Sekundärknoten umschalten, bevor Sie den DR-Entfernungsvorgang für das Gerät durchführen können.

Wenn der aktuelle Primärknoten ausfällt, während Sie den DR-Vorgang auf einem Sekundärknoten ausführen, wirkt sich das auf die Cluster-Verfügbarkeit aus. Der Primärknoten kann kein Failover auf einen anderen Knoten ausführen, bis ein neuer Sekundärknoten bereitgestellt wird.