存储实验室:Cinder 多后端配置、卷挂载实例,Swift 对象存储实操教程

文章目录

OpenStack 存储管理

OpenStack块存储管理-cinder

cinder的配置文件位置:/etc/cinder

cinder的日志文件位置:/var/log/cidner

openstack存储类型

OpenStack持久化存储简介

Cinder作用

Cinder在虚拟机与具体存储设备之间引入了一层"逻辑存储卷"的抽象,Cinder本身不是一种存储技术,并 没有实现对块设备的实际管理和服务 Cinder只是提供了一个中间的抽象层,为后端不同的存储技术,提供了统一的接口 不同的块设备服务厂商在Cinder中以驱动的形式实现上述接口与OpenStack进行整合

Cinder架构

  • Cinder Client封装Cinder提供的rest接口,以CLI形式供用户使用。 •Cinder API对外提供rest API,对操作需求进行解析,对API进行路由寻找相应的处理方法。包含卷的增 删改查(包括从源卷、镜像、快照创建)、快照增删改查、备份、volume type管理、挂载/卸载(Nova 调用)等。 •Cinder Scheduler负责收集backend上报的容量、能力信息,根据设定的算法完成卷到指定cinder- volume的调度。

  • Cinder Volume多节点部署,使用不同的配置文件、接入不同的backend设备,由各存储厂商插入 driver代码与设备交互完成设备容量和能力信息收集、卷操作。 •Cinder Backup实现将卷的数据备份到其他存储介质(目前SWIFT/Ceph/TSM提供了驱动)。 •SQL DB提供存储卷、快照、备份、service等数据,支持MySQL、PG、MSSQL等SQL数据库。

查看控制节点cinder进程:

bash 复制代码
# 执行命令:ps -e | grep cinder
[root@controller ~]# ps -e | grep cinder
  1746 ?        00:00:03 cinder-schedule
   1748 ?        00:00:04 cinder-api
   1772 ?        00:00:03 cinder-backup
   1791 ?        00:00:04 cinder-volume
   2812 ?        00:00:00 cinder-backup
   2931 ?        00:00:00 cinder-volume
   2959 ?        00:00:00 cinder-api
   2961 ?        00:00:00 cinder-api
   2964 ?        00:00:00 cinder-api
   2967 ?        00:00:00 cinder-api

查看cinder-volume默认支持的存储设备:

bash 复制代码
# 切换到/usr/lib/python3.6/site-packages/cinder/volume/drivers/目录
[root@controller ~]# cd /usr/lib/python3.6/site-packages/cinder/volume/drivers/

# 列出当前目录内容
[root@controller drivers]# ls
datera         huawei        lenovo         nfs.py       rbd.py        
storpool.py      windows
dell_emc       ibm           linstordrv.py  nimble.py    remotefs.py   stx       
       zadara.py
fujitsu        infinidat.py  lvm.py         prophetstor  rsd.py        synology
fusionstorage  infortrend    macrosan       pure.py      san           
veritas_access
hedvig         __init__.py   nec            __pycache__  sandstone     
veritas_cnfs.py
hitachi        inspur        netapp         qnap.py      solidfire.py  vmware
hpe            kaminario     nexenta        quobyte.py   spdk.py       
vzstorage.py

Cinder架构说明

  • Cinder默认使用LVM(Logical Volume Manager)作为后端存储(Backend Storage),而LVM通过在 操作系统与物理存储资源之间引入逻辑卷(Logical Volume)的抽象来解决传统磁盘分区管理工具的问 题。 •LVM将众多不同的物理存储资源(物理卷、Physical Volume,如磁盘分区)组成卷组。LVM从卷组中 创建一个逻辑卷,然后将ext3、ReiserFS等文件系统安装在这个逻辑卷上。 •除了LVM,目前Cinder已经以驱动的形式支持众多存储技术或存储厂商的设备作为后端存储,如SAN (Storage Area Network)、Ceph、Sheepdog,以及EMC、华为等厂商的设备。

实验环境后端存储就是LVM(安装时决定的):

bash 复制代码
# 编辑answers.txt配置文件
[root@controller ~]# vim answers.txt
536 CONFIG_CINDER_BACKEND=lvm
544 CONFIG_CINDER_VOLUMES_CREATE=y
547 CONFIG_CINDER_VOLUME_NAME=cinder-volumes
554 CONFIG_CINDER_VOLUMES_SIZE=20G

实验环境查看:

bash 复制代码
# 执行命令:vgdisplay cinder-volumes
[root@controller ~]# vgdisplay cinder-volumes
  --- Volume group ---
  VG Name               cinder-volumes
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  8
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <20.60 GiB
  PE Size               4.00 MiB
  Total PE              5273
  Alloc PE / Size       5020 / <19.61 GiB
  Free  PE / Size       253 / 1012.00 MiB
  VG UUID               ODOHA8-u2MO-RAtc-y43r-1r1u-PIn8-XOFuhi

Cinder架构部署:以SAN存储为例

