KR20100065768A - 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른데이터 관리 방법 - Google Patents

객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른데이터 관리 방법 Download PDF

Info

Publication number
KR20100065768A
KR20100065768A KR1020080124279A KR20080124279A KR20100065768A KR 20100065768 A KR20100065768 A KR 20100065768A KR 1020080124279 A KR1020080124279 A KR 1020080124279A KR 20080124279 A KR20080124279 A KR 20080124279A KR 20100065768 A KR20100065768 A KR 20100065768A
Authority
KR
South Korea
Prior art keywords
iops
data
response
management
data server
Prior art date
Application number
KR1020080124279A
Other languages
English (en)
Other versions
KR101023585B1 (ko
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
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Priority to KR1020080124279A priority Critical patent/KR101023585B1/ko
Publication of KR20100065768A publication Critical patent/KR20100065768A/ko
Application granted granted Critical
Publication of KR101023585B1 publication Critical patent/KR101023585B1/ko

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

본 발명은 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법에 관한 것으로, 클라이언트의 요청빈도가 증가하면 청크를 분할한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 일부 서버로 이동시켜 나머지 분할청크와 합쳐 보관하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법을 제공하고자 한다.
또한, 본 발명은 클라이언트의 요청빈도가 증가하면 청크를 복제한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 삭제하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법을 제공하고자 한다.
이를 위하여, 본 발명은 데이터 관리 방법에 있어서, 데이터 저장단위에 대한 관리유형에 따라 해당 관리범위를 결정하는 결정 단계; 상기 데이터 저장단위에 대한 클라이언트 요청빈도를 측정하는 측정 단계; 및 상기 측정된 클라이언트 요청빈도 값이 속하는 관리범위에 해당하는 관리유형에 따라 상기 데이터 저장단위를 관리하는 관리 단계를 포함한다.
객체기반 스토리지 시스템, 클라이언트 요청빈도, 데이터 관리, 청크, 분할, 분산배치, 복제

Description

객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법{METHOD FOR MANAGING A DATA ACCORDING TO THE FREQUENCY OF CLIENT REQUESTS IN OBJECT-BASED STORAGE SYSTEM}
본 발명은 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법에 관한 것으로, 더욱 상세하게는 클라이언트의 요청빈도가 증가하면 청크를 분할한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 일부 서버로 이동시켜 나머지 분할청크와 합쳐 보관하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법에 관한 것이다.
또한, 본 발명은 다른 실시예로서, 클라이언트의 요청빈도가 증가하면 청크를 복제한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 삭제하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법에 관한 것이다.
이메일, 전자상거래 등과 같은 다양한 네트워크 기반 응용에 의해 생성되는 방대한 양의 데이터가 급격하게 증가함에 따라, 기업에서는 상기와 같이 급격히 증가하는 대량의 데이터를 가능한 많이 지속적으로 축적하기 위해 스토리지 시스템(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를 제공할 수 있었다. 이는 종래의 객체기반 스토리지 시스템에서 복제를 통해 데이터의 보존성 및 가용성을 향상시킬 수 있었으나, 데이터 서버의 저장공간을 비효율적으로 사용하는 한계가 있다.
따라서 종래의 객체기반 스토리지 시스템에서는 데이터의 보존성 및 가용성을 보장하면서도 저장공간의 낭비를 최소화할 뿐만 아니라, 클라이언트의 데이터 읽기/쓰기 요청빈도를 반영하면서 능동적으로 IOPS를 일정하게 제공할 수 있는 기술이 제안될 필요가 더욱 절실하다.
따라서 상기와 같은 종래 기술은 객체기반 스토리지 시스템에서 데이터의 보존성 및 가용성을 보장할 수 있었으나 데이터 서버의 저장공간을 낭비하게 되는 문제점이 있으며, 이러한 문제점을 해결하고자 하는 것이 본 발명의 과제이다.
따라서 본 발명은 클라이언트의 요청빈도가 증가하면 청크를 분할한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 일부 서버로 이동시켜 나머지 분할청크와 합쳐 보관하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법을 제공하는데 그 목적이 있다.
또한, 본 발명은 클라이언트의 요청빈도가 증가하면 청크를 복제한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 삭제하는, 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른 데이터 관리 방법을 제공하는데 그 목적이 있다.
본 발명의 목적들은 이상에서 언급한 목적으로 제한되지 않으며, 언급되지 않은 본 발명의 다른 목적 및 장점들은 하기의 설명에 의해서 이해될 수 있으며, 본 발명의 실시예에 의해 보다 분명하게 알게 될 것이다. 또한, 본 발명의 목적 및 장점들은 특허 청구 범위에 나타낸 수단 및 그 조합에 의해 실현될 수 있음을 쉽게 알 수 있을 것이다.
상기 목적을 달성하기 위한 본 발명은, 데이터 관리 방법에 있어서, 데이터 저장단위에 대한 관리유형에 따라 해당 관리범위를 결정하는 결정 단계; 상기 데이터 저장단위에 대한 클라이언트 요청빈도를 측정하는 측정 단계; 및 상기 측정된 클라이언트 요청빈도 값이 속하는 관리범위에 해당하는 관리유형에 따라 상기 데이터 저장단위를 관리하는 관리 단계를 포함한다.
또한, 본 발명은 프로세서를 구비한 객체기반 스토리지 시스템에, 데이터 저장단위에 대한 관리유형에 따라 해당 관리범위를 결정하는 기능; 상기 데이터 저장단위에 대한 클라이언트 요청빈도를 측정하는 기능; 및 상기 측정된 클라이언트 요청빈도 값이 속하는 관리범위에 해당하는 관리유형에 따라 상기 데이터 저장단위를 관리하는 기능을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공한다.
상기와 같은 본 발명은, 클라이언트의 요청빈도가 증가하면 청크를 분할한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 일부 서버로 이동시켜 나머지 분할청크와 합쳐 보관함으로써, 데이터 서버의 저장공간을 효율적으로 이용할 수 있는 효과가 있다.
또한, 본 발명은 클라이언트의 요청빈도가 증가하면 청크를 복제한 후 분산배치하고, 클라이언트의 요청빈도가 감소하면 분할청크를 삭제함으로써, 데이터 서버의 저장공간을 효율적으로 이용할 수 있는 효과가 있다.
상술한 목적, 특징 및 장점은 첨부된 도면을 참조하여 상세하게 후술되어 있는 상세한 설명을 통하여 보다 명확해 질 것이며, 그에 따라 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명의 기술적 사상을 용이하게 실시할 수 있을 것이다. 또한, 본 발명을 설명함에 있어서 본 발명과 관련된 공지 기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에 그 상세한 설명을 생략하기로 한다. 이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 실시예를 상세히 설명하기로 한다.
도 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).
Figure 112008084514486-PAT00001
여기서, π는 데이터 서버(140)의 최대 IOPS, ρ는 이중 가용 IOPS비를 나타낸다. 일반적으로, ρ는 π의 50%∼80%로 설정된다.
다음, 데이터 서버(140)의 응답만족도(S)는 하기 [수학식 2]를 이용하여 계산한다(S402).
Figure 112008084514486-PAT00002
여기서, R은 고객서비스 SLA(Service Level Agreement) 사항인 최소한의 데이터 서버(140)의 보장응답시간을 나타낸다. R은 사용자의 데이터 접속 요청빈도수 및 요구 IOPS에 따라 별도로 규정할 수 있다. 일반적으로, 웹에서 사용자의 요청(request)당 전체 IO 응답시간은 2초 이내가 요구된다.
마지막으로, 데이터 서버(140)의 제 1 응답 IOPS(Ap)는 하기 [수학식 3]을 이용하여 도출한다(S403).
Figure 112008084514486-PAT00003
Figure 112008084514486-PAT00004
여기서, Κ는 단위 초당 가입자의 요청수이고, Φ는 청크당 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)

  1. 데이터 관리 방법에 있어서,
    데이터 저장단위에 대한 관리유형에 따라 해당 관리범위를 결정하는 결정 단계;
    상기 데이터 저장단위에 대한 클라이언트 요청빈도를 측정하는 측정 단계; 및
    상기 측정된 클라이언트 요청빈도 값이 속하는 관리범위에 해당하는 관리유형에 따라 상기 데이터 저장단위를 관리하는 관리 단계
    를 포함하는 데이터 관리 방법.
  2. 제 1 항에 있어서,
    상기 관리범위는,
    데이터 서버에서 사용자 만족을 위해 계산한 응답 IOPS(Input Output Per Second) 값인 '제 1 응답값'과, 제 1 응답값에 소정의 소수를 곱하여 계산한 응답 IOPS 값인 '제 2 응답값' 간에 형성되는 범위인 것을 특징으로 하는 데이터 관리 방법.
  3. 제 2 항에 있어서,
    상기 제 1 응답값은,
    상기 데이터 서버의 최대 IOPS를 이용하여 계산한 접속응답시간과 고객서비스 SLA(Service Level Agreement) 사항인 상기 데이터 서버의 보장응답시간을 통해 계산한 응답만족도에 대해 '단위 초당 가입자 요청수'와 '초기 데이터 저장단위의 크기'와 '최적 블록 크기'를 적용하여 계산되는 데이터 관리 방법.
  4. 제 3 항에 있어서,
    상기 최대 IOPS 및 상기 최적 블록 크기는,
    상기 데이터 서버로 소정의 배수의 크기로 전송한 측정데이터와 상기 측정데이터에 대한 IOPS에 대한 내적값을 이용해 서로 연속한 내적값의 차를 구한 집합에서 최대인 경우에 도출되는 데이터 관리 방법.
  5. 제 2 항 내지 제 4 항 중 어느 한 항에 있어서,
    상기 관리 단계는,
    상기 클라이언트 요청빈도 값이 상기 제 1 응답값보다 큰 경우에, 상기 데이터 저장단위를 적어도 2 이상의 자연수로 분할하여 분산배치하는 데이터 관리 방법.
  6. 제 5 항에 있어서,
    상기 관리 단계는,
    상기 클라이언트 요청빈도 값이 상기 제 2 응답값보다 작은 경우에, 상기 분할한 후 분산배치된 데이터 저장단위를 소정의 어느 하나의 데이터 서버로 이동시켜 합치는 데이터 관리 방법.
  7. 제 2 항 내지 제 4 항 중 어느 한 항에 있어서,
    상기 관리 단계는,
    상기 클라이언트 요청빈도 값이 상기 제 1 응답값보다 큰 경우에, 상기 데이터 저장단위를 적어도 2 이상의 자연수의 배수로 복제하여 분산배치하는 데이터 관리 방법.
  8. 제 7 항에 있어서,
    상기 관리 단계는,
    상기 클라이언트 요청빈도 값이 상기 제 2 응답값보다 작은 경우에, 상기 복제된 데이터 저장단위를 삭제하는 데이터 관리 방법.
  9. 프로세서를 구비한 객체기반 스토리지 시스템에,
    데이터 저장단위에 대한 관리유형에 따라 해당 관리범위를 결정하는 기능;
    상기 데이터 저장단위에 대한 클라이언트 요청빈도를 측정하는 기능; 및
    상기 측정된 클라이언트 요청빈도 값이 속하는 관리범위에 해당하는 관리유형에 따라 상기 데이터 저장단위를 관리하는 기능
    을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
