Tìm hiểu cách các đại gia công nghệ quản lý dữ liệu: Phần 3: Microsoft

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ớ.