柴少鹏的官方网站 技术在分享中进步,水平在学习中升华

OpenStack(三)Cinder结合LVM做云盘

一、OpenStack简介

第一部分的文字及图片内容来自《Openstack实战指南》。

1.1 OpenStack的结构

OpenStack包含了许多组件。有些组件会首先出现在孵化项目中,待成熟以后进入下一个OpenStack发行版的核心服务中。

OpenStack的核心服务包括:

Nova  #计算服务(Compute as a Service)
Neutron  #网络服务(Network as a Service)
Swift  #对象存储服务(Object Storage as a Service)
Cinder  #块存储服务(Block Storage as a Service)

OpenStack的公共服务包括:

Glance  #镜像服务(Image as a Service)
Keystone  #认证服务(Identity as a Service)
Horizon  #仪表盘服务(DashBoard as a Service)

OpenStack项目有一些共同点,比如:

OpenStack项目组件由多个子组件组成,子组件有各自的模块。
每个项目都有具有优良涉及的公共API,API基于RESTful,同时支持JSON和XML。
每个项目都有单独的数据库和隔离的持久层。
每个项目都可以单独部署,对外提供服务,也可以在一起协同完成某项工作。
每个项目都有各自的后端驱动,所有的驱动都可以以plugin方式加载。
每个项目都有各自的client项目,如Nova有nova-client作为其命令行调用RESTful的实现。

#OpenStack的一些项目或多或少也会需要Database(数据库)、Message Queue(消息队列)进行数据持久化、通信。

       OpenStack是由一系列具有RESTful接口的Web服务所实现的,是一系列组件服务集合。下图是Openstack的一个典型架构:

图片.png

       当今的云计算概念是由Google公司提出的,狭义的云计算是指IT基础设施的交付和使用模式,按需取用所需的IT资源;广义的云计算是指服务交付和使用模式,通过网络按需取用所需的服务,这种服务可以是IT、软件、互联网相关的,也可以是其他服务。它具有超大规模、虚拟化、可靠安全、弹性等特性。通过SaaS(Software as a Service)、PaaS(Platform as a Service)、Iaas(Infrastructure as a Service)提供从上到下不同层面的云计算服务。

      云计算(Cloud Computing)是网格计算(Grid Computing)、分布式计算(Distributed Computing)、并行计算(Parallel Computing)、效用计算(Utility Computing)、联机存储技术(Network Storage Technology)、虚拟化(Virtualization)、负载均衡(Load Balance)等一系列传统计算机技术和网络技术发展融合的产物。它旨在通过网络将多个成本低廉的计算实体整合成一个大型计算资源池,并借助Saas、Paas、Iaas等服务模式,将强大的计算能力分发到终端用户手中。

      OpenStack具有三大核心功能,即计算、存储、网络,分别对应相应的项目Nova、Cinder和Neutron。其中Nova提供了计算资源的管理,可以管理跨服务网络的VM实例。同时,Nova还提供对多种Hypervisor的支持,如KVM、QEMU、Xen、LXC、VMware、Hyper-V、PowerVM等。Cinder提供了存储资源的管理,可以管理各个厂商提供的专业存储设备。Neutron提供了网络资源的管理。

