Naprawianie serwera w usłudze Azure Stack HCI w wersji 23H2
Dotyczy: Azure Stack HCI, wersja 23H2
W tym artykule opisano sposób naprawiania serwera w klastrze rozwiązania Azure Stack HCI.
Informacje o naprawie serwerów
Azure Stack HCI to hiperkonwergentny system, który umożliwia naprawę serwerów z istniejących klastrów. W przypadku awarii sprzętowej może być konieczne naprawienie serwera w klastrze.
Przed naprawą serwera upewnij się, że należy sprawdzić dostawcę rozwiązań, które składniki na serwerze są jednostkami zastępczymi pól (FRU), które można zastąpić samodzielnie i które składniki wymagają od technika wymiany.
Części, które obsługują wymianę gorącą, zwykle nie wymagają ponownego obrazu serwera w przeciwieństwie do składników, które nie można zamienić na gorąco, takich jak płyta główna. Skontaktuj się z producentem sprzętu, aby określić, które zamiany składników wymagają ponownego obrazu serwera. Aby uzyskać więcej informacji, zobacz Zastępowanie składników.
Naprawianie przepływu pracy serwera
Poniższy diagram przepływu przedstawia ogólny proces naprawy serwera.
*Serwer może nie znajdować się w stanie, w którym jest możliwe zamknięcie lub konieczne
Aby naprawić istniejący serwer, wykonaj następujące ogólne kroki:
Jeśli to możliwe, zamknij serwer, który chcesz naprawić. W zależności od stanu serwera zamknięcie może być niemożliwe lub konieczne.
Reimage serwera, który musi zostać naprawiony.
Uruchom operację naprawy serwera. System operacyjny, sterowniki i oprogramowanie układowe usługi Azure Stack HCI są aktualizowane w ramach operacji naprawy.
Magazyn jest automatycznie ponownie zrównoważony na serwerze z obrazem. Ponowne równoważenie magazynu to zadanie o niskim priorytcie, które może być uruchamiane przez wiele dni w zależności od liczby serwerów i używanego magazynu.
Obsługiwane scenariusze
Naprawianie serwera odtwarza obraz serwera i przywraca go z powrotem do klastra z poprzednią nazwą i konfiguracją.
Naprawienie pojedynczego serwera powoduje ponowne wdrożenie z opcją utrwalania woluminów danych. Tylko wolumin systemowy jest usuwany i nowo aprowizowany podczas wdrażania.
Ważne
Upewnij się, że zawsze masz kopie zapasowe dla obciążeń i nie polegaj tylko na odporności systemu. Jest to szczególnie krytyczne w scenariuszach z jednym serwerem.
Ustawienia odporności
W tej wersji na potrzeby naprawy operacji serwera określone zadania nie są wykonywane na woluminach obciążeń utworzonych po wdrożeniu. W przypadku operacji naprawy serwera tylko wymagane woluminy infrastruktury i woluminy obciążenia są przywracane i udostępniane jako udostępnione woluminy klastra (CSV).
Inne woluminy obciążenia utworzone po wdrożeniu są nadal zachowywane i można je odnaleźć, uruchamiając Get-VirtuaDisk
polecenie cmdlet. Należy ręcznie odblokować wolumin (jeśli wolumin ma włączoną funkcję BitLocker) i utworzyć wolumin CSV (w razie potrzeby).
Wymagania sprzętowe
Podczas naprawiania serwera system weryfikuje sprzęt nowego, przychodzącego serwera i zapewnia, że serwer spełnia wymagania sprzętowe przed dodaniu go do klastra.
Składnik | Sprawdzanie zgodności |
---|---|
Procesor CPU | Sprawdź, czy nowy serwer ma taką samą liczbę rdzeni procesora CPU lub więcej. Jeśli rdzenie procesora CPU w węźle przychodzącym nie spełniają tego wymagania, zostanie wyświetlone ostrzeżenie. Operacja jest jednak dozwolona. |
Pamięć | Sprawdź, czy nowy serwer ma zainstalowaną taką samą ilość pamięci lub więcej. Jeśli pamięć w węźle przychodzącym nie spełnia tego wymagania, zostanie wyświetlone ostrzeżenie. Operacja jest jednak dozwolona. |
Dyski | Sprawdź, czy nowy serwer ma taką samą liczbę dysków danych dostępnych dla usługi Miejsca do magazynowania Direct. Jeśli liczba dysków w węźle przychodzącym nie spełnia tego wymagania, zostanie zgłoszony błąd i operacja zostanie zablokowana. |
Wymiana serwera
Możesz zastąpić cały serwer:
- W przypadku nowego serwera, który ma inny numer seryjny w porównaniu ze starym serwerem.
- Po odtworzeniu obrazu bieżącego serwera.
Podczas zamiany serwera obsługiwane są następujące scenariusze:
Server (Serwer) | Disk | Obsługiwane |
---|---|---|
Nowy serwer | Nowe dyski | Tak |
Nowy serwer | Bieżące dyski | Tak |
Bieżący serwer (reimaged) | Bieżące dyski sformatowane * | Nie. |
Bieżący serwer (reimaged) | Nowe dyski | Tak |
Bieżący serwer (reimaged) | Bieżące dyski | Tak |
**Dyski używane przez Miejsca do magazynowania Direct wymagają odpowiedniego czyszczenia. Ponowne formatowanie nie jest wystarczające. Zobacz, jak czyścić dyski.
Ważne
Jeśli zastąpisz składnik podczas naprawy serwera, nie musisz zastępować ani resetować dysków danych. Jeśli zamienisz dysk lub zresetujesz go, dysk nie zostanie rozpoznany po dołączeniu serwera do klastra.
Wymiana składników
W klastrze Azure Stack HCI składniki niezamienne do wymiany zawierają następujące elementy:
- Kontroler zarządzania płytą główną/płytą główną (BMC)/karta wideo
- Kontroler dysku/karta magistrali hosta (HBA)/backplace
- Karta sieciowa
- Jednostka przetwarzania grafiki
- Dyski danych (dyski, które nie obsługują wymiany gorącej, na przykład karty dodatku PCI-e)
Rzeczywiste kroki wymiany składników, które nie można zamienić na gorąco, różnią się w zależności od dostawcy sprzętu producenta oryginalnego sprzętu (OEM). Zapoznaj się z dokumentacją dostawcy OEM, jeśli naprawa serwera jest wymagana w przypadku składników, które nie można zamienić na gorąco.
Wymagania wstępne
Przed naprawą serwera należy upewnić się, że:
AzureStackLCMUser
jest aktywny w usłudze Active Directory. Aby uzyskać więcej informacji, zobacz Przygotowywanie usługi Active Directory.- Zalogował się jako
AzureStackLCMUser
lub inny użytkownik z równoważnymi uprawnieniami. - Poświadczenia dla elementu
AzureStackLCMUser
nie zostały zmienione.
W razie potrzeby przełącz serwer zidentyfikowany do naprawy w trybie offline. Wykonaj kroki opisane tutaj:
Naprawianie serwera
W tej sekcji opisano, jak naprawić serwer przy użyciu programu PowerShell, monitorować stan Repair-Server
operacji i rozwiązywać problemy, jeśli występują jakieś problemy.
Upewnij się, że sprawdzono wymagania wstępne.
Wykonaj następujące kroki na serwerze, który próbujesz naprawić.
Zainstaluj system operacyjny i wymagane sterowniki. Wykonaj kroki opisane w temacie Instalowanie rozwiązania Azure Stack HCI w wersji 23H2.
Uwaga
Jeśli klaster używa dedykowanej intencji usługi ATC sieci dla magazynu i używasz niestandardowych adresów IP magazynu, należy skonfigurować adresy IP na kartach sieciowych magazynu przed uruchomieniem operacji Repair-Server. Jeśli klaster używa udostępnionej sieci atC intencji magazynu i innego typu ruchu, takiego jak obliczenia i zarządzanie, należy ręcznie skonfigurować adresy IP na wirtualnych kartach sieciowych magazynu po naprawie serwera.
Zarejestruj serwer w usłudze Arc. Wykonaj kroki opisane w temacie Rejestrowanie w usłudze Arc i konfigurowanie uprawnień.
Uwaga
Aby zarejestrować się w usłudze Arc, należy użyć tych samych parametrów co istniejące węzły. Na przykład: Nazwa grupy zasobów, Region, Subskrypcja i Tatant.
Przypisz następujące uprawnienia do naprawionego węzła:
- Rola Zarządzanie urządzeniami usługi Azure Stack HCI
- Aby uzyskać więcej informacji, zobacz Przypisywanie uprawnień do serwera.
Wykonaj następujące kroki na innym serwerze, który jest członkiem tego samego klastra usługi Azure Stack HCI.
Przed dodaniem serwera upewnij się, że został zaktualizowany token uwierzytelniania. Uruchom następujące polecenie:
Update-AuthenticationToken
Zaloguj się do serwera, który jest już członkiem klastra, przy użyciu poświadczeń użytkownika domeny podanych podczas wdrażania klastra. Uruchom następujące polecenie, aby naprawić serwer przychodzący:
$Cred = Get-Credential Repair-Server -Name "< Name of the new server>" -LocalAdminCredential $Cred
Uwaga
Nazwa serwera musi być nazwą NetBIOS.
Zanotuj identyfikator operacji jako dane wyjściowe polecenia
Repair-Server
. Ten krok będzie używany później do monitorowania postępuRepair-Server
operacji.
Uwaga
Jeśli klaster usługi Azure Stack HCI został wdrożony przy użyciu niestandardowych adresów IP magazynu, należy ręcznie przypisać adresy IP do kart sieciowych magazynu po naprawieniu serwera.
Monitorowanie postępu operacji
Aby monitorować postęp operacji dodawania serwera, wykonaj następujące kroki:
Uruchom następujące polecenie cmdlet i podaj identyfikator operacji z poprzedniego kroku.
$ID = "<Operation ID>" Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID
Po zakończeniu operacji zadanie ponownego równoważenia magazynu w tle będzie nadal działać. Poczekaj na zakończenie zadania ponownego równoważenia magazynu. Aby sprawdzić postęp tego zadania ponownego równoważenia magazynu, użyj następującego polecenia cmdlet:
Get-VirtualDisk|Get-StorageJob
Jeśli zadanie ponownego równoważenia magazynu zostanie ukończone, polecenie cmdlet nie zwróci danych wyjściowych.
Scenariusze odzyskiwania
Poniższe scenariusze odzyskiwania i zalecane kroki ograniczania ryzyka są tabelaryczne na potrzeby naprawy serwera:
Opis scenariusza | Czynności zapobiegawcze | Obsługiwane? |
---|---|---|
Operacja naprawy serwera nie powiodła się. | Aby ukończyć operację, zbadaj błąd. Uruchom ponownie operację, która zakończyła się niepowodzeniem przy użyciu polecenia Add-Server -Rerun . |
Tak |
Naprawa operacji serwera powiodła się częściowo, ale musiała rozpocząć od nowej instalacji systemu operacyjnego. | W tym scenariuszu orkiestrator (znany również jako Menedżer cyklu życia) zaktualizował już swój magazyn wiedzy o nowym serwerze. Użyj scenariusza naprawy serwera. | Tak |
Rozwiązywanie problemów
Jeśli wystąpią błędy lub błędy podczas naprawiania serwera, możesz przechwycić dane wyjściowe błędów w pliku dziennika.
Zaloguj się przy użyciu poświadczeń użytkownika domeny podanych podczas wdrażania klastra. Przechwyć problem w plikach dziennika.
Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt
Aby ponownie uruchomić operację, która zakończyła się niepowodzeniem, użyj następującego polecenia cmdlet:
Repair-Server -Rerun
Następne kroki
Dowiedz się więcej o sposobie dodawania serwera.