新积累思维导图

产品名称

密级

ODL平台各产品 内部公开

产品版本 共31页

控制器ODL平台集群测试指导

拟制 鲍明先/116307 日期 2015-12-08

审核 日期

批准 日期

 

华为技术有限公司

版权所有  侵权必究

（TST01T04 V2.0/ IPD-PTM / 仅供内部使用）

 

修订记录

日期 修订版本 修订描述 作者

2015-12-09 1.0 初稿完成 鲍明先/116307

 

目  录

控制器ODL平台集群测试指导 1

1 概述 6

2 集群简介 6

2.1 什么是集群？ 6

2.2 使用集群的目的 6

2.2.1 提高性能 6

2.2.2 降低成本 7

2.2.3 提高可扩展性 7

2.2.4 增强可靠性 7

3 AC集群介绍 7

3.1 集群框架 7

3.2 Ngnix主备 8

3.3 ODL集群 9

3.3.1 Dom集群 9

3.3.2 RPC集群 12

3.3.3 南向集群 12

3.3.4 集群配置文件 13

3.4 MongoDB集群 13

3.4.1 ReplSet方式 14

3.4.2 ReplSet+Shard方式 17

3.5 Puppet主备 18

3.6 OMS主备 20

4 Zookeeper集群 20

4.1 Zookeeper简介 20

4.2 系统架构 21

5 Infinispan集群 22

5.1 Infinispan简介 22

5.2 系统架构 22

6 集群/分布式测试分析 23

6.1 选举 23

6.2 数据同步 23

6.3 分片 24

6.4 对外一致性 25

6.5 测试设计分析 26

6.5.1 通用分布式设计分析 26

6.5.2 ODL平台测试设计分析 27

7 分布式锁测试分析 28

7.1 锁介绍 28

7.2 分布式锁测试设计分析 29

8 附件 29

8.1 MongoDB操作工具 29

8.1.1 命令行登陆 29

8.1.2 使用客户端工具 30

8.2 设计分析思维导图 31

 

控制器ODL平台集群测试指导

关键词：ODL、MongoDB、zookeeper、infinispan、ngnix、集群

摘    要： 本文介绍Agile Controller-DCN V1R2C00版本基于ODL集群框架搭建的平台集群框架的产品架构和测试设计以及测试方法指导

缩略语清单：

Abbreviations缩略语 Full spelling 英文全名 Chinese explanation 中文解释

1 概述

Agile Controller-DCN（以下简称AC）是新开发的数据中心控制器产品，其平台采用开源的ODL集群框架，并在此系统上进行加固和引入其他周边配套的集群组件，从而实现一个完整的平台基础框架业务，支撑本产品以及周边其他使用该平台的产品。本文主要介绍AC的ODL平台框架中包含的所有集群相关组件业务，并对相关组件系统进行架构和测试分析，用以指导进行平台集群框架测试。

2 集群简介

2.1 什么是集群？

集群（cluster）技术是一种较新的技术，通过集群技术，可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较高的收益，其任务调度则是集群系统中的核心技术。

集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群像是一个独立的服务器。集群配置是用于提高可用性和可缩放性。

2.2 使用集群的目的

集群的特性主要有以下四点：提高性能、降低成本、提高可扩展性和增强可靠性，AC集群主要是利用了集群可靠性强的特性，通过集群的建立高系统的可靠性的同时减小故障损失。

2.2.1 提高性能

一些计算密集型应用，如：天气预报、核试验模拟等，需要计算机要有很强的运算处理能力，现有的技术，即使普通的大型机其计算也很难胜任。这时，一般都使用计算机集群技术，集中几十台甚至上百台计算机的运算能力来满足要求。提高处理性能一直是集群技术研究的一个重要目标之一。

2.2.2 降低成本

通常一套较好的集群配置，其软硬件开销要超过100000美元。但与价值上百万美元的专用超级计算机相比已属相当便宜。在达到同样性能的条件下，采用计算机集群比采用同等运算能力的大型计算机具有更高的性价比。

2.2.3 提高可扩展性

