구글 파일 시스템

Google File System
구글 파일 시스템
운영 체제Linux 커널
유형분산 파일 시스템
면허증.독자 사양

Google File System(GFS 또는 GoogleFS, GFS Linux 파일 시스템과 혼동하지 않음)은 대규모 상용 하드웨어 클러스터를 사용하여 데이터에 효율적이고 신뢰할 수 있는 액세스를 제공하기 위해 Google에 의해 개발된 독점 분산 파일 시스템입니다.구글 파일 시스템의 마지막 버전은 [1][2]Colosus로 코드명이 붙여져 2010년에 출시되었습니다.

설계.

Google 파일 시스템은 시스템 간 상호 작용을 위해 설계되었으며 사용자 간 상호 작용을 위해 설계되지 않았습니다.청크 서버는 데이터를 자동으로 복제합니다.

GFS는 구글의 핵심 데이터 스토리지 및 사용 요구(주로 검색 엔진)를 위해 강화되었습니다.Google File System은 구글 초기 래리 페이지와 세르게이 브린이 개발한 구글의 초기 노력인 "BigFiles"에서 발전했습니다.파일은 64메가바이트의 고정 크기 청크로 분할됩니다.이는 일반 파일 시스템의 클러스터나 섹터와 비슷하며 덮어쓰거나 축소되는 경우는 극히 드물며, 보통 파일이 추가되거나 읽힙니다.또한 저렴한 "커맨드" 컴퓨터로 구성된 고밀도 노드인 구글 컴퓨팅 클러스터에서 실행되도록 설계 및 최적화되어 있습니다. 즉, 개별 노드의 높은 장애율과 그에 따른 데이터 손실에 대한 예방 조치를 취해야 합니다.다른 설계 결정에서는 지연 시간을 희생하더라도 높은 데이터 처리량을 선택합니다.

GFS 클러스터는 여러 노드로 구성됩니다.이러한 노드는 1개의 마스터노드와 여러 개의 청커버의 2가지 유형으로 나뉩니다.각 파일은 고정 크기 청크로 분할됩니다.청커버는 이 청크를 저장합니다.각 청크는 작성 시 마스터 노드에 의해 글로벌하게 고유한 64비트라벨이 할당되며 구성 청크에 대한 파일의 논리적 매핑이 유지됩니다.각 청크는 네트워크 전체에서 여러 번 복제됩니다.기본적으로는 3회 복제되지만 구성 가능합니다.[3]요구가 높은 파일은 레플리케이션 팩터가 높을 수 있지만, 애플리케이션 클라이언트가 엄격한 스토리지 최적화를 사용하는 파일은, 신속한 가비지 [3]클리닝 정책에 대응하기 위해서, 3 회 미만으로 레플리케이션을 실시할 수 있습니다.

마스터 서버는 보통 실제 청크를 저장하는 것이 아니라 64비트 라벨을 청크 위치에 매핑하는 테이블과 이들이 구성하는 파일(파일에서 청크로 매핑), 청크 복사본 위치, 특정 청크에 읽기 또는 쓰기 중인 프로세스 또는 taki 등 청크에 관련된 모든 메타데이터를 저장합니다.ng 복제에 따라 청크의 "스냅샷"을 만듭니다(일반적으로 노드 장애로 인해 청크의 복사본 수가 설정된 수보다 적은 경우 마스터 서버의 지시에 따라).이러한 메타데이터는 모두 마스터 서버가 정기적으로 각 청크 서버로부터 업데이트를 수신함으로써 최신 상태로 유지됩니다("하트비트 메시지").

변경 권한은 기간 제한이 있는 "리스" 시스템에 의해 처리됩니다.이 시스템에서는 마스터 서버가 한정된 기간 동안 프로세스에 대한 권한을 부여하며, 이 기간 동안 마스터 서버로부터 청크를 수정할 수 있는 다른 프로세스는 허용되지 않습니다.수정 청크 서버는 항상 주 청크 홀더이며 변경 내용을 백업 복사본이 있는 청커버로 전파합니다.변경 내용은 모든 청커버가 확인 응답을 할 때까지 저장되지 않으므로 작업의 완료와 원자성이 보증됩니다.

프로그램은 먼저 마스터 서버에서 원하는 청크의 위치를 쿼리하여 청크에 액세스합니다.청크가 동작하지 않는 경우(즉 미결 리스가 존재하지 않는 경우), 마스터는 해당 위치와 함께 응답하고 프로그램은 청크 서버에 직접 연락하여 데이터를 수신합니다(Kazaa 및 그 슈퍼노드와 유사).

대부분의 다른 파일 시스템과 달리 GFS는 운영 체제의 커널에 구현되지 않고 사용자 공간 [4]라이브러리로 제공됩니다.

인터페이스

Google 파일 시스템은 POSIX [5]인터페이스를 제공하지 않습니다.파일은 디렉토리로 계층적으로 구성되며 경로 이름으로 식별됩니다.작성, 삭제, 열기, 닫기, 읽기, 쓰기 등의 파일 작업이 지원됩니다.Record Append를 지원하므로 여러 클라이언트가 동시에 동일한 파일에 데이터를 추가할 수 있으며 원자성이 보장됩니다.

성능

벤치마킹 [3]결과에 따라 비교적 적은 수의 서버(15)에서 사용할 경우 파일 시스템은 단일 디스크와 동등한 읽기 성능(80~100MB/s)을 달성하지만 쓰기 성능(30MB/s)이 저하되고 기존 파일에 데이터를 추가하는 속도(5MB/s)가 상대적으로 느립니다.저자들은 무작위 탐색 시간에 대한 결과를 제시하지 않는다.마스터 노드는 데이터 읽기에 직접 관여하지 않기 때문에(데이터는 청크 서버에서 읽기 클라이언트로 직접 전달됨), 읽기 속도는 청크 서버의 수에 따라 크게 증가하여 342 노드에 대해 583 MB/s를 달성한다.복수의 서버를 집약하는 것으로, 대용량을 실현할 수 있는 한편, 3개의 독립된 장소에 데이터를 보존하는 것으로(용장성을 실현) 다소 삭감할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Hoff, Todd (2010-09-11). "Google's Colossus Makes Search Real-Time by Dumping MapReduce". High Scalability. Archived from the original on 2019-04-04.
  2. ^ Ma, Eric (2012-11-29). "Colossus: Successor to the Google File System (GFS)". SysTutorials. Archived from the original on 2019-04-12. Retrieved 2016-05-10.
  3. ^ a b c Ghemawat, Gobioff & Leung 2003.
  4. ^ Kyriazis, Dimosthenis (2013). Data Intensive Storage Services for Cloud Environments. IGI Global. p. 13. ISBN 9781466639355.
  5. ^ Marshall Kirk McKusick; Sean Quinlan (August 2009). "GFS: Evolution on Fast-forward". ACM Queue. 7 (7): 10–20. doi:10.1145/1594204.1594206. Retrieved 21 December 2019.

참고 문헌

외부 링크

  • 를 클릭합니다"GFS: Evolution on Fast-forward", Queue, ACM.
  • 를 클릭합니다"Google File System Eval, Part I", Storage mojo.