Udostępnij przez


Usuwanie problemów z walidacją sprzętu w klastrze Azure Operator Nexus

W tym artykule opisano sposób rozwiązywania problemów z niepowodzeniem weryfikacji sprzętu serwera (HWV). HWV jest uruchamiany w ramach akcji wdrażania klastra i akcji bez systemu operacyjnego replace . HWV weryfikuje maszynę Bare Metal (BMM), wykonując testy na podstawie kontrolera zarządzania płytą główną (BMC). Platforma Azure Operator Nexus jest wdrażana na serwerach firmy Dell. Serwery firmy Dell korzystają ze zintegrowanego kontrolera dostępu zdalnego firmy Dell (iDRAC), który jest odpowiednikiem kontrolera BMC.

Wymagania wstępne

  1. Zainstaluj najnowszą wersję odpowiednich rozszerzeń CLI.
  2. Zażądaj dostępu do uruchomienia poleceń rozszerzenia interfejsu wiersza polecenia dla sieciowego fabricu (NF) i chmury sieciowej platformy Azure Operator Nexus.
  3. Zaloguj się do interfejsu wiersza polecenia platformy Azure i wybierz subskrypcję, w której wdrożono klaster.
  4. Zbierz następujące informacje:
    • Identyfikator subskrypcji (SUBSCRIPTION)
    • Nazwa klastra (CLUSTER)
    • Grupa zasobów (CLUSTER_RG)
    • Zarządzana grupa zasobów (CLUSTER_MRG) — zasoby BareMetal Machines (BMM) znajdują się w tej grupie.
    • Nazwa maszyny BareMetal (BMM_NAME) wymagającej operacji zarządzania cyklu życia
  1. Zażądaj dostępu do obszaru roboczego usługi Log Analytics klastra (LAW).
  2. Dostęp do internetowego interfejsu użytkownika BMC lub serwera pośredniczącego, który umożliwia uruchomienie narzędzia racadm.

Lokalizowanie wyników weryfikacji sprzętu

Jeśli podczas działania Bare Metal Machine (BMM) Replace sprawdzanie poprawności sprzętu nie powiodło się, szczegółowe wyniki błędów powinny być dostępne w Replace wyniku działania i dzienniku aktywności BMM. Aby uzyskać więcej informacji, zobacz Zastępowanie maszyny 'bare metal'.

W przeciwnym razie znajdź wyniki weryfikacji sprzętu w obszarze roboczym usługi Log Analytics klastra (LAW) w następujący sposób.

  1. Przejdź do grupy zasobów klastra w subskrypcji.

  2. Rozwiń zasób LAW dla klastra.

  3. Przejdź do karty *Dzienniki####.

  4. Pobierz wyniki weryfikacji sprzętu przy użyciu zapytania do tabeli HWVal_CL, na podstawie poniższego przykładu.

    Zrzut ekranu przedstawiający zapytanie tabeli niestandardowej LAW w klastrze.

Sprawdzanie wyników weryfikacji sprzętu

Wynik HWV dla określonego serwera zawiera następujące kategorie:

  • system_info
  • drive_info
  • network_info
  • health_info
  • boot_info

Rozwiń result_detail dla określonej kategorii, aby zobaczyć szczegółowe wyniki.

Rozwiąż problemy z określonymi awariami

W tej sekcji omówiono rozwiązywanie problemów, które mogą wystąpić.

Kategoria informacji o systemie

Specyfikacje pamięci są zdefiniowane w wersji. Pamięć poniżej wartości progowej wskazuje brak lub niepowodzenie modułu pamięci wbudowanej (DIMM, Dual Inline Memory Module). W kategorii health_info znajduje się również odzwierciedlenie uszkodzonego modułu DIMM. W poniższym przykładzie przedstawiono nieudane sprawdzanie pamięci.

{
  "field_name": "memory_capacity_GB",
  "comparison_result": "Fail",
  "expected": "512",
  "fetched": "480"
}

