Skip to main content
ONTAP MetroCluster
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Konfigurieren der MetroCluster-Software in ONTAP

Beitragende
PDFs

Sie müssen jeden Node in der MetroCluster Konfiguration in ONTAP einrichten, einschließlich der Node-Konfiguration und der Konfiguration der Nodes an zwei Standorten. Sie müssen auch die MetroCluster Beziehung zwischen beiden Standorten implementieren.

Workflow Node- und Cluster-Konfigurationssoftware auf hoher Ebene
Schritte

  1. Sammeln Sie die erforderlichen IP-Adressen für die Controller-Module, bevor Sie mit dem Konfigurationsprozess beginnen.

  2. Füllen Sie das Arbeitsblatt für IP-Netzwerkinformationen für Standort A aus

Arbeitsblatt für IP-Netzwerkinformationen für Standort A

Vor dem Konfigurieren des Systems müssen Sie IP-Adressen und andere Netzwerkinformationen für den ersten MetroCluster-Standort (Standort A) vom Netzwerkadministrator beziehen.

Informationen zur Cluster-Erstellung von Standort A

Wenn Sie zum ersten Mal das Cluster erstellen, benötigen Sie die folgenden Informationen:

Informationstyp

Ihre Werte

Cluster-Name. Beispiel für diese Information: Site_A

DNS-Domäne

DNS-Name-Server

Standort

Administratorpasswort

Node-Informationen zu Standort A

Für jeden Node im Cluster benötigen Sie eine Management-IP-Adresse, eine Netzwerkmaske und ein Standard-Gateway.

Knoten

Port

IP-Adresse

Netzwerkmaske

Standard-Gateway

Knoten 1: Beispiel, das in diesen Informationen verwendet wird: Controller_A_1

Knoten 2: Nicht erforderlich, wenn eine MetroCluster Konfiguration mit zwei Nodes verwendet wird (ein Node an jedem Standort).

Beispiel, das in diesen Informationen verwendet wird: Controller_A_2

Standort A LIFs und Ports für Cluster-Peering

Sie benötigen für jeden Node im Cluster die IP-Adressen zweier Intercluster-LIFs, einschließlich einer Netzwerkmaske und eines Standard-Gateway. Die Intercluster-LIFs werden verwendet, um die Cluster miteinander zu begleichen.

Knoten

Port

IP-Adresse von Intercluster LIF

Netzwerkmaske

Standard-Gateway

Knoten 1 IC LIF 1

Knoten 1 IC LIF 2

Informationen zum Zeitserver an Standort A

Sie müssen die Zeit synchronisieren, die einen oder mehrere NTP-Zeitserver erfordert.

Knoten

Host-Name

IP-Adresse

Netzwerkmaske

Standard-Gateway

NTP-Server 1

NTP-Server 2

Standort A nbsp; AutoSupport-Informationen

Sie müssen AutoSupport für jeden Node konfigurieren. Dazu sind folgende Informationen erforderlich:

Informationstyp

Ihre Werte

Von E-Mail-Adresse

Mail-Hosts

IP-Adressen oder Namen

Transportprotokoll

HTTP, HTTPS ODER SMTP

Proxy-Server

E-Mail-Adressen oder Verteilerlisten des Empfängers

Mitteilungen in voller Länge

Präzise Nachrichten

SP-Informationen an Standort A

Sie müssen für die Fehlerbehebung und Wartung den Zugriff auf den Service-Prozessor (SP) jedes Node aktivieren. Hierfür sind für jeden Node die folgenden Netzwerkinformationen erforderlich:

Knoten

IP-Adresse

Netzwerkmaske

Standard-Gateway

Knoten 1

Arbeitsblatt für IP-Netzwerkinformationen für Standort B

Vor dem Konfigurieren des Systems müssen Sie IP-Adressen und andere Netzwerkinformationen für den zweiten MetroCluster-Standort (Standort B) vom Netzwerkadministrator beziehen.

Informationen zur Cluster-Erstellung von Standort B

Wenn Sie zum ersten Mal das Cluster erstellen, benötigen Sie die folgenden Informationen:

Informationstyp

Ihre Werte

Cluster-Name. Beispiel für diese Information: Site_B

DNS-Domäne

DNS-Name-Server

Standort

Administratorpasswort

Node-Informationen zu Standort B

Für jeden Node im Cluster benötigen Sie eine Management-IP-Adresse, eine Netzwerkmaske und ein Standard-Gateway.

Knoten

Port

IP-Adresse

Netzwerkmaske

Standard-Gateway

Knoten 1: Beispiel, das in diesen Informationen verwendet wird: Controller_B_1

Knoten 2: Nicht erforderlich für MetroCluster Konfigurationen mit zwei Nodes (ein Node an jedem Standort)

Beispiel, das in diesen Informationen verwendet wird: Controller_B_2

Standort B LIFs und Ports für Cluster-Peering

Sie benötigen für jeden Node im Cluster die IP-Adressen zweier Intercluster-LIFs, einschließlich einer Netzwerkmaske und eines Standard-Gateway. Die Intercluster-LIFs werden verwendet, um die Cluster miteinander zu begleichen.

Knoten

Port

IP-Adresse von Intercluster LIF

Netzwerkmaske

Standard-Gateway

Knoten 1 IC LIF 1

Knoten 1 IC LIF 2

Standort B Informationen zum Zeitserver

Sie müssen die Zeit synchronisieren, die einen oder mehrere NTP-Zeitserver erfordert.

Knoten

Host-Name

IP-Adresse

Netzwerkmaske

Standard-Gateway

NTP-Server 1

NTP-Server 2

Standort B nbsp; AutoSupport-Informationen

Sie müssen AutoSupport für jeden Node konfigurieren. Dazu sind folgende Informationen erforderlich:

Informationstyp

Ihre Werte

Von E-Mail-Adresse

Mail-Hosts

IP-Adressen oder Namen

Transportprotokoll

HTTP, HTTPS ODER SMTP

Proxy-Server

E-Mail-Adressen oder Verteilerlisten des Empfängers

Mitteilungen in voller Länge

Präzise Nachrichten

Standort B nbsp; SP-Informationen

Sie müssen den Zugriff auf den Service-Prozessor (SP) jedes Node für die Fehlerbehebung und Wartung aktivieren. Hierfür sind die folgenden Netzwerkinformationen für jeden Node erforderlich:

Knoten

IP-Adresse

Netzwerkmaske

Standard-Gateway

Knoten 1 (Controller_B_1)

Ähnlichkeiten und Unterschiede zwischen Standard-Cluster und MetroCluster Konfigurationen

Die Konfiguration der Nodes in jedem Cluster in einer MetroCluster-Konfiguration ist ähnlich wie bei den Nodes in einem Standard-Cluster.

Die MetroCluster-Konfiguration basiert auf zwei Standard-Clustern. Physisch muss die Konfiguration symmetrisch sein, wobei jeder Node über dieselbe Hardware-Konfiguration verfügt. Außerdem müssen alle MetroCluster Komponenten verkabelt und konfiguriert werden. Die grundlegende Softwarekonfiguration für Nodes in einer MetroCluster-Konfiguration ist jedoch dieselbe wie für Nodes in einem Standard-Cluster.

Konfigurationsschritt

Standardmäßige Cluster-Konfiguration

MetroCluster-Konfiguration

Konfiguration von Management-, Cluster- und Daten-LIFs auf jedem Node

Gleiches gilt für beide Cluster-Typen

Konfigurieren Sie das Root-Aggregat.

Gleiches gilt für beide Cluster-Typen

Richten Sie das Cluster auf einem Node im Cluster ein.

Gleiches gilt für beide Cluster-Typen

Fügen Sie den anderen Node zum Cluster hinzu.

Gleiches gilt für beide Cluster-Typen

Erstellen Sie ein gespiegeltes Root-Aggregat.

Optional

Erforderlich

Peer-to-Peer-Cluster

Optional

Erforderlich

Aktivieren der MetroCluster-Konfiguration

