open stack总结

时间:2019-06-11
本文章向大家介绍open stack总结,主要包括open stack总结使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。
 
 
vmware 和xen属于1型虚拟化,hypervisor直接安装在物理机上,多个虚拟机在hypervisor上运行。
2型虚拟化:物理机上首先安装常规的操作系统,比如 Redhat、Ubuntu 和 Windows。
Hypervisor 作为 OS 上的一个程序模块运行,并对管理虚拟机进行管理。
KVM、VirtualBox 和 VMWare Workstation 都属于这个类型。
ACL访问控制列表
ACL是Access Control List(访问控制列表)的缩写
ACL 可实现对单一用户设定访问文件的权限
例如外人来访问公司资源,拥有r、w但是没有x权限。这时候普通的三种身份不够用,这时用到acl。
使用getfacl查看acl权限信息,格式为
getfacl  文件名
使用setfacl 选项  文件名进行操作
setfacl 选项  文件名
-m  设定acl权限,格式u:用户名:权限,例如
setfacl -m u:chen:rx /test 设定chen用户对test目录具有rx权限;如果是组的话,参数为setfacl -m g:chen:rx /test 设定群组chen对test目录具有rx权限
-x 删除指定用户   setfacl -x u:chen /test
-b 删除所有的acl权限  setfacl -b /test 表示删除有关test目录的所有acl权限
-k  删除默认acl权限
Iaas、Paas、Saas的区别
SaaS:软件即服务,简单来说就是把企业想要的功能开发好成应用软件,然后直接卖给用户使用。通俗点讲就是去饭店吃饭一样,什么都是店家的。
PaaS:平台即服务,简单来说就是云计算平台提供硬件、编程语言、开发库等帮助用户更好更快的开发软件。通俗来说就是点外卖,使用时店家的,但是餐桌是自己的。
IaaS:基础设施即服务,简单来说就是云服务商提供企业所需要的服务器、存储、网络给企业用。通俗来说就是买菜买面,回家自己做饭。
 
openstack
日常巡检、维护、安装。
巡检命令:
keystone service-list     查看所有服务
keystone endpoint-list   查看keystone endpoint
keystone tenant-list       查看keystone租户
openstack-status 查看所有组件的状态
openstack service list    列出实例
openstack domain list      查看域
openstack endpoint list    查看服务端点
openstack-service status  查看服务状态
nova-manage service list
nova host-list
nova list      查看所有计算实例
nova flavor-list  查看虚拟机配置种类
glance image-list
查看云主机的生命历程  nova instance-action-list a1833d9a-a3b0-4df4-b3ba-5b79fbd99639
fule部署
Nailgun(莱耿)是Fuel的核心组件,使用Python开发。它提供用于部署和管理的REST API;管理磁盘卷配置数据、网络配置数据以及其他环境相关的数据。它能够根据编排逻辑按照正确顺序生成部署命令。Nailgun使用SQL数据库保存数据,使用AMQP服务与workers进行交互。用户通过Web UI或 Fuel CLI与其进行交互。
Astute(爱死tiu特)是另外一个重要的组件,代表着nailgun的workers。它主要是根据nailgun提供的指令运行着某些操作。Astute实际上什么东西都没有只是一层封装着所有细节和相互影响的服务比如cobbler、puppet、shell scripts等等,和提供了异步通用接口给那些服务。它是通过其他基本本地协议(比如XML-RPC协议)来管理这些服务或者可以使用Mcollective agents去提供定义好的命令比如运行’puppet apply’在其他的远程节点上面或运行某些脚本。当然它是通过AMQP来与nailgun交互数据。
    Cobbler用于网卡启动环境准备,被用来提供快速网络安装的linux服务。
    Puppet用户部署,可以通过MCollective agent去管理其他的配置管理框架,比如Chef,SaltStack等。
    Mcollective agents用于执行类似硬件驱动清理、网络连接探查等特别任务。
    OSTF(OpenStack Testing Framework/Health Check)是一个独立的组件,用于在部署后测试OpenStack环境。
