⑩ OpenStack高可用集群部署方案(train版)—OpenStack对接Ceph存储

参考Ceph官方安装文档

Openstack环境中，数据存储可分为临时性存储与永久性存储。

临时性存储：主要由本地文件系统提供，并主要用于nova虚拟机的本地系统与临时数据盘，以及存储glance上传的系统镜像；

永久性存储：主要由cinder提供的块存储与swift提供的对象存储构成，以cinder提供的块存储应用最为广泛，块存储通常以云盘的形式挂载到虚拟机中使用。

Openstack中需要进行数据存储的三大项目主要是nova项目（虚拟机镜像文件），glance项目（共用模版镜像）与cinder项目（块存储）。

下图为cinder，glance与nova访问ceph集群的逻辑图：

ceph与openstack集成主要用到ceph的rbd服务，ceph底层为rados存储集群，ceph通过librados库实现对底层rados的访问；

openstack各项目客户端调用librbd，再由librbd调用librados访问底层rados；

实际使用中，nova需要使用libvirtdriver驱动以通过libvirt与qemu调用librbd；cinder与glance可直接调用librbd；

写入ceph集群的数据被条带切分成多个object，object通过hash函数映射到pg（构成pg容器池pool），然后pg通过几圈crush算法近似均匀地映射到物理存储设备osd（osd是基于文件系统的物理存储设备，如xfs，ext4等）。

CEPH PG数量设置与详细介绍

在创建池之前要设置一下每个OSD的最大PG 数量

PG PGP官方计算公式计算器

参数解释：

依据参数使用公式计算新的 PG 的数目:

PG 总数= ((OSD总数100)/最大副本数)/池数

3x100/3/3=3333 ;舍入到2的N次幕为32

openstack集群作为ceph的客户端；下面需要再openstack集群上进行ceph客户端的环境配置

在openstack所有控制和计算节点安装ceph Octopus源码包，centos8有默认安装，但是版本一定要跟连接的ceph版本一致

glance-api 服务运行在3个控制节点， 因此三台控制节点都必须安装

cinder-volume 与 nova-compute 服务运行在3个计算（存储）节点； 因此三台计算节点都必须安装

将配置文件和密钥复制到openstack集群各节点

配置文件就是生成的cephconf；而密钥是 cephclientadminkeyring ，当使用ceph客户端连接至ceph集群时需要使用的密默认密钥，这里我们所有节点都要复制，命令如下

※Glance 作为openstack中镜像服务，支持多种适配器，支持将镜像存放到本地文件系统，http服务器，ceph分布式文件系统，glusterfs和sleepdog等开源的分布式文件系统上。目前glance采用的是本地filesystem的方式存储，存放在默认的路径 /var/lib/glance/images 下，当把本地的文件系统修改为分布式的文件系统ceph之后，原本在系统中镜像将无法使用，所以建议当前的镜像删除，部署好ceph之后，再统一上传至ceph中存储。

※Nova 负责虚拟机的生命周期管理，包括创建，删除，重建，开机，关机，重启，快照等，作为openstack的核心，nova负责IaaS中计算重要的职责，其中nova的存储格外重要，默认情况下，nova将instance的数据存放在/var/lib/nova/instances/%UUID目录下，使用本地的存储空间。使用这种方式带来的好处是:简单，易实现，速度快，故障域在一个可控制的范围内。然而，缺点也非常明显：compute出故障，上面的虚拟机down机时间长，没法快速恢复，此外，一些特性如热迁移live-migration,虚拟机容灾nova evacuate等高级特性，将无法使用，对于后期的云平台建设，有明显的缺陷。对接 Ceph 主要是希望将实例的系统磁盘文件储存到 Ceph 集群中。与其说是对接 Nova，更准确来说是对接 QEMU-KVM/libvirt，因为 librbd 早已原生集成到其中。

※Cinder 为 OpenStack 提供卷服务，支持非常广泛的后端存储类型。对接 Ceph 后，Cinder 创建的 Volume 本质就是 Ceph RBD 的块设备，当 Volume 被虚拟机挂载后，Libvirt 会以 rbd 协议的方式使用这些 Disk 设备。除了 cinder-volume 之后，Cinder 的 Backup 服务也可以对接 Ceph，将备份的 Image 以对象或块设备的形式上传到 Ceph 集群。

