HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH

VIỄN THÔNG (PTIT)

BÁO CÁO BÀI TẬP LỚN

Môn học ”Hệ điều hành”

Chủ đề

TÌM HIỂU VỀ HỆ THỐNG FILE (Google File System)

Giới thiệu, kiến trúc, các thành phần, cơ chế hoạt động, cài đặt, ưu
và nhược điểm.

Nhóm 7 Giảng viên: Hoàng Xuân Dậu

Trần Đức Nguyên

Nguyễn Quang Phúc
Trần Đức Quân
Vũ Hồng Quân
Mục lục

I. Giới thiệu: .......................................................................................................................3

II. Nội dung: .......................................................................................................................4

1. Kiến trúc: ..................................................................................................................4
1.1 Máy chủ master: .............................................................................................4
1.2 Chunk server (máy chủ chunk): .........................................................................5
1.3 Clients Machines: ...............................................................................................6
2. Các thành phần: ...........................................................................................................7
2.1 Giao diện (Interface): .....................................................................................7
2.2 Chunk files: ........................................................................................................7
2.3 Siêu dữ liệu (metadata):..................................................................................8
3. Cơ chế hoạt động ......................................................................................................9
3.1. Lease và Mutation .............................................................................................9
3.2. Interfaces .........................................................................................................10
3.3. Replication Placement: ....................................................................................12
3.4. Quản lý namespace và locking ........................................................................12
3.5. Fault Tolerance ................................................................................................12
3.6 Garbage Collection ..........................................................................................14
4. Cài đặt ....................................................................................................................14
4.1. Chuẩn bị máy chủ và hệ điều hành .................................................................14
4.2. Tải và cài đặt GFS ...........................................................................................15
4.3. Cấu hình GFS ..................................................................................................15
4.4. Khởi động dịch vụ ...........................................................................................15
4.5. Kiểm tra và giám sát........................................................................................15
5. Ưu và nhược điểm .....................................................................................................16
5.1 Ưu điểm ............................................................................................................16
5.2 Nhược điểm ......................................................................................................16

III. Kết luận: .....................................................................................................................18

IV. Tài liệu tham khảo: ...................................................................................................19

2
I. Giới thiệu:

Google File System (GFS) là một hệ thống mở rộng phân phối tập tin (DFS) tạo ra
bởi Google Inc và phát triển để phù hợp với dữ liệu mở rộng của Google yêu cầu chế biến.
GFS cung cấp khả năng chịu lỗi, độ tin cậy, khả năng mở rộng, tính sẵn có và hiệu suất
với các mạng lớn và các nút được kết nối. GFS được tạo thành từ nhiều hệ thống lưu trữ
được xây dựng từ các thành phần phần cứng hàng hóa giá rẻ. Nó được tối ưu hóa để chứa
dữ liệu sử dụng và lưu trữ nhu cầu khác nhau của Google, chẳng hạn như công cụ tìm
kiếm của nó, mà tạo ra một lượng lớn dữ liệu phải được lưu trữ.

Có thể nói GFS là xương sống cho hầu hết mọi dịch vụ mà Google cung cấp hiện
nay. Hệ thống cơ sở dữ liệu người dùng đồ sộ, các dịch vụ điện toán đám mây và lượng dữ
liệu khổng lồ phục vụ việc tìm kiếm, tất cả đều được quản lý dựa trên GFS. Ví dụ như các
dịch vụ lưu trữ như Drive, Mail, Google Photos, … và còn vô số dịch vụ khác đều được
dựa trên nền tảng GFS.

Tuy rằng GFS là một sản phẩm không được công bố ra cộng đồng, chỉ được độc
quyền và duy nhất Google sử dụng nhưng nhờ có sự chia sẻ của kỹ sư trưởng dự án mà
trong bài báo cáo này sẽ tìm hiểu về kiến trúc, các thành phần, cách thức hoạt động cũng
như ưu nhược điểm của hệ thống GFS. Dựa vào điều gì mà hệ thống GFS trở lên to lớn vĩ
đại và có thể chứa được hàng trăm, hàng nghìn, hàng tỷ dữ liệu nhưng vẫn ổn định và luôn
sẵn sàng mở rộng. Trước khi đến với nội dung chính một thông tin cần biết về phiên bản
mới nhất hiện nay của GFS có tên chính thức là Colossus.

3
II. Nội dung:
1. Kiến trúc:

Hình 1: Kiến trúc của GFS

Một cụm GFS bao gồm một máy chủ master duy nhất và nhiều máy chủ chunk, và
được truy cập bởi nhiều khách hàng, như được thể hiện trong Hình 1. Mỗi thành phần này
thường là một máy tính Linux thông thường chạy một quy trình máy chủ ở mức người
dùng. Việc chạy cả máy chủ chunk và khách hàng trên cùng một máy tính rất dễ dàng,
miễn là tài nguyên máy tính cho phép và sự không đáng tin cậy hơn do việc chạy mã ứng
dụng có thể gây ra không quá đáng kể.

1.1 Máy chủ master:

Việc có một máy chủ master duy nhất đáng kể đơn giản hóa thiết kế của GFS và
cho phép máy chủ master thực hiện việc định vị chunk và quyết định nhân bản chunk phức
tạp bằng cách sử dụng kiến thức toàn cầu. Tuy nhiên, các nhà phát triển phải giới hạn sự
tham gia của máy chủ master trong việc đọc và ghi để tránh trở thành điểm hẹp. Khách
hàng không bao giờ đọc và ghi dữ liệu tệp qua máy chủ này. Thay vào đó, khách hàng yêu
cầu máy chủ master xác định các máy chủ chunk mà nó nên liên hệ. Khách hàng lưu cache
thông tin này trong một khoảng thời gian giới hạn và tương tác trực tiếp với các máy chủ
chunk cho nhiều hoạt động tiếp theo.

4
 Để giải thích quá trình tương tác cho một hoạt động đọc một cách đơn giản với
