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

选择GPU服务器时首先要考虑业务需求来选择适合的GPU型号。在HPC高性能计算中还需要根据精度来选择，比如有的高性能计算需要双精度，这时如果使用P40或者P4就不合适，只能使用V100或者P100；同时也会对显存容量有要求，比如石油或石化勘探类的计算应用对显存要求比较高；还有些对总线标准有要求，因此选择GPU型号要先看业务需求。

GPU服务器人工智能领域的应用也比较多。在教学场景中，对GPU虚拟化的要求比较高。根据课堂人数，一个老师可能需要将GPU服务器虚拟出30甚至60个虚拟GPU，因此批量Training对GPU要求比较高，通常用V100做GPU的训练。模型训练完之后需要进行推理，因此推理一般会使用P4或者T4，少部分情况也会用V100。

综上所述，选择服务器时不仅需要考虑业务需求，还要考虑性能指标，比如精度、显存类型、显存容量以及功耗等，同时也会有一些服务器是需要水冷、降噪或者对温度、移动性等等方面有特殊的要求，就需要特殊定制的服务器。

欢迎了解更多：网页链接

最近没怎么更新，事比较多，刚忙完。

使用vsphere也有几年时间了，基本保持每年一次大版本升级，从50版升级到55、60，最近开始部署65，最头疼的问题就是网络规划，这也是vsphere部署的重点。

从传统数据中心转型时，只有4台HP机架式服务器，压根没考虑过网络规划的事，跟原来的服务器混用一个vlan，一个C类地址。这也就造成了以后的各种麻烦，随着服务器的增加，IP不够用，安全性没有保障。

虽然数据中心可以正常运转，但是不合理，趁着规模小，又赶上升级65，正好重新规划一下网络。

根据最佳实践做法，Management、vMotion、vSphereFT、iSCSI等的网络相互隔离，从而提高安全性和性能。同时每个网络建议配置2块物理网卡用作冗余和负载均衡，根据最佳实践可能至少需要6块网卡，多则十几块网卡，这对标配4块网卡的机架式服务器是不现实的。

我的标准配置是4块网卡，vMotion、Management和vSphereFT网络共用2块网卡，生产网络用2块网卡。vSwitch使用access端口，vSphere Distributed Switch使用trunk模式。

vlan20 17220201/24 HP oa、vc、ilo、FC SAN存储等硬件管理地址

vlan21 17220211/24 vcenter、vsphere、vcops、vdp等VMware地址

    1722001/24 vmotion地址

    1722011/24 vSphere FT地址

vlan100 xxxx/24 对外web服务地址

vlan200 xxxx/24 对内业务运维平台地址

vMotion和vSphereFT走二层即可，无需配置路由，在vsphere65版本中可为vMotion配置独立的TCP/IP堆栈。

在vMotion网络配置上犯过一个错误，以前都为vMotion网络配置独立的VMkernel，升级到60的时候发现做到Management里也没问题，就不再为vMotion配置独立地址，在双物理网卡的情况下一般是不会出现问题的，但是当一块物理网卡出现故障时做vMotion操作就会导致单播泛洪。

安全策略:

1 通过三层交换的acl或端口隔离阻止互相访问

2 防火墙上的策略只允许管理员访问管理地址

最佳实践网络拓扑图如下，建议上行端口分布到两台交换机上实现冗余。

其实Linux服务器系统的维护技巧有很多，掌握其中的一些可以帮助用户更加便捷应用，这里就先给大家介绍四大妙招，让新手可以逐渐掌握linux系统维护。

用户要及时拥有最新版本系统

尽管是开源软件，但是Linux服务器的软件包也如同Windwos操作系统的补丁一样在不断的升级。作为Linux服务器软件的升级主要有两个目的：增强软件的功能和解决安全漏洞。

而看是简单的升级，对于新手来讲最新的软件版本与安全漏洞如何找寻？通常情况下，RedHat公司在得到安全漏洞的通知后，会在最短时间内找到相关的解决方案，并在官网上进行公布并连接最新版本的软件包下载地址。所以系统管理员需要关注所用linux系统的网站，以了解软件包最新的版本信息与安全漏洞信息。

创建启动软盘以备不时之需

