云驱动器与云文件（或者我们不应该打扰吗？）
该 Web 应用程序正在从独立服务器迁移到负载平衡器后面的一对服务器，并且包含一个 50GB 的用户创建数据目录，该目录正在快速增长。在机架空间上，动态添加磁盘空间的唯一方法是将 RAM 和每月成本加倍，但这是没有必要的。所以，对于云文件来说就是这样（除非有人想到了其他解决方案？）。使用 JungleDisk，我可以将文件移动到云文件容器，并且可以在两台服务器上安装云容器，并创建从内容所在目录到已安装驱动器的符号链接。这不需要修改代码。或者，我可以使用 PHP API 直接与云文件交互，但这需要大量代码更改（所有路径？真的吗？）。在这种情况下，采取简单的方法是否存在任何固有的问题？我建立了一个模型，看起来效果很好，但我通常似乎遗漏了一些东西。
谢谢， 布兰登
The web application is in the process of moving from a standalone server to a pair of servers behind a load-balancer, and contains a 50GB directory of user-created data that is growing rapidly. On rackspace, the only way to add disk space dynamically is by also doubling RAM and monthly cost, which isn't necessary. So, to cloud files it is (unless anyone has another solution in mind?). Using JungleDisk, I can move the files to a cloud files container, and can mount the cloud container on both the servers, and create a symbolic link from the directories where the content was to the mounted drive. This would require no code modification. Alternatively, I could interface directly with cloud files using their PHP API, but this would require massive code changes (all the paths? really?). Is there any inherent problem with taking the easy way out in this case? I set up a model and it seems to work well, but I usually seem to be missing something.
Thanks,
Brandon
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为安装驱动器对于您的情况很有意义，但说实话我还没有在任何负载下尝试过它。好消息是，您始终可以尝试简单的方法，然后如果它无法在负载下执行，则进行重构。我希望 Rackspace 能够考虑并测试这个确切的场景，这对我来说似乎是合乎逻辑的。
对于一些无关的信息，我们在这里遇到了同样的问题，并对使用云站点与云文件进行了成本比较。我们必须将带宽和存储量都考虑到成本中，因为站点/服务器和云文件之间的通信仍然会产生带宽费用。换句话说，您是否有大量文件存在，或者是否有一些经常访问的文件。
我们花了很多时间与 RackSpace 支持人员讨论云站点和云文件之间的性能和可扩展性差异 - 我建议给他们打电话。由于我们的需求，我们最终选择只使用站点，随着规模的扩大，成本差异非常微不足道。另外，由于云文件 API 不具备我们所需的精细安全性，因此我们无论如何都必须编写网关服务。
I think mounting the drive makes a lot of sense for your scenario, but to be honest I haven't tried it with any load. The good news is that you could always try the easy approach and then refactor if it doesn't perform under load. I'd hope Rackspace accounted and tested for this exact scenario, it seems logical to me.
For some extraneous information, we faced the same question here and did a cost comparison of using Cloud Site vs Cloud Files. We had to factor in both bandwidth and amount of storage into the costs because communication between Sites/Servers and Cloud Files still incurs bandwidth charges. In other words, do you have a lot of files that sit around, or do you have a few files that get accessed often.
We spend a lot of time talking with RackSpace support about performance and scalability differences between Cloud Sites and Cloud Files - I'd recommend giving them a call. We ultimately chose to just use Sites because of our needs, the cost difference was pretty insignificant as it scaled. Also because the Cloud Files API didn't have the granular security that we needed, so we would have to have written a gateway service anyway.