用户若想扩展系统能力，不得不购买更高性能的服务器，才能获得额外所需的CPU 和存储器。如果采用集群技术，则只需要将新的服务器加入集群中即可，对于客户来看，服务无论从连续性还是性能上都几乎没有变化，好像系统在不知不觉中完成了升级。

2.2.4 增强可靠性

集群技术使系统在故障发生时仍可以继续工作，将系统停运时间减到最小。集群系统在提高系统的可靠性的同时，也大大减小了故障损失。

3 AC集群介绍

3.1 集群框架

 

如上图所示，整个AC控制器中，存在北向接口代理主备、MongoDB数据库集群、ODL节点集群（包含ODL本身的dom、RPC集群以及AC自主添加的南向集群）、Zookeeper集群、Infinispan集群、Puppet主备系统、OMS主备系统几大组件组成。

3.2 Ngnix主备

Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器，也是一个 IMAP/POP3/SMTP 代理服务器。Nginx作为负载均衡服务器：Nginx 既可以在内部直接支持 Rails 和 PHP 程序对外进行服务，也可以支持作为 HTTP代理服务器对外进行服务。Nginx采用C进行编写，不论是系统资源开销还是CPU使用效率都比 Perlbal 要好很多。

Nignix主备通过对外公布浮动IP，作为整个系统的对外访问IP，用来向北向屏蔽整个AC集群操作。系统通过利用nginx+keepalived进行主备切换，配置负载均衡，提高系统可靠性及性能。Keepalived的作用是监控Ngnix服务器的状态，如果有Ngnix主机故障后，Keepalived进程会将浮动IP切换到备用Ngnix服务器上，并在备机上启动Ngnix进程的实现主备切换，保证业务的可靠性。 

并可以通过/var/log/HA/ha.log查看(HA: High Availability)，获取主备切换信息：

 

查看/etc/ngnix /ngnix.conf文件，可以查看ngnix的负载算法以及浮动IP配置：

 

通过ifconfig命令查看，确定浮动IP生效：

 

3.3 ODL集群

ODL集群是开源平台提供的集群功能，基于AKKA系统提供分布式调度，ODL集群中共包含Dom集群、RPC集群和南向集群三个独立运行的集群系统，共同完成整个集群的业务支撑。

3.3.1 Dom集群

ODL集群在设备管理中使用了Dom树，用来分片管理所有整个集群中的设备，既做到负载均衡，又可以做到在单个节点故障的情况下，可以通过刷新Dom树将故障节点的设备分片到其他正常节点，以解决单点故障问题，如果节点恢复后，可以通过北向接口进行重新负载，将设备再负载到恢复节点（重新负载只能保证设备数量平均，不能保证是原来在该故障节点的设备重新挂载回来）。

当前设备分片的Dom树保存在Mongodb数据库中（开源ODL保存在内存中，持久化到文件中，但由于性能和可靠性较低被修改为数据库中），所有的Dom树变更只能通过dom集群的主节点进行操作，保证业务处理的唯一性。查看Mongodb的com_huawei_enterprise_naas_dom_NodeEntity可以查看到每一个物理设备分配的节点信息，其中master为主节点，slave为备节点（当前设备支持多链路链接）。

 

从数据库中还可以看到和dom相关的有ControllerEntity，其保存的是整个控制器节点的数据信息，FabircNodeEntity表是阿里版本独有，后续版本不再使用。OpenflowNodeEntity里面保存的是注册Openflow节点的信息，用来进行Openflow业务下发。

DOM集群是有状态的集群，所以集群启动时，需要进行集群选举，选举出来主节点进行业务调度和分配，只有选举成功后，整个集群才能正常工作。集群选举使用raft算法：

Raft算法将Server划分为3种角色：

1.       Leader

负责Client交互和log复制，同一时刻系统中最多存在1个

2.       Follower

被动响应请求RPC，从不主动发起请求RPC

3.       Candidate

由Follower向Leader转换的中间状态

 

图表 9：角色状态转换图

选举流程

 所有的Server均以Follower角色启动，并启动选举定时器

 Follower期望从Leader或者Candidate接收RPC

 如果Follower选举定时器超时，发起选举

 获得超过半数Server的投票，转换为Leader，广播Heartbeat（该条限制集群存活的节点必须超过半数）

 Leader广播Heartbeat重置Follower的选举定时器

