클라우드용 분산 파일 시스템

Distributed file system for cloud

클라우드용 분산 파일 시스템은 많은 클라이언트가 데이터에 액세스할 수 있도록 하고 해당 데이터에 대한 작업(작성, 삭제, 수정, 읽기, 쓰기)을 지원하는 파일 시스템입니다.각 데이터 파일은 청크라고 불리는 여러 부분으로 분할될 수 있습니다.각 청크는 다른 리모트머신에 보존할 수 있기 때문에, 애플리케이션의 병렬 실행을 용이하게 할 수 있습니다.일반적으로 데이터는 계층 트리의 파일에 저장됩니다.여기서 노드는 디렉토리를 나타냅니다.분산 아키텍처에서 파일을 공유하는 방법에는 여러 가지가 있습니다.각 솔루션은 애플리케이션의 복잡도에 따라 특정 유형의 애플리케이션에 적합해야 합니다.한편, 시스템의 보안은 확보되어야 한다.기밀성, 가용성 무결성은 안전한 시스템의 주요 열쇠입니다.

사용자는 클라우드 컴퓨팅을 통해 컴퓨팅 리소스를 공유할 수 있습니다.클라우드 컴퓨팅은 일반적으로 물리 서버, 애플리케이션 및 동적으로 가상화 및 할당되는 서비스 등 확장성과 탄력성이 뛰어난 리소스를 특징으로 합니다.모든 디바이스가 최신인지 확인하려면 동기화가 필요합니다.

분산 파일 시스템을 사용하면 많은 대기업, 중견기업 및 중소기업이 로컬 데이터처럼 원격 데이터를 저장하고 액세스할 수 있으므로 다양한 리소스를 쉽게 사용할 수 있습니다.

개요

역사

오늘날에는 분산 파일 시스템이 많이 구현되어 있습니다.최초의 파일 서버는 1970년대에 연구자들에 의해 개발되었다.Sun Microsystem의 네트워크 파일 시스템은 1980년대에 사용할 수 있게 되었습니다.그 이전에는 파일을 공유하고자 하는 사람들이 저장 매체에 저장된 파일을 물리적으로 이곳저곳으로 전송하는 스니커넷 방식을 사용했습니다.일단 컴퓨터 네트워크가 확산되기 시작하면, 기존의 파일 시스템은 많은 제한이 있고 다중 사용자 환경에 적합하지 않다는 것이 명백해졌습니다.사용자는 처음에 FTP를 사용하여 [1]파일을 공유했습니다.FTP는 1973년 말에 PDP-10에서 처음 실행되었습니다.FTP를 사용하더라도 파일을 소스 컴퓨터에서 서버로 복사한 다음 서버에서 대상 컴퓨터로 복사해야 했습니다.사용자는 파일 [2]공유와 관련된 모든 컴퓨터의 물리적 주소를 알아야 했습니다.

서포트 테크닉

최신 데이터 센터는 다양한 용량의 다수의 컴퓨터로 구성된 이종 혼재된 대규모 환경을 지원해야 합니다.클라우드 컴퓨팅은 데이터센터 네트워킹(DCN), 병렬 및 분산 시스템에서 데이터 집약적인 컴퓨팅 애플리케이션을 지원하는 MapReduce 프레임워크, 동적 리소스 할당을 제공하는 가상화 기술과 같은 기술을 사용하여 이러한 모든 시스템의 운영을 조정합니다. 여러 운영 체제가 공존할 수 있습니다.같은 물리 서버상에 있습니다.

적용들

클라우드 컴퓨팅은 사용자에게 필요한 CPU 및 스토리지 리소스를 완벽하게 투명하게 제공할 수 있기 때문에 대규모 컴퓨팅을 제공합니다.따라서 클라우드 컴퓨팅은 대규모 분산 프로세싱을 필요로 하는 다양한 유형의 애플리케이션을 지원하는 데 특히 적합합니다. 데이터 집약적인 컴퓨팅에는 가상 머신(VM)[3] 간에 데이터를 공유할 수 있는 고성능 파일 시스템이 필요합니다.

클라우드 컴퓨팅은 필요한 리소스를 동적으로 할당하고 작업이 완료되면 리소스를 해방합니다. 따라서 사용자는 종종 서비스 수준 계약을 통해 필요한 서비스에 대해서만 비용을 지불해야 합니다.클라우드 컴퓨팅과 클러스터 컴퓨팅 패러다임은 실험을 [4]수행하기 위해 많은 수의 컴퓨터를 사용할 수 있어야 하는 산업 데이터 처리 및 천문학 및 물리학과 같은 과학 애플리케이션에 점점 더 중요해지고 있습니다.

아키텍처

대부분의 분산 파일 시스템은 클라이언트-서버 아키텍처를 기반으로 구축되지만, 다른 분산형 솔루션도 존재합니다.

클라이언트 서버 아키텍처

