引 言

ZStack是开源的云计算IaaS(基础架构即服务)软件。通过提供的API来管理包括计算、存储和网络在内的数据中心的各种资源。跟OpenStack相比，ZStack具有易用、稳定、灵活等特点。

ZStack版本升级非常简单，官方的安装包已经做到了快捷，安全，简单。但是当前主流的Zstack系统的版本则横跨Centos7.2，Centos7.4，Centos7.6三个版本。虽然Zstack系统中可同时存在三个版本的宿主系统，但因安全或者其他驱动或内核因素，系统升级成为强需求。

Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。ceph 的统一体现在可以提供文件系统、块存储和对象存储，分布式体现在可以动态扩展。在国内一些公司的云环境中，通常会采用 ceph 作为Xstack，OpenStack 等唯一后端存储来提高数据转发效率。

XSKY主体的两个新产品——面向云计算场景的“X-CBS存储”和面向通用应用场景的“X-EBS存储”。这两个产品是基于主流开源存储系统Ceph的SDS解决方案。可替代传统SAN存储，满足企业云计算环境和通用业务环境的数据持久化需求。主要有以下特点：

  • 具备与传统SAN存储相当的丰富接口与技术，如Fiber Channel，iSCSI，SCSI，存储多路径等
  • 支持存储卷动态QoS调整和数据恢复流量控制，适应企业业务压力周期性在线变化
  • 在线扩展，全冗余架构，互联网化自运维特性
  • 统一的图形化管理，直观、简单、易用
  • 软件与硬件充分解耦，适配通用硬件；为NVMe新存储协议与高速网络充分优化，发挥高性能
  • 充分适应大多数应用负载与应用场景，无缝支持OpenStack，Zstack云

openstack多少种版本 openstack哪个版本最稳定_重启

系统的升级，并不困难，但当多种软硬件环境融合在一起(私有云超融合)的时候，那么如果还是按照一般的系统升级步骤进行升级，则可能带来灾难级别的故障。这也是我们所经历过的。复杂的环境升级遵循分级操作的原则，优先升级不影响业务但相对核心的节点，然后对核心节点进行业务迁移以及节点拆分的方式进行不停服升级。

系统的升级ZStack官网并没有给出对应的升级操作指南。因此，我们在多次的升级实践中总结出以下的升级流程以及原则。

升级信息

以下信息需在升级之前进行确认，本文主要针对的是ZStack与xsky/Ceph的超融合环境。

  1. 环境配置确认
  • 版本信息：操作系统，zstack，存储版本，存储类型等。
  • 部署信息：a. 超融合(存储 Mon是否独立) b. 计算与存储独立 c. 网络类型。
  • 容量信息：管理、计算以及存储节点数量，虚拟机数量，超融合情况下存储容量等信息。
  • 平台资源使用信息：计算，存储等资源用量统计，平台当前压力统计等。

特殊说明

  • 超融合的情况下，XSKY MON节点是否独立部署，如共享计算的情况下，则要优先升级。
  • 如使用VPC 类型的网络，确认VPC 虚拟路由已经迁移。
  • 管理节点是否需要升级，如管理共享计算，则要优先升级(升级之前做好备份)。
  • 超融合情况下，单台计算存储节点的数据量有多少，数据量不多的情况下推荐，数据迁移。如较多的话，升级时关闭数据均衡，进入维护模式。

这里有几个重要步骤，推荐在计划任何ZStacl升级时采取

  1. 通篇详读Zstack版本注释，以识别出潜在的版本间的不兼容性。尤其在对原生代码更改的情况下，比如对接商业存储后引起的配置的不兼容。
  2. 选择合适的方法升级Zstack系统以及确认升级的目的。本质上Zstack的版本不受系统版本的影响。
  3. 准备一个升级失败的回滚计划。随时准备回滚。得益于Zstack服务都为无状态，如控制节点的升级失败，导回数据可恢复。
  4. 准备一个数据备份计划，至少，带有配置文件和数据库的备份。以及提前准备好新版本配置文件。配置文件不会因为软件的升级而升级，需要手工更新。
  5. 依照特定服务的SLAs，定一个可接受的云停机时间，如果可能存在数据丢失，服务的中断时间。升级期间尽量不要操作云平台。
  6. 在有条件的情况下，提前与平台用户核对各种情况，确认平台是否有特殊的配置。

升级目标

  • 平滑升级，业务无影响，升级后功能组件正常。
  • 最短服务暂停时间。但云主机，云盘以及网络等云资源正常工作。
  • 升级失败可立刻回退。回退后可继续提供云服务。