Cinder-api,Cinder-Scheduler,Cinder-Volume可以选择部署到一个节点上,也可以分别部署 API采用AA模式,HAproxy作为LB,分发请求到多个Cinder API Scheduler也采用AA模式,由rabbitmq以负载均衡模式向3个节点分发任务,并同时从rabbitmq收 取Cinder volume上报的能力信息,调度时,scheduler通过在DB中预留资源从而保证数据一致性 Cinder Volume也采用AA模式,同时上报同一个backend容量和能力信息,并同时接受请求进行处 理 RabbitMQ,支持主备或集群 MySQL,支持主备或集群

Cinder-api

Cinder API 检查参数合法性(用户输入,权限,资源是否存在等) 准备创建的参数字典,预留和提交配额 在数据库中创建对应的数据记录 通过消息队列将请求和参数发送到Scheduler 查看cinder API服务状态:

bash 复制代码
# 执行命令:systemctl status openstack-cinder-api.se
[root@controller ~]# systemctl status openstack-cinder-api.service
● openstack-cinder-api.service - OpenStack Cinder API Server
   Loaded: loaded (/usr/lib/systemd/system/openstack-cinder-api.service; enabled; 
vendor preset: disabled)
   Active: active (running) since Fri 2024-09-27 09:44:47 CST; 1h 7min ago
 Main PID: 1748 (cinder-api)
    Tasks: 5 (limit: 100416)
   Memory: 501.2M
   CGroup: /system.slice/openstack-cinder-api.service
           ├─1748 /usr/bin/python3 /usr/bin/cinder-api --config-file 
/usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --
logfile />
           ├─2959 /usr/bin/python3 /usr/bin/cinder-api --config-file 
/usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --
logfile />
           ├─2961 /usr/bin/python3 /usr/bin/cinder-api --config-file 
/usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --
logfile />
           ├─2964 /usr/bin/python3 /usr/bin/cinder-api --config-file 
/usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --
logfile />
           └─2967 /usr/bin/python3 /usr/bin/cinder-api --config-file 
/usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --
logfile />
Sep 27 09:44:47 controller systemd[1]: Started OpenStack Cinder API Server.

Cinder-scheduler

  • 和Nova Scheduler类似,Cinder Scheduler也是经过Filter筛选符合条件的后端,然后使用Weigher计算 后端进行权重排序,最终选择出最合适的后端存储。

Cinder Scheduler服务 提取接收到的请求参数 通过配置的filter和输入参数对后端进行过滤 Availability_zone_filter Capacity_filter Capabilities_filter Affinity_filter(SameBackendFilter/DifferentBackendFilter) ...... Weigher计算后端进行权重 CapacityWeigher/AllocatedCapacityWeigher ChanceWeigher GoodnessWeigher ...... 选取最优的Backend并通过消息队列将请求发送到指定的后端

查看配置文件:

bash 复制代码
# 切换到/etc/cinder/目录
[root@controller ~]# cd /etc/cinder/

# 列出当前目录内容
[root@controller cinder]# ls
api-paste.ini  cinder.conf  resource_filters.json  rootwrap.conf  rootwrap.d  
volumes

# 编辑cinder.conf配置文件
[root@controller cinder]# vim cinder.conf
 592 #scheduler_default_filters = 
AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter
 593
 595 #scheduler_default_weighers = CapacityWeigher
 596
 601 # Default scheduler driver to use (string value)
 602 #scheduler_driver = cinder.scheduler.filter_scheduler.FilterScheduler

AvailabilityZoneFilter 为提高容灾性和提供隔离服务,可以将存储节点和计算节点划分到不同的 Availability Zone 中。例如把 一个机架上的机器划分在一个 Availability Zone 中。OpenStack 默认有一个命名为"nova"的 Availability Zone,所有的节点初始都是放在"nova"中。用户可以根据需要创建自己的 Availability Zone。 创建 Volume 时,用户会指定 Volume 的大小。CapacityFilter 的作用是将存储空间不能满足 Volume 创 建需求的存储节点过滤掉。 配置cinder配置文件cinder.conf

bash 复制代码
# 切换到/etc/cinder/目录
[root@controller ~]# cd /etc/cinder/

# 列出当前目录内容
[root@controller cinder]# ls
api-paste.ini  cinder.conf  resource_filters.json  rootwrap.conf  rootwrap.d  
volumes

# 编辑cinder.conf配置文件
[root@controller cinder]# vim cinder.conf
592 scheduler_default_filters = 
AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter
#该配置文件的节点的AZ设置为az1
395 storage_availability_zone=az1
#创建卷时,不指定az默认使用nova AZ
401 default_availability_zone=nova

# 重启openstack-cinder*服务
[root@controller cinder]# systemctl restart openstack-cinder*

验证AZ实验:

bash 复制代码
#cinder.conf配置文件配置401 default_availability_zone=nova,创建卷时不指定AZ则使用nova 
AZ,而该节点属于az1 AZ,创建失败

