Reparera en nod på Azure Local
Gäller för: Azure Local 2311.2 och senare
Den här artikeln beskriver hur du reparerar en nod på din lokala Azure-instans. I den här artikeln kallas varje server för en nod.
Om reparationsnoder
Azure Local är ett hyperkonvergerat system som gör att du kan reparera noder från befintliga system. Du kan behöva reparera en nod i ett system om det uppstår ett maskinvarufel.
Innan du reparerar en nod kontrollerar du med din lösningsleverantör vilka komponenter på noden som är fältersättningsenheter (FRUs) som du kan ersätta själv och vilka komponenter som kräver att en tekniker ersätter.
Delar som stöder frekvent växling kräver vanligtvis inte att du återskapar noden till skillnad från de icke-snabbväxbara komponenterna som moderkortet gör. Kontakta maskinvarutillverkaren för att avgöra vilka komponentbyten som skulle kräva att du återskapar noden. Mer information finns i Komponentersättning.
Reparera nodarbetsflöde
Följande flödesdiagram visar den övergripande processen för att reparera en nod.
*Noden kanske inte är i ett tillstånd där avstängning är möjlig eller nödvändig*
Följ dessa övergripande steg för att reparera en befintlig nod:
Stäng om möjligt den nod som du vill reparera. Beroende på nodens tillstånd kanske en avstängning inte är möjlig eller nödvändig.
Återskapa den nod som behöver repareras.
Kör reparationsnodåtgärden. Azure Stack HCI-operativsystemet, drivrutinerna och den inbyggda programvaran uppdateras som en del av reparationen.
Lagringen balanseras automatiskt om på den omskapade noden. Ombalansering av lagring är en uppgift med låg prioritet som kan köras i flera dagar beroende på antalet noder och den lagring som används.
Stödda scenarier
När du reparerar en nod återskapas en nod och den återgår till systemet med det tidigare namnet och konfigurationen.
Reparation av en enskild nod resulterar i en omdistribution med alternativet att spara datavolymerna. Endast systemvolymen tas bort och etableras nyligen under distributionen.
Viktigt!
Kontrollera att du alltid har säkerhetskopior för dina arbetsbelastningar och inte bara förlitar dig på systemets återhämtning. Detta är särskilt viktigt i scenarier med en nod.
Återhämtningsinställningar
I den här versionen utförs inte specifika uppgifter för en reparationsnodåtgärd på de arbetsbelastningsvolymer som du skapade efter distributionen. För en reparationsnodåtgärd återställs endast de nödvändiga infrastrukturvolymerna och arbetsbelastningsvolymerna och visas som klusterdelade volymer (CSV:er).
De andra arbetsbelastningsvolymerna som du skapade efter distributionen behålls fortfarande och du kan identifiera dessa volymer genom att köra cmdleten Get-VirtualDisk
. Du måste låsa upp volymen manuellt (om volymen har BitLocker aktiverat) och skapa en CSV (om det behövs).
Maskinvarukrav
När du reparerar en nod verifierar systemet maskinvaran för den nya inkommande noden och ser till att noden uppfyller maskinvarukraven innan den läggs till i systemet.
Komponent | Efterlevnadskontroll |
---|---|
Processor | Verifiera att den nya noden har samma antal eller fler CPU-kärnor. Om CPU-kärnorna på den inkommande noden inte uppfyller detta krav visas en varning. Åtgärden är dock tillåten. |
Minne | Kontrollera att den nya noden har samma mängd eller mer minne installerat. Om minnet på den inkommande noden inte uppfyller det här kravet visas en varning. Åtgärden är dock tillåten. |
Drivrutiner | Kontrollera att den nya noden har samma antal tillgängliga dataenheter för Lagringsutrymmen Direct. Om antalet enheter på den inkommande noden inte uppfyller detta krav rapporteras ett fel och åtgärden blockeras. |
Nodbyte
Du kan ersätta hela noden:
- Med en ny nod som har ett annat serienummer jämfört med den gamla noden.
- Med den aktuella noden när du har återskapat den.
Följande scenarier stöds vid nodbyte:
Node | Disk | Stöds |
---|---|---|
Ny nod | Nya diskar | Ja |
Ny nod | Aktuella diskar | Ja |
Aktuell nod (omskapad) | Aktuella diskar omformaterade ** | Nej |
Aktuell nod (omskapad) | Nya diskar | Ja |
Aktuell nod (omskapad) | Aktuella diskar | Ja |
**Diskar som har använts av Lagringsutrymmen Direct kräver korrekt rengöring. Omformatering räcker inte. Se hur du rensar enheter.
Viktigt!
Om du ersätter en komponent under nodreparationen behöver du inte ersätta eller återställa dataenheter. Om du ersätter en enhet eller återställer den identifieras inte enheten när noden ansluter till systemet.
Komponentersättning
I din lokala Azure-instans innehåller komponenter som inte kan växlas frekvent följande:
- Moderkort/baseboard management controller (BMC)/grafikkort
- Diskkontrollant/värdbusskort (HBA)/backplace
- Nätverkskort
- Grafikbearbetningsenhet
- Dataenheter (enheter som inte stöder snabbväxling, till exempel PCI-e-tilläggskort)
De faktiska ersättningsstegen för icke-snabbväxlingsbara komponenter varierar beroende på oem-maskinvaruleverantören (originalutrustningstillverkaren). Se OEM-leverantörens dokumentation om en nodreparation krävs för komponenter som inte kan bytas mot frekventa komponenter.
Förutsättningar
Innan du reparerar en nod måste du se till att:
-
AzureStackLCMUser
är aktiv i Active Directory. Mer information finns i Förbereda Active Directory. - Inloggad som
AzureStackLCMUser
eller en annan användare med motsvarande behörigheter. - Autentiseringsuppgifterna
AzureStackLCMUser
för har inte ändrats.
Om det behövs tar du den nod som du har identifierat för reparation offline. Följ stegen här:
Reparera en nod
I det här avsnittet beskrivs hur du reparerar en nod med PowerShell, övervakar åtgärdens Repair-Server
status och felsöker om det finns några problem.
Kontrollera att du har granskat förutsättningarna.
Följ de här stegen på den nod som du försöker reparera.
Logga in på Azure-portalen med behörigheter för Azure Stack HCI-administratörsrollen.
Gå till den resursgrupp som används för att distribuera din lokala Azure-instans. I resursgruppen identifierar du Azure Arc-datorresursen för den felaktiga nod som du vill reparera.
I Azure Arc-datorresursen går du till Inställningar > Lås. I den högra rutan visas ett resurslås.
Välj låset och välj sedan papperskorgsikonen för att ta bort låset.
På sidan Översikt i Azure Arc-datorresursen, i det högra fönstret, väljer du Ta bort. Den här åtgärden bör ta bort den felaktiga datornoden.
Installera operativsystemet och nödvändiga drivrutiner på den nod som du vill reparera. Följ stegen i Installera Azure Stack HCI-operativsystemet version 23H2.
Kommentar
Om du har distribuerat din lokala Azure-instans med anpassade lagrings-IP-adresser måste du manuellt tilldela IP-adresser till lagringsnätverkskorten när noden har reparerats.
Registrera noden med Arc. Följ stegen i Registrera med Arc och konfigurera behörigheter.
Kommentar
Du måste använda samma parametrar som de befintliga noderna för att registrera dig med Arc. Till exempel: Resursgruppsnamn, Region, Prenumeration och Klientorganisation.
Tilldela följande behörigheter till den reparerade noden:
- Azure Local Enhetshantering-roll
- Key Vault Secrets User Mer information finns i Tilldela behörigheter till noden.
Följ dessa steg på en annan nod som är medlem i samma lokala Azure-instans.
Om du kör en version före 2405.3 måste du köra följande kommando för att rensa filer som är i konflikt:
Get-ChildItem -Path "$env:SystemDrive\NugetStore" -Exclude Microsoft.AzureStack.Solution.LCMControllerWinService*,Microsoft.AzureStack.Role.Deployment.Service* | Remove-Item -Recurse -Force
Logga in på noden som redan är medlem i systemet med de autentiseringsuppgifter för domänanvändare som du angav under distributionen av systemet. Kör följande kommando för att reparera den inkommande noden:
$Cred = Get-Credential Repair-Server -Name "<Name of the new node>" -LocalAdminCredential $Cred
Kommentar
Nodnamnet måste vara NetBIOS-namnet. Parametern
LocalAdminCredential
som standard är det inbyggda administratörskontot som skapats av Windows OS-installationen.Anteckna åtgärds-ID:t som utdata från
Repair-Server
kommandot. Du använder detta senare för att övervaka förloppet för åtgärdenRepair-Server
.
Övervaka åtgärdens förlopp
Följ dessa steg för att övervaka förloppet för åtgärden lägg till nod:
Kör följande cmdlet och ange åtgärds-ID från föregående steg.
$ID = "<Operation ID>" Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID
När åtgärden är klar fortsätter ombalanseringsjobbet för bakgrundslagring att köras. Vänta tills lagringsombalanseringsjobbet har slutförts. Använd följande cmdlet för att verifiera förloppet för det här lagringsombalanseringsjobbet:
Get-VirtualDisk|Get-StorageJob
Om lagringsombalanseringsjobbet är klart returnerar cmdleten inte några utdata.
Återställningsscenarier
Följande återställningsscenarier och de rekommenderade åtgärdsstegen är tabulerade för att reparera en nod:
Beskrivning av scenario | Riskreducering | Stöds? |
---|---|---|
Det gick inte att reparera nodåtgärden. | Om du vill slutföra åtgärden undersöker du felet. Kör den misslyckade åtgärden igen med . Repair-Server -Rerun |
Ja |
Reparationsnodåtgärden lyckades delvis men måste börja med en ny installation av åtgärdssystemet. | I det här scenariot har orkestratorn (även kallat Livscykelhanteraren) redan uppdaterat sitt kunskapslager med den nya noden. Använd scenariot för reparationsnoden. | Ja |
Felsökning
Om det uppstår fel eller fel när du reparerar en nod kan du samla in utdata från felen i en loggfil.
Logga in med de autentiseringsuppgifter för domänanvändare som du angav under distributionen av systemet. Samla in problemet i loggfilerna.
Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt
Om du vill köra den misslyckade åtgärden igen använder du följande cmdlet:
Repair-Server -Rerun
Nästa steg
Läs mer om hur du lägger till en nod.