分3个网,管理网,内网,外网
组件
rabbitmq   实现了AMQP高级消息队列协议的消息队列服务
connection Factory(连接管理器):应用程序与rabbit建立连接
channel(信道):消息 推送使用的通道
RoutingKey(路由键):用于把生产者的数据分配到交换器上
Exchange(交换器):接受、分配信息
BindingKey(邦定键): 把交换机的消息绑定到队列上
Queue(队列):用于存储生产者的消息
memcached  缓存系统
对于关系型数据库,如果对其进行每秒上万次的并发访问,每次访问都在一个有上亿条记录的数据库中查询时,负荷会很重
概念:在内存中缓存数据和对象来减少读取数据库的次数,从而提高网站访问速度,加速动态,web应有,减轻数据库负载
数据存放于内存上的Hash表内,以key-value的形式。当memcached服务节点物理内存空间不足时,使用算法LRU(最近最少使用)对最近不活跃的数据进行清理。
Galera实现原理
复制功能基于galera library实现,为了让mysql与galea library通讯,特别针对mysql开发了wsrep api(复制接口的抽象层)
Galera插件保证集群同步数据靠的就是可认证的复制(当客户端发出一个commit的指令,在事务被提交之前,所有对数据库的更改都会被write-set收集起来,并且将write-set记录的内容发送给其它节点,write-set对每个节点进行认证测试,测试结果决定是否应用write-set更改数据)
keystone
作为 OpenStack 的基础支持服务,Keystone 做下面这几件事情:
  1. 管理用户及其权限
  2. 维护 OpenStack Services 的 Endpoint
  3. Authentication(认证)和 Authorization(鉴权)
•Token: 用来生成和管理token
•Catalog:用来存储和管理service/endpoint
•Identity:用来管理tenant/user/role和验证
•Policy:用来管理访问权限
v3的改进(keystone)
将tenant改称为project
引入Domain的概念
引入Group的概念
  • v2中,资源分配是以Tenant为单位的。如果一个公司在openstack中拥有两个不同的项目,他就需要管理两个tenant来分别对应这两个项目,并对这两个tenant中的用户分别分配角色,但是tenant之上并不存在一个更高层次的概率,无法对tenant进行统一的管理。v3中引入了domain的概率实现真正的多租户架构,domain担任project的高层容器。云服务的客户是domain的所有者。可以在domian中创建多个projects、user、groups和roles。云服务客户可以对其拥有的多个project进行统一管理。简而言之,domain的引入是为了将多个project进行封装,成为单一实体在交付给相应的一个客户使用
  • v2中,用户的权限管理是一每一个用户为单位,需要对每一个用户进行角色分配。v3中引入了group的概念。group是一组user的容器,可以向group中添加角色,并直接给group分配角色,实现了对用户组的管理,达到了同时管理一组用户权限的目的。
