Gfs Kyu

대용량 데이터 처리 필요 최대 규모의 검색 , 최대 규모의 동영상 서비스

컴포넌트의 고장은 일반적 여러 저가 장비에 자료를 분산시키고 관리해야 했다 .

시간에 따라 추가되는 컨텐츠 블로그 , 동영상 , 검색 등의 구글 서비스는 랜덤 접근 보다 순차적인 추가가 많았다 .

큰 스트리밍 읽기 , 적은 랜덤 읽기

동일한 파일에 대한 append

POSIX 같은 표준 API 는 없음 .

만들기 지우기 열기 닫기 읽기 쓰기

아직 더 있습니다 . 안 끝났으니깐 울지 말아요 .

내용을 추가하는 record append

Metadata 저장 마스터 서버

Metadata 영구적 (Operation Log) 파일과 Chunk 네임스페이스 청크와 파일의 연결 정보 Chunkserver 에게 문의 청크의 복사본 위치 Chunkserver 가 시작될 때 .

하나의 Chunk 는 여러 서버에 저장 .

Chunk – 64MB 의 작은 조각

한번 요청시 64MB 을 전송 . 순차적인 파일에서 재 요청 필요없음 . 작은 랜덤 읽기시에도 캐쉬되어 사용 . 마스터 서버와 네트워크 부하를 줄임 . 메타 데이터 캐쉬 가능 . 용량의 낭비가 생길 수 있다 .

Chunk server 들의 위치를 물음

Chunk server 들에게 데이터 전달

Secondary Replication 복제 확인

Client 에게 성공했다고 알림

한 파일이 여러 서버에 Chunk 로 분산 . 여러 서버로 부터 전송되어 빠르게 받음 . 한 Chunk 가 3 개의 서버에 분산되어 저장 . 오프라인 서버가 발생시 해결 . 손상된 청크 발견시 해결 . Chunk 복제시 동기화 백업 알고리즘의 단순화 . 모든 서버가 기록이 완료되어야 함 -> 성능저하

이름영역 관리 디렉토리 별로 자료 구조를 가지지 않음 . 파일이나 디렉토리의 별명을 사용안함 . 하드 링크 심볼링 링크 논리적으로 전체 경로이름을 연결 .

락킹 /home/user 가 /save/user 의 스냅샷 /home/user/foo 를 만들 경우 home, save: read lock / user: write lock 부모 디렉토리에는 read lock 만 필요 . 여러 파일 생성시 write lock 에 의해 대기 . read lock 은 삭제 , 변경 , 스냅샷을 막음 . /home /user / foo /save /user / foo

쓰레기 수집 마스터 서버에 삭제 시간 정보를 기록 숨겨진 이름으로 변경 . 이름을 변경하면 파일이 복구될 수 있음 . 3 일 이상된 히든 파일을 마스터에서 삭제 . 마스터가 모르는 청크는 “쓰레기” 쓰레기 수집기가 쓰레기를 제거 . 단순하고 신뢰할 수 있음 . 배치 작업으로 효과적 .

상한 복사본 발견 청크 서버가 작동하지 않는 동안 해당 서버의 청크는 변화하지 않음 . 마스터는 청크의 버전 번호를 붙여서 상한 복사본을 관리 . 청크 번호가 맞지 않은 청크 서버를 재시작시켜서 관리 .

장애 허용성 빠른 복구 마스터와 청크서버는 상태를 저장하고 복구하도록 설계됨 . 청크 복제 각 청크는 다른 장비에 복제되어 보호됨 . 마스터 복제 마스터의 로그와 체크포인트를 여러 서버에 복제하여 신뢰성을 향상 .

보안은 어떻게 되나요 ? 논문에 언급이 없음 . 클론 Hadoop 은 보안 문제 있음 . IP 와 PORT 를 알면 접근 가능

MapReduce: 병렬처리도 가능해요 .

FUSE: 파일 시스템 대체

GFS 는 구글만 쓰나요 ? Open source GFS Clone

Coda: GFS 와 비슷한 파일 시스템 - 캐쉬를 통해 읽는 속도 향상 - 볼륨 단위의 복제

Gfs Kyu

More Related Content

What's hot

Viewers also liked

Similar to Gfs Kyu

Gfs Kyu