如何在规模集 VM 之间有效共享数据答案

【问题标题】：How to effectively share data between scale set VMs如何在规模集 VM 之间有效共享数据
【发布时间】：2019-01-13 11:43:03
【问题描述】：

我们有一个可扩展的应用程序。基本上，您有一个或多个无状态节点，它们都对读取和写入共享 NFS 共享的文件进行一些独立的工作。这个 NFS 可能是瓶颈，但对于本地部署，客户只需购买足够大的盒子即可获得足够的性能。现在我们正在将它转移到 Azure，我希望有一种更好、更“多云”的数据共享方式 :) 如果我们需要管理它们，运行一些 Linux NFS 服务器并不是理想的场景。 Azure Blob 存储是否适合这项工作 (https://azure.microsoft.com/en-us/services/storage/blobs/)？

我们需要良好的可扩展性。例如一分钟最多可写入 10k 个文件
文件非常小，平均每个文件不到 50KB
文件创建和读取，未更改
文件是短暂的，我们每天都会清除它们

我正在寻找更多关于这种存储的实践经验以及它到底有多好。

【问题讨论】：

标签： azure azure-blob-storage scalability

【解决方案1】：

您的请求有两种可能的解决方案，使用 Azure 存储 Blob（推荐用于您的方案）或 Azure 文件。

Azure Blob 具有以下缩放目标：

它不支持将其附加到服务器的事实，例如网络共享。
Blob 不支持层次文件结构，除了具有容器（可以访问虚拟文件夹，但缺点是如果容器包含 Blob，则不能删除容器 - 关于清除 - 但有一些方法可以进行清除使用您自己的代码。）

Azure 文件：

推荐链接： Azure 文件和 Blob 的比较：https://docs.microsoft.com/en-us/azure/storage/common/storage-decide-blobs-files-disks

信息性 SO 帖子 here

【讨论】：

我已经在研究 Azure Files，它只是一个 smb3 文件共享，由 MS 管理。它提供了简单性，即使在 Linux 上也能正常工作。只是当你有多个节点时，它们可能会压倒它，而我看不到，无法扩展它。
根据 Azure Scale 目标的文档，它的每个共享的最大 IOPS 为 1000 IOPS，对于任何有效大小的文件，每秒请求 20,000 个。所以它可以是可扩展的，除非你必须有更大的要求。更多关于可扩展性的信息可以在这里找到：docs.microsoft.com/en-us/azure/storage/files/…
我知道，我已阅读文档并尝试过 Azure Files，但它们没有达到预期。从理论上讲，我可以拥有数十或数百个共享来分散负载，但这不再是单个命名空间。
所以我正在寻找是否有人对 blob 存储有实际经验。由于带宽和请求数量是每个 blob 的，那么每个文件都是一个单独的 blob，您可以推送非常大的数字，对吗？跨度>
@Primoz Blob 将是您的最佳选择，因为它非常可扩展，并且在性能方面非常持久。我只添加/提及 Azure 文件，主要是在您添加以使用 NFS 类似系统时。斑点将是要走的路。