KR101023585B1 - 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른데이터 관리 방법 - Google Patents
객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른데이터 관리 방법 Download PDFInfo
- Publication number
- KR101023585B1 KR101023585B1 KR1020080124279A KR20080124279A KR101023585B1 KR 101023585 B1 KR101023585 B1 KR 101023585B1 KR 1020080124279 A KR1020080124279 A KR 1020080124279A KR 20080124279 A KR20080124279 A KR 20080124279A KR 101023585 B1 KR101023585 B1 KR 101023585B1
- Authority
- KR
- South Korea
- Prior art keywords
- data
- iops
- response
- request frequency
- storage system
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
- H04L67/1078—Resource delivery mechanisms
- H04L67/108—Resource delivery mechanisms characterised by resources being split in blocks or fragments
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
본 발명은 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법에 관한 것으로, 클라이언트의 요청빈도가 증가하면 청크를 분할한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 일부 서버로 이동시켜 나머지 분할청크와 합쳐 보관하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법을 제공하고자 한다.
또한, 본 발명은 클라이언트의 요청빈도가 증가하면 청크를 복제한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 삭제하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법을 제공하고자 한다.
이를 위하여, 본 발명은, 데이터 관리 방법에 있어서, 데이터 저장단위에 대한 관리유형에 따라 해당 관리범위를 결정하는 결정 단계; 상기 데이터 저장단위에 대한 클라이언트 요청빈도를 측정하는 측정 단계; 및 상기 측정된 클라이언트 요청빈도 값이 속하는 상기 관리범위에 해당하는 관리유형에 따라 상기 데이터 저장단위를 관리하는 관리 단계를 포함하되, 상기 관리범위는, 데이터 서버에서 사용자 만족을 위해 계산한 응답 IOPS(Input Output Per Second) 값인 '제 1 응답값'과, 상기 제 1 응답값에 소정의 소수를 곱하여 계산한 응답 IOPS 값인 '제 2 응답값' 간에 형성되는 범위인 것을 특징으로 한다.
객체기반 스토리지 시스템, 클라이언트 요청빈도, 데이터 관리, 청크, 분할, 분산배치, 복제
Description
본 발명은 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법에 관한 것으로, 더욱 상세하게는 클라이언트의 요청빈도가 증가하면 청크를 분할한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 일부 서버로 이동시켜 나머지 분할청크와 합쳐 보관하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법에 관한 것이다.
또한, 본 발명은 다른 실시예로서, 클라이언트의 요청빈도가 증가하면 청크를 복제한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 삭제하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법에 관한 것이다.
이메일, 전자상거래 등과 같은 다양한 네트워크 기반 응용에 의해 생성되는 방대한 양의 데이터가 급격하게 증가함에 따라, 기업에서는 상기와 같이 급격히 증가하는 대량의 데이터를 가능한 많이 지속적으로 축적하기 위해 스토리지 시스템(storage system) 구축에 심혈을 기울이고 있다. 이는 기업의 중요한 비즈니스 프로세스를 지원하기 위한 데이터 관리가 조직 역량의 중추적인 요소로 평가되고 있기 때문이다. 하지만, 기업에서 활용되고 있는 스토리지 시스템 관련 기술은 여러 문제에 직면해 있다. 즉, 기업이 이미 보유하고 있는 이질적인 인터넷 환경으로 인해, 기업에서는 여러 곳에 산재하고 있는 스토리지 저장소들에 존재하는 정보들을 관리 및 활용하기가 매우 어렵다.
이에 따라, 대량의 데이터를 효율적으로 처리하기 위한 스토리지 시스템과 관련된 기술로서, 'DAS(Direct Attached Storage)', 'NAS(Network Attached Storage)', 'SAN(Storage Area Network)' 등이 제안되었다. 구체적으로, DAS는 블록기반의 스토리지 디바이스를 호스트 컴퓨터의 입출력 버스에 SCSI 혹은 IDE를 통하여 직접 연결한 구조인데, 고성능 및 강력한 데이터 보호 기능을 제공하지만 스토리지 디바이스의 확장성에 있어 제약이 존재하는 한계가 있다. NAS는 상이한 플랫폼을 갖는 호스트들에서 데이터를 공유할 수 있는 파일 서비스를 제공하기 위해, 파일이 스토리지 디바이스에 어떻게 저장되었는지를 기술하는 메타데이터를 하나의 서버에서 모두 관리하는 구조이며, 모든 파일에 대한 입출력이 하나의 서버를 통해 이루어지기 때문에 파일 서버에 병목 현상이 발생하는 문제가 있다. SAN은 스토리지 디바이스 연결성 제약과 스토리지 디바이스의 공유 문제를 해결하고, 더욱 많은 클라이언트 호스트와 스토리지 디바이스를 지원하기 위해 빠르고 확장성이 높은 상 호 연결을 지원하는 구조이며, 파일 시스템과 같은 스토리지 응용이 데이터를 공유하기 위해 서로 다른 플랫폼들에서 파일 시스템의 메타데이터를 이해할 수 있어야 하고 별도의 고가 장비들이 필요로 하기 때문에 스토리지 확장성에 제한이 있다.
앞서 언급된 DAS, NAS 및 SAN이 갖는 한계를 극복하기 위해, '객체기반 스토리지 시스템(Object-Based Storage system)'이 제안되었다. 여기서, 객체기반 스토리지 시스템은 스토리지 환경에서 사용하던 데이터 처리 경로를 메타데이터 영역 및 실제 데이터 영역으로 구분함으로써, 기존의 NAS 및 SAN이 갖는 개념들을 객체 인터페이스를 통해 통합할 뿐만 아니라, 고성능, 높은 확장성, 플랫폼간 데이터 공유 등과 같은 스토리지 환경을 위한 조건을 만족시킨다.
그런데, 종래의 객체기반 스토리지 시스템에서는 클라이언트의 요청빈도에 상관없이 데이터 서버의 데이터 저장단위인 청크(chunk)의 크기와 그 분할횟수를 일정하게 고정시켜 저장함으로써, 클라이언트의 데이터 읽기/쓰기(read/write) 요청빈도에 적절히 대응할 수 없었다. 이와 같이, 종래의 객체기반 스토리지 시스템에서는 데이터 읽기/쓰기 요청빈도가 증가함에 따라, 고정된 크기의 청크를 복제(replica)하여 타 데이터 서버에 배치하여 입출력 분산을 통해 일정 IOPS(Input Output Per Second)를 제공할 수 있었다. 이는 종래의 객체기반 스토리지 시스템에서 복제를 통해 데이터의 보존성 및 가용성을 향상시킬 수 있었으나, 데이터 서버의 저장공간을 비효율적으로 사용하는 한계가 있다.
따라서 종래의 객체기반 스토리지 시스템에서는 데이터의 보존성 및 가용성을 보장하면서도 저장공간의 낭비를 최소화할 뿐만 아니라, 클라이언트의 데이터 읽기/쓰기 요청빈도를 반영하면서 능동적으로 IOPS를 일정하게 제공할 수 있는 기술이 제안될 필요가 더욱 절실하다.
따라서 상기와 같은 종래 기술은 객체기반 스토리지 시스템에서 데이터의 보존성 및 가용성을 보장할 수 있었으나 데이터 서버의 저장공간을 낭비하게 되는 문제점이 있으며, 이러한 문제점을 해결하고자 하는 것이 본 발명의 과제이다.
따라서 본 발명은 클라이언트의 요청빈도가 증가하면 청크를 분할한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 일부 서버로 이동시켜 나머지 분할청크와 합쳐 보관하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법을 제공하는데 그 목적이 있다.
또한, 본 발명은 클라이언트의 요청빈도가 증가하면 청크를 복제한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 삭제하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법을 제공하는데 그 목적이 있다.
본 발명의 목적들은 이상에서 언급한 목적으로 제한되지 않으며, 언급되지 않은 본 발명의 다른 목적 및 장점들은 하기의 설명에 의해서 이해될 수 있으며, 본 발명의 실시예에 의해 보다 분명하게 알게 될 것이다. 또한, 본 발명의 목적 및 장점들은 특허 청구 범위에 나타낸 수단 및 그 조합에 의해 실현될 수 있음을 쉽게 알 수 있을 것이다.
상기 목적을 달성하기 위한 본 발명은, 데이터 관리 방법에 있어서, 데이터 저장단위에 대한 관리유형에 따라 해당 관리범위를 결정하는 결정 단계; 상기 데이터 저장단위에 대한 클라이언트 요청빈도를 측정하는 측정 단계; 및 상기 측정된 클라이언트 요청빈도 값이 속하는 상기 관리범위에 해당하는 관리유형에 따라 상기 데이터 저장단위를 관리하는 관리 단계를 포함하되, 상기 관리범위는, 데이터 서버에서 사용자 만족을 위해 계산한 응답 IOPS(Input Output Per Second) 값인 '제 1 응답값'과, 상기 제 1 응답값에 소정의 소수를 곱하여 계산한 응답 IOPS 값인 '제 2 응답값' 간에 형성되는 범위인 것을 특징으로 한다.
삭제
상기와 같은 본 발명은, 클라이언트의 요청빈도가 증가하면 청크를 분할한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 일부 서버로 이동시켜 나머지 분할청크와 합쳐 보관함으로써, 데이터 서버의 저장공간을 효율적으로 이용할 수 있는 효과가 있다.
또한, 본 발명은 클라이언트의 요청빈도가 증가하면 청크를 복제한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 삭제함으로써, 데이터 서버의 저장공간을 효율적으로 이용할 수 있는 효과가 있다.
상술한 목적, 특징 및 장점은 첨부된 도면을 참조하여 상세하게 후술되어 있는 상세한 설명을 통하여 보다 명확해 질 것이며, 그에 따라 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명의 기술적 사상을 용이하게 실시할 수 있을 것이다. 또한, 본 발명을 설명함에 있어서 본 발명과 관련된 공지 기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에 그 상세한 설명을 생략하기로 한다. 이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 실시예를 상세히 설명하기로 한다.
도 1은 본 발명이 적용되는 객체기반 스토리지 시스템에 대한 일실시예 구성도이다.
도 1에 도시된 바와 같이, 본 발명이 적용되는 객체기반 스토리지 시스템은, 데이터에 대한 접속을 요청하는 적어도 하나 이상의 클라이언트(110), 클라이언트(110)의 요청을 중계하는 클라이언트 서버(120), 데이터가 어떻게 저장되어 있는지를 기술하는 메타데이터를 관리함으로써 클라이언트 서버(120)로부터 전달받은 정보를 기반으로 데이터의 위치를 찾아주는 메타데이터 서버(130), 실제 데이터를 저장하는 적어도 둘 이상의 데이터 서버(140), 데이터 서버(140)의 공간절약을 위해 별도의 데이터를 압축하여 저장하는 압축 데이터 서버(150)를 포함한다.
본 발명의 객체기반 스토리지 시스템은 서버 기반 컴퓨팅(Server Based Computing) 서비스, IPTV 서비스, 이메일 서비스, 웹스토리지(web storage) 서비스 등과 같이 저가형 고가용성 대용량 저장 시스템으로 적용될 수 있다.
이하, 사용자가 클라이언트(110)를 통해 본 발명의 객체기반 스토리지 시스템에 저장된 데이터에 대한 접속을 수행하는 과정에 대해 도 1을 참조하여 간략히 설명한다.
먼저, 클라이언트(110)는 임의의 데이터에 대한 접속을 클라이언트 서버(102)로 요청한다(①).
다음으로, 클라이언트 서버(120)는 클라이언트(110)의 요청을 분석하여 해당 데이터의 위치에 대한 정보를 메타데이터 서버(130)로 요청한다(②). 이때, 클라이언트 서버(120)는 '웹서비스(WEB SERVICE)' 또는 '포직스(POSIX API)'와 같은 인터페이스 환경을 통해 클라이언트(110)와 통신한다.
다음으로, 메타데이터 서버(130)는 데이터 서버(140)에서 해당 데이터의 위치를 파악한 후, 클라이언트(110) 및 데이터 서버(140) 간에 연결될 수 있도록 하는데, 사업자의 정책에 따라 클라이언트(110) 및 데이터 서버(140) 간 직접적인 연결이 이루어지도록 하거나, 클라이언트 서버(120)를 통해 클라이언트(110) 및 데이터 서버(140) 간의 연결이 이루어지도록 한다(③).
다음으로, 클라이언트(110)는 데이터 서버(140)와 직접 연결되거나 클라이언트 서버(120)를 경유하여 데이터 서버(140)와 연결됨에 따라, 데이터 서버(140)에 저장된 해당 데이터에 접속하고, 데이터 관리기능(예를 들어, 저장기능, 삭제기능, 수정기능, 열람기능 등)을 수행한다(④). 이때, 클라이언트(110)에 의한 저장기능 및 삭제기능이 수행되는 경우에는, 데이터 서버(140)가 메타데이터 서버(130)로 그 수행결과를 통보한다. 이는 정책적으로 즉시 이루어지거나, 성공적으로 수행된 후 최한시에 이루어질 수 있다.
한편, 압축 데이터 서버(150)는 최근 최소 사용(Least Recently Used: LRU) 알고리즘에 기초하여 데이터 서버(140)의 데이터 중 소정의 기간에 액세스되지 않은 데이터를 압축하여 보관함으로써, 데이터의 가용성 및 보존성을 높이면서 데이터 서버(140)의 저장공간을 절약할 수 있다. 여기서, 압축 데이터 서버(150)는 데이터 서버(140)와 직접적 혹은 메타데이터 서버(130)를 통해 간접적으로 연결되어 있다.
특히, 본 발명의 스토리지 시스템에서는 클라이언트(110)의 요청빈도에 따라, 데이터 서버(140)에 저장된 데이터를 유형별로 관리한다. 이를 위해, 본 발명의 스토리지 시스템에서는 클라이언트(110)의 단위시간당 요청빈도(즉, 읽기/쓰기의 요청빈도)에 따라 '요청빈도가 증가하면 청크를 소정의 크기로 분할한 각 분할청크를 데이터 서버(140)에 분산배치하는 관리유형을 적용하거나, 요청빈도가 감소하면 각 분할청크를 일부 서버로 이동하여 나머지 분할청크와 합쳐 보관하는 관리유형을 적용하는 방식(후술할 도 2 참조)' 또는 '요청빈도가 증가하면 청크를 소정의 배수로 복제한 각 복제청크를 데이터 서버(140)에 분산배치하는 관리유형을 적용하거나, 요청빈도가 감소하면 복제청크 중 일부를 삭제하는 관리유형을 적용하는 방식(후술할 도 3 참조)'을 이용함으로써, 데이터 서버(140)에서 클라이언트(110)로 일정한 IOPS(Input Output Per Second)를 제공하고 데이터에 대한 저장 및 열람 속도를 향상시킬 수 있다.
이를 위해, 본 발명의 스토리지 시스템에서는 데이터 서버(140)의 청크를 분할 또는 복제할지를 판단하기 위한 기준[즉, 데이터 서버(140)의 요청빈도가 어느 정도까지 증가하면 청크를 분할 또는 복제할지를 판단하기 위한 기준]으로서 '데이터 서버(140)에서 사용자 만족을 위해 계산한 응답 IOPS'[이하 "제 1 응답 IOPS(Ap)"라 함]와, 데이터 서버(140)의 분할청크를 합침 또는 삭제할지를 판단하기 위한 기준[즉, 데이터 서버(140)의 요청빈도가 어느 정도까지 감소하면 분할청크를 합침 또는 삭제할지를 판단하기 위한 기준]으로서 '제 1 응답 IOPS(Ap)에 소정의 소수(일례로, 0.1∼0.5 범위에 속하는 소수, 본 발명에서는 0.5로 편의상 설명하는데 즉, Tp=Ap/2이라 가정함)를 곱하여 계산한 IOPS'[이하 "제 2 응답 IOPS(Tp)"라 함]를 설정한다. 바람직하게는, 제 2 응답 IOPS(Tp)를 계산하기 위한 소정의 소수는, 분할청크를 이동한 후 합치는 과정(또는 복제청크를 삭제하는 과정)을 지나치게 수행하는 것을 방지하기 위하여 0.5 이하로 설정하도록 한다.
또한, 본 발명의 스토리지 시스템에서는 클라이언트(110)에서 특정 청크에 대한 단위시간당 요청빈도에 해당되는 값으로서 '데이터 서버(140)에 대한 요청 IOPS'[이하 "요청 IOPS(Dp)"라 함]를 측정한다.
이에 따라, 본 발명의 스토리지 시스템에서는 '제 1 응답 IOPS(Ap)' 및 '제 2 응답 IOPS(Tp)' 간에 결정되는 관리범위에서 '요청 IOPS(Dp)'가 어느 범위에 속하는지를 판단함으로써, 데이터 서버(140)에 저장된 데이터를 관리유형에 따라 가변적으로 관리한다.
먼저, 본 발명의 클라이언트(110)의 요청빈도에 따라 '요청빈도가 증가하면 청크를 소정의 크기로 분할한 각 분할청크를 데이터 서버(140)에 분산배치하고, 요청빈도가 낮아지면 각 분할청크를 일부 서버로 이동하여 나머지 분할청크와 합쳐 보관하는 방식'에 대해 도 2를 참조하여 상세히 설명하기로 한다.
도 2는 본 발명에 따른 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 가변적 데이터 관리 방법에 대한 일실시예 흐름도이다.
우선, 본 발명에 따른 객체기반 스토리지 시스템에서는 제 1 응답 IOPS(Ap) 및 제 2 응답 IOPS(Tp)를 미리 설정한다(S201). 여기서, 제 1 응답 IOPS(Ap)의 도출과정에 대해서는 도 4 및 도 5를 참조하여 상세히 후술하기로 한다.
이후, 스토리지 시스템은 데이터 서버(140)의 특정 청크에 대한 요청 IOPS(Dp)를 측정한다(S202). 여기서, 요청 IOPS(Dp)는 시스템 관리자의 요청에 의해 측정되거나, 주기적으로 측정될 수 있다. 또한, 요청 IOPS(Dp)는 측정순간의 값이거나, 적어도 하루 이상의 일수를 대상으로 산출한 평균값으로 측정될 수 있다.
이후, 스토리지 시스템은 요청 IOPS(Dp)가 제 1 응답 IOPS(AP) 및 제 2 응답 IOPS(Tp) 간에 형성되는 범위에서 어느 범위에 속하는지를 판단한다(S203). 이때, 제 1 응답 IOPS(Ap) 및 제 2 응답 IOPS(Tp) 간에 결정되는 관리범위에는, 요청 IOPS(Dp)>제 1 응답 IOPS(Ap), 제 2 응답 IOPS(Tp)≤요청 IOPS(Dp)≤제 1 응답 IOPS(Ap), 요청 IOPS(Dp)<제 2 응답 IOPS(Tp)가 있다.
먼저, 요청 IOPS(Dp)가 제 1 응답 IOPS(Ap)보다 크면(Dp>Ap), 스토리지 시스템은 데이터 서버(140)의 특정 청크에 대한 요청빈도가 증가한 상태이므로, 특정 청크를 1/n(n은 적어도 2이상의 자연수)씩 분할하여 데이터 서버(140)에 분산 배치한다(S204). 이때, 스토리지 시스템은 데이터 서버(140)의 저장용량의 상태를 확인하면서 저장용량이 낮은 상태의 서버부터 순차적으로 분할청크를 분산 배치하거나, 데이터 서버(140)의 분할청크를 수용할 수 있는지만을 확인하여 임의로 분할청크를 분산 배치할 수 있다. 일례로, n이 3이고, 데이터 서버(140)가 저장용량이 낮은 순서로 A, B, C, D와 같다면, 데이터 서버(140) A, B 및 C 각각에 대해 분할청크를 분산 배치한다.
또한, 스토리지 시스템은 요청 IOPS(Dp)를 재측정한 결과로, 요청 IOPS(Dp)가 제 1 응답 IOPS(Ap)보다 여전히 크면 각각의 분할청크를 재분할하여 데이터 서버(140)에 분산 배치하는 과정을 반복수행하고(Dp>Ap), 요청 IOPS(Dp)가 제 2 응답 IOPS(Tp)보다 작지 않고 제 1 응답 IOPS(Ap)보다 크지 않으면 종료한다(Tp≤Dp≤Ap).
다음으로, 요청 IOPS(Dp)가 제 2 응답 IOPS(Tp)보다 작으면(Dp<Tp), 스토리지 시스템은 데이터 서버(140)의 특정 분할청크에 대한 요청빈도가 감소한 상태이므로, 특정 분할청크의 세트를 나머지 분할청크의 세트가 있는 데이터 서버(140)로 이동시켜 나머지 분할청크의 세트와 합친다(S205). 이때, 분할청크를 합치는 과정은 요청 IOPS(Dp)가 제 2 응답 IOPS(Tp)보다 작은 경우를 만족하는 데이터 서버(140)에서 이루어지므로, 전체 분할청크의 수가 변하거나(홀수개에서 짝수개로), 일부 데이터 서버(140)에서 각각의 분할청크들이 합쳐져 편중될 수 있다.
또한, 스토리지 시스템은 데이터 서버(140)의 요청 IOPS(Dp)를 재측정한 결 과로 요청 IOPS(Dp)가 제 2 응답 IOPS(Tp)보다 작으면(Dp<Tp), 이를 만족하는 데이터 서버(140)의 특정 분할청크 세트를 나머지 분할청크 세트가 있는 데이터 서버(140)로 이동시켜 합치는 과정을 수행한다. 반면에, 스토리지 시스템은 데이터 서버(140)의 요청 IOPS(Dp)를 재측정한 결과로 요청 IOPS(Dp)가 제 2 응답 IOPS(Tp)보다 작지 않고 제 1 응답 IOPS(Ap)보다 크지 않으면(Tp≤Dp≤Ap), 종료한다.
일반적으로, 스토리지 시스템에서는 데이터 서버(140)의 특정 청크에 대한 요청빈도가 증가하면 Dp>Ap를 만족하는 동안 특정 청크에서 있어 '분할 및 배치 과정'(S204)을 반복수행하고 Tp≤Dp≤Ap를 만족하면 종료한다. 이후, 스토리지 시스템에서는 소정의 시간이 경과하면 청크에 대한 요청빈도가 감소하므로, Dp<Tp를 만족하는 동안 분할청크에 있어 '이동 및 합칩 과정'(S205)을 반복수행하고 Tp≤Dp≤Ap를 만족하면 종료한다.
한편, 본 발명의 클라이언트(110)의 요청빈도에 따라 '요청빈도가 증가하면 청크를 소정의 배수로 복제한 각 복제청크를 데이터 서버(140)에 분산배치하고, 요청빈도가 낮아지면 복제청크 중 일부를 삭제하는 방식'에 대해 도 3을 참조하여 상세히 설명하기로 한다.
도 3은 본 발명에 따른 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 가변적 데이터 관리 방법에 대한 다른 실시예 흐름도이다.
도 3에서 S301 단계 내지 S303 단계 각각은 도 2에서 S201 단계 내지 S203 단계에 대응되므로, 자세한 설명을 생략하더라도 당업자가 쉽게 이해할 수 있을 것이다.
도 2와 마찬가지로, 스토리지 시스템은 요청 IOPS(Dp)가 제 1 응답 IOPS(AP) 및 제 2 응답 IOPS(Tp) 간에 형성되는 범위에서 어느 범위에 속하는지를 판단한다(S303). 또한, 제 1 응답 IOPS(Ap) 및 제 2 응답 IOPS(Tp) 간에 형성되는 범위에는, 요청 IOPS(Dp)>제 1 응답 IOPS(Ap), 제 2 응답 IOPS(Tp)≤요청 IOPS(Dp)≤제 1 응답 IOPS(Ap), 요청 IOPS(Dp)<제 2 응답 IOPS(Tp)가 있다.
먼저, 요청 IOPS(Dp)가 제 1 응답 IOPS(Ap)보다 크면(Dp>Ap), 스토리지 시스템은 데이터 서버(140)의 특정 청크에 대한 요청빈도가 증가한 상태이므로, 특정 청크를 n(n은 적어도 2이상의 자연수)배씩 복제하여 데이터 서버(140)에 분산 배치한다(S304). 이때, 스토리지 시스템은 데이터 서버(140)의 저장용량의 상태를 확인하면서 저장용량이 낮은 상태의 서버부터 순차적으로 복제청크를 분산 배치하거나, 데이터 서버(140)의 복제청크를 수용할 수 있는지만을 확인하여 임의로 복제청크를 분산 배치할 수 있다. 일례로, n이 3이고, 데이터 서버(140)가 저장용량이 낮은 순서로 A, B, C, D와 같다면, 데이터 서버(140) A, B 및 C 각각에 대해 복제청크를 분산 배치한다.
또한, 스토리지 시스템은 데이터 서버(140)의 요청 IOPS(Dp)를 재측정한 결과로 요청 IOPS(Dp)가 제 1 응답 IOPS(Ap)보다 크면(Dp>Ap), 청크를 재복제하여 복제청크가 저장되지 않은 데이터 서버(140)로 분산 배치하는 과정을 반복수행한다. 이때, 스토리지 시스템은 관리자의 정책에 따라 원본청크를 재복제하거나, 각각의 복제청크를 재복제할 수 있다. 반면에, 스토리지 시스템은 데이터 서버(140)의 요청 IOPS(Dp)를 재측정한 결과로 요청 IOPS(Dp)가 제 2 응답 IOPS(Tp)보다 작지 않고 제 1 응답 IOPS(Ap)보다 크지 않으면(Tp≤Dp≤Ap), 종료한다.
다음, 요청 IOPS(Dp)가 제 2 응답 IOPS(Tp)보다 작으면(Dp<Tp), 스토리지 시스템은 데이터 서버(140)의 특정 복제청크에 대한 요청빈도가 감소한 상태이므로 복제청크를 삭제한다(S305). 이때, 스토리지 시스템은 저장용량의 상태를 확인하여 여유공간이 없는 데이터 서버(140)부터 우선적으로 복제청크를 삭제하는 것이 바람직하다.
또한, 스토리지 시스템은 데이터 서버(140)의 요청 IOPS(Dp)를 재측정한 결과로 요청 IOPS(Dp)가 제 2 응답 IOPS(Tp)보다 작으면(Dp<Tp), 이를 만족하는 데이터 서버(140)의 특정 복제청크만 삭제한다. 반면에, 스토리지 시스템은 데이터 서버(140)의 요청 IOPS(Dp)가 제 2 응답 IOPS(Tp)보다 작지 않고 제 1 응답 IOPS(Ap)보다 크지 않으면(Tp≤Dp≤Ap), 종료한다.
일반적으로, 스토리지 시스템에서는 데이터 서버(140)의 특정 청크에 대한 요청빈도가 증가하면 Dp>Ap를 만족하는 동안 특정 청크에서 있어 '복제 및 배치 과정'(S304)을 반복수행하고 Tp≤Dp≤Ap를 만족하면 종료한다. 이후, 스토리지 시스템에서는 소정의 시간이 경과하면 청크에 대한 요청빈도가 감소하므로, Dp<Tp를 만족하는 동안 분할청크에 있어 '삭제 과정'(S305)을 반복수행하고 Tp≤Dp≤Ap를 만족하면 종료한다. 이하, 제 1 응답 IOPS(Ap)를 계산하는 과정에 대하여 상세히 설명한다.
도 4는 제 1 응답 IOPS(Ap)의 도출과정에 대한 흐름도이다.
스토리지 시스템에서는 데이터 서버(140)의 접속응답시간(Rs) 및 응답만족도(S)를 계산한 후(S401, S402), 이를 통해 제 1 응답 IOPS(Ap)를 도출한다(S403).
이에 대해 구체적으로 설명하면, 먼저 데이터 서버(140)의 접속응답시간(Rs)(sec)은 하기 [수학식 1]을 이용하여 계산한다(S401).
여기서, π는 데이터 서버(140)의 최대 IOPS, ρ는 이중 가용 IOPS비를 나타낸다. 일반적으로, ρ는 π의 50%∼80%로 설정된다.
다음, 데이터 서버(140)의 응답만족도(S)는 하기 [수학식 2]를 이용하여 계산한다(S402).
여기서, R은 고객서비스 SLA(Service Level Agreement) 사항인 최소한의 데이터 서버(140)의 보장응답시간을 나타낸다. R은 사용자의 데이터 접속 요청빈도수 및 요구 IOPS에 따라 별도로 규정할 수 있다. 일반적으로, 웹에서 사용자의 요청(request)당 전체 IO 응답시간은 2초 이내가 요구된다.
마지막으로, 데이터 서버(140)의 제 1 응답 IOPS(Ap)는 하기 [수학식 3]을 이용하여 도출한다(S403).
여기서, Κ는 단위 초당 가입자의 요청수이고, Φ는 청크당 IOPS이고, τ(bytes)는 초기 청크 크기이고, N은 최적 블록 크기이다. 특히, 전술한 데이터 서버(140)의 최대 IOPS(π) 및 최적 블록 크기(N)는 후술할 도 5를 통해 도출한다.
도 5a는 최대 IOPS(π) 및 최적 블록 크기(N)의 도출과정에 대한 흐름도이다.
스토리지 시스템에서는 최대 IOPS(π) 및 최적 블록 크기(N)를 도출하기 위 해, 단위 블록 크기의 배수(일례로, 2배씩 증가하는 경우)에 해당하는 측정데이터를 데이터 서버(140)로 전송한 후 측정한 '최대 쓰기(write) IOPS'와 이때 측정데이터에 대한 '블록 크기'의 내적(곱)을 이용한다. 이때, 스토리지 시스템은 연속한 3개의 내적(곱) M1, M2 및 M3이 있을 때, 인접한 2개의 내적(곱)간의 차 (M3-M2), (M2-M1)를 서로 비교하여 최대 IOPS(π) 및 최적 블록 크기(N)를 도출한다. 여기서, 본 발명에서는 최대 IOPS(π)를 도출하기 위해, 데이터의 연속적인(sequential) 분포와 읽기(read) IOPS를 이용하는 경우에 더 나은 내적을 계산할 수 있으나, 최대 쓰기 IOPS를 이용함으로써 열악한 상황을 가정한다. 일반적으로, 쓰기 IOPS와 읽기 IOPS는 비례한다.
이하, 최대 IOPS(π) 및 최대 블록 크기(N)의 도출과정에 대해 상세히 설명한다.
먼저, 스토리지 시스템은 최대 IOPS(π)를 측정하기 위한 데이터 서버(140)를 선택하고, 데이터 서버(140)의 저장단위로서 단위 블록 크기(B1)를 설정한다(S501). 이때, 스토리지 시스템은 전체 데이터 서버(140)의 특성이 동일한 경우에 임의의 데이터 서버를 선택하거나 그렇지 않을 경우에 특정 데이터 서버를 선택한다. 또한, 스토리지 시스템은 단위 블록 크기로서 1K, 2K, 4K 등과 같이 다양하게 설정할 수 있으며, 이는 스토리지 시스템 관리자에 의해 정책적으로 결정될 수 있다.
다음으로, 스토리지 시스템은 1개의 단위 블록 크기(N1=B1)에 해당하는 측정 데이터를 상기 S501 단계에서 선택한 데이터 서버(140)로 전송한 후 측정데이터의 IOPS(I1)를 측정하고, 측정데이터의 블록 크기인 B1과 측정한 IOPS인 I1의 내적(곱)인 M1(=B1*I1)을 계산하여 기록한다(S502). 이때, 스토리지 시스템은 데이터 서버(140)의 임의의 위치에 해당 측정데이터를 기록한다.
다음으로, 스토리지 시스템은 이전 측정데이터의 2배(즉, N2=2*B2)에 해당하는 측정데이터를 상기 S501 단계에서 선택한 데이터 서버(140)로 전송한 후 측정데이터의 IOPS(I2)를 측정하고, 측정데이터의 블록크기인 N2과 측정한 IOPS인 I2의 내적(곱)인 M2(=N2*I2)를 계산하여 기록한다(S503).
다음으로, 스토리지 시스템은 이전 측정데이터의 2배(N3=2*N2)에 해당하는 측정데이터를 상기 S501 단계에서 선택한 데이터 서버(140)로 전송한 후 측정데이터의 IOPS(I3)를 측정하고, 측정데이터의 블록크기인 N3과 측정한 IOPS인 I3의 내적(곱)인 M3(=N3*I3)를 계산하여 기록한다(S504).
한편, 스토리지 시스템은 상기와 같이 연속한 세 개의 내적(곱)(즉, M1, M2 및 M3)을 계산하여(S502 내지 S504), 연속한 내적 간의 차 'M1과 M2의 차(즉, M2-M1)(S1)'와 'M2와 M3의 차(즉, M3-M2)(S2)'를 비교한다(S505). 이때, S1>S2이면, 스토리지 시스템은 최대 IOPS(π)로서 가장 최근에 측정한 IOPS인 'I3'로 도출하고, 최 대 블록 크기(N)로서 가장 최근에 측정데이터의 블록 크기인 N3/2인 N2(즉, N3=2*N2)로 도출한다(S506). 반면에, S1<S2이면, 스토리지 시스템은 M4를 계산하여 기록하는 과정 즉, 이전 측정데이터의 2배(N4=2*N3)에 해당하는 측정데이터를 상기 S501 단계에서 선택한 데이터 서버(140)로 전송한 후 측정데이터의 IOPS(I4)를 측정하고, 측정데이터의 블록크기인 N4과 측정한 IOPS인 I4의 내적(곱)인 M4(=N4*I4)를 계산하여 기록한다(S507).
이후, 스토리지 시스템은 'M2과 M3의 차(즉, M3-M2)(S2)'와 'M3와 M4의 차(즉, M4-M3)(S3)'를 비교하여(S508), S2>S3이면, 스토리지 시스템은 최대 IOPS(π)로서 가장 최근에 측정한 IOPS인 'I4'로 도출하고, 최대 블록 크기(N)로서 가장 최근에 측정데이터의 블록 크기인 N4/2인 N3(즉, N4=2*N3)로 도출한다(S509). 반면에, S2<S3이면, 스토리지 시스템은 다시 M5를 계산하는 과정을 수행한 후 내적 간의 차를 비교하는 과정을 다시 수행한다(S510). 이후의 과정은 당업자가 S508 단계 내지 S511 단계와 같은 과정을 참조하여 쉽게 유추할 수 있는 과정으로서, 자세한 설명을 생략하기로 한다.
특히, 스토리지 시스템은 스토리지 시스템은 연속한 내적 간의 차인 {S1,…,Sk}(k≥2인 자연수)의 집합 중에서 Sk -1이 최대일 때, 최대 IOPS(π) 및 최적 블 록 크기(N)를 도출하는 특징이 있다. 전술한 S509 단계에서 스토리지 시스템이 최대 IOPS(π) 및 최적 블록 크기(N)를 도출한다고 가정하면, 이때 연속한 내적 간의 차로 이루어진 집합이 {S1,S2,S3}이므로 S1, S2 및 S3에서 S2가 최대가 된다. 즉, S509 단계에서 최대 IOPS(π) 및 최적 블록 크기(N)를 도출하기 위해서는, S1<S2를 만족하고 S2>S3를 만족해야 하므로, 결국 S1<S2>S3와 같이 S2가 최대가 되어야 한다.
따라서 S510 단계 이후에, 스토리지 시스템은 연속한 내적 간의 차인 Sk의 집합 중에서 Sk -1이 최대일 때까지 S507 단계 내지 S510 단계와 같은 과정을 반복수행한 후 최대 IOPS(π) 및 최적 블록 크기(N)를 도출한다.
도 5b는 상기 도 5a에 대한 상세 흐름도이다.
스토리지 시스템은 최대 IOPS(π) 및 최대 블록 크기(N)의 도출과정을 도 5b에 도시된 바와 같이 구체적으로 구현할 수 있다.
앞서 언급한 바와 같이, 스토리지 시스템은 최대 IOPS(π) 및 최대 블록 크기(N)를 도출할 데이터 서버(140)를 선택하고, 데이터 서버(140)의 저장 기본 단위인 단위 블록 크기(B1)를 선택한다(S551).
다음으로, 스토리지 시스템은 1개의 단위 블록 크기에 해당하는 측정데이터(B1)를 전송하여 IOPS(I1)를 측정기록하고, 블록 크기(B1) 및 IOPS(I1)의 내적(곱) 인 M1(=B1*I1)을 기록한다(S552).
다음으로, 스토리지 시스템은 2배의 단위 블록 크기에 해당하는 측정데이터(N2=2*B1)를 전송하여 IOPS(I2)를 측정기록하고, 블록 크기(N2) 및 IOPS(I2)의 내적(곱)인 M2(=N2*I2)를 기록한다(S553). 이때, 스토리지 시스템은 M2와 M1의 차를 Smax(=M2-M1)에 넣고 MN-1에 M2를 대입한다(S554).
다음, 스토리지 시스템은 4배의 단위 블록 크기에 해당하는 측정데이터(N=2*N2)를 전송하여 IOPS(IN)를 측정기록하고, 블록크기(N) 및 IOPS(IN)의 내적(곱)인 MN(=N*IN)을 기록한다(S555). 이때, 스토리지 시스템은 MN 과 MN-1 차를 SN(=MN-MN-1)에 대입한다(S556).
한편, 스토리지 시스템은 SN과 Smax를 비교하여 SN이 Smax보다 크면(S557), Smax에 SN를 대입하고 MN-1에 MN을 대입하여(S558), 다시 S555 단계로 이동하여 블록 크기를 2배로 하여 SN과 이전의 Smax를 비교하는 과정을 반복한다. 여기서, 스토리지 시스템은 SN과 Smax를 비교하여 SN이 Smax보다 작으면(S557), 최대 블록 크기가 이전의 N의 1/2이고 최대 IOPS가 IN이 된다(S559).
도 6a는 본 발명에 따른 청크분할 및 분산저장에 대한 예시도이다.
도 6a에 도시된 바와 같이, 스토리지 시스템은 청크1을 1/2로 분할한 후 데이터 서버(140)에 속한 데이터 서버1(즉, 청크1_1) 및 데이터 서버3(즉, 청크1_2)에 각각 분산저장하고, 청크2를 1/2로 분할한 후 데이터 서버(140)에 속한 데이터 서버2(즉, 청크2_1) 및 데이터 서버4(즉, 청크2_2)에 각각 분산저장한다.
도 6b는 본 발명에 따른 청크합침 및 집중저장에 대한 예시도이다.
도 6b에 도시된 바와 같이, 스토리지 시스템은 사용자의 접속빈도 및 응답시간의 변화로 인해 데이터 서버1의 청크1_1 및 데이터 서버3의 청크1_2를 합친 후 데이터 서버1에 청크1로 집중저장하고, 데이터 서버2의 청크2_1 및 데이터 서버4의 청크2_2를 합친 후 데이터 서버2의 청크2로 집중저장한다. 이때, 스토리지 시스템은 압축 데이터 서버(150)에 상기와 같이 합친 후 청크1 및 청크2를 저장할 수도 있다.
도 7a는 본 발명에 따른 청크복제 및 분산저장에 대한 예시도이다.
도 7a에 도시된 바와 같이, 스토리지 시스템은 청크1을 2배로 복제한 후 데이터 서버(140)에 속한 데이터 서버1(즉, 청크1) 및 데이터 서버3(즉, 청크1)에 각각 분산저장하고, 청크2를 2배로 복제한 후 데이터 서버(140)에 속한 데이터 서버2(즉, 청크2) 및 데이터 서버4(즉, 청크2)에 각각 분산저장한다.
도 7b는 본 발명에 따른 청크삭제에 대한 예시도이다.
도 7b에 도시된 바와 같이, 스토리지 시스템은 사용자의 접속빈도 및 응답시간의 변화로 인해 데이터 서버3의 청크1을 삭제하고, 데이터 서버4의 청크2를 삭제 한다.
한편, 전술한 바와 같은 본 발명의 방법은 컴퓨터 프로그램으로 작성이 가능하다. 그리고 상기 프로그램을 구성하는 코드 및 코드 세그먼트는 당해 분야의 컴퓨터 프로그래머에 의하여 용이하게 추론될 수 있다. 또한, 상기 작성된 프로그램은 컴퓨터가 읽을 수 있는 기록매체(정보저장매체)에 저장되고, 컴퓨터에 의하여 판독되고 실행됨으로써 본 발명의 방법을 구현한다. 그리고 상기 기록매체는 컴퓨터가 판독할 수 있는 모든 형태의 기록매체를 포함한다.
이상에서 설명한 본 발명은, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 있어 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 여러 가지 치환, 변형 및 변경이 가능하므로 전술한 실시예 및 첨부된 도면에 의해 한정되는 것이 아니다.
도 1은 본 발명이 적용되는 객체기반 스토리지 시스템에 대한 일실시예 구성도,
도 2는 본 발명에 따른 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 가변적 데이터 관리 방법에 대한 일실시예 흐름도,
도 3은 본 발명에 따른 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 가변적 데이터 관리 방법에 대한 다른 실시예 흐름도,
도 4는 제 1 응답 IOPS(Ap)의 도출과정에 대한 흐름도,
도 5a는 최대 IOPS(π) 및 최적 블록 크기(N)의 도출과정에 대한 흐름도,
도 5b는 상기 도 5a에 대한 상세 흐름도,
도 6a는 본 발명에 따른 청크분할 및 분산저장에 대한 예시도,
도 6b는 본 발명에 따른 청크합침 및 집중저장에 대한 예시도,
도 7a는 본 발명에 따른 청크복제 및 분산저장에 대한 예시도,
도 7b는 본 발명에 따른 청크삭제에 대한 예시도이다.
* 도면의 주요 부분에 대한 부호의 설명
110 : 클라이언트 120 : 클라이언트 서버
130 : 메타데이터 서버 140 : 데이터 서버
150 : 압축 데이터 서버
Claims (9)
- 삭제
- 데이터 관리 방법에 있어서,데이터 저장단위에 대한 관리유형에 따라 해당 관리범위를 결정하는 결정 단계;상기 데이터 저장단위에 대한 클라이언트 요청빈도를 측정하는 측정 단계; 및상기 측정된 클라이언트 요청빈도 값이 속하는 상기 관리범위에 해당하는 관리유형에 따라 상기 데이터 저장단위를 관리하는 관리 단계를 포함하되,상기 관리범위는,데이터 서버에서 사용자 만족을 위해 계산한 응답 IOPS(Input Output Per Second) 값인 '제 1 응답값'과, 상기 제 1 응답값에 소정의 소수를 곱하여 계산한 응답 IOPS 값인 '제 2 응답값' 간에 형성되는 범위인 것을 특징으로 하는 데이터 관리 방법.
- 제 2 항에 있어서,상기 제 1 응답값은,상기 데이터 서버의 최대 IOPS를 이용하여 계산한 접속응답시간과 고객서비스 SLA(Service Level Agreement) 사항인 상기 데이터 서버의 보장응답시간을 통해 계산한 응답만족도에 대해 '단위 초당 가입자 요청수'와 '초기 데이터 저장단위의 크기'와 '최적 블록 크기'를 적용하여 계산되는 데이터 관리 방법.
- 제 3 항에 있어서,상기 최대 IOPS 및 상기 최적 블록 크기는,상기 데이터 서버로 소정의 배수의 크기로 전송한 측정데이터와 상기 측정데이터에 대한 IOPS에 대한 내적값을 이용해 서로 연속한 내적값의 차를 구한 집합에서 최대인 경우에 도출되는 데이터 관리 방법.
- 제 2 항 내지 제 4 항 중 어느 한 항에 있어서,상기 관리 단계는,상기 클라이언트 요청빈도 값이 상기 제 1 응답값보다 큰 경우에, 상기 데이터 저장단위를 적어도 2 이상의 자연수로 분할하여 분산배치하는 데이터 관리 방법.
- 제 5 항에 있어서,상기 관리 단계는,상기 클라이언트 요청빈도 값이 상기 제 2 응답값보다 작은 경우에, 상기 분할한 후 분산배치된 데이터 저장단위를 소정의 어느 하나의 데이터 서버로 이동시켜 합치는 데이터 관리 방법.
- 제 2 항 내지 제 4 항 중 어느 한 항에 있어서,상기 관리 단계는,상기 클라이언트 요청빈도 값이 상기 제 1 응답값보다 큰 경우에, 상기 데이터 저장단위를 적어도 2 이상의 자연수의 배수로 복제하여 분산배치하는 데이터 관리 방법.
- 제 7 항에 있어서,상기 관리 단계는,상기 클라이언트 요청빈도 값이 상기 제 2 응답값보다 작은 경우에, 상기 복제된 데이터 저장단위를 삭제하는 데이터 관리 방법.
- 삭제
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020080124279A KR101023585B1 (ko) | 2008-12-08 | 2008-12-08 | 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른데이터 관리 방법 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020080124279A KR101023585B1 (ko) | 2008-12-08 | 2008-12-08 | 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른데이터 관리 방법 |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20100065768A KR20100065768A (ko) | 2010-06-17 |
KR101023585B1 true KR101023585B1 (ko) | 2011-03-21 |
Family
ID=42364959
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020080124279A KR101023585B1 (ko) | 2008-12-08 | 2008-12-08 | 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른데이터 관리 방법 |
Country Status (1)
Country | Link |
---|---|
KR (1) | KR101023585B1 (ko) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012141404A1 (ko) * | 2011-04-13 | 2012-10-18 | (주)케이티 | 분산 저장 시스템의 복제 서버 장치 및 복제본 생성 방법 |
US8495013B2 (en) | 2010-12-24 | 2013-07-23 | Kt Corporation | Distributed storage system and method for storing objects based on locations |
US8775870B2 (en) | 2010-12-22 | 2014-07-08 | Kt Corporation | Method and apparatus for recovering errors in a storage system |
US9052962B2 (en) | 2011-03-31 | 2015-06-09 | Kt Corporation | Distributed storage of data in a cloud storage system |
KR20150074677A (ko) * | 2013-12-24 | 2015-07-02 | 주식회사 케이티 | 계층형 스토리지 제어 장치 및 방법 |
KR20150074571A (ko) * | 2013-12-24 | 2015-07-02 | 주식회사 케이티 | 테이프 스토리지 시스템 및 이의 제어 방법 |
US9158460B2 (en) | 2011-04-25 | 2015-10-13 | Kt Corporation | Selecting data nodes using multiple storage policies in cloud storage system |
WO2016122595A1 (en) * | 2015-01-30 | 2016-08-04 | Hewlett Packard Enterprise Development Lp | Chunk monitoring |
US9888062B2 (en) | 2010-12-24 | 2018-02-06 | Kt Corporation | Distributed storage system including a plurality of proxy servers and method for managing objects |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016054800A1 (en) * | 2014-10-10 | 2016-04-14 | Empire Technology Development Llc | Scene image generator |
CN112632075A (zh) * | 2020-12-25 | 2021-04-09 | 创新科技术有限公司 | 集群元数据的存储、读取方法和装置 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080059718A1 (en) * | 2006-09-01 | 2008-03-06 | Sachie Tajima | Storage system, data relocation method thereof, and recording medium that records data relocation program |
US20080270436A1 (en) | 2007-04-27 | 2008-10-30 | Fineberg Samuel A | Storing chunks within a file system |
-
2008
- 2008-12-08 KR KR1020080124279A patent/KR101023585B1/ko not_active IP Right Cessation
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080059718A1 (en) * | 2006-09-01 | 2008-03-06 | Sachie Tajima | Storage system, data relocation method thereof, and recording medium that records data relocation program |
JP2008059438A (ja) * | 2006-09-01 | 2008-03-13 | Hitachi Ltd | 記憶システム、そのデータ再配置方法、データ再配置プログラム |
US20080270436A1 (en) | 2007-04-27 | 2008-10-30 | Fineberg Samuel A | Storing chunks within a file system |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8775870B2 (en) | 2010-12-22 | 2014-07-08 | Kt Corporation | Method and apparatus for recovering errors in a storage system |
US8495013B2 (en) | 2010-12-24 | 2013-07-23 | Kt Corporation | Distributed storage system and method for storing objects based on locations |
US9888062B2 (en) | 2010-12-24 | 2018-02-06 | Kt Corporation | Distributed storage system including a plurality of proxy servers and method for managing objects |
US9052962B2 (en) | 2011-03-31 | 2015-06-09 | Kt Corporation | Distributed storage of data in a cloud storage system |
US8849756B2 (en) | 2011-04-13 | 2014-09-30 | Kt Corporation | Selecting data nodes in distributed storage system |
WO2012141404A1 (ko) * | 2011-04-13 | 2012-10-18 | (주)케이티 | 분산 저장 시스템의 복제 서버 장치 및 복제본 생성 방법 |
US9158460B2 (en) | 2011-04-25 | 2015-10-13 | Kt Corporation | Selecting data nodes using multiple storage policies in cloud storage system |
KR20150074571A (ko) * | 2013-12-24 | 2015-07-02 | 주식회사 케이티 | 테이프 스토리지 시스템 및 이의 제어 방법 |
KR101593012B1 (ko) | 2013-12-24 | 2016-02-18 | 주식회사 케이티 | 계층형 스토리지 제어 장치 및 방법 |
US9454328B2 (en) | 2013-12-24 | 2016-09-27 | Kt Corporation | Controlling hierarchical storage |
KR20150074677A (ko) * | 2013-12-24 | 2015-07-02 | 주식회사 케이티 | 계층형 스토리지 제어 장치 및 방법 |
KR102172317B1 (ko) * | 2013-12-24 | 2020-10-30 | 주식회사 케이티 | 테이프 스토리지 시스템 및 이의 제어 방법 |
WO2016122595A1 (en) * | 2015-01-30 | 2016-08-04 | Hewlett Packard Enterprise Development Lp | Chunk monitoring |
US20180004430A1 (en) * | 2015-01-30 | 2018-01-04 | Hewlett Packard Enterprise Development Lp | Chunk Monitoring |
Also Published As
Publication number | Publication date |
---|---|
KR20100065768A (ko) | 2010-06-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR101023585B1 (ko) | 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른데이터 관리 방법 | |
US10956447B2 (en) | Determining data replication cost for cloud based application | |
US8190742B2 (en) | Distributed differential store with non-distributed objects and compression-enhancing data-object routing | |
Manogar et al. | A study on data deduplication techniques for optimized storage | |
Xu et al. | Data deduplication mechanism for cloud storage systems | |
US20180107404A1 (en) | Garbage collection system and process | |
CN109144406A (zh) | 分布式存储***中元数据存储方法、***及存储介质 | |
KR101441059B1 (ko) | 분산 파일 시스템에서 효율적인 자료 저장 방법 | |
Abad et al. | Generating request streams on Big Data using clustered renewal processes | |
Selvi et al. | OPTIMIZING THE STORAGE SPACE AND COST WITH RELIABILITY ASSURANCE BY REPLICA REDUCTION ON CLOUD STORAGE SYSTEM. | |
Nachiappan et al. | Adaptive bandwidth-efficient recovery techniques in erasure-coded cloud storage | |
Kumar et al. | Differential Evolution based bucket indexed data deduplication for big data storage | |
Rao | Data duplication using Amazon Web Services cloud storage | |
KR101718739B1 (ko) | 이기종 하둡을 위한 동적 데이터 복제 시스템 및 방법 | |
Jo et al. | On the trade-off between performance and storage efficiency of replication-based object storage | |
Ma et al. | An evaluation of storage systems based on network-attached disks | |
Mkandawire | Improving backup and restore performance for deduplication-based cloud backup services | |
Li et al. | Frequency and similarity-aware partitioning for cloud storage based on space-time utility maximization model | |
Tijare | Data deduplication concepts | |
Phyu et al. | Efficient data deduplication scheme for scale-out distributed storage | |
Shial et al. | Techniques for file synchronization: a survey | |
Priscilla | Cloud Computing Elastic Storage System for Storage Optimization | |
US8849763B1 (en) | Using multiple clients for data backup | |
Grangia et al. | Balancing the storage in a deduplication cluster | |
Łukawski et al. | Balancing workloads of servers maintaining scalable distributed data structures |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A201 | Request for examination | ||
E902 | Notification of reason for refusal | ||
E701 | Decision to grant or registration of patent right | ||
GRNT | Written decision to grant | ||
FPAY | Annual fee payment |
Payment date: 20140304 Year of fee payment: 4 |
|
LAPS | Lapse due to unpaid annual fee |