KR20140136473A

KR20140136473A - 어플리케이션-제어된 서브-lun 수준의 데이터 이동

Info

Publication number: KR20140136473A
Application number: KR1020147027065A
Authority: KR
Inventors: 칼 에반 존스; 가우라브 차운커; 판카즈 바비쉬; 판카즈 옴프라카쉬 칸델왈; 서브호지트 로이
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2012-05-29
Filing date: 2013-05-14
Publication date: 2014-11-28
Also published as: US20130326183A1; WO2013179171A1; JP6270827B2; SG11201404021WA; JP2015519667A; MX2014014163A; US20130326182A1; CN104335188A; US10831390B2; AU2013269206A1; CN104335188B; US10817202B2; MX337317B; KR101730695B1; EP2856322A4; EP2856322A1

Abstract

LUN 배후의(behind the LUN) 물리적 스토리지로부터 새로운 물리적 위치로 명시된 사이즈의 데이터(a specified size of data)를 이동시키기 위해 소스 코드 기반 스펙(a source code-based specification)이 스토리지 컨트롤러와 소유 어플리케이션(an owning application) 사이의 인터페이스로서 사용하기 위해 구현된다.

Description

어플리케이션-제어된 서브-LUN 수준의 데이터 이동{APPLICATION-CONTROLLED SUB-LUN LEVEL DATA MIGRATION}

본 발명은 일반적으로 컴퓨터들과 관련되며, 더 구체적으로는 컴퓨팅 스토리지 환경들에서 스토리지 성능을 향상시키기 위한 방법, 시스템, 및 컴퓨터 프로그램 제품에 관한 것이다.

컴퓨터들 및 컴퓨터 시스템들은 오늘날 사회에서 다양한 시설에서 사용된다. 컴퓨팅 환경들 및 네트워크들은 집에서, 직장에서, 학교에서, 관청에서 그리고 기타 시설들에서 사용될 수 있다. 컴퓨팅 환경들이 하나 또는 그 이상의 스토리지 환경들에 데이터를 저장하는 일이 점점 증가하고 있으며, 이들 스토리지 환경들은 많은 경우에 사용자에게 제공된 로컬 인터페이스로부터 멀리 떨어져 있다.

이들 컴퓨팅 스토리지 환경들은, 디스크 드라이브들과 같은, 많은 스토리지 디바이스들을 사용할 수 있고, 그러한 디바이스들은, 큰 규모의 데이터(a large body of data)를 저장, 검색, 그리고 갱신하기 위해, 종종 동시에 작업을 수행할 수도 있으며, 그 다음, 그러한 데이터는 이를 요청하거나 또는 송신하는 호스트 컴퓨터에 제공될 수 있다. 어떤 경우에, 다수의 데이터 스토리지 서브시스템들이 단일 데이터 스토리지 시스템으로서 집단적으로 관리되기도 한다. 이들 서브시스템들은 여러 프로세싱 유닛들 또는 프로세싱 유닛들의 클러스터들을 결합하는 호스트 "sysplex"(시스템 콤플렉스) 구성들에 의해서 관리될 수도 있다. 이런 방식으로, 다층/다중 시스템 컴퓨팅 환경들(multi-tiered/multi-system computing environments)은, 종종 다양한 형태의 스토리지 디바이스들을 포함하여, 대규모 데이터를 조직하고 처리하기 위해 사용될 수 있다.

데이터 이동(data migration)의 필요는 모든 데이터 센터들에서 현실적으로 존재하며 다양한 이유들 때문에 일어난다. 그러한 데이터 이동은 어플리케이션에 대해서 투명해야(transparent) 한다(즉, 어플리케이션의 가동중단 시간(downtime)이 영이어야 한다). 오늘날, 데이터 이동은 호스트 또는 스토리지 컨트롤러들 상에 설치된 스토리지 가상화 소프트웨어(storage virtualization software)에 의해 제공되는 하나의 특징이다. 현재의 방식에서는, 그러나, 어플리케이션은 스토리지 컨트롤러들에 의해서 지시된(orchestrated) 데이터 이동을 위해 데이터의 어떤 부분들이 새로운 스토리지 위치로 이동되어야 하는지에 대하여 컨트롤을 행사할 수 없다. 호스트 기반의 이동 솔루션들은 어플리케이션들이 데이터의 어떤 부분들이 이동되어야 하는지에 대하여 컨트롤할 수 있게 해주는 범용 인터페이스를 제공하지 않는다. 호스트 기반 이동 솔루션들은 또한 데이터 이동을 실행하기 위해 그들이 호스트로부터 또는 호스트로 데이터를 이동시켜야 하기 때문에 어려움이 있다. 이 컨트롤은 전체 논리 유닛 네임(LUN) 또는, 더 일반적으로 범용 스토리지 유닛 보다는 훨씬 더 미세한 수준에서(at a much more granular level) 데이터 이동을 필요로 할 수 있는 데이터 베이스와 같은 어플리케이션들을 위해서 유익하다. 하지만, 그리고 이후 설명하는 바와 같이, 데이터 이동 결정들은 종종 어플리케이션에 관한 지식 없이 내려진다. 이것은 그러한 데이터 이동의 피크 실행 요건(the peak performance requirement)이 이미 지나버린 후에 이동이 이루어지는 상황들을 초래할 수 있는데, 그 이유는 과중한 워크로드(heavy workload)는 그 성격상 매우 짧은 기간에(spiky in nature) 발생하는 것이라서 오늘날 스토리지 컨트롤러들 내부에서 이용 가능한 표준 감시 메커니즘들에 의해서는 검출될 수 없기 때문이다. 그러므로, 스토리지의 미세한 부분들이, 어플리케이션 요구에 따라, 스토리지 컨트롤러에 의해서 이동될 수 있는 메커니즘에 대한 필요성이 존재한다.

따라서, 그리고 전술한 관점에서, 컴퓨팅 환경 내의 프로세서에 의해서 서브-논리 유닛 네임(LUN) 데이터 이동을 수행하기 위한 다양한 실시 예들이 제공된다. 한 실시 예에서, 오직 예로서, 그러한 서브-LUN 데이터 이동을 위한 방법이 개시된다. 상기 LUN 배후의 물리적 스토리지로부터 새로운 물리적 위치로 명시된 사이즈의 데이터를 이동시키기 위해 스토리지 컨트롤러와 소유 어플리케이션 사이의 인터페이스로서 사용하기 위해 소스 코드-기반의 스펙(a source code-based specification)이 구현된다(implemented).

전술한 예시적 실시 예에 더하여, 다양한 시스템 및 컴퓨터 프로그램 실시 예들이 제공되고 관련 장점들을 제공한다.

본 발명의 장점들을 잘 이해되도록 하기 위해서, 위에서 간단하게 기술한 본 발명의 더 구체적인 설명은 첨부된 도면들에 예시된 특정 실시 예들을 참조하여 제공될 것이다. 이들 도면들은 본 발명의 통상적인 실시 예들을 단지 묘사할 뿐이며, 따라서 본 발명의 범위를 제한하는 것으로 간주되어서는 안 된다는 것을 이해하면서, 본 발명은 아래에 첨부된 도면들의 사용을 통해서 더 구체적으로 더 상세히 기술되고 설명될 것이다:
도 1은 본 발명의 특징들을 구현할 수 있는 예시적 다층 데이터 스토리지 컴퓨팅 환경을 도시하는 블록 다이어그램이다.
도 2는 서브-LUN 수준의 데이터 이동을 수행하기 위한 종래 방법의 블록 다이어그램이다.
도 3은 본 발명의 특징들이 구현될 수 있는 서브-LUN 수준의 데이터 이동을 수행하기 위한 예시적 방법의 블록 다이어그램이다.
도 4는 본 발명의 특징들이 구현될 수 있는, LUN을 위해 가상에서 물리적 매핑으로 변경하기 위한 예시적 방법의 제1단계의 블록 다이어그램이다.
도 5는 본 발명의 특징들이 구현될 수 있는, 도 4에서 이전에 기술한 가상에서 물리적 매핑으로 변경하기 위한 예시적 방법의 제2단계의 블록 다이어그램이다.
도 6은 서브-LUN 수준의 데이터 이동을 수행하기 위한 예시적 방법의 플로 차트 다이어그램이다.
도 7은 서브-LUN 수준의 데이터 이동을 수행하기 위한 추가의 예시적 방법의 플로 차트 다이어그램이다.
도 8도 서브-LUN 수준의 데이터 이동을 수행하기 위한 추가의 예시적 방법의 플로 차트 다이어그램이다.
도 9도 서브-LUN 수준의 데이터 이동을 수행하기 위한 추가의 예시적 방법의 플로 차트 다이어그램이다.
도 10도 서브-LUN 수준의 데이터 이동을 수행하기 위한 추가의 예시적 방법의 플로 차트 다이어그램이다. 그리고
도 11도 서브-LUN 수준의 데이터 이동을 수행하기 위한 추가의 예시적 방법의 플로 차트 다이어그램이다.

