Mã hóa xóa (Erasure Coding) và độ bền dữ liệu trong lưu trữ phân tán

1. Tổng quan

A. Định nghĩa

Mã hóa xóa (Erasure Coding, EC) là kỹ thuật bảo vệ dữ liệu dựa trên mã sửa lỗi (error-correcting code), chia dữ liệu gốc thành k mảnh dữ liệu (fragment), sau đó bằng mã hóa toán học tạo thêm m mảnh dư thừa (chẵn lẻ - parity), lưu phân tán tổng cộng n (=k+m) mảnh, và cho phép khôi phục hoàn toàn dữ liệu gốc chỉ cần k mảnh bất kỳ còn tồn tại.

Bản chất của mã hóa xóa là cấy "tình huống dữ liệu bị xóa (erasure, mất mát trong đó biết vị trí nào bị mất nhưng không biết giá trị) trên kênh truyền" vào hệ thống lưu trữ. Mã Reed–Solomon phát triển từ lý thuyết truyền thông được áp dụng nguyên vẹn cho mô hình lỗi của phương tiện lưu trữ; vì sự cố đĩa·nút cho biết chính xác "mảnh đó đã mất", việc khôi phục hiệu quả hơn nhiều so với sửa lỗi thông thường không biết vị trí. Tức là EC là phương thức bố trí dư thừa gần tối ưu về mặt lý thuyết thông tin, đạt độ bền (durability) cao với chi phí dung lượng thấp.

B. Bối cảnh ra đời và sự cần thiết

Trong thời đại lưu trữ đám mây·đối tượng, tổng lượng dữ liệu phình to vượt petabyte lên exabyte, nhưng độ tin cậy của từng đĩa không cải thiện tương ứng. Theo truyền thống, lưu trữ phân tán bảo đảm độ bền bằng nhân bản 3 bản (3-replication). Nhân bản 3 bản dễ hiện thực và có tính cục bộ khi đọc tốt, nhưng chi phí lưu trữ tăng thêm 200% (1 bản gốc + 2 bản sao) là rất lớn. Ở quy mô hàng chục PB, chi phí 200% này đồng nghĩa với chi phí khổng lồ về đĩa·điện năng·không gian rack.

Mã hóa xóa đạt độ bền tương đương hoặc cao hơn với dư thừa ít hơn nhiều. Ví dụ, cấu hình RS(10,4) phổ biến gồm 10 mảnh dữ liệu + 4 mảnh chẵn lẻ = 14 mảnh, chi phí lưu trữ thêm chỉ 40% nhưng chịu được mất đồng thời 4 mảnh bất kỳ. So với nhân bản 3 bản chịu được mất tối đa 2 bản sao (trên cùng dữ liệu), EC cho phép nhiều sự cố đồng thời hơn với ít không gian hơn. Khi dữ liệu dung lượng lớn·ít truy cập (cold/warm) bùng nổ, yêu cầu tối đa hóa "độ bền trên chi phí" là động lực căn bản của sự lan rộng EC. Thực tế, f4 của Meta, Microsoft Azure, AWS S3, Google Colossus, Ceph, HDFS-EC đều đã chọn EC làm chuẩn cho tầng lưu trữ quy mô lớn.

Về căn bản, sự trỗi dậy của EC là vấn đề kinh tế học lưu trữ (storage economics). Ở quy mô vài EB, chênh lệch 1 điểm phần trăm chi phí lưu trữ quy đổi thành chênh lệch hàng nghìn đĩa cùng điện năng·làm mát·không gian rack·nhân lực vận hành đi kèm. Hạ chi phí 200% của nhân bản 3 bản xuống 40~50% của EC nghĩa là phần cứng cần để bảo vệ cùng lượng dữ liệu giảm xuống dưới một phần ba, và với các nhà cung cấp siêu quy mô, điều này dẫn đến tiết kiệm tổng chi phí sở hữu (TCO) hàng chục tỷ won mỗi năm. Đồng thời, phân phối dữ liệu đã thay đổi sao cho dữ liệu lạnh "được tạo ra nhưng hầu như không được đọc lại" chiếm phần lớn; với dữ liệu ít truy cập như vậy, hình phạt độ trễ có thể chấp nhận được và hiệu quả tiết kiệm chi phí lưu trữ được tối đa hóa, nên phạm vi áp dụng EC rất rộng. Tóm lại, EC là kết quả diễn giải lại công nghệ sửa lỗi của lý thuyết truyền thông cho phù hợp với yêu cầu của lưu trữ là phải bảo vệ dữ liệu bùng nổ một cách kinh tế.

