Azure Local 버전 23H2에서 노드 복구

아티클
12/18/2024

적용 대상: Azure Local, 버전 23H2

이 문서에서는 Azure 로컬 인스턴스에서 노드를 복구하는 방법을 설명합니다. 이 문서에서는 각 서버를 노드라고 합니다.

복구 노드 정보

Azure Local은 기존 시스템에서 노드를 복구할 수 있는 하이퍼 컨버지드 시스템입니다. 하드웨어 오류가 있는 경우 시스템의 노드를 복구해야 할 수 있습니다.

노드를 복구하기 전에 솔루션 공급자에게 확인해야 합니다. 노드의 구성 요소는 직접 대체할 수 있는 FRU(필드 교체 단위)이며 기술자가 교체해야 하는 구성 요소입니다.

핫 스왑을 지원하는 파트는 일반적으로 마더보드와 같이 핫스왑할 수 없는 구성 요소와 달리 노드를 이미지로 다시 설치할 필요가 없습니다. 노드를 이미지로 다시 설치해야 하는 구성 요소 교체를 확인하려면 하드웨어 제조업체에 문의하세요. 자세한 내용은 구성 요소 교체를 참조하세요.

노드 워크플로 복구

다음 흐름 다이어그램은 노드를 복구하는 전체 프로세스를 보여줍니다.

*노드가 종료가 가능하거나 필요한 상태가 아닐 수 있습니다*

기존 노드를 복구하려면 다음 개략적인 단계를 수행합니다.

가능하면 복구하려는 노드를 종료합니다. 노드의 상태에 따라 종료가 불가능하거나 필요하지 않을 수 있습니다.
복구해야 하는 노드를 이미지로 다시 설치합니다.
복구 노드 작업을 실행합니다. Azure Stack HCI 운영 체제, 드라이버 및 펌웨어는 복구 작업의 일부로 업데이트됩니다.

스토리지는 이미지 다시 설치 노드에서 자동으로 균형을 조정합니다. 스토리지 재조정은 노드 수 및 사용된 스토리지에 따라 며칠 동안 실행할 수 있는 낮은 우선 순위 작업입니다.

지원되는 시나리오

노드를 복구하면 노드가 이미지로 다시 설치되고 이전 이름과 구성을 사용하여 시스템에 다시 가져옵니다.

단일 노드를 복구하면 데이터 볼륨을 유지하는 옵션을 사용하여 다시 배포됩니다. 배포하는 동안 시스템 볼륨만 삭제되고 새로 프로비전됩니다.

Important

워크로드에 대한 백업이 항상 있고 시스템 복원력에만 의존하지 않는지 확인합니다. 이는 단일 노드 시나리오에서 특히 중요합니다.

복원력 설정

이 릴리스에서는 복구 노드 작업의 경우 배포 후에 만든 워크로드 볼륨에서 특정 작업이 수행되지 않습니다. 복구 노드 작업의 경우 필요한 인프라 볼륨 및 워크로드 볼륨만 복원되고 CSV(클러스터 공유 볼륨)로 표시됩니다.

배포 후 만든 다른 워크로드 볼륨은 계속 유지되며 cmdlet을 실행하여 이러한 볼륨을 Get-VirtualDisk 검색할 수 있습니다. 볼륨의 잠금을 수동으로 해제하고(볼륨에 BitLocker를 사용하도록 설정한 경우) CSV를 만들어야 합니다(필요한 경우).

하드웨어 요구 사항

노드를 복구할 때 시스템은 들어오는 새 노드의 하드웨어의 유효성을 검사하고 노드가 시스템에 추가되기 전에 하드웨어 요구 사항을 충족하는지 확인합니다.

구성 요소	규정 준수 확인
CPU	새 노드의 CPU 코어 수가 동일한지 확인합니다. 들어오는 노드의 CPU 코어가 이 요구 사항을 충족하지 않으면 경고가 표시됩니다. 그러나 작업은 허용됩니다.
메모리	새 노드에 설치된 메모리 양이 동일한지 확인합니다. 들어오는 노드의 메모리가 이 요구 사항을 충족하지 않으면 경고가 표시됩니다. 그러나 작업은 허용됩니다.
드라이브	새 노드에 저장소 공간 Direct에 사용할 수 있는 데이터 드라이브 수가 동일한지 확인합니다. 들어오는 노드의 드라이브 수가 이 요구 사항을 충족하지 않으면 오류가 보고되고 작업이 차단됩니다.

