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

개체 무결성을 확인합니다

기여자
PDF

StorageGRID 시스템은 스토리지 노드에서 오브젝트 데이터의 무결성을 확인하여 손상되거나 누락된 오브젝트가 없는지 확인합니다.

검증 프로세스에는 두 가지가 있습니다. 백그라운드 검증 및 개체 존재 확인(이전의 포그라운드 검증)입니다. 이 두 구성 모두 함께 작동하여 데이터 무결성을 보장합니다. 백그라운드 검증이 자동으로 실행되고 개체 데이터의 정확성을 지속적으로 확인합니다. 개체의 존재 여부를 보다 빠르게 확인하기 위해 사용자가 개체 존재 여부를 확인할 수 있습니다(정확성은 아님).

백그라운드 검증이란 무엇입니까?

백그라운드 검증 프로세스는 스토리지 노드에서 손상된 오브젝트 데이터 복사본을 자동으로 지속적으로 검사하고 발견한 문제를 자동으로 복구합니다.

백그라운드 검증 에서는 다음과 같이 복제된 오브젝트와 삭제 코딩 오브젝트의 무결성을 검사합니다.

  • * 복제된 객체 *: 백그라운드 검증 프로세스에서 손상된 복제된 객체가 발견되면 손상된 복제본이 해당 위치에서 제거되고 스토리지 노드의 다른 곳에서 격리됩니다. 그런 다음 활성 ILM 정책을 충족하기 위해 손상되지 않은 새 복사본이 생성되고 배치됩니다. 새 복제본이 원래 복제본에 사용된 스토리지 노드에 배치되지 않을 수 있습니다.

참고 손상된 개체 데이터가 시스템에서 삭제되지 않고 격리되므로 계속 액세스할 수 있습니다. 격리된 객체 데이터에 액세스하는 방법에 대한 자세한 내용은 기술 지원 부서에 문의하십시오.

  • * 삭제 코딩 오브젝트 *: 백그라운드 검증 프로세스에서 삭제 코딩 오브젝트의 조각이 손상된 것을 감지하면 StorageGRID는 나머지 데이터 및 패리티 조각을 사용하여 동일한 스토리지 노드에 누락된 조각을 자동으로 재구축하려고 시도합니다. 손상된 조각을 다시 만들 수 없는 경우 개체의 다른 복사본을 가져오려고 시도합니다. 가져오기가 성공하면 삭제 코딩 개체의 대체 복사본을 만들기 위해 ILM 평가가 수행됩니다.

    백그라운드 검증 프로세스는 스토리지 노드의 객체만 확인합니다. 클라우드 스토리지 풀의 오브젝트는 검사하지 않습니다. 백그라운드 검증을 받으려면 객체가 4일 이상이어야 합니다.

백그라운드 검증은 일반적인 시스템 활동을 방해하지 않도록 설계된 연속 속도로 실행됩니다. 백그라운드 검증을 중지할 수 없습니다. 그러나 문제가 의심될 경우 백그라운드 검증 속도를 높여 스토리지 노드의 내용을 더 빠르게 확인할 수 있습니다.

백그라운드 확인과 관련된 경고

손상된 개체가 시스템에서 자동으로 수정할 수 없는 것을 감지하면(손상으로 인해 개체가 식별되지 않음) * 식별되지 않은 손상된 개체가 감지됨 * 경고가 트리거됩니다.

다른 복사본을 찾을 수 없기 때문에 백그라운드 검증이 손상된 개체를 대체할 수 없는 경우 * Objects Lost * 경고가 트리거됩니다.

백그라운드 검증 비율을 변경합니다

데이터 무결성에 대한 우려가 있는 경우 백그라운드 검증이 스토리지 노드에서 복제된 오브젝트 데이터를 검사하는 속도를 변경할 수 있습니다.

시작하기 전에
이 작업에 대해

스토리지 노드에서 백그라운드 검증을 위한 검증 비율을 변경할 수 있습니다.

  • 적응: 기본 설정. 이 작업은 최대 4MB/s 또는 10개의 오브젝트/s(둘 중 먼저 초과되는 값)에서 확인하도록 설계되었습니다.

  • 높음: 일반적인 시스템 작업을 느리게 할 수 있는 속도로 스토리지 검증이 빠르게 진행됩니다.

하드웨어 또는 소프트웨어 오류로 인해 오브젝트 데이터가 손상되었을 수 있다고 의심되는 경우에만 높은 확인 속도를 사용하십시오. 우선 순위가 높은 백그라운드 검증이 완료되면 검증 속도가 자동으로 적응(Adaptive)으로 재설정됩니다.

