作者：李晓辉

联系方式：

1. 微信：Lxh_Chat

2. 邮箱：939958092@qq.com

存储类型介绍

今天来给你唠唠红帽 OpenStack 平台里的那三种超厉害的持久存储方式，这可都是存储数据的神器呢，各有各的绝活儿，用起来贼方便。

先说说块存储吧。你可以把块存储想象成一块块超级灵活的“数字乐高积木”。这些“积木”可以拼凑成各种大小和形状的存储空间，特别适合那些对性能要求特别高的应用。比如，要是你有个数据库，里面存着海量的用户数据，块存储就能给它提供一个快速读写、稳定可靠的存储环境。它就像给数据库建了一个专属的“小窝”，让数据存取速度飞快，而且还能随时根据需要调整大小，简直是数据库的“贴心小棉袄”。

再聊聊对象存储。这玩意儿有点像一个超大的、智能的仓库。在这个仓库里，每一个文件都被封装成一个“对象”，每个对象都有自己的“身份证”，也就是元数据，里面记录了文件的各种信息，比如大小、类型、创建时间等等。对象存储特别适合存那种海量的、不太需要频繁修改的文件，比如图片、视频、文档这些。想象一下，你在网上冲浪时，那些网站上的图片和视频，背后可能就是对象存储在默默支持呢。它能轻松应对海量数据，而且还能自动备份、自动管理，不用担心数据丢掉，简直就是数据的“超级保护者”。

最后说说文件存储。这可能是大家最熟悉的一种存储方式了。它就像一个传统的文件柜，里面按照一定的目录结构，把文件一层层地存起来。文件存储特别适合那些需要共享文件的场景，比如在一个团队里，大家需要共享一些项目文件、文档之类的，文件存储就能很方便地让大家访问和修改这些文件。它支持多种协议，能和各种系统无缝对接，用起来特别顺手，是团队协作的“得力助手”。

这三种存储方式各有各的强项，红帽 OpenStack 平台把它们都整合在一起，就像给你准备了一个超全的“存储百宝箱”，不管你是要处理数据库、海量文件还是团队共享，都能找到合适的工具。是不是很厉害？

块存储选择

块存储分两种：临时存储和持久存储。临时存储，顾名思义，就是临时用用，它的“寿命”和实例（就是运行的虚拟机）是绑在一起的。实例没了，临时存储也跟着消失，就像临时工，任务结束就撤了。而持久存储就不一样了，它是个“长期工”，有自己的独立“户口”，和实例是分开的。你可以把持久存储想象成一个独立的硬盘，想把它插到哪个实例上就插到哪个实例上，用完还能拔下来，换个实例继续用，数据一点都不会丢，超级靠谱！
在 OpenStack 里，块存储是由一个叫 Cinder 的服务来搞定的。Cinder 就像是块存储的“大管家”，它把块存储设备包装成一个个卷，让用户能很方便地使用。这些卷都是持久的，你可以把它们挂在实例上，用完了再摘下来，换个实例接着用，数据一直都在，完全不用担心会丢。就像你有个移动硬盘，插到电脑上就能用，拔下来还能换台电脑继续用，超方便！
而且，Cinder 这个“大管家”还特别能干，它用块存储驱动程序来支持各种各样的后端存储。红帽 OpenStack 平台特别厉害，支持超多商用存储后端技术，你可以根据自己的需求，把不同的存储技术组合起来，就像搭积木一样，怎么搭都行。比如，你可以用高端的存储设备，也可以用普通的硬盘，Cinder 都能搞定，让你的存储方案灵活又强大。

LVM 和 iSCSI

先说说 LVM，这玩意儿全名叫 Linux 的逻辑卷管理器，听起来挺高大上的，其实它就是个“存储魔法师”。它能把本地的物理磁盘变成逻辑卷，然后把这些逻辑卷公开给操作系统用。简单来说，LVM 就像是把硬盘重新“切割”一下，让系统能更灵活地管理存储空间。

