StorageGRID에서 확장 후 EC 재조정에 대해 알아보십시오
변경 제안
PDF
스토리지 노드를 추가하여 확장하는 과정에서 ILM 규칙을 사용하여 데이터를 소거 코딩하는 경우, 사용 중인 소거 코딩 방식에 필요한 스토리지 노드를 충분히 추가할 수 없다면 소거 코딩(EC) 재조정 절차를 수행해야 할 수 있습니다.
이러한 사항들을 검토한 후 확장 작업을 수행하고, 이어서 "스토리지 노드를 추가한 후 이레이저 코딩된 데이터 재조정"로 이동하여 절차를 실행하십시오.
EC 리밸런싱이란 무엇인가요?
EC 리밸런싱은 StorageGRID 스토리지 노드 확장 후 필요할 수 있는 StorageGRID 절차입니다. 이 절차는 기본 관리 노드에서 명령줄 스크립트로 실행됩니다. EC 리밸런싱 절차를 실행하면 StorageGRID 사이트 내 기존 스토리지 노드와 새로 추가된 스토리지 노드 간에 이레이저 코딩된 조각을 재분배합니다.
EC 재조정 절차:
-
소거 부호화된 객체 데이터만 이동합니다. 복제된 객체 데이터는 이동하지 않습니다.
-
사이트 내에서 데이터를 재분배합니다. 사이트 간에 데이터를 이동시키지는 않습니다.
-
사이트 내 모든 스토리지 노드에 데이터를 재분배합니다. 스토리지 볼륨 내의 데이터는 재분배하지 않습니다.
-
각 노드에 동일한 바이트 수를 분산시키려고 시도합니다. 복제된 데이터가 더 많은 노드는 재균형 조정이 완료된 후 소거 부호화된 데이터를 더 적게 저장하게 됩니다.
-
각 노드의 상대적 용량을 고려하지 않고 소거 부호화된 데이터를 스토리지 노드 간에 균등하게 재분배합니다. 복제된 데이터도 계산에 포함됩니다.
-
스토리지 노드의 용량이 80% 이상 차면 이레이저 코딩된 데이터를 해당 노드에 배포하지 않습니다.
-
실행 시 ILM 작업 및 S3 클라이언트 작업 성능이 저하될 수 있습니다—소거 코딩 조각을 재배포하는 데 추가 리소스가 필요합니다.
EC 리밸런싱 절차가 완료되면:
-
삭제 코딩된 데이터는 사용 가능한 공간이 부족한 스토리지 노드에서 사용 가능한 공간이 더 많은 스토리지 노드로 이동됩니다.
-
이레이저 코딩된 객체의 데이터 보호는 변경되지 않습니다.
-
스토리지 노드 간 사용률(%) 값이 다를 수 있는 이유는 두 가지입니다.
-
복제된 객체 복사본은 기존 노드의 공간을 계속 차지합니다—EC 리밸런싱 절차는 복제된 데이터를 이동하지 않습니다.
-
모든 노드에 최종적으로 저장되는 데이터 양은 거의 동일하더라도, 용량이 큰 노드는 용량이 작은 노드에 비해 상대적으로 사용량이 적을 것입니다.
예를 들어, 200TB 노드 세 개가 각각 80%씩 차 있다고 가정해 보겠습니다(200 × 0.8 = 각 노드에 160TB, 사이트 전체에는 480TB). 여기에 400TB 노드를 추가하고 리밸런싱 절차를 실행하면 모든 노드에 대략 동일한 양의 소거 코드 데이터(480/4 = 120TB)가 저장됩니다. 하지만 용량이 더 큰 노드의 사용률(%)은 용량이 더 작은 노드들의 사용률(%)보다 낮아집니다.
-
삭제 코딩 데이터의 재조정 시기
EC 재분배 절차는 기존 소거 부호화 데이터의 재분배를 통해 노드가 가득 차거나 가득 찬 상태로 유지되는 것을 방지합니다. 이 절차는 사이트에서 EC 인코딩이 지속될 수 있도록 지원합니다.
사이트의 데이터 배포에 심각한 편향이 있고 해당 사이트에 EC 데이터가 주로 저장되는 경우(복제된 데이터는 리밸런싱으로 이동할 수 없으므로) 리밸런싱 절차를 실행하십시오.
다음 시나리오를 고려하십시오.
-
StorageGRID는 3개의 스토리지 노드를 포함하는 단일 사이트에서 실행됩니다.
-
ILM 정책은 1.0MB보다 큰 모든 객체에 대해 2+1 소거 코딩 규칙을 사용하고, 더 작은 객체에 대해서는 2개 복사본 복제 규칙을 사용합니다.
-
모든 스토리지 노드가 완전히 가득 찼습니다. 객체 스토리지 부족 경고가 심각도 최고 수준으로 발생했습니다.
노드를 충분히 추가하면 리밸런싱이 필요하지 않습니다.
EC 리밸런싱이 필요하지 않은 경우를 이해하기 위해, 세 개(또는 그 이상)의 새 스토리지 노드를 추가했다고 가정해 보겠습니다. 이 경우 EC 리밸런싱을 수행할 필요가 없습니다. 기존 스토리지 노드는 계속 가득 차 있지만, 새 객체는 이제 세 개의 새 노드를 사용하여 2+1 이레이저 코딩을 수행합니다. 즉, 두 개의 데이터 조각과 하나의 패리티 조각이 각각 다른 노드에 저장될 수 있습니다.
|
이 경우 EC 리밸런싱 절차를 실행할 수는 있지만, 기존의 이레이저 코딩된 데이터를 이동하면 그리드 성능이 일시적으로 저하되어 클라이언트 운영에 영향을 미칠 수 있습니다. |
노드를 충분히 추가할 수 없는 경우 리밸런싱이 필요합니다.
EC 리밸런싱이 필요한 시점을 이해하기 위해 스토리지 노드를 3개가 아닌 2개만 추가할 수 있다고 가정해 보겠습니다. 2+1 방식은 최소 3개의 스토리지 노드에 여유 공간이 필요하므로, 비어 있는 노드는 새로운 이레이저 코딩 데이터를 저장하는 데 사용할 수 없습니다.
새로운 스토리지 노드를 활용하려면 EC 재조정 절차를 실행해야 합니다. 이 절차가 실행되면 StorageGRID는 기존의 이레이저 코딩된 데이터와 패리티 조각을 사이트의 모든 스토리지 노드에 재분배합니다. 이 예에서 EC 재조정 절차가 완료되면 5개 노드 모두 사용률이 60%로 줄어들고, 모든 스토리지 노드에서 2+1 이레이저 코딩 방식으로 객체를 계속 수집할 수 있습니다.
EC 리밸런싱에 대한 권장 사항
NetApp 다음 조건이 모두 충족될 경우 EC 리밸런싱을 요구합니다.
-
객체 데이터에 소거 코딩을 사용합니다.
-
사이트의 하나 이상의 스토리지 노드에서 Low Object Storage 경고가 트리거되었습니다. 이는 해당 노드가 80% 이상 가득 찼음을 나타냅니다.
-
현재 사용 중인 소거 부호화 방식에 필요한 만큼의 새 스토리지 노드를 추가할 수 없습니다. "삭제 코딩 오브젝트의 스토리지 용량 추가"을 참조하십시오.
-
EC 리밸런싱 절차가 실행되는 동안 S3 클라이언트는 쓰기 및 읽기 작업에서 성능 저하를 감수할 수 있습니다.
스토리지 노드를 비슷한 수준으로 채우는 것을 선호하고 EC 리밸런싱 절차가 실행되는 동안 S3 클라이언트가 쓰기 및 읽기 작업 성능 저하를 허용할 수 있는 경우 선택적으로 EC 리밸런싱 절차를 실행할 수 있습니다.
EC 리밸런싱 절차가 다른 유지 관리 작업과 상호 작용하는 방식
EC 리밸런싱 절차를 실행하는 동안에는 특정 유지 관리 절차를 동시에 수행할 수 없습니다.
| 절차 | EC 리밸런싱 절차 중에 허용됩니까? |
|---|---|
추가 EC 리밸런싱 절차 |
아니요. EC 리밸런싱 절차는 한 번에 하나만 실행할 수 있습니다. |
폐기 절차 EC 데이터 복구 작업 |
아니요.
|
확장 절차 |
아니요. 확장 시 새 스토리지 노드를 추가해야 하는 경우, 모든 새 노드를 추가한 후 EC 리밸런싱 절차를 실행하십시오. |
업그레이드 절차 |
아니요. StorageGRID 소프트웨어를 업그레이드해야 하는 경우, EC 리밸런싱 절차를 실행하기 전이나 후에 업그레이드 절차를 수행하십시오. 필요에 따라 EC 리밸런싱 절차를 중단하고 소프트웨어 업그레이드를 수행할 수 있습니다. |
어플라이언스 노드 복제 절차 |
아니요. 어플라이언스 스토리지 노드를 복제해야 하는 경우 새 노드를 추가한 후 EC 리밸런싱 절차를 실행하십시오. |
핫픽스 절차 |
예. EC 리밸런싱 절차가 실행되는 동안 StorageGRID 핫픽스를 적용할 수 있습니다. |
기타 유지보수 절차 |
아니요. 다른 유지 관리 절차를 실행하기 전에 EC 리밸런싱 절차를 종료해야 합니다. |
EC 리밸런싱 절차가 ILM과 상호 작용하는 방식
EC 리밸런싱 절차가 실행되는 동안 기존 이레이저 코딩된 객체의 위치를 변경할 수 있는 ILM 변경을 하지 마십시오. 예를 들어, 다른 이레이저 코딩 프로파일을 사용하는 ILM 규칙을 시작하지 마십시오. 이러한 ILM 변경이 필요한 경우 EC 리밸런싱 절차를 종료해야 합니다.