노드 교체

전체 노드를 바꿀 수 있습니다.

이전 노드와 다른 일련 번호가 있는 새 노드를 사용하는 경우
이미지로 다시 설치한 후 현재 노드를 사용하여

노드를 교체하는 동안 지원되는 시나리오는 다음과 같습니다.

Node	디스크	지원됨
새 노드	새 디스크	예
새 노드	현재 디스크	예
현재 노드(이미지 다시 설치)	현재 디스크 다시 포맷 **	아니요
현재 노드(이미지 다시 설치)	새 디스크	예
현재 노드(이미지 다시 설치)	현재 디스크	예

**저장소 공간 Direct에서 사용한 디스크에는 적절한 정리가 필요합니다. 서식을 다시 지정하는 것으로는 충분하지 않습니다. 드라이브를 정리하는 방법을 알아보세요.

Important

노드 복구 중에 구성 요소를 교체하는 경우 데이터 드라이브를 바꾸거나 다시 설정할 필요가 없습니다. 드라이브를 교체하거나 다시 설정하는 경우 노드가 시스템에 조인되면 드라이브가 인식되지 않습니다.

구성 요소 교체

Azure 로컬 인스턴스에서 핫스왑할 수 없는 구성 요소에는 다음 항목이 포함됩니다.

마더보드/BMC(베이스보드 관리 컨트롤러)/비디오 카드
디스크 컨트롤러/HBA(호스트 버스 어댑터)/백플레이스
네트워크 어댑터
그래픽 처리 장치
데이터 드라이브(PCI-e 애드인 카드처럼 핫 스왑을 지원하지 않는 드라이브)

핫스왑이 불가능한 구성 요소의 실제 교체 단계는 OEM(원래 장비 제조업체) 하드웨어 공급업체에 따라 달라집니다. 핫스왑이 불가능한 구성 요소에 노드 복구가 필요한 경우 OEM 공급업체의 설명서를 참조하세요.

필수 조건

노드를 복구하기 전에 다음을 확인해야 합니다.

AzureStackLCMUser Active Directory에서 활성화되어 있습니다. 자세한 내용은 Active Directory 준비를 참조 하세요.
동일한 사용 권한이 있는 다른 사용자 또는 다른 사용자로 AzureStackLCMUser 로그인합니다.
AzureStackLCMUser 아직 변경되지 않은 자격 증명입니다.

필요한 경우 오프라인으로 복구하기 위해 식별한 노드를 사용합니다. 다음 단계를 수행합니다.
1. 노드를 오프라인으로 전환하기 전에 노드가 정상인지 확인합니다.
2. 노드를 일시 중지하고 드레이닝합니다.
3. 노드를 종료합니다.

노드 복구

이 섹션에서는 PowerShell을 사용하여 노드를 복구하고, 작업 상태를 Repair-Server 모니터링하고, 문제가 있는 경우 문제를 해결하는 방법을 설명합니다.

필수 구성 요소를 검토했는지 확인합니다.

복구하려는 노드에서 다음 단계를 수행합니다.

Azure Portal에 Azure Stack HCI 관리자 역할 권한로그인합니다.
1. Azure 로컬 인스턴스를 배포하는 데 사용되는 리소스 그룹으로 이동합니다. 리소스 그룹에서 복구하려는 결함이 있는 노드에 대한 Azure Arc 머신 리소스를 식별합니다.
2. Azure Arc 컴퓨터 리소스의 설정 > 잠금으로 이동하세요. 오른쪽 창에 리소스 잠금이 표시됩니다.
3. 잠금을 선택한 다음 휴지통 아이콘을 선택하여 잠금을 삭제합니다.
4. Azure Arc 머신 리소스의 개요 페이지의 오른쪽 창에서 삭제선택합니다. 이 작업은 결함이 있는 컴퓨터 노드를 삭제해야 합니다.
복구하려는 노드에 운영 체제 및 필수 드라이버를 설치합니다. Azure Stack HCI 운영 체제 버전 23H2 설치의 단계를 따릅니다.