C. Đặc điểm cốt lõi

Tính chất của EC được tóm tắt thành bốn điểm. Thứ nhất là hiệu quả không gian — mã MDS đạt giới hạn trên lý thuyết của độ bền so với dư thừa, cho cùng độ bền với không gian lưu trữ ít hơn nhiều so với nhân bản. Thứ hai là độ bền cao — bằng cách điều chỉnh m có thể thiết kế độ bền tinh vi để chịu được tới m sự cố đồng thời bất kỳ. Thứ ba là chi phí bất đối xứng — đọc thông thường rẻ nhưng khôi phục·đọc suy giảm·cập nhật một phần thì đắt. Thứ tư là phụ thuộc bố trí — chỉ khi phân tán các mảnh sang đủ nhiều miền sự cố thì độ bền lý thuyết mới thực sự được bảo đảm. Các đặc điểm này là căn cứ phán đoán "khi nào dùng EC và khi nào dùng nhân bản" sẽ được bàn ở phần sau.

2. Nguyên lý hoạt động và kiến trúc của mã hóa xóa

A. Nguyên lý cơ bản của mã hóa·giải mã

Nền tảng toán học của EC là đại số tuyến tính trên trường Galois (GF(2^w)). Coi k mảnh dữ liệu là vector D, nhân với ma trận sinh (generator matrix) G kích thước (k+m)×k để tạo n mảnh mã hóa C = G·D. Trong mã Reed–Solomon, k hàng trên của G là ma trận đơn vị (lưu nguyên bản gốc, systematic code), m hàng dưới được cấu thành từ ma trận Vandermonde hoặc Cauchy, được thiết kế sao cho chọn k hàng bất kỳ thì ma trận con đó đều khả nghịch (invertible). Nhờ tính chất này, chỉ cần có k mảnh bất kỳ là có thể nhân với ma trận nghịch đảo của ma trận con tương ứng để khôi phục duy nhất bản gốc D.

Điểm cốt lõi ở đây là tính chất MDS (Maximum Distance Separable). Mã MDS đạt giới hạn trên lý thuyết của độ bền so với dư thừa: "dù mất m mảnh bất kỳ trong n mảnh vẫn khôi phục được từ k mảnh còn lại". Reed–Solomon là mã MDS tiêu biểu, và đây là lý do căn bản khiến EC hiệu quả không gian hơn nhân bản. Khi giải mã, chỉ chọn các hàng tương ứng với mảnh còn sống để thực hiện phép nghịch đảo ma trận, nên trong môi trường lưu trữ biết vị trí bị xóa thì lượng tính toán giảm đáng kể.

Trực giác ở dạng đơn giản nhất là chẵn lẻ XOR cũng được dùng trong RAID. EC đặc biệt với m=1 chỉ đặt một P = D1 ⊕ D2 ⊕ D3 cho dữ liệu D1, D2, D3, nên dù một mảnh bất kỳ bị mất vẫn khôi phục được bằng XOR của các mảnh còn lại với P. Tuy nhiên m=1 không chịu được mất đồng thời 2 mảnh. Reed–Solomon tổng quát hóa ý tưởng này bằng phép toán đa thức·ma trận trên trường Galois, tạo ra m mảnh chẵn lẻ độc lập tuyến tính với nhau để mở rộng khả năng chịu mất đồng thời tới m mảnh bất kỳ. Tức là có thể hiểu chẵn lẻ XOR là trường hợp đặc biệt mỏng nhất của EC, còn RS là lời giải tổng quát nâng nó lên m tùy ý. Nhờ tính tổng quát này, hệ thống lưu trữ có thể tự do điều chỉnh m theo độ bền yêu cầu.

flowchart LR
  O["Đối tượng gốc"] --> SPLIT["Chia thành k mảnh dữ liệu"]
  SPLIT --> ENC["Bộ máy mã hóa<br/>Nhân ma trận sinh G (phép toán GF)"]
  ENC --> D1["Mảnh dữ liệu D1..Dk"]
  ENC --> P1["Mảnh chẵn lẻ P1..Pm"]
  D1 --> DIST["Bố trí phân tán mảnh sang các nút/rack/AZ khác nhau"]
  P1 --> DIST
  DIST --> FAIL["Cho phép mất tối đa m mảnh"]
  FAIL --> DEC["Giải mã (k mảnh bất kỳ + ma trận nghịch đảo)"]
  DEC --> R["Khôi phục đối tượng gốc"]

