快照是什麼？揭祕存儲快照的實現

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

本文由許登博 發表於雲+社區專欄

原創聲明：本文首發騰訊雲·雲+社區，未經容許，不得轉載

前言

存儲網絡行業協會SNIA（StorageNetworking Industry Association）快照的定義：關於指定數據集合的一個徹底可用拷貝，該拷貝包括相應數據在某個時間點（拷貝開始的時間點）的映像。快照能夠是其所表示的數據的一個副本，也能夠是數據的一個複製品。

須要注意的是：快照是徹底可用的拷貝，但不是一份完整的拷貝，至於爲何，後面會詳細講。

存儲快照的使用場景

場景一：

存儲快照，是一種數據保護措施，能夠對源數據進行必定程度的保護，通俗地講，能夠理解爲----後悔藥。

如上圖，假設在t0時刻，有一份完整的源數據，咱們在t1時刻，針對這份源數據建立一份快照。

t2時刻，若由於各類緣由（誤操做、系統錯誤等）致使源數據損毀，那麼，咱們能夠經過回滾（rollback）快照，將源數據恢復至快照建立時的狀態（即t1時刻），這樣，能夠儘可能下降數據損失（損失的數據，是t1到t2之間產生的數據）。

這種功能，經常使用於銀行、公安戶籍、科研單位等。操做系統、軟件升級或機房設備更替，通常會選擇在夜間或其餘無生產業務時，進行高危操做，操做前會對數據進行快照，若操做失敗，則將快照進行rollback，將源數據恢復至操做前的狀態。

場景2：

前言中說過，快照是一份徹底可用的副本，那麼，它徹底能夠被上層業務當作源數據。

如上圖，針對源數據，建立快照後，將快照卷映射給其餘上層業務，能夠用於數據挖掘和開發測試等工做，針對快照的讀操做不影響源卷的數據。

這種功能，經常使用於直播（視頻&圖片）鑑黃、科研數據模擬開發測試等，好比，視頻直播平臺須要將某一段時間的視頻提供給執法機構進行篩查分析，那麼能夠經過對特定時間點保存的數據建立快照，將快照映射給執法機構的業務主機去進行挖掘分析。

存儲快照的實現原理

目前，快照的實現方式均由各個廠商自行決定，但主要技術分爲2類，一種是寫時拷貝COW（Copy On Write），另外一種，是寫重定向ROW（Redirect On Write）。

寫時拷貝COW

COW(Copy-On-Write)，寫時拷貝，也稱爲寫前拷貝。

建立快照之後，若是源卷的數據發生了變化，那麼快照系統會首先將原始數據拷貝到快照捲上對應的數據塊中，而後再對源捲進行改寫。

寫操做：

如上圖簡要示例，快照建立之後，若上層業務對源卷寫數據X，X在緩存中排隊，快照系統將X即將寫入的位置（邏輯地址）上的數據Y，拷貝到快照卷中對應的位置（邏輯地址）上，同時，生成一張映射表，表中一列記錄源捲上數據變化的邏輯地址，另外一列記錄快照捲上數據變化的邏輯地址。咱們能夠看到，上層業務每下發一個數據塊，存儲上，發生了兩次寫操做：一次是源卷將數據寫入快照卷（即圖中Y），一次是上層業務將數據寫入源卷（即圖中X）。

讀操做：

如上圖，快照卷若映射給上層業務進行數據分析等用途時，針對快照進行讀操做時，首先由快照系統判斷，上層業務須要讀取的數據是否在快照卷中，若在，直接從快照卷讀取，若不在，則查詢映射表，去對應源卷的邏輯地中讀取（這個查表並去源卷讀的操做，也叫讀重定向）。這一點，剛好就解釋了爲何快照是一份徹底可用的副本，它沒有對源捲進行100%的拷貝，但對上層業務來講，卻能夠將快照看作是和源卷「如出一轍」的副本。

針對源卷進行讀操做時，與快照卷沒有數據交互。

咱們能夠看到，快照對源卷的數據具備很好的保護措施，快照能夠單獨做爲一份能夠讀取的副本，但並無像簡單的鏡像那樣，一開始就佔用了和源卷同樣的空間，而是根據建立快照後上層業務產生的數據，來實時佔用必需的存儲空間。

快照回滾（rollback）：

如上圖，回滾操做的前提條件是，鎖定源卷（暫停對待回滾的邏輯地址上的IO操做），而後經過查映射表，將快照捲上的對應數據回拷到源卷中。