细节补充

1. Candidate在等待投票结果的过程中，可能会接收到来自其它Leader的AppendEntries RPC。如果该Leader的Term不小于本地的currentTerm，则认可该Leader身份的合法性，主动降级为Follower；反之，则维持Candidate身份，继续等待投票结果

2. Candidate既没有选举成功，也没有收到其它Leader的RPC，这种情况一般出现在多个节点同时发起选举，最终每个Candidate都将超时。为了减少冲突，这里采取“随机退让”策略，每个Candidate重启选举定时器（随机值），大大降低了冲突概率

3.南向集群选举日志，出现cluster state change to Leader则表明选举完成：

 

3.3.2 RPC集群

    RPC集群是一个无主集群，所有节点的角色一样，所以不需要选举，其作用是在整个集群中实现远程业务调用。前面已经讲过了DOM集群对设备进行了分片，而北向的Ngnix也是通过轮训和ip_hash的算法来进行分布式调度，这样就可能出现北向接口要操作的设备并不在当前北向请求的节点，需要在集群中进行跨节点调用，RPC集群就是解决跨节点调用问题。

RPC集群在设备注册到节点后，会在该节点上注册RPC调用的接口，并在本地RPC集群节点中存储，同时RPC集群之间通过gossip算法将RPC注册的接口信息同步给集群中的其他节点（注意gossip算法不是强一致性算法，所以会存在RPC注册后未能完全同步到所有节点，导致RPC调用失败的情况，所以当前产品采用了延时调用以及一定的超时时间方式来规避该问题，但如果集群节点数目较大时，依然会存在该问题，后续还需要继续优化）。当所有节点的PRC信息全部同步后，就可以实现在任意节点上请求，都可以根据具体的节点分片信息路由到正确的节点，实现对上层业务调用的隔离。

3.3.3 南向集群

南向集群也是有状态集群，跟DOM集群类似，需要选举出主节点。南向集群的作用类似于Ngnix的北向屏蔽，即对南向设备屏蔽集群节点对设备的影响，所有的设备都访问南向集群的主节点所在的浮动IP（通过配置文件配置），然后由南向主节点再进行DOM分片，最终再通过分片的真实节点的IP向设备进行链接建立和业务处理。南向节点主要解决由于设备太多以及设备不在线时，可以完成批量配置和设备主动注册的场景，目前南向集群支持通过netconf和ovsdb完成节点注册。虽然南向集群和DOM集群都使用raft算法，但两个集群相互独立，不能保证两个集群的leader节点是一致的。

南向集群节点的Leader可以通过北向接口/restconf/operations/device-attach:is-leader来查询是否为主，同时也可以通过查询浮动IP来确定主节点，浮动IP配置文件在/opt/controller/naas/naas-karaf-1.0.1-SNAPSHOT/configuration/float-ip.propertites中，通过ifconfig查看IP所在节点即可确定（部分版本未使用南向集群时，float.ip.addresss选项为空）：

 

3.3.4 集群配置文件

ODL集群的配置文件都放在/opt/controller/naas/naas-karaf-1.0.1-SNAPSHOT/configuration/initial文件夹下，共分为如下几个文件：

akka.conf：ODL原生集群配置文件，里面配置了odl-cluster-data（DOM集群）和odl-cluster-rpc（RPC集群）两个集群的核心节点配置（注意集群扩容时，核心节点配置不会变化）。

akka-persistence.conf：ODL原生的集群DOM数据的持久化配置，当前AC控制器已经将DOM数据持久化到MongoDB，故该配置文件废弃。

modules.conf /module-shards.conf：Dom树的分片配置，当前AC未对Mom树进行分片配置，故该文件暂时未使用。

platform-cluster.conf：南向集群配置文件，定义南向集群的核心节点数据。

platform-cluster-nodes.conf：定义南向集群节点的名称和集合。

3.4 MongoDB集群

MongoDB数据库是一种NoSQL数据库，其表结构并不固定，而是以json格式的方式存数的文本类型，支持类似关系型数据库的部分功能，提供高效、可靠的分布式数据库。MongoDB的数据库集群主要分为ReplSet方式和ReplSet+Shard两种方式。

