設計Azure 非關聯式資料的儲存方案

26 min readJan 27, 2022

在本文中，我們將介紹不同的存儲策略。存儲策略將包括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中的資料分開？

更多的Sotrage accounts資訊可參考此篇文件。

資料冗餘(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類型的比較。

Ultra-disk storage 提供了最佳效能。除了high throughput、high IOPS 和low latency之外，如果我們還需要最快的存儲效能，請選擇此選項。 Ultra-disk storage在每個Azure region不一定都有提供。
Premium SSD storage. Azure Premium SSD-managed disks 以low latency提供high throughput和 IOPS。與 Ultra Disk Storage 相比，這些disk的效能略遜一籌。 Premium SSD storage在所有的Azure Region都有．
Standard SSD. Azure Standard SSD-managed disks 對於需要在較低速度下保持一致性能的虛擬機來說，它是一種經濟高效的存儲選項。 Standard SSD disk 不如premium SSD disk 或 Ultra Disk Storage 快。我們可以將standard SSD disk attach到任何 VM。
Standard HDD. 在 Azure Standard HDD-managed disks中，資料存儲在具有移動心軸的傳統disk driver上。與SSD相比，disk速度較慢且速度變化較大。與標準 SSD disk一樣，您可以將標準 HDD disk用於任何 VM。

更多有關Azure Managed Disk的資訊可參考此篇文件．

用disk caching增強效能

Azure VM disk caching是關於優化對virtual hard disk (VHD) file的read/write access。這些 VHD attach到 Azure VM。以下是data disk 的推薦disk caching設置。

注意：
Disk caching不支援 4 TB以上的disk。當多個disk attach到我們的 VM 時，每個小於 4 TB 的disk都將支援cache。變更Azure disk 的cache setting會detaches並reattaches target disk。如果變更的是OS disk時，VM 會重新啟動。

使用加密來保護Disk的安全

Azure針對managed disks提供了數種的加密類型，包含Azure Disk Encryption (ADE), Server-Side Encryption (SSE) and encryption at host.

Azure Disk Encryption ADE 加密VM的VHD。如果 VHD 受 ADE 保護，則disk image只能由擁有該disk的VM存取。
Server-Side Encryption （也稱為encryption-at-rest or Azure Storage encryption）在資料中心的physical disk上執行。如果有人直接存取 physical disk，資料是加密的。當從disk access data時，它會被解密並加載到memory中。
Encryption at host 確保存儲在 VM 主機上的資料at rest時被加密，並以加密的方式流向存儲服務。啟用主機加密的disk未使用 SSE 加密。相反，VM 底層的Server為我們的資料提供加密，並且加密的資料流入 Azure storage。

Storage 安全的設計

Azure storage提供分層的安全模型。此模型使我們能夠保護和控制對storage account的存取等級。在這裡，我們將介紹一些存儲安全的最佳實踐。

使用hared access signatures (SAS)限制Azure Storage的存取

它提供對storage account中資源的secure delegated access。借由 SAS，我們可以對client 進行granular control 來控制如何存取我們的資料。例如：

client可以存取哪些資源。
他們對這些資源擁有什麼權限。
SAS 的有效期。

啟用 firewall policies 與rules

配置防火牆規則以限制對我們的storage account的存取。 Requests可以限制為特定的 IP 地址或範圍，或 Azure virtual network中的subnets lists。 Azure storage firewall為storage account的public endpoint提供access control。在使用private endpoint時，我們還可以使用firewall block 通過public endpoint的所有access。我們的storage firewall configuration還允許選擇受信任的 Azure 平台服務來安全的access storage account。

使用 service endpoint限制network access

我們可以使用virtual network service endpoint來提拱直接的連結給我們的Azure storage.

Service endpoints有以下幾種優勢．

允許我們將 Azure storage account納入到我們的virtual network的保護中。
通過永遠將流向 Azure storage 的流量保持在 Azure backbone network上，提供最佳路由。
Service endpoints 使 VNet 中的private IP address 能夠access service endpoint。不需要public IP address。
使on-premise networks能夠使用 NAT IP access resources。

決定何時使用 private endpoints

Private endpoint是virtual networks中 Azure service的特定的 network interface。當我們為storage account創建private endpoint時，它會在 VNet 上的client和storage之間提供安全連接。

啟用安全傳輸

我們可以將storage account配置為接受來自安全連接的請求。這是通過為storage account設置安全傳輸所需屬性來完成的。當我們需要安全傳輸時，來自非安全連接的任何請求都會被拒絕。 Microsoft 建議我們始終要求對所有stroage account進行安全傳輸。有關更多安全傳輸的資料請參考此篇文件．

使用customer-managed encryption keys

Storage account中的資料會自動加密。 Azure Storage encryption提供了兩種用於在storage account level管理加密密鑰的選項：

Microsoft-managed keys.這是預設選項，微軟會管理並使用這些key來加密我們的storage account.
Customer-managed keys. 我們可以選擇管理storage account的加密密鑰。 Customer-managed keys必須存儲在 Azure Key Vault 中。當我們bring-your-own-key(BYOK) 時，我們可以完全控制誰可以使用加密密鑰以及誰可以access加密資料。

關於Storage的安全性考量

適用於Azure security baseline for Azure Storage會授與對 Azure Storage resources的有限存取權。 Azure Azure security baseline提供保護 Azure 儲存體的完整方式清單。
Shared access signatures可提供對儲存體帳號中資源的安全委派存取權。使用 SAS 時，控制用戶端存取資料的方式更為精細。
防火牆原則和規則會限制對儲存體帳戶的存取權。要求可以限制在特定 IP 位址或範圍，或 Azure 虛擬網路中的子網路清單。 Azure 儲存體防火牆會為儲存體帳戶的公用端點提供存取控制。
Virtual network service endpoints會限制網路存取，並提供對 Azure 儲存體的直接連線。可以將儲存體帳戶保護至虛擬網路，並在虛擬網路中啟用private IP 位址以連線到服務端點。透過private endpoints，可以在虛擬網路中建立適用於 Azure 服務的特殊網路介面。
安全傳輸可讓 Azure 儲存體帳戶接受來自安全連線的要求。當要求安全傳輸時，源自非安全連線的任何要求都會被拒絕。 Microsoft 建議一律要求所有儲存體帳戶使用安全傳輸。
儲存體帳戶中的資料會自動加密。 Azure 儲存體加密提供兩種方式來管理儲存體帳戶層級的加密金鑰：
— Microsoft-managed keys：根據預設，Microsoft 會管理用來加密儲存體帳戶的金鑰。
— Customer-managed keys:：您可以選擇是否要管理儲存體帳戶的加密金鑰。這些金鑰必須儲存在 Azure Key Vault 中。