Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Google3

598 views

Published on

Published in: Technology, Business
  • Login to see the comments

  • Be the first to like this

Google3

  1. 1. Google을 지탱하는 기술 Google의 분산 스토리지 - GFS samantha
  2. 2. GFS(Google File System) 구글의 독자적인 분산파일시스템  다수의 컴퓨터를 조합해 거대한 스토리지(외  부기억장치)를 만들어내는 기술 네트워크를 통해 파일을 읽고 쓰기 위한  시스템 장점  ◦ 큰 용량 ◦ 효율적인 데이터 전송
  3. 3. 데이터 전송을 위한 특화 설계 장애 대책  ◦ 고장 발생을 전제로 하여 시스템 설계 ◦ GFS에서 파일은 항상 백업된 상태 대용량 파일  ◦ 데이터를 대량으로 기록하고 읽어 내는 데이 터 송수신에 활용할 수 있도록 특화 설계 cue 사용  ◦ 파일을 데이터의 cue로서 사용 ◦ GFS에서 파일이란 데이터의 통로
  4. 4. GFS의 기능 작성 삭제 열기 닫기 레코드 추가 스냅샷 읽기 쓰기 – 파일 끝에 – 파일 복사 데이터 추가
  5. 5. GFS의 전체모습 Master  ◦ GFS전체의 상태를 관리하고 통제하는 중앙서버 Chunk  ◦ GFS상의 파일 ◦ 64MB의 하나의 블록 ◦ 각각의 Chunk는 보통 3개의 Chunk Server 에 복제되어 보관 Chunk Server  ◦ Master가 관리하는 다수의 서버 ◦ 하드디스크 입출력 담당 Client  ◦ GFS를 이용하여 파일을 읽고 쓰는 애플리케이션
  6. 6. GFS의 전체모습 클라이언트 마스터 청크 서버 청크 서버 청크 서버 파일 청크 청크 청크 …
  7. 7. 쓰기 Primary  ◦ 마스터가 청크 서버 중에서 통합하는 역할을 할 것으로 결정한 하나의 청크 서버 Secondary – Primary외의 나머지  클라이언트에게 어느 서버가 프라이머리인지  전달되면 이후에 기록이 완료될 때까지 이 프 라이머리가 기록 과정 통제 청크 서버가 도중에 고장이 나거나 하드디스크  장애로 기록에 실패할지도 모르기 때문에 대책 마련 필수
  8. 8. 레코드 추가 파일의 끝에 한 묶음의 데이터를 효율적  으로 추가하도록 설계 Record  ◦ 한 번에 읽고 쓰는 데이터의 단위 ◦ 도중에 바뀌지 않고 확실하게 기록되어야 한 다 Atomic조작  ◦ 하나의 처리가 마지막까지 중단되지 않고 단 번에 이루어지는 것
  9. 9. GFS에서 일어날 수 있는 장애 대 책 청크의 장애 대책  ◦ 시스템의 신뢰성을 높이기 위해 청크를 보존할 때 체크섬을 계산하여 청크의 내용과 기록 ◦ Checksum  데이터의 무결성을 검증하기 위해 만들어진 값.  동일한 데이터라면 반드시 동일한 체크섬 값이 만들어져 야 한다.  읽을 때와 쓸 때의 데이터가 다르다면 체크섬 대조에 실패 하여 에러가 발생한 것으로 간주 청크 서버의 장애 대책  ◦ 청크 서버와의 통신이 완전히 끊기면 마스터는 그 것을 관리 대상에서 제외. ◦ 청크는 새로운 서버에게 다시 할당되어 청크복사 본의 개수는 동일하게 유지
  10. 10. GFS에서 일어날 수 있는 장애 대 책 마스터 장애 대책  ◦ 마스터가 정지하면 GFS전체가 제 기능을 하지 못함 ◦ 관리 정보 갱신시 Operation Log에 기록 ◦ 마스터가 정지해도 Operation Log에서 읽어와 고장나기 전 상태로 되돌릴 수 있다

×