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

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