Các mảnh đã mã hóa bắt buộc phải được bố trí phân tán trên các miền sự cố (failure domain) khác nhau — nút, rack, hệ thống nguồn điện, vùng sẵn sàng (AZ). Nếu nhiều mảnh dồn vào một rack thì khi mất điện cấp rack sẽ phát sinh mất mát vượt quá m mảnh và không thể khôi phục. Do đó, trong chính sách bố trí của EC, bố trí nhận biết cấu trúc liên kết (topology-aware) quan trọng không kém tham số mã (k, m).

Các thành phần chính của hệ thống EC được tổng hợp như sau.

• Bộ máy mã hóa/giải mã: Mô-đun cốt lõi thực hiện ma trận sinh·phép toán GF. Được tăng tốc bằng thư viện SIMD như ISA-L hoặc offload sang DPU/GPU.
• Bộ quản lý stripe: Chia đối tượng thành stripe·mảnh và quản lý siêu dữ liệu ánh xạ.
• Bộ máy chính sách bố trí (placement): Thực thi quy tắc bố trí phân tán mảnh không trùng lặp miền sự cố.
• Bộ quản lý tái dựng: Phát hiện mất mảnh, lập lịch tái dựng và điều tiết băng thông.
• Bộ kiểm chứng toàn vẹn (scrubber): Kiểm tra định kỳ checksum của mảnh để phát hiện·sửa sớm hư hỏng âm thầm.

B. Kiến trúc hệ thống và đường I/O

Trong lưu trữ phân tán, EC có đường ghi và đường đọc bất đối xứng. Khi ghi, client hoặc gateway gom dữ liệu theo đơn vị stripe, mã hóa rồi truyền song song tới n nút. Khi đọc thông thường (không phải degraded), do đặc tính mã systematic chỉ cần đọc nguyên k mảnh dữ liệu nên không cần phép giải mã — đây là điểm tối ưu quan trọng trong thiết kế hiệu năng EC. Ngược lại, khi đọc suy giảm (degraded) do mất mảnh hoặc khi tái dựng (reconstruction), phải kéo k mảnh qua mạng để giải mã nên tải mạng·CPU tăng vọt.

sequenceDiagram
  participant C as Client
  participant G as EC gateway/điều phối
  participant N as Nút lưu trữ (N1..Nn)
  C->>G: PUT đối tượng
  G->>G: Chia k mảnh + mã hóa m chẵn lẻ
  par Lưu phân tán song song
    G->>N: Ghi mảnh D1..Dk, P1..Pm
  end
  N-->>G: ACK ghi (đạt quorum)
  G-->>C: Hoàn tất ghi
  Note over N: Một số mảnh mất do sự cố nút
  C->>G: GET đối tượng (degraded)
  G->>N: Yêu cầu k mảnh bất kỳ còn sống
  N-->>G: Trả về k mảnh
  G->>G: Tái cấu trúc bản gốc bằng giải mã ma trận nghịch đảo
  G-->>C: Trả về đối tượng

Trong cấu trúc này, thứ tốn kém nhất là lưu lượng tái dựng. Với RS(10,4), để khôi phục một mảnh phải đọc mảnh từ 10 nút khác, nên phát sinh I/O mạng·đĩa gấp 10 lần lượng dữ liệu cần khôi phục. Trong cụm quy mô lớn, thay đĩa là chuyện thường ngày, nên băng thông tái dựng này trở thành tải nền thường trực cạnh tranh với I/O dịch vụ thông thường. LRC (Local Reconstruction Codes) sẽ được bàn ở phần sau chính là để giảm nhẹ vấn đề này.

Một điểm khác cần lưu ý là chi phí cập nhật một phần (small write). Phương thức nhân bản chỉ cần sửa block cụ thể và phản ánh vào mỗi bản sao, nhưng trong EC chỉ cần một mảnh dữ liệu trong stripe thay đổi là phải tính lại toàn bộ chẵn lẻ của stripe đó. Vì gánh nặng "read-modify-write" này, EC phù hợp với đối tượng bất biến (immutable)·chỉ ghi nối (append-only) hoặc ghi tuần tự dung lượng lớn, và không phù hợp với tải công việc dạng giao dịch có cập nhật nhỏ thường xuyên. Tính chất này là căn cứ kỹ thuật của việc phân tầng: đặt EC ở tầng lưu trữ đối tượng·lưu trữ lâu dài, còn dữ liệu nóng dạng block·file dùng nhân bản.

