nova挂载cinder卷流程分析,novacinder


                                               Nova挂载cinder卷流程分析
  
 1. nova通过命令nova volume-attach server volume device-name或者http请求
 Req:POST /v2/{tenant-id}/servers/{server-id}/os-volume_attachments' 
 Body:{'volumeAttachment': {'device': '/dev/vdb',
        'volumeId': '951be889-b794-4723-9ac9-efde61cacf3a'}}'
发起卷挂载请求。


 2. nova获取可用的挂载点,若指定了挂载点则验证其有效性,没有则找出一个有效的挂载点,同时创建数据库信息,在block_device_mapping表写入一条如下信息:
   *************************** 1. row ***************************
           created_at: 2014-07-07 06:24:12
           updated_at: NULL
           id: 6
           device_name: /dev/vdb
           volume_id: b5ce6d0f-e7db-41cb-a5f1-5c47454248c1
           volume_size: NULL
           connection_info: NULL
           instance_uuid:9de3d836-be91-4348-9fc1-b67d8623157f                    source_type: volume
           destination_type: volume
   
 3. nova向cinder发送请求,获取卷信息,请求和回复如下所示:
    Req: GET /v1/{tenant-id}/volumes/{volume-id}
        Header:-H "X-Auth-Token: 8138b1ace73b4e359122be531c55d2dd"
    Res: 
    {
      "volume": {
            "status": "available",
            "display_name": "dfg",
          "attachments": [],
          "availability_zone": "nova",
          "bootable": "false",
          "encrypted": false,
          "created_at": "2014-06-30T08:33:47.000000",
          "os-vol-tenant-attr:tenant_id":  "xxx-tenant-id",
          "display_description": null,
          "os-vol-host-attr:host": "xfolsom",
          "volume_type": "None",
          "snapshot_id": null,
          "source_volid": null,
          "os-vol-mig-status-attr:name_id": null,
          "metadata": {
              "readonly": "False"
          },
          "id": "951be889-b794-4723-9ac9-efde61cacf3a",
          "os-vol-mig-status-attr:migstat": null,
          "size": 1
         }
        }


 4.nova检查卷的状态,若volume['status']!='available',抛出400异常,异常信息为:status must be 'available',一个典型的错误信息如下:
ERROR (BadRequest): Invalid volume: status must be 'available' (HTTP 400)
   若volume['status']=='attached',抛出ERROR (BadRequest): Invalid volume: already attached (HTTP 400)
   
 5. 向cinder发送请求,保留这个盘,避免被别人使用,请求和回复如下:
    Req:POST  v1/{tenant-id}/volumes/{volume-id}/action
        Header:-H "X-Auth-Token: 8138b1ace73b4e359122be531c55d2dd"
        Body:{"os-reserve": null}
   Res:Http 202
  Cinder收到请求后,若volume['status']=='available',则将状态改为volume['status']==‘attaching’,否则抛出400异常。


 6. nova获取connector,得到connector信息如下所示:
   {'ip': '10.160.162.24', 'host': 'nvs-1', 'initiator': 'iqn.1993-08.org.debian:01:35725f2f2a'}
   其中initiator为/etc/iscsi/initiatorname.iscsi文件内容。


