Tiêu chí lựa chọn hệ thống lưu trữ dữ liệu nghiên cứu

Vì vậy, việc lựa chọn nên bắt đầu bằng câu hỏi “hệ thống có đáp ứng đúng đặc tính và vòng đời của dữ liệu hay không?” thay vì “hệ thống nào có dung lượng lớn nhất?” hoặc “nên dùng cloud hay máy chủ nội bộ?”. Một giải pháp chỉ thực sự phù hợp khi các đặc tính kỹ thuật, quản trị và tài chính của nó khớp với yêu cầu thực tế của dự án.

Xác định yêu cầu dữ liệu trước khi chọn hệ thống

Tiêu chí đầu tiên không nằm ở bản thân sản phẩm lưu trữ mà nằm ở dữ liệu cần lưu. Hai dự án đều tạo ra 10 TB dữ liệu nhưng có thể cần kiến trúc hoàn toàn khác nhau nếu một dự án tạo vài nghìn tệp ảnh rất lớn, còn dự án kia tạo hàng triệu tệp nhỏ cần được truy cập liên tục. NIST RDaF cũng tách riêng các yêu cầu về lưu trữ, tính toán, mạng, bảo mật và hạ tầng bởi chúng phụ thuộc vào nhu cầu nghiên cứu của tổ chức và từng giai đoạn trong vòng đời dữ liệu.

Trước khi đánh giá hệ thống, cần định lượng ít nhất các thông số sau:

·         Dung lượng dữ liệu hiện tại và dung lượng dự kiến khi dự án kết thúc

·         Tốc độ tăng dữ liệu theo tháng hoặc theo năm

·         Số lượng tệp và kích thước tệp điển hình

·         Kích thước tệp lớn nhất có thể phát sinh

·         Tần suất đọc, ghi và sửa dữ liệu

·         Số người hoặc hệ thống cần truy cập đồng thời

·         Thời gian dữ liệu cần được duy trì

·         Mức độ nhạy cảm hoặc hạn chế truy cập của dữ liệu

·         Nhu cầu sử dụng dữ liệu sau khi dự án kết thúc

Cách tiếp cận này quan trọng vì “1 TB dung lượng” chỉ phản ánh một biến số. Một nghiên cứu mô phỏng có thể cần tốc độ ghi cao trong một khoảng thời gian ngắn; nghiên cứu ảnh y sinh có thể cần dung lượng lớn và kiểm soát truy cập chặt; nghiên cứu xã hội có thể đặt nặng bảo vệ thông tin nhận dạng; còn bộ dữ liệu đã công bố lại ưu tiên khả năng truy xuất, metadata và bảo tồn dài hạn.

Cũng cần phân biệt lưu trữ dữ liệu đang hoạt động với lưu trữ hoặc bảo tồn dài hạn. Dữ liệu đang được phân tích thường cần tốc độ truy cập, khả năng sửa đổi và tích hợp với công cụ nghiên cứu. Sau khi dự án hoàn tất, trọng tâm có thể chuyển sang tính toàn vẹn, khả năng tìm kiếm, metadata, thời gian lưu giữ và khả năng tiếp tục truy cập nhiều năm sau. NIST RDaF xem “Process/Analyze” và “Preserve/Discard” là những giai đoạn khác nhau của vòng đời, với các yêu cầu lưu trữ liên quan nhưng không đồng nhất.

Do đó, không nhất thiết một hệ thống duy nhất phải tối ưu cho mọi giai đoạn. Điều quan trọng là xác định trước hệ thống được lựa chọn sẽ đảm nhiệm vai trò nào trong vòng đời dữ liệu.

Bảo mật, quyền truy cập và tuân thủ

Với dữ liệu nghiên cứu, bảo mật phải được đánh giá theo độ nhạy cảm của dữ liệu và hậu quả khi xảy ra sự cố, không chỉ theo việc nhà cung cấp có tuyên bố “mã hóa” hay không. NIST RDaF gắn lựa chọn kiến trúc lưu trữ với bảo mật, quyền truy cập, dữ liệu nhạy cảm, thông tin nhận dạng cá nhân và yêu cầu tuân thủ.