Aby sprawdzić informacje o pamięci w internetowym interfejsie użytkownika kontrolera BMC, postępuj zgodnie ze ścieżką BMC nawigacji ->System ->Memory.

Aby sprawdzić informacje o pamięci za pomocą polecenia racadm:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD hwinventory | grep SysMemTotalSize

Aby rozwiązać problem z pamięcią, skontaktuj się z dostawcą.

Specyfikacje techniczne procesora są określone w wersji oprogramowania. Niepowodzenie cpu_sockets w sprawdzaniu wskazuje na niezgodność liczby procesorów CPU lub na błąd procesora. W poniższym przykładzie pokazano nieudane sprawdzanie procesora.

{
  "field_name": "cpu_sockets",
  "comparison_result": "Fail",
  "expected": "2",
  "fetched": "1"
}

Aby sprawdzić informacje o CPU w interfejsie webowym BMC, wykonaj nawigację ścieżką BMC ->System ->CPU.

Aby sprawdzić informacje o procesorze CPU za pomocą racadm:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD hwinventory | grep PopulatedCPUSockets

Aby rozwiązać problem z procesorem CPU, skontaktuj się z dostawcą.

Niepowodzenie sprawdzania modelu (Model)

Nieudane sprawdzenie Model wskazuje, że niewłaściwy serwer jest zamontowany w nieodpowiednim miejscu w szafie, lub występuje niezgodność okablowania. W poniższym przykładzie pokazano nieudane sprawdzanie modelu.

{
  "field_name": "Model",
  "comparison_result": "Fail",
  "expected": "R750",
  "fetched": "R650"
}

Aby sprawdzić informacje o modelu w webowym interfejsie użytkownika BMC, postępuj zgodnie ze ścieżką nawigacyjną BMC ->Dashboard - Pokaż model.

Aby sprawdzić informacje o modelu za pomocą polecenia racadm:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD getsysinfo | grep Model

Aby rozwiązać ten problem, upewnij się, że serwer jest w stojaku w odpowiedniej lokalizacji i odpowiednio podłączony oraz że przypisano prawidłowy adres IP.

Niepowodzenie sprawdzania numeru seryjnego (Serial_Number)

Numer seryjny serwera, określany również jako tag usługi, jest zdefiniowany w klastrze. Sprawdzanie nie powiodło Serial_Number się wskazuje niezgodność między numerem seryjnym w klastrze a rzeczywistym numerem seryjnym maszyny. W poniższym przykładzie pokazano nieudane sprawdzanie numeru seryjnego.

{
  "field_name": "Serial_Number",
  "comparison_result": "Fail",
  "expected": "1234567",
  "fetched": "7654321"
}

Aby sprawdzić informacje o numerze seryjnym w internetowym interfejsie użytkownika kontrolera BMC, postępuj zgodnie ze ścieżką BMC nawigacji —>Dashboard Pokazuje tag usługi.

Aby sprawdzić informacje o numerze seryjnym za pomocą polecenia racadm:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD getsysinfo | grep "Service Tag"

Aby rozwiązać ten problem, upewnij się, że serwer jest w stojaku w odpowiedniej lokalizacji i odpowiednio podłączony oraz że przypisano prawidłowy adres IP.

Niepowodzenie sprawdzania licencji iDRAC

Wszystkie kontrolery iDRAC wymagają bezterminowej/produkcyjnej licencji iDRAC dla centrum danych lub przedsiębiorstwa. Licencje próbne są ważne tylko przez 30 dni. iDRAC License Check Błąd wskazuje, że brakuje wymaganej licencji iDRAC. W poniższych przykładach przedstawiono sprawdzanie licencji iDRAC, które zakończyło się niepowodzeniem, odpowiednio dla licencji próbnej i braku licencji.

{
  "field_name": "iDRAC License Check",
  "comparison_result": "Fail",
  "expected": "idrac9 x5 datacenter license or idrac9 x5 enterprise license - perpetual or production",
  "fetched": "iDRAC9 x5 Datacenter Trial License - Trial"
}
{
  "field_name": "iDRAC License Check",
  "comparison_result": "Fail",
  "expected": "idrac9 x5 datacenter license or idrac9 x5 enterprise license - perpetual or production",
  "fetched": ""
}