使用ceph的rbd接口，需要通过libvirt，所以需要在客户端机器上安装libvirt和qemu，关于ceph和openstack结合的结构如下，同时，在openstack中，需要用到存储的地方有三个:

为 Glance、Nova、Cinder 创建专用的RBD Pools池

需要配置hosts解析文件，这里最开始已经配置完成，如未添加hosts解析需要进行配置

在cephnode01管理节点上操作 ；命名为：volumes，vms，images

记录：删除存储池的操作

在cephnode01管理节点上操作 ；

针对pool设置权限，pool名对应创建的pool

nova-compute与cinder-volume都部署在计算节点 ，不必重复操作,如果计算节点与存储节点分离需要分别推送；

全部计算节点配置；以compute01节点为例；

Glance 为 OpenStack 提供镜像及其元数据注册服务，Glance 支持对接多种后端存储。与 Ceph 完成对接后，Glance 上传的 Image 会作为块设备储存在 Ceph 集群中。新版本的 Glance 也开始支持 enabled_backends 了，可以同时对接多个存储提供商。

写时复制技术(copy-on-write) ：内核只为新生成的子进程创建虚拟空间结构，它们复制于父进程的虚拟空间结构，但是不为这些段分配物理内存，它们共享父进程的物理空间，当父子进程中有更改相应的段的行为发生时，再为子进程相应的段分配物理空间。写时复制技术大大降低了进程对资源的浪费。

全部控制节点进行配置；以controller01节点为例；

只修改涉及glance集成ceph的相关配置

变更配置文件，重启服务

ceph官网介绍 QEMU和块设备

对接 Ceph 之后，通常会以 RAW 格式创建 Glance Image，而不再使用 QCOW2 格式，否则创建虚拟机时需要进行镜像复制，没有利用 Ceph RBD COW 的优秀特性。

总结

将openstack集群中的glance镜像的数据存储到ceph中是一种非常好的解决方案，既能够保障镜像数据的安全性，同时glance和nova在同个存储池中，能够基于copy-on-write(写时复制)的方式快速创建虚拟机，能够在秒级为单位实现vm的创建。

全部计算节点进行配置； 以compute01节点为例；只修改glance集成ceph的相关配置

全部计算节点重启cinder-volume服务；

任意openstack控制节点上查看;

在任意控制节点为cinder的ceph后端存储创建对应的type，在配置多存储后端时可区分类型；

为ceph type设置扩展规格，键值 volume_backend_name ，value值 ceph

任意控制节点上创建一个1GB的卷 ；最后的数字1代表容量为1G

查看创建好的卷

openstack创建一个空白 Volume，Ceph相当于执行了以下指令

从镜像创建 Volume 的时候应用了 Ceph RBD COW Clone 功能，这是通过 glance-apiconf [DEFAULT] show_image_direct_url = True 来开启。这个配置项的作用是持久化 Image 的 location，此时 Glance RBD Driver 才可以通过 Image location 执行 Clone 操作。并且还会根据指定的 Volume Size 来调整 RBD Image 的 Size。

一直存在的cirros_qcow2镜像为对接ceph之前的镜像，现在已无法使用，所以将之删除

在openstack上从镜像创建一个Volume，Ceph相当于执行了以下指令

任意控制节点操作；

查看快照详细信息

在openstack上对镜像的卷创建快照，Ceph相当于执行了以下指令

如果说快照时一个时间机器，那么备份就是一个异地的时间机器，它具有容灾的含义。所以一般来说 Ceph Pool backup 应该与 Pool images、volumes 以及 vms 处于不同的灾备隔离域。

https://wwwcnblogscom/luohaixian/p/9344803html

https://docsopenstackorg/zh_CN/user-guide/backup-db-incrementalhtml

一般的，备份具有以下类型：

在虚拟磁盘映像的计算节点上使用本地存储有一些缺点：

Nova 为 OpenStack 提供计算服务，对接 Ceph 主要是希望将实例的系统磁盘文件储存到 Ceph 集群中。与其说是对接 Nova，更准确来说是对接 QEMU-KVM/libvirt ，因为 librbd 早已原生集成到其中。