3.4.1 ReplSet方式

     ReplSet为副本集方式，即对于同一份数据库数据，存在多个副本，如果主系统故障后，其他副本数据能保证接替主系统进行工作，实现高可靠性。

 

首先介绍一下在replica set里分为三种节点类型：

 primary ：负责client的读写，所有数据操作都在主节点进行。

 secondary：作为热备节点，应用Primary的oplog读取的操作日志,和primary保持一致，由于通过日志文件读取，所以会在大量数据写入时存在一定的延迟，当此时主节点故障，可能存在部分数据丢失。另外Secondary不支持数据写入，但可以配置允许读取，配置可以读取时需要考虑可能存在脏读数据。

 arbiter：它不负责任何读写,只作为一个仲裁者，负责primary down的时候剩余节点的选举操作。

节点角色可以通过rs.status()可以查看到详细的主从信息

主节点：

 

副节点：

 

仲裁节点：

 

通过rs.conf查看priority字段，查看节点竞选优先级，arbiter只有选举权没有被选举权。当主节点故障后，优先级最高的节点竞选为主节点。

 

目前AC系统的MongoDB集群采用副本集方式，其中一个为主节点，负责所有数据的读写，另外默认使用2个备份节点备份所有数据，如果节点数为5个或者5个以上时，增加2个仲裁节点，用来保证高可靠性。AC的MongoDB采用读写不分离的方式配置，即所有数据操作只在主节点上进行，备份节点只进行和主节点同步。这样的设计能保证数据的一致性，但由于所有的数据操作都落在主节点上，会导致主节点性能影响较大，整体集群的吞吐量受到单节点的性能限制。

3.4.2 ReplSet+Shard方式

前面介绍ReplSet存在性能瓶颈，所以MongoDB又新支持了在ReplSet基础上进行分片，实现分布式的读写，提升性能和容量。

Shard方式实际上就是将以前的一个数据库通过一定的算法分片为多个数据库，每一个Shard是一个独立的ReplSet，实现ReplSet的高可靠性，同时多个Shard组成一个完整数据集群，每个Shard中有一个主节点，负责读写数据，这样就可以将数据的读写分散到所有节点上，提升整体读写性能和系统容量。既然增加了多个Shard的分片配置，就需要像前面ODL集群一下实现对外屏蔽实现，对内分片管理和数据整合，故Shard方式增加了一些配置和调度的进程，具体架构如下：

 

 shards：一个shard为一组mongod，通常一组为三台，这一组mongod中的数据是相同的。数据分割按有序分割方式，每个分片上的数据为某一范围的数据块，故可支持指定分片的范围查询。数据块有指定的最大容量，一旦某个数据块的容量增长到最大容量时，这个数据块会切分成为两块；当分片的数据过多时，数据块将被迁移到系统的其他分片中。另外，新的分片加入时，数据块也会迁移。 

 config server：存储集群的信息，包括分片和块数据信息。主要存储块数据信息，每个config server上都有一份所有块数据信息的拷贝，以保证每台config server上的数据的一致性。注意config Server需要同时在线时，才能对分片数据进行修改，所以必须保证config server的正常运行（AC系统目前由于config server和mongodb数据库同机部署，导致config server和mongod同时故障的情况下，概率性会出现主备切换不及时，导致故障恢复时间过长问题，最终放弃了shard方式，后续还会继续分析并解决该问题，提升数据库分布式性能）。 

 mongos：可以有多个，相当于一个控制中心，负责路由和协调操作，使得集群像一个整体的系统（类似ngnix）。mongos可以运行在任何一台服务器上，有些选择放在shards服务器上，也有放在client 服务器上的。mongos启动时需要从config servers上获取基本信息，然后接受client端的请求，路由到shards服务器上，然后整理返回的结果发回给client服务器。

 

通过在命令行输入mongo 192.168.6.106:27020查看分片信息（这里以5节点为例）

       

3.5 Puppet主备

  puppet是一种Linux、Unix、windows平台的集中配置管理系统，使用自有的puppet描述语言，可管理配置文件、用户、cron任务、软件包、系统服务等。puppet把这些系统实体称之为资源，puppet的设计目标是简化对这些资源的管理以及妥善处理资源间的依赖关系。