Wiederherstellung der Systemstandards und Konfiguration des HBA-Typs auf einem Controller-Modul

Um eine erfolgreiche MetroCluster-Installation zu gewährleisten, setzen Sie die Standardeinstellungen auf den Controller-Modulen zurück und stellen sie wieder her.

Wichtig

Dies ist nur für Stretch-Konfigurationen mit FC-to-SAS-Bridges erforderlich.

Schritte

  1. Geben Sie an der LOADER-Eingabeaufforderung die Umgebungsvariablen auf ihre Standardeinstellung zurück:

    set-defaults

  2. Starten Sie den Knoten im Wartungsmodus, und konfigurieren Sie dann die Einstellungen für alle HBAs im System:

    1. Booten in den Wartungsmodus:

      boot_ontap maint

    2. Überprüfen Sie die aktuellen Einstellungen der Ports:

      ucadmin show

    3. Aktualisieren Sie die Porteinstellungen nach Bedarf.

    Wenn Sie über diese Art von HBA und den gewünschten Modus verfügen…​

    Befehl

    CNA FC

    ucadmin modify -m fc -t initiator adapter_name

    CNA-Ethernet

    ucadmin modify -mode cna adapter_name

    FC-Ziel

    fcadmin config -t target adapter_name

    FC-Initiator

    fcadmin config -t initiator adapter_name

  3. Beenden des Wartungsmodus:

    halt

    Warten Sie, bis der Node an der LOADER-Eingabeaufforderung angehalten wird, nachdem Sie den Befehl ausgeführt haben.

  4. Starten Sie den Node wieder in den Wartungsmodus, damit die Konfigurationsänderungen wirksam werden:

    boot_ontap maint

  5. Überprüfen Sie die vorgenommenen Änderungen:

    Wenn Sie über diese Art von HBA verfügen…​

    Befehl

    CNA

    ucadmin show

    FC

    fcadmin show

  6. Beenden des Wartungsmodus:

    halt

    Warten Sie, bis der Node an der LOADER-Eingabeaufforderung angehalten wird, nachdem Sie den Befehl ausgeführt haben.

  7. Starten Sie den Knoten im Startmenü:

    boot_ontap menu

    Warten Sie, bis das Boot-Menü angezeigt wird, nachdem Sie den Befehl ausgeführt haben.

  8. Löschen Sie die Knotenkonfiguration, indem Sie in der Eingabeaufforderung des Startmenüs „wipeconfig“ eingeben und dann die Eingabetaste drücken.

    Auf dem folgenden Bildschirm wird die Eingabeaufforderung des Startmenüs angezeigt:

    Please choose one of the following:

     (1) Normal Boot.
     (2) Boot without /etc/rc.
     (3) Change password.
     (4) Clean configuration and initialize all disks.
     (5) Maintenance mode boot.
     (6) Update flash from backup config.
     (7) Install new software first.
     (8) Reboot node.
     (9) Configure Advanced Drive Partitioning.
     Selection (1-9)?  wipeconfig
 This option deletes critical system configuration, including cluster membership.
 Warning: do not run this option on a HA node that has been taken over.
 Are you sure you want to continue?: yes
 Rebooting to finish wipeconfig request.

Konfigurieren von FC-VI-Ports auf einer X1132A-R6 Quad-Port-Karte auf FAS8020 Systemen

Wenn Sie die Quad-Port-Karte X1132A-R6 auf einem FAS8020 System verwenden, können Sie in den Wartungsmodus wechseln, um die 1a- und 1b-Ports für die FC-VI- und Initiatorverwendung zu konfigurieren. Dies ist für MetroCluster Systeme, die vom Werk empfangen werden, in denen die Ports für Ihre Konfiguration entsprechend eingestellt sind, nicht erforderlich.

Über diese Aufgabe

Diese Aufgabe muss im Wartungsmodus ausgeführt werden.

Hinweis Die Konvertierung eines FC-Ports in einen FC-VI-Port mit dem Befehl ucadmin wird nur auf den Systemen FAS8020 und AFF 8020 unterstützt. Das Konvertieren von FC-Ports in FCVI-Ports wird auf keiner anderen Plattform unterstützt.
Schritte

  1. Deaktivieren Sie die Ports:

    storage disable adapter 1a

    storage disable adapter 1b

    *> storage disable adapter 1a
Jun 03 02:17:57 [controller_B_1:fci.adapter.offlining:info]: Offlining Fibre Channel adapter 1a.
Host adapter 1a disable succeeded
Jun 03 02:17:57 [controller_B_1:fci.adapter.offline:info]: Fibre Channel adapter 1a is now offline.
*> storage disable adapter 1b
Jun 03 02:18:43 [controller_B_1:fci.adapter.offlining:info]: Offlining Fibre Channel adapter 1b.
Host adapter 1b disable succeeded
Jun 03 02:18:43 [controller_B_1:fci.adapter.offline:info]: Fibre Channel adapter 1b is now offline.
*>

  2. Vergewissern Sie sich, dass die Ports deaktiviert sind:

    ucadmin show

    *> ucadmin show
         Current  Current    Pending  Pending    Admin
Adapter  Mode     Type       Mode     Type       Status
-------  -------  ---------  -------  ---------  -------
  ...
  1a     fc       initiator  -        -          offline
  1b     fc       initiator  -        -          offline
  1c     fc       initiator  -        -          online
  1d     fc       initiator  -        -          online

  3. Setzen Sie die A- und b-Ports auf den FC-VI-Modus:

    ucadmin modify -adapter 1a -type fcvi

    Der Befehl setzt den Modus auf beiden Ports im Port-Paar 1a und 1b (auch wenn im Befehl nur 1a angegeben ist).

    *> ucadmin modify -t fcvi 1a
Jun 03 02:19:13 [controller_B_1:ucm.type.changed:info]: FC-4 type has changed to fcvi on adapter 1a. Reboot the controller for the changes to take effect.
Jun 03 02:19:13 [controller_B_1:ucm.type.changed:info]: FC-4 type has changed to fcvi on adapter 1b. Reboot the controller for the changes to take effect.

  4. Bestätigen Sie, dass die Änderung aussteht:

    ucadmin show

    *> ucadmin show
         Current  Current    Pending  Pending    Admin
Adapter  Mode     Type       Mode     Type       Status
-------  -------  ---------  -------  ---------  -------
  ...
  1a     fc       initiator  -        fcvi       offline
  1b     fc       initiator  -        fcvi       offline
  1c     fc       initiator  -        -          online
  1d     fc       initiator  -        -          online

  5. Fahren Sie den Controller herunter, und starten Sie dann im Wartungsmodus neu.

  6. Bestätigen Sie die Konfigurationsänderung:

    ucadmin show local

    Node           Adapter  Mode     Type       Mode     Type       Status
------------   -------  -------  ---------  -------  ---------  -----------
...
controller_B_1
               1a       fc       fcvi       -        -          online
controller_B_1
               1b       fc       fcvi       -        -          online
controller_B_1
               1c       fc       initiator  -        -          online
controller_B_1
               1d       fc       initiator  -        -          online
6 entries were displayed.

Überprüfen der Festplattenzuweisung im Wartungsmodus in einer Konfiguration mit zwei Nodes

Vor dem vollständigen Booten des Systems zu ONTAP können Sie optional das System im Wartungsmodus booten und die Festplattenzuordnung auf den Nodes überprüfen. Die Festplatten sollten eine vollständig symmetrische Konfiguration erstellen, bei der beide Standorte ihre eigenen Platten-Shelves besitzen und Daten bereitstellen, wobei jedem Knoten und jedem Pool die gleiche Anzahl von gespiegelten Festplatten zugewiesen ist.

Bevor Sie beginnen

Das System muss sich im Wartungsmodus befinden.

Über diese Aufgabe

Neue MetroCluster Systeme haben vor der Auslieferung Festplattenzuordnungen abgeschlossen.

