Lecture 3: GFS

Why BIG storage so hard?

high performance => sharding (분산처리) => fault tolerance 필요

sharding causes faults => fault tolerance 필요
tolerance => replication
replication => Inconsistency
consistency => low performance
* strong consistency : 서버 하나와 통신하는것처럼 보이게 하는것

Bad replication design

bad design

c1 -> s1,s2에 write request
c2 -> s1,s2에 write request
consistency 보장 X

GFS

장점

- big & fast

- sharding : throughput 늘리고 한 파일이 한 디스크보다 더 클 수 있게 됨
 구글 내부에서 모든 사람이 쓰고 읽을 수 있는 시스템 (global)
- automatic recovery
- single data center (customer 서비스가 아님)

단점
- Internal use : 왜 internal만? master 한개 -> ram 감당불가 / master failure recovery too long
- Big batch data를 못표로 하여 많은 사용자를 처리하기 위한 구조가 아님
 

General Structure

- 1 master server, hundreds of chunk servers

- big files split into 64 MB chunks

- chunk server에 클라이언트가 직접 통신을 하여 일기/쓰기 수행 => huge parallel throughput
  if lots of clients access different chunks, huge parallel throughput

 

chunk server : 실제 데이터 저장
master server : 파일이 어느 chunk server에 있는 지 알려줌 (두 개의 테이블로 구성)
 1. file name to array of chunk handles (not volitile)
 2. handle ->

   - list of chunk servers (volatile : 처음 기동할 때 chunk 서버에게 물어봐서 가져)

   - version of chunk server number (every chunk has a version number, not volitile )

   - which is primary(volatile)

   - lease expiration(volatile) : 60초까지만 primary 서버로 동작 가능

      * (split brain problem) 만약 primary가 fail 되고 secondary가 primary가 되면 primary가 2개 생성되어 이를 방지해준다.

 LOG , checkpoint : master 상태를 디스크에 저장하기 위한 용도, 체크포인트 기준으로 log가 쌓인다 (주기적으로 업데이트 됨), server down시 두 가지 정보로 다시 master 만듬

 

READ

1. name과 offset을 master에 전송
2. Master : chunk handler, list of servers 반환
3. client가 chunk server로 요청

Write

write는 GFS에서 appending data를 의미한다  (=> 맨마지막 chunk가 무엇인지 알아야한다)

1. Client가 master에게 write 요청

2. master가 동시성 조절하여 write 순서를 정한다
3. if) no primary
    find up-to-date replicas (version number를 보고 확인)
    pick that server primary and others to be secondary (60초 뒤에는 primary 바꿔야함,(lease))
    increment version number (master가 primary가 없다고 판단될때만 version number 높임)
    tells primary and secondary the version number
    Master writes version number to disk 

     * 만약 리부팅 시 v# 보다 더 높은 chunk server가 있다고 하면 master에 crash가 있다고 가정하고 master version # update

4. Primary picks offset

5. Primary가 쓰기 수행
6. Primary가 모든 replicas에 쓰라고 지시
7. if) all secondary "yes" => "success" to client
    else) "no" to client --- 이후 client가 다시 쓰기 요청을 해야한다

 

Inconsistency 발생하는 예제

Inconsistency 발생하는 예제

1. Client1 : A write : 성공

2. Client2 : B write : secondary2에서 실패

3. Client3 : C write : 성공

4. Client2 : B write(retry) : 성공

5. Client4 : D write : Secondary1에서 실패

6. Client4 connection lost

 

>> detect duplicate request
>> secondary한테 작업을 보내면 error를 보내지 않고 무조건 처리하게 한다 / 만약 disk damage가 있다면 secondary에서 제거한다