KR101679512B1 - 대용량 데이터 처리를 위한 레거시 데스크탑 기반 파일의 분산 저장 시스템 및 방법 - Google Patents

대용량 데이터 처리를 위한 레거시 데스크탑 기반 파일의 분산 저장 시스템 및 방법 Download PDF

Info

Publication number
KR101679512B1
KR101679512B1 KR1020150067800A KR20150067800A KR101679512B1 KR 101679512 B1 KR101679512 B1 KR 101679512B1 KR 1020150067800 A KR1020150067800 A KR 1020150067800A KR 20150067800 A KR20150067800 A KR 20150067800A KR 101679512 B1 KR101679512 B1 KR 101679512B1
Authority
KR
South Korea
Prior art keywords
server
client
clients
storage
reference value
Prior art date
Application number
KR1020150067800A
Other languages
English (en)
Other versions
KR20160134173A (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 KR1020150067800A priority Critical patent/KR101679512B1/ko
Publication of KR20160134173A publication Critical patent/KR20160134173A/ko
Application granted granted Critical
Publication of KR101679512B1 publication Critical patent/KR101679512B1/ko

Links

Images

Classifications

    • 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/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • G06F17/30194—
    • 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]
    • 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/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer

Landscapes

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

Abstract

대용량 데이터 처리를 위한 레거시 데스크탑 기반 파일의 분산 저장 시스템 및 방법이 개시된다. 본 발명의 일 실시예에 따른 파일의 분산 저장 시스템은, 스토리지를 구비하는 복수의 클라이언트; 및 저장하고자 하는 대상 파일을 분할하고, 분할된 상기 대상 파일을 복수의 상기 클라이언트의 상기 스토리지 내에 분산 저장하는 서버를 포함하며, 상기 클라이언트는, 상기 서버의 장애 여부의 판별을 위한 점검 메시지를 설정된 주기마다 상기 서버에 송신하며, 설정된 기간 동안 상기 점검 메시지에 대한 응답 메시지를 상기 서버로부터 수신하지 않는 경우 상기 서버에 장애가 발생한 것으로 판단한다.

Description

