技术分享|GBase 8a在某客户的部署方案
软硬件需求估算
配置计算原则
按照客户方估算：初始入库10TB左右，月增长1TB左右，数据保存年限15年，基于以上计算考虑到系统冗余，集群整体数据承载能力需求大于200TB。建议部署3节点集群。由我方提供人员进行安装、部署和调试。我方将配合系统应用开发验收，应用系统投产试运行三个月后，启动产品验收。
对于MPP数据库集群，充分考虑OLAP分析型处理场景的特征，作为配置策略，配置主体依存于所处理的数据总量，而非OLTP在线交易类场景的TPMC等指标。依托数据库厂商积累的实际案例经验，在项目实施中合理规划硬件资源与处理数据量之间比例关系，确保最佳得发挥所购设备的各项技术性能。
硬件配置估算的过程立足海量数据分析、数据仓库类应用场景，同时严格平衡资源需求与性能指标之间的关系，此外还参考了GBase 8a MPP Cluster在金融、电信等行业其它类似案例中的实际工程经验。
一般类大数据平台MPP数据库建设中，CPU、内存与磁盘空间如下比例：即1core:8GB:1TB；
建议MPP数据库网络结构
集群需3台Linux服务器上部署MPP数据库软件。3个节点作为管理节点与数据节点部署在一起。集群GBase 8a MPP Cluster 管理节点、运算节点网络连接方式
说明：GBase 8a MPP Cluster数据库集群中每台服务器的配置2个万兆光口，双网卡绑定，分别连接到2台万兆交换机上，形成高可用，用于GBase 8a MPP Cluster数据库节点之间高速数据交换；配置2个万兆网卡，双网卡绑定，分别连接到2台万兆交换机上，形成高可用，用于GBase 8a MPP Cluster数据库集群与其外部节点如应用服务器、监控服务器等数据交换。
软件配置清单
| 产品名称 |
版本 |
备注 |
| GBase 8a MPP Cluster |
V95 |
南大通用大规模分布式并行数据库集群系统 |
备份
建议采用的存1备的方式。每个节点的数据都是3分之1乘以2。
数据高可用的保障机制包括主副本机制、gcrecover机制、failover机制等，它们共同确保GBase 8a MPP的数据高可用。
主副本机制：存储层提供的高可用保障，是数据高可用的基础。
gcrecover机制：执行层提供的数据高可用保障，是一种事务补偿机制，保障数据的最终一致性；与基于事务日志的强一致系统不同，8a MPP采取的是最终一致性（2PC+事务补偿），以获得更好的执行效率。
failover机制：一致性服务层（corosync）提供的数据高可用保障，属于集群层的末端保护，确保集群写操作在极端异常情况下的数据一致性；failover是一种数据高可用的保障机制，用来保障集群异常（发起节点gclusterd crash、发起节点掉电、集群整体crash等）情况下的数据一致性。
数据节点服务器配置估算
对于基于GBase 8a MPP Cluster分布式数据库集群系统，其物理磁盘容量的计算方法为：
最小磁盘空间需求MDSR (Minimum Disk Space Requirements) = 原始数据×数据库及相关工作空间因子×副本选项因子×操作系统因子×RAID因子×数据库压缩因子。
最小磁盘空间需求MDSR除以每台服务器的存储空间，就能得到数据节点服务器的数量。
| 膨胀因子 |
因子值 |
说明 |
| 数据库及相关工作空间因子 |
1.5 |
对于海量数据的复杂关联和复杂聚合运算，中间过程涉及大量表间关联操作，生成众多中间表；上述过程均占用较大的临时工作空间，一般预留30%~40%临时空间 |
| 副本选项因子 |
2 |
权衡性能、空间代价和高可用性等因素，配置1份副本 |
| 操作系统和文件系统因子 |
1 |
一般情况下，规划2块独立的400GSSD盘用于安装操作系统以及其他软件，操作系统盘不占据数据盘存储空间，所以此项因子为1 |
| RAID因子 |
12/10 |
一般采用RAID5，同时还需要考虑热备盘。12块盘3.84TB的SSD盘，设置1块热备盘，11块盘做成 1组RAID5； |
| 数据库压缩因子 |
1 |
本项目按压缩后实际落盘存储空间计算，不考虑原始数据的压缩比。故数据库压缩因子为1 |
协调节点服务器配置说明
协调节点部署分布式任务协调调度层组件GCluster，负责SQL的解析、SQL的优化、分布式执行计划生成、执行调度，管理元数据。
协调节点生成执行计划后下发给各计算节点进行计算，为保证协调节点之间元数据信息同步的高效性，以及协调节点与数据节点之间任务分发的高效性，协调节点之间、协调节点与计算节点之间必须使用万兆网络进行连接。
协调节点服务器的数量配置为单数。
服务器节点部署方案
部署架构
正式生产环境中管理节点负载分担的方式工作。计算节点通过数据副本实现高可用。
服务器节点设置
硬盘设置
操作系统盘与集群数据盘分开独立划分RAID，防止操作系统损坏对数据的影响，系统盘采用RAID1，数据盘采用RAID50，具体划分策略如下表：
| 用途 |
磁盘划分 |
目录 |
文件系统格式 |
大小 |
目录含义 |
备注 |
| 操作系统盘 |
两块盘RAID1 |
/ |
XFS |
约600GB（以盘的实际大小为准） |
操作系统根目录 |
默认 |
| /boot |
XFS |
500M |
操作系统引导目录 |
|||
| /swap |
XFS |
128GB |
操作系统swap |
|||
| 数据盘 |
剩余盘RAID50（1块全局热备） |
/opt |
XFS |
数据库主目录 |
RAID卡设置建议： Strip Size：条带尺寸为1M； Access Policy：设置为RW； Read Policy：设置为Ahead； Write Policy：设置为Write Back with BBU； IO Policy：设置为Cached IO模式； |
操作系统设置
为发挥GBase 8a集群的最佳性能，部署时需对操作系统的部分参数做一些调整修改，详细设置如下表：
| 参数项 |
设置值 |
含义 |
| vm.vfs_cache_pressure |
1024 |
表示内核回收用于directory和inode cache内存的倾向，默认值为100，增加该值超过100，将导致内核倾向于回收directory和inode cache；集群服务器设置此操作系统参数为1024，使操作系统倾向于回收directory和inode cache，避免定时执行sync&&sync&&echo 3>/proc/sys/vm/drop_caches操作 |
| vm.min_free_kbytes |
8388608 |
表示强制Linux 操作系统为VM文件系统最低保留多少空闲内存（Kbytes），此参数设置为8G大小可以避免因gbase库进程占用大量内存导致异常 |
| kernel.core_uses_pid |
1 |
控制核心转储是否附加PID的核心文。用于调试多线程应序件。 |
| net.ipv4.tcp_syncookies |
1 |
控制 TCPsyncookies的使用。 |
| net.ipv4.ip_local_reserved_portss |
5050,5258,5288,6666 |
防止数据库需要使用的端口被其他程序强行占用 |
| vm.zone_reclaim_mode |
0 |
配置vm.zone_reclaim_mode = 0使得内存不足时去remote memory分配优先于swap out local page |
| vm.swappiness |
1 |
swappiness参数为swap内存使用倾向，60代表内存剩余60%时会使用swap，设置为1表示强制使用物理内存。 |
| net.core.netdev_max_backlog |
262144 |
每个网络接口收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包最大目。 |
| vm.overcommit_memory |
0 |
检查是否有足够的内存可用，如果是，允许分配；如内存不够拒绝该请求，并返回一个错误给应用程序。 |
| net.core.rmem_default |
8388608 |
接收套字缓冲区大小的默认值(以字节为单位 ) |
| net.core.rmem_max |
16777216 |
接收套字缓冲区大小的最大值(以字节为单位 ) |
| net.core.somaxconn |
65536 |
用来限制监听(LISTEN)队列最大数据包的数量，超过这个就会导致链接超时或者触发重传机制。 |
| net.core.wmem_default |
8388608 |
发送套字缓冲区大小的默认值(以字节为单位 ) |
| net.core.wmem_max |
16777216 |
发送套字缓冲区大小的最大值(以字节为单位 ) |
| net.ipv4.tcp_fin_timeout |
1 |
如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAITT-2状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是60秒。 |
| net.net.ipv4.tcp_max_orphans |
3276800 |
系统中最多有少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，孤儿连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单的 仅是为了防止简单的DoS攻击，不能过分依靠它或者人为地减小这个值， 更应该增加这个值(如果增加了内存之后 )。 |
| net.ipv4.tcp_max_syn_backlog |
262144 |
表示那些尚未收到客户端确认信息的连接（ SYN 消息）队列的长度，默认为 1024，加大队列长度为 ，加大队列长度为262144，可以容纳更多等待连接的网络连接数。 |
| net.ipv4.tcp_max_tw_buckets |
20000 |
系统在同时所处理的最大timewait sockets数目。如果超过此的话time-wait socket会被立即删除并且显示警告信息。之所以要设定这个 且显示警告信息。之所以要设定这个限制，纯粹为了抵御那些简单的Dos攻击，千万不要人为的降低这个限制攻击，不过如果网络条件需要比默认值更多，则可以提高它 (或许还要增加内存)。 |
| net.ipv4.tcp_mem |
94500000 915000000 927000000 |
第一个值是内存使用的下限。第二个值是内存压力模式开始对缓冲区使用的上限。第三个值是内存应用压力的上 限。第三个值是内存上限。在这个层次上可以将报文丢弃，从而减少对内存的使用。 |
| net.ipv4.tcp_rmem |
4096 87380 4194304 |
TCP 接收缓冲区，3个字段分别是 min，default，max。MIN：为TCP socket预留用于接收缓冲的内存数量，即使在内存出现紧张情况下TCP socket都至少会有这么多数量的内存用于接收。 |
| net.ipv4.tcp_timestamps |
0 |
时间戳可以避免序列号的卷绕。一个 1Gbps 1Gbps的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种 “异常”的数据包。 |
| net.ipv4.tcp_tw_recycle |
1 |
开启 TCP 连接中 TIME-WAIT sockets的快速回收，默认为0，表示关闭。 |
| net.ipv4.tcp_wmem |
4096 87380 4194304 |
TCP发送缓冲区，3个字段分别是 min， default，max。Min：为 TCP socket预留用于发送缓冲的内存最小值。每个 TCP socket都可以使用它。 |
| net.ipv4.tcp_tw_reuse |
1 |
表示是否允许重新应用处于 TIME-WAIT 状态的socket用于新的TCP连接。 |
| net.ipv4.tcp_sack |
1 |
表示是否启用有选择的应答 （Selective Acknowledgment），这可以通过有选择地应答乱序接收到的报文来提高性能（这样可以让发送者只发送丢失的报文段）；（对于广域网通 信来说）这个选项应该启用，但是会增加对 CPU的占用。 |
| net.ipv4.tcp_window_scaling |
1 |
支持更大的TCP窗口。 如果TCP窗口最大超过 65535(64KB), 必须设置该数值为1。 |
| ulimit虚拟内存配置 |
/etc/security/limits.conf，添加如下两行，操作系统重启后生效： |
虚拟内存不足会造成的运算缓慢 |
| ulimit内存配置 |
/etc/security/limits.conf，添加如下内容 |
内存不足时杀掉进程 |
| ulimit打开文件数配置 |
/etc/security/limits.conf，添加如下内容 |
文件句柄数不足集群使用报错 |
| 透明页 transparent_hugepage |
never |
为保证数据库高效运行，需要关闭 transparent_hugepage 参数 |
| 服务器操作系统IO调度器 |
deadline |
GBase集群服务器需要将IO调度器（IO elevator）配置为deadline以提升小文件读写IO效率 |
| selinux |
disabled |
要求各节点禁用 SELINUX |
网络设置
集群节点配置千兆和万兆网络IP地址（千兆连接办公网，万兆用于集群内部数据交换）
万兆、千兆网络均需采用双网卡绑定，绑定模式为主备模式（mode=1），网卡绑定必须设置成开机自动生效。
后续扩展方案
硬件扩展方案
对于分布式MPP数据库系统，建议采用水平横向扩展方式进行系统扩展，即增加集群节点数量实现集群规模的扩展。GBase 8a MPP Cluster分布式数据库的性能随集群节点数量增加而呈准线性提升，具体包括存储容量的扩增，计算能力提升和并发响应能力的增长。
系统扩容的控制行为完全由GBase 8a MPP Cluster集群内部自动完成，即扩容过程中数据的重分布和集群结构的元数据更新全部由内部自动完成。通过元数据信息更新保证映射关系的无损失移植，保证扩容后集群结构对上层应用透明，使原有应用可以平滑移植，即应用无需修改。扩容之后，考虑MPP + Shared nothing 的分布式数据库特征，系统能力(包括存储能力和处理能力)会根据节点数增加而近线形提升。对于功能扩展的情形，一方面要扩展集群的节点数规模，而另一方面则应考虑通过产品的资源管理组功能实现集群资源的多租户能力，以防止随着系统功能扩展而发生应用之间资源相互争夺以及相互影响的情况。
作为GBase 8a MPP Cluster分布式数据库的内部数据重分布实现，充分利用了虚拟哈希桶提供的2层映射关系，从而大大加强了系统的扩展灵活性。其具体的扩容实现过程如下：
GBase 8a MPP Cluster分布式数据库的扩容的步骤/原理简述如下：
1） 新增节点元数据的生成；
2） 根据扩容节点计算新的hash 桶分布(从每个老的集群节点上移动一定数量的hash 桶到新的集群节点)；
3） 按照新的hash 桶分布采用select into server 的方式将老节点上的符合新的hash 桶分布要求的数据搬移到新节点；(select into server：将符合条件的数据insert 到一个节点分片上，即在老节点上执行select，在新节点上执行insert)；
4） delete 老节点上的重新分布已经完成的数据；
5） 重新生成hash 映射表nodedatamap（nodedatamap 表记录了哪些hash 桶分布在哪个节点上）；
GBase 8a MPP Cluster分布式数据库扩容过程中不支持人为的暂停和续作。但在扩容期间，如果因为网络等异常原因导致扩容失败而中断时，在故障排除后使用完全相同的扩容命令（包括参数）重新扩容时，扩容程序会自动从上次失败时中断的地方开始，继续进行后续的扩容步骤。这就实现GBase 8a MPP Cluster分布式数据库扩容过程中所需要的断点续传功能。
GBase 8a MPP Cluster分布式数据库支持动态扩展，支持灵活的系统扩展方式，包括容量扩展、主机服务器扩展、应用功能扩展等，下面分别对这些系统扩展方式进行描述，并且说明该扩展对现有系统的影响。
1）容量扩展
单集群节点扩容：集群节点增配硬盘，扩展单节点存储容量。
增加节点：通过增加集群节点，扩展集群存储容量。
对现有系统的影响：提升系统的数据存储容量，无负面影响。
2）主机计算能力扩展
单节点增配：扩展节点的内存、CPU等，提升集群节点的计算能力。
增加节点：通过增加集群节点，扩展集群的计算能力，并发能力。
对现有系统的影响：提升系统的性能，包括计算能力、并发能力等，无负面影响。
3）应用功能扩展
应用系统功能扩展对GBase 8a MPP Cluster分布式数据库无影响。
对现有系统的影响：增强系统功能，无负面影响。
软件扩展方案
作为软件扩展方案，在GBase 8a MPP Cluster分布式数据库增加新功能时，可通过平滑升级每个节点上的数据库及集群软件、打补丁等，增强GBase 8a MPP Cluster分布式数据库的功能，提升其性能。
作为实际实施时，往往在增加GBase 8a MPP Cluster分布式数据库集群节点时，同时可以考虑实施快速的系统软件的升级部署，包括操作系统、GBase 8a MPP Cluster分布式数据库等，并需要同时进行数据重新分布，以通过软件扩展方式全面提升系统能力。