用于图像存储的服务器设置

Question

我需要存储2500万照片在4个大小=总计100米文件，文件大小将在3Kb到200 kb之间的文件和使用的存储在开始大约14-15 TB。

我们的目标是使2-4服务器上的数据可用，并通过本地快速we服务器(nginx或lighthttpd)服务它们，我们需要尽可能多地使用req/sec。

我的计划是使用来自英特尔的2U Servercase和12x2TB (WD RE4)和Raid 6(或者FS与红度？)对于数据和操作系统2x60GB的SSD，这是一个好方法吗？现在:我找到了Adaptec 5805ZQ谁可以使用SLC驱动器缓存大多数已使用的文件，有什么建议吗？

我需要选择什么读缓存大小？

如果我计划有2-4个这样的服务器，那么什么是最佳的修复和负载平衡的方法？

对于我们的目标，集群和分布式FS之间的利弊是什么？

Answer 1

如果这是绿地开发，那么我绝对会用云来做这个。100 M文件是大量的数据；将该文件的冗余存储卸载到fx Amazon S3将是一个重大的改进。

考虑到我们谈论的是100 M文件，我相信我们可以安全地说，数据集的某些部分将是“热”的(经常被请求)，并且大多数部分将是冷的。因此，我们确实需要缓存。

--关于如何在Amazon上实现此操作的概述：

• 第一层:亚马逊管理的弹性负载平衡和Amazon使用nginx或Apache对两个小的CloudWatch实例进行监视。这些服务器只是带有静态配置文件的哑负载平衡器，所以Cloudwatch可以为我们监视它们，并在其中一个崩溃时自动生成新实例。
• 从第一层：基于基于请求URL的一致(文件名)到一层缓存服务器。您希望基于文件名进行散列，以确保每个文件不会多次缓存(降低缓存命中率)，而是使用N个缓存服务器处理地址空间的1/N。
• 第二层:缓存服务器(S)。您的缓存服务器是具有更多内存的EC2实例，并安装了Squid或Varnish或Apache流量服务器缓存。
• 从第二层:普通的旧HTTP到亚马逊的S3文件存储。

由于这个设置是松散耦合的，所以水平扩展它很容易(因为缩放问题)。

它的速度将在很大程度上取决于冷热数据的比率。如果您的工作负载主要是很热的，那么我就不会惊讶地看到，仅从两个小负载均衡器EC2s和两个高mem缓存EC2实例中可以看到超过10.000 req/s。

Answer 2

对于操作系统本身来说，SSD本身是过火的，除非你真的对更快的30来个启动感兴趣。只要得到一对小的SAS驱动器，它应该是足够的。

Wrt。缓存，缓存的有用性取决于工作集。也就是说，对于图像的请求被期望均匀地分布在所有的图像上，还是您认为大多数请求都是针对一个小子集的？在后一种情况下，缓存可能是有用的，而在前者则不是那么有用。请注意，磁盘控制器上的缓存主要用于缓存写入(如果缓存是非易失性的)，这对于fsync()-intensive应用程序(如数据库)很有帮助。对于形象服务，我想好处不会那么大。

集群和分布式FS的一个问题是它们的设置比较复杂，特别是分布式FS比“普通”单节点FS更不成熟。集群FS通常意味着共享存储，这意味着如果您想避免单点故障，则需要相对昂贵的SAN。

另一种方法是建立一个集群，运行类似Amazon 3的集群，提供HTTP可访问、分布式和复制的键值存储。例如openstack存储。

Answer 3

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

但是，如果不反复请求映像，缓存也不会提供很大的提升，那么一两台服务器上的nginx/lighttpd就可以做到这一点。你还需要考虑你将要传送的带宽的数量。您的数据集的一个小子集的800 by /秒将很容易被操作系统缓存。数据集的一个巨大子集的800 be /秒可能会遇到IO瓶颈，因为您无法以足够快的速度将数据从磁盘上取出，以便在这种情况下，您需要将系统分成足够多的部分以获得IO带宽。

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