快照與 LVM

在本章的的快照一開始就一直說明了 Snapshot 與 LVM 有很大的關係，首先我們必需瞭解 Gluster 使用了 LVM 的一些特殊功能。

Thin Provisioning

假設有一間金控公司開了一間銀行其資本額為 100 億的實收金額，甲公司借了 60 億、乙公司借了 60 億、丙公司借了 40 億。

銀行雖然資本只有 100 億，但是一共借出了 160 億元的帳面金額給不同公司，因為不是每間公司一下就需要使用到這些金額，這是合法，但不安全的作法。

當三家公司同時間要將錢取出時，可以發現銀行並沒有足夠的金額轉出，因此會發生兩個情況：

1. 暫時轉出，並發生違約
2. 向金控母公司請求更多的金額以完成轉出作業

以上說明指出了 LVM Thin Provisioning 的大致作業情況。

在 LVM 的 Thin Provisioning 就有點像是銀行（LV Group）、借款公司（LV Brick）、與金錢（空間大小）。

你可以在 Thin Provisioning 中規劃出一個 Pool，然後在 Pool 中切出不同的 Brick 要使用的 LV。然而一開始所有的 Brick 並不會存放足量的資料，大部份都是漸進式的使用，所以您可以在 Pool 中切出的 LV 總量可以超過自己的全部總額。

但是總有一天會資料量會佔滿所指定的大小，此時若 Pool 容量不足時，該 LV 就會被系統強制停用，若不處理的話則會讓資料無法存取（違約）；或是將該 Pool 加大空間（向金控母公司要求更多金額），讓各個 LVM 可以繼存有足夠的空間儲存。

優點

1. 使用 Thin Provisioning 時可以在一開始規劃出較多的可用 LV。
2. 減少實際儲存空間的浪費。
3. 有彈性的應用儲存空間。

缺點

1. 若發生 Pool 容量不夠時，其所包含的 LV 成員將無法運作。

應變與管理

1. 在建置初期，在 VG 中保留一定數量的空間，以便日後延展 VG Pool。
2. 時常性的使用 lvs 指令查看每個節點伺服中 Brick Pool 的 Data 使用量，在接近 80% 的時候應該要立即採取應變作業。

Snapshot

在 Thin Provisioning 中，假設 Pool 為 10GB、LV 為 8GB，此時 LV 實際使用空間為 7GB，那麼其 Snapshot 也會從 Pool 佔用 8GB 的空間設定為快照使用。

情況

1. 當您的 LV 空刪檔案刪除，其空間不會還給 Pool 而會繼續佔用。
2. 當檔案再次的寫入時，Pool 必需再提出足夠的空間讓 LV 繼續新增檔案。
3. LV 的檔案繼續增長，但 Pool 已經沒有空間。
4. LV 被暫停使用。

所以當您的 Pool 沒有空間，其所影響的範圍會是全面性的，若是在 Gluster 中，該 Brick 就會失效下線。

解決方式

1. 刪除 Snapshot。
2. 使用 fstrim 將 LV 重新整理，並適放沒有使用的空間給 Pool。

維護方式

1. 定期性的使用 fstrim 釋放容間至 Pool 中。
2. 經常性的使用 lvs 檢查 Pool 的 Data 使用量。
3. Pool 使用量達到 70% 考慮加大 Pool 或是新增其它 Brick。