为每个应用创建Azure存储帐户或每个区域创建一个存储是否更好?

时间:2017-02-02 06:32:50

标签: azure azure-storage azure-storage-blobs

所以我在这里考虑了两种情况:

  1. 为每个地区(例如西欧)创建一个大型存储帐户,并为每个应用创建一个容器。存储帐户将转到每个区域的资源组。
  2. 在包含其他应用资源的资源组中为每个应用创建一个存储帐户。
  3. 1的抽奖:

    • 容器与其他应用资源分开,因为它们位于每个区域的存储帐户

    • 容器设计为扁平结构(您可以创建文件夹,但不是很明显)

    Drawbacs for 2:

    • 很多存储帐户

    看看这个,我会说每个应用程序创建存储帐户是一个更好的选择,但也许我在这里缺少一些东西。

    所以问题是:这里还有其他事情要考虑让一个选项比另一个更好吗?也许费用?

    我偶然发现了一个类似的question,但它是关于有一个大容器或许多小容器。 所以问题在某种程度上是完全不同的,因为存储帐户作为一个整体是区域约束的,并且没有访问策略。虽然帐户中的所有容器都位于同一区域,但可以具有不同的访问策略。

2 个答案:

答案 0 :(得分:7)

这个问题没有正确答案。但客观地说,你会考虑几件事:

  • 如果您按容器分隔租户/应用,您将无法再按容器分隔应用的资产 - 您将限制自己使用应用内所有资产的单个容器。
  • 如果您为所有租户/应用程序使用一个存储帐户,则可能会达到存储帐户的20K /秒事务限制(并且可能达到500TB总限制)
  • 如果您使用一个存储帐户,而您的应用使用存储帐户密钥,则每个应用实际上都可以完全访问存储帐户中的所有资源。 (您可以使用共享访问签名缓解此问题,但您还需要考虑队列/表的使用情况。)
  • 如果您的租户/应用程序位于不同的区域,则租户对远程存储帐户的访问权限可能比距离较近的地区要慢。
  • 如果您尝试限制对特定应用的访问权限,并且只有一个存储帐户,则最终可能需要授予用户访问存储帐户所在资源组的权限。这些人可能来自构建不同应用程序的团队。因此,您可能会将一个应用程序的资源暴露给另一个团队。
  • 如果多个团队共享同一个存储帐户,则存在一个团队可能无意中从其他团队的应用程序中删除资产的风险。

我可能会忘记其他事情。

答案 1 :(得分:0)

我按DR / BC类型划分存储帐户。即我是否需要LSR,ZSR,GSR,RO-GSR。例如,我的某些服务器需要ZSR(例如DC),而其他服务器(例如应用程序Web服务器或SQL OS)则需要GSR。然后,这基本上可以模仿我们多年来在内部VMware数据存储中所做的工作,其中一些数据存储是使用SAN复制复制到DR站点的,而另一些则没有。

相关问题