H3C MSR3600-28路由器如何配置双机热备，命令如何输入？

命令通过以下方法输入：

一、使用console口进行连接

二、点击开始——程序——附件——通讯——超级终端——选com口默认值，即可进入（以XP为例）。

三、进入到超级终端窗口，进入配置H3C界面。

配置双机热备：

一、创建RDO

在配置双机热备之前，必须先在每台设备上创建RDO。

进入系统视图：system-view

创建RDO，并进入RDO视图：rdo rdo-id

注：互为主备状态的两个设备之间的RDO ID号必须一致。

二、配置本端HA接口

本端和对端防火墙需要使用HA接口协商双方的主备状态并同步配置命令和状态信息。

配置本端HA接口：

ha-interface interface interface-name [ peer-mac mac-address ]

可以通过peer-mac参数指定对端HA接口的MAC地址。

若不指定对端HA接口的MAC地址，则使用广播MAC地址FFFF-FFFF-FFFF。

注：双机热备的协商报文和业务同步数据都使用HA接口进行传输，这些报文不同于普通报文，因此防火墙的防火墙模块（如黑名单、包过滤等）对这些报文不起作用。

三、配置VIF

配置虚拟接口包括配置接口的虚拟IP地址、接口权值和虚拟MAC地址。

当防火墙工作在路由模式下时，主备上互为备份的业务接口必须配置相同的虚拟接口ID、虚拟IP地址和虚拟MAC地址。

虚拟IP地址必须与接口的真实IP地址在同一网段，但是不能与接口的真实IP地址相同，虚MAC不能与接口的真实MAC相同。

当防火墙工作在网桥模式下时，不能配置虚拟IP地址和虚拟MAC地址。

接口权值用于动态更新优先级，当接口DOWN/UP的时候，系统根据权值对RDO实时优先级进行调整。

1、路由模式下配置VIF：

vif vif-id interface interface-name virtual-ip ip-address [ virtual-mac H-H-H ] [ reduce value-reduced ]

缺省情况下，value-reduced的值为10。

2、网桥模式下配置VIF

vif vif-id interface interface-name [ reduce value-reduced ]

缺省情况下，value-reduced的值为10。

注：

1）虚拟接口不能重复配置，必须首先用undo命令取消掉原来的配置，才能重新配置。

2）VIF的地址不能与被绑定接口的地址相同。

3）批量备份过程中不能用undo命令取消虚拟接口。

4）为了保证RDO的实时优先级为正值，在一个RDO下每个绑定接口的权值（value-reduced）总和不能大于或等于对应RDO的静态优先级。

5）当使用了双机热备功能后，请不要配置并使用VRRP，否则会导致双机热备功能异常。

四、配置双机热备的调整和优化

（一）配置RSO静态有衔接

RDO静态优先级是指设备的接口全部为UP状态时的RDO的优先级。

根据静态优先级与各接口的实际状态、权值可以计算出RDO的实时优先级。

通过比较RDO的实时优先级可以确定设备之间的主备关系，优先级数值高的为Master。

配置RDO静态优先级：priority value

缺省情况下，静态优先级为100。

注：若本端和对端的实时优先级相等，则根据双方HA接口的MAC地址确定主备关系，MAC地址大的为Master。

（二）配置认证方式

认证方式是指设备通过HA接口收发数据报文和控制报文时使用的认证方式。

认证方式有简单认证模式和MD5认证模式。

配置认证方式：

authentication-mode simplepassword keyword

authentication-mode md5 password { plain | cipher } keyword

缺省情况下，不使用认证。

注：互为主备的设备之间要使用相同的认证模式和认证密码。

建议在配置对端IP和虚接口之前配置认证模式和认证密码。

一旦主备协商完成，配置认证方式会造成部分报文丢失，可能会影响设备状态。

（三）配置通告隔离

一个RDO中的主设备会定期发送抑制报文，通知备份设备自己处于正常工作的状态，并且通告自己的优先级。