In der folgenden Tabelle sind Beispiele für Pool-Zuweisungen für eine MetroCluster-Konfiguration aufgeführt. Festplatten werden Pools nach Shelf-Basis zugewiesen.

Festplatten-Shelf (Beispielname)…​

An Standort…​

Gehört zu…​

Und ist diesem Node zugewiesen…​

Festplatten-Shelf 1 (Shelf_A_1_1)

Standort A

Knoten A 1

Pool 0

Festplatten-Shelf 2 (Shelf_A_1_3)

Festplatten-Shelf 3 (Shelf_B_1_1)

Knoten B 1

Pool 1

Festplatten-Shelf 4 (Shelf_B_1_3)

Festplatten-Shelf 9 (Shelf_B_1_2)

Standort B

Knoten B 1

Pool 0

Festplatten-Shelf 10 (Shelf_B_1_4)

Platten-Shelf 11 (Shelf_A_1_2)

Knoten A 1

Wenn Ihre Konfiguration DS460C Festplatten-Shelfs umfasst, sollten Sie die Festplatten anhand der folgenden Richtlinien für jedes Laufwerk mit 12 Festplatten manuell zuweisen:

Diese Festplatten in der Schublade zuweisen…​

Zu diesem Knoten und Pool…​

1 - 6

Pool des lokalen Node 0

7 - 12

Pool 1 DES DR-Partners

Dieses Muster der Festplattenzuordnung minimiert die Auswirkungen auf ein Aggregat, wenn ein Einschub offline geht.

Schritte

  1. Wenn Ihr System vom Werk empfangen wurde, bestätigen Sie die Regalzuordnungen:

    disk show –v

  2. Bei Bedarf können Sie den entsprechenden Pool explizit Festplatten in den angeschlossenen Platten-Shelfs zuweisen

    disk assign

    Festplatten-Shelfs an demselben Standort wie der Node werden Pool 0 zugewiesen, und Festplatten-Shelfs, die sich am Standort des Partners befinden, werden Pool 1 zugewiesen. Sie sollten jedem Pool die gleiche Anzahl von Shelfs zuweisen.

    1. Wenn Sie dies noch nicht getan haben, starten Sie jedes System in den Wartungsmodus.

    2. Weisen Sie auf dem Knoten vor Ort A systematisch die lokalen Platten-Shelfs dem Pool 0 und den Remote-Festplatten-Shelfs zu, um 1: + zu bündeln disk assign -shelf disk_shelf_name -p pool

      Wenn der Storage Controller Node_A_1 vier Shelfs aufweist, geben Sie die folgenden Befehle ein:

      *> disk assign -shelf shelf_A_1_1 -p 0
*> disk assign -shelf shelf_A_1_3 -p 0

*> disk assign -shelf shelf_A_1_2 -p 1
*> disk assign -shelf shelf_A_1_4 -p 1

    3. Weisen Sie auf dem Knoten am Remote-Standort (Standort B) systematisch seine lokalen Festplatten-Shelfs dem Pool 0 und seinen Remote-Festplatten-Shelfs zu, um Pool 1: + zu bilden disk assign -shelf disk_shelf_name -p pool

      Wenn der Storage Controller Node_B_1 vier Shelfs hat, geben Sie die folgenden Befehle ein:

    *> disk assign -shelf shelf_B_1_2   -p 0
*> disk assign -shelf shelf_B_1_4  -p 0

*> disk assign -shelf shelf_B_1_1 -p 1
 *> disk assign -shelf shelf_B_1_3 -p 1

    1. Zeigt die Festplatten-Shelf-IDs und Einschübe für jede Festplatte an:
      disk show –v

Überprüfen des HA-Status von Komponenten

In einer Stretch MetroCluster Konfiguration, die werkseitig nicht vorkonfiguriert ist, müssen Sie überprüfen, ob der HA-Zustand der Controller- und Gehäusekomponente auf „mcc-2n“ eingestellt ist, damit sie ordnungsgemäß hochfahren. Bei Systemen, die vom Werk empfangen werden, ist dieser Wert vorkonfiguriert, und Sie müssen ihn nicht überprüfen.

Bevor Sie beginnen

Das System muss sich im Wartungsmodus befinden.

Schritte

  1. Zeigen Sie im Wartungsmodus den HA-Status des Controller-Moduls und des Chassis an:

    ha-config show

    Das Controller-Modul und das Gehäuse sollten den Wert „mcc-2n“ aufweisen.

  2. Wenn der angezeigte Systemzustand des Controllers nicht „mcc-2n“ lautet, stellen Sie den HA-Status für den Controller ein:

    ha-config modify controller mcc-2n

  3. Wenn der angezeigte Systemzustand des Gehäuses nicht „mcc-2n“ lautet, stellen Sie den HA-Status für das Gehäuse ein:

    ha-config modify chassis mcc-2n

    Halten Sie den Knoten an.

    Warten Sie, bis der Node an der LOADER-Eingabeaufforderung wieder angezeigt wird.

  4. Wiederholen Sie diese Schritte auf jedem Knoten der MetroCluster-Konfiguration.

Einrichten von ONTAP in einer MetroCluster Konfiguration mit zwei Nodes

In einer MetroCluster-Konfiguration mit zwei Nodes müssen Sie auf jedem Cluster den Node booten, den Setup-Assistenten für den Cluster beenden und den verwenden cluster setup Befehl zum Konfigurieren des Node in einem Single-Node-Cluster.

Bevor Sie beginnen

Sie dürfen den Service Processor nicht konfiguriert haben.

Über diese Aufgabe

Diese Aufgabe gilt für MetroCluster-Konfigurationen mit zwei Nodes, die nativen NetApp Storage verwenden.

Neue MetroCluster Systeme sind vorkonfiguriert. Sie müssen diese Schritte nicht ausführen. Sie sollten jedoch AutoSupport konfigurieren.

Diese Aufgabe muss auf beiden Clustern in der MetroCluster Konfiguration ausgeführt werden.

Weitere allgemeine Informationen zum Einrichten von ONTAP finden Sie im "Einrichtung von ONTAP"

Schritte

  1. Schalten Sie den ersten Node ein.

    Hinweis Sie müssen diesen Schritt auf dem Node am Disaster-Recovery-Standort (DR) wiederholen.

    Der Node bootet. Dann startet der Cluster-Setup-Assistent auf der Konsole, der Sie darüber informiert, dass AutoSupport automatisch aktiviert wird.

    ::> Welcome to the cluster setup wizard.

You can enter the following commands at any time:
  "help" or "?" - if you want to have a question clarified,
  "back" - if you want to change previously answered questions, and
  "exit" or "quit" - if you want to quit the cluster setup wizard.
     Any changes you made before quitting will be saved.

You can return to cluster setup at any time by typing "cluster setup".
To accept a default or omit a question, do not enter a value.

This system will send event messages and periodic reports to NetApp Technical
Support. To disable this feature, enter
autosupport modify -support disable
within 24 hours.

Enabling AutoSupport can significantly speed problem determination and
resolution, should a problem occur on your system.
For further information on AutoSupport, see:
http://support.netapp.com/autosupport/

Type yes to confirm and continue {yes}: yes

Enter the node management interface port [e0M]:
Enter the node management interface IP address [10.101.01.01]:

Enter the node management interface netmask [101.010.101.0]:
Enter the node management interface default gateway [10.101.01.0]:



