在Azure中管理多租户存储的最有效方法？

Question

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

以下是一些需要考虑的数字.拥有5,000名用户,每位用户每年27,000个8Mb文档,即每年1080TB.每个存储帐户的存储容器最大为500TB.

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

以下是我们考虑过的一些事情:

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

2. 为每个客户端创建一个blob容器.存储帐户最多可以有500TB,因此除非最终我们必须拆分为其他存储帐户,否则这可能会有效.如果用户最终在两个帐户中拥有数据,我不确定这是如何工作的.可能会变得凌乱.

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

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

Answer 1

不是一个答案,但把它想象成"思考的食物":).基本上,您的体系结构应该基于每个存储帐户都有一些,scalability targets并且您的设计应该不超过这些以保持应用程序的高可用性存储.

一些建议:

• 首先创建多个存储帐户(比如10开始).我们打电话给他们吧Pods.
• 每个租户都会获得一个吊舱.您可以随机选择一个pod存储帐户或使用一些预定义的逻辑.有关pod的信息存储在旁边租户信息中.
• 从描述中看来,目前您只将文件信息存储在一个表中.这会给一个表/存储帐户带来很大的压力,这不是一个可扩展的设计恕我直言.而是在创建租户时,将一个窗格分配给租户,然后为每个租户创建一个表,该表将文件信息存储在该表中.这将带来以下好处:1)您已经很好地隔离了每个租户数据,2)读取请求现在是负载平衡的,因此允许您保持在可扩展性目标内; 3)由于每个租户数据位于单独的表中,因此您PartitionKey获得了免费如果需要,您可以指定其他值.

现在开始存储文件:

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

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

Answer 2

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

Azure Blob存储

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

2. 提供一个用于创建容器的api，其中容器名称是租户id的组合Guid::ToString("N") + <resourcename>。您无需将其作为容器出售给您的用户，我可以是文件夹，工作集或文件箱，但您可以找到名称。

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

这意味着，pod pool如果增加租户，您可以增加租户数量，然后删除pods被填满的租户。

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

延伸点

Blob存储Api经纪人

在上述设计之上，我制作了一个Owin中间件，该中间件包装在客户端和Blob存储之间，基本上只是将请求从客户端转发到Blob存储。此步骤已关闭，因为不需要，因为您可以委派普通的sas令牌并直接从客户端与blob存储进行对话。但是，当对文件执行操作时，它很容易陷入困境。每个租户都有自己的终点files/teantid/<resourcename>/

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

Blob存储元数据

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

这里您应该小心一点，因为您不想在这里增加太多逻辑，因为它会增加所有请求的代价，但是精打细算可以使这项工作变得非常好。

此扩展名还允许您允许用户在容器内创建“空”子文件夹，但放置一个零字节文件，其状态为：隐藏，该文件也将被过滤掉。（请记住，如果其中包含某些内容，则Blob存储只能显示虚拟文件夹）。这也可以使用表存储来实现。

Azure搜索

另一个很好的扩展点是，对于每个Blob，您都可以将其保留在Azure搜索中，以便能够查找内容，这很可能是我的最爱。我看不到仅使用Blob存储或表存储的任何良好解决方案，它们可以为您提供良好的搜索功能，甚至可以提供良好的过滤体验。借助Azure搜索，这将为用户提供非常丰富的体验，供他们再次查找其内容。

快照

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

这些想法来自我想分享的一个项目，但是由于接下来的几个月我很忙，所以我看不到自己在暑假之前给我时间来完成我的项目。该项目的动机是提供一个nuget软件包，该软件包使其他开发人员能够快速设置我上面提到的Broker API并配置多租户Blob存储解决方案。

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

我认为gaurav Mantris的回答在上述问题上更受关注，但只是想分享我对该主题的看法。