Aby rozwiązać ten problem, skontaktuj się z dostawcą, aby uzyskać poprawną licencję. Zastosuj licencję przy użyciu internetowego interfejsu użytkownika iDRAC w następującej ścieżce nawigacji BMC ->Configuration ->Licenses.

Sprawdzanie wersji oprogramowania układowego

Testy wersji oprogramowania układowego zostały wprowadzone w wersji 3.9. W poniższym przykładzie pokazano oczekiwany log dla wersji wydania wcześniejszych niż 3.9.

{
  "system_info": {
    "system_info_result": "Pass",
    "result_log": ["Firmware validation not supported in release 3.8"]
  }
}

Wersje oprogramowania układowego są określane na podstawie cluster version wartości w obiekcie klastra. W poniższym przykładzie pokazano, że sprawdzanie nie powiodło się z powodu nieokreślonej wersji klastra. Jeśli ten problem zostanie napotkany, sprawdź wersję w obiekcie klastra.

{
  "system_info": {
    "system_info_result": "Fail",
    "result_log": ["Unable to determine firmware release"]
  }
}

Wersje oprogramowania układowego są zapisywane jako informacja. Następujące wersje firmware'u składników są zazwyczaj rejestrowane (w zależności od modelu sprzętowego).

  • BIOS
  • iDRAC
  • Złożone programowalne urządzenie logiki (CPLD)
  • Kontroler macierzy RAID (Redundant Array of Independent Disks)
  • Płyta główna
  • Broadcom/Mellanox/NVIDIA Network Interface Card (NIC)

Platforma HWV identyfikuje problematyczne wersje oprogramowania układowego i próbuje je naprawić automatycznie. Wersje komponentów automatycznej poprawki HWV są powiązane z wydaniami. W poniższym przykładzie przedstawiono pomyślną poprawkę oprogramowania układowego iDRAC. (Wersje i identyfikator zadania są przeznaczone tylko dla ilustracji).

{
  "system_info": {
    "system_info_result": "Pass",
    "result_detail": [
      {
        "field_name": "Integrated Dell Remote Access Controller - unsupported_firmware_check",
        "comparison_result": "Pass",
        "expected": "6.00.30.00 - unsupported_firmware",
        "fetched": "7.10.30.00"
      }
    ],
    "result_log": [
      "Firmware autofix task /redfish/v1/TaskService/Tasks/JID_274085357727 completed"
    ]
  }
}

Uwaga / Notatka

Struktura automatycznego naprawiania firmware'u HWV została rozszerzona w celu uwzględnienia CPLD dla modeli Ice Lake w wersji 2510.1 (NC4.7.0).

Kategoria informacji o dysku

Niepowodzenie sprawdzania dysku

Specyfikacje napędów są określone w wersji oprogramowania. Niedopasowane wartości pojemności wskazują nieprawidłowe dyski lub dyski wstawione do nieprawidłowych gniazd. Brakujące wartości pojemności i typu wskazują dyski, które zakończyły się niepowodzeniem, brakuje lub zostały wstawione do nieprawidłowych miejsc.

{
  "field_name": "Disk_0_Capacity_GB",
  "comparison_result": "Fail",
  "expected": "893",
  "fetched": "3576"
}
{
  "field_name": "Disk_0_Capacity_GB",
  "comparison_result": "Fail",
  "expected": "893",
  "fetched": ""
}
{
  "field_name": "Disk_0_Type",
  "comparison_result": "Fail",
  "expected": "SSD",
  "fetched": ""
}

Aby sprawdzić informacje o dysku w interfejsie użytkownika BMC, postępuj zgodnie ze ścieżką nawigacji BMC ->Storage ->Physical Disks.

Aby sprawdzić informacje o dysku za pomocą polecenia racadm:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD raid get pdisks -o -p State,Size

