从故障计算节点恢复¶

如果您使用共享文件系统部署 Compute，可以使用几种方法快速从节点故障中恢复。本节讨论手动恢复。

迁移实例¶

如果硬件故障或其他错误导致云计算节点失败，可以使用 nova evacuate 命令迁移实例。有关使用该命令的更多信息，请参阅迁移实例。

手动恢复¶

要手动恢复故障计算节点

使用 openstack server list 和 openstack server show 命令的组合来识别受影响主机上的虚拟机。

查询 Compute 数据库以获取主机的状态。此示例将 EC2 API 实例 ID 转换为 OpenStack ID。如果您使用 nova 命令，可以直接替换 ID。以下输出已截断

mysql> SELECT * FROM instances WHERE id = CONV('15b9', 16, 10) \G;
*************************** 1. row ***************************
created_at: 2012-06-19 00:48:11
updated_at: 2012-07-03 00:35:11
deleted_at: NULL
...
id: 5561
...
power_state: 5
vm_state: shutoff
...
hostname: at3-ui02
host: np-rcc54
...
uuid: 3f57699a-e773-4650-a443-b4b37eed5a06
...
task_state: NULL
...

注意

在 /etc/nova.conf 文件中找到数据库的凭据。

决定将受影响的虚拟机迁移到哪个计算主机。运行此数据库命令将虚拟机迁移到该主机
```
mysql> UPDATE instances SET host = 'np-rcc46' WHERE uuid = '3f57699a-e773-4650-a443-b4b37eed5a06';
```
如果使用依赖于 libvirt 的 hypervisor，例如 KVM，请更新 libvirt.xml 文件，该文件位于 /var/lib/nova/instances/[instance ID] 中，并进行以下更改
- 将 DHCPSERVER 值更改为新计算主机的 IP 地址。
- 将 VNC IP 更新为 0.0.0.0。

重新启动虚拟机

$ openstack server reboot 3f57699a-e773-4650-a443-b4b37eed5a06

通常，数据库更新和 openstack server reboot 命令可以从故障主机恢复虚拟机。但是，如果问题仍然存在，请尝试以下操作之一

使用 virsh 重新创建网络过滤器配置。
重新启动 Compute 服务。
更新 Compute 数据库中的 vm_state 和 power_state 字段。

从 UID/GID 不匹配中恢复¶

有时，当您使用共享文件系统或自动化配置工具运行 Compute 时，计算节点上的文件可能会使用错误的 UID 或 GID。这种 UID 或 GID 不匹配可能会阻止您运行实时迁移或启动虚拟机。

此过程在基于 KVM hypervisor 的 nova-compute 主机上运行

在所有主机的 /etc/passwd 文件中将 nova UID 设置为相同数字。例如，将 UID 设置为 112。

注意

选择未被其他用户或组使用的 UID 或 GID。
在所有主机的 /etc/passwd 文件中将 libvirt-qemu UID 设置为相同数字。例如，将 UID 设置为 119。
在所有主机的 /etc/group 文件中将 nova 组设置为相同数字。例如，将组设置为 120。
在所有主机的 /etc/group 文件中将 libvirtd 组设置为相同数字。例如，将组设置为 119。
停止计算节点上的服务。

更改 nova 用户或组拥有的所有文件。例如

# find / -uid 108 -exec chown nova {} \;
# note the 108 here is the old nova UID before the change
# find / -gid 120 -exec chgrp nova {} \;

如果需要，对 libvirt-qemu 文件重复所有步骤。
重新启动服务。
要验证所有文件是否使用正确的 ID，请运行 find 命令。

灾后恢复云¶

本节介绍如何在灾难后管理您的云并备份持久存储卷。即使在非灾难情况下，备份也是强制性的。

有关灾难恢复计划 (DRP) 的定义，请参阅 https://en.wikipedia.org/wiki/Disaster_Recovery_Plan。

磁盘崩溃、网络丢失或电源故障会影响云架构中的多个组件。云的最大灾难是电源丢失。电源丢失会影响以下组件

云控制器 (nova-api、nova-conductor、nova-scheduler)
计算节点 (nova-compute)
由 OpenStack Block Storage (cinder-volumes) 使用的存储区域网络 (SAN)

在电源丢失之前

从 SAN 到云控制器的活动 iSCSI 会话（用于 cinder-volumes LVM 的 VG）。
从云控制器到计算节点的活动 iSCSI 会话（由 cinder-volume 管理）。
为每个卷创建一个 iSCSI 会话（因此 14 个 EBS 卷需要 14 个 iSCSI 会话）。
从云控制器到计算节点创建 iptables 或 ebtables 规则。这允许从云控制器访问正在运行的实例。
将数据库的当前状态、正在运行的实例的当前状态以及附加的卷（挂载点、卷 ID、卷状态等）保存至少从云控制器到计算节点。