대용량 데이터 처리를 위한 레거시 데스크탑 기반 파일의 분산 저장 시스템 및 방법 {SYSTEM AND METHOD FOR DISTRIBUTIVELY STORING FILES BASED ON LEGACY DESKTOP FOR PROCESSING BIG DATA}
본 발명의 실시예들은 파일을 분산 저장하는 기술과 관련된다.
빅데이터 시대가 도래함에 따라, 대용량 데이터를 효율적으로 처리하기 위한 방법으로서 하둡 분산 파일 시스템(HDFS: Hadoop Distributed File System) 기술이 사용되고 있다. 하둡 분산 파일 시스템의 경우 파일과 블록, 데이터 노드의 매핑 정보를 관리하는 네임 노드(Namenode), 각 파일을 블록 단위로 여러 장소에 분산 저장하는 데이터 노드(Datanode) 및 파일 백업을 위한 백업 노드(Backupnode)를 이용하여 데이터를 분산 저장한다. 그러나, 종래 기술에 따르면 네임 노드 및 백업 노드 모두에서 장애가 발생한 경우 데이터 노드에 저장된 파일들이 무용지물이 되는 문제점이 있었다. 또한, 종래 기술에 따르면, 사용자의 파일이 어디에 저장되어 있는지 여부를 알 수 없어 저장된 파일에 대한 손실 위험이 있었으며, 파일 메타 정보를 중앙 서버에서 관리함에 따라 서버의 다운 등과 같은 장애 발생시 이에 대한 대처가 어려운 문제점이 있었다.
본 발명의 실시예들은 클라이언트 내 스토리지에 대상 파일을 효율적으로 분산 저장하기 위한 수단을 제공하기 위한 것이다.
본 발명의 예시적인 실시예에 따르면, 스토리지를 구비하는 복수의 클라이언트; 및 저장하고자 하는 대상 파일을 분할하고, 분할된 상기 대상 파일을 복수의 상기 클라이언트 내 스토리지 내에 분산 저장하는 서버를 포함하며, 상기 클라이언트는, 상기 서버의 장애 여부의 판별을 위한 점검 메시지를 설정된 주기마다 상기 서버에 송신하며, 설정된 기간 동안 상기 점검 메시지에 대한 응답 메시지를 상기 서버로부터 수신하지 않는 경우 상기 서버에 장애가 발생한 것으로 판단하는, 파일의 분산 저장 시스템이 제공된다.
상기 서버는, 클라이언트 메타 정보를 복수의 상기 클라이언트에 각각 송신하며, 상기 클라이언트는, 상기 서버에 장애가 발생한 것으로 판단된 경우 상기 클라이언트 메타 정보를 이용하여 복수의 상기 클라이언트를 정렬하고, 정렬된 복수의 상기 클라이언트 중 최상단에 위치한 클라이언트를 대체 서버로 선정할 수 있다.
상기 클라이언트 메타 정보는, 상기 서버에서 복수의 상기 클라이언트 각각에 호출 메시지를 송신한 경우 복수의 상기 클라이언트 각각으로부터 상기 호출 메시지에 대한 응답 메시지를 수신하는 데까지 걸리는 시간, 복수의 상기 클라이언트 각각의 CPU 점유율, 복수의 상기 클라이언트 각각의 CPU의 데이터 처리 속도, 복수의 상기 클라이언트 각각의 RAM 용량 및 복수의 상기 클라이언트 내 스토리지에 저장된 상기 대상 파일의 총 크기 중 하나 이상을 포함할 수 있다.
상기 클라이언트는, 상기 클라이언트 메타 정보를 이용하여 복수의 상기 클라이언트 각각에 대해 정렬 기준값을 계산하고, 상기 정렬 기준값의 크기 순으로 복수의 상기 클라이언트를 정렬할 수 있다.
상기 정렬 기준값은, 상기 응답 메시지를 수신하는 데까지 걸리는 시간이 짧을수록 클 수 있다.
상기 정렬 기준값은, 상기 CPU 점유율이 낮을수록 클 수 있다.
상기 정렬 기준값은, 상기 CPU의 데이터 처리 속도가 빠를수록 클 수 있다.
상기 정렬 기준값은, 상기 RAM 용량이 클수록 클 수 있다.
상기 정렬 기준값은, 상기 스토리지에 저장된 상기 대상 파일의 총 크기가 작을수록 클 수 있다.
상기 대체 서버는, 상기 대체 서버에 저장된 대상 파일을 상기 대체 서버를 제외한 클라이언트 내 스토리지에 저장할 수 있다.
본 발명의 다른 예시적인 실시예에 따르면, 서버에서, 저장하고자 하는 대상 파일을 분할하는 단계; 상기 서버에서, 분할된 상기 대상 파일을 복수의 클라이언트 내 스토리지에 분산 저장하는 단계; 상기 클라이언트에서, 상기 서버의 장애 여부의 판별을 위한 점검 메시지를 설정된 주기마다 상기 서버에 송신하는 단계; 및 상기 클라이언트에서, 설정된 기간 동안 상기 점검 메시지에 대한 응답 메시지를 상기 서버로부터 수신하지 않는 경우 상기 서버에 장애가 발생한 것으로 판단하는 단계를 포함하는, 파일의 분산 저장 방법이 제공된다.
상기 파일의 분산 저장 방법은, 상기 서버에서, 클라이언트 메타 정보를 복수의 상기 클라이언트에 각각 송신하는 단계; 상기 클라이언트에서, 상기 서버에 장애가 발생한 것으로 판단된 경우 상기 클라이언트 메타 정보를 이용하여 복수의 상기 클라이언트를 정렬하는 단계; 및 상기 클라이언트에서, 정렬된 복수의 상기 클라이언트 중 최상단에 위치한 클라이언트를 대체 서버로 선정하는 단계를 더 포함할 수 있다.
상기 클라이언트 메타 정보는, 상기 서버에서 복수의 상기 클라이언트 각각에 호출 메시지를 송신한 경우 복수의 상기 클라이언트 각각으로부터 상기 호출 메시지에 대한 응답 메시지를 수신하는 데까지 걸리는 시간, 복수의 상기 클라이언트 각각의 CPU 점유율, 복수의 상기 클라이언트 각각의 CPU의 데이터 처리 속도, 복수의 상기 클라이언트 각각의 RAM 용량 및 복수의 상기 클라이언트 내 스토리지에 저장된 상기 대상 파일의 총 크기 중 하나 이상을 포함할 수 있다.
복수의 상기 클라이언트를 정렬하는 단계는, 상기 클라이언트 메타 정보를 이용하여 복수의 상기 클라이언트 각각에 대해 정렬 기준값을 계산하는 단계; 및 상기 정렬 기준값의 크기 순으로 복수의 상기 클라이언트를 정렬하는 단계를 포함할 수 있다.
상기 정렬 기준값은, 상기 응답 메시지를 수신하는 데까지 걸리는 시간이 짧을수록 클 수 있다.
상기 정렬 기준값은, 상기 CPU 점유율이 낮을수록 클 수 있다.
상기 정렬 기준값은, 상기 CPU의 데이터 처리 속도가 빠를수록 클 수 있다.
상기 정렬 기준값은, 상기 RAM 용량이 클수록 클 수 있다.
상기 정렬 기준값은, 상기 스토리지에 저장된 상기 대상 파일의 총 크기가 작을수록 클 수 있다.
상기 파일의 분산 저장 방법은, 상기 대체 서버에서, 상기 대체 서버에 저장된 대상 파일을 상기 대체 서버를 제외한 클라이언트 내 스토리지에 저장하는 단계를 더 포함할 수 있다.
본 발명의 실시예들에 따르면, 각 클라이언트 내 스토리지에 대상 파일을 분산 저장하도록 함으로써, 스토리지 자원을 효율적으로 이용하고 파일 저장에 따른 비용을 절감할 수 있다. 또한, 대상 파일을 로컬 영역에 저장하도록 함으로써, 대상 파일의 유출 위험을 방지할 수 있다. 나아가, 서버에 장애가 발생하는 경우 각 클라이언트 중 하나를 대체 서버로 선정하도록 함으로써, 대상 파일을 유연하고 안전하게 저장할 수 있다.
도 1은 본 발명의 일 실시예에 따른 파일의 분산 저장 시스템의 상세 구성을 나타낸 도면
도 2는 서버에 장애가 발생하여 각 클라이언트와 서버와의 접속이 종료되는 과정을 설명하기 위한 도면
도 3은 본 발명의 일 실시예에 따른 파일의 분산 저장 방법을 설명하기 위한 흐름도
도 4는 도 3의 S612 단계를 설명하기 위한 흐름도
이하, 도면을 참조하여 본 발명의 구체적인 실시형태를 설명하기로 한다. 이하의 상세한 설명은 본 명세서에서 기술된 방법, 장치 및/또는 시스템에 대한 포괄적인 이해를 돕기 위해 제공된다. 그러나 이는 예시에 불과하며 본 발명은 이에 제한되지 않는다.
본 발명의 실시예들을 설명함에 있어서, 본 발명과 관련된 공지기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략하기로 한다. 그리고, 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다. 상세한 설명에서 사용되는 용어는 단지 본 발명의 실시예들을 기술하기 위한 것이며, 결코 제한적이어서는 안 된다. 명확하게 달리 사용되지 않는 한, 단수 형태의 표현은 복수 형태의 의미를 포함한다. 본 설명에서, "포함" 또는 "구비"와 같은 표현은 어떤 특성들, 숫자들, 단계들, 동작들, 요소들, 이들의 일부 또는 조합을 가리키기 위한 것이며, 기술된 것 이외에 하나 또는 그 이상의 다른 특성, 숫자, 단계, 동작, 요소, 이들의 일부 또는 조합의 존재 또는 가능성을 배제하도록 해석되어서는 안 된다.
도 1은 본 발명의 일 실시예에 따른 파일의 분산 저장 시스템(100)의 상세 구성을 나타낸 도면이다. 도 1에 도시된 바와 같이, 본 발명의 일 실시예에 따른 파일의 분산 저장 시스템(100)은 서버(102) 및 복수의 클라이언트(104)를 포함한다.
서버(102)는 사용자 또는 서버 관리자가 저장하고자 하는 대상 파일 및 대상 파일이 저장되는 클라이언트(104) 내 스토리지를 관리하기 위한 장치로서, 예를 들어 데스크탑, 노트북, 태블릿 컴퓨터, PDA 등과 같은 전자 기기가 될 수 있다. 대상 파일은 예를 들어, 텍스트 파일, 동영상 파일, 이미지 파일 등이 될 수 있으나 대상 파일의 종류가 특별히 제한되는 것은 아니다.
서버 관리자는 서버(102)의 아이피 주소 및 포트 번호를 입력하여 서버(102)를 실행시킬 수 있으며, 청크 사이즈(chunk size)를 설정할 수 있다. 청크 사이즈는 대상 파일이 분할되었을 때 분할된 대상 파일 각각의 크기를 의미하며, 예를 들어 64MB가 될 수 있다.
서버(102)는 클라이언트(104)로부터 접속 요청 메시지를 수신할 수 있으며, 접속 요청 메시지를 이용하여 클라이언트(104)의 접속을 허용할 수 있다. 접속 요청 메시지는 클라이언트(104)의 아이디, 패스워드, 아이피 주소 및 포트 번호 중 하나 이상을 포함할 수 있다. 서버(102)는 예를 들어, 접속 요청 메시지에 포함된 아이디 및 패스워드를 인증함으로써 클라이언트(104)의 접속을 허용할 수 있다. 또한, 아이디 및 패스워드는 각 클라이언트(104-1 내지 104-n)의 고유 식별 정보로서, 복수의 클라이언트(104-1 내지 104-n) 중 일부가 서버(102)와의 접속이 끊겼다 다시 접속된 경우 해당 클라이언트를 식별하는 데 사용될 수 있다. 만약, 복수의 클라이언트(104-1 내지 104-n) 중 일부와 서버(102)와의 접속이 끊긴 경우, 서버(102)는 접속이 끊긴 클라이언트 내 스토리지에 저장된 대상 파일을 다른 클라이언트 내 스토리지에 저장하기 위해 해당 대상 파일을 어느 곳에 저장을 할 것인지에 대한 연산을 수행하여야 하는 번거로움이 있으나, 접속이 끊긴 클라이언트가 서버(102)에 재접속하는 경우 해당 클라이언트의 아이디 및 패스워드를 통해 해당 클라이언트 내 스토리지에 저장된 대상 파일의 존재를 신속하게 파악할 수 있다. 이 경우, 서버(102)는 파일 메타 정보를 수정할 필요가 없게 된다.
또한, 접속 요청 메시지에는 클라이언트(104) 내 스토리지(미도시)의 가용 크기, 클라이언트(104) 내 스토리지의 위치 등이 더 포함될 수 있다. 스토리지의 가용 크기는 클라이언트(104)가 제공하는 저장 공간의 최대 크기로서, 예를 들어 5GB일 수 있다. 또한, 스토리지의 위치는 대상 파일이 저장되는 위치로서, 예를 들어 D 드라이브가 될 수 있다. 클라이언트(104)는 이와 같은 스토리지의 가용 크기 및 위치를 사용자로부터 입력 받을 수 있으며, 스토리지의 가용 크기 및 위치는 각 클라이언트(104-1 내지 104-n)별로 다를 수 있다. 예를 들어, 제 1 클라이언트(104-1) 내 스토리지의 가용 크기 및 위치는 5GB 및 D 드라이브이고, 제 2 클라이언트(104-2) 내 스토리지의 가용 크기 및 위치는 10GB 및 C 드라이브이며, 제 3 클라이언트(104-3) 내 스토리지의 가용 크기 및 위치는 15GB 및 D 드라이브일 수 있다. 또한, 클라이언트(104)는 서버(102)로부터 청크 사이즈에 대한 정보를 수신할 수 있으며, 사용자가 입력한 스토리지 가용 크기가 청크 사이즈보다 작은 경우 사용자로 하여금 스토리지 가용 크기를 재입력하도록 알림 메시지를 출력할 수 있다.
서버(102)는 설정된 청크 사이즈에 따라 대상 파일을 분할하고, 분할된 대상 파일을 각 클라이언트(104-1 내지 104-n) 내 스토리지의 가용 크기를 초과하지 않는 범위에서 각 클라이언트(104-1 내지 104-n) 내 스토리지에 분산 저장할 수 있다. 예를 들어, 대상 파일의 크기가 10GB이며 청크 사이즈가 64MB인 경우, 서버(102)는 대상 파일을 64MB의 크기를 갖는 160개의 파일로 분할하고, 분할된 대상 파일 160개를 각 클라이언트(104-1 내지 104-n) 내 스토리지의 가용 크기를 초과하지 않는 범위에서 각 클라이언트(104-1 내지 104-n) 내 스토리지에 분산 저장할 수 있다.
이때, 서버(102)는 클라이언트(104) 내 스토리지의 가용 크기 중 클라이언트(104) 내 스토리지에 저장된 대상 파일의 크기를 제외한 나머지 크기에 해당하는 더미 파일(dummy file)을 생성하여 클라이언트(104) 내 스토리지에 저장할 수 있다. 예를 들어, 제 1 클라이언트(104-1) 내 스토리지의 가용 크기가 5GB이며 제 1 클라이언트(104-1) 내 스토리지에 저장된 대상 파일의 크기가 3GB인 경우, 서버(102)는 2GB의 더미 파일을 생성하여 제 1 클라이언트(104-1) 내 스토리지에 저장할 수 있다. 이에 따라, 스토리지의 가용 크기(5GB)에 해당하는 저장 공간을 대상 파일의 저장에만 사용할 수 있으며, 사용자로 인해 스토리지의 가용 크기(5GB)에 해당하는 저장 공간이 침해되는 것을 방지할 수 있다.
또한, 서버(102)는 분할된 대상 파일을 복제(예를 들어, 3번)하여 복수의 클라이언트(예를 들어, 104-1, 104-11, 104-21)에 중복 저장할 수 있다. 이때, 복제된 대상 파일이 저장되는 클라이언트(예를 들어, 104-1, 104-11, 104-21) 각각은 서로 다른 지역(예를 들어, 학교 내 제 1 전산실, 제 2 전산실, 제 3 전산실) 내에 위치할 수 있다. 이에 따라, 분할된 대상 파일이 저장된 클라이언트(예를 들어, 104-1)가 동작하지 않거나 해당 클라이언트(104-1)에 저장된 대상 파일이 손상 또는 유실되는 경우 동일한 대상 파일을 저장하고 있는 다른 클라이언트(예를 들어, 104-11, 104-21)로부터 대상 파일을 호출할 수 있으며, 대상 파일의 유실을 방지할 수 있다.
또한, 서버(102)는 파일 메타 정보를 각 클라이언트(104-1 내지 104-n)에 송신할 수 있다. 표 1은 본 발명의 일 실시예에 따른 파일 메타 정보의 예시를 나타낸 도면이다. 표 1에 도시된 바와 같이, 본 발명의 일 실시예에 따른 파일 메타 정보는 분산 저장된 대상 파일의 이름(name), 크기(size), 소유자(owner), 유형 또는 종류(type), 저장 위치(location) 및 저장 일자(date) 중 하나 이상을 포함할 수 있다. 상기 저장 위치(location)는 분할된 대상 파일 별 인덱스(index), 분할된 대상 파일이 저장된 위치(pil), 분할된 대상 파일 별 고유 이름(sfn) 등을 포함할 수 있다. 또한, 상기 분할된 대상 파일이 저장된 위치(pil)는 분할된 대상 파일의 중복 저장 위치(rdl) 및 분할된 대상 파일의 중복 저장 횟수(count) 등을 포함할 수 있다.
속성 내용
name 대상 파일의 이름
size 대상 파일의 크기
owner 대상 파일의 소유자
type 대상 파일의 유형 또는 종류(예를 들어, 대상 파일의 확장자)
location 대상 파일이 저장된 위치
date 대상 파일의 저장 일자(또는 시간)
index Location의 서브 메타 정보로서, 분할된 대상 파일의 인덱스
pil
(path information list)		 Location의 서브 메타 정보로서, 분할된 대상 파일이 저장된 위치
sfn
(split file name)		 Location의 서브 메타 정보로서, 분할된 대상 파일의 고유 이름
rdl
(redundant data location)		 Pil의 서브 메타 정보로서, 분할된 대상 파일의 중복 저장 위치
count Pil의 서브 메타 정보로서, 분할된 대상 파일의 중복 저장 횟수
서버(102)는 파일 메타 정보를 관리하며, 파일 메타 정보에 변경이 발생할 경우(예를 들어, 대상 파일의 저장 위치가 변경되거나 대상 파일이 추가된 경우 등) 이를 업데이트할 수 있다. 서버(102)는 파일 메타 정보를 업데이트할 때마다 각 클라이언트(104-1 내지 104-n)에 업데이트된 파일 메타 정보를 송신할 수 있다. 또한, 서버(102)는 설정된 주기마다(예를 들어, 하루에 한 번) 파일 메타 정보를 각 클라이언트(104-1 내지 104-n)에 송신할 수도 있다.
또한, 서버(102)는 클라이언트 메타 정보를 각 클라이언트(104-1 내지 104-n)에 송신할 수 있다. 클라이언트 메타 정보는 예를 들어, 서버(102)에서 복수의 클라이언트 각각(104-1 내지 104-n)에 호출 메시지를 송신한 경우 복수의 클라이언트 각각(104-1 내지 104-n)으로부터 호출 메시지에 대한 응답 메시지를 수신하는 데까지 걸리는 시간, 복수의 클라이언트 각각(104-1 내지 104-n)의 CPU 점유율, 복수의 클라이언트 각각(104-1 내지 104-n)의 CPU의 데이터 처리 속도, 복수의 클라이언트 각각(104-1 내지 104-n)의 RAM 용량 및 복수의 클라이언트(104-1 내지 104-n) 내 스토리지에 저장된 대상 파일의 총 크기 중 하나 이상일 수 있다. 또한, 클라이언트 메타 정보는 클라이언트 각각 클라이언트(104-1 내지 104-n)의 아이피 주소 및 포트 번호를 더 포함할 수 있다. 여기서, 호출 메시지는 서버(102)에 대한 클라이언트 각각(104-1 내지 104-n)의 응답 시간을 측정하기 위한 메시지로서, 서버(102)는 클라이언트 각각(104-1 내지 104-n)에 호출 메시지를 송신하고, 호출 메시지에 대한 응답 메시지를 클라이언트 각각(104-1 내지 104-n)으로부터 수신한 후 응답 메시지의 수신 시간을 측정할 수 있다. 또한, CPU 점유율은 클라이언트(104) 내 CPU의 현재 사용률을 의미하며, 예를 들어 70%가 될 수 있다. 또한, CPU의 데이터 처리 속도는 클라이언트(104) 내 CPU의 동작 속도(초당 처리 속도)를 의미하며 예를 들어, 4GHz가 될 수 있다. 또한, 클라이언트(104)의 RAM 용량은 예를 들어, 4GB일 수 있으며, 클라이언트(104) 내 스토리지에 저장된 대상 파일의 총 크기는 예를 들어, 1GB일 수 있다.
서버(102)는 클라이언트(104)가 서버(102)에 접속할 때마다 클라이언트 메타 정보를 업데이트할 수 있다. 서버(102)는 클라이언트 메타 정보를 업데이트하고, 각 클라이언트(104-1 내지 104-n)에 업데이트된 클라이언트 메타 정보를 송신할 수 있다. 또한, 서버(102)는 설정된 주기마다(예를 들어, 하루에 한 번) 클라이언트 메타 정보를 각 클라이언트(104-1 내지 104-n)에 송신할 수도 있다.
서버(102)는 각 클라이언트(104-1 내지 104-n)로부터 점검 메시지를 수신할 수 있으며, 각 클라이언트(104-1 내지 104-n)는 점검 메시지를 이용하여 서버(102)의 장애 여부를 판단할 수 있다. 만약, 서버(102)에 장애가 발생한 것으로 판단되는 경우, 각 클라이언트(104-1 내지 104-n)는 서버(102)로부터 수신한 클라이언트 메타 정보를 이용하여 복수의 클라이언트(104-1 내지 104-n) 중 하나를 대체 서버로 선정할 수 있다. 각 클라이언트(104-1 내지 104-n)가 클라이언트 메타 정보를 이용하여 대체 서버를 선정하는 방법에 대해서는 아래에서 구체적으로 설명하기로 한다.
클라이언트(104)는 대상 파일의 저장 공간을 제공하는 장치로서, 예를 들어 학교, 연구소, 기업 등에서 사용되는 데스크탑, 노트북, 태블릿 컴퓨터, PDA 등과 같은 전자 기기가 될 수 있다. 일반적으로, 학교, 연구소, 기업 등에서 사용되는 데스크탑은 항상 부팅되어 있는 반면에 내부의 스토리지의 이용율이 매주 낮거나 저조하다. 이에 따라, 본 발명의 실시예들에서는 클라우드 서버 내 스토리지가 아닌 클라이언트(104) 내 스토리지에 대상 파일을 저장할 수 있도록 하였다. 클라이언트(104)는 일상적인 데스크탑 용도로 활용됨과 동시에, 스토리지 자원의 일부로서 사용될 수 있다.
클라이언트(104)는 사용자로부터 스토리지의 가용 크기 및 위치를 입력받아 접속 요청 메시지를 생성할 수 있다. 상술한 바와 같이, 접속 요청 메시지는 클라이언트(104) 내 스토리지의 가용 크기, 클라이언트(104) 내 스토리지의 위치, 클라이언트(104)의 아이디, 패스워드, 아이피 주소 및 포트 번호 중 하나 이상을 포함할 수 있다. 서버(102)는 클라이언트(104)로부터 수신한 접속 요청 메시지에 따라 클라이언트(104)의 접속을 허용할 수 있으며, 대상 파일을 각 클라이언트(104-1 내지 104-n) 내 스토리지에 분산 저장할 수 있다. 이때, 클라이언트(104) 내 스토리지에 분산 저장된 대상 파일의 크기는 사용자가 설정한 해당 클라이언트(104) 내 스토리지의 가용 크기를 초과하지 않는다. 또한, 서버(102)는 클라이언트(104) 내 스토리지의 가용 크기 중 클라이언트(104) 내 스토리지에 저장된 대상 파일의 크기를 제외한 나머지 크기에 해당하는 더미 파일을 생성하여 해당 클라이언트(104) 내 스토리지에 저장할 수 있으며, 이에 따라 사용자로 인해 스토리지의 가용 크기에 해당하는 저장 공간이 침해되는 것을 방지할 수 있다.
또한, 클라이언트(104)는 서버(102)로부터 파일 메타 정보를 수신할 수 있으며, 이에 따라 클라이언트(104)는 분할된 대상 파일 각각의 저장 위치, 저장 일자 등을 알 수 있다.
또한, 클라이언트(104)는 서버(102)로부터 각 클라이언트(104-1 내지 104-n)의 메타 정보를 수신할 수 있으며, 이에 따라 서버(102)에 장애가 발생하는 경우 상기 클라이언트 메타 정보를 이용하여 복수의 클라이언트(104-1 내지 104-n) 중 하나를 대체 서버로 선정할 수 있다.
이를 위해, 클라이언트(104)는 먼저 서버(102)의 장애 여부 판별을 위한 점검 메시지를 설정된 주기마다(예를 들어, 20초에 한 번씩) 서버(102)에 송신할 수 있다. 클라이언트(104)는 설정된 기간(예를 들어, 10초) 동안 점검 메시지에 대한 응답 메시지를 서버(102)로부터 수신하지 않는 경우 서버(102)에 장애가 발생한 것으로 판단할 수 있다.
도 2를 참조하면, 각 클라이언트(104-1, 104-2, 104-3, 104-4)는 점검 메시지를 설정된 주기마다 서버(102)에 송신함으로써 서버(102)의 장애 여부를 판단할 수 있다. 도 2에서는 설명의 편의상 4개의 클라이언트(104-1, 104-2, 104-3, 104-4)가 서버(102)와 접속되어 있는 것으로 가정하여 설명하기로 한다. 먼저, 각 클라이언트(104-1, 104-2, 104-3, 104-4)는 서버(102)의 장애 여부 판별을 위한 점검 메시지를 설정된 주기마다 서버(102)에 송신할 수 있다. 다음으로, 각 클라이언트(104-1, 104-2, 104-3, 104-4)는 설정된 기간 동안 점검 메시지에 대한 응답 메시지를 서버(102)로부터 수신하지 않는 경우 서버(102)에 장애가 발생한 것으로 판단할 수 있다. 만약, 서버에 장애가 발생한 것으로 판단되는 경우 각 클라이언트(104-1, 104-2, 104-3, 104-4)는 서버(102)와의 접속을 종료할 수 있다.
또한, 서버(102)에 장애가 발생한 것으로 판단되는 경우, 각 클라이언트(104-1 내지 104-4)는 클라이언트 메타 정보를 이용하여 클라이언트 각각(104-1 내지 104-4)에 대한 정렬 기준값을 계산하고, 정렬 기준값의 크기 순으로 클라이언트 각각(104-1 내지 104-4)을 정렬함으로써 대체 서버를 선정할 수 있다. 정렬 기준값은 복수의 클라이언트(104-1, 104-2, 104-3, 104-4) 중 하나를 대체 서버로 선정하기 위한 참조값으로서, 클라이언트 메타 정보에 포함된 인자값에 따라 달라질 수 있다. 상술한 바와 같이, 클라이언트 메타 정보는 서버(102)에서 복수의 클라이언트 각각에 호출 메시지를 송신한 경우 복수의 클라이언트 각각으로부터 호출메시지에 대한 응답 메시지를 수신하는 데까지 걸리는 시간, 클라이언트(104-1 내지 104-4) 각각의 CPU 점유율, 클라이언트(104-1 내지 104-4) 각각의 CPU의 데이터 처리 속도, 클라이언트(104-1 내지 104-4) 각각의 RAM 크기 및 클라이언트(104-1 내지 104-4) 각각의 스토리지에 저장된 대상 파일의 총 크기 중 하나 이상을 포함할 수 있다. 각 클라이언트(104-1 내지 104-4)는 예를 들어, 정렬 기준값이 가장 큰 클라이언트(104-2)를 대체 서버로 선정할 수 있다.
구체적으로, 클라이언트(104-1 내지 104-4)는 클라이언트 메타 정보에 포함된 상기 응답 메시지를 수신하는 데까지 걸리는 시간, 상기 CPU 점유율, 상기 CPU의 데이터 처리 속도, 상기 RAM 크기 및 상기 토리지에 저장된 대상 파일의 총 크기 중 하나 이상을 이용하여 정렬 기준값을 계산할 수 있다.
일 예시로서, 서버(102)가 클라이언트(104-1 내지 104-4) 각각에 대해 응답 메시지를 수신하는 데까지 걸리는 시간이 각각 0.1초, 0.3초, 0.2초, 0.4초인 경우 클라이언트(104-1 내지 104-4) 각각에 대한 정렬 기준값은 10, 8, 9, 7 일 수 있다. 즉, 정렬 기준값은 상기 응답 메시지를 수신하는 데까지 걸리는 시간이 짧을수록 클 수 있다.
다른 예시로서, 클라이언트(104-1 내지 104-4) 각각의 CPU 점유율이 각각 80%, 70%, 90%, 85%인 경우 클라이언트(104-1 내지 104-4) 각각에 대한 정렬 기준값은 20, 30, 10, 15 일 수 있다. 즉, 정렬 기준값은 상기 CPU 점유율이 낮을수록 클 수 있다.
다른 예시로서, 클라이언트(104-1 내지 104-4) 각각의 CPU의 데이터 처리 속도가 각각 4GHz, 2GHz, 5GHz, 3GHz 인 경우 클라이언트(104-1 내지 104-4) 각각에 대한 정렬 기준값은 4, 2, 5, 3 일 수 있다. 즉, 정렬 기준값은 상기 CPU의 데이터 처리 속도가 빠를수록 클 수 있다.
다른 예시로서, 클라이언트(104-1 내지 104-4) 각각의 RAM 크기가 4GB, 5GB, 3GB, 6GB인 경우 클라이언트(104-1 내지 104-4) 각각에 대한 정렬 기준값은 4, 5, 3, 6 일 수 있다. 즉, 정렬 기준값은 상기 RAM 용량이 클수록 클 수 있다.
또 다른 예시로서, 클라이언트(104-1 내지 104-4) 각각의 스토리지에 저장된 대상 파일의 총 크기가 각각 1GB, 2GB, 5GB, 4GB 인 경우 클라이언트(104-1 내지 104-4) 각각에 대한 정렬 기준값은 9, 8, 5, 6 일 수 있다. 즉, 정렬 기준값은 기 스토리지에 저장된 상기 대상 파일의 총 크기가 작을수록 클 수 있다.
클라이언트(104-1 내지 104-4)는 위와 같은 과정을 통해 정렬 기준값을 계산할 수 있다. 다만, 상술한 정렬 기준값의 계산 방법은 실시예들에 불과하며 정렬 기준값의 계산 방법이 이에 한정되는 것은 아니다. 예를 들어, 클라이언트(104-1 내지 104-4) 각각의 RAM 크기가 4GB, 5GB, 3GB, 6GB인 경우 클라이언트(104-1 내지 104-4) 각각에 대한 정렬 기준값은 40, 50, 30, 60 일 수도 있다. 또한, 클라이언트(104-1 내지 104-4)는 클라이언크 메타 정보에 포함된 인자값(즉, 상기 응답 메시지를 수신하는 데까지 걸리는 시간, 상기 CPU 점유율, 상기 CPU의 데이터 처리 속도, 상기 RAM 크기 및 상기 토리지에 저장된 대상 파일의 총 크기) 각각에 대해 정렬 기준값을 계산하고, 각 인자값에 대한 정렬 기준값을 조합하여 최종 정렬 기준값을 계산할 수도 있다. 예를 들어, 클라이언트(104-1 내지 104-4)는 각 인자값에 대한 정렬 기준값을 더하여 최종 정렬 기준값을 계산할 수 있다. 이때, 클라이언트(104-1 내지 104-4)는 각 인자값에 대한 정렬 기준값 각각에 가중치를 부여할 수 있다. 상기 가중치는 각 인자값에 대한 중요도를 나타낸 수치로서, 서버 관리자에 의해 설정될 수 있다.
예를 들어, 상기 응답 메시지를 수신하는 데까지 걸리는 시간, 상기 CPU 점유율, 상기 CPU의 데이터 처리 속도, 상기 RAM 크기 및 상기 토리지에 저장된 대상 파일의 총 크기에 대한 가중치가 각각 0.4, 0.2, 0.1, 0.2, 0.1 이라 가정하는 경우, 제 1 클라이언트(104-1)에 대한 정렬 기준값은 10*0.4 + 20*0.2 + 4*0.1 + 4*0.2 + 9*0.1 = 10.1 일 수 있다. 각 클라이언트(104-1 내지 104-4)는 나머지 클라이언트(104-2 내지 104-4)에 대해서도 정렬 기준값을 계산할 수 있다.
클라이언트(104-1 내지 104-4)는 상술한 과정을 통해 정렬 기준값을 계산하고, 상기 정렬 기준값의 크기 순으로 복수의 클라이언트(104-1 내지 104-4)를 정렬할 수 있다. 예를 들어, 클라이언트(104-1 내지 104-4)는 정렬값이 큰 순으로 복수의 클라이언트(104-1 내지 104-4)를 정렬할 수 있으며, 정렬 기준값이 가장 큰 클라이언트(104-2)를 대체 서버로 선정할 수 있다. 예를 들어, 제 2 클라이언트(104-2)의 정렬 기준값이 가장 큰 경우, 클라이언트(104-1 내지 104-4)는 제 2 클라이언트(104-2)를 대체 서버로 선정할 수 있다. 다만, 여기서는 설명의 편의상 정렬 기준값이 가장 큰 클라이언트를 대체 서버로 선정하는 것으로 설명하였으나, 이는 하나의 실시예에 불과하며 정렬 기준값이 가장 작은 클라이언트를 대체 서버로 선정할 수도 있다.
나아가, 서버(102)에 장애가 발생한 것으로 판단되는 경우, 각 클라이언트(104-1, 104-2, 104-3, 104-4)는 각 클라이언트(104-1, 104-2, 104-3, 104-4)의 아이피 주소를 이용하여 대체 서버를 선정할 수도 있다. 상술한 바와 같이, 클라이언트 메타 정보는 각 클라이언트(104-1, 104-2, 104-3, 104-4)의 아이피 주소를 더 포함할 수 있다. 각 클라이언트(104-1, 104-2, 104-3, 104-4)는 각 클라이언트(104-1, 104-2, 104-3, 104-4)의 아이피 주소를 크기 순으로 정렬하고, 정렬된 각 클라이언트(104-1, 104-2, 104-3, 104-4)의 아이피 주소(210.94.185.158/210.94.185.157/210.94.185.159/210.94.185.160) 중 최상단(또는 최하단)에 위치한 아이피 주소(210.94.185.157)에 대응되는 제 2 클라이언트(104-2)를 대체 서버로 선정할 수도 있다.
이와 같이, 서버(102)에 장애가 발생한 것으로 판단되는 경우, 각 클라이언트(104-1, 104-2, 104-3, 104-4)는 클라이언트 메타 정보에 포함된 다양한 인자값을 활용하여 대체 서버를 선정할 수 있다.
이후, 선정된 대체 서버(104-2)는 서버(102)와 동일한 기능을 수행할 수 있다. 즉, 대체 서버(104-2)는 파일 메타 정보를 업데이트하고, 업데이트된 파일 메타 정보를 대체 서버(104-2)를 제외한 제 1 클라이언트(104-1), 제 3 클라이언트(104-3) 및 제 4 클라이언트(104-4)에 송신할 수 있다. 또한, 대체 서버(104-2)는 클라이언트 메타 정보를 업데이트하고, 업데이트된 클라이언트 메타 정보를 대체 서버(104-2)를 제외한 클라이언트에 송신할 수 있다. 나아가, 제 1 클라이언트(104-1), 제 3 클라이언트(104-3) 및 제 4 클라이언트(104-4)는 설정된 주기마다 대체 서버(104-2)로 점검 메시지를 송신할 수 있으며, 설정된 기간 동안 점검 메시지에 대한 응답 메시지를 대체 서버(104-2)로부터 수신하지 않는 경우 대체 서버(104-1)에 장애가 발생한 것으로 판단할 수 있다.
본 발명의 실시예들에 따르면, 각 클라이언트(104-1 내지 104-4) 내 스토리지에 대상 파일을 분산 저장하도록 함으로써, 스토리지 자원을 효율적으로 이용하고 파일 저장에 따른 비용을 절감할 수 있다. 또한, 대상 파일을 로컬 영역에 저장하도록 함으로써, 대상 파일의 유출 위험을 방지할 수 있다. 나아가, 서버(102)에 장애가 발생하는 경우 각 클라이언트(104-1 내지 104-4) 중 하나를 대체 서버로 선정하도록 함으로써, 대상 파일을 유연하고 안전하게 저장할 수 있다.
도 3은 본 발명의 일 실시예에 따른 파일의 분산 저장 방법을 설명하기 위한 흐름도이다.
먼저, 클라이언트(104)는 사용자로부터 스토리지의 가용 크기를 입력받아 접속 요청 메시지를 생성한다(S602). 상술한 바와 같이, 접속 요청 메시지는 클라이언트(104) 내 스토리지의 가용 크기, 클라이언트(104)의 아이디, 패스워드, 아이피 주소 및 포트 번호 중 하나 이상을 포함할 수 있다.
다음으로, 서버(102)는 클라이언트(104)로부터 수신한 접속 요청 메시지에 따라 클라이언트(104)의 접속을 허용한다(S604). 서버(102)는 예를 들어, 접속 요청 메시지에 포함된 아이디 및 패스워드를 인증함으로써 클라이언트(104)의 접속을 허용할 수 있다.
다음으로, 서버(102)는 대상 파일을 분할한다(S606). 서버(102)는 서버 관리자로부터 청크 사이즈(chunk size)를 입력받고, 대상 파일을 청크 사이즈에 따라 분할할 수 있다. 청크 사이즈는 예를 들어, 예를 들어 64MB가 될 수 있다.
다음으로, 서버(102)는 분할된 대상 파일을 스토리지의 가용 크기를 초과하지 않는 범위에서 각 클라이언트(104-1 내지 104-n) 내 스토리지에 분산 저장한다(S608). 이때, 서버(102)는 클라이언트(104) 내 스토리지의 가용 크기 중 클라이언트(104) 내 스토리지에 저장된 대상 파일의 크기를 제외한 나머지 크기에 해당하는 더미 파일(dummy file)을 생성하여 클라이언트(104) 내 스토리지에 저장할 수 있다. 예를 들어, 클라이언트(104) 내 스토리지의 가용 크기가 5GB이며 클라이언트(104) 내 스토리지에 저장된 대상 파일의 크기가 3GB인 경우, 서버(102)는 2GB의 더미 파일을 생성하여 클라이언트(104) 내 스토리지에 저장할 수 있다.
다음으로, 서버(102)는 파일 메타 정보 및 클라이언트 메타 정보를 각 클라이언트(104-1 내지 104-n)에 송신한다(S610). 파일 메타 정보는 예를 들어, 분산 저장된 대상 파일의 이름, 크기, 소유자, 유형, 저장 위치 및 저장 일자 중 하나 이상을 포함할 수 있으며, 클라이언트 메타 정보는 각 클라이언트(104-1 내지 104-n)의 아이피 주소, 포트 번호 등을 포함할 수 있다.
마지막으로, 각 클라이언트(104-1 내지 104-n)는 점검 메시지를 이용하여 서버(102)의 장애 여부를 판별하고, 대체 서버(104-1)를 선정한다(S612). 이에 대해서는 도 4를 참조하여 구체적으로 설명하기로 한다.
도 4는 도 3의 S612단계를 설명하기 위한 흐름도이다.
먼저, 각 클라이언트(104-1 내지 104-n)는 서버(102)의 장애 여부의 판별을 위한 점검 메시지를 서버(102)에 송신한다(S702).
각 클라이언트(104-1 내지 104-n)는 설정된 기간 동안 점검 메시지에 대한 응답 메시지를 서버(102)로부터 수신하지 않는 경우 서버(102)에 장애가 발생한 것으로 판단한다(S704, S708). 또한, 각 클라이언트(104-1 내지 104-n)는 설정된 기간 동안 점검 메시지에 대한 응답 메시지를 서버(102)로부터 수신하는 경우 서버(102)가 정상 동작하고 있는 것으로 판단한다(S704, S706).
만약, 서버(102)에 장애가 발생한 것으로 판단되는 경우, 각 클라이언트(104-1 내지 104-n)는 클라이언트 메타 정보를 이용하여 각 클라이언트(104-1 내지 104-n)에 대한 정렬 기준값을 계산하고, 정렬 기준값의 크기 순으로 각 클라이언트(104-1 내지 104-n)를 정렬한다(S710). 상술한 바와 같이, 클라이언트(104-1 내지 104-4)는 클라이언트 메타 정보에 포함된 응답 메시지를 수신하는 데까지 걸리는 시간, CPU 점유율, CPU의 데이터 처리 속도, RAM 크기 및 스토리지에 저장된 대상 파일의 총 크기 중 하나 이상을 이용하여 정렬 기준값을 계산할 수 있다. 각 클라이언트(104-1 내지 104-4)는 예를 들어, 정렬값이 큰 순으로 복수의 클라이언트(104-1 내지 104-4)를 정렬할 수 있다.
마지막으로, 각 클라이언트(104-1 내지 104-n)는 정렬 기준값이 가장 큰 클라이언트(104-2)를 대체 서버로 선정할 수 있다(S712). 예를 들어, 제 2 클라이언트(104-2)의 정렬 기준값이 가장 큰 경우, 클라이언트(104-1 내지 104-4)는 제 2 클라이언트(104-2)를 대체 서버로 선정할 수 있다.
이후, 대체 서버(104-2)는 대체 서버(104-2)에 저장된 대상 파일을 대체 서버(104-2)를 제외한 클라이언트(104-1, 104-3 내지 104-n) 내 스토리지에 저장하며, 파일 메타 정보를 업데이트할 수 있다. 대체 서버(104-2)는 서버(102)와 동일한 기능을 수행하도록 동작할 수 있으며, 각 클라이언트(104-1, 104-3 내지 104-n)는 앞선 S702 단계 내지 S714 단계를 반복할 수 있다.
이상에서 대표적인 실시예를 통하여 본 발명에 대하여 상세하게 설명하였으나, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 전술한 실시예에 대하여 본 발명의 범주에서 벗어나지 않는 한도 내에서 다양한 변형이 가능함을 이해할 것이다. 그러므로 본 발명의 권리범위는 설명된 실시예에 국한되어 정해져서는 안 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 것들에 의해 정해져야 한다.
100 : 파일의 분산 저장 시스템
102 : 서버
104 : 클라이언트