C. Kiểm chứng toàn vẹn và ứng phó hư hỏng âm thầm

Giả định độ bền của EC được xây dựng trên tiền đề "biết chính xác vị trí mảnh bị mất". Tuy nhiên, đĩa có thể gây ra hư hỏng dữ liệu âm thầm (silent data corruption) trong đó bit bị lật lặng lẽ dù đĩa chưa chết hẳn; khi đó hệ thống không nhận biết được sự hư hỏng và có nguy cơ giải mã bằng mảnh sai rồi trả về bản gốc bị nhiễm bẩn. Do đó, hệ thống EC thực tế lưu song song checksum (CRC/hash) cho mỗi mảnh và thực hiện scrubbing — định kỳ đọc mảnh ở nền để kiểm chứng. Mảnh bị phát hiện không khớp trong kiểm chứng được coi là bị xóa và được tái tạo bằng EC, qua đó chuyển hư hỏng không biết vị trí thành bài toán xóa biết vị trí. Tức là hiệu quả của EC chỉ hoàn thiện thành độ bền thực chất khi kết hợp với checksum·scrubbing.

3. Loại hình và lựa chọn tham số

Mã hóa xóa được phân loại theo họ mã, tham số (k, m) và việc có cải thiện hiệu quả khôi phục hay không. Phổ biến nhất là họ Reed–Solomon, và các biến thể nhằm giảm chi phí tái dựng là LRC và mã tái sinh (Regenerating Codes) đã xuất hiện. Lựa chọn tham số chính là vấn đề đặt điểm cân bằng ở đâu trong đánh đổi ba bên: độ bền · hiệu quả lưu trữ · chi phí khôi phục.

Phân loại	Phương thức tiêu biểu	Chi phí lưu trữ thêm	Chịu lỗi	Chi phí tái dựng	Ví dụ áp dụng
Nhân bản (nhóm so sánh)	3-replication	200%	2 bản sao	Thấp (sao chép 1:1)	Mặc định HDFS, dữ liệu nóng
RS(6,3)	Reed–Solomon	50%	3 mảnh	Cao (đọc 6 mảnh)	Ví dụ mặc định của Ceph
RS(10,4)	Reed–Solomon	40%	4 mảnh	Cao (đọc 10 mảnh)	Facebook f4, HDFS-EC
LRC(12,2,2)	Local Reconstruction	Khoảng 50%	Đa tầng	Trung bình (chỉ nhóm cục bộ)	Azure Storage
MSR/MBR	Regenerating Code	40~50%	m mảnh	Thấp (chỉ một phần mảnh)	Nghiên cứu·lưu trữ thế hệ mới

Trong RS(k,m), tăng m thì độ bền cải thiện nhanh chóng nhưng chi phí lưu trữ cũng tăng theo, còn tăng k thì hiệu quả lưu trữ tốt hơn nhưng số mảnh phải đọc khi tái dựng tăng làm gánh nặng khôi phục lớn hơn. Ví dụ, RS(10,4) chịu được tối đa 4 sự cố với chi phí thêm 40%, vượt trội cả về không gian lẫn độ bền so với nhân bản 3 bản (chi phí 200%, thực chất chịu 2 sự cố). Tuy nhiên vì mảnh rải trên 14 nút nên bất lợi cho tái dựng·đọc ngẫu nhiên quy mô nhỏ. Vì vậy, chính sách lai phân tầng dữ liệu nóng có tần suất truy cập cao dùng nhân bản, dữ liệu ấm/lạnh ít truy cập dùng EC đã trở thành chuẩn thực tiễn.

LRC nhắm thẳng vào vấn đề chi phí tái dựng này. Chia toàn bộ mảnh thành vài nhóm cục bộ và đặt chẵn lẻ cục bộ cho mỗi nhóm, nên khi mất một mảnh chỉ cần đọc một số ít mảnh trong cùng nhóm thay vì toàn bộ để khôi phục. LRC(12,2,2) của Azure chia 12 dữ liệu thành hai nhóm 6+6, mỗi nhóm có 1 chẵn lẻ cục bộ và toàn thể có 2 chẵn lẻ toàn cục. Kết quả là giảm đáng kể chi phí khôi phục sự cố một nút (trường hợp thường gặp nhất trong thực tế) trong khi vẫn giữ chi phí lưu trữ thấp hơn nhân bản — Microsoft báo cáo phương thức này giảm I/O tái dựng xuống khoảng một nửa so với RS thuần.