Do you want to create a new cluster or join an existing cluster? {create, join}:

  2. Erstellen eines neuen Clusters:

    create

  3. Wählen Sie, ob der Node als Single Node Cluster verwendet werden soll.

    Do you intend for this node to be used as a single node cluster? {yes, no} [yes]:

  4. Übernehmen Sie die Standardeinstellung „ja“, indem Sie die Eingabetaste drücken, oder geben Sie Ihre eigenen Werte ein, indem Sie „no“ eingeben und anschließend die Eingabetaste drücken.

  5. Befolgen Sie die Anweisungen, um den Assistenten Cluster Setup abzuschließen. Drücken Sie die Eingabetaste, um die Standardwerte zu akzeptieren, oder geben Sie Ihre eigenen Werte ein, und drücken Sie dann die Eingabetaste.

    Die Standardwerte werden automatisch basierend auf Ihrer Plattform und Netzwerkkonfiguration ermittelt.

  6. Nachdem Sie den Cluster Setup-Assistenten abgeschlossen und beendet haben, überprüfen Sie, ob der Cluster aktiv ist und der erste Knoten ordnungsgemäß ist:

    cluster show

    Das folgende Beispiel zeigt ein Cluster, in dem der erste Node (cluster1-01) sich in einem ordnungsgemäßen Zustand befindet und zur Teilnahme berechtigt ist:

    cluster1::> cluster show
Node                  Health  Eligibility
--------------------- ------- ------------
cluster1-01           true    true

    Wenn eine der Einstellungen, die Sie für die Admin-SVM oder Node-SVM eingegeben haben, geändert werden muss, können Sie über den auf den Assistenten * Cluster Setup* zugreifen cluster setup Befehl.

Konfigurieren der Cluster in einer MetroCluster-Konfiguration

Sie müssen die Cluster Peer, die Root-Aggregate spiegeln, ein gespiegeltes Datenaggregat erstellen und dann den Befehl zum Implementieren der MetroCluster Operationen ausgeben.

Peering der Cluster

Die Cluster in der MetroCluster Konfiguration müssen sich in einer Peer-Beziehung zueinander finden, damit sie kommunizieren und die für MetroCluster Disaster Recovery essentielle Datenspiegelung durchführen können.

Verwandte Informationen

"Express-Konfiguration für Cluster und SVM-Peering"

"Überlegungen bei der Verwendung von dedizierten Ports"

"Überlegungen bei der Freigabe von Datenports"

Konfigurieren von Intercluster-LIFs

Sie müssen Intercluster-LIFs an Ports erstellen, die für die Kommunikation zwischen den MetroCluster-Partner-Clustern verwendet werden. Sie können dedizierte Ports oder Ports verwenden, die auch Datenverkehr haben.

Konfigurieren von Intercluster-LIFs auf dedizierten Ports

Sie können Intercluster-LIFs auf dedizierten Ports konfigurieren. Dadurch wird typischerweise die verfügbare Bandbreite für den Replizierungsverkehr erhöht.

Schritte

  1. Liste der Ports im Cluster:

    network port show

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    Im folgenden Beispiel werden die Netzwerk-Ports in „cluster01“ angezeigt:

    cluster01::> network port show
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
cluster01-01
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000
       e0e       Default      Default          up     1500   auto/1000
       e0f       Default      Default          up     1500   auto/1000
cluster01-02
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000
       e0e       Default      Default          up     1500   auto/1000
       e0f       Default      Default          up     1500   auto/1000

  2. Bestimmen Sie, welche Ports für die Intercluster-Kommunikation verfügbar sind:

    network interface show -fields home-port,curr-port

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    Im folgenden Beispiel werden die Ports „e0e“ und „e0f“ nicht zugewiesen:

    cluster01::> network interface show -fields home-port,curr-port
vserver lif                  home-port curr-port

Cluster cluster01-01_clus1   e0a       e0a
Cluster cluster01-01_clus2   e0b       e0b
Cluster cluster01-02_clus1   e0a       e0a
Cluster cluster01-02_clus2   e0b       e0b
cluster01
        cluster_mgmt         e0c       e0c
cluster01
        cluster01-01_mgmt1   e0c       e0c
cluster01
        cluster01-02_mgmt1   e0c       e0c

  3. Erstellen Sie eine Failover-Gruppe für die dedizierten Ports:

    network interface failover-groups create -vserver system_SVM -failover-group failover_group -targets physical_or_logical_ports

    Im folgenden Beispiel werden der Failover-Gruppe „intercluster01“ die Ports „e0e“ und „e0f“ auf der System-SVM „cluster01“ zugewiesen:

    cluster01::> network interface failover-groups create -vserver cluster01 -failover-group
intercluster01 -targets
cluster01-01:e0e,cluster01-01:e0f,cluster01-02:e0e,cluster01-02:e0f

  4. Vergewissern Sie sich, dass die Failover-Gruppe erstellt wurde:

    network interface failover-groups show

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    cluster01::> network interface failover-groups show
                                  Failover
Vserver          Group            Targets
---------------- ---------------- --------------------------------------------
Cluster
                 Cluster
                                  cluster01-01:e0a, cluster01-01:e0b,
                                  cluster01-02:e0a, cluster01-02:e0b
cluster01
                 Default
                                  cluster01-01:e0c, cluster01-01:e0d,
                                  cluster01-02:e0c, cluster01-02:e0d,
                                  cluster01-01:e0e, cluster01-01:e0f
                                  cluster01-02:e0e, cluster01-02:e0f
                 intercluster01
                                  cluster01-01:e0e, cluster01-01:e0f
                                  cluster01-02:e0e, cluster01-02:e0f

  5. Erstellen Sie Intercluster-LIFs auf der System-SVM und weisen Sie sie der Failover-Gruppe zu.

    ONTAP-Version

    Befehl

    ONTAP 9.6 und höher

    network interface create -vserver system_SVM -lif LIF_name -service-policy default-intercluster -home-node node -home-port port -address port_IP -netmask netmask -failover-group failover_group

    ONTAP 9.5 und früher

    network interface create -vserver system_SVM -lif LIF_name -role intercluster -home-node node -home-port port -address port_IP -netmask netmask -failover-group failover_group

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    Im folgenden Beispiel werden Intercluster-LIFs „cluster01_ic01“ und „cluster01_ic02“ in der Failover-Gruppe „intercluster01“ erstellt:

    cluster01::> network interface create -vserver cluster01 -lif cluster01_icl01 -service-
policy default-intercluster -home-node cluster01-01 -home-port e0e -address 192.168.1.201
-netmask 255.255.255.0 -failover-group intercluster01

cluster01::> network interface create -vserver cluster01 -lif cluster01_icl02 -service-
policy default-intercluster -home-node cluster01-02 -home-port e0e -address 192.168.1.202
-netmask 255.255.255.0 -failover-group intercluster01

  6. Überprüfen Sie, ob die Intercluster-LIFs erstellt wurden:

    ONTAP-Version

    Befehl

    ONTAP 9.6 und höher

    network interface show -service-policy default-intercluster

    ONTAP 9.5 und früher

    network interface show -role intercluster

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    cluster01::> network interface show -service-policy default-intercluster
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster01
            cluster01_icl01
                       up/up      192.168.1.201/24   cluster01-01  e0e     true
            cluster01_icl02
                       up/up      192.168.1.202/24   cluster01-02  e0f     true

  7. Vergewissern Sie sich, dass die Intercluster-LIFs redundant sind:

    ONTAP-Version

    Befehl

    ONTAP 9.6 und höher

    network interface show -service-policy default-intercluster -failover

    In ONTAP 9.5 und früher

    network interface show -role intercluster -failover

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    Das folgende Beispiel zeigt, dass die Intercluster-LIFs „cluster01_ic01“ und „cluster01_ic02“ auf dem SVM-Port „e0e“ an Port „e0f“ scheitern.

    cluster01::> network interface show -service-policy default-intercluster –failover
         Logical         Home                  Failover        Failover
Vserver  Interface       Node:Port             Policy          Group
-------- --------------- --------------------- --------------- --------
cluster01
         cluster01_icl01 cluster01-01:e0e   local-only      intercluster01
                            Failover Targets:  cluster01-01:e0e,
                                               cluster01-01:e0f
         cluster01_icl02 cluster01-02:e0e   local-only      intercluster01
                            Failover Targets:  cluster01-02:e0e,
                                               cluster01-02:e0f
Verwandte Informationen

"Überlegungen bei der Verwendung von dedizierten Ports"

Konfigurieren von Intercluster-LIFs auf gemeinsam genutzten Datenports