Network File System(NFS; 네트워크 파일 시스템)은 클라이언트-서버 아키텍처를 사용합니다.이 아키텍처를 사용하면 네트워크상의 여러 머신 간에 로컬에 있는 것처럼 파일을 공유할 수 있어 표준화된 뷰를 얻을 수 있습니다.NFS 프로토콜을 사용하면 서로 다른 시스템 및 서로 다른 운영 체제에서 실행되는 이기종 클라이언트의 프로세스가 실제 파일 위치를 무시하고 원격 서버의 파일에 액세스할 수 있습니다.단일 서버에 의존하면 NFS 프로토콜의 가용성이 저하되고 확장성이 저하될 수 있습니다.복수의 서버를 사용해도, 각 [5]서버가 개별적으로 동작하고 있기 때문에, 가용성 문제는 해결되지 않습니다.NFS 모델은 원격 파일 서비스입니다.이 모델은 리모트액세스 모델이라고도 불리며 업로드/다운로드 모델과는 대조적입니다.

  • 원격 액세스 모델: 투과성을 제공합니다.클라이언트는 파일에 액세스 할 수 있습니다.리모트 파일(파일이 서버에 남아 있는 동안)[6]에 요구를 송신합니다.
  • 모델 업로드/다운로드:클라이언트는 로컬에서만 파일에 액세스할 수 있습니다.즉, 다른 고객이 사용하기 위해 파일을 다운로드하고 수정한 후 다시 업로드해야 합니다.

NFS에서 사용되는 파일 시스템은 Unix 시스템에서 사용되는 것과 거의 동일합니다.파일은 디렉토리와 파일이 노드로 표시되는 명명 그래프로 계층적으로 구성됩니다.

클러스터 기반 아키텍처

클러스터 기반 아키텍처는 클라이언트-서버 아키텍처의 일부 문제를 개선하여 애플리케이션 병렬 실행을 개선합니다.여기서 사용하는 기술은 파일 스트라이핑입니다.파일은 여러 스토리지 서버에 걸쳐 여러 개의 청크로 분할됩니다.파일의 다른 부분에 병렬로 액세스할 수 있도록 하는 것이 목표입니다.응용 프로그램이 이 기술의 혜택을 받지 못할 경우 서로 다른 서버에 서로 다른 파일을 저장하는 것이 더 편리합니다.그러나 웹 클라이언트에 서비스를 제공하는 Amazon이나 Google과 같은 대규모 데이터 센터용 분산 파일 시스템을 구성할 경우 다수의 컴퓨터에 분산된 파일에 대해 여러 작업(읽기, 업데이트, 삭제 등)을 수행할 수 있으므로 클러스터 기반 솔루션이 더욱 유용합니다.컴퓨터의 수가 많으면 하드웨어 [7]장애가 증가할 수 있습니다.이러한 유형의 분산 파일 시스템(DFS) 중 가장 널리 사용되는 두 가지는 GFS(Google File System)와 HDFS(Hadoop Distributed File System)입니다.양쪽의 파일 시스템은 표준 운영 체제([8]GFS의 경우 Linux)에서 실행되는 사용자 수준의 프로세스에 의해 구현됩니다.

설계 원리

목표들

GFS(Google File System) 및 HDFS(Hadoop Distributed File System)는 매우 큰 데이터 세트에서 배치 처리를 처리하기 위해 특별히 설계되었습니다.이를 위해서는 다음과 같은 가설을 [9]고려해야 합니다.

  • 고가용성: 클러스터는 수천 개의 파일 서버를 포함할 수 있으며, 그 중 일부는 언제든지 다운될 수 있습니다.
  • 서버는 랙, 방, 데이터센터, 국가 및 대륙에 속해 있어 지리적 위치를 정확하게 파악할 수 있습니다.
  • 파일 크기는 수 기가바이트에서 수 테라바이트까지 다양합니다.파일 시스템은 대량의 파일을 지원할 수 있어야 합니다.
  • 추가 작업을 지원하고 파일을 쓰는 동안에도 파일 내용을 볼 수 있어야 함
  • 동작하는 머신간의 통신은 신뢰성이 높아집니다.TCP/IP 는, RPC 통신 추상화라고 불리는 리모트 프로시저와 함께 사용됩니다.TCP 를 사용하면, 문제가 발생했을 때와 새로운 [10]접속을 확립할 필요가 있는 것을 클라이언트는 거의 즉시 알 수 있습니다.
로드 밸런싱

분산 환경에서 효율적인 운영을 위해서는 로드 밸런싱이 필수적입니다.즉, 동일한 시간 내에 더 많은 작업을 수행하고 고객에게 더 빨리 서비스를 제공하기 위해 서로 다른 [11]서버 간에 공평하게 작업을 분배해야 합니다.클라우드(N은 1000, 10000 또는 그 이상)에 N개의 청커버를 포함하는 시스템에서 각 파일은 고정 크기(예를 들어 64메가바이트)의 여러 부분 또는 청크로 분할되며,[12] 각 청커버의 부하는 서버가 호스팅하는 청커 수에 비례한다.부하 분산 클라우드에서는 리소스를 효율적으로 사용하는 동시에 MapReduce 기반 애플리케이션의 성능을 극대화할 수 있습니다.

부하 재조정

클라우드 컴퓨팅 환경에서는 장애가 [13][14]일반적이며 청커버는 업그레이드, 교체 및 시스템에 추가할 수 있습니다.파일을 동적으로 생성, 삭제 및 추가할 수도 있습니다.이로 인해 분산 파일 시스템의 부하 불균형이 발생하여 파일 청크가 서버 간에 균등하게 분산되지 않습니다.

GFS 및 HDFS와 같은 클라우드 내 분산 파일 시스템은 중앙 또는 마스터 서버 또는 노드(GFS용 마스터 및 HDFS용 NameNode)에 의존하여 메타데이터 및 로드 밸런싱을 관리합니다.마스터는 정기적으로 복제를 재조정합니다.첫 번째 서버의 빈 공간이 특정 임계값을 [15]밑돌면 데이터를 하나의 DataNode/Chunks 서버에서 다른 DataNode/Chunks 서버로 이동해야 합니다.그러나 이러한 중앙 집중식 접근 방식은 이미 많은 양의 파일 액세스를 관리할 수 없게 되면 이미 많은 양의 부하가 증가하므로 마스터 서버의 병목현상이 될 수 있습니다.로드 리밸런스 문제는 NP하드입니다.[16]

