openstack——Nova组件

最新推荐文章于 2020-05-24 11:15:34 发布

胖可仃

最新推荐文章于 2020-05-24 11:15:34 发布

阅读量552

点赞数

分类专栏： openstack 文章标签： openstack

本文链接：https://blog.csdn.net/herhan1/article/details/103715679

版权

openstack 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

`Nova`

搭建本地的`pip`源

《基于CentOS的pip本地源搭建方法》
- 采用bandsnatch与pypi官方源同步，不能指定单个软件包同步
- bandsnatch仅支持与https的源同步，不支持与http的源同步
- 同步的软件数量巨大，耗时长，且网络质量差，经常超时失败
《搭建本地pypi源方法 – 仅同步openstack依赖的的pypi软件包》
- 采用pip2pi进行同步，支持单个软件包同步，也支持批量软件包同步
- 既支持与https的源同步，也支持与http的源同步
- 同步的软件数量少，耗时短，并且可以与国内优秀的源同步（比如豆瓣）

`Nova`架构介绍

简单架构

简单架构
- 单点服务
- 无负载均衡
- 无高可靠

复杂架构

复杂架构
- 负载均衡
- 高可靠

`nova`的服务

`Nova API`

nova-api服务
- 接收和响应用户的API请求
  - api接口调用，与命令行调用相区别

    #API接口：
    curl -H "X-Auth-Token: <Token ID>" http://192.168.100.70:8774/v2/<Tenant ID>/servers
    #命令行：
    nova list

服务启动脚本（devstack vs. packstack）
- /usr/bin/nova-api vs. /etc/init.d/openstack-nova-api (对比二者的内容)
服务监听端口（netstat -anp | grep pid, pid是nova-api主进程的id）
- 三个端口： 8773,8774和8775

扩展性
- 服务入口是否会成为瓶颈，比如单个服务无法处理大量并发请求

ps aux | grep nova-api （devstack方式部署）
- 发现启动13个nova-api进程，其中一个主进程，实际为12个nova-api服务进程
启动多少个nova-api服务进程由谁来控制
- nova.conf中的默认配置（devstack方式部署）
- nova.conf中的默认配置（packstack方式部署）
devstack方式部署时nova.conf的自动生成
- devstack/lib/nova中的函数create_nova_conf
三个配置项必须要 >= 1
- 思考（作业1）：在packstack部署的时候，ec2_workers和metadata_workers都没有配置,前面看到，ec2_workers=24, 那么此时有多少个nova-api服务进程?

`Nova-Scheduler`

nova-scheduler服务 – 调度器
- 虚拟机调度，即创建虚拟机时，根据物理机的资源使用情况，虚拟机应该被分配到哪台物理机上运行
- 服务启动（devstack vs. packstack）
```
    /usr/bin/nova-scheduler --config-file /etc/nova/nova.conf
    /etc/init.d/openstack-nova-scheduler start #（看下启动脚本） 
```
- 监听端口（ps aux | grep pid）
  - nova-scheduler没有固定的端口
  - nova-scheduler只对内部组件提供服务，并不对外服务
- 调度算法，即选出最佳物理机的算法，主要包括过滤算法和权重算法两个阶段
```
    scheduler_driver = nova.scheduler.filter_scheduler.filterScheduler
```
- 目前支持的过滤算法（23种左右）,默认加载以下算法：
  - RetryFilter
  - AvailabilityZoneFilter
  - RamFilter
  - ComputeFilter
  - ComputeCapabilitiesFilter
  - ImagePropertiesFilter
  - CoreFilter
- 过滤算法
  - 选择，yes or no?
  - 符合条件的host进入下一轮
- 权重算法
  - 排序
  - 符合条件的host进行优先级排序
- 过滤（filter）算法
  - RetryFilter
    - 如果虚拟机调度失败，是否重新调度的次数（ scheduler_max_attempts=3 ）
  - AvailabilityZoneFilter
    - 是否支持虚拟机选择availability zone(可用区)
  - RamFilter
    - 选择能够满足虚拟机内存要求的物理机，如果不指定默认，不判断内存资源
    - 指定内存超分比率，ram_allocation_ratio=1.58773`
  - ComputeCapabilitiesFilter
    - 选择具有某些特定属性的物理机
    - 以namespace:key的格式来执行属性，比如AZ1:node1
  - ImagePropertiesFilter
    - 根据镜像中指定的某一属性（properties）来过滤物理机
```
    glance image-update img-uuid --property architecture=arm --property hypervisor_type=qemu 