전술한 바와 같이, 데이터 이동에 대한 필요는 다양한 이유들 때문에 모든 데이터 센터들에서 실제적으로 존재한다. 그러한 경우들의 예들은: (a) 현재 사용중인 스토리지 어레이의 임대 만료 때문에 한 스토리지 어레이로부터 다른 스토리지 어레이로 데이터를 이동해야 하는 필요; (b) 덜 빈번하게 사용되는 데이터를 하위 층의 스토리지로 이동시킬 필요; 그리고 (c) 조직의 성장 요구조건들을 충족하기 위해 고성능 및 용량 스토리지 어레이로 업그레이드해야 하는 필요를 포함한다. 데이터 이동은 소유 어플리케이션에 대해서, 소유 어플리케이션을 위한 다운타임이 영이 되도록, 투명해야 한다.

다시 말하지만, 전술한 바와 같이, 오늘날 데이터 이동은 호스트에 설치된 스토리지 가상화 소프트웨어에 의해서 제공되는 하나의 특징이며, 이 소프트웨어의 예들에는 Linux® 호환 환경들을 위한 논리 볼륨 관리자(LVM) 및 Veritas® 볼륨 관리자(Volume Manager)가 있고 이들은 스토리지 컨트롤러들(예를 들어, IBM® System Storage DS800 또는 Storwize® V7000), 및 네트워크 스토리지 버추얼라이저들(network storage virtualizers)(예를 들어, IBM® SAN Volume Controller (SVC))를 통해서 도움을 받는다(facilitated). 한 예에서, 만일 사이즈 1TB의 LUN을 위해 데이터를 이동할 필요가 있다면, 전체의 LUN이 현재 사용중인 백엔드 스토리지의 1TB로부터 사이즈 1TB의 새로운 스토리지까지 이동된다. 따라서, 현재의 방식에서, 특정 LUN 상에 저장되는 전체 데이터는 새로운 위치로 이동된다.

현재의 방식에서, 그러나, 어플리케이션은 데이터의 어떤 부분들이 새로운 스토리지 위치로 이동되어야 하는지에 대해서 컨트롤을 행사할 수 없다. 이것은 전체 LUN보다 훨씬 더 미세한 수준에서 데이터를 이동시킬 필요가 있을 수 있는 데이터베이스와 같은 어플리케이션들을 위해 유용하다. 다음의 예를 생각해보자. 소유 어플리케이션이, 이 경우에 데이터베이스(즉, Oracle®)가 주어진 테이블 상의 데이터가 더 이상 빈번하게 액세스되지 않기 때문에 단일의 테이블(또는 레코드)만 현재 스토리지로부터 새로운 스토리지 위치로 이동하기를 원한다고 하자. 어플리케이션에 의해서 컨트롤되는 LUN의 부분 데이터 이동의 이러한 형태는 스토리지 버추얼라이저들(storage virtualizers)에 의해서 제공되는 전통적인 이동 방법들에 의해서는 가능하지 않다.

서브-LUN 수준에서 데이터를 이동하는 것이 가능하더라도, 종래에는 그러한 이동을 착수하는 결정들은 스토리지 컨트롤러 수준에서 데이터 액세스 패턴들의 감시와 분석에 의해서 내려진다. 스토리지 컨트롤러는 데이터의 시맨틱스에 관한 지식을 갖고 있지 않기 때문에, 데이터 이동이, 예를 들어, 피크 실행 요건들(peak performance requirements)이 이미 지났을 때에 시작될 가능성이 있다. 어떤 데이터가 이동되어야 하며 언제 이동되어야 하는지에 대한 가장 빠른 결정들을 내릴 수 있는 해당 층은 데이터를 생성하는 어플리케이션이다. 따라서, 어플리케이션 인지의 문제(the problem of application awareness)와 어플리케이션-기반의 결정 처리(application-based decision making)는 기존의 솔루션들에서는 해결되지 않고 남아있다.

여러 종래의 기술들이 서브-LUN 수준의 데이터 이동의 문제를 풀려고 시도했다. 첫째, 스토리지 컨트롤러들(스토리지 어레이들로서 또한 알려져 있다)은 LUN과 관련된 물리적 스토리지로부터 다른 물리적 스토리지로, 어플리케이션에 대해 투명하게, 데이터를 이동시키는 제한적 능력을 제공한다. 그러나, 그러한 이동은 전체 LUN에 대해서 수행되므로, 따라서 그 프로세스는 어플리케이션이 특정 LUN 상에 저장하고 있는 데이터의 부분들만 이동하기를 요구하는 상황들에서는 부적당하다. 또한, 스토리지 컨트롤러들은 보통으로 동일 벤더와 관련된 디바이스들에 대해서만 데이터 이동을 허용하기 때문에, 벤더 고정화(lock-in)를 조장하여 비용이 비싸지거나 또는 그렇지 않으면 자원 집약적(resource intensive)이 되는 경향이 있다.

둘째, 호스트 상에서 실행되는 스토리지 가상화 소프트웨어는 잠재적으로 디스크 어레이 벤더들을 망라하는(span across) 데이터 이동 사용 케이스들(data migration use cases)을 제공하고, 따라서 벤더 고정화를 조장하지는 않는다. 그러나, 종래의 가상화 소프트웨어는 하나의 물리적 스토리지로부터 다른 물리적 스토리지로 전체 LUN의 데이터를 이동시킨다. 이것은 종래 가상화 소프트웨어는 서브-LUN 수준에서 데이터를 이동시키는 것을 필요로 하는 어플리케이션들에 대해서 도전들을 가져다 준다는 것을 의미한다.

셋째, 재산권 볼륨 관리(proprietary volume management) 및 파일 시스템 소프트웨어(예를 들어, 데이터 베이스 파일들에 대한)는 여러 다른 물리적 스토리지들에 걸쳐(across differing physical storages) 서브-LUN 수준의 데이터 이동을 하게한다. 그러나, 그러한 데이터 이동은 호스트에 대해서 동시에 사용되는 물리적 스토리지로부터 데이터를 읽어서 그 호스트로부터 데이터를 새로운 스토리지에 기록하는 것이 필요하다. 이 프로세스는 데이터 이동을 위한 스토리지 네트워크의 대역폭(bandwidth)과 호스트 상의 중앙 처리 장치(CPU)의 대역폭 모두를 소비하며, 이는 스토리지 네트워크 및/또는 서버 성능의 하락을 초래한다. 또한 그러한 재산권 소프트웨어는 특정 벤더-기반 구현에 대해 벤더 특정(vendor-specific)이다.

전술한 기술들과는 대조적으로, 도시된 실시 예들의 메커니즘들은 스토리지 가상화 소프트웨어(storage virtualization software)에 의해서 노출된(exposed) 어플리케이션 프로그래밍 인터페이스들(APIs)이 어플리케이션으로 하여금 서브-LUN 수준에서 현재 물리적 스토리지로부터 새로운 위치로 데이터 이동을 시작할 수 있도록 해주는 기술들을 설명한다. 이들 메커니즘들을 사용하면, 어플리케이션은 데이터가 이동되어야 하는 물리적 스토리지를 식별하기 위하여 가상 디스크 상의 데이터 조각의 시작 LBA(Logical Block Address) 및 사이즈와 타겟 물리적 스토리지 디스크립션(a target physical storage description)을 명시할 수 있다. 이러한 API 콜을 수신하면, 스토리지 가상화 소프트웨어는 현재의 스토리지 위치로부터 명시된 타겟 스토리지 위치로 데이터를 어플리케이션으로부터 투명하게 이동시킬 수 있다. 이 동작이 완료되고 나면, 스토리지 상의 가상 디스크 맵은 원자적으로(atomically) 수정되어 그 데이터의 새로운 위치를 가리킨다. 과거 물리적 데이터 스토리지 위치는 해제된다(freed). 이러한 API는 새로운 SCSI 명령의 형식으로 또는 XCOPY와 같은 기존의 SCSI 명령들의 사용으로 표시될 수 있다. 또한 API의 다른 아웃-오브-밴드 표시들(other out-of-band manifestations)도 가능하다.

예시된 실시 예들의 메커니즘들은 다음과 같은 여러 장점들을 제공한다. 첫째, 스토리지 가상화 소프트웨어에 의해서 노출된 서브-LUN 수준의 이동 API는 어플리케이션들이 한 물리적 스토리지로부터 다른 물리적 스토리지로 LUN 내의 데이터의 일부분들을 이동시킬 수 있게 해준다. 이것은 어플리케이션들이 필요에 따라서 개별 레코드들, 테이블들 또는 테이블 공간들을 새로운 물리적 스토리지로 이동시킬 수 있게 해준다. 그 결과, 덜 빈번하게 액세스되는 테이블들/레코드들은 덜 비싼 스토리지를 소비하는 하위 층 스토리지(lower tier storage)로 이동되게 할 수 있거나 또는 매우 빈번하게 액세스되는 데이터는 고위 IOPs 요건들(higher IOPs requirements)을 만족시킬 수 있는 고위 층의 스토리지(a higher tier of storage)로 이동되게 할 수 있다.

