Rozwiązywanie problemów z serwerem Azure Operator Nexus Bare Metal Machine

W tym artykule opisano sposób rozwiązywania problemów z serwerem przy użyciu akcji Ponowne uruchamianie, Ponowne obrazowanie i Zastąpienie na maszynach Bare Metal Operatora Nexus platformy Azure. Może być konieczne wykonanie tych działań na serwerze ze względu na konserwację, co może spowodować krótkie zakłócenia w działaniu określonych modułów BMM.

Czas wymagany do ukończenia każdej z tych akcji jest podobny. Ponowne uruchamianie jest najszybsze, podczas gdy wymiana trwa nieco dłużej. Wszystkie trzy akcje są prostymi i wydajnymi metodami rozwiązywania problemów.

Wymagania wstępne

• Zapoznaj się z możliwościami, do których odwołuje się ten artykuł, przeglądając akcje programu BMM.
• Zbierz następujące informacje (niezbędne dla wszystkich akcji):
  • Nazwa zarządzanej grupy zasobów dla programu BMM
  • Nazwa programu BMM, który wymaga operacji zarządzania cyklem życia
  • Identyfikator subskrypcji
• Stan szczegółowy klastra musi mieć wartość Running
• Łączność między klastrem a menedżerem klastra musi być Connected

Identyfikowanie akcji naprawczej

Podczas rozwiązywania problemów z programem BMM pod kątem błędów i określania najbardziej odpowiednich działań naprawczych niezbędne jest zrozumienie dostępnych opcji. Ten artykuł zawiera systematyczne podejście do rozwiązywania problemów z serwerem Nexus operatora platformy Azure przy użyciu następujących trzech metod:

• Ponowne uruchomienie — najmniej inwazyjna metoda, najlepsza dla tymczasowych usterek lub nieodpowiadające maszyny wirtualne
• Reimage — rozwiązanie pośrednie przywraca system operacyjny do znanego dobrego stanu bez wpływu na dane
• Zastąp — najbardziej znacząca akcja, wymagana w przypadku awarii składników sprzętowych, takich jak pamięć RAM, dysk twardy itp. Zastąp akcję należy użyć po zastąpieniu składników programu BMM.

Drzewo decyzyjne do rozwiązywania problemów

Postępuj zgodnie z tą ścieżką eskalacji podczas rozwiązywania problemów z programem BMM:

Zalecanym podejściem jest rozpoczęcie od najmniej inwazyjnego rozwiązania (ponownego uruchomienia) i eskalacji do bardziej złożonych środków tylko w razie potrzeby. Zawsze sprawdzaj, czy problem został rozwiązany po każdej akcji naprawczej.

Rozwiązywanie problemów z akcją ponownego uruchamiania

Ponowne uruchomienie programu BMM to proces ponownego uruchamiania serwera za pomocą prostego wywołania interfejsu API. Ta akcja może być przydatna w przypadku rozwiązywania problemów, gdy maszyny wirtualne najemcy na hoście nie reagują lub są w jakikolwiek sposób zablokowane.

Ponowne uruchomienie zazwyczaj jest punktem wyjścia do rozwiązania problemu.

Uruchom ponownie przepływ pracy

1. Ocena wpływu — określ, czy ponowne uruchomienie programu BMM ma wpływ na krytyczne obciążenia.
2. Wyłącz — w razie potrzeby wyłącz program BMM (opcjonalnie).
3. Uruchom lub uruchom ponownie — uruchom wyłączony program BMM lub uruchom ponownie uruchomiony program BMM.
4. Sprawdź stan — sprawdź , czy program BMM wraca do trybu online i działa prawidłowo.

power-off

az networkcloud baremetalmachine power-off \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

start

az networkcloud baremetalmachine start \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

restart

az networkcloud baremetalmachine restart \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

Aby sprawdzić stan programu BMM po ponownym uruchomieniu:

az networkcloud baremetalmachine show \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID> \
  --query "provisioningState"

Wynik Succeeded wskaże, że polecenie zostało ukończone.

Rozwiązywanie problemów z akcją z obrazem