Sie können Intercluster-LIFs an Ports konfigurieren, die gemeinsam mit dem Datennetzwerk verwendet werden. Auf diese Weise wird die Anzahl der Ports reduziert, die Sie für Intercluster-Netzwerke benötigen.

Schritte

  1. Liste der Ports im Cluster:

    network port show

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    Im folgenden Beispiel werden die Netzwerk-Ports in „cluster01“ angezeigt:

    cluster01::> network port show
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
cluster01-01
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000
cluster01-02
       e0a       Cluster      Cluster          up     1500   auto/1000
       e0b       Cluster      Cluster          up     1500   auto/1000
       e0c       Default      Default          up     1500   auto/1000
       e0d       Default      Default          up     1500   auto/1000

  2. Intercluster-LIFs auf der System-SVM erstellen:

    ONTAP-Version

    Befehl

    ONTAP 9.6 und höher

    network interface create -vserver system_SVM -lif LIF_name -service-policy default-intercluster -home-node node -home-port port -address port_IP -netmask netmask

    ONTAP 9.5 und früher

    network interface create -vserver system_SVM -lif LIF_name -role intercluster -home-node node -home-port port -address port_IP -netmask netmask

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    Im folgenden Beispiel werden Intercluster-LIFs „cluster01_ic01“ und „cluster01_ic02“ erstellt:

    cluster01::> network interface create -vserver cluster01 -lif cluster01_icl01 -service-
policy default-intercluster -home-node cluster01-01 -home-port e0c -address 192.168.1.201
-netmask 255.255.255.0

cluster01::> network interface create -vserver cluster01 -lif cluster01_icl02 -service-
policy default-intercluster -home-node cluster01-02 -home-port e0c -address 192.168.1.202
-netmask 255.255.255.0

  3. Überprüfen Sie, ob die Intercluster-LIFs erstellt wurden:

    ONTAP-Version

    Befehl

    ONTAP 9.6 und höher

    network interface show -service-policy default-intercluster

    ONTAP 9.5 und früher

    network interface show -role intercluster

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    cluster01::> network interface show -service-policy default-intercluster
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster01
            cluster01_icl01
                       up/up      192.168.1.201/24   cluster01-01  e0c     true
            cluster01_icl02
                       up/up      192.168.1.202/24   cluster01-02  e0c     true

  4. Vergewissern Sie sich, dass die Intercluster-LIFs redundant sind:

    ONTAP-Version

    Befehl

    ONTAP 9.6 und höher

    network interface show –service-policy default-intercluster -failover

    ONTAP 9.5 und früher

    network interface show -role intercluster -failover

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    Das folgende Beispiel zeigt, dass die Intercluster-LIFs „cluster01_ic01“ und „cluster01_ic02“ am Port „e0c“ über den Port „e0d“ scheitern.

    cluster01::> network interface show -service-policy default-intercluster –failover
         Logical         Home                  Failover        Failover
Vserver  Interface       Node:Port             Policy          Group
-------- --------------- --------------------- --------------- --------
cluster01
         cluster01_icl01 cluster01-01:e0c   local-only      192.168.1.201/24
                            Failover Targets: cluster01-01:e0c,
                                              cluster01-01:e0d
         cluster01_icl02 cluster01-02:e0c   local-only      192.168.1.201/24
                            Failover Targets: cluster01-02:e0c,
                                              cluster01-02:e0d
Verwandte Informationen

"Überlegungen bei der Freigabe von Datenports"

Erstellen einer Cluster-Peer-Beziehung

Sie müssen die Cluster-Peer-Beziehung zwischen den MetroCluster Clustern erstellen.

Erstellen einer Cluster-Peer-Beziehung

Sie können das verwenden cluster peer create Befehl zum Erstellen einer Peer-Beziehung zwischen einem lokalen und einem Remote-Cluster. Nachdem die Peer-Beziehung erstellt wurde, können Sie ausführen cluster peer create Im Remote-Cluster zur Authentifizierung beim lokalen Cluster.

Bevor Sie beginnen

  • Sie müssen auf jedem Node in den Clustern, die Peering durchführen, Intercluster LIFs erstellt haben.

  • Die Cluster müssen ONTAP 9.3 oder höher ausführen.

Schritte

  1. Erstellen Sie auf dem Ziel-Cluster eine Peer-Beziehung mit dem Quell-Cluster:

    cluster peer create -generate-passphrase -offer-expiration MM/DD/YYYY HH:MM:SS|1…​7days|1…​168hours -peer-addrs peer_LIF_IPs -ipspace ipspace

    Wenn Sie beides angeben -generate-passphrase Und -peer-addrs, Nur der Cluster, dessen Intercluster LIFs in angegeben sind -peer-addrs Kann das generierte Passwort verwenden.

    Sie können die ignorieren -ipspace Option, wenn kein benutzerdefinierter IPspace verwendet wird. Eine vollständige Befehlssyntax finden Sie in der man-Page.

    Im folgenden Beispiel wird eine Cluster-Peer-Beziehung auf einem nicht angegebenen Remote-Cluster erstellt:

    cluster02::> cluster peer create -generate-passphrase -offer-expiration 2days

                     Passphrase: UCa+6lRVICXeL/gq1WrK7ShR
                Expiration Time: 6/7/2017 08:16:10 EST
  Initial Allowed Vserver Peers: -
            Intercluster LIF IP: 192.140.112.101
              Peer Cluster Name: Clus_7ShR (temporary generated)

Warning: make a note of the passphrase - it cannot be displayed again.

  2. Authentifizierung des Quellclusters auf dem Quellcluster beim Ziel-Cluster:

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    Im folgenden Beispiel wird der lokale Cluster an den Remote-Cluster unter LIF-IP-Adressen 192.140.112.101 und 192.140.112.102 authentifiziert:

    cluster01::> cluster peer create -peer-addrs 192.140.112.101,192.140.112.102

Notice: Use a generated passphrase or choose a passphrase of 8 or more characters.
        To ensure the authenticity of the peering relationship, use a phrase or sequence of characters that would be hard to guess.

Enter the passphrase:
Confirm the passphrase:

Clusters cluster02 and cluster01 are peered.

    Geben Sie die Passphrase für die Peer-Beziehung ein, wenn Sie dazu aufgefordert werden.

  3. Vergewissern Sie sich, dass die Cluster-Peer-Beziehung erstellt wurde:

    cluster peer show -instance

    cluster01::> cluster peer show -instance

                               Peer Cluster Name: cluster02
                   Remote Intercluster Addresses: 192.140.112.101, 192.140.112.102
              Availability of the Remote Cluster: Available
                             Remote Cluster Name: cluster2
                             Active IP Addresses: 192.140.112.101, 192.140.112.102
                           Cluster Serial Number: 1-80-123456
                  Address Family of Relationship: ipv4
            Authentication Status Administrative: no-authentication
               Authentication Status Operational: absent
                                Last Update Time: 02/05 21:05:41
                    IPspace for the Relationship: Default

  4. Prüfen Sie die Konnektivität und den Status der Knoten in der Peer-Beziehung:

    cluster peer health show

    cluster01::> cluster peer health show
Node       cluster-Name                Node-Name
             Ping-Status               RDB-Health Cluster-Health  Avail…
---------- --------------------------- ---------  --------------- --------
cluster01-01
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
cluster01-02
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
Erstellen einer Cluster-Peer-Beziehung (ONTAP 9.2 und älter)

Sie können das verwenden cluster peer create Befehl zum Initiierung einer Anforderung für eine Peering-Beziehung zwischen einem lokalen und einem Remote-Cluster. Nachdem die Peer-Beziehung vom lokalen Cluster angefordert wurde, können Sie ausführen cluster peer create Auf dem Remote-Cluster, um die Beziehung zu akzeptieren.

Bevor Sie beginnen

  • Sie müssen auf jedem Node in den Clustern, die Peering durchführen, Intercluster LIFs erstellt haben.

  • Die Clusteradministratoren müssen die Passphrase vereinbart haben, die jedes Cluster verwendet, um sich beim anderen zu authentifizieren.