tham chiếu ở Hình 1. Đầu tiên, sử dụng kích thước chunk cố định, khách hàng chuyển đổi
tên tệp và vị trí byte được chỉ định bởi ứng dụng thành một chỉ số chunk trong tệp. Sau đó,
nó gửi yêu cầu chứa tên tệp và chỉ số chunk tới máy chủ master. Máy chủ master trả lời
với chunk handle tương ứng và vị trí của các bản sao. Khách hàng lưu cache thông tin này
bằng cách sử dụng tên tệp và chỉ số chunk làm khóa. Khách hàng sau đó gửi yêu cầu tới
một trong các bản sao, có thể là bản sao gần nhất. Yêu cầu chỉ định chunk handle và phạm
vi byte trong chunk đó. Việc đọc tiếp theo của cùng một chunk không đòi hỏi thêm tương
tác giữa khách hàng và máy chủ master cho đến khi thông tin cache hết hạn hoặc tệp được
mở lại. Thực tế, khách hàng thường yêu cầu nhiều chunk trong cùng một yêu cầu và máy
chủ này cũng có thể bao gồm thông tin cho các chunk ngay sau các chunk được yêu cầu.
Thông tin bổ sung này giúp tránh một số tương tác khách hàng-master trong tương lai mà
gần như không tốn thêm chi phí.

1.2 Chunk server (máy chủ chunk):

Chunk server là một phần quan trọng trong hệ thống GFS (Google File System),
đóng vai trò lưu trữ và quản lý các chunk (phân đoạn) của dữ liệu. Trong GFS, một tệp lớn
được chia thành nhiều chunk nhỏ hơn, mỗi chunk có kích thước cố định. Chunk server
chịu trách nhiệm lưu trữ và cung cấp dữ liệu cho các chunk này.

Các tệp được chia thành các chunk có kích thước cố định. Mỗi chunk được xác
định bằng một chuỗi 64 bit duy nhất và không thể thay đổi được gọi là "chunk handle"
được máy chủ master gán cho chunk khi chunk được tạo. Các máy chủ chunk lưu trữ các
chunk trên đĩa cục bộ dưới dạng các tệp Linux và đọc hoặc ghi dữ liệu chunk được chỉ
định bằng chunk handle và phạm vi byte. Để đảm bảo tính tin cậy, mỗi chunk được nhân
bản trên nhiều máy chủ chunk.

Một hoạt động quan trọng của chunk server là việc cấp phát, ghi và đọc dữ liệu.
Khi một client muốn ghi dữ liệu vào GFS, nó trực tiếp giao tiếp với chunk server để thực
hiện việc ghi dữ liệu vào chunk tương ứng. Tương tự, khi client muốn đọc dữ liệu, nó liên
hệ trực tiếp với chunk server để nhận dữ liệu từ chunk tương ứng.
5
Một tính năng quan trọng của chunk server là khả năng xử lý và phục hồi lỗi. GFS sử dụng
các bản sao dữ liệu (replicas) để đảm bảo sự an toàn và sẵn sàng của dữ liệu. Mỗi chunk
được nhân bản thành nhiều bản sao và phân bố trên các chunk server khác nhau. Khi một
chunk server gặp sự cố, các bản sao trên các chunk server khác có thể được sử dụng để
phục hồi dữ liệu và duy trì tính sẵn sàng của hệ thống.

Ngoài ra, chunk server cũng thực hiện các hoạt động quản lý như cập nhật thông tin
metadata về chunk, báo cáo trạng thái và sức khỏe cho master server, và thực hiện các
thao tác như sao chép, di chuyển hoặc xóa chunk theo yêu cầu của master server.

Với việc sử dụng nhiều chunk servers, GFS đạt được khả năng mở rộng lớn hơn,
khả năng chịu lỗi và khả năng xử lý dữ liệu đồng nhất song song. Chunk server đóng vai
trò quan trọng trong việc tạo ra một hệ thống tệp tin phân tán mạnh mẽ và tin cậy.

1.3 Clients Machines:

Clients Machines là các máy tính khách sử dụng dịch vụ của GFS để truy cập, đọc
và ghi dữ liệu từ GFS. Chúng làm nhiệm vụ tương tác với hệ thống tệp GFS và gửi yêu
cầu đến các máy chủ chunk (chunk servers) để truy xuất dữ liệu.

Đầu tiên, hoạt động quan trọng đó là giao tiếp với máy chủ chunk. Client machines
gửi yêu cầu đến các máy chủ chunk để truy xuất dữ liệu. Khi có yêu cầu đọc, client
machines gửi yêu cầu đến máy chủ chunk chứa phân đoạn tương ứng và nhận dữ liệu trả
về. Khi có yêu cầu ghi, client machines gửi yêu cầu đến máy chủ chunk để cập nhật dữ
liệu trong phân đoạn.

Một tính năng khác đó là quản lý bộ nhớ cache. Client machines duy trì một bộ nhớ
cache (memory cache) để lưu trữ các phân đoạn dữ liệu đã được truy xuất gần đây. Việc
lưu trữ dữ liệu trong bộ nhớ cache giúp giảm thời gian truy xuất dữ liệu khi có yêu cầu đọc
tiếp theo cùng từ phân đoạn đó.

Tiếp theo, Clients machines được trang bị thêm chức năng xử lý đồng thời đa tác
vụ. Client machines có khả năng xử lý đồng thời nhiều yêu cầu từ nhiều người dùng khác
nhau. Điều này cho phép nhiều yêu cầu đọc/ghi được xử lý song song trên các máy chủ
chunk khác nhau, tăng hiệu suất và khả năng mở rộng của hệ thống.

Cuối cùng một chức năng không thể thiếu chúng có thể linh hoạt xử lý lỗi và khôi
phục dữ liệu. Client machines có khả năng xử lý lỗi và khôi phục dữ liệu trong trường hợp
xảy ra sự cố. Khi một máy chủ chunk gặp sự cố, client machines có thể yêu cầu dữ liệu từ
các máy chủ chunk khác để đảm bảo tính sẵn sàng và nhất quán của dữ liệu.

6
2. Các thành phần:
2.1 Giao diện (Interface):
GFS cung cấp một giao diện hệ thống tệp tin quen thuộc, mặc dù nó không thực
hiện một API tiêu chuẩn như POSIX. Các tệp tin được tổ chức theo cấu trúc cây thư mục
và được xác định bằng các tên đường dẫn. GFS hỗ trợ các hoạt động thông thường để tạo,
xóa, mở, đóng, đọc và ghi tệp tin.

