Skip to main content
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

스토리지 볼륨을 다시 마운트하고 다시 포맷합니다(수동 단계)

PDF

보존된 스토리지 볼륨을 다시 마운트하고 오류가 발생한 스토리지 볼륨을 다시 포맷하려면 두 개의 스크립트를 수동으로 실행해야 합니다. 첫 번째 스크립트는 StorageGRID 스토리지 볼륨으로 올바르게 포맷된 볼륨을 다시 마운트합니다. 두 번째 스크립트는 마운트되지 않은 볼륨을 다시 포맷하고, 필요한 경우 Cassandra를 다시 빌드하고, 서비스를 시작합니다.

시작하기 전에

  • 교체가 필요하다고 생각되는 모든 실패한 스토리지 볼륨에 대한 하드웨어를 이미 교체했습니다.

    실행 중 sn-remount-volumes 스크립트를 사용하면 추가로 실패한 스토리지 볼륨을 식별하는 데 도움이 될 수 있습니다.

  • 스토리지 노드 해체가 진행 중이 아닌지 확인했거나 노드 해체 절차를 일시 중지했습니다. (그리드 관리자에서 유지관리 > 작업 > *해제*를 선택합니다.)

  • 확장이 진행 중이 아님을 확인했습니다. (그리드 관리자에서 유지관리 > 작업 > *확장*을 선택합니다.)

  • 당신은 가지고있다"스토리지 노드 시스템 드라이브 복구에 대한 경고를 검토했습니다." .

    주의 두 개 이상의 스토리지 노드가 오프라인 상태이거나 이 그리드의 스토리지 노드가 지난 15일 이내에 재구축된 경우 기술 지원팀에 문의하세요. 실행하지 마십시오 sn-recovery-postinstall.sh 스크립트. 15일 이내에 두 개 이상의 스토리지 노드에서 Cassandra를 재구축하면 데이터가 손실될 수 있습니다.
이 작업에 관하여

이 절차를 완료하려면 다음과 같은 고급 작업을 수행하세요.

  • 복구된 스토리지 노드에 로그인합니다.

  • 실행하다 sn-remount-volumes 올바르게 포맷된 저장 볼륨을 다시 마운트하는 스크립트입니다. 이 스크립트를 실행하면 다음 작업이 수행됩니다.

    • XFS 저널을 재생하기 위해 각 스토리지 볼륨을 마운트 및 마운트 해제합니다.

    • XFS 파일 일관성 검사를 수행합니다.

    • 파일 시스템이 일관성이 있는 경우, 스토리지 볼륨이 올바르게 포맷된 StorageGRID 스토리지 볼륨인지 확인합니다.

    • 저장 볼륨이 올바르게 포맷된 경우 저장 볼륨을 다시 마운트합니다. 해당 볼륨의 기존 데이터는 그대로 유지됩니다.

  • 스크립트 출력을 검토하고 문제를 해결하세요.

  • 실행하다 sn-recovery-postinstall.sh 스크립트. 이 스크립트를 실행하면 다음 작업이 수행됩니다.

    주의 복구 중에 스토리지 노드를 재부팅하지 마십시오. sn-recovery-postinstall.sh 실패한 저장 볼륨을 다시 포맷하고 개체 메타데이터를 복원합니다. 스토리지 노드를 재부팅하기 전에 sn-recovery-postinstall.sh 완료하면 시작을 시도하는 서비스에 오류가 발생하고 StorageGRID 어플라이언스 노드가 유지 관리 모드를 종료합니다. 단계를 참조하세요설치 후 스크립트 .

    • 모든 저장 볼륨을 다시 포맷합니다. sn-remount-volumes 스크립트를 마운트할 수 없거나 형식이 잘못되었습니다.

      참고 저장 볼륨을 다시 포맷하면 해당 볼륨의 모든 데이터가 손실됩니다. ILM 규칙이 두 개 이상의 개체 복사본을 저장하도록 구성되었다고 가정하고 그리드의 다른 위치에서 개체 데이터를 복원하려면 추가 절차를 수행해야 합니다.

    • 필요한 경우 노드에서 Cassandra 데이터베이스를 다시 빌드합니다.

    • 스토리지 노드에서 서비스를 시작합니다.