Schritte

  1. Erstellen Sie auf dem Ziel-Cluster für die Datensicherung eine Peer-Beziehung mit dem Quell-Cluster:

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    Sie können die ignorieren -ipspace Option, wenn kein benutzerdefinierter IPspace verwendet wird. Eine vollständige Befehlssyntax finden Sie in der man-Page.

    Im folgenden Beispiel wird eine Cluster-Peer-Beziehung zum Remote-Cluster bei Intercluster LIF IP-Adressen 192.168.2.201 und 192.168.2.202 erstellt:

    cluster02::> cluster peer create -peer-addrs 192.168.2.201,192.168.2.202
Enter the passphrase:
Please enter the passphrase again:

    Geben Sie die Passphrase für die Peer-Beziehung ein, wenn Sie dazu aufgefordert werden.

  2. Authentifizieren Sie das Quell-Cluster im Datensicherungs-Quellcluster beim Ziel-Cluster:

    cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    Im folgenden Beispiel wird der lokale Cluster an den Remote-Cluster unter LIF-IP-Adressen 192.140.112.203 und 192.140.112.204 authentifiziert:

    cluster01::> cluster peer create -peer-addrs 192.168.2.203,192.168.2.204
Please confirm the passphrase:
Please confirm the passphrase again:

    Geben Sie die Passphrase für die Peer-Beziehung ein, wenn Sie dazu aufgefordert werden.

  3. Vergewissern Sie sich, dass die Cluster-Peer-Beziehung erstellt wurde:

    cluster peer show –instance

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    cluster01::> cluster peer show –instance
Peer Cluster Name: cluster01
Remote Intercluster Addresses: 192.168.2.201,192.168.2.202
Availability: Available
Remote Cluster Name: cluster02
Active IP Addresses: 192.168.2.201,192.168.2.202
Cluster Serial Number: 1-80-000013

  4. Prüfen Sie die Konnektivität und den Status der Knoten in der Peer-Beziehung:

    cluster peer health show

    Eine vollständige Befehlssyntax finden Sie in der man-Page.

    cluster01::> cluster peer health show
Node       cluster-Name                Node-Name
             Ping-Status               RDB-Health Cluster-Health  Avail…
---------- --------------------------- ---------  --------------- --------
cluster01-01
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
cluster01-02
           cluster02                   cluster02-01
             Data: interface_reachable
             ICMP: interface_reachable true       true            true
                                       cluster02-02
             Data: interface_reachable
             ICMP: interface_reachable true       true            true

Spiegelung der Root-Aggregate

Um Datensicherung zu ermöglichen, müssen Sie die Root-Aggregate spiegeln.

Über diese Aufgabe

Standardmäßig wird das Root-Aggregat als RAID-DP Typ Aggregat erstellt. Sie können das Root-Aggregat von RAID-DP zu einem Aggregat des RAID4-Typs ändern. Mit dem folgenden Befehl wird das Root-Aggregat für das RAID4-Typ-Aggregat modifiziert:

storage aggregate modify –aggregate aggr_name -raidtype raid4

Hinweis Auf Systemen anderer Hersteller kann der RAID-Typ des Aggregats von dem Standard RAID-DP zu RAID4 vor oder nach der Spiegelung des Aggregats geändert werden.
Schritte

  1. Root-Aggregat spiegeln:

    storage aggregate mirror aggr_name

    Mit dem folgenden Befehl wird das Root-Aggregat für „Controller_A_1“ gespiegelt:

    controller_A_1::> storage aggregate mirror aggr0_controller_A_1

    Dies spiegelt das Aggregat, also besteht es aus einem lokalen Plex und einem Remote Plex am Remote MetroCluster Standort.

  2. Wiederholen Sie den vorherigen Schritt für jeden Node in der MetroCluster-Konfiguration.

Verwandte Informationen

"Logisches Storage-Management"

"ONTAP-Konzepte"

Erstellung eines gespiegelten Datenaggregats auf jedem Node

Sie müssen auf jedem Knoten in der DR-Gruppe ein gespiegeltes Datenaggregat erstellen.

Bevor Sie beginnen

  • Sie sollten wissen, welche Laufwerke oder Array LUNs im neuen Aggregat verwendet werden.

  • Wenn Sie mehrere Laufwerktypen in Ihrem System haben (heterogener Speicher), sollten Sie verstehen, wie Sie sicherstellen können, dass der richtige Laufwerkstyp ausgewählt ist.

Über diese Aufgabe

  • Laufwerke und Array-LUNs sind Eigentum eines bestimmten Nodes. Wenn Sie ein Aggregat erstellen, müssen alle Laufwerke in diesem Aggregat Eigentum desselben Node sein, der zum Home Node für das Aggregat wird.

  • Aggregatnamen sollten dem Benennungsschema entsprechen, das Sie beim Planen Ihrer MetroCluster-Konfiguration ermittelt haben.

    "Festplatten- und Aggregatmanagement"

Schritte

  1. Liste der verfügbaren Ersatzteile anzeigen:

    storage disk show -spare -owner node_name

  2. Erstellen Sie das Aggregat:

    storage aggregate create -mirror true

    Wenn Sie auf der Cluster-Managementoberfläche beim Cluster angemeldet sind, können Sie auf jedem Node im Cluster ein Aggregat erstellen. Um sicherzustellen, dass das Aggregat auf einem bestimmten Node erstellt wird, verwenden Sie die -node Parameter oder geben Sie Laufwerke an, die diesem Node gehören.

    Sie können die folgenden Optionen angeben:

    • Der Home Node des Aggregats (d. h. der Knoten, der das Aggregat im normalen Betrieb besitzt)

    • Liste bestimmter Laufwerke oder Array LUNs, die dem Aggregat hinzugefügt werden sollen

    • Anzahl der zu einführenden Laufwerke

      Hinweis In der unterstützten Minimalkonfiguration, bei der eine begrenzte Anzahl an Laufwerken verfügbar ist, müssen Sie die Force-Small-Aggregate Option verwenden, um das Erstellen eines drei Festplatten-RAID-DP Aggregats zu ermöglichen.

    • Prüfsummenstil, den Sie für das Aggregat verwenden möchten

    • Typ der zu verwendenden Laufwerke

    • Die Größe der zu verwendenden Laufwerke

    • Fahrgeschwindigkeit zu verwenden

    • RAID-Typ für RAID-Gruppen auf dem Aggregat

    • Maximale Anzahl an Laufwerken oder Array-LUNs, die in einer RAID-Gruppe enthalten sein können

    • Weitere Informationen zu diesen Optionen finden Sie im, ob Laufwerke mit unterschiedlichen U/min zulässig sind storage aggregate create Man-Page.

      Mit dem folgenden Befehl wird ein gespiegeltes Aggregat mit 10 Festplatten erstellt:

    cluster_A::> storage aggregate create aggr1_node_A_1 -diskcount 10 -node node_A_1 -mirror true
[Job 15] Job is queued: Create aggr1_node_A_1.
[Job 15] The job is starting.
[Job 15] Job succeeded: DONE

  3. Überprüfen Sie die RAID-Gruppe und die Laufwerke Ihres neuen Aggregats:

    storage aggregate show-status -aggregate aggregate-name

Erstellen von nicht gespiegelten Datenaggregaten

Optional können Sie nicht gespiegelte Datenaggregate für Daten erstellen, für die keine redundante Spiegelung von MetroCluster-Konfigurationen erforderlich ist.

Bevor Sie beginnen

  • Sie sollten wissen, welche Laufwerke oder Array LUNs im neuen Aggregat verwendet werden.

  • Wenn Sie mehrere Laufwerktypen in Ihrem System haben (heterogener Speicher), sollten Sie verstehen, wie Sie überprüfen können, ob der richtige Laufwerkstyp ausgewählt ist.

Beispiel 1. Über diese Aufgabe