단계

  1. 지원 * > * 도구 * > * 그리드 토폴로지 * 를 선택합니다.

  2. 스토리지 노드 * > * LDR * > * 검증 * 을 선택합니다.

  3. Configuration * > * Main * 을 선택합니다.

  4. LDR * > * 검증 * > * 구성 * > * 주 * 로 이동합니다.

  5. Background Verification(배경 검증) 아래에서 * Verification Rate(검증 비율) * > * High(높음) * 또는 * Verification Rate(검증 비율) * > * Adaptive * 를 선택합니다.

    확인 속도 설정

  6. 변경 내용 적용 * 을 클릭합니다.

  7. 복제된 객체에 대한 백그라운드 검증 결과를 모니터링합니다.

    1. 노드 * > *스토리지 노드 * > * 개체 * 로 이동합니다.

    2. 확인 섹션에서 * 손상된 개체 * 및 * 식별되지 않은 개체 * 에 대한 값을 모니터링합니다.

      백그라운드 확인이 손상된 복제된 개체 데이터를 찾으면 * 손상된 개체 * 메트릭이 증가하고 StorageGRID는 다음과 같이 데이터에서 개체 식별자를 추출하려고 시도합니다.

      • 개체 식별자를 추출할 수 있는 경우 StorageGRID는 개체 데이터의 새 복사본을 자동으로 만듭니다. 활성 ILM 정책을 충족하는 StorageGRID 시스템의 어느 곳에서나 새 복사본을 만들 수 있습니다.

      • 개체 식별자가 손상되어 추출할 수 없는 경우 * 손상된 개체 식별되지 않음 * 메트릭이 증가하고 * 식별되지 않은 손상된 개체가 감지됨 * 경고가 트리거됩니다.

    3. 손상된 복제된 개체 데이터가 발견되면 기술 지원 부서에 문의하여 손상의 근본 원인을 확인하십시오.

  8. 삭제 코딩 개체에 대한 백그라운드 검증 결과를 모니터링합니다.

    백그라운드 검증이 삭제 코딩 오브젝트 데이터의 손상된 조각을 찾으면 손상된 조각 감지됨 속성이 증가합니다. StorageGRID는 동일한 스토리지 노드에 손상된 부분을 재생성하여 복구합니다.

    1. 지원 * > * 도구 * > * 그리드 토폴로지 * 를 선택합니다.

    2. 스토리지 노드 * > * LDR * > * 삭제 코딩 * 을 선택합니다.

    3. Verification Results 테이블에서 손상된 조각 감지(ECCD) 속성을 모니터링합니다.

  9. 손상된 개체가 StorageGRID 시스템에 의해 자동으로 복구된 후 손상된 개체의 수를 재설정합니다.

    1. 지원 * > * 도구 * > * 그리드 토폴로지 * 를 선택합니다.

    2. 스토리지 노드 * > * LDR * > * 검증 * > * 구성 * 을 선택합니다.

    3. 손상된 개체 수 재설정 * 을 선택합니다.

    4. 변경 내용 적용 * 을 클릭합니다.

  10. 격리된 객체가 필요하지 않은 것으로 확신하면 삭제할 수 있습니다.

    참고 Objects Lost * 경고가 트리거된 경우 기술 지원 부서에서는 격리된 개체에 액세스하여 근본적인 문제를 디버깅하거나 데이터 복구를 시도할 수 있습니다.

    1. 지원 * > * 도구 * > * 그리드 토폴로지 * 를 선택합니다.

    2. 스토리지 노드 * > * LDR * > * 검증 * > * 구성 * 을 선택합니다.

    3. 격리된 개체 삭제 * 를 선택합니다.

    4. Apply Changes * 를 선택합니다.

개체 존재 확인이란 무엇입니까?

오브젝트 존재 여부는 스토리지 노드에 예상되는 모든 오브젝트 복제 복사본과 삭제 코딩 조각이 있는지 확인합니다. 개체 존재 확인은 개체 데이터 자체를 확인하지 않습니다(백그라운드 검증에서 확인). 대신 스토리지 디바이스의 무결성을 확인하는 방법을 제공합니다. 특히 최근 하드웨어 문제로 인해 데이터 무결성이 영향을 받을 수 있는 경우 더욱 그렇습니다.

자동으로 발생하는 백그라운드 확인과는 달리 개체 존재 확인 작업을 수동으로 시작해야 합니다.

