我正在一台专用机器上运行一个简单的铁轨堆栈。 我们达到了我们的全部容量，并且完全没有缩放的设置，只有一台机器上只有一个应用程序。 我做了一些研究，并提出了一个可扩展性的潜在堆栈。 我不是专业pipe理员，但是我已经就如何处理EC2做了一些想法。 我仍然对文件系统共享有些不确定，这是我的主要问题。 首先，这是我正在处理的。
当前堆栈：
我们的应用程序的function
我们的应用程序使用ImageMagick进行大量的图像上传和繁重的image processing。 它还与jaxer讨论冗长的canvas-to-image转换。 所有这一切都在延迟工作。 我们希望确保这个东西可以特别扩展。 所以我们正在谈论快速增长的文件存储需求和后台作业中的繁重image processing。
我迄今的决定：
问题：
主要的实际问题是：所有的文件会发生什么？ 如果我决定将应用程序angular色分成多个实例，那么如何获得共享的文件系统访问权？
另外，听到关于我的设置的一些想法总是很棒的。
所以，你所得到的大部分是非常简单的。 把PgSQL放到它自己的机器上，作为第一步缓解一堆CPU /磁盘IO /内存消耗。 狮身人面像也进入它自己的小世界。 绝对切换到resque允许轻松的水平缩放你的工人。
但文件…是的，文件是困难的。 他们总是很难。 而你的select是非常薄。
有些人会推荐群集文件系统的路由，不是神奇的超群集（GFS2 / OCFS2），就是像GlusterFS这样稍差的选项。 我已经运行了很多使用GFS的系统（1000+），而我永远不会再这样做。 （实际上它甚至可能不在EC2的networking上运行）。 GFS2 / OCFS2是一个混乱的移动部件，logging不完整，过于复杂，容易引起混乱的故障模式，只会给您带来宕机的麻烦。 它也不值得，尤其是在一个写入繁重的环境中 – 它只是倒下，把整个集群放下来，花上10-30分钟的上师级工作来重新启动它。 避免它，你的生活变得更容易。 我从来没有运行GlusterFS，但那是因为我从来没有特别印象深刻。 任何你可以用它做的事情，通常有更好的方法来做到这一点。
在我看来，更好的select是历史悠久的NFS服务器。 一台机器有一个大的（或不是很大的）EBS卷和一个NFS守护进程，每个人都在装载它。 它有它的问题（这不是一个真正的POSIX文件系统，所以不要这样对待），但是对于99％的用例来说，简单的“我已经修复了”操作，这并不坏。 至less，这可以是一个权宜之计，而你在一个更好的解决scheme，这是…
使用您的应用程序知识分层存储。 这是我最近采取的方法（缩放Github），它的工作很好。 基本上，不要将文件存储视为文件系统，而是将其视为一种服务 – 为应用程序的文件存储使用部分提供一个智能API，以用于执行您需要执行的操作。 在你的情况下，你可能只需要能够存储和检索图像预先分配的ID（例如，在数据库中的“图像”表的PK）。 这并不需要整个POSIX文件系统，它只需要一些超级优化的HTTP方法（POST需要dynamic处理，但是如果你真的很聪明，你可以让GET直接从磁盘作为静态文件） 。 地狱，你可能直接把这些图像送回给客户，所以切断中间人，让你的服务器在公共访问资产服务器。
工作stream可能会是这样的：
你不必使用HTTP POST来把图像放到服务器上，例如，Github就可以使用Git-over-SSH与文件服务器进行通信，这对于他们来说工作正常。 但是，关键是要把更多的思想放在需要完成工作的地方，并避免不必要地使用稀缺的资源（NFS服务器请求的networkingIO），而是使用更为有限的一组使用选项（“请求整个文件primefaces！“）适用于您的应用程序。
最后，你将不得不考虑可伸缩性因素。 如果你使用的是智能传输，那么很容易 – 添加（less量）逻辑来确定每个与文件服务器对话的文件服务器需要与哪个文件服务器进行通信，而且基本上具有无限的可伸缩性。 在你的情况下，你可能会意识到，你的第一个文件服务器将会充满，例如75万张图像。 所以你的规则是“与主机fs#{image_id / 750_000}的文件服务器进行通话”，这并不难编码。
我总是习惯于这部分工作的乐趣…