Phần 1: Google

GenK - Trong thế giới hiện đại ngày nay, đằng sau mỗi thao tác đơn giản của chúng ta trên thế giới mạng là cả một hệ thống đồ sộ đang vận hành. Từng giờ, từng giây trên thế giới có hàng chục triệu người đang sử dụng dịch vụ của các hãng công nghệ lớn trên thế giới như Google, Yahoo, Microsoft, Facebook..v.v.. Điều này đòi hỏi sức mạnh từ của hàng ngàn bộ xử lý trên hàng ngàn server của các hãng này. Chỉ tính riêng công việc trả về kết quả tìm kiếm mỗi khi người dùng gõ từ khóa vào search box, Google dã phải vận hành hàng loạt server đặt khắp thế giới, liên tục thực hiện thuật toán tìm kiếm cũng như sục sạo khắp thế giới web để có được một bức tranh toàn cảnh sẵn sàng được sử dụng để phục vụ người dùng một cách nhanh nhất. Với cường độ hoạt động 24/7, 365 ngày/ năm không có lấy một giây ngơi nghỉ, riêng việc phục vụ nhu cầu tìm kiếm đã đòi hỏi các hệ thống của Google xử lý xấp xỉ 20 petabyte dữ liệu mỗi ngày, một con số mà người bình thường khó có thể tưởng tượng ra nổi.

Ở tầm vóc này, mọi sai lầm dù là nhỏ nhất, dù là trong khâu thiết kế hay triển khai cũng có tiềm năng gây hậu quả lâu dài. Mọi công việc từ bổ sung dung lượng lưu trữ đến thay đổi đôi chút kết cấu cơ sở dữ liệu đều sẽ cần được được cân nhắc kỹ lưỡng, và quan trọng nhất là cần một thiết kế hợp lý để không làm ảnh hưởng đến hàng triệu người dùng đang "kêu gào" đòi hỏi ngoài kia. Với hàng trăm ngàn người dùng đang online và hàng ngàn terabyte dữ liệu được đọc/ghi ngay cả vào những thời điểm hệ thống đang được nâng cấp, các giải pháp công nghệ đơn giản của các trung tâm dữ liệu thông thường sẽ khó mà phù hợp cho quy mô này. Vậy rốt cuộc, những người khổng lồ công nghệ này quản lý dữ liệu của mình như thế nào để đáp ứng nhu cầu ngày càng gia tăng đó? Qua bài viết của Arcstechnica, chúng ta hãy cùng điểm qua một vài giải pháp dễ hiểu nhất mà Google, Amazon và Microsoft sử dụng.

Google File System

Không lấy gì làm lạ khi Google là một trong những hãng đầu tiên phải đối mặt với bài toán về lưu trữ khi xét đến số lượng người dùng mà hãng này phục vụ. Lời giải được các kỹ sư của hãng đưa ra vào năm 2003 là hệ thống lưu trữ phân tán, được tối ưu cho các dịch vụ mà Google cung cấp: Google File System (GFS). 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. 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.

Các chi tiết kỹ thuật GFS dĩ nhiên là được Google…giữ kín cho riêng mình, nhưng chúng ta vẫn có thể hình dung ra phần nào cách hệ thống này vận hành dựa trên những gì mà kỹ sư trưởng Howard Gobioff và Shun-Tak Leung chia sẻ hồi năm 2003. Tiêu chí hoạt động của GFS có thể gói gọn trong một câu: binh quý hồ…đa. Nói cách khác, với quy mô dữ liệu mà mình phải vận hành, các kỹ sư thiết kế GFS coi trọng khả năng mở rộng hệ thống, tăng số lượng server và ổ cứng thay vì đầu tư quá nhiều vào việc tạo ra các server hay thiết bị lưu trữ chất lượng cao. Google muốn kết hợp các server cũng như thiết bị lưu trữ rẻ và đơn giản thành một hệ thống với khả năng chịu lỗi cao nhất có thể. Như thế nào ư? Hãy nhìn vào câu phát biểu sau đây.

Nói cụ thể ra một chút, với cường độ hoạt động mà người dùng và Google đòi hỏi, các Server này sớm muộn cũng sẽ… ra đi. Và thiết kế của GFS được tạo ra để bảo đảm rằng, dù có phải thường xuyên thay đổi các server trong hệ thống, lượng dữ liệu bị mất đi vẫn sẽ được giữ ở mức tối thiểu. Trong các hệ thống của mình, Google thường lưu trữ dữ liệu trên các file dung lượng cực lớn, và các file này sẽ được đọc, ghi, sử dụng bởi rất nhiều ứng dụng tại cùng một thời điểm. Vì vậy GFS còn cần một đặc tính nữa là khả năng cung cấp lượng lớn dữ liệu ở tốc độ cao cho các ứng dụng này trong mọi thời điểm.

