Inhalt

Problemaussage:

Betroffene Hardware:

Server mit UCSB-MRAID12G RAID-Controllern:

Betroffene Firmware:

Betroffenes Betriebssystem:

Ursache:

Wie kann verhindert werden, dass das Problem auftritt?

Wie kann ich die Wiederherstellung durchführen, wenn der Server mit diesem Problem betroffen ist?

Ähnliches BUG: CSCvr11972

Problemaussage:

Nach dem Austausch des RAID-Controllers wurde die NAA-ID des VD beim Import der Fremdkonfiguration geändert, wodurch die Bereitstellung des Datenspeichers fehlschlug.

Betroffene Hardware:

UCSB-MRAID12G

UCSC-MRAID12G

Server mit UCSB-MRAID12G RAID-Controllern:

UCS B200 M4

UCS B200 M5

UCS B480 M5

UCS B420 M4

UCS C220 M4

UCS C240 M4

Betroffene Firmware:

RAID-Controller-Firmware: 24.5.x.x und 24.6.x.x

Beispielnr.

***mrsasctlr.24.5.0-0043_6.19.05.0_NA.bin

24.5.x.x Controller-Firmware wird in allen UCSM-Versionen vor 3.2 angezeigt.*

Versionshinweise von 3.1 #

https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/release/notes/CiscoUCSManager-RB-3-1.htmlhttps://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/release/notes/CiscoUCSManager-RB-3-1.html

Betroffenes Betriebssystem:

VMware ESXi

Ursache:

Bei älteren Firmware-Versionen kann die Controller-FW die NAA-ID aus dem DDF beim Import aus dem Ausland nicht wiederherstellen, wenn ein Fehler bei der Workspace-Version des DDF(Device Data Format) festgestellt wird.

MR 6.4 hat DDF_WORK_SPACE Version 1, MR6.10 hingegen DDF_WORK_SPACE Version 3. Spätere Versionen von FW nach MR 6.4 wurden Korrekturen vorgenommen, die es der Controller-FW ermöglichen, die NAA-IDD von DDF wiederherzustellen, selbst wenn eine DDF-Workspace-Diskrepanz gefunden wurde. NAA-ID kann nicht ordnungsgemäß analysiert werden, wenn die Firmware des Ersatz-Controllers alt ist (Beispiel: 24.5.x und 24.6.x). Die Version 24.12.x kann die NAA-ID jedoch ordnungsgemäß analysieren.

Vor dem Austausch:

Server 2/2:

Ausgerüsteter Produktname: Cisco UCS B200 M5 2-Socket-Blade-Server

Ausgerüstete PID: UCSB-B200-M5

Ausgerüstete VID: V06

Seriell ausgerüstete Geräte (SN): FCH22973K5

Steckplatzstatus: Ausgerüstet

Bestätigter Produktname: Cisco UCS B200 M5 2-Socket-Blade-Server

Bestätigte PID: UCSB-B200-M5

Bestätigte VID: V06

Serial (SN) bestätigt: FCH22973K5

Bestätigter Speicher (MB): 524288

Bestätigter effektiver Speicher (MB): 524288

Bestätigte Kerne: 28

Bestätigte Adapter: 1

Virtuelles Laufwerk 0:

Typ: RAID 1 gespiegelt

Blockgröße: 512

Blöcke: 1560545280

Betriebsfähigkeit: Operabel

Präsenz: Ausgerüstet

Größe: 761985

Lebenszyklus: Zugeordnet

Laufwerkstatus: Optimal

Strip-Größe (KB): 64

Zugriffsrichtlinie: Schreiben lesen

Richtlinien lesen: Normal

Konfigurierte Cache-Richtlinie für Schreibvorgänge: Schreiben durch

Aktuelle Cache-Richtlinie für Schreibvorgänge: Schreiben durch

IO-Richtlinie: Direkt

Laufwerkcache: Keine Änderung

Bootfähig: Richtig

Eindeutige Kennung: bcc0dd21-2006-4189-86c1-132017ad0958

Eindeutige Identifikation des Anbieters: 618e7283-72eb-6460-240f-d02c0bd9310 <<<<<<<<<

Nach Ersatz:

Server 2/2:

Ausgerüsteter Produktname: Cisco UCS B200 M5 2-Socket-Blade-Server

Ausgerüstete PID: UCSB-B200-M5

Ausgerüstete VID: V06

Seriell ausgerüstete Geräte (SN): FCH22973K5

Steckplatzstatus: Ausgerüstet

Bestätigter Produktname: Cisco UCS B200 M5 2-Socket-Blade-Server

Bestätigte PID: UCSB-B200-M5

Bestätigte VID: V06

Serial (SN) bestätigt: FCH22973K5

Bestätigter Speicher (MB): 524288

Bestätigter effektiver Speicher (MB): 524288

Bestätigte Kerne: 28

Bestätigte Adapter: 1

Virtuelles Laufwerk 0:

Typ: RAID 1 gespiegelt

Blockgröße: 512

Blöcke: 1560545280

Betriebsfähigkeit: Operabel

Präsenz: Ausgerüstet

Größe: 761985

Lebenszyklus: Zugeordnet

Laufwerkstatus: Optimal

Strip-Größe (KB): 64

Zugriffsrichtlinie: Schreiben lesen

Richtlinien lesen: Normal

Konfigurierte Cache-Richtlinie für Schreibvorgänge: Schreiben durch

Aktuelle Cache-Richtlinie für Schreibvorgänge: Schreiben durch

IO-Richtlinie: Direkt

Laufwerkcache: Keine Änderung

