在本文中，我們將介紹不同的存儲策略。 存儲策略將包括data types, storage accounts, blob storage, file storage, disk storage, storage security, 與資料保護。

在這裏我們會學習到的是：

• Design for data storage.
• Design for Azure storage accounts.
• Design for Azure blob storage.
• Design for Azure files.
• Design an Azure disk solution.
• Design for storage security.
• Design for data redundancy.

設計data storage
設計Azure storage,我們首先檢視我們有哪些類型的資料

Structured data包括relational data並具有shared schema。 Structured data通常存儲在具有rows, columns, and keys的DB table中。 Structured data通常用於電商網站等交易型的使用。

Semi-structured data的資料組織性不如Structured data，並且不以Structured data存儲。 Semi-structured data field不能整齊地放入table、column和row中。 Semi-structured data包含明確資料組織方式的tags。 這種風格的資料呈現和結構是由serialization language定義的。 Semi-structured data的範例包含Hypertext Markup Language (HTML) files, JavaScript Object Notation (JSON) files, and Extensible Markup Language (XML) files

Unstructured data是資料組織結構中最少的資料類型。 Unstructured data的資料組織是模棱兩可的。 Unstructured data的範例包括：

• 媒體檔案，例如photos, videos, audio files
• Office 文件，例如 Word 檔
• Text file (如email內的文字)

Azure non-relational storage objects
在Azure中， 非關聯式資料包含了幾種不同的storage data objects. 而我們將會介紹以下四種型態

Azure Blob storage(等同於AWS S3/ GCP Cloud storage) 是用於存儲大量非結構化資料的object store。 Blob 代表 Binary Large Object，其中包括圖片和多媒體文件等object。

Azure Files(等同於AWS EFS/ GCP File storage) 是一種sahred storage service。簡單的來說就是Azure提供 基於Linux based上的Server Message Block (SMB) or CIFS (Common Internet File System )服務。

Azure managed disks，一種block-level 的storage volumes。由Azure託管並且用於Azure VM上。

Azure Queue Storage(等同於AWS SQS/ GCP Pub&Sub) ，這是一種儲存大量message的服務。Queue通常用於非同步處理的message。

Azure storage accounts的設計
確定資料存儲的需求後，我們需要建立 storage accounts。 Azure storage accounts將我們需要的所有 Azure storage service組合在一起。 storage accounts提供了一個唯一的namespace，可通過 HTTPS 進行存取。 storage accounts中的資料是持續且高可用、安全且可大規模擴展。

選擇正確的stroage account 種類
Azure storage提供多種storage account。 每種類型都支援不同的功能，並有自己的計價模型。 我們考慮這些差異以確定最適合我們Application的帳戶類型。 storage account的類型包括：

決定需要多少個storage accounts
Storage accounts呈現一個 location, replication strategy, 與subscription owner等設置的集合。 公司組織通常有多個Storage accounts，因此我們可以實現不同的需求。 下圖顯示了一個設置不同的兩個Storage accounts。 需求的差異性讓我們需要建立不同的Storage accounts。

建立Storage accounts需要考量的事項

• 地點(Location) — 我們是否有特定於某個國家或地區的資料？ 出於效能原因，我們可能希望將資料放在靠近客戶/使用者的位置。 每個位置可能需要一個storage account。
• 合規(Compliance) — 我們是否有將資料保存在特定位置的法規要求？ 我們是否有稽核或存儲資料的內部要求？
• 成本(Cost) — storage account本身沒有成本； 但是，我們為帳戶選擇的設置確實會影響帳戶中的服務成本。Geo-redundant storage的成本高於locally redundant storage。 Premium performance 與 hot access tier增加了 blob 的成本。 我們是否需要按部門或專案追踪費用或帳單？ 我們是否與需要分離與合作夥伴一起合作的存儲成本？
• 複製(Replication) — 我們的資料存儲是否有不同的replication strategies？ 例如，我們可以將資料劃分為重要和不重要類別。 我們可以將重要資料放入具有geo-redundant storage的storage account中。 我們可以將不重要資料放在locally redundant storage的不同storage account中。
• 管理成本(Admin overhead) — 個storage account都需要管理員花費一些時間和精力來創建和維護。 它還增加了將任何人將資料放到 cloud storage的複雜性。 所有的管理員都需要了解每個storage account的用途，以便將新的資料放到到正確的account
• 資料敏感度(Data sensitivity) — 我們是否有一些公司的專有資料和一些供公眾使用的資料？ 如果是這樣，我們可以為公司的專有資料而不是公眾資料啟用虛擬網路。 這可能需要單獨的storage account。
• 資料隔離(Data isolation) — 法規、合規性或當地政府政策可能要求對資料進行隔離。 也許一個Application中的資料應該與另一個Application中的資料分開？