备份设备根据通告时间间隔确定收到抑制报文的超时时间，如果连续三次未收到抑制报文则认为主设备已经出现故障，并进行状态切换。建议本端和对端设置相同的通告间隔。

配置通告间隔：ad-interval time-value

缺省情况下，通告间隔为3秒。

注：由于不同型号产品的硬件性能差异，以及设备在实际应用中的业务量大小等因素，双机热备中的备机在批量备份与恢复过程中可能会不能及时处理主机发来的通告报文，从而导致主备设备无法达到稳定同步状态，发生主备频繁切换的异常现象，可以通过配置更大的通告时间间隔来避免此现象。建议用户配置的通告时间间隔大于或等于3秒，以防止上述问题发生。

对于每一个刚接触到OpenStack的新人而言，安装无疑是最困难的，同时这也客观上提高了大家学习OpenStack云计算的技术门槛。想一想，自己3年前网上偶然接触到OpenStack时，一头茫然，手动搭建一个多节点环境时居然用了3个星期。

时至今日，真是感触颇多，从某种角度而言，也很庆幸当时自己并未因困难而放弃OpenStack，否则，应该是去做其他领域了吧！

言归正传，咱们就来数落数落部署OpenStack都有哪些方式吧。这里，我们根据使用者群体的不同类型来进行分类和归纳：

个人使用方面

DevStack

无疑，在可预见的未来时间内，DevStack仍将是众多开发者们的首选安装方式或工具。该方式主要是通过配置参数，执行shell脚本来安装一个OpenStack的开发环境。

Github: https://github.com/openstack-dev/devstack

Wiki: https://wiki.openstack.org/wiki/DevStack

Rdo

Rdo是由Red Hat开源的一款部署OpenStack的工具，同DevStack一样，支持单节点和多节点部署。但Rdo只支持CentOS系列的 *** 作系统。需要注意的是，该项目并不属于OpenStack官方社区项目。

Docs：https://www.rdoproject.org/install/quickstart

手动部署

手动部署all-in-one、multi-node、multi-HA-node环境。

其他

企业、团体方面

Puppet

Puppet由Ruby语言编写。应当说，Puppet是进入OpenStack自动化部署中的早期一批项目，历史还算悠久。目前，它的活跃开发群体们是Red hat、 Mirantis、UnitedStack等。

Red

hat自从收购Ansible之后，如今仍然保持强势劲头在Puppet

OpenStack项目中的Commit数量和质量，其技术实力不容小觑；Mirantis出品的Fuel部署工具中，大量的模块代码便使用的是

Puppet。就国内而言，UnitedStack是Puppet社区贡献和使用的最大用户。

Github：

https://github.com/openstack/puppet-keystone

Governance：

Wiki：

https://wiki.openstack.org/wiki/Puppet

Ansible

Ansible

是新近出现的自动化运维工具，已被Red

Hat收购。基于Python开发，集合了众多运维工具（puppet、cfengine、chef、saltstack等）的优点，实现了批量系统配

置、批量程序部署、批量运行命令等功能，它一方面总结了Puppet的设计上的得失，另一方面也改进了很多设计。比如是基于SSH方式工作，故而不需要在

被控端安装客户端。使得在和OpenStack结合上没有历史包袱，更加能够轻装上阵，未来发展潜力不容小觑号称是“你一直寻找的下一代Iaas”的

Zstack，使用到的部署工具也是基于Ansible。

Openstack-ansible项目，最早是由老牌Rackspace公司在Launchpad官网上注册。

在最新的Ansible OpenStack项目社区Commit贡献中，Rackspace也可谓是遥遥领先，而紧随其后的是Red Hat、国内九州云等公司。

Github：https://github.com/openstack/openstack-ansible

SaltStack

SaltStack

也是一款开源的自动化部署工具，基于Python开发，实现了批量系统配置、批量程序部署、批量运行命令等功能，和Ansible也是挺相近的。不同之一

是，由于SaltStack的master和minion认证机制和工作方式，需要在被控端安装minion客户端，在加之其他原因，自然和

