그리드 노드를 호스트에 복구합니다
변경 제안
PDF
장애가 발생한 그리드 노드를 새 Linux 호스트로 복원하려면 다음 단계를 수행하여 노드 구성 파일을 복원합니다.
-
노드를 복원 및 확인합니다 노드 구성 파일을 복구합니다. 새 설치의 경우 호스트에 설치할 각 그리드 노드에 대한 노드 구성 파일을 만듭니다. 그리드 노드를 대체 호스트로 복원할 때 장애가 발생한 모든 그리드 노드에 대한 노드 구성 파일을 복구하거나 교체합니다.
-
필요에 따라 시작하지 못한 노드를 복구합니다.
이전 호스트에서 보존한 블록 스토리지 볼륨이 있는 경우 추가 복구 절차를 수행해야 할 수 있습니다. 이 섹션의 명령을 사용하면 필요한 추가 절차를 결정할 수 있습니다.
그리드 노드 복원 및 검증
장애가 발생한 그리드 노드에 대해 그리드 구성 파일을 복원한 다음 그리드 구성 파일의 유효성을 검사하고 오류를 해결해야 합니다.
호스트에 있어야 하는 모든 그리드 노드를 가져올 수 있습니다(있는 경우) /var/local 이전 호스트에 장애가 발생하여 볼륨이 손실되지 않았습니다. 예를 들면, 입니다 /var/local Linux 운영 체제의 StorageGRID 설치 지침에 설명된 대로 StorageGRID 시스템 데이터 볼륨에 공유 스토리지를 사용한 경우에도 볼륨이 존재할 수 있습니다. 노드를 가져오면 해당 노드 구성 파일이 호스트에 복구됩니다.
누락된 노드를 가져올 수 없는 경우 그리드 구성 파일을 다시 생성해야 합니다.
그런 다음 그리드 구성 파일을 확인하고 StorageGRID를 다시 시작하기 전에 발생할 수 있는 네트워킹 또는 스토리지 문제를 해결해야 합니다. 노드에 대한 구성 파일을 다시 생성할 때 복구 중인 노드에 사용된 교체 노드에 대해 동일한 이름을 사용해야 합니다.
의 위치에 대한 자세한 내용은 설치 지침을 참조하십시오 /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볼륨을 생성한 후 노드의 구성 파일을 다시 생성하여 호스트에 복구합니다. 자세한 내용은 다음을 참조하십시오.-
"Ubuntu 또는 Debian용 노드 구성 파일을 만듭니다"
노드에 대한 구성 파일을 다시 생성할 때 복구 중인 노드에 사용된 교체 노드에 대해 동일한 이름을 사용해야 합니다. Linux 배포의 경우 구성 파일 이름에 노드 이름이 포함되어 있는지 확인합니다. 가능하면 동일한 네트워크 인터페이스, 블록 장치 매핑 및 IP 주소를 사용해야 합니다. 이러한 관행은 복구 중에 노드로 복사해야 하는 데이터 양을 최소화하여 복구 속도가 크게 향상되도록 합니다(경우에 따라 몇 주가 아닌 몇 분).
새 블록 디바이스(StorageGRID 노드에서 이전에 사용하지 않았던 디바이스)를 로 시작하는 구성 변수의 값으로 사용하는 경우 BLOCK_DEVICE_노드에 대한 구성 파일을 다시 생성할 때 의 지침을 따릅니다 누락된 블록 장치 오류를 수정합니다. -
복구된 호스트에서 다음 명령을 실행하여 모든 StorageGRID 노드를 나열합니다.
sudo storagegrid node list -
StorageGRID 노드 목록 출력에 이름이 표시된 각 그리드 노드에 대한 노드 구성 파일의 유효성을 검사합니다.
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에 대한 액세스를 제공하고 인터페이스가 Bond 또는 Bridge 장치를 직접 참조하지 않는지 확인합니다. 호스트의 연결 디바이스 위에 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" 또는 "Snapfed" 상태가 반환되면 다음 명령을 실행합니다.
sudo storagegrid node start node-name
-
이전에 StorageGRID 호스트 서비스를 설정 및 시작한 경우(또는 서비스가 활성화 및 시작되었는지 확실하지 않은 경우) 다음 명령을 실행합니다.
sudo systemctl reload-or-restart storagegrid
정상적으로 시작하지 못한 노드를 복구합니다
StorageGRID 노드가 그리드에 정상적으로 다시 연결되지 않고 복구 가능으로 표시되지 않으면 손상된 것일 수 있습니다. 노드를 복구 모드로 강제 전환할 수 있습니다.
-
노드의 네트워크 구성이 올바른지 확인합니다.
잘못된 네트워크 인터페이스 매핑이나 잘못된 그리드 네트워크 IP 주소 또는 게이트웨이로 인해 노드가 그리드에 다시 연결되지 않았을 수 있습니다.
-
네트워크 구성이 올바른 경우 를 실행합니다
force-recovery명령:sudo storagegrid node force-recovery node-name -
노드에 대해 추가 복구 단계를 수행합니다. 을 참조하십시오 "다음 단계: 필요한 경우 추가 복구 단계를 수행합니다".