```
    - 以这个镜像创建虚拟机，只能选择体系结构式arm，hypervisor是qemu的主机
  - CoreFilter
    - 选择哪些能够满足虚拟机cpu要求的那些物理机
    - 如果不设置，单个虚拟机的和数可以超过物理机的和数
    - 可以指定cpu超分比率， cpu_allocation_ratio=16.0
    - 思考：如果一台4核的物理机，cpu_allocation_ratio=2，那么最大可以创建多少核的虚拟机
- 权重（weight）算法-权重是如何计算出来的?
  - ram_weight_multiplier(内存权重系数)
    - 整数，选出内存最大的物理机 $- >$ 虚拟机在所有物理机上平铺（spreading）
    - 负数，选出内存最小的物理机 $- >$ 虚拟机在部分物理机上堆叠（stacking）
  - scheduler_host_subset_size(最佳机器的子集大小)
    - 如果有N个机器的优先级相同，则随机选择scheduler_host_subset_size个
    - scheduler_host_subset_size = 1（默认）
  - scheduler_weight_classes（权重计算算法选择类）
    - RamWeigher，内存权重排序算法，默认算法
    - MetricsWeigher，自定义的权重排序算法

`Nova-conductor`

数据库访问代理服务
- 防止计算节点直接访问数据库
  - 计算节点相对不可信、高风险的
  - 负载均衡，可扩展性好
- 不能与nova-compute部署在同一节点上
- 如果不想使用nova-conductor，在nova.conf中增加配置项：
  - use_local = True

`Nova-VNC`服务

VNC访问方式原理
- VNC访问方式
  - host_ip:port,比如221.130.253.135:1
  - 如何获得虚拟机对应的vnc port? -> vncdisplay domain_id
  - 客户端软件：vnc viewer, tightVNC等等
- VNC访问原理
  - 基于RFB协议，即Remote FrameBuffer protocol
  - 有两部分组成：vnc server和vnc client
  - Server和client端共享图形界面
noVNC访问方式原理
- 由两个服务构成：nova-novncproxy和nova-consoleauth
- nova-novncproxy的功能
  - 将公网（public network）和私网（private network）隔离
    - vnc client运行在公网上，vnc server运行在私网上
    - vnc proxy作为连接二者的桥梁
  - 通过token对vnc client进行验证
  - 可以同时支持多种vnc client
    - novnc,基于html5 websockets,Canvas和JavaScripts实现
    - Spice,redhat的虚拟桌面技术
- nova-consoleauth服务
  - 用于进行token的验证
- 访问原理
  - nova-novncproxy监听6080端口
  - 作为用户vnc访问的一道大门，处理用户的vnc访问请求
noVNC访问原理
1. 一个用户试图从浏览器里面打开连接到虚拟机的VNC Client
2. 浏览器向nova-api发送请求，要求返回访问vnc的url
3. nova-api调用nova-compute的get_vnc_console方法，要求返回连接VNC的信息
4. nova-compute调用libvirt的get_vnc_console函数
5. libvirt会通过解析虚拟机的的配置文件/instance-00000001.xml来获得VNC Server的信息
6. libvirt将host, port等信息以json格式返回给nova-compute
7. nova-compute会随机生成一个UUID作为Token
8. nova-api会调用nova-consoleauth的authorize_console函数
9. nova-api将connect_info中的access url信息返回给浏览器
10. 当浏览器试图打开这个链接时，会将请求发送给nova-novncproxy
11. nova-novncproxy调用nova-consoleauth的check_token函数
12. nova-consoleauth验证了这个token，将这个instance对应的connect_info返回给nova-novncproxy
13. nova-novncproxy通过connect_info中的host, port等信息，连接compute节点上的VNC Server，从而开始了proxy的工作
14. nova-compute将libvirt返回的信息以及配置文件中的信息综合成connect_info返回给nova-api
noVNC配置项

    vncserver_proxyclient_address = compute_ip
    vncserver_listen = 0.0.0.0
    vnc_enabled = true
    novncproxy_base_url = http://10.0.10.10:6080/vnc_auto.html

`Nova-cert`和`Nova-objectstore`

nova-cert服务
- X509认证服务，仅用于调用openstack兼容EC2的API时候使用
nova-objectstore服务
- nova对象存储接口服务，通过此服务来访问Swift或S3

`Nova-compute`

nova-compute服务
- 所有的计算节点要运行的服务
- 主要处理虚拟机相关的各种操作，虚拟机的创建，删除，挂起，重启等
- 可以通过nova service-list来查看当前环境中的所有的nova服务

虚拟机创建流程分析

openstack集群的初始状态
1.获取用户凭证并将HTTP请求发送到Keystone
2.生成并发送回用于nova-api的身份验证令牌
3.将以“创建实例”形式指定的新实例参数转换为REST API请求并调用nova-api
4.验证身份验证令牌和访问权限
5.验证新实例参数并为新实例创建初始数据库条目
6.rpc.call. 请求实例计划。期望获取指定了主机ID的更新实例条目
7.通过过滤和加权找到合适的主机使用主机ID更新实例条目
8.rpc.cast 将“虚拟机配置”请求发送到已计划配置的主机上的nova-compute
9.rpc.call 为实例保留和分配网络
10.从数据库中获取实例信息，为虚拟机监控程序驱动程序生成日期并在虚拟机监控程序上执行请求（通过api或libvirt）
11.从Glance中按镜像ID获取镜像URL并从镜像存储中上传镜像
12.轮询请求实例状态

虚拟机状态()

`Status`	`AvailabilityZone`	`Task`	`Power state`
`Active`	`nova`	`None`	`Running`

Status->vm_state
- 虚拟机处在稳定状态，通过api产生的状态
- Active,Error,Reboot,Build,Shutoff

`Status`	`AvailabilityZone`	`Task`	`Power state`
`Shutoff`	`nova`	`Powering-On`	`Shutdown`

task state
- 虚拟机处在中间状态，通过api产生的状态
- 表示虚拟机正在执行某种任务（操作）
- 当任务执行完成后，task state都会变成None
- vm_state的虚拟机的task state都是None
- Powering-on,Suspending等等带ing的状态
power state
- 从hypervisor上获取的虚拟机的状态
- 通过libvirt得到的状态
vm state,power state和task state的关系
- 三者没有必然的关系
  - 被修复过的虚拟机，power state是running的虚拟机，vm state可能是rescued
- 三个状态之间会出现冲突
  - 虚拟机内部关机，由于没有调用api,所以vm state还是activce,但是power state变成shutoff
  - 但实际情况是vm state也会变成shutoff,由于openstack会根据三个状态来判断出当前合理的状态
- 每次task state的变化都会对应一个task,这个task会有唯一的id来表示
  - 任务结束后，task state和task id都设置为空
  - 只有某些特殊任务可以抢占其他任务，比如force_delete

`NOVA`操作的原理

migrate操作
- 虚拟机的冷迁移
  - 从一台物理机迁移到另外一台物理机（或者本机）
  - 涉及到物理机的选择，就要经过调度器（nova-scheduler）来选择
- 底层实现
  - Nova-scheduler选出一台目标主机
  - 将虚拟机关机，然后改变源目录的名称
  - 如果本地存储，ssh到目标主机建立相同的目录，然后执行scp拷贝镜像文件
  - 重新生成虚拟机配置文件libvirt.xml
  - 启动虚拟机
resize操作
- 修改虚拟机的flavor
  - flavor中包括：cpu，memory，disk等资源信息
  - 虚拟机使用的资源变化了，原来物理机的资源还能否满足需求
  - resize操作会触发重新调度，重新选择最佳的物理机
- 底层实现
  - resize的底层实现与migrate大致是相同的，只不过多了一步是否更换flavor，
  - 如果flavor有变化，以磁盘为例，通过执行qemu-img resize命令来改变磁盘文件的大小
  - 对于处于resized状态的虚拟机，可以执行revert_resize和confirm_resize
  - resize_confirm_window>0,超时后自动执行rever_resize
rebuild操作
- 重建虚拟机
  - 保留原来虚拟机的所有信息，拿原来镜像重新创建虚拟机
  - 默认保留主机名，ip，用户名和密码等信息
  - 可以拿所有可用的镜像来rebuild,即用户可选的所有镜像
    - windows->linux
- 底层实现
  - 根据用户选择的镜像以及原虚拟机的信息重新创建一个虚拟机

本地镜像缓存机制

nova缓存机制
- /opt/stack/data/nova/instances
- 本地缓存目录：_base/
- 虚拟机运行目录：xxxxx-xxx-xxx-xxx-xxxxxxxxxx(虚拟机的ID)
- 重要命令：qemu-img
- 重要概念：派生镜像（backing files）
```
    qemu-img create -f qcow2 base.qcow2 -o backing_file=disk 10G
```
- 《OpenStack虚拟机创建过程中镜像格式的的变化过程》

胖可仃

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
openstack——Nova组件

Nova搭建本地的pip源《基于CentOS的pip本地源搭建方法》采用bandsnatch与pypi官方源同步，不能指定单个软件包同步bandsnatch仅支持与https的源同步，不支持与http的源同步同步的软件数量巨大，耗时长，且网络质量差，经常超时失败《搭建本地pypi源方法 – 仅同步openstack依赖的的pypi软件包》采用pip2pi进行同步，支持单个...
复制链接

扫一扫