Để đáp ứng được 2 yêu cầu kể trên (tốc độ và khả năng chịu lỗi), hiển nhiên ta sẽ nghĩ ngay đến công nghệ RAID, và quả thực GFS hoạt động với cơ chế tương tự. Các tập hợp, gói file dữ liệu với dung lượng được định sẵn sẽ được rải đều trên một số cụm (cluster) server. Với cách tiếp cận như đã nêu: sử dụng các phần cứng giá thành rẻ, lấy số lượng lớn để bù đắp cho hiệu năng; sẽ là không ngoa khi nói các server này của Google “thăng” với tần suất khá thường xuyên, nhưng số lượng dữ liệu bị mất vẫn luôn được giữ ở mức hết sức tối thiểu.

Tuy nói là “tương tự”, nhưng quả thực trừ việc tăng tốc độ truy xuất và khả năng chịu lỗi, GFS khác rất nhiều so với RAID. Các server kể trên có thể nằm trong các dải mạng khác nhau, có lúc thuộc cùng datacenter, có lúc thậm chí còn không thuộc cùng một datacenter (tùy thuộc vào việc các file dữ liệu trên đó phục vụ việc gì). Quy mô của hai công nghệ rất chênh lệch. Với quy môt hoạt động của Google, khi nhắc đến “lưu trữ” thì ổ đĩa cứng là cách nghĩ quá hạn hẹp.

Điều này còn được thể hiện trong cách nhìn nhận đơn vị dữ liệu. Trong GFS, các kỹ sư chú trọng đến việc cung cấp dữ liệu theo từng khối cho việc xử lý, vì vậy khả năng cho phép đọc lượng lớn dữ liệu ở tốc độ cao là quan trọng nhất, còn tốc độ đọc hay ghi từng file vẫn chỉ được xếp vào hàng thứ yếu. Như các kỹ sư đã nêu trong bài viết của mình “Việc thực hiện một thay đổi bất kỳ trên từng file dĩ nhiên vẫn được hỗ trợ trong GFS, nhưng không được ưu tiên và hiệu năng của việc này cũng không được chú trọng tối ưu”. Nói dễ hiểu hơn, với quy mô của mình – GFS chủ yếu làm việc với dữ liệu theo từng khối, có thể bao gồm hàng triệu file với dung lượng từ hàng trăm MB đến vài GB. Và bởi các file dữ liệu này sẽ được rất nhiều ứng dụng sử dụng tại cùng một thời điểm, một cơ chế chịu lỗi khác cũng được thiết kế để bảo đảm rẵng mối khi có một thao tác ghi (write) xảy ra lỗi, dữ liệu sẽ có thể được rollback lại thời điểm ngay trước đó mà không làm ảnh hưởng đến các ứng dụng khác. Làm được điều này một cách chính xác mà không gây ảnh hưởng lớn đến hiệu năng là cả một kỳ công.

GFS gồm ba lớp: các GFS client sẽ xử lý các yêu cầu truy xuất dữ liệu của các ứng dụng; GFS master chuyên quản lý việc phân phối và theo dõi vị trí của các khối dữ liệu trên các cụm server (mỗi cụm chứa cùng loại dữ liệu), cũng như các file nằm trong đó (có thể nói dễ hiểu là các tiếp tân và một tay…thủ kho); cuối cùng chính là các server. Ngày trước, khi mà mọi thứ còn “đơn giản”, mô hình cơ bản sẽ là một master cho mỗi cụm server, các Client được đặt rải rác khắp nơi có thể liên lạc với bất kỳ Master nào khi cần. Nhưng hiện nay với nhu cầu ngày càng gia tăng của thế giới web, Google đã phải mở rộng mô hình phát triển một hệ thống master mới chuyên để quản lý các master cấp dưới, thông tin cụ thể về hệ thống này đáng tiếc lại chưa được hé lộ đầy đủ

Khi GFS client nhận được yêu cầu về một file dữ liệu từ một ứng dụng nào đó, nó sẽ gửi yêu cầu về thông tin vị trí của file này cho server master. Server master sẽ cung cấp vị trí của một trong các server/cụm server có chứa file đó (nhớ rằng các máy này đóng vai trò như các RAID trong hệ thống nhỏ mà ta thường gặp). Nếu việc kết nối thành công, GFS Client sẽ làm việc trực tiếp với server dữ liệu đó để lấy file, Master sẽ không tham gia vào quá trình giao tiếp này trừ khi có lỗi xảy ra buộc Client phải quay lại “cầu cứu”.

