传统客户调研国产分布式数据库过程中，POC(Proof Of Conception的简称)环节必不可少。各家数据库POC是否顺利，是否卓有成效，技术上通常跟下面几点有关系:

• 测试需求
• 测试环境
• 测试方案

本文主要记录测试环境准备方面的思考。由于对其他产品测试环境准备不了解，所以说的都是OB方面的经验。

OceanBase部署步骤麻烦吗？我曾经在文章《OceanBase数据库实践入门——手动搭建OceanBase集群》里总结过OceanBase集群的搭建相比ORACLE RAC而言还是很简单的。当客户问我部署OB要多久，早期我常说1-2个小时就可以(环境OK时15分钟就可以)，然而却多次被现实打脸，经常半天下来，我还在整理客户测试环境(机器)。

整理机器环境的事情非常琐碎。比如说统一主机名风格、软件版本和YUM源、时间设置和NTP源、文件系统目录、内核参数、会话参数、网络和安全设置等。机器数量多的时候更加费时。有人问，为什么不用自动化脚本去做？不是不想，是不能。自动化的前提是标准化。交付的机器在软硬件各项方面如果有很大不同，自动化脚本可能还不如手动快。

虽然很琐碎，标准化是一个企业运维走向成熟的必经阶段，关乎效率、成本。下面是一些经验。

• 主机名：体现机房信息、IP后面6位信息。
• 网卡：每个网口在主机层面默认是一个网卡，主机上看至少会有2个网卡，建议做bonding。物理上2个网口连接两个交换机。这样单个网口就有高可用。传统客户可能还有2个口用于管理IP。如果要考虑单个网卡或者单个交换机的故障场景，那建议两个网卡分别选一个口做bonding。这种物理连线方式和bonding的配置方法会决定测试中某些场景需求是否可以实现。
• NUMA：数据库主机建议关闭NUMA，在BIOS里关闭最好，其次是在grub.conf里关闭。
• 硬盘：如果硬盘很多，单独取两块盘做RAID1。其他盘如果是SAS，则做RAID10；如果是SSD，则做RAID5；如果是一块大容量NVME接口的SSD或者flash卡之类，则直接用。
• 文件系统：操作系统相关的文件系统和数据库文件和日志相关的文件系统分别使用不同的盘。只有一个大容量裸设备时用LVM输出两个LV，分别用于数据库数据文件和事务日志。通常关系型数据库的数据文件和事务日志文件的读写特点不一样，性能最好的盘输出的裸设备优先给事务日志文件系统使用。
• 内核参数：数据库通常对网络报文、信号量有特别设置。
• 防火墙：数据库不建议开防火墙，访问安全通过交换机上vlan设置实现。
• 会话设置：调大会话能使用的一些计算机资源，如文件句柄数、消息队列、内存或虚拟内存、core dump文件、进程数等等。
• 时间和时区：默认时区东8区，除非有国际业务，时间配置同步，源为内部NTP服务器。如果没有内部NTP服务器，手动调整服务器时间为当前时间(不要相差太多)。多个机器搭建分布式数据库产品时，选其中一台机器充当NTP源给其他机器同步时间用。

以上这些标准大部分可以做到装机模板中。

OceanBase的集群安装有手动安装和自动安装两种方式。自动安装是通过OCP(OceanBase Cloud Platform的简称)平台做的，在文章《OceanBase一体机和云栖大会OB体验介绍》里有简单介绍。OCP还是需要手动安装，目前使用Docker编排技术能做到很高的自动化。只要机器符合上面标准，OCP的安装完全可以一键搞定。

对OCP，客户常有很多误解。

首先，这只是个监控告警平台。实际上OCP是个运维PaaS平台，运维对数据库的绝大部分操作都可以在这个平台上通过图形化界面完成。对此不同客户运维的观点不一。有的期望平台能做所有事情，运维不接触实际机器，减少出问题的概率和不必要的风险、责任。也有的运维喜欢技术细节，喜欢命令行下可控制的那种感觉。无论哪种需求都可以满足。

第二，OCP只是个运维平台，用户少应该没有多大压力，对资源要求应该很少。实际是运维PaaS平台会管理监控所有OceanBase集群，即使业务OB集群很空闲，运维平台的后台任务却不会空闲。OCP也有自己的元数据库(一个独立的OB集群)，OCP以及它的元数据库应该是运维产品和数据库中最核心的，离开它就不能方便管理业务OB集群。当然，如果OCP或者OCP的OB不可用，对业务OB是不会有实际影响，只会影响运维的工作。但是OCP及其OB依然是运维应该重点保障的对象。所有用于OCP安装的机器的资源能力(CPU、内存和空间)不能太少。否则后面各种运维任务(包括安装业务OB集群)会非常慢甚至失败报错，影响运维体验，乃至OB POC结果的分析定性等。

说到OB要求的机器资源，网友和客户可能颇多微词。这点确实是OceanBase及其产品目前做得还不够好的地方，主要是当前所有研发的精力都在做产品的核心能力上。这些机器资源相比对于外部客户的生产环境机器来说并不高，只是开发测试环境很难有这么高配的机器。对网友学习OceanBase也是一个很大的障碍。

目前产品团队也在准备未来推出一个单副本版本(对资源要求很低)供大家了解OceanBase的功能(主要是多租户、SQL及其兼容性方面)。此外，听说OceanBase 2.x版本(包括OCP)近期就会通过新官网提供下载。敬请关注。

