OushuDB(MPP)集群硬件规划

OushuDBMPP集群硬件规划
OushuDB(MPP)硬件配置原则
性能原则
均衡原则
可靠性原则
OushuDB(MPP)硬件配置建议选择
处理器与内存
网卡
存储
RAID配置
RAID卡选项
OushuDB(MPP)硬件配置原则
OushuDB是一个数据库产品,在企业系统框架里数据库属于比较核心的地位，所以一般数据库产品我们会考虑几个方面

性能原则
有一个误区，由于OushuDB存储使用的是HDFS，很多说法是HDFS对硬件要求不高，选用HDFS就是要降低硬件成本，这也是这种项目与传统数据库的优势。
其实这种说法是不对的，也可以说是片面的，这种观念的产生，主要还是业务需求的问题，因为目前大部分在HDFS(HADOOP常见场景)都是属于历史数据存储，或者做简单加工，这种应用对性能本身要求就不是很高，响应级别也很低，那么硬件可能相对要求不是很高，所以硬件配置完全与应用相关，硬件是性能的基础，让我们想象一下在硬件无穷大的情况下，什么设计与优化都不必关心，当然这是不现实的事情。
我们要做的是在现有需求的前提下做佳性价比的选择

均衡原则
配置均衡是硬件配置很重要的原则，不然会出现严重的浪费情况。

下面有几个例子：

配置1：cpu 24个核，内存256GB,网络万兆环境，两个机械盘容量16T

配置2：cpu 24个核，内存256GB,网络千兆环境，12个机械每块盘容量12T

配置3：cpu 24个核，内存256GB,网络万兆环境，12个机械每块盘容量96T

配置1的配置看起来很强劲，但是只有两块物理盘，终会怎么样呢，出现了一个明显的"木桶"，两块物理盘可能IO吞吐量才200多MB，那么在应用繁忙时cpu和网络都在等IO,这种配置还不如配个少点cpu,千兆网络，当然内存也不用那么高，因为配置高也用不到(当然不是情况，cpu密集计算情况下cpu多点还是好的，但是一般作为离线的数据仓库产品，大量的批量操作使得IO使用都会很大)。

配置2也是同理，在其他配置都很高的情况下，网络是千兆的，那么千兆网络实际也就100MB带宽，12块盘一般都在1GB的带宽，由于我们是MPP架构，终瓶颈全在网络上了。

配置3很有意思，我们看到似乎配置很平均，不过按这个配置每块盘8T，明显这是大容量盘，这里有两个问题。
个问题，一般我们扩容都是与存储相关的，如果一个节点的空间没用到50%以上有什么理由去扩容？申请扩容都很难，但是按这么大的容量，到后来计算能力很可能跟不上，就会出现"小马拉大车的情况"。
第二个问题，一般大容量盘转速都比较低，那么一进一出这个配置在项目后期会有很大问题。

所以总结一下，均衡不单要考虑项目前期，还要考虑后期随数据量上升，扩容的问题，才能保证系统与资源的健康良性扩展。

可靠性原则
可靠性是所有数据库产品必需考虑的问题，X86架构的PC服务器在稳定性上肯定不如小机，所以我们在软件实现了一定的高可用，不过由于硬件的不稳定导致的问题肯定会影响到软件，所以在选择硬件上一般要选择业界比较稳定的机型搭建集群。

OushuDB(MPP)硬件配置建议选择
我们的推荐：

处理器(CPU)：双路(2*8核)/ 双路(2*12核) intel
执行以下语句，确定CPU是否有相关avx指令集
cat /proc/cpuinfo | grep avx (新执行器)
内存：128GB/256GB
网卡：one-port/dual-port 万兆网卡
mode=4绑定或者mode=6绑定
存储：12 * 2TB
SAS盘
RAID 5(Hot-Spare)或者RAID1+0 、条带化512KB、Read Policy为Read Ahead、Write Policy为Write Back
交换机：网兆交换机
建议开启LACP功能，做动态链路聚合，或者对应mode=6不做配置

处理器与内存
处理器推荐以当前情况来看，还是比较普遍的配置，性价比很好，需要注意的是目前我们只支持intel，并且CPU是否有avx扩展指令集(这个是我们新执行器需要支持的)。内存的推荐配置也比较普遍。

网卡
网卡方面，希望万兆并且条件允许的情况下好4块网卡，因为一般设计会做内网与外网的的隔离，往往一个网段需要两块做绑定所以需要四块，绑定级别上一般选择mode 4或者mode 6，聚合以后可以保证高可用与负载均衡的兼顾。

存储
存储一般推荐SAS盘，SATA盘差了一点，SSD很少有全配的，1块两块SSD比10几块机械盘IO吞吐量还是不够的，所以SAS盘性价比比较好。

RAID配置
raid配置上推荐RAID 5(Hot-Spare)或者RAID1+0，虽然OushuDB有自己的数据副本，出现坏盘不至于影响应用，不过总归是一个故障，如果有一层raid保护可以更好的高可用，比如RAID 5(Hot-Spare)盘坏后热盘直接自动替换，一般磁盘在3年后会慢慢出现故障。另外RAID卡的缓存对性能也有很大帮助。

RAID卡选项
Read Policy为Read Ahead，条带化512KB
因为MPP数据库主要面向离线系统，操作大多是顺序读，所以块大点可以减少IO次数，Read Ahead也对顺序读有预读缓存的优化，所以建议这样选择，不过如果是随机读频繁的场景，就不太适合这种选择。

Write Policy为Write Back
Write Back在高速缓存性能上优于Write through,但是在安全性上Write through好。

Force WB with no battery
这个是在raid电池损坏的情况下依然缓存写，这样如果出现故障有丢数的可能性，这个要看取舍。
————————————————
版权声明：本文为CSDN博主「shi.heng@oushu.io」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/nkgsh/article/details/118371605