Ansible相比，其优缺点便很明显了。

需要注意的是，使用Saltstack部署OpenStack，并不属于OpenStack社区项目。目前，主要还是处于用户自研自用的阶段。据笔者所知，目前国内的携程应该是使用Saltstack部署OpenStack规模最大的用户。

Saltstack部署OpenStack示例：https://github.com/luckpenguin/saltstack_openstack

Saltstack部署OpenStack模块：

TripleO

Tripleo

项目最早由HP于2013.4在launchpad上注册BP。用于完成OpenStack的安装与部署。TripleO全称“OpenStack On

OpenStack”，意思即为“云上云”，可以简单理解为利用OpenStack来部署OpenStack，即首先基于V2P(和P2V相反，也就是指

把虚拟机的镜像迁移到物理机上)的理念事先准备好一些OpenStack节点（计算、存储、控制节点）的镜像，然后利用已有openstack环境的裸机

服务Ironic项目去部署裸机，软件安装部分的diskimage-builder，最后通过Heat项目和镜像内的DevOps工具(Puppet

Or Chef)再在裸机上配置运行openstack。

和其他部署工具不同的是，TripleO利用OpenStack本来的基础设施来部署OpenStack，基于Nova、 Neutron、Ironic和Heat，来自动化部署和伸缩OpenStack集群。

应

当确切的说，TripleO项目属于当前OpenStack社区主推的“Big Tent”开发模式下的big tent

project（OpenStack下的项目分为三种，core project: nova/neutron等核心项目，big tent

project: 非核心项目，但也被OpenStack 基金会接受；第三种就是其它项目，只是放在OpenStack下，但是社区还没有接受）。

在该项目的社区Commit贡献上，Red hat可谓是遥遥领先，而紧随其后的是IBM等公司。

Wiki：https://wiki.openstack.org/wiki/TripleO

Kolla

在

国内一些互联网资料上，常看到关于kolla是TripleO项目的一部分这样的描述，其实是不准确的。真实的是，Kolla项目起源于Tripleo项

目，时至今日，与它没有任何关系（虽然它们的目标都是做自动化部署，但走的道路却不同）。比之于Tripleo和其他部署工具，Kolla走的是

docker容器部署路线。

kolla项目起源于TripleO项目，聚焦于使用docker容器部署OpenStack服务。该项目由

Cisco于2014年9月提出，是OpenStack的孵化项目。当前Kolla项目在Kollaglue

repo提供了以下服务的docker镜像。 # docker search kollaglue

Kolla的优势和使用场景，体现在如下几个方面：

原子性的升级或者回退OpenStack部署；

基于组件升级OpenStack；

基于组件回退OpenStack；

这里，我们予以拆分来理解：

Kolla

的最终目标是为OpenStack的每一个服务都创建一个对应的Docker Image，通过Docker

Image将升级的粒度减小到Service级别，从而使升级时，对OpenStack影响能达到最小，并且一旦升级失败，也很容易回滚。升级只需要三

步：Pull新版本的容器镜像，停止老版本的容器服务，然后启动新版本容器。回滚也不需要重新安装包了，直接启动老版本容器服务就行，非常方便。

Kolla是通过Docker Compose来部署OpenStack集群的，现在主要是针对裸机部署的，所以在部署Docker Container时，默认的网络配置都是Host模式。

首

先，只需要通过一个命令就可以把管理节点部署完成，这个命令是调用Docker

Compose来部署OpenStack的所有服务，然后我们可以在每一个计算节点上通过Docker

Compose安装计算节点需要的服务，就能部署一个OpenStack集群。因为Kolla的Docker

Image粒度很小，它针对每个OpenStack服务都有特定的Image，所以我们也可以通过Docker

Run来 *** 作某个具体的OpenStack服务。

目前，我所在的公司九州云的一位同事近日获得提名成为Kolla项目Core。为OpenStack社区中增添了一份来自于中国的力量。

Fuel

Fuel