Claims (20)

  1. 스토리지를 구비하는 복수의 클라이언트; 및
    저장하고자 하는 대상 파일을 분할하고, 분할된 상기 대상 파일을 복수의 상기 클라이언트 내 스토리지 내에 분산 저장하는 서버를 포함하며,
    상기 클라이언트는, 상기 서버의 장애 여부의 판별을 위한 점검 메시지를 설정된 주기마다 상기 서버에 송신하며, 설정된 기간 동안 상기 점검 메시지에 대한 응답 메시지를 상기 서버로부터 수신하지 않는 경우 상기 서버에 장애가 발생한 것으로 판단하며,
    상기 서버는, 클라이언트 메타 정보를 복수의 상기 클라이언트에 각각 송신하며,
    상기 클라이언트는, 상기 서버에 장애가 발생한 것으로 판단된 경우 상기 클라이언트 메타 정보를 이용하여 복수의 상기 클라이언트를 정렬하고, 정렬된 복수의 상기 클라이언트 중 최상단에 위치한 클라이언트를 대체 서버로 선정하는, 파일의 분산 저장 시스템.
  2. 삭제
  3. 청구항 1에 있어서,
    상기 클라이언트 메타 정보는, 상기 서버에서 복수의 상기 클라이언트 각각에 호출 메시지를 송신한 경우 복수의 상기 클라이언트 각각으로부터 상기 호출 메시지에 대한 응답 메시지를 수신하는 데까지 걸리는 시간, 복수의 상기 클라이언트 각각의 CPU 점유율, 복수의 상기 클라이언트 각각의 CPU의 데이터 처리 속도, 복수의 상기 클라이언트 각각의 RAM 용량 및 복수의 상기 클라이언트 내 스토리지에 저장된 상기 대상 파일의 총 크기 중 하나 이상을 포함하는, 파일의 분산 저장 시스템.
  4. 청구항 3에 있어서,
    상기 클라이언트는, 상기 클라이언트 메타 정보를 이용하여 복수의 상기 클라이언트 각각에 대해 정렬 기준값을 계산하고, 상기 정렬 기준값의 크기 순으로 복수의 상기 클라이언트를 정렬하는, 파일의 분산 저장 시스템.
  5. 청구항 4에 있어서,
    상기 정렬 기준값은, 상기 응답 메시지를 수신하는 데까지 걸리는 시간이 짧을수록 큰, 파일의 분산 저장 시스템.
  6. 청구항 4에 있어서,
    상기 정렬 기준값은, 상기 CPU 점유율이 낮을수록 큰, 파일의 분산 저장 시스템.
  7. 청구항 4에 있어서,
    상기 정렬 기준값은, 상기 CPU의 데이터 처리 속도가 빠를수록 큰, 파일의 분산 저장 시스템.
  8. 청구항 4에 있어서,
    상기 정렬 기준값은, 상기 RAM 용량이 클수록 큰, 파일의 분산 저장 시스템.
  9. 청구항 4에 있어서,
    상기 정렬 기준값은, 상기 스토리지에 저장된 상기 대상 파일의 총 크기가 작을수록 큰, 파일의 분산 저장 시스템.
  10. 청구항 1에 있어서,
    상기 대체 서버는, 상기 대체 서버에 저장된 대상 파일을 상기 대체 서버를 제외한 클라이언트 내 스토리지에 저장하는, 파일의 분산 저장 시스템.
  11. 서버에서, 저장하고자 하는 대상 파일을 분할하는 단계;
    상기 서버에서, 분할된 상기 대상 파일을 복수의 클라이언트 내 스토리지에 분산 저장하는 단계;
    상기 클라이언트에서, 상기 서버의 장애 여부의 판별을 위한 점검 메시지를 설정된 주기마다 상기 서버에 송신하는 단계;
    상기 클라이언트에서, 설정된 기간 동안 상기 점검 메시지에 대한 응답 메시지를 상기 서버로부터 수신하지 않는 경우 상기 서버에 장애가 발생한 것으로 판단하는 단계;
    상기 서버에서, 클라이언트 메타 정보를 복수의 상기 클라이언트에 각각 송신하는 단계;
    상기 클라이언트에서, 상기 서버에 장애가 발생한 것으로 판단된 경우 상기 클라이언트 메타 정보를 이용하여 복수의 상기 클라이언트를 정렬하는 단계; 및
    상기 클라이언트에서, 정렬된 복수의 상기 클라이언트 중 최상단에 위치한 클라이언트를 대체 서버로 선정하는 단계를 포함하는, 파일의 분산 저장 방법.
  12. 삭제
  13. 청구항 11에 있어서,
    상기 클라이언트 메타 정보는, 상기 서버에서 복수의 상기 클라이언트 각각에 호출 메시지를 송신한 경우 복수의 상기 클라이언트 각각으로부터 상기 호출 메시지에 대한 응답 메시지를 수신하는 데까지 걸리는 시간, 복수의 상기 클라이언트 각각의 CPU 점유율, 복수의 상기 클라이언트 각각의 CPU의 데이터 처리 속도, 복수의 상기 클라이언트 각각의 RAM 용량 및 복수의 상기 클라이언트 내 스토리지에 저장된 상기 대상 파일의 총 크기 중 하나 이상을 포함하는, 파일의 분산 저장 방법.
  14. 청구항 13에 있어서,
    복수의 상기 클라이언트를 정렬하는 단계는,
    상기 클라이언트 메타 정보를 이용하여 복수의 상기 클라이언트 각각에 대해 정렬 기준값을 계산하는 단계; 및
    상기 정렬 기준값의 크기 순으로 복수의 상기 클라이언트를 정렬하는 단계를 포함하는, 파일 분산 저장 파일의 분산 저장 방법.
  15. 청구항 14에 있어서,
    상기 정렬 기준값은, 상기 응답 메시지를 수신하는 데까지 걸리는 시간이 짧을수록 큰, 파일의 분산 저장 방법.
  16. 청구항 14에 있어서,
    상기 정렬 기준값은, 상기 CPU 점유율이 낮을수록 큰, 파일의 분산 저장 방법.
  17. 청구항 14에 있어서,
    상기 정렬 기준값은, 상기 CPU의 데이터 처리 속도가 빠를수록 큰, 파일의 분산 저장 방법.
  18. 청구항 14에 있어서,
    상기 정렬 기준값은, 상기 RAM 용량이 클수록 큰, 파일의 분산 저장 방법.
  19. 청구항 14에 있어서,
    상기 정렬 기준값은, 상기 스토리지에 저장된 상기 대상 파일의 총 크기가 작을수록 큰, 파일의 분산 저장 방법.
  20. 청구항 11에 있어서,
    상기 대체 서버에서, 상기 대체 서버에 저장된 대상 파일을 상기 대체 서버를 제외한 클라이언트 내 스토리지에 저장하는 단계를 더 포함하는, 파일의 분산 저장 방법.