# 加载keystonerc_admin环境变量
[root@controller ~]# source keystonerc_admin

# 创建volume--size
[root@controller ~(keystone_admin)]# openstack volume create --size 1 volume1
Availability zone 'nova' is invalid. (HTTP 400) (Request-ID: req-c4e2d4d1-d299-
4267-b2a1-22fcd676a6ea)
#cinder配置文件配置395 storage_availability_zone=az1,该节点属于AZ az1节点,创建AZ az2
卷,被AvailabilityZoneFilter过滤

# 创建volume--size
[root@controller ~(keystone_admin)]# openstack volume create --size 1 --availability-zone az2 volume1
Availability zone 'az2' is invalid. (HTTP 400) (Request-ID: req-749dad9d-d5fb-
4122-95aa-ab03d0c5a955)
#cinder配置文件配置395 storage_availability_zone=az1,该节点属于AZ az1节点,创建AZ az1
卷,创建成功

# 创建volume--size
[root@controller ~(keystone_admin)]# openstack volume create --size 1 --availability-zone az1 volume1
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| attachments         | []                                   |
| availability_zone   | az1                                  |
| bootable            | false                                |
| consistencygroup_id | None                                 |
| created_at          | 2024-09-27T06:02:35.368543           |
| description         | None                                 |
| encrypted           | False                                |
| id                  | 43746d03-a0c5-4232-8f1b-6023ffe83545 |
| migration_status    | None                                 |
| multiattach         | False                                |
| name                | volume1                              |
| properties          |                                      |
| replication_status  | None                                 |
| size                | 1                                    |
| snapshot_id         | None                                 |
| source_volid        | None                                 |
| status              | creating                             |
| type                | iscsi                                |
| updated_at          | None                                 |
| user_id             | 7ef9147a8abe485889ece90dce340ab1     |
+---------------------+--------------------------------------+

CapacityFilter 创建 Volume 时,用户会指定 Volume 的大小。CapacityFilter 的作用是将存储空间不能满足 Volume 创 建需求的存储节点过滤掉。 CapabilitiesFilter 不同的 Volume Provider 有自己的特性(Capabilities),比如是否支持 thin provision 等。Cinder 允 许用户创建 Volume 时通过 Volume Type 指定需要的 Capabilities。

创建卷的时候,卷类型指定为iscsi,那么后端使用的是LVM,为何? 由卷类型,扩展规格决定

接下来查看配置文件:

bash 复制代码
# 编辑/etc/cinder/cinder.conf配置文件
[root@controller ~(keystone_admin)]# vim /etc/cinder/cinder.conf
5261 [lvm]
5262 volume_backend_name=lvm
5263 volume_driver=cinder.volume.drivers.lvm.LVMVolumeDriver
5264 target_ip_address=192.168.108.10
5265 target_helper=lioadm
5266 volume_group=cinder-volumes
5267 volumes_dir=/var/lib/cinder/volumes                                         

Cinder-volume

Cinder Volume服务 提取接收到的请求参数

调用对应的Driver在后端创建实际的卷 使用Driver返回的模型更新数据库中的记录 Cinder挂载流程

挂卷流程: 挂卷是通过Nova和Cinder的配合最终将远端的卷连接到虚拟机所在的Host节点上,并最终 通过虚拟机管理程序映射到内部的虚拟机中 •Nova调用Cinder API创建卷,传递主机的信息,如hostname,iSCSI initiator name,FC WWPNs。 •Cinder API将该信息传递给Cinder Volume。 •Cinder Volume通过创建卷时保存的host信息找到对应的Cinder Driver。 •Cinder Driver通知存储允许该主机访问该卷,并返回该存储的连接信息(如iSCSI iqn,portal,FC Target WWPN,NFS path等)。 •Nova调用针对于不同存储类型进行主机识别磁盘的代码( Cinder 提供了brick模块用于参考)实现识别 磁盘或者文件设备。 •Nova通知Cinder已经进行了挂载。 •Nova将主机的设备信息传递给hypervisor来实现虚拟机挂载磁盘。

OpenStack对象存储-Swift

swift在openstack中的作用

Swift并不是文件系统或者实时的数据存储系统,它称为对象存储,用于永久类型的静态数据的长期 存储,这些数据可以检索、调整,必要时进行更新 最适合存储的数据类型的例子是虚拟机镜像、图片存储、邮件存储和存档备份 因为没有中心单元或主控结点,Swift提供了更强的扩展性、冗余和持久性 使用命令swift stat可以显示Swift中的帐户、容器和对象的信息。 Swift为帐户,容器和对象分别定义了Ring(环)将虚拟节点(分区)映射到一组物理存储设备上,包括 Account Ring、 Container Ring 、 Object Ring。 Ring记录了存储对象与物理位置的映射关系,通过Zone、 Device、 Partition和Replica来维护映射信 息。

华为OBS体验

直到安装结束

点进控制台

Swift实验

控制节点新添加一块20GB磁盘 一。新添磁盘分成两个区,并格式化 分区一:挂载到obs1目录 分区二:挂载到obs2目录