다수의 청커버가 협업하여 동작하도록 하고 분산 파일 시스템의 로드밸런싱 문제를 해결하기 위해 파일 청크를 재할당하여 가능한 [12]한 균등하게 배포하고 이동 비용을 절감하는 등의 몇 가지 접근법이 제안되었습니다.

구글 파일 시스템

묘사

가장 큰 인터넷 회사 중 하나인 구글은 구글의 데이터 처리 요구의 급증하는 수요를 충족시키기 위해 구글 파일 시스템(GFS)이라는 자체 분산 파일 시스템을 개발했으며, 모든 클라우드 서비스에 사용됩니다.GFS는 데이터 집약적인 애플리케이션을 위한 확장 가능한 분산 파일 시스템입니다.다수의 클라이언트가 동시에 액세스 할 수 있는 폴트 톨러런스 고성능 데이터 스토리지를 제공합니다.

GFS는 MapReduce를 사용합니다.이것에 의해, 유저는 병렬화나 로드 밸런싱의 문제를 생각하지 않고, 프로그램을 작성해 복수의 머신상에서 실행할 수 있습니다.GFS 아키텍처는 여러 청커버와 여러 클라이언트를 [17]위한 단일 마스터 서버를 기반으로 합니다.

전용 노드에서 실행되는 마스터 서버는 스토리지 리소스를 조정하고 파일의 메타데이터를 관리합니다(예: [9]기존 파일 시스템의 inode에 해당합니다).각 파일은 64MB의 여러 청크로 분할됩니다.각 청크는 청크 서버에 저장됩니다.청크는 청크 핸들에 의해 식별됩니다.이는 청크가 처음 생성될 때 마스터에 의해 할당되는 글로벌하게 고유한 64비트 번호입니다.

마스터는 파일 이름, 디렉터리 및 각 파일의 데이터를 포함하는 청크 목록에 대한 파일 매핑을 포함하여 파일의 모든 메타데이터를 유지합니다.메타데이터는 파일/청크 매핑과 함께 마스터 서버의 메인 메모리에 저장됩니다.이 데이터에 대한 업데이트는 디스크의 작업 로그에 기록됩니다.이 작업 로그는 원격 시스템에 복제됩니다.로그가 너무 커지면 체크포인트가 만들어지고 메인 [18]메모리 데이터는 메인 메모리에 매핑하기 쉽도록 B-트리 구조로 저장됩니다.

폴트 톨러런스

폴트 톨러런스를 용이하게 하기 위해 각 청크는 여러(기본값, 3개) 청크 서버에 [19]복제됩니다.청크를 하나 이상의 청크 서버에서 사용할 수 있습니다.이 계획의 장점은 단순함이다.마스터는 각 청크에 대해 청크 서버를 할당하는 역할을 하며 메타데이터 정보에 대해서만 연결됩니다.다른 모든 데이터의 경우 클라이언트는 청크 서버와 상호 작용해야 합니다.

마스터는 청크의 위치를 추적합니다.그러나 청크 위치를 정확하게 유지하려고 시도하지 않고 가끔 청크 서버에 연결하여 저장된 [20]청크를 확인합니다.이를 통해 확장성을 확보하고 워크로드 [21]증가로 인한 병목 현상을 방지할 수 있습니다.

GFS에서는 대부분의 파일이 기존 데이터를 덮어쓰지 않고 새 데이터를 추가함으로써 수정됩니다.일단 써지면 보통 파일은 랜덤이 아니라 순차적으로 읽혀지기 때문에 이 DFS는 많은 대용량 파일이 한 번 생성되고 여러 [22][23]번 읽히는 시나리오에 가장 적합합니다.

파일 처리

클라이언트가 파일 쓰기/업데이트를 원할 때 마스터는 복제본을 할당합니다. 복제본은 첫 번째 수정인 경우 기본 복제본이 됩니다.쓰기 프로세스는 다음 두 [9]단계로 구성됩니다.

  • 송신:우선 가장 중요한 것은 클라이언트가 마스터에 연락하여 어떤 청크서버가 데이터를 보유하고 있는지 알아내는 것입니다.클라이언트에는 기본 및 보조 청크 서버를 식별하는 복제본 목록이 제공됩니다.그런 다음 클라이언트는 가장 가까운 복제 청크 서버에 연결하여 데이터를 전송합니다.이 서버는 다음으로 가까운 서버로 데이터를 전송하고, 이 서버는 데이터를 다른 복제본으로 전달하는 방식으로 데이터를 전송합니다.그런 다음 데이터가 전파되고 메모리에 캐시되지만 아직 파일에 기록되지는 않습니다.
  • 기입:모든 복제본이 데이터를 수신하면 클라이언트는 기본 청크 서버에 쓰기 요청을 전송 단계에서 전송된 데이터를 식별합니다.다음으로 프라이머리 서버는 수신한 쓰기 조작에 시퀀스 번호를 할당하고 파일에 시리얼 번호 순서로 쓰기를 적용하여 그 순서로 쓰기 요구를 세컨더리 서버에 전송합니다.한편 마스터는 루프에서 제외됩니다.