Để đổi lại tốc độ cung cấp dữ liệu, các kỹ sư thiết kế GFS quyết định đánh đổi một phần tính nhất quán (consistency) của hệ thống. Hệ thống vẫn chịu lỗi tốt, vì như đã nói nếu có trục trặc trong quá trình ghi mọi thứ liên quan sẽ được rollback, đồng thời Client có thể sẽ được cung cấp một địa chỉ lưu trữ khác để tìm cách ghi dữ liệu đó lần nữa nếu trục trặc tiếp tục xảy ra. Nhưng do Master không trực tiếp theo dõi quá trình trao đổi giữa Client và các server dữ liệu, các thao tác “ghi” mà Client thực hiện trên một server sẽ không lập tức được đồng bộ với các bản sao của nó trong cùng cụm đó. Giải pháp của Google cho vấn đề này là “relaxed consistency model” (Tạm dịch: mô hình nhất quán lỏng). Nói một cách đơn giản thì lý thuyết này cho rằng nếu nhu cầu đang cấp thiết thì cung cấp cho Client địa chỉ của một server chứa dữ liệu hơi cũ cũng… chẳng sao, miễn sao sau đó các thay đổi trên khối dữ liệu sẽ được đồng bộ vào…một lúc nào đó. Theo từng chu kỳ, Master sẽ tìm kiếm thay đổi trên các khối dữ liệu của các server (được quản lý theo “phiên bản” – version) và bảo đảm việc đồng bộ được diễn ra thường xuyên nhất có thể mà vẫn không làm Client phải chờ lâu. Nếu có một server dữ liệu nào đó tụt lại quá xa – ví dụ như có quá nhiều khối dữ liệu cũ hoặc một khối nào đó quá cũ, Master sẽ bảo đảm nó không được “giới thiệu” cho Client nữa đến khi được cập nhật bằng bạn bằng bè.

Nhưng vẫn còn hai vấn đề, tại thời điểm Master phát hiện ra kẻ “tụt hậu” này, các phiên làm việc của Client với nó vẫn tiếp diễn. Client sẽ không biết được các dữ liệu trên đó là phiên bản cũ cho đến khi Master cập nhật cơ sở dữ liệu của mình. Bản thân cơ sở dữ liệu này của Master cũng được sao lưu ra nhiều nơi phòng khi Master hỏng, và không có Master thì các cụm server dữ liệu đó sẽ trở nên vô dụng. Tuy nhiên các thay đổi mà Client thực hiện trên dữ liệu tại thời điểm Master “thăng” cũng sẽ mất và gây ảnh hưởng đến tính nhất quán, bất kể có backup thường xuyên thế nào đi chăng nữa. Một lần nữa điều này được giải quyết bằng lý thuyết chứ không phải bằng một công nghệ đột phá gì: đại đa số các dữ liệu phục vụ việc tìm kiếm không cần phải được cập nhật mới với tốc độ quá khủng khiếp (đó cũng là lí do cho phát biểu ở trên: việc lấy lượng lớn dữ liệu ra mới là quan trọng”), và các thay đổi thường là bổ sung dữ liệu mới, chứ không phải thay thế dữ liệu cũ. Hai vấn đề cùng được giải quyết chỉ bằng một lý luận ngắn gọn này, nhưng rốt cuộc điều đó chỉ đúng với bộ máy tìm kiếm mà thôi.

Bigtable