Một hệ thống phù hợp cần cho phép trả lời rõ các câu hỏi: ai được xem dữ liệu, ai được chỉnh sửa, ai có quyền chia sẻ, ai quản trị hệ thống và liệu các hành động quan trọng có thể được truy vết hay không. Với nhóm nghiên cứu có nhiều thành viên hoặc nhiều tổ chức tham gia, việc chỉ có hai trạng thái “có quyền/không có quyền” thường không đủ; cần xem khả năng phân quyền theo vai trò, nhóm, dự án hoặc tập dữ liệu.

Các cơ chế nên được xem xét gồm:

·         Xác thực người dùng phù hợp với chính sách của tổ chức

·         Phân quyền theo nguyên tắc quyền tối thiểu cần thiết

·         Mã hóa dữ liệu nhạy cảm khi lưu trữ

·         Bảo vệ dữ liệu khi truyền qua mạng

·         Quản lý khóa mã hóa phù hợp

·         Nhật ký truy cập và thay đổi

·         Khả năng thu hồi quyền nhanh chóng khi thành viên rời dự án

·         Chính sách xử lý bản sao, snapshot và dữ liệu sao lưu

·         Vị trí lưu dữ liệu khi có yêu cầu về khu vực pháp lý hoặc tổ chức

NIST SP 800-209 khuyến nghị giới hạn quyền truy cập xuống mức tối thiểu cần thiết và xem mã hóa dữ liệu khi lưu trữ cũng như khi truyền là những thành phần của bảo vệ hạ tầng lưu trữ. Tài liệu này cũng nhấn mạnh vai trò của audit log trong việc phát hiện và điều tra hành vi bất thường.

Một hiểu nhầm phổ biến là có mã hóa đồng nghĩa với hệ thống đã an toàn. Mã hóa chỉ giải quyết một nhóm rủi ro. Nếu tài khoản quản trị bị chiếm quyền, phân quyền cấu hình sai, khóa mã hóa được quản lý kém hoặc bản sao lưu cũng có thể bị sửa/xóa cùng với dữ liệu chính, hệ thống vẫn có thể gặp sự cố nghiêm trọng. Vì vậy, bảo mật phải được xem như sự kết hợp giữa xác thực, phân quyền, mã hóa, giám sát, sao lưu và quy trình quản trị.

Yêu cầu tuân thủ cũng không chỉ đến từ pháp luật. Chính sách của tổ chức, hội đồng đạo đức và nhà tài trợ có thể đặt ra điều kiện về quản lý, chia sẻ và bảo tồn dữ liệu. Chẳng hạn, chính sách Data Management and Sharing của NIH yêu cầu các dự án thuộc phạm vi áp dụng lập kế hoạch quản lý và chia sẻ dữ liệu, đồng thời thừa nhận các yếu tố pháp lý, đạo đức và kỹ thuật có thể giới hạn việc chia sẻ hoặc bảo tồn.

Vì thế, một tính năng bảo mật chỉ có giá trị khi nó phù hợp với mức phân loại dữ liệu và nghĩa vụ thực tế của dự án.

Dung lượng, khả năng mở rộng và hiệu năng

Dung lượng phải được đánh giá theo đường tăng trưởng dữ liệu, không phải chỉ theo nhu cầu tại ngày mua hệ thống. Nếu dự án đang có 5 TB nhưng tạo thêm 2 TB mỗi tháng, một giải pháp “đủ chỗ” ở thời điểm hiện tại có thể trở thành điểm nghẽn rất nhanh.

Thay vì chỉ hỏi hệ thống hỗ trợ tối đa bao nhiêu TB, nên xác định:

·         Dung lượng cần thiết ở thời điểm cao nhất

·         Tốc độ tăng dữ liệu

·         Khả năng mở rộng mà không phải di chuyển toàn bộ dữ liệu

·         Giới hạn kích thước từng tệp

·         Giới hạn số lượng đối tượng hoặc tệp nếu có

·         Thời gian cần thiết để bổ sung dung lượng

·         Ảnh hưởng của việc mở rộng đến hiệu năng và chi phí

