IOPS QoS 제어는 확실히 특정 리소스의 총 IOPS가 기준이 되지만 IOPS QoS는 직관적이지 않은 여러 측면을 가지고 있습니다. IOPS 임계값에 도달했을 때 지연 시간이 뚜렷이 증가되는 현상에 몇몇 고객은 초기에 혼란을 느꼈습니다. 지연 시간 증가는 IOPS 제한으로 인한 당연한 결과입니다. 논리적으로는 토큰 시스템과 비슷하게 작동합니다. 예를 들어, 특정 볼륨에 10K IOPS 제한이 있는 데이터 파일이 포함된 경우 유입되는 각 I/O에서 처리가 계속되려면 먼저 토큰이 수신되어야 합니다. 초당 10K 이상의 토큰이 소비되지 않는 한 지연은 없습니다. 입출력 작업이 토큰을 수신하기 위해 대기해야 하는 경우 이 대기는 추가 지연 시간으로 나타납니다. 워크로드가 QoS 제한에 근접할수록 각 IO는 해당 회전이 처리될 때까지 대기열에서 대기해야 하는 시간이 길어집니다. 이는 사용자에게 더 높은 지연 시간으로 나타납니다.

모든 I/O 크기가 같지는 않습니다. 예를 들어, 데이터베이스가 여러 개의 작은 블록 읽기를 수행하여 IOPS 임계값에 도달할 수 있고 또한 데이터베이스는 매우 적은 수의 대규모 블록 읽기로 구성된 전체 테이블 스캔 작업을 수행할 수도 있으며, 이는 대역폭은 많이, IOPS는 상대적으로 적게 소비합니다.

마찬가지로 VMware 환경은 부팅 중에 매우 많은 수의 랜덤 IOPS를 구동할 수 있지만 외부 백업 중에는 적은 수의 입출력을 수행하지만 더 큰 입출력을 수행할 수 있습니다.

성능을 효과적으로 관리하려면 IOPS 또는 대역폭 QoS 제한이나 둘 다 필요합니다.

많은 고객들이 QoS 보장이 포함된 솔루션을 모색하는데, 이는 생각보다 달성하기 어렵고 낭비가 될 가능성이 있습니다. 예를 들어 10개의 데이터베이스를 10K IOPS 보장으로 배치하려면 10개의 데이터베이스 모두가 동시에 10K IOPS로 실행되는 시나리오의 경우 총 100,000에 대해 시스템을 사이징해야 합니다.

최소 QoS 제어를 위한 최선의 사용은 중요 워크로드를 보호하는 것입니다. 예를 들어 최대 IOPS가 500K이고 운영 워크로드와 개발 워크로드를 혼합할 수 있는 ONTAP 컨트롤러를 가정해 보겠습니다. 특정 데이터베이스가 컨트롤러를 독점하지 못하도록 개발 워크로드에 최대 QoS 정책을 적용해야 합니다. 그런 다음 운영 워크로드에 최소 QoS 정책을 적용하여 필요할 때 항상 필요한 IOPS를 사용할 수 있도록 합니다.

적응형 QoS는 QoS 제한이 스토리지 오브젝트의 용량을 기반으로 하는 ONTAP 기능을 가리킵니다. 일반적으로 데이터베이스 크기와 성능 요구사항 간에는 어떠한 링크도 없기 때문에 데이터베이스에는 거의 사용되지 않습니다. 대규모 데이터베이스는 거의 불활성 상태가 될 수 있지만, 작은 데이터베이스는 가장 IOPS를 많이 포함할 수 있습니다.

적응형 QoS는 이러한 데이터 세트의 IOPS 요구사항이 데이터베이스의 총 크기와 상관하는 경향이 있기 때문에 가상화 데이터 저장소와 함께 매우 유용할 수 있습니다. 1TB의 VMDK 파일이 포함된 최신 데이터 저장소에는 2TB 데이터 저장소보다 절반의 성능이 필요할 수 있습니다. 적응형 QoS를 사용하면 데이터 저장소가 데이터로 채워질 때 QoS 제한을 자동으로 늘릴 수 있습니다.