Bạn đã bao giờ tò mò về cách mà 1 hệ thống lớn như Google quản lý và lưu trữ hàng ngàn terabyte dữ liệu từ các dịch vụ như Gmail, Google Drive, YouTube,... chưa? Ngày hôm nay, chúng ta sẽ khám phá Google File System (GFS) - hệ thống lưu trữ mạnh mẽ của Google, là nền tảng cho việc quản lý và xử lý hàng tỷ files trên toàn cầu. GFS được coi là một trong những tiền đề quan trọng cho các hệ thống lưu trữ file phân tán sau này, đặt nền móng cho việc phát triển các hệ thống lưu trữ phân tán khác như Hadoop Distributed File System (HDFS) và các hệ thống tương tự. Hãy cùng mình tìm hiểu cơ chế và nguyên lý hoạt động của GFS để hiểu rõ hơn về cách Google quản lý dữ liệu của mình.
Một số giả định trong thiết kế:
- Large Scale: GFS giả định rằng nó sẽ được sử dụng trong các môi trường lưu trữ dữ liệu có quy mô lớn, bao gồm hàng nghìn máy chủ và lưu trữ petabyte hoặc thậm chí exabyte dữ liệu.
- Frequent Failures : GFS được giả định xây dựng trên các "inexpensive commodity hardware", do đó GFS được thiết kế để có khả năng fault tolerance cao đồng thời cần có cơ chế để đảm bảo high availability, ngay cả khi có sự cố phần cứng xảy ra.
- Large Files: GFS được tối ưu hóa để xử lý các files kích thước lớn, thường là từ megabyte đến gigabyte. Không optimize nhiều cho các case kích thước file nhỏ.
- Append-Only or Sequential Write : GFS giả định rằng hầu hết các lần ghi sẽ là việc chỉ thêm vào cuối file hiện có hoặc ghi tuần tự, thay vì ghi random.
- Simplified Metadata Management : GFS đơn giản hóa việc quản lý file bằng cách chia file thành các khối và lưu trữ chúng riêng biệt, với giả định rằng phương pháp này có tính scalable hơn so với hệ thống quản lý file truyền thống.
- Consistency Trade-offs : GFS ưu tiên tăng tốc độ và tính availability hơn là strong consistency, đặc biệt trong các tình huống ghi đồng thời.
Ý tưởng thiết kế:
- Master-Worker Architecture: Kiến trúc master-worker giống như một hệ thống điều khiển trung tâm (master) giám sát một đội công nhân (worker nodes). Master node quản lý thông tin quan trọng về hệ thống file, như nơi lưu trữ các files, quyền truy cập và cách chúng được sao chép. Worker nodes chịu trách nhiệm lưu trữ và truy xuất data. Việc chỉ sử dụng master node để lưu trữ các metadata mà không read/write trực tiếp trên master node giúp giảm thiểu bottleneck ở master.
- Chunk-based Storage: GFS chia các files thành các mảnh nhỏ hơn gọi là chunks, với kích thước cố định 64 megabytes mỗi chunk. Mỗi chunk được xử lý như một đơn vị lưu trữ dữ liệu riêng biệt, được xác định bởi 1 chuỗi 64 bit gọi là
chunk handle. Một chunk lớn nghĩa là client có khả năng thực hiện nhiều thao tác trên một chunk nhất định hơn và client có thể tái sử dụng kết nối TCP. Hơn nữa, kích thước chunk lớn hơn –> số lượng chunk ít hơn –> Tiết kiệm không gian lưu trữ metadata cho master node và điều này rất quan trọng đối với GFS. Tuy nhiên, việc số lượng chunk ít hơn cũng có 1 nhược điểm đó là nếu như nhiều client cùng access tới 1 file sẽ khiến chunk đó trở thành 1 "hot spot".
- Replication and Fault Tolerance: Để đảm bảo high availability ngay cả khi một số phần của hệ thống bị hỏng, GFS tạo ra các bản sao của mỗi chunk và lưu trữ chúng trên nhiều worker nodes. Mặc định, 3 bản sao của mỗi chunk được lưu trữ trên các worker nodes khác nhau. Nếu một bản sao trở nên không khả dụng do sự cố phần cứng hoặc vấn đề khác, hệ thống vẫn có thể truy cập dữ liệu từ các bản sao khác.
Với master, GFS duy trì một shadow master, shadow master này có thể được sử dụng để trở thành master node khi master node gặp sự cố. Shadow master có thể sync data từ operation logs. Khi có sự thay đổi data, master sẽ thực hiện ghi log vào operation log, nếu việc ghi log thành công thì master mới cập nhật các thay đổi của metadata lên memory. Điều này giúp cho operation logs luôn phản ánh chính xác trạng thái của hệ thống trước bất kỳ sự thay đổi nào, đảm bảo rằng shadow master có thể đồng bộ và duy trì một bản sao chính xác của metadata. Nếu master gặp sự cố, shadow master có thể tiếp quản và khôi phục hệ thống một cách nhanh chóng và hiệu quả, đảm bảo tính liên tục và ổn định cho hệ thống. Cơ chế này khá tương tự với master-slave trong MySql
- Lazy Rebalancing: Khi master node phát hiện một số worker nodes ít sử dụng trong khi các node khác quá tải, nó sẽ dần dần di chuyển data từ các node quá tải đến các node ít sử dụng hơn. Quá trình này được gọi là lazy rebalancing vì nó không diễn ra ngay lập tức; thay vào đó, nó diễn ra từ từ theo thời gian để giảm thiểu sự gián đoạn cho các hoạt động đang diễn ra.
- Atomic Record Append: GFS hỗ trợ một thao tác đặc biệt gọi là
atomic record append, cho phép nhiều quá trình ghi dữ liệu vào một file đồng thời mà không gây ra data corruption. Tính năng này đặc biệt hữu ích cho các ứng dụng như distributed logging, nơi nhiều process cần ghi log đồng thời. - Data integrity: Các chunkserver sử dụng checksum để đảm bảo toàn vẹn dữ liệu. Một chunk được chia thành các khối 64 KB. Mỗi khối có một checksum 32-bit tương ứng. Các checksum được lưu trong memory và trong logs. Khi đọc, chunkserver kiểm tra checksum của các khối dữ liệu trước khi trả lại bất kỳ dữ liệu nào cho client hoặc chunkserver khác. Nếu có sự không khớp checksum xảy ra trong một khối, chunkserver sẽ trả về lỗi và báo về master. Trong trường hợp này, client sẽ đọc từ các replica khác, trong khi master sẽ clone chunk từ một replica khác.
- Leases and Mutation Order: Mutation là một thao tác thay đổi nội dung hoặc metadata của chunk. GFS thực hiện mỗi mutation trên tất cả các replica của chunk. GFS triển khai một cơ chế lease để đảm bảo thứ tự mutation nhất quán trên các chunkserver. Master cấp một chunk lease cho một trong các replica (primary). Primary chọn một thứ tự tuần tự cho tất cả các mutations của chunk. Tất cả các replica phải tuân theo thứ tự này khi áp dụng mutations. Cơ chế này được thiết kế để giảm tải áp lực quản lý của master. Lease có thời gian chờ mặc định là 60 giây, nhưng primary có thể yêu cầu gia hạn thời gian chờ từ master. Tuy nhiên, cũng có thể thu hồi một lease trước khi nó hết hạn trong một số trường hợp, chẳng hạn như master muốn dừng các mutations trên file đã được đổi tên. Master có thể cấp một lease mới cho một replica khác sau khi lease cũ hết hạn nếu nó mất liên lạc với primary. Chi tiết hơn bạn có thể xem ở flow write data bên dưới.
Architecture:
GFS gồm 3 thành phần chính: Client, Master, và các ChunkServer.
Master: là cơ quan đầu não quản lí các hoạt động của GFS.
- Namespace Management and Locking: Master quản lý các thông tin metadata của các chunk,
đồng thời quản lý các lock trong quá trình read/write data.
- Replica Placement: Master quyết định nơi đặt các replica của các chunk trên các chunkserver, đảm bảo tính phân tán và dự phòng của dữ liệu, tối ưu hóa performance và khả năng phục hồi của hệ thống.
- Replica Creation: Master quản lý việc tạo replica để duy trì số lượng bản sao mong muốn của mỗi chunk, khởi tạo replica mới khi phát hiện số lượng giảm xuống dưới ngưỡng yêu cầu(mặc định là 3), đảm bảo tính toàn vẹn và sẵn sàng của dữ liệu trong hệ thống.
- Re-replication: được kích hoạt khi có sự cố hoặc khi một chunkserver bị hỏng, đảm bảo rằng tất cả các chunks luôn có số lượng replica đủ để duy trì hoạt động ổn định.
- Rebalancing: Master giám sát tình trạng của các chunkserver và tự động cân bằng lại các chunk giữa chúng để đảm bảo rằng tải công việc được phân phối đều cho mỗi chunk nhằm tối ưu hóa hiệu suất của hệ thống.
- Stale Replica Detection: Master giám sát trạng thái của các replicas trên các chunkserver và xử lý các replica không đồng bộ hoặc out-of-date bằng cách khởi động quá trình tạo lại replica. Điều này đảm bảo rằng dữ liệu lưu trữ luôn được duy trì tính nhất quán và độ tin cậy của hệ thống không bị ảnh hưởng.
- Garbage Collection: Master quản lý việc loại bỏ các chunk không còn được sử dụng để giải phóng không gian lưu trữ thông qua garbage collection.
Client: là thành phần tương tác trực tiếp với người dùng hoặc ứng dụng để thực hiện các thao tác đọc và ghi dữ liệu vào GFS.
- Truy cập dữ liệu: Client có khả năng truy cập và tải dữ liệu từ GFS bằng cách gửi các yêu cầu đến Master và ChunkServer.
- Ghi dữ liệu: Client cũng có thể ghi dữ liệu vào GFS bằng cách gửi yêu cầu ghi đến Master. Sau khi nhận được vị trí của chunk từ Master, Client gửi dữ liệu đến các ChunkServer để lưu trữ.
ChunkServer: là nơi thực hiện lưu trữ thực tế của dữ liệu trong GFS. Mỗi chunk trong GFS được lưu trữ trên một hoặc nhiều ChunkServer dưới dạng các replica.
- Lưu trữ dữ liệu: ChunkServer nhận dữ liệu từ Client và lưu trữ chúng theo định dạng chunk. Mỗi ChunkServer có thể chứa nhiều chunk và chịu trách nhiệm duy trì các replica của chúng.
- Truy xuất dữ liệu: ChunkServer cung cấp dữ liệu cho Client khi được yêu cầu và thực hiện các thao tác đọc và ghi dữ liệu theo yêu cầu của Client.
Data flow
Write
Mô tả:
-
Yêu cầu thông tin từ master:
- Client gửi yêu cầu đến Master để lấy thông tin về holder của chunk lease và các vị trí replica.
- Master phản hồi với thông tin về primary và các vị trí của replica.
-
Gửi dữ liệu đến các chunkserver:
- Client đẩy dữ liệu tới PrimaryChunkserver, SecondaryChunkserver1 và SecondaryChunkserver2.
- PrimaryChunkserver và các chunkserver thứ cấp xác nhận đã nhận dữ liệu.
-
Thực hiện yêu cầu ghi:
- Client gửi yêu cầu ghi tới PrimaryChunkserver.
- PrimaryChunkserver chuyển tiếp yêu cầu ghi tới SecondaryChunkserver1 và SecondaryChunkserver2.
-
Hoàn tất quá trình ghi:
- SecondaryChunkserver1 và SecondaryChunkserver2 respond kết quả ghi về PrimaryChunkserver.
- PrimaryChunkserver respond quá trình ghi hoàn tất tới Client.
-
Xử lý lỗi: Nếu có lỗi xảy ra trong quá trình ghi, Client sẽ retry. Quá trình retry bao gồm các bước từ 3 đến 7 cho đến khi ghi thành công.
Read
Mô tả:
- Client gửi một yêu cầu đến Master để nhận thông tin về file chunk.
- Master trả lời Client với thông tin chunk handle và các vị trí của các replicas.
- Client gửi yêu cầu đến một trong các replica:
- Client chọn một trong số các replicas, có thể là bản sao gần nhất, và gửi yêu cầu để lấy data.
- Nếu replica đầu không khả dụng, Client sẽ gửi yêu cầu đến bản sao tiếp theo gần nhất.
Delete
Mô tả:
- Client yêu cầu xóa file: Client gửi yêu cầu xóa file đến Master.
- Master xử lý yêu cầu xóa:
- Master nhận yêu cầu và thêm lệnh xóa vào logs.
- Master đổi tên file với một tên ẩn (hidden name), điều này cho phép data có thể được khôi phục lại nếu cần thiết trong một khoảng thời gian nhất định.
- File được giữ trong hệ thống với tên ẩn trong 3 ngày để đảm bảo rằng nó có thể được khôi phục nếu cần.
- Garbage Collection:
- Garbage Collection diễn ra sau mỗi 1 khoảng thời gian nhất định nhưng bỏ qua các tệp tin bị xóa chưa quá 3 ngày.
- Garbage Collection yêu cầu Master thực hiện scan định kỳ tên miền của tệp tin (file namespace).
- Master loại bỏ tên tệp tin khỏi tên miền của tệp (namespace) nếu đã qua 3 ngày.
- Scan định kỳ chunk namespace của Master:
- Garbage Collection yêu cầu Master thực hiện scan định kỳ tên miền của các chunk (chunk namespace).
- Master loại bỏ tên chunk có số lượng tham chiếu nhỏ hơn 1 (reference count < 1).
- Giao tiếp giữa Chunkservers và Master:
- Chunkserver1 gửi thông tin chunk đến Master.
- Master không tìm thấy chunk trong namespace, và yêu cầu Chunkserver1 xóa chunk ở local.
- Chunkserver2 gửi thông tin chunk đến Master.
- Master không tìm thấy chunk trong namespace, và yêu cầu Chunkserver2 xóa chunk ở local.
- Chunkserver3 gửi thông tin chunk đến Master.
- Master không tìm thấy chunk trong namespace, và yêu cầu Chunkserver3 xóa chunk ở local.
Kết luận:
Mặc dù Paper về GFS được Google publish từ năm 2003, tuy nhiên "Old but Gold" có lẽ là câu nói chính xác cho GFS khi mà những ý tưởng trong GFS vẫn còn nguyên giá trị cho tới ngày hôm nay. Trên đây chỉ là những tóm tắt sơ lược về cơ chế hoạt động của GFS, chi tiết hơn về cơ chế lock read/write, snapshot mechanism, consitency model, performance measurement các bạn có thể xem ở paper chính thức của Google: https://research.google/pubs/the-google-file-system/. Bên cạnh đó, khi gần viết xong bài blog thì mình tìm ra một bài viết khá chi tiết và dễ hiểu trên Medium, vì vậy nếu bạn muốn hiểu hơn về GFS mình thực sự highly recommend các bạn nên đọc bài viết này: https://medium.com/thedeephub/all-you-need-to-know-about-the-google-file-system-bf74aa157c62. Sau cùng, cảm ơn bạn đã dành thời gian đọc bài viết. Hẹn gặp lại các bạn ở những bài viết sau!
Referrence:
https://research.google/pubs/the-google-file-system
https://brabalawuka.cc/posts/study/gfs/
https://w3.cs.jmu.edu/kirkpams/OpenCSF/Books/csf/html/DistDataStorage.html
https://medium.com/thedeephub/all-you-need-to-know-about-the-google-file-system-bf74aa157c62