Hiệu năng cũng phải gắn với kiểu công việc. Với tệp dữ liệu lớn được đọc tuần tự, throughput theo MB/s hoặc GB/s có thể quan trọng hơn độ trễ. Với hàng triệu tệp nhỏ hoặc workload có nhiều thao tác ngẫu nhiên, độ trễ và số thao tác I/O mỗi giây có thể trở thành biến số chính. Nếu dữ liệu phải thường xuyên chuyển sang cụm tính toán, tốc độ mạng và vị trí tương đối giữa storage với compute cũng ảnh hưởng trực tiếp đến thời gian xử lý. NIST RDaF đưa storage requirements, network requirements và compute requirements vào cùng nhóm cân nhắc cho hoạt động xử lý và phân tích dữ liệu.

Không có một giá trị throughput, IOPS hay latency duy nhất phù hợp cho mọi nghiên cứu. Cách đánh giá đáng tin cậy hơn là lấy workload thực tế hoặc một mẫu đại diện để đặt yêu cầu. Ví dụ, nếu một pipeline cần đọc 4 TB dữ liệu trong tối đa hai giờ, tiêu chí hiệu năng có thể được chuyển thành một yêu cầu đo được thay vì nhận xét chung chung rằng hệ thống phải “nhanh”.

Khả năng mở rộng cũng không nên được hiểu đơn giản là nhà cung cấp cho phép mua thêm dung lượng. Cần xem việc mở rộng có giữ nguyên cách truy cập, phân quyền, sao lưu và chi phí vận hành hay không. Một hệ thống có thể mở rộng về số TB nhưng trở nên khó quản trị hoặc quá tốn kém ở quy mô lớn hơn.

Do đó, ba câu hỏi cần được tách biệt: có chứa được dữ liệu không, có phục vụ workload đủ nhanh không và có tiếp tục làm được hai việc đó khi dữ liệu tăng lên không.

Sao lưu, khôi phục và toàn vẹn dữ liệu

Lưu trữ chính và sao lưu không phải là một khái niệm. Một hệ thống có RAID, replication hoặc nhiều ổ đĩa vẫn cần được đánh giá riêng về khả năng khôi phục sau khi dữ liệu bị xóa nhầm, mã hóa bởi ransomware, hỏng logic hoặc bị thay đổi ngoài ý muốn.

Hai chỉ số thực tế giúp biến yêu cầu phục hồi thành tiêu chí đo được là RPO và RTO. RPO thể hiện lượng dữ liệu tối đa có thể chấp nhận mất tính theo thời gian; RTO thể hiện yêu cầu về tốc độ khôi phục. NIST SP 800-209 khuyến nghị công nghệ sao lưu và bản sao dữ liệu phải phù hợp với RPO/RTO của từng tài sản dữ liệu, đồng thời yêu cầu kiểm thử khôi phục định kỳ để xác nhận hệ thống thực sự đạt mục tiêu đó.

Ví dụ, nếu một thiết bị thí nghiệm tạo dữ liệu liên tục và nhóm chỉ chấp nhận mất tối đa một giờ dữ liệu, RPO phải phản ánh giới hạn đó. Nếu nghiên cứu có thể dừng tối đa bốn giờ sau sự cố, RTO phải được đặt ở mức tương ứng. Khi hai mục tiêu trở nên nghiêm ngặt hơn, chi phí và độ phức tạp của hệ thống thường cũng tăng, vì cần bản sao thường xuyên hơn, hạ tầng phục hồi nhanh hơn hoặc nhiều mức dự phòng hơn. NIST SP 800-209 cũng yêu cầu cân bằng yêu cầu tốc độ phục hồi với chi phí để đạt được tốc độ đó.

Khi đánh giá phương án lưu trữ, nên kiểm tra:

·         Tần suất tạo bản sao

·         Số phiên bản dữ liệu có thể phục hồi

·         Thời gian giữ các bản sao

·         Có bản sao nằm ngoài hệ thống sản xuất hay không

·         Có khả năng cách ly hoặc bảo vệ bản sao khỏi sửa/xóa trái phép hay không

·         Thời gian phục hồi một tệp và cả tập dữ liệu lớn

·         Quy trình kiểm thử restore

·         Khả năng xác minh dữ liệu sau khi phục hồi

