StorageGRID 노드를 호스트에 복원합니다
변경 제안
PDF
실패한 그리드 노드를 새 Linux 호스트로 복원하려면 다음 단계를 수행하여 노드 구성 파일을 복원합니다.
-
노드 복원 및 유효성 검사 노드 구성 파일을 복원하여 수행합니다. 새 설치의 경우 호스트에 설치할 각 그리드 노드에 대한 노드 구성 파일을 생성합니다. 그리드 노드를 교체 호스트로 복원할 때는 장애가 발생한 그리드 노드의 노드 구성 파일을 복원하거나 교체합니다.
-
필요에 따라 시작에 실패한 노드를 복구합니다..
이전 호스트에서 블록 스토리지 볼륨이 보존된 경우 추가 복구 절차를 수행해야 할 수 있습니다. 이 섹션의 명령은 필요한 추가 절차를 확인하는 데 도움이 됩니다.
그리드 노드 복원 및 유효성 검사
장애가 발생한 그리드 노드에 대한 그리드 구성 파일을 복원한 다음, 그리드 구성 파일의 유효성을 검사하고 오류를 해결해야 합니다.
이전 호스트 장애로 인해 /var/local 볼륨이 손실되지 않은 한, 호스트에 있어야 하는 모든 그리드 노드를 가져올 수 있습니다. 예를 들어, Linux 운영 체제용 StorageGRID 설치 지침에 설명된 대로 StorageGRID 시스템 데이터 볼륨에 공유 스토리지를 사용한 경우 /var/local 볼륨이 여전히 존재할 수 있습니다. 노드를 가져오면 해당 노드의 구성 파일이 호스트에 복원됩니다.
누락된 노드를 가져올 수 없는 경우 해당 노드의 그리드 구성 파일을 다시 생성해야 합니다.
그런 다음 그리드 구성 파일을 검증하고, StorageGRID를 다시 시작하기 전에 발생할 수 있는 네트워킹 또는 스토리지 문제를 해결해야 합니다. 노드에 대한 구성 파일을 다시 생성할 때는 복구하려는 노드에 사용했던 것과 동일한 이름을 대체 노드에 사용해야 합니다.
"Linux 설치 지침"에서 노드의 /var/local 볼륨 위치에 대한 자세한 내용을 확인하십시오.
-
복구된 호스트의 명령줄에서 현재 구성된 모든 StorageGRID 노드를 나열합니다.
sudo storagegrid node list그리드 노드가 구성되지 않은 경우 출력이 없습니다. 그리드 노드가 구성된 경우 다음과 같은 형식으로 출력이 표시됩니다.
Name Metadata-Volume ================================================================ dc1-adm1 /dev/mapper/sgws-adm1-var-local dc1-gw1 /dev/mapper/sgws-gw1-var-local dc1-sn1 /dev/mapper/sgws-sn1-var-local dc1-arc1 /dev/mapper/sgws-arc1-var-local
호스트에 구성되어야 하는 그리드 노드 중 일부 또는 전부가 목록에 표시되지 않으면 누락된 그리드 노드를 복원해야 합니다.
-
/var/local볼륨이 있는 그리드 노드를 가져오려면:-
가져오려는 각 노드에 대해 다음 명령을 실행하십시오.
sudo storagegrid node import node-var-local-volume-path이
storagegrid node import명령은 대상 노드가 마지막으로 실행된 호스트에서 정상적으로 종료된 경우에만 성공합니다. 그렇지 않은 경우 다음과 유사한 오류가 발생합니다.This node (node-name) appears to be owned by another host (UUID host-uuid).
Use the --force flag if you are sure import is safe.-
노드가 다른 호스트에 의해 소유되었다는 오류가 표시되면
--force플래그를 사용하여 가져오기를 완료하기 위해 명령을 다시 실행하십시오:sudo storagegrid --force node import node-var-local-volume-path
--force플래그를 사용하여 가져온 노드는 "다음 단계: 필요한 경우 추가 복구 단계를 수행하십시오."에 설명된 대로 그리드에 다시 참여하기 전에 추가 복구 단계를 거쳐야 합니다.
-
-
/var/local볼륨이 없는 그리드 노드의 경우, 노드의 구성 파일을 다시 생성하여 호스트에 복원하십시오. 지침은 "노드 구성 파일 생성"을 참조하십시오.
노드의 구성 파일을 다시 생성할 때는 복구하려는 노드에 사용했던 것과 동일한 이름을 대체 노드에 사용해야 합니다. Linux 배포 환경의 경우 구성 파일 이름에 노드 이름이 포함되어 있는지 확인하십시오. 가능하면 동일한 네트워크 인터페이스, 블록 장치 매핑 및 IP 주소를 사용하는 것이 좋습니다. 이렇게 하면 복구 중에 노드에 복사해야 하는 데이터 양이 최소화되어 복구 속도가 크게 향상될 수 있습니다(경우에 따라 몇 주가 아닌 몇 분 만에 복구 가능).
노드의 구성 파일을 다시 생성할 때 `BLOCK_DEVICE_`로 시작하는 구성 변수의 값으로 새 블록 장치(StorageGRID 노드에서 이전에 사용하지 않았던 장치)를 사용하는 경우, 누락된 블록 장치 오류 수정의 지침을 따르십시오. -
복구된 호스트에서 다음 명령을 실행하여 모든 StorageGRID 노드를 나열하십시오.
sudo storagegrid node list -
storagegrid node list 출력에 이름이 표시된 각 그리드 노드의 노드 구성 파일을 검증합니다.
sudo storagegrid node validate node-nameStorageGRID 호스트 서비스를 시작하기 전에 모든 오류 또는 경고를 해결해야 합니다. 다음 섹션에서는 복구 중에 특히 중요할 수 있는 오류에 대한 자세한 내용을 제공합니다.
누락된 네트워크 인터페이스 오류 수정
호스트 네트워크가 올바르게 구성되지 않았거나 이름이 잘못 입력된 경우, StorageGRID가 /etc/storagegrid/nodes/node-name.conf 파일에 지정된 매핑을 확인할 때 오류가 발생합니다.
다음과 같은 오류 또는 경고 메시지가 표시될 수 있습니다.
Checking configuration file /etc/storagegrid/nodes/<node-name>.conf for node <node-name>...
ERROR: <node-name>: GRID_NETWORK_TARGET = <host-interface-name>
<node-name>: Interface <host-interface-name>' does not exist
이 오류는 그리드 네트워크, 관리 네트워크 또는 클라이언트 네트워크에서 발생할 수 있습니다. 이 오류는 /etc/storagegrid/nodes/node-name.conf 파일이 지정된 StorageGRID 네트워크를 `host-interface-name`라는 호스트 인터페이스에 매핑하지만 현재 호스트에 해당 이름의 인터페이스가 없음을 의미합니다.
이 오류가 발생하는 경우, "새 Linux 호스트 배포"에 제시된 단계를 모두 완료했는지 확인하십시오. 모든 호스트 인터페이스에 원래 호스트에서 사용했던 것과 동일한 이름을 사용하십시오.
호스트 인터페이스 이름을 노드 구성 파일과 일치하도록 지정할 수 없는 경우, 노드 구성 파일을 편집하여 GRID_NETWORK_TARGET, ADMIN_NETWORK_TARGET 또는 CLIENT_NETWORK_TARGET 값을 기존 호스트 인터페이스와 일치하도록 변경할 수 있습니다.
호스트 인터페이스가 적절한 물리적 네트워크 포트 또는 VLAN에 대한 액세스를 제공하고, 인터페이스가 본드 또는 브리지 장치를 직접 참조하지 않는지 확인하십시오. 호스트에서 본드 장치 위에 VLAN(또는 다른 가상 인터페이스)을 구성하거나 브리지와 가상 이더넷(veth) 쌍을 사용해야 합니다.
누락된 블록 장치 오류 수정
이 시스템은 복구된 각 노드가 유효한 블록 장치 특수 파일 또는 블록 장치 특수 파일에 대한 유효한 소프트링크에 매핑되는지 확인합니다. StorageGRID가 /etc/storagegrid/nodes/node-name.conf 파일에서 유효하지 않은 매핑을 발견하면 블록 장치 누락 오류가 표시됩니다.
다음과 같은 패턴의 오류가 발생한 경우:
Checking configuration file /etc/storagegrid/nodes/<node-name>.conf for node <node-name>...
ERROR: <node-name>: BLOCK_DEVICE_PURPOSE = <path-name>
<node-name>: <path-name> does not exist
이는 `/etc/storagegrid/nodes/node-name.conf`이 _node-name_이 사용하는 블록 장치를 `PURPOSE`에 대해 Linux 파일 시스템의 지정된 경로 이름에 매핑하지만, 해당 위치에 유효한 블록 장치 특수 파일이나 블록 장치 특수 파일에 대한 소프트링크가 없음을 의미합니다.
"새 Linux 호스트 배포"의 단계를 완료했는지 확인하십시오. 모든 블록 장치에 대해 원래 호스트에서 사용했던 것과 동일한 영구 장치 이름을 사용하십시오.
누락된 블록 장치 특수 파일을 복원하거나 다시 생성할 수 없는 경우, 적절한 크기와 스토리지 범주를 가진 새 블록 장치를 할당하고 노드 구성 파일을 편집하여 `BLOCK_DEVICE_PURPOSE`의 값이 새 블록 장치 특수 파일을 가리키도록 변경할 수 있습니다.
Linux 운영 체제에 맞는 적절한 크기와 스토리지 범주를 확인하려면 표를 참조하십시오. "스토리지 및 성능 요구 사항"을 참조하십시오.
"호스트 스토리지 구성"에 대한 권장 사항을 검토한 후 블록 장치 교체를 진행하십시오.
|
|
원래 블록 장치가 장애가 발생한 호스트와 함께 손실되어 `BLOCK_DEVICE_`로 시작하는 구성 파일 변수에 새 블록 스토리지 장치를 제공해야 하는 경우, 추가 복구 절차를 시도하기 전에 새 블록 장치가 포맷되지 않은 상태인지 확인하십시오. 공유 스토리지를 사용하고 새 볼륨을 생성한 경우 새 블록 장치는 포맷되지 않은 상태입니다. 확실하지 않은 경우 새 블록 스토리지 장치 특수 파일에 대해 다음 명령을 실행하십시오. |
|
다음 명령은 새 블록 스토리지 장치에 대해서만 실행하십시오. 복구 중인 노드에 대한 유효한 데이터가 블록 스토리지에 여전히 남아 있다고 판단되는 경우에는 이 명령을 실행하지 마십시오. 장치에 있는 모든 데이터가 손실됩니다.
|
StorageGRID 호스트 서비스 시작
StorageGRID 노드를 시작하고 호스트 재부팅 후에도 노드가 다시 시작되도록 하려면 StorageGRID 호스트 서비스를 활성화하고 시작해야 합니다.
-
각 호스트에서 다음 명령을 실행하십시오.
sudo systemctl enable storagegrid sudo systemctl start storagegrid
-
배포가 제대로 진행되고 있는지 확인하려면 다음 명령을 실행하십시오.
sudo storagegrid node status node-name
-
어떤 노드라도 상태가 "Not Running" 또는 "Stopped"로 표시되면 다음 명령을 실행하십시오.
sudo storagegrid node start node-name
-
이전에 StorageGRID 호스트 서비스를 활성화하고 시작한 경우(또는 서비스가 활성화되고 시작되었는지 확실하지 않은 경우) 다음 명령도 실행하십시오.
sudo systemctl reload-or-restart storagegrid
정상적으로 시작되지 않는 노드 복구
StorageGRID 노드가 정상적으로 그리드에 다시 참여하지 못하고 복구 가능한 상태로 표시되지 않으면 노드가 손상되었을 수 있습니다. 이 경우 노드를 강제로 복구 모드로 전환할 수 있습니다.
-
노드의 네트워크 구성이 올바른지 확인하십시오.
노드가 그리드에 다시 연결되지 못한 이유는 잘못된 네트워크 인터페이스 매핑이나 잘못된 그리드 네트워크 IP 주소 또는 게이트웨이 때문일 수 있습니다.
-
네트워크 구성이 올바르면 다음
force-recovery명령을 실행하십시오.sudo storagegrid node force-recovery node-name -
노드에 대한 추가 복구 단계를 수행하십시오. "다음 단계: 필요한 경우 추가 복구 단계를 수행하십시오."을 참조하십시오.