升级前准备

  1. 云主机以及数据迁移
    a. 升级涉及重启，所以需要提前将本计算节点上的虚拟机迁移到其他正常工作的资源空余节点。
    b. 超融合根据数据量确定迁移，最佳但最慢的做法是：计算存储同时迁移，升级后再进行迁移已经均衡。如需快速升级，那关闭存储数据均衡，仅仅迁移云主机以及VPC路由器。
  2. 确定节点升级顺序
    a. 优先升级控制与计算共享节点
    b. 其次升级Mon与计算共享节点
    c. 最后按照顺序升级独立计算节点
  3. 升级前确认zstack计算节点处于维护模式，XSKY/Ceph节点处于空停止均衡状态(维护状态)
  4. 备份zstack数据(数据库以及配置文件)，在控制升级失败的情况下回滚
  5. 升级前请确认当前系统有足够的升级空间(升级镜像和升级报错日志可能会占用大量的磁盘空间)
  6. 升级前确认业务低峰点，选择合适的升级时间
  7. 准备好同zstack版本的不通版本的升级镜像，比如当前Zstack基于centos7.4的3.3版本升级为centos7.6的3.7版本，请提前准备好Zstack 3.7 Centos7.6镜像，验证镜像md5值

升级操作

升级的操作需在准备工作全部完成后进行，升级之前请登录系统，确认当前升级节点已无任何业务虚拟机，且流量趋近于0，同时确认配置备份已经完成。升级过程需小心谨慎。在超融合的情况下，升级相对复杂一些，升级的不仅仅是计算节点，同时也是存储节点。

不管是zstack还是xsky/Ceph，只要官方版本确认对系统的支持，那么就可以满足升级的条件。

升级涉及到的工具：

  • 升级命令工具：zstack-upgrade
  • 网络配置工具：zs-network-setting，zs-bond等zstack内置网络管理工具
  • 服务重启工具：systemctl start/restart/status libvirtd/sshd 等

本次升级核心命令为zstack-upgrade,使用该命令之前，确认版本，否则需要下载匹配当前zstack版本的zstack-upgrade工具，zstack-upgrade 详细的命令参数如下：

# zstack-upgrade -hUsage: /usr/local/bin/zstack-upgrade [-h] [-a] [-r] [-F] LOCAL_ISO_PATH|REMOTE_ISO_LINKOptional arguments: -hShow help message -a/--add_repoAdd a new repo -rOnly upgrade ZStack local repo -FDo force database upgrating.  NOTE: only use -F when you know exactly what it does

升级流程如下：

  1. 下载需要升级的zstack操作系统版本，请注意保持zstack版本不变，zstack-upgrade也请匹配当前版本：
    wget -c http://files.tyun.cn/zstack/iso/ZStack-x86_64-DVD-3.7.1-c76.iso
  2. 确认当前系统的可用空间，确认升级需求，确认当前节点已不存在运行的虚拟机：
# # virsh list --all Id    Name                           State----------------------------------------------------# df -hFilesystem               Size  Used Avail Use% Mounted on/dev/mapper/zstack-root  491G  8.9G  483G   2% /devtmpfs                 7.8G     0  7.8G   0% /devtmpfs                    7.8G     0  7.8G   0% /dev/shmtmpfs                    7.8G  8.8M  7.8G   1% /runtmpfs                    7.8G     0  7.8G   0% /sys/fs/cgroup/dev/vda1               1014M  173M  842M  18% /boottmpfs                    1.6G     0  1.6G   0% /run/user/0# uname -srLinux 3.10.0-693.11.1.el7.x86_64# ceph -s
  1. 确认存储XSKY已经设置为维护模式，同步在控制节点上调整该节点为维护模式
  2. 使用zstack-upgrade已经zstack的镜像进行升级
    计算节点如果没有zstack-ctl可能会有报错，但可以忽略：
# 更新新版本操作系统镜像源，默认位置为/opt/zstack-dvd# zstack-upgrade -a ZStack-x86_64-DVD-3.7.1-c76.iso
  1. 修改yum源，使用新的yum源，进行升级操作
    zstack的默认yum源为本地的yum源，名称为zstack-local.repo，默认内容是匹配当前操作系统的版本，当前的目的是升级为新版本的操作系统，本次环境为c74升级为c76，修改为如下配置即可：
# cat zstack-local.repo[zstack-local]name=zstack-localbaseurl=file:///opt/zstack-dvd/$basearch/c76gpgcheck=0enabled=1# yum clean all# yum makecache fast# yum update -y

如果系统曾经安装过其他非zstack内置工具，升级的过程中可能会有软件包依赖错误，此时可以到centos官网镜像厂库下载对应的依赖包即可。升级过程请不要人为中断，可以使用screen或者tmux进行升级操作。

升级完成后，请用如下命令配置yum源：

# zstack-upgrade -r ZStack-x86_64-DVD-3.7.1-c76.iso
  1. 升级后请不要急着重启系统，请确认系统版本是否为升级后的版本
