기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Tape Gateway의 성능 및 최적화
이 섹션에서는 Storage Gateway 성능에 대해 설명합니다.
Tape Gateway의 성능 지침
이 섹션에서는 Tape Gateway VM에 하드웨어를 프로비저닝하기 위한 구성 지침을 알아봅니다. 표에 나와 있는 Amazon EC2 인스턴스 크기와 유형은 예시이며 참고용으로 제공됩니다.
구성 | 쓰기 처리량 Gbps | 캐시에서 읽기 처리량 Gbps | Amazon Web Services 클라우드에서 읽기 처리량(GBps) |
---|---|---|---|
호스트 플랫폼: Amazon EC2 인스턴스 - c5.4xlarge CPU: 16 vCPU | RAM: 32GB 루트 디스크: 80GB, io1 SSD, 4,000 IOPS 캐시 디스크: 스트라이프 RAID(2 x 500GB, io1 EBS SSD, 25000 IOPs) 업로드 버퍼 디스크: 450GB, io1 SSD, 2000IOPS 클라우드 측 네트워크 대역폭: 10Gbps |
2.3 | 4.0 | 2.2 |
호스트 플랫폼: Storage Gateway 하드웨어 어플라이언스 캐시 디스크: 2.5TB 업로드 버퍼 디스크: 2TB 클라우드 측 네트워크 대역폭: 10Gbps |
2.3 | 8.8 | 3.8 |
호스트 플랫폼: Amazon EC2 인스턴스 - c5d.9xlarge CPU: 36 vCPU | RAM: 72GB 루트 디스크: 80GB, io1 SSD, 4,000 IOPS 캐시 디스크: 900GB NVMe 디스크 업로드 버퍼 디스크: 900GB NVMe 디스크 클라우드 측 네트워크 대역폭: 10Gbps |
5.2 | 11.6 | 5.2 |
호스트 플랫폼: Amazon EC2 인스턴스 - c5d.metal CPU: 96 vCPU | RAM: 192GB 루트 디스크: 80GB, io1 SSD, 4,000 IOPS 캐시 디스크: 스트라이프 RAID(2 x 900GB NVMe 디스크) 업로드 버퍼 디스크: 900GB NVMe 디스크 클라우드 측 네트워크 대역폭: 10Gbps |
5.2 | 11.6 | 7.2 |
참고
해당 성능은 1개의 1MB 블록 크기와 10개의 테이프 드라이브를 동시에 사용한 경우입니다.
위 표의 EC2 구성은 유사한 리소스를 사용하는 자체 물리적 서버에서 얻을 수 있는 성능을 대표적으로 보여주기 위한 것입니다. 예를 들어, 스트라이프 RAID를 사용하는 EC2 구성은 일반적으로 EC2의 게이트웨이에서 지원하지 않는 특수 메커니즘을 통해 이루어졌습니다. 비슷한 성능을 얻으려면 게이트웨이를 실행하는 온프레미스 서버에 연결된 하드웨어 RAID 컨트롤러를 대신 사용해야 합니다.
성능은 호스트 플랫폼 구성 및 네트워크 대역폭에 따라 달라질 수 있습니다.
Tape Gateway의 쓰기 및 읽기 처리량 성능을 향상시키려면 iSCSI 설정 최적화, 테이프 드라이브에 더 큰 블록 크기 사용, 백업 소프트웨어의 가상 테이프 드라이브 성능 최적화 섹션을 참조하세요.
게이트웨이 성능 최적화
권장되는 게이트웨이 서버 구성
게이트웨이의 성능을 극대화하기 위해 Storage Gateway는 게이트웨이 호스트 서버에 다음과 같은 게이트웨이 구성을 권장합니다.
-
최소 24개의 전용 물리적 CPU 코어
-
Tape Gateway의 경우 하드웨어에 할당해야 하는 RAM 양은 다음과 같습니다.
-
최소 16GiB의 예약 RAM(캐시 크기가 최대 16TiB인 게이트웨이)
-
최소 32GiB의 예약 RAM(캐시 크기가 16Ti-32TiB인 게이트웨이)
-
최소 48GiB의 예약 RAM(캐시 크기가 32Ti-64TiB인 게이트웨이)
참고
게이트웨이 성능을 최적화하려면 최소 32GiB의 RAM을 프로비저닝해야 합니다.
-
-
디스크 1 - 다음과 같이 게이트웨이 캐시로 사용됨
-
NVMe SSD로 구성된 스트라이프 RAID(독립 디스크의 중복 어레이)
-
-
디스크 2 - 다음과 같이 게이트웨이 업로드 버퍼로 사용됨
-
NVMe SSD로 구성된 스트라이프 RAID
-
-
디스크 3 - 다음과 같이 게이트웨이 업로드 버퍼로 사용됨
-
NVMe SSD로 구성된 스트라이프 RAID
-
-
VM 네트워크 1에 구성된 네트워크 어댑터 1:
-
VM 네트워크 1을 사용하고 수집에 사용할 VMXNet3(10Gbps)를 추가합니다.
-
-
VM 네트워크 2에 구성된 네트워크 어댑터 2:
-
VM 네트워크 2를 사용하고 AWS에 연결하는 데 사용할 VMXNet3(10Gbps)를 추가합니다.
-
게이트웨이에 리소스 추가
다음과 같은 병목 현상이 발생할 경우 Tape Gateway 의 성능이 이론상 최대 지속 처리량(AWS 클라우드로의 대역폭) 이하로 저하될 수 있습니다.
-
CPU 코어 수
-
캐시/업로드 버퍼 디스크 처리량
-
총 RAM 용량
-
AWS로의 네트워크 대역폭
-
이니시에이터에서 게이트웨이까지의 네트워크 대역폭
이 섹션에서는 게이트웨이 성능을 최적화하기 위해 수행할 수 있는 단계에 대해 다룹니다. 이 지침은 게이트웨이 또는 애플리케이션 서버에 리소스를 추가하는 것을 전제로 합니다.
다음 중 하나 이상의 방법으로 게이트웨이에 리소스를 추가하여 게이트웨이 성능을 최적화할 수 있습니다.
- 고성능 디스크 사용
-
캐시 및 업로드 버퍼 디스크 처리량으로 인해 게이트웨이의 업로드 및 다운로드 성능이 제한될 수 있습니다. 게이트웨이 성능이 예상보다 현저히 낮은 경우 다음과 같이 캐시 및 업로드 버퍼 디스크 처리량을 개선하는 것이 좋습니다.
-
스트라이프 RAID(예: RAID 10)를 사용하여 디스크 처리량을 개선합니다. 하드웨어 RAID 컨트롤러를 사용하는 것이 가장 좋습니다.
참고
RAID(Redundant Array of Independent Disk) 또는 특히 RAID 10과 같은 디스크 스트라이프 RAID 구성은 데이터 본문을 블록으로 나누고 데이터 블록을 여러 스토리지 디바이스에 분산하는 프로세스입니다. 사용하는 RAID 수준은 달성할 수 있는 정확한 속도와 내결함성에 영향을 줍니다. I/O 워크로드를 여러 디스크에 분산하므로 RAID 디바이스의 전체 처리량은 단일 멤버 디스크의 처리량보다 훨씬 높습니다.
-
직접 연결된 고성능 디스크 사용
게이트웨이 성능을 최적화하기 위해 SSD(Solid-State Drive) 및 NVMe 컨트롤러와 같은 고성능 디스크를 추가할 수 있습니다. Microsoft Hyper-V NTFS 대신 스토리지 영역 네트워크(SAN)에서 직접 가상 디스크를 VM에 연결할 수도 있습니다. 디스크 성능이 향상되면 일반적으로 처리량과 초당 입출력 작업 처리량(IOPS)이 증가합니다.
처리량을 측정하려면
ReadBytes
및WriteBytes
지표를Samples
Amazon CloudWatch 통계와 함께 사용합니다. 예를 들어, 5분의 샘플 기간 동안의ReadBytes
지표의Samples
통계를 300초로 나누면 IOPS를 알 수 있습니다. 일반적으로 게이트웨이에 대한 이러한 지표를 검토할 때는 디스크 관련 병목 현상을 나타내는 낮은 처리량과 낮은 IOPS 추세를 살펴보세요. 게이트웨이 지표에 대한 자세한 내용은 Tape Gateway와 AWS 간 성능 측정 섹션을 참조하세요.참고
CloudWatch 지표를 모든 게이트웨이에 사용할 수 있는 것은 아닙니다. 게이트웨이 지표에 대한 자세한 내용은 Storage Gateway 모니터링 섹션을 참조하세요.
-
- 업로드 버퍼 디스크 추가
-
쓰기 처리량을 높이려면 업로드 버퍼 디스크를 두 개 이상 추가하십시오. 데이터가 게이트웨이에 기록되면 업로드 버퍼 디스크에 로컬로 기록되고 저장됩니다. 그런 다음 저장된 로컬 데이터를 디스크에서 비동기적으로 읽고 처리한 뒤 AWS에 업로드합니다. 업로드 버퍼 디스크를 추가하면 각 개별 디스크에서 수행되는 동시 I/O 작업의 양을 줄일 수 있습니다. 이로 인해 게이트웨이에 대한 쓰기 처리량이 증가할 수 있습니다.
- 별도의 물리적 디스크로 게이트웨이 가상 디스크 지원
-
게이트웨이 디스크를 프로비저닝할 때는 동일한 기본 물리적 스토리지 디스크를 사용하는 업로드 버퍼 및 캐시 스토리지에 로컬 디스크를 프로비저닝하지 않는 것이 좋습니다. 예를 들어, VMware ESXi에서는 기본 물리적 스토리지 리소스가 데이터 스토어로 표시됩니다. 게이트웨이 VM을 배포할 경우, VM 파일을 저장할 데이터 스토어를 선택합니다. 가상 디스크를 프로비저닝할 때(예: 업로드 버퍼 용도) 가상 디스크를 VM과 동일한 데이터 스토어 또는 다른 데이터 스토어에 저장할 수 있습니다.
데이터 스토어가 두 개 이상인 경우 생성하는 로컬 스토리지의 유형별로 하나씩 데이터 스토어를 선택하는 것이 좋습니다. 기본 물리적 디스크 하나로만 지원되는 데이터 스토어는 성능 저하로 이어질 수 있습니다. 게이트웨이 설정에서 이러한 디스크를 사용하여 캐시 스토리지와 업로드 버퍼를 모두 지원하는 경우를 예로 들 수 있습니다. 마찬가지로, RAID 1 또는 RAID 6와 같이 성능이 낮은 RAID 구성을 통해 지원되는 데이터 스토어는 성능이 저하될 수 있습니다.
- 게이트웨이 호스트에 CPU 리소스 추가
-
게이트웨이 호스트 서버의 최소 요구 사항은 가상 프로세서 4개입니다. 게이트웨이 성능을 최적화하려면 게이트웨이 VM에 할당된 각 가상 프로세서에 전용 CPU 코어가 지원되는지 확인합니다. 또한 호스트 서버의 CPU를 과다 구독하고 있지 않은지 확인합니다.
게이트웨이 호스트 서버에 CPU를 추가하면 게이트웨이의 처리 능력이 향상됩니다. 이렇게 하면 게이트웨이가 애플리케이션의 데이터를 로컬 스토리지에 저장하고 이 데이터를 Amazon S3로 업로드하는 작업을 병렬로 처리할 수 있습니다. CPU를 추가하면 호스트를 다른 VM과 공유할 때 게이트웨이가 충분한 CPU 리소스를 확보할 수 있습니다. CPU 리소스를 충분히 제공하면 일반적으로 처리량이 향상되는 효과가 있습니다.
- 게이트웨이와 AWS 클라우드 간 대역폭 늘리기
-
AWS와 주고받는 대역폭을 늘리면 게이트웨이로 들어오는 데이터의 최대 속도와 AWS 클라우드로 나가는 데이터의 최대 속도가 증가합니다. 이렇게 하면 느린 디스크나 낮은 게이트웨이-이니시에이터 연결 대역폭과 같은 다른 요인보다 네트워크 속도가 게이트웨이 구성의 제한 요소인 경우 게이트웨이 성능을 개선할 수 있습니다.
AWS와 주고받는 네트워크 대역폭은 지속적인 워크로드 동안 Tape Gateway의 이론상 최대 평균 성능을 정의합니다.
-
Tape Gateway에 장기간 데이터를 쓸 수 있는 평균 속도는 AWS로의 업로드 대역폭을 초과하지 않습니다.
-
Tape Gateway에서 장기간 데이터를 읽을 수 있는 평균 속도는 AWS로의 다운로드 대역폭을 초과하지 않습니다.
참고
캐시/업로드 버퍼 디스크 처리량, CPU 코어 수, 총 RAM 용량 또는 이니시에이터와 게이트웨이 간 대역폭 등 여기에 나열된 다른 제한 요인으로 인해 관찰된 게이트웨이 성능이 네트워크 대역폭보다 낮을 수 있습니다. 또한, 게이트웨이의 정상 작동에는 데이터를 보호하기 위한 여러 가지 조치가 포함되므로 관찰된 성능이 네트워크 대역폭보다 낮을 수 있습니다.
-
iSCSI 설정 최적화
iSCSI 초기자에서 iSCSI 설정을 최적화하여 I/O 성능을 높일 수 있습니다. MaxReceiveDataSegmentLength
및 FirstBurstLength
에는 256 KiB를 선택하고, MaxBurstLength
에는 1MiB를 선택하는 것이 좋습니다. iSCSI 설정 구성에 대한 자세한 내용은 iSCSI 설정 사용자 지정 단원을 참조하십시오.
참고
이러한 권장 설정을 통해 전반적으로 더 나은 성능을 실현할 수 있습니다. 그러나 성능을 최적화하는 데 필요한 특정 iSCSI 설정은 사용하는 백업 소프트웨어에 따라 다릅니다. 자세한 내용은 백업 소프트웨어 설명서를 참조하십시오.
테이프 드라이브에 더 큰 블록 크기 사용
Tape Gateway의 경우 테이프 드라이브의 기본 블록 크기는 64KB입니다. 하지만 블록 크기를 최대 1MB까지 늘려 I/O 성능을 향상시킬 수 있습니다.
선택하는 블록 크기는 백업 소프트웨어가 지원하는 최대 블록 크기에 따라 달라집니다. 백업 소프트웨어에서 테이프 드라이브의 블록 크기를 가능한 한 크게 설정하는 것이 좋습니다. 그러나 이 블록 크기는 게이트웨이가 지원하는 최대 크기인 1MB를 초과해서는 안됩니다.
Tape Gateway는 백업 소프트웨어에 설정된 크기와 자동으로 일치하도록 가상 테이프 드라이브의 블록 크기를 협상합니다. 백업 소프트웨어에서 블록 크기를 늘릴 때는 설정을 확인하여 호스트 이니시에이터가 새 블록 크기를 지원하는지도 확인하는 것이 좋습니다. 자세한 내용은 사용 중인 백업 소프트웨어의 설명서를 참조하세요. 특정 게이트웨이 성능 지침에 대한 자세한 내용은 Tape Gateway의 성능 및 최적화 섹션을 참조하세요.
백업 소프트웨어의 가상 테이프 드라이브 성능 최적화
백업 소프트웨어는 Tape Gateway에 있는 최대 10개의 가상 테이프 드라이브에 데이터를 동시에 백업할 수 있습니다. Tape Gateway에서 최소 4개의 가상 테이프 드라이브를 동시에 사용하도록 백업 소프트웨어의 백업 작업을 구성하는 것이 좋습니다. 백업 소프트웨어가 동시에 둘 이상의 가상 테이프에 데이터를 백업하면 쓰기 처리량을 높일 수 있습니다.
일반적으로 더 많은 가상 테이프에서 동시에 작업(읽기 또는 쓰기)을 수행하면 최대 처리량을 높일 수 있습니다. 테이프 드라이브를 더 많이 사용하면 게이트웨이에서 더 많은 요청을 동시에 처리할 수 있어 성능이 향상될 수 있습니다.
애플리케이션 환경에 리소스 추가
- 애플리케이션 서버와 게이트웨이 간의 대역폭 늘리기
-
iSCSI 이니시에이터와 게이트웨이 간의 연결로 인해 업로드 및 다운로드 성능이 제한될 수 있습니다. 게이트웨이의 성능이 예상보다 현저히 떨어지는데 CPU 코어 수와 디스크 처리량을 이미 개선했다면 다음 사항을 고려하세요.
-
네트워크 케이블을 업그레이드하여 이니시에이터와 게이트웨이 간에 더 높은 대역폭을 확보합니다.
-
가능한 한 많은 테이프 드라이브를 동시에 사용합니다. iSCSI는 동일한 대상에 대해 여러 요청을 대기열에 넣는 것을 지원하지 않습니다. 즉, 테이프 드라이브를 많이 사용할수록 게이트웨이에서 동시에 처리할 수 있는 요청도 많아집니다. 이렇게 하면 게이트웨이와 이니시에이터 간의 대역폭을 최대한 활용하여 게이트웨이의 예상 처리량을 늘릴 수 있습니다.
게이트웨이 성능을 최적화하려면 애플리케이션과 게이트웨이 간의 네트워크 대역폭이 애플리케이션 요구 사항을 충족할 수 있는지 확인하세요. 게이트웨이의
ReadBytes
및WriteBytes
지표를 사용하여 총 데이터 처리량을 측정할 수 있습니다. 이러한 지표에 대한 자세한 내용은 Tape Gateway와 AWS 간 성능 측정 섹션을 참조하세요.애플리케이션의 경우 측정된 처리량을 원하는 처리량과 비교합니다. 측정된 처리량이 원하는 처리량보다 적을 경우, 애플리케이션과 게이트웨이 간의 대역폭을 늘리면 네트워크 병목 현상이 발생하는 경우 성능을 개선할 수 있습니다. 마찬가지로, 직접 연결되지 않은 VM과 로컬 디스크 간의 대역폭을 늘릴 수 있습니다.
-
- 애플리케이션 환경에 CPU 리소스 추가
-
애플리케이션에서 추가 CPU 리소스를 사용할 수 있는 경우 CPU를 더 추가하면 애플리케이션이 I/O 부하를 조정하는 데 도움이 될 수 있습니다.