Báo cáo bài tập lớn môn an toàn hệ điều hành đề tài tìm hiểu hệ thống file phân tán google file system

Mỗi chunk được định danh bởi duy nhất một “chunk handle” có 64 bit và được gánbởimastervàothờiđiểmchunkđượctạo.Chunkserverlưutrữcácchunk trên ổ đĩa dưới dạng các tệp Linux và đọc hoặc gh

HỌCVIỆNCÔNGNGHỆBƯUCHÍNHVIỄNTHÔNG KHOA AN

TOÀN THÔNG TIN

BÁO CÁO BÀI TẬP LỚN MÔNANTOÀNHỆĐIỀUHÀNH

Nhómthựchiện:G04

ĐỀTÀI:Tìmhiểuhệthốngfilephântán Google

File System

Sinhviênthựchiện:LạiDuyHải–B21DCAT080

Chu Bá Hiếu – B21DCAT086 NguyễnMinhHiệu–B21DCAT090 Nguyễn Quý Hùng – B21DCAT096 Tô Quang Huy – B21DCAT104

HàNội2/2024

I Giớithiệu 1

II Kiếntrúcvàcácthànhphần 2

1 Kiếntrúctổngquan 2

2 Cácthànhphầnvà đặctrưng 3

2.1 Máyc h ủ c h í n h ( M a s t e r s e r v e r ) v à l à d u y n h ấ t ( S i n g l e m aster)

3 2.2 Máyc h ủ đ o ạ n ( c h u n k s e r v e r ) v à k í c h t h ư ớ c đ o ạ n ( C h u n k size)

3 2.3 Metadata 5

2.3.1 In-MemoryDataStructures 5

2.3.2 ChunkLocations 5

2.3.3 OperationLog 6

III Tươngtáchệthống(Cáchthứchoạtđộng) 7

1 Đọcvàtruycậpfile(Read) 7

2 Thuêvàthứtựghi(LeaseandMutationOrder) 7

3 Luồngdữliệu(Dataflow) 9

4 Thêmdữliệunguyêntử(Atomicrecordappends) 10

5 Chịulỗivàchẩnđoán(Faulttoleranceanddiagnosis) 11

5.1 Tínhsẵnsàngcao(Highavailability) 11

5.2 Toànvẹndữliệu(DataIntegrity) 12

5.3 Côngcụchẩnđoán(DiagnosticTools) 13

IV Ưunhượcđiểm 13

1 Ưuđiểm 13

2 Nhượcđiểm 13

V Kếtluận 14

VI Tàiliệuthamkhảo 15

I Giớithiệu

Google File System (GFS) là một hệ thống quản lý tập tin phân tán (DFS) được phát triển bởi Google, được sử dụng nội bộ và không được công bố dưới dạng mã nguồn mở GFS không chỉ tuân theo các tiêu chí quan trọng như hiệu suất (performances), khả năng mở rộng (scalability), độ tin cậy (reliability) và tính sẵn dùng (availability) như các hệ thống tệp phân tán trước đây, mà còn đưa ra những cải tiến đột phá trong thiết kế để đáp ứng các yêu cầu của môi trường vận hành tại Google

Phầncứngthươngmại(Commodityhardware)

Lỗithànhphần(componentfailure)xảyrathườngxuyênhơn.Hệthốngfile bao gồm hàng trăm thậm chí là hàng nghìn thiết bị lưu trữ Những thiết bị lưu trữ này được tạo nên bởi những phần cứng thương mại (commodity hardware) chi phí thấp và được truy cập bởi một lượng lớn máy khách Với sốlượnglớnmáychủcùngvớichấtlượngcủacácphầncứngthươngmạiđã

dựđoánvàkhẳngđịnhchắcchắnrằng:trongbấtcứthờiđiểmnàocũngluôn

cómộtsốthiếtbịlưutrữkhônghoạtđộngvàmộtsốsẽkhôngthểkhôiphục lạitừnhững sựcố đó.Trên thựctế đãghinhận những lỗinhư: lỗi ứng dụng (application bugs), lỗi server, lỗi mạng, lỗi hệ điều hành (os bugs) hay lỗi củaconngười(errorbugs),…VìthếGooglecầnphảilàmtốttrongviệcgiám sát và kiểm soát lỗi, cũng như khắc phục hậu quả

Tuy nhiên, sử dụng phần cứng thương mại lại đem đến một số lợi ích nhất định như giúp giảm đi chi phí đầu tư ban đầu và chi phí duy trì, đồng thời làmgiảmtổngchiphívậnhànhcủahệthống.Vàviệcsửdụngmộtsốlượng

