首页 > 代码库 > 私有云存储服务4节点部署各方案对比

私有云存储服务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部署相关的书中一开始都会强调——“不要为了优化而优化”。只要满足现在的要求并能为未来的优化留下空间就行,因为完美的要求永远是动态变化的。