glance
glance-api:glance-api 是系统后台运行的服务进程。 对外提供 REST API,响应 image 查询、获取和存储的调用。
glance-api 不会真正处理请求。 如果操作是与 image metadata(元数据)相关,glance-api 会把请求转发给 glance-registry; 如果操作是与 image 自身存取相关,glance-api会把请求转发给该 image 的 store backend。
glance-registry:负责处理和存取 image 的 metadata,支持image格式:raw 、iso、qcow2、aki等等
store backend: 真正的 image 是存放在 backend 中的。 Glance 支持多种 backend,如下:ceph rbd  、 Amazon S3、cinder,使用那种backend,在/etc/glance/glance-api.cnf中配置的
查看目前存在的image  openstack image list
上传镜像命令:
openstack image create "名字"  \ --file 景象名称 \ --disk-format  (格式)  qcow2 \ --container-format  bare \ --public
创建虚拟机流程
Openstack虚拟机创建流程?
1、界面或命令行通过RESTful API向keystone获取认证信息。
2、keystone通过用户请求认证信息,并生成auth-token返回给对应的认证请求。
3、界面或命令行通过RESTful API向nova-api发送一个boot instance的请求(携带auth-token)。
4、nova-api接受请求后向keystone发送认证请求,查看token是否为有效用户和token。
5、keystone验证token是否有效,如有效则返回有效的认证和对应的角色(注:有些操作需要有角色权限才能操作)。
6、通过认证后nova-api和数据库通讯。
7、初始化新建虚拟机的数据库记录。
8、nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。
9、nova-scheduler进程侦听消息队列,获取nova-api的请求。
10、nova-scheduler通过查询nova数据库中计算资源的情况,并通过调度算法计算符合虚拟机创建需要的主机。
11、对于有符合虚拟机创建的主机,nova-scheduler更新数据库中虚拟机对应的物理主机信息。
12、nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。
13、nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
14、nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。(Flavor)
15、nova-conductor从消息队队列中拿到nova-compute请求消息。
16、nova-conductor根据消息查询虚拟机对应的信息。
17、nova-conductor从数据库中获得虚拟机对应信息。
18、nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
19、nova-compute从对应的消息队列中获取虚拟机信息消息。
20、nova-compute通过keystone的RESTfull API拿到认证的token,并通过HTTP请求glance-api获取创建虚拟机所需要镜像。
21、glance-api向keystone认证token是否有效,并返回验证结果。
22、token验证通过,nova-compute获得虚拟机镜像信息(URL)。
23、nova-compute通过keystone的RESTfull API拿到认证k的token,并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
24、neutron-server向keystone认证token是否有效,并返回验证结果。
25、token验证通过,nova-compute获得虚拟机网络信息。
26、nova-compute通过keystone的RESTfull API拿到认证的token,并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。
27、cinder-api向keystone认证token是否有效,并返回验证结果。
28、token验证通过,nova-compute获得虚拟机持久化存储信息。
29、nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。
nova
nova-compute 是管理虚机的核心服务,在计算节点上运行。通过调用Hypervisor API实现节点上的 instance的生命周期管理。
launch:启动虚机
shut off:关闭虚机
terminate:终止
resize:通过应用不同的 flavor 调整分配给 instance 的资源。
lock/unlock:可以防止对instance的误操作,可以加锁。Lock/Unlock 操作都是在 nova-api 中进行的。
Snapshot :备份 instance 到 Glance。产生的 image 可用于故障恢复,或者以此为模板部署新的instance。
故障处理
故障处理有两种场景:计划内和计划外。
计划内是指提前安排时间窗口做的维护工作,比如服务器定期的微码升级,添加更换硬件等。
计划外是指发生了没有预料到的突发故障,比如强行关机造成 OS 系统文件损坏,服务器掉电,硬件故障等。
计划内故障处理
对于计划内的故障处理,可以在维护窗口中将 instance 迁移到其他计算节点。
涉及如下操作:
Migrate
Migrate 前必须满足一个条件:计算节点间需要配置 nova 用户无密码访问。
migrate 实际上是通过 resize 操作实现的
将 instance 迁移到其他计算节点。
迁移之前,instance 会被 Shut Off,支持共享存储和非共享存储。
Live Migrate
与 Migrate 不同,Live Migrate 能不停机在线地迁移 instance,保证了业务的连续性。也支持共享存储和非共享存储(Block Migration)
源和目标节点需要满足一些条件才能支持Live Migrate:
  • 源和目标节点的CPU类型要一致
  • 源和目标节点的Libvirt版本要一致
  • 源和目标节点能相互识别对方的主机名称,比如可以在/etc/hosts中加入对方的条目
  • 在源和目标节点的/etc//nova/nova.conf中知名在线迁移时使用TCP协议
  • instance使用config driver保存其metadata。在Block Migration过程中,该conf driver 也需要迁移到目标节点。由于目前libvirt只支持config driver,所以必须在/etc/nova/nova.conf中明确指明launch instance时创建vfat类型的config driver。
  • 源和目标节点的libvirt TCP远程监听服务得打开,需要在下面两个配置文件做一点配置. /etc/default/libvirt-bin