Aby rozwiązać problemy, upewnij się, że dyski są wstawiane do odpowiednich miejsc. Jeśli problem będzie się powtarzać, skontaktuj się z dostawcą.

Kategoria informacji o sieci

Niepowodzenie sprawdzania kart interfejsu sieciowego (NIC)

Specyfikacje NIC serwera firmy Dell są określone w wersji. Niezgodny stan połączenia wskazuje na luźne lub wadliwe okablowanie, albo kable krzyżowe. Niezgodny model wskazuje, że niepoprawna karta sieciowa jest wstawiana do gniazda. Brakujące wartości linków lub modeli wskazują, że karty sieciowe są uszkodzone, brakujące lub zostały umieszczone w niewłaściwych gniazdach.

{
  "field_name": "NIC.Slot.3-1-1_LinkStatus",
  "comparison_result": "Fail",
  "expected": "Up",
  "fetched": "Down"
}
{
  "field_name": "NIC.Embedded.2-1-1_LinkStatus",
  "comparison_result": "Fail",
  "expected": "Down",
  "fetched": "Up"
}
{
  "field_name": "NIC.Slot.3-1-1_Model",
  "comparison_result": "Fail",
  "expected": "ConnectX-6",
  "fetched": "BCM5720"
}
{
  "field_name": "NIC.Slot.3-1-1_LinkStatus",
  "comparison_result": "Fail",
  "expected": "Up",
  "fetched": ""
}
{
  "field_name": "NIC.Slot.3-1-1_Model",
  "comparison_result": "Fail",
  "expected": "ConnectX-6",
  "fetched": ""
}

Aby sprawdzić informacje o karcie sieciowej w webowym interfejsie użytkownika BMC, postępuj zgodnie ze ścieżką nawigacyjną BMC ->System ->Network Devices.

Aby sprawdzić wszystkie informacje o karcie sieciowej (NIC) za pomocą racadm:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD hwinventory NIC

pl-PL: Aby sprawdzić określoną kartę sieciową za pomocą racadm, podaj w pełni kwalifikowany deskryptor urządzenia:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD hwinventory NIC.Embedded.1-1-1

Aby rozwiązać problemy, upewnij się, że serwery są poprawnie podłączone i że porty są połączone. Odbić port w sieci szkieletowej. Wykonaj zabieg przeciwpchelny. Jeśli problem będzie się powtarzać, skontaktuj się z dostawcą.

Sprawdzanie informacji o przełączniku warstwy 2 przez kartę sieciową

Funkcja HWV raportuje informacje o przełączniku warstwy 2 dla każdego interfejsu serwera. Identyfikator połączenia przełącznika (interfejs przełącznika MAC) i identyfikator połączenia portu przełącznika (etykieta interfejsu przełącznika) są informacyjne.

{
  "field_name": "NIC.Slot.3-1-1_SwitchConnectionID",
  "comparison_result": "Info",
  "expected": "unknown",
  "fetched": "c0:d6:82:23:0c:7d"
}
{
  "field_name": "NIC.Slot.3-1-1_SwitchPortConnectionID",
  "comparison_result": "Info",
  "expected": "unknown",
  "fetched": "Ethernet10/1"
}

Sprawdzanie okablowania dla interfejsów wiązanych

Niezgodność okablowania jest zgłaszana w pliku result_log. Sprawdzenie kabli weryfikuje, czy połączone karty sieciowe łączą się z portami przełącznika o tym samym identyfikatorze portu. W poniższym przykładzie złącza komponentów peryferyjnych (PCI) 3/1 i 3/2 są połączone z Ethernet1/1 i Ethernet1/3 odpowiednio na TOR, co wyzwala błąd dla HWV.