新建两个分区

将两个分区格式化为xfs格式

下面为默认挂给swift的虚拟设备分区,将其卸载

bash 复制代码
# 执行命令:umount /srv/node/swiftloopback      #卸载原
[root@controller ~]# umount /srv/node/swiftloopback      #卸载原来的swift虚拟设备分区

# 切换到/srv/node           #切换到swift目录目录
[root@controller ~]# cd /srv/node           #切换到swift目录

# 列出当前目录内容
[root@controller node]# ls
swiftloopback

# 执行命令:rm -rf swiftloopback/       #删除原来的swift挂
[root@controller node]# rm -rf swiftloopback/       #删除原来的swift挂载目录

# 执行命令:mkdir obs1 obs2          #创建新的挂载目录,分别挂载s
[root@controller node]# mkdir obs1 obs2          #创建新的挂载目录,分别挂载sdb1,sbd2

配置挂载文件,将obs1--sdb1,obs2--sdb2分别挂载关联

bash 复制代码
# 编辑/etc/fstab    #下面三行话,一句注释,两句添加配置文件
[root@controller node]# vim /etc/fstab    #下面三行话,一句注释,两句添加
#/srv/loopback-device/swiftloopback     /srv/node/swiftloopback ext4    
noatime,nodiratime,nofail,loop,user_xattr       0       0
/dev/sdb1 /srv/node/obs1 xfs defaults 0 0
/dev/sdb2 /srv/node/obs2 xfs defaults 0 0

# 执行命令:mount -a              #挂载
[root@controller node]# mount -a              #挂载
mount: (hint) your fstab has been modified, but systemd still uses
       the old version; use 'systemctl daemon-reload' to reload.

# 执行命令:df                    #查看现象
[root@controller node]# df                    #查看现象
Filesystem          1K-blocks    Used Available Use% Mounted on
devtmpfs              3904608       0   3904608   0% /dev
tmpfs                 3924792       4   3924788   1% /dev/shm
tmpfs                 3924792   17652   3907140   1% /run
tmpfs                 3924792       0   3924792   0% /sys/fs/cgroup
/dev/mapper/cs-root  73364480 6867104  66497376  10% /
/dev/mapper/cs-home 131081692  946964 130134728   1% /home
/dev/sda1             1038336  234124    804212  23% /boot
tmpfs                  784956       0    784956   0% /run/user/0
/dev/sdb1            10475520  106088  10369432   2% /srv/node/obs1
/dev/sdb2            10474496  106088  10368408   2% /srv/node/obs2

修改obs1目录和obs2目录权限

bash 复制代码
# 执行命令:chown swift:swift obs1
[root@controller node]# chown swift:swift obs1

# 执行命令:chown swift:swift obs2
[root@controller node]# chown swift:swift obs2

# 执行命令:ll
[root@controller node]# ll
total 0
drwxr-xr-x 2 swift swift 6 Sep 29 14:04 obs1
drwxr-xr-x 2 swift swift 6 Sep 29 14:04 obs2

创建swfit ring:

bash 复制代码
# 切换到/etc/swift/目录
[root@controller node]# cd /etc/swift/

# 列出当前目录内容
[root@controller swift]# ls
account.builder  account-server.conf  container-reconciler.conf  container-
server.conf  object-expirer.conf  object-server.conf  swift.conf
account.ring.gz  backups              container.ring.gz          internal-
client.conf   object.ring.gz       proxy-server
account-server   container.builder    container-server           object.builder   
      object-server        proxy-server.conf

# 执行命令:swift-ring-builder container.builder cre
[root@controller swift]# swift-ring-builder container.builder create --help
swift-ring-builder <builder_file> create <part_power> <replicas>
                                         <min_part_hours>
    Creates <builder_file> with 2^<part_power> partitions and <replicas>.
    <min_part_hours> is number of hours to restrict moving a partition more
    than once.

# 执行命令:swift-ring-builder container.builder cre
[root@controller swift]# swift-ring-builder container.builder create 12 2 1

# 执行命令:swift-ring-builder account.builder creat
[root@controller swift]# swift-ring-builder account.builder create 12 2 1

# 执行命令:swift-ring-builder object.builder create
[root@controller swift]# swift-ring-builder object.builder create 12 2 1
#12表示ring分区数量为2^12
#2表示2个副本
#1表示最少1个小时后才能更改ring配置

创建ring映射关系:

bash 复制代码
#查看配置文件,分别查看account,container,obeject的bind_port记录下来
[root@controller swift]# cat account-server.conf | grep bind_port
bind_port = 6002

# 查看container-server.conf | grep bind_port文件内容
[root@controller swift]# cat container-server.conf | grep bind_port
bind_port = 6001

# 查看object-server.conf | grep bind_port文件内容
[root@controller swift]# cat object-server.conf | grep bind_port
bind_port = 6000