start_libvirtd=”yes” 
libvirtd_opts=-d -l”
/etc/libvirt/libvirtd.conf
listen_tls =0
listen_tcp =1
unix_sock_group = “libvirtd” 
unix_sock_ro_perms =0777
unix_sock_rw_perms =0770
auth_unix_ro = “none” 
auth_unix_rw = “none” 
auth_tcp = “none”
之后重启libvirt服务
systemctl restart libvirt-bin
Shelve/Unshelve
Shelve 将 instance 保存到 Glance 上,之后可通过 Unshelve 重新部署。
Shelve 操作成功后,instance 会从原来的计算节点上删除。
Unshelve 会重新选择节点部署,可能不是原节点。
计划外故障处理
计划外的故障按照影响的范围又分为两类:Instance 故障和计算节点故障
Instance 故障
Instance 故障只限于某一个 instance 的操作系统层面,系统无法正常启动。
可以使用如下操作修复 instance:
Rescue/Unrescue
用指定的启动盘启动,进入 Rescue 模式,修复受损的系统盘。成功修复后,通过 Unrescue 正常启动 instance。
Rebuild
如果 Rescue 无法修复,则只能通过 Rebuild 从已有的备份恢复。Instance 的备份是通过 snapshot 创建的,所以需要有备份策略定期备份。
计算节点故障
Instance 故障的影响范围局限在特定的 instance,计算节点本身是正常工作的。如果计算节点发生故障,OpenStack 则无法与节点的 nova-compute 通信,其上运行的所有 instance 都会受到影响。这个时候,只能通过 Evacuate 操作在其他正常节点上重建 Instance。
Evacuate (一挖可蕾特)
利用共享存储上 Instance 的镜像文件在其他计算节点上重建 Instance。
Evacuate 可在 nova-compute 无法工作的情况下将节点上的 instance 迁移到其他计算节点上。但有个前提: Instance 的镜像文件必须放在共享存储上。
所以提前规划共享存储是关键。
 
scheduler调度器
在 /etc/nova/nova.conf 中,nova 通过 driver=filter_scheduler 这个参数来配置 nova-scheduler。
Filter(非u特) scheduler 是 nova-scheduler 默认的调度器,调度过程分为两步:
1. 通过过滤器(filter)选择满足条件的计算节点(运行 nova-compute)
2. 通过权重计算(weighting)选择在最优(权重值最大)的计算节点上创建 Instance。
目前 nova-scheduler 的默认实现是根据计算节点空闲的内存量计算权重值:
空闲内存越多,权重越大,instance 将被部署到当前空闲内存最多的计算节点上。
nova中的filter有哪些(nova.cnf文件)
Retryfilter                     刷掉之前已经调度过的节点
AvailabilityZoneFilter  为提高容灾性和提供隔离服务,可以将计算节点划分到不同的Availability Zone中。nova-scheduler 在做 filtering 时,会使用 AvailabilityZoneFilter 将不属于指定 Availability Zone 的计算节点过滤掉。
DiskFilter      将不能满足flavor磁盘需求的计算节点过滤掉
CoreFliter        将不能满足flavor vCPU需求的计算节点过滤掉
ComputerFilter     保证只有nova-compute服务正常工作的计算节点才能够被nova-scheduler调度
ComputerCapabilitiesFiler    根据计算节点的特性来筛选
#####################################################################
quota:配额管理(控制用户资源的管理)
在~/nova/quota.py中实现,调用quotaEngine类中的方法,真正实现DbQuotaDriver,其中重要的三个方法为:reserve(), commit()  rollback().,三者共同构成配额管理的一个重要的特性:事务性,(当资源失败或者达到上限等异常情况发生时,对已经修改过的数据库,回滚到分配之前的状态)
在数据库中涉及四个表:show columns from quotas;
                                        show columns from quota_classes;
                                        show columns from quota_usages;
                                        shwo columns from reservations;
reserve():这个函数的作用就是判断一下如果分配给请求的资源的数量给这个工程,是否会超出限额,如果超出就报异常,如果没有超出,就更新一下数据库中quota_usages表的in_use值。 
执行过程分为以下几步:
(1)、为什么要同步呢?这里同步的是什么呢?因为在为工程分配资源时,可能有各种特殊情况导致quota_usages表中记录的in_use不准确,需要得到当前实际使用的资源的情况,更新一下in_use,得到真实的资源使用情况。这里的特殊情况有一下4个:
          1)当前申请的资源没有在quota_usages表中记录
          2)当前申请的资源在quota_usages表中的in_use值小于0
          3)当前申请的资源的until_refresh值不为空,减1之后小于0
          4)当前申请的资源在quota_usages表中更新的时间减去现在的时间大于max_age