資料冗餘(Data redundancy)的設計
Azure storage 永遠都會有資料的多個副本。 這種冗餘可確保資料免受預期內或預期外的影響。 這些事故可能包括短暫的硬體故障、網路斷線或斷電，以及大規模的自然災害。 Storage redundancy可確保我們的storage accounts滿足其可用性和持久性目標。

在決定哪種redundancy option最適合我們時，我們需要考慮在較低成本和較高可用性之間進行權衡。 有助於確定我們應該選擇哪種redundancy option的因素包括：

• 我們的資料如何在主要region中進行replicate。

• 我們的資料是否複製到第二個region。 第二個region在地理上遠離主要region。 這有助於防止區域性災難。

如果主要region因任何原因變得不可用，我們的application是否需要對secondary region中的replicated data進行read access。
在主要Region的Redunancy
Azure提供兩種在主要Region replicate 資料的類型

Locally redundant storage (LRS) 是成本最低的redundancy option，與其他選項相比，它的durability最低。 LRS 保護我們的資料免受server/driver/故障的影響(AWS與GCP都沒有管到這麼細)。 但是，如果資料中心出現故障，則使用 LRS 的storage account的所有副本都可能不見或無法恢復。 LRS 是可以用在以下狀況：

• 如果我們的Application的資料在發生資料遺失時可以簡單的重建。

如果由於資料治理要求，您的Application僅限於在一個國家或地區內replicating data。
Zone-redundant storage (ZRS) 跨主要region中的三個 Azure 可用性區域(availability zones)同步複製。 使用 ZRS，即使zone不可用，我們的資料仍可用於read/write操作。 如果我們的資料暫時無法使用，ZRS 可為我們的資料提供效能、低延遲和彈性。 但是，ZRS 本身可能無法保護您的資料當有多個zone有問題時的regional disaster。

第二個Region的Redundancy
對於需要high durability的Application，我們可以選擇將storage account中的資料複製到secondary region。 建立storage accounts時，我們選擇該帳戶的主要region。 配對的econdary region根據主要region決定的(也就是我們們無法任意選擇secondary region)。 Azure storage提供了兩種將資料複製到secondary region的選項: Geo-redundant storage (GRS), and Geo-zone-redundant storage (GZRS).

• GRS 和GZRS 之間的主要區別在於資料在主要region中的複製方式。 在secondary region內，資料是複製到LRS。

• 如果主要region不可用，我們可以選擇fail over到secondary region。 failover完成後，secondary region成為主要region，我們可以再次read/write data

• 資料非步複製到secondary region話， 如果無法恢復主要region，影響主要region的故障可能會導致我們損失部分資料。

GRS 或GZRS運作時，secondary region中的資料無法read/write，除非fail over到secondary region。 要對secondary region進行read access，我們要將storage account配置為使用讀取訪問read-access geo-redundant storage (RA-GRS) 或read-access geo-zone-redundant storage (RA-GZRS)。
小提示:
如果我們的storage account配置設定對secondary regions進行讀取，那麼我們可以將Application設計為在主要region因任何原因變得不可用時無縫轉換為從secondary region讀取資料。更多的 資訊可參閱此篇文件。

Azure blob storage的設計
在設計 Blob storage時，我們將重點介紹兩個主要方向。 首先是確定 blob access tire。 Blob storage type會影響資料存儲的”可用性、延遲和成本”。 第二個方向是決定是否需要不可變更的儲存。

Azure blob access tier
將資料放置在適當的access tier有助於來優化我們的存儲成本。

• Hot tier — 預設情況下，在hot access tier中創建新的storage account。 hot tier針對storage account中物件頻繁read/write進行了優化。 hot tier的存儲成本高於cool 、cold與archive tiers，但存取成本最低。
• Cool tier — 針對存儲不經常存取的大量資料進行了優化。 這個等級適用於會在cool tier中保留至少 30 天的資料。 與hot storage相比，cool tier具有更低的存儲成本和更高的存取成本。 cool tier的一個範例是短期備份和災難復原以及舊多媒體內容。 此內容不會經常存取，但資料必須立即取得。
• Cold Tier — 適用於儲存大量不常使用的資料。 這個tier適用於至少會保留在層 90 天的資料。
• Archive tier — 針對可以承受數小時retrieval latency的資料進行了優化(意思是我們取出資料要等幾個小時)。 資料必須在archive tier中保留至少 180 天，否則將收取提前刪除費用(也就是就算你刪掉資料沒放，Azure還是要跟你收錢)。 archive tier是存儲資料的最具成本效益的選擇。 但是，但取出資料是所有tier中最貴的。 Archive tier的資料包括secondary backups, original raw data和法規要求的合規資訊。

Azure blob immutable storage
適用於 Azure Blob storage的 immutable storage使user能夠以 WORM（Write Once, Read Many）狀態存儲重要的資料。 處於 WORM 狀態時，無法在user指定的時間間隔內修改或刪除資料。 通過為 blob 資料配置immutability policies，我們可以保護資料不被覆蓋和刪除。 Policies可以用在container level 與audit logs(如下圖)。