是针对OpenStack生产环境目标

（非开源）设计的一个端到端”一键部署“的工具，大量采用了Python、Ruby和JavaScript等语言。其功能含盖自动的PXE方式的 *** 作系统

安装，DHCP服务，Orchestration服务 和puppet 配置管理相关服务等，此外还有OpenStack关键业务健康检查和log

实时查看等非常好用的服务。

Fuel，这款让很多人即爱且痛的工具，在国内外都很盛名。爱的原因是，它确实很棒；痛的原因是，要想彻底掌握

它，可不是一件容易事（各个模块集成度高、使用技术复杂）。既然提到Fuel，自然不能不提它的父母——Mirantis。Mirantis是一家技术实

力非常雄厚的OpenStack服务集成商，他是社区贡献排名前5名中唯一一个靠OpenStack软件和服务盈利的公司。同时，Fuel的版本节奏也很

快，平均每半年就能提供一个相对稳定的社区版。

从和笔者接触到的一些情况来看，国内研究、使用Fuel的个人、群体还是为数不少的。不少国内OpenStack初创公司的安装包就是基于Fuel去修改的。

由于OpenStack的初衷是面向公有云，因此 OpenStack在“基因”里便缺乏虚机高可用设计 ，这也是到目前为止OpenStack的计算服务Nova一直没有完善的虚机高可用功能的原因。在公有云环境中， 用户业务系统的高可用性应该更多地依赖于分布在集群中的应用程序本身 ，即公有云上运行的 应用程序有自己的集群和负载均衡系统 ，能在一定程度上容忍物理计算节点宕机所带来的虚机不可用，并能通过负载均衡系统实现故障计算节点上的负载自动转移。随着越来越多传统IT架构下的用户转入云计算， OpenStack的私有云用户不断增加 ，由于传统集中式应用系统的非中断运行几乎完全依赖于服务器的高可用性，因此在私有云环境下，OpenStack Nova服务的虚拟机高可用性变得极为迫切( 如果虚机是主备的，倒没有那么迫切，如果是负荷分担或者应用本身没有高可用再或者实现虚拟机层面的高可用会减少宕机时间 )，也是众多OpenStack私有云用户所急需的功能。

为了兼顾和确保传统应用系统向云计算平滑过渡，虽然OpenStack社区并没有提供完整的虚机高可用解决方案，但也提供了部分配合外部监控服务的工作机制让用户可以自己实现虚机高可用。此外，在Liberty版本中， OpenStack实现并改进了相关的NovaAPI接口，以便更好地配合外部高可用系统对Nova服务状态改变的监控和对虚机故障转移 。例如红帽的RDO便实现了基于Pacemaker-remote的虚机高可用，同时社区也有基于Zookeeper对nova-compute服务进行监控以实现虚机高可用。

在OpenStack中，所谓虚机高可用，指在物理计算节点发生硬件故障时(如磁盘损坏、CPU或内存故障导致宕机、物理网络故障和电源故障)，自动将该节点关闭，该节点上的虚机在集群中其它健康的计算节点上重启，如果能实现虚机的动态迁移，便是最佳的高可用方案 。在实现OpenStack虚机高可用方案中，虽然所使用的软件不同，但 通常都是基于三个步骤来实现：监控(Monitoring)、隔离(Fencing)和恢复(Recovery) 。

1) 监控的目的在于判断Hypervisor是否故障，并为隔离 *** 作提供执行依据 。 监控功能由两部分构成 ，一是检测主机故障情况，二是触发主机故障后的自动响应任务(隔离和恢复)。 关于监控功能是否应该集成到Nova中，社区一直存在争论 ：认为计算节点服务的监控应该集成到Nova项目中，主要是基于Nova服务一定程度上已获取其自身运行所依赖基础架构的健康状况，或者说Nova本身已经可以跟踪活动的计算节点。 但Nova对计算节点的跟踪监控只能探测Nova-compute服务的故障与否，而Nova-compute服务的故障并不意味着虚拟机也出现故障 ，即计算节点Nova-compute服务正常与否和该节点上虚机故障与否并无必然联系。 社区也有将监控功能集成到Heat项目的建议，但是此方案需要OpenStack终端用户在虚机故障时使用Heat模板来重启虚机( 但这应该是云管理员的任务，而不是要求用户来执行)。当前的OpenStack高可用环境中， Pacemaker结合Corosync是使用最多的服务高可用监控工具，但是由于历史原因，Corosync对计算节点的支持数目有限，不过Redhat提出的Pacemaker_remote解决了这种限制 。