Ponowne wyobrażanie sobie programu BMM to proces używany do ponownego wdrażania obrazu na dysku systemu operacyjnego bez wpływu na dane dzierżawy. Ta akcja wykonuje kroki ponownego dołączania klastra z tymi samymi identyfikatorami.

Akcja z obrazu może być przydatna do rozwiązywania problemów przez przywrócenie systemu operacyjnego do znanego dobrego stanu pracy. Typowe przyczyny, które można rozwiązać za pomocą utworzenia nowego obrazu, obejmują odzyskiwanie z powodu wątpliwości co do integralności hosta, podejrzenie lub potwierdzenie naruszenia zabezpieczeń lub "break glass" operację zapisu.

Akcja reimage jest najlepszym rozwiązaniem dla najniższego ryzyka operacyjnego, aby zapewnić integralność programu BMM.

Przepływ pracy dotyczący odtworzenia obrazu dysku

1. Sprawdź uruchomione obciążenia — przed ponownym obrazowaniem sprawdź, jakie obciążenia są uruchomione na maszynie BMM.
2. Cordon i ewakuuj zadania — przekierowanie zadań z BMM.
3. Wykonaj reimage — wykonaj operację reimage.
4. Uncordon: Umożliwienie ponownego planowania BMM po zakończeniu reimage.

Aby określić, czy jakiekolwiek obciążenia są obecnie uruchomione w programie BMM, uruchom następujące polecenie:

W przypadku maszyn wirtualnych:

az networkcloud baremetalmachine show -n <nodeName> \
--resource-group <resourceGroup> \
--subscription <subscriptionID> | jq '.virtualMachinesAssociatedIds'

W przypadku węzłów klastra Nexus Kubernetes: (wymaga zalogowania się do klastra Nexus Kubernetes)

kubectl get nodes <resourceName> -ojson |jq '.metadata.labels."topology.kubernetes.io/baremetalmachine"'

Następujące polecenie interfejsu wiersza polecenia platformy Azure spowoduje cordon , że określony parametr bareMetalMachineName.

az networkcloud baremetalmachine cordon \
  --evacuate "True" \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

Następujące polecenie interfejsu wiersza polecenia platformy Azure spowoduje reimage , że określony parametr bareMetalMachineName.

az networkcloud baremetalmachine reimage \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

Następujące polecenie interfejsu wiersza polecenia platformy Azure spowoduje uncordon , że określony parametr bareMetalMachineName.

az networkcloud baremetalmachine uncordon \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

Aby sprawdzić stan BMM po reimage:

az networkcloud baremetalmachine show \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID> \
  --query "provisioningState"

Wynik pokaże Succeeded , że program BMM został aprowizowany i ponownie dołączył do klastra.

Rozwiązywanie problemów z akcją zamieniania

Serwery zawierają wiele składników fizycznych, które mogą zakończyć się niepowodzeniem w czasie. Ważne jest, aby zrozumieć, które naprawy fizyczne wymagają wymiany modułu BMM i kiedy zaleca się jego wymianę. Dane dzierżawy nie są modyfikowane podczas zastępowania, pod warunkiem że używana jest flaga storage-policy="Preserve".

Wywoływany jest proces weryfikacji sprzętu w celu zapewnienia integralności hosta fizycznego przed wdrożeniem obrazu systemu operacyjnego.

Ten artykuł zawiera omówienie procesu weryfikacji sprzętu — omówienie weryfikacji sprzętu

Ten artykuł zawiera instrukcje dotyczące sprawdzania i rozwiązywania problemów z wynikami sprawdzania poprawności sprzętu

Zamień przepływ pracy

1. Cordon i ewakuacja — usuń obciążenia robocze z systemu BMM przed naprawą fizyczną.
2. Wykonaj naprawy fizyczne — w razie potrzeby zastąp składniki sprzętowe.
3. Wykonaj polecenie replace — uruchom polecenie replace z wymaganymi parametrami.
4. Uncordon — uczynić BMM ponownie planyzowalnym po zakończeniu wymiany.
5. Sprawdź stan — sprawdź, czy program BMM działa prawidłowo.

Następujące polecenie interfejsu wiersza polecenia platformy Azure spowoduje cordon , że określony parametr bareMetalMachineName.

az networkcloud baremetalmachine cordon \
  --evacuate "True" \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

