Řešení potíží se serverem Nexus operátora Azure

  • Článek

Tento článek popisuje, jak řešit potíže se serverem pomocí restartování, opětovného sestavení a nahrazení akcí na holých počítačích Azure Operator Nexus. Tyto akce možná budete muset provést na serveru z důvodů údržby, což způsobí krátké přerušení konkrétních BMM.

Doba potřebná k dokončení každé z těchto akcí je podobná. Restartování je nejrychlejší, zatímco nahrazení trvá trochu déle. Všechny tři akce jsou jednoduché a efektivní metody pro řešení potíží.

Upozornění

Neprovádějte žádnou akci se servery pro správu bez první konzultace s pracovníky podpory Microsoftu. To by mohlo ovlivnit integritu clusteru Operátor Nexus.

Požadavky

  • Seznamte se s možnostmi odkazovanými v tomto článku tím , že si prohlédněte akce BMM.
  • Shromážděte následující informace:
    • Název skupiny prostředků pro BMM
    • Název nástroje BMM, který vyžaduje operaci správy životního cyklu

Důležité

Rušivé požadavky příkazů na uzel řídicí roviny Kubernetes (KCP) jsou odmítnuty, pokud je na jiném uzlu KCP spuštěn jiný příkaz rušivé akce nebo pokud není k dispozici úplný KCP.

Restartování, opětovné vytvoření a nahrazení se považují za rušivé akce.

Tato kontrola se provádí, aby se zachovala integrita instance Nexus a zajistilo, že několik uzlů KCP nefunguje najednou kvůli souběžným rušivým akcím. Pokud dojde ke snížení počtu uzlů, rozdělí se prahová hodnota kvora v pořádku řídicí roviny Kubernetes.

Identifikace opravné akce

Při řešení potíží s nástrojem BMM pro selhání a určením nejlepší nápravné akce je důležité porozumět dostupným možnostem. Restartování nebo opětovné vytvoření nástroje BMM může být efektivním a efektivním způsobem, jak opravit problémy nebo obnovit software na známé místo. Při selhání jedné nebo více hardwarových komponent na serveru může být vyžadováno nahrazení nástroje BMM. Tento článek obsahuje pokyny k osvědčeným postupům pro každou ze tří akcí.

Řešení technických problémů vyžaduje systematický přístup. Jednou z účinných metod je začít s nejméně invazivním roztokem a v případě potřeby pracujete na složitějších a drastických opatřeních.

Prvním krokem při řešení potíží je často pokus o restartování zařízení nebo systému. Restartování může pomoct vymazat všechny dočasné chyby nebo chyby, které můžou být příčinou problému. Pokud restartování problém nevyřeší, může být dalším krokem pokus o opětovné sestavení zařízení nebo systému.

Pokud reimaging problém nevyřeší, může poslední krok nahradit vadnou hardwarovou komponentu. Nahrazení může být výraznější, ale může být nutné, pokud problém souvisí s chybou hardwaru.

Mějte na paměti, že tyto metody řešení potíží nemusí být vždy efektivní a jiné faktory, které hrají, můžou vyžadovat jiný přístup.

Řešení potíží s akcí restartování

Restartování BMM je proces restartování serveru prostřednictvím jednoduchého volání rozhraní API. Tato akce může být užitečná při řešení potíží, když virtuální počítače tenanta na hostiteli nereagují nebo jsou jinak zablokované.

Restartování je obvykle výchozím bodem pro zmírnění problému.

Řešení potíží s akcí opětovného vytvoření image

Opětovné nasazení nástroje BMM je proces, který použijete k opětovnému nasazení image na disk s operačním systémem, aniž by to mělo vliv na data tenanta. Tato akce provede kroky pro opětovné připojení clusteru se stejnými identifikátory.

Akce opětovného sestavení může být užitečná pro řešení problémů obnovením operačního systému do známého funkčního stavu. Mezi běžné příčiny, které je možné vyřešit opětovným nastavením, patří obnovení z důvodu pochybností o integritě hostitele, podezření nebo potvrzeného ohrožení zabezpečení nebo aktivitě zápisu break glass.

Akce opětovného vytvoření je osvědčeným postupem pro nejnižší provozní riziko, aby se zajistila integrita nástroje BMM.

Řešení potíží s akcí nahrazení

Servery obsahují mnoho fyzických komponent, které můžou převzít služby při selhání v průběhu času. Je důležité pochopit, které fyzické opravy vyžadují nahrazení BMM, a pokud se doporučuje nahrazení BMM, ale nevyžaduje se.

Vyvolá se proces ověření hardwaru, který zajistí integritu fyzického hostitele před nasazením image operačního systému. Podobně jako akce opětovného vytvoření image se data tenanta během výměny nezmění.

Důležité

Počínaje verzí rozhraní GA API z 2024-07-01 se řadič RAID resetuje během výměny BMM a vymaže všechna data z virtuálních disků serveru. Výstrahy virtuálního disku řadiče pro správu základní desky aktivované během nahrazení BMM je možné ignorovat, pokud nejsou k dispozici výstrahy řadičů RAID nebo fyzických disků additonal.

Osvědčeným postupem je nejprve vydat cordon příkaz k odebrání holého počítače z plánování úloh a vypnutí nástroje BMM před fyzickými opravami.

Když provádíte opravu fyzického vyměnitelného napájecího zdroje za provozu, není potřeba provést akci nahrazení, protože hostitel BMM bude po opravě dál normálně fungovat.

Při provádění následujících fyzických oprav doporučujeme akci nahrazení, i když není nutné vrátit nástroj BMM zpět do provozu:

  • Procesor
  • Dvouřádkové paměťové moduly (DIMM)
  • Fanoušek
  • Expanzní deskový zvedač
  • Vysílač s přijímačem
  • Výměna ethernetového nebo optického kabelu

Při provádění následujících fyzických oprav se k vrácení nástroje BMM zpět do provozu vyžaduje akce nahrazení:

  • Propojovací rovina
  • Systémová deska
  • Disk SSD
  • Adaptér PERC/RAID
  • Síťová karta Mellanox (NIC)
  • Integrovaná síťová karta Broadcom

Shrnutí

Restartování, opětovné nahrazování a nahrazování jsou efektivní metody řešení potíží, které můžete použít k řešení technických problémů. Je však důležité mít systematický přístup a zvážit další faktory, než vyzkoušíte nějaká drastická opatření. Další podrobnosti o akcích BMM najdete v článku akcí BMM.

Pokud máte stále dotazy, obraťte se na podporu. Další informace o plánech podpory najdete v tématu Plány podpory Azure.