Cảm nhận định lượng về lựa chọn tham số như sau. Chi phí lưu trữ thêm được tính bằng (k+m)/k − 1, nên RS(6,3) là (6+3)/6 − 1 = 50%, RS(10,4) là (10+4)/10 − 1 = 40%, RS(12,4) là 33%. Tức là k càng lớn thì chẵn lẻ được pha loãng tương đối và chi phí thêm giảm, nhưng đổi lại độ rộng stripe tăng nên số mảnh phải đọc khi tái dựng và yêu cầu số miền sự cố để bố trí mảnh cùng tăng. Ví dụ, để bố trí RS(10,4) an toàn theo đơn vị rack cần tối thiểu 14 miền sự cố khác nhau, và ở cụm nhỏ bản thân yêu cầu này trở thành ràng buộc. Ngược lại, ở cụm nhỏ các mã độ rộng hẹp như RS(4,2)·RS(6,2) là thực tế hơn. Như vậy, tham số mã là quyết định thực tiễn phụ thuộc không chỉ hiệu quả lý thuyết mà cả quy mô và cấu trúc liên kết của cụm.

4. So sánh với nhân bản và các trường hợp áp dụng thực tế

Lựa chọn giữa mã hóa xóa và nhân bản không đơn thuần là "cái nào tốt hơn" mà là vấn đề sự phù hợp với đặc tính tải công việc. Nhân bản có mỗi bản sao là dữ liệu hoàn chỉnh nên tính cục bộ khi đọc vượt trội, không cần gom mảnh để giải mã nên độ trễ thấp, và tái dựng chỉ là sao chép đơn giản nên nhanh. Ngược lại, EC có hiệu quả lưu trữ vượt trội nhưng bất lợi về độ trễ đọc ngẫu nhiên quy mô nhỏ và băng thông tái dựng. Do đó, lý do căn bản của sự khác biệt là khác biệt triết lý thiết kế "giữ dư thừa dưới dạng bản sao hoàn chỉnh hay dưới dạng chẵn lẻ nén toán học", và điều này biểu hiện thành sự trao đổi giữa chi phí và hiệu năng.

Sự khác biệt này nổi bật trong triển khai thực tế của lưu trữ đối tượng. Lưu trữ đối tượng xử lý dữ liệu theo đơn vị đối tượng bất biến chứ không theo đơn vị block của hệ thống tệp, nên rất hợp với EC khi mã hóa nguyên mỗi đối tượng thành stripe và rải mảnh trên nhiều nút·AZ. Đối tượng đã ghi một lần thì ít thay đổi nên hầu như không có gánh nặng cập nhật một phần, và mẫu truy cập chủ yếu là PUT/GET nên có thể thực hiện mã hóa·giải mã tự nhiên tại ranh giới yêu cầu. Ngược lại, lưu trữ block (đĩa máy ảo, volume cơ sở dữ liệu) có cập nhật nhỏ ngẫu nhiên thường xuyên nên chi phí read-modify-write của EC lớn, vì vậy ở đây nhân bản hoặc EC độ rộng hẹp được ưa chuộng. Như vậy, "bảo vệ cái gì bằng EC" gắn chặt với phương thức truy cập lưu trữ (đối tượng/tệp/block).

Về trường hợp cụ thể, f4 của Facebook (Meta) lưu BLOB ít được truy cập (ảnh·video) bằng RS(10,4), giảm không gian lưu trữ xuống khoảng dưới một nửa so với nhân bản 3 bản trước đó. AWS S3 ở lớp lưu trữ tiêu chuẩn phân tán đối tượng bằng EC và bố trí trên tối thiểu 3 AZ, quảng cáo độ bền "99,999999999% mỗi năm (11 nines)"; độ bền cực đoan này chỉ có thể đạt được một cách kinh tế nhờ kết hợp EC với bố trí đa AZ. Ceph cho phép chọn profile replicated/erasure theo đơn vị pool, để người vận hành chỉ định chính sách theo cấp dữ liệu. HDFS-EC (3.0+) áp dụng chính sách RS(6,3)·RS(10,4) cho thư mục dữ liệu lạnh, cắt giảm mạnh chi phí lưu trữ của cụm Hadoop.

