Azure 儲存體 磁帶移轉概觀
本文著重於磁帶移轉。 其旨在簡化、提供指引和考慮，以順利將儲存在各種磁帶媒體上的數據移轉至 Azure 記憶體服務。
概觀
磁帶會儲存大量的世界數據，而且仍然是其中一種主要類型的儲存媒體。 磁帶媒體存在數十年，而且每年大量使用數百 PB 的新磁帶。
磁帶是儲存冷數據的絕佳媒體。 它們在循序讀取中很快速，但需要機械移動的階段（如載入和卸除磁帶、磁帶搜尋等）的速度較慢。 這使得磁帶無法用於傳統、隨機式存取，而且是目前儲存在磁帶上的數據很少使用的主要原因。 此外，磁帶是需要特殊處理的磁媒體。 它們對環境特別敏感，尤其是溫度和濕度。 如果保存在其操作環境範圍內，則可以達到高持久性，並取得良好的還原成功率。 不過，當保留在不友好的環境中時，經常發生惡化，並轉譯磁帶無法讀取。
大部分的磁帶會儲存深色數據（建立和儲存的數據，但不會用於任何用途）。 深色數據不會為數據擁有者帶來任何值。 隨著 AI 功能和輔助功能的增加，趨勢正在改變。 客戶正在研究深色數據如何協助他們提高效率、開啟新的收入來源，或提高其競爭優勢。 為了利用深色數據，許多組織都考慮將數據從磁帶移轉至雲端記憶體。 雲端記憶體可讓您輕鬆地分析數據、擷取商業價值（使用 AI、機器學習、Azure 搜尋服務等服務），或利用封存記憶體進行長期保留來降低成本。
我們看到磁帶到雲端移轉增加的一些主要原因如下：
- 從深色數據擷取商業價值，
- 減少長期保留管理數據所需的工作
- 避免從一個磁帶產生到另一個磁帶的移轉程式，
- 降低數據遺失的風險，特別是針對較舊的一代磁帶，
- 更換異地磁帶儲存設施，
- 簡化災害復原程式，
- 將 AI 和 ML 等新式工具套用至歷程記錄數據。
考量
在磁帶移轉程序開始之前，必須仔細考慮選項。 第一個考慮是決定誰執行移轉。 常用的兩個選項：
- 客戶執行 移轉時客戶執行端對端移轉，
- 客戶將磁帶運送到合作夥伴的磁帶移轉合作夥伴 ，合作夥伴會執行移轉程式。
| 方法 | 優點 | 缺點 |
|---|---|---|
| 客戶執行移轉 | - 數據永遠不會離開網站 - 沒有運送磁帶的物流 |
- 需要硬體資源 - 將更多工作新增至人員 - 需要處理磁帶的特定知識 - 可能未知的成本 |
| 磁帶移轉合作夥伴 | - 簡單的定價和已知的成本預付 （按磁帶付費） - 不會影響生產環境 - 不會影響人員 |
- 需要運送磁帶的物流 - 由於運送磁帶而需要的安全性考慮 - 移轉期間數據可用性所需的多個複本 |
有幾個主要考慮可輕鬆地引導我們決定誰可以執行移轉、客戶或合作夥伴。
資源
資源是磁帶移轉程式最重要的部分，我們會將它們分成下列類別：
| 類別 | 備註 |
|---|---|
| 人員 | - 需要特定一組技能 - 程式需要大量人力 |
| 硬體 | - 不同的磁帶世代需要不同類型的硬體 - 移轉速度與可用的磁碟驅動器和網路頻寬成正比 |
| 軟體 | - 需要存取建立數據的軟體 - 需要存取加密金鑰 |
硬體通常是最具挑戰性的部分。 如果我們要移轉現有的磁帶世代，硬體可以使用，但做為現有生產環境的一部分使用。 但對於較舊的磁帶世代來說，硬體通常是生命周期結束，而且很難取得。 使用較舊的磁帶產生時，使用磁帶移轉合作夥伴是慣用且更簡單的選項。 當生產硬體用於移轉時，需要仔細規劃，以確保移轉不會干擾生產工作負載。 我們在這裡可以套用三種不同的模型：
- 使用專用硬體進行移轉：最簡單的移轉模型、輕鬆排程，並規劃不會影響生產環境。 它增加了取得硬體的成本（如果尚未可用），並在移轉后造成低硬體使用率。
- 在生產硬體上執行移轉時數：移轉模型不會影響生產環境。 需要複雜的排程、執行，以及下班人員。 只有在生產硬體未使用 24x7 時，才可能。
- 一起執行生產環境，並一起移轉：最不慣用的移轉模型，因為它很容易影響生產環境。 此模型可減少生產環境可用的硬體、需要複雜的排程和規劃。 如果使用此模型，減少對生產環境的影響，對於控制移轉時程表至關重要。 只有在生產硬體使用率低時，才建議使用此模型。
資料傳輸選項
從磁帶讀取數據之後，必須將它移至 Azure 儲存體。 您可以使用網路或離線裝置來行動資料，例如 Azure 資料箱。 影響資料傳輸選項選擇的一些參數如下：
- 可用的網路頻寬
- 完成移轉所需的時程表
- 數據變更的頻率
在這裡深入瞭解如何選取最佳選項的指引。 網路傳輸更簡單且慣用的選項。 也可以組合網路和離線方法，但需要更多規劃，以確保已移轉的數據不會重疊。
如果沒有可用的資源來執行移轉，無論資源類型為何，我們唯一的選項是使用磁帶移轉合作夥伴。 在此情況下，我們可以在兩個選項之間選擇：
- 在客戶網站上執行的移轉：磁帶移轉合作夥伴會提供硬體、僱用人員，並在客戶的位置上執行工作。 客戶需要提供磁帶的存取權、設備專用空間、網路連線，以及存取 Azure 儲存體 服務。 合作夥伴負責所有其他活動。
- 在合作夥伴網站上執行的移轉：客戶會將磁帶運送到合作夥伴，並提供 Azure 儲存體 服務的存取權。 磁帶移轉合作夥伴會執行所有工作，將數據從磁帶遷移至 Azure 儲存體。
第二個選項比較容易，而且更常用。 磁帶移轉合作夥伴具有設計且能夠大規模執行磁帶移轉的設施。 此選項也會降低風險，以及因為合作夥伴有更多可用的硬體資源，因此時程表。 只有在安全性，且隱私權考慮不允許客戶將磁帶寄送給合作夥伴時，才會在客戶網站上執行移轉。
數個合作夥伴可以執行磁帶移轉至 Azure。 您可以在離線媒體匯入中找到合作夥伴的完整清單。
以下是簡化選取程式的簡單流程圖。
資料格式
數據格式對移轉設計有很大的影響，而且是未來數據可用性的重要考慮。 數據可以以專屬或原生格式儲存。 專屬格式通常儲存為虛擬磁帶。 原生格式需要從磁帶還原檔案，並將其儲存為檔案或物件。
| 模型 | 優點 | 缺點 |
|---|---|---|
| 虛擬磁帶 | - 更輕鬆且更快速的移轉 - 可以重新建立與原始相同的磁帶媒體 - 不需要存取原始軟體來寫入數據 |
- 需要維護虛擬磁帶清查 - 以應用程式相依格式儲存的數據，需要原始軟體才能還原數據 - Azure 服務無法存取的數據（AI/ML），而不需要還原 |
| 原生檔案 | - 任何應用程式與服務都可以存取的檔案 （AI/ ML） - 可能讓數據獲利 - 不需要存取原始軟體進行還原 |
- 更複雜的移轉 - 需要存取原始軟體以寫入數據 |
決定格式的主要準則是我們計劃使用數據的方式。 如果數據只針對長期保留進行移轉，則虛擬磁帶是不錯的選擇。 在其他情況下，以原生格式儲存數據是慣用的選項。 它可讓您在未來輕鬆使用數據，並透過數據分析開啟許多可能性。
移轉程序
一旦我們決定移轉執行，以及慣用的數據格式，我們可以從移轉開始。 移轉會經歷數個階段。
信息階段
信息階段對於收集重要需求至關重要。 收集的資訊指南正確設計和規劃。 雖然某些資訊可以在後續階段更新，但提供精確的資訊會設定場景，並避免需要對程序進行巨大的變更。 此階段需要回答的一些關鍵問題包括：
- 需要移轉哪種類型的磁帶（例如 LTO3、LTO6、3592JC 等）。
- 需要移轉之每個模型的磁帶數量為何（例如 100xLTO3、200xLTO6 等等）。
- 哪些軟體是用來在磁帶上寫入數據，該軟體仍可使用？
- 使用何種格式在磁帶上寫入數據，是否開啟或專屬格式會套用壓縮？
- 是否使用加密，如果是，交換加密密鑰的最安全選項為何？
- 目標區域為何？
- 使用何種記憶體服務？
- 哪些法規需求至關重要（HIPAA、GDPR 等）？ 監管鏈是強制性的嗎？
- 什麼是移轉期限？ 是否有任何重要的里程碑？
- 有多少網路頻寬可供移轉？
- 磁帶實際儲存在哪裡，而且可以寄送？
- 您是否已經有所有檔案的哈希值？ 如果是，則會使用哪一種哈希演算法？
- 移轉後是否需要磁帶？
- 如何在移轉/傳輸期間維護磁帶的溫度和濕度？
- 誰是主要項目關係人？
準備階段
收集基本資訊之後，我們可以準備移轉。 準備階段可以包含許多不同的步驟，但大部分移轉都有一些常見的步驟：
數據分析 提供需要移轉之數據的資訊。 信息對於估計從磁帶讀取數據的速度，以及我們需要達到多少平行處理原則，才能在期限前順利完成移轉非常重要。 它會影響對所需硬體的估計（連結庫、機器人、磁碟驅動器）。 數據分析是透過取樣多個磁帶來完成，這些磁帶代表要移轉的數據集。 我們正在尋找的一般資訊如下：
- 檔案大小，
- 每個磁帶儲存的數據量，
- 每個磁帶的檔案數目，
- 最小和檔案大小上限，
- 檔案類型。
數據品質 有助於估計需要移轉的最終數據集和唯一數據集。 磁帶移轉最常見的問題之一是重複數據。 磁帶移轉是清除重複數據的理想時間。 此程式可改善未來使用的數據品質、降低成本，以及移轉的持續時間。
數據優先順序 決定數據可移轉的順序。 在理想情況下，我們想要從每個磁帶實現直接串流，而不是從不同的磁帶隨機讀取檔案（以避免不斷載入、卸除和搜尋）。 此方法可達到最高的輸送量，而且一律是最快速的移轉路徑。 數據優先順序採用商務需求和技術可行性，以達到最佳結果。
移轉設計 包含移轉的所有技術層面，以及可形成最終移轉程序的資訊。 這是一份書面檔，成為其餘階段的真相來源。 它至少必須包含：
- 清除移轉程式，以及移轉期限
- 硬體和人員需求、
- 基礎結構和網路設計、
- 安全性考慮，
- 如何處理無法讀取的磁帶，
- 角色和責任等。
移轉階段
移轉設計完成後，我們會開始移轉程式。 在提高到完整移轉步調之前，我們一律會以較小的樣本執行測試。 測試的目標是確保端對端程式正常運作。 它可讓我們進行調整，並改善程式。 一旦測試成功，且我們對結果感到滿意，我們會執行移轉。 如果我們使用原生檔案與虛擬磁帶，移轉階段會稍有不同。 在這兩種情況下，這是一個重複的程式，會迴圈所有磁帶，並讀取其整個內容。 此流程圖會顯示移轉至原生檔案時的移轉階段。
資料驗證
針對我們移轉的每個檔案，我們需要執行數據驗證，以確保數據在移轉過程中未損毀。 數據驗證是藉由在移轉之前和移轉之後比較哈希值來完成。 有許多類型的哈希演算法可以使用。 常見的方法是使用 MD5，因為 Azure 儲存體 包含可在移轉期間填入的預先定義元數據欄位 Content-MD5。 當我們存取數據以驗證數據未變更或損毀時，此方法允許檢查相同的 MD5 值。 在理想情況下，源數據已經包含哈希值，與移轉后哈希值相比很容易。 如果哈希不存在，則必須在移轉檔案之前加以計算。 如果哈希相符，檔案會標示為已移轉。 如果沒有，則會捨棄檔案，並再次移轉。 有時候來源磁帶上的數據已損毀。 擁有原始哈希值有助於攔截這些罕見的情況。 如果發生，我們可以從次要複本讀取數據，如果存在的話。 數據驗證程式是移轉設計的重要元件。 必須定義處理失敗驗證的程式。 移轉階段也會持續受到監視，以確保我們可以對無法預測的情況做出反應，並加以調整。 定期向主要專案關係人報告，對於讓移轉保持正軌很重要。
移轉後階段
移轉完成後，在成功關閉移轉專案之前，我們仍需考慮幾個步驟。 如有需要，我們需要處置用於移轉的硬體。 最重要的問題是如何處置磁帶。 磁帶處置是兩個步驟的程式。 如果磁帶正在儲存敏感性和機密資訊（且通常確實這麼做），則必須先予以消損。 解除管制可確保所有數據都會從媒體磁上刪除。 刪除之後，磁帶必須正確終結並回收。 如果我們使用磁帶移轉合作夥伴，也可以讓合作夥伴安全地處置磁帶。