둘째. 다양한 재산권 볼륨 컨트롤러들(various proprietary volume controllers)과 같은, 스토리지 영역 네트워크(SAN) 내의 스토리지 버추얼라이저들에 의해서 노출된 서브-LUN 수준의 이동 API들은 호스트에 대해 전체 데이터를 읽고 그 다음 새로운 스토리지로 기록할 필요가 없이 한 물리적 스토리지로부터 다른 물리적 스토리지로 데이터의 이동을 할 수 있게 해준다. 이것은 스토리지 네트워크 대역폭을 보호하고(preserve) 데이터 이동을 실행할 호스트 CPU 사이클들의 사용을 예방한다(prevent).

셋째, 서브-LUN 수준의 이동은 사용 케이스에 따라서(depending on the use case) 특정 LUN 상의 데이터의 어떤 부분들이 다른 물리적 스토리지로 이동되어야 하는지를 결정하도록 어플리케이션에 컨트롤을 제공한다. 어플리케이션은 자신의 데이터와 관련된 시맨틱스에 관하여 완전한 지식을 가지고 있기 때문에, 어떤 데이터가 언제 이동해야 하는지에 관하여 가장 빠르게 최선의 결정들을 내릴 수 있다.

넷째, 스토리지 컨트롤러들에 의해서 제공된 서브-LUN 수준의 이동은 다양한 벤더들로부터의 어플리케이션들에도 유익할 수 있다. 호스트 상에서 실행되는 기타 어플리케이션들도 또한 그러한 API로부터 유익을 얻을 수 있다. 끝으로, 스토리지 가상화 소프트웨어에 의해서 제공된 서브-LUN 수준의 이동은 데이터가 배치된 스토리지의 성능과 비용에 기초하여 여러 다른 종류의 스토리지에 데이터를 저장하여야 할 현재의 필요들에 즉각적으로 반응하도록 어플리케이션의 능력을 향상시킬 수 있다. 만일 스토리지 가상화 소프트웨어가 “핫스팟(hotspot)” 이동에 관한 결정을 내리기 위해서 데이터 액세스 패턴들을 감시해야 한다면, 이동의 유익은 지연되어 나타날 것이다(felt only after a delay) (아마도 더 높은 성능(higher performance)에 대한 필요가 사라진 시점에서).

다음 설명에서, 첨부된 도면들이 참조되고, 도면들은 본 발명의 일 부분을 형성하며 여러 실시 예들을 도시한다. 다른 실시 예들도 이용될 수 있으며 본 발명의 범위를 벗어남이 없이 구조적 및 동작적 변경들이 만들어질 수 있음을 이해하여야 한다. 도 1은 본 발명의 특징들이 구현될 수 있는 컴퓨팅 스토리지 환경을 도시한다. 복수의 호스트 시스템들(2a, b...n)은 입력/출력(I/O) 요청들을 하나 또는 그 이상의 스토리지 볼륨들(28, 30 및 32)에 전송하는데 스토리지 볼륨들(26, 30 및 32)에 대한 액세스를 관리하는 스토리지 컨트롤러(6)을 통해서 한다. 특정 구현들에서, 스토리지 볼륨들은 물리적으로 디스크들 다발 (JBOD), RAID어레이, 직접 액세스 스토리지 디바이스들(DASD), SSD, 테이프 디바이스들, 등으로 구성된 복수의 하드 디스크 드라이브들로 구성될 수 있다.

다수의 가상 볼륨들(22, 24, 및 26)이 다수의 물리적 또는 논리적 볼륨들을 제공하는 대신에 호스트 시스템들(2a, b...n)에 제공된다(종종 이들은 물리적으로 복합적 관계로(in a complex relationship) 구성될 수 있다). 호스트 시스템들(2a, b...n)은 스토리지 컨트롤러(6)과 통신하는데, 프로토콜 스택 내의 여러 다른 층들에서 TCP/IP, 파이버 채널(Fibre Channel), 이더넷(Ethernet), 등과 같은 다수의 통신 프로토콜을 사용하여, 인터넷, 스토리지 영역 네트워크(SAN), 인트라넷, 로컬 영역 네트워크(LAN), 광역 네트워크(WAN), 등과 같은 네트워크(8)을 통해서 한다.

스토리지 컨트롤러(6)은 스토리지 컨트롤러 동작들을 수행하기 위해 코드(12)를 실행하는 프로세서(10)을 포함한다. 스토리지 컨트롤러(6)은 또한 캐시 시스템(14)와, 배터리 백업 메모리 디바이스와 같은, 비-휘발성 스토리지 유닛(16)을 포함한다. 스토리지 컨트롤러(6)은 호스트들(2a, b...n)로부터 수신된 데이터 갱신들을 가상 스토리지 볼륨들(22, 24, 및 26)에 (그리고 이에 의하여 볼륨들(28, 30, 및 32)에) 기록하기 위해서 또한 볼륨들(28, 30, 및 32)로부터 데이터를 읽어서 호스트들(2a, b...n)로 리턴하기 위해서 캐시(14)에 데이터 갱신들을 저장한다. 패스트 라이트 모드(Fast Write mode)에서 동작할 때는, 호스트들(2a, b...n)으로부터 수신된 데이터 갱신들은 캐시(14)와 NVS(16) 모두에 복사된다. 엔드 상태(End status)는 상기 갱신이 캐시(14) 및 NVS(16) 모두에 복사된 후에 상기 데이터 갱신을 보내는 호스트들(2a, b...n)로 리턴된다.

스토리지 컨트롤러(6)은 또한 소스 코드-기반 스펙(a source code-based specification)을 포함하는데, 이는 스토리지 컨트롤러(6)과 호스트들(2a, b...n) 상에서 동작하는 소유 어플리케이션(an owning application) 사이의 인터페이스로서 사용하기 위함이다. 도시된 실시 예에서, 이 스펙/인터페이스는 어플리케이션 프로그래밍 인터페이스(API)(17)로서 표시된다. API(17)은 스토리지 컨트롤러(6)에 의해서 호스트들(2a, b...n)에 제공되는데, 구체적으로는 호스트들(2a, b...n) 상에서 동작하는 소유 어플리케이션에 제공되며, 이에 관해서는 더 설명될 것이다. 더 나아가, 스토리지 컨트롤러(6)은 또한 스토리지 가상화 엔진(18)을 포함하는데, 이는 API(17)과 함께 동작하여 도시된 실시 예들의 목적들을 달성할 수 있는데, 이에 대해서도 더 설명할 것이다.

캐시 시스템(14)는 가상 디스크 맵(15)를 포함하며, 이는 간단히 “스토리지 맵”(15)이라 한다. 캐시 시스템(14)는 호스트들(2a, b...n) 또는 유사한 디바이스들로부터의 쓰기 데이터를 수신하고, 이 데이터는 캐시 메모리에 배치된다. 한 실시 예에서, 스토리지 맵(15)는 물리적 볼륨(28, 30, 및 32)를 가상 볼륨들(22, 24, 26) 등으로 연결하기 위해 물리적에서 가상으로 데이터의 다양한 매핑들(various physical-to-virtual mappings of data)을 포함한다.

도 1은, 당업자가 이해할 수 있듯이, 이전에 예시한 스토리지 컨트롤러(6)과 같은 다수의 상호 관련된 컴포넌트들을 갖는 대규모, 다수-시스템/다수-클러스터 스토리지 환경(a larger, multi-system/multi-cluster storage environment)의 일부분을 도시한다. 이전에 표시하였듯이, 가상 볼륨(22, 24, 및 26)은 호스트 시스템들(2a, b...n)을 통해서 사용자에게 제공되지만, 하부 물리적 구성은 많은 다양한 형태들을 취할 수 있다. 예를 들어, SSD, SATA, HDD, 테이프, 등과 같은 다양한 종류로 다수의 상호 관련된 스토리지 디바이스들은 특정 구성에 따라서 스토리지 볼륨들(28. 30, 및 32)를 포함할 수 있다.

프로세서(10)과 같은, 스토리지 환경의 다양한 컴포넌트들이 본 발명의 특징들 및 다음의 청구항 주제들을 구현하기 위해 구성될 수 있다. 예를 들어, 스토리지 가상화 엔진(18)은 프로세서(10)과 함께 동작하여, 가상 디스크 맵(15)와 함께 가상화 기능을 제공하는 것과 같은, 이 후 설명할 다양한 기능들을 수행할 수 있다. 비슷하게, API도 또한 프로세서(1), 또는 스토리지 환경 내에 동작 가능하게 결합된 다른 컴포넌트들과 함께 동작할 수 있다. 당업자는 다른 다양한 처리 및 메모리 컴포넌트들도 이들 특징들을 실현하기 위해 구성될 수 있고, 스토리지 컨트롤러(6), 또는 다른 곳에서 동작될 수 있음을 이해할 것이다.

본 발명의 한 실시 예에서, 스토리지 컨트롤러(6)은 LUN 배후의 물리적 스토리지(예를 들어, 28, 30, 32)로부터, 호스트(2a...2b...n)에서 동작 가능한 어플리케이션으로부터 투명하게, 새로운 물리적 위치로 명시된 사이즈의 데이터를 이동시키기 위해 API(17)을 제공한다. 이 API(17)은 데이터를 저장하기 위해 사용되는 LUN을 교란시키지 않고 하나의 물리적 위치로부터 다른 물리적 위치로 특정 데이터만을 이동시키기 위해 데이터베이스(Oracle® 또는 DB2)와 같은 어플리케이션들에 의해서 호출될 수 있다(invoked).