오브젝트 존재 확인 은 StorageGRID에 저장된 모든 오브젝트의 메타데이터를 읽고 복제 오브젝트 복사본과 삭제 코딩 오브젝트 조각의 존재 여부를 확인합니다. 누락된 데이터는 다음과 같이 처리됩니다.

  • * 복제된 복사본 *: 복제된 개체 데이터의 복사본이 누락된 경우 StorageGRID는 자동으로 시스템의 다른 위치에 저장된 복사본에서 복사본을 교체하려고 시도합니다. 스토리지 노드는 ILM 평가를 통해 기존 복사본을 실행합니다. 그러면 다른 복사본이 없기 때문에 현재 ILM 정책이 이 개체에 대해 더 이상 충족되지 않는 것으로 결정됩니다. 시스템의 활성 ILM 정책을 충족하기 위해 새 복사본이 생성되고 배치됩니다. 이 새 사본은 누락된 사본이 저장된 동일한 위치에 배치되지 않을 수 있습니다.

  • * 삭제 코딩 단편 *: 삭제 코딩 오브젝트의 조각이 누락된 경우 StorageGRID는 나머지 조각을 사용하여 동일한 스토리지 노드에 누락된 조각을 자동으로 재구축합니다. 누락된 조각을 다시 생성할 수 없는 경우(너무 많은 조각이 손실되었기 때문에) ILM은 오브젝트의 다른 복사본을 찾으려고 시도합니다. 이 복사본은 새로운 삭제 코딩 조각을 생성하는 데 사용할 수 있습니다.

개체 존재 확인 실행

한 번에 하나의 개체 존재 확인 작업을 만들고 실행할 수 있습니다. 작업을 생성할 때 확인할 스토리지 노드 및 볼륨을 선택합니다. 작업의 일관성을 선택할 수도 있습니다.

시작하기 전에

  • 을 사용하여 그리드 관리자에 로그인되어 있습니다."지원되는 웹 브라우저"

  • 이 "유지 관리 또는 루트 액세스 권한"있습니다.

  • 확인할 스토리지 노드가 온라인 상태인지 확인했습니다. 노드 테이블을 보려면 * nodes * 를 선택합니다. 확인할 노드의 노드 이름 옆에 알림 아이콘이 나타나지 않는지 확인합니다.

  • 확인할 노드에서 다음 절차가 * 실행되지 않음 * 인지 확인했습니다.

    • 스토리지 노드를 추가하기 위한 그리드 확장

    • 스토리지 노드 서비스 해제

    • 장애가 발생한 스토리지 볼륨 복구

    • 장애가 발생한 시스템 드라이브로 스토리지 노드 복구

    • EC 재조정

    • 어플라이언스 노드 클론

개체 존재 여부 검사는 이러한 절차가 진행 중인 동안에는 유용한 정보를 제공하지 않습니다.

이 작업에 대해

개체 존재 여부 확인 작업은 그리드의 개체 수, 선택한 스토리지 노드와 볼륨 및 선택한 정합성 보장에 따라 완료하는 데 며칠 또는 몇 주가 걸릴 수 있습니다. 한 번에 하나의 작업만 실행할 수 있지만 여러 스토리지 노드와 볼륨을 동시에 선택할 수 있습니다.