puppet采用C/S星状的结构，所有的客户端和一个或几个服务器交互。每个客户端周期的（默认半个小时）向服务器发送请求，获得其最新的配置信息，保证和该配置信息同步。每个puppet客户端每半小时(可以设置)连接一次服务器端，下载最新的配置文件,并且严格按照配置文件来配置客户端。配置完成以后，puppet客户端可以反馈给服务器端一个消息. 如果出错,也会给服务器端反馈一个消息。

 

图表 8：Puppet架构

puppet master通过读取配置文件模板对client端进行集中管理，并且能都通过修改配置文件，对client进行管理。由于puppet master存在单点故障的可靠性问题，AC控制器提供了主备master配置，采用浮动IP方式配置（安装时用户指定），并通过自动同步数据的方式备份主信息到备，当检测到主机故障后，备机自动拉起提供服务。

通过命令行输入ps aux|gerp puppet指令查看puppet进程：

Master节点：

 

Agent节点：

 

集群环境搭建完成后，可以通过浏览器进入AC的集群管理界面，正常情况如下图：

 

当puppet agent进程停止后，与puppet master通信异常，master将对agent失去管理能力，最直观的现象可以通过运维页面观测到：

 

3.6 OMS主备

OMS是公司提供的开源网管平台，在AC中提供告警和性能相关功能，同样也提供主备方式进行可靠性保证。OMS分为主程序和guass数据库两部分，在系统中部署两套OMS程序，通过浮动IP对外部提供服务（安装时用户指定，故障后切换），同时数据库采用日志备份方式（跟mongodb备份方式相同），实现主备负载和切换。

4 Zookeeper集群

4.1 Zookeeper简介

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。ZooKeeper是以Fast Paxos算法为基础的，paxos算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos作了一些优化，通过选举产生一个leader，只有leader才能提交proposer。目前AC主要利用zookeeper实现分布式锁。

4.2 系统架构

 

Zookeeper系统由多个Server构成，在AC中是独立的进程，每个节点部署一个（默认部署3个节点），Zookeeper集群启动后会进行选举，确定Leader后，整个集群正常运行。Client端内嵌在AC的karaf进程中（和ODL进程在一起），和Zookeeper 集群服务进行交互。Zookeeper集群具有如下特点：

1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。

2 .可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。

3 .实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

4 .等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

5.原子性：更新只能成功或者失败，没有中间状态。

6 .顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

正式上述特性，AC使用Zookeeper集群实现在分布式并发调度下，对于有竞争关系的业务资源进行统一锁，以解决资源冲突问题，所有设计业务资源竞争的，都需要使用分布式锁来进行设计，并保证锁的顺序性（具体设计分析见后面分布式锁分析）。Zookeeper的相关操作和命令可以参考：http://www.wangyuxiong.com/archives/51725

5 Infinispan集群

5.1 Infinispan简介

Infinispan是一个高度可扩展，高度可用的键/值数据存储和数据网格平台。它经常被用来作为一个分布式缓存，也可作为一个NoSQL的键/值存储或对象数据库。由于其具有分布式的协调和存储能力，适用于大型的分布式内存数据库系统，解决集群环境下的大容量和高速访问缓存。目前AC使用Infinispan是引入2012的分布式调度框架，用来解决并发业务下存在时序控制和资源分配时，对冲突范围内的资源通过hash方式进行调度，使得对于资源请求有冲突的都hash到固定节点，进行时序控制。同时hash分配可以解决大量请求时的并发处理性能。对于Infinispan，后续可能引入对于性能和并发要求较高的业务加入缓存中，解决性能瓶颈（但当前存在持久化不稳定问题，还在继续解决中，故AC暂时未重点使用）。

5.2 系统架构

