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
服务进程
- 发现启动13个
- 启动多少个
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
服务进程?
- 思考(作业1):在
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.5
8773`
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
访问原理- 一个用户试图从浏览器里面打开连接到虚拟机的
VNC Client
- 浏览器向
nova-api
发送请求,要求返回访问vnc
的url
nova-api
调用nova-compute
的get_vnc_console
方法,要求返回连接VNC
的信息nova-compute
调用libvirt
的get_vnc_console
函数libvirt
会通过解析虚拟机的的配置文件/instance-00000001.xml
来获得VNC Server
的信息libvirt
将host
,port
等信息以json
格式返回给nova-compute
nova-compute
会随机生成一个UUID
作为Token
nova-api
会调用nova-consoleauth
的authorize_console
函数nova-api
将connect_info
中的access url
信息返回给浏览器- 当浏览器试图打开这个链接时,会将请求发送给
nova-novncproxy
nova-novncproxy
调用nova-consoleauth
的check_token
函数nova-consoleauth
验证了这个token
,将这个instance
对应的connect_info
返回给nova-novncproxy
nova-novncproxy
通过connect_info
中的host
,port
等信息,连接compute
节点上的VNC Server
,从而开始了proxy
的工作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
来源:CSDN
作者:胖可仃
链接:https://blog.csdn.net/herhan1/article/details/103715679