LVM 后端是块存储的一种实现方式，它把存储空间搞成逻辑分区的形式。每台运行 LVM 的计算主机，都得有个专门的卷组，用来给块存储服务用。虽然 LVM 是块存储服务的默认后端，但红帽官方说了，在生产环境中不支持用 LVM，毕竟它更适合测试或者小规模的场景，大规模生产环境还是得用更靠谱的方案。

红帽 Ceph 存储

再来说说红帽 Ceph 存储，这可是个“存储大杀器”，能提供超大容量的存储，PB 级别都不在话下！Ceph 牛就牛在它的高弹性和冗余架构，数据安全性超高，就算部分硬件出问题，也不会丢数据。

Ceph 可以干好多事儿，它能以对象服务（Swift）的形式提供对象存储 API 支持，还能当块存储服务（Cinder）和镜像服务（Glance）的后端。换句话说，Ceph 就是个“多面手”，啥存储需求都能搞定。它还支持通过 NFS 和分布式文件系统接口 CephFS 来共享文件，用起来特别灵活。

通过 NFS 提供存储

最后说说 NFS，这玩意儿全名叫网络文件系统，是个挺传统的存储方案。它利用文件系统协议，让文件客户端可以通过远程过程调用（RPC）把远程文件系统挂载成块设备卷，然后就能访问里面的内容了。

NFS 的好处是成本低，因为它可以用共享的网卡和传统的网络，不用额外买啥高端设备。不过，NFS 也有个缺点，和 Ceph 或 Gluster 这些专门设计的云存储后端比起来，它的性能可能差一点，吞吐量没那么高，延迟也可能高一些。不过要是你只是想搞个简单的存储方案，NFS 也是个不错的选择。

这几种存储技术各有各的强项，LVM 适合小规模测试，Ceph 是“全能选手”，NFS 则是“经济实惠型”

红帽 Ceph 存储架构

Ceph介绍

Ceph 是基于一种模块化分布式架构的，听起来有点复杂，但其实特别好用。它的核心是两个关键部分：

对象存储后端：RADOS

首先，Ceph 的“心脏”是一个叫 RADOS（可靠的自主分布式对象存储）的东西。别被这名字吓到，它其实就是 Ceph 的底层存储系统，专门用来存数据的。RADOS 可厉害了，它是个“智能存储大脑”，能自动修复自己，还能自动管理数据，完全不需要人工干预。比如，如果某个硬盘坏了，RADOS 能自动把数据复制到其他地方，保证数据不会丢，简直就像有“自我修复超能力”一样！

多种访问方式

除了底层的 RADOS，Ceph 还提供了多种和它交互的方式。这就像是给 RADOS 这个“大脑”接上了不同的“接口”，让它能和各种系统、应用无缝对接。比如，你可以通过对象存储 API（比如 Swift 或 S3）来访问它，也可以把它当作块存储（Cinder）或者文件存储（CephFS）来用。换句话说，不管你是想存文件、数据库还是别的啥，Ceph 都能满足你，就像一个“多功能瑞士军刀”，啥都能搞定。

Ceph术语

Ceph 集群

Ceph 集群，你可以把它想象成一个“超级存储团队”，这个团队里有很多成员（也就是服务器），它们一起工作，把数据存得又安全又高效。集群里的每个成员都有自己的任务，比如有的负责存储数据，有的负责管理数据的分布。整个集群就像一个“数据大仓库”，数据在里面被分散存储，就算某个成员出了问题，也不会影响整个仓库的运行，数据依然安全。

节点

节点，就是集群里的“成员”，也就是一台台的服务器。这些服务器在集群里各司其职，有的节点专门负责存储数据（叫存储节点），有的节点负责管理集群的状态（叫监控节点）。比如，一个 Ceph 集群可能有 10 台服务器，每台服务器就是一个节点，它们一起协作，搞定所有的存储任务。

池，你可以把它想象成一个“数据分区”，是集群里用来存放数据的一个逻辑区域。在 Ceph 里，你可以根据自己的需求创建不同的池，比如一个池用来存重要数据，另一个池用来存不太重要的数据。每个池都有自己的规则，比如数据的副本数量、存储位置等等。简单来说，池就是用来把数据分类存储的地方，让数据管理更方便。

放置组