Infinispan的系统架构类似于MongoDB，也是支持副本集和分片两种方式，当前系统采用分布式的分片模式来搭建分布式缓存数据库。infinispan使用哈希一致性算法决定集群实体的保存位置。在一致性哈希算法中通过配置可以确定每个节点实体的备份个数，备份数需要在性能和数据持久性间做权衡。备份个数越多，性能消耗会越高，但同时有更好的数据安全性，能大大降低数据丢失风险，当前实现是infinispan写入时，需要保证写入成功一半以上的副本才返回成功，做到写入强一致性。读取操作时，get请求会并行的发往每个拥有该数据的节点，并获取第一个返回的结果，该机制能够保证数据一致性。Infinispan可以通过命令查看其运行状态：

 

对于Infinispan的测试分析，其既具有分布式特性（相关分布式可以参考Zookeeper），同时它还是一个缓存数据库，对于缓存测试分析，还需要考虑持久化和一致性（当前infinispan就在持久化上存在问题，暂时未进行持久化）。

6 集群/分布式测试分析

6.1 选举

集群分为有主集群（大多数集群）和无主集群，其中有主集群需要进行选举来确定主节点，主节点负责在整个系统中的任务调度、节点状态管理、数据同步等工作。选举在节点启动时触发，如果节点获得超过半数的投票（这就是为什么一定要有超过半数的节点正常运行）即可选举成为主节点。只有主节点选举成功，其他节点的状态都稳定后，整个集群才能正常运转。而分布式系统由于控制层面不在分布式节点中，故不需要考虑。

集群的选举，主要关注选举的算法和流程，通过状态机的设计模式来设计选举中节点状态变化以及在不通状态下节点的基本业务。除了初次启动外，还需要关注节点故障后选举流程的再次启动以及最终完成变化（如节点故障/恢复、新增和删除节点）。另外节点选举还需要保证主节点的稳定性，当主节点正常场景下，节点状态变化不应该触发主节点选举，因为主节点选举过程中，整个集群的业务将受到影响。

在集群场景下，由于有很多的业务需要有主节点来进行，所以主节点的验证需要重点覆盖主节点故障后对业务的影响以及主节点重新选举的效率，并验证其规格是否能够达到产品要求。

在双机的场景中，实际上也存在选举的流程，只不过一般选举都是通过配置文件指定，故障后的状态切换也比较简单，可以参考集群选举方式来进行设计。

6.2 数据同步

在集群中，有很多需要全局共享的数据，需要各个节点完成同步，并根据相应的数据来进行业务的逻辑处理，所以数据同步是集群的核心功能。数据同步主要是保证数据的一致性，根据一致性和性能的取舍，可以分为强一致性和弱一致性两种。强制一致的最高要求是所有节点的数据更新全部成功后，本次数据更新操作才会认为成功（类似同步接口），弱一致性的最低要求是有一个节点更新成功后，即返回操作更新成功，而其他节点通过另外的同步机制进行数据的刷新，达到最终的一致性（类似异步接口）。另外还有一些介于最高一致性和最低一致性的算法，比如超过半数后返回成功等，根据实际的算法来进行设计分析，其核心思路就是如何保证数据的一致性，如果存在不一致的情况下，如何保证业务能够正常运行以及业务最终恢复。

数据同步的方式也有多种，分为内存同步、中间持久化同步、异步日志同步的方式。其中内存同步其性能较高，难度也最大，一般用于对一致性要求比较高的。内存同步除了要保证内存数据在各节点上快速同步外，还需要考虑内存数据的持久化以及和持久化的一致性（参考缓存中的分析，内存数据实际上就是缓存）。同时内存一致性还需要重点考虑数据修改的性能，确保数据刷新。使用中间的持久化进行同步一般使用数据库，即所有节点都读取和写入同一个数据库，数据库对所有节点可见，并且每次操作都是单次操作（数据库存在集群或者其可靠性不在此考虑范围内，作为一个独立的组件进行分析），属于强一致的数据同步范畴，对于该方式的处理，主要考虑多节点并发处理数据库的资源竞争和锁问题，特别是有对数据库表进行加锁操作的，需要充分考虑是否存在死锁问题。异步日志同步方式属于弱一致性场景下的常用设计方式，即主节点进行数据更新后，记录日志，另外的线程将操作日志同步给其他节点，其他节点按照日志的操作刷新数据，使得最终保证数据的一致性。在弱一致性的场景下，需要重点验证的是在不一致的情况下，是否能够保证业务不受影响以及最终是否可以保证数据的一致性。在弱一致性的方式下，也可以通过所有的读写只通过主节点实现的方式来达到数据强一致，但会影响业务效率和加重主节点的负载，需要覆盖性能和可靠性验证。

