antony@notes:~/data-platform$ cat "Minio-Erasure-Coding.md"
Minio Erasure Coding
Minio Erasure Coding
MinIO 將 Erasure Coding ( 擦除編碼 ) 作為提供資料 redundancy ( 冗餘 ) 和可用性的核心元件。
Erasure Coding Basics
MinIO 將同一組 Minio Server 中的硬碟分組為一個或多個大小相同的 Erasure Sets ( 擦除集 )。
上述部署範例包括 4 個節點，每個節點有 4 個硬碟。 MinIO 初始化時使用由所有 4 個節點的全部 16 個硬碟組成的單一擦除集。
MinIO 會在初始化所有 minio server 的時後，決定 Erasure Sets 的最佳數量和大小。 初始設定後，就不能修改這些設定了。
對於每次寫入操作，MinIO 都會將物件分割成資料碎片和 parity shards ( 奇偶校驗碎片 )。
Erasure set stripe 大小決定了部署的最大奇偶校驗可能。決定要產生的資料分片和奇偶校驗分片數量的公式是
N (ERASURE SET SIZE) = K (DATA) + M (PARITY)
上述部署範例具有 16 個硬碟的一個 erasure set，parity 的數量可以支援設定 0 個 ~ 8 個 ( 1/2 的 Erasure Set size )。
可以將 parity value ( 奇偶校驗值 ) 設定在 0 到 1/2 個 Erasure Set size 之間。
MinIO 使用 Reed-Solomon erasure code 實現，並將 object 分割成多個部分，以分散儲存在 erasure set 上。上面的範例部署使用了 16 顆硬碟的 erasure set，並使用了
EC:4的奇偶性檢查。
使用特定的 parity 設定將物件寫入 MinIO，那麼在更改 parity 值之後，這些物件不會自動更新。
MinIO 要求至少有 K 個任何類型的碎片才能讀取一個物件。
此處的 K 值構成部署的讀取法定人數。 因此，erasure set 中必須至少有 K 個健康的硬碟才能支援讀取操作。
此部署有一個離線節點，因此僅剩下 12 個健康的硬碟。 物件以
EC:4寫入，讀取法定人數為K=12。 因此，該物件保持了讀取法定人數，MinIO 可以對其進行讀取操作重建。
MinIO 無法重建失去讀取法定人數的 Object。 此類物件可透過複製重新同步等其他方式復原。
MinIO 至少需要 K 個 erasure set 硬碟才能寫入一個物件。
此處的 K 值構成部署的寫入法定人數。 因此，erasure set 必須至少有 K 個可用硬碟上線，以支援寫入操作。
此部署有一個離線節點，因此只剩下 12 個健康硬碟。 用戶端使用
EC:4奇偶校驗設定寫入一個 Object，其中 erasure set 的寫法定人數為K=12。 此 erasure set 維護寫入法定人數，MinIO 可以使用它進行寫入操作。
如果奇偶校驗 EC:M 恰好是 erasure set 大小的 1/2，則寫入法定人數為 K+1
這樣就能防止出現 “大腦分裂” 的情況，例如網路問題恰好將一半的 erasure set 硬碟與其他硬碟隔離開來。
由於瞬時網路故障，該部署有兩個節點離線。 客戶端以
EC:8奇偶校驗設定寫入一個 Object，其中 erasure set 的寫法定人數為K=9。 該 erasure set 已失去寫入法定人數，MinIO 無法使用它進行寫入操作。
K+1 邏輯確保客戶端不可能兩次寫入同一個物件，每 “半 " 個 erasure set 一次。
對於保持讀取法定人數的 Object，MinIO 可以使用任何資料碎片或奇偶校驗碎片來修復損壞的碎片。
由於硬碟故障，
EC:4物件遺失了 12 個資料碎片中的 4 個。 由於該物件保持了讀取法定人數，因此 MinIO 可以使用可用的奇偶校驗碎片來修復這些遺失的資料碎片。
使用 MinIO Erasure Coding 計算器 可以幫你算硬碟和 Minio Server 的容錯。 盡可能使用偶數節點和每個節點的硬碟數量，以簡化拓撲規劃和硬碟/擦除集分佈的概念化。
Erasure Parity and Storage Efficiency
為部署設定奇偶校驗是可用性和總可用儲存之間的平衡。 奇偶校驗值越高，對硬碟或節點故障的復原能力就越強，但可用儲存空間就會減少；而奇偶校驗值越低，儲存空間就會越大，但對硬碟/節點故障的容錯 能力就會降低。 使用 MinIO Erasure Code Calculator 來探討奇偶校驗對計畫群集部署的影響。
下表列出了由 1 個節點和 16 個 1TB 硬碟組成的 MinIO 部署中不同擦除碼奇偶校驗層級的結果：
| Parity | Total Storage | Storage Ratio | Minimum Drives for Read Operations | Minimum Drives for Write Operations |
|---|---|---|---|---|
| EC: 4 (Default) | 12 Tebibytes | 0.750 | 12 | 12 |
| EC: 6 | 10 Tebibytes | 0.625 | 10 | 10 |
| EC: 8 | 8 Tebibytes | 0.500 | 8 | 9 |
Bitrot Protection
Bit rot ( 位元腐爛 ) 是硬碟隨機變化造成的無聲資料損壞。 對於數據驅動器來說，它通常是代表數據的電荷或磁性方向衰減的結果。 這些來源可能是停電時的小電流尖峰，也可能是導致位元翻轉的隨機宇宙射線。 由此產生的 “位元旋轉” 會在資料媒體上造成微妙的錯誤或損壞，而不會觸發監控工具或硬體。
MinIO 透過優化的 HighwayHash 算法實作，確保它可以即時捕捉並修復損壞的物件。透過在讀取時計算雜湊值，並在寫入時從應用程式、網路到記憶體或硬碟驗證這個雜湊值，從頭到尾保證了資料的完整性。這個實作是為了速度設計的，能夠在單核的 Intel CPU 上達到每秒超過 10 GB 的哈希運算速度。
Demo
# SSH 連線至 kube-kadm
$ ssh bigred@172.22.1.11 -p 22100
# 測試與 tk8s 連接
$ mc ready tk8s
The cluster is ready
# 檢視 Erasure sets size
$ mc admin info tk8s
● minio-0.minio.kube-system.svc.k1.org:9000
Uptime: 1 hour
Version: 2024-02-26T09:33:48Z
Network: 2/2 OK
Drives: 2/2 OK
Pool: 1
● minio-1.minio.kube-system.svc.k1.org:9000
Uptime: 1 hour
Version: 2024-02-26T09:33:48Z
Network: 2/2 OK
Drives: 2/2 OK
Pool: 1
Pools:
1st, Erasure sets: 1, Drives per erasure set: 4
512 MiB Used, 5 Buckets, 1 Object
4 drives online, 0 drives offline
# 檢視 Minio Erasure code 設定值
$ mc admin config get tk8s storage_class
storage_class standard= rrs=EC:1
> standard (string) set the parity count for default standard storage class e.g. "EC:4"
> rrs (string) set the parity count for reduced redundancy storage class e.g. "EC:2"
# 產生一個 32 MB 的檔案
$ dd if=/dev/zero of=./512MB_File bs=1M count=32
# 匯入 Minio
$ mc cp --storage-class REDUCED_REDUNDANCY 32MB_File tk8s/mysql/
# 確認檔案已匯入
$ mc ls tk8s/mysql
mc ls tk8s/mysql
[2024-03-02 18:32:11 CST] 32MiB REDUCED_REDUNDANCY 32MB_File
# SSH 連線至 tkadm 虛擬主機
$ ssh bigred@192.168.61.128
# 檢視在 k1w1 上 Minio 的檔案
$ talosctl --nodes 172.22.1.15 --talosconfig=/home/bigred/k1/v1.6.5/talosconfig list -l /opt/m0data0/mysql
NODE MODE UID GID SIZE(B) LASTMOD NAME
172.22.1.15 drwxr-xr-x 0 0 24 Mar 1 17:12:30 .
172.22.1.15 drwxr-xr-x 0 0 65 Mar 2 18:32:11 32MB_File
$ talosctl --nodes 172.22.1.15 --talosconfig=/home/bigred/k1/v1.6.5/talosconfig list -l /opt/m0data0/mysql/32MB_File/
NODE MODE UID GID SIZE(B) LASTMOD NAME
172.22.1.15 drwxr-xr-x 0 0 65 Mar 2 18:32:11 .
172.22.1.15 drwxr-xr-x 0 0 34 Mar 2 18:32:11 6dfa0b95-1f51-4a7a-87f4-03a9d23dcd01
172.22.1.15 -rw-r--r-- 0 0 457 Mar 2 18:32:11 xl.meta
$ talosctl --nodes 172.22.1.15 --talosconfig=/home/bigred/k1/v1.6.5/talosconfig list -lH /opt/m0data0/mysql/32MB_File/6dfa0b95-1f51-4a7a-87f4-03a9d23dcd01
NODE MODE UID GID SIZE(B) LASTMOD NAME
172.22.1.15 drwxr-xr-x 0 0 34 B 6 minutes ago .
172.22.1.15 -rw-r--r-- 0 0 5.6 MB 6 minutes ago part.1
172.22.1.15 -rw-r--r-- 0 0 5.6 MB 6 minutes ago part.2Getting started with MinIO storage classes
There are two storage classes supported currently, Standard and Reduced Redundancy.
Standard storage class
Standard storage class is the default storage class storage class of your deployment. Once set, all the PutObject requests by default will adhere to the data/parity configuration set under standard storage class.
Reduced redundancy storage class
Reduced redundancy storage class can be applied to objects of a less critical nature, requiring less replication. To apply this class, set object metadata as X-Amz-Storage-Class:REDUCED_REDUNDANCY in a PutObject (or multi-part) request. This indicates MinIO server to store the corresponding object with data and parity as defined by the reduced redundancy class.