如果需要从ceph rbd中启动虚拟机，必须将ceph配置为nova的临时后端；

推荐在计算节点的配置文件中启用rbd cache功能；

为了便于故障排查，配置admin socket参数，这样每个使用ceph rbd的虚拟机都有1个socket将有利于虚拟机性能分析与故障解决；

相关配置只涉及全部计算节点cephconf文件的[client]与[clientcinder]字段，以compute163节点为例

全部计算节点配置 cephconf文件相关的 [client] 与 [clientcinder] 字段，以compute01节点为例；

在全部计算节点配置nova后端使用ceph集群的vms池，以compute01节点为例；

在全部计算节点操作;

在全部计算节点操作，以compute01节点为例；

以下给出libvirtdconf文件的修改处所在的行num

最近对离线数仓体系进行了扩容和架构改造，也算是一波三折，出了很多小插曲，有一些改进点对我们来说也是真空地带，通过对比和模拟压测总算是得到了预期的结果，这方面尤其值得一提的是郭运凯同学的敬业，很多前置的工作，优化和应用压测的工作都是他完成的。 

整体来说，整个事情的背景是因为服务器硬件过保，刚好借着过保服务器替换的机会来做集群架构的优化和改造。 

1集群架构改造的目标

在之前也总结过目前存在的一些潜在问题，也是本次部署架构改进的目标：

1）之前 的GP segment数量设计过度 ，因为资源限制，过多考虑了功能和性能，对于集群的稳定性和资源平衡性考虑有所欠缺，在每个物理机节点上部署了10个Primary,10个Mirror，一旦1个服务器节点不可用，整个集群几乎无法支撑业务。

2）GP集群 的存储资源和性能的平衡不够 ，GP存储基于RAID-5,如果出现坏盘，磁盘重构的代价比较高，而且重构期间如果再出现坏盘，就会非常被动，而且对于离线数仓的数据质量要求较高，存储容量相对不是很大，所以在存储容量和性能的综合之上，我们选择了RAID-10。

3)集 群的异常场景的恢复需要完善， 集群在异常情况下（如服务器异常宕机，数据节点不可用，服务器后续过保实现节点滚动替换）的故障恢复场景测试不够充分，导致在一些迁移和改造中，相对底气不足，存在一些知识盲区。

4）集群版本过 低 ，功能和性能上存在改进空间。毕竟这个集群是4年前的版本，底层的PG节点的版本也比较旧了，在功能上和性能上都有一定的期望，至少能够与时俱进。

5）操作系统版本升 级 ，之前的操作系统是基于CentOS6，至少需要适配CentOS 7 。

6）集群TPCH 压测验收 ，集群在完成部署之后，需要做一次整体的TPCH压测验收，如果存在明显的问题需要不断调整配置和架构，使得达到预期的性能目标。

此外在应用层面也有一些考虑，总而言之，是希望能够解决绝大多数的痛点问题，无论是在系统层面，还是应用层面，都能上一个台阶。

2集群规划设计的选型和思考

明确了目标，就是拆分任务来规划设计了，在规划设计方面主要有如下的几个问题：

1）Greenplum的版本选择 ，目前有两个主要的版本类别，一个是开源版（Open Source distribution）和Pivotal官方版，它们的其中一个差异就是官方版需要注册，签署协议，在此基础上还有GPCC等工具可以用，而开源版本可以实现源码编译或者rpm安装，无法配置GPCC。综合来看，我们选择了 开源版本的6162 ，这其中也询问了一些行业朋友，特意选择了几个涉及稳定性bug修复的版本。

2）数据集市的技术选型 ，在数据集市的技术选型方面起初我是比较坚持基于PostgreSQL的模式，而业务侧是希望对于一些较为复杂的逻辑能够通过GP去支撑，一来二去之后，加上我咨询了一些行业朋友的意见，是可以选择基于GP的方案，于是我们就抱着试一试的方式做了压测，所以数据仓库和和数据集市会是两个不同规模体量的GP集群来支撑。

3）GP的容量规划 ，因为之前的节点设计有些过度，所以在数量上我们做了缩减，每台服务器部署12个segment节点，比如一共12台服务器，其中有10台服务器是Segment节点，每台上面部署了6个Primary,6个Mirror，另外2台部署了Master和Standby，就是即（6+6）10+2，整体的配置情况类似下面的模式。

