KR20140107544A - 클라이언트 사용 및 시스템 메트릭들에 기초한 비례 서비스 품질 - Google Patents

클라이언트 사용 및 시스템 메트릭들에 기초한 비례 서비스 품질 Download PDF

Info

Publication number
KR20140107544A
KR20140107544A KR1020147020329A KR20147020329A KR20140107544A KR 20140107544 A KR20140107544 A KR 20140107544A KR 1020147020329 A KR1020147020329 A KR 1020147020329A KR 20147020329 A KR20147020329 A KR 20147020329A KR 20140107544 A KR20140107544 A KR 20140107544A
Authority
KR
South Korea
Prior art keywords
client
value
load
performance
storage system
Prior art date
Application number
KR1020147020329A
Other languages
English (en)
Inventor
데이비드 디. 라이트
마이클 수
Original Assignee
솔리드파이어, 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/338,039 external-priority patent/US9003021B2/en
Application filed by 솔리드파이어, 인크. filed Critical 솔리드파이어, 인크.
Publication of KR20140107544A publication Critical patent/KR20140107544A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0653—Monitoring storage devices or systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3485—Performance evaluation by tracing or monitoring for I/O devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/81—Threshold

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)

Abstract

복수의 클라이언트들 중 제1 클라이언트에 대한 저장 시스템에서의 볼륨의 클라이언트 메트릭들을 결정하기 위한 시스템들, 컴퓨터-판독 가능한 매체들, 및 방법들이 개시된다. 저장 시스템은 복수의 클라이언트들로부터의 데이터를 저장한다. 저장 시스템에서의 클러스터의 시스템 메트릭들은 복수의 클라이언트들에 의한 저장 시스템의 사용에 기초하여 결정된다. 저장 시스템의 로드 값은 시스템 메트릭들 및 클라이언트 메트릭들에 기초하여 결정된다. 로드 값은 미리 정의된 임계치를 초과하는 것으로 결정된다. 타겟 성능 값은 로드 값, 최소 서비스 품질 값, 및 최대 서비스 품질 값에 기초하여 산출된다. 저장 시스템의 성능은 타겟 성능 값 및 로드 값이 미리 정의된 임계치 이상임을 결정하는 것에 기초하여 클라이언트에 대해 조정된다.

Description