Như bạn đọc cũng đoán được, khi Google bổ sung các dịch vụ khác như Youtube, Google Docs .v.v.. việc chỉ dựa vào một hệ thống quản lý dữ liệu theo từng khối, tại không chú trọng tính nhất quán là hoàn toàn không phù hợp. Để giải quyết vấn đề này, trên nền GFS hãng đã bổ sung Bigtable, công nghệ quản lý dữ liệu có dạng như một cơ sở dữ liệu. Mọi thứ được quản lý dưới dạng "bảng" (table) (cũng là lý do nhiều người coi BigTable có dạng như cơ sở dữ liệu dù rằng nói chính xác thì không phải vậy). Với hàng tỷ (vâng, hàng tỷ) webpage cần được lưu, các BigTable có tên hàng là các URL và các đặc tính liên quan của webpage đó (keyword, ngôn ngữ .v.v... ) làm tên các cột. Nội dung của trang đó sẽ được lưu vào các ô tương ứng với thông tin về thời điểm ghi, phiên bản (timestamp). Về cơ bản, cách mà Bigtable xử lý dữ liệu cũng vẫn khá giống GFS: ưu tiên việc đọc dữ liệu hơn và các thay đổi chủ yếu được thực hiện dưới dạng bổ sung, đi kèm là một chỉ số "phiên bản" chứ không trực tiếp thay đổi các dữ liệu cũ (kể cả là các dữ liệu cho dịch vụ dạng Google Docs cũng được quản lý theo dạng này). Tuy vậy cách tổ chức dạng bảng này cũng đủ khác biệt để giúp khắc phục các khó khăn trước đó mà Google gặp phải khi mở rộng số lượng dịch vụ mà chỉ dựa vào GFS. Như chúng ta đều thấy, các dịch vụ mail, video, calendar.v.v.. chúng ta đang sử dụng ngày nay được cập nhật mới khá chính xác. Đi sâu hơn về chi tiết kỹ thuật, Bigtable sẽ khá khó hiểu cho những ai không có nền tảng về cơ sở dữ liệu cũng như hệ thống thông tin nói chúng, vì vậy chúng ta sẽ từ biệt Google ở đây để chuẩn bị "nhòm ngó" Amazon và Microsoft trong các bài sắp tới.

Phần 2: Amazon

GenK - Nếu đem so sánh với Google thì Amazon - với hệ thống dịch vụ bán lẻ của mình - phải giải quyết rất nhiều vấn đề liên quan đến việc truy cập dữ liệu của các ứng dụng. Cơ cấu của hệ thống Dynamo mà hãng này sử dụng thực tế chưa bao giờ được chính thức công bố. Tuy vậy dựa trên những gì mà CTO (Chief Technology Officer) Werner Vogels của hãng này trình bày trên blog của mình hồi năm 2007, kết hợp với những thông tin về dịch vụ cơ sở dữ liệu DynamoDB của Amazon (ra mắt hồi 18/1 vừa rồi), chúng ta vẫn có thể phần nào nắm được cách mà hệ thống này vận hành.

Cũng là một gương mặt lớn trong thế giới công nghệ, hệ thống phần cứng mà Amazon đầu tư để phục vụ khách hàng có thể chưa đồ sộ được bằng Google, nhưng chắc chắn vẫn thừa sức khiến các datacenter thông thường phải ngả mũ kính nể. Điểm chung lớn nhất giữa Dynamo của Amazon và GFS của Google là việc chấp nhận đánh đổi một phần tính nhất quán của dữ liệu để có được tốc độ truy xuất, xử lý cao.

Tuy vậy, do dịch vụ chủ đạo của 2 hãng có khác biệt rất lớn (tìm kiếm vs bán lẻ), cách mà Dynamo và GFS “đối đãi” với dữ liệu cũng rất khác nhau. Hệ thống bán lẻ của Amazon cần cung cấp mọi thông tin sẵn có về một sản phẩm mà khách hàng yêu cầu, cũng như hiển thị mọi thông tin liên quan đến giao dịch như địa chỉ giao hàng, thông tin thanh toán .v.v... ngay trên môi trường web mà khách hàng đang thao tác.

Với những yêu cầu này, việc chỉ chú trọng đọc dữ liệu theo từng khối như GFS chắc chắn là không phù hợp, thay vào đó Dynamo cần đảm cho phép các ứng dụng web truy cập ngẫu nhiên đến từng file nhỏ nhất trên hệ thống trong mọi thời điểm. Tại hội nghị về nguyên lý hệ điều hành hồi tháng 10/2007, Vogel và nhóm kỹ sư của mình cho biết “Dynamo hướng đến việc quản lý các đối tượng dữ liệu rất nhỏ - thường có dung lượng chỉ dưới 1MB”.

Hơn thế nữa, thay vì được tối ưu phục vụ việc đọc dữ liệu, Dynamo luôn luôn ở trạng thái sẵn sàng để nhận các dữ liệu mới – nói cách khác là hướng tới việc cho phép các ứng dụng bên ngoài ghi dữ liệu bất cứ khi nào cần. Trái ngược hoàn toàn với GFS của Google trên đó các ứng dụng bên ngoài thường xuyên cần đọc dữ liệu để phân tích kết quả tìm kiếm cho người dùng. Như nhóm nhóm kỹ sư của Vogel đã viết trong buổi hội thảo “Trên đa số các dịch vụ của Amazon, việc chậm cập nhật thông tin mà người dùng nhập vào sẽ khiến chất lượng dịch vụ giảm đi rất nhiều trong mắt khách hàng. Ví dụ, tình trạng giỏ hàng của khách hàng cần được cập nhật chính xác mỗi khi học thực hiện bổ sung hoặc loại bỏ một sản phẩm trong đó, thậm chí ngay cả khi hệ thống server đang gặp trục trặc.”