KR1020080124279A 2008-12-08 2008-12-08 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른데이터 관리 방법 KR101023585B1 (ko)

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 true KR20100065768A (ko) 2010-06-17
KR101023585B1 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 (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170068546A (ko) * 2014-10-10 2017-06-19 엠파이어 테크놀로지 디벨롭먼트 엘엘씨 장면 이미지 생성기
CN112632075A (zh) * 2020-12-25 2021-04-09 创新科技术有限公司 集群元数据的存储、读取方法和装置

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101502895B1 (ko) 2010-12-22 2015-03-17 주식회사 케이티 복수의 오류 복제본으로부터 오류를 복구하는 방법 및 상기 방법을 이용하는 스토리지 시스템
KR101544480B1 (ko) 2010-12-24 2015-08-13 주식회사 케이티 복수 개의 프락시 서버를 포함하는 분산 저장 시스템 및 그 오브젝트 관리 방법 및 컴퓨터에 의하여 독출가능한 저장 매체
KR101585146B1 (ko) 2010-12-24 2016-01-14 주식회사 케이티 오브젝트를 복수 개의 데이터 노드들의 위치에 기반하여 분산 저장하는 분산 저장 시스템 및 그 위치 기반 분산 저장 방법 및 컴퓨터에 의하여 독출 가능한 저장 매체
KR101483127B1 (ko) 2011-03-31 2015-01-22 주식회사 케이티 클라우드 스토리지 시스템에서 리소스를 고려한 자료분배방법 및 장치
KR101544483B1 (ko) 2011-04-13 2015-08-17 주식회사 케이티 분산 저장 시스템의 복제 서버 장치 및 복제본 생성 방법
KR101544485B1 (ko) 2011-04-25 2015-08-17 주식회사 케이티 클라우드 스토리지 시스템에서 복수개의 복제본을 분산 저장하는 방법 및 장치
KR102172317B1 (ko) * 2013-12-24 2020-10-30 주식회사 케이티 테이프 스토리지 시스템 및 이의 제어 방법
KR101593012B1 (ko) 2013-12-24 2016-02-18 주식회사 케이티 계층형 스토리지 제어 장치 및 방법
WO2016122595A1 (en) * 2015-01-30 2016-08-04 Hewlett Packard Enterprise Development Lp Chunk monitoring

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4859595B2 (ja) * 2006-09-01 2012-01-25 株式会社日立製作所 記憶システム、そのデータ再配置方法、データ再配置プログラム
US20080270436A1 (en) 2007-04-27 2008-10-30 Fineberg Samuel A Storing chunks within a file system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170068546A (ko) * 2014-10-10 2017-06-19 엠파이어 테크놀로지 디벨롭먼트 엘엘씨 장면 이미지 생성기
CN112632075A (zh) * 2020-12-25 2021-04-09 创新科技术有限公司 集群元数据的存储、读取方法和装置

Also Published As

Publication number Publication date
KR101023585B1 (ko) 2011-03-21

Similar Documents

Publication Publication Date Title
KR101023585B1 (ko) 객체기반 스토리지 시스템에서 클라이언트 요청빈도에 따른데이터 관리 방법
CN110291509B (zh) 在分散存储网络的区域中存储数据的方法和系统
US10956447B2 (en) Determining data replication cost for cloud based application
JP6479020B2 (ja) 分散ストレージシステムにおけるオブジェクトの階層チャンキング
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
Kumar et al. Simplified HDFS architecture with blockchain distribution of metadata
Abad et al. Generating request streams on Big Data using clustered renewal processes
KR101441059B1 (ko) 분산 파일 시스템에서 효율적인 자료 저장 방법
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
KR101718739B1 (ko) 이기종 하둡을 위한 동적 데이터 복제 시스템 및 방법
Langner et al. Optimal file-distribution in heterogeneous and asymmetric storage networks
Rao Data duplication using Amazon Web Services cloud storage
Jo et al. On the trade-off between performance and storage efficiency of replication-based object storage
Mkandawire Improving backup and restore performance for deduplication-based cloud backup services
Ma et al. An evaluation of storage systems based on network-attached disks
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
Priscilla Cloud Computing Elastic Storage System for Storage Optimization
Duan et al. A high‐performance distributed file system for large‐scale concurrent HD video streams

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