最近一直有人咨询超融合私有云的项目实施及运行情况,正好有两个项目,一直良好运行着,下面我们先来看看其运行情况。

项目1

4个物理节点,前端两台配置很低的旧物理服务器做负载均衡,再加上备份等其它辅助设施。超融合私有云核心部分的配置如下:

1.单台服务器:2颗cpu(10核心、20线程,总线程数40);196G DDR3内存;一块256G 固态硬盘,三块1.8T 10000转sas磁盘。

2.网络:数据与集群网络皆为千兆,双网卡绑定。

3.业务数据如下图所示:

QQ截图20190121115629.jpg

主站当前数据

 

QQ截图20190121120006.jpg

论坛当前数据

再来看看底层平台的运行情况:

mmy01.jpg

4节点承载35个运行中的虚拟机

 

mmy02.jpg

不间断无故障运行91天

项目实际是2018年7月正式上线运行的,由于中间搬迁过机柜,所有设备都断电,因此系统现实的持续运行时间是91天。另外,再运行过程中,在线扩充了内存。具体操作是--先随机关闭一个物理节点,等运行其上的虚拟机全部漂移到其它物理节点且正常运行后,下架该服务器,并插入内存;上架开机,从管理后台人工迁移一些虚拟机到此新增内存的服务器。重复这个过程,顺利完成在线扩充内存容量。

 

当然也有教训,那就是不小心对ceph做了离线操作,导致部分磁盘不可用,还好,通过折腾得以恢复。

mmy03.jpg

状态为UP

项目2

在第一个项目成功的基础上,很快就实施第二个项目。

还是四个物理节点组成超融合私有云,加上其它一些辅助设施,组成一个可用性极高的应用平台。虚拟机可以随便死掉一些、物理节点也可以随便死掉1-2台、负载均衡也可以随便死掉1台,而业务不会中断。甚至整个平台奔溃,也可以利用备份数据,重新快速部署一套新的超融合私有云,挂接备份,很快就能完整恢复,而不需要像传统方式那样复制数据,占用大量的资源、耗费更多的时间。

超融合私有云核心部分的配置如下:

1.单台服务器:2颗cpu(10核心、20线程,总线程数40);256G DDR3内存;一块256G 固态硬盘,四块2.4T 10000转sas磁盘。

2.网络:数据为千兆,集群网络为万兆(集群网络与存储网络合二为一)。

平台的整体运行情况如下图所示:

itpub01.jpg

44个虚拟机处于运行状态

 

itpub02.jpg

无间断运行100多天

本项目在运行中,为出现设置上的问题(如前个项目的误操作),但有段时间的夜间,某几个虚拟机的负载飙升,传导至与其关联的数据库,导致具体的一个站点打不开(502错误),通过分析日志,一部分是流氓爬虫作祟,一部分是恶意请求,在系统层面和web层面做了限定以后,逐渐趋于正常。

 

超融合私有云通用架构

虽然两个项目互不隶属,应用上也存在差异,但总体架构及规划思路是一致的,由本人规划、实施及日常运营。下面给出通用框架,共大家在项目中参考。

jiagou01.jpg

超融合私有云系统架构模型

超融合私有云的主要特征

1.去中心化:没有专门的控制节点、没有共享存储。节点集群去中心化,分布式存储集群ceph也是去中心化的。

2.统一管理界面:web管控物理节点、虚拟机、容器、存储、网络、克隆、迁移、备份、恢复、去中心化存储ceph...

3.快速部署:iso一键安装,功能几乎全部集成;安装过程仅仅需要输入密码、ip地址等少数信息。

4.灵活可控:底层是完整版本的debian9,老司机可以在底层进行各种操作。

5.更高的可用性:去中心化加上前端负载均衡等辅助设施,可用性比常规模式要高好几个量级。

6.更低的建设成本:去掉了昂贵的集中存储,不光是成本大幅降低,性能和存储可靠性得以大大提升--磁盘io、网络io分散。

7.易于恢复与重建:超融合私有云具有很高的可用性,保证数据的安全及业务的连续性,极端情况下,即便整各系统崩溃,也能迅速重建并恢复系统。


怎么样?伙计们,动心了么?欢迎打call。