Hơn nữa, GFS cung cấp các hoạt động snapshot và record append. Snapshot tạo ra
một bản sao của một tệp tin hoặc cây thư mục với chi phí thấp. Record append cho phép
nhiều khách hàng cùng ghi thêm dữ liệu vào cùng một tệp tin một cách đồng thời, đồng
thời đảm bảo tính nguyên tử của mỗi ghi thêm của từng khách hàng. Điều này rất hữu ích
để thực hiện việc kết hợp đa hướng và hàng đợi sản xuất-tiêu thụ mà nhiều khách hàng có
thể ghi thêm dữ liệu vào mà không cần khóa mục bổ sung. GFS thấy rằng các loại tệp tin
này rất quan trọng trong việc xây dựng các ứng dụng phân tán lớn.

2.2 Chunk files:

GFS phân chia mỗi file thành các đơn vị nhỏ hơn được gọi là file chunk. Mỗi file
chunk có kích thước cố định (thường là 64 MB). Các file chunk được lưu trữ và quản lý
bởi worker servers. Phân chia dữ liệu thành các chunk cho phép GFS xử lý dữ liệu lớn một
cách hiệu quả và tăng khả năng mở rộng của hệ thống.

2.2.1 Kích thước của chunk:

Kích thước của các chunk là một trong những tham số thiết kế quan trọng. Nhà phát
triển đã chọn kích thước là 64MB, lớn hơn nhiều so với kích thước khối thông thường của
hệ thống tệp tin. Mỗi bản sao chunk được lưu trữ dưới dạng một tệp Linux thuần túy trên
một máy chủ chunk và chỉ mở rộng khi cần thiết. Phương pháp cấp phát không gian lười
biếng (lazy space allocation) giúp tránh lãng phí không gian do sự tách rời nội bộ, có thể là
một trong những đối tác đáng kể nhất đối với kích thước chunk lớn như vậy.

Kích thước chunk lớn mang lại một số lợi ích quan trọng. Thứ nhất, nó giảm nhu
cầu tương tác của khách hàng với master vì việc đọc và ghi trên cùng một chunk chỉ đòi
hỏi một yêu cầu ban đầu tới master để lấy thông tin vị trí của chunk. Sự giảm này đặc biệt
quan trọng đối với khối lượng công việc của GFS vì các ứng dụng chủ yếu đọc và ghi các
tệp tin lớn theo trình tự. Ngay cả đối với việc đọc ngẫu nhiên nhỏ, khách hàng có thể dễ
dàng lưu cache thông tin vị trí chunk cho một tập dữ liệu làm việc đa TB. Thứ hai, vì trên
một chunk lớn, khách hàng có khả năng thực hiện nhiều hoạt động trên một chunk cụ thể,
nên nó có thể giảm tải mạng bằng cách duy trì một kết nối TCP liên tục với máy chủ
chunk trong một khoảng thời gian kéo dài. Thứ ba, nó giảm kích thước của siêu dữ liệu
(metadata) được lưu trữ trên master. Điều này cho phép GFS giữ siêu dữ liệu trong bộ
nhớ, từ đó mang lại những lợi ích khác.

Tuy nhiên, kích thước chunk lớn, ngay cả với phương pháp cấp phát không gian
lười biếng, cũng có nhược điểm của nó. Một tệp tin nhỏ bao gồm một số chunk nhỏ, có thể
7
chỉ là một chunk. Các máy chủ chunk lưu trữ những chunk đó có thể trở thành điểm nóng
nếu có nhiều khách hàng truy cập vào cùng một tệp tin. Trong thực tế, điểm nóng không
phải là vấn đề lớn vì các ứng dụng của GFS chủ yếu đọc các tệp tin lớn gồm nhiều chunk
theo trình tự.

Tuy nhiên, điểm nóng đã xảy ra khi GFS được sử dụng lần đầu bởi hệ thống hàng
đợi xử lý hàng loạt: một tệp thực thi được viết vào GFS dưới dạng một tệp tin chỉ có một
chunk và sau đó được khởi động trên hàng trăm máy cùng một lúc. Các máy chủ chunk
lưu trữ tệp thực thi này đã bị quá tải bởi hàng trăm yêu cầu đồng thời. Các nhà phát triển
đã khắc phục vấn đề này bằng cách lưu trữ các tệp thực thi như vậy với một yếu tố nhân
bản cao hơn và làm cho hệ thống hàng đợi xử lý hàng loạt khởi động các ứng dụng vào
các thời điểm khác nhau. Một giải pháp tiềm năng dài hạn là cho phép khách hàng đọc dữ
liệu từ các khách hàng khác trong những tình huống như vậy.

2.2.2. Vị trí của các chunk:

Master không duy trì một bản ghi liên tục về các máy chủ chunk nào có bản sao của
một chunk cụ thể. Nó chỉ yêu cầu thông tin này từ các máy chủ chunk khi khởi động.
Master có thể cập nhật thông tin này sau đó bởi vì nó kiểm soát việc đặt chunk và giám sát
trạng thái của các máy chủ chunk thông qua các tin nhắn HeartBeat định kỳ.

Ban đầu, GFS đã cố gắng duy trì thông tin vị trí chunk một cách liên tục trên
master, nhưng các nhà phát triển quyết định rằng việc yêu cầu dữ liệu này từ các máy chủ
chunk khi khởi động và định kỳ sau đó đơn giản hơn nhiều. Điều này loại bỏ vấn đề của
việc đồng bộ master và các máy chủ chunk khi các máy chủ chunk tham gia và rời khỏi
cụm, thay đổi tên, gặp sự cố, khởi động lại và các sự kiện tương tự. Trong một cụm máy
chủ với hàng trăm máy chủ, những sự kiện này xảy ra quá thường xuyên.

Một cách khác để hiểu quyết định thiết kế này là nhận ra rằng một máy chủ chunk
có quyền cuối cùng quyết định xem nó có hoặc không có các chunk trên đĩa của mình.
Không có ý nghĩa gì trong việc cố gắng duy trì một cái nhìn nhất quán về thông tin này
trên masstel vì lỗi trên máy chủ chunk có thể làm cho các chunk biến mất một cách tự phát
(ví dụ: ổ đĩa có thể hỏng và bị tắt) hoặc một nhà điều hành có thể đổi tên một máy chủ
chunk.