UK Data Service khuyến nghị sao lưu dữ liệu nghiên cứu đang hoạt động một cách thường xuyên, duy trì nhiều bản sao ở các vị trí tách biệt, mã hóa bản sao khi làm việc với dữ liệu nhạy cảm và kiểm tra định kỳ khả năng khôi phục.

Bên cạnh khả năng phục hồi là toàn vẹn dữ liệu. Dữ liệu phục hồi được nhưng đã bị hỏng âm thầm vẫn có thể làm sai kết quả nghiên cứu. NIST RDaF xem checksum và kiểm tra fixity là những hoạt động của data curation, giúp xác nhận đối tượng dữ liệu vẫn giữ nguyên qua thời gian.

Vì vậy, tiêu chí tốt không phải “có backup hay không”, mà là backup có độc lập đủ, có thể phục hồi trong thời gian yêu cầu và dữ liệu phục hồi có được xác minh hay không.

Truy cập, cộng tác và tích hợp quy trình nghiên cứu

Một hệ thống lưu trữ có thể rất an toàn nhưng vẫn không phù hợp nếu việc đưa dữ liệu vào và lấy dữ liệu ra gây cản trở hoạt động nghiên cứu hàng ngày. NIST RDaF phân biệt truy cập nội bộ, truy cập bên ngoài và truy cập bằng chương trình, đồng thời đưa công cụ cộng tác, mạng và kiến trúc lưu trữ vào các yếu tố cần cân nhắc trong vòng đời dữ liệu.

Với nhóm nghiên cứu làm việc tại một địa điểm, yêu cầu có thể tương đối đơn giản. Nhưng khi có cộng tác viên ở nhiều tổ chức, làm việc từ xa hoặc cần pipeline tự động, cần đánh giá thêm:

·         Người dùng ngoài tổ chức có thể được cấp quyền an toàn hay không

·         Hệ thống có hỗ trợ nhóm và vai trò hay không

·         Có cơ chế truy cập bằng API hoặc giao thức phù hợp với công cụ nghiên cứu hay không

·         Việc truyền bộ dữ liệu lớn có thuận tiện và đủ nhanh hay không

·         Có thể truy cập trực tiếp từ môi trường tính toán hay phải tạo nhiều bản sao trung gian

·         Có hỗ trợ theo dõi phiên bản hoặc lịch sử thay đổi khi nhiều người cùng làm việc hay không

·         Quy trình cấp và thu hồi quyền có đủ đơn giản để nhóm thực hiện đúng chính sách hay không

Điểm cần cân bằng ở đây là tính thuận tiện và mức kiểm soát. Nếu việc truy cập quá khó, người dùng có xu hướng tạo bản sao ngoài luồng để làm việc thuận tiện hơn, khiến quản trị dữ liệu trở nên phức tạp. Ngược lại, nếu chia sẻ quá dễ mà không có giới hạn theo vai trò hoặc tập dữ liệu, nguy cơ cấp quyền rộng hơn mức cần thiết tăng lên.

Khả năng tích hợp cũng ảnh hưởng đến số lần phải sao chép dữ liệu. Nếu storage có thể được sử dụng trực tiếp bởi công cụ phân tích, notebook, cụm HPC hoặc workflow tự động của dự án, dữ liệu có thể đi qua ít bước trung gian hơn. Việc này cần được đánh giá bằng một workflow thực tế thay vì chỉ dựa vào danh sách giao thức mà hệ thống quảng bá.

Vì vậy, tiêu chí “dễ sử dụng” nên được chuyển thành những câu hỏi cụ thể: mất bao nhiêu bước để người có thẩm quyền truy cập dữ liệu, mất bao lâu để đưa một dataset điển hình vào pipeline và có bao nhiêu bản sao ngoài hệ thống chính được tạo ra trong quá trình đó.

Metadata, khả năng di chuyển và lưu trữ dài hạn