{
  "network_info": {
    "network_info_result": "Fail",
    "result_detail": [
      {
        "field_name": "NIC.Slot.3-1-1_SwitchPortConnectionID",
        "fetched": "Ethernet1/1"
      },
      {
        "field_name": "NIC.Slot.3-2-1_SwitchPortConnectionID",
        "fetched": "Ethernet1/3"
      }
    ],
    "result_log": [
      "Cabling problem detected on PCI Slot 3 - server NIC.Slot.3-1-1 connected to switch Ethernet1/1 - server NIC.Slot.3-2-1 connected to switch Ethernet1/3"
    ]
  }
}

Aby rozwiązać ten problem, włóż kable do odpowiednich interfejsów.

Niepowodzenie sprawdzania adresów MAC iDRAC (BMC)

Adres MAC iDRAC jest zdefiniowany w klastrze dla każdej maszyny typu Bare Metal. iDRAC_MAC Sprawdzanie się nie powiodło, wskazuje niezgodność między iDRAC/BMC MAC w klastrze a rzeczywistym adresem MAC pobranym z maszyny.

{
  "field_name": "iDRAC_MAC",
  "comparison_result": "Fail",
  "expected": "aa:bb:cc:dd:ee:ff",
  "fetched": "aa:bb:cc:dd:ee:gg"
}

Aby rozwiązać ten problem, upewnij się, że prawidłowy adres MAC jest zdefiniowany w klastrze. Jeśli adres MAC jest właściwy dla obiektu klastra, spróbuj usunąć problem. Jeśli problem będzie się powtarzać, upewnij się, że serwer jest w stojaku w odpowiedniej lokalizacji, odpowiednio podłączony i że przypisano prawidłowy adres IP.

Niepowodzenie sprawdzania adresu MAC środowiska preboot eXecution Environment (PXE)

Adres MAC PXE jest zdefiniowany w klastrze dla każdej maszyny Bare Metal. Sprawdzenie zakończone niepowodzeniem PXE_MAC wskazuje na niezgodność między adresem MAC PXE w klastrze a rzeczywistym adresem MAC pobranym z maszyny.

{
  "field_name": "NIC.Embedded.1-1_PXE_MAC",
  "comparison_result": "Fail",
  "expected": "aa:bb:cc:dd:ee:ff",
  "fetched": "aa:bb:cc:dd:ee:gg"
}

Aby rozwiązać ten problem, upewnij się, że prawidłowy adres MAC jest zdefiniowany w klastrze. Jeśli adres MAC jest właściwy dla obiektu klastra, spróbuj usunąć problem. Jeśli problem będzie się powtarzać, upewnij się, że serwer jest w stojaku w odpowiedniej lokalizacji, odpowiednio podłączony i że przypisano prawidłowy adres IP.

Kategoria informacji o kondycji

Błąd czujnika kontroli kondycji

Testy kondycji serwera obejmują różne czujniki składników sprzętu. Czujnik kondycji, który zakończył się niepowodzeniem, wskazuje problem z odpowiednim składnikiem sprzętu. W poniższych przykładach przedstawiono odpowiednio awarie wentylatora, dysku i procesora CPU.

{
  "field_name": "System Board Fan1A",
  "comparison_result": "Fail",
  "expected": "Enabled-OK",
  "fetched": "Enabled-Critical"
}
{
  "field_name": "Solid State Disk 0:1:1",
  "comparison_result": "Fail",
  "expected": "Enabled-OK",
  "fetched": "Enabled-Critical"
}
{
  "field_name": "CPU.Socket.1",
  "comparison_result": "Fail",
  "expected": "Enabled-OK",
  "fetched": "Enabled-Critical"
}

Aby sprawdzić informacje o kondycji w internetowym interfejsie użytkownika kontrolera BMC, postępuj zgodnie ze ścieżką BMC nawigacji —>Dashboard pokazuje informacje o kondycji.

Aby sprawdzić informacje zdrowotne za pomocą racadm:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD getsensorinfo

Aby rozwiązać problem z awarią kondycji serwera, skontaktuj się z dostawcą.

Błędy dziennika kontroli kondycji (LC)