2) 隔离在高可用集群中是个非常关键的 *** 作 ，所谓的 集群“脑裂”通常是由不完善的隔离 *** 作引起的。 在OpenStack集群的Nova服务高可用中， 隔离就是将故障计算节点与集群完全隔离，使其成为孤立节点 。在实例高可用环境中， 计算节点可能因各种原因出现故障情况，在其他健康节点上重启故障计算节点的虚机之前，必须确保此虚机确实已经不存在，否则可能在一个OpenStack集群中同时出现两个相同虚机的情况 。更糟糕的是， 如果虚机部署在共享存储上，则会出现两个相同虚机同时运行的情况，两个虚机同写一份数据通常会导致数据损坏，而且还会导致同一网络中出现两个相同的IP地址。 因此，在高可用软件对故障虚机进行恢复之前，监控程序必须对有故障的计算节点进行隔离，否则必然会对虚机造成各种破坏。 Pacemaker提供了对集群节点的隔离功能 ，如果采用其他集群工具，则需要自己实现隔离功能。

3) 监控到计算节点故障之后，对该节点进行隔离完成之后，便可对用户的虚机进行 恢复 。在Nova中， 实现虚机恢复的功能主要是Nova提供的Evacuate命令 。当Evacuate被调用时，故障计算节点上的虚机会被自动撤离，并在新的节点上恢复虚机。 为了完成虚机的恢复，虚机应该创建在共享存储上，作为替代方案，也可以将虚机创建在Cinder提供的Volume 上(SAN BOOT)。不过，共享存储或者Volume并非Evacuate执行成功的前提，如果未采用上述两种方案创建虚机，Evacuate也会在其他节点上恢复虚机，但这是 一种有损恢复( 因为Evacuate仅是采用原虚机相同的基础镜像在其他节点上重新创建一个相同的虚机，但是原虚机中相对基础镜像做过变更的数据却不能恢复)。

目前，OpenStack没有一套完成的监控、隔离和恢复方案，因此， 用户必须自己实现服务监控和节点隔离，同时触发故障计算节点上的Evacuate *** 作 。如果 使用Pacemaker集群资源管理器，则需要在计算节点上实现一个Evacuate的资源代理 ，从而允许Pacemaker触发节点上的Evacuate *** 作。

Nova提供了Evacuate API来恢复故障计算节点上的虚机，这是实现计算节点虚机高可用的基础。在监控到计算节点故障并将其隔离之后，便可触发Evacuate *** 作以对该节点上的虚机进行恢复。本质上来说，Evacuate是对Rebuild功能的扩展，或者说基于虚机HA的需求对Rebuild功能进行了扩展，而Rebuild功能仍然具有其实用性。 Rebuild与Evacuate的区别主要在于 ：Rebuild会刷新虚拟机镜像磁盘，即使用新的镜像重新创建具有相同ID的虚机，因此Rebuild无须共享存储，其功能更像是相同的硬件重新安装另外的 *** 作系统(如windows系统换成Linux系统)；而Evacuate是真正的原样复原，包括系统和用户数据。此外， Evacuate和Rebuild仅支持Active和Stopped状态的虚机 ，而不支持Paused、Suspend和Shut down等状态的虚机。