그 결과 데이터 흐름과 제어 흐름의 두 가지 유형의 흐름을 구분할 수 있습니다.데이터 플로우는 송신 위상에 관련지어져 제어 플로우는 기입 위상에 관련지어진다.이것에 의해, 프라이머리 청크 서버가 기입 순서를 제어할 수 있게 됩니다.마스터가 복제본에 쓰기 작업을 할당하면 청크 버전 번호가 증가하고 해당 청크가 포함된 모든 복제본에 새 버전 번호가 통지됩니다.청크 서버가 [24]다운되어 복제본이 업데이트되지 않은 경우 청크 버전 번호를 사용하여 업데이트 오류 탐지를 수행할 수 있습니다.

일부 새로운 구글 애플리케이션은 64메가 청크 크기에서 잘 작동하지 않았다.이 문제를 해결하기 위해 GFS는 2004년에 빅테이블 [25]접근법을 구현하기 시작했습니다.

하둡 분산 파일 시스템

Apache Software Foundation이 개발한 이 분산 파일 시스템은 매우 많은 양의 데이터(테라바이트 또는 페타바이트)를 저장할 수 있도록 설계되었습니다HDFS .아키텍처는 GFS(마스터/슬레이브 아키텍처)와 유사합니다.HDFS는 일반적으로 시스템 클러스터에 설치됩니다.Hadoop의 [26]설계 개념은 Google File System, Google MapReduce Bigtable이 각각 HDFS(Hadoop Distributed File System), Hadoop MapReduce(HBase)에 의해 구현되고 있는 등 Google이 제공합니다.GFS와 마찬가지로 HDFS는 Write-Once-Read-Many 파일 액세스가 가능한 시나리오에 적합하며 랜덤 읽기 및 쓰기 대신 파일 추가 및 잘라내기를 지원하여 데이터 일관성 [27]문제를 단순화합니다.

HDFS 클러스터는 단일 NameNode와 여러 DataNode 시스템으로 구성됩니다.마스터 서버인 NameNode는 RAM에서 스토리지 DataNode의 메타데이터를 관리 및 유지합니다.DataNodes는 실행되는 노드에 연결된 스토리지를 관리합니다.NameNode 및 DataNode는 일상 사용 머신에서 실행되도록 설계된 소프트웨어이며, 일반적으로 Linux OS에서 실행됩니다.HDFS는 Java를 지원하는 모든 머신에서 실행할 수 있으므로 NameNode [28]또는 Datanode 소프트웨어를 실행할 수 있습니다.

HDFS 클러스터에서는 마지막 블록이 더 작을 가능성을 제외하고 파일이 하나 이상의 동일한 크기의 블록으로 분할됩니다.각 블록은 여러 DataNode에 저장되며, 가용성을 보장하기 위해 각 블록을 여러 DataNode에 복제할 수 있습니다.기본적으로 각 블록은 "블록 수준 복제"[29]라고 하는 프로세스로 세 번 복제됩니다.

NameNode는 파일 및 디렉토리의 열기, 닫기 및 이름 변경과 같은 파일 시스템 네임스페이스 작업을 관리하고 파일 액세스를 제어합니다.또한 DataNodes에 대한 블록 매핑도 결정합니다.DataNode는 파일 시스템 클라이언트의 읽기 및 쓰기 요청을 처리하고, 블록 할당 또는 삭제를 관리하며,[30] 블록을 복제하는 역할을 합니다.

클라이언트는 데이터를 읽거나 쓰기를 원할 때 NameNode에 접속하고 NameNode는 데이터의 읽기 또는 쓰기 위치를 확인합니다.그 후 클라이언트는 DataNode의 위치를 파악하여 읽기 또는 쓰기 요청을 전송할 수 있습니다.

HDFS는 일반적으로 데이터 재조정 방식과의 호환성을 특징으로 합니다.일반적으로 DataNode의 빈 공간을 관리하는 것은 매우 중요합니다.사용 가능한 공간이 충분하지 않은 경우 DataNode 간에 데이터를 이동해야 하며, 추가 복제본을 생성할 경우 시스템 [29]균형을 보장하기 위해 데이터를 이동해야 합니다.

기타 예

분산 파일 시스템은 다양한 용도로 최적화할 수 있습니다.GFS를 포함한 인터넷 서비스용으로 설계된 일부 제품은 확장성에 최적화되어 있습니다.분산 파일 시스템의 다른 설계에서는 일반적으로 [31]병렬로 실행되는 성능 집약적인 애플리케이션을 지원합니다.를 들어 MapR 파일 시스템(MapR-FS), Ceph-FS, Fraunhofer 파일 시스템(BeeGFS), Lustre 파일 시스템, IBM GPFS(General Parallel File System), 병렬 가상 파일 시스템 등이 있습니다.

MapR-FS는 MapR Converged Platform의 기반이 되는 분산 파일 시스템이며 분산 파일 스토리지, 여러 API를 사용하는 NoSQL 데이터베이스 및 통합 메시지 스트리밍 시스템을 제공합니다.MapR-FS는 확장성, 성능, 안정성 및 가용성을 위해 최적화되어 있습니다.파일 스토리지 기능은 Apache Hadoop Distributed File System(HDFS) API와 호환되지만 HDFS와 구별되는 몇 가지 설계 특성을 가지고 있습니다.가장 눈에 띄는 차이점은 MapR-FS는 파일 및 디렉토리의 메타데이터가 네임스페이스 전체에 분산된 완전한 읽기/쓰기 파일 시스템이기 때문에 NameNode가 [32][33][34][35][36]없다는 것입니다.