Sprawdzanie kondycji serwera firmy Dell kończy się niepowodzeniem w przypadku ostatnich alarmów krytycznych w dzienniku LC. Wtyczka sprawdzania poprawności sprzętu rejestruje identyfikator alarmu, nazwę i sygnaturę czasową. Ostatnie krytyczne alarmy wskazują na potrzebę dalszego badania. W poniższym przykładzie pokazano awarię krytycznego alarmu napięcia płaszczyzny wstecznej.

{
  "field_name": "LCLog_Critical_Alarms",
  "comparison_result": "Fail",
  "expected": "No Critical Errors",
  "fetched": "53539 2023-07-22T23:44:06-05:00 The system board BP1 PG voltage is outside of range."
}
  • Błędy dysku wirtualnego zwykle wskazują na fałszywie dodatni wynik procesu czyszczenia RAID. Są rejestrowane z powodu synchronizacji czyszczenia RAID i wyłączenia systemu przed HWV. Poniższy przykład pokazuje błąd krytyczny logu LC na dysku wirtualnym 238. Jeśli wystąpi wiele błędów blokujących wdrożenie, usuń klaster, zaczekaj dwie godziny, a następnie spróbuj ponownie przeprowadzić wdrożenie klastra. Jeśli błędy nie blokują wdrożenia, poczekaj dwie godziny, a następnie uruchom maszynę bare metal replace.
  • Błędy dysku wirtualnego są umieszczane na białej liście począwszy od wersji 3.13 i nie powodują awarii podczas sprawdzania kondycji.
{
  "field_name": "LCLog_Critical_Alarms",
  "comparison_result": "Fail",
  "expected": "No Critical Errors",
  "fetched": "104473 2024-07-26T16:05:19-05:00 Virtual Disk 238 on RAID Controller in SL 3 has failed."
}

Począwszy od wersji 3.14 operatora platformy Azure, alarmy krytyczne i alarmy ostrzegawcze umieszczone na liście dozwolonych są rejestrowane jako informacyjne.

{
  "field_name": "LCLog_Warning_Alarms - Non-Failing",
  "comparison_result": "Info",
  "expected": "Warning Alarm",
  "fetched": "104473 2024-07-26T16:05:19-05:00 The Embedded NIC 1 Port 1 network link is down."
}

Aby sprawdzić dzienniki LC w internetowym interfejsie użytkownika BMC, postępuj zgodnie ze ścieżką BMC ->Maintenance ->Lifecycle Log.

Aby sprawdzić alarmy krytyczne dziennika LC za pomocą racadm:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD lclog view -s critical

W przypadku Backplane Comm rejestrowania błędów krytycznych należy wykonać drenaż pchli. Skontaktuj się z dostawcą, aby rozwiązać problemy z pozostałymi błędami krytycznymi dziennika LC.

Błędy dotyczące sterowania zasilaniem serwera sprawdzania kondycji

Testy kondycji serwera firmy Dell nie powiodły się w przypadku awarii zasilania serwera lub nieudanego resetowania iDRAC. Akcja kontroli serwera, która zakończyła się niepowodzeniem, wskazuje podstawowy problem ze sprzętem. W poniższym przykładzie przedstawiono nieudaną próbę włączenia zasilania.

{
  "field_name": "Server Control Actions",
  "comparison_result": "Fail",
  "expected": "Success",
  "fetched": "Failed"
}
"result_log": [
    "Server power up failed with: server OS is powered off after successful power on attempt",
]

Aby włączyć serwer w internetowym interfejsie użytkownika kontrolera BMC, podążaj ścieżką nawigacyjną BMC->Dashboard->Power On System.

Aby włączyć serwer za pomocą polecenia racadm:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD serveraction powerup

Aby rozwiązać problemy z awarią zasilania serwera, spróbuj opróżnić płot. Jeśli problem będzie się powtarzać, skontaktuj się z dostawcą.

Wirtualne usuwanie pcheł

HWV próbuje wirtualnego usuwania błędów dla większości nieudanych sprawdzeń. Próby opróżniania Flea są rejestrowane w obszarze health_info>result_log.

