本文属于【Azure 架构师学习笔记】系列。
本文属于【Azure Storage Account】系列。
接上文 【Azure 架构师学习笔记】-Azure Storage Account(4)- ADF 读取Queue Storage
前言
不管在云还是非云环境中, 存储是IT 系统的其中一个核心组件。在Azure 上,云存储主要以存储帐户(Storage Account)来实现。在使用Storage Account时,又有很多需要考虑的事项,比如安全,高可用,文件结构等。
本系列分3篇文章,以最常用的Azure Data Lake Store Gen2 (ADLS Gen2)作为例子演示一些架构方面的配置和考虑, 包括:Storage Account的物理结构、文件系统设计、安全配置。
Data Lake Layers
Storage Account是一个物理资源,但是根据现实的软件环境,又需要分为类似DEV, SIT, UAT, PROD等环境,通常每个环境会独立使用一个资源以实现环境隔离。所以首先分层的是环境。
存储帐户
在每个环境中,会有一个或多个Storage Account,在配置的时候,可以有很多选项,要按照实际情况选择,很多选项明确指明在创建后不可修改。另外也并不是所有选项都支持当前选择的所在区域。
在Storage Account下面,会有4个Feature: Container, File Shares, Queues, Tables。 最常用的就是Container, 它可以理解为一个文件系统,以分层形式存储文件。
文件系统
如果没有文件系统,文件只是像一盘沙子那样铺在存储帐户上,为了更好地组织和管理文件, 需要借助文件系统,类似Windows上的文件夹结构。除了文件本身的层级结构之外,还有一些其他需要关注的属性:
Public Access Level:
在新建container的时候会注意到有这些选项,除了名字之外,匿名访问"Anonymous access level"是显示private并且为灰色意味着当前不可修改, 需要从storage account中开启。
如果要启用,可以从overview页点下图部分进去修改:
启用后即可看到新建时的可选项。
创建之后进入container的属性页
然后点击"Access Policy"可以看到有两个access policy:
- Stored access policies:可以通过配置来控制Shred Access Signatures (SAS) 的起止时间。
- Immutable blob storage:提供单次写多次读的机制,当数据写到存储帐户后数据变成不可修改,可以通过策略来控制。
点开"Stored access policies":控制的是SAS token的有效期和允许的操作, 这是container 级别的控制,在存储帐户级别也有类似的配置,如果同时存在,则以container的优先。
点开"Immutable blob storage": 有两类选项,默认的"Legal hold"可以应用在数据层面用于保护数据不被修改和删除。
小结
本文初步介绍了存储帐户的概述,但是实际上光这个服务就足够用上百篇文章来解释,所以把内容拆散以免阅读疲劳。
接下来的一文将介绍Container(文件系统)内部的结构。