数据同步除了在正常的业务运行过程中会存在，在节点故障恢复时也需要完成和其他节点保证数据一致，才能正常的对外部提供业务服务。除了通过中间持久化的方式单一数据源实现的持久化，其他场景都要考虑重启后的数据一致性处理，并保证只有当数据完全一致后，才能对外部提供服务。

分布式场景下，一般不涉及使用异步同步或者内存同步的方式，如果需要同步都使用中间持久化的方式，所以分布式场景下数据同步设计按照业务场景考虑即可。

6.3 分片

集群和分布式之所以可以提升业务容量，主要是将业务进行分片，每个节点负责一部分的业务，所有集群节点组合起来负责所有的业务数据处理，以一个整体方式对外部提供大容量业务。业务的分片设计需要覆盖分片的业务算法，既要保证相对的负载均匀（负载算法也可以分为多种方式），又要保证所有业务都有节点完成处理。除了初始的分片外，还需要考虑后续业务增加和删除后负载算法的变化、新增节点后业务是否能动态切换到新节点、节点故障后原来负载在该节点的业务是否能够动态切换到其他正常的节点，保证集群业务的可靠性。同样一个节点的负载也是有限的，考虑极端场景下业务负载的上限，对于设置了上限的业务，如何在其他节点故障且超过本机上限时保证业务不丢失。

在完成分片后，集群和分布式需要实现基于分片的调度，保证业务依据分片原则在指定的节点完成业务执行和调度。当有分片刷新时，集群应该能够立即感知（必须保证时序和数据一致性）分片变化，所有业务调用或者消息发送能够正确的切换到新节点，确保业务不中断。在分片切换的场景下，需要重点验证切换后业务调度的正确性，特别是在集群规模越大、弱一致性的场景下，需要特别设计考虑。

6.4 对外一致性

集群/分布式内部是多个节点组成一个整体，对外部只体现为一个独立的节点，屏蔽外部对集群的感知。在OSS的产品业务中，主要对外部提供http服务或者其他北向接口，同时南向提供设备的业务上报服务（如SNMP等），其他由集群节点主动发起的业务，不受唯一性影响。

在北向HTTP服务上，使用较多的为ngnix代理方式。北向提供一个浮动IP地址，用来接收所有的向集群发起的请求，并由ngnix实现负载均衡算法（业务需要根据自己使用的负载均衡算法验证是否按照要求负载），将请求分发给各个节点，并且能够感知节点的故障或者恢复，动态完成负载的变化。在不同的负载算法下，还需要考虑鉴权处理，在不同的节点上请求，要保证鉴权的一致性（或者使用基于源IP的hash算法，使得同一个用户的请求永远在一个节点上执行，但也要考虑该节点故障后算法切换）。

除了负载算法，另外一个就是浮动IP地址的设置，由于要兼顾可靠性问题，故负载均衡进程也需要实现主备或者集群方式，满足可靠性要求。另外如果是普通的浮动IP配置，必须保证浮动IP和实际IP在一个网段内，如果需要实现浮动IP跨节点，就必须保证节点能够实现浮动IP的路由动态发布，测试设计时，需要根据实际组网场景来分析，保证浮动IP能够正常倒换，且倒换时间满足规格要求。

南向接口的上报实际上需要实现的功能和北向一致，即要保证负载均衡，又要保证浮动IP的唯一性和可靠性，具体的测试设计思路依据具体实现的流程，保证上述测试点覆盖即可。

6.5 测试设计分析

6.5.1 通用分布式设计分析

 

6.5.2 ODL平台测试设计分析

 

 

7 分布式锁测试分析

在多线程并发的时候，由于每个线程之间独立调度，在任务中存在资源共享和依赖时，每个线程之间无法做到资源的一致性，可能存在数据的脏读或者脏写，导致数据出错。为了解决多线程的资源共享问题，最常用的设计方式就是锁，当前版本使用Zookeeper实现分布式锁方式。