"result_log": [
    "flea drain completed successfully",
]

Jeśli wirtualny system „flea drain” się nie powiedzie, wykonaj fizyczny system „flea drain” jako pierwszy krok rozwiązywania problemu.

Błędy oczyszczania RAID

W ramach oczyszczania RAID resetowana jest konfiguracja kontrolera RAID. Sprawdzanie kondycji serwera firmy Dell kończy się niepowodzeniem w przypadku niepowodzenia resetowania kontrolera RAID. Akcja oczyszczania RAID, która nie powiodła się, wskazuje podstawowy problem ze sprzętem. W poniższym przykładzie pokazano niepowodzenie resetowania kontrolera RAID.

{
  "field_name": "Server Control Actions",
  "comparison_result": "Fail",
  "expected": "Success",
  "fetched": "Failed"
}
"result_log": [
    "RAID cleanup failed with: raid deletion failed after 2 attempts",
]

Aby wyczyścić macierz RAID w internetowym interfejsie użytkownika BMC, podążaj ścieżką nawigacji i wybierz pozycję BMC>Dashboard>Storage>Controllers>Actions>Reset Configuration.

Aby wyczyścić macierz RAID za pomocą racadm, sprawdź kontrolery RAID, potem wyczyść konfigurację.

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD storage get controllers | grep "RAID"
racadm --nocertwarn -r $IP -u $BMC_USR -p $BC_PWD storage resetconfig:RAID.SL.3-1         #substitute with RAID controller from get command
racadm --nocertwarn -r $IP -u $BMC_USR -p $BC_PWD jobqueue create RAID.SL.3-1 --realtime  #substitute with RAID controller from get command

Aby rozwiązać problemy z niepowodzeniem oczyszczania raid, sprawdź wszelkie zarejestrowane błędy. W przypadku komputerów Dell R650/660 upewnij się, że tylko gniazda 0 i 1 zawierają dyski fizyczne. W przypadku firmy Dell R750/760 upewnij się, że tylko gniazda od 0 do 3 zawierają dyski fizyczne. W przypadku innych modeli upewnij się, że żadne dodatkowe dyski nie są wstawiane na podstawie definicji wersji. Wszystkie dodatkowe dyski należy usunąć, aby dopasować je do wersji. Jeśli problem będzie się powtarzać, skontaktuj się z dostawcą.

Alerty krytyczne dotyczące wirtualnego dysku BMC można zignorować podczas HWV.

Zagadnienia dotyczące awarii zasilania i nadmiarowości kontroli kondycji

Testy kondycji serwera firmy Dell ostrzegają, gdy brakuje jednego zasilacza lub gdy jeden zasilacz ulegnie awarii. Zasilacz field_name może pojawić się odpowiednio jako 0/PS0/Zasilacz 0 i 1/PS1/Zasilacz 1 dla pierwszych i drugich zasilaczy. Awaria jednego zasilacza nie powoduje awarii urządzenia HWV.

{
  "field_name": "Power Supply 1",
  "comparison_result": "Warning",
  "expected": "Enabled-OK",
  "fetched": "UnavailableOffline-Critical"
}
{
  "field_name": "System Board PS Redundancy",
  "comparison_result": "Warning",
  "expected": "Enabled-OK",
  "fetched": "Enabled-Critical"
}

Aby sprawdzić zasilacze w interfejsie użytkownika BMC, wybierz pozycję BMC>System>Power.

Aby sprawdzić zasilacze za pomocą racadm:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD getsensorinfo | grep PS

Zmiana zasilania może rozwiązać problem. Jeśli alarmy będą się powtarzać, skontaktuj się z dostawcą.

Kategoria informacji o rozruchu

Zagadnienia dotyczące sprawdzania nazwy urządzenia rozruchowego

  • Kontrola boot_device_name jest obecnie informacyjna.
  • Niezgodna nazwa urządzenia rozruchowego nie powinna wyzwalać błędu urządzenia.
{
  "field_name": "boot_device_name",
  "comparison_result": "Info",
  "expected": "NIC.PxeDevice.1-1",
  "fetched": "NIC.PxeDevice.1-1"
}