1.2 OpenStack的用户界面

       OpenStack的用户界面由两部分组成:一是Web界面,二是Shell界面。

       Horizon负责展现Web仪表盘,用户可以通过浏览器直接操作、管理、运维OpenStack的一些功能。由于OpenStack项目队伍不断扩大,Dashboard并不能展现所有的OpenStack功能,因此,最新的功能一般会先开发Shell命令行,也就是CLI(Command Line Interface)提供给Linux用户操作。

      OpenStack仪表盘可以安装在任意节点,通常将其安装在Nova API的管理节点,以方便访问。Horizon和Nova-Client一样,需要Keystone的用户名及密码认证,以及Keystone的Token进行授权访问,这些都是Horizon内部实现的,普通用户只要有用户名及密码就能登录到仪表盘中进行日常操作。

     通过Horizon创建虚拟机实例有很多先决条件,如Horizon本身能正常运行并对外提供创建服务;建立在OpenStack三个核心组件之上等。这三个核心组件分别是Keystone、Glance、Nova。Keystone负责授权认证、租户管理、项目权限和配额以及服务目录管理。Glance负责为Nova提供创建实例所需要的镜像文件。Nova负责虚拟机生命周期的管理,以及宿主机资源调度。Nova还决定了虚拟机实例建立在哪一台Hypervisor物理机之上。由着三个核心组件协作,Horizon将用户的HTTP请求转换为RESTful请求,然后将RESTful请求分发给Nova API,进行实例创建。当创建后,虚拟机实例会进入Build状态,任务状态将是Spawning。这期间会将镜像文件从Glance中下载到Nova节点,并进行一些虚拟机的配置。当一切正常后,虚拟机将会进入Active状态。创建所需的时间一般由创建实例的镜像文件大小、传输镜像带宽,以及创建的Hypervisor磁盘性能来决定。

     Horizon并不是唯一可以管理虚拟机的用户界面。之前提到OpenStack还有基于Python的CLI,虚拟机创建之后可以通过Nova-Client进行管理。在计算节点上通过命令行输入nova list,可以看到所有OpenStack实例的运行情况,以及实例相应的信息。

blob.png

        Web界面的实例的控制台界面,可以对虚拟机进行操作。这是一个VNC控制台,不必像以前使用虚拟机那样,登录到Hypervisor端配置VNC端口信息,然后再通过VNC Client登录管理虚拟机。OpenStack将这些日常操作抽象出来,进行自动化,整个过程无需用户进行任何配置。

blob.png     

#从上图可以看出每个实例都会开放一个vnc的端口。

1.3 创建虚拟机流程概述

1). Horizon通过Keystone获取Compute组件的访问地址(URL),并获取授权令牌(Token)。

blob.png

2). 携带授权令牌,发送创建虚拟机指令

blob.png

3). nova-compute组件通过glance-api下载虚拟机镜像,glance镜像中有缓存机制,通常将缓存文件放入名为_base目录(也就base缓存),镜像分两个阶段,第一个阶段是如果base缓存中没有此次虚拟机镜像文件,则从Glance下载镜像到base缓存;第二个阶段是从base缓存复制到本地镜像目录。base缓存可关闭,默认为开启。建议不要修改此默认值,每次镜像都通过Glance下载,会消耗大量的网络带宽。

blob.png

blob.png

4). Glance检索后端镜像,Glance 后端存储不一定要使用Swift,只要能存放镜像的文件系统都可以。

blob.png

5). 获取网络信息,决定虚拟机网络模式及建立网络连接。

blob.png

6). nova-compute发送启动虚拟机指令,至此虚拟机创建完毕。

blob.png

1.4 各节点上面组件的简单介绍

控制节点上面的组件介绍:

RabbitMQ:

在OpenStack中,各个服务之间是通过消息来交互的。因为OpenStack使用AMQP(高级消息队列协议)作为其消息传递的技术,所以RabbitMQ、Qpid、ZeroMQ等支持AMQP的软件都是被OpenStack所支持的。OpenStack通过AMQP实现RPC的服务,来保证不同组件之间的通信,RabbitMQ是controller中一个非常关键的服务。

图片.png

MySQL:

OpenStack所使用的数据库。包括Nova、Glance、Cinder等在内的组件都会简历自己的数据库,保持一些必要的数据。

Keystone:

OpenStack的用户认证组件。它的功能主要是建立管理项目的用户和各种服务端口,以及进行用户的身份认证。要使用OpenStack的任意API,第一步就必须通过Keystone的验证。

Glance:

用来存放管理虚拟机镜像和快照的服务,这也是最小架构中必须有的服务。