对于在部署完毕Linux服务器之后，新手最好能够建立一张软盘启动盘，因为一些大型的服务器中仍然留有软驱，在必要时可以通过软驱解决一些复杂的问题。

正是因为软盘启动盘在Linux服务器维护中作用，为此linux系统也提供了许多创建软盘启动盘的方法。如在安装过程中创建软盘启动盘等等。这里对于新手而言最直接的是在一个Windows环境下创建软盘启动盘的方法，由于大部分系统管理员通过一台Windwos操作系统的电脑作为客户端来进行熟练操作。

系统管理员先把Linux安装盘放入到Windwos客户端的光驱中，利用windows操作系统的远程管理进行有效创建RedHat启动盘文件。

  键盘配置

  鼠标配置

同时创建完启动文件之后，从软盘启动的方式跟从光盘启动差不多。但由于Linux引导程序就没有Windows的引导程序那么简便智能，需要用户在引导的过程中，配置指定所采用的键盘与鼠标类型。

合理规划分区 保证性能

对于系统分区来说，Windows操作系统分区规划对于其性能的影响很小，但Linux操作系统的分区规划不同，其对服务器的性能影响很大。作为企业应用的Linux操作系统服务器，某些特殊的目录放置在不同的分区上，有利于提高后续服务器的性能与安全性。

另外，对于用户在交换分区应用上。Linux操作系统下的交换分区如果发现虚拟空间不足影响则会影响应用程序的性能，甚至也会影响到应用程序的安装。此时如果要调整的话，新手会感觉调整起来相当麻烦，所以最好能够在安装部署Linux服务器之间，做到最大程度上的相关分区规划工作。主要是要考虑要把那些目录分别存放到不同的路径上、要设置多大的交换分区空间等等，由于分区设置后，后续调整相对比较复杂。而即使进行调整的话，其性能也没有预计的好。

启动所需服务 关闭不必要服务

和Windwos系统一样，安装Linux操作系统完毕后会自动启动很多服务。而这些服务中有些则是应用程序不需要启动的，一旦启动会带来一定的安全隐患。为此系统管理员在部署完Linux操作系统之后，需要查看其运行的服务。然后根据需要把一些不需要的服务关闭掉。

为此作为新手需要具有能够判断哪些服务是必需的能力，但可以不断通过学习，与资深系统管理员交流获取可以参考的说明，并结合自己的工作经验来进行判断。

linux系统维护对于企业管理员来说最简单不过的IT应用，通过简单的四大应用介绍让新手掌握简单linux系统维护知识，用户在实际应用中根据需要会不断对linux服务器进行有效的升级更新，从而提供更加完善的IT环境。

1 数据中心设计原则

依据数据中心网络安全建设和改造需求，数据中心方案设计将遵循以下原则：

11 网络适应云环境原则

网络的设计要在业务需求的基础上，屏蔽基础网络差异，实现网络资源的池化；根据业务自动按需分配网络资源，有效增强业务系统的灵活性、安全性，降低业务系统部署实施周期和运维成本。

12 高安全强度原则

安全系统应基于等保要求和实际业务需求，部署较为完备的安全防护策略，防止对核心业务系统的非法访问，保护数据的安全传输与存储，设计完善的面向全网的统一安全防护体系。同时，应充分考虑访问流量大、业务丰富、面向公众及虚拟化环境下的安全防护需求，合理设计云计算环境内安全隔离、监测和审计的方案，提出云计算环境安全解决思路。

13 追求架构先进，可靠性强原则

设计中所采用的网络技术架构，需要放眼长远，采用先进的网络技术，顺应当前云网络发展方向，使系统建设具有较长的生命周期，顺应业务的长远发展。同时保证网络系统的可靠性，实现关键业务的双活需求。同时，应为设备和链路提供冗余备份，有效降低故障率，缩短故障修复时间。

14 兼容性和开放性原则

设计中所采用的网络技术，遵守先进性、兼容性、开放性，以保证网络系统的互操作性、可维护性、可扩展性。采用标准网络协议，保证在异构网络中的系统兼容性；网络架构提供标准化接口，便于整体网络的管理对接，实现对网络资源的统一管理。

2 云计算环境下的安全设计

