Azure 儲存體 磁帶移轉概觀

本文著重於磁帶移轉。 其旨在簡化、提供指引和考慮，以順利將儲存在各種磁帶媒體上的數據移轉至 Azure 記憶體服務。

概觀

磁帶會儲存大量的世界數據，而且仍然是其中一種主要類型的儲存媒體。 磁帶媒體存在數十年，而且每年大量使用數百 PB 的新磁帶。

磁帶是儲存冷數據的絕佳媒體。 它們在循序讀取中很快速，但需要機械移動的階段（如載入和卸除磁帶、磁帶搜尋等）的速度較慢。 這使得磁帶無法用於傳統、隨機式存取，而且是目前儲存在磁帶上的數據很少使用的主要原因。 此外，磁帶是需要特殊處理的磁媒體。 它們對環境特別敏感，尤其是溫度和濕度。 如果保存在其操作環境範圍內，則可以達到高持久性，並取得良好的還原成功率。 不過，當保留在不友好的環境中時，經常發生惡化，並轉譯磁帶無法讀取。

大部分的磁帶會儲存深色數據（建立和儲存的數據，但不會用於任何用途）。 深色數據不會為數據擁有者帶來任何值。 隨著 AI 功能和輔助功能的增加，趨勢正在改變。 客戶正在研究深色數據如何協助他們提高效率、開啟新的收入來源，或提高其競爭優勢。 為了利用深色數據，許多組織都考慮將數據從磁帶移轉至雲端記憶體。 雲端記憶體可讓您輕鬆地分析數據、擷取商業價值（使用 AI、機器學習、Azure 搜尋服務等服務），或利用封存記憶體進行長期保留來降低成本。

我們看到磁帶到雲端移轉增加的一些主要原因如下：

• 從深色數據擷取商業價值，
• 減少長期保留管理數據所需的工作
• 避免從一個磁帶產生到另一個磁帶的移轉程式，
• 降低數據遺失的風險，特別是針對較舊的一代磁帶，
• 更換異地磁帶儲存設施，
• 簡化災害復原程式，
• 將 AI 和 ML 等新式工具套用至歷程記錄數據。

考量

在磁帶移轉程序開始之前，必須仔細考慮選項。 第一個考慮是決定誰執行移轉。 常用的兩個選項：

• 客戶執行 移轉時客戶執行端對端移轉，
• 客戶將磁帶運送到合作夥伴的磁帶移轉合作夥伴 ，合作夥伴會執行移轉程式。

方法	優點	缺點
客戶執行移轉	- 數據永遠不會離開網站 - 沒有運送磁帶的物流	- 需要硬體資源 - 將更多工作新增至人員 - 需要處理磁帶的特定知識 - 可能未知的成本
磁帶移轉合作夥伴	- 簡單的定價和已知的成本預付 （按磁帶付費） - 不會影響生產環境 - 不會影響人員	- 需要運送磁帶的物流 - 由於運送磁帶而需要的安全性考慮 - 移轉期間數據可用性所需的多個複本

有幾個主要考慮可輕鬆地引導我們決定誰可以執行移轉、客戶或合作夥伴。

資源

資源是磁帶移轉程式最重要的部分，我們會將它們分成下列類別：

類別	備註
人員	- 需要特定一組技能 - 程式需要大量人力
硬體	- 不同的磁帶世代需要不同類型的硬體 - 移轉速度與可用的磁碟驅動器和網路頻寬成正比
軟體	- 需要存取建立數據的軟體 - 需要存取加密金鑰

硬體通常是最具挑戰性的部分。 如果我們要移轉現有的磁帶世代，硬體可以使用，但做為現有生產環境的一部分使用。 但對於較舊的磁帶世代來說，硬體通常是生命周期結束，而且很難取得。 使用較舊的磁帶產生時，使用磁帶移轉合作夥伴是慣用且更簡單的選項。 當生產硬體用於移轉時，需要仔細規劃，以確保移轉不會干擾生產工作負載。 我們在這裡可以套用三種不同的模型：

1. 使用專用硬體進行移轉：最簡單的移轉模型、輕鬆排程，並規劃不會影響生產環境。 它增加了取得硬體的成本（如果尚未可用），並在移轉后造成低硬體使用率。
2. 在生產硬體上執行移轉時數：移轉模型不會影響生產環境。 需要複雜的排程、執行，以及下班人員。 只有在生產硬體未使用 24x7 時，才可能。
3. 一起執行生產環境，並一起移轉：最不慣用的移轉模型，因為它很容易影響生產環境。 此模型可減少生產環境可用的硬體、需要複雜的排程和規劃。 如果使用此模型，減少對生產環境的影響，對於控制移轉時程表至關重要。 只有在生產硬體使用率低時，才建議使用此模型。