Neutron:

        用来提供虚拟机网络通信的组件。Neutron在整个OpenStack中负责网络部分的功能,其实Neutron仅仅只有管理功能,实际的网络方面的实现依靠的是更加底层的网络技术,比如Linux网桥、Open vSwitch和Nicira等,在Neutron中,这些网络技术以plugin的形式使用。因此,在各个节点上,需要安装Neutron的不同服务,才能形成一个真正的网络组件。

       Neutron-server是Neutron的主服务进程,是一个Python的守护进程,提供Neutron的API接口,负责接收用户通过API传入的请求,然后把不同的请求传到Neutron相应的agent。在这个期间,neutron-server需要在数据库中存储静态数据,因此这个服务可以安装在控制节点和网络节点上或者是单独的一台节点上,但是必须保证能访问数据库,能进行RPC通信和Keystone认证。

      neutron-pluging-XXXX: 底层网络虚拟化技术的插件,XXXX取决于底层使用的网络技术。plugin必须安装在neutron-server的节点上,因为neutron-server需要知道用户到底使用哪种底层的虚拟化技术,并且把用户的请求交给这个具体技术的plugin进行处理。

       Open vSwitch(OVS)是一个开源的虚拟交换机软件,被Neuron支持并使用,它不但能作为一个软交换机在系统的管理程序中运行,也能控制物理的交换机设备。在Neutron中,Open vSwitch以plugin的形式被使用,它主要包括以下两个部分:

    plugin  #在Neutron服务运行的时候被载入。plugin负责处理API请求和在后端数据库中保存相关的网络逻辑数据。
    agent   #在每个计算节点和网络节点运行。agent负责从配置文件和中心数据库收集数据,并在本地的Open vSwitch实例通信,把要执行的网络流程操作发送给实例,来实现基于逻辑数据模型的网络。

Nova(除去Nova-compute的其他组件):

这里不包括nova-compute,因为controller节点不负责运行虚拟机。Nova是个至关重要的组件,也是个相对庞大的组件,其中有很多服务,它是进行生成虚拟机工作的主要服务。nova-scheduler管理虚拟机的调度,确定在哪一台物理机上创建虚拟机。例如,从nova-api发起创建虚拟机指令,nova-scheduler会寻找适合创建这台虚拟机的nova-compute组件的位置,确定在哪个nova-compute上创建后,通过RPC消息队列,让nova-compute处理创建虚拟机请求。

Cinder(除去Cinder-volume的其他组件):

用来创建、删除及管理volume(虚拟磁盘卷),以及给volume做快照等服务的组件。要在控制节点上安装cinder-api和cinder-scheduler,其中cinder-api负责接收其他组件或命令对cinder-volume的请求,而cinder-scheduler则是Cinder的调度程序,调度使用哪个volume。

Horizon:

OpenStack的Web管理页面,使用Django框架开发。Web管理页面包含了日常使用的大部分功能,提供给用户一个最直观的展现方式。

网络节点上面的组件介绍:

        网络节点主要负责虚拟机的网络控制,包括DHCP、虚拟路由、公网访问虚拟机等。通过软件网桥等方式控制虚拟机的网络,代替传统环境中所需要的交换机、路由器等。这里就是使用Open vSwitch作为底层的网络驱动。

由于采用Open vSwitch作为Neutron的plugin来实现底层的网络虚拟化,因此需要安装Open vSwitch。

        在网络节点,需要安装Neutron的大部分组件,要安装openvswitch-plugin的agent,负责neutron server和plugin之间的相互联系,dhcp-agent负责虚拟网络的DHCP,l3-agent负责虚拟网络的路由和外部连接(虚拟网络是在l3-agent的配置里设置的,简单来说,是用于虚拟机和Internet之间通信的,因此需要把网络节点上连接Internet的eth0接入到这个br-ex的虚拟交换机上),另外还有metadata-agent。

        使用了Neutron组件后,用户可以再OpenStack中为自己的项目创建一个或多个私有网络,这些网络在逻辑上与其他用户的网络隔离,即使在同一个项目中,不同的私有网络也是隔离的。       

计算节点上面的组件介绍:

       计算节点主要负责运行虚拟机。这里我们使用KVM作为底层的虚拟化技术,OpenStack采用libvirt库来管理KVM。网络使用Open vSwitch来和其他节点及网络节点通信。

       Neutron的agent必须安装在哪些需要处理虚拟机网络数据包的节点上。简单地说,由于虚拟机在计算节点上运行,所以虚拟机的网卡数据肯定是从计算节点(安装了nova-compute)物理网卡上出入,所以计算节点必须安装agent。另外,在安装了neutron-DHCP-agent、neutron-l3-agent、neutron-lbaas-agent服务的节点上,也需要安装agent,因为它们也会处理流入/流出虚拟机的网络数据,通常情况下,在安装plugin的agent的同时,也会依赖安装相应的plugin包。

