UCS Server der B-Serie: Das Ersetzen eines RAID-Controllers durch eine ältere Firmware kann dazu führen, dass die Bereitstellung des Datenspeichers auf ESXi-Hosts fehlschlägt.

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