图像存储的服务器设置

如果这是绿地开发，那么我绝对会使用这个云 。 100M文件是很多数据; 将这种冗余存储卸载到fx Amazon S3将是一项重大改进。

考虑到我们正在谈论的100M的文件，我相信我们可以放心地说，数据集的一些部分将是“热”（经常要求），大部分是冷的。 所以我们真的想要caching。

概述如何在Amazon Web Services上完成这项工作：

• 第一层：由 Amazonpipe理的Elastic Load Balancing和Amazon CloudWatch监控到nginx或Apache的两个小型EC2实例。 这些服务器只是具有静态configuration文件的负载均衡器，因此Cloudwatch可以监视它们，并在其中一个崩溃时自动产生新的实例。
• 从第一层： 基于请求URL（文件名）到caching服务器层的一致hasting 。 你需要根据文件名进行散列，以确保每个文件不会被caching多次（降低caching命中率），而是每个服务器处理N个地址空间的N个caching服务器。
• 第二层：caching服务器。 您的caching服务器是具有更多内存的EC2实例，并安装了Squid或Varnish或Apache Traffic Servercaching。
• 从第二层：简单的旧HTTP到Amazon S3文件存储。

由于这个设置是松耦合的， 水平伸缩是很容易的 （当缩放问题发生时）。

它的速度有多快主要取决于冷热数据之间的比例。 如果您的工作负载大部分是热的，那么从2个小负载平衡器EC2和2个高cachingEC2实例中，我们就不会惊讶地发现远高于10.000 req / s。

固态硬盘的操作系统本身是过度杀伤，除非你真的真的有兴趣启动30秒更快。 只需要一对小的SAS驱动器，它应该是绰绰有余。

WRT。 caching，caching的实用性取决于工作集。 也就是说要求图像能够均匀地分布在所有的图像上，或者你期望大多数的请求将会是一个小的子集？ 在后一种情况下，caching可能是有用的，前者不是那么多。 请注意，磁盘控制器上的高速caching主要用于高速caching写入（如果高速caching是非易失性的），这对fsync（）密集型应用程序（如数据库）很有帮助。 对于形象服务，我怀疑这个好处不会那么大。

集群和分布式FS的问题在于它们设置起来比较复杂，尤其是分布式FS比“正常”的单节点FS更不成熟。 群集FS通常意味着共享存储，这意味着如果您希望避免单点故障，则使用相对昂贵的SAN。

另一种方法是build立一个运行某种类似Amazon S3的集群，提供一个HTTP可访问的分布式和复制键值存储。 如OpenStack存储 。

很大程度上取决于这些项目的使用频率。 如果你可以期望它们中的一小部分是一次非常活跃的话，那么你可能需要考虑Varnish做你的前端处理，从你的nginx / lighttpd后端负载平衡。 由于经常使用的图像将被caching，磁盘速度不那么重要。

但是，如果图像不被重复请求，并且caching不会提供巨大的提升，那么服务器或两个服务器上的nginx / lighttpd就可以做到这一点。 您还需要考虑将要提供的带宽量。 您的数据集的一小部分800mb / sec将很容易被操作系统caching。 一个巨大的数据集的800mb /秒可能会遇到一个IO瓶颈，因为你无法从磁盘上获得足够快的数据，在这种情况下，你需要将你的系统分成足够多的部分来获得IO带宽。

即使你正在运行raid-6，这仍然不能替代备份，因此，预算一台类似的机器来做备份，或者可能充当故障转移存储服务器。

我会select一个自定义集群而不是分布式FS，因为在工作的同时理解和排除故障更简单。 也就是说，您自己的集群的可靠性权衡是显而易见的，但是要确定分布式FS如何对死亡服务器或交换机发生故障是一个任务。

解决你的问题的一个可能的解决scheme是将整个照片归档分成部分（比如2个部分），并在URL中显示部分id（例如，使其成为一个子域或GET参数，expression式）。 然后，你将有4个存储服务器与照片（每个部分2服务器）。 使用第五台服务器作为分配和平衡负载的逆向代理。 所有五台服务器都可以运行lighttpd。 也就是说，我提出一个非常愚蠢的问题，但是工作（对于我工作的公司来说 – 每秒总共有大约5000个请求，大小为3-10 KB的文件，总共8 TB的唯一文件，来自24个后端的服务器，但是，运行一个自定义的HTTP守护进程而不是lighttpd）解决scheme。

至于磁盘和内存：我们在每台服务器上使用由四个快速而廉价的SATA磁盘组成的软件RAID-0（如果磁盘出现故障，所有数据都可以从另一台服务器上的副本进行复制），另外还有一个自定义解决scheme在单个读取错误后使整个服务器脱机。 即使一个磁盘出现故障，RAID-5和RAID-6的速度也是非常糟糕，请不要使用它们。 在内容服务器上，大量的RAM是必不可less的（如磁盘caching），寻找24 GB或更多。 即使如此，准备好30分钟的热身时间。 在反向代理上，如果你使用lighttpd，请考虑到它尽可能快地将整个上游响应caching到RAM中，并且可能花费大量时间将caching的照片推送给拨号或GPRS上的某个人（并且在那段时间，需要RAM中的缓冲区）。 我们也拿了24GB只是为了有相同的configuration，但我不知道这是否过于矫枉过正。 反向代理上基于内存的HTTPcaching并不是必需的（即使存在热图像！），因为后端操作系统提供的磁盘caching也能正常工作。

为了确保所有服务于归档相同部分的后端都具有相同的数据：这很容易。 发布照片时，只需将其复制到所有服务器。 然后在档案的旧部分使用rsync来纠正任何差异，从而使一个副本成为主。