lớnservernhưvậycóthểdễdàngmởrộngvàthêmvàohệthống.Bằngcách

thêmcácmáychủmớivàocụm,GFScóthểmởrộngmàkhônggặpphảicác vấn đề lớn về tính tương thích hoặc hạn chế của phần cứng

Kíchthướctệplớn(Largefiles)

Các tệp trong GFS thường có kích thước lớn, thậm chí là hàng Giga Bytes Mỗitệpthườngchứanhiềuđốitượngứngdụngnhưtàiliệuweb.GFSđược tối ưu để đọc hay ghi những file có kích thước lớn như vậy

Vậnhànhfile(Fileoperations)

Việcghifilethayvìghiđèdữliệumớilêndữliệuhiệncócủafile,GFSthêm dữ liệu vào cuối của file Việc ghi ngẫu nhiên trong một tệp gần nhưkhông tồn tại Một khi file đã được ghi, file sẽ ở trạng thái chỉ đọc (read only) và việc đọc thường là tuần tự

Cách xử lý dữ liệu trong GFS đã ảnh hưởng đến việc thiết kế và tối ưu hóa của hệ thống, ví dụ như việc tập trung vào việc thêm dữ liệu mới (append-only), quản lý việc đọc dữ liệu một cách hiệu quả và đảm bảo tính toàn vẹn

dữ liệu

II Kiếntrúcvàcácthànhphần

1 Kiếntrúctổngquan

MộthệthốngGFSbaogồmmộtmáychủmaster(masterserver)duynhấtvà nhiều máy chủ đoạn (chunk server) và được truy cập bởi nhiều client Mỗi mộttrongsốchúngthườnglàmộtmáythươngmạiLinux(commodityLinux Machine) chạy một tiến trình server ở mức người dùng Việc chạy cả một chunkservervàmộtclienttrêncùngmộtmáyrấtdễdàng,miễnlàtàinguyên hệ thống cho phép

Các tập tin được chia thành các đoạn (chunk) có kích thước cố định Mỗi chunk được định danh bởi duy nhất một “chunk handle” có 64 bit và được gánbởimastervàothờiđiểmchunkđượctạo.Chunkserverlưutrữcácchunk trên ổ đĩa dưới dạng các tệp Linux và đọc hoặc ghi dữ liệu chunk được chỉ định bằng một “chunk handle” và “byte range” Để đảm bảo độ tin cậy (reliability), mỗi chunk được sao chép trên nhiều chunkserver Mặc định sẽ có 3 bản sao (replicas) được lưu, tuy nhiên người dùng có thể điều chỉnh số lượng bản sao được lưu trên chunkserver

Master server chứa tất cả metadata của hệ thống tệp, bao gồm không gian tên (namespace),t h ô n g t i n k i ể m soát truy cập (access control information), ánh xạ từ tệp đến các chunk và vị trí hiện tại của các chunk Master server cũngđiềukhiểncáchoạtđộngcủahệthốngnhưthuê(lease),dọndẹpdữliệu dưthừavàdichuyểnchunkgiữacácchunkserver.Mastergiaotiếptheochu kỳ xác định với mỗi chunkserver bằng HeartBeat để gửi chỉ thị và thu thập trạng thái của chunkserver

Cácclienttươngtácvớimasterđểlấymetadata,nhưngtấtcảviệctruyềndữ liệu đều trực tiếp đến các chunkserver Cả client và chunkserver đều không sử dụng cache do dữ liệu thường là rất lớn để có thể lưu vào cache Việc khôngsửdụngcachegiúpđơngiảnhóaclientvàhệthốngvìloạibỏcácvấn đề liên quan đến sự đồng nhất của cache Chunkserver không cần lưu trữ cache vì các chunk được lưu trữ dưới dạng các tệp cục bộ

2 Cácthànhphầnvàđặctrưng

2.1 Máychủchính(Masterserver)vàlàduynhất(Singlemaster)

Máy chủ chính (Master server) chứa tất cả các metadata của hệ thống tệp như không gian tên (namespace),t h ô n g t i n k i ể m s o á t t r u y c ậ p ( a c c e s s c o n t r o l i n f o r m a t i o n ) , á n h x ạ t ừ t ệ p đ ế n c á c

c h u n k v à v ị t r í h i ệ n t ạ i c ủ a c á c c h u n k , v à đ i ề u đ ặ c b i ệ t ở

đ â y l à c h ỉ c ó d u y n h ấ t m ộ t m a s t e r c h o t o à n b ộ h ệ t h ố n g