放置组，这是 Ceph 里一个特别有意思的概念。你可以把它想象成“数据的小包裹”。当数据被存到池里的时候，Ceph 会把数据分成很多个小包裹（也就是放置组），然后把这些小包裹分散到不同的节点上。这样做的好处是，就算某个节点坏了，数据也不会丢，因为数据被分散存储了。而且，Ceph 会自动管理这些放置组，保证数据的分布是合理的，读写速度也更快。

Ceph 存储后端组件

监控器 (MON)

监控器（MON）是 Ceph 的“大脑”，它主要负责维护整个集群的状态映射。你可以把它想象成一个“指挥官”，它知道集群里每个节点的情况，比如哪些节点是好的，哪些节点可能出了点问题。MON 的任务是帮助其他守护进程（就是那些在后台默默工作的程序）互相协调，确保整个集群运行得又稳又快。要是没有 MON，其他组件就可能会乱成一团，不知道该往哪儿使劲呢。

对象存储设备 (OSD)

对象存储设备（OSD）是 Ceph 的“存储主力”，它负责实实在在地存储数据。你可以把 OSD 想象成一个个“数据仓库”，数据被分成很多小块，然后分散存储在这些仓库里。OSD 还特别厉害，它不仅能存数据，还能自动处理数据的复制（就是把数据多存几份，防止丢数据）、恢复（要是某个数据块丢了，它能自动修复）和重新平衡（要是某个仓库太满了，它能把数据挪挪地方，让存储更均匀）。总之，OSD 是 Ceph 的“劳模”，干的活儿最多，也最辛苦。

管理器 (MGR)

管理器（MGR）是 Ceph 的“管家”，它主要负责跟踪集群的运行时指标（就是集群运行的各种数据，比如 CPU 使用率、内存使用情况等等），然后通过一个基于 Web 的控制面板（就是那种可以在浏览器里打开的界面）和 REST API（一种可以让其他程序和它交互的接口），把集群的信息展示出来。管理员可以通过 MGR 来监控集群的状态，比如看看哪些节点负载过高，或者哪些数据需要优化。MGR 就像是一个贴心的“小秘书”，把集群的运行情况都整理得清清楚楚，方便管理员管理。

元数据服务器 (MDS)

元数据服务器（MDS）是 Ceph 的“导航员”，它主要负责存储供 CephFS（Ceph 的文件系统）使用的元数据。元数据你可以理解为数据的“说明书”，它记录了数据的各种信息，比如数据的大小、类型、存储位置等等。MDS 的作用是让客户端（就是那些需要使用 Ceph 存储的程序）能够高效地执行 POSIX 命令（POSIX 是一种标准的操作系统接口，很多文件操作命令都基于它）。有了 MDS，客户端就能快速找到数据，就像有了一个“活地图”，操作起来特别方便。

以下是我们课程中的Ceph组件位置：

通过 Cephx 进⾏⾝份验证

Ceph 的身份验证可是保证数据安全的关键环节。Ceph 用的是一种叫 cephx 的协议，听起来挺高大上的，其实原理很简单，就是用共享的密钥（secret key）来验证身份。就好比你有个“暗号”，只有你知道的人才能用这个“暗号”来和你交流，这样就能防止坏人混进来啦！

Cephx 是 Ceph 用来验证身份的“神器”，它确保集群里的客户端、应用和守护进程之间通信的时候，大家都是“自己人”。具体来说：

Ceph 守护进程的账号：这些账号的名字和守护进程是匹配的，比如 osd.1（这是对象存储设备守护进程的账号）或者 mgr.serverc（这是管理器守护进程的账号）。这就像是给每个守护进程都配了一个“身份证”，方便识别。
使用 librados 的客户端应用账号：这些账号的名字都以 client. 开头，比如 client.openstack。这就像是给客户端应用起了一个专门的名字，方便管理。
Ceph 对象网关的账号：当你部署 Ceph 对象网关的时候，会创建一个叫 client.rgw.hostname 的账号。这个账号是专门用来管理对象网关的。
管理员账号：这个账号名字是 client.admin，是个“超级管理员”。如果没有指定用户名，默认就会用这个账号。就好比你有个“万能钥匙”，啥都能干。

