기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
아마존 FSx 포 러스터 퍼포먼스
널리 사용되는 고성능 파일 시스템인 Lustre를 기반으로 구축된 Amazon FSx for Lustre는 파일 시스템 크기에 따라 선형적으로 증가하는 스케일 아웃 성능을 제공합니다. Lustre 파일 시스템은 여러 파일 서버와 디스크에서 수평적으로 확장됩니다. 이러한 확장을 통해 각 클라이언트는 각 디스크에 저장된 데이터에 직접 액세스하여 기존 파일 시스템에 존재하는 여러 병목 현상을 없앨 수 있습니다. Amazon FSx for Lustre는 Lustre의 확장 가능한 아키텍처를 기반으로 구축되어 많은 클라이언트에서 높은 수준의 성능을 지원합니다.
주제
Lustre 파일 시스템의 작동 방식 FSx
각 FSx for Lustre 파일 시스템은 클라이언트가 통신하는 파일 서버와 데이터를 저장하는 각 파일 서버에 연결된 디스크 세트로 구성됩니다. 각 파일 서버는 고속 인 메모리 캐시를 사용하여 가장 자주 액세스하는 데이터의 성능을 향상시킵니다. HDD또한 기반 파일 시스템에 SSD 기반 읽기 캐시를 제공하여 가장 자주 액세스하는 데이터의 성능을 더욱 향상시킬 수 있습니다. 클라이언트가 인메모리 또는 SSD 캐시에 저장된 데이터에 액세스할 때 파일 서버는 디스크에서 데이터를 읽을 필요가 없으므로 지연 시간이 줄어들고 총 처리량이 늘어납니다. 다음 다이어그램은 쓰기 작업, 디스크에서 제공되는 읽기 작업, 인메모리 또는 캐시에서 제공되는 읽기 작업의 경로를 보여줍니다. SSD
파일 서버의 인메모리 또는 SSD 캐시에 저장된 데이터를 읽을 때 파일 시스템 성능은 네트워크 처리량에 따라 결정됩니다. 파일 시스템에 데이터를 쓰거나 인 메모리 캐시에 저장되지 않은 데이터를 읽을 때 파일 시스템 성능은 네트워크 처리량과 디스크 처리량 중 낮은 값에 따라 결정됩니다.
SSD캐시로 HDD Lustre 파일 시스템을 프로비저닝하면 Amazon은 파일 시스템 HDD 스토리지 용량의 20% 에 맞게 자동으로 크기가 조정되는 SSD 캐시를 FSx 생성합니다. 이렇게 하면 자주 액세스하는 파일에 대해 1밀리초 미만의 지연 시간 이상을 IOPS 제공할 수 있습니다.
집계 파일 시스템 성능
FSxfor Lustre 파일 시스템이 지원하는 처리량은 스토리지 용량에 비례합니다. Amazon FSx for Lustre 파일 시스템은 수백 개의 처리량과 수백만 개의 처리량으로 확장됩니다. GBps IOPS Amazon FSx for Lustre는 수천 개의 컴퓨팅 인스턴스에서 동일한 파일 또는 디렉터리에 대한 동시 액세스도 지원합니다. 이 액세스를 통해 애플리케이션 메모리에서 스토리지로 신속하게 데이터를 체크포인팅할 수 있으며, 이는 고성능 컴퓨팅에서 흔히 사용되는 기술입니다 (). HPC 파일 시스템을 생성한 후 언제든지 필요에 따라 스토리지 용량과 처리량을 늘릴 수 있습니다. 자세한 내용은 스토리지 용량 관리 단원을 참조하십시오.
FSxLustre의 경우 파일 시스템은 평균 대역폭 사용률을 기준으로 네트워크 대역폭을 할당하는 네트워크 I/O 크레딧 메커니즘을 사용하여 버스트 읽기 처리량을 제공합니다. 이러한 파일 시스템의 네트워크 대역폭 사용량이 기준 한도 미만으로 떨어지면 크레딧이 발생하는데, 이 크레딧은 네트워크 데이터를 전송할 때 사용할 수 있습니다.
다음 표에는 FSx for Lustre 배포 옵션이 설계된 성능이 나와 있습니다.
배포 유형 | 네트워크 처리량(프로비저닝된 스토리지의 MB/s/TiB) | 네트워크 IOPS (프로비저닝된 스토리지의 IOPS /TiB) | 캐시 스토리지 (프로비저닝된 스토리지의 GiB 또는 RAM /TiB) | 파일 작업당 디스크 지연 시간(밀리초, P50) | 디스크 처리량 (프로비저닝된 스토리지 또는 SSD 캐시의 MBps /tiB) | ||
---|---|---|---|---|---|---|---|
기준 |
버스트 |
기준 |
버스트 |
||||
SCRATCH_2 | 200 | 1300 | x0,000(기본) x00,000 버스트 |
6.7 |
메타데이터: 밀리초 미만 데이터: 밀리초 미만 |
200(읽기) 100(쓰기) |
‐ |
PERSISTENT-125 | 320 | 1300 | 3.4 |
125 |
500 | ||
PERSISTENT-250 | 640 | 1300 | 6.8 |
250 |
500 | ||
PERSISTENT-500 | 1300 | ‐ | 13.7 | 500 | ‐ |
||
PERSISTENT-1000 | 2600 | ‐ | 27.3 | 1000 | ‐ |
배포 유형 | 네트워크 처리량 (프로비저닝된 스토리지 또는 캐시의 MB/s/tiB) SSD | 네트워크 IOPS (프로비저닝된 스토리지의 IOPS /TiB) | 캐시 스토리지 (프로비저닝된 스토리지의 GiB 또는 RAM /TiB) | 파일 작업당 디스크 지연 시간(밀리초, P50) | 디스크 처리량 (프로비저닝된 스토리지 또는 SSD 캐시의 MBps /tiB) | ||
---|---|---|---|---|---|---|---|
기준 |
버스트 |
기준 |
버스트 |
||||
PERSISTENT-12 | |||||||
HDD스토리지 | 40 | 375* |
x0,000(기본) x00,000 버스트 |
0.4 메모리 |
메타데이터: 밀리초 미만 데이터: 한 자릿수 ms |
12 |
80(읽기) 50(쓰기) |
SSD읽기 캐시 |
200 |
1,900 |
200 SSD 캐시 |
데이터: 밀리초 미만 |
200 |
- |
|
PERSISTENT-40 | |||||||
HDD스토리지 | 150 | 1,300* |
x0,000(기본) x00,000 버스트 |
1.5 |
메타데이터: 밀리초 미만 데이터: 한 자릿수 ms |
40 |
250(읽기) 150(쓰기) |
SSD읽기 캐시 |
750 |
6500 |
200 캐시 SSD |
데이터: 밀리초 미만 |
200 |
- |
배포 유형 | 네트워크 처리량(프로비저닝된 스토리지의 TiB당 MB/s) | 네트워크 IOPS (IOPS프로비저닝된 스토리지의 TiB당) | 캐시 스토리지(프로비저닝된 스토리지의 TiB당 GiB) | 파일 작업당 디스크 지연 시간(밀리초, P50) | 디스크 처리량 (프로비저닝된 스토리지 또는 SSD 캐시의 TiB당 MB/s) | ||
---|---|---|---|---|---|---|---|
기준 |
버스트 |
기준 |
버스트 |
||||
PERSISTENT-50 | 250 | 1,300* | x0,000(기본) x00,000 버스트 |
2.2 RAM |
메타데이터: 밀리초 미만 데이터: 밀리초 미만 |
50 | 240 |
PERSISTENT-100 | 500 | 1,300* | 4.4 RAM | 100 | 240 | ||
PERSISTENT-200 | 750 | 1,300* | 8.8 RAM | 200 | 240 |
참고
*다음의 영구 파일 시스템은 스토리지 TiB당 최대 530MB/s의 네트워크 버스트를 AWS 리전 제공합니다: 아프리카 (케이프타운), 아시아 태평양 (홍콩), 아시아 태평양 (오사카), 아시아 태평양 (싱가포르), 캐나다 (중부), 유럽 (프랑크푸르트), 유럽 (런던), 유럽 (밀라노), 유럽 (스톡홀름), 중동 (바레인), 남아메리카 (상파울루), 중국 및 미국 서부 (로스앤젤레스).
예제: 기준 및 버스트 처리량 총계
다음 예제는 스토리지 용량과 디스크 처리량이 파일 시스템 성능에 미치는 영향을 보여줍니다.
스토리지 용량이 4.8TiB이고 스토리지 유닛당 처리량이 TiB당 50MB/s인 영구 파일 시스템은 총 기준 디스크 처리량이 240MB/s이고 버스트 디스크 처리량은 1.152GB/s입니다.
Amazon FSx for Lustre는 파일 시스템 크기와 관계없이 파일 작업에 대해 1밀리초 미만의 일관된 지연 시간을 제공합니다.
파일 시스템 메타데이터 성능
초당 파일 시스템 메타데이터 입출력 작업 수 (IOPS) 에 따라 초당 생성, 나열, 읽기 및 삭제할 수 있는 파일 및 디렉터리 수가 결정됩니다. 메타데이터는 IOPS 프로비저닝한 스토리지 FSx 용량에 따라 Lustre 파일 시스템에 자동으로 프로비저닝됩니다.
Persistent_2 파일 시스템을 사용하면 스토리지 용량과 IOPS 독립적으로 메타데이터를 프로비저닝할 수 있으며 IOPS 클라이언트 인스턴스가 파일 시스템에서 구동하는 메타데이터의 수와 유형에 대한 가시성을 높일 수 있습니다.
Lustre Persistent_2 파일 시스템의 IOPS 경우 프로비저닝하는 메타데이터 수와 메타데이터 작업 유형에 따라 파일 시스템이 지원할 수 있는 메타데이터 작업 속도가 결정됩니다. FSx 프로비저닝하는 메타데이터 IOPS 수준에 따라 파일 시스템의 메타데이터 디스크에 IOPS 프로비저닝되는 개수가 결정됩니다.
작업 유형 | 프로비저닝된 각 메타데이터에 대해 초당 처리할 수 있는 작업 IOPS |
---|---|
파일 생성, 열기 및 닫기 |
2 |
파일 삭제 |
1 |
디렉터리 생성, 이름 변경 |
0.1 |
디렉터리 삭제 |
0.2 |
자동 모드 또는 사용자 제공 모드를 IOPS 사용하여 메타데이터를 프로비전하도록 선택할 수 있습니다. 자동 모드에서 Amazon은 아래 표에 따라 파일 시스템의 스토리지 용량을 IOPS 기준으로 메타데이터를 FSx 자동으로 프로비저닝합니다.
파일 시스템 스토리지 용량 | 자동 모드에 포함된 메타데이터 IOPS |
---|---|
1200 GiB |
1500 |
2400 GiB |
3000 |
4800—9600기가바이트 |
6000 |
12000—45600 기가바이트 |
12000 |
48000 기가바이트 이상 |
24000 IOPS 기가바이트당 12000 |
사용자 프로비저닝 모드에서는 프로비저닝할 메타데이터 수를 선택적으로 지정할 수 있습니다. IOPS 파일 시스템의 기본 메타데이터 수보다 많이 IOPS 프로비전된 메타데이터에 IOPS 대한 비용을 지불합니다.
파일 시스템 스토리지 레이아웃
Lustre의 모든 파일 데이터는 오브젝트 스토리지 타겟 () 이라는 스토리지 볼륨에 저장됩니다. OSTs 모든 파일 메타데이터 (파일 이름, 타임스탬프, 권한 등 포함) 는 메타데이터 대상 () 이라는 스토리지 볼륨에 저장됩니다. MDTs Amazon FSx for Lustre 파일 시스템은 하나 이상의 MDTs 여러 개로 구성되어 있습니다. OSTs 파일 시스템의 배포 유형에 따라 각각의 OST 크기는 약 1~2TiB입니다. Amazon FSx for Lustre는 파일 시스템을 OSTs 구성하는 모든 영역에 파일 데이터를 분산하여 스토리지 용량과 처리량 및 IOPS 부하의 균형을 유지합니다.
파일 시스템을 OSTs 구성하는 NAD의 스토리지 사용량을 보려면 파일 시스템이 마운트된 클라이언트에서 다음 명령을 실행하십시오. MDT
lfs df -h
mount/path
이 명령의 출력은 다음과 같습니다.
UUID bytes Used Available Use% Mounted on
mountname
-MDT0000_UUID 68.7G 5.4M 68.7G 0% /fsx[MDT:0]mountname
-OST0000_UUID 1.1T 4.5M 1.1T 0% /fsx[OST:0]mountname
-OST0001_UUID 1.1T 4.5M 1.1T 0% /fsx[OST:1] filesystem_summary: 2.2T 9.0M 2.2T 0% /fsx
파일 시스템의 스트라이핑 데이터
파일 스트라이핑으로 파일 시스템의 처리량 성능을 최적화할 수 있습니다. Amazon FSx for Lustre는 모든 스토리지 서버에서 데이터가 제공되도록 하기 위해 파일을 자동으로 OSTs 분산합니다. 파일이 여러 곳에 스트라이핑되는 방식을 구성하여 파일 수준에서 동일한 개념을 적용할 수 있습니다. OSTs
스트라이핑이란 파일을 여러 청크로 나눈 다음 여러 청크에 저장할 수 있다는 뜻입니다. OSTs 파일이 여러 OSTs 개에 걸쳐 스트라이핑되면 파일에 대한 읽기 또는 쓰기 요청이 해당 OSTs 파일에 분산되어 총 처리량이 증가하거나 IOPS 애플리케이션이 처리량을 처리할 수 있습니다.
다음은 Amazon FSx for Lustre 파일 시스템의 기본 레이아웃입니다.
2020년 12월 18일 이전에 생성된 파일 시스템의 경우 기본 레이아웃은 스트라이프 수를 1로 지정합니다. 즉, 다른 레이아웃을 지정하지 않는 한 Amazon FSx for Lustre에서 표준 Linux 도구를 사용하여 만든 각 파일은 단일 디스크에 저장됩니다.
2020년 12월 18일 이후에 생성된 파일 시스템의 경우 기본 레이아웃은 크기가 1GiB 미만인 파일이 하나의 스트라이프에 저장되는 프로그레시브 파일 레이아웃이고 큰 파일에는 스트라이프 수 5가 할당됩니다.
2023년 8월 25일 이후에 생성된 파일 시스템의 경우 기본 레이아웃은 프로그레시브 파일 레이아웃에서 설명하는 4구성 요소 프로그레시브 파일 레이아웃입니다.
생성 날짜와 상관없이 모든 파일 시스템에서 Amazon S3에서 가져온 파일은 기본 레이아웃을 사용하지 않고 대신 파일 시스템
ImportedFileChunkSize
파라미터의 레이아웃을 사용합니다. S3에서 가져온 파일 크기가 인보다ImportedFileChunkSize
크면 스트라이프 수가 1개인 여러 OSTs 개에 저장됩니다.(FileSize / ImportedFileChunksize) + 1
ImportedFileChunkSize
의 기본값은 1GiB입니다.
lfs getstripe
명령을 사용하여 파일 또는 디렉터리의 레이아웃 구성을 볼 수 있습니다.
lfs getstripe
path/to/filename
이 명령은 파일의 스트라이프 수, 스트라이프 크기 및 스트라이프 오프셋을 보고합니다. 스트라이프 수는 OSTs 스트라이핑된 파일 수입니다. 스트라이프 크기는 저장되는 연속 데이터의 양입니다. OST 스트라이프 오프셋은 파일이 OST 스트라이핑되는 첫 번째 항목의 인덱스입니다.
스트라이핑 구성 수정
파일의 레이아웃 파라미터는 파일이 처음 생성될 때 설정됩니다. lfs setstripe
명령을 사용하여 지정된 레이아웃에 비어 있는 새 파일을 생성합니다.
lfs setstripe
filename
--stripe-countnumber_of_OSTs
이 lfs setstripe
명령은 새 파일의 레이아웃에만 영향을 줍니다. 파일을 만들기 전에 이 명령을 사용하여 파일의 레이아웃을 지정할 수 있습니다. 디렉터리의 레이아웃을 정의할 수도 있습니다. 디렉터리에 설정된 레이아웃은 해당 디렉터리에 추가되는 모든 새 파일에 적용되지만 기존 파일에는 적용되지 않습니다. 새로 만드는 모든 하위 디렉터리도 새 레이아웃을 상속하며, 이 레이아웃은 해당 하위 디렉터리 내에 새로 만드는 모든 파일 또는 디렉터리에 적용됩니다.
기존 파일의 레이아웃을 수정하려면 lfs migrate
명령을 사용합니다. 이 명령은 필요에 따라 파일을 복사하여 명령에서 지정한 레이아웃에 따라 내용을 배포합니다. 예를 들어 파일을 추가하거나 크기를 늘려도 스트라이프 수는 변경되지 않으므로 파일을 마이그레이션하여 파일 레이아웃을 변경해야 합니다. 또는 lfs setstripe
명령을 사용하여 새 파일을 만들어 레이아웃을 지정하고 원본 내용을 새 파일에 복사한 다음 새 파일의 이름을 변경하여 원본 파일을 대체할 수 있습니다.
기본 레이아웃 구성이 워크로드에 최적화되지 않는 경우가 있을 수 있습니다. 예를 들어 수십 개의 멀티기가바이트 파일이 있는 파일 시스템에서는 기본 스트라이프 수 값인 5개를 초과하여 파일을 스트라이핑하면 성능이 향상될 수 있습니다. OSTs OSTs 스트라이프 수가 적은 대용량 파일을 만들면 I/O 성능 병목 현상이 발생할 수 있으며 용량이 가득 찰 수도 있습니다. OSTs 이 경우 이러한 파일에 대해 스트라이프 수가 더 많은 디렉터리를 만들 수 있습니다.
대용량 파일(특히 크기가 1GB보다 큰 파일)의 스트라이프 레이아웃을 설정하는 것은 다음과 같은 이유로 중요합니다.
대용량 파일을 읽고 쓸 때 여러 서버 OSTs 및 관련 서버IOPS, 네트워크 대역폭 및 CPU 리소스가 제공되므로 처리량이 향상됩니다.
일부 하위 집합이 전체 워크로드 성능을 제한하는 핫스팟이 OSTs 될 가능성을 줄입니다.
하나의 큰 파일이 파일을 가득 채워 디스크 전체 오류가 발생할 수 있는 문제를 방지합니다. OST
모든 사용 사례에 최적화된 단일 레이아웃 구성은 없습니다. 파일 레이아웃에 대한 자세한 지침은 Lustre.org 설명서의 파일 레이아웃(스트라이핑) 및 여유 공간 관리
스트라이프 레이아웃은 대용량 파일, 특히 파일 크기가 일반적으로 수백 메가바이트 이상인 사용 사례에서 가장 중요합니다. 이러한 이유로 새 파일 시스템의 기본 레이아웃에서는 크기가 1GiB를 초과하는 파일에 대해 스트라이프 수를 5개로 지정합니다.
스트라이프 수는 대용량 파일을 지원하는 시스템에 맞게 조정해야 하는 레이아웃 파라미터입니다. 스트라이프 수는 스트라이프 파일의 청크를 담을 OST 볼륨 수를 지정합니다. 예를 들어 스트라이프 수가 2이고 스트라이프 크기가 1MiB인 경우 Lustre는 파일의 1MiB 청크를 각각 두 개에 대체 기록합니다. OSTs
유효 스트라이프 수는 실제 볼륨 수와 지정한 스트라이프 수 값 중 적은 수입니다. OST 특수 스트라이프 수 값을 사용하여 모든 볼륨에 스트라이프를
-1
배치하도록 지정할 수 있습니다. OST파일이 너무 작아서 모든 볼륨의 공간을 차지할 수 없는 경우에도 특정 작업의 경우 OST Lustre에서 모든 레이아웃으로 네트워크 왕복을 해야 하기 때문에 작은 파일에 대해 큰 스트라이프 수를 설정하는 것은 최적이 아닙니다. OST
크기에 따라 파일 레이아웃을 변경할 수 있는 점진적 파일 레이아웃 (PFL) 을 설정할 수 있습니다. PFL구성을 사용하면 각 파일에 대해 구성을 명시적으로 설정할 필요 없이 크고 작은 파일이 조합된 파일 시스템을 간편하게 관리할 수 있습니다. 자세한 내용은 프로그레시브 파일 레이아웃 단원을 참조하십시오.
스트라이프 크기는 기본적으로 1MiB입니다. 스트라이프 오프셋 설정은 특별한 경우에 유용할 수 있지만 일반적으로 지정하지 않고 기본값을 사용하는 것이 가장 좋습니다.
프로그레시브 파일 레이아웃
디렉토리의 프로그레시브 파일 레이아웃 (PFL) 구성을 지정하여 작은 파일과 큰 파일을 채우기 전에 각각 다른 스트라이프 구성을 지정할 수 있습니다. 예를 들어 새 파일 PFL 시스템에 데이터를 쓰기 전에 최상위 디렉토리에 a를 설정할 수 있습니다.
PFL구성을 지정하려면 다음 명령과 같이 lfs setstripe
명령을 -E
옵션과 함께 사용하여 크기가 다른 파일의 레이아웃 구성요소를 지정합니다.
lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32
/mountname/directory
이 명령은 네 가지 레이아웃 구성 요소를 설정합니다.
첫 번째 구성 요소(
-E 100M -c 1
)는 최대 100MiB 크기의 파일에 대한 스트라이프 수 값 1을 나타냅니다.두 번째 구성 요소(
-E 10G -c 8
)는 최대 10GiB 크기의 파일에 대한 스트라이프 수 8을 나타냅니다.세 번째 구성 요소(
-E 100G -c 16
)는 최대 100GiB 크기의 파일에 대한 스트라이프 수가 16개임을 나타냅니다.네 번째 구성 요소(
-E -1 -c 32
)는 100GiB보다 큰 파일의 스트라이프 수가 32개임을 나타냅니다.
중요
레이아웃으로 만든 파일에 데이터를 추가하면 해당 PFL 레이아웃 구성요소가 모두 채워집니다. 예를 들어 위에 표시된 4가지 구성 요소 명령을 사용하여 1MiB 파일을 만든 다음 그 끝에 데이터를 추가하면 파일의 레이아웃이 스트라이프 수가 -1이 되도록 확장됩니다. 즉, 시스템에 있는 모든 파일을 의미합니다. OSTs 그렇다고 데이터가 모든 곳에 쓰여지는 것은 아니지만OST, 파일 길이를 읽는 것과 같은 작업을 수행하면 모든 OST 파일에 병렬로 요청이 전송되므로 파일 시스템에 상당한 네트워크 부하가 가중됩니다.
따라서 나중에 데이터가 추가될 수 있는 작거나 중간 길이의 파일에서는 스트라이프 수를 제한해야 한다는 점을 유의하세요. 일반적으로 새 레코드가 추가되면 로그 파일이 커지므로 Amazon FSx for Lustre는 상위 디렉터리에 지정된 기본 스트라이프 구성과 상관없이 추가 모드에서 생성되는 모든 파일에 기본 스트라이프 개수 1을 할당합니다.
2023년 8월 25일 이후에 생성된 Amazon FSx for Lustre 파일 시스템의 기본 PFL 구성은 다음 명령으로 설정됩니다.
lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32
/mountname
워크로드가 중대형 파일에 대한 동시 액세스 빈도가 높은 고객은 네 가지 구성 요소 예제 레이아웃에서 볼 수 있듯이 작은 크기에서 더 많은 스트라이프를 사용하고 가장 큰 파일에는 전체에 스트라이핑을 적용하는 레이아웃을 사용하는 것이 OSTs 좋습니다.
성능 및 사용량 모니터링
Amazon FSx for Lustre는 1분마다 각 디스크 (MDT및) 에 대한 사용량 지표를 Amazon에 OST 내보냅니다. CloudWatch
전체 파일 시스템 사용량 세부 정보를 보려면 각 지표의 합계 통계를 보면 됩니다. 예를 들어, DataReadBytes
통계 합계는 파일 시스템에 있는 모든 사용자가 확인한 총 읽기 처리량을 보고합니다OSTs. 마찬가지로 FreeDataStorageCapacity
통계 합계는 파일 시스템의 파일 데이터에 사용할 수 있는 총 스토리지 용량을 보고합니다.
파일 시스템 성능 모니터링에 대한 자세한 내용은 Amazon FSx for Lustre 모니터링 섹션을 참조하세요.
성능 팁
Amazon FSx for Lustre를 사용할 때는 다음과 같은 성능 팁을 염두에 두십시오. 서비스 제한은 아마존 FSx for Lustre에 대한 할당량 섹션을 참조하세요.
-
평균 I/O 크기 — Amazon FSx for Lustre는 네트워크 파일 시스템이므로 각 파일 작업은 클라이언트와 Amazon FSx for Lustre를 왕복하며, 이로 인해 약간의 지연 시간 오버헤드가 발생합니다. 이렇게 작업당 지연 시간이 있으므로 평균 I/O 크기가 늘어남에 따라 전체 처리량도 대개 증가합니다. 대량의 데이터에 대해 오버헤드가 분할 사용되기 때문입니다.
-
요청 모델 — 파일 시스템에 대한 비동기 쓰기를 활성화하면 보류 중인 쓰기 작업이 Amazon for Lustre에 비동기적으로 기록되기 전에 EC2 Amazon 인스턴스에서 버퍼링됩니다. FSx 비동기 쓰기는 일반적으로 지연 시간이 더 짧습니다. 비동기 쓰기를 수행하는 경우 커널은 캐싱에 추가 메모리를 사용합니다. 동기 쓰기가 활성화된 파일 시스템은 Amazon FSx for Lustre에 동기 요청을 보냅니다. 모든 작업은 클라이언트와 Amazon FSx for Lustre를 오가는 왕복 과정을 거칩니다.
참고
선택한 요청 모델은 일관성 (여러 Amazon EC2 인스턴스를 사용하는 경우) 과 속도 측면에서 절충점이 있습니다.
-
디렉터리 크기 제한 - Persistent_2 FSx for Lustre 파일 시스템에서 최적의 메타데이터 성능을 달성하려면 각 디렉터리를 10만 개 미만의 파일로 제한하십시오. 디렉터리의 파일 수를 제한하면 파일 시스템이 상위 디렉터리를 잠그는 데 필요한 시간을 줄일 수 있습니다.
-
Amazon EC2 인스턴스 — 읽기 및 쓰기 작업을 많이 수행하는 애플리케이션은 그렇지 않은 애플리케이션보다 더 많은 메모리 또는 컴퓨팅 용량이 필요할 수 있습니다. 컴퓨팅 집약적인 워크로드를 위해 Amazon EC2 인스턴스를 시작할 때는 애플리케이션에 필요한 만큼의 리소스를 갖춘 인스턴스 유형을 선택하십시오. Amazon FSx for Lustre 파일 시스템의 성능 특성은 Amazon EBS 최적화 인스턴스의 사용에 좌우되지 않습니다.
-
최적의 성능을 위한 권장 클라이언트 인스턴스 튜닝
모든 클라이언트 인스턴스 유형 및 크기에 대해 다음 조정을 적용하는 것이 좋습니다.
sudo lctl set_param osc.*.max_dirty_mb=64
메모리가 64GiB를 초과하는 클라이언트 인스턴스 유형의 경우 다음 조정을 적용하는 것이 좋습니다.
sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000 sudo lctl set_param ldlm.namespaces.*.lru_size=<100 *
number_of_CPUs
>64v CPU 코어가 넘는 클라이언트 인스턴스 유형의 경우 다음 조정을 적용하는 것이 좋습니다.
echo "options ptlrpc ptlrpcd_per_cpt_max=32" >> /etc/modprobe.d/modprobe.conf echo "options ksocklnd credits=2560" >> /etc/modprobe.d/modprobe.conf # reload all kernel modules to apply the above two settings sudo reboot
클라이언트가 마운트된 후에는 다음 튜닝을 적용해야 합니다.
sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32 sudo lctl set_param mdc.*.max_rpcs_in_flight=64 sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50
lctl set_param
은 재부팅하는 경우 지속되지 않는 것으로 알려져 있습니다. 이러한 파라미터는 클라이언트 측에서 영구적으로 설정할 수 없으므로 부팅 크론 작업을 구현하여 권장 튜닝으로 구성을 설정하는 것이 좋습니다. -
전체 워크로드 밸런싱 OSTs — 파일 시스템이 제공할 수 있는 총 처리량 (스토리지 TiB당 200MB/s) 을 워크로드로 인해 주도하지 못하는 경우도 있습니다. 그렇다면 CloudWatch 메트릭을 사용하여 워크로드 I/O 패턴의 불균형으로 인해 성능이 영향을 받는지 여부를 해결할 수 있습니다. 이것이 원인인지 확인하려면 Amazon FSx for Lustre의 최대 CloudWatch 측정치를 살펴보십시오.
경우에 따라 이 통계는 처리량 (단일 1.2TiB FSx Amazon for Lustre MBps 디스크의 처리 용량) 의 240을 초과하는 부하를 보여줍니다. 이 경우 워크로드가 디스크 전체에 고르게 분산되지 않습니다. 이 경우
lfs setstripe
명령을 사용하여 워크로드에서 가장 자주 액세스하는 파일의 스트라이핑을 수정할 수 있습니다. 최적의 성능을 위해 처리량 요구 사항이 높은 파일을 파일 시스템을 구성하는 모든 파일에 스트라이핑하십시오. OSTs파일을 데이터 리포지토리에서 가져오는 경우 처리량이 높은 파일을 데이터 저장소에 고르게 스트라이핑하는 다른 방법을 사용할 수 있습니다. OSTs 이렇게 하려면 다음 Amazon FSx for Lustre 파일 시스템을 생성할 때
ImportedFileChunkSize
파라미터를 수정하면 됩니다.예를 들어, 워크로드가 7.0TiB 파일 시스템 (6x 1.17TiB로 구성OSTs) 을 사용하고 2.4GiB 파일에서 높은 처리량을 구현해야 한다고 가정해 보겠습니다. 이 경우 파일이 파일 시스템 전체에 균등하게
(2.4 GiB / 6 OSTs) = 400 MiB
분산되도록ImportedFileChunkSize
값을 로 설정할 수 있습니다. OSTs -
메타데이터용 Lustre 클라이언트 IOPS - 파일 시스템에 메타데이터 구성이 지정된 경우, 다음 OS 버전 (아마존 리눅스 2023, 아마존 리눅스 2, 레드햇/록키 리눅스 8.9, 8.10 또는 9.x, CentOS 8.9 또는 8.10, 6.2 또는 6.5 커널이 설치된 우분투 22, 우분투 20) 중 하나를 사용하는 Lustre 2.15 클라이언트 또는 Lustre 2.12 클라이언트를 설치하는 것이 좋습니다..