Nhìn bằng con số thì hàm ý rất rõ. Lưu 1PB dữ liệu gốc bằng nhân bản 3 bản cần 3PB đĩa thực tế, nhưng lưu bằng RS(10,4) thì chỉ cần 1,4PB — với cùng dữ liệu, chi phí đĩa·điện năng·không gian rack giảm xuống dưới một nửa. Tuy nhiên, sự tiết kiệm này đi kèm cái giá "không phù hợp với dữ liệu nhạy độ trễ·truy cập tần suất cao", nên trong thực tiễn, cách làm chuẩn là dùng chính sách vòng đời dữ liệu (lifecycle policy) tự động chuyển dữ liệu cũ từ nhân bản → EC.

Về độ bền, hai phương thức cũng được so sánh định lượng. Độ bền dữ liệu thường được biểu diễn bằng "bao nhiêu số 9 (nines)", phụ thuộc vào tỷ lệ hỏng hằng năm (AFR) của từng mảnh, thời gian tái dựng (MTTR) và số mảnh mất đồng thời chịu được m. Tái dựng càng nhanh (khoảng dễ tổn thương càng ngắn) và m càng lớn thì độ bền cải thiện theo hàm mũ. Vì vậy, nhà cung cấp đám mây tăng m của EC và bố trí mảnh trên đa AZ để quảng cáo độ bền cấp 11 nines, đồng thời tinh chỉnh kỹ LRC·tái dựng song song·điều tiết để tăng tốc tái dựng. Ngược lại, trong môi trường đĩa dung lượng lớn tái dựng chậm mà m nhỏ, nguy cơ sự cố tương quan (correlated failure) — sự cố thứ 2, thứ 3 chồng lên trong lúc tái dựng dẫn đến mất dữ liệu — sẽ tăng. Do đó, thiết kế EC là vấn đề phải xem xét đồng thời không chỉ "đặt m bằng bao nhiêu" mà cả "có thể hoàn tất tái dựng nhanh đến đâu".

Tóm lại, lựa chọn giữa hai phương thức có thể phán đoán theo các tiêu chí sau.

• Trường hợp nhân bản có lợi: Dữ liệu nóng cần độ trễ thấp·IOPS cao, cập nhật nhỏ thường xuyên (giao dịch·siêu dữ liệu), cụm nhỏ (thiếu miền sự cố), tải công việc coi trọng tái dựng đơn giản nhanh chóng.
• Trường hợp EC có lợi: Dữ liệu ấm/lạnh dung lượng lớn·bất biến·truy cập tuần tự (sao lưu·lưu trữ lâu dài·media·log), khi tiết kiệm chi phí lưu trữ là ưu tiên hàng đầu, cụm quy mô lớn đủ miền sự cố, khi yêu cầu độ bền đa AZ/vùng.
• Trường hợp lai là lời giải: Phần lớn thực tiễn trong đó cấp dữ liệu thay đổi theo thời gian — dùng chính sách vòng đời, ban đầu nhân bản, sau một thời gian tự động chuyển sang EC.

5. Chuyên sâu: vấn đề chi phí tái dựng và xu hướng mã thế hệ mới

Tiền tuyến nghiên cứu·thực tiễn EC tập trung vào "giữ hiệu quả lưu trữ của MDS nhưng làm sao giảm chi phí tái dựng". Điểm yếu lớn nhất của Reed–Solomon thuần là để khôi phục một mảnh phải chuyển toàn bộ k mảnh qua mạng, và trong thực tế cụm quy mô lớn thay đĩa thường xuyên, lưu lượng sửa chữa (repair traffic) này chiếm tỷ trọng đáng kể của mạng cụm.

Bối cảnh khiến vấn đề này đặc biệt nghiêm trọng là sự tăng dung lượng đĩa. Khi dung lượng một đĩa lên tới hàng chục TB, chỉ riêng tái dựng một đĩa bằng EC có thể mất từ vài giờ đến hơn một ngày. Tái dựng càng lâu thì xác suất mất thêm mảnh khác trong khoảng thời gian đó càng tích lũy và độ bền thực chất giảm, nên "giảm băng thông tái dựng và song song hóa như thế nào" gắn trực tiếp với vấn đề độ bền. Các cách tiếp cận giải quyết được tóm tắt như sau.

