当前位置:   article > 正文

ZA303学习笔记一云存储_shared access policies

shared access policies

Azure 托管磁盘简介

  • 高度持久和可用
  • 简单且可缩放的 VM 部署
  • 集成可用性集:可确保可用性集中的 VM 的磁盘彼此之间完全隔离以避免单点故障
  • Azure 备份支持
  • 可以使用 Azure 基于角色的访问控制 (Azure RBAC) 将托管磁盘的特定权限分配给一个或多个用户。

最终目标:根据客户需求选择合适的存储方案

Azure存储平台包括以下数据服务

在这里插入图片描述

存储账户类型

官网

https://docs.microsoft.com/zh-cn/azure/storage/common/storage-account-overview
  • 1
存储帐户的类型支持的存储服务冗余选项使用情况
标准常规用途 v2(Standard general-purpose v2)Blob 存储(包括 Data Lake Storage1)、队列存储、表存储和 Azure 文件存储LRS,GRS,RA-GRSBlob、文件共享、队列和表的标准存储帐户类型。 建议在大多数情况下使用 Azure 存储。 适合存储巨量的非结构化数据。。如果想要在 Azure 文件存储中支持网络文件系统 (NFS),请使用高级文件共享帐户类型。
高级块 blob (Premium block blobs)Blob 存储(包括 Data Lake Storage1)LRS,ZRS块 Blob 和追加 Blob 的高级存储帐户类型。 建议用于事务率较高的方案,或者用于使用较小对象或需要存储延迟始终较低的方案。支持大型图像、视频和音频流
高级文件共享Azure 文件存储LRS,ZRS仅适用于文件共享的高级存储帐户类型。 建议用于企业级应用程序或高性能级应用程序。 如果想要同时支持服务器消息块 (SMB) 和 NFS 文件共享的存储帐户,请使用此帐户类型。
高级页 Blob仅页 BlobLRS仅适用于页 blob 的高级存储帐户类型。最适合随机读取和随机写入

Azure Blob:

适用于文本和二进制数据的可大规模缩放的对象存储。最适合存储巨量的非结构化数据。非结构化数据是不遵从特定数据模型或定义的数据(如文本或二进制)。
面向对象存储:把文件当成一个单元进行存储),如果进行修改是创建一个新的对象替代旧的对象 (不能多人共享)
支持非托管
块blob 单个文件最大支持4T
页blob 单个文件最大支持8T

Blob最大容量: 5PB
https://azure.microsoft.com/en-us/blog/announcing-larger-higher-scale-storage-accounts/
在这里插入图片描述

https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#storage-limits

  • Blob 存储提供了三种类型的资源:
    1:存储帐户
    2:存储帐户中的容器
    3:容器中的 Blob
    在这里插入图片描述

适用场景

使用最多的是大规模数据存储和备份以及日志

  • 直接向浏览器提供图像或文档
  • 存储文件以供分布式访问
  • 对视频和音频进行流式处理
  • 向日志文件进行写入
  • 存储用于备份和还原,灾难恢复及存档的数据
  • 存储数据以供本地或Azure托管服务执行分析

用户或客户端应用程序通过http/https可以从世界任何地方访问blob存储中的对象,blob存储中的对象可以通过Azure存储REST API,Azure PowerShell,Azure CLI或Azure存储客户端库访问

Blob存储现在支持网络文件系统(NFS)3.0协议。这种支持以对象存储规模和价格提供Linux文件系统兼容性,并使Linux客户端能够从Azure虚拟机(VM)或本地计算机在Blob存储中装载容器。

Azure Databricks访问存储blob

使用Azure Active Directory(Azure AD)身份验证为单个Blob设置权限。

  • 只要打开分层命名空间 (HNS) 功能,就会为存储帐户启用通过 ACL 的访问控制。
  • 企业现在可以使用 Azure 的基于角色的访问控制 (RBAC) 从其 Azure AD 租户向用户和服务标识授予特定的数据访问权限。

Azure文件:

  • 使用于云或本地部署的托管文件共享(类似自己搭建的ftp和samba做文件共享的)适用于多人协作.
  • 云中完全托管的文件共享,可通过标准服务器消息块 (SMB) 协议进行访问。在使用 Windows API 或 REST API 的应用程序之间实现文件共享
  • Azure 文件支持两个存储层:高级和标准。 标准文件共享在通用(GPv1 或 GPv2)存储帐户中创建,高级文件共享在 FileStorage 存储帐户中创建。
  • 不能从 Blob 存储帐户或高级通用(GPv1 或 GPv2)存储帐户创建 Azure 文件共享。 标准 Azure 文件共享只能在标准通用帐户中创建,高级 Azure 文件共享只能在 FileStorage 存储帐户中创建。 高级通用(GPv1 和 GPv2)存储帐户仅适用于高级页 Blob。
  • 最大容量: 5 TiB