2.3 Siêu dữ liệu (metadata):

Metadata là thông tin quản lý về các file và dữ liệu trong GFS. Nó bao gồm các
thuộc tính của file (như tên, kích thước, thời gian tạo và quyền truy cập) cũng như vị trí
của các replicas và các thông tin khác liên quan đến quản lý dữ liệu.
2.3.1 Cấu trúc dữ liệu trong bộ nhớ:
Vì siêu dữ liệu được lưu trữ trong bộ nhớ, các hoạt động của master được thực hiện
nhanh chóng. Hơn nữa, việc quét định kỳ toàn bộ trạng thái của master trong nền rất dễ
dàng và hiệu quả. Việc quét định kỳ này được sử dụng để thực hiện việc thu gom rác

8
chunk, sao chép lại chunk khi máy chủ chunk gặp sự cố, và di chuyển chunk để cân bằng
tải và sử dụng không gian đĩa trên các máy chủ chunk.

Một vấn đề tiềm năng cho phương pháp chỉ sử dụng bộ nhớ này là số lượng chunk
và do đó dung lượng của toàn hệ thống bị giới hạn bởi bộ nhớ của master. Tuy nhiên, điều
này không phải là một hạn chế quan trọng trong thực tế. Master duy trì ít hơn 64 byte siêu
dữ liệu cho mỗi chunk 64 MB. Hầu hết các chunk đều đầy vì hầu hết các tệp tin chứa
nhiều chunk, chỉ có chunk cuối cùng có thể bị lấp đầy một phần. Tương tự, dữ liệu không
gian tên tệp tin thường chỉ yêu cầu ít hơn 64 byte cho mỗi tệp tin vì nó lưu trữ tên tệp tin
một cách gọn gàng bằng cách sử dụng nén tiền tố.

2.3.2 Cấu trúc dữ liệu trong nhật ký hoạt động

Bản ghi hoạt động chứa một lịch sử các thay đổi quan trọng về siêu dữ liệu. Nó là
trung tâm của GFS. Không chỉ là một bản ghi cố định duy nhất về siêu dữ liệu, nó còn
đóng vai trò như một dòng thời gian logic xác định thứ tự các hoạt động đồng thời. Các
tệp tin và chunk, cũng như các phiên bản của chúng, đều được định danh duy nhất và vĩnh
viễn bằng các thời gian logic khi chúng được tạo ra.

Vì bản ghi hoạt động là rất quan trọng, chúng ta phải lưu trữ nó một cách đáng tin
cậy và không làm cho các thay đổi trở nên hiển thị cho khách hàng cho đến khi các thay
đổi về siêu dữ liệu trở nên cố định. Nếu không, chúng ta sẽ mất hệ thống tệp tin hoàn toàn
hoặc các hoạt động gần đây của khách hàng ngay cả khi các chunk tồn tại. Do đó, chúng ta
sao chép nó trên nhiều máy từ xa và phản hồi cho một hoạt động của khách hàng chỉ sau
khi xả bỏ bản ghi nhật ký tương ứng vào đĩa cục bộ và từ xa. Master sẽ gom nhóm một số
bản ghi nhật ký lại trước khi xả bỏ, từ đó giảm ảnh hưởng của việc xả bỏ và sao chép đến
hiệu suất tổng thể của hệ thống.

3. Cơ chế hoạt động

Sau khi đã biết được các thành phần cũng như kiến của của Google System File ta
cũng tìm hiểu cách thức hoạt động, các cơ chế hoạt động, bảo toàn, lưu trữ dữ liệu bên
trong GFS.
3.1. Lease và Mutation
Hai thao tác này kết hợp với nhau nhằm đảm bảo cho dữ liệu bên trong GFS luôn
được an toàn và truy xuất một cách nhanh chóng.

3.1.1. Mutation
Cơ chế mutation thay đổi nội dung file hoặc metadata của một chunk như phương
thức write hoặc append record. Các mutations sẽ được thực hiện cả trên các bản sao của
chunks.

3.1.2. Leases
9
 Leases được thiết kế nhằm giảm sự tham gia của master vào các thao tác trên file.
Master sẽ chọn một trong các replica và replica đó trở thành primary replica. Primary
replica thay thế master tương tác với client khi client yêu cầu tương tác. Do đó GFS sử
dụng leases duy trì thứ tự đột biến nhất quán trên tất cả replica.

3.2. Interfaces
Phía trên đã giới thiệu sơ qua về các interface trong GFS giờ đi sâu hơn vào 2
interface tiêu biểu cung cấp phương thức Read và Write. Ngoài ra GFS được đặc biệt tích
hợp thêm 2 cơ chế là Snapshot và Record Append.

3.2.1. Read

Hình 2: Trình tự phương thức Read

Phương thức Read thực hiện được thực hiện khi ứng dụng tạo một yêu cầu đọc và
gửi nó đến GFS client. GFS client phiên dịch yêu cầu và gửi nó đến Master. Master phản
hồi bằng cách cung cấp mã xử lý chunk (chunk handle) và vị trí của một bản sao chunk
cho GFS client. Sau đó, GFS client sử dụng mã xử lý chunk và thông tin vị trí này để gửi
yêu cầu đến chunk server. Chunk server tiến hành gửi dữ liệu đến cho GFS client, và cuối
cùng, GFS client chuyển dữ liệu này đến ứng dụng của mình.

3.2.2. Write

Hình 3: Trình tự của phương thức Write

Phương thức Write trong GFS bao gồm các bước sau: Ứng dụng tạo một yêu cầu
write và gửi nó đến GFS client. GFS client dịch yêu cầu và gửi nó đến master. Master
phản hồi bằng cách cung cấp mã xử lý chunk (chunk handle) và vị trí của tất cả các bản
sao chunk cho GFS client. Sau đó, client chuyển dữ liệu cần được ghi đến tất cả các chunk
server chứa các bản sao. Dữ liệu này được lưu trữ trong bộ đệm nội bộ (internal buffer)
của các chunk server. Tiếp theo, client gửi yêu cầu ghi dữ liệu đến primary replica.