Przewodnik wymiany składników sprzętowych

Podczas przeprowadzania fizycznej naprawy zasilacza z możliwością wymiany na gorąco akcja wymiany nie jest wymagana, ponieważ host BMM będzie nadal działać normalnie po naprawie.

Podczas wykonywania następujących napraw fizycznych zalecamy wykonanie akcji zamiany, chociaż nie jest konieczne przywrócenie programu BMM z powrotem do usługi:

• CPU
• Moduł pamięci DIMM (Dual In-Line Memory Module)
• Wentylator
• Karta rozszerzeń z podnośnikiem
• Nadajnik-odbiornik
• Wymiana kabla ethernetowego lub światłowodowego

Podczas wykonywania następujących napraw fizycznych wymagana jest akcja zamiany, aby przywrócić program BMM do usługi:

• Płyta główna
• Tablica systemowa
• dysk SSD
• Adapter PERC/RAID
• Karta interfejsu sieciowego Mellanox (NIC)
• Osadzona karta sieciowa Broadcom

Po zakończeniu napraw fizycznych sprawdź, czy wszystkie wersje oprogramowania układowego są zgodne z wersjami obsługiwanymi dla odpowiedniego środowiska uruchomieniowego. Zastosuj te same testy najlepszych rozwiązań używane podczas wdrażania, aby upewnić się, że składniki spełniają minimalne wymagania dotyczące oprogramowania układowego.

Po zakończeniu sprawdzania oprogramowania układowego przystąp do wymiany.

Następujące polecenie interfejsu wiersza polecenia platformy Azure spowoduje replace , że określony parametr bareMetalMachineName.

az networkcloud baremetalmachine replace \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --bmc-credentials password=<IDRAC_PASSWORD> username=<IDRAC_USER> \
  --bmc-mac-address <IDRAC_MAC> \
  --boot-mac-address <PXE_MAC> \
  --machine-name <OS_HOSTNAME> \
  --serial-number <SERIAL_NUM> \
  --subscription <subscriptionID> \
  --storage-policy <STORAGE_POLICY>

Następujące polecenie interfejsu wiersza polecenia platformy Azure spowoduje anulowaniekordonu określonego bareMetalMachineName.

az networkcloud baremetalmachine uncordon \
  --name <bareMetalMachineName> \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID>

Aby sprawdzić stan BMM po replace:

az networkcloud baremetalmachine show \
  --name <bareMetalMachineName>  \
  --resource-group "<resourceGroup>" \
  --subscription <subscriptionID> \
  --query "provisioningState"

Wynik pokaże Succeeded , że program BMM został aprowizowany i ponownie dołączył do klastra.

Podsumowanie

Ponowne uruchamianie, ponowne przywracanie obrazu i zastępowanie to skuteczne metody rozwiązywania problemów z serwerem Azure Operator Nexus. Oto krótki przewodnik informacyjny:

Najlepsze rozwiązania

• Zawsze postępuj zgodnie ze ścieżką eskalacji: Zacznij od ponownego uruchomienia, potem obrazuj, a następnie wymień, chyba że problem wyraźnie wskazuje inaczej.
• Sprawdź obciążenia przed akcją: użyj podanych poleceń, aby zidentyfikować uruchomione obciążenia przed wszelkimi działaniami zakłócaczymi.
• Cordon z ewakuacją: podczas wykonywania reimage lub zastępowania akcji zawsze używaj polecenia cordon , evacuate="True" aby bezpiecznie przenosić obciążenia.
• Nigdy nie uruchamiaj wielu operacji jednocześnie: upewnij się, że jedna operacja została ukończona przed uruchomieniem innego, aby zapobiec problemom z serwerem.
• Sprawdź rozwiązanie: po wykonaniu dowolnej akcji sprawdź stan programu BMM i czy oryginalny problem został rozwiązany.

Więcej szczegółów na temat akcji programu BMM można znaleźć w artykule Dotyczącym akcji programu BMM.

Jeśli nadal masz pytania, skontaktuj się z pomocą techniczną. Aby uzyskać więcej informacji na temat planów pomocy technicznej, zobacz Plany pomocy technicznej platformy Azure.