KR101440605B1 - 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법 - Google Patents

파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법 Download PDF

Info

Publication number
KR101440605B1
KR101440605B1 KR1020120130233A KR20120130233A KR101440605B1 KR 101440605 B1 KR101440605 B1 KR 101440605B1 KR 1020120130233 A KR1020120130233 A KR 1020120130233A KR 20120130233 A KR20120130233 A KR 20120130233A KR 101440605 B1 KR101440605 B1 KR 101440605B1
Authority
KR
South Korea
Prior art keywords
file system
access
user
storage
collector
Prior art date
Application number
KR1020120130233A
Other languages
English (en)
Other versions
KR20140063181A (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 KR1020120130233A priority Critical patent/KR101440605B1/ko
Publication of KR20140063181A publication Critical patent/KR20140063181A/ko
Application granted granted Critical
Publication of KR101440605B1 publication Critical patent/KR101440605B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • 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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법이 개시된다. 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치는, 사용자 작성 프로그램의 설치에 의해 구축되고, 사용자 어플리케이션이 억세스 요청한 데이터를 통신망을 통해 연결되고 하나 이상의 파일 시스템이 각각 설정된 하나 이상의 스토리지 시스템에서 억세스 처리할 수집기(aggregator)를 선정하는 프로그래머블 로직 블록; 및 구비된 복수의 수집기 중에서, 상기 프로그래머블 로직 블록에 의해 선정된 수집기가 통신망을 통해 연결된 하나 이상의 스토리지 시스템으로부터 요청된 데이터에 대한 억세스 처리를 수행하는 수집 블록을 포함한다.

Description

파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법{User device having file system gateway unit and method for accessing to stored data}
본 발명은 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법에 관한 것이다.
일반적으로 컴퓨터 운영체제(Operating system)가 탑재된 대부분의 사용자 장치는 해당 장치의 운용에 필요한 소프트웨어 및 데이터 등을 설치하고 저장하기 위해 예를 들어 하드 디스크, 플래시 기반의 SSD(Solid State Disk) 등의 저장매체(storage)를 구비하고 있다.
컴퓨터 운영체제는 저장매체에 데이터(또는 파일)를 연속적으로 저장하고 억세스하기 위해 저장 데이터를 구조화한 파일 시스템을 이용하여 자유롭게 저장매체에 데이터를 저장하거나 저장된 데이터에 억세스할 수 있다. 이때, 컴퓨터 운영체제는 저장매체의 저장 공간을 데이터 기록 등의 처리를 위해 요구되는 형식으로 맞추는 포맷(format) 과정을 선행할 수 있다.
초기의 컴퓨터 운영체제는 해당 운영체제가 설치된 사용자 장치 내부에 장착된 저장매체를 대상으로만 억세스할 수 있도록 제한되었으나, 최근에는 NFS(Network File System), CIFS(Common Internet File System) 등의 표준 프로토콜을 사용하여 통신망을 통해 연결된 저장매체일지라도 사용자 장치 내부에 장착된 저장매체인 것처럼 사용할 수 있는 기술이 개발되었다.
또한, 클라우드 컴퓨팅 기술의 급속한 확산에 따라 클라우드 스토리지 환경에 적합한 다양한 파일 시스템도 개발되고 있으며, 이러한 파일 시스템으로는 예를 들어 Hadoop 분산 파일 시스템, Lustre, Panasas, PVFS2, OASIS 등이 있다.
이외에도, 빅 데이터(big data), 대용량 데이터의 급증 추세에 맞춰 다양한 파일 시스템이 개발되어 사용되고 있으며, 이에 따라 응용 프로그램도 제공하는 기능 또는 서비스 특성에 따라 최적의 파일 시스템을 사용할 수 있도록 구성되고 있다.
응용 프로그램이 소정의 파일 시스템을 사용함에 있어, 종래에는 운영체제에 포함되어 제공되는 파일 시스템 추상화 계층을 통해 응용 프로그램이 파일 시스템을 이용하는 구조를 가지고 있었다. 특정의 응용프로그램이 기능 및 서비스에 최적인 특정 파일시스템을 사용하도록 하기 위해서는 해당 응용프로그램 설치 단계에서 특정 파일 시스템을 사용하도록 설정하거나, 특정 파일 시스템 설치 단계에서 응용 프로그램이 사용하는 저장매체 영역(예를 들어, 응용 프로그램이 억세스하는 디렉터리 등)에 파일 시스템이 구성되도록 설치하는 방법 등이 이용된다.
일 예로, 리눅스(LINUX) 운영체제와 같이 다양한 파일 시스템을 설치(마운트)하여 사용하는 것을 지원하는 컴퓨터 운영체제는 파일 시스템과 사용자 응용 프로그램 사이에 파일 시스템을 추상화(abstraction)하여(예를 들어, 가상 파일 시스템(VFS, Virtual File System), 사용자 응용 프로그램이 파일 시스템의 종류에 관계없이 공통된 인터페이스 기능을 이용하여 파일 시스템에 억세스할 수 있도록 한다.
추상화 과정을 거쳐 하위 파일 시스템을 억세스하도록 하는 구조는, 사용자 응용 프로그램이 파일 시스템의 종류에 관계없이 표준화된 파일 시스템 억세스 인터페이스(예를 들어, open(), read(), write(), close() 등)를 통해 파일 시스템 이용이 가능한 장점은 있으나, 전술한 추상화 과정으로 인해 응용 프로그램이 하위 파일 시스템에 대한 직접적인 억세스가 차단되는 문제점이 있다.
또한, 종래기술에 따른 저장된 데이터 억세스 방법에서는 응용 프로그램의 구동되는 동안 기존에 이용하던 파일 시스템과 상이한 파일 시스템을 사용하도록 설정하거나, 하나의 응용 프로그램이 서로 다른 종류의 파일 시스템을 함께 사용하도록 설정할 수 없는 한계가 있었다.
따라서, 응용 프로그램이 이용하는 파일 시스템을 변경하기 위해서는 구동되는 응용 프로그램의 수행을 중단시키거나, 경우에 따라서는 응용 프로그램이 구동되는 사용자 장치 자체를 재부팅하여야 하는 불편함이 있었다. 또한, 하나의 응용 프로그램이 서로 다른 종류의 파일 시스템을 이용할 수 있도록 하기 위해서는, 같은 응용 프로그램을 복수로 실행시키고 복수로 실행된 각각의 응용 프로그램이 각기 다른 파일 시스템을 사용하도록 한 후 서로 다른 파일 시스템에 저장된 정보를 공유하도록 하는 별도의 프로그램을 개발하여 사용하여야 하는 불편함도 있었다.
본 발명은 사용자 장치의 사용자가 보유하고 있거나 통신망을 통해 접근 가능한 다양한 기술규격의 파일 시스템들에 대해 사용자 응용 프로그램이 다양한 파일 시스템 억세스 알고리즘을 이용하여 억세스할 수 있는 환경을 제공할 수 있는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법을 제공하기 위한 것이다.
본 발명은 다양한 기술 특성을 가지는 파일 시스템을 억세스함에 있어 사용자 응용 프로그램의 종류, 파일 시스템이 운용되는 스토리지 시스템의 물리적 위치, 입출력 속도, 용량 및 비용 등의 다양한 특성을 고려하여 파일 시스템 억세스 알고리즘의 억세스 정책을 사용자가 직접 프로그래밍하여 이용할 수 있는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법을 제공하기 위한 것이다.
본 발명은 응용 프로그램의 수정이나 실행 중단없이 다양한 파일 시스템(예를 들어, Hadoop HDFS(Hadoop Distributed File System) 또는 Swift, Lustre 등과 같이 클라우드 환경에 최적화된 파일 시스템, NFS(Network File System), CIFS(Common Internet File System) 등)에 자유롭게 억세스할 수 있도록 하는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법을 제공하기 위한 것이다.
본 발명은 응용 프로그램이 통신망을 통해 연결된 다양한 파일 시스템으로 구현된 다양한 스토리지 시스템에 억세스할 수 있도록 하여 하드웨어 자원의 효율적 이용을 도모할 수 있는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법을 제공하기 위한 것이다.
본 발명은 대용량 콘텐츠의 급증 및 다양한 형태의 인터넷 서비스 개발에 따른 인터넷 서비스 사업자의 데이터 관리 효율성을 제고할 수 있는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법을 제공하기 위한 것이다. 예를 들어, 인터넷 서비스 사업자는 용량 및 이용 형태(즉, 억세스 형태)가 다양한 콘텐츠에 대해 비용 및 서비스 품질 측면에서 효과적으로 관리할 수 있도록 하기 위해 대용량이거나 억세스 빈도가 낮은 콘텐츠는 저렴한 저장매체(예를 들어, 클라우드 컴퓨팅 방식의 스토리지)를 이용하도록 하고, 이용빈도가 높거나 고품질의 서비스가 요구되는 콘텐츠는 고성능 저장매체(예를 들어 NAS(Network Attached Storage))에 저장하여 관리할 수 있을 것이다.
본 발명의 이외의 목적들은 하기의 설명을 통해 쉽게 이해될 수 있을 것이다.
본 발명의 일 측면에 따르면, 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치에 있어서, 사용자 작성 프로그램의 설치에 의해 구축되고, 사용자 어플리케이션이 억세스 요청한 데이터를 통신망을 통해 연결되고 하나 이상의 파일 시스템이 각각 설정된 하나 이상의 스토리지 시스템에서 억세스 처리할 수집기(aggregator)를 선정하는 프로그래머블 로직 블록; 및 구비된 복수의 수집기 중에서, 상기 프로그래머블 로직 블록에 의해 선정된 수집기가 통신망을 통해 연결된 하나 이상의 스토리지 시스템으로부터 요청된 데이터에 대한 억세스 처리를 수행하는 수집 블록을 포함하는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치가 제공된다.
상기 프로그래머블 로직 블록은 상기 사용자 어플리케이션의 억세스 요청에 상응하여 소정의 파일 시스템을 선정하고, 상기 수집기는 상기 선정된 파일 시스템이 구축된 스토리지 시스템을 대상으로 요청된 데이터에 대한 억세스 처리를 수행할 수 있다.
상기 사용자 작성 프로그램은 상기 사용자 장치가 억세스 가능한 파일 시스템의 종류를 정의하기 위한 영역, 각각의 사용자 어플리케이션에 대해 억세스 가능한 파일 시스템의 종류 정의 영역, 각각의 어플리케이션의 종류에 따라 선정될 수집기의 종류를 정의하기 위한 영역, 사용자 어플리케이션의 억세스 요청 형태에 대응되는 수집기를 정의하기 위한 영역 및 사용자 어플리케이션으로부터 스토리지 시스템에 대한 억세스 요청을 입력받는 영역을 포함할 수 있다.
상기 사용자 작성 프로그램은 상기 선정된 수집기 및 상기 사용자 어플리케이션 중 하나 이상에 대한 억세스 정책을 정의하기 위한 영역을 더 포함할 수 있고, 상기 억세스 정책은 SequencialAccess, AllOrNothing 및 FirstResponse 중 하나 이상을 포함할 수 있다.
상기 수집 블록은, 각 수집기별로 개별 이용되도록 할당되는 수집기 캐시 및 각 스토리지 시스템에 대해 개별 할당되는 파일 시스템 캐시를 포함할 수 있다.
각각의 스토리지 시스템에 구축된 파일 시스템과 연동되도록 하기 위한 드라이버 및 API(Application Programming Interface) 블록을 더 포함할 수 있고, 상기 수집 블록에 포함된 접속부는 상기 드라이버 및 API 블록으로 파일 시스템에 관계없이 공통화된 파일 시스템 억세스 함수를 이용한 데이터 억세스 요청을 전송할 수 있다.
상기 파일 시스템 억세스 함수는 억세스 요청 형태에 대한 정보, 파일 시스템 식별 정보, 데이터의 저장 위치에 대한 디렉토리 정보, 억세스된 데이터의 저장소 정보 및 억세스할 데이터 크기 정보를 포함하도록 구성될 수 있다.
상기 파일 시스템 억세스 함수는 억세스 요청 형태에 대한 정보, SNS(Social Network Service) 식별 정보, SNS 서비스가 상기 사용자 장치에 제공한 Open API 이름 정보, 억세스된 데이터의 저장소 정보 및 억세스할 데이터 크기 정보를 포함할 수 있다.
상기 사용자 어플리케이션과 상기 프로그래머블 로직 블록간의 통신 프로토콜과 상기 프로그래머블 로직 블록과 상기 드라이버 및 API(Application Programming Interface) 블록간의 통신 프로토콜은 상이한 통신 프로토콜일 수 있다.
상기 파일 시스템은 Hadoop HDFS(Hadoop Distributed File System), Swift, Lustre, GLORY FS, NFS(Network File System), CIFS(Common Internet File System) 중 하나 이상을 포함할 수 있다.
본 발명의 다른 측면에 따르면, 사용자 장치에 의한 저장 데이터 억세스 방법에 있어서, (a) 프로그래머블 로직 블록이 사용자 어플리케이션에서 발생된 억세스 이벤트에 상응하는 억세스 정보를 참조하여 상기 사용자 어플리케이션에 상응하도록 지정된 스토리지 시스템 및 수집기를 각각 선정하는 단계; 및 (b) 상기 수집기가 통신망을 통해 상기 선정된 하나 이상의 스토리지 시스템에 접속하여 상기 억세스 정보에 의해 지정된 데이터를 억세스하는 단계를 포함하는 저장 데이터 억세스 방법이 제공된다.
상기 억세스 정보에 의해 지정된 데이터가 수집기 캐시에 저장된 것인지를 판단하는 단계가 상기 (a)와 (b) 사이에서 수행될 수 있고, 상기 수집기 캐시에 상기 데이터가 저장된 경우, 상기 프로그래머블 로직 블록은 상기 저장된 데이터를 상기 사용자 어플리케이션에 제공할 수 있다.
상기 수집기는 상기 선정된 스토리지 시스템에 억세스하기 전에, 파일 시스템 캐시에 상기 억세스 정보에 의해 지정된 데이터가 저장된 것인지를 판단하는 단계; 및 저장된 경우, 상기 저장된 데이터를 상기 사용자 어플리케이션에 제공하는 단계를 수행할 수 있다.
상기 프로그래머블 로직 블록은 사용자 작성 프로그램의 설치에 의해 구축될 수 있고, 상기 사용자 작성 프로그램은 상기 사용자 장치가 억세스 가능한 파일 시스템의 종류를 정의하기 위한 영역, 각각의 사용자 어플리케이션에 대해 억세스 가능한 파일 시스템의 종류 정의 영역, 각각의 어플리케이션의 종류에 따라 선정될 수집기의 종류를 정의하기 위한 영역, 사용자 어플리케이션의 억세스 요청 형태에 대응되는 수집기를 정의하기 위한 영역 및 사용자 어플리케이션으로부터 스토리지 시스템에 대한 억세스 요청을 입력받는 영역을 포함할 수 있다.
상기 사용자 작성 프로그램은, 상기 선정된 수집기 및 상기 사용자 어플리케이션 중 하나 이상에 대한 억세스 정책을 정의하기 위한 영역을 더 포함할 수 있고, 상기 억세스 정책은 SequencialAccess, AllOrNothing 및 FirstResponse 중 하나 이상을 포함할 수 있다.
상기 선정된 스토리지 시스템들은 상이한 파일 시스템에 의해 구축될 수 있고, 상기 구축된 파일 시스템은 Hadoop HDFS(Hadoop Distributed File System), Swift, Lustre, GLORY FS, NFS(Network File System), CIFS(Common Internet File System) 중 각각 어느 하나일 수 있다.
전술한 것 외의 다른 측면, 특징, 이점이 이하의 도면, 특허청구범위 및 발명의 상세한 설명으로부터 명확해질 것이다.
본 발명의 실시예에 따르면, 사용자 장치의 사용자가 보유하고 있거나 통신망을 통해 접근 가능한 다양한 기술규격의 파일 시스템들에 대해 사용자 응용 프로그램이 다양한 파일 시스템 억세스 알고리즘을 이용하여 억세스할 수 있는 환경을 제공할 수 있는 효과가 있다.
또한 다양한 기술 특성을 가지는 파일 시스템을 억세스함에 있어 사용자 응용 프로그램의 종류, 파일 시스템이 운용되는 스토리지 시스템의 물리적 위치, 입출력 속도, 용량 및 비용 등의 다양한 특성을 고려하여 파일 시스템 억세스 알고리즘의 억세스 정책을 사용자가 직접 프로그래밍하여 이용할 수 있는 효과도 있다.
또한 응용 프로그램의 수정이나 실행 중단없이 다양한 파일 시스템(예를 들어, Hadoop HDFS(Hadoop Distributed File System) 또는 Swift, Lustre 등과 같이 클라우드 환경에 최적화된 파일 시스템, NFS(Network File System), CIFS(Common Internet File System) 등)에 자유롭게 억세스할 수 있도록 하는 효과도 있다.
또한 응용 프로그램이 통신망을 통해 연결된 다양한 파일 시스템으로 구현된 다양한 스토리지 시스템에 억세스할 수 있도록 하여 하드웨어 자원의 효율적 이용을 도모할 수 있는 효과도 있다.
또한 대용량 콘텐츠의 급증 및 다양한 형태의 인터넷 서비스 개발에 따른 인터넷 서비스 사업자의 데이터 관리 효율성을 제고할 수 있는 효과도 있다.
도 1은 본 발명의 일 실시예에 따른 사용자 장치와 스토리지 시스템의 통신망을 통한 연결 관계를 나타낸 도면.
도 2는 본 발명의 일 실시예에 따른 스토리지 시스템에 대한 사용자 장치의 억세스 관계를 나타낸 도면.
도 3은 본 발명의 일 실시예에 따른 사용자 장치의 구성을 개략적으로 나타낸 블록 구성도.
도 4는 본 발명의 일 실시예에 따른 프로그래머블 로직 블록의 구성을 개략적으로 나타낸 도면.
도 5는 본 발명의 일 실시예에 따른 사용자 어플리케이션의 요청에 따른 저장 데이터 억세스 방법을 나타낸 순서도.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
본 명세서에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다.
또한, 명세서에 기재된 "…부", "…유닛", "…모듈", "…기" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어나 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다.
또한, 각 도면을 참조하여 설명하는 실시예의 구성 요소가 해당 실시예에만 제한적으로 적용되는 것은 아니며, 본 발명의 기술적 사상이 유지되는 범위 내에서 다른 실시예에 포함되도록 구현될 수 있으며, 또한 별도의 설명이 생략될지라도 복수의 실시예가 통합된 하나의 실시예로 다시 구현될 수도 있음은 당연하다.
또한, 첨부 도면을 참조하여 설명함에 있어, 도면 부호에 관계없이 동일한 구성 요소는 동일하거나 관련된 참조부호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 본 발명을 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다.
이하 관련 도면을 참조하여 본 명세서에서 수집기 및 파일 시스템들의 일부가 예를 들어 설명되지만, 예시되지 않은 형태의 수집기 및 파일 시스템이나 사용자가 스스로 만든 수집기 또는 다른 파일 시스템도 본 발명에 적용될 수 있음은 당연하다.
도 1은 본 발명의 일 실시예에 따른 사용자 장치와 스토리지 시스템의 통신망을 통한 연결 관계를 나타낸 도면이고, 도 2는 본 발명의 일 실시예에 따른 스토리지 시스템에 대한 사용자 장치의 억세스 관계를 나타낸 도면이다.
도 1 및 도 2를 참조하면, 하나 이상의 사용자 장치(110_1, 110_2. ... , 110_n - 이하 구분의 필요가 없는 경우 편의상 110으로 통칭함)가 통신망을 통해 하나 이상의 스토리지 시스템(120_1, 120_2. ... , 120_m - 이하 구분의 필요가 없는 경우 편의상 120으로 통칭함)에 각각 연결되도록 구성된다. 여기서, n과 m은 각각 임의의 자연수를 나타낸다.
스토리지 시스템(120)에는 일반적으로 다수의 저장매체(스토리지)와 이들 저장매체를 억세스하고 제어하는 컨트롤러가 포함될 수 있으며, 컨트롤러는 예를 들어 구비된 하나 이상의 저장매체를 마치 하나의 저장매체인 것처럼 사용할 수 있도록 하는 RAID(Redundant Array of Independent Disk) 기술을 구비할 수 있다.
스토리지 시스템(120) 각각에 구비된 하나 이상의 저장매체들은 동일한 파일 시스템으로 구성되거나 상이한 파일 시스템으로 구성될 수 있으며, 사용자 장치(110)에 포함된 파일 시스템 게이트웨이 유닛(115_1, 115_2. ... , 115_n - 이하 구분의 필요가 없는 경우 편의상 115로 통칭함)은 스토리지 시스템(120)에 구성된 하나 이상의 파일 시스템에 접속 가능하도록 구성될 수 있다.
도시된 바와 같이, 일반적으로 대규모 저장장치가 요구되는 시스템 환경에서는 사용자 어플리케이션(예를 들어, 워드프로세서, 멀티미디어 재생 프로그램 등의 응용 프로그램 등)이 구동되는 사용자 장치(110)와 독립적으로 구현되는 스토리지 시스템(120)이 통신망을 통해 상호 연결되도록 구성된다.
이때, 사용자 장치(110)와 스토리지 시스템(120) 각각에는 소정의 파일 시스템이 구축되어 운용되고 있으며, 사용자 장치(110)와 스토리지 시스템(120)에 구축된 파일 시스템은 각각 일치하거나 상이한 것일 수 있다. 스토리지 시스템(120)에는 예를 들어 통신망을 통해 원격지에서 스토리지 자원의 억세스가 지원되도록 하는 파일 시스템인 NFS, CIFS, HDFS 등의 파일 시스템이 구축될 수 있고, 각 스토리지 시스템(120) 또는 스토리지 시스템(120)에 구비되는 각 저장매체에 대해 구축된 파일 시스템은 각각 일치하거나 상이할 수도 있다.
도 2에는 사용자 장치(110)가 억세스할 수 있는 파일 시스템과 스토리지 시스템(120)에 구축된 파일 시스템간의 관계에 따른 사용자 장치(110)의 스토리지 시스템(120)에 대한 억세스 상태가 예시되어 있다.
도 2에 예시된 바와 같이, 제1 사용자 장치(110_1)은 파일 시스템 A 및 파일 시스템 B로 구축된 스토리지 시스템(120)에 억세스할 수 있는 파일 시스템 게이트웨이 유닛(115_1)을 구비하고, 제2 사용자 장치(110_2)은 파일 시스템 A, 파일 시스템 D 및 파일 시스템 E로 구축된 스토리지 시스템(120)에 억세스할 수 있는 파일 시스템 게이트웨이 유닛(115_2)을 구비하며, 제n 사용자 장치(110_n)은 파일 시스템 B 및 파일 시스템 C로 구축된 스토리지 시스템(120)에 억세스할 수 있는 파일 시스템 게이트웨이 유닛(115_n)을 구비하는 것으로 가정한다.
또한, 제1 스토리지 시스템(120_1)은 파일 시스템 A 및 파일 시스템 D로 구축된 저장매체를 구비하고, 제2 스토리지 시스템(120_2)은 파일 시스템 B 및 파일 시스템 C로 구축된 저장매체를 구비하며, 제3 스토리지 시스템(120_3)은 파일 시스템 B, 파일 시스템 D 및 파일 시스템 E로 구축된 저장매체를 구비하고, 제n 스토리지 시스템(120_m)은 파일 시스템 C 및 파일 시스템 D로 구축된 저장매체를 구비하는 것으로 가정한다.
이와 같이, 각각의 스토리지 시스템(120)은 상이한 파일 시스템을 지원하는 저장매체가 구성되어 있으며, 사용자 장치(110)에 설치된 사용자 어플리케이션은 해당 사용자 장치(110)에 포함된 파일 시스템 게이트웨이 유닛(115)이 억세스할 수 있는 스토리지 시스템(120)의 저장매체(즉, 공통된 파일 시스템으로 구축된 저장매체)에 억세스 처리에 의해 파일의 독출(read), 기록(write) 등의 처리가 가능하다.
즉, 구비된 파일 시스템 게이트웨이 유닛(115)의 처리에 의해 제1 사용자 장치(110_1)는 동일한 파일 시스템으로 구축된 제1 스토리지 시스템(120_1), 제2 스토리지 시스템(120_2) 및 제3 스토리지 시스템(120_3)의 저장 매체에 억세스할 수 있고, 제2 사용자 장치(110_2)는 제1 스토리지 시스템(120_1), 제3 스토리지 시스템(120_3) 및 제n 스토리지 시스템(120_m)의 저장매체에 억세스할 수 있으며, 제n 사용자 장치(110_n)는 제2 스토리지 시스템(120_2), 제3 스토리지 시스템(120_3) 및 제n 스토리지 시스템(120_m)의 저장매체에 억세스할 수 있다. 물론, 각 사용자 장치(110)가 해당 스토리지 시스템(120)에 억세스될 수 있을지라도, 억세스하도록 설정된 파일 시스템으로 구축된 개별 저장매체에 대한 억세스만이 허용될 것이다.
이때, 각 사용자 장치(110)에 구비된 파일 시스템 게이트웨이 유닛(115)이 어떤 파일 시스템으로 구축된 스토리지 시스템(120) 및/또는 저장매체에 억세스하도록 할 것인지는 이후 설명되는 바와 같이, 사용자가 직접 간단한 프로그램 작성을 통해 구현할 수 있는 프로그래머블 로직 블록(220, 도 3 참조)의 구성 방법에 따라 상이해질 수 있다.
파일 시스템 게이트웨이 유닛(115)이 복수의 파일 시스템을 지원하도록 사용자가 프로그램하는 것(즉, 프로그래머블 로직 블록(220)을 구축하는 것)이 반드시 더 많은 스토리지 자원(즉, 용량)을 사용할 수 있음을 의미하지는 않으나, 스토리지 시스템(120)의 사용자로 하여금 보다 더 다양한 스토리지 자원을 사용할 수 있도록 하여 결과적으로 더 많은 자원을 사용할 수 있는 가능성을 가지도록 한다.
도 2에는 각 파일 시스템 게이트웨이 유닛(115)이 2 내지 3 종류의 파일 시스템(예를 들어, 제1 사용자 장치인 경우 FS-A와 FS-B)을 지원하는 스토리지 시스템(120)에 억세스할 수 있도록 프로그램하는 경우가 예시되었으나, 그 이상의 파일 시스템의 지원이 가능하도록 파일 시스템 게이트웨이 유닛(115)이 구현될 수도 있음은 당연하다.
이제까지 도 1 및 2를 참조하여 간략히 설명되고, 이후 관련 도면을 참조하여 상세히 설명되는 바와 같이, 본 발명의 실시예는 응용 프로그램이나 사용자 장치(110)의 중단없이 사용자 장치(110)에 설치된 응용 프로그램(사용자 어플리케이션)이 다양한 종류의 파일 시스템을 사용할 수 있는 방법을 제공한다. 이 경우, 새로운 파일 시스템을 추가적으로 이용하고자 하는 경우에도 프로그래머블 로직 블록(220)의 갱신을 통해 응용 프로그램이나 사용자 장치(110)의 중단없이 새로운 파일 시스템의 이용이 가능하도록 구현할 수도 있다.
이를 위해, 본 발명의 실시예들에서는 기존 운영체제가 제공하는 파일 시스템과 응용 프로그램 사이의 인터페이스 체계(예를 들어, 가상 파일 시스템(VFS, Virtual File System) 등)를 이용하지 않고, 도시된 파일 시스템 게이트웨이 유닛(115)이 해당 처리를 수행한다.
이를 통해, 사용자 장치(110)는 다양한 파일 시스템에 대한 각각의 특성이나 사용자 어플리케이션이 요청하는 데이터 특성에 대해 파일 시스템 억세스 정책을 최적화할 수 있고, 이러한 처리가 사용자의 간단한 프로그램 작성을 통해 구현될 수 있는 장점을 가진다.
도 3은 본 발명의 일 실시예에 따른 사용자 장치의 구성을 개략적으로 나타낸 블록 구성도이고, 도 4는 본 발명의 일 실시예에 따른 프로그래머블 로직 블록의 구성을 개략적으로 나타낸 도면이다.
도 3을 참조하면, 파일 시스템 게이트웨이 유닛(115)은 인터페이스 블록(Interface block)(210), 프로그래머블 로직 블록(Programmable logic block)(220), 수집 블록(Aggregation block)(230) 및 드라이버 및 API(Application Programming Interface) 블록(240)을 포함하여 구성될 수 있다.
인터페이스 블록(210)은 사용자 장치(110)에 설치된 하나 이상의 사용자 어플리케이션이 파일 시스템 게이트웨이 유닛(115)과 연동되도록 하는 API(Application Programming Interface)와 라이브러리 등의 형태를 제공하는 파일 시스템 인터페이스 모듈을 포함할 수 있다.
프로그래머블 로직 블록(220)은 응용 프로그램이 억세스할 파일 시스템의 종류와 여러 종류의 파일 시스템에 대한 억세스 정책 등을 사용자가 직접 프로그래밍하여 구성하는 블록이다. 사용자는 프로그래머블 로직 블록(220)의 수정 등을 통해 파일 시스템에 대한 억세스 정책 등을 갱신할 수 있다.
도 4에는 프로그래머블 로직 블록(220)의 구성이 개략적으로 도시되어 있다.
도 4를 참조하면, 프로그래머블 로직 블록(220)은 다양한 종류의 파일 시스템에 대한 억세스 조건을 사용자 장치(110) 또는 별도의 시스템에서 프로그램(즉, 사용자 작성 프로그램)하고, 작성된 프로그램을 사용자 장치(110)에서 구동될 수 있는 언어로 변환시키는 컴파일러나 인터프리터를 이용하여 변환한 후, 파일 시스템 게이트웨이 유닛(115)의 사용자 프로그램 영역에 이식함으로써 구성할 수 있다.
파일 시스템 게이트웨이 유닛(115)은 프로그래머블 로직 블록(220)에 형성된 파일 시스템의 억세스 정책에 상응하도록 스토리지 시스템(120)에 대한 억세스를 수행한다.
프로그래머블 로직 블록(220)은 관리 로직부(310), 수집기 리스트(Aggregator List) 관리부(320), 스토리지 리스트 관리부(330), 드라이버 상태정보 관리부(340) 및 캐시 상태정보 관리부(350)를 포함한다. 이외에도 사용자는 추가적인 기능이 요구되는 경우 이에 대한 프로그램을 추가로 작성하여 해당 관리부를 구성할 수도 있다.
관리 로직부(310)는 사용자 어플리케이션과 연동하여 사용자 어플리케이션으로부터 제공되는 스토리지 시스템(120)에 대한 억세스 요청을 분석하고 수집기 리스트(Aggregator List) 관리부(320), 스토리지 리스트 관리부(330), 드라이버 상태정보 관리부(340) 및 캐시 상태정보 관리부(350)에서 관리하는 정보를 참조하여 적절한 수집기(234) 및/또는 스토리지 시스템(120)을 선정하고, 스토리지 시스템(120)에 대한 억세스 결과를 수집 블록(230)으로부터 제공받아 사용자 어플리케이션으로 제공한다.
관리 로직부(310)는 억세스 요청에 따른 파일이 수집 블록(230)의 수집기 캐시(232)에 저장되어 있는 경우, 선정한 수집기(234)를 동작시키지 않고 저장된 파일을 요청한 사용자 어플리케이션으로 제공할 수도 있다.
수집기 리스트 관리부(320)는 다양한 종류의 파일 시스템들이 설치된 각 스토리지 시스템(120)이 제공하는 스토리지 자원을 통합적으로 억세스하는 수집기(Aggregator)의 종류 및 기능을 정의하고 관리한다.
스토리지 리스트 관리부(330)는 스토리지 시스템(120)들 각각에 설치된 파일 시스템의 종류 및 스토리지 시스템(120)에 대한 억세스 경로 정보를 관리한다.
드라이버 상태정보 관리부(340)는 사용자 장치(110)가 억세스할 수 있는 스토리지 시스템(120)의 상태 정보를 수집 및 관리한다. 예를 들어, 드라이버 상태정보 관리부(340)는 드라이버 및 API 블록(240)에 구비된 드라이버의 상태 정보(예를 들어, 각각의 스토리지 시스템(120)과의 통신 장애 발생 여부, 과부하 여부 등의 상태 정보 등)를 참조하여 각 스토리지 시스템(120)에 대한 상태 정보를 수집 및 관리할 수 있다. 파일 시스템 게이트웨이 유닛(115)은 드라이버 상태정보 관리부(340)에 의해 관리되는 상태 정보를 이용하여 스토리지 시스템(120) 간의 억세스 부하나 데이터 저장 용량이 분산되도록 처리할 수 있고, 또한 장애가 발생한 스토리지 시스템(120)이 존재하는 경우 우회하거나 장애발생 사실을 사용자 어플리케이션 등으로 통지할 수 있을 것이다.
캐시 상태정보 관리부(350)는 수집 블록(230)에 구비된 수집기 캐시(232) 및 파일 시스템 캐시(236)의 이용 상태 정보(예를 들어, Full, Empty, 이용 비율 등)를 수집 관리하는 기능을 수행한다. 파일 시스템 게이트웨이 유닛(115)은 캐시 상태정보 관리부(350)에 의해 관리되는 이용 상태 정보를 이용하여 캐시 사용 수준이 미리 지정된 임계값(예를 들어 90%) 이상인 경우 해당 캐시에 더 많은 메모리 자원을 할당하도록 사용자 어플리케이션 등으로 통지할 수도 있다.
여기서, 수집기 캐시(232)는 각 수집기(234)별로 개별 이용하도록 구분되어 운용될 수 있고, 파일 시스템 캐시(236)는 각 스토리지 시스템(120)별로 개별 할당되도록 구분되어 운용될 수 있다. 수집 블록(230)은 파일 시스템 캐시(236) 내에 사용자 어플리케이션이 요청한 파일이 존재하는 경우 스토리지 시스템(120)에 억세스하지 않고 파일 시스템 캐시(236) 내에 존재하는 파일을 사용자 어플리케이션으로 제공함으로써 파일 시스템 게이트웨이 유닛(115)의 성능을 향상시킬 수 있다.
프로그래머블 로직 블록(220)을 구성하기 위해 사용자가 작성하는 프로그램의 작성 예를 제시하면 다음과 같다. 물론, 해당 프로그램의 작성 형태는 다양할 수 있으며, 아래에 제시된 예에 제한되지 않음은 당연하다.
/*******************************************************
User programming module main program algorithm example
********************************************************/

/*
억세스하기 위한 파일 시스템의 종류 및 각 파일 시스템의 특성 정의
*/
FileSystemDefine :=
{
FileSystemType_1 :: FileSystemName, /* 예를 들어 파일 시스템 식별정보 */
FileSystemPath, /* 예를 들어 디렉토리, IP 주소, URL 주소 등의 표시형태 */
FileSystemType, /* 예를 들어 NFS, CIFS 등 */
ResponseTimeOutCondition, /* 예를 들어 스토리지 시스템의 장애, 과부하 상태 등의 파악용으로 응답 대기를 위한 최대 지연시간 등 */
....
FileSystemType_2 :: ...
}

/*
사용자 어플리케이션에 따라 억세스 가능한 파일 시스템 종류를 정의
*/
FileSystemAccessList[] :=
{
ApplicationA[] := {File_System_A};
ApplicationB[] := {File_System_A, File_System_C}; /* 응용프로그램이 동시에 여러 종류의 파일시스템을 액세스할 수 있도록 지정 */
ApplicationC[] := {File_System_B, File_System_D, ...}
....;
}
/*
사용자 어플리케이션의 종류에 따라 수집기(Aggregator) 알고리즘 종류를 정의

Application_AggregationAlgorithm[] := /* 사용자 어플리케이션별 사용할 수집기 및 억세스 정책의 정의*/
{
ApplicationA_AggregationAlgorithm := AllOrNothing;
ApplicationB_AggregationAlgorithm := SequencialAccess;
ApplicationC_AggregationAlgorithm := FirstResponse;
...
}

/*
인터페이스 블록(210)으로부터 사용자 어플리케이션의 스토리지 시스템 액세스 요청을 받는 알고리즘
*/
While( ) /* 무한 루프 */
{
GetUserApplicationRequest(
UserAppication ID, /* 사용자 어플리케이션 구분용 식별자 */
UserApplicationRequestType, /* 예) open(), read(), write()등 */
UserDataPath, /* 액세스 요청된 파일의 저장경로, 일반적으로 /user/app/... 등의 형태 */
FileID /*액세스 요청된 파일 ID(또는 파일이름)*/
...
);
}

/*
사용자 어플리케이션의 요청에 대해 수집기 종류를 선정하여 스토리지 시스템을 억세스하도록 하는 알고리즘
*/

If(Aggregator Cache Block에 요청 데이터 있음)
Return (Aggregator Cache Block에서 데이터 액세스)
Else
AggregatorCall
(
/*사용자 어플리케이션이 액세스 할 수 있는 파일시스템 종류 정보*/
FileSystemAccessList[UserAppication ID],
/*사용자 어플리케이션의 스토리지 시스템 액세스 요청에 대해, 사용할 수집기(알고리즘) 선정 */
Application_AggregationAlgorithm[UserAppication ID]
UserApplicationRequestType,
UserDataPath,
FileID
...
)
Return(AggregatorCall()결과);
위의 예에서 제시되는 바와 같이, 프로그래머블 로직 블록(220)을 구성하기 위한 사용자 작성 프로그램은 예를 들어 상기 사용자 장치가 억세스 가능한 파일 시스템의 종류를 정의하기 위한 영역, 각각의 사용자 어플리케이션에 대해 억세스 가능한 파일 시스템의 종류 정의 영역, 각각의 어플리케이션의 종류에 따라 선정될 수집기의 종류를 정의하기 위한 영역, 사용자 어플리케이션의 억세스 요청 형태(예를 들어, read, write 등)에 대응되는 수집기를 정의하기 위한 영역 및 사용자 어플리케이션으로부터 스토리지 시스템에 대한 억세스 요청을 입력받는 영역 등 중 하나 이상을 포함할 수 있다.
사용자 장치(110)가 억세스할 수 있는 파일 시스템을 정의하는 영역에는 앞서 설명된 바와 같이, FileSystemName, FileSystemPath, DefaultFileName, FileSystemType, ResponseTimeOutCondition 등의 파라미터들이 정의될 수 있고, 사용자의 목적에 따라 더 많은 종류의 파라미터(예를 들어, 중복저장 개수 등)가 스토리지 시스템(120)의 성능, 안정성 또는 관리 용이성 등의 향상을 위해 추가될 수 있음은 당연하다.
또한 사용자 어플리케이션으로부터 스토리지 시스템(120)에 대한 억세스 요청을 입력받는 영역에는 사용자 어플리케이션 각각을 구분하기 위한 어플리케이션 식별자인 UserAppication ID, 사용자 어플리케이션에 대해 억세스 하고자 하는 기능(예를 들어, read, write 등)의 종류인 UserApplicationRequestType, 그리고 사용자 어플리케이션이 액세스 하고자 하는 스토리지 경로 정보인 UserDataPath 등을 지정할 수 있으며, 이 밖에도 사용자가 원하는 파라미터가 추가될 수도 있다.
또한 사용자 어플리케이션의 스토리지 시스템(120) 억세스 요청에 대응되는 수집기(Aggregator)를 선정하는데 있어서, 사용자 어플리케이션의 종류 또는 사용자 어플리케이션의 스토리지 시스템(120) 억세스 요청 형태(예를 들어, read, write 등)에 따라 임의의 수집기 알고리즘이 선택되도록 프로그램이 구성된다. 위의 예시에서, 사용자 어플리케이션의 종류에 따라 수집기 알고리즘 종류를 정의함에 있어, 해당 알고리즘 정의는 사용자 어플리케이션의 종류에 따라 개별적으로 정의할 수도 있지만, 사용자 어플리케이션의 스토리지 시스템 억세스 유형(예를 들어, Read, Write 등)에 따라 정의할 수도 있다.
또한, 사용자 어플리케이션별로 적용할 억세스 정책 즉, 어떤 경우에 하나 이상의 스토리지 시스템(120)에 대한 억세스가 정상적으로 완료된 것으로 판단할 것인지가 결정될 수 있다.
위의 예시에는, 적용될 수 있는 억세스 정책으로서 SequencialAccess(지정된 하나 이상의 스토리지 시스템에 대한 데이터 억세스를 모두 수행하되, 어느 하나의 스토리지 시스템에서라도 지정된 파일의 억세스가 성공하면 억세스가 정상적으로 완료된 것으로 사용자 어플리케이션에 보고함), AllOrNothing(지정된 스토리지 시스템 모두에서 데이터 억세스가 성공적으로 완료된 경우에만 데이터 억세스가 정상적으로 완료된 것으로 사용자 어플리케이션에 보고), FirstResponse(지정된 하나 이상의 스토리지 시스템들 중 어느 하나의 스토리지 시스템만이라도 정상적인 데이터 억세스가 수행되면 나머지 다른 스토리지 시스템에 대한 억세스는 중지하고 억세스가 정상적으로 완료된 것으로 사용자 어플리케이션에 보고)가 예시되어 있다. 이외에도, 사용자는 다른 형태의 억세스 정책을 자유롭게 설정하여 프로그램에 기재할 수 있음은 당연하다.
프로그래머블 로직 블록(220)은 예를 들어, 사용자 어플리케이션과 인터페이스 블록(210)을 통해 일반적인 파일 시스템 프로토콜(예를 들어, FTP, NFS, CIFS 등)을 이용하여 연동할 수 있고, 수집 블록(230)과는 프로세스간 연동 프로토콜(예를 들어 Pipe 통신)을 이용하여 연동할 수 있도록 함으로써, 사용자 어플리케이션이 구동되는 동안에도(중단 없이) 프로그래머블 로직 블록(220)의 수정 및/또는 업데이트가 가능하도록 구성할 수 있다.
다시 도 3을 참조하면, 사용자가 구성한 프로그래머블 로직 블록(220)의 스토리지 시스템 억세스 정책에 따라 파일 시스템에 대한 억세스를 수행하는 수집 블록(230)은 각 스토리지 시스템에 각각 구축된 다양한 종류의 파일 시스템에 대한 수집 정책이 각각 프로그램되어 있는 복수의 수집기(234), 수집기 캐시(232), 파일 시스템 캐시(236)와, 실제 파일 시스템(즉, 스토리지 시스템(120))에 억세스하는 드라이버 및 API 블록(240)과의 인터페이스를 제공하는 접속부(238)를 포함하여 구성될 수 있다.
수집기 캐시(232)는 프로그래머블 로직 블록(220)과 수집 블록(230)간의 고속 데이터 억세스를 지원하기 위한 캐시이며, 각 수집기(234)별로 할당되어 각각의 수집기(234)에 의해 억세스된 파일(또는 데이터) 저장된다.
파일 시스템 캐시(236)는 수집 블록과 스토리지 시스템(120)간의 고속 데이터 억세스를 지원하기 위한 캐시이며, 각 스토리지 시스템(120)별로 할당되어 임의의 수집기(234)에 의해 해당 스토리지 시스템(120)으로부터 억세스된 파일이 해당 캐시에 저장된다.
수집기 캐시(232)와 파일 시스템 캐시(236)는 파일 시스템 게이트웨이 유닛(115)의 성능 향상을 위해 이전의 데이터 억세스 결과를 이용하여 신속한 데이터 억세스가 가능하도록 한 것으로, 사용자의 목적에 따라 수집기 캐시(232)와 파일 시스템 캐시(236) 모두를 포함하여 구성되거나 어느 하나 이상이 제외되어 구성될 수도 있다.
종래기술에 따른 파일 시스템에서의 데이터 억세스는 일반적으로 read(fd, buf, size) 등과 같은 형태의 함수를 통해 데이터 억세스가 이루어지며, 이는 지정된 파일 아이디(fd)를 가지는 데이터를 지정된 크기(size)만큼 억세스하여 지정된 저장소(buf)에 저장하도록 하는 함수이다. 이러한 구조의 함수는 일단 실행되면 지정된 조건(예를 들어, 크기(size) 조건)을 모두 만족할 때까지 파일 시스템에 대한 억세스가 수행된다.
그러나 본 실시예에 따른 파일 시스템 게이트웨이 유닛(115)을 구비한 사용자 장치(110)는 사용자 어플리케이션이 전술한 종래기술에 따른 형태의 함수를 이용하여 파일 시스템에 대한 억세스를 요청할지라도, 수집 블록(230)의 지정된 수집기(234)는 프로그래머블 로직 블록(220)에 규정된 억세스 정책(즉, 억세스 알고리즘)에 따른 데이터 억세스를 수행한다.
앞서 설명한 바와 같이, 수집기(234)에 적용되는 억세스 정책은 예를 들어 AllOrNothing, FirstResponse, SequencialAccess 등일 수 있다.
예시된 AllOrNothing 알고리즘은 하나의 파일을 복수의 스토리지 시스템(120)에 복제 파일을 만들 때, 지정된 스토리지 시스템(120) 모두에 대해 복제가 완료되어야 만족되는 억세스 정책일 수 있다. 마찬가지로, 사용자 어플리케이션이 “user/hwp/” 디렉토리에 존재하는 a.hwp에 대한 억세스를 요청한 경우, 해당 사용자 어플리케이션에 대해 지정된 수집기(234)는 지정된 스토리지 시스템(120)들의 저장매체들에서 해당 디렉토리 내의 해당 파일이 존재하는 경우 모두 억세스하여 결과를 사용자 어플리케이션으로 전달하도록 할 수도 있다.
또한 FirstResponse 알고리즘은 지정된 하나 이상의 스토리지 시스템들 중 어느 하나의 스토리지 시스템만이라도 정상적인 데이터 억세스가 수행되면 억세스가 정상적으로 완료된 것으로 판단하는 억세스 정책으로서, 사용자 어플리케이션이 매우 빠른 응답을 받을 필요가 있거나 가장 빠른 스토리지 시스템을 이용하고자 할 때 사용할 수 있다.
예를 들어 억세스 빈도가 적거나 새로 추가된 스토리지 시스템이 사용자 어플리케이션의 억세스 요청에 대한 빠른 응답을 주게 되므로, 사용자가 부하가 적은 스토리지 시스템에 억세스하고자 할 때 FirstResponse 알고리즘을 이용함으로써 빠른 응답효과를 얻을 수 있고 또한 스토리지 시스템(120) 사이의 부하분산 효과도 얻을 수 있다
또한 수집기(234)를 SequencialAccess 알고리즘을 기반으로 하여 구현하게 되면, 사용자 어플리케이션이 억세스하도록 지정한 모든 스토리지 시스템(120)에 대해 미리 지정된 순서에 따라 순차적인 파일 억세스가 실행된다. 만일 파일이 Active-Standby 형태로 구성된 스토리지 시스템(120)에 저장된 경우 SequencialAccess 알고리즘을 이용하면, 먼저 Active 스토리지를 억세스한 후 억세스가 실패한 경우 Standby 스토리지를 억세스하도록 함으로써 스토리지 시스템(120)의 가용성을 향상시킬 수도 있다.
접속부(238)는 수집기(234)들이 표준화된 인터페이스를 이용(예를 들어 파일 시스템 억세스 함수 이용)하여 다양한 종류의 파일 시스템에 억세스할 수 있는 환경을 제공한다. 만일 새로운 파일 시스템을 이용하고자 하는 경우, 사용자는 통상적인 방법으로 사용자 장치 및/또는 원격지에 위치하는 스토리지 시스템(120)에 이용할 파일 시스템을 설치하고, 파일 시스템 드라이버나 API를 접속부(238)에 연동시키는 작업을 통해 파일 시스템과 파일 시스템 게이트웨이 유닛(115)과의 연결이 완료된다.
하기 예시되는 파일 시스템 억세스 함수를 이용함으로써, 접속부(238)는 본 실시예에 따른 파일 시스템 게이트웨이 유닛(115)이 통상의 스토리지 시스템(120)뿐 아니라 데이터를 제공하는 다양한 서비스를 스토리지 시스템(120)처럼 억세스 가능하도록 할 수도 있다.
일 예로, 통상의 스토리지 시스템에 접속하기 위한 파일 시스템 억세스 함수는 FileSystemRead(FileSystemName, FileSystemDriver, Buffer, Size)로 정의될 수 있다. 여기서, FileSystemRead는 억세스 요청 형태에 대한 정보, FileSystemName은 파일 시스템 식별 정보, FileSystemDriver는 파일의 저장 위치에 대한 디렉토리 정보, Buffer는 억세스된 파일의 저장소 정보, Size는 억세스할 데이터 크기 정보를 나타낼 수 있다.
또한 트위터, 페이스북과 같은 SNS 서비스를 스토리지 시스템(120)처럼 인식하여 데이터를 수집 및 저장하기 위한 파일 시스템 억세스 함수는 FileSystemRead(SNS_Name, SNS_Read_OpenAPI, Buffer, Size)와 같이 정의될 수도 있을 것이다. 여기서, FileSystemRead는 접속부(238)가 스토리지 시스템(120)에서 데이터를 읽을때 사용하기 위해 정의한 표준함수이고, SNS_Name는 데이터를 읽어들일 SNS 서비스 이름을 나타내며, SNS_Read_OpenAPI는 SNS 서비스가 데이터 수집 대상에게 제공하는 Open API 이름을 나타내고, Buff는 SNS 서비스로부터 수집한 데이터를 저장할 저장소(또는 파일 정보)를 나타내며, Size는 SNS 서비스로부터 수집할 데이터 용량을 나타낸다.
전술한 바와 같이, 사용자의 필요에 따라 사용자 작성 프로그램의 작성 및 프로그래머블 로직 블록(220)을 구성함으로써 수집기(234) 운용을 위한 알고리즘 추가가 가능하고, 또한 접속부에 신규 추가되는 파일 시스템에 대한 인터페이스를 추가함으로써 새로운 파일 시스템(예를 들어, HDFS, Lustre, GLORY FS 등)에 대한 억세스가 가능해질 수 있다.
드라이버 및 API 블록(240)은 임의의 파일 시스템이 구축된 각각의 스토리지 시스템(120)에 연동되기 위한 드라이버 및 API를 포함할 수 있다.
도 5는 본 발명의 일 실시예에 따른 사용자 어플리케이션의 요청에 따른 저장 데이터 억세스 방법을 나타낸 순서도이다.
도 5를 참조하면, 사용자 장치(110)에서 구동되는 사용자 어플리케이션에서 스토리지 시스템(120)에 대한 억세스 이벤트(예를 들어, open(file_id, access mode), read(file_id, size), write(file_id, size) 등)가 발생(단계 410)되면, 해당 사용자 어플리케이션과 연계된 인터페이스 블록(210)은 사용자 어플리케이션 식별자, 파일 경로 정보(예를 들어, 디렉토리 등), 파일 식별자 중 하나 이상을 포함하는 억세스 정보를 생성하여 프로그래머블 로직 블록(220)의 관리 로직부(310)로 전달한다(단계 420).
단계 430에서 관리 로직부(310)는 인터페이스 블록(210)으로부터 전달받은 억세스 정보를 토대로 사용자 어플리케이션별 억세스할 파일 시스템(또는 스토리지 시스템)과 억세스 알고리즘을 수행할 수집기(234)를 선정한다. 이때, 사용자 작성 프로그램에 의해 구축된 수집기 관리부(320), 스토리지 관리부(330), 드라이버 상태정보 관리부(340) 및 캐시 상태정보 관리부(350) 중 하나 이상에 의해 관리되는 상태정보가 고려될 수 있다.
프로그래머블 로직 블록(220)의 관리 로직부(310)는 단계 440에서 수집기 캐시(232)에 억세스 정보에 의해 특정되는 파일이 존재하는지 여부를 판단한다. 만일 수집기 캐시(232)에 해당 파일이 존재하는 경우에는 단계 450으로 진행하여 요청된 파일을 인터페이스 블록(210)을 통해 사용자 어플리케이션으로 전달한다.
그러나, 수집기 캐시(232)에 억세스 정보에 의해 특정되는 파일이 존재하지 않는 경우에는 단계 460으로 진행하여, 단계 440에서 선정된 수집기(234)가 구동되도록 한다.
단계 460에 의해 구동된 수집기(234)는 지정된 스토리지 시스템(120)에 통신망을 통해 억세스하기 전에, 단계 470에서 지정된 스토리지 시스템(120) 각각에 대해 할당된 파일 시스템 캐시 내에 억세스 정보에 의해 특정되는 파일이 존재하는지 여부를 판단한다.
만일 파일 시스템 캐시(236) 내에 해당 파일이 존재하는 경우에는 단계 450으로 진행하여 요청된 파일을 프로그래머블 로직 블록(220) 및 인터페이스 블록(210)을 통해 사용자 어플리케이션으로 전달한다. 이 경우, 구동된 수집기(234)의 동작은 종료될 것이다.
그러나, 파일 시스템 캐시(236) 내에 억세스 정보에 의해 특정되는 파일이 존재하지 않는 경우에는 단계 480으로 진행하여, 프로그래머블 로직 블록(220)의 관리 로직부(310)에 의해 지정된 스토리지 시스템(120)에 통신망을 통한 데이터 억세스를 수행한다. 데이터 억세스에 의해 억세스된 파일은 후속하는 데이터 억세스 과정에서 이용될 수 있도록 파일 시스템 캐시(236) 및 수집기 캐시(232)에 각각 저장될 것이다.
단계 490에서 하나 이상의 스토리지 시스템에 대한 데이터 억세스가 완료되면 프로그래머블 로직 블록(220)의 관리 로직부(310)는 해당 수집기(234)에 대해 지정된 억세스 정책이 만족되었는지 여부를 판단한다. 해당 수집기(234)에 대해 지정된 억세스 정책은 SequencialAccess, AllOrNothing, FirstResponse 등 중 하나일 수 있다.
지정된 억세스 정책이 만족되지 않았다면 해당 억세스 정책이 만족될 때까지 단계 480을 지속하고, 지정된 억세스 정책이 만족되었다면 단계 450으로 진행하여 요청된 파일을 프로그래머블 로직 블록(220) 및 인터페이스 블록(210)을 통해 사용자 어플리케이션으로 전달한다.
단계 480 및 단계 490이 수행되는 과정에서 수집기(234)는 통신망을 통해 각기 상이한 파일 시스템을 가지는 스토리지 시스템(120)에 접속될 수 있다. 이 경우, 수집기(234)에서 파일 시스템 억세스 인터페이스를 호출하기 위한 프로그램이 복잡하여 수집기(234)의 개발 및 수정이 곤란해질 수 있다.
이러한 문제를 해결하기 위해, 본 실시예에서는 수집 블록(230)에 접속부(238)를 추가함으로써, 다양한 파일 시스템들이 제공하는 서로 다른 형식의 억세스 인터페이스를 통일된 형식(예를 들어, 통일된 형식의 파일 시스템 억세스 함수 이용)으로 제공할 수 있는 장점이 있다. 따라서, 수집 블록(230) 내의 수집기(234)들은 접속부(238)에 의해 통일화된(추상화된) 파일 시스템 억세스 함수를 이용하여 다양한 파일 시스템의 스토리지 시스템(120)에 억세스할 수 있다.
전술한 바와 같이, 파일 시스템 게이트웨이 유닛(115)을 포함하는 사용자 장치는 통신망을 통해 동종의 파일 시스템이 구축된 스토리지 시스템(120)뿐 아니라 이종의 파일 시스템이 구축된 스토리지 시스템(120)에 억세스할 수 있도록 구현된다. 그리고 각 스토리지 시스템(120)의 네트워크 연결 상태, 입출력 성능, 제공 용량, 가용 용량 등과 같은 요소를 고려하여 프로그래밍한 사용자 작성 프로그램을 이용하여 프로그래머블 로직 블록(220)을 구축할 수 있도록 함으로써 통신망을 통해 분산 연결된 스토리지 자원의 활용도를 극대화할 수도 있다.
일 예로, 종래에는 NAS(Network-Attached Storage) 스토리지 시스템과 대용량 저장/데이터 분석에 강점을 가지고 있는 하둡 파일 시스템(HDFS)을 함께 사용하고자 하는 경우, 각 스토리지 시스템 별로 사용할 사용자 어플리케이션의 할당 및 관리 시스템이 요구되는 문제점이 있었으나, 본 실시예에 따른 파일 시스템 게이트웨이 유닛(115)을 이용하면 전술한 문제점 없이 이들 이종의 스토리지 자원을 통합하여 관리 및 이용할 수 있게 된다.
따라서 특정의 사용자 어플리케이션에 최적화된 스토리지 시스템 도입의 편리성이 증가하거나 이종 파일 시스템을 지원하는 스토리지 시스템이 혼재된 상황에서도 통합 자원 관리 및 이용이 용이해질 수 있고, IT 서비스 품질의 향상과 함께 스토리지 자원에 대한 투자를 최적화 할 수 있는 효과가 있다. 또한 새로운 기술의 파일 시스템을 지원하는 스토리지 시스템이 도입되더라도 종래의 파일 시스템을 지원하는 스토리지 시스템도 함께 사용할 수 있는 환경이 마련되어 IT 자원 활용도를 높일 수 있고, 동시에 새로운 기술의 파일 시스템 도입에 따른 투자 비용도 최적화 할 수 있다.
상술한 저장 데이터 억세스 방법은 디지털 처리 장치에 내장되거나 설치된 프로그램 등에 의해 시계열적 순서에 따른 자동화된 절차로 수행될 수도 있음은 당연하다. 상기 프로그램을 구성하는 코드들 및 코드 세그먼트들은 당해 분야의 컴퓨터 프로그래머에 의하여 용이하게 추론될 수 있다. 또한, 상기 프로그램은 디지털 처리 장치가 읽을 수 있는 정보저장매체(computer readable media)에 저장되고, 디지털 처리 장치에 의하여 읽혀지고 실행됨으로써 상기 방법을 구현한다. 상기 정보저장매체는 자기 기록매체, 광 기록매체 및 캐리어 웨이브 매체를 포함한다.
상기에서는 본 발명의 실시예를 참조하여 설명하였지만, 해당 기술 분야에서 통상의 지식을 가진 자라면 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.
110 : 사용자 장치 115 : 파일 시스템 게이트웨이 유닛
120 : 스토리지 시스템 210 : 인터페이스 블록
220 : 프로그래머블 로직 블록 230 : 수집 블록
232 : 수집기 캐시 234 : 수집기
236 : 파일 시스템 캐시 238 : 접속부
240 : 드라이버 및 API 블록 310 : 관리 로직부
320 : 수집기 관리부 330 : 스토리지 관리부
340 : 드라이버 상태정보 관리부 350 : 캐시 상태정보 관리부

Claims (16)

  1. 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치에 있어서,
    사용자 작성 프로그램의 설치에 의해 구축되고, 사용자 어플리케이션이 억세스 요청한 데이터를 통신망을 통해 연결되고 하나 이상의 파일 시스템이 각각 설정된 하나 이상의 스토리지 시스템에서 억세스 처리할 수집기(aggregator)를 선정하는 프로그래머블 로직 블록; 및
    구비된 복수의 수집기 중에서, 상기 프로그래머블 로직 블록에 의해 선정된 수집기가 통신망을 통해 연결된 하나 이상의 스토리지 시스템으로부터 요청된 데이터에 대한 억세스 처리를 수행하는 수집 블록을 포함하되,
    상기 프로그래머블 로직 블록은 상기 사용자 어플리케이션의 억세스 요청에 상응하여 소정의 파일 시스템을 선정하고, 상기 수집기는 상기 선정된 파일 시스템이 구축된 스토리지 시스템을 대상으로 요청된 데이터에 대한 억세스 처리를 수행하는 것을 특징으로 하는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치.
  2. 삭제
  3. 제1항에 있어서,
    상기 사용자 작성 프로그램은 상기 사용자 장치가 억세스 가능한 파일 시스템의 종류를 정의하기 위한 영역, 각각의 사용자 어플리케이션에 대해 억세스 가능한 파일 시스템의 종류 정의 영역, 각각의 어플리케이션의 종류에 따라 선정될 수집기의 종류를 정의하기 위한 영역, 사용자 어플리케이션의 억세스 요청 형태에 대응되는 수집기를 정의하기 위한 영역 및 사용자 어플리케이션으로부터 스토리지 시스템에 대한 억세스 요청을 입력받는 영역 중 하나 이상을 포함하는 것을 특징으로 하는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치.
  4. 제3항에 있어서,
    상기 사용자 작성 프로그램은 상기 선정된 수집기 및 상기 사용자 어플리케이션 중 하나 이상에 대한 억세스 정책을 정의하기 위한 영역을 더 포함하고,
    상기 억세스 정책은 SequencialAccess, AllOrNothing 및 FirstResponse 중 하나 이상을 포함하는 것을 특징으로 하는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치.
  5. 제1항에 있어서,
    상기 수집 블록은, 각 수집기별로 개별 이용되도록 할당되는 수집기 캐시 및 각 스토리지 시스템에 대해 개별 할당되는 파일 시스템 캐시를 포함하는 것을 특징으로 하는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치.
  6. 제1항에 있어서,
    각각의 스토리지 시스템에 구축된 파일 시스템과 연동되도록 하기 위한 드라이버 및 API(Application Programming Interface) 블록을 더 포함하고,
    상기 수집 블록에 포함된 접속부는 상기 드라이버 및 API 블록으로 파일 시스템에 관계없이 공통화된 파일 시스템 억세스 함수를 이용한 데이터 억세스 요청을 전송하는 것을 특징으로 하는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치.
  7. 제6항에 있어서,
    상기 파일 시스템 억세스 함수는 억세스 요청 형태에 대한 정보, 파일 시스템 식별 정보, 데이터의 저장 위치에 대한 디렉토리 정보, 억세스된 데이터의 저장소 정보 및 억세스할 데이터의 크기 정보를 포함하도록 구성되는 것을 특징으로 하는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치.
  8. 제6항에 있어서,
    상기 파일 시스템 억세스 함수는 억세스 요청 형태에 대한 정보, SNS(Social Network Service) 식별 정보, SNS 서비스가 상기 사용자 장치에 제공한 Open API 이름 정보, 억세스된 데이터의 저장소 정보 및 억세스할 데이터의 크기 정보를 포함하도록 구성되는 것을 특징으로 하는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치.
  9. 제6항에 있어서,
    상기 사용자 어플리케이션과 상기 프로그래머블 로직 블록간의 통신 프로토콜과 상기 프로그래머블 로직 블록과 상기 드라이버 및 API(Application Programming Interface) 블록간의 통신 프로토콜은 상이한 통신 프로토콜인 것을 특징으로 하는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치.
  10. 제1항에 있어서,
    상기 구축된 파일 시스템은 Hadoop HDFS(Hadoop Distributed File System), Swift, Lustre, Panasas, PVFS2, OASIS, GLORY FS, NFS(Network File System), CIFS(Common Internet File System) 중 하나 이상을 포함하는 것을 특징으로 하는 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치.
  11. 사용자 장치에 의한 저장 데이터 억세스 방법에 있어서,
    (a) 프로그래머블 로직 블록이 사용자 어플리케이션에서 발생된 억세스 이벤트에 상응하는 억세스 정보를 참조하여 상기 사용자 어플리케이션에 상응하도록 지정된 스토리지 시스템 및 수집기를 각각 선정하는 단계; 및
    (b) 상기 수집기가 통신망을 통해 상기 선정된 하나 이상의 스토리지 시스템에 접속하여 상기 억세스 정보에 의해 지정된 데이터를 억세스하는 단계를 포함하되,
    상기 억세스 정보에 의해 지정된 데이터가 수집기 캐시에 저장된 것인지를 판단하는 단계가 상기 (a)와 (b) 사이에서 수행되고,
    상기 수집기 캐시에 상기 데이터가 저장된 경우, 상기 프로그래머블 로직 블록은 상기 저장된 데이터를 상기 사용자 어플리케이션에 제공하는 것을 특징으로 하는 저장 데이터 억세스 방법.
  12. 삭제
  13. 제11항에 있어서,
    상기 수집기는 상기 선정된 스토리지 시스템에 억세스하기 전에,
    파일 시스템 캐시에 상기 억세스 정보에 의해 지정된 데이터가 저장된 것인지를 판단하는 단계; 및
    저장된 경우, 상기 저장된 데이터를 상기 사용자 어플리케이션에 제공하는 단계를 수행하는 것을 특징으로 하는 저장 데이터 억세스 방법.
  14. 제11항에 있어서,
    상기 프로그래머블 로직 블록은 사용자 작성 프로그램의 설치에 의해 구축되고,
    상기 사용자 작성 프로그램은 상기 사용자 장치가 억세스 가능한 파일 시스템의 종류를 정의하기 위한 영역, 각각의 사용자 어플리케이션에 대해 억세스 가능한 파일 시스템의 종류 정의 영역, 각각의 어플리케이션의 종류에 따라 선정될 수집기의 종류를 정의하기 위한 영역, 사용자 어플리케이션의 억세스 요청 형태에 대응되는 수집기를 정의하기 위한 영역 및 사용자 어플리케이션으로부터 스토리지 시스템에 대한 억세스 요청을 입력받는 영역을 포함하는 것을 특징으로 하는 저장 데이터 억세스 방법.
  15. 제14항에 있어서,
    상기 사용자 작성 프로그램은, 상기 선정된 수집기 및 상기 사용자 어플리케이션 중 하나 이상에 대한 억세스 정책을 정의하기 위한 영역을 더 포함하고,
    상기 억세스 정책은 SequencialAccess, AllOrNothing 및 FirstResponse 중 하나 이상을 포함하는 것을 특징으로 하는 저장 데이터 억세스 방법.
  16. 제11항에 있어서,
    상기 선정된 스토리지 시스템들은 상이한 파일 시스템에 의해 구축되고,
    상기 구축된 파일 시스템은 Hadoop HDFS(Hadoop Distributed File System), Swift, Lustre, Panasas, PVFS2, OASIS, GLORY FS, NFS(Network File System), CIFS(Common Internet File System) 중 각각 어느 하나인 것을 특징으로 하는 저장 데이터 억세스 방법.
KR1020120130233A 2012-11-16 2012-11-16 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법 KR101440605B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020120130233A KR101440605B1 (ko) 2012-11-16 2012-11-16 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020120130233A KR101440605B1 (ko) 2012-11-16 2012-11-16 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법

Publications (2)

Publication Number Publication Date
KR20140063181A KR20140063181A (ko) 2014-05-27
KR101440605B1 true KR101440605B1 (ko) 2014-09-18

Family

ID=50891247

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020120130233A KR101440605B1 (ko) 2012-11-16 2012-11-16 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법

Country Status (1)

Country Link
KR (1) KR101440605B1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101924099B1 (ko) * 2016-12-26 2018-11-30 경희대학교 산학협력단 정책 기반의 스토리지 서비스 페더레이션 수행 방법 및 장치

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020165941A1 (en) 2001-02-27 2002-11-07 Gahan Richard A. Network area storage block and file aggregation
JP2007287180A (ja) 2007-07-26 2007-11-01 Hitachi Ltd 分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法
JP2009251756A (ja) 2008-04-02 2009-10-29 Nec Corp クライアント装置、分散ファイルシステム、共有リソース多重化方法およびプログラム
KR20100062442A (ko) * 2008-12-02 2010-06-10 엔에이치엔비즈니스플랫폼 주식회사 파일 스토리지 액세스 시스템 및 방법

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020165941A1 (en) 2001-02-27 2002-11-07 Gahan Richard A. Network area storage block and file aggregation
JP2007287180A (ja) 2007-07-26 2007-11-01 Hitachi Ltd 分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法
JP2009251756A (ja) 2008-04-02 2009-10-29 Nec Corp クライアント装置、分散ファイルシステム、共有リソース多重化方法およびプログラム
KR20100062442A (ko) * 2008-12-02 2010-06-10 엔에이치엔비즈니스플랫폼 주식회사 파일 스토리지 액세스 시스템 및 방법

Also Published As

Publication number Publication date
KR20140063181A (ko) 2014-05-27

Similar Documents

Publication Publication Date Title
AU2019213340B2 (en) Dynamic configuration of data volumes
CA2978889C (en) Opportunistic resource migration to optimize resource placement
KR101920173B1 (ko) 스토리지 클라이언트 파일 시스템들을 위한 스토리지 볼륨들의 동적 스케일링
EP2284725B1 (en) Client, brokerage server and method for providing cloud storage
US9285992B2 (en) System and method for optimally creating storage objects in a storage system
JP2021522615A (ja) ストレージボリューム作成方法および装置、サーバ、並びに記憶媒体
US10616134B1 (en) Prioritizing resource hosts for resource placement
KR101430649B1 (ko) 클라우드 환경 내의 데이터 분석 서비스 제공 시스템 및 방법
US10776173B1 (en) Local placement of resource instances in a distributed system
CN104050248A (zh) 一种文件存储系统及存储方法
US11347413B2 (en) Opportunistic storage service
CN105739930A (zh) 一种存储架构及其初始化方法和数据存储方法及管理装置
US10812408B1 (en) Preventing concentrated selection of resource hosts for placing resources
US11336519B1 (en) Evaluating placement configurations for distributed resource placement
KR101440605B1 (ko) 파일 시스템 게이트웨이 유닛을 구비한 사용자 장치 및 저장 데이터 억세스 방법
US10721181B1 (en) Network locality-based throttling for automated resource migration
CN117093158B (zh) 分布式存储系统的存储节点、系统、数据处理方法及装置
US20230244390A1 (en) Collecting quality of service statistics for in-use child physical functions of multiple physical function non-volatile memory devices
KR20140060962A (ko) 네트워크 분산 파일 시스템에서 유휴 리소스를 이용한 다중 서비스 제공 시스템 및 방법

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
FPAY Annual fee payment

Payment date: 20170904

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20180903

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20191014

Year of fee payment: 6