Ceph-FS는 뛰어난 성능과 [37]신뢰성을 제공하는 분산 파일 시스템입니다.대용량 파일 및 디렉토리 처리, 수천 개의 디스크 액티비티 조정, 대규모 메타데이터 병렬 액세스 제공, 과학 워크로드와 범용 워크로드 모두 조작, 대규모 인증 및 암호화, 빈번한 디바이스로 인한 동적 증가 또는 감소 등의 과제를 해결합니다.사용 중지, 디바이스 장애 및 클러스터 [38]확장입니다.

BeeGFS는 Fraunhofer Competence Center for High Performance Computing의 고성능 병렬 파일 시스템입니다.Bee의 분산 메타데이터 아키텍처GFS는 I/[39]O 요구가 높은 HPC 및 유사한 애플리케이션을 실행하는 데 필요한 확장성과 유연성을 제공하도록 설계되었습니다.

Lustre File System은 분산형 시스템에서 전통적으로 볼 수 있는 병목현상에 대처하도록 설계 및 구현되어 있습니다.Lustre는 효율성, 확장성 및 [40]용장성을 특징으로 합니다.GPFS는 또한 [41]이러한 병목 현상을 제거하기 위해 설계되었습니다.

의사소통

분산 파일 시스템의 고성능을 실현하려면 컴퓨팅 노드 간의 효율적인 통신과 스토리지 시스템에 대한 빠른 액세스가 필요합니다.퍼포먼스를 보증하려면 , 열기, 닫기, 읽기, 쓰기, 송신, 수신등의 조작을 고속으로 실시할 필요가 있습니다.예를 들어, 각 읽기 또는 쓰기 요청은 Disk 스토리지에 액세스하므로 검색,[42] 회전 및 네트워크 지연 시간이 발생합니다.

데이터 통신(송수신) 작업은 애플리케이션 버퍼에서 머신 커널로 데이터를 전송하고 TCP는 프로세스를 제어하며 커널에서 구현됩니다.다만, 네트워크의 congestion나 에러의 경우는, TCP 가 직접 데이터를 송신하지 않는 경우가 있습니다.커널의 버퍼에서 애플리케이션으로 데이터를 전송하는 동안 머신은 원격 머신의 바이트 스트림을 읽지 않습니다.실제로 [43]TCP는 애플리케이션의 데이터 버퍼링을 담당합니다.

파일 읽기 및 쓰기 또는 파일 송수신용 버퍼 크기를 선택하는 작업은 응용 프로그램 수준에서 수행됩니다.버퍼는 순환 링크 [44]목록을 사용하여 유지됩니다.버퍼 노드 세트로 구성됩니다.각 BufferNode에는 DataField가 있습니다.DataField에는 데이터와 다음 BufferNode를 가리키는 NextBufferNode라는 이름의 포인터가 포함되어 있습니다.현재 위치를 찾으려면 다음 두 가지 포인터가 사용됩니다.CurrentBufferNode 및 EndBufferNode: 마지막 쓰기 및 읽기 위치의 BufferNode 위치를 나타냅니다.BufferNode에 빈 공간이 없는 경우 사용 가능한 공간이 [45]생길 때까지 대기 신호를 클라이언트에 보냅니다.

분산 파일 시스템의 클라우드 기반 동기화

애드혹 접속이 가능한 복수의 디바이스를 가지는 유저가 증가하고 있습니다.이러한 디바이스에 복제되는 데이터 세트는 임의의 수의 서버 간에 동기화되어야 합니다.이 기능은 백업 및 오프라인 작업에도 유용합니다.실제로 사용자 네트워크 상태가 좋지 않을 경우 사용자 디바이스는 데이터의 일부를 선택적으로 복제하여 나중에 오프라인으로 변경합니다.네트워크 상태가 양호해지면 디바이스가 [46]동기화됩니다.분산 동기 문제를 해결하기 위해서는 사용자 제어 피어 투 피어 동기화 및 클라우드 마스터 복제 [46]동기화라는 두 가지 방법이 있습니다.

  • 사용자가 제어하는 피어투피어:rsync 등의 소프트웨어는 데이터를 포함하는 모든 사용자의 컴퓨터에 설치해야 합니다.파일은 피어 투 피어(peer-to-peer) 동기화에 의해 동기화됩니다.이 경우 사용자는 네트워크주소와 동기화 파라미터를 지정해야 하므로 수동 프로세스가 됩니다.
  • 클라우드 마스터-하드웨어 동기화: 클라우드 서비스에서 널리 사용되며, 마스터 복제본은 클라우드에서 유지 관리되며 모든 업데이트 및 동기화 작업이 이 마스터 복사본에 대해 수행되므로 장애 발생 시 높은 수준의 가용성과 안정성을 제공합니다.

보안 키

클라우드 컴퓨팅에서 가장 중요한 보안 개념은 기밀성, 무결성가용성("CIA")입니다.개인정보를 공개하지 않기 위해서는 기밀유지가 필수적이다.무결성은 데이터가 [47]손상되지 않도록 보장합니다.

기밀성

기밀성은 데이터 및 계산 태스크가 기밀임을 의미합니다. 클라우드 프로바이더나 다른 클라이언트 모두 클라이언트의 데이터에 액세스할 수 없습니다.기밀성에 대한 많은 연구가 이루어졌습니다. 기밀성은 여전히 클라우드 컴퓨팅에 있어 중요한 과제 중 하나이기 때문입니다.클라우드 제공자에 대한 신뢰 부족도 이와 관련된 [48]문제입니다.클라우드의 인프라는 승인되지 않은 당사자가 고객의 데이터에 액세스하지 않도록 해야 합니다.