클라이언트 사용 및 시스템 메트릭들에 기초한 비례 서비스 품질{PROPORTIONAL QUALITY OF SERVICE BASED ON CLIENT USAGE AND SYSTEM METIRCS}
관련 특허 출원들에 대한 상호-참조
본 출원은 그 전체가 모든 목적들을 위해 참조로서 여기에 통합되는, 2011년 12월 27일에 출원된, Wright 등에 의한 "클라이언트 성능 및 클러스터 헬스에 기초한 저장 시스템 액세스의 관리(Management of Storage System Access Based on Client Performance and Cluster Health)"라는 제목의, 이전 미국 출원 일련 번호 제13/338,039호(솔리드파이어 문서 번호. POO2)의, U.S.C. §120의 규정들에 의한, 일부 계속 출원이다.
다음의 설명은 판독자의 이해를 돕기 위해 제공된다. 제공된 정보 중 어떤 것도 종래 기술인 것으로 인정되지 않는다.
데이터 저장 아키텍처들에서, 클라이언트의 데이터는 볼륨에 저장될 수 있다. 통상적으로, 볼륨의 데이터는 저장 클러스터에서 작은 퍼센티지의 드라이브들 상에 존재한다. 이러한 배열은 클러스터의 다른 부분들이 충분히 이용되지 않는 동안 클러스터의 부분들이 과하게 이용되는 핫 스폿들의 이슈들을 야기한다. 예를 들면, 클라이언트가 볼륨에서 데이터의 다수의 액세스들을 수행하고 있다면, 데이터가 저장되는 작은 퍼센티지의 드라이브들에 기인한 로드가 증가하여, 핫 스폿을 야기한다. 이러한 배열은 몇몇 클라이언트들이 그것들의 데이터가 충분히 이용되지 않는 부분들 상에 저장된다면 양호한 성능을 경험할 수 있으며 몇몇 클라이언트가 그것들의 데이터가 과하게 이용되는 부분들 상에 저장된다면 열악한 성능을 경험하기 때문에 클러스터의 모든 볼륨들에 걸쳐 일관성 없는 클라이언트 경험을 야기할 수 있다.
보다 양호한 클라이언트 경험을 제공하려고 시도하는 하나의 방식은 클라이언트 우선순위화에 기초한 서비스 품질을 사용하는 것이다. 예를 들면, 클라이언트들은 상이한 우선순위 레벨들을 할당받는다. 이들 우선순위 레벨들에 기초하여, 다양한 클라이언트들에 대한 액세스 요청들(예로서, 판독 및 기록 요청들)이 우선순위화된다. 클라이언트들의 액세스 요청들은 클러스터의 로드 및 각각의 클러스터에 할당된 우선순위에 기초하여 발송된다. 예를 들면, 보다 높은 우선순위를 가진 클라이언트는 클러스터가 보다 높은 부하를 경험하고 있을 때의 시간들 동안 보다 낮은 우선순위를 가진 또 다른 클라이언트보다 프로세싱된 보다 많은 액세스 요청들을 가질 수 있다. 우선순위 시스템을 사용하는 것은 단지 약간 더 양호한 클라이언트 경험을 허용한다. 예를 들면, 우선순위들은 특정한, 일관적인 레벨의 성능을 보장하지 않으며 클러스터가 항상 모든 클라이언트들 중에서 그것의 전체 성능을 나눈다는 아이디어에 기초한다. 이에 대한 하나의 이유는 클러스터의 성능에 대한 단일 클라이언트의 효과들이 캐핑(cap)되지 않는다는 것이며, 시스템이 스트레스를 받을 때, 시스템은 항상 그것이 여전히 우선순위화되어 작동하기 때문에 얼마나 많은 고객들이 시스템상에 있는지에 관계없이 느리게 작동한다. 우선순위화는 또한, 우선순위화가 고객이 얻는 실제 성능에 대한 이해 가능한 아이디어를 고객들에게 확대시키지 않기 때문에, 고객이 그것들이 수신하는 실제 성능을 이해하는 것을 어렵게 만든다. 또한, 우선순위화는 관리자들로 하여금 시스템이 어떻게 다수의 고객들을 지원하는지 및 고객들이 어떻게 시스템을 로딩하게 하는지를 제어하도록 허용하지 않는다.
본 개시의 앞서 말한 및 다른 특징들은 첨부한 도면들과 함께 취해진, 다음의 설명 및 첨부된 청구항들로부터 보다 완전하게 명백해질 것이다.
도 1a는 예시적인 구현에 따른 저장 시스템에서의 성능 관리를 위한 간소화된 시스템을 묘사한다.
도 1b는 예시적인 구현에 따른 시스템의 보다 상세한 예를 예시한다.
도 2는 예시적인 구현에 따른 서비스 품질 파라미터들을 설정하기 위한 사용자 인터페이스를 묘사한다.
도 3은 예시적인 구현에 따른 성능 관리를 수행하는 방법의 간소화된 흐름도를 묘사한다.
도 4는 예시적인 구현에 따른 성능 관리자를 사용하여 성능을 조정하는 보다 상세한 예를 묘사한다.
도 5는 예시적인 구현에 따른 시스템 부하와 입력/출력 동작들의 크기를 비교하는 성능 곡선을 묘사한다.
도 6은 예시적인 구현에 따른 클라이언트 메트릭과 오버로딩된 시스템 메트릭을 매칭시키는 성능 관리를 수행하는 방법의 간소화된 흐름도를 묘사한다.
도 7은 예시적인 구현에 따른 시간 기간에 걸쳐 클라이언트에 의해 수행된 다수의 IOPS의 그래프를 예시한다.
도 8은 예시적인 구현에 따라 서비스 제공자들, 사용자들, 및/또는 다른 엔티티들이 사용의 상이한 성능 클래스들을 동적으로 정의 및/또는 생성할 수 있게 하고 및/또는 저장 시스템에서 성능/QoS 관련 맞춤화들을 정의할 수 있게 하도록 구성되거나 또는 설계될 수 있는 예시적인 QoS 인터페이스 GUI(800)를 도시한다.
도 9는 예시적인 구현에 다른 저장 시스템의 일 부분을 도시한다.
도 10은 로드-서비스 데이터 구조의 특정 예시적인 실시예를 예시한다.
도 11은 저장 시스템 내에서 작동하는 상이한 서비스들과 연관된 시스템 로드 특성들 및 상태들을 추적하기 위해 구성되거나 또는 설계될 수 있는 로드-서비스 데이터 구조(1100)의 대안의 예시적인 실시예를 예시한다.
도 12는 클라이언트-서비스 데이터 구조의 특정 예시적인 실시예를 예시한다.
도 13a는 예시적인 구현에 따른 로드(서비스) 분석 절차의 흐름도를 도시한다.
도 13b는 예시적인 구현에 따른 로드(판독) 분석 절차의 흐름도를 도시한다.
도 13c는 예시적인 구현에 따른 로드(기록) 분석 절차의 흐름도를 도시한다.
도 14는 예시적인 구현에 따른 로드(클라이언트) 분석 절차의 흐름도를 도시한다.
도 15는 예시적인 구현에 따른 QoS 클라이언트 정책 관리 절차의 흐름도를 도시한다.
도 16은 예시적인 구현에 따른 QoS 클라이언트-판독 정책 관리 절차의 흐름도를 도시한다.
도 17은 예시적인 구현에 따른 QoS 클라이언트-기록 정책 관리 절차의 흐름도를 도시한다.
도 18은 예시적인 구현에 따라 도 15에 예시된 것과 같은 QoS 클라이언트 정책 관리 절차의 양상들을 저장 시스템이 어떻게 구현하는지를 예시한 그래픽 표현을 도시한다.
도 19a는 클라이언트 IOPS를 스로틀링하기 위한 상이한 QoS 관리 정책 세트들이 어떻게 예시적인 구현에 따라 로드(클라이언트) 상태들을 변경하는 것에 응답하여 자동으로 및/또는 동적으로 구현될 수 있는지를 예시한 그래픽 표현을 도시한다.
도 19b는 QoS 관리 및 IOPS 스로틀링이 어떻게 예시적인 구현에 따라 저장 시스템의 다수의 상이한 클라이언트들에 대해 동시에, 독립적으로, 및 동적으로 구현될 수 있는지를 예시한 그래픽 표현을 도시한다.
도 20은 클라이언트 IOPS를 스로틀링하기 위한 상이한 QoS 관리 정책 세트들이 어떻게 예시적인 구현에 따라 로드(클라이언트-판독) 상태들을 변경하는 것에 응답하여 자동으로 및/또는 동적으로 구현될 수 있는지를 예시한 그래픽 표현을 도시한다.
도 21은 클라이언트 IOPS를 스로틀링하기 위한 상이한 QoS 관리 정책 세트들이 어떻게 예시적인 구현에 따라 로드(클라이언트-기록) 상태를 변경하는 것에 응답하여 자동으로 및/또는 동적으로 구현될 수 있는지를 예시한 그래픽 표현을 도시한다.
개괄
일반적으로, 본 명세서에 설명된 주제의 일 양상은 복수의 클라이언트들 중 제 1 클라이언트에 대한 저장 시스템에서 볼륨의 클라이언트 메트릭들을 결정하기 위한 방법들에서 구체화될 수 있다. 저장 시스템은 복수의 클라이언트들로부터의 데이터를 저장한다. 저장 시스템에서의 클러스터의 시스템 메트릭들은 복수의 클라이언트들에 의한 저장 시스템의 사용에 기초하여 결정된다. 저장 시스템의 로드 값은 시스템 메트릭들 및 클라이언트 메트릭들에 기초하여 결정된다. 로드 값은 미리 정의된 임계치 이상인 것으로 결정된다. 타겟 성능 값은 로드 값, 최소 서비스 품질 값, 및 최대 서비스 품질 값에 기초하여 산출된다. 저장 시스템의 성능은 타겟 성능 값 및 상기 로드 값이 상기 미리 정의된 임계치 이상임을 결정하는 것에 기초하여 상기 클라이언트에 대해 조정된다. 이 양상의 다른 구현들은 상기 방법의 동작들을 수행하도록 구성된 대응하는 시스템들, 장치들, 및 컴퓨터-판독 가능한 미디어를 포함한다.
본 명세서에 설명된 주제의 또 다른 양상은 복수의 데이터 볼륨들에 대한 데이터를 저장하는 저장 시스템에서 성능을 관리하기 위한 방법들에서 구체화될 수 있으며, 여기에서 개개의 데이터 볼륨은 연관된 클라이언트를 가진다. 개개의 데이터 볼륨에 대한 사용의 성능 클래스의 선택이 수신된다. 사용의 성능 클래스는 사용의 적어도 하나의 성능 클래스가 상이한 초당 입력 출력(Input Output Per Second; IOPS) 서비스 품질 파라미터를 갖는 복수의 성능 클래스들로부터 선택된다. 개개의 데이터 볼륨에 대한 액세스는 선택된 사용의 성능 클래스의 상기 IOPS 서비스 품질 파라미터에 기초하여 관리된다. 이 양상의 다른 구현들은 상기 방법의 상기 동작들을 수행하도록 구성된 대응하는 시스템들, 장치들, 및 컴퓨터-판독 가능한 미디어를 포함한다.
본 명세서에 설명된 주제의 또 다른 양상은 클라이언트에 대한 저장 시스템에 저장된 데이터의 액세스와 연관된 로드 값을 결정하기 위한 방법들에서 구체화될 수 있다. 데이터는 복수의 블록들로 나뉘며 저장 시스템의 복수의 노드들에 걸쳐 실질적으로 고르게 저장된다. 저장 시스템은 복수의 클라이언트들로부터의 데이터를 포함한다. 클라이언트로부터의 요청된 서비스 품질 파라미터가 수신된다. 상기 요청된 서비스 품질 파라미터에 따른 데이터의 액세스가 모니터링된다. 상기 데이터에 대한 액세스는 상기 모니터링한 데이터의 액세스에 기초하여 스로틀링된다. 이러한 양상의 다른 구현들은 상기 방법의 동작들을 수행하도록 구성된 대응하는 시스템들, 장치들, 및 컴퓨터-판독 가능한 미디어를 포함한다.
본 명세서에 설명된 주제의 또 다른 양상은 클라이언트에 대한 저장 시스템에 저장된 데이터의 액세스와 연관된 초당 입력/출력 동작들(IOPS) 메트릭을 결정하기 위한 방법들에서 구체화될 수 있다. 상기 데이터는 복수의 블록들로 나뉘며 상기 복수의 블록들은 상기 저장 시스템의 복수의 노드들에 걸쳐 실질적으로 고르게 저장된다. 상기 저장 시스템은 복수의 클라이언트들로부터의 데이터를 포함한다. 요청된 IOPS 값이 수신된다. 상기 데이터에 대한 액세스는 상기 요청된 IOPS 값에 기초하여 이관된다. 이 양상의 다른 구현들은 상기 방법의 동작들을 수행하도록 구성된 대응하는 시스템들, 장치들, 및 컴퓨터-판독 가능한 미디어를 포함한다.
본 명세서에 설명된 주제의 또 다른 양상은 저장 시스템 볼륨을 액세스하는 컴퓨팅 디바이스와 연관된 최소 성능 서비스 품질 파라미터를 수신하기 위한 방법들에서 구체화될 수 있다. 상기 저장 시스템 볼륨과 연관된 시스템 메트릭들이 수신된다. 상기 컴퓨팅 디바이스와 연관된 타겟 성능 값은 상기 최소 성능 서비스 품질 메트릭들 및 상기 시스템 메트릭들에 기초하여 산출된다. 상기 타겟 성능 값은 제어기 모듈이 상기 저장 시스템 볼륨을 액세스하는 상기 컴퓨팅 디바이스의 성능을 상기 타겟 성능 값으로 제한하도록 상기 타겟 성능 값이 상기 최소 성능 서비스 품질 메트릭을 만족시킬 때 상기 제어기 모듈에 전송된다. 이러한 양상의 다른 구현들은 상기 방법의 동작들을 수행하도록 구성된 대응하는 시스템들, 장치들, 및 컴퓨터-판독 가능한 미디어를 포함한다.
본 명세서에 설명된 주제의 또 다른 양상은 저장 시스템에 대한 용량의 총 양을 결정하기 위한 방법들에서 구체화될 수 있다. 상기 용량은 서비스 품질 파라미터에 의해 정의된다. 상기 저장 시스템을 액세스하기 위해 복수의 클라이언트들에 대해 프로비전되는 상기 서비스 품질 파라미터의 복수의 값들이 수신된다. 상기 복수의 클라이언트들에서의 각각의 클라이언트는 상기 서비스 품질 파라미터의 값을 프로비전된다. 상기 저장 시스템에서 상기 복수의 클라이언트들에 대해 프로비전되는 상기 복수의 값들은 모니터링되며 상기 복수의 값들이 임계치를 위반하는지 결정된다. 상기 임계치는 상기 저장 시스템에 대한 용량의 총 양에 기초한다. 신호는 하나 이상의 클라이언트들에 대한 상기 서비스 품질 파라미터의 값 또는 상기 저장 시스템에 대한 용량의 총 양에서의 조정이 수행되어야 함을 표시하기 위해 상기 복수의 값들이 상기 임계치를 위반할 때 자동으로 출력된다. 이러한 양상의 다른 구현들은 상기 방법의 동작들을 수행하도록 구성된 대응하는 시스템들, 장치들, 및 컴퓨터-판독 가능한 미디어를 포함한다.
본 명세서에 설명된 주제의 또 다른 양상은 저장 시스템을 액세스하기 위해 서비스 품질 파라미터들을 복수의 클라이언트들에 프로비전하기 위한 방법들에서 구체화될 수 있다. 상기 복수의 클라이언트들에 의한 상기 저장 시스템의 액세스가 모니터링된다. 상기 저장 시스템을 액세스할 때 상기 복수의 클라이언트들에서의 클라이언트의 성능이 모니터링된다. 상기 저장 시스템을 액세스할 때 상기 클라이언트의 성능은 상기 클라이언트가 프로비전받은 상기 서비스 품질 파라미터들에 기초하여 제어된다. 상기 클라이언트의 성능 및 상기 복수의 클라이언트들에 의한 상기 저장 시스템의 액세스는 상기 클라이언트에 대한 타겟 성능 값을 결정하기 위해 분석된다. 상기 저장 시스템을 액세스할 때 상기 클라이언트의 제어는 상기 서비스 품질 파라미터들에 기초하여 상기 클라이언트의 성능을 조정하기 위해 동적으로 조정된다. 이러한 양상의 다른 구현들은 상기 방법의 동작들을 수행하도록 구성된 대응하는 시스템들, 장치들, 및 컴퓨터-판독 가능한 미디어를 포함한다.
본 명세서에 설명된 주제의 또 다른 양상이 저장 시스템을 액세스하기 위해 서비스 품질 파라미터들을 복수의 클라이언트들에 프로비전하기 위한 방법들에서 구체화될 수 있다. 상기 저장 시스템을 액세스할 때 상기 복수의 클라이언트들에서의 클라이언트의 성능이 모니터링된다. 상기 저장 시스템을 액세스할 때 상기 클라이언트의 성능은 상기 클라이언트가 상기 복수의 클라이언트들에서의 다른 클라이언트들에 대해 프로비전받은 서비스 품질 파라미터들에 상관없이 프로비전받은 상기 서비스 품질 파라미터들에 기초하여 독립적으로 제어된다. 상기 클라이언트에 대한 로드 값은 상기 클라이언트에 의한 상기 저장 시스템의 사용 및 상기 서비스 품질 파라미터들에 기초하여 산출된다. 상기 클라이언트의 성능은 상기 성능 및 상기 로드 값 사이에서의 차이를 결정하기 위해 상기 클라이언트에 대한 상기 서비스 품질 파라미터들에 대하여 분석된다. 상기 저장 시스템의 리소스들에 대한 액세스는 상기 성능 및 상기 로드 값 사이에서의 상기 차이에 기초하여 상기 클라이언트의 성능의 제어를 독립적으로 조정하기 위해 동적으로 할당된다. 이러한 양상의 다른 구현들은 상기 방법의 동작들을 수행하도록 구성된 대응하는 시스템들, 장치들, 및 컴퓨터-판독 가능한 미디어를 포함한다.
본 명세서에 설명된 주제의 또 다른 양상은 서버 시스템 내에서 데이터에 대한 클라이언트 액세스를 조정하기 위한 방법들에서 구체화될 수 있다. 상기 클라이언트와 통신하는 볼륨 서버는 데이터를 액세스하기 위해 상기 클라이언트로부터 요청을 수신한다. 성능 관리기는 메트릭들을 모니터링하며 타겟 값에 대하여 상기 메트릭들을 비교하는 것에 응답하여 상기 데이터에 대한 상기 클라이언트의 액세스를 조정한다. 이러한 양상의 다른 구현들은 상기 방법의 동작들을 수행하도록 구성된 대응하는 시스템들, 장치들, 및 컴퓨터-판독 가능한 미디어를 포함한다.
본 명세서에 설명된 주제의 또 다른 양상은 서버 시스템 내에서 데이터에 대한 클라이언트에 의한 액세스를 조정하기 위한 방법들에서 구체화될 수 있다. 타겟 클라이언트 메트릭을 표시한 타겟 값이 수신된다. 상기 서버 시스템 내에서 상기 데이터를 액세스하기 위한 상기 클라이언트에 의한 요청이 수신된다. 상기 클라이언트 성능은 상기 타겟 값에 비교되며 상기 타겟 값에 대한 상기 비교에 기초하여, 상기 데이터에 대한 클라이언트의 액세스가 조정된다.
앞서 말한 요약은 단지 예시적이며 임의의 방식으로 제한하도록 의도되지 않는다. 상기 설명된 예시적인 양상들, 구현들, 및 특징들 외에, 추가의 양상들, 구현들, 및 특징들이 다음의 도면들 및 상세한 설명을 참조하여 명백해질 것이다.
특정 예시 실시예들
하나 이상의 상이한 발명들이 본 출원에 설명될 것이다. 더욱이, 여기에 설명된 발명(들) 중 하나 이상에 대해, 다수의 실시예들이 본 특허 출원에 설명될 수 있으며, 단지 예시적인 목적들을 위해 제공된다. 설명된 실시예들은 임의의 의미로 제한적이도록 의도되지 않는다. 본 발명(들) 중 하나 이상은, 개시로부터 쉽게 명백한 바와 같이, 다수의 실시예들에 광범위하게 적용 가능할 수 있다. 이들 실시예들은 이 기술분야의 숙련자들이 발명(들) 중 하나 이상을 실시하게 할 수 있도록 충분히 상세히 설명되며, 다른 실시예들이 이용될 수 있으며 구조적, 논리적, 소프트웨어, 전기적 및 다른 변화들이 발명(들) 중 하나 이상의 범위로부터 벗어나지 않고 이루어질 수 있다는 것이 이해될 것이다. 따라서, 이 기술분야의 숙련자들은 발명(들) 중 하나 이상이 다양한 수정들 및 변경들을 갖고 실시될 수 있다는 것을 인식할 것이다. 발명(들) 중 하나 이상의 특정한 특징들이 본 개시의 일부를 형성하며, 예시로서 발명(들) 중 하나 이상의 특정 실시예들이 도시되는, 하나 이상의 특정한 실시예들 또는 도면들을 참조하여 설명될 수 있다. 그러나, 이러한 특징들은 그것들이 설명되는 것을 참조하여 하나 이상의 특정한 실시예들 또는 특징들에서의 사용에 제한되지 않는다는 것이 이해되어야 한다. 본 개시는 발명(들) 중 하나 이상의 모든 실시예들에 대한 문자 그대로의 설명도 모든 실시예들에 제공되어야 하는 발명(들) 중 하나 이상의 특징들의 목록도 아니다.
본 특허 출원에 제공된 섹션들의 주제들 및 본 특허 출원의 제목은 단지 편리함을 위한 것이며 임의의 방식으로 개시를 제한하는 것으로 취해져서는 안된다. 서로 통신하는 디바이스들은, 명확하게 달리 특정되지 않는다면, 서로 계속해서 통신할 필요는 없다. 또한, 서로 통신하는 디바이스들은 하나 이상의 중재자들을 통해 직접 또는 간접적으로 통신할 수 있다. 서로 통신하는 여러 개의 구성요소들을 가진 실시예의 설명은 모든 이러한 구성요소들이 요구됨을 내포하지 않는다. 그와 반대로, 다양한 선택적 구성요소들이 발명(들) 중 하나 이상의 광범위한 다양한 실시예들을 예시하기 위해 설명된다.
또한, 프로세스 단계들, 방법 단계들, 알고리즘들 등이 순차적인 순서로 설명될 수 있지만, 이러한 프로세스들, 방법들, 및 알고리즘들은 대안의 순서들로 동작하도록 구성될 수 있다. 다시 말해서, 본 특허 출원에 설명될 수 있는 임의의 시퀀스 또는 순서의 단계들 그것 자체는 단계들이 상기 순서로 수행되는 요건을 표시하지 않는다. 설명된 프로세스들의 단계들은 실현 가능한 임의의 순서로 수행될 수 있다. 또한, 몇몇 단계들은 비-동시적으로 발생하는 것으로서 설명되거나 또는 내포됨에도 불구하고(예로서, 하나의 단계는 다른 단계 후 설명되기 때문에) 동시에 수행될 수 있다. 게다가, 도면에서의 그것의 묘사에 의한 프로세스의 예시는 예시된 프로세스가 다른 변화들을 제외한다는 것을 내포하지 않으며 그것에 대한 수정들은 예시된 프로세스 또는 그 단계들 중 임의의 것이 발명(들) 중 하나 이상에 필수적임을 내포하지 않으며, 예시된 프로세스가 선호됨을 내포하지 않는다.
단일 디바이스 또는 물품이 설명될 때, 하나 이상의 디바이스/물품(그것들이 협력하는지 여부에 관계없이)이 단일 디바이스/물품 대신에 사용될 수 있다는 것이 쉽게 명백할 것이다. 유사하게, 하나 이상의 디바이스 또는 물품이 설명되지만(그것들이 협력하는지 여부에 관계없이), 단일 디바이스/물품이 하나 이상의 디바이스 또는 물품을 대신해서 사용될 수 있다는 것이 쉽게 명백할 것이다. 디바이스의 기능 및/또는 특징들은 대안적으로 이러한 기능/특징들을 갖는 것으로서 명확하게 설명되지 않는 하나 이상의 다른 디바이스들에 의해 구체화될 수 있다. 따라서, 발명(들) 중 하나 이상의 다른 실시예들은 디바이스 자체를 포함할 필요가 없다.
여기에 설명되거나 또는 언급된 기술들 및 메커니즘들은 때때로 명료함을 위해 단일 형태로 설명될 것이다. 그러나, 특정한 실시예들이 달리 주지되지 않는다면 기술의 다수의 반복들 또는 메커니즘의 다수의 인스턴스화들을 포함한다는 것이 주의되어야 한다.
상세한 설명
성능 관리 저장 시스템에 대한 기술들이 여기에 설명된다. 다음의 설명에서, 설명을 위해, 다수의 예들 및 특정한 세부사항들이 다양한 구현들의 철저한 이해를 제공하기 위해 제시된다. 청구항들에 의해 정의된 바와 같이 특정한 구현들은 단독으로 또는 이하에 설명된 다른 특징들과 조합하여 이들 예들에서 특징들의 일부 또는 모두를 포함할 수 있으며, 여기에 설명된 특징들 및 개념들의 수정들 및 등가물들을 더 포함할 수 있다.
저장 시스템
도 1a는 예시적인 실시예에 따른 저장 시스템(100)에서의 성능 관리를 위한 간소화된 시스템을 묘사한다. 시스템(100)은 클라이언트 층(102), 메타데이터 층(104), 블록 서버 층(106), 및 저장소(116)를 포함한다.
특정한 구현들이 어떻게 클라이언트들(108)의 성능을 관리하는지를 논의하기 전에, 가능한 시스템의 구조가 설명된다. 클라이언트 층(102)은 하나 이상의 클라이언트들(108a 내지 108n)을 포함한다. 클라이언트들(108)은 하나 이상의 물리적 기계들 상에 존재할 수 있는 클라이언트 프로세스들을 포함한다. 용어("클라이언트")가 개시에 사용될 때, 수행되는 동작은 클라이언트 프로세스에 의해 수행될 수 있다. 클라이언트 프로세스는 시스템(100)에서 데이터를 저장, 검색, 및 삭제하는데 책임이 있다. 클라이언트 프로세스는 저장 시스템의 특징 및 저장된 데이터의 포맷에 의존하여 데이터의 조각들을 어드레싱할 수 있다. 예를 들면, 클라이언트 프로세스는 클라이언트 어드레스를 사용하여 데이터를 참조할 수 있다. 클라이언트 어드레스는 상이한 형태들을 취할 수 있다. 예를 들면, 파일 저장소를 사용하는 저장 시스템에서, 클라이언트(108)는 특정한 볼륨 또는 파티션, 및 파일 명을 참조할 수 있다. 오브젝트 저장소를 갖고, 클라이언트 어드레스는 고유 오브젝트 명일 수 있다. 블록 저장에 대해, 클라이언트 어드레스는 볼륨 또는 파티션, 및 블록 어드레스일 수 있다. 클라이언트들(108)은 소형 컴퓨터 시스템 인터페이스(SCSI), 인터넷 소형 컴퓨터 시스템 인터페이스(ISCSI), 파이버 채널(FC), 공통 인터넷 파일 시스템(CIFS), 네트워크 파일 시스템(NFS), 하이퍼텍스트 전송 프로토콜(HTTP), 웹-기반 분산 저작 및 버저닝(WebDAV), 또는 고객 프로토콜과 같은, 상이한 프로토콜들을 사용하여 메타데이터 층(104)과 통신한다.
메타데이터 층(104)은 하나 이상의 메타데이터 서버들(110a 내지 110n)을 포함한다. 성능 관리기들(114)은 메타데이터 서버들(110a 내지 110n) 상에 위치될 수 있다. 블록 서버 층(106)은 하나 이상의 블록 서버들(112a 내지 112n)을 포함한다. 블록 서버들(112a 내지 112n)은 저장소(116)에 결합되며, 이것은 클라이언트들(108)에 대한 볼륨 데이터를 저장한다. 각각의 클라이언트(108)는 볼륨과 연관될 수 있다. 일 구현에 있어서, 단지 하나의 클라이언트(108)가 볼륨에서의 데이터를 액세스하며; 그러나, 다수의 클라이언트들(108)은 단일 볼륨에서 데이터를 액세스할 수 있다.
저장소(116)는 다수의 고체 상태 드라이브들(SSD들)을 포함할 수 있다. 일 구현에 있어서, 저장소(116)는 네트워크를 통해 함께 결합된 개개의 드라이브들의 클러스터일 수 있다. 용어("클러스터")가 사용될 때, 클러스터는 함께 네트워킹되지 않을 수 있는 다수의 디스크들을 포함하는 저장 시스템을 나타낼 수 있다는 것이 인식될 것이다. 일 구현에 있어서, 저장소(116)는 영구적 데이터를 저장하기 위해 고체 상태 메모리를 사용한다. SSD들은 비-휘발성 메모리 칩들에 데이터를 저장하며 어떤 이동 부분들도 포함하지 않는 마이크로칩들을 사용한다. 이에 대한 하나의 결과는 SSD들이 회전 디스크들을 가진 드라이브들에 비교할 때 최적화된 방식으로 상이한 드라이브들에서의 데이터에 대한 랜덤 액세스를 허용한다는 것이다. SSD들의 비-순차적인 부분들에 대한 판독 또는 기록 요청들은 순차적인 판독 또는 기록 요청들에 비교할 때 비교할 만한 양의 시간에서 수행될 수 있다. 반대로, 회전 디스크들이 사용될 때, 랜덤 판독/기록들은, 데이터를 판독하기 위해 다양한 랜덤 위치들에서 판독/기록 헤드를 삽입하는 것이 데이터가 순차적인 위치들로부터 판독되는 경우보다 더 느린 데이터 액세스를 야기하기 때문에 효율적이지 않을 것이다. 따라서, 전기 기계 디스크 저장소를 사용하는 것은 데이터의 클라이언트의 볼륨이 비-순차적인 데이터에 대한 보다 느린 데이터 액세스를 회피하기 위해 클러스터의 작은 비교적 순차적인 부분에 집중되는 것을 요구할 수 있다. SSD들을 사용하는 것은 이러한 한계를 제거한다.
다양한 구현들에 있어서, 저장소(116)에 데이터를 비-순차적으로 저장하는 것은 하나 이상의 저장 유닛들, 예로서 데이터 블록들로 데이터를 분산시키는 것에 기초한다. 그러므로, 데이터 블록은 볼륨에 대한 원 데이터이며 데이터의 최소 어드레싱 가능한 유닛일 수 있다. 메타데이터 층(104) 또는 클라이언트 층(102)은 데이터를 데이터 블록들로 분해할 수 있다. 데이터 블록들은 그 후 다수의 블록 서버들(112) 상에 저장될 수 있다. 데이터 블록들은 고정된 크기일 수 있으며, 처음에 고정된 크기이지만 압축될 수 있거나, 또는 가변 크기일 수 있다. 데이터 블록들은 또한 블록의 맥락 콘텐트에 기초하여 분할될 수 있다. 예를 들면, 특정한 유형의 데이터는 다른 유형들의 데이터에 비교하여 보다 큰 데이터 블록 크기를 가질 수 있다. 기록상에서의 블록들(및 기록상에서의 대응하는 재-어셈블리)의 세분화(segmentation)를 유지하는 것은 클라이언트 층(102) 및/또는 메타데이터 층(104)에서 발생할 수 있다. 또한, 압축이 클라이언트 층(102), 메타데이터 층(104), 및/또는 블록 서버 층(106)에서 발생할 수 있다.
데이터를 비-순차적으로 저장하는 것 외에, 데이터 블록들은 저장 시스템에 걸쳐 실질적으로 고른 분포를 달성하기 위해 저장될 수 있다. 다양한 예들에서, 고른 분포는 고유 블록 식별자에 기초할 수 있다. 블록 식별자는 콘텐트의 해시에 의해서와 같이, 데이터 블록의 콘텐트에 기초하여 결정되는 식별자일 수 있다. 블록 식별자는 데이터의 상기 블록에 고유하다. 예를 들면, 동일한 콘텐트를 가진 블록들은 동일한 블록 식별자를 갖지만, 상이한 콘텐트를 가진 블록들은 상이한 블록 식별자들을 가진다. 고른 분포를 달성하기 위해, 가능한 고유 식별자들의 값들은 균일한 분포를 가질 수 있다. 따라서, 고유 식별자, 또는 고유 식별자의 일 부분에 기초하여 데이터 블록들을 저장하는 것은 클러스터에서의 드라이브들에 걸쳐 실질적으로 고르게 저장되는 데이터를 야기한다.
클라이언트 데이터, 예로서 클라이언트와 연관된 볼륨이 클러스터에서의 드라이브들의 모두에 걸쳐 고르게 확산되기 때문에, 클러스터에서의 모든 드라이브가 각각의 볼륨의 판독 및 기록 경로들에 수반된다. 이러한 구성은 드라이브들의 모두에 걸쳐 데이터 및 로드의 균형을 유지한다. 이러한 배열은 또한 클러스터의 데이터가 임의의 볼륨 상에 순차적으로 저장될 때 발생할 수 있는, 클러스터 내에서의 핫 스폿들을 제거한다.
또한, 클러스터에서의 드라이브들에 걸쳐 고르게 데이터를 확산시키는 것은 클러스터의 일관된 총 총괄 성능이 정의되며 달성되도록 허용한다. 이러한 총합은, 각각의 클라이언트에 대한 데이터가 드라이브들을 통해 고르게 확산되기 때문에 달성될 수 있다. 따라서, 클라이언트의 I/O는 클러스터에서의 드라이브들 모두를 수반할 것이다. 모든 클라이언트들이 저장 시스템에서의 드라이브들 모두를 통해 실질적으로 고르게 그것들의 데이터 확산을 갖기 때문에, 시스템의 성능은 단일 숫자로서, 예로서 저장 시스템에서의 드라이브들 모두의 성능의 합으로서 모두 합쳐 설명될 수 있다.
블록 서버들(112) 및 슬라이스 서버들(124)은 블록 식별자 및 블록 서버(112)의 저장 매체에서의 데이터 블록의 위치 사이에서의 매핑을 유지한다. 볼륨은 이들 고유하며 균일한 랜덤 식별자들을 포함하고, 따라서 볼륨의 데이터는 또한 클러스터 전체에 걸쳐 고르게 분포된다.
메타데이터 층(104)은 클라이언트 층(102) 및 블록 서버 층(106) 사이에서 매핑하는 메타데이터를 저장한다. 예를 들면, 메타데이터 서버들(110)은 클라이언트들(108)에 의해 사용된 클라이언트 어드레싱(예로서, 파일명들, 오브젝트명들, 블록 번호들 등) 및 블록 서버 층(106)에서 사용된 블록 층 어드레싱(예로서, 블록 식별자) 사이에서 매핑시킨다. 클라이언트들(108)은 클라이언트 어드레스들에 기초하여 액세스를 수행할 수 있다. 그러나, 상기 설명된 바와 같이, 블록 서버들(112)은 식별자들에 기초하여 데이터를 저장하며 클라이언트 어드레스들에 기초하여 데이터를 저장하지 않는다. 따라서, 클라이언트는 결국 저장소(116)에서의 클라이언트의 데이터를 참조하는 대응하는 고유 식별자들로 변환되는 클라이언트 어드레스를 사용하여 데이터를 액세스할 수 있다.
시스템(100)의 부분들이 논리적으로 분리되는 것으로서 도시되지만, 엔티티들은 상이한 방식들로 조합될 수 있다. 예를 들면, 층들 중 임의의 것의 기능들은 단일 프로세스 또는 단일 기계(예로서, 컴퓨팅 디바이스)로 조합될 수 있으며 다수의 기능들 또는 모든 기능들이 하나의 기계 상에 또는 다수의 기계들에 걸쳐 존재할 수 있다. 또한, 다수의 기계들에 걸쳐 동작할 때, 기계들은 근거리 네트워크(LAN) 또는 광역 네트워크(WAN)와 같은, 네트워크 인터페이스를 사용하여 통신할 수 있다. 일 구현에 있어서, 하나 이상의 메타데이터 서버들(110)은 단일 기계에서 하나 이상의 블록 서버들(112)과 조합될 수 있다. 시스템(100)에서의 엔티티들은 가상화된 엔티티들일 수 있다. 예를 들면, 다수의 가상 블록 서버들(112)이 기계 상에 포함될 수 있다. 엔티티들은 또한 클러스터에 포함될 수 있으며, 여기에서 클러스터의 컴퓨팅 리소스들은 컴퓨팅 리소스들이 단일 엔티티처럼 보이도록 가상화된다.
도 1b는 일 구현에 따른 시스템(100)의 보다 상세한 예를 묘사한다. 메타데이터 층(104)은 리디렉터 서버(120) 및 다수의 볼륨 서버들(122)을 포함할 수 있다. 각각의 볼륨 서버(122)는 복수의 슬라이스 서버들(124)과 연관될 수 있다.
이 예에서, 클라이언트(108a)는 볼륨(예로서, 클라이언트 어드레스)에 연결하기를 원한다. 클라이언트(108a)는 리디렉터 서버(120)와 통신하고, 개시자 명에 의해 스스로를 식별하며 또한 클라이언트(108a)가 연결하기를 원하는 볼륨을 타겟명에 의해 표시한다. 상이한 볼륨 서버들(122)은 상이한 볼륨들에 책임이 있을 수 있다. 이러한 경우에, 리디렉터 서버(120)는 클라이언트를 특정 볼륨 서버(122)에 리디렉팅하기 위해 사용된다. 클라이언트(108)로, 리디렉터 서버(120)는 단일 접촉 포인트를 나타낼 수 있다. 클라이언트(108a)로부터의 제 1 요청은 그 후 특정 볼륨 서버(122)로 리디렉팅된다. 예를 들면, 리디렉터 서버(120)는 어떤 볼륨 서버(122)가 요청된 타겟 명에 대한 1차 볼륨 서버인지를 결정하기 위해 볼륨들의 데이터베이스를 사용할 수 있다. 클라이언트(108a)로부터의 요청은 그 후 클라이언트(108a)로 하여금 특정 볼륨 서버(122)에 직접 연결하게 하는 특정 볼륨 서버(122)로 향해진다. 클라이언트(108a) 및 특정 볼륨 서버(122) 사이에서의 통신들은 그 후 리디렉터 서버(120) 없이 진행할 수 있다.
볼륨 서버(122)는 메타데이터 서버(110)에 대하여 설명된 바와 같이 기능들을 수행한다. 부가적으로, 각각의 볼륨 서버(122)는 성능 관리기(114)를 포함한다. 볼륨 서버(122)에 의해 호스팅된 각각의 볼륨에 대해, 블록 식별자들의 리스트가 볼륨 상에서 각각의 논리 블록에 대한 하나의 블록 식별자를 갖고 저장된다. 각각의 볼륨은 하나 이상의 볼륨 서버들(122) 사이에서 복제될 수 있으며 각각의 볼륨에 대한 메타데이터는 상기 볼륨을 호스팅하는 볼륨 서버들(122)의 각각 사이에서 동기화될 수 있다. 볼륨 서버(122)가 고장난다면, 리디렉터 서버(120)는 클라이언트(108)를 대안의 볼륨 서버(122)로 향하게 할 수 있다.
일 구현에 있어서, 볼륨 서버(122) 상에 저장되는 메타데이터는 하나의 볼륨 서버(122)에 대해 너무 클 수 있다. 따라서, 다수의 슬라이스 서버들(124)이 각각의 볼륨 서버(122)와 연관될 수 있다. 메타데이터는 슬라이스들로 분할될 수 있으며 메타데이터의 슬라이스는 각각의 슬라이스 서버(124)상에 저장될 수 있다. 볼륨에 대한 요청이 볼륨 서버(122)에서 수신될 때, 볼륨 서버(122)는 어떤 슬라이스 서버(124)가 상기 볼륨에 대한 메타데이터를 포함하는지를 결정한다. 볼륨 서버(122)는 그 후 적절한 슬라이스 서버(124)로 요청을 라우팅한다. 따라서, 슬라이스 서버(124)는 추상의 부가적인 층을 볼륨 서버(122)에 부가한다.
상기 구조는 디스크들의 클러스터에 걸쳐 고르게 데이터의 저장을 허용한다. 예를 들면, 블록 식별자들에 기초하여 데이터를 저장함으로써, 데이터는 클러스터의 드라이브들에 걸쳐 고르게 저장될 수 있다. 상기 설명된 바와 같이, 클러스터에 걸쳐 고르게 저장된 데이터는 성능 메트릭들이 시스템(100)에서의 로드를 관리하도록 허용한다. 시스템(100)이 로드 아래에 있다면, 클라이언트들은 스로틀링(throttle)되거나 또는 볼륨으로부터 록될 수 있다. 클라이언트가 볼륨으로부터 록될 때, 메타데이터 서버(110) 또는 볼륨 서버(122)는 명령 윈도우를 폐쇄하거나 또는 클라이언트(108)에 대한 시간에서 프로세싱되는 판독 또는 기록 데이터의 양을 감소시키거나 또는 영에 맞출 수 있다. 메타데이터 서버(110) 또는 볼륨 서버(122)는 클라이언트(108)에 대한 액세스 요청들을 큐잉할 수 있으며, 따라서 클라이언트(108)로부터의 IO 요청들은 볼륨에 대한 클라이언트의 액세스가 록 아웃(lock out) 기간 후 재개한 후 프로세싱될 수 있다.
저장 시스템의 성능 메트릭들 및 로드
저장 시스템(100)은 또한 저장 시스템의 리소스들의 클라이언트의 사용을 모니터링할 수 있는 성능 관리기(114)를 포함할 수 있다. 또한, 성능 관리기(114)는 저장 시스템(100)의 클라이언트의 사용을 조절할 수 있다. 저장 시스템의 클라이언트의 사용은 성능 메트릭들, 클라이언트의 서비스 품질 파라미터들, 및 저장 시스템의 로드에 기초하여 조정될 수 있다. 성능 메트릭들은 저장 시스템의 다양한 측정 가능한 속성들이다. 하나 이상의 성능 메트릭들은 시스템의 로드를 산출하기 위해 사용될 수 있으며, 이것은 이하에 보다 상세히 설명되는 바와 같이, 시스템의 클라이언트들을 스로틀링하기 위해 사용될 수 있다.
성능 메트릭들은 상이한 카테고리들의 메트릭들로 그룹핑될 수 있다. 시스템 메트릭들은 하나의 이러한 카테고리이다. 시스템 메트릭들은 모든 클라이언트들에 의해 시스템 또는 시스템의 구성요소들의 사용을 반영하는 메트릭들이다. 시스템 메트릭들은 전체 저장 시스템과 또는 저장 시스템 내에서의 구성요소들과 연관된 메트릭들을 포함할 수 있다. 예를 들면, 시스템 메트릭들은 시스템 레벨, 클러스터 레벨, 노드 레벨, 서비스 레벨, 또는 드라이브 레벨에서 산출될 수 있다. 공간 이용은 시스템 메트릭의 일 예이다. 클러스터 공간 이용은 얼마나 많은 공간이 특정한 클러스터에 대해 이용 가능한지를 반영하는 반면, 드라이브 공간 이용은 메트릭은 얼마나 많은 공간이 특정한 드라이브에 대해 이용 가능한지를 반영한다. 공간 이용 메트릭들은 또한 시스템 레벨, 서비스 레벨, 및 노드 레벨에서 결정될 수 있다. 시스템 메트릭들의 다른 예들은 판독 대기 시간, 기록 대기 시간, 초당 입력/출력 동작들(IOPS), 판독 IOPS, 기록 IOPS, I/O 크기, 기록 캐시 용량, 중복 제거-능력(dedupe-ability), 압축률, 총 대역폭, 판독 대역폭, 기록 대역폭, 판독/기록 비, 작업 로드 유형, 데이터 콘텐트, 데이터 유형 등과 같은, 측정되거나 또는 총합된 메트릭들을 포함한다.
IOPS는 클러스터 또는 드라이브에 대해 측정되는 실제 초당 입력/출력 동작들일 수 있다. 대역폭은 클라이언트들(108) 및 데이터의 볼륨 사이에서 전달되는 데이터의 양일 수 있다. 판독 대기 시간은 볼륨으로부터 데이터를 판독하고 데이터를 클라이언트로 리턴하기 위해 시스템(100)에 대해 취해진 시간일 수 있다. 기록 대기 시간은 데이터를 기록하고 성공 표시자를 클라이언트에 리턴하기 위해 시스템에 대해 취해진 시간일 수 있다. 작업 로드 유형은 IO 액세스가 순차적인지 또는 랜덤한지를 표시할 수 있다. 데이터 유형은 액세스/기록되는 데이터의 유형, 예로서 텍스트, 비디오, 이미지들, 오디오 등을 식별할 수 있다. 기록 캐시 용량은 기록 캐시 또는 노드, 블록 서버, 또는 볼륨 서버를 나타낸다. 기록 캐시는 그것이 저장소(116)에 기록되기 전에 데이터를 저장하기 위해 사용되는 비교적 빠른 메모리이다. 상기 주지된 바와 같이, 이들 메트릭들의 각각은 시스템, 클러스터, 노드 등에 대해 독립적으로 산출될 수 있다. 또한, 이들 값들은 또한 클라이언트 레벨에서 산출될 수 있다.
클라이언트 메트릭들은 산출될 수 있는 메트릭들의 또 다른 카테고리이다. 시스템 메트릭들과 달리, 클라이언트 메트릭들은 시스템의 클라이언트의 사용을 고려하여 산출된다. 이하에 보다 상세히 설명되는 바와 같이, 클라이언트 메트릭은 시스템의 공통 특징들을 사용하는 다른 클라이언트들에 의한 사용을 포함할 수 있다. 그러나, 클라이언트 메트릭들은 다른 클라이언트들에 의한 시스템의 비-공통적인 특징들의 사용을 포함하지 않을 것이다. 일 구현예에서, 클라이언트 메트릭들은 구성요소 또는 시스템 전체인 것 대신에, 클라이언트의 볼륨에 특정적인, 시스템 메트릭들과 동일한 메트릭들을 포함할 수 있다. 예를 들면, 판독 대기 시간 또는 기록 IOPS와 같은 메트릭들이 클라이언트의 특정한 볼륨에 대해 모니터링될 수 있다.
시스템 및 클라이언트 양쪽 모두의, 메트릭들은 시간 기간, 예로서 250ms, 500ms, 1s 등에 걸쳐 산출될 수 있다. 따라서, 최소, 최대, 표준 편차, 평균 등과 같은 상이한 값들이 각각의 메트릭에 대해 산출될 수 있다. 메트릭들 중 하나 이상은 저장 시스템의 로드를 표현하는 값을 산출하기 위해 사용될 수 있다. 이하에 보다 상세히 설명되는 바와 같이, 다양한 상이한 로드 산출들이 산출될 수 있다. 로드들은 전체로서 저장 시스템에 대해, 개개의 구성요소들에 대해, 개개의 서비스들에 대해, 및/또는 개개의 클라이언트들에 대해 산출될 수 있다. 로드 값들, 예로서 시스템 로드 값들 및/또는 클라이언트 로드 값들은 그 후 클라이언트들이 스로틀링되는지 및 어떻게 하는지를 결정하기 위해 서비스 품질 시스템에 의해 사용될 수 있다.
이하에 보다 상세히 설명되는 바와 같이, 개개의 클라이언트들에 대한 성능이 모니터링된 메트릭들에 기초하여 조정될 수 있다. 예를 들면, 시스템 메트릭들, 클라이언트 메트릭들, 및 클라이언트 서비스 품질 파라미터들과 같은 다수의 인자들에 기초하여, 시간 기간에 걸쳐 클라이언트(108)에 의해 수행될 수 있는 IOPS의 수가 관리될 수 있다. 일 구현예에서, 성능 관리기(114)는 얼마나 많은 IOPS가 클라이언트(108)에 의해 수행될 수 있는지를 관리하기 위해 상이한 시간 양들에 대해 볼륨 밖에서 클라이언트(108)를 록함으로써 수행되는 IOPS의 수를 조절한다. 예를 들면, 클라이언트(108)가 심하게 제한될 때, 클라이언트(108)가 매 500 밀리초들마다 450 밀리초들 동안 볼륨을 액세스하는 것으로부터 록될 수 있으며 클라이언트(108)가 심하게 제한되지 않을 때, 클라이언트(108)는 매 500 밀리초들 동안 50 밀리초들 마다 볼륨이 제거된다. 록아웃은 클라이언트(108)가 매 500 밀리초들마다 수행할 수 있는 IOPS의 수를 효과적으로 관리한다. IOPS를 사용한 예들이 설명되지만, 이하에 보다 상세히 설명될 바와 같이, 다른 메트릭들이 또한 사용될 수 있다.
시스템(100)에서 로드를 관리하기 위한 메트릭들의 사용은 전역적 클러스터 성능에 대한 클라이언트들의 효과가 데이터의 분포의 균등성, 및 그러므로 데이터 로드로 인해 예측 가능하기 때문에 가능하다. 예를 들면, 클라이언트(108)가 클러스터를 액세스하는 것을 록 아웃함으로써, 클러스터에서의 로드는 효과적으로 관리될 수 있다. 로드가 고르게 분산되기 때문에, 클라이언트의 볼륨에 대한 액세스를 감소시키는 것은 클러스터에 걸쳐 상기 클라이언트의 로드를 고르게 감소시킨다. 그러나, 핫 스폿들이 발생할 수 있는 종래의 저장 아키텍처들은 예측 가능하지 않은 클러스터 성능을 야기한다. 따라서, 클라이언트에 의해 액세스를 감소시키는 것은 클라이언트가 클러스터의 문제 영역들을 액세스하지 않을 수 있기 때문에 핫 스폿들을 완화시키지 않을 수 있다. 설명된 실시예에서, 클라이언트 로드들은 시스템을 통해 고르게 분산되기 때문에, 전역적 성능 풀이 산출될 수 있으며 시스템이 어떻게 사용되는지에 대한 개개의 클라이언트 기여들이 또한 산출될 수 있다.
클라이언트 서비스 품질 파라미터들
시스템 메트릭들 및 클라이언트 메트릭들 외에, 클라이언트 서비스 품질(QoS) 파라미터들이 어떻게 클라이언트가 저장 시스템을 사용하는지에 영향을 미치기 위해 사용될 수 있다. 메트릭들과 달리, 클라이언트 QoS 파라미터들은 측정된 값들이 아니며, 오히려 클라이언트에 대한 원하는 QoS 경계를 정의하는 설정될 수 있는 변수들이다. 클라이언트 QoS 파라미터들은 관리자 또는 클라이언트에 의해 설정될 수 있다. 일 구현예에서, 클라이언트 QoS 파라미터들은 최소, 최대, 및 최대 버스트 값들을 포함한다. 일 예로서 IOPS를 사용할 때, 최소 IOPS 값은 클라이언트에 대한 클라이언트의 성능의 비례 양이다. 따라서, 최소 IOPS는 볼륨이 항상 이러한 최소 IOPS 값에서 수행할 것임을 보장하지 않는다. 볼륨이 오버로드 상황에 있을 때, 최소 IOPS 값은 시스템에 클라이언트에 제공하려고 시도하는 IOPS의 최소 수이다. 그러나, 클라이언트 성능에 기초하여, 개개의 클라이언트의 IOPS는 오버로드 상황 동안 최소 값보다 낮거나 또는 높을 수 있다. 일 구현예에서, 시스템(100)은 모든 클라이언트들에 걸쳐 최소 IOPS의 합이 시스템(100)이 주어진 시간에 모든 클라이언트들에 대해 최소 IOPS 값을 지속시킬 수 있도록 하기 위해 프로비전될 수 있다. 이러한 상황에서, 각각의 클라이언트는 그것의 최소 IOPS 값에서 또는 이상에서 수행할 수 있어야 한다. 그러나, 시스템(100)은 또한 모든 클라이언트들에 걸쳐 최소 IOPS의 합이 시스템(100)이 모든 클라이언트들에 대한 최소 IOPS를 지속시킬 수 없도록 하기 위해 프로비전될 수 있다. 이러한 경우에, 시스템이 모든 클라이언트들의 사용을 통해 오버로딩된다면, 클라이언트의 실현된 IOPS는 클라이언트의 최소 IOPS 값보다 적을 수 있다. 실패 상황들에서, 시스템은 또한 그것들의 실현된 IOPS가 그것들의 최소 IOPS 값보다 작도록 사용자들을 스로틀링할 수 있다. 최대 IOPS 파라미터는 확대된 시간 기간에 걸쳐 최대 유지된 IOPS 값이다. 최대 버스트 IOPS 파라미터는 클라이언트가 크레딧들에 기초하여 짧은 시간 기간 동안 최대 IOPS 파라미터 이상으로 "버스팅(burst)"할 수 있는 최대 IOPS 값이다. 일 구현예에서, 클라이언트에 대한 크레딧들은 클라이언트가 그것들 각각의 최대 IOPS 파라미터 하에서 동작할 때 누적된다. 따라서, 클라이언트는 단지 그것들 각각의 최대 IOPS 및 최대 버스트 IOPS 파라미터들에 따라 시스템을 사용할 수 있을 것이다. 예를 들면, 단일 클라이언트는, 그것들이 이용 가능할지라도 시스템의 전체 리소스들을 사용할 수 없을 것이며, 오히려 그것들 각각의 최대 IOPS 및 최대 버스트 IOPS 파라미터들에 의해 제한된다.
상기 주지된 바와 같이, 클라이언트 QoS 파라미터들은 클라이언트 또는 관리자에 의해 언제라도 변경될 수 있다. 도 2는 일 예시적인 구현에 따라 클라이언트 QoS를 설정하기 위한 사용자 인터페이스(200)를 묘사한다. 사용자 인터페이스(200)는 다양한 QoS 파라미터들을 변경하기 위해 사용되는 입력들을 포함할 수 있다. 예를 들면, 슬라이드 바들(202) 및/또는 텍스트 박스들(204)이 QoS 파라미터들을 조정하기 위해 사용될 수 있다. 일 구현예에서 상기 주지된 바와 같이, 클라이언트 QoS 파라미터들은 최소 IOPS, 최대 IOPS, 및 최대 버스트 IOPS를 포함한다. 이들 파라미터들의 각각은 입력들, 예로서 슬라이드 바들 및/또는 텍스트 박스들을 갖고 조정될 수 있다. 또한, 상이한 크기 IO 동작들에 대한 IOPS가 도시될 수 있다. 사용자 인터페이스(200)에서, 4k 크기 IO 동작들과 연관된 QoS 파라미터들이 변경된다. 임의의 성능 파라미터가 변경될 때, 상이한 크기 IO 동작들에 대한 대응하는 IOPS는 자동으로 조정된다. 예를 들면, 버스트 파라미터가 변경될 때, IOPS 값들(206)은 자동으로 조정된다. 업데이트된 값들은 이하에 보다 상세히 설명되는 바와 같이 성능 곡선에 기초할 수 있다. 일단 QoS 파라미터들이 설정된다면, 저장 변화 버튼(208)을 활성화시키는 것은 클라이언트의 QoS 파라미터들을 업데이트한다. 이하에 설명되는 바와 같이, 타겟 성능 관리기(402)는 업데이트된 QoS 파라미터들을 사용할 수 있으며, 따라서 업데이트된 QoS 파라미터들은 즉시 시행된다. 업데이트된 QoS 파라미터들은 임의의 사용자 데이터가 시스템에서 이동되는 것을 요구하지 않고 시행된다.
성능 관리
도 3은 일 구현에 따라 성능 관리를 수행하는 방법의 간소화된 흐름도(300)를 묘사한다. 방법(300)의 부가적인, 보다 적거나, 또는 상이한 동작들이 특정한 실시예에 의존하여 수행될 수 있다. 방법(300)은 컴퓨팅 디바이스 상에서 구현될 수 있다. 일 구현예에서, 방법(300)은 컴퓨팅 디바이스에 의해 실행될 때, 컴퓨팅 디바이스가 방법(300)의 동작들을 수행하게 하는 지시들을 포함하는 컴퓨터-판독 가능한 매체 상에서 인코딩된다.
302에서, 성능 관리기(114)는 하나 이상의 성능 메트릭들에 기초하여 클라이언트 로드를 결정한다. 예를 들면, 성능 관리기(114)는 IOPS, 대역폭, 및 대기 시간과 같은, 상이한 성능 메트릭들에 기초하여 클라이언트의 로드를 산출할 수 있다. 메트릭들은 이력 메트릭들 및/또는 현재 성능 메트릭들일 수 있다. 이력 성능은 지난 주의 성능 메트릭들과 같은, 시간 양에 대한 이전 성능을 측정할 수 있다. 현재 성능은 실시간 성능 메트릭들일 수 있다. 이들 성능 메트릭들, 예로서 시스템 메트릭들 및/또는 클라이언트 메트릭들을 사용하여, 로드 값이 산출된다. 예시적인 로드 값들이 이하에 보다 상세히 설명된다.
303에서, 성능 관리기(114)는 클러스터의 헬스에 대한 정보를 수집한다. 클러스터의 헬스는 로드 값과 같은, 클러스터의 성능을 수량화할 수 있는 정보일 수 있다. 클러스터 헬스 정보는 시스템(100)의 상이한 부분들로부터 수집될 수 있으며 시스템 메트릭들 및/또는 클라이언트 메트릭들과 같은, 시스템(100)의 많은 상이한 양상들에서의 정보를 포함할 수 있다. 또한 및 이하에 보다 상세히 설명되는 바와 같이, 클러스터 헬스 정보는 클라이언트 및/또는 시스템 메트릭들로부터의 로드 값으로서 산출될 수 있다. 이하에 보다 상세히 설명되는 바와 같이, 헬스 정보는 클러스터-전체가 아닐 수 있지만, 성능 관리를 수행하고 있는 볼륨 서버(122)에 국소적인 정보를 포함할 수 있다. 클러스터 헬스는 영향을 받을 수 있으며; 예를 들면, 발생한 재건된 클러스터 데이터가 있다면, 클러스터의 총 성능은 떨어질 수 있다. 또한, 데이터를 폐기, 노드들의 부가 또는 제거, 볼륨들의 부가 또는 제거, 정전들, 사용된 공간, 또는 성능에 영향을 미치는 다른 이벤트들이 발생할 때, 성능 관리기(114)는 클러스터로부터 이러한 정보를 수집한다.
304에서, 성능 관리기(114)는 타겟 성능 값을 결정한다. 예를 들면, 로드 값들 및 클라이언트 서비스 품질 파라미터들에 기초하여, 타겟 성능 값이 결정된다. 이하에 보다 상세히 설명될 바와 같이, 타겟 성능 값은, 로드 값들, 클라이언트 메트릭들, 시스템 메트릭들, 및 서비스 품질 파라미터들과 같은 상이한 기준들에 기초할 수 있다. 타겟 성능 값은 성능 관리기(114)에서 클라이언트(108)가 동작시키고 싶어하는 값이다. 예를 들면, 타겟 성능은 110 IOPS일 수 있다.
306에서, 성능 관리기(114)는 클라이언트(108)의 성능을 조정한다. 예를 들면, 미래 클라이언트 성능은 타겟 성능 값을 향해 조정될 수 있다. IOPS가 성능 메트릭으로서 측정된다면, 시간 기간에 걸쳐 클라이언트(108)가 수행하는 IOPS의 수는 타겟 성능 값으로 조정될 수 있다. 예를 들면, 클라이언트가 수행할 수 있는 IOPS의 수가 변동되도록 허용하기 위해 대기 시간이 도입되거나 또는 제거될 수 있다. 일 예에서, 이전 클라이언트 성능에서의 IOPS의 수가 80이고 타겟 성능 값이 110 IOPS이면, 클라이언트의 성능은 클라이언트의 성능이 110 IOPS를 수행하는 것을 향해 이동하도록 클라이언트(108)로 하여금 보다 많은 IOPS를 수행하도록 허용하기 위해 조정된다.
종래의 프로비저닝 시스템들은 요청된 서비스 품질을 클라이언트에 제공해야 하는 시스템 상에 클라이언트의 데이터를 배치함으로써 서비스 품질을 달성하려고 시도한다. 그러므로, 그것들의 서비스 품질에 대한 변화를 요청하는 클라이언트는 클라이언트의 데이터가 하나의 시스템에서 또 다른 시스템으로 이동되도록 요구할 수 있다. 예를 들면, 그것의 서비스 품질을 주로 증가시키고 싶어하는 클라이언트는 증가된 서비스 품질을 보장하기 위해 보다 강력한 시스템으로 이동될 필요가 있을 수 있다. 종래의 프로비저닝 시스템들과 달리, 성능 관리기는 클라이언트의 데이터를 또 다른 클러스터에 이동시키지 않고 특정 클라이언트들에 대한 서비스 품질을 동적으로 조정할 수 있다. 따라서, 클라이언트에 대한 서비스 품질은 즉시 조정될 수 있으며, 클라이언트는 시행될 이들 QoS 파라미터들에 대한 수동 개입을 요구하지 않고 QoS 파라미터들을 변경할 수 있다. 이러한 특징은 클라이언트가 그것들의 QoS 파라미터들에 대한 변화들을 스케줄링하도록 허용한다. 예를 들면, 클라이언트가 매달 첫 번째 일요일에 오전 2시에서 오전 4시까지 백업들을 수행한다면, 그것들은 백업의 시작 직전에 자동으로 변경되며 백업이 끝난 후 다시 바뀌는 그것들의 QoS 파라미터들을 가질 수 있다. 이러한 양상은 클라이언트의 요구에 기초하여 그것들의 QoS 파라미터들에 대한 변화들을 스케줄링하기 위한 유연성을 클라이언트에게 허용한다. 또 다른 예로서, 클라이언트는 터보 버튼을 제공받을 수 있다. 선택될 때, 터보 버튼은 몇몇 인자, 예로서 3, 4, 5 등만큼, 또는 몇몇 큰 양으로 클라이언트의 QoS 파라미터들을 증가시킨다. 클라이언트들은, 클라이언트의 웹사이트가 많은 수의 방문자들을 경험할 때와 같이, 그것들의 데이터 요구들이 갑작스럽게 증가된다면 이러한 특징을 사용할 수 있다. 클라이언트는 그 후 그것들의 원래의 QoS 파라미터들로 리턴하기 위해 터보 버튼을 선택 해제할 수 있다. 클라이언트들은 얼마나 길게 그들이 터보 버튼 특징들을 사용하는지에 대해 변경될 수 있다. 또 다른 구현에서, 터보 버튼은 클라이언트의 원래 QoS 파라미터들이 리셋되기 전에 미리 결정된 시간 동안 시행 중인 채로 있다.
상기 예들 외에, 클라이언트들 및/또는 관리자들은 다양한 상태들에 기초하여 클라이언트 QoS 파라미터들을 설정할 수 있다. 또한, 상기 주지된 바와 같이 클라이언트 QoS 파라미터들은 IOPS에 제한되지 않는다. 상이한 구현들에서, 클라이언트 QoS 파라미터들은 대역폭, 대기 시간 등일 수 있다. 상이한 실시예들에 따르면, 저장 시스템은 서비스 제공자들, 클라이언트들, 관리자들 및/또는 사용자들로 하여금 예를 들면, 주어진 사용자 또는 클라이언트에 의해 요구되는 바와 같이, QoS 파라미터들 및/또는 프로비저닝/QoS 타겟 유형들의 다양한 상이한 조합들에 기초할 수 있는 상이한 유형들의 QoS 및 프로비저닝 규칙들을 선택적으로 및 동적으로 구성 및/또는 정의하도록 허용하기 위해 구성되거나 또는 설계될 수 있다.
상이한 실시예들에 따르면, 클라이언트 QoS 파라미터들의 예들은 이에 제한되지 않지만, 다음 중 하나 이상(또는 그것들의 조합들)을 포함할 수 있다:
IOPS;
대역폭;
기록 대기 시간;
판독 대기 시간;
기록 버퍼 큐 깊이;
I/O 크기(예로서, 초당 액세스된 바이트들의 양);
I/O 유형(예로서, 판독 I/O들, 기록 I/O들 등);
예를 들면, 작업 로드유형(예로서, 순차적, 랜덤)과 같은 데이터 속성들; 중복 제거-능력; 압축률; 데이터 콘텐트; 데이터 유형(예로서, 텍스트, 비디오, 이미지들, 오디오 등);
등.
상이한 실시예들에 따르면, 다양한 프로비저닝/QoS 타겟 유형들의 예들이 이에 제한되지 않지만, 다음 중 하나 이상(또는 그것의 조합들)을 포함할 수 있다:
서비스 또는 서비스들의 그룹;
클라이언트 또는 클라이언트들의 그룹;
연결(예로서, 클라이언트 연결);
볼륨, 또는 볼륨들의 그룹;
노드 또는 노드들의 그룹;
계정/클라이언트;
사용자;
iSCSI 세션;
시간 세그먼트;
판독 IOPS 양;
기록 IOPS 양;
애플리케이션 유형;
애플리케이션 우선순위;
볼륨의 영역(예로서, LBA들의 서브세트);
볼륨 세션(들);
I/O 크기;
데이터 속성 유형;
등.
도 8은 서비스 제공자들, 사용자들, 및/또는 다른 엔티티들이 사용의 상이한 성능 클래스들을 동적으로 정의하고 및/또는 생성할 수 있게 및/또는 저장 시스템에서의 성능/QoS 관련 맞춤화들을 정의할 수 있게 하기 위해 구성되거나 또는 설계될 수 있는 예시적인 QoS 인터페이스 GUI(800)를 도시한다. 적어도 일 실시예에서, QoS 인터페이스 GUI는 서비스 제공자들, 사용자들, 및/또는 다른 엔티티들이 사용의 상이한 성능 클래스들 사이에서 동적으로 스위칭하도록 허용하기 위해 구성되거나 또는 설계될 수 있어서, 이러한 클라이언트들이 즉석에서(예로서, 실시간으로) 그것들의 성능 설정들을 동적으로 변경하도록 허용한다.
예를 들면, 다양한 실시예들에 따르면, 서비스 제공자는 저장 시스템에서의 사용의 상이한 성능 클래스들을 동적으로 정의 및/또는 생성할 수 있고, 클라이언트들이 사용의 상이한 성능 클래스들 사이에서 동적으로 스위칭하도록 허용할 수 있어서, 이러한 클라이언트들이 즉석에서(예로서, 실시간으로) 그것들의 성능 설정들을 동적으로 수정하거나 또는 변경하도록 허용한다. 적어도 일 실시예에서, 저장 시스템은 특정 프로비저닝/QoS 타겟들에 대해, 및 성능/QoS 수정들을 구현하기 위해 클라이언트의 저장 볼륨이 오프-라인으로 취해지도록 요구하지 않고, 특정된 변화들을 즉시 구현하도록 구성되거나 또는 설계된다. 적어도 일 실시예에서, 사용의 상이한 성능 클래스들은 각각 예를 들면, QoS 파라미터들 및/또는 프로비저닝/QoS 타겟 유형들의 다양한 상이한 조합들에 기초할 수 있는 QoS 및/또는 프로비저닝 규칙들(예로서, 810)의 각각의 세트와 연관된다.
성능 관리를 수행하기 위한 상기 프로세스는 시간의 기간들에 걸쳐 연속적으로 수행될 수 있다. 예를 들면, 500 밀리초들의 기간은 성능이 조정되어야 하는지를 평가하기 위해 사용된다. 이하에 보다 상세히 설명될 바와 같이, 클라이언트(108)는 수행되는 IOPS의 수를 감소시키거나 또는 증가시키기 위해 각각의 기간의 특정한 시간 양 동안 IOPS를 수행하는 것으로부터 록될 수 있다.
상이한 유형들의 조건들, 기준들, 및/또는 도 8의 QoS 인터페이스 GUI를 구성하기 위해 사용될 수 있는 다른 정보의 예들은 이에 제한되지 않지만, 다음 중 하나 이상(또는 그것의 조합)을 포함할 수 있다.
예시적인 경계 조건들(예로서, 824)
ㆍ 로드(서비스); ㆍ 날짜
ㆍ 로드(판독); ㆍ 판독 IOPS
ㆍ 로드(기록); ㆍ 기록 IOPS
ㆍ 로드(기록_버퍼); ㆍ 애플리케이션 유형
ㆍ 로드(클라이언트-판독); ㆍ 애플리케이션 우선순위
ㆍ 로드(클라이언트-기록); ㆍ 볼륨의 영역
ㆍ 로드(클라이언트); ㆍ LAB ID
ㆍ 로드(클러스터); ㆍ 볼륨 세션 ID
ㆍ 로드(시스템); ㆍ 연결 ID
ㆍ 기록 대기 시간; ㆍ I/O 크기
ㆍ 판독 대기 시간; ㆍ I/O 유형
ㆍ 기록 버퍼 큐 깊이; ㆍ 작업 로드 유형
ㆍ 로드(클라이언트); ㆍ 중복 제거-능력
ㆍ 볼륨 ID ㆍ 압축률
ㆍ 그룹 ID ㆍ 데이터 콘텐트
ㆍ 계정 ID ㆍ 데이터 유형
ㆍ 클라이언트 ID ㆍ 데이터 속성들
ㆍ 사용자 ID ㆍ 검출 가능한 상태 및/또는 이벤트
ㆍ iSCSI 세션 ID ㆍ 등
ㆍ 시간
예시적인 QoS 파라미터들(예로서, 842)
ㆍ 최대 IOPS ㆍ 최대 판독 I/O
ㆍ 최소 IOPS ㆍ 최소 판독 I/O
ㆍ 버스트 IOPS ㆍ 버스트 판독 I/O
ㆍ 최대 대역폭 ㆍ 최대 기록 I/O
ㆍ 최소 대역폭 ㆍ 최소 기록 I/O
ㆍ 버스트 대역폭 ㆍ 버스트 기록 I/O
ㆍ 최대 대기 시간 ㆍ I/O 유형
ㆍ 최소 대기 시간 ㆍ 작업 로드 유형
ㆍ 버스트 대기 시간 ㆍ 중복 제거-능력
ㆍ 최대 I/O 크기 ㆍ 압축률
ㆍ 최소 I/O 크기 ㆍ 데이터 콘텐트
ㆍ 버스트 I/O 크기 ㆍ 데이터 유형
ㆍ I/O 유형 ㆍ 과금 양
예시적인 프로비저닝/QoS 타겟들(예로서, 844)
ㆍ 클러스터 ID ㆍ 시간
ㆍ 서비스 ID ㆍ 날짜
ㆍ 클라이언트 ID ㆍ 판독 IOPS
ㆍ 연결 ID ㆍ 기록 IOPS
ㆍ 노드 ID ㆍ 애플리케이션 유형
ㆍ 볼륨 ID ㆍ 애플리케이션 우선 순위
ㆍ 그룹 ID ㆍ 볼륨의 영역
ㆍ 계정 ID ㆍ LBA ID
ㆍ 클라이언트 ID ㆍ 볼륨 세션 ID
ㆍ 사용자 ID ㆍ 연결 ID
ㆍ iSCSI 세션 ID ㆍ I/O 크기
ㆍ I/O 유형 ㆍ 데이터 콘텐트
ㆍ 작업 로드 유형 ㆍ 데이터 유형
ㆍ 중복 제거-능력 ㆍ 데이터 속성들
ㆍ 압축률 ㆍ 등
예시적인 연산자들(예로서, 826, 846)
ㆍ 과 같은 ㆍ 과 같지 않은
ㆍ 보다 작은 ㆍ 포함하는
ㆍ 보다 큰 ㆍ 포함하지 않는
ㆍ 이하 ㆍ 매칭하는
ㆍ 이상 ㆍ 정규 표현(들)
ㆍ 의 범위 내에 있는
예시적인 임계 값들(예로서, 828, 848)
ㆍ 영숫자 값(들) ㆍ 랜덤 유형
ㆍ 수치 값(들) ㆍ 텍스트 유형
ㆍ 수치 범위(들) ㆍ 비디오 유형
ㆍ 시간 간격 값당 수치 값 ㆍ 오디오 유형
(예로서, 5000 IOPS/초) ㆍ 이미지 유형
ㆍ 순차적 유형 ㆍ 사용의 성능 클래스 값
예시적인 부울 연산자들(예로서, 825, 845)
ㆍ AND ㆍ NAND
ㆍ OR ㆍ NOR
ㆍ XOR ㆍ XNOR
ㆍ NOT
ㆍ EXCEPT
다음의 예시적인 시나리오들은 QoS 인터페이스 GUI(800)에 의해 인에이블된 다양한 특징들 및 기능들을 예시하도록 도우며, 저장 시스템의 성능/QoS 관련 프로비저닝 특징들을 예시하도록 돕는다.
예 A - 백업이 시간의 특정 윈도우 동안 더 빨라질 수 있게 하기 위해 저장 성능을 자동으로 및/또는 동적으로 증가시키도록 저장 시스템을 구성/프로비저닝. 예를 들면, 일 실시예에서, 볼륨 백업 동작의 속도는 최대 IOPS 값 및/또는 최소 IOPS 값이 상기 특정한 시간 간격 동안 자동으로 및 동적으로 증가되게 함으로써 특정 시간 간격 동안 자동으로 및 동적으로 증가될 수 있다.
예 B - 자동으로 및/또는 동적으로 선택된 개시자가 오후 10시에서 자정까지 보다 빠른 순차적인 IO들을 수행할 수 있게 하도록 저장 시스템을 구성/프로비저닝.
예 C - 자동으로 및/또는 동적으로 선택된 애플리케이션이 증가된 I/O 저장 성능을 가질 수 있게 하도록 저장 시스템을 구성/프로비저닝.
예 D - 자동으로 및/또는 동적으로 클라이언트들의 선택된 그룹이 각각의 달의 선택된 날들/날짜들에서 2배인 그것들 각각의 최대, 최소, 및 버스트 IOPS를 가질 수 있게 하도록 저장 시스템을 구성/프로비저닝.
예 E - 가상 터보 버튼을 포함하는 "터보 부스트(Turbo Boost)" 인터페이스를 클라이언트 또는 사용자에게 제공하도록 저장 시스템을 구성/프로비저닝. 클라이언트는 그에 의해 저장 시스템이 상기 클라이언트에 대해 프로비전되는 성능의 레벨을 자동으로 및 동적으로 증가시키게 하기 위해 터보 버튼을 수동으로 활성화시키도록(예로서, 즉석에서 또는 실시간으로) 선택할 수 있다. 예를 들면, 일 실시예에서, 터보 버튼의 클라이언트 활성화는 저장 시스템이 1시간 동안 3x의 배수에 의해 클라이언트 프로비전되는 성능을 자동으로 및 동적으로 증가시키게 할 수 있다. 적어도 일 실시예에서, 프로비전되는 성능에서의 동적 증가는 미리 결정된 시가 간격 후 자동으로 중단될 수 있다. 적어도 일 실시예에서, 저장 시스템은 터보 부스트 서비스/특징의 사용에 대한 증가된 과금 양을 클라이언트에 청구하도록 구성되거나 또는 설계될 수 있다.
예 F - 특정한 시간에 더 빠르게 하기 위해 증가된 저장 어레이 성능(예로서, 보다 빠른 백업을 허용하기 위해)을 동적으로 제공하기 위한 부가적인 요금 또는 과금 양을 자동으로 및/또는 동적으로 청구하도록 저장 시스템을 구성/프로비저닝.
예 G - 하나 이상의 지정된 시간 간격들 동안 최소 임계 값(들)을 초과하는 저장 시스템의 I/O 액세스 및/또는 IOPS에 대한 부가적인 요금 또는 과금 양을 자동으로 및/또는 동적으로 청구하도록 저장 시스템을 구성/프로비저닝.
성능 관리기(114)는 성능을 조정하는 상이한 방식들을 사용할 수 있다. 도 4는 일 구현에 따른 성능 관리기(114)를 사용하여 성능을 조정하는 보다 상세한 예를 묘사한다. 타겟 성능 관리기(402)는 타겟 성능 값을 결정한다. 일 구현예에서, 타겟 성능 관리기(402)는 타겟 성능 값을 결정하기 위해 클라이언트의 QoS 파라미터들, 시스템 메트릭들, 및 클라이언트 메트릭들을 사용한다. 이하에 보다 상세히 설명될 바와 같이, 시스템 메트릭들 및 클라이언트 메트릭들은 시스템 로드 및 클라이언트 로드를 결정하기 위해 사용될 수 있다. 일 예로서, 클라이언트 로드는 IOPS, 바이트들, 또는 밀리초들로의 대기 시간들과 같은, 클라이언트 메트릭들에 기초하여 측정될 수 있다.
일 구현예에서, 시스템 메트릭들은 클러스터의 현재 로드를 수량화하는 데이터이다. 이하에 보다 상세히 설명될 바와 같이, 다양한 시스템 로드 값들이 시스템 메트릭들에 기초하여 산출될 수 있다. 로드 값들은 시스템 로드의 정규화된 측정치들일 수 있다. 예를 들면, 상이한 로드 값들은, 로드 값들이 그것들의 산출들에서 상이한 메트릭들을 사용할지라도, 서로 비교될 수 있다. 일 예로서, 시스템 로드는 클러스터의 현재 로드에 기초하여 퍼센티지로 표현될 수 있다. 일 예에서, 요청들을 프로세싱하는 것으로 오버로딩되는 클러스터는 시스템이 오버로드되지 않을 때보다 낮은 값을 가질 수 있다. 또 다른 구현에서, 타겟 성능 관리기(402)는 시스템 및/또는 클라이언트 메트릭들보다, 입력으로서 산출된 로드 값들을 수신한다.
타겟 성능 관리기(402)는 클라이언트 QoS 파라미터들, 관련 있는 시스템 메트릭들, 및 관련 있는 클라이언트 메트릭들을 판독할 수 있다. 이들 값들은 클라이언트(108)에 대한 타겟 성능 값을 결정하기 위해 사용될 수 있다. QoS 파라미터들은 또한 보다 높은 레벨의 성능이 요구될 때(예로서, 고객이 보다 높은 레벨의 성능에 대해 지불한)와 같이, 상기 설명된 바와 같이 관리자 또는 클라이언트에 의한 런타임 동안 동적으로 조정될 수 있다. 타겟 성능 값의 산출은 이하에 보다 상세히 설명된다.
일 구현예에서, 타겟 성능 관리기(402)는 비례-적분-미분(PID) 제어기 블록(404)에 타겟 성능 값을 출력한다. PID 제어기 블록(404)은 상이한 성능 메트릭들에 대한 다수의 PID 제어기들을 포함할 수 있다. PID 제어기들이 설명되지만, 다른 제어기들이 클라이언트들(108)의 성능을 제어하기 위해 사용될 수 있다. 일 예에서, PID 제어기 블록(404)은 IOPS, 대역폭, 및 대기 시간에 대한 PID 제어기들을 포함한다. 타겟 성능 관리기(402)는 성능 메트릭들에 대한 상이한 타겟 성능 값들을 적용 가능한 PID 제어기들에 출력한다. PID 제어기들은 또한 이전 및/또는 현재 클라이언트 성능 및 타겟 성능 값에 대한 정보를 수신한다. 예를 들면, PID 제어기들은 타겟 성능 값과 부합하는, 클라이언트 메트릭들, 시스템 메트릭들, 및/또는 로드 값들을 수신할 수 있다. PID 제어기는 그 후 클라이언트 성능 조정 값을 결정할 수 있다. 예를 들면, PID 제어기는 이전 클라이언트 성능의 피드백을 취하며 시스템으로 하여금 타겟 성능 값을 향해 이동하게 하기 위해 값을 결정하도록 구성된다. 예를 들면, PID는 다양한 양들의 압력이 인가되게 할 수 있으며, 이러한 경우에서 압력은 클라이언트(108)가 IOPS를 수행할 때와 동일하게 속도를 늦추고, 속도를 올리거나 또는 그대로 있게 한다. 일 예로서, 타겟 성능 값이 110 IOPS이며 클라이언트(108)가 90 IOPS에서 동작한다면, 클라이언트 성능 조정 값이 출력되며, 이것은 클라이언트(108)에 적용됨으로써, 수행되는 IOPS의 수를 증가시켜야 한다.
일 구현예에서, PID 제어기 블록(404)은 성능 조정 값을 출력한다. 일 예로서, 성능 조정 값은 클라이언트가 저장 시스템 내에서 IO 동작들을 수행하는 것이 록 아웃되는 시간의 양을 표시하는 압력 값일 수 있다. 이러한 록 아웃 시간은 클라이언트 성능이 타겟 성능 값을 향해 이동하게 할 것이다. 예를 들면, 밀리 초들에서의 시간은 얼마나 길게 볼륨에서 클라이언트(108)를 록하는지를 결정하기 위해 사용되는 출력이다. IO 동작들을 수행하는 것에서 클라이언트를 록하는 것은 클라이언트의 IO 동작들로 대기 시간을 인위적으로 주입한다. 또 다른 구현들에서, 성능 조정 값은 클라이언트가 시간 기간에 수행할 수 있는 IO 동작들의 수일 수 있다. 클라이언트가 보다 많은 IO 동작들을 수행하려고 시도한다면, 클라이언트는 후속 시간 기간까지 이들 IO 동작들을 행하는 것으로부터 록될 수 있다. 상이한 시간들 동안 볼륨에서 클라이언트(108)를 록하는 것은 클라이언트(108)에 의해 수행된 IOPS의 수를 변경한다. 예를 들면, 보다 짧은 시간 기간들 동안 볼륨으로부터 클라이언트(108)를 록하는 것은 상기 기간 동안 클라이언트(108)에 의해 수행될 수 있는 IOPS의 수를 증가시킨다.
성능 제어기(406)는 성능 조정 값을 수신하며 클라이언트(108)의 성능을 제어하기 위해 클라이언트 제어 신호를 출력한다. 예를 들면, 록아웃의 양이 산출될 수 있으며 1/2초마다 적용된다. 일 구현예에서, 클라이언트들(108)은 인터넷 소형 컴퓨터 시스템 인터페이스(iSCSI) 명령 윈도우와 같은, 명령 윈도우를 폐쇄 및 개방함으로써 록 아웃된다. 명령 윈도우를 폐쇄하는 것은 클라이언트(108)가 볼륨에 액세스 요청을 발행하도록 허용하지 않으며 명령 윈도우를 개방하는 것은 클라이언트(108)가 볼륨에 액세스 요청들을 발행하도록 허용한다. 볼륨에서 클라이언트들(108)을 록하는 것은 클라이언트에 대한 IOPS의 수, 대역폭, 또는 대기 시간을 조정할 수 있다. 예를 들면, 클라이언트(108)가 매 500 밀리초들 중 450 밀리초들 동안 볼륨에서 록되는 것과 비교하여 매 500 밀리초들 중 매 50 밀리초들마다 볼륨에서 록된다면, 클라이언트는 보다 많은 IOPS를 발행할 수 있다. 대역폭 예에 대해, 대역폭이 제한된다면, 클라이언트(108)는 이용 가능한 대역폭을 증가시키기 위해 보다 긴 시간 기간 동안 볼륨으로부터 록된다. 또 다른 구현에서, 한 번에 서비스되는 데이터의 양은, 시스템이 상기 클라이언트의 IO를 서비스하는 성능에 영향을 미치도록 0 또는 몇몇 숫자로 수정된다.
상기 설명된 바와 같이, IOPS는 클라이언트의 성능을 관리하기 위해 사용될 수 있는 메트릭들이다. IOPS는 기록 IOPS 및 판독 IOPS 양쪽 모두를 포함한다. 개개의 입력/출력 동작들은 세트 크기를 갖지 않는다. 즉, 입력 동작은 드라이브에 64k의 데이터를 기록할 수 있는 반면, 또 다른 입력 동작은 드라이브에 4k의 데이터를 기록할 수 있다. 따라서, 시간 기간에 걸쳐 원래 수의 입력/출력 동작들을 캡처하는 것은 반드시 IO 동작이 실제로 얼마나 비싼지를 캡처하는 것은 아니다. 이러한 상황을 고려하기 위해, 입력/출력 동작은 I/O 동작의 크기에 기초하여 정규화될 수 있다. 이러한 특징은 데이터의 각각의 동작의 크기에 관계없이, IOPS의 일관된 처리를 허용한다. 이러한 정규화는 성능 곡선을 사용하여 달성될 수 있다. 도 5는 예시적인 구현에 따라 시스템 로드와 입력/출력 동작들의 크기를 비교하는 성능 곡선(500)을 묘사한다. 라인(504)은 전체 로드에서 시스템을 표시하는 반면, 라인(502)은 상이한 크기들의 IO 동작들에 대한 시스템의 로드를 표시한다. 성능 곡선은 시스템(100)의 경험적 데이터에 기초하여 결정될 수 있다. 성능 곡선은 상이한 크기들의 IOPS가 비교되며 상이한 크기들의 IOPS를 정규화하도록 허용한다. 예를 들면, 크기(32k)의 IOP는 4k IOP보다 대략 5배 더 비싸다. 즉, 시스템의 100% 로드를 달성하기 위해 크기(32k)의 IOPS의 수는 크기(4k)의 IOPS의 수의 대략 20%이다. 이것은 보다 큰 블록 크기들이 IP를 행하며 보다 작은 블록들의 데이터를 프로세싱할 필요가 없는 할인을 갖기 때문이다. 다양한 구현들에서, 이러한 곡선은 클라이언트의 타겟 성능 값을 결정할 때 인자로서 사용될 수 있다. 예를 들면, 클라이언트에 대한 타겟 성능 값이 1,000 IOPS인 것으로 결정된다면, 이러한 숫자는 클라이언트가 과거에 행한 IO들의 평균 크기에 기초하여 변경될 수 있다. 일 예로서, 클라이언트의 평균 IO 크기가 4k이면, 클라이언트의 타겟 성능 값은 1,000 IOPS에 남아 있을 수 있다. 그러나, 클라이언트의 평균 IO 크기가 32k인 것으로 결정된다면, 클라이언트의 타겟 성능 값은 200개의 IOPS, 예로서, 1000*0.2로 감소될 수 있다. 크기(32k)의 200개의 IOPS는 크기(4k)의 1,000 IOPS와 대략 동일하다.
타겟 성능 값을 결정할 때, 타겟 성능 관리기(402)는 클라이언트에 대한 타겟 성능 값을 결정하기 위해 클라이언트의 QoS 파라미터들을 사용한다. 일 구현예에서, 오버로드 조건이 검출되며 모든 클라이언트들은 일관된 방식으로 스로틀링된다. 예를 들면, 시스템 로드가 20%에 있는 것으로 결정된다면, 모든 클라이언트들은 그것들의 타겟 성능 값이 그것들의 최대 IOPS 설정의 90%로 설정되도록 스로틀링될 수 있다. 시스템 로드가 50%로 증가한다면, 모든 클라이언트들은 그것들의 최대 IOPS 설정의 40%로 그것들의 타겟 성능 값을 설정하는 것에 기초하여 스로틀링될 수 있다. 오버로드 조건들이 어떻게 결정되는지에 대한 부가적인 예들이 이하에 제공된다.
클라이언트들은 유사한 방식으로 스로틀링될 필요는 없다. 예를 들면, 클라이언트들은 사용들의 상이한 클래스들에 속할 수 있다. 일 구현예에서, 사용들의 클래스들은 상이한 클라이언트들의 QoS 파라미터들을 상이하게 설정함으로써 간단히 구현될 수 있다. 예를 들면, 사용의 프리미엄 클래스는 사용의 정상 클래스와 비교하여 보다 높은 QoS 파라미터들, 예로서 최소 IOPS, 최대 IOPS, 및 버스트 IOPS 값들을 가질 수 있다. 또 다른 구현에서, 사용의 클래스는 타겟 성능 값을 산출할 때 고려될 수 있다. 예를 들면, 두 개의 상이한 클래스들을 취하며, 하나의 클래스는 다른 클래스보다 적게 스로틀링될 수 있다. 상기 예시적인 시나리오를 사용하여, 제 1 클래스에 속한 클라이언트들은 시스템 로드가 20%에 도달할 때 그것들의 최대 IOPS 값의 80%로 스로틀링될 수 있다. 그러나, 클라이언트들의 제 2 클래스는 전혀 스로틀링되지 않거나 또는, 그것들의 최대 IOPS 값의 95%와 같이, 상이한 양만큼 스로틀링될 수 있다.
또 다른 구현에서, 클라이언트의 최소 IOPS 및 최대 IOPS 사이에서의 차이는 특정한 클라이언트를 얼마나 많이 스로틀링할지를 결정하기 위해 사용될 수 있다. 예를 들면, 큰 차이를 가진 클라이언트는 그 차이가 작은 클라이언트보다 많이 스로틀링될 수 있다. 일 구현예에서, 클라이언트의 최대 IOPS 및 최소 IOPS 사이에서의 차이는 타겟 성능 값을 산출하기 위해 적용되는 인자를 산출하기 위해 사용된다. 이러한 구현에서, 인자는 5,000 IOPS와 같은, 몇몇 미리 결정된 IOPS 양으로 나뉘어진 IOPS 차이로서 결정될 수 있다. 이러한 예에서, 그것들의 최대 IOPS 및 그것들의 최소 IOPS 사이에서의 차이가 10,000인 클라이언트는 그 IOPS 차이가 5,000인 클라이언트보다 2배 스로틀링될 것이다. 시스템의 클라이언트들은 그것들의 클래스에 기초하여 상이한 양들을 청구될 수 있다. 따라서, 클라이언트들은 나중에 스로틀링되도록 더 많이 및/또는 다른 클래스들의 클라이언트들보다 적게 지불할 수 있다.
또 다른 구현에서, 클라이언트들의 스로틀링은 시스템의 클라이언트의 사용에 기초할 수 있다. 이러한 구현에서, 타겟 성능 관리기(402)는 어떤 메트릭들이 현재 오버로드되는지를 결정하기 위해 시스템 메트릭들을 검토할 수 있다. 다음으로, 클라이언트 메트릭들은 상기 클라이언트가 오버로딩된 시스템 값에 기여하는지를 결정하기 위해 분석될 수 있다. 예를 들면, 타겟 성능 관리기(402)는 클러스터의 기록 대기 시간이 오버로딩될 때 시스템이 오버로드됨을 결정할 수 있다. 클라이언트에 대한 판독/기록 IOPS 비는 특정한 클라이언트가 오버로드 조건에 보다 큰 영향을 갖는지를 결정하기 위해 사용될 수 있다. 이러한 예를 계속하면, 그 판독/기록 IOPS 비가 클라이언트가 판독들보다 3배 더 많이 기록들을 행하며 1,500의 기록들을 행하도록 하는 클라이언트는 클러스터의 성능에 부정적으로 영향을 주는 것으로 결정될 것이다. 따라서, 타겟 성능 관리기(402)는 이러한 클라이언트를 상당히 스로틀링할 수 있다. 일 구현에 있어서, 이러한 특징은 판독/기록 IOPS 비에 기초하여 인자를 산출함으로써 행해질 수 있다. 이러한 인자는 타겟 성능 값을 산출할 때 적용될 수 있으며, 따라서 상기 예시적인 클라이언트는 그것의 판독/기록 IOPS 비가 높은 클라이언트보다 많이 스로틀링될 것이다. 이 예에서, 높은 판독/기록 IOPS 비는 클라이언트가 기록들보다 더 많은 판독들을 행하고 있음을 표시한다. 인자는 또한 각각의 클라이언트가 행한 IOPS의 수에 기초할 수 있다. 또한, 특정한 클라이언트에 대한 IOPS의 수는 클러스터에 대한 IOPS의 수에 비교될 수 있으며, 따라서 얼마나 심하게 특정한 클라이언트가 클러스터를 사용하고 있는지에 대한 표시가 결정될 수 있다. 이러한 정보를 사용하여, 타겟 성능 관리기는 모든 다른 클라이언트들과 비교하여 얼마나 많은 클라이언트가 시스템을 사용하고 있는지에 기초하여 타겟 성능 값을 스케일링하기 위해 사용될 수 있는 또 다른 인자를 산출할 수 있다.
도 6은 일 예시적인 구현에 따라 클라이언트 메트릭과 오버로딩된 시스템을 매칭시키는 성능 관리를 수행하는 방법(600)의 간소화된 흐름도를 묘사한다. 방법(600)의 부가적인, 보다 적거나, 또는 상이한 동작들이 특정한 실시예에 의존하여 수행될 수 있다. 방법(600)은 컴퓨팅 디바이스 상에 구현될 수 있다. 일 구현예에서, 방법(600)은 컴퓨팅 디바이스에 의해 실행될 때, 컴퓨팅 디바이스가 방법(600)의 동작들을 수행하게 하는 지시들을 포함하는 컴퓨터-판독 가능한 매체 상에서 인코딩된다.
동작(602)에서, 클라이언트 메트릭들이 결정될 수 있다. 예를 들면, 성능 관리기(114)는 앞선 시간 기간, 예로서 100 ms, 1 s, 10 s 등 동안 상기 설명된 바와 같이 클라이언트 메트릭들을 결정할 수 있다. 동작(604)에서, 시스템 메트릭들이 결정될 수 있다. 예를 들면, 성능 관리기(114) 또는 또 다른 프로세스는 상기 설명된 바와 같이 시스템 메트릭들을 결정할 수 있다. 일 구현에 있어서, 클라이언트 메트릭들 및/또는 시스템 메트릭들은 하나 이상의 로드 값들을 산출하기 위해 사용된다. 로드 값들의 산출은 이하에 보다 상세히 설명된다. 동작(606)에서, 타겟 성능 관리기(402)는 그 후 다양한 로드 값들에 기초한 방식으로 시스템이 오버로딩되는지를 결정할 수 있다. 예를 들면, 타겟 성능 관리기(402)는 대응하는 임계치들과 시스템 로드 값들을 비교함으로써 시스템이 오버로드되는지를 결정할 수 있다. 그것의 대응하는 임계치 이상의 임의의 로드 값들은 오버로드 상태를 표시한다. 일 구현예에서, 시스템 로드 값들은 우선순위화된 순서로 분석되며 제 1 오버로딩된 로드 값은 클라이언트들을 스로틀링하는 방법을 결정하기 위해 사용된다.
동작(608)에서, 오버로딩된 로드 값과 연관된 하나 이상의 대응하는 클라이언트 메트릭들이 결정된다. 예를 들면, 오버로딩된 시스템 로드가 판독 동작들의 수이면, 클라이언트의 판독 동작들의 수는 연관된 클라이언트 메트릭으로서 사용될 수 있다. 클라이언트의 메트릭은 오버로딩된 시스템 메트릭과 동일할 필요는 없다. 또 다른 예로서, 오버로딩된 시스템 로드가 판독 대기 시간이라면, 대응하는 클라이언트 메트릭들은 판독 대 기록 IO 동작들의 비 및 클라이언트에 대한 판독 동작들의 총 수일 수 있다. 동작(610)에서, 클라이언트-특정 인자는 오버로딩된 시스템 로드 값과 연관된 클라이언트 메트릭에 기초하여 결정된다. 상기 제 1 예에서, 인자는 클러스터의 판독 동작들의 총 수로 나뉘어진 클라이언트의 판독 동작들의 수일 수 있다. 그러므로, 클라이언트 인자는 얼마나 많은 클라이언트가 시스템 로드 값에 기여하는지에 대한 것일 것이다. 비교적 더 많은 수의 판독들을 행한 클라이언트들은 비교적 보다 적은 수의 판독들을 행한 클라이언트와 비교하여 보다 큰 클라이언트 메트릭을 가질 것이다.
동작(612)에서, 클라이언트-특정 인자는 클라이언트에 대한 타겟 성능 값을 산출하기 위해 사용된다. 일 구현예에서, 초기 타겟 성능 값이 산출될 수 있으며 그 후 클라이언트 특정 인자로 곱하여질 수 있다. 또 다른 구현에서, 클러스터 감소 값이 결정되며 이 값은 클라이언트 특정 인자로 곱하여진다. 상기 예를 계속하면, 클러스터 감소 값은 스로틀링되어야 하는 판독 IOPS의 수일 수 있다. 클러스터 감소 값에 기초하여 각각의 클라이언트를 동일하게 스로틀링하는 것과 비교하여, 클라이언트-특정 인자를 사용하는 것은 스로틀링되는 동일한 수의 판독 IOPS를 야기하지만, 다수의 판독 IO 동작들을 가진 클라이언트들은 보다 작은 수의 판독 IO 동작들을 가진 클라이언트들보다 많이 스로틀링된다. 클라이언트-특정 인자들을 사용하는 것은 타겟 성능 관리기(402)가 스로틀링이 효과적임을 보장하도록 돕기 위해 클라이언트들의 스로틀링을 제어하도록 돕는다. 예를 들면, 클라이언트-특정 인자들이 사용되지 않으며 스로틀링이 모든 클라이언트들에 걸쳐 동일하게 적용된다면, 시스템의 사용이 시스템의 오버로딩에 기여하지 않는 클라이언트는 불필요하게 스로틀링될 것이다. 더 나쁘게, 클라이언트들의 모두의 스로틀링은 스로틀링될 필요가 없는 클라이언트들의 스로틀링이 클라이언트들에 적용되는 훨씬 더 많은 스로틀링을 야기할 수 있는, 오버로딩 상태를 용이하게 하도록 돕지 않을 것이다.
동작(614)에서, 성능 관리기(114)는 클라이언트(108)의 성능을 조정할 수 있다. 예를 들면, 시스템의 클라이언트의 사용은 상기 설명된 바와 같이 스로틀링될 수 있다.
상기 시스템을 사용하여, 클라이언트들(108)은 IOPS와 같은, 성능 메트릭들에 기초하여 성능 보장들을 제공받을 수 있다. 예를 들면, 시스템(100)이 총 수의 IOPS를 프로세싱할 수 있다는 것을 고려하면, 총 수는 총 양 내에서의 IOPS의 수에 관해서 상이한 클라이언트들(108) 중에서 나뉘어질 수 있다. IOPS는 최소, 최대, 및 버스트를 사용하여 할당된다. 그것이 총 수 이상이면, 가능한, 관리자는 너무 많은 IOPS가 보증됨을 통지받으며 보다 많은 성능 용량을 부가하거나 또는 IOPS 보증들을 변경하도록 지시받는다. 이러한 통지는 용량 임계치가 도달되기 전(예로서, 전체 용량 또는 전체 용량 미만의 미리-정의된 임계치)일 수 있다. 통지는 클라이언트 성능이 IOPS에 대하여 특성화되기 때문에 용량이 도달되기 전에 전송될 수 있으며 관리자는 성능이 N 수의 IOPS에 의해 오버프로비전됨을 경고받을 수 있다. 예를 들면, 클라이언트들(108)은 시간에 걸쳐 최소 및 최대 수의 IOPS 사이에서(특정한 시간들에서 최대치 이상의 버스트들을 갖고) 동작되도록 보장받을 수 있다. 성능 관리기(114)는 상기 시스템을 사용하여 이들 QoS 파라미터들 내에서의 성능을 보장할 수 있다. 로드가 고르게 분산되기 때문에, 핫 스폿들은 발생하지 않을 것이며 시스템(100)은 약 총 양의 IOPS를 규칙적으로 동작시킬 수 있다. 따라서, 핫 스폿 문제들 없이 및 총 양의 IOPS를 규칙적으로 제공할 수 있는 시스템(100)을 갖고, 성능은 클라이언트들(108)에 의해 수행된 IOPS의 수가, 각각의 클라이언트가 각각의 주어진 클라이언트(108)에 대한 QoS 파라미터들 내에서 동작하고 있음을 확인하기 위해 총수 내에서 조정되기 때문에 클라이언트들(108)에 대해 보장될 수 있다. 성능의 전역적 풀에 대한 각각의 클라이언트의 효과가 측정되며 예측 가능하기 때문에, 관리자는 각각 그 자신의 성능 한계들을 가진, 개개의 노드들과 대조적으로, 성능의 풀로서 전체 클러스터의 성능을 고려할 수 있다. 이러한 특징은 클러스터가 그것의 성능을 정확하게 특성화하며 그것의 볼륨들의 모두 중에서 성능을 전달하기 위한 그것의 능력을 보장하도록 허용한다.
따라서, 성능 관리는 분포된 데이터 아키텍처에 기초하여 제공된다. 데이터가 클러스터에서의 모든 드라이브들에 걸쳐 고르게 분포되기 때문에, 각각의 개개의 볼륨의 로드는 또한 저장 시스템(100)에서 모든 단일 드라이브에 걸쳐 동일하다. 이러한 특징은 핫 스폿들을 제거할 수 있으며 성능 관리가 정확하며 공정하게 프로비전되고 개개의 볼륨들에 대한 전체 클러스터 성능을 보장하도록 허용한다.
로드 값 산출들
로드 값들은 클라이언트가 모든 클라이언트들 중에서 QoS를 보장하도록 돕기 위해 스로틀링되어야 하는지를 결정하기 위해 사용될 수 있다. 다양한 로드 값들이 하나 이상의 시스템 메트릭 및/또는 클라이언트 메트릭에 기초하여 산출될 수 있다. 일 예로서, 클라이언트의 데이터 판독 대기 시간에 대응하는 로드 값이 산출될 수 있다. 클라이언트와 부합하는 로드 값을 산출할 때, 클라이언트의 데이터가 저장 시스템상에서 어떻게 관리되는지가 중요해진다.
도 9는 일 예시적인 구현에 따른 저장 시스템의 일 부분을 도시한다. 도 9의 특정 예시적인 실시예에서, 저장 시스템은 노드들(912, 914, 916, 및 918)의 클러스터(910)를 포함하는 것으로 도시된다. 상이한 실시예들에 따르면, 각각의 노드는 예를 들면 하나 이상의 고체 상태 드라이브들(SSD들)과 같은 하나 이상의 저장 디바이스들을 포함할 수 있다. 도 9의 예시적인 실시예에서, 예시의 목적들을 위해, 3개의 상이한 클라이언트들(예로서, 클라이언트 A(902), 클라이언트 B(904), 및 클라이언트 C(906))이 각각 저장 클러스터(910)로부터/로 데이터의 판독/기록에 능동적으로 참여된다.
부가적으로, 도 9의 예시적인 실시예에 예시되는 바와 같이, 각각의 노드는 하나 이상의 서비스들(예로서, 서비스들(A 내지 H))과 연관될 수 있으며, 여기에서 각각의 서비스는 특정한 세트의 기능들 및/또는 태스크들을 핸들링하도록 구성되거나 또는 설계될 수 있다. 예를 들면, 도 9의 예시적인 실시예에 예시된 바와 같이: 서비스들(A 및 B)은 노드 1(912)과 연관될 수 있고(및/또는 그에 의해 핸들링될 수 있고); 서비스들(C 및 D)은 노드 2(914)와 연관될 수 있고(및/또는 그에 의해 핸들링될 수 있고); 서비스 E는 노드 3(916)과 연관될 수 있고(및/또는 그에 의해 핸들링될 수 있고); 서비스들(F, G, H)은 노드 4(918)과 연관될 수 있다(및/또는 그에 의해 핸들링될 수 있다). 적어도 일 실시예에서, 서비스들 중 하나 이상은 슬라이스 서버를 구현하도록 구성되거나 또는 설계될 수 있다. 슬라이스 서버는 또한 슬라이스 서비스 기능을 제공하는 것으로서 설명될 수 있다.
부가적으로, 상이한 실시예들에 따르면, 주어진 서비스는 적어도 하나의 1차 역할과 연관될 수 있으며 또한 하나 이상의 2차 역할들과 연관될 수 있다. 예를 들면, 도 9의 예시적인 실시예에서, 서비스 A는 적어도 다음의 기능을 포함하도록 구성되거나 또는 설계된다고 가정된다: (1) 서비스 A의 1차 역할은 클라이언트 A에 대한 1차 슬라이스 서비스로서 기능하며, (2) 서비스 A의 2차 역할은 클라이언트 A에 관한 데이터/메타데이터 복제 태스크들(예로서, 슬라이스 서버 복제 태스크들)을 핸들링하고, 이것은 이 예에서 서비스 C에 대한 클라이언트 A의 기록 요청들(및/또는 클라이언트 Z에 대한 다른 슬라이스-관련 메타데이터)을 복제하는 것을 수반한다. 따라서, 예를 들면, 일 실시예에서, 클라이언트 A로부터 개시된 기록 요청들은 서비스 A(902a)에서 수신될 수 있으며, 이에 응답하여, 서비스 A는 다음의 동작들 중 하나 이상(또는 그 조합들)을 수행하고 및/또는 개시할 수 있다.
ㆍ 예를 들면, 서비스 A의 슬라이스 서버에서 관련된 메타데이터를 생성하는 것 및 저장하는 것을 포함할 수 있는, 서비스 A의 슬라이스 서버에서의 기록 요청을 프로세싱하는 것;
ㆍ (요구된다면) 데이터가(기록 요청의) 블록 저장(예로서, 서비스 A에 의해 관리된)의 제 1 위치에 저장되게 하는 것;
ㆍ 기록 요청(및/또는 연관된 데이터/메타데이터)을 복제를 위해 서비스 C에 포워딩하는 것(902b).
적어도 일 실시예에서, 서비스 C가 클라이언트 A 기록 요청의 사본을 수신할 때, 그것은 서비스 C의 슬라이스 서버에서 기록 요청을 프로세싱하며, (요구된다면) 데이터(기록 요청의)가 복제 또는 이중화 목적들을 위해 블록 저장(예로서, 서비스 C에 의해 관리된)의 제 2 위치에 저장되게 함으로써 응답할 수 있다. 적어도 일 실시예에서, 블록 저장의 제 1 및 제 2 위치들은 각각 상이한 물리적 노드들에 존재할 수 있다. 유사하게 서비스 A의 슬라이스 서버 및 서비스 C의 슬라이스 서버는 각각 상이한 물리적 노드들에 구현될 수 있다.
따라서, 도 9의 예시적인 실시예에서, 클라이언트 A 기록 요청의 프로세싱은 2개 별개의 블록 저장 기록 동작들을 수반할 수 있다 - 하나는 서비스 A(1차 서비스)에 의해 개시되며 또 다른 것은 서비스 C(이중화 서비스)에 의해 개시된다. 다른 한편으로, 클라이언트 A 판독 요청의 프로세싱은 서비스 A가 서비스 C를 필수적으로 수반하지 않고 판독 요청을 핸들링할 수 있기 때문에 단지 서비스 A(예로서, 서비스 A가 서비스 C를 수반하지 않기 때문에 정상 상태들 하에서)에 의해 핸들링될 수 있다.
예시의 목적들을 위해, 도 9의 예시적인 실시예에서, 서비스 E는 적어도 다음의 기능을 포함하도록 구성되거나 또는 설계된다고 또한 가정된다: (1) 서비스 E의 1차 역할은 클라이언트 B에 대한 1차 슬라이스 서비스로서 기능하며, (2) 서비스 E의 2차 역할은, 이 예에서 서비스 D에 대한 클라이언트 B의 기록 요청들(및/또는 클라이언트 B에 대한 다른 슬라이스-관련 메타데이터)을 복제하는 것을 수반하는, 클라이언트 B에 관한 데이터 및/또는 메타데이터 복제 태스크들(예로서, 슬라이스 서버 복제 태스크들)을 핸들링한다. 따라서, 예를 들면, 일 실시예에서, 클라이언트 B로부터 개시된 기록 요청들은 서비스 E(904a)에서 수신될 수 있으며, 이에 응답하여, 서비스 E는 다음의 동작들 중 하나 이상(또는 그것의 조합들)을 수행 및/또는 개시할 수 있다.
ㆍ 예를 들면, 서비스 E의 슬라이스 서버에서 관련된 메타데이터를 생성하는 것 및 저장하는 것을 포함할 수 있는, 서비스 E의 슬라이스 서버에서 기록 요청을 프로세싱하는 것;
ㆍ (요구된다면) 데이터(기록 요청의) 블록 저장(예로서, 서비스 E에 의해 관리된)의 제 1 위치에 저장되게 하는 것;
ㆍ 기록 요청(및/또는 연관된 데이터/메타데이터)을 복제를 위해 서비스 D에 포워딩하는 것(904b).
적어도 일 실시예에서, 서비스 D가 클라이언트 B 기록 요청의 사본을 수신할 때, 그것은 서비스 D의 슬라이스 서버에서 기록 요청을 프로세싱하며, (요구된다면) 데이터(기록 요청의)가 복제 또는 이중화 목적들을 위해 블록 저장(예로서, 서비스 D에 의해 관리된)의 제 2 위치에 저장되게 함으로써 응답할 수 있다. 적어도 일 실시예에서, 블록 저장의 제 1 및 제 2 위치들은 각각 상이한 물리적 노드들에 존재할 수 있다. 유사하게, 서비스 E의 슬라이스 서버 및 서비스 D의 슬라이스 서버 각각은 상이한 물리적 노드들에 구현될 수 있다.
상이한 실시예들에 따르면, 다수의 복제(예로서, 데이터/메타데이터가 저장 시스템/클러스터 내에서의 둘 이상의 다른 위치들에서 복제되는)를 구현하는 것이 또한 가능하다. 예를 들면, 도 9의 예시적인 실시예에 예시된 바와 같이, 서비스 E는 적어도 다음의 기능을 포함하도록 구성되거나 또는 설계된다: (1) 서비스 E의 1차 역할은 클라이언트 C에 대한 1차 슬라이스 서비스로서 기능하고, (2) 서비스 E의 2차 역할은 이 예에서, 서비스 C에 대한 클라이언트 C의 기록 요청들(및/또는 클라이언트 C에 대한 다른 슬라이스-관련 메타데이터)을 복제하는 것을 수반하는, 클라이언트 C에 관한 데이터 및/또는 메타데이터 복제 태스크들(예로서, 슬라이스 서비스 복제 태스크들)을 핸들링하며; (3) 서비스 E의 2차 역할은 이 예에서 서비스 G에 대한 클라이언트 C의 기록 요청들(및/또는 클라이언트 C에 대한 다른 슬라이스-관련 메타데이터)을 복제하는 것을 수반하는, 클라이언트 C에 관한 데이터 및/또는 메타데이터 복제 태스크들(예로서, 슬라이스 서비스 복제 태스크들)을 핸들링한다. 따라서, 예를 들면, 일 실시예에서, 클라이언트 C로부터 개시된 기록 요청들은 서비스 E(906a)에서 수신될 수 있으며, 이에 응답하여, 서비스 E는 다음의 동작들 중 하나 이상(또는 그것의 조합들)을 수행 및/또는 개시할 수 있다:
ㆍ 예를 들면, 서비스 E의 슬라이스 서버에서 관련된 메타데이터를 생성하는 것 및 저장하는 것을 포함할 수 있는, 서비스 E의 슬라이스 서버에서 기록 요청을 프로세싱하는 것;
ㆍ (요구된다면) 데이터(기록 요청의)가 블록 저장(예로서, 서비스 E에 의해 관리된)의 제 1 위치에 저장되게 하는 것;
ㆍ 기록 요청(및/또는 연관된 데이터/메타데이터)을 복제를 위해 서비스 C에 포워딩하는 것(906b);
ㆍ 기록 요청(및/또는 연관된 데이터/메타데이터)을 복제를 위해 서비스 G에 포워딩하는 것(906c).
적어도 일 실시예에서, 서비스 C가 클라이언트 C 기록 요청의 사본을 수신할 때, 그것은 서비스 C의 슬라이스 서버에서 기록 요청을 프로세싱하며, (요구된다면) 데이터(기록 요청의)가 복제 또는 이중화 목적들을 위해 블록 저장(예로서, 서비스 C에 의해 관리된)의 제 2 위치에 저장되게 함으로써 응답할 수 있다. 유사하게, 적어도 일 실시예에서, 서비스 G가 클라이언트 C 기록 요청의 사본을 수신할 때, 그것은 서비스 G의 슬라이스 서버에서 기록 요청을 프로세싱하며, (요구된다면) 데이터(기록 요청의)가 복제 또는 이중화 목적들을 위해 블록 저장(예로서, 서비스 G에 의해 관리된)의 제 3 위치에 저장되게 함으로써 응답할 수 있다.
로드 값들 및 서비스 품질( QoS ) 분석
상이한 실시예들에 따르면, 저장 시스템의 QoS 기능은 시스템 메트릭들 및/또는 클라이언트 메트릭들로부터 결정된 다양한 로드 값들의 입력으로서 사용할 수 있다. 예를 들면, 일 실시예에서, 저장 시스템은 하나 이상의 시스템 리소스들이 로딩되고, 스트레싱되고 및/또는 오버로딩될 수 있는 정도를 결정하도록 돕기 위해 사용되거나 또는 판독 및/또는 기록 동작들에 대해 영향을 받는 시스템 리소스들을 측정, 추적, 및/또는 분석하도록 구성되거나 또는 설계될 수 있다.
적어도 일 실시예에서, 상이한 유형들의 메트릭들이 하나 이상의 시스템 리소스들(예로서, 노드들, 구성요소들, 서비스들 등)이 로딩되고, 스트레싱되고 및/또는 오버로딩되는 정도를 표현하기 위해 사용될 수 있는 로드 값들을 산출하기 위해 사용될 수 있다. 예를 들면, 적어도 일 실시예에서, 하나 이상의 상이한 유형들의 로드 값들이 어떤 다양한 유형들로 시스템 리소스들이 로딩되고, 스트레싱되고, 및/또는 오버로딩되는 상대적인 정도들을 표현하거나 또는 수량화하기 위해 자동으로 및/또는 동적으로 산출될 수 있다. 다양한 유형들의 로드 값들의 예들은, 이에 제한되지 않지만, 다음 중 하나 이상(또는 그것의 조합들)을 포함할 수 있다.
ㆍ 예를 들면, 시스템에서 구동하는 식별된 서비스에 관한 시스템 리소스 로드 또는 스트레스의 상대적인 정도 또는 양을 표현할 수 있는 로드(서비스). 상이한 실시예들에 따르면, 로드(서비스) 값은 식별된 서비스와 연관된 판독 및/또는 기록 동작들에 관한 판독 대기 시간 및/또는 기록 대기 시간의 측정된 양(들)에 적어도 부분적으로 기초하여 자동으로 및/또는 동적으로 산출될 수 있다(예로서, 실시간으로). 서비스가 다수의 클라이언트들로부터의 판독/기록 동작들을 핸들링하기 위해 할당되는 적어도 일 실시예에서, 로드(서비스) 값은 서비스가 할당되는 다수의 클라이언트들과 연관된 판독/기록 동작들에 기인한 판독 대기 시간들 및/또는 기록 대기 시간들을 반영할 수 있다.
ㆍ 예를 들면, 판독 IOPS에 관한 시스템 리소스 로드 또는 스트레스의 상대적인 정도 또는 양을 표현할 수 있는 로드(판독). 상이한 실시예들에 따르면, 로드(판독) 값은 판독 IOPS에 관한 시스템 대기 시간의 측정된 양(들)에 적어도 부분적으로 기초하여 자동으로 및/또는 동적으로 산출될 수 있다(예로서, 실시간으로). 상이한 실시예들에 따르면, 로드(판독) 메트릭은 다음 중 하나 이상(또는 그것의 조합)과 연관되는 판독 IOPS에 관한 시스템 리소스 로드 또는 스트레스의 상대적인 정도 또는 양을 표현하도록 구성될 수 있다: 식별된 서비스, 식별된 서비스들의 그룹, 식별된 클라이언트, 식별된 연결(예로서, 클라이언트 연결), 식별된 볼륨(또는 그것의 부분), 볼륨들의 식별된 그룹, 식별된 노드, 노드들의 식별된 그룹, 및/또는 다른 구체적으로 식별된 시스템 리소스들.
ㆍ 예를 들면, 기록 IOPS에 관한 시스템 리소스 로드 또는 스트레스의 상대적인 정도 또는 양을 표현할 수 있는 로드(기록). 상이한 실시예들에 따르면, 로드(기록) 값은 기록 IOPS에 관한 시스템 대기 시간의 측정된 양(들)에 적어도 부분적으로 기초하여 자동으로 및/또는 동적으로 산출될 수 있다(예로서, 실시간으로). 상이한 실시예들에 따르면, 로드(기록) 메트릭은 다음 중 하나 이상(또는 그것의 조합들)과 연관되는 기록 IOPS에 관한 시스템 리소스 로드 또는 스트레스의 상대적인 정도 또는 양을 표현하도록 구성될 수 있다: 식별된 서비스, 식별된 서비스들의 그룹, 식별된 클라이언트, 식별된 연결(예로서, 클라이언트 연결), 식별된 볼륨(또는 그것의 부분), 볼륨들의 식별된 그룹, 식별된 노드, 노드들의 식별된 그룹, 및/또는 다른 구체적으로 식별된 시스템 리소스들.
ㆍ 예를 들면, 사용되는 기록 버퍼 캐시 용량의 상대적인 양을 표현할 수 있는 로드(기록_버퍼). 상이한 실시예들에 따르면, 로드(기록_버퍼) 값은 기록 버퍼 캐시의 채움의 퍼센티지에 적어도 부분적으로 기초하여 자동으로 및/또는 동적으로 산출될 수 있다(예로서, 실시간으로).
ㆍ 예를 들면, 식별된 클라이언트에 대한 판독, 기록, 및 복제 동작들을 핸드링하기 위해 할당되는 서비스(들)(예로서, 1차 서비스 및 2차 서비스(들))와 연관된 IO 활동들에 관한 시스템 리소스 로드 또는 스트레스의 상대적인 정도 또는 양을 표현할 수 있는 로드(클라이언트). 상이한 실시예들에 따르면, 로드(클라이언트) 값은 식별된 클라이언트에 대한 판독, 기록, 및 복제 동작들을 핸들링하기 위해 할당되는 서비스(들)에 관한 판독 대기 시간 및/또는 기록 대기 시간의 측정된 양(들)에 적어도 부분적으로 기초하여 자동으로 및/또는 동적으로 산출될 수 있다(예로서, 실시간으로).
ㆍ 예를 들면, 식별된 클라이언트에 대한 판독 동작들을 핸들링하기 위해 ㅎ할당되는 서비스(들)와 연관된 IO 활동들에 관한 시스템 리소스 로드 또는 스트레스의 상대적인 정도 또는 양을 표현할 수 있는 로드(클라이언트-판독). 상이한 실시예들에 따르면, 로드(클라이언트-판독) 값은 식별된 클라이언트에 대한 IO 동작들을 핸들링하기 위해 할당되는 서비스(들)에 관한 판독 대기 시간의 측정된 양(들)에 적어도 부분적으로 기초하여 자동으로 및/또는 동적으로 산출될 수 있다(예로서, 실시간으로).
ㆍ 예를 들면, 식별된 클라이언트에 대한 기록 동작들을 핸들링하기 위해 할당되는 서비스(들)와 연관된 IO 활동들에 관한 시스템 리소스 로드 또는 스트레스의 상대적인 정도 또는 양을 표현할 수 있는 로드(클라이언트-기록). 상이한 실시예들에 따르면, 로드(클라이언트-기록) 값은 식별된 클라이언트에 대한 IO 동작들을 핸들링하기 위해 할당되는 서비스(들)에 관한 기록 대기 시간의 측정된 양(들)에 적어도 부분적으로 기초하여 자동으로 및/또는 동적으로 산출될 수 있다(예로서, 실시간으로).
ㆍ 예를 들면, 식별된 리소스(예로서, 캐시 메모리, 디스크 저장 공간, 클러스터 저장 공간 등)에 관한 시스템 로드 또는 스트레스의 상대적인 정도 또는 양을 표현할 수 있는 로드(리소스). 상이한 실시예들에 따르면, 로드(리소스) 값은 다음 중 하나 이상(또는 그것의 조합들)에 관한 리소스 이용 가능성/사용 특성들 및/또는 성능 특성들에 적어도 부분적으로 기초하여 자동으로 및/또는 동적으로 산출될 수 있다(예로서, 실시간으로): 클러스터 레벨 메트릭들 및/또는 드라이브 레벨 메트릭들, 판독 대기 시간, 기록 대기 시간, 초당 입력/출력 동작들(IOPS), 판독 IOPS, 기록 IOPS, I/O 크기, 기록 캐시 용량, 중복 제거-능력, 압축률, 총 대역폭, 판독 대역폭, 기록 대역폭, 판독/기록 비, 작업 로드 유형, 데이터 콘텐트, 데이터 유형 등. 예를 들면, 저장 시스템의 선택된 부분에 관한 시스템 로드 또는 스트레스의 상대적인 정도 또는 양을 표현할 수 있는 로드(시스템).
ㆍ 예를 들면, 식별된 서비스에 대한 디스크 공간 이용(DSU)의 상대적인 양을 표현할 수 있는 로드(DSU-서비스).
ㆍ 예를 들면, 식별된 저장 클러스터에 대한 디스크 공간 이용(DSU)의 상대적인 양을 표현할 수 있는 로드(DSU-클러스터).
ㆍ 예를 들면, 식별된 저장 클러스터(예로서, 도 9의 저장 클러스터(910))에 관한 시스템 로드 또는 스트레스의 상대적인 정도 또는 양을 표현할 수 있는 로드(클러스터).
상기 도시된 바와 같이, 클라이언트 로드 값은 클라이언트의 판독 대기 시간 및 기록 대기 시간 메트릭들 양쪽 모두에 기초하여 산출될 수 있다. 또한, 별개의 클라이언트 로드 값들이 판독 대기 시간 및 기록 대기 시간 메트릭들에 기초하여 산출될 수 있다. 적어도 일 실시예에서, QoS 관리에 관한 하나 이상의 양상들이 판독-관련 IOPS 및 기록-관련 IOPS(예로서, 주어진 클라이언트, 서비스, 및/또는 서비스들의 그룹에 대해) 사이에서 모니터링하며 구별함으로써 개시되고 및/또는 가능하게 될 수 있다. 예를 들면, 일 실시예에서, 주어진 서비스(예로서, 서비스 A)에 대한 판독-관련 동작들을 위한 QoS 구현을 가능하게 하기 위해, 서비스 A와 연관된 볼륨들의 판독 대기 시간이 모니터링되고 및/또는 측정될 수 있다. 일 실시예에서, 주어진 볼륨의 판독 대기 시간은 시스템이 식별된 서비스(예로서, 슬라이스 서비스) 및 데이터가 판독되는 대응하는 블록 서비스 사이에서 행해진 데이터 판독 동작(들)을 내부적으로 서비스하고 완료하기 위해 걸리는 시간의 양에 기초하여 산출되거나 또는 결정될 수 있다.
주어진 서비스(예로서, 서비스 A)에 대한 기록-관련 동작들을 위한 QoS 구현을 개시하고 및/또는 가능하게 하기 위해, 서비스 A와 연관된 볼륨들의 기록 대기 시간이 모니터링되고 및/또는 측정될 수 있다. 일 실시예에서, 주어진 볼륨의 기록 대기 시간은 시스템이 식별된 서비스(예로서, 슬라이스 서비스) 및 데이터가 기록되는 대응하는 블록 서비스 사이에서 행해진 데이터 기록 동작(들)을 내부적으로 서비스하고 완료하는데 걸리는 시간의 양에 기초하여 산출되거나 또는 결정될 수 있다.
적어도 일 실시예에서, 주어진 클라이언트(예로서, 클라이언트 A(902))에 대한 기록-관련 동작들을 위한 QoS 구현을 가능하게 하기 위해, 클라이언트 A와 연관된 서비스들(예로서, 서비스 A, 서비스 C)의 기록 대기 시간이 모니터링되고 및/또는 측정될 수 있다. 예를 들면, 일 실시예에서, 주어진 클라이언트에 대한 기록 대기 시간은 시스템이 예를 들면 (i) 1차 슬라이스 서비스(예로서, 서비스 A)에 의해 핸들링된 데이터 기록 동작(들), 및 (ii) 2차(예로서, 복제) 서비스(들)(예로서, 서비스 C)의 각각에 의해 핸들링된 데이터 기록 동작(들)을 포함할 수 있는, 연관된 데이터 기록 동작(들)을 내부적으로 서비스하고 완료하는데 걸리는 시간의 양에 기초하여 산출되거나 또는 결정될 수 있다.
적어도 몇몇 실시예들에서, 이용 가능한 기록 버퍼 캐시 용량(하나 이상의 식별된 노드들에 대한)의 정도 또는 양(예로서, 퍼센티지)은 또한 기록 대기 시간 측정들/산출들을 수행할 때 사용되거나 또는 고려될 수 있다. 예를 들면, 적어도 몇몇 기록-관련 동작들에 대해, 저장 시스템은 예를 들면, 고속-기록 메모리(예로서, 배터리 지원 RAM, Marvell™ 카드 등과 연관된 것과 같은)를 사용하여 구현될 수 있는 하나 이상의 기록 캐시(들)(또는 기록 버퍼들)를 이용할 수 있다. 적어도 일 실시예에서, 저장 시스템은 기록 캐시(들)에 저장된 큐잉된 기록들의 크기 또는 양을 모니터링할 수 있으며 스로틀 클라이언트들을 주도적으로 관리하기 위해 이 정보를 사용한다.
예를 들면, 일 실시예에서, 주어진 기록 캐시에서의 데이터의 양과 연관된 로드 값이 미리 정의된 임계 한계들에 도달하거나 또는 이를 초과함에 따라, 저장 시스템은 예를 들면, 데이터 플러싱 프로세스(예로서, 슬라이스 서비스 기록 캐시로부터 블록 저장소로)가 인입하는 클라이언트 기록들을 알 수 없음이 검출되거나 또는 결정될 때의 상태들 동안 배압(back pressure)을 인가함으로써와 같이, QoS 표준들을 유지하도록 돕기 위해 적절한 절차들을 자동으로 및/또는 동적으로 식별하고 및/또는 구현한다. 몇몇 실시예들에서, 시스템은 미리 정의된 임계 한계들을 충족시키거나 또는 이를 초과하는 기록 캐시들을 갖는 것으로서 식별되는 노드들 및/또는 볼륨들의 서브세트에만 배압을 적용할 수 있다.
상이한 실시예들에 따르면, 저장 시스템에 의해 자동으로 및/또는 동적으로 개시되고 및/또는 구현될 수 있는 절차의 다양한 예들이 이에 제한되지는 않지만, 다음 중 하나 이상(또는 그것의 조합들)을 포함할 수 있다.
ㆍ 하나 이상의 선택된 서비스들, 노드들, 볼륨들, 클라이언트들, 및/또는 연결들에 대한 판독 및 기록 IOPS를 일시적으로 스로틀링하는 것;
ㆍ 하나 이상의 선택된 서비스들, 노드들, 볼륨들, 클라이언트들, 및/또는 연결들에 대한 판독-관련 IOPS를 일시적으로 스로틀링하는 것;
ㆍ 하나 이상의 선택된 서비스들, 노드들, 볼륨들, 클라이언트들, 및/또는 연결들에 대한 기록-관련 IOPS를 일시적으로 스로틀링하는 것;
ㆍ 하나 이상의 선택된 서비스들, 노드들, 볼륨들, 클라이언트들, 및/또는 연결들 사이에서의 내부 메시지 요청들을 연기하는 것;
ㆍ 및/또는 시스템 리소스 로드 또는 스트레스의 상대적인 정도 또는 양을 감소시키거나 또는 완화하도록 도울 수 있는 다른 유형들의 동작들/활동들.
예시적인 로드 산출들
상이한 실시예들에 따르면, 다양한 유형들의 기술들 및/또는 컴퓨터-구현된 알고리즘들이 원하는 로드 값들을 동적으로 산출하기 위해 사용될 수 있다. 예시로서, 로드 산출 기술들의 여러 개의 상이한 예시적인 실시예들이 도 9에 예시된 예시적인 시스템 실시예를 참조하여 이하에 설명된다.
예시적인 로드 산출 기술 A
일 실시예에서, 도 9에 예시된 예시적인 시스템 실시예를 참조하면, 각각의 로드(클라이언트) 값들은 다음에 따라 자동으로 및/또는 동적으로 산출될 수 있다:
로드(클라이언트 A) = a*로드(서비스 A) + b*로드(서비스 C);
로드(클라이언트 B) = c*로드(서비스 E) + d*로드(서비스 D);
로드(클라이언트 C) = e*로드(서비스 E) + f*로드(서비스 C) + g*로드(서비스 G);
여기에서, a, b, c는 각각이 0 및 1 사이에서 각각의 값을 갖는 가중 변수들(예로서, 가중 계수들)이며; a+b=1, c+d=1, 및 e+g+f=1.
적어도 일 실시예에서, 계수들의 값은 예를 들면, 판독/기록 작업 로드들의 측정된 퍼센티지들에 기초하여 자동으로 및/또는 동적으로 조정될 수 있다(예로서, 실시간으로).
일 실시예에서, 도 9에 예시된 예시적인 시스템 실시예를 참조하면, 식별된 서비스(서비스_ID)에 대한 로드(서비스) 값(들)은 다음에 따라 자동으로 및/또는 동적으로 산출될 수 있다:
로드(서비스_ID) = h*로드(판독@서비스_ID)
+ j*로드(기록@서비스_ID)
+ k*로드(기록_버퍼@서비스_ID)
+ m*로드(DSU-서비스_ID),
여기에서:
ㆍ j, j, k, m은 각각이 0 및 1 사이에서 각각의 값을 갖는 가중 변수들(예로서, 가중 계수들)이며, 여기에서 h+j+k+m=1;
ㆍ 로드(판독@서비스_ID)는 서비스_ID에 의해 식별된 서비스에 의해 핸들링되는 판독 IOPS와 연관된 시스템 리소스 로드/스트레스의 상대적인 정도 또는 양을 표현하는 정규화된 값(예로서, 0-1 사이)을 표현한다;
ㆍ 로드(기록@서비스_ID)는 서비스_ID에 의해 식별된 서비스에 의해 핸들링되는 기록 IOPS와 연관된 시스템 리소스 로드/스트레스의 상대적인 정도 또는 양을 표현하는 정규화된 값(예로서, 0-1 사이)을 표현한다.
ㆍ 로드(기록_버퍼@서비스_ID)는 서비스_ID에 의해 식별된 서비스에 의한 사용을 위해 할당되는 노드의 기록 캐시 상에 큐잉되는 큐잉된 기록 요청들의 상대적인 크기 또는 양을 표현하는 정규화된 값(예로서, 0-1 사이)을 표현한다;
ㆍ 로드(DSU-서비스_ID)는 서비스_ID에 의해 식별된 서비스에 대한 디스크 공간 이용(DSU)의 상대적인 양을 표현하는 정규화된 값(예로서, 0-1 사이)을 표현한다.
서비스가 다수의 클라이언트들로부터의 판독/기록 동작들을 핸들링하기 위해 할당되는 적어도 일 실시예에서, 로드(판독) 값은 서비스가 할당되는 다수의 클라이언트들과 연관된 판독 동작들에 기인한 판독 대기 시간들을 반영할 수 있다. 유사하게, 서비스가 다수의 클라이언트들로부터의 판독/기록 동작들을 핸들링하기 위해 할당되지만, 로드(기록) 값은 서비스가 할당되는 다수의 클라이언트들과 연관된 기록 동작들에 기인한 기록 대기 시간들을 반영할 수 있다.
예시적인 로드 산출 기술 B
또 다른 실시예에서, 주어진 클라이언트에 대한 로드(클라이언트) 값은 예를 들면, 로드(클라이언트-판독) 및 로드(클라이언트-기록)을 포함할 수 있는 값들의 세트로부터 비교적 가장 높은 값을 식별 및 선택함으로써 자동으로 및/또는 동적으로 결정될 수 있다.
따라서, 예를 들면, 도 9에 예시된 예시적인 시스템 실시예를 참조하면, 로드(클라이언트 A) 값은 다음에 따라 자동으로 및/또는 동적으로 산출될 수 있다:
로드(클라이언트 A) = 최대_값{(로드(판독@서비스 A), 로드(기록@(서비스 A), 로드((기록@서비스 C)},
여기에서:
ㆍ 최대_값{x,y,z}는 세트{x,y,z}로부터 선택된 비교적 가장 높은 값을 리턴하는 함수를 표현한다;
ㆍ 로드(판독@서비스 A)는 서비스 A에 의해 핸들링되는 판독 IOPS와 연관된 시스템 리소스 로드/스트레스의 상대적인 정도 또는 양을 표현하는 정규화된 값(예로서, 0-1 사이)을 표현한다.
ㆍ 로드(기록@서비스 A)는 서비스 A에 의해 핸들링되는 기록 IOPS와 연관된 시스템 리소스 로드/스트레스의 상대적인 정도 또는 양을 표현하는 정규화된 값(예로서, 0-1 사이)을 표현한다;
ㆍ 로드(기록@서비스 C)는 서비스 C에 의해 핸들링되는 기록 IOPS와 연관된 시스템 리소스 로드/스트레스의 상대적인 정도 또는 양을 표현하는 정규화된 값(예로서, 0-1 사이)을 표현한다.
유사하게, 각각의 로드(클라이언트 B) 및 로드(클라이언트 C) 값들은 각각 다음에 따라 자동으로 및/또는 동적으로 산출될 수 있다:
로드(클라이언트 B) = 최대_값{(로드(판독@서비스 E),
로드(기록@(서비스 E),
로드(기록@서비스 D)}
로드(클라이언트 C) = 최대_값{(로드(판독@서비스 E),
로드(기록@(서비스 E),
로드(기록@서비스 C),
로드(기록@서비스 G)}.
로드 값 데이터 구조들
도 10 내지 도 12는 저장 시스템 내에서 판독, 기록, 및 복제 기능을 가능하게 하기 위해 사용될 수 있는 상이한 유형들의 데이터 및 데이터 구조들의 예시적인 실시예들을 예시한다. 적어도 일 실시예에서, 도 10 내지 도 12의 데이터 구조들 중 하나 이상의 별개의 인스턴스는 저장 클러스터(예로서, 910) 내에서 구동하는 각각의 개별적인 서비스와 연관될 수 있으며 그것의 각각의 서비스가 인스턴스화되는 동일한 물리적 노드에서 인스턴스화되고 업데이트될 수 있다. 상이한 실시예들에 따르면, 저장 시스템은 도 10 내지 도 12에 예시된 다양한 데이터 구조들을 주기적으로 및 동적으로 생성, 실장, 및 업데이트하도록 구성되거나 또는 설계될 수 있다.
도 10은 로드-서비스 데이터 구조(1000)의 특정 예시적인 실시예를 예시한다. 적어도 일 실시예에서, 로드-서비스 데이터 구조는 저장 시스템 내에서 구동하는 상이한 서비스들과 연관된 시스템 로드 특성들 및 상태들을 추적하기 위해 구성되거나 또는 설계될 수 있다. 적어도 일 실시예에서, 로드-서비스 데이터 구조(1000)는 저장 클러스터에서 구동하는 선택된 서비스(들)에 대한 현재의 또는 업데이트된 로드 상태들을 추적하기 위해 사용될 수 있다. 일 실시예에서, 로드-서비스 데이터 구조(1000)는 저장 클러스터에서 구동하는 각각의 활성 슬라이스 서비스에 대한 현재의 또는 업데이트된 로드 상태들을 추적하기 위해 사용될 수 있다.
로드-서비스 데이터 구조(1000)의 에시적인 실시예가 이제 도 9에 예시된 저장 시스템 구성을 참조하여 예로서 설명될 것이다. 도 10의 예시적인 실시예에 예시된 바 같이, 로드-서비스 데이터 구조(1000)는 저장 클러스터(예로서, 도 9의, 910) 내에서의 구체적으로 식별된 서비스들에 관한 복수의 레코드들(또는 엔트리들)(예로서, 1001, 1003, 1005)을 포함할 수 있다. 적어도 일 실시예에서, 각각의 레코드는 다음의 유형들의 정보 중 하나 이상(또는 그것의 조합들)을 포함할 수 있다:
ㆍ 저장 클러스터에서 구동하는 특정 서비스를 식별하는 서비스 식별자 정보(예로서, 서비스_ID(1002));
ㆍ 식별된 서비스와 연관된 시스템 로드 또는 스트레스의 실시간(또는 근 실시간) 정도 또는 양을 표현한 값(예로서, 로드(서비스) 값)을 포함할 수 있는 시스템 로드 정보(예로서, 로드(서비스)(1004)).
상이한 실시예들에 따르면, 주어진 서비스에 대한 로드(서비스) 값은 식별된 서비스와 연관된 판독 및/또는 기록 동작들에 관한 판독 대기 시간 및/또는 기록 대기 시간의 측정된 양(들)에 적어도 부분적으로 기초하여 저장 시스템에 의해 자동으로 및/또는 동적으로 산출될 수 있다(예로서, 실시간으로). 예를 들면, 일 실시예에서, 시스템은 로드-서비스 데이터 구조(1000)를 실장하고 및/또는 업데이트하기 위해 로드(서비스) 분석 절차(1300)(도 13a)를 이용할 수 있다.
도 11은 저장 시스템 내에서 구동하는 상이한 서비스들과 연관된 시스템 로드 특성들 및 상태들을 추적하기 위해 구성되거나 또는 설계될 수 있는 로드-서비스 데이터 구조(1100)의 대안의 예시적인 실시예를 예시한다. 도 11의 예시적인 실시예에 예시된 바와 같이, 로드-서비스 데이터 구조(1100)는 저장 클러스터 내에서의 구체적으로 식별된 서비스에 관한 복수의 레코드들(또는 엔티티들)(예로서, 1101, 1103, 1105)을 포함할 수 있다. 적어도 일 실시예에서, 각각의 레코드는 다음의 유형들의 정보 중 하나 이상(또는 그것의 조합들)을 포함할 수 있다:
ㆍ 저장 클러스터에서 구동하는 특정 서비스를 식별하는 서비스 식별자 정보(예로서, 서비스_ID(1102));
ㆍ 식별된 서비스와 연관된 시스템 로드 또는 스트레스의 실시간(또는 근 실시간) 정도 또는 양을 표현한 로드(판독) 값을 포함할 수 있는 로드(판독) 정보(1104);
ㆍ 식별된 서비스와 연관된 시스템 로드 또는 스트레스의 실시간(또는 근 실시간) 정도 또는 양을 표현한 로드(기록) 값을 포함할 수 있는 로드(기록) 정보(1104).
상이한 실시예들에 따르면, 로드(판독) 값들은 식별된 서비스와 연관되는 판독 I/O 대기 시간의 측정된 양(들)에 적어도 부분적으로 기초하여 자동으로 및/또는 동적으로 산출될 수 있다(예로서, 실시간으로). 상이한 실시예들에 따르면, 로드(기록) 값들은 식별된 서비스와 연관되는 기록 I/O 대기 시간 및/또는 기록 캐시 큐 깊이(들)의 측정된 양(들)에 적어도 부분적으로 기초하여 자동으로 및/또는 동적으로 산출될 수 있다(예로서, 실시간으로).
도 12는 클라이언트-서비스 데이터 구조(1200)의 특정한 예시적인 실시예를 예시한다. 적어도 일 실시예에서, 클라이언트-서비스 데이터 구조(1200)는 저장 클러스터와 상호 작용하는 각각의 클라이언트와 연관된 판독/기록 동작들을 핸들링하기 위해 할당되는 각각의 서비스들을 추적하기 위해 구성되거나 또는 설계될 수 있다. 예시적인 목적들을 위해, 도 12의 예시적인 클라이언트-서비스 데이터 구조 실시예가 이제 도 9에 예시된 저장 시스템 구성을 참조하여 예로서 설명될 것이다. 도 12의 예시적인 실시예에 예시된 바와 같이, 클라이언트-서비스 데이터 구조(1200)는 각각 저장 시스템의 구체적으로 식별된 클라이언트에 관한 복수의 레코드들(또는 엔트리들)(예로서, 1201, 1203, 1205)을 포함할 수 있다. 적어도 일 실시예에서, 각각의 레코드는 다음의 유형들의 정보 중 하나 이상(또는 그것의 조합들)을 포함할 수 있다.
ㆍ 특정 클라이언트(예로서, 클라이언트 A, 클라이언트 B, 클라이언트 C 등)를 식별하는 클라이언트 식별자 정보(예로서, 클라이언트_ID(1202)). 몇몇 실시예들에서, 저장 클러스터와 상호 작용하는 각각의 클라이언트는 주어진 클라이언트와 연관되는 통신들, 요청들(예로서, 판독/기록 요청들), 활동들, 및/또는 다른 정보를 식별 및 추적하기 위해 시스템에 의해 사용될 수 있는 각각 고유 연결 식별자(연결_ID)와 연관될 수 있다. 따라서, 예를 들면, 일 실시예에서, 주어진 클라이언트-서비스 데이터 레코드(예로서, 1201)의 클라이언트_ID 부분(1202)은 상기 클라이언트의 할당된 연결_ID 식별자를 사용하여 표현될 수 있다.
ㆍ 식별한 클라이언트로부터 비롯된 판독/기록 요청들의 서비스를 포함하여, 식별된 클라이언트와의 통신들을 핸들링하기 위해 할당된 1차 슬라이스 서비스를 식별하는 1차 슬라이스 서비스_ID 정보(1204).
ㆍ 예를 들면, 식별된 클라이언트와 연관되는 메타데이터(예로서, 슬라이스) 및/또는 데이터 복제 태스크들을 핸들링하기 위해 할당되는 이들 서비스들과 같이, 식별된 클라이언트와 연관된 하나 이상의 2차 서비스(들)를 식별하는 연관된 복제 서비스_ID(들) 정보(1206).
적어도 일 실시예에서, 클러스터에서의 각각의 노드는 그것의 산출된 로드 값들을 각각의 다른 노드에 보고한다. 이러한 방식으로, 각각의 노드(및/또는 서비스)는 각각의 다른 노드의(및/또는 서비스의) 로드 값들에 대해 통지받을 수 있다. 이러한 정보는 상기 클라이언트가 사용하는 클러스터에서 노드들 및/또는 서비스들의 로드 값을 결정하기 위해 사용될 수 있다(예로서, 클라이언트가 연결되는 슬라이스 서비스 상에서).
로드 값들은 공유된 노드/서비스 리소스 사용 정보를 사용하여 산출되거나 또는 결정될 수 있다. 몇몇 실시예들에서, 저장 시스템은 예를 들면, 판독들, 기록들, 대역폭, 압축 등 중 하나 이상(또는 그것의 조합들)과 같은 상이한 시스템 로드 값들로 인하거나 또는 그것에 의해 야기되는 오버로딩된 상태들 사이에서 구별하도록 구성되거나 또는 설계될 수 있다. 예를 들면, 적어도 일 실시예에서, 저장 시스템은 시스템(또는 그 부분)이 판독 오버로딩됨, 기록 오버로딩됨, 대역폭 오버로딩됨, 압축 오버로딩됨 등을 결정할 수 있다.
적어도 일 실시예에서, 산출된 로드 값들(예를 들면, 적어도 하나의 클라이언트 볼륨에 고유할 수 있는)은 클라이언트 메트릭들과 함께, 타겟 성능 관리기(402)(도 4의)에 의해, 각각의 개별적인 클라이언트에 대해 구현될 타겟 성능 값을 결정하기 위해 사용될 수 있다.
예시적인 절차들 및 흐름도들
도 13 내지 도 17은 여기에 개시된 저장 시스템 QoS 양상들 중 하나 이상에 관한 활동들을 가능하게 하기 위해 사용될 수 있는 상이한 절차들 및/또는 절차 흐름들의 다양한 예시적인 실시예들을 예시한다.
도 13a는 특정 실시예에 따른 로드(서비스) 분석 절차(1300)의 흐름도를 도시한다. 절차(1300)의 부가적인, 보다 적거나, 또는 상이한 동작들이 특정한 실시예에 의존하여 수행될 수 있다. 절차(1300)는 컴퓨팅 디바이스 상에 구현될 수 있다. 일 구현예에서, 절차(1300)는 컴퓨팅 디바이스에 의해 실행될 때, 컴퓨팅 디바이스가 절차(1300)의 동작들을 수행하게 하는 지시들을 포함하는 컴퓨터-판독 가능한 매체 상에 인코딩된다. 상이한 실시예들에 따르면, 로드(서비스) 분석 절차에 의해 제공된 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들의 적어도 일 부분이 저장 시스템의 하나 이상의 노드들 및/또는 볼륨들에 구현될 수 있다. 적어도 일 실시예에서, 로드(서비스) 분석 절차는 저장 클러스터에서 구동하는 하나 이상의 선택된 서비스들에 대한 로드 정보의 분석, 측정, 산출, 및 업데이팅에 관한 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들을 수행하고 및/또는 구현하도록 동작 가능할 수 있다. 특정 실시예들에 따르면, 로드(서비스) 분석 절차의 다수의 인스턴스들 또는 스레드들이 하나 이상의 프로세서들 및/또는 하드웨어 및/또는 하드웨어 및 소프트웨어의 다른 조합들의 사용을 통해 동시에 구현되고 및/또는 개시될 수 있다.
상이한 실시예들에 따르면, 로드(서비스) 분석 절차의 하나 이상의 상이한 스레드들 또는 인스턴스들은 하나 이상의 상이한 시간 간격들에서(예로서, 특정 시간 간격 동안, 규칙적인 주기적 간격들로, 불규칙적인 주기적 간격들로, 요구시 등) 자동으로 및/또는 동적으로 개시되고 및/또는 구현될 수 있다.
도 13a의 예시적인 실시예에 예시된 바와 같이, 1302에서, 적어도 하나의 상태 또는 이벤트가 로드(서비스) 분석 절차의 실행을 개시하기 위해 검출된다고 가정된다. 예를 들면, 일 실시예에서, 로드(서비스) 분석 절차의 주어진 인스턴스는 그에 의해 식별된 서비스에 대한 업데이트된 로드(서비스) 값을 분석 및 결정하기 위해 스케줄대로, 예로서 매 500ms, 1s, 10s, 20s 등마다 자동으로 구동하도록 구성되거나 또는 설계될 수 있다. 몇몇 실시예들에서, 주어진 서비스에 대한 로드(서비스) 분석 절차의 실행의 빈도는 예를 들면, 시스템 메트릭들, 클라이언트 메트릭들, QoS 관리 정책들에서의 변화들 등과 같은 다른 이벤트들 및/또는 상태들에 기초하여 자동으로 및/또는 동적으로 변할 수 있다.
1304에 도시된 바와 같이, 로드(서비스) 분석 절차는 식별된 서비스에 대한 시스템 및/또는 클라이언트 메트릭들의 분석을 개시할 수 있다. 적어도 일 실시예에서, 시스템 및/또는 클라이언트 메트릭들의 분석은 식별된 서비스와 연관된 판독 및/또는 기록 동작들에 대한 판독 대기 시간 및/또는 기록 대기 시간에 관한 실시간 정보를 측정, 획득, 및/또는 결정하는 것을 포함할 수 있다.
1306에 도시된 바와 같이, 로드(서비스) 분석 절차는 식별된 서비스에 대한 현재의 로드(서비스) 값을 결정할 수 있다. 상이한 실시예들에 따르면, 로드(서비스) 값은 예를 들면, 여기에 설명된 다양한 로드 산출 기술들 중 하나 이상을 사용하여 결정되거나 또는 산출될 수 있다.
1308에 도시된 바와 같이, 선택된 서비스에 대한 현재 산출된 로드(서비스) 값이 이전 산출된 로드(서비스) 값으로부터 변경되었는지 여부에 대한 선택적 결정이 이루어질 수 있다. 예를 들면, 일 실시예에서, 로드(서비스) 분석 절차는 예를 들면, 식별된 서비스에 대한 가장 최근의 이력 로드 값을 표현할 수 있는, 로컬 로드-서비스 표(예로서, 도 9의, 900)로부터 로드(서비스) 값(예로서, 도 9, 904)을 검색하거나 또는 액세스하기 위해 식별된 서비스의 서비스_ID를 사용할 수 있다. 적어도 일 실시예에서, 로드(서비스) 분석 절차는 선택된 서비스에 대한 현재 산출된 로드(서비스) 값이 변경되었는지 여부를 결정하기 위해 로드-서비스 표로부터 검색된 대응하는 로드(서비스) 값에 현재 산출된 로드(서비스) 값을 비교할 수 있다.
일 실시예에서, 선택된 서비스에 대한 현재 산출된 로드(서비스) 값이 로드 서비스 표에 저장된 로드(서비스) 값으로부터 변경되지 않았다고 결정된다면, 어떤 부가적인 동작들도 이때 요구되지 않을 수 있다. 대안적으로, 선택된 서비스에 대한 현재 산출된 로드(서비스) 값이 로드-서비스 표 산출된 로드(서비스) 값에 저장된 S로드(서비스) 값으로부터 변경되었다고 결정된다면, 선택된 서비스에 대한 현재 산출된 로드(서비스) 값은 로컬 로드-서비스 표에 저장될 수 있다(1310). 부가적으로, 선택된 서비스에 대한 로드(서비스) 값의 이러한 업데이트에 관한 정보 및/또는 통지는 저장 클러스터의 다른 노드들 중 하나 이상에 푸싱될 수 있다(1312). 적어도 일 실시예에서, 로드(서비스) 값 통지 업데이트를 수신할 때, 다른 노드(들)는 업데이트된 로드(서비스) 값 정보를 사용하여 그것들 각각의 로컬 로드-서비스 표들을 자동으로 및 동적으로 업데이트할 수 있다.
도 13b는 특정 실시예에 따른 로드(판독) 분석 절차(1330)의 흐름도를 도시한다. 절차(1330)의 부가적인, 보다 적거나, 또는 상이한 동작들이 특정한 실시예에 의존하여 수행될 수 있다. 절차(1330)는 컴퓨팅 디바이스 상에 구현될 수 있다. 일 구현예에서, 절차(1330)는 컴퓨팅 디바이스에 의해 실행될 때, 컴퓨팅 디바이스가 절차(1330)의 동작들을 수행하게 하는 지시들을 포함하는 컴퓨터-판독 가능한 매체 상에 인코딩된다. 상이한 실시예들에 따르면, 로드(판독) 분석 절차에 의해 제공된 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들의 적어도 일 부분이 저장 시스템의 하나 이상의 노드들 및/또는 볼륨들에 구현될 수 있다. 적어도 일 실시예에서, 로드(판독) 분석 절차는 저장 클러스터에서 구동하는 하나 이상의 선택된 서비스들과 연관된 판독-관련 트랜잭션들에 대한 로드 정보의 분석, 측정, 산출, 및 업데이팅에 관한 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들을 수행하고 및/또는 구현하도록 동작 가능할 수 있다.
도 13b의 예시적인 실시예에 예시된 바와 같이, 1332에서, 적어도 하나의 상태 또는 이벤트가 로드(판독) 분석 절차의 실행을 개시하기 위해 검출된다고 가정된다. 1334에서 도시된 바와 같이, 로드(판독) 분석 절차는 식별된 서비스에 대한 판독-관련 시스템 및/또는 클라이언트 메트릭들의 분석을 개시할 수 있다. 적어도 일 실시예에서, 시스템 및/또는 클라이언트 메트릭들의 분석은 식별된 서비스에 의해 핸들링된(또는 그와 연관된) 판독 동작들에 대한 판독 대기 시간에 관한 실시간 정보를 측정, 획득, 및/또는 결정하는 것을 포함할 수 있다.
1336에서 도시된 바와 같이, 로드(판독) 분석 절차는 식별된 서비스에 대한 현재 로드(판독) 값을 결정할 수 있다. 상이한 실시예들에 따르면, 로드(판독) 값은 예를 들면, 여기에 설명된 다양한 로드 산출 기술들 중 하나 이상을 사용하여 결정되거나 또는 산출될 수 있다.
1338에 도시된 바와 같이, 선택된 서비스에 대한 현재 산출된 로드(판독) 값이 이전 산출된 로드(판독) 값으로부터 변경되었는지 여부에 대한 선택적 결정이 이루어질 수 있다. 예를 들면, 일 실시예에서, 로드(판독) 분석 절차는 예를 들면, 식별된 서비스에 대한 가장 최근의 이력 로드(판독) 값을 표현할 수 있는, 로컬 로드서비스 표(예로서, 도 11, 1100)로부터 로드(판독) 값(예로서, 도 11, 1104)을 검색하거나 또는 액세스하기 위해 식별된 서비스의 서비스_ID를 사용할 수 있다. 적어도 일 실시예에서, 로드(판독) 분석 절차는 선택된 서비스에 대한 현재 산출된 로드(판독) 값이 변경되었는지 여부를 결정하기 위해 로드-서비스 표(1100)로부터 검색된 대응하는 로드(판독) 값에 현재 산출된 로드(판독) 값을 비교할 수 있다.
일 실시예에서, 선택된 서비스에 대한 현재 산출된 로드(판독) 값이 로드-서비스 표에 저장된 로드(판독) 값으로부터 변경되지 않았다고 결정된다면, 어떤 부가적인 동작들도 이때 요구되지 않을 수 있다. 대안적으로, 선택된 서비스에 대한 현재 산출된 로드(판독) 값이 로드-서비스 표 산출된 로드(판독) 값에 저장된 S로드(판독) 값으로부터 변경되었다고 결정된다면, 선택된 서비스에 대한 현재 산출된 로드(판독) 값은 로컬 로드-서비스 표(1100)에 저장될 수 있다(1340). 부가적으로, 선택된 서비스에 대한 로드(판독) 값의 이러한 업데이트에 관한 정보 및/또는 통지는 저장 클러스터의 다른 노드들 중 하나 이상에 푸싱될 수 있다(1342). 적어도 일 실시예에서, 로드(판독) 값 통지 업데이트를 수신할 때, 다른 노드(들)가 업데이트된 로드(판독) 값 정보를 사용하여 그것들 각각의 로컬 로드-서비스 표들을 자동으로 및 동적으로 업데이트할 수 있다.
도 13c는 특정 실시예에 따른 로드(기록) 분석 절차(1350)의 흐름도를 도시한다. 절차(1350)의 부가적인, 보다 적거나, 또는 상이한 동작들이 특정한 실시예에 의존하여 수행될 수 있다. 절차(1350)는 컴퓨팅 디바이스 상에 구현될 수 있다. 일 구현예에서, 절차(1350)는 컴퓨팅 디바이스에 의해 실행될 때, 컴퓨팅 디바이스가 절차(1350)의 동작들을 수행하게 하는 지시들을 포함하는 컴퓨터-판독 가능한 매체 상에 인코딩된다. 상이한 실시예들에 따르면, 로드(기록) 분석 절차에 의해 제공된 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들의 적어도 일 부분이 저장 시스템의 하나 이상의 노드들 및/또는 볼륨들에 구현될 수 있다. 적어도 일 실시예에서, 로드(기록) 분석 절차는 저장 클러스터에서 구동하는 하나 이상의 선택된 서비스들과 연관된 기록-관련 트랜잭션들에 대한 로드 정보의 분석, 측정, 산출, 및 업데이팅에 관한 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들을 수행하고 및/또는 구현하도록 동작 가능할 수 있다.
도 13c의 예시적인 실시예에 예시되는 바와 같이, 1352에서, 적어도 하나의 상태 또는 이벤트가 로드(기록) 분석 절차의 실행을 개시하기 위해 검출된다고 가정된다. 1354에 도시되는 바와 같이, 로드(기록) 분석 절차는 식별된 서비스에 대한 기록-관련 시스템 및/또는 클라이언트 메트릭들의 분석을 개시할 수 있다. 적어도 일 실시예에서, 시스템 및/또는 클라이언트 메트릭들의 분석은 식별된 서비스에 의해 핸들링된(또는 그와 연관된) 기록 동작들에 대한 기록 대기 시간에 관한 실시간 정보를 측정, 획득, 및/또는 결정하는 것을 포함할 수 있다.
1356에 도시된 바와 같이, 로드(기록) 분석 절차는 식별된 서비스에 대한 현재 로드(기록) 값을 결정할 수 있다. 상이한 실시예들에 따르면, 로드(기록) 값은 예를 들면, 여기에 설명된 다양한 로드 산출 기술들 중 하나 이상을 사용하여, 결정되거나 또는 산출될 수 있다.
1358에 도시된 바와 같이, 선택된 서비스에 대한 현재 산출된 로드(기록) 값이 이전에 산출된 로드(기록) 값으로부터 변경되었는지 여부에 대한 선택적 결정이 이루어질 수 있다. 예를 들면, 일 실시예에서, 로드(기록) 분석 절차는 예를 들면, 식별된 서비스에 대한 가장 최근의 이력 로드(기록) 값을 표현할 수 있는 로컬 로드-서비스 표(예로서, 도 11, 1100)로부터 로드(기록) 값(예로서, 도 11, 1106)을 검색하거나 또는 액세스하기 위해 식별된 서비스의 서비스_ID를 사용할 수 있다. 적어도 일 실시예에서, 로드(기록) 분석 절차는 선택된 서비스에 대한 현재 산출된 로드(기록) 값이 변경되었는지 여부를 결정하기 위해 로드-서비스 표(1100)로부터 검색된 대응하는 로드(기록) 값에 현재 산출된 로드(기록) 값을 비교할 수 있다.
일 실시예에서, 선택된 서비스에 대한 현재 산출된 로드(기록) 값이 로드-서비스 표에 저장된 로드(기록) 값으로부터 변경되지 않았다고 결정된다면, 어떤 부가적인 동작들도 이때 요구되지 않을 수 있다. 대안적으로, 선택된 서비스에 대한 현재 산출된 로드(기록) 값이 로드-서비스 표 산출된 로드(기록) 값에 저장된 S로드(기록) 값으로부터 변경되었다고 결정된다면, 선택된 서비스에 대한 현재 산출된 로드(기록) 값은 로컬 로드-서비스 표(1000)에 저장될 수 있다(1360). 부가적으로, 선택된 서비스에 대한 로드(기록) 값의 이러한 업데이트에 관한 정보 및/또는 통지는 저장 클러스터의 다른 노드들 중 하나 이상에 푸싱될 수 있다(1362). 적어도 일 실시예에서, 로드(기록) 값 통지 업데이트를 수신할 때, 다른 노드(들)는 업데이트된 로드(기록) 값 정보를 사용하여 그것들 각각의 로컬 로드-서비스 표들을 자동으로 및 동적으로 업데이트할 수 있다.
도 14는 특정 실시예에 따른 로드(클라이언트) 분석 절차(1400)의 흐름도를 도시한다. 절차(1400)의 부가적인, 보다 적거나, 또는 상이한 동작들이 특정한 실시예에 의존하여 수행될 수 있다. 절차(1400)는 컴퓨팅 디바이스 상에 구현될 수 있다. 일 구현예에서, 절차(1400)는 컴퓨팅 디바이스에 의해 실행될 때, 컴퓨팅 디바이스가 절차(1400)의 동작들을 수행하게 하는 지시들을 포함하는 컴퓨터-판독 가능한 매체 상에 인코딩된다. 상이한 실시예들에 따르면, 로드(클라이언트) 분석 절차에 의해 제공된 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들의 적어도 일 부분이 저장 시스템의 하나 이상의 노드들 및/또는 볼륨들에 구현될 수 있다. 예를 들면, 일 실시예에서, 로드(클라이언트) 분석 절차는 식별된 클라이언트와의 판독/기록 통신들을 핸들링하기 위해 할당되는 1차 슬라이스 서비스에 의해 개시되고 및/또는 수행될 수 있다. 적어도 일 실시예에서, 로드(클라이언트) 분석 절차는 저장 시스템의 하나 이상의 선택된 클라이언트들에 대한 로드 정보의 분석, 측정, 산출, 및 업데이팅에 관한 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들을 수행하고 및/또는 구현하도록 동작 가능할 수 있다.
특정 실시예들에 따르면, 로드(클라이언트) 분석 절차의 다수의 인스턴스들 또는 스레드들이 하나 이상의 프로세서들 및/또는 하드웨어의 다른 조합들 및/또는 하드웨어 및 소프트웨어의 사용을 통해 동시에 구현되고 및/또는 개시될 수 있다. 일 실시예에서, 로드(클라이언트) 분석 절차의 별개의 인스턴스 또는 스레드는 저장 시스템의 각각의 개별적인 클라이언트에 대해 개시될 수 있다. 도 14의 특정한 예시적인 실시예에서, 로드(클라이언트) 분석 절차는 선택된 클라이언트(예로서, 도 9, 클라이언트 A)에 대한 현재 또는 업데이트된 로드(클라이언트)를 동적으로 결정하기 위해 인스턴스화된다고 결정된다.
상이한 실시예들에 따르면, 로드(클라이언트) 분석 절차의 하나 이상의 상이한 스레드들 또는 인스턴스들은 하나 이상의 상이한 시간 간격들(예로서, 특정 시간 간격 동안, 규칙적인 주기적 간격들로, 불규칙적인 주기적 간격들로, 요구시 등)로 자동으로 및/또는 동적으로 개시되고 및/또는 구현될 수 있다. 예를 들면, 일 실시예에서, 로드(클라이언트) 분석 절차의 주어진 인스턴스는 그에 의해 식별된 클라이언트에 대한 업데이트된 로드(클라이언트) 값을 분석 및 결정하기 위해 약 10 내지 20초마다(예로서, 주어진 클라이언트에 대해) 자동으로 구동하도록 구성되거나 또는 설계될 수 있다. 몇몇 실시예들에서, 주어진 클라이언트에 대한 로드(클라이언트) 분석 절차의 실행의 빈도는 예를 들면, 시스템 메트릭들, 클라이언트 메트릭들, QoS 관리 정책들에서의 변화들 등과 같은 다른 이벤트들 및/또는 상태들에 기초하여 자동으로 및/또는 동적으로 변할 수 있다.
도 14의 예시적인 실시예에서, 1402에서, 적어도 하나의 상태 또는 이벤트가 로드(클라이언트) 분석 절차의 실행을 개시하기 위해 검출된다고 가정된다. 1404에 도시된 바와 같이, 로드(클라이언트) 분석 절차는 시스템 및/또는 클라이언트 메트릭들의 분석을 개시할 수 있다. 적어도 일 실시예에서, 시스템 및/또는 클라이언트 메트릭들의 분석은 식별된 클라이언트와 연관된 판독/기록 동작들에 대한 판독 대기 시간 및/또는 기록 대기 시간에 관한 실시간 정보를 측정, 획득, 및/또는 결정하는 것을 포함할 수 있다.
도 14의 특정한 예시적인 실시예에서, 식별된 클라이언트(예로서, 클라이언트 A)에 대한 현재 로드(클라이언트)를 결정하는 프로세스는 선택된 클라이언트와 연관되며, 로드(클라이언트) 값의 계산에 대한 요인이 되는 적절한 서비스(들)를 식별하는 것(1406)을 포함할 수 있다. 이 예에서, 로드(클라이언트) 값은 식별된 클라이언트와 연관된 것으로서 식별되는 선택된 서비스들(예로서, 1차 슬라이스 서비스, 복제 서비스들)에 대한 실시간 시스템 로드를 반영하는 클라이언트-특정 값이라고 가정된다. 예를 들면, 일 실시예에서, 로드(클라이언트) 분석 절차는 식별된 클라이언트(예로서,로드(클라이언트) 산출의 목적들을 위해)와 연관되는 특정 서비스들을 식별하기 위해 로컬 클라이언트-서비스 데이터 구조(예로서, 도 11, 1100)로부터 정보를 액세스하기 위해 식별된 클라이언트의 클라이언트_ID를 사용할 수 있다. 예로서, 도 11의 서비스-클라이언트 데이터 구조(1100)의 특정 예시적인 실시예를 참조하면, 식별된 클라이언트가 클라이언트 A에 대응한다고 가정되면, 클라이언트 A와 연관된 특정 서비스들은 서비스 A(예로서, 클라이언트 A의 1차 슬라이스 서비스로서 할당되는), 및 서비스 C(예로서, 클라이언트 A 데이터/메타데이터의 복제를 핸들링하기 위해 클라이언트 A의 2차 서비스로서 할당되는)로서 식별될 수 있다.
1408에 도시된 바와 같이, 식별된 클라이언트에 대한 현재 로드(클라이언트) 값이 동적으로 결정되거나 또는 산출될 수 있다. 상이한 실시예들에 따르면, 로드(클라이언트) 값은 예를 들면, 여기에 설명된 다양한 로드(클라이언트) 산출 기술들 중 하나 이상을 사용하여, 동적으로 결정되거나 또는 산출될 수 있다. 예를 들면, 일 실시예에서, 클라이언트 A에 대한 로드(클라이언트) 값이 다음에 따라 동적으로 산출될 수 있다:
로드(클라이언트 A) = 최대_값{(로드(판독@서비스 A),
로드(기록@(서비스 A),
로드(기록@서비스 C)}.
적어도 일 실시예에서, 산출된 로드(클라이언트) 값은 식별된 클라이언트에 대한 판독, 기록, 및 복제 동작들을 핸들링하기 위해 할당되는 서비스(들)(예로서, 1차 서비스 및 2차 서비스(들))와 연관된 IO 활동들에 관한 시스템 리소스 로드 또는 스트레스의 상대적인 정도 또는 양을 나타낼 수 있다. 적어도 일 실시예에서, 저장 시스템은 판독 및 기록 관련 트랜잭션들 사이에서 구별하기 위해, 및 식별된 클라이언트와 연관된 로드(판독) 및 로드(기록) 값들을 개별적으로 분석, 결정, 및/또는 추적하기 위해 구성되거나 또는 설계될 수 있다. 이러한 기술들의 예시적인 실시예들이 예를 들면, 도 16, 도 17, 도 20, 및 도 21에 예시되며 이하에 보다 상세히 설명된다.
저장 시스템에서 QoS 구현에 대한 하나의 관심사는 비교적 "덜" 중요한 클라이언트들이 저장 클러스터에서 증가된 대기 시간들을 야기하거나 또는 그것에 기여할 수 있어서, 시스템의 공정하고, 비례적인 스루풋을 얻기 위해 비교적 더 중요한(예로서, 비교적 더 높은 최소 QoS 성능 보증들을 가진) 이들 클라이언트들에 대해 더 어렵게 한다.
도 9를 참조하여 예로서, 저장 클러스터(910)는 다음의 QoS 성능 보장들을 구현하도록 구성된다고 가정될 수 있다:
ㆍ 15k 최소 IOPS에서 설정된 클라이언트 A(902) 볼륨
ㆍ 1k 최소 IOPS에서 설정된 40개의 다른 클라이언트 볼륨들(클라이언트 B 및 클라이언트 C를 포함한)
ㆍ 각각의 클라이언트에 대한 IO들은 80% 판독 IOPS 및 20% 기록 IOPS이다.
ㆍ 각각의 IO 트랜잭션의 크기는 4kb이다.
이러한 예시적인 실시예에서, 예시적인 목적들을 위해 저장 시스템이 특정 최소 보장된 15k IOPS를 클라이언트 A에 제공할 수 없다고 가정될 수 있다. 또한, 이 예에서, 임의의 증가된 판독 대기 시간이 많은 판독 작업 로드들을 이끄는 다른 40개의 클라이언트 볼륨들에 의해 야기된다고 가정된다. 적어도 일 실시예에서, 저장 시스템은 클라이언트 A 작업 로드가 많은 판독 IOPS이기 때문에, 기록-기반 로드 값들은 그것의 최소 IOPS 보장들을 달성하기 위해 클라이언트 A의 불능에 기여할 수 있는 판독 대기 시간에서의 검출된 증가에서 중요한 역할을 하지 않을 수 있음을 동적으로 결정하도록 구성되거나 또는 설계될 수 있다.
타겟 성능 값 산출들
상기 주지된 바와 같이, 타겟 성능 관리기(402)는 시스템 로드 값들, 클라이언트 로드 값들, 및 클라이언트 QoS 파라미터들에 기초하여 타겟 성능 값을 산출한다. 타겟 성능 값은 그 후 클라이언트가 어떻게 저장 시스템의 리소스들을 액세스할 수 있는지를 제어하기 위해 사용된다.
도 15는 특정 실시예에 따른 QoS 클라이언트 정책 관리 절차(1500)의 흐름도를 도시한다. 절차(1500)의 부가적인, 보다 적거나, 또는 상이한 동작들이 특정한 실시예에 의존하여 수행될 수 있다. 절차(1500)는 컴퓨팅 디바이스 상에 구현될 수 있다. 일 구현예에서, 절차(1500)는 컴퓨팅 디바이스에 의해 실행될 때, 컴퓨팅 디바이스가 절차(1500)의 동작들을 수행하게 하는 지시들을 포함하는 컴퓨터-판독 가능한 매체 상에 인코딩된다. 상이한 실시예들에 따르면, QoS 클라이언트 정책 관리 절차에 의해 제공된 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들의 적어도 일 부분이 저장 시스템의 하나 이상의 노드들 및/또는 볼륨들에 구현될 수 있다. 예시의 목적들을 위해, QoS 클라이언트 정책 관리 절차(1500)는 선택된 클라이언트(예로서, 도 9, 클라이언트 A)에 대한 QoS 정책 관리를 수행하기 위해 인스턴스화된다고 가정된다.
적어도 일 실시예에서, QoS 클라이언트 정책 관리 절차는 저장 시스템의 하나 이상의 선택된 클라이언트들에 대한 로드 정보의 분석, 측정, 산출, 및 업데이팅에 관한 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들을 수행하고 및/또는 구현하도록 동작 가능할 수 있다. 특정 실시예들에 따르면, QoS 클라이언트 정책 관리 절차의 다수의 인스턴스들 또는 스레드들은 하나 이상의 프로세서들 및/또는 하드웨어 및/또는 하드웨어와 소프트웨어의 다른 조합들의 사용을 통해 동시에 구현되고 및/또는 개시될 수 있다. 일 실시예에서, QoS 클라이언트 정책 관리 절차의 별개의 인스턴스 또는 스레드는 저장 시스템의 각각의 개별적인 클라이언트에 대한 QoS 클라이언트 정책 관리를 수행하거나 또는 가능하게 하기 위해 개시될 수 있다.
상이한 실시예들에 따르면, QoS 클라이언트 정책 관리 절차의 하나 이상의 상이한 스레드들 또는 인스턴스들이 하나 이상의 상이한 시간 간격들(예로서, 특정 시간 간격 동안, 규칙적인 주기적 간격들로, 불규칙적인 주기적 간격들로, 요구시 등)로 자동으로 및/또는 동적으로 개시되고 및/또는 구현될 수 있다. 예를 들면, 일 실시예에서, QoS 클라이언트 정책 관리 절차의 주어진 인스턴스는 그에 의해 식별된 클라이언트에 대한 업데이트된 로드(클라이언트) 값을 분석 및 결정하기 위해 약 250 내지 1000 밀리초들마다(예로서, 주어진 클라이언트에 대해 500 ms마다) 자동으로 구동하도록 구성되거나 또는 설계될 수 있다. 몇몇 실시예들에서, 주어진 클라이언트에 대한 QoS 클라이언트 정책 관리 절차의 실행의 빈도는 예를 들면, 시스템 메트릭들, 클라이언트 메트릭들, QoS 관리 정책들에서의 변화들 등과 같은, 다른 이벤트들 및/또는 상태들에 기초하여 자동으로 및/또는 동적으로 변할 수 있다.
도 15의 예시적인 실시예에서, 1502에서, 적어도 하나의 상태 또는 이벤트가 QoS 클라이언트 정책 관리 절차의 실행을 개시하기 위해 검출된다고 가정된다. 1504에 도시된 바와 같이, QoS 클라이언트 정책 관리 절차는 시스템 및/또는 클라이언트 메트릭들의 분석을 개시할 수 있다. 적어도 일 실시예에서, 시스템 및/또는 클라이언트 메트릭들의 분석은 식별된 클라이언트에 대한 판독, 기록, 및 복제 동작들을 핸들링하기 위해 할당되는 서비스(들)(예로서, 1차 서비스 및 2차 서비스(들))와 연관된 IO 활동들에 대한 판독 대기 시간들 및/또는 기록 대기 시간들에 관한 실시간 정보를 측정, 획득, 및/또는 결정하는 것을 포함할 수 있다.
1506에 도시된 바와 같이, QoS 클라이언트 정책 관리 절차는 식별된 클라이언트에 대한 현재 로드(클라이언트) 값을 결정할 수 있다. 상이한 실시예들에 따르면, 로드(클라이언트) 값은, 예를 들면, 여기에 설명된 다양한 로드(클라이언트) 산출 기술들 중 하나 이상을 사용하여, 결정되거나 또는 산출될 수 있다. 도 15의 특정한 예시적인 실시예에서, 로드(클라이언트) 값은 식별된 클라이언트에 대한 판독, 기록, 및 복제 동작들을 핸들링하기 위해 할당되는 서비스(들)(예로서, 1차 서비스 및 2차 서비스(들))과 연관된 IO 활동들에 대한 판독 대기 시간 및 기록 대기 시간 메트릭들 양쪽 모두에 인자로 포함하는 클라이언트-특정 로드 값이라고 가정된다.
1508에 도시된 바와 같이, QoS 클라이언트 정책 관리 절차는 현재의 로드(클라이언트) 값을 분석할 수 있으며, 이에 응답하여 식별된 클라이언트에 대한 적절한 QoS 관리 정책을 선택 및 구현할 수 있다. 예를 들면, 도 15의 예시적인 실시예에 예시된 바와 같이:
ㆍ 로드(클라이언트) < 임계 값(A1)이라고 결정된다면, QoS 클라이언트 정책 관리 절차는 QoS 관리 정책 세트(A1)를 구현할 수 있다(1510);
ㆍ 임계 값(A1)≥로드(클라이언트)≥임계 값(A2)라고 결정된다면, QoS 클라이언트 정책 관리 절차는 QoS 관리 정책 세트(B1)를 구현할 수 있다(1512);
ㆍ 로드(클라이언트) > 임계 값(A2)이라고 결정된다면, QoS 클라이언트 정책 관리 절차는 QoS 관리 정책 세트(C1)를 구현할 수 있다(1514).
적어도 일 실시예에서, 저장 시스템은 (1) 판독 및 기록 관련 트랜잭션들 사이에서 구별하도록, 및 주어진 클라이언트와 연관된 로드(클라이언트-판독) 및 로드(클라이언트-기록) 값들을 개별적으로 분석, 결정, 및/또는 추적하도록; 및 (2) 클라이언트-관련 판독 IOPS 및 클라이언트-관련 기록 IOPS에 대한 상이한 각각의 QoS 관리 정책 세트들을 독립적으로 평가 및 구현하도록 구성되거나 또는 설계될 수 있다. 이러한 기술들의 예시적인 실시예들이 예를 들면, 도 16, 도 17, 도 20, 및 도 21에 예시되며, 이하에 보다 상세히 설명된다.
도 18은 저장 시스템이 어떻게 도 15를 참조하여 설명된 것과 같이 QoS 클라이언트 정책 관리 절차의 양상들을 구현할 수 있는지를 예시한 그래픽 표현을 도시한다. 도 18의 예시적인 실시예에 예시된 바와 같이, 클라이언트 IOPS(1810)(예로서, 판독 및 기록 IOPS 둘 모두)에 대응하는 타겟 성능 값들을 표현한 Y-축 및 선택된 로드 값(로드 A(1801))을 표현한 X-축을 포함하는 X-Y 그래프 부분(1800)이 도시된다. 예시의 목적들을 위해, 로드 A는 선택된 클라이언트(예로서, 클라이언트 A)에 대한 로드(클라이언트) 메트릭에 대응한다고 가정된다. 그러나, 대안적인 실시예들에서(도시되지 않음), 로드 A는 예를 들면, 다음 중 하나 이상(또는 그것의 조합들)과 같이 여기에 설명된 다양한 상이한 메트릭들 중 하나에 대응할 수 있다는 것이 이해될 것이다: 로드(서비스); 로드(판독); 로드(기록); 로드(기록_버퍼); 로드(클라이언트-판독); 로드(클라이언트-기록); 등.
도 18의 예시적인 실시예에 예시된 바와 같이, 그래프 부분(1800)은 식별된 클라이언트에 대한 최소 IOPS 파라미터(1805); 최대 IOPS QoS 파라미터(1805); 및 최대 버스트 IOPS QoS 파라미터(1807)를 표현한 기준 라인들(1803, 1805, 1807)을 포함한다. 부가적으로, 그래프 부분(1800)은 이러한 예시적인 실시예에서, 식별된 클라이언트에 대해 시행 중인 현재의 QoS 관리 정책 세트를 결정 및 선택하기 위해 사용될 수 있는 임계 값들을 표현하는 기준 라인들(1811, 1813, 1815)을 포함한다. 예를 들어, 도 18에 예시된 바와 같이:
ㆍ 로드 A < 임계 값(A1)일 때의 시간들 동안, QoS 관리 정책 세트(A1)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 18의 특정한 예시적인 실시예에서, 영역(1802)은 클라이언트가 QoS 관리 정책 세트(A1)에 따라 동작할 수 있는 IOPS의 가능한 값들의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(A1)는 클라이언트가 IOPS 크레딧들을 누적하도록 허용되며, 클라이언트의 IOPS가 클라이언트의 최대 IOPS QoS 파라미터(1805)와 동일하거나 또는 그보다 작을 수 있으며; 누적된 크레딧들에 기초하여 클라이언트의 최대 버스트 IOPS QoS 파라미터 위에서 동작하도록 허용될 수 있지만; 클라이언트의 최대 버스트 IOPS QoS 파라미터(1807)를 초과하지 않는다고 특정할 수 있다.
ㆍ 임계 값(A1) ≥ 로드 A ≥ 임계 값(A2)일 때 시간들 동안, QoS 관리 정책 세트(B1)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 18의 특정한 예시적인 실시예에서, 영역(1804)은 클라이언트가 수행할 수 있는 IOPS의 범위의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(B1)는 클라이언트의 IOPS가 클라이언트의 최대 IOPS QoS 파라미터 및 최소 IOPS QoS 파라미터 사이에서의 범위 내에 있는 타겟 성능 IOPS 값으로 스로틀링된다고 특정할 수 있다. 클라이언트는 물론 저장 시스템의 클라이언트의 사용에 의존하여 최소 IOPS보다 적은 IOPS를 사용할 수 있다. 부가적으로, QoS 관리 정책 세트(B1)는 또한 (i) 클라이언트의 IOPS가 클라이언트의 최대 IOPS QoS 파라미터를 초과하지 않으며; (ii) 클라이언트의 IOPS의 스로틀링이 클라이언트의 로드(클라이언트) 값이 임계 값(A1)(1811)에서 임계 값(A2)(1813)으로 증가함에 따라 증가한다고 특정할 수 있다.
ㆍ 로드 A > 임계 값(A2)일 때 시간들 동안, QoS 관리 정책 세트(C1)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 18의 특정한 예시적인 실시예에서, 영역(1806)은 클라이언트가 QoS 관리 정책 세트(C1)에 따라 동작할 수 있는 IOPS의 가능한 값들의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(B1)는 클라이언트의 최소 IOPS QoS 파라미터 및 0 사이에서의 범위 내에 있는 타겟 성능 IOPS 값으로 스로틀링된다고 특정할 수 있다. 부가적으로, QoS 관리 정책 세트(C1)는 또한 클라이언트의 IOPS의 스로틀링이, 클라이언트의 로드(클라이언트) 값이 임계 값(A2)(1813)에서 임계 값(A3)(1815)으로 증가함에 따라 증가한다고 특정할 수 있다.
도 19a는 클라이언트 IOPS를 스로틀링하기 위한 상이한 QoS 관리 정책 세트들이 어떻게 로드(클라이언트) 상태들을 변경하는 것에 응답하여 자동으로 및/또는 동적으로 구현될 수 있는지에 대한 예시적이 실시예를 예시한 그래픽 표현을 도시한다. 도 19a의 예시적인 실시예에 예시된 바와 같이, 클라이언트 IOPS(1910)(예로서, 판독 및 기록 IOPS 둘 모두)에 대응하는 타겟 성능 값들을 표현한 Y-축 및 선택된 클라이언트(예로서, 클라이언트 A)에 대한 클라이언트 로드(클라이언트) 메트릭을 표현한 X-축을 포함하는 X-Y 그래프 부분(1900)이 도시된다. 도 19a의 예시적인 실시예에 예시된 바와 같이, 그래프 부분(1900)은 식별된 클라이언트에 대한 ㅊ최소 IOPS QoS 파라미터(1905); 최대 IOPS QoS 파라미터(1905); 및 최대 버스트 IOPS QoS 파라미터(1907)를 표현하는 기준 라인들(1903, 1905, 1907)을 포함한다. 부가적으로, 그래프 부분(1900)은 이러한 예시적인 실시예에서, 식별된 클라이언트에 대해 실행될 현재 QoS 관리 정책 세트를 결정 및 선택하기 위해 사용될 수 있는 임계 값들을 표현하는 기준 라인들(1911, 1913, 1915)을 포함한다. 예를 들면, 도 19a에 예시된 바와 같이:
ㆍ 로드(클라이언트) < 임계 값(A1)일 때 시간들 동안, QoS 관리 정책 세트(A1)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 19a의 특정한 예시적인 실시예에서, 영역(1902)은 클라이언트가 QoS 관리 정책 세트(A1)에 따라 동작할 수 있는 IOPS의 가능한 값들의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(A1)는 클라이언트가 IOPS 크레딧들을 누적하도록 허용되며, 클라이언트의 IOPS가: 클라이언트의 최대 IOPS QoS 파라미터(1905)와 동일하거나 작을 수 있고; 누적된 크레딧들에 기초하여 클라이언트의 최대 버스트 IOPS QoS 파라미터 위에서 동작하도록 허용될 수 있지만; 클라이언트의 최대 버스트 IOPS QoS 파라미터(1907)를 초과하지 않는다고 특정할 수 있다. 일 실시예에서, 임계 값(A1)은 0.2 내지 0.4(예로서, 임계 값(A1) = 0.33)의 범위 내에 수치 값이 있는 것으로 정의될 수 있다;
ㆍ 임계 값(A1)≥로드(클라이언트)≥임계 값(A2)일 때 시간들 동안, QoS 관리 정책 세트(B1)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 19a의 특정한 예시적인 실시예에서, 영역(1904)은 클라이언트가 QoS 관리 정책 세트(B1)에 따라 동작할 수 있는 IOPS의 가능한 값들의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(B1)는 클라이언트의 최대 IOPS 파라미터 및 최소 IOPS 파라미터 사이에서의 범위 내에 있는 타겟 성능 IOPS로 스로틀링된다는 것을 특정할 수 있다. 부가적으로, QoS 관리 정책 세트(B1)는 또한, 임의의 주어진 시간에(임계 값(A1)≥로드(클라이언트)≥임계 값(A2)인 동안), 클라이언트의 IOPS는 클라이언트의 현재(예로서, 실시간) 로드(클라이언트) 값에 기초하여 동적으로 결정되는 타겟 성능 IOPS 값으로 스로틀링된다. 예를 들면, 도 19a의 예시적인 실시예에서, Qos 관리 정책 세트(B1)가 시행 중인 동안, 클라이언트의 IOPS는 경계 곡선(1904a)(예로서, 클라이언트의 현재 로드(클라이언트) 값에 대해 클라이언트의 허용 가능한 IOPS의 상한을 정의하는)에 의해 정의된 대응하는 IOPS를 초과하지 않는 타겟 성능 IOPS로 스로틀링된다. 일 실시예에서, 임계 값(A2)은 0.5 내지 0.8(예로서, 임계 값(A2)=0.66) 내에 있는 수치 값인 것으로 정의될 수 있다.
ㆍ 로드(클라이언트) > 임계 값(A2)일 때 시간들 동안, QoS 관리 정책 세트(C1)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 19a의 특정한 예시적인 실시예에서, 영역(1906)은 클라이언트가 QoS 관리 정책 세트(C1)에 따라 동작할 수 있는 IOPS의 가능한 값들의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(C1)는 클라이언트의 IOPS가 클라이언트의 최소 IOPS 파라미터 및 0 사이에서의 범위 내에 있는 타겟 성능 IOPS 값으로 스로틀링된다고 특정할 수 있다. 부가적으로, QoS 관리 정책 세트(C1)는 또한 임의의 주어진 시간에(로드(클라이언트) > 임계 값(A2)), 클라이언트의 IOPS가 클라이언트의 로드(클라이언트) 값에 기초하여 동적으로 결정되는 타겟 성능 IOPS 값으로 스로틀링된다고 특정할 수 있다. 예를 들면, 도 19a의 예시적인 실시예에서, QoS 관리 정책 세트(C1)가 시행 중인 동안, 클라이언트의 IOPS는 경계 곡선(1906a)(예로서, 클라이언트의 현재 로드(클라이언트) 값에 대한 클라이언트의 허용 가능한 IOPS의 상한을 정의하는)에 의해 정의된 대응하는 IOPS 값을 초과하지 않는 IOPS 값으로 스로틀링된다. 일 실시예에서, 임계 값(A3)은 0.75 내지 1.0(예로서, 임계 값(A3)=0.85)의 범위 내에서의 수치 값인 것으로 정의될 수 있다.
상이한 실시예들에 따르면, QoS 관리 정책 세트들(및 그와 연관된 IOPS 경계 곡선들)은 클라이언트 특정적일 수 있으며, 그러므로 하나 이상의 클라이언트들에 대해 상이할 수 있다. 예를 들면, 일 실시예에서, 클라이언트 A에 대해 구현될 수 있는 QoS 관리 정책 세트들은 클라이언트들(B 및 C)에 대해 구현된 QoS 관리 정책 세트들과 상이할 수 있다. 부가적으로, 적어도 일 실시예에서, IOPS 스로틀링은 클라이언트 기반으로 다수의 상이한 클라이언트들에 걸쳐 독립적으로 구현되며 관리될 수 있다.
예를 들면, 도 19b는 QoS 관리 및 IOPS 스로틀링이 어떻게 저장 시스템의 다수의 상이한 클라이언트들(예로서, 클라이언트 A, 클라이언트 B, 클라이언트 C)에 대해 동시에, 독립적으로, 및 동적으로 구현될 수 있는지를 예시한 예시적인 실시예를 도시한다. 도 19b의 예시적인 실시예에 예시된 바와 같이, 클라이언트 IOPS(1910)(예로서, 판독 및 기록 IOPS 양쪽 모두)에 대응하는 타겟 성능 값들을 표현한 Y-축 및 클라이언트 로드(클라이언트) 값들을 표현한 X-축을 포함하는 X-Y 그래프 부분(1950)이 도시된다.
도 19b의 예시적인 실시예에 예시된 바와 같이, 그래프 부분(1950)은 각각의 클라이언트의 최소 IOPS QoS 파라미터(1903), 최대 IOPS QoS 파라미터(1905); 및 최대 버스트 IOPS QoS 파라미터(1909)의 표시들을 포함한다. 부가적으로, 그래프 부분(1950)은 이 예시적인 실시예에서, 각각의 클라이언트에 대한 QoS 관리 및/또는 IOPS 스로틀링을 결정하기 위해 사용될 특정한 QoS 관리 정책 세트(들)를 결정하기 위해 사용될 수 있는 임계 값들을 표현하는 기준 라인들(1911, 1913, 1915)을 포함한다.
도 19b의 특정한 예시적인 실시예에서, 예시의 용이함을 위해, 클라이언트들(A, B, C)에 대한 최소 IOPS, 최대 IOPS, 및 최대 버스트 IOPS 값들이 동일하다고 가정된다. 그러나, 다른 실시예들에서, 클라이언트들(A, B, C)에 대한 각각의 최소 IOPS, 최대 IOPS, 및 최대 버스트 IOPS 값은 각각의 클라이언트에 대해 상이할 수 있다. 유사하게, 예시의 용이함을 위해, 동일한 로드 임계 값들(예로서, A1, A2, A3)이 클라이언트들(A, B, C)에 적용된다는 것이 가정된다. 그러나, 다른 실시예들에서, 각각의 클라이언트는 상기 클라이언트에 대해 사용될 특정한 QoS 관리 정책 세트(들)를 결정하기 위해 사용될 수 있는 로드 임계 값들의 각각의 세트를 그것과 연관시킬 수 있다.
도 19b의 예시적인 실시예에 예시된 바와 같이, 예시의 목적을 위해, 클라이언트 A의 현재 로드 값("로드(클라이언트 A)")(1962)은 로드(클라이언트 A) = 0.23인 것으로 산출되며, 이것은 로드(클라이언트) 임계 값(A1)보다 작은 것으로 가정된다고 가정된다. 따라서, 이러한 예시적인 실시예에서, 저장 시스템은 QoS 관리 정책 세트(A1)가 클라이언트 A에 대한 타겟 IOPS 값을 결정하기 위해 사용된다고 결정할 수 있다.
따라서, 예를 들면, 도 19b의 예시적인 실시예에서, 클라이언트 A에 대한 타겟 IOPS 값은 로드(클라이언트 A) 값이 Qos 관리 정책 세트(A1)("QMPA1") 곡선(1902a)과 교차하는 좌표(1962a)에 의해 결정될 수 있다. 이러한 예에 예시된 바와 같이, 좌표(1962a)와 연관된 값들은 (0.23, 1.0, QMPA1)이며, 여기에서:
ㆍ 0.23은 로드(클라이언트 A) 값을 표현한다;
ㆍ QMPA1은 QoS 관리 정책 세트(A1)를 표현한다;
ㆍ 1.0은 그 값이 QoS 관리 정책 세트(A) 및 로드(클라이언트) 값의 함수에 기초하여 결정될 수 있는 스케일링된(및/또는 정규화된) 타겟 IOPS 비를 표현한다. 예를 들면, 도 19b의 특정한 예시적인 실시예에서, 타겟 IOPS 비 값은 로드(클라이언트 A) 값이 QoS 관리 정책 세트(A1)("QMPA1") 곡선(1902a)과 교차하는 교차 포인트(예로서, 1962a)에 의해 결정될 수 있다.
적어도 일 실시예에서, 클라이언트 A에 대한 타겟 IOPS 값(예로서, T1)은 예로서, 다음과 같은, 클라이언트 A의 최소 및 최대 IOPS 값들에 대한 함수로서 표현될 수 있다:
TargetIOPS(클라이언트A) = T1
T2 = (1.0*(최대 IOPS (클라이언트A) + 최소 IOPS (클라이언트A) )) + 최소 IOPS (클라이언트A)
따라서, 예를 들면, 저장 시스템은 클라이언트 A의 IOPS가 T1을 초과하지 않는 IOPS 값으로 스로틀링되게(적어도 일시적으로) 함으로써 클라이언트 A의 IO들에 대한 QoS 관리를 구현할 수 있다. 도 19b의 예시적인 실시예에서, 클라이언트 A에 대한 타겟 IOPS 값(T1)은 클라이언트 A의 MAX IOPS 값과 동일한 것으로 결정될 수 있다. 부가적으로, QoS 관리 정책 세트(A1)는 또한 클라이언트 A의 IOPS가 그것의 각각의 최대 IOPS 값 위에서 버스트할 수 있게 하기 위한 클라이언트 A의 크레딧들의 사용을 허용할 수 있다.
또한, 도 19b의 예시적인 실시예에 예시된 바와 같이, 예시의 목적들을 위해, 클라이언트 B의 현재 로드 값("로드(클라이언트 B)")(1972)은 로드(클라이언트) 임계 값(A1)보다 크지만, 로드(클라이언트) 임계 값(A2)보다 작은 것으로 가정되는, 로드(클라이언트 B) = 0.39이도록 산출된다고 가정된다. 따라서, 이러한 예시적인 실시예에서, 저장 시스템은 QoS 관리 정책 세트(B1)가 클라이언트 B에 대한 타겟 IOPS 값을 결정하기 위해 사용된다고 결정할 수 있다.
따라서, 예를 들면, 도 19b의 예시적인 실시예에서, 클라이언트 B에 대한 타겟 IOPS 값은 로드(클라이언트 B) 값이 QoS 관리 정책 세트(B1)("QMPB1") 곡선(1904a)과 교차하는 좌표(1972a)에 의해 결정될 수 있다. 이 예에서 예시된 바와 같이, 좌표(1972a)와 연관된 값들은: (0.39, 0.48, QMPB1)이며, 여기에서:
ㆍ 0.39는 로드(클라이언트 B) 값을 표현하고;
ㆍ QMPB1은 QoS 관리 정책 세트(B1)를 표현하고;
ㆍ 0.48은 그 값이 QoS 관리 정책 세트(B) 및 로드(클라이언트) 값의 함수에 기초하여 결정될 수 있는 스케일링된(및/또는 정규화된) 타겟 IOPS 비를 표현한다. 예를 들면, 도 19b의 특정한 예시적인 실시예에서, 타겟 IOPS 비 값은 로드(클라이언트 B) 값이 QoS 관리 정책 세트(B1)("QMPB1") 곡선(1904a)과 교차하는 교차 포인트(예로서, 1972a)에 의해 결정될 수 있다.
적어도 일 실시예에서, 클라이언트 B에 대한 타겟 IOPS 값(예로서, T2)은 예를 들면, 다음과 같은 클라이언트 B의 최소 및 최대 IOPS 값들에 대한 함수로서 표현될 수 있다:
TargetIOPS(클라이언트B) = T2
T2 = (0.48*(최대 IOPS (클라이언트B) + 최소 IOPS (클라이언트B) )) + 최소 IOPS (클라이언트B)
따라서, 예를 들면, 저장 시스템은 클라이언트 B의 IOPS가 T2를 초과하지 않는 IOPS 값으로 스로틀링되게(적어도 일시적으로) 함으로써 클라이언트 B의 IO들에 대한 QoS 관리를 구현할 수 있다.
유사하게, 도 19b의 예시적인 실시예에 예시된 바와 같이, 예시의 목적들을 위해, 클라이언트 C의 현재 로드 값("로드(클라이언트 C)")(1982)은 로드(클라이언트) 임계 값(A1)보다 크지만, 로드(클라이언트) 임계 값(A2)보다 작은 것으로 가정되는, 로드(클라이언트 C) = 0.55인 것으로 산출된다고 가정된다. 따라서, 이러한 예시적인 실시예에서, 저장 시스템은 QoS 관리 정책 세트(B1)가 클라이언트 C에 대한 타겟 IOPS 값을 결정하기 위해 사용된다고 결정할 수 있다.
따라서, 예를 들면, 도 19b의 예시적인 실시예에서, 클라이언트 C에 대한 타겟 IOPS 값은 로드(클라이언트 C) 값이 QoS 관리 정책 세트(B1)("QMPB1") 곡선(1904a)과 교차하는 좌표(1982a)에 의해 결정될 수 있다. 이 예에 예시된 바와 같이, 좌표(1982a)와 연관된 값들은: (0.55, 0.18, QMPB1)이며, 여기에서:
ㆍ 0.55는 로드(클라이언트 C) 값을 표현하고;
ㆍ QMPB1은 QoS 관리 정책 세트(B1)를 표현하고;
ㆍ 0.19는 그 값이 QoS 관리 정책 세트(B) 및 로드(클라이언트) 값의 함수에 기초하여 결정될 수 있는 스케일링된(및/또는 정규화된) 타겟 IOPS 비를 표현한다. 예를 들면, 도 19b의 특정한 예시적인 실시예에서, 타겟 IOPS 비 값은 로드(클라이언트 C) 값이 QoS 관리 정책 세트(B1)("QMPB1") 곡선(1904a)과 교차하는 교차 포인트(예로서, 1982a)에 의해 결정될 수 있다.
적어도 일 실시예에서, 클라이언트 C에 대한 타겟 IOPS 값(예로서, T3)은 예를 들면, 다음과 같은 클라이언트 C의 최소 및 최대 IOPS 값들에 대한 함수로서 표현될 수 있다:
TargetIOPS(클라이언트C) = T3
T3 = (0.19*(최대 IOPS (클라이언트C) + 최소 IOPS (클라이언트C) )) + 최소 IOPS (클라이언트C)
따라서, 예를 들면, 저장 시스템은 클라이언트 C의 IOPS가 T3를 초과하지 않는 IOPS 값으로 스로틀링되게(적어도 일시적으로) 함으로써 클라이언트 C의 IO들에 대한 QoS 관리를 구현할 수 있다.
부가적으로, 도 19b의 예시적인 실시예에 예시된 바와 같이, 예시의 목적들을 위해, 클라이언트 D의 현재 로드 값("로드(클라이언트 D)")(1992)은 로드(클라이언트) 임계 값(A2)보다 크다고 가정되는, 로드(클라이언트 D) = 0.74인 것으로 산출된다고 가정된다. 따라서, 이러한 예시적인 실시예에서, 저장 시스템은 QoS 관리 정책 세트(C1)가 클라이언트 D에 대한 타겟 IOPS 값을 결정하기 위해 사용된다고 결정할 수 있다.
따라서, 예를 들면, 도 19b의 예시적인 실시예에서, 클라이언트 D에 대한 타겟 IOPS 값은 로드(클라이언트 D) 값이 QoS 관리 정책 세트(C1)("QMPC1") 곡선(1906a)과 교차하는 좌표(1992a)에 의해 결정될 수 있다. 이 예에 예시된 바와 같이, 좌표(1992a)와 연관된 값들은: (0.74, 0.74, QMPC1)이며, 여기에서:
ㆍ 0.74는 로드(클라이언트 D) 값을 표현하고;
ㆍ QMPC1은 QoS 관리 정책 세트(C1)를 표현하고;
ㆍ 0.75는 그 값이 QoS 관리 정책 세트(C) 및 로드(클라이언트) 값의 함수에 기초하여 결정될 수 있는 스케일링된(및/또는 정규화된) 타겟 IOPS 비를 표현한다. 예를 들면, 도 19b의 특정한 예시적인 실시예에서, 타겟 IOPS 비 값은 로드(클라이언트 D) 값이 QoS 관리 정책 세트(C1)("QMPC1") 곡선(1906a)과 교차하는 교차 포인트(예로서, 1992a)에 의해 결정될 수 있다.
적어도 일 실시예에서, 클라이언트 D에 대한 타겟 IOPS 값(예로서, T4)은 예를 들면, 다음과 같은 클라이언트 D의 최소 및 최대 IOPS 값들에 대한 함수로서 표현될 수 있다:
TargetIOPS(클라이언트D) = T4
T4 = 0.75*최소 IOPS (클라이언트D)
따라서, 예를 들면, 저장 시스템은 클라이언트 D의 IOPS가 T4를 초과하지 않는 IOPS 값으로 스로틀링되게(적어도 일시적으로) 함으로써 클라이언트 D의 IO들에 대한 QoS 관리를 구현할 수 있다.
적어도 몇몇 실시예들에서, 저장 시스템은 최소 및 최대 IOPS의 상기 클라이언트 정의 범위에 대하여 각각의 클라이언트에 대한 IOPS를 비례적으로 스로틀링할 수 있다. 몇몇 실시예들에서, 각각의 개별적인 클라이언트에 대해 구현되는 상이한 QoS 관리 정책 세트들은 다른 것들에 대해 몇몇 클라이언트들을 우선순위화하는 효과를 가질 수 있다. 부가적으로, 몇몇 실시예들에서, QoS 관리 정책 세트들은 시스템이 오버로딩되는 것을 방지하도록 돕기 위해 하나 이상의 클라이언트들에 대한 타겟 IOPS 값들을 우선적으로 감소시킬 수 있다.
이전에 언급된 바와 같이, 저장 시스템은 (1) 판독 및 기록 관련 트랜잭션들 사이에서 구별하도록, 및 주어진 클라이언트와 연관된 로드(클라이언트-판독) 및 로드(클라이언트-기록)를 개별적으로 분석, 결정, 및/또는 추적하도록; 및 (2) 클라이언트-관련된 판독 IOPS 및 클라이언트-관련 기록 IOPS에 대한 상이한 각각의 QoS 관리 정책 세트들을 독립적으로 평가 및 구현하도록 구성되거나 또는 설계될 수 있다. 이러한 기술들의 예시적인 실시예들은 예를 들면, 도 16, 도 17, 도 20, 및 도 21에 예시된다.
도 16은 특정 실시예에 따른 QoS 클라이언트-판독 정책 관리 절차(1600)의 흐름도를 도시한다. 절차(1600)의 부가적인, 보다 적거나, 또는 상이한 동작들이 특정한 실시예에 의존하여 수행될 수 있다. 절차(1600)는 컴퓨팅 디바이스 상에 구현될 수 있다. 일 구현예에서, 절차(1600)는 컴퓨팅 디바이스에 의해 실행될 때, 컴퓨팅 디바이스가 절차(1600)의 동작들을 수행하게 하는 지시들을 포함하는 컴퓨터-판독 가능한 매체 상에 인코딩된다. 상이한 실시예들에 따르면, QoS 클라이언트-판독 정책 관리 절차에 의해 제공된 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들의 적어도 일 부분이 저장 시스템의 하나 이상의 노드들 및/또는 볼륨들에 구현될 수 있다. 예시의 목적들을 위해, QoS 클라이언트-판독 정책 관리 절차(1600)는 선택된 클라이언트(예로서, 도 9, 클라이언트 A)에 대한 QoS 정책 관리를 수행하기 위해 인스턴스화된다고 가정된다.
적어도 일 실시예에서, QoS 클라이언트-판독 정책 관리 절차는 저장 시스템의 하나 이상의 선택된 클라이언트들에 대한 로드 정보의 분석, 측정, 산출, 및 업데이팅에 관한 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들을 수행하고 및/또는 구현하도록 동작 가능할 수 있다. 특정 실시예들에 따르면, QoS 클라이언트-판독 정책 관리 절차의 다수의 인스턴스들 또는 스레드들은 하나 이상의 프로세서들 및/또는 하드웨어 및/또는 하드웨어와 소프트웨어의 다른 조합들의 사용을 통해 동시에 구현되고 및/또는 개시될 수 있다. 일 실시예에서, QoS 클라이언트-판독 정책 관리 절차의 별개의 인스턴스 또는 스레드는 저장 시스템의 각각의 개별적인 클라이언트에 대한 QoS 정책 관리를 수행하거나 또는 가능하게 하기 위해 개시될 수 있다.
상이한 실시예들에 따르면, QoS 클라이언트-판독 정책 관리 절차의 하나 이상의 상이한 스레드들 또는 인스턴스들이 하나 이상의 상이한 시간 간격들(예로서, 특정 시간 간격 동안, 규칙적인 주기적 간격들로, 불규칙적인 주기적 간격들로, 요구시 등)로 자동으로 및/또는 동적으로 개시되고 및/또는 구현될 수 있다. 예를 들면, 일 실시예에서, QoS 클라이언트-판독 정책 관리 절차의 주어진 인스턴스는 그에 의해 식별된 클라이언트에 대한 업데이트된 로드(클라이언트-판독) 값을 분석 및 결정하기 위해 약 250 내지 1000 밀리초들마다(예로서, 주어진 클라이언트에 대해 500 ms마다) 자동으로 구동하도록 구성되거나 또는 설계될 수 있다. 몇몇 실시예들에서, 주어진 클라이언트에 대한 QoS 클라이언트-판독 정책 관리 절차의 실행의 빈도는 예를 들면, 시스템 메트릭들, 클라이언트 메트릭들, QoS 관리 정책들에서의 변화들 등과 같은, 다른 이벤트들 및/또는 상태들에 기초하여 자동으로 및/또는 동적으로 변할 수 있다.
도 16의 예시적인 실시예에서, 1602에서, 적어도 하나의 상태 또는 이벤트가 QoS 클라이언트-판독 정책 관리 절차의 실행을 개시하기 위해 검출된다고 가정된다. 1604에 도시된 바와 같이, QoS 클라이언트-판독 정책 관리 절차는 시스템 및/또는 클라이언트 메트릭들의 분석을 개시할 수 있다. 적어도 일 실시예에서, 시스템 메트릭들의 분석은 식별된 클라이언트에 대한 판독 동작들을 핸들링하기 위해 할당되는 서비스(들)와 연관된 IO 활동들에 대한 판독 대기 시간들에 관한 실시간 정보를 측정, 획득, 및/또는 결정하는 것을 포함할 수 있다.
1606에 도시된 바와 같이, QoS 클라이언트-판독 정책 관리 절차는 식별된 클라이언트에 대한 현재 로드(클라이언트-판독) 값을 결정할 수 있다. 상이한 실시예들에 따르면, 로드(클라이언-판독) 값은, 예를 들면, 여기에 설명된 다양한 로드(클라이언트-판독) 산출 기술들 중 하나 이상을 사용하여, 결정되거나 또는 산출될 수 있다. 적어도 일 실시예에서, 로드(클라이언트-판독) 값은 식별된 클라이언트에 대한 판독 동작들을 핸들링하기 위해 할당되는 서비스(들)와 연관된 IO 활동들에 대한 판독 대기 시간 메트릭들을 고려하는 클라이언트-특정 로드 값으로서 표현될 수 있다.
1608에 도시된 바와 같이, QoS 클라이언트-판독 정책 관리 절차는 현재의 로드(클라이언트-판독) 값을 분석할 수 있으며, 이에 응답하여 식별된 클라이언트에 대한 적절한 QoS 관리 정책을 선택 및 구현할 수 있다. 예를 들면, 도 16의 예시적인 실시예에 예시된 바와 같이:
ㆍ 로드(클라이언트-판독) < 임계 값(A1)이라고 결정된다면, QoS 클라이언트-판독 정책 관리 절차는 QoS 관리 정책 세트(A2)를 구현할 수 있다(1610);
ㆍ 임계 값(A1)≥로드(클라이언트-판독)≥임계 값(A2)이라고 결정된다면, QoS 클라이언트-판독 정책 관리 절차는 QoS 관리 정책 세트(B2)를 구현할 수 있다(1612);
ㆍ 로드(클라이언트-판독) > 임계 값(A2)이라고 결정된다면, QoS 클라이언트-판독 정책 관리 절차는 QoS 관리 정책 세트(C2)를 구현할 수 있다(1615).
도 20은 클라이언트 IOPS를 스로틀링하기 위한 상이한 QoS 관리 정책 세트들이 어떻게 로드(클라이언트-판독) 상태들을 변경하는 것에 응답하여 자동으로 및/또는 동적으로 구현될 수 있는지에 대한 예시적이 실시예를 예시한 그래픽 표현을 도시한다. 도 20의 예시적인 실시예에 예시된 바와 같이, 클라이언트 판독 IOPS(2010)에 대응하는 타겟 성능 값들을 표현한 Y-축 및 선택된 클라이언트(예로서, 클라이언트 A)에 대한 클라이언트 로드(클라이언트-판독) 값들을 표현한 X-축을 포함하는 X-Y 그래프 부분(2000)이 도시된다. 도 20의 예시적인 실시예에 예시된 바와 같이, 그래프 부분(2000)은 식별된 클라이언트에 대한 최소판독 IOPS QoS 파라미터(2003); 최대 판독 IOPS QoS 파라미터(2005); 및 최대 버스트 판독 IOPS QoS 파라미터(2007)를 표현하는 기준 라인들(2003, 2005, 2007)을 포함한다. 부가적으로, 그래프 부분(2000)은 이러한 예시적인 실시예에서, 식별된 클라이언트에 대해 실행될 현재 QoS 관리 정책 세트를 결정 및 선택하기 위해 사용될 수 있는 임계 값들을 표현하는 기준 라인들(2011, 2013, 2015)을 포함한다. 예를 들면, 도 20에 예시된 바와 같이:
ㆍ 로드(클라이언트-판독) < 임계 값(A2)일 때 시간들 동안, QoS 관리 정책 세트(A2)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 20의 특정한 예시적인 실시예에서, 영역(2002)은 클라이언트가 QoS 관리 정책 세트(A2)에 따라 동작할 수 있는 IOPS의 가능한 값들의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(A2)는 클라이언트가 IOPS 크레딧들을 누적하도록 허용되며, 클라이언트의 IOPS가: 클라이언트의 max IOPS QoS 파라미터(2005)와 동일하거나 작을 수 있고; 누적된 크레딧들에 기초하여 클라이언트의 최대 버스트 IOPS QoS 파라미터 위에서 동작하도록 허용될 수 있지만; 클라이언트의 최대 버스트 IOPS QoS 파라미터(2007)를 초과하지 않는다고 특정할 수 있다.
ㆍ 임계 값(A2)≥로드(클라이언트-판독)≥임계 값(A2)일 때 시간들 동안, QoS 관리 정책 세트(B2)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 20의 특정한 예시적인 실시예에서, 영역(2004)은 클라이언트가 QoS 관리 정책 세트(B2)에 따라 동작할 수 있는 IOPS의 가능한 값들의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(B2)는 클라이언트의 최대 판독 IOPS QoS 파라미터 및 최소 판독 IOPS QoS 파라미터 사이에서의 범위 내에 있는 타겟 성능 IOPS 값으로 스로틀링된다는 것을 특정할 수 있다. 부가적으로, QoS 관리 정책 세트(B2)는 또한, 임의의 주어진 시간에(임계 값(A1)≥로드(클라이언트-판독)≥임계 값(A2)인 동안), 클라이언트의 판독 IOPS는 클라이언트의 현재(예로서, 실시간) 로드(클라이언트-판독) 값에 기초하여 동적으로 결정되는 타겟 성능 IOPS 값으로 스로틀링된다는 것을 특정할 수 있다. 예를 들면, 도 20의 예시적인 실시예에서, QoS 관리 정책 세트(B2)가 시행 중인 동안, 클라이언트의 판독 IOPS는 경계 곡선(2004a)(예로서, 클라이언트의 현재 로드(클라이언트-판독) 값에 대해 클라이언트의 허용 가능한 판독 IOPS의 상한을 정의하는)에 의해 정의된 대응하는 IOPS 값을 초과하지 않는 타겟 성능 IOPS로 스로틀링된다.
ㆍ 로드(클라이언트-판독) > 임계 값(A2)일 때 시간들 동안, QoS 관리 정책 세트(C2)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 20의 특정한 예시적인 실시예에서, 영역(2006)은 클라이언트가 QoS 관리 정책 세트(C2)에 따라 동작할 수 있는 IOPS의 가능한 값들의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(C2)는 클라이언트의 판독 IOPS가 클라이언트의 최소 판독 IOPS 파라미터 및 0 사이에서의 범위 내에 있는 타겟 성능 IOPS 값으로 스로틀링된다고 특정할 수 있다. 부가적으로, QoS 관리 정책 세트(C2)는 또한 임의의 주어진 시간에(로드(클라이언트-판독) > 임계 값(A2)), 클라이언트의 판독 IOPS가 클라이언트의 로드(클라이언트-판독) 값에 기초하여 동적으로 결정되는 타겟 성능 IOPS 값으로 스로틀링된다고 특정할 수 있다. 예를 들면, 도 20의 예시적인 실시예에서, QoS 관리 정책 세트(C2)가 시행 중인 동안, 클라이언트의 판독 IOPS는 경계 곡선(2006a)(예로서, 클라이언트의 현재 로드(클라이언트-판독) 값에 대한 클라이언트의 허용 가능한 판독 IOPS의 상한을 정의하는)에 의해 정의된 대응하는 IOPS 값을 초과하지 않는 IOPS 값으로 스로틀링된다.
도 17은 특정 실시예에 따른 QoS 클라이언트-기록 정책 관리 절차(1700)의 흐름도를 도시한다. 절차(1700)의 부가적인, 보다 적거나, 또는 상이한 동작들이 특정한 실시예에 의존하여 수행될 수 있다. 절차(1700)는 컴퓨팅 디바이스 상에 구현될 수 있다. 일 구현예에서, 절차(1700)는 컴퓨팅 디바이스에 의해 실행될 때, 컴퓨팅 디바이스가 절차(1700)의 동작들을 수행하게 하는 지시들을 포함하는 컴퓨터-판독 가능한 매체 상에 인코딩된다. 상이한 실시예들에 따르면, QoS 클라이언트-기록 정책 관리 절차에 의해 제공된 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들의 적어도 일 부분이 저장 시스템의 하나 이상의 노드들 및/또는 볼륨들에 구현될 수 있다. 예시의 목적들을 위해, QoS 클라이언트-기록 정책 관리 절차(1700)는 선택된 클라이언트(예로서, 도 9, 클라이언트 A)에 대한 QoS 정책 관리를 수행하기 위해 인스턴스화된다고 가정된다.
적어도 일 실시예에서, QoS 클라이언트-기록 정책 관리 절차는 저장 시스템의 하나 이상의 선택된 클라이언트들에 대한 로드 정보의 분석, 측정, 산출, 및 업데이팅에 관한 다양한 유형들의 기능들, 동작들, 행동들, 및/또는 다른 특징들을 수행하고 및/또는 구현하도록 동작 가능할 수 있다. 특정 실시예들에 따르면, QoS 클라이언트-기록 정책 관리 절차의 다수의 인스턴스들 또는 스레드들은 하나 이상의 프로세서들 및/또는 하드웨어 및/또는 하드웨어와 소프트웨어의 다른 조합들의 사용을 통해 동시에 구현되고 및/또는 개시될 수 있다. 일 실시예에서, QoS 클라이언트-기록 정책 관리 절차의 별개의 인스턴스 또는 스레드는 저장 시스템의 각각의 개별적인 클라이언트에 대한 QoS 정책 관리를 수행하거나 또는 가능하게 하기 위해 개시될 수 있다.
상이한 실시예들에 따르면,QoS 클라이언트-기록 정책 관리 절차의 하나 이상의 상이한 스레드들 또는 인스턴스들이 하나 이상의 상이한 시간 간격들(예로서, 특정 시간 간격 동안, 규칙적인 주기적 간격들로, 불규칙적인 주기적 간격들로, 요구시 등)로 자동으로 및/또는 동적으로 개시되고 및/또는 구현될 수 있다. 예를 들면, 일 실시예에서, QoS 클라이언트-기록 정책 관리 절차의 주어진 인스턴스는 그에 의해 식별된 클라이언트에 대한 업데이트된 로드(클라이언트-기록) 값을 분석 및 결정하기 위해 약 250 내지 1000 밀리초들마다(예로서, 주어진 클라이언트에 대해 500 ms마다) 자동으로 구동하도록 구성되거나 또는 설계될 수 있다. 몇몇 실시예들에서, 주어진 클라이언트에 대한 QoS 클라이언트-기록 정책 관리 절차의 실행의 빈도는 예를 들면, 시스템 메트릭들, 클라이언트 메트릭들, QoS 관리 정책들에서의 변화들 등과 같은, 다른 이벤트들 및/또는 상태들에 기초하여 자동으로 및/또는 동적으로 변할 수 있다.
도 17의 예시적인 실시예에서, 1702에서, 적어도 하나의 상태 또는 이벤트가 QoS 클라이언트-기록 정책 관리 절차의 실행을 개시하기 위해 검출된다고 가정된다. 1704에 도시된 바와 같이, QoS 클라이언트-기록 정책 관리 절차는 시스템 및/또는 클라이언트 메트릭들의 분석을 개시할 수 있다. 적어도 일 실시예에서, 시스템 메트릭들의 분석은 식별된 클라이언트에 대한 기록 및/또는 복제 동작들을 핸들링하기 위해 할당되는 서비스(들)와 연관된 IO 활동들에 대한 기록 대기 시간들에 관한 실시간 정보를 측정, 획득, 및/또는 결정하는 것을 포함할 수 있다.
1706에 도시된 바와 같이, QoS 클라이언트-기록 정책 관리 절차는 식별된 클라이언트에 대한 현재 로드(클라이언트-기록) 값을 결정할 수 있다. 상이한 실시예들에 따르면, 로드(클라이언-기록) 값은, 예를 들면, 여기에 설명된 다양한 로드(클라이언트-기록) 산출 기술들 중 하나 이상을 사용하여, 결정되거나 또는 산출될 수 있다. 적어도 일 실시예에서, 로드(클라이언트-기록) 값은 식별된 클라이언트에 대한 기록 및 복제 동작들을 핸들링하기 위해 할당되는 서비스(들)와 연관된 IO 활동들에 대한 기록 대기 시간 메트릭들을 고려하는 클라이언트-특정 로드 값으로서 표현될 수 있다.
1708에 도시된 바와 같이,QoS 클라이언트-기록 정책 관리 절차는 현재의 로드(클라이언트-기록) 값을 분석할 수 있으며, 이에 응답하여 식별된 클라이언트에 대한 적절한 QoS 관리 정책을 선택 및 구현할 수 있다. 예를 들면, 도 17의 예시적인 실시예에 예시된 바와 같이:
ㆍ 로드(클라이언트-기록) < 임계 값(A1)이라고 결정된다면, QoS 클라이언트-기록 정책 관리 절차는 QoS 관리 정책 세트(A3)를 구현할 수 있다(1710);
ㆍ 임계 값(A1)≥로드(클라이언트-기록)≥임계 값(A2)이라고 결정된다면, QoS 클라이언트-기록 정책 관리 절차는 QoS 관리 정책 세트(B3)를 구현할 수 있다(1712);
ㆍ 로드(클라이언트-기록) > 임계 값(A2)이라고 결정된다면, QoS 클라이언트-기록 정책 관리 절차는 QoS 관리 정책 세트(C1)를 구현할 수 있다(1716).
도 21은 클라이언트 IOPS를 스로틀링하기 위한 상이한 QoS 관리 정책 세트들이 어떻게 로드(클라이언트-기록) 상태들을 변경하는 것에 응답하여 자동으로 및/또는 동적으로 구현될 수 있는지에 대한 예시적이 실시예를 예시한 그래픽 표현을 도시한다. 도 21의 예시적인 실시예에 예시된 바와 같이, 클라이언트 기록 IOPS(2110)에 대응하는 타겟 성능 값들을 표현한 Y-축 및 선택된 클라이언트(예로서, 클라이언트 A)에 대한 클라이언트 로드(클라이언트-기록) 값들을 표현한 X-축을 포함하는 X-Y 그래프 부분(2100)이 도시된다. 도 21의 예시적인 실시예에 예시된 바와 같이, 그래프 부분(2100)은 식별된 클라이언트에 대한 최소 기록 IOPS QoS 파라미터(2103); 최대 기록 IOPS QoS 파라미터(2105); 및 최대 버스트 기록 IOPS QoS 파라미터(2107)를 표현하는 기준 라인들(2103, 2105, 2107)을 포함한다. 부가적으로, 그래프 부분(2100)은 이러한 예시적인 실시예에서, 식별된 클라이언트에 대해 실행될 현재 QoS 관리 정책 세트를 결정 및 선택하기 위해 사용될 수 있는 임계 값들을 표현하는 기준 라인들(2111, 2113, 2115)을 포함한다. 예를 들면, 도 21에 예시된 바와 같이:
ㆍ 로드(클라이언트-기록) < 임계 값(A1)일 때 시간들 동안, QoS 관리 정책 세트(A3)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 21의 특정한 예시적인 실시예에서, 영역(2102)은 클라이언트가 QoS 관리 정책 세트(A3)에 따라 동작할 수 있는 IOPS의 가능한 값들의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(A3)는 클라이언트가 IOPS 크레딧들을 누적하도록 허용되며, 클라이언트의 IOPS가: 클라이언트의 최대 IOPS QoS 파라미터(2105)와 동일하거나 작을 수 있고; 누적된 크레딧들에 기초하여 클라이언트의 최대 버스트 IOPS QoS 파라미터 위에서 동작하도록 허용될 수 있지만; 클라이언트의 최대 버스트 IOPS QoS 파라미터(2107)를 초과하지 않는다고 특정할 수 있다.
ㆍ 임계 값(A3)≥로드(클라이언트-기록)≥임계 값(A2)일 때 시간들 동안, QoS 관리 정책 세트(B3)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 21의 특정한 예시적인 실시예에서, 영역(2104)은 클라이언트가 QoS 관리 정책 세트(B1)에 따라 동작할 수 있는 IOPS의 가능한 값들의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(B3)는 클라이언트의 max 판독 IOPS QoS 파라미터 및 min 판독 IOPS QoS 파라미터 사이에서의 범위 내에 있는 타겟 성능 IOPS 값으로 스로틀링된다는 것을 특정할 수 있다. 부가적으로, QoS 관리 정책 세트(B1)는 또한, 임의의 주어진 시간에(임계 값(A1)≥로드(클라이언트-기록)≥임계 값(A2)인 동안), 클라이언트의 기록 IOPS는 클라이언트의 현재(예로서, 실시간) 로드(클라이언트-기록) 값에 기초하여 동적으로 결정되는 타겟 성능 IOPS 값으로 스로틀링된다는 것을 특정할 수 있다. 예를 들면, 도 21의 예시적인 실시예에서, QoS 관리 정책 세트(B3)가 시행 중인 동안, 클라이언트의 기록 IOPS는 경계 곡선(2104a)(예로서, 클라이언트의 현재 로드(클라이언트-기록) 값에 대해 클라이언트의 허용 가능한 기록 IOPS의 상한을 정의하는)에 의해 정의된 대응하는 IOPS 값을 초과하지 않는 타겟 성능 IOPS로 스로틀링된다.
ㆍ 로드(클라이언트-기록) > 임계 값(A2)일 때 시간들 동안, QoS 관리 정책 세트(C3)는 식별된 클라이언트에 대해 시행되게 설정될 수 있다. 도 21의 특정한 예시적인 실시예에서, 영역(2106)은 클라이언트가 QoS 관리 정책 세트(C3)에 따라 동작할 수 있는 IOPS의 가능한 값들의 그래픽 표현을 제공한다. 이러한 예시적인 실시예에서, QoS 관리 정책 세트(C3)는 클라이언트의 기록 IOPS가 클라이언트의 min 판독 IOPS 파라미터 및 0 사이에서의 범위 내에 있는 타겟 성능 IOPS 값으로 스로틀링된다고 특정할 수 있다. 부가적으로, QoS 관리 정책 세트(C3)는 또한 임의의 주어진 시간에(로드(클라이언트-기록) > 임계 값(A2)), 클라이언트의 판독 IOPS가 클라이언트의 로드(클라이언트-기록) 값에 기초하여 동적으로 결정되는 타겟 성능 IOPS 값으로 스로틀링된다고 특정할 수 있다. 예를 들면, 도 21의 예시적인 실시예에서, QoS 관리 정책 세트(C3)가 시행 중인 동안, 클라이언트의 기록 IOPS는 경계 곡선(2106a)(예로서, 클라이언트의 현재 로드(클라이언트-기록) 값에 대한 클라이언트의 허용 가능한 기록 IOPS의 상한을 정의하는)에 의해 정의된 대응하는 IOPS 값을 초과하지 않는 IOPS 값으로 스로틀링된다.
적어도 일 실시예에서, 여기에 설명된 다양한 QOS 기술들의 적어도 일 부분이 주어진 클러스터의 다수의 상이한 클라이언트들에 걸쳐 개별적으로 맞춤화된 QoS 관리 정책들을 동적으로 구현하기 위한 저장 시스템에 대한 능력에 적어도 부분적으로 기초할 수 있다.
대안적인 실시예에서, 저장 시스템이 클러스터가 오버로딩된다고 결정할 때, 시스템은 클러스터의 각각의 클라이언트와 연관된 IOPS를 비례적으로 및 고르게 스로틀링하기 위해 슬라이드제(sliding scale)를 사용할 수 있다. 시스템 오버로드가 증가함에 따라, 각각의 클라이언트의 IOPS는 각각의 클라이언트의 각각의, 업데이트된 타겟 IOPS 값에 기초하여 자동으로, 동적으로, 및/또는 비례적으로 철회(또는 스로틀링)될 수 있다. 최대 IOPS 및 최소 IOPS QoS 파라미터들이 각각의 클라이언트에 대해 상이할 수 있으므로, 각각의 클라이언트에 대한 타겟 성능 IOPS 값은 유사한 시스렘 로드 상태들 하에서조차 상이할 수 있다.
예를 들면, 5 ms 대기 시간에서, 저장 시스템은 제 1 임계 값(예로서, 로드(시스템) = 70%) 이상이도록 시스템의 로드를 지정할 수 있으며, 이것은 예를 들면 각각의 클라이언트의 IOPS가 그것들 각각의 최소 IOPS QoS 파라미터에 가까운 어딘가에 값으로 스로틀링되게 하는 제 1 QoS 관리 정책 세트를 구현한 시스템을 야기할 수 있다. 이것이 발생할 때, 예를 들면, 보다 많은 용량을 부가함으로써 및/또는 볼륨들의 최대 IOPS QoS 파라미터들을 낮춤으로써와 같이, 클러스터에 대한 보다 높은 성능을 달성하기 위한 단지 제한된 방식들이 있을 수 있다. 대안적으로, 보다 작은 클러스터 대기 시간들(예로서, < ~2ms)에서, 저장 시스템은 제 2 임계 값(예로서, 로드(시스템) = 30%) 미만이도록 시스템의 로드를 지정할 수 있으며, 시스템은 클라이언트들이 계속해서 버스트하며 그것들의 최대 IOPS QoS 파라미터 이상으로 가도록 허용하는 제 2 QoS 관리 정책 세트를 구현할 수 있다. 클러스터가 오버로딩된 것으로 고려되지 않는 실시예들에서(예로서, 판독 대기 시간들이 수용 가능하며, 기록 캐시 큐(들)가 충분히 낮은), 클러스터 로드는 최종 타겟 성능 IOPS 값에 영향을 미치지 않을 수 있다. 따라서, 예를 들면, 클라이언트 A의 최대 IOPS QoS 파라미터가 1000 IOPS로 설정되며, 클라이언트 A의 최대 버스트 IOPS QoS 파라미터가 1500 IOPS로 설정된다면, 로딩되지 않은 상태들 하에서, 시스템은 클라이언트 A의 타겟 성능 IOPS 값을 1000 내지 1500 IOPS의 범위 내에 있는 것으로 설정할 수 있다.
그것들의 최대 QoS 파라미터( 버스팅 ) 이상에서 동작하는 클라이언트들
도 7은 일 구현에 따른 시간 기간에 걸쳐 클라이언트(108)에 의해 수행된 IOPS의 수의 그래프(700)를 묘사한다. Y-축은 초당 수행된 IOPS의 수를 도시한다. 1/2 초의 기간들이 X-축 상에 도시된다. IOPS의 수가 최대 IOPS 레벨(100 IOPS) 미만일 때 누적되는 크레딧들이 도시된다. 도시된 바와 같이, 크레딧들은 시간 기간들( 1 내지 8)로부터 점차 증가한다. 시간 기간(8)에서, 클라이언트는, 바(702)에 의해 표시된 바와 같이, 대략 320개의 크레딧들을 누적시킨다. 클라이언트(108)가 최대 IOPS 값 이상으로 버스팅함에 따라, 크레딧들의 수는 감소하기 시작한다. 그래프(700)에서, 클라이언트는 시간 기간(9)에서 정사각형(704)에 의해 도시된 바와 같이, 대략 125 IOPS를 사용한다. 클라이언트는, 바(702)에 의해 도시된 바와 같이, 그것들이 누적된 크레딧들을 갖기 때문에, 그것들의 최대 IOPS 레벨 이상으로 버스팅하도록 허용된다. 클라이언트의 IOPS 레벨은 그것들의 버스트 IOPS 값에서 캡핑된다. 그래프(700)에서, 클라이언트는 시간 기간들(10 및 11)에서 그것들의 버스트 IOPS 값에 도달한다. 클라이언트가 그것들의 최대 IOPS 값 이상으로 동작할 때, 그것들의 크레딧들은 감소된다. 일 구현예에서, 감소된 크레딧들의 양은 클라이언트의 최대 IOPS 값에 대해 IOPS의 양과 동일하다. 시간 기간(13)으로부터, 클라이언트(108)는 최대 IOPS 레벨에서 동작하며 크레딧들의 수는 증가하지 않는다.
크레딧들은 클라이언트 메트릭들에 기초하여 누적될 수 있다. 예를 들면, 일 실시예에서, 클라이언트의 IOPS가 특정된 임계치 미만인 동안(예로서, 클라이언트의 IOPS가 클라이언트의 최대 IOPS 값 미만인 동안) 클라이언트가 이용하지 않는 각각의 IO 동작에 대해, 클라이언트는 그 다음에 클라이언트의 IOPS가 클라이언트의 최대 IOPS 값 이상으로 버스팅할 수 있게 하기 위해 사용될 수 있는(시스템에 의해 허용될 때) "IOP 크레딧"을 수신할 수 있다. 예를 들면, 클라이언트의 최대 IOPS 값이 1000 IOPS에서 설정되며, 클라이언트의 최대 버스트 IOPS 값이 1500 IOPS에서 설정된다고 가정되며, 클라이언트가 현재 단지 900 IOPS를 사용하고 있으며 시스템이 오버로딩되지 않는다고 추가로 가정된다면, 클라이언트는 그 다음에 클라이언트의 IOPS가 1000 IOPS 이상으로 버스팅할 수 있게 하기 위해 사용될 수 있는 100 IOPS 크레딧들(예로서, 각각의 초)을 누적시킬 수 있다.
상이한 실시예들에 따르면, 하나 이상의 한계들 또는 제한들이 예를 들면, 다음 중 하나 이상(또는 그것의 조합들)과 같은 IOPS 버스트 활동들과 관련하여 도입될 수 있다:
총 IOPS 크레딧들(예로서, 주어진 클라이언트에 대해 및/또는 주어진 클러스터에 대해)이 특정한 양에서 캡핑될 수 있다. 예를 들면, 일 실시예에서, 주어진 클라이언트에 대해, 상기 클라이언트에 의해 누적될 수 있는 총 IOPS 크레딧들이:
총 IOPS 크레딧들 = (최대 버스트 IOPS 값 - 최대 IOPS 값) * 버스트 시간에 따라 결정될 수 있다. 따라서, 버스트 시간이 10 초들에서 설정되는 일 예시적인 실시예에서, 클라이언트는 (1500 - 1000) * 10 = 5000 IOPS 크레딧들의 최대치를 누적시킬 수 있다.
클라이언트는 단지 주어진 시간 간격 동안 그것의 누적된 IOPS 크레딧들의 할당된 부분만을 사용하는 것에 제한될 수 있다. 예를 들면, 클라이언트가 5000 크레딧들을 누적할 수 있지만, 클라이언트는 하나 이상의 특정 시간 간격들 동안 그것의 5000 크레딧들 중 단지 500(예로서, 1500-1000=500)을 사용하도록 허용될 수 있다. 또한, 버스팅은 상기 설명된 바와 같이 QoS 정책 세트들에 기초하여 제한될 수 있다.
슬라이스 서버 재균형화
상기 설명된 바와 같이, 볼륨 서버(122)는 하나 이상의 슬라이스 서버들과 연관될 수 있다. 각각의 슬라이스 서버(124)는 시스템(100) 내에서 볼륨과 연관된 메타데이터를 저장한다. 일 구현예에서, 새롭게 생성된 볼륨에 대한 새로운 슬라이스는 볼륨 서버(124)의 용량에 기초하여 볼륨 서버(122) 상에 위치될 수 있다. 예를 들면, 보다 많은 자유 저장 용량을 가진 볼륨 서버(122)가 보다 적은 자유 저장 용량을 가진 다른 볼륨 서버들에 대해 선택될 수 있다. 그러나, 새로운 슬라이스의 배치는 새로운 볼륨을 액세스하는 클라이언트에 대한 서비스 품질에 영향을 줄 수 있는, 볼륨 서버(122)의 로드를 참조하여 이상적이지 않을 수 있다. 슬라이스들의 보다 양호한 분포를 얻기 위해, 상기 설명된 로드 값들, 시스템 메트릭들, 클라이언트 메트릭들, 및 QoS 파라미터들이 언제 및 어디에 클라이언트의 슬라이스들을 배치할지를 결정하기 위해 사용될 수 있다. 예를 들면, 최소 QoS 파라미터들은 특정한 서비스 상에서 합산될 수 있다. 이러한 합산된 값은 서비스가 클라이언트들의 요청 QoS를 지원할 수 있음을 보장하기 위해 사용될 수 있다. 슬라이스들은 다양한 서비스들에 걸쳐 이러한 합산된 값에 기초하여 위치되고 및/또는 이동될 수 있다.
일 구현에 있어서, 클라이언트들의 QoS 파라미터들은 특정한 볼륨 서버의 타겟 서비스 품질 인덱스를 결정하기 위해 사용된다. 예를 들면, 특정한 볼륨 서버 상에 슬라이스 서버를 갖는 모든 클라이언트들이 결정될 수 있다. 각각의 클라이언트에 대한 최소 IOPS 또는 최대 IOPS가 합산될 수 있다. 이 값이 미리 결정된 임계치 이상이면, 하나 이상의 슬라이스들을 이동시키기 위한 결정이 이루어진다. 합이 임계치 이상일 때, 경보가 시스템의 관리자들에게 전송될 수 있다. 관리자는 그 후 어떤 슬라이스가 또 다른 슬라이스 서버로 이동할지를 결정할 수 있다. 대안적인 실시예에서, 이동은 그것 없이 로딩되지 않은 볼륨 서버를 선택함으로써, 슬라이스 서버들의 각각에 대한 서비스 품질 인덱스를 고르게 하는 이러한 방식으로 자동으로 발생할 수 있다. 어떤 볼륨 서버가 오버로딩되는지를 식별하는 것 외에, 충분히 이용되지 않은 볼륨 서버들이 또한 유사한 방식으로 식별될 수 있다. 각각의 볼륨 서버에 대한 최소 IOPS의 합이 산출되며 관리자들에게 디스플레이될 수 있다. 관리자들은 그 후 새로운 볼륨 서버를 지능적으로 선택할 수 있다. 또 다른 구현에서, 슬라이스는 오버로딩된 볼륨 서버를 검출하는 것에 기초하여 자동으로 이동될 수 있다.
QoS 파라미터들을 사용하는 것 외에, 상기 설명된 성능 메트릭들 및 로드 값들이 볼륨이 오버로딩되는지 및 어떤 볼륨들이 오버로딩되지 않는지를 결정하기 위해 사용될 수 있다. 예를 들면, 볼륨 서버의 기록-캐시 용량이 언제 및 어떤 슬라이스가 이동할지를 결정하기 위해 클라이언트의 메트릭들과 함께 사용될 수 있다. 프로세스는 볼륨 서버의 기록 캐시 용량과 같은, 다양한 시스템 레벨 메트릭들을 모니터링할 수 있으며, 임의의 볼륨 서버가 오버로딩되는지를 결정할 수 있다. 상기 설명된 타겟 성능 관리기(402)와 유사하게, 오버로딩된 상태는 대응하는 임계치들과 로드 값들을 비교하는 것에 기초하여 결정될 수 있다. 오버로드 상태가 검출된다면, 클라이언트 메트릭들, 시스템 메트릭들, 및/또는 로드 값들이 임의의 클라이언트들이 오버로드 상태에 불비례적으로 책임이 있는지를 결정하기 위해 사용될 수 있다. 예를 들면, 볼륨 서버는 다수의 클라이언트들에 대한 슬라이스들 및/또는 슬라이스 서버들을 가질 수 있다. 두 개의 이러한 클라이언트들은 볼륨 서버의 기록 캐시 용량에 영향을 주는 볼륨 서버상에서의 다량의 데이터 기록들을 고려할 수 있다. IO 기록들의 수, 클라이언트들 모두의 기록된 대역폭의 양, 및/또는 IO 기록들의 수 및/도는 대역폭과 연관된 로드 값들을 사용하여, 다른 클라이언트들보다 많이 기록 캐시 용량에 영향을 주는 두 개의 클라이언트들이 결정될 수 있다. 이러한 특성에 기초하여, 이들 두 개의 클라이언트들 중 하나와 연관된 슬라이스가 또 다른 볼륨 서버로 이동되도록 선택될 수 있다. 이러한 특징은 볼륨에서 특정한 슬라이스를 이동시키는 것이 시스템상에서의 다른 클라이언트들에 대한 오버로드 상태를 감소시키거나 또는 제거할 때 상당한 영향을 준다고 보장하도록 돕는다. 클라이언트 메트릭들, 시스템 메트릭들, 및/또는 로드 값들을 조사하지 않고, 볼륨 서버의 성능에 상당한 영향을 주지 않는 슬라이스가 이동될 수 있다. 이러한 시나리오는 여전히 오버로딩되는 원래 볼륨 서버를 야기할 수 있다.
또한, 다른 볼륨 서버들과 연관된 성능 메트릭들 및/또는 로드 값들이 슬라이스 서버에 대한 볼륨 서버를 찾기 위해 분석될 수 있다. 상기 예를 계속하면, 다량의 기록들을 핸들링할 수 있는 볼륨 서버가 결정될 수 있다. 예를 들면, 큰 기록 캐시 용량을 갖거나 또는 볼륨 서버의 모든 고객들에 걸쳐 비교적 작은 수의 기록 IO들을 갖는 볼륨 서버들이 성능 메트릭들 또는 로드 값들을 통해 식별될 수 있다. 슬라이스는 그 후 이들 식별된 슬라이스 서버들 중 하나로 이동될 수 있어서, 슬라이스를 이동시키는 것이 슬라이스 서버를 이동시키는 것에 기초하여 새로운 볼륨 서버에 대한 오버로드 상태를 야기하지 않을 것임을 보장하도록 돕는다.
일 구현예에서, 슬라이스 서버 재균형화는 서비스 품질 모니터링으로부터 독립적으로 행해진다. 예를 들면, 임의의 슬라이스가 이동되어야 하는지를 결정하기 위해 검사하는 것은 스케줄대로, 예로서 500 ms, 1 초, 1 분 등마다 행해질 수 있다. 또 다른 구현에서, 서비스 품질 모니터링 및 슬라이스 서버 재균형화가 통합될 수 있다. 예를 들면, 클라이언트들에 대한 서비스 품질을 검사하기 이전에, 슬라이스 서버 재균형화 프로세스는 임의의 슬라이스가 이동되어야 하는지를 결정하기 위해 질의될 수 있다. 임의의 볼륨 서버가 오버로딩된다면, 서비스 품질 모니터링은 슬라이스가 이동될 때까지 대기할 수 있다. 오버로딩된 볼륨 서버는 시스템 및 클라이언트들의 성능 메트릭들 및 로드 값들에 영향을 줄 수 있기 때문에, 서비스 품질 모니터링은 슬라이스 서버들이 재균형화된 후까지 대기할 수 있다. 이러한 특징은 서비스 품질 모니터링이 오버로딩된 볼륨 서버에 의해 부정적인 영향을 받지 않고 시스템 성능 및 클라이언트 성능을 적절하게 설명하는 성능 메트릭들 및/또는 로드 값들을 사용하도록 허용한다.
하나 이상의 흐름도들이 여기에 사용된다. 흐름도들의 사용은 수행된 동작들의 순서에 대해 제한적인 것으로 의도되지 않는다. 여기에 설명된 주제는 때때로 상이한 다른 구성요소들 내에 포함되거나 또는 그것과 연결된 상이한 구성요소들을 예시한다. 이러한 묘사된 아키텍처들은 단지 대표적이며, 사실상 동일한 기능을 달성하는 많은 다른 아키텍처들이 구현될 수 있다는 것이 이해될 것이다. 개념적인 의미에서, 동일한 기능을 달성하기 위한 구성요소들의 임의의 배열은 원하는 기능이 달성되도록 효과적으로 "연관된다". 그러므로, 특정한 기능을 달성하기 위해 여기에 조합된 임의의 두 개의 구성요소들은 아키텍처들 또는 중간 구성요소들에 관계없이, 원하는 기능이 달성되도록 서로 "연관된" 것으로서 보여질 수 있다. 마찬가지로, 그렇게 연관된 임의의 두 개의 구성요소들은 원하는 기능을 달성하기 위해 서로에 "동작 가능하게 연결된" 또는 "동작 가능하게 결합된" 것으로서 보여질 수 있으며, 그렇게 연관될 수 있는 임의의 두 개의 구성요소들은 또한 원하는 기능을 달성하기 위해 서로에 "동작 가능하게 결합 가능한" 것으로서 보여질 수 있다. 동작 가능하게 결합 가능한 특정 예들은 이에 제한되지 않지만, 물리적으로 짝을 이룰 수 있는 및/또는 물리적으로 상호 작용하는 구성요소들 및/또는 무선으로 상호 작용 가능한 및/또는 무선으로 상호 작용하는 구성요소들 및/또는 논리적으로 상호 작용하는 및/또는 논리적으로 상호 작용 가능한 구성요소들을 포함한다.
여기에서 실질적으로 임의의 복수 및/또는 단수 형태들의 사용에 대하여, 이 기술분야의 숙련자들은 맥락 및/또는 애플리케이션에 적절한 것으로서 복수에서 단수로 및/또는 단수에서 복수로 변환할 수 있다. 다양한 단수/복수 치환들은 명료함을 위해 여기에 명확하게 제시될 수 있다.
일반적으로, 여기에, 및 특히 첨부된 청구항들(예로서, 첨부된 청구항들의 몸체들)에 사용된 용어들은 일반적으로 "개방적" 용어들(예로서, 용어("포함하는")는 "그것에 제한되지 않고 포함하는"으로서 해석되어야 하고, 용어("갖는"은 "적어도 갖는"으로서 해석되어야 하고, 용어("포함하다"는 "이에 제한되지 않고 포함하다"로서 해석되어야 하는 등)로서 의도된다는 것이 이 기술분야의 숙련자들에 의해 이해될 것이다. 특정한 수의 도입된 청구항 설명이 의도된다면, 이러한 의도는 청구항에 명시적으로 설명될 것이며, 이러한 설명의 부재시, 어떤 그러한 의도는 존재하지 않는다는 것이 이 기술분야의 숙련자들에 의해 추가로 이해될 것이다. 예를 들면, 이해를 돕기 위한 것으로서, 다음의 첨부된 청구항들은 청구항 설명들을 도입하기 위해 도입구들("적어도 하나" 및 "하나 이상")의 사용을 포함할 수 있다. 그러나, 이러한 구절들의 사용은 부정 관사들("a" 또는 "an")에 의한 청구항 설명의 도입이 동일한 청구항이 도입구들("하나 이상" 또는 "적어도 하나") 및 "a" 도는 "an"(예로서, "a" 및/또는 "an"은 통상적으로 "적어도 하나" 또는 "하나 이상"을 의미하도록 해석되어야 한다)과 같으 부정 관사들을 포함할 때조차, 단지 하나의 이러한 설명을 포함한 발명들로 이러한 도입된 청구항 설명을 포함하는 임의의 특정한 청구항을 제한함을 내포하는 것으로서 해석되어서는 안된다; 청구항 설명들을 도입하기 위해 사용된 정관사들의 사용에 대해 동일하게 유효하다. 또한, 특정한 수의 도입 청구항 설명이 명확하게 나열될지라도, 이 기술분야의 숙련자들은 이러한 설명이 통상적으로 적어도 나열된 수(예로서, 다른 변경자들 없이, "두 개의 설명들"의 맨 설명은 통상적으로 적어도 두 개의 설명들, 또는 둘 이상의 설명들을 의미한다)를 의미하도록 해석되어야 한다는 것을 인식할 것이다. 더욱이, "A, B, 및 C 중 적어도 하나 등"과 유사한 관례가 사용되는 이들 인스턴스들에서, 일반적으로 이러한 구성은 이 기술분야의 숙련자가 관례를 이해할 것이라는 의미로 의도된다(예로서, "A, B, 및 C 중 적어도 하나를 가진 시스템"은 이에 제한되지 않지만 A 단독, B 단독, C 단독, A 및 B를 함께, A 및 C를 함께, B 및 C를 함께, 및/또는 A, B, 및 C를 함께 등을 갖는 시스템들을 포함할 것이다). "A, B, 또는 C 중 적어도 하나 등"과 유사한 관례가 사용되는 이들 인스턴스들에서, 일반적으로 이러한 구성은 이 기술분야의 숙련자가 관례를 이해할 것이라는 의미로 의도된다(예로서, "A, B, 또는 C 중 적어도 하나를 가진 시스템"이 이에 제한되지 않지만, A 단독, B 단독, C 단독, A 및 B를 함께, A 및 C를 함께, B 및 C를 함께, 및/또는 A, B, 및 C를 함께 등을 포함할 것이다). 둘 이상의 대안적인 용어들을 제공하는 가상의 임의의 이접어 및/또는 구절들은, 설명, 청구항들, 또는 도면들에서에 관계없이, 용어들 중 하나, 용어들 중 어느 하나, 또는 용어들 양쪽 모두를 포함하는 확률들을 고려하기 위해 이해되어야 한다는 것이 이 기술분야의 숙련자들에 의해 추가로 이해될 것이다. 예를 들면, 구절("A 또는 B")은 "A" 또는 "B" 또는 "A 및 B"의 확률들을 포함하는 것으로 이해될 것이다.
예시적인 구현들의 앞서 말한 설명은 예시의 및 설명의 목적들을 위해 제공되었다. 개시된 정확한 형태에 대하여 철저하거나 또는 제한적인 것으로 의도되지 않으며, 수정들 및 변형들이 상기 교시를 고려하여 가능하거나 또는 개시된 구현들의 실시로부터 획득될 수 있다. 본 발명의 범위는 여기에 첨부된 청구항들 및 그것들의 등가물들에 의해 정의된다는 것이 의도된다.

Claims (90)

  1. 복수의 클라이언트 중 제1 클라이언트에 대한 저장 시스템에서의 볼륨의 클라이언트 메트릭들을 결정하는 단계로서, 상기 저장 시스템은 상기 복수의 클라이언트들로부터의 데이터를 저장하는 것인, 클라이언트 메트릭들을 결정하는 단계;
    상기 복수의 클라이언트들에 의한 상기 저장 시스템의 사용에 기초하여 상기 저장 시스템에서 클러스터의 시스템 메트릭들을 결정하는 단계;
    상기 시스템 메트릭들 및 상기 클라이언트 메트릭들에 기초하여 상기 저장 시스템의 로드 값(load value)을 결정하는 단계;
    상기 로드 값이 미리 정의된 임계치 초과임을 결정하는 단계;
    프로세서를 사용하여, 상기 로드 값, 최소 서비스 품질 값, 및 최대 서비스 품질 값에 기초하여 타겟 성능 값을 산출하는 단계; 및
    상기 로드 값이 상기 미리 정의된 임계치 초과임을 결정하는 것 및 상기 타겟 성능 값에 기초하여 상기 클라이언트에 대한 상기 저장 시스템의 성능을 조정하는 단계를 포함하는, 방법.
  2. 청구항 1에 있어서,
    상기 로드 값은 상기 제1 클라이언트와 연관된 둘 이상의 로드 값들에 기초하여 결정되는, 방법.
  3. 청구항 2에 있어서,
    상기 로드 값은 상기 저장 시스템에서의 두 개의 상이한 서버들과 연관된 기록 대기 시간 로드 값들의 최대 값이며, 상기 두 개의 상이한 서버들은 양쪽 모두 상기 제1 클라이언트와 연관되는, 방법.
  4. 청구항 1에 있어서,
    상기 클라이언트 메트릭들에 기초하여 클라이언트-특정 인자를 결정하는 단계를 더 포함하며, 상기 타겟 성능 값은 상기 클라이언트-특정 인자에 기초하는, 방법.
  5. 청구항 4에 있어서,
    상기 로드 값과 연관된 하나 이상의 클라이언트 메트릭들을 결정하는 단계를 더 포함하며, 상기 클라이언트 특정 인자는 상기 로드 값과 연관된 상기 하나 이상의 클라이언트 메트릭들에 기초하는, 방법.
  6. 청구항 5에 있어서,
    상기 로드 값은 서비스의 판독 대기 시간 또는 기록 대기 시간 중 하나에 기초하는, 방법.
  7. 청구항 6에 있어서,
    상기 하나 이상의 클라이언트 메트릭들은 상기 제1 클라이언트와 연관된 다수의 판독 동작들 및 다수의 기록 동작들 중 하나를 포함하는, 방법.
  8. 청구항 7에 있어서,
    상기 클라이언트 특정 인자는 상기 클러스터의 상기 판독 동작들의 총 수 또는 상기 기록 동작들의 총 수에 의해 나뉘어진 상기 제1 클라이언트와 연관된 상기 판독 동작들의 수 또는 상기 기록 동작들의 수의 비로서 산출되는, 방법.
  9. 청구항 8에 있어서,
    클러스터 감소 값을 결정하는 단계를 더 포함하며, 상기 타겟 성능 값은 상기 클라이언트-특정 인자를 상기 클러스터 감소 값에 곱하는 것에 기초하는, 방법.
  10. 청구항 4에 있어서,
    복수의 클래스들로부터 상기 클라이언트의 클래스를 결정하는 단계를 더 포함하며, 상기 클라이언트-특정 인자는 상기 클라이언트의 상기 클래스에 기초하는, 방법.
  11. 청구항 10에 있어서,
    상기 클라이언트의 클래스에 부분적으로 기초하여 클라이언트들에 청구하는 단계를 더 포함하는, 방법.
  12. 청구항 1에 있어서,
    상기 데이터는 상기 저장 시스템에 걸쳐 랜덤하게 및 고르게 분포되는, 방법.
  13. 청구항 12에 있어서,
    상기 데이터는 상기 데이터의 콘텐트들에 기초하여 상기 저장 시스템에 걸쳐 랜덤하고 고르게 분포되는, 방법.
  14. 청구항 1에 있어서,
    성능 곡선에 기초하여 상기 저장 시스템과 연관된 입력/출력 동작들의 입력/출력 데이터 크기에 기초하여 하나 이상의 시스템 메트릭들을 정규화하는 단계; 및
    상기 성능 곡선에 기초하여 상기 제1 클라이언트와 연관된 입력/출력 동작들의 입력/출력 데이터 크기에 기초하여 하나 이상의 클라이언트 메트릭들을 정규화하는 단계를 더 포함하는, 방법.
  15. 컴퓨팅 디바이스에 의해 실행될 때, 상기 컴퓨팅 디바이스가 동작들을 수행하게 하는 지시들을 저장한 비-일시적 컴퓨터-판독 가능한 매체에 있어서,
    상기 동작들은:
    복수의 클라이언트들 중 제1 클라이언트에 대한 저장 시스템에서의 볼륨의 클라이언트 메트릭들을 결정하는 것으로서, 상기 저장 시스템은 상기 복수의 클라이언트들로부터 데이터를 저장하는 것인, 클라이언트 메트릭들을 결정하는 것;
    상기 복수의 클라이언트들에 의한 상기 저장 시스템의 사용에 기초하여 상기 저장 시스템에서 클러스터의 시스템 메트릭들을 결정하는 것;
    상기 시스템 메트릭들 및 상기 클라이언트 메트릭들에 기초하여 상기 저장 시스템의 로드 값을 결정하는 것;
    상기 로드 값이 미리 정의된 임계치 초과임을 결정하는 것;
    상기 로드 값, 최소 서비스 품질 값, 및 최대 서비스 품질 값에 기초하여 타겟 성능 값을 산출하는 것; 및
    상기 로드 값이 상기 미리 정의된 임계치 초과임을 결정하는 것 및 상기 타겟 성능 값에 기초하여 상기 클라이언트에 대한 상기 저장 시스템의 성능을 조정하는 것을 포함하는, 비-일시적 컴퓨터-판독 가능한 매체.
  16. 청구항 15에 있어서,
    상기 로드 값은 상기 제1 클라이언트와 연관된 둘 이상의 로드 값들에 기초하여 결정되는, 비-일시적 컴퓨터-판독 가능한 매체.
  17. 청구항 16에 있어서,
    상기 로드 값은 두 개의 상이한 서버들과 연관된 기록 대기 시간 로드 값들의 최대 값이며, 상기 두 개의 상이한 서버들은 양쪽 모두 상기 제1 클라이언트와 연관되는, 비-일시적 컴퓨터-판독 가능한 매체.
  18. 청구항 15에 있어서,
    상기 동작들은 상기 클라이언트 메트릭들에 기초하여 클라이언트-특정 인자를 결정하는 것을 더 포함하며, 상기 타겟 성능 값은 상기 클라이언트-특정 인자에 기초하는, 비-일시적 컴퓨터-판독 가능한 매체.
  19. 청구항 18에 있어서,
    상기 동작들은:
    상기 로드 값과 연관된 하나 이상의 클라이언트 메트릭들을 결정하는 것을 더 포함하며, 상기 클라이언트 특정 인자는 상기 로드 값과 연관된 상기 하나 이상의 클라이언트 메트릭들에 기초하는, 비-일시적 컴퓨터-판독 가능한 매체.
  20. 청구항 19에 있어서,
    상기 로드 값은 서비스의 판독 대기 시간 또는 기록 대기 시간 중 하나에 기초하는, 비-일시적 컴퓨터-판독 가능한 매체.
  21. 청구항 20에 있어서,
    상기 하나 이상의 클라이언트 메트릭들은 상기 제1 클라이언트와 연관된 다수의 판독 동작들 및 다수의 기록 동작들 중 하나를 포함하는, 비-일시적 컴퓨터-판독 가능한 매체.
  22. 청구항 21에 있어서,
    상기 클라이언트 특정 인자는 상기 클러스터의 상기 판독 동작들의 총 수 또는 상기 기록 동작들의 총 수에 의해 나뉘어진 상기 제1 클라이언트와 연관된 상기 판독 동작들의 수 또는 상기 기록 동작들의 수의 비로서 산출되는, 비-일시적 컴퓨터-판독 가능한 매체.
  23. 청구항 22에 있어서,
    상기 동작들은:
    클러스터 감소 값을 결정하는 것을 더 포함하며, 상기 타겟 성능 값은 상기 클라이언트-특정 인자를 상기 클러스터 감소 값에 곱하는 것에 기초하는, 비-일시적 컴퓨터-판독 가능한 매체.
  24. 청구항 18에 있어서,
    상기 동작들은 복수의 클래스들로부터 상기 클라이언트의 클래스를 결정하는 것을 더 포함하며, 상기 클라이언트-특정 인자는 상기 클라이언트의 상기 클래스에 기초하는, 비-일시적 컴퓨터-판독 가능한 매체.
  25. 청구항 24에 있어서,
    상기 동작들은 상기 클라이언트의 상기 클래스에 부분적으로 기초하여 클라이언트들에 청구하는 것을 더 포함하는, 비-일시적 컴퓨터-판독 가능한 매체.
  26. 청구항 15에 있어서,
    상기 데이터는 상기 저장 시스템에 걸쳐 랜덤하게 및 고르게 분포되는, 비-일시적 컴퓨터-판독 가능한 매체.
  27. 청구항 26에 있어서,
    상기 데이터는 상기 데이터의 콘텐트들에 기초하여 상기 저장 시스템에 걸쳐 랜덤하게 및 고르게 분포되는, 비-일시적 컴퓨터-판독 가능한 매체.
  28. 청구항 15에 있어서,
    상기 동작들은:
    성능 곡선에 기초하여 상기 저장 시스템과 연관된 입력/출력 동작들의 입력/출력 데이터 크기에 기초하여 하나 이상의 시스템 메트릭들을 정규화하는 것; 및
    상기 성능 곡선에 기초하여 상기 제1 클라이언트와 연관된 입력/출력 동작들의 입력/출력 데이터 크기에 기초하여 하나 이상의 클라이언트 메트릭들을 정규화하는 것을 더 포함하는, 비-일시적 컴퓨터-판독 가능한 매체.
  29. 하나 이상의 프로세서를 포함하는 시스템에 있어서,
    상기 하나 이상의 프로세서는:
    복수의 클라이언트들 중 제1 클라이언트에 대한, 상기 복수의 클라이언트들로부터의 데이터를 저장하는 저장 시스템에서의 볼륨의 클라이언트 메트릭들을 결정하도록;
    상기 복수의 클라이언트들에 의한 상기 저장 시스템의 사용에 기초하여 상기 저장 시스템에서의 클러스터의 시스템 메트릭들을 결정하도록;
    상기 시스템 메트릭들 및 상기 클라이언트 메트릭들에 기초하여 상기 저장 시스템의 로드 값을 결정하도록;
    상기 로드 값이 미리 정의된 임계치 초과임을 결정하도록;
    상기 로드 값, 최소 서비스 품질 값, 및 최대 서비스 품질 값에 기초하여 타겟 성능 값을 산출하도록;
    상기 로드 값이 상기 미리 정의된 임계치 초과임을 결정하는 것 및 상기 타겟 성능 값에 기초하여 상기 클라이언트에 대한 상기 저장 시스템의 성능을 조정하도록 구성된, 시스템.
  30. 청구항 29에 있어서,
    상기 로드 값은 상기 제1 클라이언트와 연관된 둘 이상의 로드 값들에 기초하여 결정되는, 시스템.
  31. 청구항 30에 있어서,
    상기 로드 값은 두 개의 상이한 서버들과 연관된 기록 대기 시간 로드 값들의 최대 값이며, 상기 두 개의 상이한 서버들은 양쪽 모두 상기 제1 클라이언트와 연관되는, 시스템.
  32. 청구항 29에 있어서,
    상기 하나 이상의 프로세서들은 상기 클라이언트 메트릭들에 기초하여 클라이언트-특정 인자를 결정하도록 추가로 구성되며, 상기 타겟 성능 값은 상기 클라이언트-특정 인자에 기초하는, 시스템.
  33. 청구항 32에 있어서,
    상기 하나 이상의 프로세서들은 :
    상기 로드 값과 연관된 하나 이상의 클라이언트 메트릭들을 결정하도록 추가로 구성되며, 상기 클라이언트 특정 인자는 상기 로드 값과 연관된 상기 하나 이상의 클라이언트 메트릭들에 기초하는, 시스템.
  34. 청구항 33에 있어서,
    상기 로드 값은 서비스의 판독 대기 시간 또는 기록 대기 시간 중 하나에 기초하는, 시스템.
  35. 청구항 34에 있어서,
    상기 하나 이상의 클라이언트 메트릭들은 상기 제1 클라이언트와 연관된 다수의 판독 동작들 및 다수의 기록 동작들 중 하나를 포함하는, 시스템.
  36. 청구항 35에 있어서,
    상기 클라이언트 특정 인자는 상기 클러스터의 상기 판독 동작들의 총 수 또는 상기 기록 동작들의 총 수에 의해 나뉘어진 상기 제1 클라이언트와 연관된 상기 판독 동작들의 수 또는 상기 기록 동작들의 수의 비로서 산출되는, 시스템.
  37. 청구항 32에 있어서,
    상기 하나 이상의 프로세서들은 클러스터 감소 값을 결정하도록 추가로 구성되며, 상기 타겟 성능 값은 상기 클라이언트-특정 인자를 상기 클러스터 감소 값에 곱하는 것에 기초하는, 시스템.
  38. 청구항 37에 있어서,
    상기 하나 이상의 프로세서들은 복수의 클래스들로부터 상기 클라이언트의 클래스를 결정하도록 추가로 구성되며, 상기 클라이언트-특정 인자는 상기 클라이언트의 상기 클래스에 기초하는, 시스템.
  39. 청구항 38에 있어서,
    상기 하나 이상의 프로세서들은 상기 클라이언트의 상기 클래스에 부분적으로 기초하여 클라이언트들에 청구하도록 추가로 구성되는, 시스템.
  40. 청구항 29에 있어서,
    상기 데이터는 상기 저장 시스템에 걸쳐 랜덤하게 및 고르게 분포되는, 시스템.
  41. 청구항 40에 있어서,
    상기 데이터는 상기 데이터의 콘텐트들에 기초하여 상기 저장 시스템에 걸쳐 랜덤하게 및 고르게 분포되는, 시스템.
  42. 청구항 29에 있어서,
    상기 하나 이상의 프로세서들은 :
    성능 곡선에 기초하여 상기 저장 시스템과 연관된 입력/출력 동작들의 입력/출력 데이터 크기에 기초하여 하나 이상의 시스템 메트릭들을 정규화하고,
    상기 성능 곡선에 기초하여 상기 제1 클라이언트와 연관된 입력/출력 동작들의 입력/출력 데이터 크기에 기초하여 하나 이상의 클라이언트 메트릭들을 정규화하도록 추가로 구성되는, 시스템.
  43. 복수의 데이터 볼륨들에 대한 데이터를 저장하는 저장 시스템에서 성능을 관리하기 위한 방법으로서, 개개의 데이터 볼륨이 연관된 클라이언트를 갖는 것인, 저장 시스템에서 성능을 관리하기 위한 방법에 있어서,
    개개의 데이터 볼륨에 대한 사용의 성능 클래스의 선택을 수신하는 단계로서, 상기 사용의 성능 클래스는 사용의 적어도 하나의 성능 클래스가 상이한 초당 입력 출력(IOPS : Input Output Per Second) 서비스 품질 파라미터를 갖는 복수의 성능 클래스들로부터 선택되는 것인, 선택 수신 단계; 및
    상기 선택된 사용의 성능 클래스의 상기 IOPS 서비스 품질 파라미터에 기초하여 상기 개개의 데이터 볼륨에 대한 액세스를 관리하는 단계를 포함하는, 저장 시스템에서 성능을 관리하기 위한 방법.
  44. 청구항 43에 있어서,
    상기 사용의 성능 클래스의 상기 선택과는 별도로 상기 개개의 데이터 볼륨의 크기의 선택을 수신하는 단계를 더 포함하는, 방법.
  45. 청구항 43에 있어서,
    사용의 적어도 하나의 성능 클래스는 연관된 최소 IOPS, 최대 IOPS, 및 버스트 IOPS 중 적어도 하나를 갖는, 방법.
  46. 청구항 43에 있어서,
    상기 선택은 API를 통해 수신되는, 방법.
  47. 청구항 43에 있어서,
    상기 액세스를 관리하는 단계는 상기 IOPS 서비스 품질 파라미터에 적어도 부분적으로 기초하여 보장된 서비스 품질을 제공하는 단계를 포함하는, 방법.
  48. 복수의 데이터 볼륨들에 대한 데이터를 저장하는 저장 시스템에서 성능을 관리하기 위한 방법으로서, 개개의 데이터 볼륨이 연관된 클라이언트를 갖는 것인, 저장 시스템에서 성능을 관리하기 위한 방법에 있어서,
    클라이언트의 개개의 볼륨에 대한 초당 입력 출력(IOPS) 서비스 품질 파라미터를 연관시키는 단계; 및
    상기 IOPS 서비스 품질 파라미터에 적어도 부분적으로 기초하여 조절된 액세스를 가지고 상기 개개의 볼륨에 대한 상기 액세스를 제공하는 단계를 포함하는, 방법.
  49. 청구항 48에 있어서,
    상기 제공 단계는 상기 IOPS 서비스 품질 파라미터에 적어도 부분적으로 기초하여 성능을 보장하는 단계를 포함하는, 방법.
  50. 청구항 48에 있어서,
    개개의 볼륨은 적어도 하나의 데이터 블록을 갖는, 방법.
  51. 청구항 48에 있어서,
    상기 저장 시스템은 고체 상태 디바이스 저장 유닛들을 포함하는, 방법.
  52. 프로세서를 사용하여, 클라이언트에 대한 저장 시스템에 저장된 데이터의 액세스와 연관된 로드 값을 결정하는 단계로서, 상기 데이터는 복수의 블록들로 나뉘고, 상기 복수의 블록들은 상기 저장 시스템의 복수의 노드들에 걸쳐 실질적으로 고르게 저장되며, 상기 저장 시스템은 복수의 클라이언트들로부터의 데이터를 포함하는 것인, 로드 값 결정 단계;
    상기 클라이언트로부터 요청된 서비스 품질 파라미터를 수신하는 단계;
    상기 요청된 서비스 품질 파라미터에 따라 상기 데이터의 액세스를 모니터링하는 단계; 및
    상기 데이터의 액세스를 모니터링하는 것에 기초하여 상기 데이터에 대한 액세스를 스로틀링(throttling)하는 단계를 포함하는, 방법.
  53. 프로세서를 사용하여, 클라이언트에 대한 저장 시스템에 저장된 데이터의 액세스와 연관된 초당 입력/출력 동작들(IOPS) 메트릭을 결정하는 단계로서, 상기 데이터는 복수의 블록들로 나뉘고, 상기 복수의 블록들은 상기 저장 시스템의 복수의 노드들에 걸쳐 실질적으로 고르게 저장되며, 상기 저장 시스템은 복수의 클라이언트들로부터의 데이터를 포함하는 것인, IOPS 메트릭 결정 단계;
    요청된 IOPS 값을 수신하는 단계; 및
    상기 요청된 IOPS 값에 기초하여 상기 데이터에 대한 액세스를 조절하는 단계를 포함하는, 방법.
  54. 메모리 또는 프로세싱 디바이스 중 적어도 하나에 구현된 타겟 성능 관리기로서, 저장 시스템 볼륨과 연관된 시스템 메트릭들 및 상기 저장 시스템 볼륨을 액세스하는 컴퓨팅 디바이스와 연관된 클라이언트 메트릭들을 수신하도록 구성되고, 상기 시스템 메트릭들 및 상기 클라이언트 메트릭들에 적어도 부분적으로 기초하여 타겟 성능 값을 산출하도록 구성되는, 상기 타겟 성능 관리기; 및
    상기 타겟 성능 관리기에 작동적으로 결합된 성능 제어기로서, 상기 저장 시스템을 액세스하는 상기 컴퓨팅 디바이스의 성능이 상기 타겟 성능 관리기로부터 상기 타겟 성능 값을 수신하는 것에 응답하여 상기 타겟 성능 값에 제한되도록 제어 신호를 전송하도록 구성되는, 상기 성능 제어기를 포함하는, 장치.
  55. 지시들을 표현한 코드를 저장한 비-일시적 프로세서-판독 가능한 매체에 있어서,
    상기 지시들은 프로세서로 하여금:
    저장 시스템 볼륨을 액세스하는 컴퓨팅 디바이스와 연관된 최소 성능 서비스 품질 파라미터를 수신하게 하고;
    상기 저장 시스템 볼륨과 연관된 시스템 메트릭들을 수신하게 하고;
    상기 최소 성능 서비스 품질 메트릭들 및 상기 시스템 메트릭들에 기초하여 상기 컴퓨팅 디바이스와 연관된 타겟 성능 값을 계산하게 하며;
    상기 타겟 성능 값이 상기 최소 성능 서비스 품질 메트릭들을 만족할 때 상기 타겟 성능 값을 제어기 모듈에 전송하여 상기 제어기 모듈이 상기 저장 시스템 볼륨을 액세스하는 상기 컴퓨팅 디바이스의 성능을 상기 타겟 성능 값으로 제한하게 하는, 비-일시적 프로세서-판독 가능한 매체.
  56. 방법에 있어서,
    저장 시스템에 대한 용량의 총 양을 결정하는 단계로서, 상기 용량은 서비스 품질 파라미터에 의해 정의되는 것인, 용량의 총 양을 결정하는 단계;
    상기 저장 시스템을 액세스하기 위해 복수의 클라이언트들에 대해 프로비전되는 상기 서비스 품질 파라미터의 복수의 값들을 수신하는 단계로서, 상기 복수의 클라이언트들의 각각의 클라이언트는 상기 서비스 품질 파라미터의 값을 프로비전받는 것인, 수신 단계;
    상기 저장 시스템에서 상기 복수의 클라이언트들에 대해 프로비전되는 상기 복수의 값들을 모니터링하는 단계;
    상기 복수의 값들이 임계치를 위반하는지를 결정하는 단계로서, 상기 임계치는 상기 저장 시스템에 대한 상기 용량의 총 양에 기초하는 것인, 결정 단계; 및
    하나 이상의 클라이언트들에 대한 상기 서비스 품질 파라미터의 값 또는 상기 저장 시스템에 대한 상기 용량의 총 양에서의 조정이 수행되어야 함을 표시하기 위해 상기 복수의 값들이 상기 임계치를 위반할 때 신호를 자동으로 출력하는 단계를 포함하는, 방법.
  57. 청구항 56에 있어서,
    상기 신호를 출력하는 단계는 상기 복수의 값들이 상기 임계치를 위반함을 표시하는 통지를 출력하는 단계를 포함하는, 방법.
  58. 청구항 56에 있어서,
    상기 복수의 값들이 상기 임계치를 위반하는지를 결정하는 단계는:
    상기 복수의 값들의 총 값을 상기 임계치에 비교하는 단계; 및
    상기 총 값이 상기 임계치를 위반하는지를 결정하는 단계를 포함하는, 방법.
  59. 청구항 58에 있어서,
    상기 총 값은 상기 복수의 클라이언트들에 대해 보장되는 상기 서비스 품질 파라미터의 값들에 기초하는, 방법.
  60. 청구항 58에 있어서,
    상기 복수의 값들은 최대 양, 최소 양, 및 상기 최대 양을 초과하는 버스트 양을 포함하며, 상기 총 값은 상기 최대 양, 상기 최소 양, 및 상기 버스트 양 중 적어도 하나에 기초하는, 방법.
  61. 청구항 60에 있어서,
    상기 총 값은 상기 복수의 클라이언트들에 대해 프로비전되는 최소 양들의 누적 양(accumulation)인, 방법.
  62. 청구항 56에 있어서,
    상기 임계치는 상기 총 양 또는 상기 총 양 미만의 미리-정의된 임계치인, 방법.
  63. 청구항 56에 있어서,
    상기 임계치가 상기 총 양의 상기 조정에 기초하여 변경되도록 상기 신호의 상기 출력에 기초하여 상기 용량의 총 양을 조정하는 단계를 더 포함하는, 방법.
  64. 청구항 56에 있어서,
    상기 복수의 값들이 더 이상 상기 임계치를 초과하지 않도록 상기 복수의 값들의 일부를 조정하는 단계를 더 포함하는, 방법.
  65. 청구항 56에 있어서,
    상기 신호는 상기 복수의 클라이언트들에 의한 상기 저장 시스템의 액세스에 기초하여 상기 저장 시스템의 로드에 관계없이 출력되는, 방법.
  66. 청구항 56에 있어서,
    상기 저장 시스템은 고체 상태 드라이브들을 포함하는, 방법.
  67. 청구항 56에 있어서,
    상기 저장 시스템에서의 드라이브들에 걸친 로드는 상기 저장 시스템의 드라이브들에 걸쳐 실질적으로 고르게 분포된 복수의 볼륨들에 대한 상기 데이터로 인해 실질적으로 고른, 방법.
  68. 청구항 56에 있어서,
    상기 신호를 출력하는 단계는 실제 용량이 상기 용량의 총 양에 도달할 때 수행되는, 방법.
  69. 저장 시스템을 액세스하기 위해 서비스 품질 파라미터들을 복수의 클라이언트들에 프로비전하는 단계;
    상기 복수의 클라이언트들에 의한 상기 저장 시스템의 액세스를 모니터링하는 단계;
    상기 저장 시스템을 액세스할 때 상기 복수의 클라이언트들에서 클라이언트의 성능을 모니터링하는 단계로서, 상기 저장 시스템을 액세스할 때 상기 클라이언트의 성능은 상기 클라이언트가 프로비전된 상기 서비스 품질 파라미터들에 기초하여 제어되는 것인, 클라이언트의 성능을 모니터링하는 단계;
    상기 클라이언트에 대한 타겟 성능 값을 결정하기 위해 상기 복수의 클라이언트들에 의한 상기 저장 시스템의 상기 액세스 및 상기 클라이언트의 상기 성능을 분석하는 단계; 및
    상기 서비스 품질 파라미터들에 기초하여 상기 클라이언트의 상기 성능을 조정하기 위해 상기 저장 시스템을 액세스할 때 상기 클라이언트의 제어를 동적으로 조정하는 단계를 포함하는, 방법.
  70. 청구항 69에 있어서,
    제어를 동적으로 조정하는 단계는 상기 타겟 성능 값에 기초하여 상기 클라이언트를 위한 상기 저장 시스템에 대한 액세스를 제한하거나 또는 증가시키는 단계를 포함하는, 방법.
  71. 청구항 70에 있어서,
    액세스를 제한하거나 또는 증가시키는 단계는 상기 클라이언트가 일정 기간 동안 액세스 명령어들을 수행하도록 허용된 록아웃 시간(lockout time)을 조정하는 단계를 포함하는, 방법.
  72. 청구항 69에 있어서,
    상기 저장 시스템의 액세스를 모니터링하는 단계는 상기 저장 시스템의 로드를 결정하는 단계를 포함하며, 상기 타겟 성능 값은 상기 클라이언트의 상기 로드 및 상기 성능에 기초하여 결정되는, 방법.
  73. 청구항 69에 있어서,
    상기 서비스 품질 파라미터들은 최대 양, 최소 양, 및 상기 최대 양 초과의 버스트 양을 포함하는, 방법.
  74. 청구항 73에 있어서,
    상기 버스트 양은 상기 클라이언트의 성능이 상기 최대 양 미만일 때 증가되며, 상기 타겟 성능 값은 상기 버스트 양이 양(positive)일 때 상기 최대 양을 초과하도록 허용되는, 방법.
  75. 청구항 73에 있어서,
    상기 성능을 분석하는 단계는:
    상기 최대 양, 상기 최소 양, 및 상기 버스트 양을 수신하는 단계;
    상기 복수의 클라이언트들에 의한 상기 저장 시스템의 상기 로드를 수량화하는 시스템 로드 값을 수신하는 단계;
    상기 클라이언트의 상기 성능에 대한 클라이언트 로드 값을 수신하는 단계; 및
    상기 최대 양, 상기 최소 양, 상기 버스트 양, 상기 시스템 로드, 및 상기 클라이언트 로드에 기초하여 상기 타겟 성능 값을 결정하는 단계를 포함하는, 방법.
  76. 청구항 75에 있어서,
    상기 성능을 분석하는 단계는:
    상기 시스템 로드를 결정하는 단계;
    상기 클라이언트 로드를 결정하는 단계; 및
    성능 조정 값을 결정하는 단계로서, 상기 클라이언트의 제어는 상기 성능 조정 값에 기초하여 조정되는 것인, 성능 조정 값 결정 단계를 포함하는, 방법.
  77. 청구항 73에 있어서,
    상기 타겟 성능 값은 상기 클라이언트가 상기 버스트 양에 대해 상기 최대 양 초과의 성능을 갖도록 허용되는 경우 외에는 상기 최소 양 및 상기 최대 양 내에 있는 것으로 보장되는, 방법.
  78. 청구항 69에 있어서,
    클라이언트의 성능을 모니터링하는 단계는 초당 입력/출력 동작들 메트릭, 대역폭 메트릭, 또는 대기 시간 메트릭을 모니터링하는 단계를 포함하는, 방법.
  79. 청구항 69에 있어서,
    상기 저장 시스템은 고체 상태 드라이브들을 포함하는, 방법.
  80. 청구항 69에 있어서,
    상기 저장 시스템에 걸친 로드는 상기 저장 시스템에 걸쳐 실질적으로 고르게 분포되는 상기 복수의 클라이언트들을 위한 복수의 볼륨들에 대한 상기 데이터로 인해 실질적으로 고른, 방법.
  81. 저장 시스템을 액세스하기 위한 서비스 품질 파라미터들을 복수의 클라이언트들에 프로비전하는 단계;
    상기 저장 시스템을 액세스할 때 상기 복수의 클라이언트들에서 클라이언트의 성능을 모니터링하는 단계로서, 상기 저장 시스템을 액세스할 때 상기 클라이언트의 성능은 상기 클라이언트가 상기 복수의 클라이언트들의 다른 클라이언트들에 대해 프로비전된 서비스 품질 파라미터들에 상관없이 프로비전되는 상기 서비스 품질 파라미터들에 기초하여 독립적으로 제어되는 것인, 클라이언트의 성능을 모니터링하는 단계;
    상기 클라이언트에 의한 상기 저장 시스템의 사용 및 상기 서비스 품질 파라미터들에 기초하여 상기 클라이언트에 대한 로드 값을 산출하는 단계;
    상기 성능 및 상기 로드 값 사이에서의 차이를 결정하기 위해 상기 클라이언트에 대한 상기 서비스 품질 파라미터들에 대하여 상기 클라이언트의 상기 성능을 분석하는 단계; 및
    상기 성능 및 상기 로드 값 사이에서의 상기 차이에 기초하여 상기 클라이언트의 상기 성능의 제어를 독립적으로 조정하기 위해 상기 저장 시스템의 리소스(resource)들에 대한 액세스를 동적으로 할당하는 단계를 포함하는, 방법.
  82. 청구항 81에 있어서,
    리소스들에 대한 액세스를 동적으로 할당하는 단계는 상기 성능 및 상기 로드 값 사이에서의 상기 차이에 기초하여 상기 클라이언트를 위한 상기 저장 시스템에 대한 액세스를 제한하거나 또는 증가시키는 단계를 포함하는, 방법.
  83. 청구항 82에 있어서,
    액세스를 제한하거나 또는 증가시키는 단계는 일정 기간 동안 상기 클라이언트가 액세스 명령어들을 수행하도록 허용된 록아웃 시간을 조정하는 단계를 포함하는, 방법.
  84. 청구항 81에 있어서,
    상기 서비스 품질 파라미터들은 최대 양, 최소 양, 및 상기 최대 양 초과의 버스트 양을 포함하는, 방법.
  85. 청구항 84에 있어서,
    상기 버스트 양은 상기 클라이언트의 상기 로드가 상기 최대 양 미만일 때 증가되며, 상기 리소스들에 대한 액세스는 상기 버스트 양이 양(positive)일 때 상기 저장 시스템에 대한 액세스가 상기 최대 양을 초과하도록 허용하기 위해 증가되는, 방법.
  86. 청구항 81에 있어서,
    상기 로드는 초당 입력/출력 동작들 메트릭, 대역폭 메트릭, 또는 대기 시간 메트릭에 기초하는, 방법.
  87. 청구항 81에 있어서,
    상기 저장 시스템은 고체 상태 드라이브들을 포함하는, 방법.
  88. 청구항 81에 있어서,
    상기 저장 시스템에 걸친 로드는 상기 저장 시스템에 걸쳐 실질적으로 고르게 분포되는 상기 복수의 클라이언트들을 위한 복수의 볼륨들에 대한 상기 데이터로 인해 실질적으로 고른, 방법.
  89. 서버 시스템 내에서의 데이터에 대한 클라이언트 액세스를 조정하기 위한 시스템에 있어서,
    상기 클라이언트와 통신하는 볼륨 서버로서, 데이터를 액세스하기 위해 상기 클라이언트로부터 요청을 수신하는, 상기 볼륨 서버; 및
    메트릭들을 모니터링하는 성능 관리기로서, 타겟 값에 대비하여 상기 메트릭들을 비교하는 것에 응답하여 상기 데이터에 대한 상기 클라이언트의 액세스를 조정하는, 상기 성능 관리기를 포함하는, 클라이언트 액세스를 조정하기 위한 시스템.
  90. 서버 시스템 내에서의 데이터에 대한 클라이언트에 의한 액세스를 조정하기 위한 방법에 있어서,
    타겟 값을 수신하는 단계로서, 상기 타겟 값은 타겟 클라이언트 메트릭을 표시하는 것인, 타겟 값 수신 단계;
    상기 서버 시스템 내에서 상기 데이터를 액세스하기 위해 상기 클라이언트에 의한 요청을 수신하는 단계;
    상기 타겟 값에 상기 클라이언트 성능을 비교하는 단계; 및
    상기 타겟 값에 대한 상기 비교에 기초하여, 상기 데이터에 대한 상기 클라이언트의 액세스를 조정하는 단계를 포함하는, 액세스를 조정하기 위한 방법.
KR1020147020329A 2011-12-27 2012-12-27 클라이언트 사용 및 시스템 메트릭들에 기초한 비례 서비스 품질 KR20140107544A (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US13/338,039 2011-12-27
US13/338,039 US9003021B2 (en) 2011-12-27 2011-12-27 Management of storage system access based on client performance and cluser health
US201261697905P 2012-09-07 2012-09-07
US61/697,905 2012-09-07
PCT/US2012/071844 WO2013101947A1 (en) 2011-12-27 2012-12-27 Proportional quality of service based on client usage and system metrics

Publications (1)

Publication Number Publication Date
KR20140107544A true KR20140107544A (ko) 2014-09-04

Family

ID=48698618

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147020329A KR20140107544A (ko) 2011-12-27 2012-12-27 클라이언트 사용 및 시스템 메트릭들에 기초한 비례 서비스 품질

Country Status (4)

Country Link
EP (3) EP3796169A1 (ko)
JP (1) JP6169105B2 (ko)
KR (1) KR20140107544A (ko)
WO (1) WO2013101947A1 (ko)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8819208B2 (en) 2010-03-05 2014-08-26 Solidfire, Inc. Data deletion in a distributed data storage system
JP6179321B2 (ja) 2013-09-27 2017-08-16 富士通株式会社 ストレージ管理装置、制御方法及び制御プログラム
JP6213148B2 (ja) * 2013-10-25 2017-10-18 富士通株式会社 ストレージ装置、ストレージ装置の制御方法およびストレージ装置制御プログラム
US20150244795A1 (en) 2014-02-21 2015-08-27 Solidfire, Inc. Data syncing in a distributed system
JP6273966B2 (ja) * 2014-03-27 2018-02-07 富士通株式会社 ストレージ管理装置、性能調整方法及び性能調整プログラム
JP6394313B2 (ja) 2014-11-19 2018-09-26 富士通株式会社 ストレージ管理装置、ストレージ管理方法及びストレージ管理プログラム
JP6451307B2 (ja) * 2014-12-24 2019-01-16 富士通株式会社 ストレージ装置およびストレージ装置制御プログラム
JP6451308B2 (ja) * 2014-12-24 2019-01-16 富士通株式会社 ストレージ装置およびストレージ装置制御プログラム
JP6558090B2 (ja) * 2015-06-15 2019-08-14 富士通株式会社 ストレージ管理装置、ストレージ管理方法及びストレージ管理プログラム
US10642763B2 (en) 2016-09-20 2020-05-05 Netapp, Inc. Quality of service policy sets
US10855616B2 (en) * 2017-01-11 2020-12-01 Sony Interactive Entertainment LLC Predicting wait time for new session initiation during increased data traffic latency
CN107040591B (zh) * 2017-03-28 2020-06-19 北京小米移动软件有限公司 一种对客户端进行控制的方法及装置
CN110413206B (zh) * 2018-04-28 2023-05-30 伊姆西Ip控股有限责任公司 存储系统中的操作控制方法、设备和计算机程序产品
JP2023505617A (ja) * 2020-02-28 2023-02-09 スリーエム イノベイティブ プロパティズ カンパニー 高度モデル予測制御のための深層因果学習
EP4111379A1 (en) 2020-02-28 2023-01-04 3M Innovative Properties Company Deep causal learning for data storage and processing power management
CN113765686B (zh) * 2020-06-04 2023-07-21 腾讯科技（深圳）有限公司 设备管理方法、装置、业务获取设备及存储介质
JP7001847B1 (ja) 2021-01-06 2022-01-20 株式会社日立製作所 情報処理システムおよびバースティング制御方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020059274A1 (en) * 2000-03-03 2002-05-16 Hartsell Neal D. Systems and methods for configuration of information management systems
US7140016B2 (en) * 2000-11-29 2006-11-21 Texas Instruments Incorporated Media accelerator quality of service
US7167965B2 (en) * 2001-04-30 2007-01-23 Hewlett-Packard Development Company, L.P. Method and system for online data migration on storage systems with performance guarantees
US7519725B2 (en) * 2003-05-23 2009-04-14 International Business Machines Corporation System and method for utilizing informed throttling to guarantee quality of service to I/O streams
US7640231B2 (en) * 2005-11-16 2009-12-29 International Business Machines Corporation Approach based on self-evolving models for performance guarantees in a shared storage system
US7716180B2 (en) * 2005-12-29 2010-05-11 Amazon Technologies, Inc. Distributed storage system with web services client interface
US7739239B1 (en) * 2005-12-29 2010-06-15 Amazon Technologies, Inc. Distributed storage system with support for distinct storage classes
US8380880B2 (en) * 2007-02-02 2013-02-19 The Mathworks, Inc. Scalable architecture
US20090077097A1 (en) * 2007-04-16 2009-03-19 Attune Systems, Inc. File Aggregation in a Switched File System
JP5245934B2 (ja) * 2009-03-11 2013-07-24 富士通株式会社 管理装置の管理プログラム、管理装置、管理装置の管理方法およびストレージシステム
WO2010127365A1 (en) * 2009-05-01 2010-11-04 Citrix Systems, Inc. Systems and methods for establishing a cloud bridge between virtual storage resources
US8335163B2 (en) * 2009-10-27 2012-12-18 Microsoft Corporation Quality of service (QOS) based systems, networks, and advisors
US20110238857A1 (en) * 2010-03-29 2011-09-29 Amazon Technologies, Inc. Committed processing rates for shared resources
US9342801B2 (en) * 2010-03-29 2016-05-17 Amazon Technologies, Inc. Managing committed processing rates for shared resources
JP5471822B2 (ja) * 2010-05-20 2014-04-16 富士通株式会社 入出力制御プログラム、情報処理装置および入出力制御方法

Also Published As

Publication number Publication date
EP2798488B1 (en) 2020-10-14
EP3796169A1 (en) 2021-03-24
JP2015507268A (ja) 2015-03-05
WO2013101947A1 (en) 2013-07-04
EP2798488A4 (en) 2015-08-19
EP3783485A1 (en) 2021-02-24
EP2798488A1 (en) 2014-11-05
JP6169105B2 (ja) 2017-07-26

Similar Documents

Publication Publication Date Title
US10951488B2 (en) Rule-based performance class access management for storage cluster performance guarantees
US11212196B2 (en) Proportional quality of service based on client impact on an overload condition
KR20140107544A (ko) 클라이언트 사용 및 시스템 메트릭들에 기초한 비례 서비스 품질
US10997098B2 (en) Quality of service policy sets
US20130227145A1 (en) Slice server rebalancing
US9003021B2 (en) Management of storage system access based on client performance and cluser health
US9870330B2 (en) Methods and systems for filtering collected QOS data for predicting an expected range for future QOS data
US11106485B2 (en) Modeling space consumption of a migrated VM
US7930481B1 (en) Controlling cached write operations to storage arrays
US10067704B2 (en) Method for optimizing storage configuration for future demand and system thereof
US20150370486A1 (en) Dynamic storage management using virtual storage appliances
US11693563B2 (en) Automated tuning of a quality of service setting for a distributed storage system based on internal monitoring
US7817562B1 (en) Methods and systems for back end characterization using I/O sampling
US20150317556A1 (en) Adaptive quick response controlling system for software defined storage system for improving performance parameter
US20180121237A1 (en) Life cycle management of virtualized storage performance
EP4237945A1 (en) Interruption predictions for cloud compute instances
US10146449B1 (en) Purchase planning for data storage processing systems
US10761726B2 (en) Resource fairness control in distributed storage systems using congestion data

Legal Events

Date Code Title Description
N231 Notification of change of applicant
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid