【问题标题】:Most effective way to manage multiple tenant storage in Azure?在 Azure 中管理多租户存储的最有效方法是什么?
【发布时间】:2015-05-25 07:01:39
【问题描述】:

我们正在创建一个多租户应用程序,该应用程序必须在租户之间隔离数据。每个租户将保存各种文档,每个文档都可以分为几个不同的文档类别。我们计划为这些文档使用 Azure Blob 存储。但是,鉴于我们的用户群以及文档的数量和每个文档的大小,我们不确定如何使用当前的 Azure 订阅来最好地管理存储帐户。

这里有一些需要考虑的数字。有 5,000 个用户,每个用户每年 27,000 个 8Mb 文档,即每年总计 1080TB。每个存储帐户的存储容器最大容量为 500TB。

所以我的问题是存储这些数据并保持在 Azure 限制范围内的最有效和最具成本效益的方法是什么?

我们考虑了以下几点:

  1. 为每个客户端创建一个存储帐户。这不起作用,因为每个订阅只能有 100 个存储帐户(这将是最理想的解决方案)。

  2. 为每个客户端创建一个 Blob 容器。一个存储帐户最多可以有 500 TB,因此这可能会起作用,除非最终我们必须拆分为其他存储帐户。如果最终用户在两个帐户中拥有数据,我不确定这将如何工作。可能会弄得一团糟。

也许我们在这里遗漏了一些基本简单的东西。

更新 目前,我们的想法是使用 Azure 表存储,并为每种文档类型提供一个表。在每个表中,分区键是租户的 ID,行键是文档 ID。每行还包含文档的元数据类型信息,以及链接到 blob 本身的 URI(或其他内容)。

【问题讨论】:

  • 您会将客户端/文件关系存储在某种表中吗?例如,将存储所有客户端的所有文件列表的主表?
  • @Gaurav Mantri:好问题!我已提供更新以解决您的问题。

标签: azure azure-storage multi-tenant


【解决方案1】:

不是一个真正的答案,而是将其视为“深思熟虑”:)。基本上,您的架构应该基于每个存储帐户都有一些scalability targets 的事实,并且您的设计应该是这样的,即您不会超过那些为您的应用程序维持高可用性存储的情况。

一些建议:

  • 首先创建多个存储帐户(例如 10 个)。我们就叫他们Pods吧。
  • 每个租户将获得一个 pod。您可以随机选择一个 pod 存储帐户或使用一些预定义的逻辑。有关 pod 的信息与侧租户信息一起存储。
  • 从描述看来,目前您只将文件信息存储在一个表中。这会给一个表/存储帐户带来很大压力,恕我直言,这不是可扩展的设计。相反,当创建租户时,您将 pod 分配给租户,然后为每个租户创建一个表,该表将文件信息存储在该表中。这将有以下好处:1)您已经很好地隔离了每个租户数据,2)读取请求现在是负载平衡的,因此允许您保持在可伸缩性目标内,以及 3)由于每个租户数据位于单独的表中,您的 @987654326 @ 变为免费的,如果需要,您可以分配其他值。

现在开始存储文件:

  • 同样,您可以使用 Pod 概念,其中每个租户的文件驻留在该租户的 pod 存储帐户中。
  • 如果您发现此方法存在问题,您可以随机选择 pod 存储帐户并将文件放在那里,并将 blob URL 存储在 Files 表中。
  • 您可以只使用一个 blob 容器(例如 tenant-files),也可以为每个租户使用单独的 blob 容器。
  • 所有租户只需一个 blob 容器,管理开销较小,因为您只需在委托新的 pod 时创建此容器。然而,缺点是您无法按租户在逻辑上分离文件,因此如果您想提供对文件的直接访问(使用共享访问签名),这将是有问题的。
  • 为每个租户使用单独的 blob 容器,管理开销更大,但您可以获得很好的逻辑隔离。在这种情况下,当租户加入时,您必须在每个 pod 存储帐户中为该租户创建容器。同样,在委托新 pod 时,您必须确保为系统中的每个租户创建一个 blob 容器。

希望这能让您对如何构建解决方案有所了解。我们在我们的解决方案(明确使用 Azure 存储作为数据存储)中使用了其中一些概念。看看你想出什么架构真的很有趣。

【讨论】:

  • 我正在使用相同的方法:租户表允许轻松的“每个租户”迁移。此外,如果某个租户变得非常嘈杂,您可以通过更改 pod 设置将其移至单独的帐户。如果您将订阅存储在 pod 设置中,则可以通过使用多个订阅来打破每个订阅的存储帐户限制。
  • 我喜欢每个租户一张桌子的想法。如果我有两种可以与文档关联的实体类型,我怎么能做到这一点?现在,租户可以拥有与“会话”或“位置”相关联的文档。我可以有 sessionId = 1 和 locationId = 1,这意味着我不能将分区键设置为“1”,因为它可以引用会话或位置。我是否只需将实体名称添加到实体 ID 并将其用作分区键?例如:租户 A 有自己的表,分区键 'session1' 指的是会话 ID 1,而 'location1' 指的是位置 ID 1?
  • 在不详细了解您的应用需求的情况下,我想我很难评论这方面的内容。但是您需要记住的一件事是您将如何查询此表。基于此,您最终可能会为每个租户创建 2 个单独的表。您可能会发现以下链接很有帮助:stackoverflow.com/questions/15809078/…azure.microsoft.com/en-us/documentation/articles/…。 HTH。
  • 我试图理解您回答中提到我可以为每个租户使用单独的 blob 容器的最后一点。您说当新租户加入时,我需要为每个 POD 存储帐户为该租户创建一个容器(这是有道理的)。最后一部分让我感到困惑。为什么我需要在我的每个“pod”(存储帐户)中为此租户创建一个 blob 容器?对于新客户,我不只需要选择一个 pod,然后在该单个 pod 中创建必要的表和 blob 容器吗??
  • 对不起,我不清楚。因此,使用 pod 方法和存储文件,您可以采用 2 种方式:1)为每个租户拥有一个专用的 pod 来存储文件。在这种情况下,您将在租户的 pod 存储帐户中创建一个 blob 容器(委托租户时),并且租户的所有文件都将存储在那里。 2) 另一种方法是在保存文件时选择一个随机的 pod 存储帐户并将 blob URL 存储在租户表中。在这种情况下,租户的一个文件可以放在一个 pod 中,而另一个文件可以放在另一个 pod 中。我的评论是针对第二种情况。 HTH。
【解决方案2】:

我只是将我的想法放在这个话题上,它确实对 Gaurav Mantri 的回答有一些多余的信息。这是基于我在当前工作中做了非常相似的事情后提出的设计。

Azure Blob 存储

  1. 在创建租户时,从pod pool 中随机选择一个pod,并将其命名空间与租户信息一起存储。

  2. 提供一个用于创建容器的 api,其中容器名称由租户 ID Guid::ToString("N") + <resourcename> 组成。您不需要将它们作为容器出售给您的用户,我可以是文件夹、工作集或文件箱,您可以找到一个名称。

  3. 提供用于在这些容器中维护文档的 api。

这意味着如果有更多租户,您可以增加pod pool,或者删除那些被填满的pods

这样做的好处是您无需为数据保留两个系统,同时使用表存储和 Blob 存储。 Blob 存储已经有办法将数据呈现为目录/文件层次结构。

扩展点

Blob 存储 API 代理

在上述设计之上,我制作了一个包裹在客户端和 blob 存储之间的 Owin 中间件,基本上只是将来自客户端的请求转发到 blob 存储。 由于不需要此步骤,因此您可以委托普通 sas 令牌并直接与客户端的 blob 存储对话。但它可以很容易地挂钩何时对文件执行操作。每个租户都会有自己的端点files/teantid/<resourcename>/

使用这样的 API 还可以让您连接到您可能已经使用的任何令牌身份验证系统,以验证身份验证和授权传入请求,然后在此 API 中对请求进行签名。

Blob 存储元数据

使用上述 api 代理扩展,结合元数据,实际上可以更进一步,修改传入请求以始终包含元数据,并在返回到 blob 存储的 xml 上添加过滤器,然后再将其发送给客户端以过滤掉容器或斑点。一个例子是当用户删除一个 blob,然后设置一个 x-ms-meta-status:deleted 并在返回 blob/容器时将它们过滤掉。这样您就可以在后台添加不同的删除数据的过程。

这里应该小心,因为你不想在这里添加太多逻辑,因为它会增加对所有请求的惩罚,但是聪明地做它可以使这项工作变得非常好。

此扩展还允许您允许您的用户在容器内创建“空”子文件夹,但放置一个带有 status:hidden 的零字节文件也将被过滤掉。 (请记住,blob 存储只有在虚拟文件夹中有内容时才能显示虚拟文件夹)。这也可以使用表存储来实现。

Azure 搜索

另一个很棒的扩展点是,对于每个 blob,您可以将其保存在 Azure 搜索中以便能够找到内容,这很可能是我最喜欢的。我没有看到任何仅使用 blob 存储或表存储的好的解决方案,它们可以为您提供良好的搜索功能,或者在某种程度上甚至可以提供良好的过滤体验。借助 Azure 搜索,这将为用户再次查找内容提供非常丰富的体验。

快照

另一个扩展是可以在每次自动修改文件时创建快照。使用代理 api 变得更加容易,否则监控日志是一种选择。

这些想法来自我开始的一个我想分享的项目,但由于接下来的几个月我很忙,我不认为自己会在暑假之前发布我的项目给我时间完成。该项目的动机是提供一个 nuget 包,使其他开发人员能够快速设置我上面提到的这个代理 api 并配置多租户 blob 存储解决方案。

如果您阅读本文并相信这样的项目可以在您当前的开发过程中为您节省时间,我恳请您投票赞成这个答案。这样我可以看看我是否可以在项目上花费更多时间。

我认为 gaurav Mantris 的回答更适合上述问题,但只是想分享我对该主题的想法。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-09-15
    • 1970-01-01
    • 1970-01-01
    • 2018-03-06
    • 2011-05-24
    • 1970-01-01
    相关资源
    最近更新 更多