StorageGRID의 스토리지 및 성능 요구 사항
변경 제안
PDF
StorageGRID 노드의 스토리지 요구 사항을 이해하여 초기 구성 및 향후 스토리지 확장을 지원할 충분한 공간이 있는지 확인해야 합니다.
저장 및 성능 요구 사항은 소프트웨어 기반 노드 구현에 따라 다릅니다.
|
"Linux"는 RHEL, Ubuntu 또는 Debian 배포를 의미합니다. 지원되는 버전 목록은 다음을 참조하세요. "NetApp 상호 운용성 매트릭스 툴(IMT)" . |
저장 카테고리
StorageGRID 노드에는 다음과 같은 세 가지 논리적 스토리지 범주가 필요합니다.
-
컨테이너 풀 — 노드 컨테이너용 성능 계층(10K SAS 또는 SSD) 스토리지로, StorageGRID 노드를 지원하는 호스트에 컨테이너 엔진을 설치 및 구성할 때 컨테이너 엔진 스토리지 드라이버에 할당됩니다.
-
시스템 데이터 — 성능 등급(10K SAS 또는 SSD) 스토리지로, StorageGRID 호스트 서비스가 사용하고 개별 노드에 매핑하는 시스템 데이터 및 트랜잭션 로그의 노드별 영구 스토리지입니다.
-
* 오브젝트 데이터 * — 객체 데이터 및 객체 메타데이터의 영구 스토리지를 위한 Performance-Tier(10K SAS 또는 SSD) 스토리지 및 Capacity-Tier(NL-SAS/SATA) 대용량 스토리지
모든 스토리지 범주에는 RAID 기반 블록 장치를 사용해야 합니다. 비중복 디스크, SSD 또는 JBOD는 지원되지 않습니다. 공유 또는 로컬 RAID 스토리지는 모든 스토리지 범주에 사용할 수 있습니다. StorageGRID에서 노드를 마이그레이션하려면 시스템 데이터와 객체 데이터를 모두 공유 스토리지에 저장해야 합니다. 자세한 내용은 "노드 컨테이너 마이그레이션 요구사항"을 참조하십시오.
성능 요구사항
컨테이너 풀, 시스템 데이터 및 오브젝트 메타데이터에 사용되는 볼륨의 성능은 시스템의 전반적인 성능에 큰 영향을 미칩니다. 이러한 볼륨에 성능 계층(10K SAS 또는 SSD) 스토리지를 사용하면 지연 시간, IOPS(초당 입출력 작업) 및 처리량 측면에서 디스크 성능이 적절하게 보장됩니다. 객체 데이터의 영구 스토리지를 위해 용량 계층(NL-SAS/SATA) 스토리지를 사용할 수 있습니다.
컨테이너 풀, 시스템 데이터 및 오브젝트 데이터에 사용되는 볼륨에는 다시 쓰기 캐시가 설정되어 있어야 합니다. 캐시는 보호되거나 영구 미디어에 있어야 합니다.
NetApp ONTAP 스토리지를 사용하는 호스트의 요구 사항입니다
StorageGRID 노드가 NetApp ONTAP 시스템에서 할당된 스토리지를 사용하는 경우 볼륨에 FabricPool 계층화 정책이 활성화되어 있지 않은지 확인합니다. StorageGRID 노드와 함께 사용되는 볼륨에 대해 FabricPool 계층화를 사용하지 않도록 설정하면 문제 해결과 스토리지 작업이 간소화됩니다.
|
|
FabricPool를 사용하여 StorageGRID 관련 데이터를 StorageGRID 자체로 계층화하지 마십시오. StorageGRID 데이터를 StorageGRID로 다시 계층화하면 문제 해결과 운영 복잡성이 늘어납니다. |
필요한 호스트 수입니다
각 StorageGRID 사이트에는 최소 3개의 스토리지 노드가 필요합니다.
|
|
운영 구축 시 단일 물리적 또는 가상 호스트에서 스토리지 노드를 두 개 이상 실행하지 마십시오. 각 스토리지 노드에 전용 호스트를 사용하면 장애 발생 시 독립적인 도메인을 구축할 수 있습니다. |
관리 노드나 게이트웨이 노드와 같은 다른 유형의 노드를 동일한 호스트에 배포하거나 필요에 따라 별도의 전용 호스트에 배포할 수 있습니다.
|
|
디스크 스냅샷을 사용하여 그리드 노드를 복원할 수 없습니다. 대신 "그리드 노드 복구" 각 노드 유형에 대한 절차를 참조하십시오. |
각 노드의 저장 볼륨 수
다음 표는 각 호스트에 필요한 스토리지 볼륨(LUN)의 수와 각 LUN에 필요한 최소 크기를 보여줍니다. 이는 해당 호스트에 배포된 노드를 기준으로 합니다.
테스트된 최대 LUN 크기는 100 TiB입니다.
|
|
이러한 숫자는 전체 그리드가 아닌 각 호스트에 대한 것입니다. |
| LUN 사용 목적 | 스토리지 범주입니다 | LUN 수입니다 | 최소 크기/LUN |
|---|---|---|---|
컨테이너 엔진 스토리지 풀입니다 |
컨테이너 풀입니다 |
1 |
총 노드 수 × 100GB |
|
시스템 데이터 |
이 호스트의 각 노드에 대해 1개 |
100GB |
스토리지 노드 |
오브젝트 데이터 |
이 호스트의 각 스토리지 노드에 대해 3개 참고: Linux 소프트웨어 기반 스토리지 노드와 VMware 소프트웨어 기반 스토리지 노드는 1개에서 48개까지의 스토리지 볼륨을 가질 수 있습니다. 최소 3개의 스토리지 볼륨을 권장합니다. |
|
스토리지 노드(메타데이터만) |
오브젝트 메타데이터 |
1 |
최소 4TB/LUN 최대 테스트 LUN 크기: 100 TiB. 자세한 내용은 스토리지 노드의 스토리지 요구 사항을 참조하십시오.
|
관리자 노드 감사 로그 |
시스템 데이터 |
이 호스트의 각 관리 노드에 대해 1개 |
200GB |
관리자 노드 테이블 |
시스템 데이터 |
이 호스트의 각 관리 노드에 대해 1개 |
200GB |
|
|
구성된 감사 수준, S3 객체 키 이름과 같은 사용자 입력 크기, 보존해야 하는 감사 로그 데이터 양에 따라 각 관리 노드의 감사 로그 LUN 크기를 늘려야 할 수 있습니다. 일반적으로 그리드 환경에서는 S3 작업당 약 1KB의 감사 데이터가 생성되므로 200GB LUN은 하루 7천만 건의 작업 또는 초당 800건의 작업을 2~3일 동안 지원할 수 있습니다. |
호스트의 최소 스토리지 공간입니다
다음 표는 각 노드 유형에 필요한 최소 스토리지 공간을 보여줍니다. 이 표를 사용하여 호스트에 배포된 노드 유형에 따라 각 스토리지 범주별로 호스트에 제공해야 하는 최소 스토리지 공간을 확인할 수 있습니다.
|
|
디스크 스냅샷을 사용하여 그리드 노드를 복원할 수 없습니다. 대신 "그리드 노드 복구" 각 노드 유형에 대한 절차를 참조하십시오. |
각 노드 호스트에는 OS용 100GB LUN이 필요합니다.
| 노드 유형입니다 | 컨테이너 풀입니다 | 시스템 데이터 | 오브젝트 데이터 |
|---|---|---|---|
스토리지 노드 |
100GB |
100GB |
4,000GB |
관리자 노드 |
100GB |
500GB(3개 LUN) |
_해당 사항 없음 _ |
게이트웨이 노드 |
100GB |
100GB |
_해당 사항 없음 _ |
예: 호스트 또는 가상 머신의 스토리지 요구 사항 계산
동일한 호스트 또는 가상 머신에 스토리지 노드, 관리 노드, 게이트웨이 노드 이렇게 세 개의 노드를 배포할 계획이라고 가정해 보겠습니다. 호스트에는 최소 9개의 스토리지 볼륨이 필요합니다. 노드 컨테이너에는 최소 300GB의 성능 계층 스토리지가, 시스템 데이터 및 트랜잭션 로그에는 700GB의 성능 계층 스토리지가, 객체 데이터에는 12TB의 용량 계층 스토리지가 필요합니다.
| 노드 유형입니다 | LUN 사용 목적 | LUN 수입니다 | LUN 크기입니다 |
|---|---|---|---|
스토리지 노드 |
컨테이너 엔진 스토리지 풀입니다 |
1 |
300GB(100GB/노드) |
스토리지 노드 |
|
1 |
100GB |
스토리지 노드 |
오브젝트 데이터 |
3 |
12TB(4TB/LUN) |
관리자 노드 |
|
1 |
100GB |
관리자 노드 |
관리자 노드 감사 로그 |
1 |
200GB |
관리자 노드 |
관리자 노드 테이블 |
1 |
200GB |
게이트웨이 노드 |
|
1 |
100GB |
|
|
시스템 데이터: 700GB
|
| 노드 유형입니다 | LUN 사용 목적 | LUN 수입니다 | LUN 크기입니다 |
|---|---|---|---|
스토리지 노드 |
OS 볼륨 |
1 |
100GB |
스토리지 노드 |
오브젝트 데이터 |
3 |
12TB(4TB/LUN) |
관리자 노드 |
OS 볼륨 |
1 |
100GB |
관리자 노드 |
관리자 노드 감사 로그 |
1 |
200GB |
관리자 노드 |
관리자 노드 테이블 |
1 |
200GB |
게이트웨이 노드 |
OS 볼륨 |
1 |
100GB |
|
8 |
시스템 데이터: 700GB
|
스토리지 노드에 대한 특정 스토리지 요구 사항
Linux 및 VMware의 스토리지 노드에 대한 스토리지 요구 사항은 다음과 같습니다.
-
Linux 소프트웨어 기반 스토리지 노드는 1개에서 최대 48개의 스토리지 볼륨을 가질 수 있습니다.
-
VMware 소프트웨어 기반 스토리지 노드는 1개에서 최대 48개의 스토리지 볼륨을 가질 수 있습니다.
-
3개 이상의 저장 볼륨을 권장합니다.
-
각 저장 볼륨은 4TB 이상이어야 합니다.
|
|
어플라이언스 스토리지 노드는 최대 48개의 스토리지 볼륨을 가질 수 있습니다. |
그림에 나와 있는 것처럼 StorageGRID는 각 스토리지 노드의 스토리지 볼륨 0에 객체 메타데이터를 위한 공간을 예약합니다. 스토리지 볼륨 0 및 스토리지 노드의 다른 스토리지 볼륨의 나머지 공간은 오브젝트 데이터에만 사용됩니다.
이중화를 제공하고 개체 메타데이터를 손실로부터 보호하기 위해 StorageGRID는 각 사이트의 시스템 모든 개체에 대한 메타데이터 복사본을 3개 저장합니다. 오브젝트 메타데이터의 복사본 3개는 각 사이트의 모든 스토리지 노드에 균등하게 분산됩니다.
메타데이터 전용 스토리지 노드를 사용하여 그리드를 설치할 경우, 그리드에는 객체 스토리지를 위한 최소 개수의 노드도 포함되어야 합니다. 메타데이터 전용 스토리지 노드에 대한 자세한 내용은 "스토리지 노드 유형"을 참조하십시오.
-
단일 사이트 그리드의 경우 객체 및 메타데이터에 대해 2개 이상의 스토리지 노드가 구성됩니다.
-
다중 사이트 그리드의 경우 사이트당 하나 이상의 스토리지 노드가 객체 및 메타데이터에 대해 구성됩니다.
새 스토리지 노드의 볼륨 0에 공간을 할당하는 경우 모든 오브젝트 메타데이터의 해당 노드에 적절한 공간이 있는지 확인해야 합니다.
-
적어도 볼륨 0에 4TB 이상을 할당해야 합니다.
스토리지 노드에 대해 하나의 스토리지 볼륨만 사용하고 볼륨에 4TB 이하의 용량을 할당하면 스토리지 노드가 시작 시 스토리지 읽기 전용 상태로 전환되고 객체 메타데이터만 저장할 수 있습니다.
볼륨 0에 500GB 미만의 용량을 할당할 경우(비운영 전용) 스토리지 볼륨 용량의 10%가 메타데이터용으로 예약됩니다. -
소프트웨어 기반 메타데이터 전용 노드 리소스는 기존 스토리지 노드 리소스와 일치해야 합니다. 예를 들면 다음과 같습니다.
-
기존 StorageGRID 사이트에서 SG6000 또는 SG6100 어플라이언스를 사용 중인 경우 소프트웨어 기반 메타데이터 전용 노드가 다음과 같은 최소 요구사항을 충족해야 합니다.
-
128GB RAM
-
8코어 CPU
-
Cassandra 데이터베이스용 8TB SSD 또는 동급 스토리지(rangedb/0)
-
-
기존 StorageGRID 사이트가 24GB RAM, 8코어 CPU, 3TB 또는 4TB의 메타데이터 스토리지를 갖춘 가상 스토리지 노드를 사용하는 경우, 소프트웨어 기반 메타데이터 전용 노드는 비슷한 리소스(24GB RAM, 8코어 CPU, 4TB의 메타데이터 스토리지(rangedb/0))를 사용해야 합니다.
새 StorageGRID 사이트를 추가할 때 새 사이트의 총 메타데이터 용량은 최소한 기존 StorageGRID 사이트와 일치해야 하며 새 사이트 리소스는 기존 StorageGRID 사이트의 스토리지 노드와 일치해야 합니다.
-
-
새 시스템(StorageGRID 11.6 이상)을 설치하고 각 스토리지 노드에 128MB 이상의 RAM이 있는 경우 볼륨 0에 8TB 이상을 할당합니다. 볼륨 0에 더 큰 값을 사용하면 각 스토리지 노드에서 메타데이터에 허용되는 공간이 증가할 수 있습니다.
-
사이트에 대해 서로 다른 스토리지 노드를 구성할 때 가능하면 볼륨 0에 대해 동일한 설정을 사용하십시오. 사이트에 크기가 다른 스토리지 노드가 포함된 경우 볼륨 0의 크기가 가장 작은 스토리지 노드가 해당 사이트의 메타데이터 용량을 결정합니다.
자세한 내용은 을 "오브젝트 메타데이터 스토리지 관리"참조하십시오.