KR1020150067800A 2015-05-15 2015-05-15 대용량 데이터 처리를 위한 레거시 데스크탑 기반 파일의 분산 저장 시스템 및 방법 KR101679512B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020150067800A KR101679512B1 (ko) 2015-05-15 2015-05-15 대용량 데이터 처리를 위한 레거시 데스크탑 기반 파일의 분산 저장 시스템 및 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020150067800A KR101679512B1 (ko) 2015-05-15 2015-05-15 대용량 데이터 처리를 위한 레거시 데스크탑 기반 파일의 분산 저장 시스템 및 방법

Publications (2)

Publication Number Publication Date
KR20160134173A KR20160134173A (ko) 2016-11-23
KR101679512B1 true KR101679512B1 (ko) 2016-11-24

Family

ID=57541850

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150067800A KR101679512B1 (ko) 2015-05-15 2015-05-15 대용량 데이터 처리를 위한 레거시 데스크탑 기반 파일의 분산 저장 시스템 및 방법

Country Status (1)

Country Link
KR (1) KR101679512B1 (ko)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106855930B (zh) * 2017-01-04 2019-12-31 成都四方伟业软件股份有限公司 一种安全可靠的大数据存储系统及方法
KR102418251B1 (ko) * 2020-11-24 2022-07-07 주식회사 이노그리드 장애 대비를 위한 멀티클라우드 서비스 시스템 및 방법

