私有云存储服务4节点部署各方案对比

近日因工作需要在某高校安装私有云存储系统。部署环境是一台4节点服务器，每个节点有16GB内存，3个硬盘，每个硬盘3TB ，每个节点可用空间约为8TB。部署的目标是充分利用所有的服务器资源，提供可靠的存储服务，同时尽量不要修改我们的系统源代码。由于本人在web服务部署经验尚浅，遂问计于师哥，对比了如下多种部署方案。

1. 原始方案

• 说明：1节点部署ffmpeg转码服务，1节点部署私有云存储系统（nginx+mysql+php代码）。文件读写只在部署了私有云存储的节点进行，日后购买磁盘阵列后将存储挂载到磁盘阵列上。
• 优点：部署简单
• 缺点：有2个节点完全没有使用，作为转码服务的节点的空间利用率极低。实际可用的文件存储空间只有安装了云存储系统的节点上的8TB空间。该节点压力大，存在单点故障。
• 结论：浪费太大，可靠性差，不可

 

2.mfs 方案

• 说明：所有节点都部署mfs分布式文件系统。其中一个节点做mfs的元数据服务器，其他三个做mfs存储服务器。此外对于这三个存储服务器，用一台部署nginx和php代码做主web服务器，一台部署ffmpeg转码服务，一台部署mysql做数据库服务器。
• 优点：首先，每个节点都得到了利用。其次，由于安装了mfs，每个文件在三个节点中都有副本，数据安全性高，可靠性高。
• 缺点：mfs的三副本策略导致实际可用文件存储空间只有8TB。虽然可以设置只用1副本来增加可用空间，但是会降低可靠性。mfs依然存在单点故障（mfs的元数据服务器）。这个架构中，mfs元数据服务器、或者mysql数据库服务器、web服务器中有任意一台挂掉都会导致整个服务中断。此外，mfs安装虽然容易，但是一旦发生故障我缺少处理经验（能安装和能排错是完全不同的两个层次）。
• 结论：此方案虽然服务器资源都用上了，但是在生产环境中维护成本高，单点故障多，并且空间依然只有8TB，所以再议。

 

3. iscsi级联+raid方案

部署方案

• 说明：一个节点部署ffmpeg转码服务，一个节点部署nginx和php代码做主web服务器，一个节点安装mysql做主数据库服务器，一个节点安装mysql做热备数据库服务器。除去每个节点必须的存储空间外，剩下的存储空间都使用iscsi级联，并作raid10或raid5，挂载到web服务器上用于文件读写。
• 优点：所有节点都得到了利用，并且存储空间利用率远较前两个方案高。设每个节点自用一个硬盘，另外两个硬盘用于iscsi级联，4个节点级联后可用空间为24TB。采用raid10后，I/O速度提高两倍，可靠性大幅提高，可用空间为变为12TB，依然比1，2方案高。若采用raid5，则1盘做冗余，7盘做存储，可用空间为21TB。相对raid10而言空间利用率提高，读写速度降低。
• 缺点：存在一个单点故障——web服务器。
• 结论：此方案存储空间利用率较之1，2方案而言大幅提高，并且可靠性不比2低：文件存储空间有raid保护，数据库有热备，单点故障少。此外部署难度低，故障容易处理。可以说是目前最好的方案。

 

4.负载均衡方案

• 说明：在3的基础上，设置nginx负载均衡，让主mysql服务器只负责写，从mysql服务器只负责读。
• 优点：主数据库服务器负载有所下降。
• 缺点：要修改系统读写数据库的源代码，成本过高。
• 结论：在目前的4节点服务器中搞负载均衡实在是没什么必要。由于转码服务需要大量cpu计算能力，所以必须分单独一个节点来做。另外3个节点又必须分一个来单独做数据库服务器。对于剩下两个节点，要么都做web服务器，要么一个做web服务器一个做从数据库服务器。私有云存储系统的主要压力不在web服务，而是在数据库读写和文件存储中。所以负载均衡只能是对两台数据库服务器来做，但是这样要修改系统读写数据的源代码，成本过高。不如方案3的双机热备。

 

5.使用openstack或者vmware vcenter搞多机虚拟化

• 说明：4个节点，一个做ffmpeg转码服务，另外3个物理节点用软件openstack或者vmware vcenter变成一个虚拟机来部署安装私有云存储系统（nginx+mysql+php代码）。
• 优点：只要搞定了虚拟机，代码安装部署比较容易。其他什么效率啊，安全啊，可靠性啊，都让虚拟机软件来做。
• 缺点：这种方式的虚拟机效率低，分布式共享内存效率好不了。本来内存延迟很小的，但是经过网络之后，延迟会大几个数量级。这又不是大型机。并且openstack和vmware vcenter这种部署方式，实际上要调的参数太多，我们并不精通，很容易出现故障，出现了也难以排除。
• 结论：这个方案显然是一拍大腿想出来的。虚拟机虽然很好用，但是这样引入了未知的黑洞。据我所知很少有生产环境这么搞的——效率是最直接的问题。听说dell刚刚收购了一家公司是搞这个的，但是这种技术并不成熟。为此我还专门询问了在做openstack的师哥，连他也没见过这么搞的。新技术方案没有充分的调研和实验是不能直接上的。

结语：

最终我们采用了方案3。

系统部署方案有很多，但是每个都不是万能的。什么是好？适应当前环境的就是好。就现在来看，方案3最好，实现了最小成本最高效率和可靠性。当然，想继续优化也没问题，但是从4，5两个方案中可以看出，这样的优化是代价越来越高，效果越来越小，带来的副作用越来越多。搞负载均衡，那负载均衡的那个节点也是单点故障。其实要服务挂掉很容易，交换机一挂就全完了。就一个4节点服务器，还要怎么耍？把各种分布式文件系统都装上？复杂性那么高，以后还要不要维护了？要知道简单就是美。其实几乎每本linux部署相关的书中一开始都会强调——“不要为了优化而优化”。只要满足现在的要求并能为未来的优化留下空间就行，因为完美的要求永远是动态变化的。