# 执行命令:swift-ring-builder account.builder add z
[root@controller swift]# swift-ring-builder account.builder add z1-192.168.108.10:6002/obs1 100
WARNING: No region specified for z1-192.168.108.10:6002/obs1. Defaulting to 
region 1.

# 执行命令:swift-ring-builder account.builder add z
[root@controller swift]# swift-ring-builder account.builder add z2-192.168.108.10:6002/obs2 100

# 执行命令:swift-ring-builder container.builder add
[root@controller swift]# swift-ring-builder container.builder add z1-192.168.108.10:6001/obs1 100

# 执行命令:swift-ring-builder container.builder add
[root@controller swift]# swift-ring-builder container.builder add z2-192.168.108.10:6001/obs2 100

# 执行命令:swift-ring-builder object.builder add z1
[root@controller swift]# swift-ring-builder object.builder add z1-192.168.108.10:6000/obs1 100

# 执行命令:swift-ring-builder object.builder add z2
[root@controller swift]# swift-ring-builder object.builder add z2-192.168.108.10:6000/obs2 100

再平衡:

bash 复制代码
# 执行命令:swift-ring-builder account.builder rebal
[root@controller swift]# swift-ring-builder account.builder rebalance
Reassigned 8192 (200.00%) partitions. Balance is now 0.00.  Dispersion is now 
0.00

# 执行命令:swift-ring-builder object.builder rebala
[root@controller swift]# swift-ring-builder object.builder rebalance
Reassigned 8192 (200.00%) partitions. Balance is now 0.00.  Dispersion is now 
0.00

# 执行命令:swift-ring-builder container.builder reb
[root@controller swift]# swift-ring-builder container.builder rebalance
Reassigned 8192 (200.00%) partitions. Balance is now 0.00.  Dispersion is now 
0.00

实验测试:

上传成功

bash 复制代码
#刚才上传的文件,2副本,分别在obs1目录,obs2目录各存了一份
[root@controller obs1]# find /srv/node -name *data
/srv/node/`obs1`/objects/317/0fe/13d34c83bb5eed122321759e90f6e0fe/1727591964.0773
5.data
/srv/node/`obs2`/objects/317/0fe/13d34c83bb5eed122321759e90f6e0fe/1727591964.0773
5.data

实验介绍

关于本实验

本实验主要介绍如何通过OpenStack Dashboard 和OpenStack CLI 两种方式创建并管理卷类型和QOS,最后

介绍了卷的创建、挂载及卸载、上传卷到镜像、创建卷快照并基于卷快照创建卷、基于卷发放虚拟机实

例、卷扩容、更新卷状态以及删除卷等基本操作。

实验目的

⚫ 熟悉OpenStack Dashboard 和OpenStack CLI 创建并管理卷类型和QOS。

⚫ 熟悉OpenStack Dashboard 和OpenStack CLI 卷的创建、挂载及卸载以及卷快照、卷扩容、更新卷状态、卷

删除等基本操作方法。

⚫ 熟悉OpenStack Dashboard 和OpenStack CLI 上传卷到镜像、基于卷快照创建卷、基于卷发放虚拟机实例等

基本操作方法。

实验流程

OpenStack Dashboard 操作

卷类型和QoS 管理

使用admin 用户登录OpenStack Dashboard 界面,在左侧导航栏,选择"管理员> 卷> 卷类型",进入卷

类型列表,单击页面右上角的"创建卷类型"。

弹出创建卷类型对话框,输入卷类型名称"VolumeType_web",勾选下方的"公有",单击"创建卷类

型"。

单击下方的"创建QoS 规格"。

弹出创建Qos 规格对话框,输入Qos 规格名称"QoS_web","消费者"选择"后端",单击"创

建"。

返回卷类型列表,查看刚刚创建的卷类型,单击待操作的卷类型所在行"Actions"列方框中的,在操

作列表中选择"管理QoS 规格关联"。

弹出分配QoS 规格与卷类型对话框,在"要关联的QoS 规格"方框中选择"QoS_web",单击"关

联"。

返回卷类型列表,查看卷类型分配的QoS 规格。

卷管理

创建卷

在左侧导航栏,选择"项目>卷>卷",进入卷列表,单击页面上方的"创建卷"。

弹出创建卷对话框,输入如下信息:

⚫ 卷名称:自定义,如"Volume_web_01"。

⚫ 卷来源:选择"镜像"。

⚫ 使用镜像作为源:选择镜像"Img_web"。

⚫ 类型:选择卷类型"VolumeType_web"。

⚫ 大小:选择1 GB。

⚫ 可用分区:选择"nova"。

⚫ 其他保持默认。

单击"创建卷",完成卷的创建。

返回卷列表,查看刚刚创建的卷,状态为"可用"。

挂载和卸载卷

在左侧导航栏,选择"项目>卷>卷",进入卷列表,单击待操作卷所在行"Actions"列方框中的,在

操作列表中选择"管理连接"。

如果没有,参考发放虚拟机实例"Instance_web_01"。