密钥环⽂件

说到身份验证，就离不开密钥环文件。这个文件就像是你的“秘密宝藏”，里面藏着你的密钥。客户端要想访问 Ceph 集群，就得配置好 cephx 用户名，还得有这个密钥环文件。简单来说，客户端用这个文件来证明“我是我”，这样才能顺利访问集群。

密钥环文件的位置：默认情况下，密钥环文件会放在 /etc/ceph/ 目录下，文件名格式是 $cluster.$name.keyring。比如，对于 client.openstack 账号，它的密钥环文件就是 /etc/ceph/ceph.client.openstack.keyring。
配置文件中的 keyring 参数：在客户端系统中，librados 会用 /etc/ceph/ceph.conf 配置文件里的 keyring 参数来找到密钥环文件。这就像是告诉客户端：“嘿，你的密钥环文件在这儿呢，快去拿吧！”

身份验证案例

以下 ceph 命令以 client.operator3 进⾏⾝份验证并列出可⽤的池

需要注意的时，你安装了ceph-common就不用进入到容器里执行了

yum install ceph-common -y
scp xxxx:/etc/ceph/ceph.conf /etc/ceph/
scp xxxx:/etc/ceph/ceph.client.operator3.keyring /etc/ceph/
ceph --id operator3 osd lspools

查询集群状态

[root@controller0 /]# ceph -s
  cluster:
    id:     fe8e3db0-d6c3-11e8-a76d-52540001fac8
    health: HEALTH_OK

  services:
    mon: 1 daemons, quorum controller0
    mgr: controller0(active)
    mds: cephfs-1/1/1 up  {0=controller0=up:active}
    osd: 6 osds: 6 up, 6 in

  data:
    pools:   7 pools, 416 pgs
    objects: 748 objects, 5655 MB
    usage:   6309 MB used, 107 GB / 113 GB avail
    pgs:     416 active+clean

也可以用systemd的查看方法去看看服务是否启动

[root@controller0 ~]# systemctl list-units ceph\*
UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
ceph-mds@controller0.service loaded active running Ceph MDS
ceph-mgr@controller0.service loaded active running Ceph Manager
ceph-mon@controller0.service loaded active running Ceph Monitor


[root@ceph0 ~]# systemctl list-units ceph\*
UNIT                 LOAD   ACTIVE SUB     DESCRIPTION
ceph-osd@vdb.service loaded active running Ceph OSD
ceph-osd@vdc.service loaded active running Ceph OSD
ceph-osd@vdd.service loaded active running Ceph OSD

Cephx 授权

这次重点说说 Cephx 的授权机制。这可是个关键环节，决定了谁能在 Ceph 集群里干啥，权限有多大。简单来说，Cephx 的授权就是给每个用户和守护进程分配“通行证”，让他们能干自己该干的事儿，但又不能越界。

Cephx 授权的功能

在 Cephx 里，每个守护进程类型（比如监控器、对象存储设备、管理器等）都有几种可用的功能，这些功能可以理解为权限。具体来说：

r（读取权限）
这个权限允许用户读取数据。每个用户账号至少要在监控器（MON）上拥有读取权限，这样才能获取 CRUSH map（CRUSH map 是一个用来管理数据分布的“地图”）。就好比你得先知道数据在哪儿，才能去读它。
w（写入权限）
这个权限允许用户写入数据，也就是存储和修改对象。客户端如果想在对象存储设备（OSD）上存数据或者改数据，就得有写入权限。对于管理器（MGR），写入权限还能用来启用或禁用模块，就好比给 MGR 一个“超级开关”，能控制其他功能。
x（执行权限）
这个权限允许用户执行一些扩展操作，比如在对象上设置锁定（用 rados lock get），或者列出 RBD 镜像（用 rbd list）。这就像是给用户一个“高级工具箱”，能干一些比较复杂的操作。
*（完整权限）
这个权限就是“大满贯”，啥都能干。如果一个用户有这个权限，那他在集群里就是“超级管理员”，想干啥就干啥。
class-read 和 class-write
这两个权限是执行权限（x）的“小弟”，通常用在 RBD（Ceph 的块设备）的池上。class-read 允许用户读取一些特殊的元数据，而 class-write 允许用户修改这些元数据。就好比你只能看或者只能改一些特定的东西，而不是所有东西。