在恢复电源并重新启动所有硬件组件后

SAN 到云的 iSCSI 会话不再存在。
云控制器到计算节点的 iSCSI 会话不再存在。
实例停止运行。

实例不会丢失，因为既没有运行 destroy 也没有运行 terminate。实例的文件保留在计算节点上。
数据库不会更新。

开始恢复

警告

请勿添加任何步骤或更改此过程中的步骤顺序。

检查卷与其实例之间的当前关系，以便您可以重新创建附件。

使用 openstack volume list 命令获取此信息。请注意，openstack 客户端可以从 OpenStack Block Storage 获取卷信息。

使用以下查询更新数据库以清理停滞状态。为每个卷执行此操作

mysql> use cinder;
mysql> update volumes set mountpoint=NULL;
mysql> update volumes set status="available" where status <>"error_deleting";
mysql> update volumes set attach_status="detached";
mysql> update volumes set instance_id=0;

使用 openstack volume list 命令列出所有卷。

使用 openstack server reboot INSTANCE 命令重新启动实例。

重要提示

一些实例完全重新启动并可访问，而另一些可能会停留在 plymouth 阶段。这是预期行为。不要第二次重新启动。

此阶段的实例状态取决于您是否为该卷添加了 /etc/fstab 条目。使用 cloud-init 包构建的镜像将保持在 pending 状态，而其他镜像将跳过缺失的卷并启动。您执行此步骤以要求 Compute 重新启动每个实例，以便保留存储的状态。即使并非所有实例都成功启动，也无关紧要。有关 cloud-init 的更多信息，请参阅 help.ubuntu.com/community/CloudInit/。

如果需要，运行 openstack server add volume 命令将卷重新附加到各自的实例。此示例使用列出卷的文件来重新附加它们

#!/bin/bash

while read line; do
    volume=`echo $line | $CUT -f 1 -d " "`
    instance=`echo $line | $CUT -f 2 -d " "`
    mount_point=`echo $line | $CUT -f 3 -d " "`
        echo "ATTACHING VOLUME FOR INSTANCE - $instance"
    openstack server add volume $instance $volume $mount_point
    sleep 2
done < $volumes_tmp_file

停留在 plymouth 阶段的实例现在会自动继续启动并正常启动。先前成功启动的实例现在可以看到该卷。

使用 SSH 登录到实例并重新启动它们。

如果某些服务依赖于该卷，或者该卷在 fstab 中有一个条目，现在可以重新启动该实例。直接从实例本身而不是通过 nova 重新启动
```
# shutdown -r now
```
在计划和完成灾难恢复时，请遵循以下提示

在 fstab 文件中使用 errors=remount 选项以防止数据损坏。

如果发生 I/O 错误，此选项会阻止写入磁盘。将此配置选项添加到执行与 SAN 的 iSCSI 连接的 cinder-volume 服务器以及实例的 fstab 文件中。
请勿将 SAN 磁盘的条目添加到 cinder-volume 的 fstab 文件中。
某些系统会停在该步骤，这意味着您可能会失去对云控制器的访问权限。要手动重新运行会话，请在执行挂载之前运行此命令
# iscsiadm -m discovery -t st -p $SAN_IP $ iscsiadm -m node --target-name $IQN -p $SAN_IP -l
在您的实例上，如果您在磁盘上有整个 /home/ 目录，请留下一个用户的目录，其中包含用户的 bash 文件和 authorized_keys 文件，而不是清空 /home/ 目录并将其映射到磁盘。

此操作使您能够在未附加卷的情况下连接到实例，如果您仅允许通过公钥进行连接。

要重现电源丢失，请连接到运行该实例的计算节点并关闭 iSCSI 会话。不要使用 openstack server remove volume 命令分离卷。您必须手动关闭 iSCSI 会话。此示例关闭编号为 15 的 iSCSI 会话

# iscsiadm -m session -u -r 15

不要忘记 -r 选项。否则，所有会话都会关闭。

警告

在执行此过程时，存在数据丢失的可能。如果您使用的是 Liberty 或更早版本，请确保您已应用正确的补丁并相应地设置选项。

从故障计算节点恢复

从故障计算节点恢复¶

迁移实例¶

手动恢复¶

从 UID/GID 不匹配中恢复¶

灾后恢复云¶

nova 32.1.1.dev2

页面内容