ACHTUNG: Bei MetroCluster FC-Konfigurationen sind die nicht gespiegelten Aggregate erst nach einer Umschaltung online, wenn auf die Remote-Festplatten im Aggregat zugegriffen werden kann. Wenn die ISLs ausfallen, kann der lokale Knoten möglicherweise nicht auf die Daten auf den nicht gespiegelten Remote-Festplatten zugreifen. Der Ausfall eines Aggregats kann zu einem Neustart des lokalen Node führen.

Hinweis Die nicht gespiegelten Aggregate müssen sich lokal an dem Node halten, auf dem sie sich enthalten.

  • Laufwerke und Array-LUNs sind Eigentum eines bestimmten Nodes. Wenn Sie ein Aggregat erstellen, müssen alle Laufwerke in diesem Aggregat Eigentum desselben Node sein, der zum Home Node für das Aggregat wird.

  • Aggregatnamen sollten dem Benennungsschema entsprechen, das Sie beim Planen Ihrer MetroCluster-Konfiguration ermittelt haben.

  • Der "Festplatten- und Aggregatmanagement" Enthält weitere Informationen zur Spiegelung von Aggregaten.

Schritte

  1. Liste der verfügbaren Ersatzteile anzeigen:

    storage disk show -spare -owner node_name

  2. Erstellen Sie das Aggregat:

    storage aggregate create

    Wenn Sie auf der Cluster-Managementoberfläche beim Cluster angemeldet sind, können Sie auf jedem Node im Cluster ein Aggregat erstellen. Um zu überprüfen, ob das Aggregat auf einem bestimmten Node erstellt wird, sollten Sie das verwenden -node Parameter oder geben Sie Laufwerke an, die diesem Node gehören.

    Sie können die folgenden Optionen angeben:

    • Der Home Node des Aggregats (d. h. der Knoten, der das Aggregat im normalen Betrieb besitzt)

    • Liste bestimmter Laufwerke oder Array LUNs, die dem Aggregat hinzugefügt werden sollen

    • Anzahl der zu einführenden Laufwerke

    • Prüfsummenstil, den Sie für das Aggregat verwenden möchten

    • Typ der zu verwendenden Laufwerke

    • Die Größe der zu verwendenden Laufwerke

    • Fahrgeschwindigkeit zu verwenden

    • RAID-Typ für RAID-Gruppen auf dem Aggregat

    • Maximale Anzahl an Laufwerken oder Array-LUNs, die in einer RAID-Gruppe enthalten sein können

    • Weitere Informationen zu diesen Optionen finden Sie im, ob Laufwerke mit unterschiedlichen U/min zulässig sind storage aggregate create Man-Page.

      Mit dem folgenden Befehl wird ein nicht gespiegeltes Aggregat mit 10 Festplatten erstellt:

    controller_A_1::> storage aggregate create aggr1_controller_A_1 -diskcount 10 -node controller_A_1
[Job 15] Job is queued: Create aggr1_controller_A_1.
[Job 15] The job is starting.
[Job 15] Job succeeded: DONE

  3. Überprüfen Sie die RAID-Gruppe und die Laufwerke Ihres neuen Aggregats:

    storage aggregate show-status -aggregate aggregate-name

Implementieren der MetroCluster-Konfiguration

Sie müssen den ausführen metrocluster configure Befehl zum Starten der Datensicherung in einer MetroCluster-Konfiguration.

Bevor Sie beginnen

  • Es sollten mindestens zwei gespiegelte Datenaggregate ohne Root-Wurzeln auf jedem Cluster vorhanden sein.

    Zusätzliche Datenaggregate können entweder gespiegelt oder nicht gespiegelt werden.

    Überprüfen Sie die Aggregattypen:

    storage aggregate show

    Hinweis Wenn Sie ein einzelnes gespiegeltes Datenaggregat verwenden möchten, finden Sie weitere Informationen unter "Konfigurieren Sie die MCC Software in ONTAP" Weitere Anweisungen.

  • Der HA-Konfigurationsstatus der Controller und des Gehäuses muss „mcc-2n“ sein.

Über diese Aufgabe

Sie können die ausgeben metrocluster configure Um die MetroCluster-Konfiguration zu aktivieren, aktivieren Sie einmal den Befehl auf einem der Nodes. Sie müssen den Befehl nicht für jede der Standorte oder Nodes ausführen. Es ist nicht von Bedeutung, auf welchem Node oder Standort Sie den Befehl ausgeben möchten.

Schritte

  1. Konfigurieren Sie die MetroCluster im folgenden Format:

    Wenn Ihre MetroCluster Konfiguration…​

    Dann tun Sie das…​

    Mehrere Datenaggregate

    Konfigurieren Sie an der Eingabeaufforderung eines beliebigen Nodes MetroCluster:

    metrocluster configure node-name

    Ein einzelnes gespiegeltes Datenaggregat

    1. Ändern Sie von der Eingabeaufforderung eines beliebigen Node auf die erweiterte Berechtigungsebene:

      set -privilege advanced

      Sie müssen mit „y“ antworten, wenn Sie aufgefordert werden, in den erweiterten Modus zu wechseln, und die Eingabeaufforderung für den erweiterten Modus (*) angezeigt wird.

    2. Konfigurieren Sie die MetroCluster mit dem -allow-with-one-aggregate true Parameter:

      metrocluster configure -allow-with-one-aggregate true node-name

    3. Zurück zur Administrator-Berechtigungsebene:
      set -privilege admin
    Hinweis Die Best Practice besteht in der Nutzung mehrerer Datenaggregate. Wenn die erste DR-Gruppe nur ein Aggregat hat und Sie eine DR-Gruppe mit einem Aggregat hinzufügen möchten, müssen Sie das Metadaten-Volume aus dem einzelnen Datenaggregat verschieben. Weitere Informationen zu diesem Verfahren finden Sie unter "Verschieben eines Metadaten-Volumes in MetroCluster Konfigurationen".

    Mit dem folgenden Befehl wird die MetroCluster-Konfiguration auf allen Nodes in der DR-Gruppe aktiviert, die „Controller_A_1“ enthält:

    cluster_A::*> metrocluster configure -node-name controller_A_1

[Job 121] Job succeeded: Configure is successful.

  2. Überprüfen Sie den Netzwerkstatus auf Standort A:

    network port show

    Im folgenden Beispiel wird die Verwendung von Netzwerkports angezeigt:

    cluster_A::> network port show
                                                          Speed (Mbps)
Node   Port      IPspace   Broadcast Domain Link   MTU    Admin/Oper
------ --------- --------- ---------------- ----- ------- ------------
controller_A_1
       e0a       Cluster   Cluster          up     9000  auto/1000
       e0b       Cluster   Cluster          up     9000  auto/1000
       e0c       Default   Default          up     1500  auto/1000
       e0d       Default   Default          up     1500  auto/1000
       e0e       Default   Default          up     1500  auto/1000
       e0f       Default   Default          up     1500  auto/1000
       e0g       Default   Default          up     1500  auto/1000

7 entries were displayed.

  3. Überprüfen Sie die MetroCluster Konfiguration von beiden Standorten in der MetroCluster Konfiguration.

    1. Überprüfen Sie die Konfiguration von Standort A:
      metrocluster show

      cluster_A::> metrocluster show

Cluster                   Entry Name          State
------------------------- ------------------- -----------
 Local: cluster_A         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster
Remote: cluster_B         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster

    2. Überprüfen Sie die Konfiguration von Standort B:
      metrocluster show

      cluster_B::> metrocluster show
Cluster                   Entry Name          State
------------------------- ------------------- -----------
 Local: cluster_B         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster
Remote: cluster_A         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain auso-on-cluster-disaster

Konfiguration von FC-to-SAS-Bridges für das Monitoring des Systemzustands