7. 将上一步得到的connector和volume-id发送给cinder,初始化连接接口,获取iscsi的connection_info,cinder返回connection_info,其请求和回复信息如下所示:
    Req:POST  v1/{tenant-id}/volumes/{volume-id}/action
        Header:-H "X-Auth-Token: 8138b1ace73b4e359122be531c55d2dd"
        Body:
        {
         "os-initialize_connection": {
           "connector": {
               "ip": "10.160.161.32",
               "host": "xfolsom",
               "initiator": "iqn.1993-08.org.debian:01:11a1a0aa28f1"
           }
          }
        }
    Res:
        {u'data': {u'access_mode': u'rw',
         u'auth_method': u'CHAP',
         u'auth_password': u'jVu68HfYhUBtAQ5vQGpq',
         u'auth_username': u'pg9Zc8o7JiCpjf6LHh9C',
         u'encrypted': False,
         u'qos_specs': None,
         u'target_discovered': False,
         u'target_iqn':      u'iqn.2010-10.org.openstack:volume-b5ce6d0f-a5f1-5c47454248c1',
         u'target_lun': 1,
         u'target_portal': u'10.160.162.24:3260',
         u'volume_id': u'b5ce6d0f-e7db-41cb-a5f1-5c47454248c1'},
         u'driver_volume_type': u'iscsi'}


 8. 若第6、7步有异常(不区分异常种类,所有异常都一样),则给cinder发送unreserve请求,修改卷的状态,请求和回复如下:
    Req:POST  v1/{tenant-id}/volumes/{volume-id}/action
        Header:-H "X-Auth-Token: 8138b1ace73b4e359122be531c55d2dd"
        Body:{"os-unreserve": null}
   Res:Http 202
   Cinder这边做如下处理:若volume['status'] == "attaching",则将其状态改为‘available’,同时nova这边会删除block_device_mapping表对应的数据库行,终止卷挂载行为。
   
 9. nova调用驱动挂载卷到宿主机上,nova默认是调用LibvirtISCSIVolumeDriver驱动的connect_volume方法, 该方法用libvirt执行一些相关的iscsi命令挂载云硬盘到宿主机上,然后调用libvirt将该卷挂载到虚拟机上去,若在挂载卷到虚拟机过程中出现异常,则将前面卷挂载到宿主机这一步操作撤销,执行的是LibvirtISCSIVolumeDriver驱动的disconnect_volume方法。至此,挂载过程完成。


 10. 给cinder发送请求挂载信息,通知cinder此卷已经完成宿主机虚拟机挂载过程:
   Req:POST  v1/{tenant-id}/volumes/{volume-id}/action
   Header:-H "X-Auth-Token: 8138b1ace73b4e359122be531c55d2dd"
   Body:
        {
           "os-attach": {
           "instance_uuid": "5f1c49d6-f3ec-4564-9b9a-f6b3dc938dd2",
           "mountpoint": "/dev/vdb",
           "mode": "rw"
              }
         }
   Res:Http 202
   Cinder收到请求后,进行挂载。从cinder的代码上看,并未做什么操作,只是将信息更新到数据库而已,将卷的状态改为in-use。
   
 11. nova更新数据库,主要把connection_info信息更新进去。更新后的数据库如下所示:
   *************************** 1. row ***************************
           created_at: 2014-07-07 06:24:12
           updated_at: 2014-07-07 07:03:28
           deleted_at: NULL
                   id: 6
          device_name: /dev/vdb
          delete_on_termination: 0
          snapshot_id: NULL
          volume_id: b5ce6d0f-e7db-41cb-a5f1-5c47454248c1
          volume_size: NULL
          no_device: NULL
      connection_info: {"driver_volume_type": "iscsi", "serial": "b5ce6d0f-e7db-41cb-a5f1-5c47454248c1", "data": {"access_mode": "rw", "target_discovered": false, "encrypted": false, "qos_specs": null, "target_iqn": "iqn.2010-10.org.openstack:volume-b5ce6d0f-e7db-41cb-a5f1-5c47454248c1", "target_portal": "10.160.162.24:3260", "volume_id": "b5ce6d0f-e7db-41cb-a5f1-5c47454248c1", "target_lun": 1, "device_path": "/dev/disk/by-path/ip-10.160.162.24:3260-iscsi-iqn.2010-10.org.openstack:volume-b5ce6d0f-e7db-41cb-a5f1-5c47454248c1-lun-1", "auth_password": "jVu68HfYhUBtAQ5vQGpq", "auth_username": "pg9Zc8o7JiCpjf6LHh9C", "auth_method": "CHAP"}}
        instance_uuid: 9de3d836-be91-4348-9fc1-b67d8623157f
              deleted: 0
          source_type: volume
     destination_type: volume
   
   













openstack组件问题