• LRC (Local Reconstruction Codes): Thêm chẵn lẻ cục bộ để cục bộ hóa số mảnh cần cho khôi phục sự cố đơn. Đổi lại tăng nhẹ chi phí lưu trữ, giảm mạnh băng thông khôi phục; Azure Storage là trường hợp áp dụng tiêu biểu.
• Mã tái sinh (Regenerating Codes, MSR/MBR): Làm rõ về lý thuyết thông tin đường cong đánh đổi tối ưu giữa lượng lưu trữ và băng thông khôi phục, và thiết kế để khi khôi phục mỗi nút chỉ truyền một phần thông tin thay vì toàn bộ mảnh, tối thiểu hóa lưu lượng khôi phục.
• Các mã thực dụng như Clay/Piggyback: Họ mã nhằm áp dụng lợi thế lý thuyết của MSR vào hệ thống thực tế (ví dụ: plugin clay của Ceph) với độ phức tạp hiện thực thấp hơn.

Trong số này, LRC đã được dùng rộng rãi trong thương mại, còn họ mã tái sinh tuy tập trung ở nghiên cứu·hệ thống đặc thù nhưng được xem là hướng đi triển vọng của lưu trữ siêu quy mô.

Tổng hợp lại, trục tiến hóa gần đây của EC hội tụ về "giữ hiệu quả lưu trữ của MDS trong khi hạ chi phí tái dựng·tính toán". LRC·mã tái sinh về mặt thuật toán, offload phần cứng về mặt thực thi, phân tán địa lý·mã phân cấp về mặt bố trí đang phát triển đan xen nhau, nên dự kiến EC sẽ lan rộng sang nhiều tầng dữ liệu hơn.

Mặt khác, tăng tốc phần cứng cũng là xu hướng quan trọng. Phép nhân GF gây tải CPU lớn nên Intel ISA-L (Intelligent Storage Acceleration Library) tăng tốc mã hóa bằng lệnh SIMD (SSE/AVX), và gần đây ngày càng nhiều nỗ lực offload phép toán EC sang DPU/SmartNIC hoặc GPU để giải phóng CPU. Ngoài ra, EC đa vùng (geo-distributed EC) phân tán theo địa lý chịu được cả sự cố cấp vùng nhưng phải xem xét độ trễ·chi phí mạng diện rộng, nên thiết kế mã phân cấp kết hợp LRC đang được nghiên cứu sôi nổi. Tuy nhiên, mức độ trưởng thành·chuẩn hóa của các kỹ thuật mới này chênh lệch lớn giữa các sản phẩm, nên khi áp dụng thực tế cần thận trọng xác nhận đặc tả cụ thể và kết quả kiểm chứng của hiện thực nhà cung cấp.

Về hệ sinh thái, EC đã được tích hợp sẵn trong toàn bộ lưu trữ mã nguồn mở và thương mại. Ceph hỗ trợ nhiều plugin EC như jerasure·isa·clay để người vận hành chỉ định thuật toán và (k, m) bằng profile, MinIO áp dụng EC làm mặc định cho lưu trữ đối tượng và được dùng cả trong triển khai quy mô nhỏ. HDFS từ 3.0 cho phép chỉ định chính sách EC theo đơn vị thư mục, và phần lớn lưu trữ đối tượng thương mại·thiết bị sao lưu đều áp dụng nội bộ RS hoặc biến thể của nó. Không tồn tại một "giao thức EC" chuẩn hóa duy nhất; họ mã·kích thước mảnh·chính sách bố trí khác nhau theo hệ thống, nên khó kỳ vọng tương thích trực tiếp mảnh EC giữa các hệ lưu trữ khác nhau. Do đó, trong di trú hoặc thiết kế đa nhà cung cấp, an toàn hơn là tiếp cận với tiền đề tương tác ở cấp đối tượng/tệp chứ không phải ở cấp mảnh EC.

6. Lưu ý và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)