Cách xử lý tính nhất quán của dữ liệu trên đây cũng có nét đặc biệt: quá trình kiểm tra tính nhất quán và đồng bộ dữ liệu sẽ chỉ được thực hiện khi phần dữ liệu đó được đọc ra, chứ không phải ngay khi ghi vào. Với cách tiếp cận này, mọi thao tác ghi của các ứng dụng sẽ không bao giờ bị từ chối (ít nhất là không bị từ chối vì các lý do về mặt đồng bộ), bất kể đó là thao tác ghi để bổ sung dữ liệu mới, hay ghi đè/thay đổi dữ liệu cũ.

Về giải pháp phân phối dữ liệu trên các thiết bị lưu trữ, do trước đó đã không ít lần phải dỡ khóc dở cười với phương pháp quản trị tập trung mỗi khi server quản trị (master) gặp sự cố, các kỹ sư của Amazon đã quyết định chuyển sang các phương pháp phân tán. Cũng đồng thời để tăng sự thuận tiện mỗi khi cần mở rộng hệ thống (số lượng dịch vụ mà Amazon bổ sung hàng năm vẫn đang tăng một cách chóng mặt). Hoàn toàn trái ngược với GFS, có thể nói hệ thống Dynamo mang nhiều nét của mô hình mạng ngang hàng peer-to-peer, thay vì dạng master-slave.

Dữ liệu của từng cụm lưu trữ của Dynamo được quản lý trên một vòng không gian địa chỉ, và mỗi đơn vị lưu trữ (bài viết gốc không nói rõ mỗi đơn vị này là ổ cứng, HDD stage rack hay server như Google) sẽ chịu trách nhiệm cho một phần của vòng không gian đó. Để dễ hình dung, hãy tưởng tượng không gian địa chỉ này là một chiếc hộp tròn được chia ngăn theo dạng các lát cắt bánh để cất đồ, và mỗi đơn vị lưu trữ kể trên là một ngăn trong đó.

Nếu bạn đã từng đọc qua hay xem hình ảnh về cấu trúc phiến đĩa HDD, cũng có thể nói nôm na đây là một đĩa cứng khổng lỗ trong đó dữ liệu được ghi theo từng sector hình học (Geometrical sector). Đồng thời, để đảm bảo gánh nặng công việc được phân chia một cách hợp lý giữa các đơn vị lưu trữ (từ đây sẽ gọi là node) cũ và mới; Amazon đã thiết kế để một node vật lý có thể được chia làm nhiều node ảo, cùng lúc đảm nhiệm vị trí trên nhiều cụm. Đến đây dường như ta đã có thể phần nào kết luận các node này là các server, tương tự GFS. Cũng tương tự như việc một nhân viên giỏi, năng động có thể cùng lúc nhận việc trong nhiều nhóm để tận dụng được hết năng lực.

Mỗi khi một node mới được bổ sung vào “bàn tròn” này, nó sẽ được cấp một giá trị đại diện cho vị trí, thứ tự của nó trong đó và sẽ bắt đầu chịu trách nhiệm cho một phần không gian nhớ. Các node có vị trí “bên cạnh” node mới đó sẽ phải co giãn đôi chút để điều chỉnh cho phù hợp. Cần nhớ rằng: mỗi node chịu trách nhiệm quản lý cho một lát cắt của không gian địa chỉ, còn dữ liệu trên các lát cắt riêng biệt vẫn có thể được sao lưu cho nhau – nếu không thì khả năng sao lưu, chịu lỗi của hệ thông Dynamo này sẽ chỉ là con số không to tướng. Nếu bạn chưa hiểu ý nghĩa của điều này, hãy nhìn vào hình minh họa của Amazon và xem tiếp giải thích về cơ chế ghi dữ liệu của Dynamo phía dưới:

Khi có yêu cầu “ghi” một đối tượng dữ liệu (một đoạn lời bình, hay một file hình ảnh.v.v.) vào hệ thống Dynamo, hệ thống sẽ gán cho nó một (khóa) key riêng biệt. Khóa này lại tiếp tục được sử dụng để sinh một chuỗi MD5 128-bit độc nhất, giá trị của chuỗi MD5 sẽ được dùng để xác định vị trí (hay đúng hơn là địa chỉ) mà dữ liệu đó sẽ được ghi trên vòng không gian nói trên. Đến đây, node chịu trách nhiệm cho vị trí đó sẽ làm mọi phần việc còn lại: cho phép thao tác “ghi” đó được tiến hành trên bản thân nó, đồng thời nhắc nhở các node xung quanh nó trong cụm chấp nhận thao tác ghi này (việc các node khác có lập tức chấp nhận hay không còn phụ thuộc vào tình trạng của chúng trong thời điểm đó). Như vậy dữ liệu sẽ được trải đều trên miếng bánh. Môĩ khi có sự cố xảy ra với một node, 2 người hàng xóm bên cạnh nó sẽ ngay lập tức nhận trách nhiệm cho phần địa chỉ mà node đó đang quản lý.

Lại nói tiếp về quá trình kiểm tra đọc dữ liệu từ Dynamo. Khi có yêu cầu “đọc” dữ liệu từ các ứng dụng bên ngoài, các thiết bị quản lý request (tương tự GFS client) trong hệ thống Dynamo sẽ gọi để kiểm tra xem node nào có chứa dữ liệu đó. Tất cả các node có chứa một bản sao của dữ liệu đó sẽ phản hồi, dĩ nhiên là kèm theo cả thông tin về “phiên bản” của dữ liệu mà chúng lưu.

Tùy theo tính chất từng loại request, thiết bị quản lý request (request handler) sẽ có cách xử lý khác nhau với các phản hồi này. Nếu dữ liệu đang được yêu cầu thuộc vào loại “có là được”, không cần quá chính xác (ví dụ như các file icon hình ảnh phục vụ giao diện), node đầu tiên trả lời sẽ lập tức được đưa vào sử dụng. Ngược lại mếu ứng dụng đang yêu cầu đọc thuộc vào nhóm cần dữ liệu mới nhất, chính xác nhất (ví dụ như ứng dụng quản lý giỏ hàng), request handler sẽ chờ tất cả các node phản hồi để đảm bảo tìm được ứng cử viên phù hợp nhất.

Ngoài ra, để đảm bảo đồng bộ dữ liệu, mỗi khi nhận được phản hồi từ nhiều node cho cùng một đối tượng dữ liệu, request handler sẽ ghép các thay đổi không xung khắc trên đó (ví dụ như thay đổi trên dòng 13 từ node A, thay đổi trên dòng 15 từ node B của cùng một file text sẽ được ghép vào với nhau); hoặc sẽ thông báo cho các node chứa dữ liệu với “phiên bản” quá cũ biết rằng nó cần cập nhật file đó từ đâu . Mỗi khi một node được thay thế bởi một thiết bị mới hơn, nó sẽ được ưu tiên cập nhật dữ liệu mới nhất từ các hàng xóm xung quanh.

Mô hình này đã được thực tế chứng minh là có khả năng hoạt động ổn định trong phần lớn các trường hợp, kể cả khi xảy ra trục trặc nho nhỏ trong hệ thống. Lần trục trặc duy nhất là vào tháng 8/2011 khi mà một số kỹ sư mạng của Amazon khi nâng cấp router đã sai sót khi chuyển hướng lưu lượng mạng để nâng cấp router. Lưu lượng cho việc sao chép dữ liệu của các node trong mô hình này là cực lớn, và sai sót khi chuyển hướng dòng chảy khổng lồ này vào một số thiết bị mạng yếu vốn chỉ dùng để phục vụ việc “bắt tay” giữa các node đã khiến toàn bộ các website của Amazon gặp trục trặc trong một thời gian ngắn. Nói chung, tuy Dynamo là một mô hình hiệu quả và đã tạo cảm hứng cho rất nhiều mô hình dữ liệu khác như Cassandra của facebook, đây không phải là một kiến trúc mà các datacenter hạng vừa, với nguồn lực tài chính, thiết bị cũng như nhân sự yếu kém có thể mơ đến.

Phần 3: Microsoft

GenK - Khi Microsoft bắt đầu triển khai mô hình dịch vụ nền tảng (platform-as-a-service hay PaaS) Azure, hãng này cũng phải đối mặt với vấn đề tương tự Amazon: một lượng cực lớn dữ liệu sẽ được rất nhiều ứng dụng sử dụng chung. Do là một mô hình PaaS, các chi tiết kỹ thuật của Azure được giấu kín, thậm chí còn kín hơn các thông tin về Dynamo. Một điều chúng ta có thể chắc chắn là: không như GFS của Google hay Dynamo của Amazon, Azure được xây dựng hướng nhiều hơn tới việc phục vụ các dịch vụ đám mây cho khách hàng của Microsoft, hơn là ưu tiên tối ưu cho các tác vụ trong nội bộ hệ thống.