資料傳輸選項

從磁帶讀取數據之後，必須將它移至 Azure 儲存體。 您可以使用網路或離線裝置來行動資料，例如 Azure 資料箱。 影響資料傳輸選項選擇的一些參數如下：

• 可用的網路頻寬
• 完成移轉所需的時程表
• 數據變更的頻率

在這裡深入瞭解如何選取最佳選項的指引。 網路傳輸更簡單且慣用的選項。 也可以組合網路和離線方法，但需要更多規劃，以確保已移轉的數據不會重疊。

如果沒有可用的資源來執行移轉，無論資源類型為何，我們唯一的選項是使用磁帶移轉合作夥伴。 在此情況下，我們可以在兩個選項之間選擇：

1. 在客戶網站上執行的移轉：磁帶移轉合作夥伴會提供硬體、僱用人員，並在客戶的位置上執行工作。 客戶需要提供磁帶的存取權、設備專用空間、網路連線，以及存取 Azure 儲存體 服務。 合作夥伴負責所有其他活動。
2. 在合作夥伴網站上執行的移轉：客戶會將磁帶運送到合作夥伴，並提供 Azure 儲存體 服務的存取權。 磁帶移轉合作夥伴會執行所有工作，將數據從磁帶遷移至 Azure 儲存體。

第二個選項比較容易，而且更常用。 磁帶移轉合作夥伴具有設計且能夠大規模執行磁帶移轉的設施。 此選項也會降低風險，以及因為合作夥伴有更多可用的硬體資源，因此時程表。 只有在安全性，且隱私權考慮不允許客戶將磁帶寄送給合作夥伴時，才會在客戶網站上執行移轉。

數個合作夥伴可以執行磁帶移轉至 Azure。 您可以在離線媒體匯入中找到合作夥伴的完整清單。

以下是簡化選取程式的簡單流程圖。

資料格式

數據格式對移轉設計有很大的影響，而且是未來數據可用性的重要考慮。 數據可以以專屬或原生格式儲存。 專屬格式通常儲存為虛擬磁帶。 原生格式需要從磁帶還原檔案，並將其儲存為檔案或物件。

模型	優點	缺點
虛擬磁帶	- 更輕鬆且更快速的移轉 - 可以重新建立與原始相同的磁帶媒體 - 不需要存取原始軟體來寫入數據	- 需要維護虛擬磁帶清查 - 以應用程式相依格式儲存的數據，需要原始軟體才能還原數據 - Azure 服務無法存取的數據（AI/ML），而不需要還原
原生檔案	- 任何應用程式與服務都可以存取的檔案 （AI/ ML） - 可能讓數據獲利 - 不需要存取原始軟體進行還原	- 更複雜的移轉 - 需要存取原始軟體以寫入數據

決定格式的主要準則是我們計劃使用數據的方式。 如果數據只針對長期保留進行移轉，則虛擬磁帶是不錯的選擇。 在其他情況下，以原生格式儲存數據是慣用的選項。 它可讓您在未來輕鬆使用數據，並透過數據分析開啟許多可能性。

移轉程序

一旦我們決定移轉執行，以及慣用的數據格式，我們可以從移轉開始。 移轉會經歷數個階段。

信息階段

信息階段對於收集重要需求至關重要。 收集的資訊指南正確設計和規劃。 雖然某些資訊可以在後續階段更新，但提供精確的資訊會設定場景，並避免需要對程序進行巨大的變更。 此階段需要回答的一些關鍵問題包括：

• 需要移轉哪種類型的磁帶（例如 LTO3、LTO6、3592JC 等）。
• 需要移轉之每個模型的磁帶數量為何（例如 100xLTO3、200xLTO6 等等）。
• 哪些軟體是用來在磁帶上寫入數據，該軟體仍可使用？
• 使用何種格式在磁帶上寫入數據，是否開啟或專屬格式會套用壓縮？
• 是否使用加密，如果是，交換加密密鑰的最安全選項為何？
• 目標區域為何？
• 使用何種記憶體服務？
• 哪些法規需求至關重要（HIPAA、GDPR 等）？ 監管鏈是強制性的嗎？
• 什麼是移轉期限？ 是否有任何重要的里程碑？
• 有多少網路頻寬可供移轉？
• 磁帶實際儲存在哪裡，而且可以寄送？
• 您是否已經有所有檔案的哈希值？ 如果是，則會使用哪一種哈希演算法？
• 移轉後是否需要磁帶？
• 如何在移轉/傳輸期間維護磁帶的溫度和濕度？
• 誰是主要項目關係人？