Bootfähig: Richtig

Eindeutige Kennung: 7a894b44-721a-41ae-a3bf-380102b9e64e

Eindeutige Identifikation des Anbieters: 618e7283-72ea-3f20-ff00-005a0574b04b <<<<<<<<<

In diesem Fall [Vendor Unique Identifier] ID von Server 2/2 wurde von [618e7283-72eb-6460-240f-d02c0bbd9310] in [618e7283-72ea-3f] geändert. 20-ff00-005a0574b04b]

Wie kann verhindert werden, dass das Problem auftritt?

Dieses Problem kann vermieden werden, indem die Firmware des Ersatz-Controllers aktualisiert wird, bevor die VD/Festplatte eingefügt wird.

Detaillierte Schritte:

1. Herunterfahren des Servers

2. Entfernen Sie alle Festplatten einzeln, und belassen Sie die Festplatten im gleichen Steckplatz, sodass ihre Platzierungsreihenfolge nicht gestört wird. (Wenn Sie die Festplatten vollständig aus dem Steckplatz entfernen, notieren Sie sich bitte den Steckplatz, da die Laufwerke wieder in denselben Steckplatz eingesetzt werden müssen)

3. Installieren Sie einen neuen RAID-Controller für den Austausch, ohne dass ein Datenträger eingelegt wird.

4. Der Server erkennt den neuen RAID-Controller.

5. Aktualisieren Sie die Firmware des RAID-Controllers.

6. Schalten Sie nach dem erfolgreichen Firmware-Upgrade den Server aus, und legen Sie die Festplatte in den Server ein.

7. Schalten Sie jetzt den Server ein.

Wie kann ich die Wiederherstellung durchführen, wenn der Server mit diesem Problem betroffen ist?

Detaillierte Schritte:

========================

Verfahren zum Wiederherstellen des Datenspeichers

========================

1 Melden Sie sich beim vSphere-Client an, und wählen Sie den Server aus der Inventar-Leiste aus.

2 Klicken Sie auf die Registerkarte Konfiguration und anschließend im Bereich Hardware auf Speicher.

3 Klicken Sie auf Storage hinzufügen.

4 Wählen Sie den Speichertyp Disk/LUN aus, und klicken Sie auf Weiter.

5 Wählen Sie aus der Liste der LUNs die LUN aus, die einen in der Spalte VMFS Label angezeigten Namen für den Datenspeicher hat, und klicken Sie auf Next (Weiter).

Hinweis: Der in der Spalte VMFS Label enthaltene Name gibt an, dass es sich bei der LUN um eine Kopie eines vorhandenen VMFS-Datenspeichers handelt.

6 unter Montageoptionen, werden folgende Optionen angezeigt:

Bestehende Signatur beibehalten: Dauerhafte Bereitstellung der LUN (z. B. Bereitstellung von LUN über Neustarts hinweg)

Neue Signatur zuweisen: Unterzeichnen der LUN

Formatieren der Festplatte: LUN neu formatieren

Hinweise: Formatieren der FestplatteLöscht alle vorhandenen Daten auf der LUN. Stellen Sie vor dem Versuch einer Neusignatur sicher, dass auf keinem anderen Host virtuelle Systeme ausgeführt werden, die das VMFS-Volume ausführen, da diese virtuellen Systeme im vCenter-Serverbestand ungültig werden und auf den jeweiligen Hosts erneut registriert werden.

Wählen Sie Neue Signatur zuweisen aus, und klicken Sie auf Weiter.

7 Wählen Sie die gewünschte Option für Ihr Volume aus.

8 Überprüfen Sie auf der Seite Ready to Complete (Bereit zum Abschließen) die Konfigurationsinformationen des Datenspeichers, und klicken Sie auf Finish (Fertig stellen).

========================

Nächste Schritte

=====================

Nach der Kündigung müssen Sie möglicherweise Folgendes tun:

1 Melden Sie sich beim vSphere-Client an (U).Unter "Bestandsliste" > Klicken Sie auf "Datenspeicher".

2 Klicken Sie mit der rechten Maustaste auf den Datenspeicher, und klicken Sie auf "Datenspeicher durchsuchen".

3 Klicken Sie im linken Teilfenster auf einen Ordner für virtuelle Systeme, um den Inhalt im rechten Teilfenster anzuzeigen.

4 Klicken Sie im rechten Teilfenster mit der rechten Maustaste auf die VMX-Datei, und wählen Sie "Zu Bestand hinzufügen" aus.

5 exemplarische Vorgehensweise: Der Assistent "Add to Inventory" (Zum Bestand hinzufügen) wird ausgeführt, um das virtuelle System zum ESXi-Host hinzuzufügen.

6 Wiederholte Schritte für alle verbleibenden VMs

7 Nachdem alle VMs neu registriert wurden, entfernen Sie alle nicht zugreifbaren VMs aus dem Bestand, indem Sie mit der rechten Maustaste auf die einzelnen VMs klicken und "Aus Bestand entfernen" auswählen.

8 Schalten Sie jede VM ein, und überprüfen Sie, ob sie betriebsbereit und zugänglich ist.

Hinweis: Stellen Sie vor dem Einschalten des VM sicher, dass der ESXi-Host neu gestartet wird und nachdem er wieder online ist und über den vSphere-Client auf ihn zugegriffen werden kann, dass die VMs immer noch sichtbar sind und nicht in den Status "Unzugänglich" gewechselt sind.

Zugehöriges BUG: CSCvr11972

CSCvr11972 Eindeutige Identifikator des Anbieters nach Ersetzen von MRAID12G geändert

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr11972