块存储节点上面的组件介绍:

块存储节点负责提供volume(云硬盘)。Cinder服务可以在块存储上创建volume,以块存储的形式通过iSCSI提供给计算节点,计算节点使用底层的libvirt库把volume块存储挂载给虚拟机使用。在控制节点上已经安装了cinder-api和cinder-scheduler,在真正的块存储节点上需要安装cinder-volume的服务,它调度相应程序,在节点上创建或删除volume,并更新维护volume在数据库中的状态。cinder-volume可以使用多种后端来创建块存储,最简单的方式是使用LVM,当然还有其他分布式存储的方式。

博文来自:www.51niux.com

二、Cinder的安装与使用

1.1 Cinder的安装

Cinder介绍

Cinder主要有三个组件服务:cinder-api、cinder-scheduler、cinder-volume。要在控制节点上安装cinder-api和cinder-scheduler,其中cinder-api负责接收其他组件或命令对cinder-volume的请求,而cinder-scheduler则是Cinder的调度程序,调度使用哪个volume。

使用模式三种:

本地硬盘,优点   #IOPS性能最好,缺点:容量限制,迁移麻烦
本地硬盘+云硬盘  #系统使用本地硬盘,数据目录使用云硬盘
云硬盘
注:后端存储:NFS、ISCSI、Glusterfs、ceph都支持。

具体来说Cinder包含以下几个组件:

cinder-api        #接收 API 请求,调用 cinder-volume 执行操作。
cinder-volume     #管理 volume 的服务,与 volume provider 协调工作,管理 volume 的生命周期。运行 cinder-volume 服务的节点被称作为存储节点。
cinder-scheduler  #scheduler 通过调度算法选择最合适的存储节点创建 volume。
volume provider   #数据的存储设备,为 volume 提供物理存储空间。 cinder-volume 支持多种 volume provider,每种 volume provider 通过自己的 driver 与cinder-volume 协调工作。
Message Queue   #Cinder各个子服务通过消息队列实现进程间通信和相互协作。因为有了消息队列,子服务之间实现了解耦,这种松散的结构也是分布式系统的重要特征。
Database Cinder   #有一些数据需要存放到数据库中,一般使用MySQL。数据库是安装在控制节点上的,比如在我们的实验环境中,可以访问名称为“cinder”的数据库。

控制节点操作(现在控制节点和授权节点合并到192.168.1.51上面来了):

# cat /etc/hosts   #多搞一台计算节点出来,所以重新搞了一次测试环境,将授权节点和授权节点合一起了。

192.168.1.51 controller
192.168.1.52 compute01
192.168.1.53 compute02
192.168.1.54 network01
192.168.1.21 compute03
192.168.1.22 cinder01

创建数据库:

# mysql -uroot -p
MariaDB [(none)]> create database cinder;
MariaDB [(none)]>GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'192.168.1.%' IDENTIFIED BY '51niux';
MariaDB [(none)]> GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'localhost' IDENTIFIED BY '51niux';
MariaDB [(none)]> flush privileges;

keystone创建cinder用户:

# source /root/admin-openrc
# openstack user create --domain default --password-prompt cinder     #需要输入密码,密码还是51niux
# openstack role add --project service --user cinder admin   #添加admin角色到cinder用户上

创建cinder和cinderv2服务实体:

# openstack service create --name cinder --description "OpenStack Block Storage" volume 
# openstack service create --name cinderv2 --description "OpenStack Block Storage" volumev2

创建块设备存储服务的API入口点:

也就是创建Cinder端点,服务端点就是Cinder服务的具体提供者的URL,因为对Cinder服务的操作是通过基于HTTP或HTTPS的Rest API来完成的。

#volume服务注册
# openstack endpoint create --region RegionOne volume  public http://controller:8776/v1/%\(tenant_id\)s 
# openstack endpoint create --region RegionOne volume internal http://controller:8776/v1/%\(tenant_id\)s 
# openstack endpoint create --region RegionOne volume admin http://controller:8776/v1/%\(tenant_id\)s
#volumev2服务注册
# openstack endpoint create --region RegionOne volumev2 public http://controller:8776/v2/%\(tenant_id\)s 
# openstack endpoint create --region RegionOne volumev2 internal http://controller:8776/v2/%\(tenant_id\)s 
# openstack endpoint create --region RegionOne volumev2 admin http://controller:8776/v2/%\(tenant_id\)s