查询用户信息

所有用户列表

[root@controller0 /]# ceph auth list | more
installed auth entries:

mds.controller0
        key: AQCzM89blEMOJBAAiFp/PFV9IRB0sv5tea7srg==
        caps: [mds] allow
        caps: [mon] allow profile mds
        caps: [osd] allow rwx
osd.0
        key: AQBCM89b1fgXGxAA9xG4PyIt+0ZcVvTwFBUOBQ==
        caps: [mgr] allow profile osd
        caps: [mon] allow profile osd
        caps: [osd] allow *

特定用户信息

[root@controller0 /]# ceph auth get client.admin
exported keyring for client.admin
[client.admin]
        key = AQBhMs9bANcVCxAA3ZHYooO3wi1p0hW90kApyw==
        auid = 0
        caps mds = "allow"
        caps mgr = "allow *"
        caps mon = "allow *"
        caps osd = "allow *"

只查询keyring

1 2	[root@controller0 /]# ceph auth print-key client.admin AQBhMs9bANcVCxAA3ZHYooO3wi1p0hW90kApyw==

创建用户

[root@controller0 /]# ceph auth get-or-create client.lixiaohui mon 'allow r' osd 'allow rw' > /etc/ceph/ceph.client.lixiaohui.keyring
[root@controller0 /]# ceph auth get client.lixiaohui
exported keyring for client.lixiaohui
[client.lixiaohui]
        key = AQAAdC1n8VBwIRAAOVXXdVBHenAUbmAGtxsPKA==
        caps mon = "allow r"
        caps osd = "allow rw"

Glance与Ceph对接

这里只提到如何修改配置文件，其他信息可以参考ceph官网：https://docs.ceph.com/en/reef/rbd/rbd-openstack

[DEFAULT]
enabled_backends = rbd:rbd
show_image_direct_url = True
[glance_store]
default_backend = rbd
[rbd]
rbd_store_pool = images
rbd_store_user = glance
rbd_store_ceph_conf = /etc/ceph/ceph.conf
rbd_store_chunk_size = 8
[paste_deploy]
flavor = keystone

cinder与Ceph对接

这里只提到如何修改配置文件，其他信息可以参考ceph官网：https://docs.ceph.com/en/reef/rbd/rbd-openstack

[DEFAULT]
enabled_backends = ceph
glance_api_version = 2

[ceph]
volume_driver = cinder.volume.drivers.rbd.RBDDriver
volume_backend_name = ceph
rbd_pool = volumes
rbd_ceph_conf = /etc/ceph/ceph.conf
rbd_flatten_volume_from_snapshot = false
rbd_max_clone_depth = 5
rbd_store_chunk_size = 4
rados_connect_timeout = -1
rbd_user = cinder
rbd_secret_uuid = e4355171-b66e-4036-989f-f6af496797a6 # 这里是libvirt创uuidgen的UUID

创建cinder卷

同时为块存储服务激活了多个后端，则需要创建卷类型并将其绑定到相应的存储后端

比说如，我在配置文件中指定的后端名称为tripleo_ceph

[root@controller0 ~]# cd /var/lib/config-data/puppet-generated/cinder/etc/cinder
[root@controller0 ~]# grep -v -e ^$ -e ^# cinder.conf

[DEFAULT]
enabled_backends=tripleo_ceph
[tripleo_ceph]
backend_host=hostgroup
volume_backend_name=tripleo_ceph
volume_driver=cinder.volume.drivers.rbd.RBDDriver
rbd_ceph_conf=/etc/ceph/ceph.conf
rbd_user=openstack
rbd_pool=volumes

创建一个名为cephtype的类型供用户选择

(undercloud) [stack@director ~]$ source overcloudrc
(overcloud) [stack@director ~]$ openstack volume type create --property volume_backend_name=tripleo_ceph cephtype
+-------------+--------------------------------------+
| Field       | Value                                |
+-------------+--------------------------------------+
| description | None                                 |
| id          | 4bbce644-64b8-4fb5-9e4b-8b86aa6b4d91 |
| is_public   | True                                 |
| name        | cephtype                             |
| properties  | volume_backend_name='tripleo_ceph'   |
+-------------+--------------------------------------+