4）部署架构方案选型 ，部署架构想起来比较容易，但是落实起来有很多的考虑细节，起初考虑GP的Master和Standby节点如果混用还是能够节省一些资源，所以设计的数据仓库和数据集市的部署架构是这样考虑的，但是从走入部署阶段之后，很快就发现这种交叉部署的模式是不可行的，或者说有一些复杂度。

除此之外，在单个GP集群的部署架构层面，还有4类方案考虑。

  方案1 ：Master,Standby和segment混合部署

  方案2 ：Master,Standby和segment独立部署，整个集群的节点数会少一些

  方案3 ：Segment独立部署，Master,Standby虚拟机部署

  方案4 ：最小化单节点集群部署（这是数据集市最保底的方案）  

这方面存在较大的发挥空间，而且总体来说这种验证磨合的成本也相对比较高，实践给我上了一课， 越是想走捷径，越是会让你走一些弯路 ，而且有些时候的优化其实我也不知道改怎么往下走，感觉已经无路可走，所以上面这4种方案其实我们都做了相关的测试和验证。

3集群架构的详细设计和实践

1）设计详细的部署架构图

在整体规划之上，我设计了如下的部署架构图，每个服务器节点有6个Primary,6个Mirror,服务器两两映射。

2）内核参数优化

按照官方文档的建议和具体的配置情况，我们对内核参数做了如下的配置：

vmswappiness=10

vmzone_reclaim_mode = 0

vmdirty_expire_centisecs = 500

vmdirty_writeback_centisecs = 100

vmdirty_background_ratio = 0 # See System Memory

vmdirty_ratio = 0

vmdirty_background_bytes = 1610612736

vmdirty_bytes = 4294967296

vmmin_free_kbytes = 3943084

vmovercommit_memory=2

kernelsem = 500 2048000 200 4096

4集群部署步骤

1）首先是配置/etc/hosts，需要把所有节点的IP和主机名都整理出来。 

2）配置用户，很常规的步骤

groupadd  gpadmin

useradd gpadmin -g gpadmin

passwd gpadmin

3）配置sysctlconf和资源配置

4）使用rpm模式安装

# yum install -y apr apr-util bzip2 krb5-devel  zip

# rpm -ivh open-source-greenplum-db-6162-rhel7-x86_64rpm

5）配置两个host文件，也是为了后面进行统一部署方便，在此建议先开启gpadmin的sudo权限，可以通过gpssh处理一些较为复杂的批量操作

6）通过gpssh-exkeys来打通ssh信任关系，这里需要吐槽这个ssh互信，端口还得是22，否则处理起来很麻烦,需要修改/etc/ssh/sshd_config文件

gpssh-exkeys -f hostlist

7）较为复杂的一步是打包master的Greenplum-db-6162软件，然后分发到各个segment机器中，整个过程涉及文件打包，批量传输和配置，可以借助gpscp和gpssh，比如gpscp传输文件，如下的命令会传输到/tmp目录下

gpscp -f /usr/local/greenplum-db/conf/hostlist /tmp/greenplum-db-6162targz =:/tmp

或者说在每台服务器上面直接rpm -ivh安装也可以。

8）Master节点需要单独配置相关的目录，而Segment节点的目录可以提前规划好，比如我们把Primary和Mirror放在不同的分区。 

mkdir -p /data1/gpdata/gpdatap1

mkdir -p /data1/gpdata/gpdatap2

mkdir -p /data2/gpdata/gpdatam1

mkdir -p /data2/gpdata/gpdatam2

9）整个过程里最关键的就是gpinitsystem_config配置了，因为Segment节点的ID配置和命名，端口区间都是根据一定的规则来动态生成的，所以对于目录的配置需要额外注意。

10）部署GP集群最关键的命令是

gpinitsystem -c gpinitsystem_config -s standby_hostname

其中文件gpinitsystem_config的主要内容如下：

MASTER_HOSTNAME=xxxx

declare -a DATA_DIRECTORY=(/data1/gpdata/gpdatap1  /data1/gpdata/gpdatap2 /data1/gpdata/gpdatap3 /data1/gpdata/gpdatap4 /data1/gpdata/gpdatap5 /data1/gpdata/gpdatap6)