随着目前大量服务区虚拟化技术的应用和云计算技术的普及，在云计算环境下的安全部署日益成为关注的重点问题，也关系到未来数据中心发展趋势。在本设计方案中，建议采用高性能网络安全设备和灵活的虚拟软件安全网关（NFV 网络功能虚拟化）产品组合来进行数据中心云安全设计。在满足多业务的安全需求时，一方面可以通过建设高性能、高可靠、虚拟化的硬件安全资源池，同时集成FW/IPS/LB等多种业务引擎，每个业务可以灵活定义其需要的安全服务类型并通过云管理员分配相应的安全资源，实现对业务流量的安全隔离和防护；另一方面，针对业务主机侧的安全问题，可以通过虚拟软件安全网关实现对主机的安全防护，每个业务可以针对自身拥有的服务器计算资源进行相应的安全防护和加固的工作。其部署示意图如下所示：

21 南北向流量安全防护规划

在云计算数据中心中，针对出入数据中心的流量，我们称之为“南北向流量”。针对南北向流量的安全防护，建议采用基于虚拟化技术的高性能安全网关来实现。

虚拟化技术是实现基于多业务业务隔离的重要方式。和传统厂商的虚拟化实现方式不同，H3C的安全虚拟化是一种基于容器的完全虚拟化技术；每个安全引擎通过唯一的OS内核对系统硬件资源进行管理，每个虚拟防火墙作为一个容器实例运行在同一个内核之上，多台虚拟防火墙相互独立，每个虚拟防火墙实例对外呈现为一个完整的防火墙系统，该虚拟防火墙业务功能完整、管理独立、具备精细化的资源限制能力，典型示意图如下所示：

虚拟防火墙具备多业务的支持能力

虚拟防火墙有自己独立的运行空间，各个实例之间的运行空间完全隔离，天然具备了虚拟化特性。每个实例运行的防火墙业务系统，包括管理平面、控制平面、数据平面，具备完整的业务功能。因此，从功能的角度看，虚拟化后的系统和非虚拟化的系统功能一致。这也意味着每个虚拟防火墙内部可以使能多种安全业务，诸如路由协议，NAT，状态检测，IPSEC ***，攻击防范等都可以独立开启。

虚拟防火墙安全资源精确定义能力

通过统一的OS内核，可以细粒度的控制每个虚拟防火墙容器对的CPU、内存、存储的硬件资源的利用率，也可以管理每个VFW能使用的物理接口、VLAN等资源，有完善的虚拟化资源管理能力。通过统一的调度接口，每个容器的所能使用的资源支持动态的调整，比如，可以根据业务情况，在不中断VFW业务的情况下，在线动态增加某个VFW的内存资源。

多层次分级分角色的独立管理能力

基于分级的多角色虚拟化管理方法，可以对每个管理设备的用户都会被分配特定的级别和角色，从而确定了该用户能够执行的操作权限。一方面，通过分级管理员的定义，可以将整个安全资源划分为系统级别和虚拟防火墙级别。系统级别的管理员可以对整个防火墙的资源进行全局的配置管理，虚拟防火墙管理员只关注自身的虚拟防火墙配置管理。另一方面，通过定义多角色管理员，诸如在每个虚拟防火墙内部定义管理员、操作员、审计员等不同角色，可以精确定义每个管理员的配置管理权限，满足虚拟防火墙内部多角色分权的管理。

22 东西向流量安全防护规划

数据中心中虚机（VM）间的交互流量，我们称之为“东西向流量”。针对东西两流量，采用虚拟软件安全网关产品来实现安全防护。

对于普通的云计算VPC模型的业务，既可以将NFV安全业务安装在业务服务器内，也可以部署独立的安全业务网关服务器。可采用部署独立的安全业务网关服务器，此时安装了NFV的独立的服务器资源逻辑上被认为是单一管理节点，对外提供高性能的VFW业务。

考虑到在虚拟化之后服务器内部的多个VM之间可能存在流量交换，在这种情况下外部的安全资源池无法对其流量进行必要的安全检查，在这种情况下，基于SDN架构模式的虚拟化软件安全网关vFW产品应运而生，在安全功能方面，为用户提供了全面的安全防范体系和远程安全接入能力，支持攻击检测和防御、NAT、ALG、ACL、安全域策略，能够有效的保证网络的安全；采用ASPF（Application Specific Packet Filter）应用状态检测技术，可对连接状态过程和异常命令进行检测，提供多种智能分析和管理手段，支持多种日志，提供网络管理监控，协助网络管理员完成网络的安全管理；支持多种***业务，如L2TP ***、GRE ***、IPSec ***等丰富业务功能。

