多节点OpenStack Charms 部署指南0.0.1.dev303--21--控制器备份和还原

最新推荐文章于 2021-11-29 08:57:27 发布

injexengge

最新推荐文章于 2021-11-29 08:57:27 发布

阅读量206

点赞数

分类专栏： juju openstack maas 文章标签： ssh linux 运维

本文链接：https://blog.csdn.net/m0_49212388/article/details/115367100

版权

juju 同时被 3 个专栏收录

60 篇文章 2 订阅

订阅专栏

openstack

56 篇文章 4 订阅

订阅专栏

maas

55 篇文章 1 订阅

订阅专栏

目录：
第一节多节点OpenStack Charms 部署指南0.0.1.dev223–1--OpenStack Charms 部署指南
 第二节多节点OpenStack Charms 部署指南0.0.1.dev223–2-安装MAAS

第三节多节点OpenStack Charms 部署指南0.0.1.dev223–3-安装Juju

第四节多节点OpenStack Charms 部署指南0.0.1.dev223–4-安装openstack

第五节多节点OpenStack Charms 部署指南0.0.1.dev223–5--使bundle安装openstack

第六节多节点OpenStack Charms 部署指南0.0.1.dev223–6--配置vault和设置数字证书生命周期

第七节多节点OpenStack Charms 部署指南0.0.1.dev223–7--juju 离线部署bundle

第八节多节点OpenStack Charms 部署指南0.0.1.dev223–8--配置 OpenStack

附录 t 多节点OpenStack Charms 部署指南0.0.1.dev223–附录T–OpenStack 高可用性

第九节多节点OpenStack Charms 部署指南0.0.1.dev223–9--网络拓扑

第十节多节点OpenStack Charms 部署指南0.0.1.dev223–10–OpenStack 高可用基础架构实际

第十一节多节点OpenStack Charms 部署指南0.0.1.dev223–11–访问Juju仪表板

第十二节多节点OpenStack Charms 部署指南0.0.1.dev223–12–OpenStack 配置openstack失败后处理

第十三节多节点OpenStack Charms 部署指南0.0.1.dev223–13–OpenStack配置高可用后无法登陆openstack dashboard

第十四节多节点OpenStack Charms 部署指南0.0.1.dev223–14–ssh端口转发解决IDC机房国际线路不良问题

第十五节多节点OpenStack Charms 部署指南0.0.1.dev299–15–OpenStack 实例高可用

第十六节多节点OpenStack Charms 部署指南0.0.1.dev299–16–OpenStack基础架构高可用The easyrsa resource is missing. .

第十七节多节点OpenStack Charms 部署指南0.0.1.dev303–17–修改实例数量等quota上限

第十八节多节点OpenStack Charms 部署指南0.0.1.dev303–18–backup备份

第十九节多节点OpenStack Charms 部署指南0.0.1.dev303–19–juju log

第二十节多节点OpenStack Charms 部署指南0.0.1.dev303–20–控制器高可用性

第二十一节多节点OpenStack Charms 部署指南0.0.1.dev303–21–控制器备份和还原

第二十二节多节点OpenStack Charms 部署指南0.0.1.dev223–22-- Resource: res_masakari_haproxy not running

