在Azure中管理多个租户存储的最有效方法是? [英] Most effective way to manage multiple tenant storage in Azure?

问题描述

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

We're creating a multi-tenant application that must segregate data between tenants. Each tenant will save various documents, each of which can fall into several different document categories. We plan to use Azure blob storage for these documents. However, given our user base and the number of documents and size of each one, we're not sure how to best manage storage accounts with our current Azure subscription.

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

Here are some numbers to consider. With 5,000 users at 27,000 8Mb documents per year per user, that is 1080TB per year total. A storage container maxes out at 500TB per storage account.

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

So my question is what would be the most efficient and cost effective way to store this data and stay within the Azure limits?

以下是我们考虑过的几件事:

Here are a few things we've considered:

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

1. Create a storage account for each client. THIS DOES NOT WORK because you can only have 100 storage accounts per subscription (this would have been the most ideal solution).

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

Create a blob container for each client. A storage account can have up to 500TB, so this could potentially work except for eventually we would have to split off into other storage accounts. I'm not sure how that would work if eventually a user had data in two accounts. Could get messy.

也许我们在这里缺少根本上简单的东西.

Perhaps we are missing something fundamentally simple here.

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

UPDATE For now our thought is to use Azure table storage with a table for each document type. Within each table the partition key would be the tenant's ID, and the row key would be the document ID. Each row would also contain metadata type information for the document, along with a URI (or something) linking to the blob itself.

推荐答案

不是一个真正的答案，而是将其视为深思熟虑的食物" :).基本上，您的体系结构应基于以下事实:每个存储帐户都有一些 scalability targets 并且您的设计应确保您的应用程序不超过为应用程序保持高可用性的存储空间.

Not really an answer but think of it as "food for thought" :). Basically your architecture should be based on the fact that each storage account has some scalability targets and your design should be such that you don't exceed those to maintain high availability of storage for your application.

一些建议:

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

现在开始存储文件:

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

• Again you can go with the Pod concept wherein files for each tenant reside in the pod storage account for that tenant.
• If you see issues with this approach, you can randomly pick the pod storage account and put the file there and store the blob URL in the Files table.
• You could either go with just one blob container (say tenant-files) or separate blob containers for each tenant.
• With just one blob container for all tenants, management overhead is smaller as you just have to create this container when a new pod is commissioned. However the downside is that you can't logically separate files by tenant so if you want to provide direct access to the files (using Shared Access Signature), it would be problematic.
• With separate blob containers for each tenant, the management overhead is more but you get nice logical isolation. In this as a tenant is brought on board, you would have to create container for that tenant in each pod storage account. Similarly when a new pod is commissioned, you have to ensure that a blob container is created for each tenant in the system.

希望这使您对如何设计解决方案有所了解.我们在解决方案中使用了其中一些概念(显式使用Azure存储作为数据存储).看看您想到的是什么架构，真的很有趣.

Hope this gives you some idea about how you can go about architecting your solution. We're using some of these concepts in our solution (which explicitly uses Azure Storage as data store). It would be really interesting to see what architecture you come up with.

这篇关于在Azure中管理多个租户存储的最有效方法是?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！