Evacuate的具体 *** 作过程取决于虚机的配置和底层存储架构 。 如果虚机基于计算节点本地文件系统的“临时(ephemeral)”存储 ，则Evacuate *** 作采用与原虚机相同的镜像在其他节点创建，新老虚机具有相同的配置，如相同的实例ID、镜像ID、Attached Volumes 、Flavor、IP等。 如果虚机位于共享存储上 ，则Evacuate将在其他节点上基于相同的虚机文件重启虚机，并保持虚机的配置不变。 如果虚机是基于Volume后端的 ，则Evacuate将重建虚机并从相同的Volume上启动。因此， 基于共享存储和Volume后端的虚机可以原样恢复，而基于本地临时存储的虚机不能恢复用户数据(位于临时存储上的数据) 。

1）Rebuild前查看虚机信息(nova show  vmid)。记录UUID、IP地址、主机名和Volume挂载情况。

2）执行Rebuild *** 作。这里仍然使用原镜像cirros-image-name对vm-name进行Rebuild *** 作，用户可以选择任意其他镜像进行Rebuild *** 作。nova  rebuild  vm_namecirros-image-name

3）Rebuild之后检查虚机信息(nova show  vmid)。注意观察主机名、UUID、IP地址和Volume挂载情况是否改变，正常情况下Rebuild后这些参数应该保持不变。

1）Evacuate之前在虚机 *** 作系统中保存用户数据，以备Evacuate后验证。

[root@nfs-server ~]#  echo "This data should be recovery after evacuate">  /root/test.txt

2）Evacuate之前检查虚机信息(nova show  vmid)。核实虚机的宿主机并确认Evacuate *** 作的目标主机，Evacuate要求使用共享存储或者基于Volume的虚机，此处的nfs-server为基于NFS共享存储的虚机。nova  hypervisor-servers compute2

3）计算节点正常运行时执行Evacuate *** 作。Evacuate *** 作要求虚机所在宿主机的计算服务不能处于Active状态，否则不允许执行。//compute1节点正常运行，不允许执行Evacuate

[root@controller1~]# nova evacuate nfs_server compute2

ERROR  (BadRequest):  Compute  service  of  compute1  is  still  in  use.  (HTTP  400)

4）计算节点故障时执行Evacuate *** 作。通过shut down计算节点compute1来模拟节点故障，注意观察Evacuate执行过程中虚机状态的变化。

//shutdown compute1节点

[root@compute1~]# poweroff

//执行evacuate，目标节点为compute2

[root@controller1~]# nova evacuate nfs_server compute2

5）Evacuate之后查看虚机的变化情况(nova show vmid)。虚机所在宿主机应该由compute1漂移到compute2。

6）验证Evacuate之后用户数据是否可用。有两个方法可以验证：Evacuate前更改过虚机root用户密码，现在检查root密码是否仍然可用；Evacuate前在/root/test.txt中保存有用户数据，现在检查数据是否仍然存在。

[root@nfs-server ~]#  more /root/test.txt

This data should be recovery after evacuate

7）启动compute1节点，检查compute1节点上的虚机是否还会自动恢复。正常情况下，执行Evacuate *** 作的虚机不会在原计算节点上被恢复，在原计算节点恢复过程中会自动清除虚机相关信息。

公有云依赖于应用程序自身的高可用，在一定程度上容忍物理机的宕机，私有云依赖于服务器的高可用。为了兼顾和确保传统应用系统向云计算平滑过渡，提供了部分配合外部监控服务的工作机制让用户可以自己实现虚机高可用。虚机高可用通常是基于三个步骤来实现：监控(Monitoring)、隔离(Fencing)和恢复(Recovery)。Nova对计算节点的跟踪监控通过探测Nova-compute服务的故障与否来进行隔离，Pacemaker提供了对集群节点的隔离功能，需要在计算节点上实现一个Evacuate的资源代理，从而允许Pacemaker触发节点上的Evacuate恢复 *** 作。Pacemaker和Corosync是使用最多的服务高可用监控工具，但Corosync对计算节点的支持数目有限，另外Redhat提出的Pacemaker_remote解决了这种限制，要知如何解决请下回分解。

---