Also Published As

Publication number Publication date
KR20160134173A (ko) 2016-11-23

Similar Documents

Publication Publication Date Title
US10776396B2 (en) Computer implemented method for dynamic sharding
US9542404B2 (en) Subpartitioning of a namespace region
US9483482B2 (en) Partitioning file system namespace
US9378067B1 (en) Automated load balancing across the distributed system of hybrid storage and compute nodes
AU2014212780B2 (en) Data stream splitting for low-latency data access
US9507676B2 (en) Cluster creation and management for workload recovery
US10915409B2 (en) Caching of backup chunks
US12058210B2 (en) Multichannel virtual internet protocol address affinity
CN1602480A (zh) 管理附装在数据网络上的存储器资源
US20120078946A1 (en) Systems and methods for monitoring files in cloud-based networks
KR101704928B1 (ko) Gpu를 이용한 파일의 분산 저장 시스템 및 방법
KR101718397B1 (ko) 파일의 분산 저장 시스템 및 방법
KR101679512B1 (ko) 대용량 데이터 처리를 위한 레거시 데스크탑 기반 파일의 분산 저장 시스템 및 방법
US8903871B2 (en) Dynamic management of log persistence
US20190303021A1 (en) Rebalancing of user accounts among partitions of a storage service
JP6059558B2 (ja) 負荷分散判定システム
US9495257B2 (en) Networking support for zone clusters based on virtualization of servers
US10275467B2 (en) Multi-level high availability model for an object storage service
US9697241B1 (en) Data fabric layer having nodes associated with virtual storage volumes of underlying storage infrastructure layer
CN107948226A (zh) 一种许可管理方法和系统
US10855767B1 (en) Distribution of batch data to sharded readers
US20230185631A1 (en) Embedded capacity-computer module for microservice load balancing and distribution
Prabavathy et al. A load balancing algorithm for private cloud storage
JP6237388B2 (ja) 特定プログラム、特定方法、及び特定装置
CN116910158A (zh) 基于复制组的数据处理、查询方法、装置、设备及介质