在这里插入图片描述

在这里插入图片描述

Azure队列:

用于在应用程序组件之间进行可靠的消息传送的消息存储
Azure 队列存储是一项可存储大量消息的服务。 可以使用 HTTP 或 HTTPS 通过经验证的调用从世界任何位置访问消息。 队列消息大小最大可为 64 KB。 一个队列可以包含数百万条消息,直至达到存储帐户的总容量限值。 队列通常用于创建要异步处理的积压工作 (backlog)。

  • 存储帐户:对 Azure 存储的所有访问都要通过存储帐户来完成。 有关存储帐户容量的信息,请参阅标准存储帐户的可伸缩性和性能目标。
  • 队列:一个队列包含一组消息。 队列名称必须全部小写。
  • 消息: 一条消息(无论哪种格式)的最大大小为 64 KB。 在 2017-07-29 以前的版本中,允许的最大生存时间为 7 天。 在 2017-07-29 或更高版本中,最大生存时间可以是任何正数,或者是 -1(表示消息不会过期)。 如果省略此参数,则默认的生存时间为 7 天。
  • URL 格式:可使用以下 URL 格式对队列进行寻址:
https://<storage account>.queue.core.windows.net/<queue>
https://myaccount.queue.core.windows.net/images-to-download    #下面示意图的URL
  • 1
  • 2

在这里插入图片描述

队列里的消息读取后会被立即删除,如果未被读取则一直存在

Azure表:

https://learn.microsoft.com/en-us/rest/api/storageservices/table-service-rest-api

  • Azure 表存储以表的形式提供结构化存储。表存储 API 是用于处理表及其包含的数据的 REST API。
  • 用于在云中存储结构化NoSQL数据的服务。通过无架构设计提供键/属性存储。因为表存储无架构,因此可以很容易的随着应用程序需求的发展使数据适应存储,对于许多类型的应用程序来说,访问表存储数据速度快且经济高效,在数据 量相似的情况下,其成本通常比传统SQL还要低

适用场景

例如web应用程序的用户数据,通讯录,社保信息或者服务需要的其他类型的元数据。可以在表中存储任意数量的实体,并且一个存储账户可以包含任意数量的表,直到存储账户的容量极限

在这里插入图片描述
URL格式:
Azure存储账户使用:http://.table.core.windows.net/


Azure Cosmos DB(Azure提供的NoSQL服务)表API账户使用:

http://<storage account>/.table.cosmosdb.azure.com/<table>
  • 1

账户:对Azure存储进行的所有访问都要通过存储账户完成。对Azure cosmosDB进行的所有访问都要通过表API完成
table:表的实体的集合。表不对实体强制实施架构,意味着单个表可以包含具有不同属性集的实体
实体:于数据库行类似,一个实体就是一组属性。Azure存储中的实体大小最大可以为1MB. Azure cosmosDB中的实体大小最大可为2MB
属性:属性是名称/值对、每个实体最多可包含252个用于存储数据的属性

Azure磁盘:

相较于Blob,速度更快,费用更高
Azure VM的块级存储卷(块存储:把文件分解成无数小块0101。。。进行存储)(不能多人共享)
注意考点在IOPS,以及最大磁盘大小

在这里插入图片描述

Blob 数据的热、冷和存档访问层(Archive access tiers)

https://learn.microsoft.com/en-us/azure/storage/blobs/access-tiers-overview

仅允许在块 Blob 上设置访问层。

  • 存储在云中的数据以指数级的速度增长。为了管理不断增长的存储需求的成本,根据访问数据的频率和保留时间来组织数据会很有帮助。Azure 存储提供不同的访问层,以便你可以根据 Blob 数据的使用方式以最经济高效的方式存储 Blob 数据。Azure 存储访问层包括:

    1:热层 - 为存储经常访问或修改的数据而优化的在线层。热层具有最高的存储成本,但访问成本最低。
    2:冷层 - 为存储不常访问或修改的数据而优化的在线层。“冷”层中的数据应至少存储 30 天。与热层相比,冷层具有更低的存储成本和更高的访问成本。
    3:存档层 - 针对存储很少访问且具有灵活延迟要求(按小时数)的数据而优化的脱机层。存档层中的数据应至少存储 180 天。

Azure 存储容量限制是在帐户级别设置的,而不是根据访问层设置的。可以选择在一个层中最大化容量使用率,也可以选择在两个或更多层之间分配容量。
当数据存储在联机访问层(“热”或“冷”)中时,用户可以立即访问它。热层是活动使用中的数据的最佳选择,而冷层非常适合访问频率较低但仍必须可用于读取和写入的数据。热层和冷层支持所有冗余配置。

热层的示例使用方案包括:

  1. 正在积极使用或预计将经常读取和写入的数据。
  2. 暂存用于处理并最终迁移到冷访问层的数据。

冷访问层的使用方案包括:

  1. 短期数据备份和灾难恢复。
  2. 不经常使用但应可立即访问的旧数据集。
  3. 需要以经济高效的方式存储的大型数据集,同时收集其他数据进行处理。

生命周期管理

Azure 存储生命周期管理提供基于规则的策略,可用于将 Blob 数据转换为适当的访问层,或在数据生命周期结束时使数据过期。

可以做到

  • 访问 Blob 时,会立即将其从冷 blob 转换为热 Blob,以优化性能。
  • 如果 Blob、Blob 版本和 Blob 快照在一段时间内未被访问或修改,请将这些对象转换为较冷的存储层,以优化成本。在此方案中,生命周期管理策略可以将对象从热移动到冷,从热移动到存档,或从冷移动到存档。
  • 在 Blob、Blob 版本和 Blob 快照的生命周期结束时删除其。
  • 定义每天在存储帐户级别运行一次的规则。
  • 将规则应用于容器或 Blob 子集,使用名称前缀或 blob 索引标记作为筛选器。

常规用途 v2、高级块 blob 和 Blob 存储帐户中的块 Blob 和追加 Blob 支持生命周期管理策略。生命周期管理不会影响系统容器
如果数据集需要可读,请不要设置策略将 Blob 移动到存档层。除非首先重新冻结存档层中的 Blob,否则无法读取它们,此过程可能既耗时又昂贵。

以下示例规则筛选帐户,

对存在于 内部并以sample-containerblob1 开头的对象运行操作。

  • 分层 Blob 以在上次修改后 30 天内冷却层
  • 将 Blob 分层到上次修改后 90 天内存档层
  • 上次修改后 2,555 天(七年)删除 Blob
  • 创建后 90 天删除以前的 Blob 版本
{
  "rules": [
    {
      "enabled": true,
      "name": "sample-rule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          },
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "sample-container/blob1"
          ]
        }
      }
    }
  ]
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37

支持生命周期账户类型

在这里插入图片描述

配置存储账户的网络访问

配置允许访问URL的IP,类似安全组

部署Shared Access Signatures共享访问签名(SAS)和access policies 访问策略

官网:
https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview

共享访问签名 (SAS) 提供对存储帐户中资源的安全委派访问权限。借助 SAS,您可以精细控制客户端访问数据的方式。

  • 客户端可以访问哪些资源。
  • 他们对这些资源具有哪些权限。
  • SAS 的有效期,到期后不能访问。

共享访问签名是指向一个或多个存储资源的已签名 URI。URI 包括一个令牌,该令牌包含一组特殊的查询参数。令牌指示客户端如何访问资源。其中一个查询参数(签名)是从 SAS 参数构造的,并使用用于创建 SAS 的密钥进行签名。Azure 存储使用此签名来授权对存储资源的访问权限。

何时使用SAS

使用 SAS 向无权访问存储帐户中的资源的任何客户端授予对这些资源的安全访问权限。

SAS 有用的常见方案是用户在存储帐户中读取和写入自己的数据的服务。在存储帐户存储用户数据的方案中,有两种典型的设计模式:

  • 客户端通过执行身份验证的前端代理服务上传和下载数据。此前端代理服务允许验证业务规则。但是,对于大量数据或大容量事务,创建可以扩展以满足需求的服务可能成本高昂或困难。
    在这里插入图片描述

  • 轻量级服务根据需要对客户端进行身份验证,然后生成 SAS。客户端应用程序收到 SAS 后,可以直接访问存储帐户资源。访问权限由 SAS 定义,并在 SAS 允许的时间间隔内定义。SAS 减少了通过前端代理服务路由所有数据的需要。

方案图:SAS 提供程序服务

许多实际服务可能使用这两种方法的混合。
例如,某些数据可能通过前端代理进行处理和验证。使用 SAS 保存和/或直接读取其他数据。
此外,在某些情况下,需要 SAS 才能在复制操作中授权对源对象的访问:

  • 将 Blob 复制到驻留在不同存储帐户中的另一个 Blob 时。也可以选择使用 SAS 来授权对目标 Blob 的访问权限。
  • 将文件复制到驻留在不同存储帐户中的另一个文件时。您也可以选择使用 SAS 来授权对目标文件的访问权限。
  • 将 Blob 复制到文件或将文件复制到 Blob 时。即使源对象和目标对象位于同一存储帐户中,也必须使用 SAS

在这里插入图片描述

Blob|容器配置共享访问签名(是共享访问签名的子集只存在于Blob)