TRUSTED_SHELL=ssh

declare -a MIRROR_DATA_DIRECTORY=(/data2/gpdata/gpdatam1  /data2/gpdata/gpdatam2 /data2/gpdata/gpdatam3 /data2/gpdata/gpdatam4 /data2/gpdata/gpdatam5 /data2/gpdata/gpdatam6)

MACHINE_LIST_FILE=/usr/local/greenplum-db/conf/seg_hosts

整个过程大约5分钟~10分钟以内会完成，在部署过程中建议要查看后端的日志查看是否有异常，异常情况下的体验不是很好，可能会白等。

5集群部署问题梳理

集群部署中还是有很多细节的问题，太基础的就不提了，基本上就是配置，目录权限等问题，我提另外几个：

1） 资源配置问题 ，如果/etc/security/limitsconf的资源配置不足会在安装时有如下的警告：

2） 网络问题 ，集群部署完成后可以正常操作，但是在查询数据的时候会抛出错误，比如SQL是这样的，看起来很简单：select count() from customer,但是会抛出如下的错误：

这个问题的主要原因还是和防火墙配置相关，其实不光需要配置INPUT的权限，还需要配置OUTPUT的权限。 

对于数据节点可以开放略大的权限，如：

入口的配置：

-A INPUT -p all -s xxxxx    -j ACCEPT

出口的配置：

-A OUTPUT -p all -s xxxxx    -j ACCEPT

3）网络配置问题 ，这个问题比较诡异的是，报错和上面是一样的，但是在排除了防火墙配置后，select count() from customer；这样的语句是可以执行的，但是执行的等待时间较长，比如表lineitem这表比较大，过亿的数据量，,在10个物理节点时，查询响应时间是10秒，但是4个物理节点，查询响应时间是在90秒，总体删感觉说不过去。

为了排查网络问题，使用gpcheckperf等工具也做过测试，4节点和10节点的基础配置也是相同的。

gpcheckperf -f /usr/local/greenplum-db/conf/seg_hosts -r N -d /tmp

$ cat /etc/hosts

127001   localhost localhostlocaldomain localhost4 localhost4localdomain4

::1      localhost localhostlocaldomain localhost6 localhost6localdomain6

#127001    test-dbs-gp-128-230

xxxxx128238 test-dbs-gp-svr-128-238

xxxxx128239 test-dbs-gp-svr-128-239

其中127001的这个配置在segment和Master,Standby混部的情况是存在问题的，修正后就没问题了，这个关键的问题也是郭运凯同学发现的。

5集群故障恢复的测试

集群的故障测试是本次架构设计中的重点内容，所以这一块也是跃跃欲试。

整体上我们包含两个场景，服务器宕机修复后的集群恢复和服务器不可用时的恢复方式。

第一种场景相对比较简单，就是让Segment节点重新加入集群，并且在集群层面将Primary和Mirror的角色互换，而第二种场景相对时间较长一些，主要原因是需要重构数据节点，这个代价基本就就是PG层面的数据恢复了，为了整个测试和恢复能够完整模拟，我们采用了类似的恢复方式，比如宕机修复使用了服务器重启来替代，而服务器不可用则使用了清理数据目录，类似于一台新配置机器的模式。

1）服务器宕机修复后集群恢复

select from gp_segment_configuration where status!='u';

gprecoverseg  -o /recov

gprecoverseg -r

select from gp_segment_configuration where status='u'

2）服务器不可用时集群恢复

重构数据节点的过程中，总体来看网络带宽还是使用很充分的。

select from gp_segment_configuration where status='u'

select from gp_segment_configuration where status='u' and role!=preferred_role;

gprecoverseg -r

select from gp_segment_configuration where status='u' and role!=preferred_role;

经过测试，重启节点到数据修复，近50G数据耗时3分钟左右

6集群优化问题梳理

1）部署架构优化和迭代

对于优化问题，是本次测试中尤其关注，而且争议较多的部分。 

首先在做完初步选型后，数仓体系的部署相对是比较顺利的，采用的是第一套方案。

数据集市的集群部分因为节点相对较少，所以就选用了第二套方案