安装软件包:

# yum install openstack-cinder  -y

编辑 /etc/cinder/cinder.conf:

# vim /etc/cinder/cinder.conf

[DEFAULT]
rpc_backend = rabbit
my_ip = 1.1.1.51
auth_strategy = keystone

[database]
connection = mysql+pymysql://cinder:51niux@controller/cinder

[oslo_messaging_rabbit]
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = 51niux

[keystone_authtoken]
auth_uri = http://controller:5000  
auth_url = http://controller:35357  
memcached_servers = controller:11211  
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = cinder
password = 51niux

[oslo_concurrency]
lock_path = /var/lib/cinder/tmp

同步数据库:

# su -s /bin/sh -c "cinder-manage db sync" cinder

配置nova计算服务使用块设备存储:

# vim /etc/nova/nova.conf

[cinder]
os_region_name = RegionOne

重启nova计算API服务:

# systemctl restart openstack-nova-api.service

启动cinder块设备存储服务,并将其配置为开机自启:

#systemctl enable openstack-cinder-api.service openstack-cinder-scheduler.service
#systemctl restart openstack-cinder-api.service openstack-cinder-scheduler.service

Cinder存储节点部署(LVM卷组形式)

#这个可以是单独的一块盘多的存储服务器,如果computer节点的盘多呢,也可以在computer节点上面部署。

编辑hosts文件(当然如果配置文件里面不用主机名用IP的形式这里可以不配置):

# cat /etc/hosts

192.168.1.51 controller
192.168.1.52 compute01
192.168.1.53 compute02
192.168.1.54 network01
192.168.1.21 compute03
192.168.1.22 cinder01

安装lvm2软件并启动相关服务:

# yum install lvm2 -y
# systemctl enable lvm2-lvmetad.service
# systemctl start lvm2-lvmetad.service

配置时间同步:

使用前面时间同步的方法这里就不写了。

创建LVM卷组

图片.png

#现在把上图中五块200G的盘做成一个卷组

# pvcreate /dev/vd{b,c,d,e,f}

图片.png

# vgcreate kvmvg_22 /dev/vd{b,c,d,e,f}   #以IP后缀创建一个逻辑卷组,把五块盘分给他

图片.png

安装cinder组件软件包:

# yum install openstack-cinder targetcli python-keystone -y

将控制节点的配置文件cinder.conf 复制到存储节点上:

# scp 192.168.1.51:/etc/cinder/cinder.conf  /etc/cinder/

配置cinder配置文件:

# vim /etc/cinder/cinder.conf     #Cinder 支持多种 volume provider,LVM 是默认的 volume provider。

[DEFAULT]
rpc_backend = rabbit
my_ip = 1.1.1.22
auth_strategy = keystone
default_volume_type = lvmdriver_22    
enabled_backends = lvmdriver_22   #现在就一个,如果创建了多个pv卷组的话,这里要用逗号可开来引用。
glance_api_servers = http://controller:9292

[lvmdriver_22]   #在文件底部添加这一部分配置
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver   #指定driver类型
volume_group = kvmvg_22    #本机创建的pv卷组名称
volume_backend_name = lvmdriver_22   #是backend name,在创建volume的时候可选择。
iscsi_protocol = iscsi    #指定iSCSI协议 
iscsi_helper = lioadm    #指定iSCSI管理工具,这句话如果不加的话,云主机在给实例添加云盘的时候会报错,导致创建出来的卷添加不上

例子连接:http://www.cnblogs.com/sammyliu/p/4219974.html  #讲的还是比较详细的但是配置上还是有所差别的。