Zagadnienia dotyczące sprawdzania urządzeń PXE

  • To sprawdzenie sprawdza poprawność ustawień urządzenia PXE.
  • Ponieważ wersja interfejsu API 2024-07-01 GA, HWV próbuje automatycznie naprawić konfigurację rozruchu systemu BIOS.
  • Niepowodzenie kontroli pxe_device_1_name lub pxe_device_1_state wskazuje na problem z konfiguracją PXE.
  • Aby włączyć rozruch systemu podczas wdrażania, należy naprawić ustawienia, których nie udało się zastosować.
{
  "field_name": "pxe_device_1_name",
  "comparison_result": "Fail",
  "expected": "NIC.Embedded.1-1-1",
  "fetched": "NIC.Embedded.1-2-1"
}
{
  "field_name": "pxe_device_1_state",
  "comparison_result": "Fail",
  "expected": "Enabled",
  "fetched": "Disabled"
}

Aby zaktualizować stan i nazwę urządzenia PXE w internetowym interfejsie użytkownika kontrolera BMC, ustaw wartość, a następnie wybierz pozycję **Zastosuj*#### > **Zastosuj i uruchom ponownie**:

  • BMC->Configuration>BIOS Settings>Network Settings>PXE Device1>Enabled
  • BMC->Configuration>BIOS Settings>Network Settings>PXE Device1 Settings - ->Interface>Embedded NIC 1 Port 1 Partition 1

Aby zaktualizować stan i nazwę urządzenia PXE za pomocą polecenia racadm, uruchom następujące polecenia:

racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD set bios.NetworkSettings.PxeDev1EnDis Enabled
racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD set bios.PxeDev1Settings.PxeDev1Interface NIC.Embedded.1-1-1
racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD jobqueue create BIOS.Setup.1-1
racadm --nocertwarn -r $IP -u $BMC_USR -p $BMC_PWD serveraction powercycle

Sprawdzanie logowania urządzenia

Zagadnienia dotyczące sprawdzania logowania urządzenia

Sprawdzanie device_login nie powiedzie się, jeśli iDRAC nie jest osiągalny lub jeśli moduł sprawdzania poprawności sprzętu nie może się zalogować.

{
  "device_login": "Fail - Unreachable"
}
{
  "device_login": "Fail - Unauthorized"
}

Uwaga / Notatka

Jeśli walidacja sprzętu nie powiedzie się z powodu problemów z uwierzytelnianiem poświadczeń kontrolera BMC (Brak autoryzacji), akcja zostanie odrzucona, ale maszyna bez systemu operacyjnego nie zostanie oznaczona jako niepowodzenie lub zostanie umieszczona w stanie błędu. Maszyna bez systemu operacyjnego utrzymuje bieżący stan operacyjny, podczas gdy walidacja sprzętu zgłasza błąd uwierzytelniania poświadczeń.

Aby ustawić hasło w internetowym interfejsie użytkownika kontrolera BMC, postępuj zgodnie ze ścieżką nawigacji BMC ->iDRAC Settings ->Users ->Local Users ->Edit.

Aby ustawić hasło za pomocą racadm:

racadm -r $BMC_IP -u $BMC_USER -p $CURRENT_PASSWORD  set iDRAC.Users.2.Password $BMC_PWD

Aby rozwiązać problemy, wyślij polecenie ping do usługi iDRAC z serwera przesiadkowego z dostępem do sieci BMC. Jeśli iDRAC odpowiada na polecenie ping, sprawdź, czy hasła się zgadzają.

Dodawanie serwerów z powrotem do klastra po naprawie

Po naprawieniu sprzętu uruchom akcję Maszyna Bare Metal replace, postępując zgodnie z instrukcjami w zarządzaniu cyklem życia maszyn Bare Metal.