10
Primary replica tiến hành chọn ra thứ tự tuần tự của các khối dữ liệu trong bộ đệm của nó
và ghi chúng vào chunk theo thứ tự đó.

Sau khi ghi xong, primary replica gửi thứ tự này cho các secondary replica và yêu cầu
chúng thực hiện thao tác ghi theo thứ tự đã được nhận.

3.2.3. Snapshot
Snapshot tạo ra một bản sao của một tệp tin hoặc cây thư mục (gọi là "nguồn") gần
như ngay lập tức, đồng thời giảm thiểu bất kỳ gián đoạn nào của các thay đổi đang diễn ra.
Người dùng của GFS sử dụng nó để nhanh chóng tạo ra bản sao của các tập dữ liệu lớn (và
thường là các bản sao của các bản sao đó, đệ quy), hoặc để tạo điểm kiểm tra trạng thái
hiện tại trước khi thử nghiệm các thay đổi có thể được thực hiện hoặc hoàn tác một cách
dễ dàng sau này.

Tương tự như AFS, GFS sử dụng các kỹ thuật sao chép trên yêu cầu (copy-on-
write) tiêu chuẩn để thực hiện các bản sao. Khi Master nhận được yêu cầu Snapshot, trước
tiên nó thu hồi bất kỳ lease nào còn tồn tại trên các chunk trong các tệp tin sẽ được tạo
Snapshot. Điều này đảm bảo rằng bất kỳ ghi thêm nào sau này vào các chunk này sẽ yêu
cầu tương tác với master để tìm chủ sở hữu lease. Điều này sẽ cho phép master có cơ hội
tạo một bản sao mới của chunk trước tiên.

Sau khi các lease đã được thu hồi hoặc hết hạn, Master ghi lại hoạt động này vào
đĩa cục bộ. Sau đó, nó áp dụng bản ghi nhật ký này vào trạng thái trong bộ nhớ bằng cách
nhân bản (metadata)siêu dữ liệu cho tệp tin hoặc cây thư mục nguồn. Các tệp Snapshot
mới được tạo chỉ trỏ đến các chunk giống như các tệp tin nguồn.

3.2.4 Atomic Record Appends

GFS cung cấp một hoạt động ghi nối gắn phần tử được gọi là "record append".
Trong quá trình ghi thông thường, client chỉ định vị trí mà dữ liệu sẽ được ghi. Việc ghi
đồng thời vào cùng một vùng không tuân thủ tính tuần tự: vùng có thể chứa các đoạn dữ
liệu từ nhiều clients khác nhau. Tuy nhiên, trong record append, client chỉ định dữ liệu.
GFS nối dữ liệu vào tệp tin ít nhất một lần theo cách nguyên tử (tức là một chuỗi liên tục
các byte) tại một vị trí do GFS lựa chọn và trả lại vị trí đó cho client.

Record append được sử dụng rất nhiều bởi các ứng dụng phân tán của GFS, trong
đó nhiều clients trên các máy khác nhau ghi nối vào cùng một tệp tin đồng thời. Trong
lượng công việc của GFS, các tệp tin như vậy thường được sử dụng như hàng đợi sản
xuất/nhận dữ liệu từ nhiều nguồn khác nhau hoặc chứa kết quả hợp nhất từ nhiều khách
hàng khác nhau.

11
3.3. Replication Placement:
Một cụm GFS được phân tán rất rộng ở nhiều mức độ khác nhau. Thông thường, nó
có hàng trăm chunk servers phân tán trên nhiều rãnh của máy (machine racks). Những
chunk server này có thể được truy cập từ hàng trăm client từ cùng một hay nhiều racks
khác nhau. Giao tiếp giữa hai máy trên các racks khác nhau có thể đi qua một hoặc nhiều
switch mạng. Ngoài ra, băng thông vào hoặc ra khỏi một rack có thể nhỏ hơn tổng băng
thông của tất cả các máy trong khối đó. Phân tán đa cấp đặt ra thách thức trong việc phân
phối dữ liệu để mở rộng, tăng tính sẵn sàng và khả năng sẵn có.
Cơ chế Replication Placement hoạt động với 2 mục đích chính nhằm tối đa hóa độ
tin cậy và tính khả dụng của dữ liệu, đồng thời tối đa hóa việc sử dụng băng thông mạng.
Tuy nhiên điều đó là không đủ khi chỉ bảo vệ dữ liệu khi đĩa hoặc máy bị hỏng hoặc băng
thông đã bị sử dụng hết. Cơ chế cũng hỗ trợ trải rộng những bản sao của chunk khắp các
rack (tập hợp các chunkserver). Điều này nhằm đảm bảo một số bản sao của chunk sẽ tồn
tại và có sẵn ngay cả khi toàn bộ các rack gặp sự cố hoặc ngoại tuyến

3.4. Quản lý namespace và locking

Các thao tác của Master thường chiếm rất nhiều thời gian. Nhằm giúp cho các thao
tác của Master được diễn ra nhanh chóng, đông thời không trì hoãn lẫn nhau. GFS cho
phép nhiều thao tác diễn ra đồng thời và sử dụng các locks trên các vùng của namespace
nhằm đảm bảo tuần tự hóa.

Không giống như nhiều hệ thống tập tin truyền thống, GFS không có cấu trúc per-
directory mà mỗi thư mục liệt kê tất cả các tệp tin trong thư mục đó. Nó cũng không hỗ trợ
các bí danh cho cùng một tập tin hoặc thư mục. GFS biểu diễn một cách logic namespace
của nó dưới dạng ánh xạ bảng tra cứu với tên đường dẫn đầy đủ đến siêu dữ liệu. Với tính
năng nén tiền tố, bảng tra cứu này có thể được biểu diễn một cách hiệu quả trong bộ nhớ.
Mỗi nút trong cây namespace đều có read-write lock tương ứng.