下面的操作信息就是因为没有加iscsi_helper = lioadm ,在给实例添加云硬盘时候的报错:

Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher [req-d7f2d32b-fd3d-4a6f-b2b6-7a3fdc7bc518 fa3e0574466e4833bdc7e9f2bc197d05 2d88e50a754a41e4924eda2aa41df9f0 - - -] Exception during message handling: Unexpected error while running command.
Sep 14 11:49:37 compute03 cinder-volume: Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf tgtadm --lld iscsi --op show --mode target
Sep 14 11:49:37 compute03 cinder-volume: Exit code: 96
Sep 14 11:49:37 compute03 cinder-volume: Stdout: u''
Sep 14 11:49:37 compute03 cinder-volume: Stderr: u'/usr/bin/cinder-rootwrap: Executable not found: tgtadm (filter match = tgtadm)\n'
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher Traceback (most recent call last):
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 138, in _dispatch_and_reply
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher     incoming.message))
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 185, in _dispatch
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher     return self._do_dispatch(endpoint, method, ctxt, args)
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher   File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 127, in _do_dispatch
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher     result = func(ctxt, **new_args)
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher   File "/usr/lib/python2.7/site-packages/cinder/volume/manager.py", line 1442, in initialize_connection
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher     volume, connector)
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher   File "/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py", line 760, in create_export
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher     volume_path)
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher   File "/usr/lib/python2.7/site-packages/cinder/volume/targets/iscsi.py", line 210, in create_export
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher     **portals_config)
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher   File "/usr/lib/python2.7/site-packages/cinder/volume/targets/tgt.py", line 140, in create_iscsi_target
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher     run_as_root=True)
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher   File "/usr/lib/python2.7/site-packages/cinder/utils.py", line 148, in execute
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher     return processutils.execute(*cmd, **kwargs)
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher   File "/usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py", line 389, in execute
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher     cmd=sanitized_cmd)
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher ProcessExecutionError: Unexpected error while running command.
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf tgtadm --lld iscsi --op show --mode target
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher Exit code: 96
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher Stdout: u''
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher Stderr: u'/usr/bin/cinder-rootwrap: Executable not found: tgtadm (filter match = tgtadm)\n'
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.953 12080 ERROR oslo_messaging.rpc.dispatcher
Sep 14 11:49:37 compute03 cinder-volume: 2017-09-14 11:49:37.964 12080 ERROR oslo_messaging._drivers.common [req-d7f2d32b-fd3d-4a6f-b2b6-7a3fdc7bc518 fa3e0574466e4833bdc7e9f2bc197d05 2d88e50a754a41e4924eda2aa41df9f0 - - -] Returning exception Unexpected error while running command.

另外在配置文件cinder.conf中加上下面两句话,可以详细的输出日志,在排查问题的时候可能会用到:

[DEFAULT]
verbose = True
debug = True

启动块存储卷服务及其依赖的服务,并设置为开机启动:

# systemctl enable openstack-cinder-volume.service target.service

# systemctl restart openstack-cinder-volume.service target.service

查看检查一下:

# tail -f /var/log/cinder/volume.log    #从下面日志可以看出没有报错,以后操作过程中发现问题也要回来查看此日志

2017-09-14 15:57:20.314 4484 INFO cinder.volume.manager [req-333792a1-bde8-4cd8-961c-cec7ed9f7bf3 - - - - -] Driver initialization completed successfully.
2017-09-14 15:57:20.366 4484 INFO cinder.volume.manager [req-333792a1-bde8-4cd8-961c-cec7ed9f7bf3 - - - - -] Initializing RPC dependent components of volume driver LVMVolumeDriver (3.0.0)
2017-09-14 15:57:20.769 4484 INFO cinder.volume.manager [req-333792a1-bde8-4cd8-961c-cec7ed9f7bf3 - - - - -] Driver post RPC initialization completed successfully.

图片.png

博文来自:www.51niux.com

各节点的查看以及Horizon上面的操作

控制节点上面的查看:

# source /root/admin-openrc

# cinder service-list

图片.png

#从图上可以看到控制节点的 cinder-scheduler(cinder-scheduler的用途是在多backend环境中决定新建volume的放置host首先判断host的状态,只有service状态为up的host才会被考虑。创建volume的时候,根据filter和weight算法选出最优的host来创建volume。迁移volume的时候,根据filter和weight算法来判断目的host是不是符合要求。如果选出一个host,则使用RPC调用cinder-volume来执行volume操作。)

#然后可以看出我们的cinder01@lvmdriver_22(主机和卷组)都已经出现了,域是nova(默认就是nova),当前是up也就是存活状态。

#那个compute03@lvmdriver-1 可以忽略掉,那是我之前创建的一个。

