기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
성능
이 섹션에서는 Storage Gateway 성능에 대한 정보를 얻을 수 있습니다.
파일 게이트웨이용 성능 지침
이 단원에서는 파일 게이트웨이 VM에 하드웨어를 프로비저닝하기 위한 구성 지침을 알아봅니다. 표에 나와 있는 Amazon EC2 인스턴스 크기와 유형은 예제이며 참고용입니다.
성능을 최적화하려면 캐시 디스크 크기를 활성 작업 세트의 크기로 변경해야 합니다. 캐시에 여러 로컬 디스크를 사용하면 데이터에 대한 액세스를 병렬화하여 성능이 확장되고 IOPS가 향상됩니다.
다음 표에서는캐시 적중캐시 작업은 캐시로부터 제공되는 파일 공유에서의 읽기입니다. 캐시 미스읽기 작업은 Amazon S3 제공되는 파일 공유에서의 읽기입니다.
참고
휘발성 스토리지는 사용하지 않는 것이 좋습니다. 휘발성 스토리지 사용에 대한 자세한 내용은 EC2 게이트웨이에서 임시 스토리지 사용 단원을 참조하십시오.
다음은 파일 게이트웨이 구성의 예입니다.
Linux 클라이언트에서의 S3 파일 게이트웨이 성능
구성의 예 | 프로토콜 | 쓰기 처리량 (파일 크기 1GB) | 캐시 적중 읽기 처리량 | 캐시 누락 읽기 처리량 |
---|---|---|---|---|
루트 디스크: 80GB io1, 4,000IOPS 캐시 디스크: 512GiB 캐시, io1, 1,500M프로비저닝된 IOPS 최소 네트워크 성능: 10Gbps CPU: 16 vCPU | RAM: 32GB 리눅스에 권장되는 NFS 프로토콜 |
NFSv3 - 스레드 1개 | 110 밀리비/초 (0.92 기가비트/초) | 590MiB/초 (4.9Gbps) | 310 밀리비/초 (2.6Gbps) |
NFSv3 - 8개의 스레드 | 160MiB/s (1.3Gbps) | 590MiB/초 (4.9Gbps) | 335MiB/s (2.8Gbps) | |
NFSV4 - 스레드 1개 | 130메가바이트/초 (1.1Gbps) | 590MiB/초 (4.9Gbps) | 295MiB/s (2.5Gbps) | |
NFSV4 - 8 스레드 | 160MiB/s (1.3Gbps) | 590MiB/초 (4.9Gbps) | 335MiB/s (2.8Gbps) | |
SMBV3 - 스레드 1개 | 115MiB/s (1.0Gbps) | 325 밀리비/초 (2.7Gbps) | 255밀리비/초 (2.1Gbps) | |
SMBV3 - 스레드 8개 | 190미비/초 (1.6Gbps) | 590MiB/초 (4.9Gbps) | 335MiB/s (2.8Gbps) | |
최소 네트워크 성능: 10Gbps |
NFSv3 - 스레드 1개 | 265MiB/s (2.2Gbps) | 590MiB/초 (4.9Gbps) | 310 밀리비/초 (2.6Gbps) |
NFSv3 - 8개의 스레드 | 385밀리비/초 (3.1Gbps) | 590MiB/초 (4.9Gbps) | 335MiB/s (2.8Gbps) | |
NFSV4 - 스레드 1개 | 310 밀리비/초 (2.6Gbps) | 590MiB/초 (4.9Gbps) | 295MiB/s (2.5Gbps) | |
NFSV4 - 8 스레드 | 385밀리비/초 (3.1Gbps) | 590MiB/초 (4.9Gbps) | 335MiB/s (2.8Gbps) | |
SMBV3 - 스레드 1개 | 275밀리비/초 (2.4Gbps) | 325 밀리비/초 (2.7Gbps) | 255밀리비/초 (2.1Gbps) | |
SMBV3 - 스레드 8개 | 455MiB/s (3.8Gbps) | 590MiB/s (4.9Gbps) | 335MiB/s (2.8Gbps) | |
루트 디스크: 80GB, io1 SSD, 4,000IOPS 캐시 디스크: 4 x 2TB NVME 캐시 디스크 최소 네트워크 성능: 10Gbps CPU: 32vCPU | RAM: 244GB 리눅스에 권장되는 NFS 프로토콜 |
NFSv3 - 스레드 1개 | 300MiB/s (2.5Gbps) | 590MiB/s (4.9Gbps) | 325 밀리비/초 (2.7Gbps) |
NFSv3 - 8개의 스레드 | 585MiB/s (4.9Gbps) | 590MiB/s (4.9Gbps) | 580MiB/s (4.8Gbps) | |
NFSV4 - 스레드 1개 | 355MiB/s (3.0Gbps) | 590MiB/s (4.9Gbps) | 340MiB/s (2.9Gbps) | |
NFSV4 - 8 스레드 | 575MiB/s (4.8Gbps) | 590MiB/s (4.9Gbps) | 575MiB/s (4.8Gbps) | |
SMBV3 - 스레드 1개 | 230MiB/s (1.9Gbps) | 325 밀리비/초 (2.7Gbps) | 245MiB/s (2.0Gbps) | |
SMBV3 - 스레드 8개 | 585MiB/s (4.9Gbps) | 590MiB/s (4.9Gbps) | 580MiB/s (4.8Gbps) |
Windows 클라이언트에서의 파일 게이트웨이 성능
구성의 예 | 프로토콜 | 쓰기 처리량 (파일 크기 1GB) | 캐시 적중 읽기 처리량 | 캐시 누락 읽기 처리량 |
---|---|---|---|---|
루트 디스크: 80GB io1, 4,000IOPS 캐시 디스크: 512GiB 캐시, io1, 1,500M프로비저닝된 IOPS 최소 네트워크 성능: 10Gbps CPU: 16 vCPU | RAM: 32GB 윈도우에 권장되는 SMB 프로토콜 |
SMBV3 - 스레드 1개 | 150MiB/s (1.3Gbps) | 180MiB/s (1.5Gbps) | 20MiB/s (0.2Gbps) |
SMBV3 - 스레드 8개 | 190미비/초 (1.6Gbps) | 335MiB/s (2.8Gbps) | 195 밀리비/초 (1.6Gbps) | |
NFSv3 - 스레드 1개 | 95MiB/s (0.8Gbps) | 130메가바이트/초 (1.1Gbps) | 20MiB/s (0.2Gbps) | |
NFSv3 - 8개의 스레드 | 190미비/초 (1.6Gbps) | 330MiB/s (2.8Gbps) | 190미비/초 (1.6Gbps) | |
최소 네트워크 성능: 10Gbps |
SMBV3 - 스레드 1개 | 230MiB/s (1.9Gbps) | 255밀리비/초 (2.1Gbps) | 20MiB/s (0.2Gbps) |
SMBV3 - 스레드 8개 | 835MiB/s (7.0Gbps) | 475MiB/s (4.0Gbps) | 195 밀리비/초 (1.6Gbps) | |
NFSv3 - 스레드 1개 | 135밀리비/초 (1.1Gbps) | 185밀리비/초 (1.6Gbps) | 20MiB/s (0.2Gbps) | |
NFSv3 - 8개의 스레드 | 545 밀리비/초 (4.6Gbps) | 470MiB/s (4.0Gbps) | 190미비/초 (1.6Gbps) | |
루트 디스크: 80GB, io1 SSD, 4,000IOPS 캐시 디스크: 4 x 2TB NVME 캐시 디스크 최소 네트워크 성능: 10Gbps CPU: 32vCPU | RAM: 244GB 윈도우에 권장되는 SMB 프로토콜 |
SMBV3 - 스레드 1개 | 230MiB/s (1.9Gbps) | 265MiB/s (2.2Gbps) | 30MiB/s (0.3Gbps) |
SMBV3 - 스레드 8개 | 835MiB/초 (7.0Gbps) | 780MiB/s (6.5Gbps) | 250메가바이트/초 (2.1Gbps) | |
NFSv3 - 스레드 1개 | 135밀리바이/초 (1.1. Gbps) | 220MiB/s (1.8Gbps) | 30MiB/s (0.3Gbps) | |
NFSv3 - 8개의 스레드 | 545 밀리비/초 (4.6Gbps) | 570MiB/초 (4.8Gbps) | 240MiB/s (2.0Gbps) |
참고
성능은 호스트 플랫폼 구성 및 네트워크 대역폭에 따라 달라질 수 있습니다.
게이트웨이 성능 최적화
다음은 게이트웨이의 성능을 최적화하는 자세한 방법을 확인할 수 있습니다. 이 지침은 게이트웨이에 리소스를 추가하고 애플리케이션 서버에 리소스를 추가하는 것을 기반으로 합니다.
게이트웨이에 리소스 추가
다음 방법 중 하나 이상을 사용하여 게이트웨이에 리소스를 추가하여 게이트웨이 성능을 최적화할 수 있습니다.
- 고성능 디스크 사용
-
게이트웨이 성능을 최적화하기 위해 SSD (솔리드 스테이트 드라이브) 및 NVMe 컨트롤러와 같은 고성능 디스크를 추가할 수 있습니다. Microsoft Hyper-V NTFS 대신 SAN (저장소 영역 네트워크) 에서 직접 가상 디스크를 VM에 연결할 수도 있습니다. 디스크 성능이 향상되면 일반적으로 처리량이 향상되고 초당 입력/출력 작업 수 (IOPS) 가 증가합니다. 디스크 추가에 대한 자세한 내용은 단원을 참조하십시오.캐시 스토리지 추가.
처리량을 측정하려면
ReadBytes
과WriteBytes
의 측정치Samples
Amazon CloudWatch 통계. 예를 들어,Samples
의 통계입니다.ReadBytes
5분 동안의 샘플 시간에 걸친 지표를 300초로 나누면 IOPS가 됩니다. 일반적으로 게이트웨이에 대한 이러한 메트릭을 검토할 때는 낮은 처리량과 낮은 IOPS 추세를 찾아 디스크 관련 병목 현상을 나타냅니다.참고
CloudWatch 지표를 일부 게이트웨이에 사용할 수 있는 것은 아닙니다. 게이트웨이 지표에 대한 자세한 내용은 단원을 참조하십시오.파일 게이트웨이 모니터링.
- 게이트웨이 호스트에 CPU 리소스 추가
-
게이트웨이 호스트 서버의 최소 요구 사항은 4개의 가상 프로세서입니다. 게이트웨이 성능을 최적화하려면 게이트웨이 VM에 할당된 4개의 가상 프로세서가 4개의 코어로 지원되는지 확인합니다. 또한 호스트 서버의 CPU를 과다 구독하고 있지 않은지 확인합니다.
게이트웨이 호스트 서버에 CPU를 추가하면 게이트웨이의 처리 기능이 향상됩니다. 이렇게 하면 게이트웨이가 애플리케이션의 데이터를 로컬 스토리지로 저장하고 이 데이터를 Amazon S3 업로드할 수 있습니다. 또한 추가 CPU는 호스트가 다른 VM과 공유될 때 게이트웨이가 충분한 CPU 리소스를 확보할 수 있도록 도와줍니다. 충분한 CPU 리소스를 제공하면 처리량이 향상되는 일반적인 효과가 있습니다.
Storage Gateway 호스트 서버에서 24개의 CPU 사용을 지원합니다. 24개의 CPU를 사용하여 게이트웨이의 성능을 크게 향상시킬 수 있습니다. 게이트웨이 호스트 서버에 대해 다음 게이트웨이 구성을 권장합니다.
-
24개의 CPU.
-
파일 게이트웨이용 16GiB 예약 RAM
-
캐시 크기가 최대 16TiB인 게이트웨이를 위한 16GiB 예약 RAM
-
캐시 크기가 16TiB에서 32TiB인 게이트웨이를 위한 32GiB의 예약된 RAM
-
캐시 크기가 32TiB에서 64TiB인 게이트웨이를 위한 48GiB의 예약된 RAM
-
-
반가상화 컨트롤러 1에 연결된 디스크 1은 다음과 같이 게이트웨이 캐시로 사용됩니다.
-
NVMe 컨트롤러를 사용하는 SSD.
-
-
반가상화 컨트롤러 1에 연결된 디스크 2는 다음과 같이 게이트웨이 업로드 버퍼로 사용됩니다.
-
NVMe 컨트롤러를 사용하는 SSD
-
-
반가상화 컨트롤러 2에 연결된 디스크 3은 다음과 같이 게이트웨이 업로드 버퍼로 사용됩니다.
-
NVMe 컨트롤러를 사용하는 SSD.
-
-
VM 네트워크 1에 구성된 네트워크 어댑터 1:
-
VM 네트워크 1을 사용하고 수집에 사용할 VMXNet3 (10Gbps) 을 추가합니다.
-
-
VM 네트워크 2에 구성된 네트워크 어댑터 2:
-
VM 네트워크 2를 사용하고 연결에 사용할 VMXNet3 (10Gbps) 을 추가합니다.AWS.
-
-
- 별도의 물리적 디스크가 있는 백 게이트웨이 가상 디스크
-
게이트웨이 디스크를 프로비저닝할 때 동일한 기본 물리 스토리지 디스크를 사용하는 로컬 스토리지에 로컬 디스크를 프로비저닝하지 말 것을 적극 권장합니다. 예를 들어 VMware ESXi의 경우 기본 물리 스토리지 리소스는 데이터 스토어로 표시됩니다. 게이트웨이 VM을 배포할 경우, VM 파일을 저장할 데이터 스토어를 선택합니다. 가상 디스크를 프로비저닝하는 경우 (예: 업로드 버퍼 용도), 가상 디스크를 동일한 데이터 스토어에 VM으로 저장하거나 다른 데이터 스토어에 저장할 수 있습니다.
데이터 스토어가 한 개 이상인 경우에는 만드는 로컬 스토리지 유형마다 데이터 스토어 한 개씩 데이터 스토어 한 개씩 선택하는 것이 좋습니다. 기본 물리 디스크 한 개만 지원하는 데이터 스토어는 성능이 떨어질 수 있습니다. 예를 들어 이러한 디스크를 사용하여 게이트웨이 설정에서 캐시 스토리지와 업로드 버퍼를 모두 백업하는 경우를 들 수 있습니다. 마찬가지로 RAID 1과 같이 성능이 낮은 RAID 구성으로 뒷받침되는 데이터 저장소는 성능이 저하될 수 있습니다.
애플리케이션 환경에 리소스 추가
- 애플리케이션 서버와 게이트웨이 간 대역폭 증가
-
게이트웨이 성능을 최적화하려면 애플리케이션과 게이트웨이 간의 네트워크 대역폭이 애플리케이션 요구를 유지할 수 있는지 확인하십시오. 이
ReadBytes
과WriteBytes
전체 데이터 처리량을 측정하기 위한 게이트웨이의 메트릭입니다.애플리케이션의 경우 측정된 처리량을 원하는 처리량과 비교합니다. 측정된 처리량이 원하는 처리량보다 작은 경우 네트워크가 병목 현상일 경우 애플리케이션과 게이트웨이 간의 대역폭을 늘리면 성능이 향상될 수 있습니다. 마찬가지로 VM과 로컬 디스크가 직접 연결되지 않은 경우 VM과 로컬 디스크 간의 대역폭을 늘릴 수 있습니다.
- 애플리케이션 환경에 CPU 리소스 추가
-
애플리케이션에서 추가 CPU 리소스를 사용할 수 있는 경우 CPU를 더 추가하면 애플리케이션이 I/O 로드를 확장하는 데 도움이 될 수 있습니다.
Storage Gateway VMware vSphere 고가용성 사용
Storage Gateway VMware vSphere HA (VMware vSphere 고가용성) 와 통합된 애플리케이션 수준의 상태 확인 세트를 통해 VMware에서 고가용성을 제공합니다. 이러한 접근 방식을 통해 하드웨어, 하이퍼바이저 또는 네트워크 장애로부터 스토리지 워크로드를 보호할 수 있습니다. 또한 연결 시간 초과, 파일 공유 또는 볼륨 사용 불가와 같은 소프트웨어 오류로부터 보호할 수 있습니다.
이러한 통합을 통해 온프레미스 VMware 환경 또는 VMware Cloud on AWS에 배포된 게이트웨이는 대부분의 서비스 중단으로부터 자동으로 복구됩니다. 일반적으로 데이터 손실 없이 60초 이내에 이 작업을 수행합니다.
Storage Gateway에서 VMware HA를 사용하려면 다음 단계를 수행하십시오.
주제
vSphere VMware HA 클러스터 구성
먼저 아직 VMware 클러스터를 생성하지 않은 경우 클러스터를 생성합니다. VMware 클러스터를 생성하는 방법에 대한 자세한 내용은 VMware 설명서의 vSphere HA 클러스터 생성
Storage Gateway에서 작동하도록 VMware 클러스터를 구성합니다.
VMware 클러스터를 구성하려면
-
VMware vSphere의 Edit Cluster Settings(클러스터 설정 편집) 페이지에서 VM 모니터링이 VM 및 애플리케이션 모니터링용으로 구성되어 있는지 확인합니다. 이렇게 하려면 다음 옵션을 나열된 대로 설정합니다.
-
호스트 장애 대응: VM 재시작
-
호스트 격리에 대한 응답: VM 종료 및 다시 시작
-
PDL (PDL 포함 데이터 스토어): 비활성
-
APD (APD 포함 데이터 스토어): 비활성
-
VM 모니터링: VM 및 애플리케이션 모니터링
예를 들어, 다음 스크린샷을 참조하십시오.
-
-
다음 값을 조정하여 클러스터의 민감도를 미세 조정합니다.
-
Failure— VM 하트비트가 수신되지 않은 경우 이 간격 후 VM을 다시 시작합니다.
-
최소 가동 시간— VM이 VM 도구의 하트비트에 대한 모니터링을 시작한 후 클러스터가 이 시간 동안 기다립니다.
-
VM당 최대 재설정— 클러스터가 최대 재설정 시간 내에서 VM을 이 최대 횟수만큼 다시 시작합니다.
-
최대 재설정 시간— VM당 최대 재설정 수를 구할 시간입니다.
설정할 값을 잘 모르는 경우 다음 설정 예를 사용합니다.
-
Failure interval(실패 간격):
30
초 -
Minimum uptime(최소 가동 시간):
120
초 -
Maximum per-VM resets(VM당 최대 재설정):
3
-
Maximum resets time window(최대 재설정 시간):
1
시간
-
클러스터에서 다른 VM이 실행 중인 경우 이러한 값을 해당 VM에 맞게 설정할 수 있습니다. .ova에서 VM을 배포할 때까지는 이 작업을 수행할 수 없습니다. 이러한 값 설정에 대한 자세한 내용은 (선택 사항) 클러스터의 다른 VM에 대한 재정의 옵션 추가 단원을 참조하십시오.
게이트웨이 유형에 대한 .ova 이미지 다운로드
다음 절차에 따라 .ova 이미지를 다운로드합니다.
게이트웨이 유형에 대한 .ova 이미지를 다운로드하려면
-
다음 중 하나에서 해당 게이트웨이 유형에 대한 .ova 이미지를 다운로드합니다.
-
파일 게이트웨이 —
-
게이트웨이 배포
구성된 클러스터에서 .ova 이미지를 클러스터의 호스트 중 하나에 배포합니다.
게이트웨이 .ova 이미지를 배포하려면
-
.ova 이미지를 클러스터의 호스트 중 하나에 배포합니다.
-
루트 디스크 및 캐시에 대해 선택한 데이터 스토어를 클러스터의 모든 호스트에서 사용할 수 있는지 확인합니다.
(선택 사항) 클러스터의 다른 VM에 대한 재정의 옵션 추가
클러스터에서 다른 VM이 실행 중인 경우 각 VM에 맞게 클러스터 값을 설정할 수 있습니다.
클러스터의 다른 VM에 대한 재정의 옵션을 추가하려면
-
VMware vSphere의 요약 페이지에서 클러스터를 선택하여 클러스터 페이지를 연 다음 구성을 선택합니다.
-
구성 탭을 선택한 다음 VM Overrides(VM 재정의)를 선택합니다.
-
새 VM 재정의 옵션을 추가하여 각 값을 변경합니다.
재정의 옵션은 다음 스크린샷을 참조하십시오.
게이트웨이 활성화
게이트웨이에 대한 .ova를 배포한 후 게이트웨이를 활성화합니다. 각 게이트웨이 유형마다 서로 다른 방법에 대한 지침입니다.
게이트웨이를 활성화하려면
-
게이트웨이 유형에 따라 활성화 지침을 선택합니다.
-
파일 게이트웨이 —
-
VMware 고가용성 구성 테스트
게이트웨이를 활성화한 후 구성을 테스트합니다.
VMware HA 구성을 테스트하려면
-
에서 Storage Gateway 콘솔을 엽니다.https://console.aws.amazon.com/storagegateway/home
. -
탐색 창에서 게이트웨이를 선택한 다음 VMware HA에 대해 테스트할 게이트웨이를 선택합니다.
-
작업에서 Verify VMware HA(VMware HA 확인)를 선택합니다.
-
Verify VMware High Availability Configuration(VMware 고가용성 구성 확인) 상자가 나타나면 확인을 선택합니다.
참고
VMware HA 구성을 테스트하면 게이트웨이 VM이 재부팅되고 게이트웨이 연결이 중단됩니다. 테스트를 완료하는 데 몇 분 정도 걸릴 수 있습니다.
테스트가 성공하면 콘솔에 있는 게이트웨이의 세부 정보 탭에 확인됨 상태가 나타납니다.
-
종료를 선택합니다.
Amazon CloudWatch 로그 그룹에서 VMware HA 이벤트에 대한 정보를 찾을 수 있습니다. 자세한 내용은 CloudWatch 로그 그룹을 사용하여 파일 게이트웨이 상태 로그 가져오기 단원을 참조하세요.