V i ệ c c ó m ộ t m a s t e r d u y n h ấ t đ ơ n g i ả n h ó a t h i ế t k ế c ủ a

h ệ t h ố n g v à c h o p h é p m a s t e r t h ự c h i ệ n c á c t h a o t á c t h a y

d ễ dànghơn.Tuynhiên,cầngiảmbớtviệcmasterphảithamgiavàocáchoạt

độngđọcvàghiđểtránhtìnhtrạngnútcổchai.Clientkhôngbaogiờđọcvà ghidữliệu tệpquamaster.Thayvàođóclientsẽhỏi masternênkếtnối đến chunkserver nào và trực tiếp kết nối đến chúng Việc master server chỉ làm việc với metadata giúp cho hệ thống hoạt động nhẹ nhàng hơn, giảm tình trạng quá tải lên máy chủ

2.2 Máychủđoạn(chunkserver)vàkíchthướcđoạn(Chunksize)

Chunk serverlàmáychủ lưutrữfiledướidạng cácđoạn (chunk).Dưới đây là một

số đặc trưng về Chunk server:

- Lưu trữ dữ liệu:Chunk server lưu trữ các chunk dữ liệu trên đĩa cục

bộ của nó Các chunk được lưu trữ dưới dạng các tệp thông thường trong hệ điều hành Linux

- Đảm bảo tính an toàn của dữ liệu:GFS sử dụng kỹ thuật nhân bản

chunk (chunk replication) để đảm bảo tính an toàn của dữ liệu Mỗi chunkđượcnhânbảnvàlưutrữtrênnhiềuchunkserverkhácnhauđể đảm bảo khả năng phục hồi sau khi xảy ra sự cố

- Giaotiếpvớimaster:Chunkserverthườngliênlạcvớimasterđểbáo

cáotrạngtháihoạtđộng,nhậnthôngtinvềcácthayđổicấutrúcvà

hoạt động của hệ thống, cũng như thực hiện các tác vụ quản lý như cấp phát và giải phóng chunk

- Phụcvụcácyêucầucủaclient:Chunkserverphụcvụcácyêucầuđọc

vàghitừclient.Khimộtclientmuốntruycậphoặcsửađổidữliệu,nó

liênhệvớichunkservertươngứngđểthựchiệncácthaotácnày.Kích

thướccủamỗichunklà64MB,làmộtkíchthướctươngđốilớnsovới các hệ thống file thông thường Kích thướcchunk lớn đem lại một số lợi ích quan trọng:

- Giảm thiểu nhu cầu tương tác của các client với master:do các hoạt

độngđọcvàghitrêncùngmộtchunkchỉđòihỏimộtrequestbanđầu

đếnmasterđểnhậnthôngtinvềvịtrícủachunk.Điềunàygiảmthiểu

đángkểlượngcôngviệccủahệthốngdoGFSthườngxuyênlàmviệc

vớicácfilecókíchthướclớn.Ngaycảđốivớicáchànhđộngđọcngẫu

nhiên(randomread)tươngđốinhỏ,clientcóthểdễdànglưutrữtấtcả thông tin vị trí của chunk với nhiều TeraByte

- Giảmthiểunetworkoverhead:Clientcókhảnăngthựchiệnnhiềuhoạt động trên

một chunk cụ thể, nó có thể giảm thiểu network overhead bằngcáchduytrìmộtkếtnốiTCPliêntụcvớichunkservertrongmột khoảng thời gian kéo dài

- Giảmkíchthướccủametadata:Việclưutrữdữliệudướidạngchunk lớn có

thể giúp giảm kích thước của metadata trên master server Từ đógiúplưutrữmetadatatrongbộnhớvàđemlạimộtsốlợiíchkhác

Mặt khác, một kích thước chunk lớn, ngay cả khi sử dụng lazy space allocation(mộtphươngphápcấpphátkhônggianlưutrữkhiđượcyêucầu), cũng có nhược điểm của nó Một tệp nhỏ có thể chỉ bao gồm một số lượng nhỏ các chunk, có thể chỉ là một Các chunkserver lưu trữ những chunk đó cóthểtrởthànhcácđiểmnóng(hotspot)nếunhiềumáykháchđangtruycập

vàocùngmộttệp.Trongthựctế,việccóđiểmnóngchưaphảilàmộtvấnđề lớn vì các hệ thống chủ yếu đọc các tệp lớn có nhiều chunk theo thứ tự