Trên một số phương diện, vẫn có thể nói rằng Azure có nhiều điểm chung với Dynamo: nó được thiết kế để có khả năng cung cấp khả năng truy cập, chỉnh sửa dữ liệu ở cấp độ từng file nhỏ, dưới nhiều định dạng chứ không hướng tới từng “khối” như Google. Tuy nhiên cách phân phối dữ liệu gần như là một giải pháp lai giữa mô hình của Google và Amazon, trong đó tầng logic và vật lý của quá trình lưu trữ được tách ra riêng biệt. Cụ thể hơn, hãy nhìn vào hình minh họa sau đây:

Theo như những gì kỹ sư Brad Calder của Microsoft đã mô tả trong bài viết về Azure trên blog của mình, Azure sử dụng hệ thống khóa (key) xoay quanh MD5 hash tương tự như Dynamo để lưu trữ vị trí logic của dữ liệu trên hệ thống. Tuy nhiên trong Azure các dịch vụ hay ứng dụng bên ngoài sẽ không được trực tiếp giao tiếp với các node lưu trữ, thay đó các kết nối được thiết lập thông qua một lớp trung gian có chứa thông tin về các khóa, hay vị trí dữ liệu này. Microsoft thiết kế lớp trung gian này với nhiều server riêng biệt, load-balancing (cân bằng tải) các request giữa các server này để đảm bảo tốc độ phản hồi được tối ưu. Các front-end server này tiếp nhận mọi giao tiếp với ứng dụng bên ngoài, cũng như thực hiện mọi giao tiếp cần thiết với tầng tiếp theo của hệ thống, trên đó các dữ liệu được lưu trữ.

Mỗi cụm lưu trữ logic trong Azure lại được quản lý bởi một máy chủ riêng biệt (partition server – máy chủ phân vùng), chịu trách nhiệm theo dõi xem “extent” nào trong cụm đó chứa dữ liệu cần tìm. Các extent là các khối dữ liệu kích thước khoảng vài Gigabytes, được máy chủ này phân phối trải đều trên các phân vùng lưu trữ. Để bù đắp lại điểm yếu của việc các request phải qua nhiều bước mới tiếp cận được dữ liệu. Các máy chủ phân vùng nói trên cũng thường xuyên lựa chọn các extents phù hợp để đưa vào bộ nhớ đệm (cache). Như vậy, các request lặp lại đến từ front-end server, ví dụ như các request đến các file giao diện web thường xuyên được sử dụng, sẽ được phản hồi với tốc độ nhanh hơn nhiều,

Mọi thay đổi trên các phân vùng dữ liệu lại đồng thời được ghi lại trên một máy chủ “partition master”, để dảm bảo rằng vị trí vật lý của dữ liệu được bảo lưu trong trường hợp máy chủ phân vùng bị down. Nếu có một máy chủ phân vùng nào đó bị trục trặc, quyền quản lý mọi phân vùng mà nó đảm nhiệm sẽ tạm thời được chuyển sang cho partition master. Đồng thời, partition master cũng chịu trách nhiệm theo dõi tải (workload) của từng cụm lưu trữ và các máy chủ phân vùng trong hệ thống Azure. Nếu có một máy chủ phân vùng nào đó đang chịu tải quá nặng, partition master sẽ lập tức tiến hành yêu cầu phân phối lại dữ liệu ở cấp logic để chuyển bớt tải đó sang một cụm phân vùng khác.

Không như nhiều hệ thống file lớn khác, Azure của Microsoft rất chú trọng đến tính toàn vẹn của dữ liệu. Việc đồng bộ, sao lưu một extent trên các phân vùng khác nhau được thực hiện khi có thao tác ghi lên hệ thống, thông qua sự quản lý của một nhóm máy chủ khác: Máy chủ DFS. Một máy chủ DFS có thể là máy chủ chính (primary) của một extent, nhưng lại là máy chủ phụ (secondary) cho các extent khác (Lưu ý các extent ở đây nói đến từng khối dữ liệu nằm trên các phân vùng khác nhau, nghĩa là chúng có thể là bản sao của nhau chứ không nhất thiết là các dữ liệu khác nhau). Khi một máy chủ phân vùng cần thực hiện một thao tác “ghi”, nó sẽ liên lạc với máy chủ DFS chính của extent đang cần được ghi. Máy chủ DFS chính này sẽ gửi tiếp yêu cầu này cho các Máy chủ DFS phụ của extent đó để bảo đảm tất cả các bản sao của extent đó trên tất cả các phân vùng được cập nhật. Thao tác ghi chỉ được ghi nhận là “thành công” nếu có ít nhất 3 máy chủ DFS phụ thông báo ghi thành công