用我们的cephtype类型创建一个1G的卷

(overcloud) [stack@director ~]$ openstack volume create --size 1 --type cephtype volume1
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| attachments         | []                                   |
| availability_zone   | nova                                 |
| bootable            | false                                |
| consistencygroup_id | None                                 |
| created_at          | 2024-11-08T02:33:42.000000           |
| description         | None                                 |
| encrypted           | False                                |
| id                  | 59007d3c-64b1-48d2-8b63-56b837e4e7c4 |
| migration_status    | None                                 |
| multiattach         | False                                |
| name                | volume1                              |
| properties          |                                      |
| replication_status  | None                                 |
| size                | 1                                    |
| snapshot_id         | None                                 |
| source_volid        | None                                 |
| status              | creating                             |
| type                | cephtype                             |
| updated_at          | None                                 |
| user_id             | 9ce00d8980274974b2285ed73ef80241     |
+---------------------+--------------------------------------+
(overcloud) [stack@director ~]$ openstack volume list
+--------------------------------------+---------+-----------+------+-------------+
| ID                                   | Name    | Status    | Size | Attached to |
+--------------------------------------+---------+-----------+------+-------------+
| 59007d3c-64b1-48d2-8b63-56b837e4e7c4 | volume1 | available |    1 |             |
+--------------------------------------+---------+-----------+------+-------------+

看看这个数据有没有跑到ceph里

经过查询，volumes数据池已经有了我们59开头的ID

[root@controller0 /]# rados -p volumes ls
rbd_directory
rbd_info
rbd_object_map.86bd59895364
rbd_header.86bd59895364
rbd_id.volume-59007d3c-64b1-48d2-8b63-56b837e4e7c4

这个大小很小看不出什么，我们试试用一个镜像作为内容提供方，创建一个包含此镜像内容的卷

(overcloud) [stack@director ~]$ wget http://materials/osp-small.qcow2
--2024-11-08 02:37:34--  http://materials/osp-small.qcow2
Resolving materials (materials)... 172.25.254.254
Connecting to materials (materials)|172.25.254.254|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1632174080 (1.5G)
Saving to: ‘osp-small.qcow2’

100%[================================================================>] 1,632,174,080  302MB/s   in 4.8s

2024-11-08 02:37:39 (328 MB/s) - ‘osp-small.qcow2’ saved [1632174080/1632174080]



(overcloud) [stack@director ~]$ openstack image create --file osp-small.qcow2 image1


(overcloud) [stack@director ~]$ openstack volume create --type cephtype --image image1 --size 20 volume2
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| attachments         | []                                   |
| availability_zone   | nova                                 |
| bootable            | false                                |
| consistencygroup_id | None                                 |
| created_at          | 2024-11-08T02:39:50.000000           |
| description         | None                                 |
| encrypted           | False                                |
| id                  | 88e4c800-aa16-4f89-988c-ed8d8dc72708 |
| migration_status    | None                                 |
| multiattach         | False                                |
| name                | volume2                              |
| properties          |                                      |
| replication_status  | None                                 |
| size                | 20                                   |
| snapshot_id         | None                                 |
| source_volid        | None                                 |
| status              | creating                             |
| type                | cephtype                             |
| updated_at          | None                                 |
| user_id             | 9ce00d8980274974b2285ed73ef80241     |
+---------------------+--------------------------------------+

这个创建可能没那么快，我们稍后去ceph看看有没有88e开头的数据

[root@controller0 /]# rados -p volumes ls
rbd_directory
rbd_children
rbd_info
rbd_object_map.86bd59895364
rbd_header.86bd59895364
rbd_object_map.870e6d5693f8
rbd_id.volume-59007d3c-64b1-48d2-8b63-56b837e4e7c4
rbd_header.870e6d5693f8
rbd_id.volume-88e4c800-aa16-4f89-988c-ed8d8dc72708

创建基于Cinder的共享存储