Giá trị của dữ liệu nghiên cứu không chỉ phụ thuộc vào việc các bit còn tồn tại. Sau vài năm, một tập dữ liệu không có metadata, nguồn gốc, đơn vị đo, điều kiện thí nghiệm hoặc cấu trúc tệp rõ ràng có thể rất khó diễn giải. NIST RDaF lưu ý rằng metadata phong phú hỗ trợ khả năng tìm kiếm, tương tác và tái sử dụng, trong khi metadata nghèo có thể khiến một bộ dữ liệu quan trọng trở nên khó sử dụng khi người tạo dữ liệu không còn sẵn sàng để giải thích nó.

Điều này tạo ra một tiêu chí thường bị bỏ qua khi lựa chọn storage: hệ thống có giúp duy trì bối cảnh của dữ liệu hay chỉ giữ tệp?

Tùy loại nghiên cứu, cần xem khả năng:

·         Lưu metadata cùng dữ liệu

·         Duy trì thông tin provenance

·         Gắn định danh ổn định cho dataset hoặc đối tượng

·         Tìm kiếm theo metadata

·         Xuất metadata khi chuyển hệ thống

·         Giữ cấu trúc thư mục, quyền và thuộc tính cần thiết khi migration

·         Tích hợp với repository hoặc hệ thống quản lý dữ liệu khác

Các nguyên tắc FAIR xác định bốn mục tiêu đối với tài sản dữ liệu khoa học là Findable, Accessible, Interoperable và Reusable. FAIR không đồng nghĩa với việc mọi dữ liệu phải công khai; thay vào đó, nó nhấn mạnh khả năng tìm thấy, truy cập theo điều kiện xác định, tương tác và tái sử dụng dữ liệu một cách có hệ thống.

Khả năng di chuyển dữ liệu ra khỏi hệ thống cũng quan trọng không kém khả năng đưa dữ liệu vào. Khi đánh giá, cần biết liệu có thể xuất dữ liệu bằng giao thức hoặc định dạng thông dụng, khôi phục đầy đủ metadata và quyền cần thiết, cũng như ước tính thời gian và chi phí để chuyển toàn bộ dataset sang nền tảng khác. Nếu migration chỉ khả thi bằng một quy trình độc quyền hoặc chi phí lấy dữ liệu ra quá lớn, dự án có nguy cơ phụ thuộc sâu vào một nền tảng.

Đối với dữ liệu phải giữ lâu hơn tuổi thọ của dự án, cần đánh giá thêm chính sách retention, khả năng kiểm tra fixity, hỗ trợ định dạng bền vững, cơ chế migration khi công nghệ thay đổi và khả năng duy trì dịch vụ về dài hạn. NIST RDaF đặt longevity, support, funding model, file integrity và phương thức lưu trữ/bảo tồn vào nhóm vấn đề của giai đoạn Preserve/Discard.

Một hệ thống tốt cho dữ liệu đang hoạt động vì thế chưa chắc là nơi tốt nhất để bảo tồn dữ liệu lâu dài. Khi yêu cầu hai giai đoạn khác nhau đáng kể, kiến trúc nhiều tầng — chẳng hạn storage phục vụ nghiên cứu đang diễn ra và repository phục vụ bảo tồn/công bố — có thể hợp lý hơn việc buộc một nền tảng thực hiện mọi nhiệm vụ.

Chi phí vòng đời, hỗ trợ và cách ra quyết định

So sánh hệ thống chỉ bằng giá mỗi TB dễ dẫn đến lựa chọn sai vì chi phí lưu trữ không kết thúc ở việc mua dung lượng. NIST RDaF xem chi phí và tính bền vững là vấn đề xuyên suốt vòng đời dữ liệu, bao gồm mô hình tài trợ, nhân sự, đào tạo, phân tích chi phí–lợi ích và cả chi phí phát sinh ở các giai đoạn sau của vòng đời.

Khi tính tổng chi phí sở hữu, cần xem xét những khoản phù hợp với mô hình đang đánh giá:

·         Chi phí dung lượng chính

·         Chi phí backup, snapshot và replication

·         Chi phí mạng và truyền dữ liệu

·         Chi phí lấy dữ liệu ra hoặc phục hồi từ tầng lưu trữ lạnh

·         Chi phí phần cứng thay thế nếu tự vận hành

·         Chi phí license và hỗ trợ

·         Công sức quản trị, giám sát và xử lý sự cố