Tương tự như cách partition master theo dõi các máy chủ phân vùng, các máy chủ phân vùng này cũng thường xuyên theo dõi tình trạng của các Máy chủ DFS trong cụm mà nó quản lý để bảo đảm nó không bị quá tải. Khi tải của một máy chủ DFS nào đó lên quá cao, máy chủ phân vùng sẽ ưu tiên chuyển thao tác ghi cho một trong các máy chủ DFS phụ của các extent mà nó quản lý trước để giảm tải.

Tổng kết

Các hệ thống dữ liệu phân tán không hẳn sẽ bảo đảm thời gian uptime hoàn hảo cho tất cả các loại dịch vụ. Trong phần lớn trường hợp, dữ liệu tuy được sao lưu trên nhiều thiết bị lưu trữ nhưng các thiết bị này vẫn nằm chung trong một datacenter. Lấy ví dụ như trường hợp datacenter đó gặp thảm họa lớn như tại Nhật Bản năm trước, dữ liệu vẫn có thể bị tổn thất như thường. Hoặc đối với các mô hình sử dụng nhiều master như GFS và Azure, chỉ cần một switch hoặc router trong hệ thống thất bại trong việc chuyển hướng quản lý cho các master backup mỗi khi một master chính có trục trặc, hoạt động của hệ thống cũng sẽ phải ngừng lại. Hồi tháng 8 vừa rồi, datacenter tại Dublin (US) của cả Microsoft và Amazon đều đã ngừng hoạt động do một vụ nổ trạm biến thế, và cả hai hãng đã phải khá chật vật để khắc phục hậu quả cũng như để bảo đảm các dịch vụ của mình có thể tiếp tục hoạt động như bình thường.

Tuy trên các hệ thống mà việc đồng bộ thay đổi của dữ liệu được đặt xuống hàng thứ yếu như GFS, việc sao lưu qua lại giữa các datacenter khác nhau có thể được thực hiện dễ dàng hơn đôi chút. Nhưng đó cũng là do bản chất của các ứng dụng, dịch vụ mà GFS cung cấp dữ liệu đến. Đối với các dạng dịch vụ mà dữ liệu thay đổi với tần suất lớn, giải pháp đồng bộ trực tiếp liên tục giữa các datacenter cực kỳ khó thực hiện do các ảnh hưởng về độ trễ, băng thông.v.v.

Để giải quyết vấn đề này, Microsoft có giới thiệu một giải pháp mới mang tên “geo-replication” hồi tháng 9 vừa rồi. Trong đó dữ liệu của người dùng sẽ được gửi đến hai datacenter khác nhau. Các dữ liệu trên hai server nói chung vẫn được lưu lại một cách không đồng bộ, nhưng ít nhất khách hàng cũng có một nơi truy cập thứ hai phòng khi một trong hai datacenter gặp sự cố. Tuy vậy giải pháp này vẫn có giới hạn về khoảng cách, ví dụ như tại Mỹ dữ liệu chỉ được sao lưu nếu hai datacenter nằm cùng một khu vực, Trung Mỹ chẳng hạn.

Đối với Amazon, việc sao lưu giữa các khu vực khác nhau được thực hiện bởi tầng dịch vụ, ứng dụng, chứ không được thực hiện bởi hệ thống Dynamo. Tuy vậy, các chi tiết của quá trình này vẫn hoàn toàn được giấu kín

Đó cũng là một trong các thách thức lớn nhất mà trong tương lai những người khổng lồ này phải đối mặt và giải quyết. Trong kỷ nguyên của "Big Data", giờ đây các bộ nhớ đệm sẽ được các ứng dụng và máy chủ xem như thành phần lưu trữ chính, còn hệ thống file là nơi mà các hoạt động trên hệ thống được ghi lại - là nơi lưu trữ theo đúng nghĩa của nó chứ không còn cho phép các ứng dụng tự do truy cập; vấn đề đặt ra vẫn luôn là làm sao để cải thiện tốc độ truy xuất của các ổ cứng cũng như tăng dung lượng bộ nhớ.