삭제된 코드화된 데이터의 재조정을 위한 고려 사항
스토리지 노드를 추가하기 위한 확장을 수행하고 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 삭제 코딩을 위해 세 개의 새로운 노드를 사용합니다. 두 개의 데이터 조각과 하나의 패리티 조각은 각각 다른 노드에 저장될 수 있습니다.
|
|
이 경우 EC 재조정 절차를 실행할 수 있지만 기존 삭제 코딩된 데이터를 이동하면 그리드 성능이 일시적으로 저하되어 클라이언트 작업에 영향을 미칠 수 있습니다. |
노드를 충분히 추가할 수 없는 경우 재조정이 필요합니다.
EC 재조정이 필요한 경우를 파악하기 위해, 3개가 아닌 2개의 스토리지 노드만 추가할 수 있다고 가정해 보겠습니다. 2+1 방식은 최소 3개의 저장 노드에 사용 가능한 공간이 필요하므로 빈 노드는 새로운 삭제 코딩된 데이터에 사용할 수 없습니다.
새로운 스토리지 노드를 활용하려면 EC 재조정 절차를 실행해야 합니다. 이 절차가 실행되면 StorageGRID 기존 삭제 코딩된 데이터와 패리티 조각을 사이트의 모든 스토리지 노드에 다시 분산합니다. 이 예에서 EC 재조정 절차가 완료되면 5개 노드 모두 60%만 채워진 상태가 되고, 모든 스토리지 노드에서 2+1 삭제 코딩 방식에 객체를 계속 수집할 수 있습니다.
EC 재조정을 위한 권장 사항
다음 진술이 모두 참인 경우 NetApp EC 재조정이 필요합니다.
-
객체 데이터에 삭제 코딩을 사용합니다.
-
사이트의 하나 이상의 스토리지 노드에 대해 개체 스토리지 부족 경고가 발생했으며, 이는 노드가 80% 이상 채워졌음을 나타냅니다.
-
사용 중인 삭제 코딩 방식에는 충분한 새 스토리지 노드를 추가할 수 없습니다. 보다 "삭제된 객체에 대한 저장 용량 추가" .
-
EC 재조정 절차가 실행되는 동안 S3 클라이언트는 쓰기 및 읽기 작업에 대한 성능 저하를 허용할 수 있습니다.
스토리지 노드를 비슷한 수준으로 채우고 S3 클라이언트가 EC 재조정 절차가 실행되는 동안 쓰기 및 읽기 작업에 대한 낮은 성능을 허용할 수 있는 경우 선택적으로 EC 재조정 절차를 실행할 수 있습니다.
EC 재조정 절차가 다른 유지 관리 작업과 상호 작용하는 방식
EC 재조정 절차를 실행하는 동안 특정 유지 관리 절차를 동시에 수행할 수 없습니다.
| 절차 | EC 재조정 절차 중에 허용되나요? |
|---|---|
추가 EC 재조정 절차 |
아니요. 한 번에 하나의 EC 재조정 절차만 실행할 수 있습니다. |
해체 절차 EC 데이터 복구 작업 |
아니요.
|
확장 절차 |
아니요. 확장 시 새로운 스토리지 노드를 추가해야 하는 경우 모든 새 노드를 추가한 후 EC 재조정 절차를 실행하세요. |
업그레이드 절차 |
아니요. StorageGRID 소프트웨어를 업그레이드해야 하는 경우 EC 재조정 절차를 실행하기 전이나 실행한 후에 업그레이드 절차를 수행하세요. 필요에 따라 EC 리밸런싱 절차를 종료하여 소프트웨어 업그레이드를 수행할 수 있습니다. |
어플라이언스 노드 복제 절차 |
아니요. 어플라이언스 스토리지 노드를 복제해야 하는 경우 새 노드를 추가한 후 EC 재조정 절차를 실행하세요. |
핫픽스 절차 |
네. EC 재조정 절차가 실행되는 동안 StorageGRID 핫픽스를 적용할 수 있습니다. |
기타 유지 관리 절차 |
아니요. 다른 유지 관리 절차를 실행하기 전에 EC 재조정 절차를 종료해야 합니다. |
EC 재조정 절차가 ILM과 상호 작용하는 방식
EC 재조정 절차가 실행되는 동안 기존 삭제 코드화된 객체의 위치를 변경할 수 있는 ILM 변경을 하지 마세요. 예를 들어, 다른 삭제 코딩 프로필을 갖는 ILM 규칙을 사용하지 마세요. 이러한 ILM 변경이 필요한 경우 EC 재조정 절차를 종료해야 합니다.