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... Thực tế, khách hàng thường yêu cầu nh
Trang 1HỌ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
Trần Đức Nguyên
Nguyễn Quang Phúc
Trần Đức Quân
Vũ Hồng Quân
Trang 2Mụ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
Trang 33
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
Trang 4II Nội dung:
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
Trang 55
Để 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
Trang 6Mộ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
Trang 77
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ể
Trang 8chỉ 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
Trang 99
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
Trang 10Leases đượ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