Tìm hiểu cách các đại gia công nghệ quản lý dữ liệu: Phần 3: Microsoft
Dịch vụ nền tảng Azure của Microsoft đượ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.
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.
Đọc thêm:
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ớ.
Đọc thêm:
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.
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ớ.
Tin cùng chuyên mục
Xem theo ngày
NỔI BẬT TRANG CHỦ
Chỉ bằng một clip 41 giây, MKBHD đưa một startup AI đầy triển vọng tới nguy cơ sụp đổ
Ngay từ tựa đề, MKBHD đã gọi thiết bị AI này là "sản phẩm tồi tệ nhất mà tôi từng đánh giá ... cho đến nay".
Biểu cảm của Tim Cook khi thấy AI giả chính mình