vFW技术带来如下优势：

• 部署简单，无需改变网络即可对虚拟机提供保护

• 安全策略自动跟随虚拟机迁移，确保虚拟机安全性

• 新增虚拟机能够自动接受已有安全策略的保护

• 细粒度的安全策略确保虚拟机避免内外部安全威胁；

vFW解决方案能够监控和保护虚拟环境的安全，以避免虚拟化环境与外部网络遭受内外部威胁的侵害，从而为虚拟化数据中心和云计算网络带来全面的安全防护，帮助企业构建完善的数据中心和云计算网络安全解决方案。

3 云计算环境下数据安全防护手段建议

基于以上云计算环境下的数据安全风险分析，在云计算安全的建设过程中，需要针对这些安全风险采取有针对性的措施进行防护。

31 用户自助服务管理平台的访问安全

用户需要登录到云服务管理平台进行自身的管理操作设置，如基础的安全防护策略设置，针对关键服务器的访问权限控制设置，用户身份认证加密协议配置，虚拟机的资源配置、管理员权限配置及日志配置的自动化等等。这些部署流程应该被迁移到自服务模型并为用户所利用。在这种情况下，云服务管理者本身需要对租户的这种自服务操作进行用户身份认证确认，用户策略的保密、不同租户之间的配置安全隔离以及用户关键安全事件的日志记录以便后续可以进行问题跟踪溯源。

32 服务器虚拟化的安全

在服务器虚拟化的过程中，单台的物理服务器本身可能被虚化成多个虚拟机并提供给多个不同的租户，这些虚拟机可以认为是共享的基础设施，部分组件如CPU、缓存等对于该系统的使用者而言并不是完全隔离的。此时任何一个租户的虚拟机漏洞被黑客利用将导致整个物理服务器的全部虚拟机不能正常工作，同时，针对全部虚拟机的管理平台，一旦管理软件的安全漏洞被利用将可能导致整个云计算的服务器资源被攻击从而造成云计算环境的瘫痪。针对这类型公用基础设施的安全需要部署防护。

在此背景下，不同的租户可以选择差异化的安全模型，此时需要安全资源池的设备可以通过虚拟化技术提供基于用户的专有安全服务。如针对防火墙安全业务的租户，为了将不同租户的流量在传输过程中进行安全隔离，需要在防火墙上使能虚拟防火墙技术，不同的租户流量对应到不同的虚拟防火墙实例，此时，每个租户可以在自身的虚拟防火墙实例中配置属于自己的访问控制安全策略，同时要求设备记录所有安全事件的日志，创建基于用户的安全事件分析报告，一方面可以为用户的网络安全策略调整提供技术支撑，另一方面一旦发生安全事件，可以基于这些日志进行事后的安全审计并追踪问题发生的原因。其它的安全服务类型如IPS和LB负载均衡等也需要通过虚拟化技术将流量引入到设备并进行特定的业务处理。

33 内部人员的安全培训和行为审计

为了保证用户的数据安全，云服务管理者必须要对用户的数据安全进行相应的SLA保证。同时必须在技术和制度两个角度对内部数据操作人员进行安全培训。一方面通过制定严格的安全制度要求内部人员恪守用户数据安全，另一方面，需要通过技术手段，将内部人员的安全操作日志、安全事件日志、修改管理日志、用户授权访问日志等进行持续的安全监控，确保安全事件发生后可以做到有迹可寻。

34 管理平台的安全支持

云服务管理者需要建设统一的云管理平台，实现对整个云计算基础设施资源的管理和监控，统一的云管理平台应在安全管理功能的完整性以及接口API的开放性两个方面有所考虑。前者要求管理平台需要切实承担起对全部安全资源池设备的集中设备管理、安全策略部署以及整网安全事件的监控分析和基于用户的报表展示；后者的考虑是为了适配云计算环境中可能存在的多种安全设备类型或多厂商设备，也需要在API接口的开放性和统一性上进行规范和要求，以实现对下挂安全资源池设备的配置管理和日志格式转换等需求。也只有这样才能实现设备和管理平台的无缝对接，提升云管理平台的安全管理能力。