如果符合这四种情况之一,就执行同步。同步时,是调用当前资源的_sync_*()函数,去相关的表中查询实时的使用情况,比如_sync_instances()就是去instances表中查询出当前工程的instances数量,vcpu之和,ram之和,然后以字典的方式返回。然后根据这些实时的数据,更新in_use值。
(2)检查
根据各种资源的配额,和变化的情况(delta),来检查两种极端的情况:under和over。under是检查delta为负数的情况,即执行了删除等操作,使delta为负,in_use减少,导致in_use值可能小于0。over是检查delta为正数时的情况,in_use+delta就有可能大于最大的限额了。这里只对over的情况进行处理,即它只关心上限,不关心下限。如果没有over的话,就有下面的第(3)步了。如果over的话,就直接进行第(4)步。
(3)向reservations表中增加记录,记录申请资源的delta值。
(4)把in_use值写入到quota_usages表中保存。(不论under还是over都执行)
(5)如果over,即超出最大限额,则报出OverQuota异常。
#####################################################################
neutron
neutron  server
plugin:维护openstack逻辑网络状态
  • core plugin:负责管理核心实体net、subnet、port(二层交换)
  • server plugin:为agent提供丰富的扩展功能,路由,load balance、 firewall(三层路由)
agent:处理plugin的请求,在network provider上真正实现各种网络功能
network provider
queue
database
ML2作用:
  • 实现多种二层网络技术,
  • 支持新的network provider,无须从头开发core plugin,只需开发相应的mechanism dirver,大大减少了要编写的维护的编号
ML2对二层网络进行抽象和建模,引入了 type driver 和 mechansim driver
type driver: 负责维护网络类型的状态,执行验证,创建网络等。 ML2 支持的网络类型包括 local, flat, vlan, vxlan 和 gre。
mechansim driver:Neutron 支持的每一种网络机制都有一个对应的 ML2 mechansim driver。mechanism driver 负责获取由 type driver 维护的网络状态,并确保在相应的网络设备(物理或虚拟)上正确实现这些状态。支持三种类型:
Agent-based
包括 linux bridge, open vswitch 等。
Controller-based
包括 OpenDaylight, VMWare NSX 等。
基于物理交换机
包括 Cisco Nexus, Arista, Mellanox 等
外网访问虚机:东西流量
外网网卡通过br-ex连接到qg端做dnat目的地址转发,在通过路由的qr端接到br-int网桥上,虚机之间通过br-tun实现通信,通过br-tun连接到计算节点的br-int,经过一对vethpair连接到Linux bridge,经过tap设备接到虚拟机的网卡,实现访问虚机。
虚机访问外网:南北走向
虚机的网卡通过tap设备连到linux bridge,linux bridge 通过一对veth pair设备连到ovs的集成网桥br-int上,在通过br-tun连接到网络节点的br-int,br-int通过qr端连到路由上,路由通过qg连接到br-ex上。qg上的网关有SNAT源地址转发功能,所以虚机可以通过这种方式连接外网。
通过什么实现隔离vlan?
openvswitch通过flow rule流规则指定如何对进出br-int的数据进行转发,进而实现vlan的隔离。
instance 获取 IP
1. vm 开机启动,发出 DHCPDISCOVER 广播,该广播消息在整个 net 中都可以被收到。
2. 广播到达 veth tap19a0ed3d-fe,然后传送给 veth pair 的另一端 ns-19a0ed3d-fe。dnsmasq 在它上面监听,dnsmasq 检查其 host 文件,发现有对应项,于是dnsmasq 以  DHCPOFFER 消息将 IP(192.168.254.18)、子网掩码(255.255.255.0)、地址租用期限等信息发送给 vm。
3. vm 发送 DHCPREQUEST 消息确认接受此 DHCPOFFER。
4. dnsmasq 发送确认消息 DHCPACK,整个过程结束。
instance如果获得metadate?
instance------》neutron-ns-metadata-proxy(将instnce ip和router id 添加到http请求的head中)---------》neutron-metadata-agent查询instance id(通过routee id找到所有subnet筛选instanceIP在的subnet找到instance ip对应的port)
#####################################################################
(1)neutwork
network 是一个隔离的二层广播域。Neutron 支持多种类型的 network,包括 local, flat, VLAN, VxLAN 和 GRE。
local
local 网络与其他网络和节点隔离。local 网络中的 instance 只能与位于同一节点上同一网络的 instance 通信,local 网络主要用于单机测试。
flat
flat 网络是无 vlan tagging 的网络。flat 网络中的 instance 能与位于同一网络的 instance 通信,并且可以跨多个节点。
vlan
vlan 网络是具有 802.1q tagging 的网络。vlan 是一个二层的广播域,同一 vlan 中的 instance 可以通信,不同 vlan 只能通过 router 通信。vlan 网络可跨节点,是应用最广泛的网络类型。
vxlan
vxlan 是基于隧道技术的 overlay 网络。vxlan 网络通过唯一的 segmentation ID(也叫 VNI)与其他 vxlan 网络区分。vxlan 中数据包会通过 VNI 封装成 UDP 包进行传输。因为二层的包通过封装在三层传输,能够克服 vlan 和物理网络基础设施的限制。
gre
gre 是与 vxlan 类似的一种 overlay 网络。主要区别在于使用 IP 包而非 UDP 进行封装。
#####################################################################
vlan与vxlan的比较
支持更多的二层网络:vlan使用12-bit标记vlan ID,最多支持4094个vlan,而vxlan采用24-bit标记,支持1000多万个二层网络
能更好地利用已有的网络路径:VLAN 使用 Spanning Tree Protocol 避免环路,这会导致有一半的网络路径被 block 掉。VXLAN 的数据包是封装到 UDP 通过三层传输和转发的,可以使用所有的路径。
避免物理交换机 MAC 表耗尽:由于采用隧道机制,TOR (Top on Rack) 交换机无需在 MAC 表中记录虚拟机的信息。
操作配置vlan
  1. 下载配置文件vconfig
  2. 添加网卡设备(也就是新建一个网卡文件ensXX,将BOOTPROTO=static)
  3. 创建vlan接口,基于网卡ensXX建立vlan10接口 vconfig add ensXX.10
  4. 创建接口配置文件ensXX.10接口配置文件
  5. 建立网桥brvlan-10, brctl addbr brvlan-10
  6. 将网桥brvlan-10接口网口(接口)vlan10上 brctl addif brvlan-10 ensXX.10
  7. 重启网络服务即可