弹出管理卷挂载对话框,在"连接到实例"下方选择待挂载的虚拟机实例"Instance_web_01",单击

"连接卷"。

返回卷列表,观察卷的状态和挂载情况。

单击待操作卷所在行"Actions"列方框中的,查看卷在已挂载的状态下可执行的操作。

在操作列表中选择"管理连接"。弹出管理卷挂载对话框,列表中将显示挂载卷的虚拟机实例,单击

"Actions"列的"分离卷"。

弹出如下确认信息提示框,单击"分离卷"。

返回卷列表,再次观察卷的状态和挂载情况。

上传卷到镜像

在左侧导航栏,选择"项目>卷>卷",进入卷列表,单击待操作卷所在行"Actions"列方框中的,在

操作列表中选择"上传镜像"。

弹出上传卷到镜像对话框,输入镜像名称"Volume_Img_web",磁盘格式选择"QCOW2 - QEMU 模拟

器",单击"上传"。

在左侧导航栏,选择"项目>计算>镜像",进入镜像列表,查看刚刚创建的镜像,镜像类型为

"Image",可见性为"共享的"。

创建卷快照

在左侧导航栏,选择"项目>卷>卷",进入卷列表,单击待操作卷所在行"Actions"列方框中的,在

操作列表中选择"创建快照"。

弹出创建卷快照对话框,输入快照名称,如"Volume_ Snap_web",单击"创建卷快照"。

自动跳转到卷快照列表,查看刚刚创建的快照。

卷扩容

在左侧导航栏,选择"项目>卷>卷",进入卷列表,单击待操作卷所在行"Actions"列方框中的,在

操作列表中选择"扩展卷"。

弹出扩容卷对话框,在"新大小(GiB)"下方输入卷扩容后的大小,如"2",单击"扩展卷"。

返回卷列表,查看卷扩容后的大小。

基于卷快照创建卷

在左侧导航栏,选择"项目>卷>快照",进入卷快照列表,单击待操作的卷所在行"Actions"列的方框

中的"创建卷"。

弹出创建卷对话框,输入卷名称"Volume_web_02","使用快照作为源"已自动选择

"Volume_Snap_web",直接单击"创建卷"。

自动跳转到卷列表,查看刚刚创建的卷。

新创建的卷"Volume_web_02"相当于已恢复到卷"Volume_web_01"创建快照时的状态。

基于卷发放虚拟机实例

单击待操作卷所在行"Actions"列方框中的,在操作列表中选择"创建实例"。

弹出发放虚拟机实例对话框,在"详情"页签,输入虚拟机实例名称,如"Instance_web_02",其他保

持默认,单击"下一项"。

进入"源"页签,"选择源"选择"Volume",可用卷选择"Volume_web_02",直接单击"下一

项"。

进入"实例类型"页签,在下方"可用"列表中单击规格"Flavor_web_test"后面的,上方"已分

配"列表中将显示选择的规格,单击"下一步"。

进入"网络"页签,在下方"可用"列表中单击规格"shared"后面的,上方"已分配"列表中将显

示选择的规格,直接单击"创建实例"。

返回卷列表,观察卷的状态和挂载情况的变化。

在左侧导航栏,选择"项目>计算>实例",进入虚拟机实例列表,查看刚刚创建的虚拟机实例。

在左侧导航栏,选择"项目>卷>卷",进入卷列表,单击待操作卷所在行"Actions"列方框中的"编辑

卷"。

弹出编辑卷对话框,取消勾选下方的"可启动",取消该卷为启动卷,单击"提交"。

返回卷列表,查看卷的变化,单击待操作卷所在行"Actions"列方框中的 ,查看可支持的操作。

结论:

1. 若卷不是启动卷,则无法基于该卷发放虚拟机实例。

更新卷状态

在左侧导航栏,选择"管理员>卷>卷",进入卷列表,单击待操作卷所在行"Actions"列方框中的"更

新卷状态"。

弹出更新卷状态对话框,在"状态"下方的方框中选择状态"错误",单击"更新状态"。

返回卷列表,查看卷的状态。

删除卷

在左侧导航栏,选择"管理员>卷>卷",进入卷列表,勾选待操作卷所在行前的 ,单击"删除卷"。

弹出如下确认信息提示框,单击"删除卷"。

弹出如下无法删除卷的提示:

选择"管理员>卷>快照",进入卷快照列表,单击卷"Volume_web_01"的卷快照所在行"Actions"列

的"删除卷快照"。

弹出如下确认信息提示框,单击"删除卷快照"。

再次删除卷"Volume_web_01",验证是否成功。

删除卷"Volume_web_02",验证是否成功。

弹出如下无法删除卷的提示:

在左侧导航栏,选择"项目>计算>实例",进入虚拟机实例列表,勾选虚拟机实例

"Instance_web_02",单击页面上方的"删除实例"。

弹出如下确认信息提示框,单击"删除实例"。

再次删除卷"Volume_web_02",验证是否成功。

配置NFS 共享存储