Wenn Ihre Konfiguration über FC-to-SAS-Bridges verfügt, müssen Sie bei Systemen mit ONTAP-Versionen vor 9.8 einige besondere Konfigurationsschritte durchführen, um die FC-to-SAS-Bridges in der MetroCluster-Konfiguration zu überwachen.

  • SNMP-Überwachungstools anderer Anbieter werden für FibreBridge-Brücken nicht unterstützt.

  • Ab ONTAP 9.8 werden FC-to-SAS-Bridges standardmäßig über in-Band-Verbindungen überwacht, keine zusätzliche Konfiguration erforderlich.

Hinweis Ab ONTAP 9.8 beginnt der storage bridge Befehl wird durch ersetzt system bridge. Die folgenden Schritte zeigen das storage bridge Befehl, aber wenn Sie ONTAP 9.8 oder höher ausführen, der system bridge Befehl ist bevorzugt.
Schritte

  1. Fügen Sie von der ONTAP Cluster-Eingabeaufforderung die Bridge zur Statusüberwachung hinzu:

    1. Fügen Sie die Bridge mit dem Befehl für Ihre ONTAP-Version hinzu:

      ONTAP-Version

      Befehl

      ONTAP 9.5 und höher

      storage bridge add -address 0.0.0.0 -managed-by in-band -name bridge-name

      ONTAP 9.4 und früher

      storage bridge add -address bridge-ip-address -name bridge-name

    2. Überprüfen Sie, ob die Bridge hinzugefügt und richtig konfiguriert wurde:

      storage bridge show

      Es kann wegen des Abrufintervalls bis zu 15 Minuten dauern, alle Daten wiederzugeben. Die ONTAP-Systemzustandsüberwachung kann die Brücke kontaktieren und überwachen, wenn der Wert in der Spalte „Status“ „ok“ lautet und weitere Informationen, wie der weltweite Name (WWN), angezeigt werden.

      Das folgende Beispiel zeigt, dass die FC-to-SAS-Bridges konfiguriert sind:

    controller_A_1::> storage bridge show

Bridge              Symbolic Name Is Monitored  Monitor Status  Vendor Model                Bridge WWN
------------------  ------------- ------------  --------------  ------ -----------------    ----------
ATTO_10.10.20.10  atto01        true          ok              Atto   FibreBridge 7500N   	20000010867038c0
ATTO_10.10.20.11  atto02        true          ok              Atto   FibreBridge 7500N   	20000010867033c0
ATTO_10.10.20.12  atto03        true          ok              Atto   FibreBridge 7500N   	20000010867030c0
ATTO_10.10.20.13  atto04        true          ok              Atto   FibreBridge 7500N   	2000001086703b80

4 entries were displayed

 controller_A_1::>

Überprüfen der MetroCluster-Konfiguration

Sie können überprüfen, ob die Komponenten und Beziehungen in der MetroCluster Konfiguration ordnungsgemäß funktionieren. Nach der Erstkonfiguration und nach sämtlichen Änderungen an der MetroCluster-Konfiguration sollten Sie einen Check durchführen. Sie sollten auch vor einer ausgehandelten (geplanten) Umschaltung oder einem Switchback prüfen.

Wenn der metrocluster check run Befehl wird zweimal innerhalb kürzester Zeit auf einem oder beiden Clustern ausgegeben. Ein Konflikt kann auftreten, und der Befehl erfasst möglicherweise nicht alle Daten. Danach metrocluster check show Befehle zeigen nicht die erwartete Ausgabe an.

  1. Überprüfen Sie die Konfiguration:

    metrocluster check run

    Der Befehl wird als Hintergrundjob ausgeführt und wird möglicherweise nicht sofort ausgeführt.

    cluster_A::> metrocluster check run
The operation has been started and is running in the background. Wait for
it to complete and run "metrocluster check show" to view the results. To
check the status of the running metrocluster check operation, use the command,
"metrocluster operation history show -job-id 2245"
    cluster_A::> metrocluster check show

Component           Result
------------------- ---------
nodes               ok
lifs                ok
config-replication  ok
aggregates          ok
clusters            ok
connections         ok
volumes             ok
7 entries were displayed.

  2. Detailliertere Ergebnisse anzeigen:

    metrocluster check run

    metrocluster check aggregate show

    metrocluster check cluster show

    metrocluster check config-replication show

    metrocluster check lif show

    metrocluster check node show

    Der metrocluster check show Befehle zeigen die Ergebnisse der letzten metrocluster check run Befehl. Sie sollten immer den ausführen metrocluster check run Befehl vor Verwendung des metrocluster check show Befehle, sodass die angezeigten Informationen aktuell sind.

    Das folgende Beispiel zeigt die metrocluster check aggregate show Befehlsausgabe für eine gesunde MetroCluster Konfiguration mit vier Nodes:

    cluster_A::> metrocluster check aggregate show

Last Checked On: 8/5/2014 00:42:58

Node                  Aggregate                  Check                      Result
---------------       --------------------       ---------------------      ---------
controller_A_1        controller_A_1_aggr0
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_1_aggr1
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_1_aggr2
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok


controller_A_2        controller_A_2_aggr0
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_2_aggr1
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok
                      controller_A_2_aggr2
                                                 mirroring-status           ok
                                                 disk-pool-allocation       ok
                                                 ownership-state            ok

18 entries were displayed.

    Das folgende Beispiel zeigt die metrocluster check cluster show Befehlsausgabe für eine gesunde MetroCluster Konfiguration mit vier Nodes. Sie zeigt an, dass die Cluster bei Bedarf bereit sind, eine ausgehandelte Umschaltung durchzuführen.

    Last Checked On: 9/13/2017 20:47:04

Cluster               Check                           Result
--------------------- ------------------------------- ---------
mccint-fas9000-0102
                      negotiated-switchover-ready     not-applicable
                      switchback-ready                not-applicable
                      job-schedules                   ok
                      licenses                        ok
                      periodic-check-enabled          ok
mccint-fas9000-0304
                      negotiated-switchover-ready     not-applicable
                      switchback-ready                not-applicable
                      job-schedules                   ok
                      licenses                        ok
                      periodic-check-enabled          ok
10 entries were displayed.
Verwandte Informationen

"Festplatten- und Aggregatmanagement"

"Netzwerk- und LIF-Management"

Überprüfen auf MetroCluster-Konfigurationsfehler mit Config Advisor

Sie können die NetApp Support-Website besuchen und das Config Advisor-Tool herunterladen, um häufige Konfigurationsfehler zu überprüfen.

Config Advisor ist ein Tool zur Konfigurationsvalidierung und Statusüberprüfung. Sie können die Lösung sowohl an sicheren Standorten als auch an nicht sicheren Standorten zur Datenerfassung und Systemanalyse einsetzen.

Hinweis Der Support für Config Advisor ist begrenzt und steht nur online zur Verfügung.

  1. Rufen Sie die Config Advisor Download-Seite auf und laden Sie das Tool herunter.

    "NetApp Downloads: Config Advisor"

  2. Führen Sie Config Advisor aus, überprüfen Sie die Ausgabe des Tools und folgen Sie den Empfehlungen in der Ausgabe, um erkannte Probleme zu beheben.

Überprüfung von Umschaltung, Reparatur und Wechsel zurück

Sie sollten die Umschalttavorgänge, die Reparatur und den Wechsel der MetroCluster Konfiguration überprüfen.

  1. Verwenden Sie die im genannten Verfahren für die ausgehandelte Umschaltung, die Reparatur und den Wechsel zurück "Nach einem Ausfall wiederherstellen".

Sichern von Backup-Dateien der Konfiguration

Sie können einen zusätzlichen Schutz für die Backup-Dateien der Clusterkonfiguration bieten, indem Sie eine Remote-URL (entweder HTTP oder FTP) angeben, bei der die Backup-Dateien der Konfiguration zusätzlich zu den Standardstandorten im lokalen Cluster hochgeladen werden.

  1. Legen Sie die URL des Remote-Ziels für die Backup-Dateien der Konfiguration fest:

    system configuration backup settings modify URL-of-destination

    Der "Cluster-Management mit der CLI" Enthält zusätzliche Informationen unter dem Abschnitt Verwalten von Konfigurations-Backups.