서비스 공급자가 다음 [49]작업을 모두 수행할 수 있으면 환경이 안전하지 않게 됩니다.

  • 클라우드에서 소비자 데이터 찾기
  • 소비자 데이터에 액세스하여 검색하다
  • 데이터의 의미를 이해한다(데이터의 유형, 응용 프로그램의 기능 및 인터페이스, 데이터의 형식).

데이터의 지리적 위치는 프라이버시와 기밀성을 판단하는 데 도움이 됩니다.고객의 위치를 고려해야 합니다.예를 들어, 유럽의 고객은 미국에 있는 데이터 센터를 사용하는 데 관심이 없습니다. 왜냐하면 데이터의 기밀성 보장에 영향을 미치기 때문입니다.이 문제에 대처하기 위해 일부 클라우드 컴퓨팅 벤더는 고객과 [50]체결된 서비스 수준 계약의 파라미터로 호스트의 지리적 위치를 포함시켜 사용자가 데이터를 호스트하는 서버의 위치를 직접 선택할 수 있도록 했습니다.

기밀 유지를 위한 또 다른 접근 방식으로는 데이터 [51]암호화가 있습니다.그렇지 않으면 무단 사용의 심각한 위험이 있습니다.계산을 [53]간소화하기 위해 중요한 [52]데이터만 암호화하고 일부 작업만 지원하는 등 다양한 솔루션이 있습니다.또한 FHE와 같은 암호화 기술과 도구를 사용하여 클라우드에서 [47]개인 정보를 보호합니다.

무결성

클라우드 컴퓨팅의 무결성은 컴퓨팅 무결성뿐만 아니라 데이터 무결성도 의미합니다.이러한 무결성은 클라우드 서버에 데이터를 올바르게 저장해야 하며, 장애나 잘못된 컴퓨팅이 발생할 경우 이러한 문제를 감지해야 한다는 것을 의미합니다.

데이터 무결성은 악의적인 이벤트 또는 관리 오류(백업 및 복원, 데이터 마이그레이션 또는 P2P 시스템 [54]구성원 자격 변경 등)에 의해 영향을 받을 수 있습니다.

암호화(일반적으로 데이터 [55]블록의 메시지 인증 코드(MAC)를 사용하여)를 사용하면 무결성을 쉽게 실현할 수 있습니다.

데이터 무결성에 영향을 미치는 검사 메커니즘이 존재합니다.예:

  • HAIL(High-Availability and Integrity Layer)은 일련의 서버를 클라이언트에 대해 저장된 파일이 손상되지 않고 검색 [56]가능하다는 것을 증명할 수 있는 분산 암호화 시스템입니다.
  • Hach POR(대용량 [57]파일에 대한 검색 가능성 증명)은 대칭 암호화 시스템을 기반으로 하며, 파일 무결성을 향상시키기 위해 파일에 저장해야 하는 검증 키는 1개뿐입니다.이 메서드는 파일 F를 암호화한 후 암호화된 파일 끝에 추가해야 하는 "sentinel"이라는 이름의 랜덤 문자열을 생성하는 역할을 합니다.서버가 다른 블록과 구별할 수 없는 sentinel을 찾을 수 없기 때문에 조금만 변경해도 파일이 변경되었는지 여부를 알 수 있습니다.
  • PDP(Provible Data Owness) 체크는 신뢰할 수 없는 서버상의 데이터 무결성을 효율적으로 체크하는 방법을 제공하는 효율적이고 실용적인 방법의 클래스입니다.
    • PDP:[58] 데이터를 서버에 저장하기 전에 클라이언트는 일부 메타데이터를 로컬로 저장해야 합니다.나중에 데이터를 다운로드하지 않고 클라이언트는 서버에 데이터가 위조되지 않았는지 확인하도록 요구할 수 있습니다.이 방법은 정적 데이터에 사용됩니다.
    • 스케일러블 PDP:[59] 이 접근법은 공개 키 암호화보다 효율적인 대칭 키를 전제로 합니다.일부 동적 작업(수정, 삭제 및 추가)을 지원하지만 공개 확인에는 사용할 수 없습니다.
    • Dynamic PDP:[60] 이 접근법은 PDP 모델을 확장하여 추가, 삽입, 변경, 삭제 등의 여러 업데이트 작업을 지원하므로 집중적인 계산에 적합합니다.

유용성

가용성은 일반적으로 [61][62]복제에 의해 영향을 받습니다.[63][64] 한편, 일관성이 보장되어야 합니다.그러나 일관성과 가용성을 동시에 달성할 수는 없습니다.각각의 우선순위는 어느 정도 희생되어 있습니다.균형을 [65]맞춰야 한다.

데이터에 액세스할 수 있으려면 ID가 있어야 합니다.예를 들어, Skute는 키/밸류 스토리지를 기반으로 하는 메커니즘으로 데이터를 효율적으로 동적으로 할당할 수 있습니다.각 서버는 continent-country-datacenter-room-rack-server 형식의 라벨로 식별해야 합니다.서버는 여러 가상 노드를 참조할 수 있으며, 각 노드는 선택한 데이터(또는 여러 데이터의 여러 파티션)를 가집니다.각 데이터는 단방향 암호화 해시함수(예를 들어 MD5)에 의해 생성된 키 공간에 의해 식별되며, 이 키의 해시함수 값에 의해 현지화된다.키 공간은 여러 파티션으로 분할될 수 있으며 각 파티션은 데이터를 참조합니다.복제를 수행하려면 가상 노드를 복제하고 다른 서버에서 참조해야 합니다.데이터 내구성과 데이터 가용성을 최대화하려면 복제품을 서로 다른 서버에 배치하고 모든 서버를 서로 다른 지리적 위치에 배치해야 합니다.이는 지리적 다양성에 따라 데이터 가용성이 증가하기 때문입니다.복제 프로세스에는 공간 가용성의 평가가 포함됩니다. 공간 가용성은 각 청크 서버의 최소 임계값보다 커야 합니다.그렇지 않으면 데이터가 다른 청크 서버에 복제됩니다.각 파티션 i에는 다음 공식으로 나타나는 가용성 값이 있습니다.

