Greenplum集群部署和架构优化，我总结了5000字的心得

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

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

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基准下的基准测试表现：

很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。

将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。

当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。

什么是Microsoft集群服务器

MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。

这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。

MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。

在集群服务器上的SQL Server

SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。

SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”

注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。

单个的大的SQL Server集群还是小的集群

下面是大的、由更多的节点组成的集群的优点：

◆更高的可用新(更多的节点来灾难恢复)。

◆更多的负载均衡选择(更多的节点)。

◆更低廉的维护成本。

◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。

◆增强的管理性和简化环境(需要管理的少了)。

◆更少的停机时间(灾难恢复更多的选择)。

◆灾难恢复性能不受集群中的节点数目影响。

下面是单个大的集群的缺点：

◆集群节点数目有限(如果需要第9个节点怎么办)。

◆在集群中SQL实例数目有限。

◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。

◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。

虚拟化和集群

虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。

在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。

集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。

CoreOS集群的架设比架设一个传统服务器集群更加容易。一方面因为 CoreOS 使用了 Cloud-init 自动化了集群信息的配置，另一方面则是受益于 etcd 分布式存储实现的消息分发和服务器自发现机制。这些便利性正是 CoreOS 系统设计充分为集群架构考虑带来的效率提升。

安装 CoreOS

CoreOS 的安装方法和传统 Linux 系统有很大的不同。鉴于是基础教程，在这一篇中，我们会使用官方的Vagrant镜像一步一步的构建CoreOS的VirtualBox虚拟机集群。本文使用了Linux/Mac作为测试环境，Vagrant从16版已经支持Windows，但需要安装Putty作为登录工具，略有不同，具体使用方法见 链接。  

需要顺带说明一点，比较仔细的使用者可能已经发现官方提供的镜像中有一个是“ ISO镜像文件”，然而这个镜像实际上只是一个 Live CD，也就免安装的试用镜像，直接使用这个ISO启动的系统是不具备服务自发现和分布式消息分发的能力的。通过ISO镜像安装集群的方式我们会放到专题篇的内容里面详述。好，现在进入正题吧。

正如系列的第一篇所提到的，Cloud-init 通常依赖于具体平台的实现定制，将其直接在物理机上使用并不是主流的使用方法。对于这种安装方法， 官方有一篇文档提供了详细的步骤，这里不再进行详细讨论。

首先来看一下 CoreOS 原生支持的平台。截止到目前，最新版本的CoreOS v540已经支持的平台如下图。

可以看到除去安装到本地的 Bare Metal，其余基本是针对主流的云服务平台定制的版本。这里的定制主要是 Cloud-init 等启动服务的配置，那么如何知道 CoreOS 已经支持自动化的集群部署的平台有哪些呢？我们可以从 CoreOS 源代码的 coreos-base 目录里得到答案。

这些 oem 开头的目录就是平台定制的实现。其中每个目录中的 files/cloud-configyml 文件，就是 Cloud-init 的配置文件。在每一种平台安装 CoreOS 的方式各有不同，可以从官方网站相应的页面找到相应步骤。这里我们选择其中的 Vagrant 作为演示的目标平台。

在 Vagrant 上部署 CoreOS 集群

使用 Vagrant 建立 CoreOS 集群可以说是最简单且经济的方式了，使用本地虚拟机构建，特别适合快速验证 CoreOS 的功能。

预备

需要准备的东西，包括一台连接到互联网的 Mac 或者桌面 Linux 电脑，安装好 Git、VirtualBox 和 Vagrant。

通过 Git 下载官方的 Vagrant 仓库：

git clone https://githubcom/coreos/coreos-vagrantgit

下载完成后，我们接下来配置 CoreOS 集群。

配置

为了使用集群服务器的自发现功能，我们需要一个能用来唯一标识一个集群并提供集群信息的地址。CoreOS 官方提供了这个服务，当然我们也可以使用自己搭建的私有集群标识服务器。鉴于搭建私有标识服务器属于比较进阶的内容，我们会在这个系列的后续文章详述。

通过浏览器或命令行 curl 访问地址 https://discoveryetcdio/new可以得到一个新的集群标识 URL（如果是在Windows下，可以直接使用浏览器访问这个URL地址），这个 URL 会在配置 user-data 时候使用到。

curl https://discoveryetcdio/new

进入 coreos-vagrant 目录，将 user-datasample 和 configrbsample 两个文件各备份一份，并去掉 sample 后缀。得到 user-data 和 configrb 文件。

首先修改 user-data 文件，它将作为启动的配置文件提供给 CoreOS 操作系统。值得一提的是，在这个配置中，可以使用两个变量 $private_ipv4 和 $public_ipv4，它们会在实际运行的时候被自动替换为主机的真实外网 IP 和内网 IP 地址。

这里我们需要做的只是将其中 discovery所在行前面的注释符合“#”去掉，然后替换它的值为我们刚刚获得的集群标识 URL 地址。简单来说，所有使用了同一个标识 URL 的主机实例都会在 CoreOS 启动时自动加入到同一个集群中，这就实现了无需人工干预的集群服务器自发现。

#cloud-config 

coreos: 

  etcd: 

    # generate a new token for each unique cluster from https://discoveryetcdio/new 

    # WARNING: replace each time you 'vagrant destroy' 

    discovery: <集群标识URL地址> 

    addr: $public_ipv4:4001 

peer-addr: $public_ipv4:7001 

然后修改 configrb 文件，这里包含了 Vagrant 虚拟机的配置。通过这个文件实际上可以覆写任何 Vagrantfile 里的参数，但是目前我们只需要关注 $num_instances 和 $update_channel 这两个参数的值。

$num_instances 表示将启动的 CoreOS 集群中需要包含主机实例的数量； $update_channel 表示启动的 CoreOS 实例使用的升级通道，可以是 ‘stable’，’beta’ 或 ‘alpha’。

$num_instances=3 

$update_channel='stable'

CoreOS 没有跨越式的版本发布，而是使用与 Arch Linux 类似的平滑的滚动升级，确保用户任何时候下载到的版本都是最新发布的系统镜像，并且从根本上解决了服务器系统在运行几年后，由于无法平滑升级而被迫重新安装的情况。此外 CoreOS 提供了 Stable、Beta 和 Alpha 三种升级通道，用于满足不同用户对系统新特性和稳定性的平衡。关于升级通道的切换，可参考官方的文档。

启动

启动集群，执行：

vagrant up

查看集群运行状态，所有的集群实例都已经启动。

vagrant up 

Current machine states: 

core-01                   running (virtualbox) 

core-02                   running (virtualbox) 

core-03                   running (virtualbox)

此时，在 CoreOS 集群的内部正发生着许多故事，集群的实例之间通过自发现服务，相互认识了对方并建立了联系。它们具备了在集群中任意一个实例节点控制整个集群的能力。是的，一个功能完备的 CoreOS 服务器集群已经完全运行起来了。

我现在使用的是小鸟云，他们目前官网有活动，3折优惠，建议去看看！