实际测试的过程，因为配置问题导致TPCH的结果没有达到预期。

所以这个阶段也产生了一些疑问和怀疑，一种就是折回第一种方案，但是节点数会少很多，要不就是第三种采用虚拟机的模式部署，最保底的方案则是单节点部署，当然这是最牵强的方案。

这个阶段确实很难，而在上面提到的修复了配置之后，集群好像突然开悟了一般，性能表现不错，很快就完成了100G和1T数据量的TPCH测试。

在后续的改造中，我们也尝试了第三套方案，基于虚拟机的模式，通过测试发现，远没有我们预期的那么理想，在同样的数据节点下，Master和Standby采用物理机和虚拟机，性能差异非常大，这个是出乎我们预料的。比如同样的SQL,方案3执行需要2秒，而方案2则需要80秒，这个差异我们对比了很多指标，最后我个人理解差异还是在网卡部分。

所以经过对比后，还是选择了方案2的混合部署模式。

2）SQL性能优化的分析

此外整个过程的TPCH也为集群的性能表现提供了参考。比如方案2的混合部署模式下，有一条SQL需要18秒，但是相比同类型的集群，可能就只需要2秒钟左右，这块显然是存在问题的。 

在排除了系统配置，硬件配置的差异之后，经典的解决办法还是查看执行计划。

性能较差的SQL执行计划：

# explain analyze select count()from customer;

QUERY PLAN   

Aggregate  (cost=00043100 rows=1 width=8) (actual time=2479291624792916 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=00043100 rows=1 width=1) (actual time=325516489394 rows=150000000 loops=1)

         ->  Seq Scan on customer  (cost=00043100 rows=1 width=1) (actual time=07801267878 rows=4172607 loops=1)

Planning time: 4466 ms

   (slice0)    Executor memory: 680K bytes

   (slice1)    Executor memory: 218K bytes avg x 36 workers, 218K bytes max (seg0)

Memory used:  2457600kB

Optimizer: Pivotal Optimizer (GPORCA)

Execution time: 24832611 ms

(9 rows)

Time: 24892500 ms

性能较好的SQL执行计划：

# explain analyze select count()from customer;                            

QUERY PLAN

Aggregate  (cost=00084208 rows=1 width=8) (actual time=15193111519311 rows=1 loops=1)

   ->  Gather Motion 36:1  (slice1; segments: 36)  (cost=00084208 rows=1 width=8) (actual time=6347871519214 rows=36 loops=1)

         ->  Aggregate  (cost=00084208 rows=1 width=8) (actual time=14732961473296 rows=1 loops=1)

               ->  Seq Scan on customer  (cost=00083433 rows=4166667 width=1) (actual time=0758438319 rows=4172607 loops=1)

Planning time: 5033 ms

   (slice0)    Executor memory: 176K bytes

   (slice1)    Executor memory: 234K bytes avg x 36 workers, 234K bytes max (seg0)

Memory used:  2457600kB

Optimizer: Pivotal Optimizer (GPORCA)

Execution time: 1543611 ms

(10 rows)

Time: 1549324 ms

很明显执行计划是被误导了，而误导的因素则是基于统计信息，这个问题的修复很简单：

analyze customer;

但是深究原因，则是在压测时，先是使用了100G压测，压测完之后保留了原来的表结构，直接导入了1T的数据量，导致执行计划这块没有更新。

3）集群配置优化

此外也做了一些集群配置层面的优化，比如对缓存做了调整。 

gpconfig -c statement_mem -m 2457600 -v 2457600

gpconfig -c gp_vmem_protect_limit -m 32000 -v 32000

7集群优化数据

最后来感受下集群的性能：

1）10个物理节点，（6+6）10+2

tpch_1t=# iming on

Timing is on

tpch_1t=# select count()from customer;

   count   

-----------

150000000

(1 row)

Time: 1235801 ms

tpch_1t=# select count()from lineitem;

   count    

------------

5999989709

(1 row)

Time: 10661756 ms

2）6个物理节点，（6+6）6

# select count()from customer;

   count   

-----------

 150000000

(1 row)

Time: 1346833 ms

# select count()from lineitem;

   count    

------------

 5999989709

(1 row)

Time: 18145092 ms