{ 레플리카를 호스트하는 서버입니다. n i { i } c n j { _ { }는 서버 { _ {} j { _ { 하드웨어 컴포넌트 등의 기술적 요소에 대한 신뢰)입니다.국가의 경제적, 정치적 상황과 같은 n-기술적 상황)과 다양성은 s [66] 의 지리적 거리이다.

레플리케이션은 데이터의 가용성을 확보하기 위한 훌륭한 솔루션입니다만, 메모리 [67]용량 면에서는 비용이 너무 많이 듭니다.DiskReduce는[67] RAID 기술(RAID-5 및 RAID-6)을 기반으로 복제된 데이터의 비동기 인코딩을 허용하는 HDFS의 수정된 버전입니다.실제로 널리 복제된 데이터를 검색하여 인코딩한 후 추가 복사본을 삭제하는 백그라운드 프로세스가 있습니다.또 다른 접근법은 복제를 소거 [68]코딩으로 대체하는 것입니다.또, 데이터의 가용성을 확보하기 위해서, 데이터 리커버리를 가능하게 하는 많은 어프로치가 있습니다.실제로 데이터는 코딩되어야 하며, 데이터가 손실된 경우 코딩 단계에서 생성된 [69]조각에서 데이터를 복구할 수 있습니다.가용성을 보장하기 위해 다양한 메커니즘을 적용하는 다른 방법으로는 Microsoft Azure의 Reed-Solomon 코드와 HDFS용 RaidNode가 있습니다.또한 Google은 여전히 삭제 코딩 [70]메커니즘에 기반한 새로운 접근 방식을 개발하고 있습니다.

클라우드 [68]스토리지에는 RAID가 구현되어 있지 않습니다.

경제적 측면

클라우드 컴퓨팅 경제는 빠르게 성장하고 있습니다.미국 정부는 [71]2015년까지 70억 달러로 예상되는 복합 연간 성장률(CAGR)의 40%를 지출하기로 결정했다.

점점 더 많은 기업들이 클라우드 컴퓨팅을 사용하여 대량의 데이터를 관리하고 스토리지 용량의 부족을 극복하고 이러한 리소스를 서비스로 사용할 수 있도록 함으로써 인프라(사용량에 따른 과금 모델)[72]에 투자하지 않고도 컴퓨팅 요구를 충족할 수 있게 되었습니다.

모든 애플리케이션 프로바이더는 데이터의 복제본이 저장되어 있는 각 서버의 비용을 정기적으로 지불해야 합니다.서버 비용은 하드웨어 품질, 스토리지 용량 및 쿼리 처리 및 통신 [73]오버헤드에 따라 결정됩니다.클라우드 컴퓨팅을 통해 프로바이더는 고객의 요구에 따라 서비스를 확장할 수 있습니다.

종량제 모델은 컴퓨팅 집약적인 비즈니스에서 이익을 얻고자 하는 신생 기업의 부담도 덜어줍니다.또한 클라우드 컴퓨팅은 이러한 컴퓨팅 자원을 가지고 있지 않은 많은 제3세계 국가들에게 기회를 제공합니다.클라우드 컴퓨팅은 [74]혁신에 대한 IT 장벽을 낮출 수 있습니다.

클라우드 컴퓨팅의 광범위한 활용에도 불구하고 신뢰할 수 없는 클라우드에서 대량의 데이터를 효율적으로 공유하는 것은 여전히 어려운 과제입니다.

레퍼런스

  1. ^ Sun 마이크로시스템, 페이지 1
  2. ^ Fabio Kon, 페이지 1 : (
  3. ^ 고바야시2011년, 페이지 1
  4. ^ 앙가비니2011, 페이지 1
  5. ^ Di Sano et al. 2012, 2페이지
  6. ^ Andrew & Maarten 2006, 492페이지
  7. ^ Andrew & Maarten 2006, 496 페이지
  8. ^ 훔베토프 2012, 페이지 2
  9. ^ a b c Krzyzanowski 2012, 페이지 2
  10. ^ 파벨 조흐, 7페이지
  11. ^ 카이 2013, 페이지 23
  12. ^ a b 샤오 2013, 페이지 2
  13. ^ 샤오 2013, 952페이지
  14. ^ Ghemawat, Gobioff & Leung 2003, 페이지 1
  15. ^ Ghemawat, Gobioff & Leung 2003, 8페이지
  16. ^ 샤오 2013, 953페이지
  17. ^ Di Sano et al. 2012, 1-2페이지
  18. ^ Krzyzanowski 2012, 페이지 4
  19. ^ Di Sano et al. 2012, 2페이지
  20. ^ Andrew & Maarten 2006, 497페이지
  21. ^ 훔베토프 2012, 3페이지
  22. ^ 훔베토프 2012, 5페이지
  23. ^ Andrew & Maarten 2006, 498페이지
  24. ^ Krzyzanowski 2012, 5페이지
  25. ^ "The Great Disk Drive in the Sky: How Web giants store big—and we mean big—data". 2012-01-27.
  26. ^ Fan-Hsun2012, 2페이지
  27. ^ "Apache Hadoop 2.9.2 – HDFS Architecture".
  28. ^ 아제딘 2013, 페이지 2
  29. ^ a b Adamov 2012, 페이지 2
  30. ^ Yee & Thu Naing 2011, 페이지 122
  31. ^ 소아레스 2013, 페이지 158
  32. ^ Perez, Nicolas (2016-01-02). "How MapR improves our productivity and simplifies our design". Medium. Medium. Retrieved June 21, 2016.
  33. ^ Woodie, Alex (2016-03-08). "From Hadoop to Zeta: Inside MapR's Convergence Conversion". Datanami. Tabor Communications Inc. Retrieved June 21, 2016.
  34. ^ Brennan, Bob. "Flash Memory Summit". youtube. Samsung. Retrieved June 21, 2016.
  35. ^ Srivas, MC. "MapR File System". Hadoop Summit 2011. Hortonworks. Retrieved June 21, 2016.
  36. ^ Dunning, Ted; Friedman, Ellen (January 2015). "Chapter 3: Understanding the MapR Distribution for Apache Hadoop". Real World Hadoop (First ed.). Sebastopol, CA: O'Reilly Media, Inc. pp. 23–28. ISBN 978-1-4919-2395-5. Retrieved June 21, 2016.
  37. ^ Weil et al. 2006, 307페이지
  38. ^ Maltzahn et al., 2010, 39페이지
  39. ^ 야코비 &만, 페이지 10
  40. ^ 슈완 필립 2003, 페이지 401
  41. ^ Jones, Koniges & Yates 2000, 페이지 1
  42. ^ 우파디아야 외 2008, 400페이지
  43. ^ Upadhya et al., 2008, 페이지 403
  44. ^ Upadhya et al., 2008, 페이지 401
  45. ^ Upadhya et al., 2008, 페이지 402
  46. ^ a b Upoor, Flouris & Bilas 2010, 페이지 1
  47. ^ a b Zhifeng & Yang 2013, 페이지 854
  48. ^ Zhifeng & Yang 2013, 845-846페이지
  49. ^ Yau & An 2010, 페이지 353
  50. ^ Vecchiola, Pandey & Buya 2009, 페이지 14
  51. ^ Yau & An 2010, 352페이지
  52. ^ 미란다 & 시아니 2009
  53. ^ 내흐릭 & 라우터 2013
  54. ^ 지펑&양 2013, 5페이지
  55. ^ 쥬엘 & 오퍼레아 2013, 4페이지
  56. ^ Bowers, Juels 및 Oprea 2009
  57. ^ Juels & S. Kaliski 2007, 2페이지
  58. ^ 아테니제 외 2007년
  59. ^ 아테니제2008, 5, 9페이지
  60. ^ 어웨이 등 2009년, 페이지 2
  61. ^ a b Bonvin, Papaioannou & Aver 2009, 페이지 206
  62. ^ 쿠옹 연구진, 2012, 페이지
  63. ^ A., A. & P. 2011, 3페이지
  64. ^ Qian, D. & T. 2011, 3페이지
  65. ^ Vogels 2009, 2페이지
  66. ^ Bonvin, Papaioannou & Aver 2009, 페이지 208
  67. ^ a b 카네기 등 2009년, 페이지 1
  68. ^ a b 왕 외, 2012, 페이지 1
  69. ^ Abu-Libdeh, Princehouse & Weatherspoon 2010, 페이지 2
  70. ^ 연구진, 2012, 9페이지
  71. ^ 로리 M. 카우프만 2009, 2페이지
  72. ^ 앙가비니2011, 페이지 1
  73. ^ Bonvin, Papaioannou & Aver 2009, 3페이지
  74. ^ Marston et al. 2011, 3페이지

참고 문헌

  1. 아키텍처, 구조 및 설계:
  2. 보안.
  3. 동기
    • Uppoor, S; Flouris, M.D; Bilas, A (2010). "Cloud-based synchronization of distributed file system hierarchies". 2010 IEEE International Conference on Cluster Computing Workshops and Posters (CLUSTER WORKSHOPS). Inst. of Comput. Sci. (ICS), Found. for Res. & Technol. - Hellas (FORTH), Heraklion, Greece. pp. 1–4. doi:10.1109/CLUSTERWKSP.2010.5613087. ISBN 978-1-4244-8395-2. S2CID 14577793.
  4. 경제적 측면
    • Lori M., Kaufman (2009). "Data Security in the World of Cloud Computing". Security & Privacy, IEEE. 7 (4): 161–64. doi:10.1109/MSP.2009.87. S2CID 16233643.
    • Marston, Sean; Lia, Zhi; Bandyopadhyaya, Subhajyoti; Zhanga, Juheng; Ghalsasi, Anand (2011). Cloud computing — The business perspective. Decision Support Systems Volume 51, Issue 1. pp. 176–189. doi:10.1016/j.dss.2010.12.006.
    • Angabini, A; Yazdani, N; Mundt, T; Hassani, F (2011). "Suitability of Cloud Computing for Scientific Data Analyzing Applications; an Empirical Study". 2011 International Conference on P2P, Parallel, Grid, Cloud and Internet Computing. Sch. of Electr. & Comput. Eng., Univ. of Tehran, Tehran, Iran. pp. 193–199. doi:10.1109/3PGCIC.2011.37. ISBN 978-1-4577-1448-1. S2CID 13393620.