Mỗi một thao tác của Master đều yêu cầu một chuỗi lock trước khi nó được khởi
chạy. Thông thường, nếu nó liên quan đến /d1/d2/.../dn/leaf, nó sẽ lấy khóa đọc trên tên
thư mục /d1, /d1/d2, ..., /d1/d2/.../dn, và read lock hoặc write lock trên tên đường dẫn đầy
đủ /d1/d2/.../dn/leaf. Lưu ý rằng leaf có thể là một tập tin hoặc thư mục tùy thuộc vào thao
tác.

3.5. Fault Tolerance

3.5.1. High availability (Khả năng sẵn sàng cao)
Trong số hàng trăm máy chủ trong cụm GFS, một số máy chủ có thể sẽ không sẵn
sàng trong một vài thời điểm tuy nhiên toàn bộ hệ thống sẽ luôn ở mức sẵn sàng cao nhất
khi được áp dụng 2 kỹ thuật đơn giản nhưng hiệu quả là phục hồi nhanh và sao lưu rộng.

Cả Master và các máy chủ chunk trong hệ thống đều được thiết kế để có khả năng
phục hồi trạng thái nhanh chóng chỉ trong vài giây bất kể sau khi bị kết thúc theo cách
12
nào. Khi một máy chủ chunk hoặc chunk bị lỗi, hệ thống có khả năng thay thế các bản sao
bị lỗi bằng các bản sao khác để đảm bảo rằng dữ liệu vẫn sẵn sàng cho các ứng dụng.

Bên trên có nói rằng mỗi chunk được sao chép trên nhiều máy chú chunk khác nhau
ở các racks khác nhau. Hệ thống thực hiện sao lưu mỗi chunk thành các bản sao trên các
máy chủ chunk khác nhau, mặc định sẽ là ba bản. Điều này đảm bảo rằng dữ liệu vẫn sẵn
sàng ngay cả khi một máy chủ chunk bị lỗi hoặc không thể truy cập.

Hệ thống đảm bảo các bản sao của máy chủ chính (master server) luôn sẵn sàng.
Khi máy chủ chính có vấn đề, nó có thể khởi động lại gần như ngay lập tức. Nếu máy chủ
Master gốc gặp sự cố không thể khởi động, hạ tầng GFS sẽ bắt đầu quy trình Master mới ở
một nơi khác với bản sao nhật ký hoạt động của máy chủ Master gốc có thể tiếp tục hoạt
động để duy trì tính nhất quán và khả năng sẵn sàng.

Bên cạnh đó hệ thống cũng có các Shadowmaster cung cấp quyền truy cập chỉ đọc
vào hệ thống tệp ngay cả khi máy chủ Master tắt. Chúng là các bản sao đối với máy chủ
Master gốc, nhưng có thể kém máy chủ Master gốc một chút, thường là một phần nhỏ của
giây. Chúng nâng cao tính sẵn sàng đọc cho các tệp không được biến đổi hoặc các ứng
dụng không quan trọng khi nhận kết quả đã cũ.

3.5.2. Data integrity (Tính toàn vẹn của dữ liệu)

Mỗi chunkserver sử dụng checksum để kiểm tra phát những đoạn dữ liệu lỗi. Một
cụm GFS thường có hàng nghìn đĩa trên hàng trăm máy, nó thường xuyên gặp phải lỗi ổ
đĩa gây hỏng hoặc mất dữ liệu trên cả hai đường dẫn đọc và ghi. Hệ thống có thể phục hồi
sau khi bị hỏng bằng cách sử dụng các bản sao chunk khác, nhưng sẽ là không thực tế nếu
phát hiện những đoạn dữ liệu lỗi bằng cách so sánh bản sao trên các máy chủ chunk. Hơn
nữa, theo cơ chế mutation của GFS đã được nhắc đến bên trên cũng như cơ chế atomic
append record, không đảm bảo các bản sao giống hệt nhau. Vì vậy, mỗi chunkserver phải
có tính xác minh độc lập và tính toàn vẹn của bản sao của chính nó bằng cách duy trì các
checksums.
Một chunk được chia thành các khối 64 KB. Mỗi chunk có checksum tương ứng 32
bit. Giống như các siêu dữ liệu khác, checksum được lưu giữ trong bộ nhớ và được lưu trữ
liên tục bằng cách ghi nhật ký, tách biệt khỏi dữ liệu người dùng.

Để đọc, chunkserver xác minh dữ liệu các khối ghi đè lên nhau trong phạm vi đọc
của checksum trước khi trả về bất kỳ dữ liệu nào cho người yêu cầu, cho dù là client hay
chunkserver khác. Do đó, chunkserver sẽ không lan truyền lỗi tới các máy khác. Nếu một
khối không khớp với khối checksum đã ghi, máy chủ chunk sẽ trả về lỗi cho người yêu
cầu và báo cáo sự không phù hợp cho master. Đáp lại, người yêu cầu sẽ đọc từ các bản sao
khác, trong khi bản chính sẽ sao chép chunk từ một bản sao khác. Sau khi có giá trị mới
bản sao đã sẵn sàng, máy chủ chính sẽ hướng dẫn máy chủ chunk rằng đã báo cáo sự
không phù hợp để xóa bản sao của nó.

13
 Checksum ít ảnh hưởng đến hiệu suất đọc có nhiều lý do. Vì hầu hết các lần yêu
cầu đọc đều kéo dài ít nhất một vài khối, chúng ta chỉ cần đọc và kiểm tra tổng tương đối
lượng nhỏ dữ liệu bổ sung để xác minh. GFS client code tiếp tục giảm lượng thời gian này
bằng cách cố gắng căn chỉnh số lần đọc gần với dung lượng tối đa của checksum. Hơn
nữa, việc tra cứu checksum và so sánh trên chunkserver được thực hiện mà không cần bất
kỳ tính toán I/O và tổng kiểm tra thường có thể bị chồng chéo với I/O.

3.6 Garbage Collection