# cat /etc/redhat-releaseCentOS Linux release 7.6.1810 (Core)# uname -srLinux 3.10.0-693.11.1.el7.x86_64
  1. 配置检测
    默认情况下，操作系统的升级不会引起zstack与xsky的软件版本的变更，但可能会引起一些相关关联的软件版本变更，比如qemu-kvm，libvirt等一系列软件包。
  2. 重启系统
    操作系统的升级一般推荐进行重启系统。否则后期会有不可知的问题。
    重启系统之前推荐手工关闭服务，通过系统命令进行软关机，请不要强制断电重启。
  3. 当系统重启完成后，请优先解除zstack 升级节点的维护模式，重连，确认计算节点可以成功连接
    在一些场景中可能会出现网络丢失的情况，此时请重新配置，或者使用网络备份文件进行恢复。
    当计算节点成功后，请解除存储的维护模式，确认数据均衡，存储工作正常。
    如果zstack计算节点重连失败，重启libvirtd以及virtlogd服务，同时stop zstack-kvmagent，界面上重新连接计算节点，由控制节点去管理以及启动 zstack-kvmagent
# /etc/init.d/zstack-kvmagent stop
# service libvirtd restart
# service virtlogd restart

如果xsky存储启动失败，可以手工更新os对应的xdc包，从产品安装包sds-release的packages下提取xdc-SDS_xxx.x86_64.rpm并更新。

# tar -xzvf sds-release# cd packages# rpm -Uvh xdc-SDS_xxx.el7.x86_64.rpm# systemctl status xdc

其他节点如有问题，也可以进行同样的操作。

升级验证

当节点升级完成且成功连接到计算节点后，此时需要验证计算节点是否可以正常工作，存储能力是否受到影响，升级的目的(安全修复等)是否达到。

  1. 云平台功能验证
    功能的验证比较简单，可以迁移或者创建一台虚拟机(非核心业务)到该节点，然后进行开关机，网卡添加，qos限制，监控，备份，快照等等功能。
  2. 存储平台功能验证
    云平台上确认基于xsky/ceph的主存储功能正常，创建新卷关联到虚拟机，xsky/ceph管理后台查看卷状态。
    在xsky/ceph管理后台的资源管理部分查看缓存，硬盘以及服务器的状态，确认升级后改节点的存储能力正常。
  3. 云平台性能验证
    云平台的性能主要包含网络性能，计算性能以及存储性能，测试的方式可以使用iperf3测试网络性能，unixbench测试计算能力，fio测试存储能力，本处的存储为本地盘。
  4. 存储平台性能验证
    云平台的存储性能验证主要体现在云盘上，测试工具为fio。
  5. 综合验证
    当多个计算节点升级完毕后，推荐进行全功能以及性能的验证。

日志查看

日志能够帮助我们深入学习 zstack和排查问题。但要想高效的使用日志还得有个前提：必须先掌握 zstack 的运行机制，然后针对性的查看日志。

对于zstack的运维和管理员来说，在大部分情况下，我们都不需要看源代码。因为 zstack的日志记录得很详细了，足以帮助我们分析和定位问题。

因此，最后我们需要确认所有服务的日志无报错。如果需要，可以临时打开Debug。服务正常后请关闭Debug，否则影响性能。

  1. 系统日志：
  • /var/log/messages：存放的是系统的日志信息，它记录了各种事件，基本上什么应用都能往里写日志，在做故障诊断时可以首先查看该文件内容
  • /var/log/yum.log：yum升级日志，通过yum升级的所有内容都会在该日志中显现

zstack日志：

  • /var/log/zstack/zstack-kvmagent.log：该日志为计算节点上zstack的kvmagent日志，如管理节点管理计算节点上的虚拟机异常，可以查看该日志
  • /var/log/zstack/zstack.log: 该日志包含控制节点管理计算节点的所有日志，包含网络，存储等等。
  • /var/log/zstack/zsblk-agent/zsblk-agent.log：该日志包含存储管理的日志，比如sharedblock
  • /var/log/zstack/zsn-agent: 该日志主要包含计算节点上网络相关的日志

kvm虚拟机日志：

  • /var/log/libvirt/qemu：该目录包含所有虚拟机的日志，如虚拟机启动异常，可以在该目录下找到对应的虚拟机的相应日志

控制节点的日志：

  • /usr/local/zstack/apache-tomcat/logs：该目录包含zstack控制节点的所有日志，zstack的控制常规错误都能在该日志下发现

其他

ZStack发展到如今的3.8版本，不管是升级还是使用管理，只要合理规划，完全可以实现安全，无缝不停机快速升级。

在生产环境进行升级之前一定要提前进行测试，尤其是在跨比较多的版本或者本身环境就比较复杂的情况下。配置项的缺失或者错误导致服务不正常还是经常发生的。升级后一定要进行充分的测试，以及日志错误的排除。

如果需要进行操作系统的升级，控制节点可以一台台升级，计算节点可以先迁移虚拟机，然后再进行升级重启。

本文针对升级的环境跨度比较大，是ZStack与XSKY/Ceph的超融合环境，商业的解决方案并不意味着绝对的安全，稳定。合理的规划，合理的使用才是平台稳定的基石。