OpenStack 实例正确设置九大技巧

在 OpenStack 的术语中，一个实例就是一台虚拟机，即客机工作负载。它从操作系统镜像中启动，并且配置有特定数量的 CPU、RAM 和磁盘空间，以及其他参数，例如网络或安全设置。

在红帽资深顾问 Marko Myllynen 撰写的这篇博文中，我们将探索九个 OpenStack 配置和优化选项，帮助您的工作负载实现所要求的性能、可靠性和安全性。

无论 OpenStack 云管理员在您的云环境中启用了什么功能，某些优化可在客机内进行。然而，更先进的选项要求提前启用，而且可能需要特殊的主机能力。这意味着本文介绍的许多选项取决于管理员如何配置云环境，或者可能在某些租户中不可用，因为这些选项是为某些用户组预留的。关于本主题的更多信息可见红帽文档门户和红帽 OpenStack 镜像服务综合指南。同时，上游 OpenStack 文档也提供了一些额外指导准则。

对于在任何 OpenStack 环境中运行的任何虚拟机，需要对以下配置进行评估。这些变更没有负面影响，而且即使未使用，一般也可以安全地启用。

01、镜像格式：QCOW 还是 RAW？

OpenStack 存储配置是云管理员的一个实施选项，而租户通常无法完整看到。存储配置也可能随着时间推移而变化，而无需管理员明确通知，因为他 / 她通过不同的规范而在配置中增加了容量。

在 OpenStack 上创建新实例时，该实例基于 Glance 镜像。两种最常见并且推荐使用的镜像格式是 QCOW2 和 RAW。QCOW2 镜像（来自 QEMU Copy On Write）的体积更小。以拥有一块 100 GB 磁盘的服务器为例，RAW 格式的镜像如果格式化为 QCOW2 格式，其大小可能仅 10 GB。无论哪种格式，在通过 virt-sysprep ( 1 ) 和 virt-sparsify ( 1 ) 将镜像上传到 Glance 之前都需要进行处理。

QCOW2 的性能取决于系统管理程序内核和格式版本，最新版本为 QCOW2v3（有时称为 QCOW3），比先前的 QCOW2 性能更优秀，与 RAW 格式基本相同。总体来讲，我们假设 RAW 的整体性能更好，尽管在运行方面存在缺陷（例如缺乏快照），或者上传或引导时间增加（由于体积更大）。最新的红帽 OpenStack Platform 版本自动采用更新的 QCOW2v3 格式（得益于最近的 RHEL 版本），而且该版本可以检查并且利用 qemu-img ( 1 ) 在 RAW 和更老 / 更新的 QCOW2 镜像间进行转换。

OpenStack 实例可以从本地镜像或者远程卷中引导。这意味着：

镜像支持的实例通过旧 QCOW2 与 QCOW2v3 和 RAW 间的性能差异而显著获益。

卷支持的实例可以从 QCOW2 或 RAW Glance 镜像中创建。然而，由于 Cinder 后端视特定供应商而不同（Ceph、3PAR、EMC 等），它们可能不采用 QCOW2 或 RAW。可能有自己的机制，例如重复数据删除、精简配置或者边写入边复制。需要特别注意的是，这并不支持在配有 Ceph 的 Glance 中使用 QCOW2。

根据一般经验，极少使用的镜像应以 QCOW2 格式存储在 Glance 中，但对于经常用于创建新事例（在本地存储）的镜像，或者用于创建卷支持的事例的镜像，使用 RAW 能够提供更好的性能，尽管有时初始引导时间更长（Ceph 支持的系统除外，原因是它采用了边写入边复制的方法）。最后，任何实际的建议都依赖于云管理员所选择的 OpenStack 存储配置。

02、通过镜像额外属性进行性能调整

从 Mitaka 版本起，OpenStack 允许 Nova 自动优化计算主机上的某些 libvirt 和 KVM 属性，目的是更好地执行客机中的特定 OS。要向 Nova 提供客机 OS 信息，只需定义以下 Glance 镜像属性：

os_type=linux # 通用名称，例如 linux 或 windows

os_distro=rhel7.1 # 使用 osinfo-query os 列出支持的变体

此外，至少在目前，为了保证使用更新和更具扩展能力的 virtio-scsi 超虚拟化 SCSI 控制器取代旧的 virt-blk，需要明确设置以下属性：

hw_scsi_model=virtio-scsi

hw_disk_bus=scsi

支持的所有镜像属性在红帽文档门户和其他 CLI 选项中列出。

03、为 Cloud-init 做好准备

"Cloud-init" 是用于云实例早期初始化的程序包，用于配置基本信息，例如分区 / 文件系统大小和 SSH 密钥。

您要保证已经在 Glance 镜像中安装了 cloud-init 和 cloud-utils-growpart 程序包，而且相关服务将在引导时执行，以允许执行针对 OpenStack VM 的 "cloud-init" 配置。

许多情况下可以接受默认配置，但也有许多定制选项可以使用。

04、启用 QEMU 客机代理

在 Linux 主机上，建议安装并启用 QEMU 客机代理，以允许正常关机和（将来）需要快照时客机文件系统的自动冻结，这是一致备份的必要操作：

yum install qemu-guest-agent

systemctl enable qemu-guest-agent

为了提供必需的虚拟设备，并且在需要时使用文件系统冻结功能，需要为 Glance 镜像定义以下属性：

hw_qemu_guest_agent=yes # 创建所需的设备，以允许客机代理运行

os_require_quiesce=yes # 接受文件系统冻结 / 解冻请求

05、从客机故障状态恢复