Khi một tệp thông tin bị xóa bởi ứng dụng, máy chủ master ghi lại việc xóa ngay
lập tức giống như các thay đổi khác. Tuy nhiên, thay vì giải phóng tài nguyên ngay lập
tức, tệp thông tin chỉ được đổi tên thành một tên ẩn bao gồm thời gian xóa. Trong quá
trình quét định kỳ của máy chủ master trên không gian tên hệ thống tệp tin, nó sẽ loại bỏ
bất kỳ tệp tin ẩn nào nếu chúng tồn tại quá ba ngày (khoảng thời gian này có thể được cấu
hình). Cho đến khi đó, tệp tin vẫn có thể được đọc dưới tên mới đặc biệt và có thể được
khôi phục bằng cách đổi tên trở lại bình thường. Khi tệp tin ẩn được loại bỏ khỏi không
gian tên, siêu dữ liệu trong bộ nhớ của nó sẽ bị xóa. Điều này hiệu quả ngắt kết nối tệp tin
với tất cả các phân đoạn của nó.

Trong quá trình quét định kỳ tương tự trên không gian tên của các phân đoạn,
master xác định các phân đoạn đơn lẻ (tức là các phân đoạn không thể truy cập từ bất kỳ
tệp tin nào) và xóa siêu dữ liệu cho những phân đoạn đó. Trong một tin nhắn HeartBeat
được trao đổi định kỳ với master, mỗi chunkserver báo cáo một tập con của các phân đoạn
mà nó có, và máy chủ master trả lời với danh tính của tất cả các phân đoạn không còn tồn
tại trong siêu dữ liệu của master. Chunkserver có thể tự do xóa các bản sao của phân đoạn
không còn tồn tại này.

4. Cài đặt
Google File System (GFS) không phải là một sản phẩm công cộng, đây là sản phẩm
của riêng công ty Google và được sử dụng độc quyền cho công ty, do đó GFS không được
công bố hay phân phối dưới dạng mã nguồn mở do đó không có tài liệu chính thức nào
hướng dẫn về quá trình cài đặt GFS. Nhưng sẽ có một vài bước cơ bản khi cài đặt hệ thống
GFS giống với các hệ thống khác, các bước bên dưới đây chỉ là các bước cơ bản, việc cài
đặt một hệ thống lớn sẽ yêu cầu người có kinh nghiệm cũng như kiến thức chuyên sâu về
hạ tầng, cơ sở cũng như hệ thống mạng.

4.1. Chuẩn bị máy chủ và hệ điều hành

Để cài đặt một hệ thống như GFS chúng ta sẽ cần một máy chủ master và nhiều
máy chủ lưu trữ chia thành các rack, mỗi rack sẽ gồm nhiều chunkserver và trong mỗi
chunkserver sẽ gồm các file chunk.

Bên cạnh đó trên các chunkserver chúng ta cũng cần cài đặt một bản phân phối
thường là Linux nhằm quản lý các tài nguyên cũng như cấu hình các server
14
4.2. Tải và cài đặt GFS
Nhân viên sẽ lấy mã nguồn GFS cài đặt theo trình tự, thực hiện các bước biên dịch
sau đó cài đặt mã nguồn GFS trên mỗi máy chủ theo hướng dẫn cụ thể.

4.3. Cấu hình GFS

Đối với máy chủ Master, cần chỉ định cấu hình của hệ thống như cổng sử dụng,
cách thức quản lý dữ liệu như đã trình bày bên trên, các máy chủ kết nối đến, nguồn ra vào
của dữ liệu tất cả đều phụ thuộc vào yêu cầu của hệ thống GFS.

Đối với các máy chủ chunkserver lưu trữ, cần cấu hình để kết nối với máy chủ
Master và làm việc với toàn bộ hệ thống. Điều này cũng phụ thuộc vào yêu cầu của hệ
thống GFS.

4.4. Khởi động dịch vụ

Khởi động dịch vụ GFS trên máy chủ master đồng thời khởi động trên các máy chủ
chunkserver lưu trữ.

4.5. Kiểm tra và giám sát

Sử dụng công cụ kỹ thuật cũng như có nhân viên bên cạnh nhằm giám sát, đảm bảo
hệ thống GFS hoạt động đúng cách. Nếu xảy ra bất cứ sự cố gì sẽ kịp thời xử lý và khắc
phục

Cũng cần lập kế hoạch triển khai hệ thống giám sát nhằm theo dõi hiệu suất, sự ổn
định của hệ thống GFS nhằm đánh giá và nâng cấp cũng như bảo trì kịp thời.

15
5. Ưu và nhược điểm
5.1 Ưu điểm
Google File System (GFS) có khả năng truy cập cao là một trong những ưu điểm
quan trọng của nó. GFS sử dụng cơ chế phân tán và truy cập song song, cho phép nhiều
nguồn truy xuất dữ liệu đồng thời, giảm thời gian đợi và tăng hiệu suất. Bên cạnh đó, GFS
sử dụng bộ nhớ cache để lưu trữ dữ liệu đã truy cập gần đây, giúp tăng tốc độ truy cập. Hệ
thống cũng đảm bảo tính sẵn sàng và đồng bộ hóa dữ liệu qua việc sao chép và phân tán
dữ liệu trên nhiều máy chủ chunk. Khả năng mở rộng linh hoạt của GFS cũng đáng kể,
cho phép hệ thống tăng cường khả năng lưu trữ và xử lý khi lượng dữ liệu và số lượng
người dùng tăng lên. Tóm lại, GFS mang lại khả năng truy cập nhanh chóng, hiệu suất cao
và tính sẵn sàng cho người dùng.

Tốc độ xử lý cao là một trong những ưu điểm quan trọng của Google File System (GFS).
GFS được thiết kế để xử lý dữ liệu một cách hiệu quả và nhanh chóng. Với cơ chế phân
tán, truy cập song song và sử dụng bộ nhớ cache, GFS có khả năng xử lý đồng thời nhiều
yêu cầu truy cập, giảm thời gian đợi và tăng tốc độ truy xuất dữ liệu. Hơn nữa, khả năng
mở rộng linh hoạt của GFS cho phép hệ thống gia tăng khả năng xử lý và lưu trữ khi có
nhu cầu tăng cường. Tóm lại, tốc độ xử lý cao của GFS đảm bảo rằng người dùng có thể
truy cập và xử lý dữ liệu một cách nhanh chóng và hiệu quả.

