GFS

GFS (Google File System) ABSTRACT Google thiết kế triển khai hệ thống tệp GFS, hệ thống tệp phân tán mở rộng cho ứng dụng phân tán lớn sử dụng nhiều liệu Nó cung cấp khả chịu lỗi chạy phần cứng rẻ tiền mang lại hiệu suất tổng hợp cao cho số lượng lớn khách hàng Trong chia sẻ nhiều mục tiêu giống hệ thống tệp phân tán trước đây, thiết kế Google thúc đẩy quan sát khối lượng công việc ứng dụng môi trường công nghệ Google, phản ánh khác biệt rõ rệt so với số giả định hệ thống tệp trước Điều khiến Google xem xét lại lựa chọn truyền thống khám phá điểm thiết kế hoàn toàn khác biệt Hệ thống tệp GFS đáp ứng thành công nhu cầu lưu trữ Google Nó triển khai rộng rãi Google làm tảng lưu trữ để tạo xử lý liệu sử dụng dịch vụ Google nỗ lực nghiên cứu phát triển theo yêu cầu liệu lớn Cụm lớn cung cấp hàng trăm terabyte dung lượng lưu trữ hàng nghìn đĩa nghìn máy truy cập đồng thời hàng trăm khách hàng Trong báo này, Google trình bày phần mở rộng giao diện hệ thống tệp thiết kế để hỗ trợ ứng dụng phân tán, thảo luận nhiều khía cạnh thiết kế Google báo cáo phép so sánh từ hai khía cạnh vi mô việc sử dụng giới thực INTRODUCTION Google thiết kế triển khai hệ thống tệp Google File System (GFS) để đáp ứng nhu cầu xử lý liệu ngày tăng nhanh chóng Google GFS chia sẻ nhiều mục tiêu tương tự hệ thống tệp phân tán trước (DFS) như: hiệu suất, khả mở rộng, độ tin cậy tính khả dụng Tuy nhiên, thiết kế thúc đẩy nghiên cứu ứng dụng xử lý môi trường công nghệ Google hướng phát triển tương lai Phản ánh khởi đầu rõ rệt từ số giả định thiết kế hệ thống tệp trước Google xem xét lại lựa chọn truyền thống khám phá điểm hoàn toàn khác không gian thiết kế Đầu tiên, lỗi vài thành phần phần cứng hệ thống điều khơng phải khơng có Hệ thống tệp bao gồm hàng trăm chí hàng ngàn máy lưu trữ sử dụng phần cứng giá rẻ truy cập số lượng lớn người dùng với máy tính có Số lượng chất lượng thành phần máy tính không hoạt động liên tục thời gian định số không phục hồi từ lỗi xảy hệ thống Google Google thấy vấn đề gây ứng dụng lỗi, lỗi hệ điều hành, lỗi người lỗi đĩa, nhớ, đầu nối, mạng nguồn điện Do đó, việc giám sát liên tục, phát lỗi, lỗi người dùng sai phục hồi tự động phải phần thiếu hệ thống Thứ hai, tệp lớn so với tệp trước Nhiều tệp chứa nhiều GB phổ biến Mỗi tệp thường chứa nhiều đối tượng ứng dụng tài liệu web Khi thường xuyên làm việc với liệu phát triển nhanh chóng với nhiều TBs bao gồm hàng tỷ đối tượng, thật khó sử dụng quản lý hàng tỷ tệp có kích thước khoảng vài KB hệ thống tệp hỗ trợ Kết là, giả định thơng số thiết kế chẳng hạn hoạt động I/O blocksize phải xem xét lại Thứ ba, hầu hết tệp bị đột biến cách thêm liệu thay ghi đè liệu có Ghi ngẫu nhiên bên tập tin thực tế không tồn Sau viết, tập tin đọc theo cách Một loạt liệu nhiều người sử dụng có đặc điểm Một số tạo thành kho lưu trữ mà chương trình phân tích liệu duyệt qua Vài liệu luồng liệu tạo liên tục cách chạy ứng dụng Một số liệu lưu trữ Một số kết trung gian tạo máy xử lý khác, cho dù xử lý đồng thời hay vào thời điểm khác Dữ liệu truy cập tệp khổng lồ nối lại trở thành trọng tâm tối ưu hóa hiệu suất đảm bảo toàn vẹn liệu, khối liệu nhớ đệm máy khách hấp dẫn kích thước đệm nhỏ vài MB Thứ tư, đồng thời thiết kế lại ứng dụng hệ thống tệp API mang lại lợi ích cho hệ thống tổng thể cách tăng tính linh hoạt Google Ví dụ: Google nới lỏng mơ hình qn GFS để đơn giản hóa đáng kể hệ thống tệp mà khơng tạo gánh nặng khó khăn cho ứng dụng Google giới thiệu hoạt động nối thêm xử lý để nhiều khách hàng nối đồng thời vào tệp mà khơng cần đồng hóa thêm chúng Những điều thảo luận chi tiết phần sau báo Nhiều cụm GFS triển khai cho mục đích khác Những lớn có 1000 nút lưu trữ, 300 TB dung lượng lưu trữ đĩa truy cập nhiều hàng trăm khách hàng máy khác sở liên tục DESIGN OVERVIEW 2.1 Assumptions Trong việc thiết kế hệ thống tệp cho nhu cầu mình, Google hướng dẫn giả định đưa thách thức hội Google đề cập đến số quan sát trước đưa giả định Google chi tiết Hệ thống xây dựng từ nhiều thành phần hàng hóa rẻ tiền thường dễ bị lỗi Nó phải liên tục tự giám sát phát hiện, dung nạp phục hồi kịp thời hư hỏng phận cách thường xuyên Hệ thống lưu trữ số lượng nhỏ tệp lớn Google mong đợi khoảng vài triệu tệp, tệp thường có kích thước 100 MB lớn Các tệp nhiều GB trường hợp phổ biến cần quản lý hiệu Các tệp nhỏ phải hỗ trợ, Google khơng cần tối ưu hóa chúng Khối lượng cơng việc chủ yếu bao gồm hai loại lần đọc: lần đọc trực tuyến lớn lần đọc ngẫu nhiên nhỏ Trong lần đọc phát trực tuyến lớn, thao tác riêng lẻ thường đọc hàng trăm KB, phổ biến MB trở lên Các hoạt động từ ứng dụng khách thường đọc qua vùng tiếp giáp tệp Một đọc ngẫu nhiên nhỏ thường đọc vài KB số điểm bù tùy ý Các ứng dụng quan tâm đến hiệu suất thường hàng loạt xếp lần đọc nhỏ chúng để tiến hành đặn qua tệp thay quay quay lại Khối lượng cơng việc có nhiều ghi lớn, nối liệu vào tệp Kích thước hoạt động điển hình tương tự kích thước cho lần đọc Sau viết, tệp sửa đổi lại Ghi nhỏ vị trí tùy ý tệp hỗ trợ khơng thiết phải có hiệu Hệ thống phải triển khai hiệu ngữ nghĩa xác định rõ ràng cho nhiều máy khách đồng thời nối vào tệp Các tệp Google thường sử dụng làm hàng đợi sản xuất để hợp nhiều cách Hàng trăm nhà sản xuất, chạy nhà sản xuất máy, đồng thời thêm vào tệp Tính nguyên tử với chi phí đồng hóa tối thiểu điều cần thiết Tệp đọc sau người tiêu dùng đọc qua tệp đồng thời Băng thơng trì cao quan trọng độ trễ thấp Hầu hết ứng dụng mục tiêu Google đặt phí cao cho việc xử lý liệu hàng loạt với tỷ lệ cao, số ứng dụng có yêu cầu nghiêm ngặt thời gian phản hồi cho lần đọc ghi riêng lẻ 2.2 Interface GFS cung cấp giao diện hệ thống tệp quen thuộc, khơng triển khai API tiêu chuẩn POSIX Các tệp tổ chức phân cấp thư mục xác định tên đường dẫn Google hỗ trợ thao tác thông thường để tạo, xóa, mở, đóng, đọc ghi tệp Hơn nữa, GFS có hoạt động nối thêm ảnh chụp nhanh ghi lại Snapshot tạo tệp thư mục với chi phí thấp Phụ lục ghi cho phép nhiều khách hàng nối đồng thời liệu vào tệp đảm bảo tính nguyên tử phần phụ lục khách hàng riêng lẻ Nó hữu ích cho việc triển khai kết hợp đa chiều hàng đợi sản xuất mà nhiều máy khách đồng thời thêm vào mà khơng cần khóa thêm Google nhận thấy loại tệp vô giá việc xây dựng ứng dụng phân tán lớn Ảnh chụp nhanh phụ lục ghi thảo luận thêm phần 3.4 3.3 tương ứng 2.3 Architecture Một cụm GFS bao gồm máy chủ nhiều máy chủ truy cập nhiều máy khách, thể Hình Mỗi số thường máy Linux hàng hóa chạy quy trình máy chủ cấp người dùng Có thể dễ dàng chạy chunkserver client máy, miễn tài nguyên máy cho phép độ tin cậy thấp chạy mã ứng dụng khơng ổn định chấp nhận Các tệp chia thành phần có kích thước cố định Mỗi chunk xác định xử lý chunk 64 bit bất biến toàn cầu định master thời điểm tạo chunkcreation Chunkservers lưu trữ khối đĩa cục dạng tệp Linux đọc ghi liệu chunkdata định dải xử lý byte Để đảm bảo độ tin cậy, chunk chép nhiều máy chủ Theo mặc định, Google lưu trữ ba sao, nhiên người dùng định mức chép khác cho vùng khác không gian tên tệp Bản trì tất siêu liệu hệ thống tệp Điều bao gồm không gian tên, thơng tin kiểm sốt truy cập, ánh xạ từ tệp thành phần vị trí phần Nó kiểm sốt hoạt động tồn hệ thống quản lý chunklease, thu gom rác khối mồ côi di chuyển khối Master định kỳ liên lạc với chunkserver thông điệp HeartBeat để đưa hướng dẫn thu thập trạng thái Mã ứng dụng GFS liên kết vào ứng dụng triển khai API hệ thống tệp giao tiếp với máy chủ máy chủ khối để đọc ghi liệu thay mặt cho ứng dụng Khách hàng tương tác với máy chủ để thực hoạt động siêu liệu, tất giao tiếp mang liệu chuyển trực tiếp đến máy chủ Google không cung cấp API POSIX khơng cần kết nối với lớp vnode Linux Cả máy khách máy chủ phân khúc không lưu trữ liệu tệp Bộ nhớ đệm ứng dụng khách mang lại lợi ích hầu hết ứng dụng truyền qua tệp lớn có làm việc lớn để lưu vào nhớ cache Việc khơng có chúng đơn giản hóa máy khách hệ thống tổng thể cách loại bỏ vấn đề liên quan đến nhớ cache (Tuy nhiên, máy khách thực siêu liệu đệm.) Máy chủ phân đoạn không cần lưu trữ liệu tệp vào nhớ cache phần lưu trữ dạng tệp cục đệm đệm Linux lưu giữ liệu truy cập thường xuyên nhớ 2.4 Single Master Việc có tổng thể giúp đơn giản hóa đáng kể thiết kế Google cho phép tổng thể đưa định vị trí chép phân đoạn phức tạp cách sử dụng kiến thức toàn cầu Tuy nhiên, phải giảm thiểu tham gia vào việc đọc ghi để khơng trở thành nút cổ chai Máy khách không đọc ghi liệu tệp thơng qua tệp Thay vào đó, khách hàng hỏi master mà liên hệ với máy chủ Nó lưu thơng tin vào nhớ đệm thời gian giới hạn tương tác trực tiếp với chunkservers cho nhiều hoạt động Hãy để Google giải thích tương tác cho đọc đơn giản với tham chiếu đến Hình Đầu tiên, sử dụng chunksize cố định, máy khách dịch tên tệp độ lệch byte ứng dụng định thành chunkindex tệp Sau đó, gửi cho chủ yêu cầu chứa tên tệp mục chunk Bản trả lời tay cầm phân đoạn tương ứng vị trí Máy khách lưu trữ thông tin cách sử dụng tên tệp chunkindex làm khóa Sau đó, khách hàng gửi yêu cầu đến sao, gần Yêu cầu định xử lý phân đoạn phạm vi byte phân đoạn Các lần đọc thêm đoạn mã không yêu cầu tương tác máy khách-chủ thông tin lưu nhớ cache hết hạn tệp mở lại Trên thực tế, khách hàng thường yêu cầu nhiều phần yêu cầu chủ bao gồm thơng tin cho phần sau phần yêu cầu Thông tin bổ sung hỗ trợ số tương tác khách hàng-chủ tương lai mà thực tế không thêm phí 2.5 Chunk Size Chunksize thông số thiết kế quan trọng Google chọn 64 MB, lớn nhiều so với kích thước hệ thống tệp thông thường Mỗi chunkreplica lưu trữ dạng tệp Linux túy máy chủ phân đoạn mở rộng cần thiết Phân bổ khơng gian lười biếng tránh lãng phí khơng gian phân mảnh bên trong, có lẽ phản đối lớn chucksize lớn Kích thước lớn cung cấp số lợi quan trọng Đầu tiên, làm giảm nhu cầu tương tác khách hàng với đọc ghi chunk yêu cầu yêu cầu ban đầu cho thơng tin phân bổ Việc giảm đặc biệt có ý nghĩa khối lượng cơng việc Google ứng dụng chủ yếu đọc ghi tệp lớn cách Ngay lần đọc ngẫu nhiên nhỏ, máy khách thoải mái lưu trữ tất thơng tin phân bổ vào nhớ cache cho tập hợp làm việc nhiều TB Thứ hai, đoạn lớn, máy khách có nhiều khả thực nhiều thao tác đoạn định, giảm chi phí mạng cách giữ kết nối TCP cá nhân với phân khối qua thời gian mở rộng khoảng thời gian Thứ ba, làm giảm kích thước siêu liệu lưu trữ Điều cho phép giữ siêu liệu nhớ, mang lại lợi ích khác mà thảo luận Phần 2.6.1 Mặt khác, kích thước lớn, với việc phân bổ khơng gian lười biếng, có nhược điểm Một tệp nhỏ bao gồm số phần nhỏ, có lẽ Các phần mềm lưu trữ phần trở thành điểm nóng nhiều máy khách truy cập vào tệp Trong thực tế, điểm nóng khơng phải vấn đề lớn ứng dụng Google chủ yếu đọc nhiều tệp tin lớn Tuy nhiên, điểm nóng phát triển GFS lần sử dụng hệ thống hàng đợi hàng loạt: tệp thực thi ghi vào GFS dạng tệp tin đơn lẻ sau khởi động hàng trăm máy lúc Một vài lưu trữ tệp thực thi bị tải hàng trăm yêu cầu đồng thời Google khắc phục cố cách lưu trữ tệp thực thi với hệ số chép cao cách làm cho hệ thống hàng loạt làm trì trệ thời gian bắt đầu ứng dụng Một giải pháp dài hạn tiềm cho phép khách hàng đọc liệu từ khách hàng khác tình 2.6 Metadata Master lưu trữ ba loại siêu liệu chính: tệp không gian tên miền, ánh xạ từ tệp thành phần vị trí phần Tất siêu liệu lưu nhớ master Hai loại (namespace ánh xạ tệp thành chunk) trì liên tục cách ghi đột biến vào nhật ký hoạt động lưu trữ đĩa cục chép máy từ xa Sử dụng nhật ký cho phép Google cập nhật trạng thái cách đơn giản, đáng tin cậy khơng có nguy mâu thuẫn trường hợp xảy cố Bản gốc khơng lưu trữ thơng tin phân bổ liên tục Thay vào đó, hỏi chunkserver khối khởi động chunkserver tham gia vào cụm 2.6.1 In-Memory Data Structures Vì siêu liệu lưu trữ nhớ nên thao tác diễn nhanh chóng Hơn nữa, việc qt định kỳ toàn trạng thái chế độ dễ dàng hiệu gốc Quá trình quét định kỳ sử dụng để thực thu thập chunkgarbage, tái chép có lỗi chunkserver di chuyển đoạn để cân tải sử dụng không gian đĩa chunkserver Phần 4.3 4.4 thảo luận hoạt động Một mối quan tâm tiềm ẩn cách tiếp cận dành cho nhớ số lượng phần dung lượng toàn hệ thống bị giới hạn lượng nhớ chủ có Đây khơng phải hạn chế nghiêm trọng thực tế Bản trì 64 byte siêu liệu cho đoạn 64 MB Hầu hết phần đầy hầu hết tệp chứa nhiều phần, phần cuối lấp đầy phần Tương tự, liệu khơng gian tên tệp thường u cầu 64 byte cho tệp lưu trữ tên tệp cách nhỏ gọn cách sử dụng nén tiền tố Nếu cần thiết để hỗ trợ hệ thống tệp lớn nữa, chi phí thêm nhớ bổ sung cho giá nhỏ để trả cho đơn giản, độ tin cậy, hiệu suất tính linh hoạt mà có cách lưu trữ siêu liệu nhớ 2.6.2 Chunk Locations Người quản lý không lưu giữ ghi liên tục phân đoạn có đoạn cho Nó đơn giản thăm dị chunkserver cho thơng tin khởi động Bản tự cập nhật sau kiểm sốt tất vị trí phân đoạn giám sát trạng thái chunkserver với thông báo HeartBeat thông thường Ban đầu, Google cố gắng trì liên tục thơng tin vị trí phân đoạn chính, Google định việc yêu cầu liệu từ máy chủ phân đoạn khởi động định kỳ sau đơn giản nhiều Điều loại bỏ vấn đề giữ đồng hóa master chunkservers chunkservers tham gia rời khỏi cụm, thay đổi tên, không thành công, khởi động lại, v.v Trong cụm với hàng trăm máy chủ, kiện xảy thường xuyên Một cách khác để hiểu định thiết kế nhận lưu trữ có ý nghĩa cuối có khơng có đĩa Khơng có ích lợi cố gắng trì nhìn qn thơng tin lỗi phân khối khiến khối biến cách tự nhiên (ví dụ: đĩa bị hỏng bị vơ hiệu hóa) người vận hành đổi tên phân khối 2.6.3 Operation Log Nhật ký hoạt động chứa ghi lịch sử thay đổi siêu liệu quan trọng Nó trung tâm GFS Nó khơng ghi siêu liệu liên tục mà cịn đóng vai trò dòng thời gian logic xác định thứ tự hoạt động đồng thời Các tệp phần nhỏ, phiên chúng (xem Phần 4.5), tất xác định vĩnh cửu theo thời gian hợp lý mà chúng tạo Vì nhật ký hoạt động quan trọng, Google phải lưu trữ cách đáng tin cậy không thực thay đổi hiển thị cho khách hàng thay đổi siêu liệu thực liên tục Nếu không, Google toàn hệ thống tệp hoạt động gần máy khách phần tồn Do đó, Google chép nhiều máy từ xa phản hồi hoạt động máy khách sau lưu ghi nhật ký tương ứng vào đĩa cục từ xa Bản gốc gộp số ghi nhật ký lại với trước xả, làm giảm tác động việc xả chép lên thông lượng tổng thể hệ thống Master khơi phục trạng thái hệ thống tệp cách phát lại nhật ký hoạt động Để giảm thiểu thời gian khởi động, phải giữ nhật ký nhỏ Điểm kiểm tra kiểm tra trạng thái nhật ký phát triển vượt q kích thước định để khôi phục cách tải điểm kiểm tra từ đĩa cục phát lại số lượng ghi nhật ký hạn chế sau Điểm kiểm tra dạng B nhỏ gọn ánh xạ trực tiếp vào nhớ sử dụng để tra cứu không gian tên mà không cần phân tích cú pháp thêm Điều tiếp tục tăng tốc độ phục hồi cải thiện tính khả dụng Bởi việc xây dựng điểm kiểm tra khoảng thời gian, trạng thái bên trang cấu trúc theo cách tạo điểm kiểm tra mà khơng làm trì hoãn đột biến xảy Bản gốc chuyển sang tệp nhật ký tạo điểm kiểm tra luồng riêng biệt Điểm kiểm tra bao gồm tất đột biến trước chuyển đổi Nó tạo phút lâu cho cụm có vài triệu tệp Khi hồn thành, ghi vào diskboth cục từ xa Khơi phục cần điểm kiểm tra hồn chỉnh tệp nhật ký Các trạm kiểm soát cũ tệp nhật ký bị xóa tự do, Google giữ số điểm xung quanh để đề phòng thảm họa Lỗi q trình kiểm tra khơng ảnh hưởng đến tính đắn mã khơi phục phát bỏ qua điểm kiểm tra chưa hoàn chỉnh 2.7 Consistency Model GFS có mơ hình qn thoải mái hỗ trợ tốt ứng dụng phân tán cao Google tương đối đơn giản hiệu để triển khai Bây thảo luận đảm bảo GFS ý nghĩa chúng ứng dụng Google nêu bật cách GFS trì đảm bảo để lại chi tiết cho phần khác báo 2.7.1 Guarantees by GFS Các đột biến không gian tên tệp (ví dụ: tạo tệp) nguyên tử Chúng xử lý độc quyền master: khóa khơng gian tên đảm bảo tính nguyên tử tính đắn (Phần 4.1); nhật ký hoạt động xác định thứ tự tổng thể chung hoạt động (Phần 2.6.3) Trạng thái vùng tệp sau đột biến liệu phụ thuộc vào loại đột biến, thành cơng hay thất bại liệu có đột biến đồng thời hay khơng Bảng tóm tắt kết Một vùng tệp quán tất máy khách ln nhìn thấy liệu, chúng đọc từ Một vùng xác định sau đột biến liệu tệp quán khách hàng thấy đột biến ghi tồn Khi đột biến thành cơng mà khơng có can thiệp từ người viết đồng thời, vùng bị ảnh hưởng xác định (và theo ngụ ý qn): tất khách hàng ln nhìn thấy đột biến viết Các đột biến thành công đồng thời để lại vùng không xác định quán: tất khách hàng nhìn thấy liệu, khơng phản ánh đột biến viết Thơng thường, bao gồm đoạn trộn lẫn từ nhiều đột biến Một đột biến không thành công làm cho khu vực khơng qn (do khơng xác định): khách hàng khác thấy liệu khác thời điểm khác Dưới Google mô tả cách ứng dụng Google phân biệt vùng xác định với vùng không xác định Các ứng dụng không cần phải phân biệt thêm loại vùng không xác định khác Các đột biến liệu ghi phụ ghi Việc ghi làm cho liệu ghi độ lệch tệp ứng dụng định Phần nối thêm ghi khiến liệu (“bản ghi”) nối nguyên tử lần có đột biến đồng thời, phần bù với lựa chọn GFS (Phần 3.3) (Ngược lại, phần nối thêm “thông thường” đơn ghi phần bù mà khách hàng tin phần cuối tệp.) Phần bù trả cho khách hàng đánh dấu bắt đầu vùng xác định có chứa ghi Ngồi ra, GFS chèn đệm ghi vào Chúng chiếm khu vực coi không quán thường bị thu hẹp lượng liệu người dùng Sau chuỗi đột biến thành công, vùng tệp đột biến đảm bảo xác định chứa liệu ghi đột biến cuối GFS đạt điều cách (a) áp dụng đột biến cho chunkin theo thứ tự tất (Phần 3.1) (b) sử dụng số chunkversion để phát cũ bỏ sót đột biến trình lưu trữ bị hỏng ( Mục 4.5) Các cũ không liên quan đến đột biến đưa cho khách hàng yêu cầu chủ nhân cho vị trí chunk Chúng thu gom rác thời gian sớm Vì máy khách lưu trữ phân đoạn nhớ cache, họ đọc từ cũ trước thơng tin làm Cửa sổ bị giới hạn thời gian chờ mục nhập nhớ cache lần mở tệp, cửa sổ xóa khỏi nhớ cache tất thông tin chi tiết cho tệp Hơn nữa, hầu hết tệp Google phần phụ, nên cũ thường trả kết thúc sớm chunkrather so với liệu lỗi thời Khi trình đọc thử lại liên hệ với chủ, nhận phân bổ Rất lâu sau đột biến thành công, lỗi thành phần tất nhiên làm hỏng phá hủy liệu GFS xác định máy chủ không thành công cách bắt tay thường xuyên máy chủ tất máy chủ phát lỗi liệu cách tổng hợp (Phần 5.2) Khi cố xuất hiện, liệu khôi phục từ hợp lệ sớm tốt (Phần 4.3) Một đoạn bị phục hồi tất bị trước GFS phản ứng, thường vịng vài phút Ngay trường hợp này, trở nên khơng khả dụng, không bị hỏng: ứng dụng nhận lỗi rõ ràng liệu bị hỏng 2.7.2 Implications for Applications Các ứng dụng GFS phù hợp với mơ hình qn thoải mái với số kỹ thuật đơn giản cần cho mục đích khác: dựa vào phần bổ sung thay ghi đè, kiểm tra ghi ghi tự xác thực, tự nhận dạng Trên thực tế, tất ứng dụng Google biến đổi tệp cách thêm vào thay ghi đè Trong lần sử dụng điển hình, người viết tạo tệp từ đầu đến cuối Nó tự động đổi tên tệp thành tên vĩnh viễn sau ghi tất liệu định kỳ kiểm tra xem có ghi thành cơng Các điểm kiểm tra bao gồm tổng kiểm tra cấp ứng dụng Người đọc xác minh xử lý vùng tệp điểm kiểm tra cuối cùng, biết trạng thái xác định Bất kể vấn đề tính quán đồng thời, cách tiếp cận phục vụ Google tốt Việc bổ sung hiệu có khả chống lại lỗi ứng dụng cao nhiều so với việc ghi ngẫu nhiên Kiểm tra cho phép người viết khởi động lại bước ngăn người đọc xử lý liệu tệp viết thành cơng chưa hồn thiện theo quan điểm ứng dụng Trong cách sử dụng điển hình khác, nhiều người viết đồng thời thêm vào tệp để có kết hợp hàng đợi nhà sản xuất-người tiêu dùng Ghi lại ngữ nghĩa append-ít lần trì đầu người viết Người đọc xử lý phần đệm không thường xuyên sau Mỗi ghi người viết chuẩn bị chứa thơng tin bổ sung tổng kiểm tra để xác minh tính hợp lệ Người đọc xác định loại bỏ phần đệm thừa ghi lại đoạn cách sử dụng tổng kiểm tra Nếu khơng thể chịu đựng khơng thường xun (ví dụ: chúng kích hoạt hoạt động khơng phải đơn vị), lọc chúng cách sử dụng số nhận dạng ghi, thường cần thiết để đặt tên cho thực thể ứng dụng tương ứng tài liệu web Các chức cho I / O ghi (ngoại trừ loại bỏ trùng lặp) nằm mã thư viện ứng dụng Google chia sẻ áp dụng cho triển khai giao diện tệp khác Google Cùng với đó, chuỗi ghi, cộng với gặp, chuyển đến người đọc ghi SYSTEM INTERACTIONS Google thiết kế hệ thống để giảm thiểu tham gia chủ tất hoạt động Với tảng đó, mô tả cách tương tác máy khách, máy chủ máy chủ khối để triển khai đột biến liệu, nối thêm ghi nguyên tử ảnh chụp nhanh 3.1 Leases and Mutation Order Đột biến thao tác làm thay đổi nội dung siêu liệu phần thao tác viết thao tác nối thêm Mỗi đột biến thực tất đoạn Google sử dụng hợp đồng thuê để trì trật tự đột biến quán Master cấp chunklease cho sao, mà Google gọi Sơ đồ chọn thứ tự nối tiếp cho tất đột biến đoạn Tất tuân theo thứ tự áp dụng đột biến Do đó, thứ tự đột biến tồn cục xác định trước tiên thứ tự cấp cho thuê chủ nhân chọn hợp đồng thuê số sê-ri định Cơ chế cho thuê thiết kế để giảm thiểu chi phí quản lý tổng thể Hợp đồng thuê có thời gian chờ ban đầu 60 giây Tuy nhiên, miễn chunkis bị đột biến, gian chờ yêu cầu chưa xử lý, kết nối lại với máy chủ khởi động lại thử lại Phần 6.2.2 báo cáo thời gian khởi động quan sát 5.1.2 Chunk Replication Như thảo luận trước đó, chunkis chép nhiều chunkserver giá đỡ khác Người dùng định mức chép khác cho phần khác không gian tên tệp Giá trị mặc định ba Bản chép có cần thiết để giữ cho đoạn chép hoàn toàn máy chủ chuyển sang chế độ ngoại tuyến phát bị hỏng thông qua xác minh tổng kiểm tra (xem Phần 5.2) Mặc dù việc nhân rộng phục vụ tốt cho Google, Google khám phá hình thức dự phịng nhiều máy chủ khác mã chẵn lẻ mã xóa cho yêu cầu lưu trữ đọc ngày tăng Google Google kỳ vọng việc triển khai kế hoạch dự phòng phức tạp hệ thống kết hợp lỏng lẻo Google thách thức quản lý lưu lượng truy cập Google bị chi phối phần thêm lần đọc lần ghi ngẫu nhiên nhỏ 5.1.3 Master Replication Trạng thái chủ chép để đảm bảo độ tin cậy Nhật ký hoạt động điểm kiểm tra chép nhiều máy Một đột biến trạng thái coi cam kết sau ghi nhật ký chuyển sang ổ đĩa tất Để đơn giản, quy trình chịu trách nhiệm tất đột biến hoạt động thu gom rác thay đổi nội hệ thống Khi khơng thành cơng, khởi động lại gần Nếu máy đĩa gặp trục trặc, sở hạ tầng giám sát bên ngồi GFS bắt đầu quy trình nơi khác với nhật ký hoạt động chép Máy khách sử dụng tên tắc máy chủ (ví dụ: gfs-test), bí danh DNS thay đổi máy chủ chuyển đến máy khác Hơn nữa, "bóng tối" cung cấp quyền truy cập đọc vào hệ thống tệp bị lỗi Chúng bóng, khơng phải gương, chỗ chúng trễ so với ánh sáng chính, thường vài phần giây Chúng tăng cường khả đọc cho tệp khơng bị đột biến tích cực ứng dụng không ngại nhận kết cũ Trên thực tế, nội dung tệp đọc từ máy chủ, ứng dụng không quan sát nội dung tệp cũ Những cũ cửa sổ ngắn siêu liệu tệp, nội dung thư mục thơng tin kiểm sốt truy cập Để giữ cho thơng báo, trình chủ bóng tối đọc nhật ký hoạt động phát triển áp dụng chuỗi thay đổi cấu trúc liệu giống hệt trình tự Giống phần mềm chính, thăm dị chunkserver khởi động (và khơng thường xun sau đó) để xác định vị trí chunk trao đổi thông điệp bắt tay thường xuyên với chúng để theo dõi trạng thái chúng Nó phụ thuộc vào dành cho cập nhật vị trí định tạo xóa quan 5.2 Data Integrity Mỗi chunkserver sử dụng tổng kiểm tra để phát hỏng hóc liệu lưu trữ Do cụm GFS thường có hàng nghìn đĩa hàng trăm máy, thường xuyên gặp lỗi đĩa gây hỏng liệu đường dẫn đọc ghi (Xem Phần để biết ngun nhân.) Chúng ta khơi phục từ tham nhũng cách sử dụng phân đoạn khác, không thực tế phát tham nhũng cách so sánh qua khối Hơn nữa, khác hợp pháp: ngữ nghĩa đột biến GFS, đặc biệt phần phụ lục nguyên tử cụ thể thảo luận trước đó, khơng đảm bảo giống hệt Do đó, chunkserver phải xác minh độc lập tính tồn vẹn cách trì tổng kiểm tra Một chunksize chia thành khối 64 KB Mỗi có tổng kiểm tra 32 bit tương ứng Giống siêu liệu khác, tổng kiểm tra lưu giữ nhớ lưu trữ liên tục với việc ghi nhật ký, tách biệt với liệu người dùng Đối với lần đọc, trình quản lý phân đoạn xác minh tổng kiểm tra khối liệu chồng lên phạm vi đọc trước trả lại liệu cho người yêu cầu, cho dù máy khách hay máy chủ phân đoạn khác Do đó, máy chủ khơng truyền lỗi sang máy khác Nếu khối không khớp với tổng kiểm tra ghi lại, trình phục vụ trả lỗi cho người yêu cầu báo cáo khơng phù hợp cho Đáp lại, requestor đọc từ khác, chép đoạn mã từ khác Sau có hợp lệ, bậc thầy lệnh cho máy chủ báo cáo khơng phù hợp để xóa Kiểm tra ảnh hưởng đến hiệu suất đọc số lý Vì hầu hết lần đọc Google kéo dài vài khối, Google cần đọc tổng kiểm tra lượng liệu bổ sung tương đối nhỏ để xác minh Mã máy khách GFS giảm thêm chi phí cách cố gắng chỉnh lần đọc ranh giới khối tổng kiểm tra Hơn nữa, việc tra cứu tổng kiểm tra so sánh máy chủ khối thực mà khơng có I / O việc tính tốn tổng kiểm tra thường bị chồng chéo với I / Os Tính tốn Checksum tối ưu hóa nhiều cho việc ghi nối vào cuối đoạn (trái ngược với việc ghi đè lên liệu có) chúng chiếm ưu khối lượng công việc Google Google cập nhật bước tổng tổng kiểm tra cho khối tổng kiểm tra phần cuối tính tốn tổng kiểm tra cho khối tổng kiểm tra hoàn toàn điền phần phụ Ngay khối tổng kiểm tra phần cuối bị hỏng Google không phát bây giờ, giá trị tổng kiểm tra không khớp với liệu lưu trữ lỗi phát bình thường khối đọc Ngược lại, lần ghi ghi đè lên phạm vi có phân đoạn, phải đọc xác minh khối cuối phạm vi bị ghi đè, sau thực ghi, cuối tính tốn ghi lại tổng kiểm tra Nếu Google không xác minh khối khối cuối trước ghi đè chúng phần, tổng kiểm tra che giấu tham nhũng tồn vùng không bị ghi đè Trong thời gian nhàn rỗi, máy chủ quét xác minh nội dung tệp không hoạt động Điều cho phép Google phát tham nhũng phần đọc Khi lỗi phát hiện, gốc tạo khơng bị hỏng xóa bị hỏng Điều ngăn không cho đoạn không hoạt động bị hỏng đánh lừa chủ nhân nghĩ có đủ hợp lệ đoạn 5.3 Diagnostic Tools Ghi nhật ký chẩn đoán rộng rãi chi tiết giúp ích nhiều việc phân lập vấn đề, gỡ lỗi phân tích hiệu suất, phải chịu chi phí tối thiểu Nếu khơng có nhật ký, khó hiểu tương tác thời, không lặp lại máy Máy chủ GFS tạo nhật ký chẩn đoán ghi lại nhiều kiện quan trọng (chẳng hạn máy chủ khối lên xuống) tất yêu cầu phản hồi RPC Các ghi chẩn đốn xóa tự mà khơng ảnh hưởng đến tính đắn hệ thống Tuy nhiên, Google cố gắng lưu giữ ghi phạm vi không gian cho phép Nhật ký RPC bao gồm yêu cầu phản hồi xác gửi dây, ngoại trừ liệu tệp đọc ghi Bằng cách đối sánh yêu cầu với câu trả lời đối chiếu ghi RPC máy khác nhau, Google tạo lại tồn lịch sử tương tác để chẩn đốn cố Các ghi đóng vai trị dấu vết để kiểm tra tải phân tích hiệu suất Tác động hiệu suất việc ghi nhật ký tối thiểu (và vượt trội nhiều so với lợi ích) nhật ký viết không đồng Các kiện gần lưu nhớ có sẵn để theo dõi trực tuyến liên tục MEASUREMENTS Trong phần này, Google trình bày số điểm chuẩn vi mơ để minh họa điểm nghẽn vốn có kiến trúc triển khai GFS, số số từ cụm thực sử dụng Google 6.1 Micro-benchmarks Google đo hiệu suất cụm GFS bao gồm chính, hai chính, 16 máy chủ khối 16 máy khách Lưu ý cấu hình thiết lập để dễ kiểm tra Các cụm điển hình có hàng trăm khối hàng trăm khách hàng Tất máy cấu hình với vi xử lý PIII 1,4 GHz kép, nhớ GB, hai đĩa 80 GB tốc độ 5400 vòng / phút kết nối Ethernet song công 100 Mbps với chuyển mạch HP 2524 Tất 19 máy chủ GFS kết nối với chuyển mạch tất 16 máy khách với chuyển mạch Hai thiết bị chuyển mạch kết nối với liên kết Gbps 6.1.1 Reads Khách hàng N đọc đồng thời từ hệ thống tệp Mỗi khách hàng đọc vùng MB chọn ngẫu nhiên từ 320 GB tập tệp Điều lặp lặp lại 256 lần để khách hàng kết thúc đọc GB liệu Các chunkservers thực với Chỉ có nhớ 32 GB, Google mong đợi nhiều 10% tỷ lệ đệm Linux Kết phải gần để làm lạnh kết nhớ cache Hình (a) cho thấy tỷ lệ đọc tổng hợp cho N máy khách giới hạn lý thuyết Giới hạn đạt đỉnh tổng hợp 125 MB/s liên kết Gbps hai thiết bị chuyển mạch bị bão hòa 12,5 MB/s máy khách giao diện mạng 100 Mbps bị bão hịa, tùy theo điều kiện áp dụng Tốc độ đọc quan sát 10 MB/s, 80% giới hạn cho khách hàng, có khách hàng đọc Tốc độ đọc tổng hợp đạt 94 MB/s, khoảng 75% số 125 MB/s linklimit, cho 16 đầu đọc, MB/s cho máy khách Hiệu suất giảm từ 80% xuống 75% số lượng người đọc tăng lên, xác suất nhiều người đọc đồng thời đọc từ máy chủ 6.1.2 Writes N máy khách ghi đồng thời vào N tệp riêng biệt Mỗi máy khách ghi GB liệu vào tệp chuỗi ghi MB Tỷ lệ ghi tổng hợp giới hạn lý thuyết thể Hình 3(b) Cao nguyên giới hạn 67 MB/s cần ghi byte vào số 16 máy chủ phân đoạn, máy chủ có kết nối đầu vào 12,5 MB/s Tốc độ ghi cho máy khách 6,3 MB/s, khoảng nửa giới hạn Thủ phạm cho điều lỗi mạng Google Nó khơng tương tác tốt với sơ đồ pipelining mà Google sử dụng để đẩy liệu đến chunkreplicas Sự chậm trễ việc truyền liệu từ sang khác làm giảm tốc độ ghi tổng thể Tốc độ ghi tổng hợp đạt 35 MB/s cho 16 máy khách (hoặc 2,2 MB/s cho máy khách), khoảng nửa giới hạn lý thuyết Như trường hợp đọc, có nhiều khả nhiều máy khách ghi đồng thời vào lưu trữ số lượng khách hàng tăng lên Hơn nữa, 16 người viết có nhiều khả xảy va chạm 16 người đọc viết liên quan đến ba khác Viết chậm Google muốn Trong thực tế, vấn đề lớn làm tăng độ trễ máy khách cá nhân thấy, khơng ảnh hưởng đáng kể đến băng thơng ghi tổng hợp mà hệ thống cung cấp cho số lượng lớn máy khách 6.1.3 Record Appends Hình (c) cho thấy hiệu suất nối thêm ghi N máy khách nối đồng thời vào tệp Hiệu suất bị giới hạn băng thông mạng máy chủ lưu trữ phần cuối tệp, khơng phụ thuộc vào số lượng máy khách Nó bắt đầu tốc độ 6,0 MB/giây cho máy khách giảm xuống 4,8 MB/giây cho 16 máy khách, chủ yếu tắc nghẽn khác biệt tốc độ truyền mạng máy khách khác Các ứng dụng Google có xu hướng tạo nhiều tệp đồng thời Nói cách khác, N máy khách nối vào M tệp chia sẻ đồng thời N M hàng chục hàng trăm Do đó, tắc nghẽn mạng chunkserver thử nghiệm Google vấn đề đáng kể thực tế máy khách đạt tiến ghi tệp chunkserver cho tệp khác bận 6.2 Real World Clusters Bây Google kiểm tra hai cụm sử dụng Google đại diện cho số cụm khác giống chúng Cluster A sử dụng thường xuyên để nghiên cứu phát triển trăm kỹ sư Một tác vụ điển hình người dùng bắt đầu chạy lên đến vài Nó đọc qua vài MB đến vài TB liệu, chuyển đổi phân tích liệu ghi kết trở lại cụm Cụm B chủ yếu sử dụng để xử lý liệu sản xuất Các tác vụ kéo dài nhiều liên tục tạo xử lý tập liệu đa TB mà đơi có can thiệp người Trong hai trường hợp, “tác vụ” bao gồm nhiều trình nhiều máy đọc ghi nhiều tệp đồng thời 6.2.1 Storage Như hiển thị năm mục bảng, hai cụm có hàng trăm máy chủ, hỗ trợ nhiều TB dung lượng đĩa không hồn tồn đầy “Khơng gian sử dụng” bao gồm tất phân đoạn Hầu tất tệp chép ba lần Do đó, cụm lưu trữ 18 TB 52 TB liệu tệp tương ứng Hai cụm có số lượng tệp tương tự nhau, B có tỷ lệ tệp chết lớn hơn, cụ thể tệp bị xóa thay phiên nhớ chưa lấy lại Nó có nhiều khối tệp có xu hướng lớn 6.2.2 Metadata Các phần mềm tổng hợp lưu trữ hàng chục GB siêu liệu, chủ yếu tổng kiểm tra cho khối liệu người dùng 64 KB Siêu liệu khác lưu giữ chunkservers số phân đoạn thảo luận Phần 4.5 Siêu liệu giữ gốc nhỏ nhiều, hàng chục MB trung bình khoảng 100byte cho tệp Điều đồng ý với giả định Google kích thước nhớ khơng giới hạn dung lượng hệ thống thực tế Hầu hết siêu liệu cho tệp tên tệp lưu trữ dạng nén tiền tố Các siêu liệu khác bao gồm quyền sở hữu quyền tệp, ánh xạ từ tệp thành phần phiên phần Ngoài ra, đoạn, Google lưu trữ vị trí số lượng tham chiếu để triển khai chép ghi Mỗi máy chủ riêng lẻ, máy chủ máy chủ, có 50 đến 100 MB siêu liệu Do đó, q trình khơi phục diễn nhanh chóng: vài giây để đọc siêu liệu từ đĩa trước máy chủ trả lời truy vấn Tuy nhiên, gốc bị chập chờn khoảng thời gian - thường 30 đến 60 giây - tìm nạp thơng tin vị trí phân đoạn từ tất máy chủ 6.2.3 Read and Write Rates Bảng cho thấy tỷ lệ đọc ghi khoảng thời gian khác Cả hai cụm hoạt động khoảng tuần phép đo thực (Các cụm khởi động lại gần để nâng cấp lên phiên GFS mới.) Tốc độ ghi trung bình 30 MB/s kể từ khởi động lại Khi Google thực phép đo này, B loạt hoạt động ghi tạo khoảng 100 MB/s liệu, tạo tải trọng mạng 300 MB/s lần ghi truyền tới ba Figure 3: Aggregate Throughputs Các đường cong hiển thị giới hạn lý thuyết áp đặt hệ thống mạng Google Các đường cong hiển thị thông lượng đo Chúng có lỗi hiển thị khoảng tin cậy 95%, đọc số trường hợp phương sai thấp phép đo ... Consistency Model GFS có mơ hình qn thoải mái hỗ trợ tốt ứng dụng phân tán cao Google tương đối đơn giản hiệu để triển khai Bây thảo luận đảm bảo GFS ý nghĩa chúng ứng dụng Google nêu bật cách GFS trì... chủ yếu đọc nhiều tệp tin lớn Tuy nhiên, điểm nóng phát triển GFS lần sử dụng hệ thống hàng đợi hàng loạt: tệp thực thi ghi vào GFS dạng tệp tin đơn lẻ sau khởi động hàng trăm máy lúc Một vài... chọn GFS (Phần 3.3) (Ngược lại, phần nối thêm “thông thường” đơn ghi phần bù mà khách hàng tin phần cuối tệp.) Phần bù trả cho khách hàng đánh dấu bắt đầu vùng xác định có chứa ghi Ngồi ra, GFS