####################################################################
ceph
分布式存储:通过网络将数据分布的存储在多台服务器上,并且将这些分散的存储资源构成一个虚拟的存储设备
组件
Monitors:监视器,维护集群状态的多种映射,同时提供认证和日志记录服务。
MDS(Metadata Server):Ceph 元数据,主要保存的是Ceph文件系统的元数据。注意:ceph的块存储和ceph对象存储都不需要MDS。
OSD:即对象存储守护程序,但是它并非针对对象存储。是物理磁盘驱动器,将数据以对象的形式存储到集群中的每个节点的物理磁盘上。OSD负责存储数据、处理数据复制、恢复、回填(Backfilling)、再平衡。完成存储数据的工作绝大多数是由 OSD daemon 进程实现。在构建 Ceph OSD的时候,建议采用SSD 磁盘以及xfs文件系统来格式化分区。此外OSD还对其它OSD进行心跳检测,检测结果汇报给Monitor
librados:librados库,为应用程度提供访问接口。同时也为块存储、对象存储、
文件系统提供原生的接口。
存储过程:
file--->object映射
object--PG映射   hash算法
PG---》OSD映射 crush算法
命令:
ceph health 检查集群健康状态
ceph -w 观察集群内发生的时间
ceph -s / ceph status 检查集群状态
检查osd状态
ceph osd stat / ceoh osd dump
ceph对接openstack:
  • 创建存储池pool,分别对应cinder、glance、nova服务
  • 在ceph中创建用户glance、cinder
  • 拷贝ceph-ring(令牌环)
  • 更改文件权限,更改libvirt权限
  • 在各节点修改相应配置文件
osd故障
  • 关闭ceph集群数据迁移
  • 定位故障osd ceph osd tree | grep -i down
  • 进入osd故障节点,卸载osd挂载目录
  • 从crush map中移除osd
  • 删除故障的osd的密钥
  • 删除故障osd
