Azure 如何在缩放集虚拟机之间有效共享数据

我们有一个相当可扩展的应用程序。基本上，您有一个或多个无状态节点，它们都对读写到共享NFS共享的文件执行一些独立的工作。 这种NFS可能会成为瓶颈，但对于本地部署，客户只需购买足够大的机箱即可获得足够的性能。 现在我们正在将此迁移到Azure，我希望有一种更好的更“云”的数据共享方式：）如果我们需要管理它们，运行一些Linux NFS服务器并不是理想的方案。 Azure Blob存储是否是此作业（）的正确工具

• 我们需要良好的可伸缩性。e、 g.一分钟内可写入多达10k个文件

• 文件非常小，平均每个文件不到50KB

• 已创建和读取的文件，未更改

• 文件的寿命很短，我们每天都会清除它们
  我正在寻找更多的实际经验与这种存储和它到底有多好

---

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

Azure Blob具有以下扩展目标：

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

Azure文件：

推荐链接： Azure文件和Blob之间的比较：

---

信息丰富，所以发布后

我已经在研究Azure文件，它只是一个smb3文件共享，由MS管理。它提供了简单性，即使在Linux上也可以正常工作。只是当你有超过几个节点时，它们可以压倒它，而我看不到任何方法来扩展它。根据Azure scale targets的文档，它的最大IOPS/共享为1000 IOPS，对于任何有效大小的文件，每秒请求20000次。所以它可以扩展，除非你有更大的需求。更多关于可伸缩性的信息可以在这里找到：我知道，我已经阅读了文档，并尝试了Azure文件，但它们没有达到预期。理论上，我可以有几十个或数百个共享空间来分散负载，但这不再是单一的命名空间。因此，我想知道是否有人有blob存储的实际经验。由于带宽和请求数是每个blob的，因此每个文件都是一个单独的blob，因此可以推送非常大的数据，正确吗？@Primoz Blob将是您的最佳选择，因为它具有很强的可扩展性，并且在性能方面非常持久。我只添加了/metnioned Azure文件，主要是在您添加使用NFS类似系统的情况下。水滴是最好的选择。