通过模板创建一个NFS 节点(完整克隆),IP 配置为192.168.108.12

nfs 节点:

bash 复制代码
# 创建目录
mkdir /nfs_share

# 修改文件权限
chmod -R 777 /nfs_share

# yum包管理
yum -y install nfs-utils

# 输出内容
echo "/nfs_share *(rw,sync,no_root_squash)" > /etc/exports

# 系统服务管理
systemctl stop firewalld.service

# 系统服务管理
systemctl restart nfs-server

# 系统服务管理
systemctl enable nfs-server

nfs 节点测试:

controller 节点,compute 节点测试:

mkdir /mnt/nfs_share

chmod -R 777 /mnt/nfs_share

controller 节点配置:

bash 复制代码
# 编辑配置文件
vim /etc/cinder/cinder.conf

enabled_backends = lvm,nfs

让 cinder-volume 使用 nfs backend

nfs_mount_point_base = /mnt/nfs_share

指定存储节点上 /mnt/nfs_share 为 nfs 的 mount point。

nfs_shares_config = /etc/cinder/nfs_shares,查看 /etc/cinder/nfs_shares 活动 nfs 共享目

录列表。其内容为在 cinder 中需要根据这里的 volume_backend_name 创建对应的 volume type,这个

非常重要。

bash 复制代码
# 编辑配置文件
vim /etc/cinder/nfs_shares

列表中只有 192.168.108.12:/nfs_share。如果希望有多个 nfs 共享目录存放 volume,则可以

添加到该文件中。

bash 复制代码
# 创建目录
mkdir -p /mnt/nfs_share

# 修改文件属主
chown -R cinder:cinder /mnt/nfs_share

# 系统服务管理
systemctl restart openstack-cinder-volume

创建卷类型:

创建卷:

用卷创建实例

OpenStack CLI 操作

卷类型和QoS 管理

远程登录ECS。执行以下命令,导入用户admin 的环境变量。

bash 复制代码
# 加载环境变量配置文件
source keystonerc_admin

执行以下命令,创建卷类型"VolumeType_cli",类型为"public"。

bash 复制代码
# type卷
openstack volume type create --public VolumeType_cli

执行以下命令,查看卷类型列表。

bash 复制代码
# type卷
openstack volume type list

执行以下命令,创建卷QoS"QoS_cli",使用对象为"back-end"。

bash 复制代码
# qos卷
openstack volume qos create --consume back-end QoS_cli

执行以下命令,查看卷QoS 列表。

bash 复制代码
# qos卷
openstack volume qos list

执行以下命令,将卷QoS"QoS_cli"分配给卷类型"VolumeType_cli"。

bash 复制代码
# qos卷
openstack volume qos associate QoS_cli VolumeType_cli

执行以下命令,查看卷QoS 分配的卷类型。

bash 复制代码
# qos卷
openstack volume qos show QoS_cli

卷管理

创建卷

执行以下命令,创建卷"Volume_cli_01",要求配置如下:

⚫ 卷名称:"Volume_cli_01"。

⚫ 卷来源:"Img_cli"。

⚫ 类型:"VolumeType_cli"。

⚫ 大小:1 GB。

⚫ 可用分区:"nova"。

⚫ 启动卷。

bash 复制代码
# 创建卷
openstack volume create --image Img_cli --type VolumeType_cli --size 1 --availability-zone nova --bootable Volume_cli_01

执行以下命令,查看卷列表。

bash 复制代码
# 列出所有卷
openstack volume list

挂载和卸载卷

发放计算实例"Instance_cli_01"。

openstack server create --availability-zone nova --image Img_cli --flavor Flavor_cli --network shared --key-name KeyPair_cli Instance_cli_01

执行以下命令,将卷"Volume_cli_01"挂载给虚拟机实例"Instance_cli_01"。

bash 复制代码
# 添加虚拟机实例
openstack server add volume Instance_cli_01 Volume_cli_01

执行以下命令,查看卷的挂载情况。

bash 复制代码
# 列出所有卷
openstack volume list

执行以下命令,将卷"Volume_cli_01"从虚拟机实例"Instance_cli_01"卸载。

bash 复制代码
# 移除虚拟机实例
openstack server remove volume Instance_cli_01 Volume_cli_01

再次查看卷的挂载情况。

bash 复制代码
# 列出所有卷
openstack volume list

上传卷到镜像

执行以下命令,将卷"Volume_cli_01"上传到镜像"Volume_Img_cli",镜像格式设置为"QCOW2"。

bash 复制代码
# 创建镜像
openstack image create --volume Volume_cli_01 --disk-format qcow2 Volume_Img_cli

执行以下命令,查看刚刚创建的镜像。

bash 复制代码
# 列出所有镜像
openstack image list

创建卷快照

执行以下命令,为卷"Volume_cli_01"创建卷快照"Volume_Snap_cli"。

bash 复制代码
# 快照卷
openstack volume snapshot create --volume Volume_cli_01 Volume_Snap_cli

执行以下命令,查看刚刚创建的卷快照。

