openstack的计算节点是,openstack常用命令
openstack的计算节点是,openstack常用命令详细介绍
本文目录一览： openstack查询虚机在哪个计算节点上
场景（一个租户，两个网络，一个路由，内部网络使用GRE，Libvirt VIF Driver使用LibvirtHybridOVSBridgeDriver）：
场景一虚拟网络拓扑
Figure 11 场景一虚拟网络拓扑
如图我们有一个外网（External
Network），IP段为172.16.0.0/16，两个内网，分别是Internal：10.18.0.0/24，和
Internal2：10.22.22.0/24，值得注意的是这是两个网络（network），而不是子网（subnet）。
在这个场景下，计算节点的内部应当是这样的：
计算节点网络连接原理
下面我将解释如何得到这幅图。首先我们看下我们的虚拟机在libvirt的名称，通过 nova show 命令我们大概可以获得像这样输出（截取前半部分）：
+--------------------------------------+-------------------------------
|
| Property | Value |
+--------------------------------------+-------------------------------
| Internal network | 10.18.0.3, 172.16.19.232 |
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | compute1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | compute1 |
| OS-EXT-SRV-ATTR:instance_name | instance-0000001e |
我们看到这台虚拟机被部署在compute1节点上，instance_name为instance-0000001e，我们上compute1节点使用virsh dumpxml将instance-0000001e的信息打印出来（截取网络相关）：
<mac
address='fa:16:3e:e9:26:5a'/>
<address type="pci" domain="0x0000"
bus='0x00' slot='0x03' function='0x0'/>
在这里我们看到这台虚拟机的网络设备是tap48e06cd2-60，而且似乎连到了qbr48e06cd2-60上，让我们用brctl show再看下（截取相关部分）：
qbr48e06cd2-60 8000.bed5536ff312 no qvb48e06cd2-60tap48e06cd2-60
看到这里网桥qbr48e06cd2-60上接了两个接口，qvb48e06cd2-60和tap48e06cd2-60，其中的tap设备是
我们虚拟机使用的虚拟网络设备，那qvb48e06cd2-60是什么？我们先用lshw –class
network把所有网络设备打印出来（截取相关部分）：
*-network:5description: Ethernet interface
physical id: 7 logical name: qvb48e06cd2-60 serial: be:d5:53:6f:f3:12
size: 10Gbit/s capabilities: ethernet physical configuration:
autonegotiation=off broadcast=yes driver=veth driverversion=1.0
duplex=full firmware=N/A link=yes multicast=yes port=twisted pair
promiscuous=yes speed=10Gbit/s
我们注意到这里显示这个设备的driver是veth，而veth总是成对出现的，我们用ethtool -S 看下这个veth的另一端连到了那里：
# ethtool -S qvb48e06cd2-60NIC statistics: peer_ifindex: 16
OK，看下16号是哪个设备，ip link（截取相关部分）：
16: qvo48e06cd2-60:
mtu 1500 qdisc
pfifo_fast state UP qlen 1000link/ether aa:c0:0f:d2:e2:43 brd
ff:ff:ff:ff:ff:ff
通过上面两个步骤我们已经知道了这对从虚拟机的网络设备到veth pair这个流程，这个过程在官方文档中针对不同的 Libvirt VIF Driver有不同的简单的描述，见 https://wiki.openstack.org/wiki/LibvirtVIFDrivers
。
下面应该是连到Open vSwitch上吧，让我们验证下：
# ovs-vsctl show
1910d375-2692-4214-acdf-d364382c25a4
Bridge br-int
Port br-int
Interface br-int
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "qvo48e06cd2-60"
tag: 1
Interface "qvo48e06cd2-60"
Port "qvodfdc29e2-9a"
tag: 2
Interface "qvodfdc29e2-9a"
Port "qvo18cec000-80"
tag: 2
Interface "qvo18cec000-80"
Port "qvob86d15f1-8f"
tag: 1
Interface "qvob86d15f1-8f"
Bridge br-tun
Port br-tun
Interface br-tun
type: internal
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "gre-1"
Interface "gre-1"
type: gre
options: {in_key=flow, local_ip="192.168.10.11", out_key=flow, remote_ip="192.168.10.10"}
ovs_version: "1.11.0"
果然qvo48e06cd2-60是连到了br-int上， OpenStack采用这么复杂的机制，而不是把tap设备直接连到Open vSwitch上，这与安全组有关，将在3.2.4基于iptables的Security Group介绍。
在研究到OVS内部前，我们先注意下在poty “qvo48e06cd2-60”下有一个“tag: 1”，这个tag是Open
vSwitch用来区分不同子网的。在这里，tag1表示我们的10.18.0.0/24子网，tag2表示10.22.22.0/24子网。
br-int和br-tun通过patch连接，在官方文档上patch的介绍并不多，但一旦两个OVS网桥通过网桥连接，这两个网桥将近乎为同一个网桥，参考资料见： Open vSwitch FAQ
和 Connecting OVS Bridges with Patch Ports
。
首先看下bt-int的流表规则：
# ovs-ofctl dump-flows br-intNXST_FLOW reply (xid=0×4):
cookie=0×0,
duration=246746.016s, table=0, n_packets=702, n_bytes=78521,
idle_age=1324, hard_age=65534, priority=1 actions=NORMAL
只有一个NORMAL的动作，在Open vSwitch的官方文档里解释为将包以传统的，非OpenFlow的方式进行交换，也就是说效果和没设置OpenFlow规则一样（见 Open vSwitch Advanced Features Tutorial
）。那么我们分析br-tun的流表规则，首先在计算节点上用ovs-ofctl dump-ports-desc查看br-tun上所有接口：
OFPST_PORT_DESC reply (xid=0x2):1(patch-int):
addr:ea:a2:71:f5:9f:ad config: 0 state: 0 speed: 0 Mbps now, 0
Mbps max 2(gre-1): addr:d6:89:b0:03:d2:72 config: 0 state: 0
speed: 0 Mbps now, 0 Mbps max LOCAL(br-tun): addr:9a:49:9a:35:d1:4e
config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max
然后用ovs-ofctl dump-flows或者EasyOVS查看br-tun的流表规则（这里使用EasyOVS使排版相对好看）：
ID TAB PKT PRI MATCH ACT
0 0 339 1 in=1 resubmit(,1)
1 0 285 1 in=2 resubmit(,2)
2 0 3 0 * drop
3 1 216 0 dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 resubmit(,20)
4 1 123 0 dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 resubmit(,21)
5 10 363 1
*
learn(table=20,hard_timeout=300,priority=1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1
6 2 341 1 tun_id=0x2 mod_vlan_vid:1,resubmit(,10)
7 2 17 1 tun_id=0x3 mod_vlan_vid:2,resubmit(,10)
8 2 3 0 * drop
9 20 0 0 * resubmit(,21)
10 21 3 1 vlan=2 strip_vlan,set_tunnel:0x3,output:2
11 21 16 1 vlan=1 strip_vlan,set_tunnel:0x2,output:2
12 21 4 0 * drop
13 3 0 0 * drop
这里为了好看只显示了ID、表名、计数器、匹配规则和行为。先看这几条流：0、3、4、9、10、11、12，这些流定义了从br-int进入的包的行为，逐条从上往下看：
0. 表0：当匹配到从port 1（patch-int）进入的包时，提交给表1继续匹配；3. 表1：当目标MAC地址为单播地址时，提交给表20继续匹配；
4. 表1：当目标MAC地址为多播/广播地址时，提交给表21继续匹配；、
9.
表20：提交给21继续匹配（这个表并非只是转发，当OVS根据表10动态建立自动学习的规则时，会添加到表20，比如下面这条流表规则是自动建立的目标
MAC地址为路由的规则：“cookie = 0×0, duration = 11.099s, table = 20, n_packets =
45, n_bytes = 6132, hard_timeout = 300, idle_age = 3, hard_age = 2,
priority = 1,vlan_tci = 0×0001/0x0fff,dl_dst = fa:16:3e:a1:3f:19 actions
= load:0 -> NXM_OF_VLAN_TCI[], load:0×2 -> NXM_NX_TUN_ID[],
output:2”）；
10. 表21：当目标VLan标签为2时，剥去VLan标签，然后将Tunnel Key设置为3（GRE通道的Key，详见 rfc2890
的相关描述）并从port 2（gre-1）发出去；
11. 表21：当目标VLan标签为1时，剥去VLan标签，然后将Tunnel Key设置为2并从port 2（gre-1）发出去；
12. 表21：对没成功匹配的包，丢弃。
再看1、6、7、5，这几个流定义了来自GRE通道（Network节点）的包的行为：
1. 表0：当匹配到从port 2（gre-1）进入的包时，提交给表2继续匹配；6. 表2：当Tunnel Key为2时，添加VLan tag 1，提交给表10继续匹配；
7. 表2：当Tunnel Key为3时，添加VLan tag 2，提交给表10继续匹配；
5. 表10：首先从报文中学习VLan、MAC等信息并把规则添加表20，然后再从port 1（patch-int）发出去。
7）openstack 扩充计算节点
使用一断时间之后，玩的正hgin，创建一个新主机报错了：
openstack创建云主机时界面报错：错误： 实例 "xxxx" 执行所请求操作失败，实例处于错误状态。: 请稍后再试 [错误: No valid host was found. There are not enough hosts available.].
出现这种情况，大家可以去调查一下nova下的调度信息日志（nova-scheduler.log），不外乎下面资源用完了的情况：vCPU,内存，存储空间，网络。
我们假定现在是cpu和内存资源不够用了，无法创建更多虚拟机了，我们需要扩充计算节点。下面我们新增一台计算节点。
我们同样准备了一台CentOS7.2的主机，把它升级到最新，它的管理IP为192.168.25.25。
1，执行安装脚本安装。创建下面脚本，保存在任意位置，赋予执行权限，然后执行。
拷贝下面内容到该文件，注意如果你的环境不是严格按照我的做的话，必要的参数自行修改。
这样一台计算节点就安装完了，下面我们来验证一下。
在控制节点上执行下面命令 。看到nova-compute 的节点多了，有新加的这一台主机名，且状态是正常enabled 和up的就OK了。
Openstack中计算节点和控制节点的硬件配置各是什么样的？
这个硬件需要根据你的实际使用来具体配置了，没有一个具体的数字，比如我们的环境，控制节点的话3个1t的硬盘，两个做raid1，一个做热备，32核的cpu，24个16g的内存条。计算节点的话12个1.8t的硬盘来做存储。
openstack中创建完一个实例，这个实例实际的存放位置，具体在计算节点哪个目录？
用的ubuntu计算节点：/var/lib/nova/instances/
/var/lib/nova/instances/_base这里有个初始镜像
/var/lib/nova/instances/xxxxxxxxxxxxxxx/disk这里是快照
OpenStack-12-增加flat网段
使用OpenStack虚机启动的网卡是临时的,虚拟机重启就失效了,虚拟机挂起也会失效,网卡重启也会失效
测试环境: 分别在三台机器上增加一个网卡，选择lan网段，地址172.16.0.0/24
（一）增加一个flat网络原因
（二）添加网卡eth1
控制节点:
计算节点1:
计算节点2:
互相进行ping测试,测试连通性
（三）控制节点配置
1:控制节点
a:
b:
c：重启
systemctl restart neutron-server.service neutron-linuxbridge-agent.service
（四）计算节点配置
a:
b：重启
（五）创建网络
1、命令行创建：
neutron net-create --shared --provider:physical_network net172_16_0
--provider:network_type flat jiage
neutron subnet-create --name jiage
--allocation-pool start=172.16.0.1,end=172.16.0.250
--dns-nameserver 223.5.5.5 --gateway 172.16.0.254
jiage 172.16.0.0/24
查看创建的网络和子网详情
2、web页面创建网络：
管理员-网络-创建网络（供应商:平面）
创建子网
创建实例测试网络是否可用：项目-实例-创建实例（创建过程中可以选择刚创建的网络）
目前网络内网是通的,但是外网不通.因为指定的网关真实并不存在
需要创建一个linux系统作为路由器使用：
openstack常用命令
1,查看服务
openstack service list
删除服务：openstack service delete 服务ID #服务ID通过openstack service list查看。
2，查看endpoint
openstack endpoint list
删除endpoint：openstack service delete endpoint_ID #endpoint的ID通过openstack endpoint list查看。
3，查看域
openstack domain list
4，查看项目
openstack project list
5，查看用户
openstack user list
6，查看角色
openstack role list
7，查看镜像
openstack image list
8，列出可用类型： openstack flavor list
9，列出可用镜像： openstack image list
10，列出可用网络：openstack network list
11，列出可用的安全组：openstack security group list
12，检查实例的状态：openstack server list
13，创建角色
openstack role create user
14，查看cinder存储
cinder service-list
15，查看镜像信息
qemu-img info /var/lib/glance/images/镜像id
※可以查看到virtual size,后面创建实例的磁盘大小，必须大于此值。
【检查服务是否正常】
●以下在控制节点执行：
1，检查keystone服务是否正常
source 环境变量
openstack token issue #显示则正常
2，检查glance服务是否正常
openstack image list #显示则正常
或：openstack image-list
3，检查nova服务是否正常
openstack compute service list
或：nova service-list
是否有：
nova-conductor 控制节点
nova-consoleauth 控制节点
nova-scheduler 控制节点
nova-compute 计算节点
4,检查neutron服务是否正常
neutron agent-list
openstack最大支持多少计算节点
openstack 控制节点怎么与计算节点通讯
Openstack计算服务通过认证服务获取认证；通过镜像服务获取镜像；通过仪表盘提供的用户界面与用户交互。镜像的存取受工程和用户的限制，配额受工程的限制（例如不同工程允许虚拟机实例数量不同）。Openstack计算服务可以在标准硬件上进行横向扩展，可以下载镜像并开启虚拟机实例。
Openstack计算服务包含如下几部分，每部分都对应一个组件：
nova-api
接收并响应终端用户的计算服务API调用。该服务执行若干策略并且发起大多数编排行为，比如运行某个虚拟机实例。
云计算的知识梳理
一、云计算的定义：
官方：云计算是一种按使用量付费的模式（资源服务模式），该模式可以实现随时随地、便捷按需的从可配置资源共享池中获取所需的资源。包括网络、服务器、存储、应用及服务，资源能够快速供应并释放，大大减少了资源管理工作的开销。
百度百科：云计算 是基于互联网的相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。
特点：1.超大规模 2.虚拟化 3.高可靠性 4.按需服务 5.高可扩展性
二、OpenStack的历史版本：
云计算：2010年 元年，因为出现了OpenStack的第一个版本Austin（2010-10-21），目前已经到最新版本Queens,前一个版本是Pike版本，发行版本的规律：字母表顺序A-Z来命名的
三、OpenStack的难点在哪里？
1、OpenStack涉及的知识领域极广
2、OpenStack是一个平台，并不是一个具体的实施方案
OpenStack的Cinder（存储服务）定义了上层API，分布式存储软件，Ceph、HDFS对应的驱动
3、OpenStack本身是一个分布式系统：All-in-one部署
对于一个小白来说，OpenStack的搭建无疑是一个痛点，这个门槛有点高，我在开始学习的时候，也是煞费苦心，所以学好基础知识真的非常重要。
四、什么是虚拟化？
1）、虚拟化与虚拟化技术是什么？
虚拟化是云计算的基础，
虚拟化：软件模拟硬件的过程
具体定义：虚拟化使一台物理机上可以跑多台虚拟机，虚拟机共享物理机的CPU、内存、IO等硬件资源，每一台虚拟机逻辑上是相互隔离的。
行业内专用术语：
1、物理机：宿主机Host
2、虚拟机：客户机Guest
2）、虚拟化分类（按照虚拟化实现结构）：
1、1型虚拟化
定义：Hypervisor直接安装在物理机（裸机）上，多个虚拟机在Hypervisor上运行。
特点: 1型虚拟机本身就是一个操作系统，不需要其他操作系统的支持
举例：VMware的ESXI（workstation、server）
2型虚拟化
? ? 物理机上首先安装常规的操作系统，比如 Redhat、Ubuntu 和 Windows。Hypervisor 作为 OS 上的一个程序模块运行，并对管理虚拟机进行管理。KVM、VirtualBox 和 VMWare Workstation 都属于这个类型。
虚拟化技术：一种运行在基础物理服务器和操作系统之间的中间软件层，可以访问服务器上包括磁盘和内存在内的所有物理设备。Hypervisor协调着这些硬件资源的访问，以及各个虚拟机之间的防护。服务器启动时，它会加载所有虚拟机客户端的操作系统，同时为虚拟机分配内存、磁盘和网络等。也可叫做VMM（?virtual machine monitor?），即虚拟机监视器。
1型和2型虚拟化的对比：
1、前者性能比后者好
2、前者不需要操作系统支持，后者需要
3、后者更加灵活，特点：支持虚拟机的嵌套
使用虚拟化的原因：
打破实体结构间不可切割的障碍，使用户能更好的利用这些资源
没有虚拟化:服务器的IT资源30%
有虚拟化：服务器的IT资源70%
3）、虚拟化的优点
1、提高IT资源利用率
2、显著减少了服务器的数量，企业不动资产和管理成本。
3、加速应用部署
4、提高应用兼容性
五、云计算服务三层架构：根据提供服务的不同（会在下一篇详细讲解三种服务）
1、IaaS:infrastructure as a Service
定义：基础服务层
功能：提供的服务是存储、计算、网络等硬件资源? OpenStack
特点：负责管理虚拟机的整个生命周期，虚拟机创建、修改、启动停止、快照/备份、销毁
举例：阿里云、腾讯云、亚马逊的AWS（Amazon webserice）
2、PaaS：platform as a service
定义：平台服务层
功能：提供的服务是应用程序的运行环境和一系列中间件服务
特点：负责保证服务的性能和可用性。
举例：大数据和深度学习容器云平台
3、SaaS：Software as a service
定义：软件服务层
功能：提供的服务是软件/应用程序。
特点：用户需要登录并使用它，"拿来即用"
举例：facebook、twitter、instagram、QQ、微信
网上还有人说Docker的CaaS（container as a service）容器服务层。
六、OpenStack是什么？
OpenStack is a cloud operating system that controls large pools of storage, compute,and networking resources throughout a datacenter,all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface。
官方定义：OpenStack是一个（可以管理整个数据中心里存储、计算及网络资源的）云操作系统。
OpenStack 作为一个操作系统，管理资源是它的首要任务；
OpenStack 管理资源主要有三个方面：计算、存储和网络。
整个OpenStack是由控制节点，计算节点，网络节点，存储节点四大部分组成。这四个节点也可以安装在一台机器上，单机部署（All-in-one部署）
控制节点 负责对其余节点的控制，包含虚拟机建立，迁移，网络分配，存储分配等等
计算节点 负责虚拟机运行
网络节点 负责对外网络与内网络之间的通信
存储节点 负责对虚拟机的额外存储管理等等
下面我给出一张官方架构图（给出中文版方便理解）：
OpenStack的组件：
Nova：计算管理服务，提供了对计算节点的Nova的管理，使用Nova-API进行通信 （核心服务）
Neutron：网络管理服务，提供了对网络节点的网络拓扑管理，同时提供Neutron在Horizon的管理面板（核心服务）
Glance：镜像管理服务，提供了对虚拟机部署的时候所能提供的镜像的管理，包含镜像的导入，格式，以及制作相应的模板（核心服务）
Keystone：认证管理服务，为OpenStack的其他组件提供认证（auth）服务?（核心服务）
Cinder：提供管理存储节点的Cinder相关（为虚拟机提供存储卷（虚拟硬盘））?（核心服务）
Swift：为Glance和Cinder提供对象存储服务
Ceilometer：为OpenStack提供监控（monitor）、计量服务；提供对物理资源以及虚拟资源的监控，并记录这些数据，对该数据进行分析，在一定条件下触发相应动作
Heat：提供了基于模板来实现云环境中资源的初始化，依赖关系处理，部署等基本操作，也可以解决自动收缩,负载均衡等高级特性。
Horizon：控制台服务，提供了以Web的形式对所有节点的所有服务的管理 ?（核心服务）
第一次写关于技术方面的文章，不足之处后面还会修改补充，希望自己坚持下去。
openstack.创建实例的工作流程,分析各个组件间是如何协同工作的？
OpenStack创建实例的工作流程涉及多个组件，包括 Nova、Neutron、Glance等。以下是OpenStack创建实例的工作流程以及各个组件的协同工作方式：
1.用户使用Horizon或API创建实例请求。
2.Horizon或API将实例请求发送给Nova API。
3.Nova API将实例请求发送给Nova Scheduler，Nova Scheduler选择一个合适的计算节点创建实例。
4.Nova Scheduler通过RPC调用Nova Compute来创建实例。
5.Nova Compute创建实例并将实例状态更新到Nova数据库。
6.Nova Compute通过RPC调用Neutron来创建实例的网络。
7.Neutron创建实例的网络并将网络状态更新到Neutron数据库。
8.Nova Compute使用Glance API来下载实例镜像。
9.Glance API从镜像仓库中下载实例镜像并将镜像缓存到Glance Image Cache中。
10.Nova Compute使用Qemu/KVM等虚拟化技术来启动实例，并将实例状态更新到Nova数据库。
11.实例启动后，Nova Compute将实例的元数据信息发送给Nova Metadata Service。
12.Nova Metadata Service将实例的元数据信息发送给Nova API。
13.Nova API将实例的元数据信息发送给Horizon或API，用户可以通过Horizon或API访问实例的元数据信息。
在整个过程中，各个组件的协同工作是通过OpenStack中的消息队列系统RabbitMQ来实现的。当一个组件需要与另一个组件通信时，它会将消息发送到RabbitMQ中，另一个组件则会从RabbitMQ中接收消息并进行处理。通过消息队列的方式，各个组件之间可以实现异步通信，从而提高系统的可靠性和稳定性。
总的来说，OpenStack创建实例的工作流程涉及多个组件的协同工作，通过消息队列系统实现各个组件之间的通信和协作，从而实现实例的创建、网络的配置、镜像的下载等操作