创建实例在指定计算节点上
1、查看有效区域
openstack availability zone list
2、查看有效主机列表
openstack host list
3、查看有效计算节点列表
openstack hypervisor list
4、查询网络id
openstack network list
创建实例
openstack server create --flavor ptest --image cirros  --nic net-id=0e025936-a568-43fe-a32c-01f8b75472ae  --availability-zone nova:compute1:compute1 test
--flavor 实例类型
--image 镜像
--nic 网络 net-id网络id 第4步查得
--availability-zone nova:compute1:compute1 前三步查得
compute1为指定计算节点。
openstack server create --image 镜像名  --flavor flaovr 规格名 --security-groups 安全组名 --nic net-id=网络ID
网络出错排查思路
安全组是否打开    在web界面查看虚拟机的日志,是否有dhcp获取IP成功的日志,如果没有,则image有问题。如果虚机连不上dhcp server,则需要准备一个不适用metadat server,用户名密码可以登录的image。通过vnc登录,如果vnc等不进去,则vnc配置有问题,
通过ovs-vsctl show 和brctl来查看,各个网卡和bridge之间的关系是否正确,tunnle之间是否能够通,网卡是否处于up的状态。
网络不通的思路
检查物理链路是否正常,网线、交换机是否正常
网卡的状态是否为UP
neutron绑定的网卡是否为规则的网卡
neutron服务是否正常
路由器接口 是否为UP
网关的配置
虚拟机是否正常启动,且分配到IP
安全组是否打开
floating IP是否创建
security Group的配置
IPtable 规则是否正确
域名服务器配置是否正确
问题分析流程
检查所在计算节点nova-computer.log日志,检查neutron日志,检查mysql、rabbitmq,最后检查底层hypervisor,/var/log/libvirt/libvirtd.log
openstack获取不到IP地址的办法
网络中有没有其它dhcp源干扰
neutron所接的网卡名称、状态、
neutron服务
检查节点各项服务是否正常,以及agent是否正常启动, nova-manage service list
检查agent    neutron agent-list   (如果出现问题,可能是各节点时间不同步)
检查dhcp-agent日志    tail -f dhcp-agent.log
openstack工作中遇到问题
1、声明环境变量刚刚开始没问题,后面再运行时出现time out的错误。(web界面弹出unable to retrieve network quota information,再次刷新又不提示了)
原因:数据库最大连接数开始时默认为100,
解决方法:
1、更改 MySQL 在 Linux 的最大文件描述符限制,编辑/usr/lib/systemd/system/mariadb.service文件,在文件[Service]下添加:
LimitNOFILE=65535
LimitNPROC=65535
2、修改数据库配置文件,将最大连接数改为更大的数,如1500
echo "max_connections=1500">>/etc/my.cnf.d/mariadb_openstack.cnf
3、重启系统服务
# systemctl daemon-reload
# systemctl restart  mariadb.service
2、openstack修改policy.json后,重启httpd服务出现问题   
原因: /etc/nova/policy.json文件改为root:root,原来应该为nova:nova
解决方法:进行修改即可   chown nova:nova /etc/nova/policy.json
3、web界面无法正常登录
日志分析:tail -f /var/log/httpd/error_log
报UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 0: ordinal not in range(128)是转码失败
解决方法:
加入相关模块,在/etc/openstack-dashboard/local_settings中
import sys
reload(sys)
sys.setdefaultencoding('utf-8')
重启httpd和memcached服务
systemctl start httpd.service memcached.service
也有一种原因是80端口被占用
4、web界面上传image(镜像)失败
原因:网络原因,传输文件及其容易损坏
解决方案:命令上传
openstack image create "名字" \
--file 镜像名称  \
--disk-format (格式) qcow2 \
--container-format bare \
--public
5、ping不通虚拟机
  1. 检查物理链路是否正常,网线、交换机是否正常
  2. 网卡的状态是否为up ip addr
  3. neutron绑定的网卡是否为规划的网卡(各个节点都检查)
  4. 路由器接口是否为up(在web界面 路由/router检查)
  5. 网关是否为up
  6. 虚拟机是否已经正常启动,且分配到IP
  7. 创建虚拟机所用的安全组是否允许icmp协议通过
6、虚拟机获取不到IP
  1. 网络中有其它的dhcp源干扰
  2. neutron所桥接的网卡名称错误,或状态异常,例如网线没插好,onboot=no,
cat /etc/neutron/plugins/ml2/linuxbridge_agent.ini | grep physical_interface_mappings
  1. neutron服务异常
k8s生态体系(包括但不限于k8s的有状态存储、网络、镜像中心、CI/CD、运行时、调度、GPU支持、PA、监控等)

原文地址:https://www.cnblogs.com/lwl117/p/11004133.html