참고 항목

사용자 지정 스토리지 IP를 사용하여 Azure 로컬 인스턴스를 배포한 경우 노드를 복구한 후 스토리지 네트워크 어댑터에 IP를 수동으로 할당해야 합니다.
Arc에 노드를 등록합니다. Arc에 등록의 단계를 수행하고 사용 권한을 설정합니다.

참고 항목

Arc에 등록하려면 기존 노드와 동일한 매개 변수를 사용해야 합니다. 예를 들어 리소스 그룹 이름, 지역, 구독 및 테넌트입니다.
복구된 노드에 다음 권한을 할당합니다.
- Azure 로컬 장치 관리 역할
- Key Vault 비밀 사용자에 대한 자세한 내용은 노드에 권한 할당을 참조하세요.

동일한 Azure 로컬 인스턴스의 멤버인 다른 노드에서 다음 단계를 수행합니다.

2405.3 이전 버전을 실행하는 경우 다음 명령을 실행하여 충돌하는 파일을 정리해야 합니다.

Get-ChildItem -Path "$env:SystemDrive\NugetStore" -Exclude Microsoft.AzureStack.Solution.LCMControllerWinService*,Microsoft.AzureStack.Role.Deployment.Service* | Remove-Item -Recurse -Force

시스템 배포 중에 제공한 도메인 사용자 자격 증명을 사용하여 이미 시스템의 구성원인 노드에 로그인합니다. 다음 명령을 실행하여 들어오는 노드를 복구합니다.
```
$Cred = Get-Credential 
Repair-Server -Name "<Name of the new node>" -LocalAdminCredential $Cred
```
참고 항목

노드 이름은 NetBIOS 이름이어야 합니다. 기본적으로 LocalAdminCredential 매개 변수는 Windows OS 설치에서 만든 기본 제공 관리자 계정입니다.
명령의 출력으로 작업 ID를 기록해 둡 Repair-Server 니다. 나중에 이를 사용하여 작업의 진행률을 모니터링합니다 Repair-Server .

작업 진행률 모니터링

노드 추가 작업의 진행률을 모니터링하려면 다음 단계를 수행합니다.

다음 cmdlet을 실행하고 이전 단계의 작업 ID를 제공합니다.

$ID = "<Operation ID>" 
Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID

작업이 완료되면 백그라운드 스토리지 리밸런싱 작업이 계속 실행됩니다. 스토리지 리밸런스 작업이 완료되기를 기다립니다. 이 스토리지 리밸런싱 작업의 진행률을 확인하려면 다음 cmdlet을 사용합니다.
```
Get-VirtualDisk|Get-StorageJob
```
스토리지 리밸런스 작업이 완료되면 cmdlet은 출력을 반환하지 않습니다.

복구 시나리오

다음 복구 시나리오 및 권장 완화 단계는 노드 복구를 위해 테이블로 표시됩니다.

시나리오 설명	완화 방법	지원 여부
노드 복구 작업이 실패했습니다.	작업을 완료하려면 오류를 조사합니다. 를 사용하여 `Repair-Server -Rerun`실패한 작업을 다시 실행합니다.	예
노드 복구 작업이 부분적으로 성공했지만 새 운영 시스템 설치로 시작해야 했습니다.	이 시나리오에서는 오케스트레이터(수명 주기 관리자라고도 함)가 이미 새 노드로 기술 저장소를 업데이트했습니다. 복구 노드 시나리오를 사용합니다.	예

문제 해결

노드를 복구하는 동안 오류 또는 오류가 발생하는 경우 로그 파일에서 오류의 출력을 캡처할 수 있습니다.

시스템을 배포하는 동안 제공한 도메인 사용자 자격 증명으로 로그인합니다. 로그 파일에서 문제를 캡처합니다.
```
Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt
```
실패한 작업을 다시 실행하려면 다음 cmdlet을 사용합니다.
```
Repair-Server -Rerun
```

다음 단계

노드를 추가하는 방법에 대해 자세히 알아봅니다.

다음을 통해 공유