全面的实例故障恢复、高可用性和服务监控需要采用分层的方法。在下文中，我们列出了仅可用于客机内的选项（可视为最内层）。最常用的实例故障恢复机制有：

从内核瘫痪状态恢复

从客机挂起状态恢复（不一定涉及到内核瘫痪 / 错误）

在极少发生的客机内核瘫痪的情况下，kexec/kdump 将捕获内核 vmcore，用于提供进一步分析和客机重新引导。如果不需要 vmcore，通过设置错误内核参数，例如 "panic=1"，内核可以在瘫痪后按照指令重新引导。

为了在发生其他意外行为后对实例进行重新引导，例如某个阈值的高负荷，或者在没有内核错误时的整个系统锁定，可以使用 watchdog 服务。以下属性需要对 Glance 镜像或 Nova Flavor 而定义。

hw_watchdog_action=reset

然后，在客机内安装与配置 watchdog 程序包，最后启用该服务：

yum install watchdog

vi /etc/watchdog.conf

systemctl enable watchdog

根据默认设置，watchdog 检测到内核瘫痪和整个系统锁定。例如，如何在 watchdog 功能检查过程中添加健康监控脚本。

06、调试内核

调试 Linux 代码的最简单方式是使用 "tuned" 工具。这种服务可根据所选的档案配置几十个系统参数，对于 OpenStack，它是 " 虚拟客机 "。对于 NFV 工作负载，红帽提供了一组 NFV 调试档案，用于简化网络密集型虚拟机的调试。

在您的 Glance 镜像中，建议安装所要求的程序包，在引导时启用服务，然后激活首选的档案。您可以在将镜像上传到 Glance 之前编辑镜像，也可以作为 cloud-init 配置的一部分：

yum install tuned

systemctl enable tuned

tuned-adm profile virtual-guest

07、通过 VirtIO 多队列增强网络能力

客机内核 virtio 驱动程序是标准 RHEL/Linux 内核程序包的一部分，并且自动启用，而不需要根据需要进一步配置。对于特定的 Windows 版本，Windows 客机也应使用官方 virtio 驱动程序，用于显著提高网络和磁盘 IO 性能。

然而，在 Linux 内核和用户空间组件中网络程序包处理方面，最新的发展提供了大量用于调试或绕开 virtio 驱动程序的额外选项。下文列出了一种 virtio 设备模型。

网络多队列（或者叫 virtio-net 多队列）方法实现了并行数据包处理，这样能够随着客机可用 vCPU 数量而线性扩展，从而实现传输速度的显著提高，特别是对于 vhost-user。

由于 OpenStack Admin 配置了带有支持组件的虚拟化主机（至少 OVS 2.5 / DPDK 2.2），这一功能可由 OpenStack Tenant 通过需要网络多队列的这些 Glance 镜像中的以下属性启用：

hw_vif_multiqueue_enabled=true

在从该镜像完成初始化的客机中，可通过以下命令检查并更改 NIC 通道设置：

ethtool -l eth0 # 用于查看当前队列的数量

ethtool -L eth0 combined # 用于设置队列的数量。应与 vCPU 数量相符。

另外有一个开放 RFE，用于实施多队列激活，这是内核中的默认功能。

08、客机的其他杂项调试

毫无疑问，规模适当的实例仅包含最少的程序包，并且仅运行所需的服务。特别需要注意的是，安装并启用 irqbalance 服务可能是一种很好的做法，尽管这并非在所有情况下都绝对有必要，但该服务的开销最低，并且应该在 SR-IOV 设置中使用。

即使在 KVM 上采用隐性设置，明确添加内核参数 no_timer_check 是一种很好的做法，这可以避免定时设备出现问题。分别使用 PERSISTENT_DHCLIENT=yes 和 NOZEROCONF=yes 启用永久 DHCP 客户端，并禁用网络配置中的 zeroconf 路径有助于避免网络极端状况的问题。

根据默认设置，客机 MTU 设置一般都能够正确地调整，但在堆栈的所有级别使用正确的 MTU 对于实现最高网络性能至关重要。在配有 10G（以及更快）NIC 的环境中，这一般意味着要使用 MTU 高达 9000 的 Jumbo Frames，同时考虑可能的 VXLAN 封装。

09、改善您接入实例的方式

尽管某些纯粹主义者可能考虑在纯云原生实例中以不兼容的方式运行 SSH，尤其是在自动扩展的生产工作负载中，但我们绝大多数人仍然依赖优秀的旧有 SSH 来执行配置任务（例如通过 Ansible）以及维护和故障排除（例如，在软件故障后提取日志）。

SSH daemon 应避免 DNS 查询，目的是加快建立 SSH 连接。对于这一要求，考虑在 /etc/ssh/sshd_config 中采用 UseDNS no，并向 /etc/sysconfig/sshd 增加 OPTIONS=-u0。如果未使用 Kerberos，可以考虑设置 GSSAPIAuthentication no。如果实例频繁地互相连接，也可以考虑 ControlPersist / ControlMaster 选项。

一般来说，远程 SSH 接入和采用 Horizon 通过控制台接入对于大多数情况已经足够。在开发阶段，从 Nova 计算主机直接通过控制台接入也可能很有帮助，要做到这一点，需启用 serial-getty@ttyS1.service，允许根据需要通过向 /etc/securetty 添加 ttyS1 而通过 ttyS1 进行根接入，然后利用 virsh console – devname serial1 从 Nova 计算主机接入客机控制台。

原文：http://app.myzaker.com/news/article.php?pk=59acd8d51bc8e02535000008