소유 어플리케이션에 의해서 사용되기 위해 제공된 API들의 예들에는 다음을 포함한다:

migrate(sourceLUN #, startLBA, size, target storage pool)

이 API로, 스토리지 가상화 소프트웨어는 이동되는 데이터가 배치되어야 하는 타겟 위치를 선택한다. 타겟 스토리지 풀(target storage pool)의 선택은 어플리케이션에 의해서 이루어지지만 타겟 스토리지 풀 상의 데이터 위치는 스토리지 가상화 소프트웨어에 맡겨진다.

migrate(sourceLUN #, startLBA, size, targetLUN #, targetLBA)

이 API를 사용하여, 어플리케이션은 타겟 LUN 및 데이터가 이동되어야 하는 정확한 위치를 컨트롤한다. 그러므로, 완전한 컨트롤이 데이터를 이동시키는 동안 어플리케이션에 의해서 행사된다.

migrate(sourceLUN #, startLBA, target storage pool id) migrate(sourceLUN #, startLBA, targetLUN #, targetLBA)

API 콜들의 상기 예시에서, 각각의 API 콜에 대해 이동되는 스토리지의 사이즈는 고정되며, 즉 말하자면 구현에 따라서 128k 또는 256k이다. 콜러(caller)는 요구된 사이즈의 데이터를 이동시키기 위해 API를 여러 번 호출해야 한다.

migrate(sourceLUN #, startLBA, size, targetLUN #, targetLBA, time)

상기 API 콜에서, 어플리케이션은 소스 LUN으로부터 타겟 LUN으로 데이터 이동을 요청할 뿐만 아니라, 상기 이동이 언제 실행되어야 하는지 그 때를 또한 언급한다. 주목할 것은, 구현의 어려움들을 제거하기 위해, 한 실시 예에서는, 시작과 타겟 LBA들 및 사이즈 파라미터들은 특정 얼라인먼트들(예를 들어, 1GB 범위들(extents))로 제한될 수 있다는 것이다. 주목할 것은: 구현의 어려움들을 제거하기 위해, 시작과 타겟 LBA들 및 사이즈 파라미터들은 특정 얼라인먼트들, 예를 들어 DS8000의 1GB 범위들로 한정할 필요가 있을 수 있다는 것이다.

전술한 데이터 이동에 대한 일부 예시적 사용 케이스들이, 다음과 같이, 제공된다. 첫째 예에서, 소유 어플리케이션은 주어진 LUN 상의 현재 위치로부터 전력을 덜 소비하고 덜 리소스 집약적인 하위 층 스토리지로 특정 레코드 또는 데이터베이스 테이블을 이동시키기를 원한다. 이것은 더 오래된 데이터(자주 액세스되지 않는 데이터)를 장기 유지를 위해 더 비용-효과적인 스토리지로 이동시킬 필요에 의해서 시작될 수 있다. 예를 들어, 이 동작은 15k RPM에서 동작하는 올 파이버 채널(FC) 디스크들에서 실행하는 비용집약적 스토리지 어레이로부터 훨씬 더 낮은 RPM에서 동작하는 SATA 디스크들에서 실행하는 분리된, 덜 비용 집약적인 스토리지 어레이로 데이터를 이동시킬 것이다. 그러한 시나리오에서, 데이터 이동 API는, 어플리케이션 이동 요청에 영향을 주는 시스템 볼륨 컨트롤러(SVC)와 같은, SAN 내의 스토리지 가상화 엘리멘트에 의해서 동작된다.

둘째 예에서, 소유 어플리케이션은 주어진 레코드가 빈번하게 액세스됨을 발견한다. 그래서, 어플리케이션은 이 영역을 스토리지의 더 나은 수행을 할 수 있는 층(a better-performing tier)(예를 들어, 고체 상태 드라이브(SSD) 층 또는 15k RPM 드라이브 풀)으로 이동시키기를 원한다. 이러한 종류의 사용 케이스는 스토리지 컨트롤러 내에서 어플리케이션 제어된 “핫스팟” 이동을 용이하게 할 수 있다.

여기서 주목할 것은 전술한 데이터 이동 API는, 데이터베이스가 그러한 목적들에 유용하더라도, 데이터베이스 어플리케이션들과 같은, 특정 종류의 어플리케이션들에 한정되는 것은 아니라는 것이다. 당업자는 데이터를 이동시킬 필요성을 갖고 있는 모든 소유 어플리케이션, 예를 들어 메일 서버, 또는 기타 가상화 어플리케이션들에 적용 가능할 수 있다는 것을 이해할 것이다.

전술한 API의 다양한 실시 예들은 특정 어플리케이션에 적합한 다양한 방식으로 구현될 수 있다. 예를 들어, API는 소형 컴퓨터 시스템들 인터페이스(SCSI)를 통해서 소유 어플리케이션에 인라인(inline)으로 제공될 수 있다. 다른 예에서, API는 인터넷 프로토콜(IP)를 통해서 소유 어플리케이션에 아웃-오브-밴드(out-of-band)로 제공될 수 있다. 당업자는 전술한 API의 다양한 구현들이 특정 상황을 위해 필요에 따라 사용될 수 있다는 것을 이해할 것이다.

한 실시 예에서, 전술한 데이터 이동 API 기능을 지원하는 스토리지 컨트롤러 상에서, 한 세트의 예시적 단계들이 이동 요청을 만족시키기 위해 수행될 수 있다.

첫째, 데이터 이동 API를 지원하는 스토리지 컨트롤러는 이 스토리지 컨트롤러에 의해서 지원되는 스토리지 풀들의 목록을 그들의 성능, 리던던시 및 전력 소비 특성과 함께 노출시킨다. 이 정보는, 예를 들어 모드 센스 소형 컴퓨터 시스템들 인터페이스(a Mode Sense small computer systems interface SCSI) 커맨드를 통해서 이용 가능하게 되고, 데이터 이동을 위한 타겟 스토리지 풀을 선택하기 위해 스토리지 컨트롤러에 의해서 사용될 수 있다.

둘째, 전술한 SCSI 커맨드(또는, 다른 실시 예에서, 예를 들어, 이동 API의 호출 모드에 따라 아웃-오브-밴드 커맨드)가 스토리지 가상화 소프트웨어에 의해서 수신되는데, 이 소프트웨어는 현재의 위치(예를 들어, 높은 성능 및 비용 집약적인 15k RPM 드라이브들로 구성된)로부터 다른 스토리지 풀(a differing storage pool)(예를 들어, 덜 비용 집약적이고 그리고 에너지-효율적인 7.2k RPM 드라이브들)로 이동될 주어진 시작LBA=SLBA1 및 사이즈=SZ1로부터 시작하는 데이터를 요청한다.

셋째, 그 다음에 스토리지 가상화 소프트웨어는 스토리지 타겟 풀 상에서 이 선택된 데이터 조각(data chunk)을 위한 “베스트 핏”을 결정한다. 그 다음에 스토리지 가상화 소프트웨어는 현재의 위치로부터 타겟 위치로 (어플리케이션으로부터 투명하게) 데이터를 백그라운드로 복사한다.

넷째, 그 다음에 가상 디스크 맵은 새로운 물리적 위치를 원자적으로(atomically) 가리키도록 하여 LUN의 해당 부분만 이제 덜 비용이 드는 스토리지 상에 위치되도록 한다. 이 동작 동안, 모든 다른 이동 동작에서 처럼, 데이터는 일관성을 갖고 최신으로 유지된다.

다섯째, 일단 상기 맵이 새로운 물리적 스토리지 위치를 반영하도록 원자적으로 변경되었기 때문에, 상기 이동 동작은 실행된다(committed). 만일 API가 타겟 물리적 디스크와, 데이터를 배치할 장소를 명시한다면, 스토리지 컨트롤러가 명시된 타겟 풀 상의 새로운 타겟 위치를 선택하는 대신에, 어플리케이션에 의해서 명시된 새로운 위치로 스토리지 컨트롤러는 데이터를 이동시킨다.

도 2로 돌아가면, 종래의 데이터 이동 메커니즘(200)의 블록 다이어그램이 묘사되어 있다. 각각의 데이터 경로, 커맨드 경로, 및 커맨드 응답 경로가 표시된 화살표들 및 대응 범례에 의해서 도시되어 있고 어플리케이션 수준에서 도시되어 있다. 제1 단계로서, 소유 어플리케이션/유틸리티는 데이터를 물리적 디스크(1)(여기서 FC 15k RPM 드라이브로서 도시되어있다)로부터 물리적 디스크(2)(여기서 덜 비용 집약적인 직렬 부착(serial attached) SCSI(SAS) 7k RPM 드라이브로서 도시되어 있다)로 이동시키기 위해 커맨드(command)를 물리적 디스크 (1)에 송신한다. 그 다음 커맨드 응답(command response)이 물리적 디스크(1)(즉, 물리적 디스크(1)을 담당하는 스토리지 컨트롤러)로부터 유틸리티/소유 어플리케이션에 리턴된다. 그 다음 데이터는 호스트로 전송(pull)되고, 그 다음 도시한 바와 같이 물리적 디스크(2) 상의 새로운 위치로 기록된다(written back). 이 시나리오는 실행하기 위해 서버 자원들뿐만 아니라 스토리지 대역폭을 소비한다.

도 2와 대비하여, 다음의 도 3-4는 본 발명에 따른 예시적 실시 예들을 도시한다. 예를 들어, 아래의 도3에는, 전술한 바와 같이 실행된 API를 사용하는 스마트 서브-LUN 수준의 데이터 이동을 위한 메커니즘이 도시되어 있다.

도 3-4는, 예를 들어, API가 어떻게 실행되는지 그리고 종래의 메커니즘들에 의해서 제공되는 데이터 이동 메커니즘과 비교하여 장점들이 무엇인지에 관해서 기술하며, 상기 종래의 메커니즘은, 이전에 도시한 도 2에 도시되어 있는데, 이는 데이터를 디스크로부터 호스트로 전송(pull)하고 그 후에 그 데이터를 타겟 위치에 기록하여, 스토리지 대역폭과 서버 파우어(server power)를 소비한다. 이에 반하여, 다음의 도 3에서, 메커니즘(300)은 본 발명의 특징들이 포함될 수 있는 서브-LUN 데이터 이동을 위한 예시적 방법을 묘사한다. 더 자세하게 도 3을 참조하면, 한 실시 예에서, 이동 API의 호출(invocation)은 호스트에 위치한(local) 어플리케이션에 의해서 수행되지만 데이터 이동 동작은 스토리지 컨트롤러에 의해서 실행된다. 종래의 기타 재산권 데이터 이동 메커니즘들(other proprietary conventional data migration mechanisms)(기타 어플리케이션들을 포함하는)은 어떤 데이터를 이동시킬지 그리고 언제 이동시킬지를 결정함에 반하여, 상기 이동 동작은 호스트의 개입 없이 스토리지 버추얼라이저(the storage virtualizer)에 의해서 실행된다.

도 3은, 예시된 실시 예에서, 서브-LUN 데이터 이동이 본 발명에 따라 어떻게 실행되는지를 묘사한다. API의 사용에 의해서 그리고 도시된 예시적 명령을 사용하여, 데이터베이스 어플리케이션은 상기 예시적 커맨드를 송신하는데, 이는 서브-LUN 수준의 데이터를 물리적 디스크(1)(이 경우에는 FC 15k 드라이브들로 묘사됨)로부터 도시된 PHY 디스크들(1, 2, 및 3)의 스토리지 풀 P1 (묘사된 실시 예에서는 예시된 스토리지 풀 내에 구성된 SAS 7k RPM드라이브들로 구성됨) 내의 제2의 물리적 위치로 이동시키기 위함이다. 상기 커맨드는 호스트로 리턴된다(그렇게 하여 데이터베이스 어플리케이션으로 리턴된다). 데이터베이스 어플리케이션이 어떤 데이터를 이동시킬지 그리고 언제 이동시킬지를 결정함에 반하여, 상기 이동 동작 그 자체는, 호스트의 개입 없이, 스토리지 버추얼라이저(예를 들어, 도1의 스토리지 가상화 엔진(18))에 의해서 수행된다. 따라서, 그리고 도시한 바와 같이, 데이터는 어플리케이션을 대신하는 상기 버추얼라이저(예를 들어 SVC)를 인에이블함으로써 지능적으로 이동되는데, 이는 어플리케이션에게 부담되는 오버헤드 없이 상기 이동을 수행하기 위해서이다. 그 다음 데이터는 데이터 경로에 의해서 도시된 바와 같이 물리적 디스크(1)로부터 스토리지 풀 P1로 이동된다.

이제, 다음의, 도 4-5로 돌아가면, 선택된 LUN을 위한 가상에서 물리적으로의 매핑(the virtual-to physical mapping)에 적용되는 예시적 동작들의 블록 다이어그램들이 전술한 API-지원된 데이터 이동 메커니즘들에 따라 도시된다. 주목할 것은, 이들 다이어그램들에서 물리적 디스크들은 실제로 하부 스토리지 컨트롤러에 의해서 제공되는 가상 볼륨들(예를 들어, RAID 5 볼륨)일 수 있다. 한 실시 예에서, 도시한 가상에서 물리적으로의 매핑은 가상 디스크 맵(15)(도1)로서 구현될 수 있다. 당업자는, 그러나, 그러한 매핑들의 다양한 구현들이 특정 상황에 적합하도록 일어날 수 있음을 이해할 것이다.

먼저 도 4로 돌아가면, 제1단계(400A)에서, 초기 LUN 주소 범위 맵(여기서 0으로부터 n까지 주소지정 되는 것으로 도시됨)이 도시된 물리적 디스크(1) 내의 주소 범위에 대응하기 위해 식별된다. 도 5에서 도시된, 제2단계(400B)에서, 타겟 스토리지 풀로 데이터 조각의 이동 동작이 완료되고 나면, 새로운 LUN 주소 범위 맵이 범위들 x-y로 생성되는데, 이 범위들은 이동된 데이터 조각에 대응하는 물리적 디스크(2) 내의 타겟 스토리지 풀을 가리키도록 구성된다. 범위들 0-x 및 y-n은 도시한 바와 같이 물리적 디스크(1)을 가리키도록 유지된다(retained).

다음의, 도 6은 본 발명의 특징들이 구현될 수 있는, 컴퓨팅 스토리지 환경에서 서브-LUN 수준의 데이터 이동을 수행하기 위한 예시적 방법(600)의 플로 차트 다이어그램이다. 방법(600)은, 단계(602)에서, 시작하여, 단계(604)에서, LUN 배후의 물리적 스토리지로부터 새로운 물리적 위치로 명시된, 서브-LUN 수준의 사이즈의 데이터(a specified, sub-LUN level size of data)를 이동시키기 위해 스토리지 컨트롤러 및 소유 어플리케이션 사이의 인터페이스로서 사용하기 위한 소스 코드-기반 스펙(a source code-based specification)을 구현한다. 그 다음 방법(600)은 단계(606)에서 종료한다.

다음의, 도7은, 본 발명의 다양한 특징들이 구현될 수 있는, 소스로부터 타겟 스토리지 위치로 서브-LUN 수준의 데이터 이동을 수행하기 위한 추가의 예시적 방법(700)의 플로 차트이다. 방법(700)은, 단계(702)에서, 시작하여, 단계(704)에서, 가상 디스크 상의 데이터 조각의 시작 LBA 및 사이즈(a start LBA and a size of a chunk of data on the virtual disk)와, 타겟 물리적 스토리지 디스크립션(a target physical storage description)을 명시한다(specify). 그 다음, 단계(706)에서, 상기 소스 코드 기반 스펙(source code based specification) (예를 들어, API)은 스토리지 컨트롤러에 의해서 지원되는 스토리지 풀들의 목록을 적어도 하나의 스토리지 특성, 예를 들어, 사이즈, 이용 가능 공간, 하부 스토리지(예를 들어, SAS 드라이브들)의 물리적 특성, 등과 함께 노출한다(expose).

단계(706)으로부터 획득한 정보의 적어도 일부분에 기초하여, 방법(700)은, 단계(708)에서, 인터페이스를 통해서 콜(예를 들어, 호스트로부터)을 수신하는데, 이 인터페이스는 노출된 스토리지 풀들의 목록의 타겟 스토리지 풀로 이동될 데이터 조각의 시작 LBA 및 명시된 사이즈로부터의 데이터를 요청한다. 그 다음, 스토리지 컨트롤러 또는 유사한 스토리지 디바이스는, 단계(710)에서, 타겟 스토리지 풀 내의 데이터 조각을 위한 “베스트 핏(best fit)”을 결정한다. 예를 들어, 데이터 조각은 순차적으로 한 물리적 볼륨 상에 저장되거나, 또는 보증이 될 수 있는 상황일 때, 그리고 스토리지 컨트롤러 또는 기타 관리 디바이스의 판단으로서 다수의 볼륨들에 걸쳐 분산될 수도 있다.

다음 단계로서, 이동 동작은, 단계(712)에서, 시작되고, 데이터의 명시된 조각이 어플리케이션에 대한 오버헤드의 개입 없이 백그라운드 프로세스로 타겟 스토리지 풀로 이동된다(즉, 이 프로세스는 소유 어플리케이션에 대해 투명하게 수행된다). 상기 이동 동작이 완료되면, 가상 디스크 맵은, 단계(714)에서, 타겟 스토리지 풀 상의 새로운 물리적 위치를 가리키도록 된다. 일단 상기 변경이 가상 디스크 맵에 만들어지면, 상기 이동 동작은, 단계(716)에서 실행된다(committed). 그 다음 방법(700)은, 단계(718)에서 종료된다.

다음의, 도8은, 본 발명의 다른 실시 예에 따라, 소스로부터 타겟 스토리지 위치로 서브-LUN 수준의 데이터 이동을 수행하기 위한 추가의 예시적 방법(800)을 도시한다. 방법(800)은, 단계(802)에서, 시작하여, 단계(804)에서, 새로운 스토리지 풀로 이동될 데이터 이동 사이즈를 명시한다(specify). 그 다음, 단계(806)에서, 이동될 데이터 조각 사이즈가 명시된다. 전체 이동 사이즈는, 단계(808)에서, 이전에 명시된 데이터 조각 사이즈의 절상된 배수(a rounded-up multiple)로서 명시된다.

그 다음 방법(800)은 단계(810)으로 이동하는데, 이 단계에서 전체 이동 사이즈가 영보다 큰지 또는 같은지를 질의한다. 만일 응답이”아니오”이면, 방법(800)은, 단계(826)에서, 종료한다. 만일 응답이 “예”이면, 방법(800)은 단계(812)로 이동하는데, 여기서 이동 동작이 데이터 조각-사이즈의 증분들로(in data chunk-sized increments) 수행된다. 이동 동작(812)는, 도 7에서 이전에 기술한 단계들의 적어도 일부에 대하여 유사한 기능을 포함하는데, 이들에는 이동될 데이터 조각의 시작 LBA 및 명시된 사이즈로부터 데이터를 요청하는 API를 통한 콜을 수신하는 단계(단계 814), 상기 데이터 조각을 위한 베스트 핏을 결정하는 단계(단계816), 상기 데이터 조각을 타겟 스토리지 풀로 백그라운드 프로세스로서 이동하는 단계(단계818), 상기 가상 디스크 맵을 새로운 물리적 스토리지 위치로 가리키게 하는 단계(단계820), 및 이동 동작을 실행하는 단계(단계822)가 포함된다.

방법(800)이 단계(812)로 진행하여 이동 동작을 실행함에 따라, 전체 이동 사이즈는, 단계(824)에서, 이동되는 데이터 조각 증분 만큼 감소된다. 그리고 방법(800)은 단계(810)으로 리턴하여 다시 전체 이동 사이즈가 영보다 큰지 또는 같은지 질의를 한다. 여기서 만일 그 대답이 “아니오”이면, 방법(800)은, 단계(826)에서, 종료되고, 그 반대이면 단계(812)로 리턴하여 다른 이동 동작을 수행하는데, 다시 데이터 조각-사이즈의 증분으로 수행된다.

이제, 다음의, 도 9로 돌아가면, 소스로부터 타겟 스토리지 위치로 서브-LUN 수준의 데이터 이동을 수행하기 위한 추가의 예시적 방법(900)이 도시된다. 방법(900)은, 단계(902)에서, 시작하여, 단계(904)에서, 소스 LUN, 시작 LBA, 전체 이동 사이즈, 타겟 LUN, 및 이동될 데이터 조각의 사이즈를 명시한다(specify). 그 다음, 방법(900)은, 단계(906)에서, 이동 동작이 수행될 시간을 명시한다. 그 다음, 단계(908)에서, 만일 명시된 시간이 도달하였다면, 이동 동작 단계(910)이 수행되는데, 이에 관해서는 다음에 더 설명할 것이다. 이와 달리, 단계(908)에서, 만일 명시된 시간이 도달되지 않았다면, 방법(900)은, 단계(912)에서, 대기하고 단계(908)로 리턴하여 다시 질의를 시작한다.

단계(910)에서, 이동 동작은 도 7 및 8에서 이전에 도시한 것과 유사한 기능을 수행하는데, 이들에는 소유 어플리케이션에 대하여 투명한 백그라운드 프로세스로서 데이터를 타겟 스토리지 풀로 이동시키는 단계(914), 가상 디스크 맵을 타겟 스토리지 풀 상의 새로운 물리적 위치에 대하여 가리키도록 하는 단계(단계916), 및 이동 동작을 실행하는 단계(단계918)가 포함된다. 그 다음 상기 방법은, 단계(920)에서, 종료된다.

다음의, 도 10은, 소스로부터 타겟 스토리지 위치로 서브-LUN 수준의 데이터 이동을 수행하기 위한 추가의 예시적 방법(1000)을 도시한다. 방법(1000)은, 단계(1002)에서, 시작하여, 단계(1004)에서, 가상 디스크 상의 데이터 조각의 시작 LBA 및 사이즈와, 타겟 물리적 스토리지 디스크립션을 명시한다(specify). 그 다음, 소스 코드 기반 스펙(예를 들어, API)은 스토리지 컨트롤러에 의해서 지원되는 스토리지 풀들의 목록을, 사이즈, 이용 가능 공간, 하부 스토리지(예를 들어, SAS 드라이브들)의 물리적 특성들, 등과 같은, 적어도 하나의 스토리지 특성들과 함께 노출한다.

단계(1006)으로부터 획득된 정보의 적어도 일부분에 기초하여, 방법(1000)은 단계(1008)에서, 인터페이스를 통해서 콜(예를 들어, 호스트로부터)을 수신하는데, 이 인터페이스는 명시된 시간에 노출된 스토리지 풀들의 목록의 타겟 스토리지 풀로 이동될 데이터 조각의 시작 LBA 및 명시된 사이즈로부터 데이터를 요청한다. 그 다음, 스토리지 컨트롤러 또는 유사한 스토리지 디바이스는, 단계(1010)에서, 타겟 스토리지 풀 내의 데이터 조각을 위한 “베스트 핏(best fit)”을 결정할 수 있다. 예를 들어, 데이터 조각은 순차적으로 한 물리적 볼륨 상에 저장되거나, 또는 보증이 될 수 있는 상황일 때, 그리고 스토리지 컨트롤러 또는 기타 관리 디바이스의 판단으로서 다수의 볼륨들에 걸쳐 분산될 수도 있다.

다음 단계로서, 이동 동작은, 단계(1012)에서, 시작되고, 데이터의 명시된 조각이 명시된 시간에 어플리케이션에 대한 오버헤드를 수반하지 않으면서 백그라운드 프로세스로 타겟 스토리지 풀로 이동된다(즉, 이 프로세스는 소유 어플리케이션에 대해 투명하게 수행된다). 상기 이동 동작이 완료되면, 가상 디스크 맵은, 단계(1014)에서, 타겟 스토리지 풀 상의 새로운 물리적 위치를 가리키게 된다. 일단 상기 변경이 가상 디스크 맵에 만들어지면, 상기 이동 동작은, 단계(1016)에서 실행된다(committed). 그 다음 방법(1000)은, 단계(1018)에서 종료된다.

다음의, 도 11은, 소스로부터 타겟 스토리지 위치로 서브-LUN 수준의 데이터 이동을 수행하기 위한 추가의 예시적 방법(1100)을 도시한다. 방법(1100)은, 단계(1102)에서, 시작하여, 단계(1004)에서, 가상 디스크 상의 데이터 조각의 시작 LBA 및 사이즈와, 타겟 물리적 스토리지 디스크립션을 명시한다(specify). 그 다음, 소스 코드 기반 스펙(예를 들어, API)은 스토리지 컨트롤러에 의해서 지원되는 스토리지 풀들의 목록을, 사이즈, 이용 가능 공간, 하부 스토리지(예를 들어, SAS 드라이브들)의 물리적 특성들, 등과 같은, 적어도 하나의 스토리지 특성들과 함께 노출한다.

단계(1106)으로부터 획득된 정보의 적어도 일부분에 기초하여, 방법(1100)은 단계(1108)에서, 인터페이스를 통해서 콜(예를 들어, 호스트로부터)을 수신하는데, 이 인터페이스는 상기 콜의 수신과 일치하는 시간(즉, 즉각적으로)에 노출된 스토리지 풀들의 목록의 타겟 스토리지 풀로 이동될 데이터 조각의 시작 LBA 및 명시된 사이즈로부터 데이터를 요청한다. 그 다음, 스토리지 컨트롤러 또는 유사한 스토리지 디바이스는, 단계(1110)에서, 타겟 스토리지 풀 내의 데이터 조각을 위한 “베스트 핏(best fit)”을 결정할 수 있다. 예를 들어, 데이터 조각은 순차적으로 한 물리적 볼륨 상에 저장되거나, 또는 보증이 될 수 있는 상황일 때, 그리고 스토리지 컨트롤러 또는 기타 관리 디바이스의 판단으로서 다수의 볼륨들에 걸쳐 분산될 수도 있다.

다음 단계로서, 이동 동작은, 단계(1112)에서, 시작되고, 데이터의 명시된 조각이 명시된 시간에 어플리케이션에 대한 오버헤드를 수반하지 않으면서 백그라운드 프로세스로 타겟 스토리지 풀로 이동된다(즉, 이 프로세스는 소유 어플리케이션에 대해 투명하게 수행된다). 상기 이동 동작이 완료되면, 가상 디스크 맵은, 단계(1114)에서, 타겟 스토리지 풀 상의 새로운 물리적 위치를 가리키게 된다. 일단 상기 변경이 가상 디스크 맵에 만들어지면, 상기 이동 동작은, 단계(1116)에서 실행된다(committed). 그 다음 방법(1100)은, 단계(1118)에서, 종료된다.

당업자들이 이해하듯이, 본 발명의 특징들은 시스템, 방법, 또는 컴퓨터 프로그램 제품으로 구현될 수 있다. 따라서, 본 발명의 특징들은 전적으로 하드웨어 실시 예, 전적으로 소프트웨어 실시 예 (펌웨어 (firmware), 상주 (resident) 소프트웨어, 마이크로-코드 등을 포함하는) 또는 이하 모두 일반적으로 “회로” ("circuit,"), “모듈” ("module") 또는 “시스템”이라 할 수 있는 하드웨어 실시 예들 및 소프트웨어 실시 예들을 결합하는 실시 예의 형태를 취할 수 있다. 더 나아가서, 본 발명의 실시 예들은 컴퓨터 프로그램 제품의 형태를 취할 수 있는데, 이는 하나 또는 그 이상의 컴퓨터 읽기가능 매체(들)내에 구현되며, 컴퓨터 읽기가능 프로그램 코드가 그 위에 구현된다.

하나 또는 그 이상의 컴퓨터 읽기가능 매체(들)의 모든 조합이 사용될 수 있다. 컴퓨터 읽기가능 매체는 컴퓨터 읽기가능 신호 매체 또는 컴퓨터 읽기가능 스토리지 매체일 수 있다. 컴퓨터 읽기가능 저장 매체는 예를 들어, 전자 (electronic), 자기(magnetic), 광(optical), 전자기(electromagnetic), 적외선 (infrared) 또는 반도체(semiconductor) 시스템, 장치 또는 디바이스, 또는 상기 것들의 어떠한 적절한 조합일 수 있고 이에 국한되지는 않는다. 컴퓨터 읽기가능 스토리지 매체의 더 구체적인 사례들 (비-포괄적 리스트)에는 다음의 것들이 포함된다: 하나 또는 그 이상의 전선들을 가진 모든 전기 접속, 휴대용 컴퓨터 디스켓, 하드 디스크, 랜덤 액세스 메모리 (RAM), 판독-전용 메모리 (ROM), 지울 수 있는 프로그램가능 판독-전용 메모리 (EPROM 또는 플래시 메모리), 광 섬유, 휴대용 컴팩트 디스크 판독-전용 메모리 (CD-ROM), 광 스토리지 디바이스, 자기 스토리지 디바이스, 또는 이들의 모든 적절한 조합. 이 문서의 맥락에서, 컴퓨터 읽기가능 스토리지 매체는 명령 실행 시스템, 장치, 또는 디바이스에 의해서 또는 연결해서 사용할 프로그램을 포함 또는 저장할 수 있는 모든 유형의 매체가 될 수 있다.

컴퓨터 읽기가능 매체상에 구현된 프로그램 코드는 무선, 유선, 광섬유 케이블 (optical fiber cable), 무선 주파수 (RF)등 또는 상기 것들의 적절한 조합 등을 포함하는 모든 매체 (이에 국한되지는 않지만)를 사용하여 전송될 수 있다. 본 발명의 특징들의 동작을 수행하기 위한 컴퓨터 프로그램 코드는 하나 또는 그 이상의 프로그래밍 언어의 어떤 조합으로 기록될 수 있으며, 이 언어에는 자바 (Java), 스몰토크 (Smalltalk), C++ 등과 같은 객체 지향형 프로그래밍 언어 (object oriented programming language) 및 “C” 프로그래밍 언어, 또는 유사한 프로그래밍 언어들과 같은 종래의 순차 프로그래밍 언어 (conventional procedural programming languages)를 포함한다. 상기 프로그램 코드는, 전적으로 사용자의 컴퓨터상에서, 부분적으로 사용자의 컴퓨터상에서, 부분적으로 사용자의 컴퓨터 및 원격 컴퓨터상에서 또는 전적으로 원격 컴퓨터, 서버상에서 실행될 수 있다. 후자의 시나리오에서, 원격 컴퓨터는 근거리 통신망 (LAN) 또는 광대역 통신망 (WAN)을 포함하는, 어떠한 형태의 네트워크를 통해서 사용자의 컴퓨터와 접속이 될 수 있으며, 또는 이러한 접속은 (예를 들어, 인터넷 서비스 공급자를 사용하는 인터넷을 통하여) 외부 컴퓨터와도 접속될 수 있다.

본 발명의 여러 특징들이 본 발명의 실시 예들에 따라, 방법들, 장치 (시스템들) 그리고 컴퓨터 프로그램 제품들의 플로 차트 도시 (flowchart illustrations) 및/또는 블록 다이어그램 (block diagrams)을 참조하여 이하 설명된다. 플로 차트 도시 및/또는 블록 다이어그램의 각 블록 그리고 플로 차트 도시 및/또는 블록 다이어그램의 조합은 컴퓨터 프로그램 명령들에 의하여 실행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 명령들은 범용 컴퓨터, 특수 목적 컴퓨터, 또는 머신 (machine)을 생성하는 기타 프로그램 가능한 데이터 처리 장치의 프로세서에 제공되어, 컴퓨터나 기타 프로그램 가능한 데이터 처리 장치의 프로세서를 통하여 실행될 때, 그러한 명령들이 플로 차트 및/또는 블록 다이어그램이나 블록에 명시된 기능/동작 (acts)을 구현하는 수단을 생성하도록 한다.

이들 컴퓨터 프로그램 명령들은 또한 컴퓨터 읽기가능 매체에 저장될 수 있으며, 컴퓨터, 기타 프로그램가능 데이터 처리 장치 또는 다른 디바이스들에 지시하여 상기 컴퓨터 읽기가능 매체에 저장된 명령들은 상기 플로 차트 및/또는 블록 다이어그램의 블록 또는 블록들에 명시된 기능/동작을 구현하는 명령들을 포함하는 제품 (an article of manufacture)을 생성하도록 특정한 방식으로 기능하게 할 수 있다. 상기 컴퓨터 프로그램 명령들은 또한 컴퓨터, 기타 프로그램가능 데이터 처리 장치, 또는 다른 디바이스들에 로드되어, 컴퓨터, 기타 프로그램가능 장치 또는 다른 디바이스들에서 일련의 계산 단계들이 수행되게 하여 컴퓨터 구현 프로세스를 생성하며, 그렇게 하여 상기 컴퓨터 또는 기타 프로그램가능 장치상에서 실행되는 명령들이 플로 차트 및/또는 블록 다이어그램의 블록 또는 블록들에 명시된 기능들/동작들을 구현하기 위한 프로세스들을 제공하도록 할 수 있다.

상기 도면들 내 플로 차트 및 블록 다이어그램들은 본 발명의 여러 실시 예들에 따른 시스템들, 방법들 및 컴퓨터 프로그램 제품들의 가능한 구현들의 아키텍처, 기능, 및 동작을 예시한다. 이와 관련하여, 상기 플로 차트 또는 블록 다이어그램들 내 각 블록은 상기 명시된 논리적 기능(들)을 구현하기 위한 하나 또는 그 이상의 실행 가능한 명령들을 포함한 모듈, 세그먼트 또는 코드의 일부분을 나타낼 수 있다. 일부 다른 구현들에서, 상기 블록에 언급되는 기능들은 도면들에 언급된 순서와 다르게 일어날 수도 있다는 것에 또한 유의해야 한다. 예를 들면, 연속으로 도시된 두 개의 블록들은 실제로는 사실상 동시에 실행될 수 있고, 또는 이 두 블록들은 때때로 관련된 기능성에 따라서는 역순으로 실행될 수도 있다. 블록 다이어그램들 및/또는 플로 차트 예시의 각 블록, 및 블록 다이어그램들 및/또는 플로 차트 예시 내의 블록들의 조합들은 특수목적용 하드웨어 및 컴퓨터 명령들의 명시된 기능들 또는 동작들, 또는 이들의 조합들을 수행하는 특수목적용 하드웨어-기반 시스템들에 의해 구현될 수 있다는 것에 또한 유의한다.

본 발명의 하나 또는 그 이상의 실시 예들이 상세히 도시되었지만, 아래의 청구항들에 기재된 본 발명의 범위부터 벗어남이 없이 이들 실시 예들에 대한 변경들 및 수정들이 이루어질 수 있음을 당업자들은 이해할 것이다.

Claims

컴퓨팅 환경에서 프로세서에 의한 서브-로지컬 유닛 네임(LUN) 데이터 이동(sub-Logical Unit Name (LUN) data migration)을 위한 방법에 있어서, 상기 방법은:
스토리지 컨트롤러와 소유 어플리케이션(an owning application) 사이의 인터페이스로서 사용할 소스 코드 기반 스펙(a source code -based specification)을 구현하여 상기 LUN 배후의 (behind the LUN) 물리적 스토리지로부터 새로운 물리적 위치로 명시된 사이즈의 데이터(a specified size of data)를 이동시키는 단계(migrate)를 포함하는
방법.
제1항에 있어서, 상기 명시된 사이즈의 데이터를 이동시키는 단계(migrate)는 상기 새로운 물리적 위치를 식별하기 위해 가상 디스크 상의 상기 데이터 조각(a chunk of the data on a virtual disk)의 시작 논리 블록 주소(a start Logical Block Address: LBA) 및 사이즈(size)와 타겟 물리적 스토리지 디스크립션(a target physical storage description)을 명시하는 단계(specifying)를 포함하는
방법.
제2항에 있어서, 상기 방법은 스토리지 풀들의 목록(a list of storage pools) 중 적어도 하나와 관련된 적어도 하나의 스토리지 특성(at least one storage characteristic)과 함께 상기 스토리지 컨트롤러에 의해서 지원되는 스토리지 풀들의 목록을 노출하는 단계(exposing)를 더 포함하는
방법.
제3항에 있어서, 상기 방법은 스토리지 풀들의 상기 노출된 목록의 타겟 스토리지 풀로 이동될 상기 데이터 조각의 시작 LBA 및 명시된 사이즈로부터 데이터를 요청하는 인터페이스를 통해 콜(a call)을 수신하는 단계를 더 포함하는
방법.
제4항에 있어서, 상기 방법은 상기 타겟 스토리지 풀 상의 상기 데이터 조각을 위한 베스트 핏(a best fit)을 결정하는 단계를 더 포함하는
방법.
제5항에 있어서, 상기 방법은 상기 소유 어플리케이션에 투명한(transparent) 백그라운드 프로세스로서, 상기 타겟 스토리지 풀에 대해 상기 데이터 조각을, 이동 동작(a migration operation)으로서, 이동시키는 단계를 더 포함하는
방법.
제6항에 있어서, 상기 방법은 상기 타겟 스토리지 풀 상의 새로운 물리적 위치로 가상 디스크 맵(a virtual disk map)을 가리키는 단계(pointing)를 더 포함하는
방법.
제7항에 있어서, 상기 방법은, 상기 새로운 물리적 위치로 가상 디스크 맵(a virtual disk map)을 가리키는 단계(pointing)를 완료함에 후속하여, 상기 이동 동작을 실행하는 단계(committing)를 더 포함하는
방법.
컴퓨팅 환경에서 프로세서에 의한 서브-로지컬 유닛 네임(LUN) 데이터 이동(sub-Logical Unit Name (LUN) data migration)을 위한 시스템에 있어서, 상기 시스템은:
상기 컴퓨팅 환경에서 동작 가능한, 프로세서를 포함하고, 상기 프로세서는 스토리지 컨트롤러와 소유 어플리케이션(an owning application) 사이의 인터페이스로서 사용할 소스 코드 기반 스펙(a source code -based specification)을 구현하여 상기 LUN 배후의 (behind the LUN) 물리적 스토리지로부터 새로운 물리적 위치로 명시된 사이즈의 데이터(a specified size of data)를 이동시키기 위해(migrate) 구성되는
시스템.
제9항에 있어서, 상기 소스 코드 기반 스펙은 어플리케이션 프로그래밍 인터페이스(an application programming interface: API)를 포함하는
시스템.
제9항에 있어서, 상기 프로세서는, 상기 명시된 사이즈의 데이터를 이동시킴(migrate)에 뒤따라서, 상기 새로운 물리적 위치를 식별하기 위해 가상 디스크 상의 상기 데이터 조각의 시작 논리 블록 주소(a start Logical Block Address: LBA) 및 사이즈(size)와 타겟 물리적 스토리지 디스크립션(a target physical storage description)을 명시하기 위해(specifying) 더 구성되는
시스템.
제11항에 있어서, 상기 프로세서는 스토리지 풀들의 목록(a list of storage pools) 중 적어도 하나와 관련된 적어도 하나의 스토리지 특성(at least one storage characteristic)과 함께 상기 스토리지 컨트롤러에 의해서 지원되는 스토리지 풀들의 목록을 노출하기 위해(exposing) 더 구성되는
시스템.
제12항에 있어서, 상기 프로세서는 스토리지 풀들의 상기 노출된 목록의 타겟 스토리지 풀로 이동될 상기 데이터 조각의 시작 LBA 및 명시된 사이즈로부터 데이터를 요청하는 인터페이스를 통해 콜(a call)을 수신하기 위해 더 구성되는
시스템.
제13항에 있어서, 상기 프로세서는 상기 타겟 스토리지 풀 상의 상기 데이터 조각을 위한 베스트 핏(a best fit)을 결정하기 위해 더 구성되는
시스템.
제14항에 있어서, 상기 프로세서는 상기 소유 어플리케이션에 투명한 백그라운드 프로세스로서, 상기 타겟 스토리지 풀로 상기 데이터 조각을, 이동 동작(a migration operation)으로서, 이동시키기 위해 더 구성하는
시스템.
제15항에 있어서, 상기 프로세서는 상기 타겟 스토리지 풀 상의 새로운 물리적 위치로 가상 디스크 맵(a virtual disk map)을 가리키기 위해(pointing) 더 구성되는
시스템.
제16항에 있어서, 상기 프로세서는, 상기 새로운 물리적 위치로 가상 디스크 맵(a virtual disk map)을 가리키는 단계(pointing)를 완료함에 후속하여, 상기 이동 동작을 실행하기 위해(committing) 더 구성되는
시스템.
컴퓨팅 환경에서 프로세서에 의한 서브-로지컬 유닛 네임(LUN) 데이터 이동(sub-Logical Unit Name (LUN) data migration)을 위한 컴퓨터 프로그램 제품에 있어서, 상기 컴퓨터 프로그램 제품은 그 안에 저장된 컴퓨터 읽기가능 프로그램 코드 부분들을 갖는 컴퓨터-읽기가능 스토리지 매체를 포함하고, 상기 컴퓨터 프로그램 코드 부분들은:
스토리지 컨트롤러와 소유 어플리케이션(an owning application) 사이의 인터페이스로서 사용할 소스 코드 기반 스펙(a source code -based specification)을 구현하여 상기 LUN 배후의(behind the LUN) 물리적 스토리지로부터 새로운 물리적 위치로 명시된 사이즈의 데이터(a specified size of data)를 이동시키기 위한(migrating) 제1 실행가능 부분(a first executable portion)을 포함하는
컴퓨터 프로그램 제품.
제18항에 있어서, 상기 컴퓨터 프로그램 코드 부분들은, 상기 명시된 사이즈의 데이터를 이동시킴(migrate)에 뒤따라서, 상기 새로운 물리적 위치를 식별하기 위해 가상 디스크 상의 상기 데이터 조각의 시작 논리적 블록 주소(a start Logical Block Address: LBA) 및 사이즈(size)와 타겟 물리적 스토리지 디스크립션(a target physical storage description)을 명시하기 위한(specifying) 제2실행가능 부분(a second executable portion)을 포함하는
컴퓨터 프로그램 제품.
제19항에 있어서, 상기 컴퓨터 프로그램 코드 부분들은 스토리지 풀들의 목록(a list of storage pools) 중 적어도 하나와 관련된 적어도 하나의 스토리지 특성(at least one storage characteristic)과 함께 상기 스토리지 컨트롤러에 의해서 지원되는 스토리지 풀들의 목록을 노출하기 위한(exposing) 제3실행가능 부분(a third executable portion)을 더 포함하는
컴퓨터 프로그램 제품.
제20항에 있어서, 상기 컴퓨터 프로그램 코드 부분들은 스토리지 풀들의 상기 노출된 목록의 타겟 스토리지 풀로 이동될 상기 데이터 조각의 상기 시작 LBA 및 명시된 사이즈로부터 데이터를 요청하는 인터페이스를 통해 콜(a call)을 수신하기 위한 제4실행가능 부분(a fourth executable portion)을 더 포함하는
컴퓨터 프로그램 제품.
제21항에 있어서, 상기 컴퓨터 프로그램 코드 부분들은 상기 타겟 스토리지 풀 상의 상기 데이터 조각을 위한 베스트 핏(a best fit)을 결정하기 위한 제5실행가능 부분(a fifth executable portion)을 더 포함하는
컴퓨터 프로그램 제품.
제22항에 있어서, 상기 컴퓨터 프로그램 코드 부분들은 상기 소유 어플리케이션에 투명한 백그라운드 프로세스로서, 상기 타겟 스토리지 풀로 상기 데이터 조각을, 이동 동작(a migration operation)으로서, 이동시키기 위한 제6실행가능 부분(a sixth executable portion)을 더 포함하는
컴퓨터 프로그램 제품.
제23항에 있어서, 상기 컴퓨터 프로그램 코드 부분들은 상기 타겟 스토리지 풀 상의 새로운 물리적 위치로 가상 디스크 맵(a virtual disk map)을 가리키기 위한(pointing) 제7실행가능 부분(a seventh executable portion)을 더 포함하는
컴퓨터 프로그램 제품.
제24항에 있어서, 상기 컴퓨터 프로그램 코드 부분들은, 상기 새로운 물리적 위치로 가상 디스크 맵(a virtual disk map)을 가리키는 단계(pointing)를 완료함에 후속하여, 상기 이동 동작을 실행하기 위한(committing) 제8실행가능 부분(an eighth executable portion)을 더 포함하는
컴퓨터 프로그램 제품.