7.1 锁介绍

为了解决并发场景下不能精细的根据具体的使用来进行锁，使用锁（lock）的类来控制。当一个线程获取锁之后，在释放锁之前，该锁为当前线程所有（当前线程可以反复获取该锁，其他线程根据锁机制进行互斥），所以使用锁时，必须考虑锁的释放，如果程序处理存在问题，导致锁无法释放（多次获取的锁需要多次释放），将会导致该资源永远被锁定，造成业务阻塞。锁可以分为读锁和写锁，在加读锁时，如果该资源未加任何的写锁，则该线程将获取到对象的读锁，所以读锁之间是可以共享的；在加写锁时，如果该资源未加任何的读锁和写锁时，则该线程将获取对象的写锁。从锁的互斥原则来看，写锁是互斥的，保证资源永远只被一个线程获取，从而实现多线程中的资源共享处理。由于资源的加锁和解锁都是由开发人员代码控制，故测试设计时需要重点关注加锁的对象是否正确、对象是否存在互斥、加锁和解锁的范围、正常和异常情况下是否能够解锁。在存在组合多个资源锁的情况下，还可能存在死锁的问题（所谓死锁就是两个线程分别拥有对方需要加锁的对象，导致相互互斥形成死锁，进程被阻塞），所以该场景下还需要重点分析是否会存在死锁（常用的解决死锁的方法就是所有线程保证锁顺序的一致性）。

在多线程处理时，锁的获取是可以设置策略的，分为公平锁和非公平锁，当然也可以用户自定义或的调度规则（如通过优先级调度锁获取）。公平锁将尽量保证等待时间越长的线程尽可能获取锁，非公平锁则随机进行锁获取。公平锁会导致等待时间较长，性能比较低，所以一般默认为非公平锁。在使用非公平锁的情况下（公平锁也不能完全保证等待时间长的线程就一定优先获取锁），需要考虑前面的线程长期无法获取锁造成业务超时的情况，而自定义的锁获取规则的，测试设计时需要覆盖其设计的规则是否正常执行。

由于锁的处理时在内存中实现，还需要考虑锁的对象在内存中的清理，如果一个锁对象只是创建，而一直被引用，则会导致该对象无法被JVM回收，造成内存泄露，最终导致溢出。故设计时还需要考虑锁对象是否在任务执行完毕后（或者该对象在整个系统的生命周期完毕后）能够正确的解除引用，保证对象能够及时的完成回收。

在集群场景下跨多个节点需要完成锁的一致性，就需要使用分布式锁（如zookeeper）。分布式锁需要解决多节点的锁的数据一致性、各个节点之间的集群交互处理、单节点故障恢复、客户端故障后的自动解锁等功能，至于锁的业务处理，分布式锁和但节点锁的作用要保持一致。

7.2 分布式锁测试设计分析

 

8 附件

8.1 MongoDB操作工具

当前AC的MongoDB需要支持SSL认证和证书方式，故配置方式比较复杂，不管是使用命令行还是界面操作工具，配置相对复杂，具体操作如下：

8.1.1 命令行登陆

后台使用mongo shell方式登陆：

$MONGODB_HOME/bin/mongo ip:port/dbname –u username –p pwd --ssl --sslPEMKeyFile $INSTALL_HOME/mongodb/configuration/ssl/client.pem --sslPEMKeyPassword Changeme_123 --sslCAFile $INSTALL_HOME/mongodb/configuration/ssl/CA.pem  --sslAllowInvalidHostnames

真实命令组合如下： mongo localhost:37017/admin –u huawei –p huawei@123 --ssl --sslPEMKeyFile $INSTALL_HOME/mongodb/configuration/ssl/client.pem --sslPEMKeyPassword Changeme_123 --sslCAFile $INSTALL_HOME/mongodb/configuration/ssl/CA.pem  --sslAllowInvalidHostnames

8.1.2 使用客户端工具

使用Mongodb客户端工具“NoSQL Manager for Mongodb”创建SSL连接：

 

 

所需证书见附件，其中，PEM key file password为客户端私钥密码：Changeme_123  。

  

8.2 设计分析思维导图