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

삭제된 코드화된 데이터의 재조정을 위한 고려 사항

스토리지 노드를 추가하기 위한 확장을 수행하고 ILM 규칙을 사용하여 코드 데이터를 지우는 경우, 사용 중인 지우기 코딩 방식에 충분한 스토리지 노드를 추가할 수 없으면 지우기 코딩(EC) 재조정 절차를 수행해야 할 수 있습니다.

이러한 고려 사항을 검토한 후 확장을 수행한 다음 다음으로 이동합니다."스토리지 노드 추가 후 삭제 코딩된 데이터 재조정" 프로시저를 실행합니다.

EC 리밸런싱이란 무엇인가요?

EC 리밸런싱은 스토리지 노드 확장 후 필요할 수 있는 StorageGRID 절차입니다. 이 절차는 기본 관리 노드에서 명령줄 스크립트로 실행됩니다. EC 재조정 절차를 실행하면 StorageGRID 삭제 코딩된 조각을 사이트의 기존 스토리지 노드와 새로 추가된 스토리지 노드에 다시 분산합니다.

EC 재조정 절차:

  • 삭제된 객체 데이터만 이동합니다. 복제된 객체 데이터는 이동하지 않습니다.

  • 사이트 내에서 데이터를 재분배합니다. 사이트 간에 데이터를 이동하지 않습니다.

  • 사이트의 모든 스토리지 노드에 데이터를 재분산합니다. 저장 볼륨 내에서 데이터를 재분산하지 않습니다.

  • 삭제된 데이터를 이동할 위치를 결정할 때 각 스토리지 노드에서 복제된 데이터 사용량을 고려하지 않습니다.

  • 각 노드의 상대적 용량을 고려하지 않고 삭제된 데이터를 저장 노드 간에 균등하게 재분배합니다.

  • 80% 이상 채워진 스토리지 노드에는 삭제된 데이터를 배포하지 않습니다.

  • 실행 시 ILM 작업과 S3 클라이언트 작업의 성능이 저하될 수 있습니다. 삭제 코딩 조각을 재배포하려면 추가 리소스가 필요합니다.

EC 재조정 절차가 완료되면:

  • 삭제된 데이터는 사용 가능한 공간이 적은 스토리지 노드에서 사용 가능한 공간이 더 많은 스토리지 노드로 이동됩니다.

  • 삭제된 객체의 데이터 보호는 변경되지 않습니다.

  • 사용된(%) 값은 두 가지 이유로 스토리지 노드 간에 다를 수 있습니다.

    • 복제된 객체 사본은 기존 노드의 공간을 계속 사용합니다. EC 재조정 절차는 복제된 데이터를 이동하지 않습니다.

    • 모든 노드가 대략 동일한 양의 삭제 코딩된 데이터를 갖게 되더라도, 대용량 노드는 소용량 노드보다 상대적으로 덜 채워질 것입니다.

      예를 들어, 200TB 노드 3개가 각각 80%씩 채워졌다고 가정합니다(200 × 0.8 = 각 노드에서 160TB, 사이트의 경우 480TB). 400TB 노드를 추가하고 재조정 절차를 실행하면 이제 모든 노드가 대략 동일한 양의 삭제 코드 데이터(480/4 = 120TB)를 갖게 됩니다. 그러나 더 큰 노드의 사용률(%)은 더 작은 노드의 사용률(%)보다 낮습니다.

    확장 전 사용 공간

삭제된 데이터를 재조정해야 하는 경우

다음 시나리오를 생각해 보세요.

  • StorageGRID 3개의 스토리지 노드를 포함하는 단일 사이트에서 실행됩니다.

  • ILM 정책은 1.0MB보다 큰 모든 객체에 대해 2+1 삭제 코딩 규칙을 사용하고, 그보다 작은 객체에 대해서는 2-복사 복제 규칙을 사용합니다.

  • 모든 스토리지 노드가 완전히 가득 찼습니다. 객체 저장 공간 부족 경고가 주요 심각도 수준에서 발령되었습니다.

    확장 전 사용 공간

충분한 노드를 추가하면 재조정이 필요하지 않습니다.

EC 재조정이 필요하지 않은 경우를 파악하기 위해 3개(또는 그 이상)의 새 스토리지 노드를 추가했다고 가정해 보겠습니다. 이 경우에는 EC 리밸런싱을 수행할 필요가 없습니다. 원래의 저장 노드는 계속 가득 차 있지만, 새로운 객체는 이제 2+1 삭제 코딩을 위해 세 개의 새로운 노드를 사용합니다. 두 개의 데이터 조각과 하나의 패리티 조각은 각각 다른 노드에 저장될 수 있습니다.