단계

  1. 복구된 스토리지 노드에 로그인하세요.

    1. 다음 명령을 입력하세요: ssh admin@grid_node_IP

    2. 나열된 비밀번호를 입력하세요 Passwords.txt 파일.

    3. 다음 명령을 입력하여 루트로 전환하세요. su -

    4. 나열된 비밀번호를 입력하세요 Passwords.txt 파일.

    루트로 로그인하면 프롬프트가 다음과 같이 변경됩니다. $ 에게 # .

  2. 첫 번째 스크립트를 실행하여 올바르게 포맷된 저장 볼륨을 다시 마운트합니다.

    참고 모든 스토리지 볼륨이 새롭고 포맷이 필요한 경우, 또는 모든 스토리지 볼륨에 오류가 발생한 경우 이 단계를 건너뛰고 두 번째 스크립트를 실행하여 마운트 해제된 모든 스토리지 볼륨을 다시 포맷할 수 있습니다.

    1. 스크립트를 실행합니다: sn-remount-volumes

      이 스크립트는 데이터가 포함된 스토리지 볼륨에서 실행하는 데 몇 시간이 걸릴 수 있습니다.

    2. 스크립트가 실행되면 출력을 검토하고 모든 프롬프트에 답하세요.

      참고 필요에 따라 다음을 사용할 수 있습니다. tail -f 스크립트 로그 파일의 내용을 모니터링하는 명령(/var/local/log/sn-remount-volumes.log ) . 로그 파일에는 명령줄 출력보다 더 자세한 정보가 포함되어 있습니다. 
      root@SG:~ # sn-remount-volumes
The configured LDR noid is 12632740

====== Device /dev/sdb ======
Mount and unmount device /dev/sdb and checking file system consistency:
The device is consistent.
Check rangedb structure on device /dev/sdb:
Mount device /dev/sdb to /tmp/sdb-654321 with rangedb mount options
This device has all rangedb directories.
Found LDR node id 12632740, volume number 0 in the volID file
Attempting to remount /dev/sdb
Device /dev/sdb remounted successfully

====== Device /dev/sdc ======
Mount and unmount device /dev/sdc and checking file system consistency:
Error: File system consistency check retry failed on device /dev/sdc.
You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.

This volume could be new or damaged. If you run sn-recovery-postinstall.sh,
this volume and any data on this volume will be deleted. If you only had two
copies of object data, you will temporarily have only a single copy.
StorageGRID will attempt to restore data redundancy by making
additional replicated copies or EC fragments, according to the rules in
the active ILM policies.

Don't continue to the next step if you believe that the data remaining on
this volume can't be rebuilt from elsewhere in the grid (for example, if
your ILM policy uses a rule that makes only one copy or if volumes have
failed on multiple nodes). Instead, contact support to determine how to
recover your data.

====== Device /dev/sdd ======
Mount and unmount device /dev/sdd and checking file system consistency:
Failed to mount device /dev/sdd
This device could be an uninitialized disk or has corrupted superblock.
File system check might take a long time. Do you want to continue? (y or n) [y/N]? y

Error: File system consistency check retry failed on device /dev/sdd.
You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.

This volume could be new or damaged. If you run sn-recovery-postinstall.sh,
this volume and any data on this volume will be deleted. If you only had two
copies of object data, you will temporarily have only a single copy.
StorageGRID will attempt to restore data redundancy by making
additional replicated copies or EC fragments, according to the rules in
the active ILM policies.

Don't continue to the next step if you believe that the data remaining on
this volume can't be rebuilt from elsewhere in the grid (for example, if
your ILM policy uses a rule that makes only one copy or if volumes have
failed on multiple nodes). Instead, contact support to determine how to
recover your data.