3）4个物理节点，（6+6）4

# select count()from customer;

   count   

-----------

 150000000

(1 row)

Time: 1531621 ms

# select count()from lineitem;

   count    

------------

 5999989709

(1 row)

Time: 25072501 ms

4）TPCH在不通架构模式下的性能比对 ，有19个查询模型，有个别SQL逻辑过于复杂暂时忽略，也是郭运凯同学整理的列表。

在1T基准下的基准测试表现：

把jdk安装到 /home/trs/ 目录下，这里是 /home/trs/jdk170_79

在文件开头增加：

而后执行

使之生效即可。

海贝需要安装在已安装了zookeeper的服务器上，参见 zookeeper集群部署 ，首先部署服务器(101123)：

a 解压安装包

b 把安装包拷贝到解压出来的海贝目录的media目录中作为自动部署的介质：

c 启动海贝单节点

d 自动部署其他节点

使用浏览器登录海贝，海贝地址为： http://ip:5555 默认账号：admin/trsadmin，首次登录后会提示修改密码

菜单-节点管理-自动部署

f 启动海贝集群

理论上讲是可以通过启动每个节点来启动海贝集群的，但是亲测这样启动有时候会有各种乱七八糟的同步问题，所以建议使用统一启动的方式，即执行：

关于此脚本的具体信息参见后面的批量自动更新内容。

启动成功后，可以在海贝的节点管理中看到状态：

具体为：

a 配置无密码登录

安装expect： # yum -y install expect

bin/nodes 存放IP地址列表，一行一个IP

b 批量更新

更新文件(lib webpages trshybase-jar)的存放位置update目录（将更新包TRSHybase-server-update-targz解压缩到update目录即可）

确保bin/nodes（或者在conf/nodes）里面有所有服务器的列表（一行一个）

执行 sbin/update_allsh ，会自动执行批量关闭/更新/批量启动。

通过以上信息可知，其实这个 update_allsh 的脚本，是可以实现全库批量关闭和启动的，因此只要update目录中不放文件，执行该脚本，就可以实现批量关闭/启动海贝集群

当然，修改该脚本，把update相关的内容删除，改造一个专门的启停脚本也可以。

a Hybase节点对内存有较大的需求，因此建议用户使用多核、大内存的服务器（标配32G，推荐128G）

b 集群在部署以后，应当修改conf/hybase-envsh，增加Hybase可用的内存

c 分配规则可以参考：留50%给操作系统，其余都给Hybase进程

例如32G内存，留16G给操作系统，16G给hybase。那么需要修改conf/hybase-envsh，找到HYBASE_OPTS配置项，修改成：

硬件配置范例：

网络服务器 两台

服务器操作系统硬盘 两块

服务器数据存贮硬盘 视用户需要确定

服务器镜像卡（部分软件可使用标准网卡） 两块

网络服务网卡 两块三、双机与磁盘阵列柜

集群的软件配置

基于NT平台的集群软件

Microsoft的MSCS，也有许多第三方的专业软件公司开发的集群软件，如豪威的DATAWARE，VIN CA公司的STANDBY SERVER，NSI公司的DOUBLE-TAKE

MS WolfPack的特点

MS WolfPack是MS Cluster server的别称，是 微软针对Cluster技术研制开发的双机软件。它集成在NT SERVER上，支持由二台机器组成的双机系统，提供一种高可用且易管理的应用环境。

主要特点：

自动检测和修复服务器或应用程序的错误

可实现对服务器中应用程序的切换

可通过TCP/IP连接各种客户端，如MS-DOS、WINDOWS 3X/9X/NT，Apple Macintosh、UNIX等

生产主机无需人工干涉即可自动恢复数据并接管任务

易管理性：

可自动审核服务器和应用程序的工作状态

可建立高可用性的应用程序、文件共享、打印请求等

可灵活设置应用程序和数据的恢复策略

简单操作即可进行应用程序的离线，重新再线，服务器间的迁移。

目前，WINDOWS 2000 Advanced Server与WINDOWS 2000 DataCenter Server都集成有更先进集群技术。

其它的网络操作系统平台上也有许多集群软件，比如：

基于novell平台的集群软件有Novell HA Server、Novell SFT III