bash 复制代码
# 快照卷
openstack volume snapshot list

卷扩容

执行以下命令,将卷"Volume_cli_01"扩容至2 GB。

bash 复制代码
# 设置/修改卷
openstack volume set --size 2 Volume_cli_01

执行以下命令,查看刚刚扩容的卷。

bash 复制代码
# 查看卷
openstack volume show Volume_cli_01

基于卷快照创建卷

执行以下命令,基于卷快照"Volume_Sanp_cli"创建卷"Volume_cli_02"。

bash 复制代码
# 创建卷
openstack volume create --snapshot Volume_Snap_cli Volume_cli_02

执行以下命令,查看刚刚创建的卷。

bash 复制代码
# 列出所有卷
openstack volume list

基于卷发放虚拟机实例

执行以下命令,基于卷"Volume_cli_02"发放虚拟机实例"Instance_cli_02",规格设置为

"Flavor_cli"。

bash 复制代码
# 创建虚拟机实例
openstack server create --volume Volume_cli_02 --flavor Flavor_cli --network shared Instance_cli_02

执行以下命令,查看虚拟机实例列表。

bash 复制代码
# 列出所有虚拟机实例
openstack server list

执行以下命令,将卷"Volume_cli_02"设置为非启动卷。

bash 复制代码
# 设置/修改卷
openstack volume set --non-bootable Volume_cli_02

再次发放虚拟机实例,验证是否能成功。

bash 复制代码
# 创建虚拟机实例
openstack server create --volume Volume_cli_02 --flavor Flavor_cli Instance_cli_03

结论:

当卷为"非启动盘"时,无法使用该卷发放虚拟机实例。

更新卷状态

执行以下命令,查看卷"Volume_cli_01"的状态。

bash 复制代码
# 列出所有卷
openstack volume list | grep Volume_cli_01

执行以下命令,更新卷"Volume_cli_01"的状态。

bash 复制代码
# 设置/修改卷
openstack volume set --state error Volume_cli_01

查看卷的状态。

删除卷

执行以下命令,删除卷"Volume_cli_01"。

bash 复制代码
# 删除卷
openstack volume delete Volume_cli_01

由提示无法删除卷的原因可知,卷"Volume_cli_01"存在卷快照"Volume_Snap_cli",需要先删除卷快

照,才能删除该卷。

执行以下命令,删除卷快照"Volume_Snap_cli"。

bash 复制代码
# 快照卷
openstack volume snapshot delete Volume_Snap_cli

再次删除卷,查看是否有报错。

执行以下命令,查看卷列表。

bash 复制代码
# 列出所有卷
openstack volume list

执行以下命令,删除卷"Volume_cli_02",查看是否成功。

bash 复制代码
# 删除卷
openstack volume delete Volume_cli_02

由提示无法删除卷的原因可知,卷"Volume_cli_02"的状态不能是"in-use",需要先将卷从虚拟机实例

上卸载,状态变为"available"后再删除。

执行以下命令,将卷"Volume_cli_02"从虚拟机实例"Instance_cli_02"上卸载。

bash 复制代码
# 移除虚拟机实例
openstack server remove volume Instance_cli_02 Volume_cli_02

由提示无法卸载卷的原因可知,待删除的卷为系统卷无法卸载,因此该卷也无法删除,除非删除虚拟机

实例。

执行以下命令,删除虚拟机实例"Instance_cli_02"。

bash 复制代码
# 删除虚拟机实例
openstack server delete Instance_cli_02

执行以下命令,再次查看卷"Volume_cli_02"的状态。

bash 复制代码
# 列出所有卷
openstack volume list | grep Volume_cli_02

执行以下命令,再次删除卷"Volume_cli_02",查看是否成功。

bash 复制代码
# 删除卷
openstack volume delete Volume_cli_02

执行以下命令,再次查看卷列表,是否删除成功。

bash 复制代码
# 列出所有卷
openstack volume list
相关推荐
闲云自留地14 小时前
从零吃透 OpenStack:起源、理念、架构、创建虚拟机交互流程
架构·交互·openstack
闲云自留地1 天前
OpenStack 镜像管家 Glance:架构、镜像格式、状态机与镜像制作全讲解
架构·openstack
闲云自留地1 天前
OpenStack 的身份管家:Keystone 令牌、RBAC 权限模型拆解
wpf·openstack
shacofun2 天前
OpenStack扫盲
openstack
SatanII5 天前
OpenStack核心组件详解|Keystone+Glance+Nova+Cinder原理与实操笔记
网络·笔记·openstack
xianyuCcCcCCCcc9 天前
OpenStack 核心组件原理与架构深度剖析
linux·运维·openstack
harmony&10 天前
OpenStack 云平台管理实战:从 Keystone 认证到 Nova 计算调度
数据库·openstack
闲云野鹤在人间11 天前
OpenStack架构介绍和安装流程
linux·网络·架构·openstack
bgy666611 天前
openstack核心指南
服务器·网络·openstack