Tuy nhiên, điểm nóng đã trở thành một vấn đề lớn khi GFS lần đầu tiên sử dụng một hệ thống hàng đợi là batch-queue system: một tệp thực thi được ghi trên GFS dưới dạng một tệp chỉ có một chunk và sau đó hàng trăm máy tính yêu cầu truy cập file cùng một lúc Một số chunkserver lưu trữ tệp này

đã bị quá tải bởi hàng trăm request được gửi đến cùng một lúc Google đã khắcphụcvấnđềnàybằngcáchlưutrữnhiềubảnsaocủatệpđóvàlàmthời

giankhởiđộngbatch-queuesystemlâuhơn.Mộtgiảipháptiềmnăngdàihạn

làchophépclientđọcdữliệutừcácclientkháctrongnhữngtìnhhuốngnhưvậy

2.3 Metadata

Master server lưu trữ ba loại metadata chính: namespace, ánh xạ từ tệp đến chunk, và vị trí của các bản sao chunk Tất cả metadata được lưu trữ trong bộnhớcủamaster.Hailoạiđầutiên(namespacevàánhxạtừtệpđếnchunk) được lưu trữ bằng cách ghi nhật ký hoạt động (operation log) được lưu trữ trênổđĩacủamastervàđượcsaochépvàocácmáytừxa.Việcsửdụngmột nhật ký (log) cho phép chúng ta cập nhật trạng thái của master server một cách đơn giản, đáng tin cậy, và mà không gây ra xung đột trong trường hợp master server bị sập Master server không lưu trữ thông tin vị trí chunk lâu dài Thay vào đó, nó hỏi chunk server về các chunk chứa trong đó tại thời điểm master server khởi động

và mỗi khi một chunk server tham gia vàocụm

2.3.1 In-MemoryDataStructures

Vì dữ liệu metadata được lưu trữ trong bộ nhớ, các hoạt động của master diễn ra nhanh chóng Hơn nữa, việc quét định kỳ qua toàn bộ trạng thái của mình là dễ dàng và hiệu quả đối với master Việc quét định kỳ này được sử dụng để triển khai việc thu gom các chunk rác,tái sao chép lại trong trường hợpmấtchunkserver,vàdichuyểnchunkđểcânbằngtảivàkhônggianlưu trữ trên các chunkserver

Mộtlongạitiềmẩnchophươngphápnàylàsốlượngcácchunk,vìthếdung

lượngcủatoànbộhệthốngđượcgiớihạnbởibộnhớcủamasterserver.Tuy

nhiên,điềunàykhôngphảilàmộthạnchếnghiêmtrọngtrongthựctế.Master chỉ duy trì ít hơn

64 byte siêu dữ liệu cho mỗi chunk 64 MB Hầu như lưu trữtrêncácchunkđềuđầy,chỉcóchunkcuốicùngcủafilecóthểcònkhông gian lưu trữ Tương tự, namespace thường yêu cầu ít hơn 64 byte cho mỗitệp

Nếu có nhu cầu mở rộng hệ thống tệp lớn hơn, chi phí để thêm bộ nhớ phụ vàomasterlàmộtmứcgiárẻđểcóđượcsựđơngiản,đángtincậy,hiệusuất

vàlinhhoạtmàchúngtađạtđượcbằngcáchlưutrữmetadatatrongbộnhớ

2.3.2 ChunkLocations

Master server không giữ một bản ghi về việc các chunk server có bản sao của một chunk nhất định hay không Nó chỉ đơn giản là kiểm tra các chunk server để lấy thông tin đó khi khởi động Master server có thể tự cập nhật thôngtinnàysauđóvìnókiểmsoáttấtcảchunkserverbằngcácthôngđiệp HeartBeat định kỳ

Ban đầu, Google đã lưu trữ vị trí chunk lâu dài tại master server, nhưng họ thấy là việc yêu cầu dữ liệu từ các chunk server khi khởi động, và định kỳ sau đó, là đơn giản hơn nhiều Điều này loại bỏ vấn đề của việc duy trì sự đồng bộ giữa master server và các chunk server khi các chunk server tham giavàrờikhỏicụm,thayđổitên,gặpsựcố,khởiđộnglại, Trongmộtcụm có hàng trăm máy chủ, những việc này xảy ra quá thường xuyên

2.3.3 Operationlog

Nhật ký hoạt động (Operation log) chứa lịch sử thay đổi về metadata Nó là trung tâm của GFS Không chỉ là bản ghi lâu dài duy nhất về metadata, mà

nó còn được coi như một dòng thời gian logic giúp xác định thứ tự của các hoạtđộng.File,cácchunkvàcácphiênbản,đềuđượcxácđịnhduynhấtbởi thời gian logic khi chúng được tạo ra

