Open liusheng opened 5 years ago
最重要的一部就是预升级测试，确保未被发现的bug能够被发现，使用一套小的镜像环境，这个测试环境可以在自己的云上来做，也可以在公有云。如有可能，我们强烈建议将生产环境里的db表dump出来，并且在测试环境使用这些数据来做升级测试。
升级级别是在G版就加入到OpenStack的一个特性，用来提供版本锁定不同计算服务之间的消息传递锁。作为一个很重要的功能，这个功能保证了OpenStack服务在在线升级的过程中保证不同版本之间能够正常交互。
如果没有升级级别，X+1版本的compute服务能够接受和识别X版本的RPC消息。举个栗子，一个nova-conductor服务已经升级到x+1版本，则它也能够接受和识别来自于nova-compute服务X版本的消息，但是compute服务不能识别conductor发过来的消息。
在升级的过程中需要在nova.conf中增加一些配置项，从而来锁定RPC消息的版本，来保证无中断升级服务。这些配置项支持指定RPC版本号，也支持指定release名。e.g.
[upgrade_level] compute=x+1 conductor=x+1 scheduler=x+1
[upgrade_level]
compute=x+1
conductor=x+1
scheduler=x+1
这样，可以保证RPC版本被锁定在x+1之内，当特定的服务升级以后，就删除相应的行。
基于指定的配置文件，升级所有的包，当然也有可能会重启或中断某个以来的服务，例如，使用TGT iSCSI框架来提供块存储服务，则升级包的时候会重启这个，从而影响卷的连接性。
如果包管理器要更改你的配置文件，选择拒绝，则包管理器将会重新生成一个新的配置文件（带一个后缀来区分）
为了升级每一个节点上的服务，则需要修改配置文件，停止服务，升级数据库，再启动服务，推荐每升级一个服务就验证一个服务。
控制节点
存储节点
计算节点
由于从K版开始，OpenStack不再支持db的降级，因此一旦升级失败，db的回滚只能考恢复db的备份。通常的场景是记下管理服务， 完成升级流程，发现测试过程中未遇到的问题，因此，你需要回滚环境到初始的“已知健康的”状态，没有新创建虚拟机、网络、卷等。所有的这些新的资源将会处于冻结状态知道db从备份中恢复。
下面是回滚操作需要考虑的点
需要确保你做了足够的备份来为恢复做准备。 回滚操作是一个危险的流程，因为我们花了更多的努力在升级上而不是降级。降级出现问题将会更加难于定位解决。你需要自己评估和承担降级的风险，通常，这会是迫不得已的选择。
回滚操作（以Ubuntu安装为例）
[1] http://cloudgeekz.com/71/how-to-setup-openstack-to-use-local-disks-for-instances.html
[2] http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/Rolling_updates_OpenStack_WP.pdf
[3] https://access.redhat.com/articles/1169003
1. 升级前准备
升级计划
准备升级前的测试环境
最重要的一部就是预升级测试，确保未被发现的bug能够被发现，使用一套小的镜像环境，这个测试环境可以在自己的云上来做，也可以在公有云。如有可能，我们强烈建议将生产环境里的db表dump出来，并且在测试环境使用这些数据来做升级测试。
升级级别
升级级别是在G版就加入到OpenStack的一个特性，用来提供版本锁定不同计算服务之间的消息传递锁。作为一个很重要的功能，这个功能保证了OpenStack服务在在线升级的过程中保证不同版本之间能够正常交互。
如果没有升级级别，X+1版本的compute服务能够接受和识别X版本的RPC消息。举个栗子，一个nova-conductor服务已经升级到x+1版本，则它也能够接受和识别来自于nova-compute服务X版本的消息，但是compute服务不能识别conductor发过来的消息。
在升级的过程中需要在nova.conf中增加一些配置项，从而来锁定RPC消息的版本，来保证无中断升级服务。这些配置项支持指定RPC版本号，也支持指定release名。e.g.
这样，可以保证RPC版本被锁定在x+1之内，当特定的服务升级以后，就删除相应的行。
2. 一般升级流程
i. 首要条件
ii. 备份
iii. 升级每个节点的如软件包
基于指定的配置文件，升级所有的包，当然也有可能会重启或中断某个以来的服务，例如，使用TGT iSCSI框架来提供块存储服务，则升级包的时候会重启这个，从而影响卷的连接性。
如果包管理器要更改你的配置文件，选择拒绝，则包管理器将会重新生成一个新的配置文件（带一个后缀来区分）
iv. 升级服务
为了升级每一个节点上的服务，则需要修改配置文件，停止服务，升级数据库，再启动服务，推荐每升级一个服务就验证一个服务。
控制节点
存储节点
计算节点
v. 最后一步
3. 升级失败回滚
由于从K版开始，OpenStack不再支持db的降级，因此一旦升级失败，db的回滚只能考恢复db的备份。通常的场景是记下管理服务， 完成升级流程，发现测试过程中未遇到的问题，因此，你需要回滚环境到初始的“已知健康的”状态，没有新创建虚拟机、网络、卷等。所有的这些新的资源将会处于冻结状态知道db从备份中恢复。
下面是回滚操作需要考虑的点
需要确保你做了足够的备份来为恢复做准备。 回滚操作是一个危险的流程，因为我们花了更多的努力在升级上而不是降级。降级出现问题将会更加难于定位解决。你需要自己评估和承担降级的风险，通常，这会是迫不得已的选择。
回滚操作（以Ubuntu安装为例）
Refrence
[1] http://cloudgeekz.com/71/how-to-setup-openstack-to-use-local-disks-for-instances.html
[2] http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/Rolling_updates_OpenStack_WP.pdf
[3] https://access.redhat.com/articles/1169003