단계

  1. 유지보수 * > * 작업 * > * 개체 존재 확인 * 을 선택합니다.

  2. 작업 생성 * 을 선택합니다. 개체 존재 확인 작업 생성 마법사가 나타납니다.

  3. 확인할 볼륨이 포함된 노드를 선택합니다. 모든 온라인 노드를 선택하려면 열 머리글에서 * 노드 이름 * 확인란을 선택합니다.

    노드 이름 또는 사이트별로 검색할 수 있습니다.

    그리드에 연결되지 않은 노드는 선택할 수 없습니다.

  4. Continue * 를 선택합니다.

  5. 목록의 각 노드에 대해 하나 이상의 볼륨을 선택합니다. 스토리지 볼륨 번호 또는 노드 이름을 사용하여 볼륨을 검색할 수 있습니다.

    선택한 각 노드의 모든 볼륨을 선택하려면 열 머리글에서 * 스토리지 볼륨 * 확인란을 선택합니다.

  6. Continue * 를 선택합니다.

  7. 작업의 일관성을 선택합니다.

    일관성은 개체 존재 여부 확인에 사용되는 개체 메타데이터의 복사본 수를 결정합니다.

    • * 강력한 사이트 *: 단일 사이트에 메타데이터 복사본 2개

    • * 강력한 글로벌 *: 각 사이트에 메타데이터 복사본 2개

    • * 모두 * (기본값): 각 사이트에 있는 세 개의 메타데이터 복사본 모두

      일관성에 대한 자세한 내용은 마법사의 설명을 참조하십시오.

  8. Continue * 를 선택합니다.

  9. 선택 항목을 검토하고 확인합니다. 이전 * 을 선택하여 마법사의 이전 단계로 이동하여 선택 사항을 업데이트할 수 있습니다.

    개체 존재 확인 작업이 생성되고 다음 중 하나가 발생할 때까지 실행됩니다.

    • 작업이 완료됩니다.

    • 작업을 일시 중지하거나 취소합니다. 일시 중지한 작업은 다시 시작할 수 있지만 취소한 작업은 다시 시작할 수 없습니다.

    • 작업이 멈춥니다. Object existence check has Stallered * 경고가 트리거됩니다. 경고에 지정된 수정 조치를 따릅니다.

    • 작업이 실패합니다. 개체 존재 확인 실패 * 경고가 트리거됩니다. 경고에 지정된 수정 조치를 따릅니다.

    • "서비스를 사용할 수 없음" 또는 "내부 서버 오류" 메시지가 나타납니다. 1분 후 페이지를 새로 고쳐 작업을 계속 모니터링합니다.

      참고 필요한 경우 개체 존재 확인 페이지에서 벗어나 작업을 계속 모니터링하기 위해 돌아갈 수 있습니다.

  10. 작업이 실행될 때 * 활성 작업 * 탭을 보고 감지된 누락된 오브젝트 복사본의 값을 기록합니다.

    이 값은 하나 이상의 누락된 조각이 있는 복제된 오브젝트 및 삭제 코딩 오브젝트의 누락된 총 수를 나타냅니다.

    감지된 누락된 객체 복제본 수가 100개를 초과하는 경우 스토리지 노드의 스토리지에 문제가 있을 수 있습니다.

    OEC 활성 작업

  11. 작업이 완료된 후 필요한 추가 작업을 수행합니다.

    • 감지된 누락된 개체 복사본이 0이면 문제를 찾을 수 없습니다. 별도의 조치가 필요하지 않습니다.

    • 감지된 누락된 개체 사본이 0보다 크고 * Objects Lost * 경고가 트리거되지 않은 경우 누락된 모든 복사본은 시스템에서 복구되었습니다. 향후 개체 복사본에 대한 손상을 방지하기 위해 하드웨어 문제가 해결되었는지 확인합니다.

    • 감지된 누락된 개체 사본이 0보다 크고 * 개체 손실 * 경고가 트리거되면 데이터 무결성이 영향을 받을 수 있습니다. 기술 지원 부서에 문의하십시오.

    • grep를 사용하여 LLST 감사 메시지를 추출하여 손실된 객체 복사본을 조사할 수 있습니다 grep LLST audit_file_name.

      이 절차는 의 절차와 비슷하지만 대신"분실된 물체를 조사 중입니다" 검색하는 개체 복사본의 경우 LLST 이 OLST 절차와 비슷합니다.

  12. 작업에 대해 강력한 사이트 또는 강력한 글로벌 일관성을 선택한 경우 메타데이터 일관성을 위해 약 3주를 기다린 다음 같은 볼륨에서 작업을 다시 실행합니다.

    StorageGRID가 작업에 포함된 노드와 볼륨의 메타데이터 일관성을 달성할 시간이 있는 경우, 작업을 다시 실행하면 잘못 보고된 누락된 오브젝트 복사본을 지우거나 누락된 경우 추가 오브젝트 복사본을 확인할 수 있습니다.

    1. 유지보수 * > * 개체 존재 확인 * > * 작업 내역 * 을 선택합니다.

    2. 재실행할 준비가 된 작업을 확인합니다.

      1. 3주 전에 실행된 작업을 판별하려면 * 종료 시간 * 열을 확인하십시오.

      2. 이러한 작업의 경우 정합성 보장 제어 열에서 강력한 사이트 또는 강력한 글로벌 사이트를 검사합니다.

    3. 재실행할 각 작업의 확인란을 선택한 다음 * 재실행 * 을 선택합니다.

      OEC를 다시 실행합니다

    4. 작업 다시 실행 마법사에서 선택한 노드와 볼륨 및 일관성을 검토합니다.

    5. 작업을 다시 실행할 준비가 되면 * 재실행 * 을 선택합니다.

활성 작업 탭이 나타납니다. 선택한 모든 작업이 강력한 사이트의 일관성에서 하나의 작업으로 다시 실행됩니다. 세부 정보 섹션의 * 관련 작업 * 필드에 원래 작업의 작업 ID가 나열됩니다.

작업을 마친 후

데이터 무결성에 대한 우려가 있는 경우 * 지원 * > * 도구 * > * 그리드 토폴로지 * > *_사이트 _ * > * _ 스토리지 노드 _ * > * LDR * > * 검증 * > * 구성 * > * 주 * 로 이동하여 배경 검증 비율을 높이십시오. 백그라운드 검사는 저장된 모든 개체 데이터의 정확성을 확인하고 발견된 문제를 모두 복구합니다. 가능한 한 빨리 잠재적 문제를 찾아 수리하면 데이터 손실의 위험이 감소합니다.