在 OpenStack 里创建基于 Cinder 的共享存储，也就是能让多个实例同时连接到一个卷的技术。这玩意儿特别实用，比如在做高可用部署的时候，能让主实例和备用实例共享同一个存储卷，一旦主实例挂了，备用实例能立刻接管，数据一点都不会丢，简直是“故障转移”的神器！

创建支持多实例附加的卷类型

首先，得创建一个支持多实例附加的卷类型。这就好比给存储卷定一个“规则”，让它知道可以被多个实例同时使用。操作很简单，只需要几条命令：

这条命令会创建一个新的卷类型，名字叫 volume-multi。运行完后，你会看到类似这样的输出：

(overcloud) [stack@director ~]$ cinder type-create volume-multi
+--------------------------------------+--------------+-------------+-----------+
| ID                                   | Name         | Description | Is_Public |
+--------------------------------------+--------------+-------------+-----------+
| 2853e96d-d182-4141-8fcf-dc64a3c05b0f | volume-multi | -           | True      |
+--------------------------------------+--------------+-------------+-----------+

接下来，得给这个卷类型设置“多实例附加”的属性：

这条命令的意思是，告诉 Cinder：“嘿，这个卷类型支持多实例附加哦！”

1	(overcloud) [stack@director ~]$ cinder type-key volume-multi set multiattach="<is> True"

设置完后，可以用下面的命令查看一下卷类型的具体信息，确认设置成功：

输出会显示卷类型的各种属性，重点看 extra_specs 那一行，应该会看到 multiattach : <is> True，这就说明设置成功啦！

(overcloud) [stack@director ~]$ cinder type-show volume-multi
+---------------------------------+--------------------------------------+
| Property                        | Value                                |
+---------------------------------+--------------------------------------+
| description                     | None                                 |
| extra_specs                     | multiattach : <is> True              |
| id                              | 2853e96d-d182-4141-8fcf-dc64a3c05b0f |
| is_public                       | True                                 |
| name                            | volume-multi                         |
| os-volume-type-access:is_public | True                                 |
| qos_specs_id                    | None                                 |
+---------------------------------+--------------------------------------+

创建支持多实例附加的卷

搞定卷类型后，下一步就是创建一个实际的卷了。这就好比在硬盘上划分出一块空间，让多个实例都能用。命令也很简单：

这条命令的意思是，创建一个大小为 2GB 的卷，名字叫 multi-volume1，并且指定它的卷类型是刚才创建的 volume-multi。创建完后，可以用 cinder list 命令查看卷的状态：

1	(overcloud) [stack@director ~]$ cinder create 2 --name multi-volume1 --volume-type volume-multi

输出会显示所有卷的信息，你应该能看到你刚刚创建的 multi-volume1，状态是 available，说明它已经准备好可以被附加到实例上了。

如果你想了解更多关于这个卷的信息，可以用 cinder show 命令：

(overcloud) [stack@director ~]$ cinder list
+--------------------------------------+-----------+---------------+------+--------------+----------+-------------+
| ID                                   | Status    | Name          | Size | Volume Type  | Bootable | Attached to |
+--------------------------------------+-----------+---------------+------+--------------+----------+-------------+
| 296432a6-f47c-4988-887c-65eca6ca07bb | available | multi-volume1 | 2    | volume-multi | false    |             |
+--------------------------------------+-----------+---------------+------+--------------+----------+-------------+

输出会显示卷的详细信息，其中 multiattach 属性会显示为 True，这说明这个卷确实支持多实例附加。

(overcloud) [stack@director ~]$ cinder show multi-volume1

| multiattach                    | True                                 |
...
(overcloud) [stack@director ~]$

总结一下

创建卷类型：用 cinder type-create 创建一个支持多实例附加的卷类型。
设置多实例附加属性：用 cinder type-key 给卷类型设置 multiattach 属性。
创建卷：用 cinder create 创建一个卷，并指定卷类型。
查看卷信息：用 cinder list 和 cinder show 查看卷的状态和详细信息。

通过这几步，你就能创建一个支持多实例附加的存储卷啦！这样一来，多个实例就能共享同一个卷，无论是做高可用部署还是其他需要共享存储的场景，都能轻松搞定。