====== Device /dev/sde ======
Mount and unmount device /dev/sde and checking file system consistency:
The device is consistent.
Check rangedb structure on device /dev/sde:
Mount device /dev/sde to /tmp/sde-654321 with rangedb mount options
This device has all rangedb directories.
Found LDR node id 12000078, volume number 9 in the volID file
Error: This volume does not belong to this node. Fix the attached volume and re-run this script.

      예시 출력에서 하나의 스토리지 볼륨이 성공적으로 다시 마운트되었고 세 개의 스토리지 볼륨에 오류가 발생했습니다.

      • `/dev/sdb`XFS 파일 시스템 일관성 검사를 통과했고 유효한 볼륨 구조를 가지고 있어 성공적으로 다시 마운트되었습니다. 스크립트에 의해 다시 마운트된 장치의 데이터는 보존됩니다.

      • `/dev/sdc`저장 볼륨이 새 것이거나 손상되었기 때문에 XFS 파일 시스템 일관성 검사에 실패했습니다.

      • `/dev/sdd`디스크가 초기화되지 않았거나 디스크의 슈퍼블록이 손상되었기 때문에 마운트할 수 없습니다. 스크립트가 스토리지 볼륨을 마운트할 수 없는 경우 파일 시스템 일관성 검사를 실행할지 묻습니다.

        • 저장 볼륨이 새 디스크에 연결된 경우 프롬프트에 *N*을 입력하세요. 새 디스크의 파일 시스템을 확인할 필요는 없습니다.

        • 저장 볼륨이 기존 디스크에 연결되어 있는 경우 프롬프트에 *Y*를 답하세요. 파일 시스템 검사 결과를 사용하여 손상의 원인을 파악할 수 있습니다. 결과는 다음에 저장됩니다. /var/local/log/sn-remount-volumes.log 로그 파일.

      • /dev/sde`XFS 파일 시스템 일관성 검사를 통과했고 유효한 볼륨 구조를 가졌습니다. 그러나 volID 파일의 LDR 노드 ID가 이 스토리지 노드의 ID와 일치하지 않았습니다. `configured LDR noid (맨 위에 표시됨). 이 메시지는 이 볼륨이 다른 스토리지 노드에 속함을 나타냅니다.

  3. 스크립트 출력을 검토하고 문제를 해결하세요.

    주의 저장 볼륨이 XFS 파일 시스템 일관성 검사에 실패하거나 마운트할 수 없는 경우 출력에서 오류 메시지를 주의 깊게 검토하세요. 당신은 실행의 의미를 이해해야 합니다 sn-recovery-postinstall.sh 이 책에 대한 대본.

    1. 예상한 모든 볼륨에 대한 항목이 결과에 포함되어 있는지 확인하세요. 볼륨이 나열되지 않으면 스크립트를 다시 실행합니다.

    2. 탑재된 모든 장치의 메시지를 검토합니다. 스토리지 볼륨이 이 스토리지 노드에 속하지 않음을 나타내는 오류가 없는지 확인하세요.

      예에서 출력은 다음과 같습니다. /dev/sde 다음 오류 메시지가 포함됩니다.

      Error: This volume does not belong to this node. Fix the attached volume and re-run this script.
      주의 스토리지 볼륨이 다른 스토리지 노드에 속한다고 보고되면 기술 지원팀에 문의하세요. 실행하면 sn-recovery-postinstall.sh 스크립트를 실행하면 저장 볼륨이 다시 포맷되어 데이터 손실이 발생할 수 있습니다.

    3. 저장 장치를 마운트할 수 없는 경우, 장치 이름을 기록해 두고 해당 장치를 수리하거나 교체하세요.

      참고 마운트할 수 없는 저장 장치는 수리하거나 교체해야 합니다.

      볼륨 ID를 조회하려면 장치 이름을 사용하는데, 이는 실행할 때 입력해야 합니다. repair-data 볼륨에 개체 데이터를 복원하는 스크립트(다음 절차).

    4. 모든 장착 불가능한 장치를 수리 또는 교체한 후 다음을 실행합니다. sn-remount-volumes 다시 스크립트를 실행하여 다시 마운트할 수 있는 모든 스토리지 볼륨이 다시 마운트되었는지 확인합니다.

      주의 저장 볼륨을 마운트할 수 없거나 잘못 포맷된 경우 다음 단계로 진행하면 해당 볼륨과 볼륨에 있는 모든 데이터가 삭제됩니다. 개체 데이터 사본이 두 개 있는 경우 다음 절차(개체 데이터 복원)를 완료할 때까지 사본은 하나만 남습니다.
    주의 실행하지 마십시오 sn-recovery-postinstall.sh 그리드의 다른 곳에서 실패한 스토리지 볼륨에 남아 있는 데이터를 재구축할 수 없다고 생각되면 스크립트를 실행합니다(예: ILM 정책에서 복사본을 하나만 만드는 규칙을 사용하거나 여러 노드에서 볼륨에 실패한 경우). 대신 기술 지원팀에 문의하여 데이터를 복구하는 방법을 확인하세요.

  4. 실행하다 sn-recovery-postinstall.sh 스크립트: sn-recovery-postinstall.sh

    이 스크립트는 마운트할 수 없거나 잘못 포맷된 것으로 확인된 모든 스토리지 볼륨을 다시 포맷하고, 필요한 경우 노드에서 Cassandra 데이터베이스를 다시 빌드하고, 스토리지 노드에서 서비스를 시작합니다.

    다음 사항을 주의하세요.

    • 스크립트를 실행하는 데 몇 시간이 걸릴 수 있습니다.

    • 일반적으로 스크립트가 실행되는 동안 SSH 세션을 그대로 두어야 합니다.

    • SSH 세션이 활성화되어 있는 동안 *Ctrl+C*를 누르지 마세요.

    • 네트워크 장애가 발생하여 SSH 세션이 종료되면 스크립트가 백그라운드에서 실행되지만 복구 페이지에서 진행 상황을 볼 수 있습니다.

    • 스토리지 노드가 RSM 서비스를 사용하는 경우 노드 서비스가 다시 시작되면서 스크립트가 5분 동안 중단되는 것처럼 보일 수 있습니다. RSM 서비스가 처음 부팅될 때마다 5분 정도의 지연이 예상됩니다.

      참고 RSM 서비스는 ADC 서비스를 포함하는 스토리지 노드에 있습니다.
    참고 일부 StorageGRID 복구 절차에서는 Reaper를 사용하여 Cassandra 복구를 처리합니다. 관련 또는 필요한 서비스가 시작되면 수리는 자동으로 이루어집니다. 스크립트 출력에 "reaper" 또는 "Cassandra repair"가 언급되는 것을 볼 수 있습니다. 복구에 실패했다는 오류 메시지가 나타나면 오류 메시지에 표시된 명령을 실행하세요.

  5. sn-recovery-postinstall.sh 스크립트가 실행되면 Grid Manager에서 복구 페이지를 모니터링합니다.

    복구 페이지의 진행률 표시줄과 단계 열은 다음 사항의 높은 수준의 상태를 제공합니다. sn-recovery-postinstall.sh 스크립트.

    그리드 관리 인터페이스에서 복구 진행 상황을 보여주는 스크린샷

  6. 후에 sn-recovery-postinstall.sh 스크립트가 노드에서 서비스를 시작했으므로 스크립트로 포맷된 모든 스토리지 볼륨에 개체 데이터를 복원할 수 있습니다.

    스크립트는 Grid Manager 볼륨 복원 프로세스를 사용할지 묻습니다.

    • 대부분의 경우, 당신은해야합니다"Grid Manager를 사용하여 개체 데이터 복원" . 답변 y 그리드 관리자를 사용합니다.

    • 기술 지원에서 지시한 경우 또는 교체 노드에 원래 노드보다 개체 스토리지에 사용할 수 있는 볼륨이 적다는 것을 알고 있는 경우와 같이 드문 경우에는 다음을 수행해야 합니다."개체 데이터를 수동으로 복원" 사용하여 repair-data 스크립트. 다음 사례 중 하나에 해당되는 경우 답변하세요. n .

      참고

      당신이 대답한다면 n Grid Manager 볼륨 복원 프로세스 사용(개체 데이터 수동 복원):

      • Grid Manager를 사용하여 개체 데이터를 복원할 수 없습니다.

      • Grid Manager를 사용하여 수동 복원 작업의 진행 상황을 모니터링할 수 있습니다.

      선택을 하면 스크립트가 완료되고 개체 데이터를 복구하기 위한 다음 단계가 표시됩니다. 이러한 단계를 검토한 후 아무 키나 눌러 명령줄로 돌아갑니다.