第二十三节多节点OpenStack Charms 部署指南0.0.1.dev223–23-登录openstack-dashboad，SSLError(SSLCertVerificationError

第二十四节多节点OpenStack Charms 部署指南0.0.1.dev223–24-Resource: res_masakari_f8b6bde_vip not running

第二十五节多节点OpenStack Charms 部署指南0.0.1.dev223–25–rsyslog 日志服务器构建实际

第二十六节多节点OpenStack Charms 部署指南0.0.1.dev223–26–跨model 建立关系构建rsyslog 日志服务器构建实际

第二十七节多节点OpenStack Charms 部署指南0.0.1.dev223–27–Charm Hook

第二十八节多节点OpenStack Charms 部署指南0.0.1.dev223–28–Command run

第三十节多节点OpenStack Charms 部署指南0.0.1.–30–参考体系结构—Dell EMC硬件上的Canonical Charmed OpenStack（Ussuri）

第三十一节多节点OpenStack Charms 部署指南0.0.1.–31–vm hosting-1

第三十二节多节点OpenStack Charms 部署指南0.0.1.–32–vm hosting-2-VM host networking (snap/2.9/UI)

第三十三节多节点OpenStack Charms 部署指南0.0.1.–33–vm hosting-3-Adding a VM host (snap/2.9/UI)

第三十四节多节点OpenStack Charms 部署指南0.0.1.–34–vm hosting-4-VM host存储池和创建和删除vm (snap/2.9/UI)

第三十五节多节点OpenStack Charms 部署指南0.0.1.–35–Command export-bundle备份opensack并重新部署openstack

第三十六节多节点openstack charms 部署指南0.0.1-36-graylog实际-1

第三十七节多节点openstack charms 部署指南0.0.1-37-graylog实际-2

第三十八节多节点openstack charms 部署指南0.0.1-38-graylog实际-3

第三十九节多节点openstack charms 部署指南0.0.1-39-graylog-4-filebeat

第四十节多节点openstack charms 部署指南0.0.1-40-prometheus2

参考文档：

Controller backups
Client
Juju Tricks
Restoring from a backup

控制器的备份使人们可以保存（并在以后重新建立）控制器的配置和状态。它不会影响后备云上的工作负载实例。也就是说，如果此类实例直接在云中终止，则控制器还原将无法重新创建该实例。

此页面将涵盖以下主题：

创建备份
管理备份
高可用性注意事项

有一个单独的页面，描述了如何从备份中还原。

juju控制器

Juju提供了用于在发生故障或控制器不再存在时恢复控制器的命令。

当前状态保存在“控制器”模型中。因此，所有备份命令都需要明确地在该模型内运行或通过确保当前模型为“控制器”模型来进行操作。在下面提供的示例中，控制器名称和型号名称均明确表示（例如-m aws：controller）。由于数据备份的微妙特性，强烈建议使用此方法

创建备份

create-backup命令用于创建备份。它是通过生成存档并将其作为“ tar.gz”文件（本地备份）下载到Juju客户端系统来实现的。如果使用
--keep-copy选项，则存档的副本也将保留在控制器上（远程备份）。借助--no-download选项，可以防止本地备份，但是由于存档必须保存在某处，因此该选项意味着--keep-copy。

备份的名称由创建时间（以UTC表示）和唯一标识符组成。

以下示例假定存在以下控制器（输出到juju controllers）：

Controller  Model    User   Access     Cloud/Region         Models  Machines    HA  Version
aws         default  admin  superuser  aws/us-east-1             2         1  none  2.3.7  
lxd*        default  admin  superuser  localhost/localhost       2         1  none  2.3.7

要创建“ aws”控制器的备份，请执行以下操作：

juju create-backup -m aws:controller

样本输出类似下面：
20180515-191942.7e45250b-637a-4dc9-8389-c6aa70100cd6
downloading to juju-backup-20180515-191942.tar.gz

从档案名称中，我们看到备份是在2018年5月15日UTC进行的。

存档文件名不包含关联的控制器名称。因此，从多个控制器进行归档时应格外小心。要指定自定义名称，请使用--filename选项。该选项不会影响远程归档名称。

要在使用自定义文件名并添加可选注释的同时创建“ lxd”控制器的备份，请执行以下操作：

juju create-backup -m lxd:controller --filename juju-backup-lxd-20180515-193724.tar.gz "fresh lxd controller"

可选注释通过下面详细介绍的show-backup命令公开。

无论云类型如何，新的（空）环境的备份大小约为83 MiB。

管理备份

以下命令可用于管理备份（除还原外）：

backups
show-backup
download-backup
upload-backup
remove-backup

`juju backups`

backups命令显示给定控制器的所有远程备份的名称。例如，要查看“ lxd”控制器的所有远程存储备份，请执行以下操作：

juju backups -m lxd:controller

输出类似下面：

20180515-193724.9c6a3650-2957-489a-8f0c-6c3b5ce2e055
20180515-195557.9c6a3650-2957-489a-8f0c-6c3b5ce2e055

`juju show-backup`

show-backup命令提供特定远程备份的元数据记录（通过backups命令标识）。例如，要查询存储在“ lxd”控制器上的备份，请执行以下操作：

juju show-backup -m lxd:controller 20180515-195557.9c6a3650-2957-489a-8f0c-6c3b5ce2e055

输出类似如下：

backup ID:       "20180515-193724.9c6a3650-2957-489a-8f0c-6c3b5ce2e055"
checksum:        "pmxx7bCwtZVV+KM48YKz5w6Boc0="
checksum format: "SHA-1, base64 encoded"
size (B):        58605244
stored:          2018-05-15 19:40:28 +0000 UTC
started:         2018-05-15 19:37:24 +0000 UTC
finished:        2018-05-15 19:37:41 +0000 UTC
notes:           "fresh lxd controller"
model ID:        "9c6a3650-2957-489a-8f0c-6c3b5ce2e055"
machine ID:      "0"
created on host: "juju-e2e055-0"
juju version:    2.3.7

开始时间是各种时间戳中最相关的。它指的是创建备份的时间。

`juju download-backup`

download-backup命令下载特定的远程备份（同样，通过backups命令标识）。在这里，我们下载了存储在“ aws”控制器中的备份：

juju download-backup -m aws:controller 20180515-191942.7e45250b-637a-4dc9-8389-c6aa70100cd6

`juju upload-backup`

upload-backup命令将特定的本地备份上传到控制器。例如：

juju upload-backup -m lxd:controller juju-backup-20180515-193724.tar.gz

无法上传与远程存储的备份等效的文件。该过程将被取消，并且将显示一条错误消息。

`juju remove-backup`

remove-backup命令从控制器中删除特定的远程备份。例如：

juju remove-backup -m aws:controller 20180515-191942.7e45250b-637a-4dc9-8389-c6aa70100cd6

要清理任何可能的远程备份，可以使用--keep-latest选项。此选项指示Juju删除所有远程备份，但最新创建的备份除外：

juju remove-backup -m aws:controller --keep-latest

从备份还原

要将环境的状态还原到以前的时间，请使用独立的juju-restore工具。

以前使用juju restore-backup命令，但是从Juju 2.9开始，该命令已弃用，而应使用juju-restore代替。

高可用性注意事项

尽管Controller高可用性使Juju基础架构更加健壮（并且负载均衡），但它不应取代对数据备份的需求。但是，这样做确实不太可能从备份还原，因为只要一个控制器群集成员保持运行状态，就可以通过enable-ha命令替换其他成员。因此，仅在所有控制器都发生故障时，才有必要在高可用性方案中进行还原。但是，如果将还原应用于具有活动成员的群集，则所有可访问的控制器自然会覆盖其数据。

由于完全群集故障而还原

在所有控制器无响应的情况下，应采取以下步骤：

卸下控制器
创建一个原始控制器
执行数据还原
启用高可用性

为了演示这一点，请考虑一个初始的基于AWS的名为“ aws-ha3-1”的控制器，其中包含三个集群成员。新的控制器将称为“ aws-ha3-2”：

juju kill-controller aws-ha3-1
juju bootstrap aws aws-ha3-2
# use juju-restore to perform the data restore
juju enable-ha -m aws-ha3-2:controller -n 3

实际操作步骤：

第一种方式：备份客户端方式

此页面涵盖了可以以管理员用户或普通用户身份应用于Juju客户端（用于管理Juju的软件）的各种操作。

涵盖以下主题：

客户目录
客户端备份
客户端升级

有关客户端的完整定义，请参见“概念”页面。

客户目录

Juju客户端目录在Ubuntu上位于 ~/.local/share/juju
除了您可以重新创建的凭据YAML文件之类的内容之外，该目录还包含Juju的SSH密钥等唯一文件，这些文件对于连接到Juju计算机是必不可少的。此位置也可能是charms或模型所需资源的所在地。

在Microsoft Windows上，该目录位于其他位置（通常为 C:\Users{username}\AppData\Roaming\Juju）

客户端备份

客户端的备份使用户可以重新获得对控制器和相关云环境的管理控制。

本节将涵盖以下主题：

创建备份
从备份还原

数据备份也可以通过Juju控制器进行。请参阅控制器备份页面以获取指导。

创建备份

复制客户端目录足以备份客户端。这通常是通过备份软件完成的，该备份软件将数据压缩为单个文件（存档）。在Linux / Ubuntu系统上，tar程序是常见的选择：

cd ~
tar -cpzf juju-client-$(date "+%Y%m%d-%H%M%S").tar.gz .local/share/juju

Microsoft Windows，任何本机Windows备份工具都可以。

上面的调用在生成的归档文件的文件名中嵌入了一个时间戳，这对于了解何时进行备份很有用。当然，您可以随心所欲地对其进行命名。

通常应将归档文件转移到另一个系统（或至少转移到另一个物理驱动器）以进行安全保存。

从备份还原

还原客户端设置很简单，只需提取先前创建的备份即可。对于Ubuntu：

cd ~
tar -xzf juju-yymmdd-hhmmss.tar.gz

此命令将提取存档的内容并覆盖Juju目录中的所有现有文件。确保这是您想要的。

客户端升级

客户端软件由操作系统的程序包管理系统管理。在Ubuntu上，传统上是APT：

sudo apt update
sudo apt install juju

如果Juju是通过快照安装的，则无需采取任何措施，因为默认情况下快照会自动更新。但是，这是手动更新的方法：

sudo snap refresh juju

可以查询当前的Juju snap版本：

snap info juju

有关更多安装信息以及可用版本的信息，请参见《参考：安装Juju》。

模型也可以升级。请参阅升级模型页面以获取指导

第二种备份方法

转储数据库内容
尽管存在juju create-backup，但是您可以通过登录到控制器并运行以下命令来转储原始Juju数据库：

datestamp=`date +"%Y-%m-%d_%H-%M-%S"`
conf=/var/lib/juju/agents/machine-*/agent.conf
user=`sudo grep tag $conf | cut -d' ' -f2`
password=`sudo grep statepassword $conf | cut -d' ' -f2`
mongodump -h 127.0.0.1:37017 --username $user --password $password --authenticationDatabase admin  --db juju -o mongodump --ssl --sslAllowInvalidCertificates
tar -zcf "juju-mongodump-${datestamp}.tar.gz" mongodump

第三种备份方法：

根据原文，应该使用juju create-backup 命令来备份。但是在开始尝试这个操作时，失败了，输出如下：

juju create-backup maas-controller:admin/controller --debug
11:37:37 INFO  juju.cmd supercommand.go:54 running juju [2.8.10 0 ba81843fc09ed04ae11e59595c1370b5dc242cf0 gc go1.14.15]
11:37:37 DEBUG juju.cmd supercommand.go:55   args: []string{"/snap/juju/15845/bin/juju", "create-backup", "maas-controller:admin/controller", "--debug"}
11:37:37 INFO  juju.juju api.go:67 connecting to API addresses: [10.0.0.155:17070]
11:37:37 DEBUG juju.api apiclient.go:1107 successfully dialed "wss://10.0.0.155:17070/model/d0337a9e-a090-49fc-8c21-35abfedb8b84/api"
11:37:37 INFO  juju.api apiclient.go:639 connection established to "wss://10.0.0.155:17070/model/d0337a9e-a090-49fc-8c21-35abfedb8b84/api"
11:37:39 DEBUG juju.api monitor.go:35 RPC connection died
ERROR while creating backup archive: while dumping juju state database: error dumping databases: error executing "/usr/bin/mongodump": fork/exec /usr/bin/mongodump: exec format error
11:37:39 DEBUG cmd supercommand.go:537 error stack:
while creating backup archive: while dumping juju state database: error dumping databases: error executing "/usr/bin/mongodump": fork/exec /usr/bin/mongodump: exec format error
/build/snapcraft-juju-35d6cf/parts/juju/src/rpc/client.go:178:
/build/snapcraft-juju-35d6cf/parts/juju/src/api/apiclient.go:1212:
/build/snapcraft-juju-35d6cf/parts/juju/src/api/backups/create.go:24:
/build/snapcraft-juju-35d6cf/parts/juju/src/cmd/juju/backups/create.go:210:
/build/snapcraft-juju-35d6cf/parts/juju/src/cmd/juju/backups/create.go:154:

当时尝试了几次，应该是和mongodump 相关。所以先用的上面第一种和第二种备份方案进行了备份。

在社区提问，答案是：要不重新bootstrap controller试试。

一狠心，juju kill-controller maas-controller了下，重新juju bootstrap --bootstrap-series=focal --constraints tags=juju mymaas maas-controller了下，

再juju add-model openstack，增加openstack模型，以后在此模型部署openstack。

然后在juju controllers,输出：

Controller        Model      User   Access     Cloud/Region    Models  Nodes    HA  Version
maas-controller*  openstack  admin  superuser  mymaas/default       3      1  none  2.8.10

用juju models，显示juju 模型

#juju models
Controller: maas-controller

Model        Cloud/Region    Type  Status     Machines  Cores  Units  Access  Last connection
controller*  mymaas/default  maas  available        23      8  25     admin   just now
default      mymaas/default  maas  available         0      -  -      admin   2 hours ago
openstack    mymaas/default  maas  available        26     32  55     admin   14 minutes ago

可以看到在控制器maas-controller里，有三个模型，controller、openstack和default。
我们要备份的是controller模型，就是控制器
然后juju switch controller ,转换到controller模块，输出：

maas-controller:admin/openstack -> maas-controller:admin/controller

然后再juju create-buckup -m maas-controller:admin/controller，输出是：
输出结果

再juju switch openstack切换到openstack模型，输出为：

maas-controller:admin/controller -> maas-controller:admin/openstack

再备份openstack模型。

juju create-backup -m maas-controller:admin/openstack > /root/output/20210402-m-openstack.out --debug
10:12:16 INFO  juju.cmd supercommand.go:54 running juju [2.8.10 0 ba81843fc09ed04ae11e59595c1370b5dc242cf0 gc go1.14.15]
10:12:16 DEBUG juju.cmd supercommand.go:55   args: []string{"/snap/juju/15845/bin/juju", "create-backup", "-m", "maas-controller:admin/openstack", "--debug"}
10:12:16 INFO  juju.juju api.go:67 connecting to API addresses: [10.0.0.155:17070]
10:12:16 DEBUG juju.api apiclient.go:1107 successfully dialed "wss://10.0.0.155:17070/model/87620d2e-8d9c-483d-8552-79d3b3a2db64/api"
10:12:16 INFO  juju.api apiclient.go:639 connection established to "wss://10.0.0.155:17070/model/87620d2e-8d9c-483d-8552-79d3b3a2db64/api"
10:12:16 DEBUG juju.api monitor.go:35 RPC connection died
ERROR backups are only supported from the controller model
Use juju switch to select the controller model
10:12:16 DEBUG cmd supercommand.go:537 error stack:
backups are only supported from the controller model
Use juju switch to select the controller model
/build/snapcraft-juju-35d6cf/parts/juju/src/rpc/client.go:178:
/build/snapcraft-juju-35d6cf/parts/juju/src/api/apiclient.go:1212:
/build/snapcraft-juju-35d6cf/parts/juju/src/api/backups/create.go:24:
/build/snapcraft-juju-35d6cf/parts/juju/src/cmd/juju/backups/create.go:210:
/build/snapcraft-juju-35d6cf/parts/juju/src/cmd/juju/backups/create.go:154:

提示意为：create-backup命令只支持controller 模型的备份。

注意：下一步是部署openstack，在部署之前，需要使用juju switch
openstack命令切换到openstack模型，如忘记切换，会部署失败。

injexengge

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
多节点OpenStack Charms 部署指南0.0.1.dev303--21--控制器备份和还原

参考文档：Controller backupsClientJuju TricksRestoring from a backup控制器的备份使人们可以保存（并在以后重新建立）控制器的配置和状态。它不会影响后备云上的工作负载实例。也就是说，如果此类实例直接在云中终止，则控制器还原将无法重新创建该实例。此页面将涵盖以下主题：创建备份管理备份高可用性注意事项有一个单独的页面，描述了如何从备份中还原。juju控制器Juju提供了用于在发生故障或控制器不再存在时恢复控制器的命令。当前状
复制链接

扫一扫