临时和持久存储

临时存储单元和持久存储单元的比较

差异	临时存储	持久存储
创建时间	创建虚拟机时自动创建	用户通过 API 请求后创建
持久性	虚拟机删除后，临时存储也会消失	虚拟机删除后，持久存储仍然保留，直到用户手动删除
速度和延迟	使用直连存储时，延迟低，响应快	延迟稍高，但能处理更大的 I/O 工作负载
最大容量	取决于当前可用的存储空间	取决于存储配额
容量调整	根据虚拟机配置自动调整	根据用户需求手动调整

简单来说，当你用镜像创建虚拟机时，一开始只有临时存储。默认情况下，计算服务会在计算节点的 /var/lib/nova/instances/UUID/ 文件夹里为临时存储创建一个存储对象。如果用了红帽 Ceph 存储作为后端，这些对象就会被放在 Ceph 的 vms 池里。

创建一个持久卷看看，而且这样创建的卷，是基于镜像的，卷里会自然包含镜像的所有内容

1
2
3

(undercloud) [stack@director ~]$ source overcloudrc
(overcloud) [stack@director ~]$ openstack image create --file osp-small.qcow2 image1
(overcloud) [stack@director ~]$ openstack volume create --size 10 --image image1 volume1

块存储对实例迁移的影响

迁移实例就像是把虚拟机从一个“家”（计算节点）搬到另一个“家”。这个过程很重要，因为它能确保虚拟机里的服务在原来的“家”出问题时，还能继续正常运行。而且，如果需要对原来的“家”进行维修或者升级，迁移也能让虚拟机暂时“搬”到别的地方，保证服务不受影响。

迁移主要有两种方式：冷迁移和热迁移（也就是实时迁移）。这两种方式的区别主要在于虚拟机在迁移过程中是“关机”还是“开机”。

1. 冷迁移：虚拟机“关机搬家”

冷迁移就像是虚拟机“关机”之后再搬家。具体来说，虚拟机会先被关闭，然后它的数据会被复制到另一个计算节点上。等数据都搬完之后，虚拟机再在新的计算节点上重新启动。这种方式虽然比较稳妥，但有个缺点：虚拟机会暂时停机，也就是说，服务会中断一小段时间。

2. 热迁移（实时迁移）：虚拟机“开机搬家”

热迁移就像是虚拟机在“开机”的状态下搬家，整个过程用户几乎感觉不到停机。热迁移又可以细分为几种不同的方式：

a. 基于共享存储的实时迁移

这种方式就像是虚拟机的“家当”（内存数据）被复制到了新的“家”，但它的“临时存储”（比如一些临时文件）是放在一个共享的“仓库”里的。因为这个“仓库”是源“家”和目标“家”共享的，所以不需要把临时存储的数据也搬到新的“家”。这种方式的优点是速度快，因为只需要复制内存数据，不会增加太多的网络负担。

b. 块实时迁移

这种方式就比较复杂了。不仅虚拟机的“家当”（内存数据）要搬到新的“家”，它的“临时存储”（临时文件）也要一起搬过去。因为源“家”和目标“家”没有共享的“仓库”，所以这些数据都得通过网络传输。这会导致迁移时间变长，网络负担也会增加，但好处是灵活性更高，不需要依赖共享存储。

c. 由卷支持的实时迁移

这种方式更像是虚拟机带着“行李”（持久卷）搬家，而不是带着“临时物品”（临时存储）。在这种情况下，只有虚拟机的“家当”（内存数据）需要搬到新的“家”，因为“行李”（持久卷）本来就放在一个固定的“仓库”（存储节点）里，不需要跟着虚拟机一起搬。这种方式的优点是速度快，不会因为传输大量数据而增加网络负担，也不会延长迁移时间。

简单来说，迁移就像是给虚拟机“搬家”，冷迁移是“关机搬家”，热迁移是“开机搬家”。热迁移又分几种，有的只需要搬“家当”，有的连“临时物品”也一起搬，还有的只搬“家当”，“行李”留在原地。选择哪种方式，取决于你的需求和环境。