快照刪除：

採用COW技術的快照，其源卷即保存着完整的實時數據，所以，刪除快照時，直接銷燬了快照卷和映射表，與源卷不存在數據交互。

寫時重定向ROW

ROW(Redirect-on-write )，也稱爲寫時重定向。

建立快照之後，快照系統把對數據卷的寫請求重定向給了快照預留的存儲空間，直接將新的數據寫入快照卷。上層業務讀源卷時，建立快照前的數據從源卷讀，建立快照後產生的數據，從快照卷讀。

寫操做：

如上圖簡要示例，快照建立之後，若上層業務對源卷寫數據X，X在緩存中排隊，快照系統判斷X即將寫入源卷的邏輯地址，而後將數據X寫入快照卷中預留的對應邏輯地址中，同時，將源卷和快照卷的邏輯地址寫入映射表，即寫重定向。咱們能夠看到，上層針對源卷寫入一個數據塊X，存儲上只發生一次寫操做，只是寫以前進行了重定向。

讀操做：

若快照建立之後，上層業務對源捲進行讀，則有兩種狀況：1）若讀取的數據，在建立快照前產生，數據是保存在源捲上的，那麼，上層就從源捲進行讀取；2）若須要讀取的數據是建立快照之後才產生的，那麼上層就查詢映射表，從快照捲進行讀取（即讀重定向）。

若快照建立之後，上層業務對快照捲進行讀，一樣也有兩種狀況：1）若讀取的數據，在建立快照前產生，數據是保存在源捲上的，那麼上層就查詢映射表，從源捲進行讀取；2）若須要讀取的數據是建立快照之後才產生的，那麼上層就直接從快照捲進行讀取。

咱們能夠看到，ROW快照也是根據建立快照後上層業務產生的數據，來實時佔用必需的存儲空間。

快照回滾（rollback）：

採用ROW技術的快照，其源卷始終保存着快照建立前的完整數據，快照建立後，上層業務產生的數據都寫入了快照中，所以，快照的回滾只是取消了對源卷的讀重定向操做。通俗地說，就是源捲上沒有進行任何數據操做，上層業務對源卷的讀，僅限於讀源卷（即不會去讀取快照卷的數據）。

快照刪除：

採用ROW技術的快照，其源卷始終保存着快照建立前的完整數據，快照建立後，上層業務產生的數據都寫入了快照中。所以，若要刪除快照，必然要先將快照卷中的數據，回拷到源卷中，拷貝完成才能刪除，如上圖。此時咱們能夠設想，若是，針對一份源數據，在18:00建立了快照，上層業務持續產生大量新的數據，19:00又建立了快照，20:00又建立了快照……那麼，在有多份快照的狀況下，若是須要刪除快照，就會出現，多個快照向源捲回拷數據的狀況，可能致使回拷量很是大，耗時很長。

兩種技術對比

如上表，COW的寫時拷貝，致使每次寫入都有拷貝操做，大量寫入時，源卷的寫性能會有所降低，而讀源卷是不會受到任何影響的，刪除快照時，只是解除了快照和源卷的關係，同時刪除了快照卷的數據而已。ROW在每次寫入僅作了重定向操做，這個操做耗時是幾乎能夠忽略不計的，源卷的寫性能幾乎不會受到影響，但讀源卷時，則須要判斷數據是建立快照前仍是建立快照後，致使大量讀時，性能受到必定影響，比較致命的是，若源卷有多個快照，在刪除快照時，全部快照的數據均須要回拷到源卷才能夠保證源卷數據的完整性。

結語

上面簡單地介紹了存儲快照的實現原理，實際上，快照特性應用普遍，其應用對象是不少的：

目前，主流廠商在自研產品上，對上面的ROW和COW技術都有小範圍的改動，也有一些新興的快照技術已經誕生，但這個行業裏，沒有最好的快照技術。技術爲業務服務，只有針對業務類型作好本地化適配，才能達到最佳效用。

問答

消失存儲過程？

相關閱讀

騰訊雲CIS入門——Kubernetes部署

騰訊雲API：用Python使用騰訊雲API（機器翻譯實例）

主機遷移實踐分享

此文已由做者受權騰訊雲+社區發佈，原文連接：https://cloud.tencent.com/developer/article/1158686?fromSource=waitui

歡迎你們前往騰訊雲+社區或關注雲加社區微信公衆號（QcloudCommunity），第一時間獲取更多海量技術實踐乾貨哦~

海量技術實踐經驗，盡在雲加社區！