準備階段

收集基本資訊之後，我們可以準備移轉。 準備階段可以包含許多不同的步驟，但大部分移轉都有一些常見的步驟：

1. 數據分析 提供需要移轉之數據的資訊。 信息對於估計從磁帶讀取數據的速度，以及我們需要達到多少平行處理原則，才能在期限前順利完成移轉非常重要。 它會影響對所需硬體的估計（連結庫、機器人、磁碟驅動器）。 數據分析是透過取樣多個磁帶來完成，這些磁帶代表要移轉的數據集。 我們正在尋找的一般資訊如下：

   • 檔案大小，
   • 每個磁帶儲存的數據量，
   • 每個磁帶的檔案數目，
   • 最小和檔案大小上限，
   • 檔案類型。

2. 數據品質 有助於估計需要移轉的最終數據集和唯一數據集。 磁帶移轉最常見的問題之一是重複數據。 磁帶移轉是清除重複數據的理想時間。 此程式可改善未來使用的數據品質、降低成本，以及移轉的持續時間。

3. 數據優先順序 決定數據可移轉的順序。 在理想情況下，我們想要從每個磁帶實現直接串流，而不是從不同的磁帶隨機讀取檔案（以避免不斷載入、卸除和搜尋）。 此方法可達到最高的輸送量，而且一律是最快速的移轉路徑。 數據優先順序採用商務需求和技術可行性，以達到最佳結果。

4. 移轉設計 包含移轉的所有技術層面，以及可形成最終移轉程序的資訊。 這是一份書面檔，成為其餘階段的真相來源。 它至少必須包含：

   • 清除移轉程式，以及移轉期限
   • 硬體和人員需求、
   • 基礎結構和網路設計、
   • 安全性考慮，
   • 如何處理無法讀取的磁帶，
   • 角色和責任等。

移轉階段

移轉設計完成後，我們會開始移轉程式。 在提高到完整移轉步調之前，我們一律會以較小的樣本執行測試。 測試的目標是確保端對端程式正常運作。 它可讓我們進行調整，並改善程式。 一旦測試成功，且我們對結果感到滿意，我們會執行移轉。 如果我們使用原生檔案與虛擬磁帶，移轉階段會稍有不同。 在這兩種情況下，這是一個重複的程式，會迴圈所有磁帶，並讀取其整個內容。 此流程圖會顯示移轉至原生檔案時的移轉階段。

資料驗證

針對我們移轉的每個檔案，我們需要執行數據驗證，以確保數據在移轉過程中未損毀。 數據驗證是藉由在移轉之前和移轉之後比較哈希值來完成。 有許多類型的哈希演算法可以使用。 常見的方法是使用 MD5，因為 Azure 儲存體 包含可在移轉期間填入的預先定義元數據欄位 Content-MD5。 當我們存取數據以驗證數據未變更或損毀時，此方法允許檢查相同的 MD5 值。 在理想情況下，源數據已經包含哈希值，與移轉后哈希值相比很容易。 如果哈希不存在，則必須在移轉檔案之前加以計算。 如果哈希相符，檔案會標示為已移轉。 如果沒有，則會捨棄檔案，並再次移轉。 有時候來源磁帶上的數據已損毀。 擁有原始哈希值有助於攔截這些罕見的情況。 如果發生，我們可以從次要複本讀取數據，如果存在的話。 數據驗證程式是移轉設計的重要元件。 必須定義處理失敗驗證的程式。 移轉階段也會持續受到監視，以確保我們可以對無法預測的情況做出反應，並加以調整。 定期向主要專案關係人報告，對於讓移轉保持正軌很重要。

移轉後階段

移轉完成後，在成功關閉移轉專案之前，我們仍需考慮幾個步驟。 如有需要，我們需要處置用於移轉的硬體。 最重要的問題是如何處置磁帶。 磁帶處置是兩個步驟的程式。 如果磁帶正在儲存敏感性和機密資訊（且通常確實這麼做），則必須先予以消損。 解除管制可確保所有數據都會從媒體磁上刪除。 刪除之後，磁帶必須正確終結並回收。 如果我們使用磁帶移轉合作夥伴，也可以讓合作夥伴安全地處置磁帶。

下一步

• Azure 儲存體 概觀
• Azure 離線媒體匯入
• 比較數據傳輸選項
• 儲存體移轉概觀