下圖顯示了time-based retention policies 和legal holds如何防止寫入和刪除操作。

Azure Blob storage 的 Immutable storage 有兩種policies.

• Time-based retention policies: 使用Time-based retention policies，user可以設置policies以在指定的時間間隔內存儲資料。 當Time-based retention policies被設定時，可以create/read object，但不能修改或刪除。 保留期到期後，object可以被delete但不能被overwritten。]
• Legal hold policies: Legal hold 存儲不可變的資料，直到明確刪掉Legal hold。 設定Legal hold後，可以create/read object，但不能修改或刪除object。

Azure File的設計
將公司的共享文件移動到cloud-based的 Azure File中需要對選項進行分析並制定實施計劃。 有一個重要的決定要做。 哪就是我們將如何access 和update files？ 我們可以選擇將現有的Server Message Block (SMB)file share替換為 Azure File中的等效的文件共享。 另一個選項是設置 Azure File Sync的instance。 如果選擇使用 Azure File Sync，則可以更靈活地保護和存取文件。

什麼是Azure File

我們可以將 Azure File視為託管在 Azure 上的標準文件共享，我們可以使用 SMB/CIFS protocol 進行access。我們可以在所有主要OS 上同時mount或連接到 Azure file share。

Azure File可用於添加或替換公司現有的地端 NAS 或file server。我們的組織想要使用 Azure File的一些可能原因會有：

• 開發人員可以將Application和configuration files存儲在文件共享中，並將新 VM 連接到共享文件。這減少了將新機器投入生產的時間。
• 借助 Azure 上的file share，公司無需購買和部署昂貴的redundant hardware並管理軟體更新。這些共享是跨平台的，我們可以從 Windows、Linux 或 macOS 連接到它們。
• Azure 平台的所有resilience都由file share繼承，這使得file是globally redundant。我們還可以選擇使用整合快照功能並使用Recovery Services vaults設置自動備份。
• 所有資料在傳輸過程中都使用 HTTPS 進行加密，並at-rest時加密存儲。

Azure files share 可以通過兩種方式使用：直接mount 這些serverless Azure file share(SMB) 或使用 Azure file sync 在on-premise cache Azure file shares。

• Direct mount of an Azure file share: 由於 Azure Files 提供 SMB access，因此我們可以在on-premise或cloud中mount Azure file shares， Windows、macOS 和 Linux 中可用的標準 SMB client 來mount Azure file shares。 由於 Azure file shares是serverless，因此為正式環境進行部署不需要像在地端機房管理file server or NAS設備。 直接mount 意味著我們不必管底層的硬體或與其相關的軟體update.
• Cache Azure file share on-premises with Azure File Sync: Azure File Sync 允許我們集中組織的文件共享。 Azure Files提供on-premises file server的靈活性、效能和相容性。 Azure File Sync將on-premises (or cloud)）Windows Server 轉換為 Azure file shares 的cache，也就是主體資料位於Azure，而地端機房的File Server屬於cache layer。

選擇我們需要的效能層級
由於 Azure Files將file存儲在storage account中，因此我們可以在standard 或premium的效能storage account之間進行選擇。

Standard performance accounts使用 HDD 存儲數據。 使用 HDD，成本更低，但效能也更低。 SSD arrays支援premium storage account的效能，這會帶來更高的成本。 目前，premium storage account只能在一些region中使用具有 ZRS 存儲的file storage account，也就是Premium storage account還不能支援全部的Azure Region。

決定我們的storage tier
Azure Files提供四種不同的storage tiers：premium/transaction optimized/ hot/cool。 這些tier允許我們根據不同狀況的效能和價格要求切割成我們需要的。

何時用Azure files來取代 Azure blobs 或 Azurer NetApp Files
讓我們花一點時間來回顧一下何時應該選擇 Azure blob storage或 Azure NetApp files而不是 Azure file storage。

NetApp Files 是一項全託管、高度可用的企業等級 NAS 服務。 NetApp Files 可以處理要求最苛刻的高效能、低延遲的工作負載。 它可以搬到被認為“無法搬遷移”的工作負載。

我們對哪種技術的決定取決於所需的use case、protocol和效能(如下圖)。

Azure disk 方案設計
在這一部分，我們將關注data disks。 虛擬機使用data disk來存儲資料。 例如，DB files、網站靜態內容或自己開發的code將存儲在data disk上。 我們可以添加的data disks數量取決於虛擬機大小。 每個data disks的最大容量為 32,767 GB。

小提示：
微軟建議我們始終都要使用managed disks. 我們可以明定disk 的size/type然後provision disk.剩下的就交給Azure來處理了．

Data disk 的類型
Azure 提供了多種類型的data disk。 選擇disk類型時，請考慮我們的場景、throughput, and IOPS。 下表提供了四種disk類型的比較。