Legal Events

Date Code Title Description
PA0109 Patent application

Patent event code: PA01091R01D

Comment text: Patent Application

Patent event date: 20150515

PA0201 Request for examination
PE0902 Notice of grounds for rejection

Comment text: Notification of reason for refusal

Patent event date: 20160317

Patent event code: PE09021S01D

E601 Decision to refuse application
PE0601 Decision on rejection of patent

Patent event date: 20160922

Comment text: Decision to Refuse Application

Patent event code: PE06012S01D

Patent event date: 20160317

Comment text: Notification of reason for refusal

Patent event code: PE06011S01I

AMND Amendment
PX0901 Re-examination

Patent event code: PX09011S01I

Patent event date: 20160922

Comment text: Decision to Refuse Application

PX0701 Decision of registration after re-examination

Patent event date: 20161115

Comment text: Decision to Grant Registration

Patent event code: PX07013S01D

Patent event date: 20161024

Comment text: Amendment to Specification, etc.

Patent event code: PX07012R01I

Patent event date: 20160922

Comment text: Decision to Refuse Application

Patent event code: PX07011S01I

X701 Decision to grant (after re-examination)
GRNT Written decision to grant
PR0701 Registration of establishment

Comment text: Registration of Establishment

Patent event date: 20161118

Patent event code: PR07011E01D

PR1002 Payment of registration fee

Payment date: 20161118

End annual number: 3

Start annual number: 1

PG1501 Laying open of application
PG1601 Publication of registration
FPAY Annual fee payment

Payment date: 20191029

Year of fee payment: 4

PR1001 Payment of annual fee

Payment date: 20191029

Start annual number: 4

End annual number: 4

PR1001 Payment of annual fee

Payment date: 20201102

Start annual number: 5

End annual number: 5

PR1001 Payment of annual fee

Payment date: 20211101

Start annual number: 6

End annual number: 6

PR1001 Payment of annual fee

Payment date: 20221101

Start annual number: 7

End annual number: 7

PR1001 Payment of annual fee

Payment date: 20231031

Start annual number: 8

End annual number: 8