• Chiến lược phân tầng dựa trên tải công việc: EC không phải vạn năng. Truy cập ngẫu nhiên nhạy độ trễ·tần suất cao (DB giao dịch, cache nóng) phù hợp với nhân bản, còn truy cập tuần tự dung lượng lớn·tần suất thấp (sao lưu, lưu trữ media, log) phù hợp với EC. Thiết kế chuyển đổi tự động nóng (nhân bản) → ấm/lạnh (EC) bằng chính sách vòng đời dữ liệu là cách làm chuẩn để đồng thời đạt được chi phí và hiệu năng.
• Quản lý đánh đổi tham số·bố trí: Chọn (k, m) là cân bằng ba bên giữa độ bền·hiệu quả lưu trữ·chi phí tái dựng. Tăng m thì độ bền↑·không gian↓, tăng k thì hiệu quả không gian↑·gánh nặng khôi phục↑. Bắt buộc phải thiết kế cùng với bố trí phân tán vượt qua miền sự cố (nút·rack·AZ), và việc dồn mảnh sẽ phá vỡ giả định độ bền của EC.
• Chuẩn bị cho bão tái dựng (rebuild storm): Trong thời đại đĩa dung lượng lớn (hàng chục TB), ngay cả tái dựng một đĩa cũng tốn nhiều thời gian·băng thông, và trong lúc đó xác suất sự cố thứ 2 tăng. Phải quản lý đồng thời hư hỏng âm thầm (silent data corruption) và tải tái dựng bằng việc áp dụng LRC, điều tiết băng thông tái dựng, hàng đợi ưu tiên, scrubbing nền.
• Đánh giá định lượng hiệu năng·chi phí: Trước khi áp dụng, phải lượng hóa không chỉ "khoản tiết kiệm chi phí lưu trữ" mà cả độ trễ đọc degraded, ảnh hưởng của lưu lượng tái dựng lên I/O thông thường, chi phí CPU/mạng. Việc có áp dụng các phương tiện tăng tốc như ISA-L·offload DPU hay không quyết định chi phí hiệu dụng.
• Xác nhận sự phù hợp với phương thức truy cập: EC hợp với dữ liệu đối tượng·bất biến·tuần tự, nhưng không phù hợp với tải công việc cập nhật nhỏ ngẫu nhiên dựa trên block·tệp do chi phí read-modify-write. Phải phân tích trước mẫu truy cập của dữ liệu đích (đối tượng/tệp/block, tần suất cập nhật) để quyết định phương thức bảo vệ, và tham số mã không được vượt quá ràng buộc vật lý là số miền sự cố của cụm.
• Song hành toàn vẹn·quản trị: Giả định độ bền của EC dựa trên tiền đề "biết vị trí mất", nên bắt buộc phải có cơ chế checksum·scrubbing chuyển hư hỏng âm thầm thành bài toán xóa. Ngoài ra, khi bố trí đa AZ/vùng phải thiết kế đồng thời từ góc nhìn quản trị để yêu cầu chủ quyền dữ liệu·tuân thủ quy định (nơi lưu trú dữ liệu) không xung đột với chính sách phân tán mảnh.
• Công nghệ liên kết và triển vọng: EC là công nghệ nền tảng của lưu trữ đối tượng, data lake/lakehouse, sao lưu·lưu trữ lâu dài, tầng đám mây lạnh; trong tương lai khi hiệu quả tái dựng được cải thiện nhờ LRC·mã tái sinh·EC phân tán địa lý và offload phần cứng trở nên phổ biến, phạm vi áp dụng dự kiến sẽ mở rộng hơn. Kỹ sư chuyên nghiệp phải vượt qua kiến thức kỹ thuật đơn thuần để có thể phối hợp EC và nhân bản với vai trò nhà thiết kế tổng thể chính sách bảo vệ lưu trữ phù hợp với cấp dữ liệu·SLA·mục tiêu chi phí của tổ chức.

Tài liệu tham khảo

• Reed, I. S., & Solomon, G., "Polynomial Codes over Certain Finite Fields", 1960. — https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction
• Huang, C. et al., "Erasure Coding in Windows Azure Storage (LRC)", USENIX ATC 2012. — https://www.usenix.org/conference/atc12/technical-sessions/presentation/huang
• Muralidhar, S. et al., "f4: Facebook's Warm BLOB Storage System", OSDI 2014. — https://www.usenix.org/conference/osdi14/technical-sessions/presentation/muralidhar
• Apache Hadoop, "HDFS Erasure Coding". — https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html
• Ceph Documentation, "Erasure code". — https://docs.ceph.com/en/latest/rados/operations/erasure-code/

---

Tóm tắt một câu: Mã hóa xóa là kỹ thuật sửa lỗi MDS mã hóa dữ liệu gốc thành k mảnh dữ liệu + m mảnh chẵn lẻ (tổng n=k+m) và khôi phục chỉ từ k mảnh bất kỳ, cung cấp độ bền cao với chi phí lưu trữ thấp hơn nhiều so với nhân bản 3 bản, nhưng đi kèm cái giá là chi phí tái dựng·đọc degraded nên cần bổ trợ bằng phân tầng theo tải công việc và các kỹ thuật cải thiện hiệu quả khôi phục như LRC.