基于sco UNIX平台的集群软件有Sentinel集群软件

基于Linux平台的集群软件有TurboCluster

我帮你搜到的，不知道有用没，嘿嘿

本文不涉及到具体的HAA部署步骤，只是对Uipath相关的Redis集群、高可用方案做一个简单的介绍。

目前官方文档上介绍的的Orchestrator部署方案有三种：

1、单节点orchestrator部署

单节点部署，即是一般的orchestrator部署，这里不做多介绍。

2、多节点部署：其实类似集群（cluster）部署。

每个orchestrator都相当于集群中的一个“节点”（node）,每个节点都提供相同的服务。当有业务请求进来后，由HAA（Redis）进行业务调度，将该请求分配给此刻负载较小的节点来处理，是的每个节点的压力都比较平均。HAA实际上就充当了一个负载均衡器的角色。

由于有多个 Orchestrator 节点可用，因此这能提供更出色的性能并能有效避免故障 - 当一个节点发生故障时，其他节点还可承担负载。它还具有水平可扩展性，因为随着对机器人需求的进一步增长，还可以添加其他节点。但是，不应将此部署模型与[高可用性]混淆，因为单独的 HAA 节点仍为潜在的单点故障。

3、高可用性部署（High Availablity）

高可用性部署具有与多节点部署类似的架构，但与简单的 多节点 Orchestrator 部署 相比，此模型要使用更多资源，且至少需要 3 个 HAA 节点并要满足相应的 硬件和软件要求 。多个Orchestrator和HAA节点，能够在一个节点出现故障的时候，由其他节点承担负载。

Redis实现高可用原理：

1、主从复制数据。（replication）

2、采用哨兵监控数据节点的运行情况，一旦主节点出现问题由从节点顶上继续进行服务。（sentinel）

高可用与Redis集群的区别：

高可用实现的是服务器与业务处理数据的稳定性，降低系统整体故障的概率，提高系统整体的可用性与稳定性；集群则是为了提高系统的性能与线性扩展能力，解决单机的性能瓶颈问题。

在Kafka集群(Cluster)中，一个Kafka节点就是一个Broker，消息由Topic来承载，可以存储在1个或多个Partition中。发布消息的应用为Producer、消费消息的应用为Consumer，多个Consumer可以促成Consumer Group共同消费一个Topic中的消息。

准备3台Debian服务器，并配置好静态IP、主机名

软件版本说明

ZooKeeper节点信息如下，相关部署见 这篇文章

注 ：kafka_212-230tgz 其中212是Scala编译器的版本，230才是Kafka的版本

配置日志目录、指定ZooKeeper服务器

分节点配置

防火墙设置

分别启动Kafka

在kafka01(Broker)上创建测试Tpoic： test-kafka ，这里我们指定了3个副本、1个分区

Topic在kafka01上创建后也会同步到集群中另外两个Broker：kafka02、kafka03

这里我们向Broker(id=0)的Topic=test-kafka发送消息

在Kafka02上消费Broker03的消息

在Kafka03上消费Broker02的消息

然后均能收到消息

这是因为这两个消费消息的命令是建立了两个不同的Consumer。如果我们启动Consumer指定Consumer Group Id就可以作为一个消费组协同工，同一分区同一topic的消息同时只会被消费者组中的一个Consumer消费到

　　一个区域集群包含多个 Oracle Solaris 区域，每个区域分别驻留在其各自独立的服务器上；组成集群的各个区域链接到单个虚拟集群。

　　因为区域集群之间是相互隔离的，所以各区域集群的安全性将得到加强。此外，由于区域是聚集在一起的，所以各区域所承载应用程序的可用性得到了提高。由于一个物理集群上可存在多个区域集群，提供了在一个集群上整合多集群应用程序的方法。

　　在区域集群中安装 Oracle RAC，您就可以为同一数据库创建不同的数据库版本或进行不同的部署(例如，一个用于生产，一个用于开发)。

　　使用此架构，您还可以将多层解决方案的不同部分部署到不同的虚拟区域集群中。例如，您可以将 Oracle RAC 和应用程序服务器部署在同一集群的不同区域中。

　　使用该方法可以在充分利用 Oracle Solaris Cluster 简化管理的同时将层和管理域相互隔离开来。