在这里插入图片描述

Azure blob 访问策略access policy

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

管理访问共享密钥

紧急叫停

共享文件被盗用,想要紧急停止URL被访问,更改访问密钥,之前生成的URL链接就失效了

在这里插入图片描述

针对静态数据的 Azure 存储加密

Azure 存储使用服务端加密 (SSE) 在将数据保存到云时自动加密数据。Azure 存储加密可保护你的数据,并帮助你满足组织的安全性和符合性承诺。

加密密钥管理

默认情况下,新存储帐户中的数据使用微软管理的密钥进行加密。你可以继续依赖 Microsoft 管理的密钥来加密数据,也可以使用自己的密钥管理加密。如果选择使用自己的密钥管理加密,则有两种选择。您可以使用任一类型的密钥管理,或同时使用这两种类型:

  • 可以指定客户管理的密钥,用于加密和解密 Blob 存储和 Azure 文件中的数据。客户管理的密钥必须存储在 Azure 密钥保管库或 Azure 密钥保管库托管硬件安全模型 (HSM)(预览版)中
  • 可以在 Blob 存储操作上指定客户提供的密钥。对 Blob 存储发出读取或写入请求的客户端可以在请求中包含加密密钥,以便对 Blob 数据的加密和解密方式进行精细控制。

在这里插入图片描述

部署存储的Azure AD认证

通过角色分配,分配给某个用户或组,完成访问控制

在这里插入图片描述

部署存储冗余复制(用于备份还原)

官网
https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy

在这里插入图片描述

分为本地冗余复制 LRS:

  • 在主要区域的单个物理位置内同步复制数据三次。LRS 是最便宜的复制选项,但不建议用于需要高可用性或持久性的应用程序。
  • LRS 是成本最低的冗余选项,并且提供最低的持久性
    在这里插入图片描述

以下情况,LRS 是一个不错的选择

  • 如果您的应用程序存储的数据在发生数据丢失时可以轻松重建,则可以选择 LRS。
  • 如果由于数据治理要求,您的应用程序仅限于在某个国家或地区内复制数据,则可以选择 LRS。在某些情况下,对数据进行异地复制的配对区域可能位于其他国家或地区。

区域间的冗余复制 ZRS :

  • 在主要区域中的三个 Azure 可用性区域之间同步复制数据。对于需要高可用性的应用程序,Microsoft 建议在主要区域中使用 ZRS,同时复制到次要区域。
  • ZRS only support GPV2 (general purpose V2)
  • 使用 ZRS,即使区域变得不可用,读取和写入操作仍然可以访问数据。无需从连接的客户端重新装载 Azure 文件共享。如果某个区域变得不可用,Azure 将进行网络更新,例如 DNS 重新指向。如果您在更新完成之前访问数据,则这些更新可能会影响您的应用程序。为 ZRS 设计应用程序时,请遵循暂时性故障处理的做法,包括实现具有指数退避的重试策略。
  • 对使用 ZRS 的存储帐户的写入请求是同步发生的。只有在将数据写入三个可用区中的所有副本后,写入操作才会成功返回。

在这里插入图片描述

异地冗余存储 GRS

  • 使用 LRS 在主要区域的单个物理位置内同步复制数据三次。然后,它将数据异步复制到次要区域中的单个物理位置。在次要区域中,使用 LRS 同步复制数据三次。
    在这里插入图片描述

异地区域冗余存储 GZRS

  • 使用 ZRS 在主要区域中的三个 Azure 可用性区域之间同步复制数据。然后,它将数据异步复制到次要区域中的单个物理位置。在次要区域中,使用 LRS 同步复制数据三次。

在这里插入图片描述

GRS vs GZRS

  • GRS 和 GZRS 之间的主要区别在于如何在主要区域中复制数据。在次要区域中,始终使用 LRS 同步复制数据三次。次要区域中的 LRS 可保护数据免受硬件故障的影响。
  • 使用 GRS 或 GZRS 时,次要区域中的数据不可用于读取或写入访问,除非故障转移到次要区域。对于次要区域的读取访问权限,请将存储帐户配置为使用读取访问异地冗余存储 (RA-GRS) 或读取访问地理区域冗余存储 (RA-GZRS)

如果主要区域变得不可用,则可以选择故障转移到次要区域。故障转移完成后,次要区域将成为主要区域,你可以再次读取和写入数据。

部署存储账号的故障转移(自己发现后手动切换)

因为转移需要一个小时加上同步的时间所以会丢失一个小时加同步时间的数据
从异地复制进行切换
主要针对于账户类型为GRS(地域之间)

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

声明:本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:【wpsshop博客】
推荐阅读
相关标签
  

闽ICP备14008679号