OpenStack其实有三与存储相关组件组件被人熟知程度和组件本身出现时间早晚相符按熟悉程度排列下:
Swift——提供对象存储 (Object Storage)概念上类似于Amazon S3服务过swift具有扩展性、冗余和持久性也兼容S3 API
Glance——提供虚机镜像(Image)存储和管理包括了多与Amazon AMI catalog相似功能(Glance台数据从实践来看存放Swift
Cinder——提供块存储(Block Storage)类似于AmazonEBS块存储服务目前仅给虚机挂载使用
(AmazonOpenStack设计之初假象对手和挑战对象基本上关键功能模块都有对应项目除了上面提组件对于AWS重要EC2服务OpenStackNova来对应并且保持和EC2 API兼容性方法实现)
组件Glance主要虚机镜像管理相对简单;Swift作对象存储已经成熟连CloudStack也支持Cinder比较新出现块存储设计理念并且和商业存储有结合机会厂商比较积极
Swift
关于Swift架构和部署讨论除了官方网站网上也有多文章重复.(也参考我之前OpenStack国行活动上海站演讲PPT)从开发上看近也没有太大结构性调整我想主要说说比较适用应用领域好了
从我所了解实际案例来看Swift出现领域有4(应该还有更多希望大家看实际用例能够指教)
1.网盘
Swift对称分布式架构和多proxy多节点设计导致从基因里适合于多用户大并发应用模式典型应用莫过于类似Dropbox网盘应用Dropbox去年底已经突破亿用户数对于种规模访问良好架构设计能够支撑根本原因
Swift对称架构使得数据节点从逻辑上看处于同级别每台节点上同时都具有数据和相关元数据并且元数据核心数据结构使用哈希环致性哈希算法对于节点增减都只需重定位环空间小部分数据,具有较好容错性和扩展性另外数据无状态数据磁盘上都完整存储几点综合起来保证了存储本身良好扩展性
另外和应用结合上Swift说HTTP协议种语言使得应用和存储交互变得简单需要考虑底层基础构架细节应用软件需要进行任何修改让系统整体扩展非常大程度
2.IaaS公有云
Swift设计线性扩展高并发和多租户支持等特性使得也非常适合做IaaS选择公有云规模较大更多大量虚机并发启动种情况对于虚机镜像台存储具体来说实际上挑战于大数据(超过G)并发读性能SwiftOpenStack开始镜像库台存储经过RACKSpace上千台机器部署规模下数年实践Swift已经被证明成熟选择
另外基于IaaS要提供上层SaaS 服务多租户避免问题Swift架构设计本身支持多租户样对接起来更方便
3.备份归档
RackSpace主营业务数据备份归档Swift领域也久经考验同时们还延展出种新业务--热归档由于长尾效应数据能被调用时间窗越来越长热归档能够保证应用归档数据能够分钟级别重新获取和传统磁带机归档方案数小时而言进步
4. 移动互联网和CDN
移动互联网和手机游戏等产生大量用户数据数据量用户数Swift能够处理领域
至于加上CDN使用Swift云存储直接响应移动设备需要专门服务器去响应HTTP请求需要数据传输再经过移动设备上文件系统直接用HTTP 协议上传云端把经常被平台访问数据缓存起来利用优化机制数据地点分发用户能提高访问速度近看Swift开发社区有人讨论视频网站应用和Swift结合值得关注方向
Glance
Glance比较简单虚机镜像存储向前端nova(或者安装了Glance-client虚拟管理平台)提供镜像服务包括存储查询和检索模块本身存储大量数据需要挂载台存储(SwiftS3)来存放实际镜像数据
Glance主要包括下面几部分:
l API service: glance-api 主要用来接受Nova各种api调用请求请求放入RBMQ交由台处理
l Glacne-registry 用来和MySQL数据库进行交互存储或者获取镜像元数据注意刚才SwiftSwift自己Storage Server保存元数据元数据指保存MySQL数据库关于镜像些信息元数据属于Glance
l Image store: 台存储接口通过获取镜像台挂载默认存储Swift同时也支持Amazon S3等其镜像
Glance从某种角度上看起来有点像虚拟存储也提供API实现比较完整镜像管理功能理论上其云平台也使用
Glance比较简单又限于云内部没啥多展开讨论看看新出来块存储组件Cinder目前我对Cinder基本看法总体设计细节和功能还有多需要完善地方成熟产品还有点距离
Cinder
OpenStackF版本有比较大改变之前Nova部分持久性块存储功能(Nova-Volume)分离了出来独立组件Cinder通过整合端多种存储用API接口外界提供块存储服务主要核心对卷管理允许对卷类型快照进行处理
Cinder包含下三主要组成部分

API service:Cinder-api 主要服务接口, 负责接受和处理外界API请求请求放入RabbitMQ队列交由端执行 Cinder目前提供Volume API V2
Scheduler service: 处理任务队列任务并根据预定策略选择合适Volume Service节点来执行任务目前版本cinder仅仅提供了Simple Scheduler, 该调度器选择卷数量活跃节点来创建卷
Volume service: 该服务运行存储节点上管理存储空间塔处理cinder数据库维护状态读写请求通过消息队列和直接块存储设备或软件上与其进程交互存储节点都有Volume Service若干存储节点联合起来构成存储资源池

Cinder通过添加同厂商指定drivers来了支持同类型和型号存储目前能支持商业存储设备有EMC 和IBM几款也能通过LVM支持本地存储和NFS协议支持NAS存储NetappNAS应该也没问题好像华努力我前段时间还Cinderblueprints看IBMGPFS分布式文件系统版本应该会添加进来
目前Cinder主要和OpenstackNova内部交互之提供虚机实例所需要卷Attach上去理论上也单独向外界提供块存储
部署上把三服务部署台服务器独立部署同物理节点
Cinder还够成熟有几明显问题还没好解决支持商业存储还够多而且还支持FC SAN另外单点故障隐患没解决内部schedule调度算法也太简单另外由于把各种存储整合进来又加了管理倒有办法了效率肯定有影响性能肯定有损耗没办法事了
Openstack通过两年多发展变得越来越庞大目前光存储出现了三种:对象存储、镜像存储和块存储了满足更多需求体现出开源项目灵活快速特性说来当选择套存储系统时候考虑来会被多应用所共同使用应该视长期决策Openstack作开放系统主要解决软硬件供应商锁定问题随时选择新硬件供应商硬件和已有硬件组成混合集群管理替换软件技术服务提供商用动应用开源本身优势

openstack的问题。

OpenStack其实有三与存储相关组件组件被人熟知程度和组件本身出现时间早晚相符按熟悉程度排列下:
Swift——提供对象存储 (Object Storage)概念上类似于Amazon S3服务过swift具有扩展性、冗余和持久性也兼容S3 API
Glance——提供虚机镜像(Image)存储和管理包括了多与Amazon AMI catalog相似功能(Glance台数据从实践来看存放Swift
Cinder——提供块存储(Block Storage)类似于AmazonEBS块存储服务目前仅给虚机挂载使用
(AmazonOpenStack设计之初假象对手和挑战对象基本上关键功能模块都有对应项目除了上面提组件对于AWS重要EC2服务OpenStackNova来对应并且保持和EC2 API兼容性方法实现)
组件Glance主要虚机镜像管理相对简单;Swift作对象存储已经成熟连CloudStack也支持Cinder比较新出现块存储设计理念并且和商业存储有结合机会厂商比较积极
Swift
关于Swift架构和部署讨论除了官方网站网上也有多文章重复.(也参考我之前OpenStack国行活动上海站演讲PPT)从开发上看近也没有太大结构性调整我想主要说说比较适用应用领域好了
从我所了解实际案例来看Swift出现领域有4(应该还有更多希望大家看实际用例能够指教)
1.网盘
Swift对称分布式架构和多proxy多节点设计导致从基因里适合于多用户大并发应用模式典型应用莫过于类似Dropbox网盘应用Dropbox去年底已经突破亿用户数对于种规模访问良好架构设计能够支撑根本原因
Swift对称架构使得数据节点从逻辑上看处于同级别每台节点上同时都具有数据和相关元数据并且元数据核心数据结构使用哈希环致性哈希算法对于节点增减都只需重定位环空间小部分数据,具有较好容错性和扩展性另外数据无状态数据磁盘上都完整存储几点综合起来保证了存储本身良好扩展性
另外和应用结合上Swift说HTTP协议种语言使得应用和存储交互变得简单需要考虑底层基础构架细节应用软件需要进行任何修改让系统整体扩展非常大程度
2.IaaS公有云
Swift设计线性扩展高并发和多租户支持等特性使得也非常适合做IaaS选择公有云规模较大更多大量虚机并发启动种情况对于虚机镜像台存储具体来说实际上挑战于大数据(超过G)并发读性能SwiftOpenStack开始镜像库台存储经过RACKSpace上千台机器部署规模下数年实践Swift已经被证明成熟选择
另外基于IaaS要提供上层SaaS 服务多租户避免问题Swift架构设计本身支持多租户样对接起来更方便
3.备份归档
RackSpace主营业务数据备份归档Swift领域也久经考验同时们还延展出种新业务--热归档由于长尾效应数据能被调用时间窗越来越长热归档能够保证应用归档数据能够分钟级别重新获取和传统磁带机归档方案数小时而言进步
4. 移动互联网和CDN
移动互联网和手机游戏等产生大量用户数据数据量用户数Swift能够处理领域
至于加上CDN使用Swift云存储直接响应移动设备需要专门服务器去响应HTTP请求需要数据传输再经过移动设备上文件系统直接用HTTP 协议上传云端把经常被平台访问数据缓存起来利用优化机制数据地点分发用户能提高访问速度近看Swift开发社区有人讨论视频网站应用和Swift结合值得关注方向
Glance
Glance比较简单虚机镜像存储向前端nova(或者安装了Glance-client虚拟管理平台)提供镜像服务包括存储查询和检索模块本身存储大量数据需要挂载台存储(SwiftS3)来存放实际镜像数据
Glance主要包括下面几部分:
l API service: glance-api 主要用来接受Nova各种api调用请求请求放入RBMQ交由台处理
l Glacne-registry 用来和MySQL数据库进行交互存储或者获取镜像元数据注意刚才SwiftSwift自己Storage Server保存元数据元数据指保存MySQL数据库关于镜像些信息元数据属于Glance
l Image store: 台存储接口通过获取镜像台挂载默认存储Swift同时也支持Amazon S3等其镜像
Glance从某种角度上看起来有点像虚拟存储也提供API实现比较完整镜像管理功能理论上其云平台也使用
Glance比较简单又限于云内部没啥多展开讨论看看新出来块存储组件Cinder目前我对Cinder基本看法总体设计细节和功能还有多需要完善地方成熟产品还有点距离
Cinder
OpenStackF版本有比较大改变之前Nova部分持久性块存储功能(Nova-Volume)分离了出来独立组件Cinder通过整合端多种存储用API接口外界提供块存储服务主要核心对卷管理允许对卷类型快照进行处理
Cinder包含下三主要组成部分

API service:Cinder-api 主要服务接口, 负责接受和处理外界API请求请求放入RabbitMQ队列交由端执行 Cinder目前提供Volume API V2
Scheduler service: 处理任务队列任务并根据预定策略选择合适Volume Service节点来执行任务目前版本cinder仅仅提供了Simple Scheduler, 该调度器选择卷数量活跃节点来创建卷
Volume service: 该服务运行存储节点上管理存储空间塔处理cinder数据库维护状态读写请求通过消息队列和直接块存储设备或软件上与其进程交互存储节点都有Volume Service若干存储节点联合起来构成存储资源池

Cinder通过添加同厂商指定drivers来了支持同类型和型号存储目前能支持商业存储设备有EMC 和IBM几款也能通过LVM支持本地存储和NFS协议支持NAS存储NetappNAS应该也没问题好像华努力我前段时间还Cinderblueprints看IBMGPFS分布式文件系统版本应该会添加进来
目前Cinder主要和OpenstackNova内部交互之提供虚机实例所需要卷Attach上去理论上也单独向外界提供块存储
部署上把三服务部署台服务器独立部署同物理节点
Cinder还够成熟有几明显问题还没好解决支持商业存储还够多而且还支持FC SAN另外单点故障隐患没解决内部schedule调度算法也太简单另外由于把各种存储整合进来又加了管理倒有办法了效率肯定有影响性能肯定有损耗没办法事了
Openstack通过两年多发展变得越来越庞大目前光存储出现了三种:对象存储、镜像存储和块存储了满足更多需求体现出开源项目灵活快速特性说来当选择套存储系统时候考虑来会被多应用所共同使用应该视长期决策Openstack作开放系统主要解决软硬件供应商锁定问题随时选择新硬件供应商硬件和已有硬件组成混合集群管理替换软件技术服务提供商用动应用开源本身优势

相关内容