Lưu trữ đáng tin cậy là một trong những ưu điểm quan trọng của Google File System
(GFS). GFS được thiết kế để đảm bảo tính sẵn sàng và đồng bộ hóa dữ liệu một cách tin
cậy. Dữ liệu trong GFS được sao chép và phân tán trên nhiều máy chủ chunk, đảm bảo
rằng ngay cả khi một máy chủ gặp sự cố, dữ liệu vẫn có thể được truy xuất từ các máy chủ
khác. Hơn nữa, việc phân tán dữ liệu giữa nhiều máy chủ chunk giúp giảm tải và đảm bảo
hiệu suất cao khi có nhiều người dùng truy cập đồng thời. Tính sẵn sàng và đồng bộ hóa
này đảm bảo rằng dữ liệu trong GFS luôn được bảo vệ và truy cập một cách tin cậy. Tóm
lại, lưu trữ đáng tin cậy của GFS đảm bảo rằng dữ liệu không bị mất và người dùng có thể
tin tưởng vào tính sẵn sàng và đồng bộ hóa của hệ thống.

5.2 Nhược điểm

Các tệp tin nhỏ không phù hợp với Google File System (GFS) là 1 nhược điểm vì
GFS được thiết kế để xử lý và lưu trữ các tệp tin có kích thước lớn. GFS chia nhỏ dữ liệu
thành các "chunk" có kích thước lớn, thường là hàng trăm megabyte. Khi tệp tin nhỏ được
lưu trữ trong GFS, chúng vẫn được xử lý và lưu trữ như một chunk, dẫn đến sự lãng phí
trong việc sử dụng không gian lưu trữ và tài nguyên hệ thống. Hơn nữa, việc truy cập và
xử lý các tệp tin nhỏ trong GFS có thể gây ra hiệu suất không tốt do overhead trong quá
trình truy xuất và xử lý chunk.

Google File System (GFS) có một nhược điểm quan trọng là khả năng trì hoãn khi
master trở thành điểm bottleneck. Master trong GFS là nút quản lý hệ thống và điều phối
hoạt động của các chunk server. Trong trường hợp master gặp tải công việc quá lớn hoặc
16
xảy ra sự cố, các hoạt động của hệ thống có thể bị tạm dừng hoặc chậm lại, ảnh hưởng đến
tính sẵn sàng và hiệu suất. Tuy nhiên, GFS đã áp dụng các biện pháp giảm thiểu tác động
bằng cách sao chép dữ liệu và phân tán chunk server. Điều này cho phép truy xuất dữ liệu
từ các chunk server khác trong khi master gặp vấn đề. Hơn nữa, GFS cũng sử dụng cơ chế
tự động chuyển giao nhiệm vụ giữa các master backup để đảm bảo tính sẵn sàng và ổn
định của hệ thống. Tóm lại, mặc dù trì hoãn khi master trở thành điểm bottleneck là một
nhược điểm của GFS, hệ thống đã áp dụng các biện pháp để giảm thiểu tác động và đảm
bảo tính sẵn sàng của dữ liệu.

Google File System (GFS) có một nhược điểm đáng quan tâm khác đó là không thể
ghi ngẫu nhiên. GFS được thiết kế để tối ưu hóa việc đọc dữ liệu lớn và tuần tự, và không
phù hợp cho các ứng dụng có yêu cầu ghi ngẫu nhiên cao như cơ sở dữ liệu trực tuyến
(OLTP). Việc ghi ngẫu nhiên vào GFS đòi hỏi thực hiện các hoạt động đọc và ghi phức
tạp để duy trì tính nhất quán và đồng bộ hóa dữ liệu, gây ra hiệu suất không tốt. Tuy nhiên,
GFS đã áp dụng biện pháp ghi tập trung (write-append) để giảm tác động của ghi ngẫu
nhiên. Ghi tập trung cho phép các ứng dụng ghi dữ liệu theo một luồng tuần tự vào cuối
tệp tin hiện có, giảm số lượng hoạt động đọc và ghi phức tạp. Tóm lại, mặc dù GFS không
hỗ trợ ghi ngẫu nhiên, hệ thống đã áp dụng biện pháp ghi tập trung để giảm tác động và
cung cấp hiệu suất tốt cho việc đọc dữ liệu lớn và tuần tự.

17
III. Kết luận:
Trên đây là bài báo cáo về hệ thống Google File System (GFS), trong bài đã đưa
đến những thông tin về kiến trúc, các thành phần, cách thức hoạt động cũng như điểm
mạnh điểm yếu của hệ thống GFS. Cùng điểm lại một số thông tin quan trọng. Về kiến
trúc GFS gồm 3 thành phần máy chủ Master, máy chủ lưu trữ Chunkserver và máy khách
Client machine. Các thành phần của GFS bao gồm các interface, metadata, chunk file, bài
báo cáo cũng nói về cách thức hoạt động cũng như chi tiết về các cơ chế hoạt động của
chúng cách thức trao đổi đọc và ghi dữ liệu. GFS bên cạnh những ưu điểm về dữ liệu như
độ tin cậy cao, hiệu suất làm việc với dữ liệu cao, dễ dàng mở rộng nếu có nhu cầu, dữ liệu
dễ phục hồi thì cũng có một số khuyết điểm như không tiện lợi khi chỉ lưu các tệp tin nhỏ,
nếu có nhiều dữ liệu một lúc dễ gây nên bottleneck tại master khi chỉ có 1 luồng xử lý
nhiều thông tin.

GFS đã giúp Google xây dựng một hệ thống lưu trữ mạnh mẽ và tin cậy cho hạ
tầng của họ mà hiện nay rất nhiều tập thể cũng như cá nhân cũng đang sử dụng hàng ngày
hàng giờ.

18
IV. Tài liệu tham khảo:
• The Google File System - Sanjay Ghemawat, Howard Gobioff, and Shun-Tak
Leung. (PDF)
• Geek for Geeks
Google File System - GeeksforGeeks.
• Reading Notes - Google File System:
http://krishnabhargav.github.io/architecture/notes,/publication/notes/2014/06/22/Goog
le-File-System-Notes.html?fbclid=IwAR1P9-
dMNkJmkwYRHEUXqO0sWHROuuIakVGG7V-rLTaSzV-An2tM73P6x6U
• Cramzable - Google File System
Google File System
• Wikipedia- Google File System
https://en.wikipedia.org/wiki/Google_File_System

19