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.

Neuzuordnen der Eigentumsrechte an Pool-1-Festplatten am Disaster-Standort (MetroCluster IP-Konfigurationen)

Beitragende

Wenn am Disaster-Standort ein oder beide Controller-Module oder NVRAM-Karten ausgetauscht wurden, hat sich die System-ID geändert, und Sie müssen Festplatten, die zu den Root-Aggregaten gehören, den Ersatz-Controller-Modulen neu zuweisen.

Über diese Aufgabe

Da sich die Nodes im Switchover-Modus befinden, werden bei dieser Aufgabe nur die Festplatten mit den Root-Aggregaten von Pool1 des Disaster-Standorts neu zugewiesen. Sie sind derzeit die einzigen Festplatten, die noch zur alten System-ID gehören.

Diese Aufgabe wird auf den Ersatz-Nodes am Disaster-Standort ausgeführt.

Diese Aufgabe wird im Wartungsmodus ausgeführt.

Die Beispiele machen folgende Annahmen:

  • Standort A ist der Notfallstandort.

  • Node_A_1 wurde ersetzt.

  • Node_A_2 wurde ersetzt.

  • Standort B ist der überlebende Standort.

  • Node_B_1 ist in einem ordnungsgemäßen Zustand.

  • Node_B_2 ist in einem ordnungsgemäßen Zustand.

Die alten und neuen System-IDs wurden in identifiziert "Ersetzen Sie die Hardware und starten Sie neue Controller".

Die Beispiele in diesem Verfahren verwenden Controller mit den folgenden System-IDs:

Knoten

Ursprüngliche System-ID

Neue System-ID

Node_A_1

4068741258

1574774970

Node_A_2

4068741260

1574774991

Knoten_B_1

4068741254

Unverändert

Knoten_B_2

4068741256

Unverändert

Schritte
  1. Weisen Sie beim Austausch-Node im Wartungsmodus die Root-Aggregat-Festplatten neu zu. Verwenden Sie dabei den richtigen Befehl, je nachdem, ob Ihr System mit ADP und Ihrer ONTAP-Version konfiguriert ist.

    Sie können mit der Umverteilung fortfahren, wenn Sie dazu aufgefordert werden.

    Wenn das System ADP verwendet…​

    Verwenden Sie diesen Befehl zur Umverteilung der Festplatte…​

    Ja (ONTAP 9.8)

    disk reassign -s old-system-ID -d new-system-ID -r dr-partner-system-ID

    Ja (ONTAP 9.7.x und früher)

    disk reassign -s old-system-ID -d new-system-ID -p old-partner-system-ID

    Nein

    disk reassign -s old-system-ID -d new-system-ID

    Das folgende Beispiel zeigt die Neuzuweisung von Laufwerken auf einem nicht-ADP-System:

    *> disk reassign -s 4068741256 -d 1574774970
    Partner node must not be in Takeover mode during disk reassignment from maintenance mode.
    Serious problems could result!!
    Do not proceed with reassignment if the partner is in takeover mode. Abort reassignment (y/n)? n
    
    After the node becomes operational, you must perform a takeover and giveback of the HA partner node to ensure disk reassignment is successful.
    Do you want to continue (y/n)? y
    Disk ownership will be updated on all disks previously belonging to Filer with sysid 537037643.
    Do you want to continue (y/n)? y
    disk reassign parameters: new_home_owner_id 537070473 , new_home_owner_name
    Disk 0m.i0.3L14 will be reassigned.
    Disk 0m.i0.1L6 will be reassigned.
    Disk 0m.i0.1L8 will be reassigned.
    Number of disks to be reassigned: 3
  2. Löschen Sie den Inhalt der Mailbox-Platten:

    mailbox destroy local

    Sie können den Vorgang zum Zerstören fortsetzen, wenn Sie dazu aufgefordert werden.

    Im folgenden Beispiel wird die Ausgabe des Befehls „Mailbox zerstören“ für den lokalen Befehl angezeigt:

    *> mailbox destroy local
    Destroying mailboxes forces a node to create new empty mailboxes,
    which clears any takeover state, removes all knowledge
    of out-of-date plexes of mirrored volumes, and will prevent
    management services from going online in 2-node cluster
    HA configurations.
    Are you sure you want to destroy the local mailboxes? y
    ...............Mailboxes destroyed.
    *>
  3. Wenn die Datenträger ausgetauscht wurden, sind lokale Plexe ausgefallen, die gelöscht werden müssen.

    1. Zeigt den Aggregatstatus an:

      aggr status

      Im folgenden Beispiel ist der Plex Node_A_1_aggr0/plex0 fehlgeschlagen.

      *> aggr status
      Aug 18 15:00:07 [node_B_1:raid.vol.mirror.degraded:ALERT]: Aggregate node_A_1_aggr0 is
         mirrored and one plex has failed. It is no longer protected by mirroring.
      Aug 18 15:00:07 [node_B_1:raid.debug:info]: Mirrored aggregate node_A_1_aggr0 has plex0
         clean(-1), online(0)
      Aug 18 15:00:07 [node_B_1:raid.debug:info]: Mirrored aggregate node_A_1_aggr0 has plex2
         clean(0), online(1)
      Aug 18 15:00:07 [node_B_1:raid.mirror.vote.noRecord1Plex:error]: WARNING: Only one plex
         in aggregate node_A_1_aggr0 is available. Aggregate might contain stale data.
      Aug 18 15:00:07 [node_B_1:raid.debug:info]: volobj_mark_sb_recovery_aggrs: tree:
         node_A_1_aggr0 vol_state:1 mcc_dr_opstate: unknown
      Aug 18 15:00:07 [node_B_1:raid.fsm.commitStateTransit:debug]: /node_A_1_aggr0 (VOL):
         raid state change UNINITD -> NORMAL
      Aug 18 15:00:07 [node_B_1:raid.fsm.commitStateTransit:debug]: /node_A_1_aggr0 (MIRROR):
         raid state change UNINITD -> DEGRADED
      Aug 18 15:00:07 [node_B_1:raid.fsm.commitStateTransit:debug]: /node_A_1_aggr0/plex0
         (PLEX): raid state change UNINITD -> FAILED
      Aug 18 15:00:07 [node_B_1:raid.fsm.commitStateTransit:debug]: /node_A_1_aggr0/plex2
         (PLEX): raid state change UNINITD -> NORMAL
      Aug 18 15:00:07 [node_B_1:raid.fsm.commitStateTransit:debug]: /node_A_1_aggr0/plex2/rg0
         (GROUP): raid state change UNINITD -> NORMAL
      Aug 18 15:00:07 [node_B_1:raid.debug:info]: Topology updated for aggregate node_A_1_aggr0
         to plex plex2
      *>
    2. Löschen Sie den fehlgeschlagenen Plex:

      aggr destroy plex-id

    *> aggr destroy node_A_1_aggr0/plex0
  4. Halten Sie den Node an, um die LOADER-Eingabeaufforderung anzuzeigen:

    halt

  5. Wiederholen Sie diese Schritte auf dem anderen Node am Disaster-Standort.