Bởitínhquantrọng,Googleđãphảilưutrữnhậtkýhoạtđộngmộtcáchđáng tin cậy và không sửa đổi chúng cho đến khi các thay đổi về metadata được lưu trữ Nếu không, chúng ta thực sự mất hệ thống tệp hoặc các hoạt động gầnđâycủaclientngaycảkhicácchunkvẫntồntại.Dođó,Googlesaochép nó trên nhiều máy từ xa và phản hồi client chỉ sau khi lưu các bản ghi nhật ký tương ứng vào cả ổ đĩa cục bộ và từ xa (local and remote)

Master server phục hồi trạng thái hệ thống tệp của mình bằng cách phát lại nhật ký hoạt động Để giảm thiểu thời gian khởi động, Các nhà thiết kế hệ thống phải giữ cho nhật ký có kích thước nhỏ Máy chủ đã lưu một checkpoint trạng thái của mình mỗi khi nhật ký tăng kích thước vượt quá một kích thước nhất định Vì thế có thể khôi phục bằng cách tải lại checkpoint đã lưu từ ổ đĩa cục bộ và phát lại một số ít bản ghi nhật ký Bản kiểm soát có dạng B-Tree nhưng được nén lại có thể được ánh xạ trực tiếp vàobộnhớvàđượcsửdụngđểtìmkiếmnamespacemàkhôngcầnphântích thêm Điều này cũng làm tăng tốc quá trình khôi phục và cải thiện tính sẵn dùng (availability) Doviệcxâydựngmộtcheckpointcóthểmấtmộtthờigian,trạngtháinộibộ

củamasterserverđượctổchứcsaochomộtcheckpointmớicóthểđượctạo

ramàkhônglàmtrễquátrìnhghi.Máychủchuyểnsangmộttậptinnhậtký mớivàtạo racheckpointmớitạimộtluồng riêng.Checkpointmớibaogồm tất cả cácthay đổi trước khi chuyển và có thể được tạo ratrong khoảng một phút Khi hoàn thành, nó được ghi vào cục bộ và từ xa

Việc phục hồi chỉ cần checkpoint mới nhất và các tập tin nhật ký mới Các checkpoint và tập tin nhật ký cũ có thể được xóa một cách tự do,mặc dù hệ thốngvẫngiữmộtsốbảnđểbảovệkhỏicácsựcố.Sựcốtrongquátrìnhtạo

checkpoint không ảnh hưởng đến tính chính xác vì đoạn code phục hồi sẽ phát hiện và bỏ qua các checkpoint không hoàn chỉnh

III Tươngtáchệthống(Cáchthứchoạtđộng)

1 Đọcvàtruycậpfile(Read)

Client dịch tên tệp và độ dịch byte (byte offset) thành một chỉ mục chunk (chunkindex).Sauđó,client gửi requestchứatêntệpvàchỉ mụcchunktới masterserver.Mastergửiresponsevớichunkhandletương ứngvàvịtrícủa các bản sao Client lưu trữ thông tin bao gồm tên tệp và chỉ mụcchunk như là khóa (key)

Sauđó,Clientgửirequestbaogồmchunkhandlevàbyterangetớimộttrong các chunk server chứa bản sao, có thể là bản sao gần nhất và chunk server gửi response chứa chunk data về cho client Các lần đọc tiếp theo tới chunk đókhôngcầnthựchiệntươngtácgiữaclientvàmasterchođếnkhithôngtin

trongbộnhớcachehếthạnhoặctệpđượcmởlại.Trênthựctế,clientthường yêu cầu nhiều chunk trong cùng một request và master cũng có thể gửi response bao gồm các chunk data tương ứng

2 Thuêvàthứtựghi(LeaseandMutationOrder)

Ghi hay thay đổi (Mutation) là việc thay đổi nội dung hoặc metadata của chunk Việc ghi file trong GFS phải được thực thi trên tất cả các bản sao (replicas) của file Hệ thống sử dụng các "lease" để duy trì một thứ tự biến đổi nhất quán trên các bản sao Master server cấp phát một "lease" cho một trongcácbảnsao,gọilàprimary.Primarychọnmộtthứtựchoquátrìnhghi

(mutationorder)đếnchunkvàtấtcảcácbảnsaotuân theo thứtựnàykhiáp dụng quá trình ghi

Cơchế"lease"đượcthiếtkếđểgiảmthiểuoverheadquảnlýtạimaster.Một "lease" có thời gian chờ ban đầu là 60 giây Tuy nhiên, miễn là chunk đang