我已经有了40年的计算能力,但是我从来没有像现在这样build立一个服务器,所以这可能是一个问题。
我有一个客户端,将提供超高清音乐文件下载。 在这种情况下,这意味着FLAC压缩24 / 192Khz =〜10GB /专辑。 (不,我不想讨论产品的可取性,只是服务器configuration。)目录大约有3000个专辑,包括超高清和低清版本(对于他们的iPod,我想),给出原始数据35-40TB左右。
由于这是一个非常专业化的产品,因此市场规模相对较小(想想:在audio系统上花费2万美元以上的人),这意味着大多数情况下服务器将100%空闲(或接近它)。 ColocationAmerica提供的1Gbps连接和带宽约为20美元/ TB,这是一个很好的托pipe服务,所以现在我只需要构build一个盒子来交付货物。
数据访问用例是一次写入/多次读取的,所以我正考虑使用软件RAID 1来配对驱动器。 这可以让我(我认为 )重新configuration备用驱动器的故障的dynamic,从而能够开始重build第二个驱动器之前,一些系统pipe理员注意到系统上的红灯(他们可以自由换出)。 如果不需要的话,我可以让大部分硬盘进入hibernate/hibernate状态,这对于大多数硬盘来说是大部分时间。
我并不需要太多的计算能力 – 这个东西只是把肥pipe放在pipe道上 – 所以CPU /主板可以是非常适中的,只要它能支持这个数量的驱动器。
我目前正在考虑以下configuration:
Chasis: Supermicro CSE-847E26-RJBOD1 Drives: 30 4TB SAS drives (Seagate ST4000NM0023 ?) MB: SUPERMICRO MBD-X10SAE-O w/ 8GB CPU: Xeon E3-1220V3 3.1GHz LGA 1150 80W Quad-Core Server
那么,我是朝着正确的方向走,还是这是一个完全解决问题的方法?
更新以澄清几点:
ZFS? 效益在哪里?
好吧,我正在通过多个ZFS指南,常见问题解答等方式来抨击我。请原谅我听起来很愚蠢,但我真的很想了解使用ZFS而不是N RAID1对的先前概念。 在这个最佳实践的页面(从2006年开始),他们甚至build议不要使用48个ZFS设备,而是使用24个2个设备的镜像 – 这听起来就像我正在谈论的那样。 其他页面提到为了交付1个(一个)ZFS块而必须访问的设备数量。 另外,请记住,每个对象10GB,磁盘利用率为80%, 每个4TB驱动器总共存储320个文件。 对于任何给定的驱动器故障,我使用N个RAID 1重build时间是从一个设备到另一个设备的4TB写入。 ZFS如何使这个更好?
我会承认是恐龙,但是磁盘价格便宜,RAID 1我知道,我的文件pipe理需求是微不足道的,Linux上的ZFS(我的首选操作系统)还是很年轻的。 也许我太保守了,但是当我看着一个生产系统的时候,我就是这样滚动的。
我感谢你们所有的意见,这让我想到了这一点。 我还没有完全决定,我可能不得不回来问一些更多的问题。
根据您的问题描述,您的问题不是存储的服务器。
您需要像ZFS这样的可靠,强大的文件系统来处理大型存储容量,并且具有内置的pipe理function,以使系统的端点更容易pipe理。
正如在评论中提到的那样,我将使用ZFS作为存储池(可能在FreeBSD上,因为我对这个操作系统非常熟悉,而且它在ZFS方面有很长的,可靠的性能logging – 我的第二select操作系统将是Illumos ,再次因为经过良好testing的ZFS支持)。
至于提供的文件,我同意 – 你不需要太多的硬件,只是推出的数据networking端口。 CPU / RAM的主要驱动程序将成为文件系统(ZFS)的需求。
一般的经验法则是ZFS需要1GB内存,加上每pipe理10TB磁盘空间需要1GB(因此对于40TB,ZFS需要5GB内存) – 这种关系不是非常线性的(有很多关于ZFS的好书/教程/文档,可以帮助您对您的环境进行估算)。
请注意,添加重复数据删除等ZFS铃声和哨声将需要更多的RAM。
很明显,内存要求不是宕机,不要吝啬:如果你的math说,你需要5GB的内存不要加载8GB的服务器 – 升级到16GB。
然后,您可以直接在存储盒上运行服务器(这意味着您需要更多的RAM来支持服务器进程),或者您可以将存储远程安装到“前端”服务器实际上服务客户的要求
(前者最初便宜,后者长期更好。)
除了这个build议,我可以给你的最好的build议已经在我们的容量规划系列的问题中得到了很好的覆盖 – 基本上就是“负载testing, 负载testing , 负载testing ”。
我使用ZFS作为多TB服务器,并且一直坚如磐石。 我使用OpenIndiana开始,现在已经转移到FreeNAS,因为它做我需要做的。
我推荐使用带有SAS扩展器的LSI HBA卡(9211-8i是一个很好的基卡)(SuperMicro案例可以使用基于LSI芯片组的集成SAS扩展器)。 FreeNAS和FreeBSD支持LSI固件。 检查适当的版本(V16在FreeBSD V9.x上是好的)。
考虑到一次写入你的系统的许多性质,我会使用ZFS Z2拓扑(避免RAID-5和Z1驱动器的大小)。 考虑到您使用的是4TB磁盘,如果池已满,大型单个vDevarrays的重build(重新启动)时间将会很长。 为了避免冗长的重build时间,请将vDevs分成6组或10组来创build池(FreeNAS文档中的build议)。 由三个6驱动器vDevs(假定4TB驱动器)组成的池将具有〜48TB的可用容量,并提供良好的容错级别(请记住,由于RAID不会替代备份,所以仍然需要备份)。
为了加快常用文件的速度,你可以在L2ARC上安装一些固态硬盘(可能不是你的应用程序所需要的,但是对于120GB固态硬盘来说它们相当便宜)。
如上所述,使用大量的RAM。 考虑到系统中的其他硬件,64GB并不是太昂贵。 不幸的是,更小的XEON不能使用超过32GB。 你可以试试,但根据ZFS文献(我使用XEON你提到的32GB内存和24TB容量的Z2arrays,它工作正常),更多的RAM会更好。
ZFS的另一个优点是您可以设置定期快照。 这样,您可以轻松恢复以前的版本,快照非常节省空间。 此外,您可以将任何快照复制到另一个数据集(本地或远程),这可以通过SSH安全来完成。
我非常喜欢ZFS系统的可靠性。 我也喜欢它是硬件独立的事实! 任何可以看到驱动器的系统都可以导入池。 没有固件依赖等,可能发生在硬件突袭(不是一个更好的卡问题,但他们比HBA卡更昂贵,需要驱动程序等 – 在过去一点点)。
鉴于这个post比较老,你可能有一个解决scheme。 如果是这样,请告诉我们你build立了什么?
干杯,