Horizon上面操作创建一个云盘挂载到实例上面:

项目==》卷==》创建卷

图片.png

图片.png

#是点击编辑卷右边的下拉三角来选择管理连接

图片.png

图片.png

#出现上图基本算是成功了,等待几秒钟立马就连接成功了。

图片.png

上云主机上面查看:

图片.png

#这是从控制台进行的操作,可以看到已经格式化并进行了挂载。

存储节点上面查看:

# tail -f /var/log/cinder/volume.log   #从日志可以看出没有报错提示操作成功

2017-09-14 16:09:40.761 4484 INFO cinder.volume.flows.manager.create_volume [req-844620c4-adc0-46de-b7f6-d27e82b43013 fa3e0574466e4833bdc7e9f2bc197d05 2d88e50a754a41e4924eda2aa41df9f0 - - -] Volume 5c938112-7554-4670-9656-8b44ca0152dc: being created as raw with specification: {'status': u'creating', 'volume_size': 200, 'volume_name': 'volume-5c938112-7554-4670-9656-8b44ca0152dc'}
2017-09-14 16:09:41.301 4484 INFO cinder.volume.flows.manager.create_volume [req-844620c4-adc0-46de-b7f6-d27e82b43013 fa3e0574466e4833bdc7e9f2bc197d05 2d88e50a754a41e4924eda2aa41df9f0 - - -] Volume volume-5c938112-7554-4670-9656-8b44ca0152dc (5c938112-7554-4670-9656-8b44ca0152dc): created successfully
2017-09-14 16:09:41.306 4484 INFO cinder.volume.manager [req-844620c4-adc0-46de-b7f6-d27e82b43013 fa3e0574466e4833bdc7e9f2bc197d05 2d88e50a754a41e4924eda2aa41df9f0 - - -] Created volume successfully.
2017-09-14 16:12:57.363 4484 INFO cinder.volume.targets.lio [req-b946702a-339b-4541-af1b-b69e6a8f008b fa3e0574466e4833bdc7e9f2bc197d05 2d88e50a754a41e4924eda2aa41df9f0 - - -] Creating iscsi_target for volume: volume-5c938112-7554-4670-9656-8b44ca0152dc
2017-09-14 16:12:59.140 4484 INFO cinder.volume.manager [req-b946702a-339b-4541-af1b-b69e6a8f008b fa3e0574466e4833bdc7e9f2bc197d05 2d88e50a754a41e4924eda2aa41df9f0 - - -] Initialize volume connection completed successfully.
2017-09-14 16:13:02.039 4484 INFO cinder.volume.manager [req-17206180-53a9-4acc-baf1-c965b5eca1a3 fa3e0574466e4833bdc7e9f2bc197d05 2d88e50a754a41e4924eda2aa41df9f0 - - -] Attach volume completed successfully.

图片.png

计算节点上面查看:

因为我现在又两个计算节点了,我通过操作查看找到gskvm05这台实例在compute01这台计算节点上面。

图片.png

#注意上图有个_base目录,镜像从Glance所在的服务器复制到这个目录下,复制完成后,计算节点便从_base下的文件生成虚拟机。在这个计算节点生成第二台同样配置的该镜像的虚拟机时,就不需要再从Glance复制到这个计算节点上了。Nova所用的虚拟机磁盘方式是qcow2时,绝对不能删除_base中相应的镜像文件,因为此时instance中的disk是在_base中文件的基础上增量使用的。

#通过上图可以看到确实在啊,因为标识号是一致的。

# cat 2d874993-f868-49e2-b8fc-a887f1d05b1f/libvirt.xml|grep -A 2 '<domain type="kvm">'

<domain type="kvm">
  <uuid>2d874993-f868-49e2-b8fc-a887f1d05b1f</uuid>  
  <name>instance-0000000b</name>    #这个字段是我们需要的,因为这里是virt list --all显示的名称

图片.png