·         Chi phí tăng dung lượng trong tương lai

·         Chi phí migration khi thay hệ thống

·         Chi phí duy trì dữ liệu sau khi dự án kết thúc

Một phương án có giá lưu trữ thấp nhưng yêu cầu nhiều nhân lực quản trị hoặc có chi phí migration cao có thể đắt hơn trong toàn bộ vòng đời. Ngược lại, hệ thống có giá đơn vị cao hơn đôi khi giảm được công việc vận hành hoặc cung cấp khả năng phục hồi phù hợp hơn. Vì vậy, nên so sánh theo chi phí trên cùng một mức dịch vụ và cùng thời gian sử dụng, thay vì chỉ so giá dung lượng.

Khả năng hỗ trợ cũng cần được xem như một phần của độ bền hệ thống. Cần xác định ai chịu trách nhiệm khi storage gặp sự cố, thời gian hỗ trợ, quy trình escalation, khả năng tiếp cận nhân sự kỹ thuật, cam kết duy trì nền tảng và phương án lấy dữ liệu ra nếu dịch vụ thay đổi hoặc chấm dứt. NIST RDaF đặt longevity, support, funding model và service-level agreements trong các vấn đề liên quan đến tính bền vững và sử dụng dữ liệu.

Để lựa chọn có hệ thống hơn, có thể chia tiêu chí thành hai tầng. Tầng bắt buộc là các điều kiện mà hệ thống không đáp ứng thì bị loại ngay, chẳng hạn không đáp ứng yêu cầu bảo mật của dữ liệu nhạy cảm, không đủ dung lượng tối thiểu hoặc không thể đáp ứng RPO/RTO cần thiết. Tầng chấm điểm dùng cho những tiêu chí có thể đánh đổi như hiệu năng cao hơn, thao tác thuận tiện hơn, chi phí thấp hơn hoặc khả năng tích hợp tốt hơn.

Trước khi chấm điểm, mỗi tiêu chí nên được chuyển thành một yêu cầu có thể kiểm tra. Thay vì “có backup tốt”, hãy đặt RPO, RTO và yêu cầu restore test. Thay vì “dễ mở rộng”, hãy xác định dung lượng dự kiến sau ba hoặc năm năm và quá trình bổ sung dung lượng. Thay vì “chi phí hợp lý”, hãy tính tổng chi phí trong thời gian dự án cộng với giai đoạn lưu giữ bắt buộc.

Một bộ tiêu chí lựa chọn thực tế vì thế nên trả lời được bốn câu hỏi cho từng phương án: hệ thống đáp ứng yêu cầu nào, bằng chứng nào chứng minh điều đó, giới hạn nằm ở đâu và chi phí để duy trì khả năng đó trong toàn bộ vòng đời dữ liệu là bao nhiêu. Khi bốn câu hỏi này được lượng hóa, việc lựa chọn sẽ ít phụ thuộc vào mô tả marketing và phản ánh sát hơn nhu cầu nghiên cứu.

Lựa chọn hệ thống lưu trữ dữ liệu nghiên cứu là bài toán phù hợp với mục đích, không phải cuộc tìm kiếm hệ thống có nhiều dung lượng hoặc nhiều tính năng nhất. Một phương án đáng lựa chọn phải đồng thời phù hợp với đặc tính dữ liệu, đáp ứng yêu cầu bảo mật và truy cập, đủ năng lực mở rộng, có cơ chế sao lưu–khôi phục kiểm chứng được, hỗ trợ workflow nghiên cứu và không cản trở việc bảo tồn hoặc di chuyển dữ liệu về sau.

Trong thực tế, nên bắt đầu bằng việc định lượng nhu cầu dữ liệu và xác định các điều kiện bắt buộc; sau đó mới so sánh hiệu năng, khả năng cộng tác, metadata, tính di động, hỗ trợ và tổng chi phí vòng đời. Cách đánh giá này giúp tránh ba sai lầm phổ biến: coi dung lượng là tiêu chí chính, coi backup là đồng nghĩa với bảo tồn và chọn giải pháp dựa trên giá ban đầu mà không tính đến chi phí cũng như rủi ro trong toàn bộ vòng đời dữ liệu.