在POC中，如果前期测试需求对性能很关注，那么用于POC的机器资源就要尽可能符合OB要求。最低的要求简单描述就是内存不少于256G，32CPU，SSD盘，容量不要低于1T，万兆网卡。

实际经验表明，当机器资源能力一再低于这个标准时，为后期的性能测试分析增加很多不必要的麻烦。曾有客户把应用服务器用于分布式数据库选型，SATA盘。结果所有厂商的数据库性能瓶颈都在IO上。客户想的是在同等硬件条件下看哪个数据库性能更好。

磁盘对数据库的影响具体就体现在数据的随机读写和事务日志的顺序写环节。通常生产环境要将带来随机读写的请求占总请求的比例控制在很低范围。为0不现实，很高也不合理(表明数据库资源不足或者SQL不够优化)。如果磁盘很差，即使这个比例很小也会拖累数据库的性能，就达不到POC的目的。目前OceanBase的能力也不是在低配服务器上发挥更好的性能。

所以，当测试需求确定测试性能时，就应该尽可能准备匹配测试需求的机器环境。否则这个差距一定会以另外一种负面形式(如效率成本方面)体现。

在环境准备中，操作系统的Yum源也很重要。OCP的安装也考虑过将所有依赖的rpm包都打包到安装文件中，但实际由于客户的OS类型和版本各不相同，安装本地的rpm包很容易跟客户现有OS里的版本冲突，引来更多问题。所以后期都使用yum安装相应的包。测试机器除了要尽可能统一OS的版本，还需要提供一个版本匹配的Yum源。并且OS在安装时要尽可能多安装一些基础的RPM。如跟开发语言有关的(gcc、python等)、网络诊断相关的(如telnet)、时间同步相关的(如ntp、ntpdate)等。

时间同步NTP服务器也是很重要的基础设施。在分布式数据库里，各个节点的时间要尽可能的保持一致，误差控制在很小的范围内。需要注意的是时间同步延时跟网络延时是两个概念。跨机房的网络延时可能会有几ms到十几ms，但是使用同一NTP源同步时间时，其时间误差是可以做到1ms以内。如果没有公用的NTP源，则从测试机器里选择一台配置为NTP源。即使如此，机器在交付的时候，其时间也应该做到跟当前时间相差不大，并且时区也正确(默认为东8区)。

还有其他客观因素会影响POC。如网络隔离导致只能在特定机器上操作、网络访问权限、相关文件传输(如安装介质、运行日志)等。

附录

内核参数设置参考

#!/bin/sh

sysctl_config(){
cat >> /etc/sysctl.conf <<EOF
fs.file-max = 655350
fs.aio-max-nr = 3145728

kernel.core_uses_pid = 1
kernel.exec-shield = 1
kernel.msgmax = 65536
kernel.msgmnb = 65536
kernel.randomize_va_space = 1
kernel.sem = 250 32000 100 128
kernel.shmall = 4294967296
kernel.shmmax = 68719476736
kernel.sysrq = 0

net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.core.netdev_max_backlog = 10000
net.core.rmem_default = 262144
net.core.rmem_max = 16777216
net.core.somaxconn = 2048
net.core.wmem_default = 262144
net.core.wmem_max = 16777216
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route =  0
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.ip_forward = 0
net.ipv4.ip_local_port_range = 40000 65535
net.ipv4.tcp_fin_timeout = 5
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_mem = 8388608 12582912 16777216
net.ipv4.tcp_rmem = 8192 87380 16777216
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_wmem = 8192 65536 16777216
net.netfilter.nf_conntrack_max = 1200000
net.nf_conntrack_max = 1200000

vm.mmap_min_addr = 4096
vm.min_free_kbytes = 398520
vm.swappiness = 0
fs.bio_netoops = 0
EOF
}

ulimit参数设置

主要设置OS用户能使用的资源限制

#!/bin/sh

ulimit_config(){
cat >> /etc/security/limits.conf <<EOF
* soft nofile 655360
* hard nofile 655360
* soft nproc 655360
* hard nproc 655360
* soft stack unlimited
* hard stack unlimited
EOF
rm -f  /etc/security/limits.d/90-nproc.conf
#rh6引入了这个配置,且优先级最高,影响nproc.直接删除即可
}

grub设置

主要是设置IO调度算法、关闭NUMA等。

#!/bin/sh

grub_config(){
#要是系统配置工具,都像grubby这么透明就好了.....
        grubby --grub --update-kernel=ALL --args="numa=off"
        grubby --grub --update-kernel=ALL --args="elevator=deadline"
### disable CPU C-stat for low-lantency IO/SSD
#判断是2.6.32kernel则运行
#grubby --grub --update-kernel=ALL --args="processor.max_cstate=0"
if is_rhel 6 ; then
                grubby --grub --update-kernel=ALL --args="intel_idle.max_cstate=0"
fi
}

OceanBase POC机器最低配置

以下配置实际项目里可能有调整。

• 分布式数据库选型测试(一)——测试需求

• OceanBase数据库实践入门——手动搭建OceanBase集群

• OceanBase一体机和云栖大会OB体验介绍

• 蚂蚁社招通道启动中，OB求贤若渴，欢迎推荐

• OceanBase资料大汇总(20190720)