# virsh edit instance-0000000b   #查看配置文件,这里只截图添加云盘的那段

    <disk type='file' device='disk'>  #这是本身自己的系统硬盘的位置
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/nova/instances/2d874993-f868-49e2-b8fc-a887f1d05b1f/disk'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    <disk type='block' device='disk'>   #这是挂载的那块卷(云盘)的配置区域位置
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/disk/by-path/ip-1.1.1.22:3260-iscsi-iqn.2010-10.org.openstack:volume-5c938112-7554-4670-9656-8b44ca0152dc-lun-0'/>   #这是那块挂载盘的位置
      <target dev='vdb' bus='virtio'/>
      <serial>5c938112-7554-4670-9656-8b44ca0152dc</serial>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>

注:这里还有一个问题解决就写在这里吧,还是Mysql的问题:

集群运行了一段时间之后,web页面老是弹出这个连接失败,那个连接失败的,查看控制节点的日志又有新的报错了:

2017-09-14 14:37:36.668 50625 ERROR nova.servicegroup.drivers.db     dbapi_connection.rollback()
2017-09-14 14:37:36.668 50625 ERROR nova.servicegroup.drivers.db   File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 777, in rollback
2017-09-14 14:37:36.668 50625 ERROR nova.servicegroup.drivers.db     self._execute_command(COMMAND.COM_QUERY, "ROLLBACK")
2017-09-14 14:37:36.668 50625 ERROR nova.servicegroup.drivers.db   File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 1064, in _execute_command
2017-09-14 14:37:36.668 50625 ERROR nova.servicegroup.drivers.db     self._write_bytes(packet)
2017-09-14 14:37:36.668 50625 ERROR nova.servicegroup.drivers.db   File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 1016, in _write_bytes
2017-09-14 14:37:36.668 50625 ERROR nova.servicegroup.drivers.db     raise err.OperationalError(2006, "MySQL server has gone away (%r)" % (e,))
2017-09-14 14:37:36.668 50625 ERROR nova.servicegroup.drivers.db OperationalError: (pymysql.err.OperationalError) (2006, "MySQL server has gone away (error(32, 'Broken pipe'))")
2017-09-14 14:37:36.668 50625 ERROR nova.servicegroup.drivers.db

#http://blog.csdn.net/u013673976/article/details/45939297     #这篇文章说的听明白的,但是需要在程序做改动,加上pool_recycle=3600这句话。

#mysql出现ERROR : (2006, 'MySQL server has gone away') 的问题意思就是指client和MySQL server之间的链接断开了。造成这样的原因一般是sql操作的时间过长,或者是传送的数据太大(例如使用insert ... values的语句过长, 这种情况可以通过修改max_allowed_packed的配置参数来避免,也可以在程序中将数据分批插入)。

 ERROR cinder.service OperationalError: (pymysql.err.OperationalError) (2006, "MySQL server has gone away (error(32, 'Broken pipe'))")  #当然还有一种可能就是mysql重启啦,或者mysql客户端跟mysql服务端之间的连接出现问题

#如果重启了mysql服务器后最好等一两分钟再操作,不然会报这个连接不上哪个连接不上,如果还不行,最好将相关跟mysql想连接的服务重启一下如果可以的话。

这里我就不再程序上面做改动,改下mysql的配置吧:

MariaDB [(none)]>show global variables like '%timeout%';    #查看下超时时间

图片.png

# vim /etc/my.cnf  #修改配置文件进行参数调整,加大超时时间和添加缓存用来控制其通信缓冲区的最大长度。

[mysqld]
wait_timeout=2880000
interactive_timeout = 2880000
max_allowed_packet = 100M

# systemctl daemon-reload

# service mariadb restart    #重启mysql服务,再次登录mysql然后用上面的查看超时命令查看一下是否更改了。

博文来自:www.51niux.com

小小的收个尾:

卷的类型还没有设置,这里设置下卷类型:

# cinder type-create lvm   #创建一个lvm类型

图片.png

# cinder type-key lvm set volume_backend_name=lvmdriver_22    #将我们创建的那个卷组名称跟lvm关联一下

图片.png

图片.png

#当然更改卷类型没多大意思,创建镜像做的启动卷的时候可启用那里自动就变成了True。

#当然还有NFS,GFS各种当做后端存储的,掌握一两种其他的意思都差不多,这里就不一一记录了。

作者:忙碌的柴少 分类:OpenStack 浏览:9039 评论:1
留言列表
josonle
josonle 灰常好  回复
发表评论
来宾的头像