3노드 확장 후 사용된 공간
주의 이 경우 EC 재조정 절차를 실행할 수 있지만 기존 삭제 코딩된 데이터를 이동하면 그리드 성능이 일시적으로 저하되어 클라이언트 작업에 영향을 미칠 수 있습니다.

노드를 충분히 추가할 수 없는 경우 재조정이 필요합니다.

EC 재조정이 필요한 경우를 파악하기 위해, 3개가 아닌 2개의 스토리지 노드만 추가할 수 있다고 가정해 보겠습니다. 2+1 방식은 최소 3개의 저장 노드에 사용 가능한 공간이 필요하므로 빈 노드는 새로운 삭제 코딩된 데이터에 사용할 수 없습니다.

2노드 확장 후 사용된 공간

새로운 스토리지 노드를 활용하려면 EC 재조정 절차를 실행해야 합니다. 이 절차가 실행되면 StorageGRID 기존 삭제 코딩된 데이터와 패리티 조각을 사이트의 모든 스토리지 노드에 다시 분산합니다. 이 예에서 EC 재조정 절차가 완료되면 5개 노드 모두 60%만 채워진 상태가 되고, 모든 스토리지 노드에서 2+1 삭제 코딩 방식에 객체를 계속 수집할 수 있습니다.

EC 재조정 후 사용된 공간

EC 재조정을 위한 권장 사항

다음 진술이 모두 참인 경우 NetApp EC 재조정이 필요합니다.

  • 객체 데이터에 삭제 코딩을 사용합니다.

  • 사이트의 하나 이상의 스토리지 노드에 대해 개체 스토리지 부족 경고가 발생했으며, 이는 노드가 80% 이상 채워졌음을 나타냅니다.

  • 사용 중인 삭제 코딩 방식에는 충분한 새 스토리지 노드를 추가할 수 없습니다. 보다 "삭제된 객체에 대한 저장 용량 추가" .

  • EC 재조정 절차가 실행되는 동안 S3 클라이언트는 쓰기 및 읽기 작업에 대한 성능 저하를 허용할 수 있습니다.

스토리지 노드를 비슷한 수준으로 채우고 S3 클라이언트가 EC 재조정 절차가 실행되는 동안 쓰기 및 읽기 작업에 대한 낮은 성능을 허용할 수 있는 경우 선택적으로 EC 재조정 절차를 실행할 수 있습니다.

EC 재조정 절차가 다른 유지 관리 작업과 상호 작용하는 방식

EC 재조정 절차를 실행하는 동안 특정 유지 관리 절차를 동시에 수행할 수 없습니다.

절차 EC 재조정 절차 중에 허용되나요?

추가 EC 재조정 절차

아니요.

한 번에 하나의 EC 재조정 절차만 실행할 수 있습니다.

해체 절차

EC 데이터 복구 작업

아니요.

  • EC 재조정 절차가 실행되는 동안에는 서비스 중단 절차나 EC 데이터 복구를 시작할 수 없습니다.

  • 스토리지 노드 해체 절차 또는 EC 데이터 복구가 실행되는 동안에는 EC 재조정 절차를 시작할 수 없습니다.

확장 절차

아니요.

확장 시 새로운 스토리지 노드를 추가해야 하는 경우 모든 새 노드를 추가한 후 EC 재조정 절차를 실행하세요.

업그레이드 절차

아니요.

StorageGRID 소프트웨어를 업그레이드해야 하는 경우 EC 재조정 절차를 실행하기 전이나 실행한 후에 업그레이드 절차를 수행하세요. 필요에 따라 EC 리밸런싱 절차를 종료하여 소프트웨어 업그레이드를 수행할 수 있습니다.

어플라이언스 노드 복제 절차

아니요.

어플라이언스 스토리지 노드를 복제해야 하는 경우 새 노드를 추가한 후 EC 재조정 절차를 실행하세요.

핫픽스 절차

네.

EC 재조정 절차가 실행되는 동안 StorageGRID 핫픽스를 적용할 수 있습니다.

기타 유지 관리 절차

아니요.

다른 유지 관리 절차를 실행하기 전에 EC 재조정 절차를 종료해야 합니다.

EC 재조정 절차가 ILM과 상호 작용하는 방식

EC 재조정 절차가 실행되는 동안 기존 삭제 코드화된 객체의 위치를 변경할 수 있는 ILM 변경을 하지 마세요. 예를 들어, 다른 삭제 코딩 프로필을 갖는 ILM 규칙을 사용하지 마세요. 이러한 ILM 변경이 필요한 경우 EC 재조정 절차를 종료해야 합니다.