OpenStack

openstack 修改内存大小和vcu

妖精的绣舞 提交于 2020-03-09 12:28:35
openstack 修改内存大小和VCU openstack 修改内存大小 登陆控制节点: #nova list (显示所有实例列表) nova flavor-list(显示所有flavor)列表 [root@node-37 ~]# nova show 8b08ce7d-cddd-4f74-ab80-01436edeab85 (显示该实例的详细信息) [root@node-37 ~]# nova resize 8b08ce7d-cddd-4f74-ab80-01436edeab85 2 (将实例8b08ce7d-cddd-4f74-ab80-01436edeab85的flavor更改为flavorID=2的flavor) [root@node-37 ~]# nova resiez-confirm 8b08ce7d-cddd-4f74-ab80-01436edeab85 来源: 51CTO 作者: bristol 链接: https://blog.51cto.com/bristol/2376988

OpenStack入门之核心组件梳理(2)——Nova篇

浪子不回头ぞ 提交于 2020-03-08 22:20:22
OpenStack入门之核心组件梳理(2)——Nova篇 前言 ​ 上篇文章我们从概念到原理,层层递进深入讲述了Keystone项目,而本文旨在继续介绍OpenStack核心组件之一的Nova组件项目。 ​ 相对于Keystone项目,Nova项目是作为OpenStack这个大开源项目最早也是最成熟的项目,从这一层面上也体现出Nova项目所提供的计算服务从始至终都是OpenStack最为核心的部分,笔者在之前的文章中谈到OpenStack这一开源项目所提供和管理的三大资源就是计算、网络和管理。这同样也是云计算的核心部分。 ​ 从笔者个人理解和观点来看的话,对于OpenStack而言,其真正的灵魂(可以理解为OpenStack中组件的复杂程度、使用概率以及故障出现概率等方面)一是在于宏观(这里“宏观的意思是相对早期版本的OpenStack平台而言”)的Nova(计算服务),二是在于相对其他服务最为复杂的Neutron网络服务(之后的文章也会针对该组件进行详细介绍),这里不包括CEPH分布式存储,因为CEPH本身就是可以认为是一个独立的大项目,其作用不仅仅是OpenStack中Swift(对象存储服务)的高效分布式集群存储的替代,还包括与其他技术的结合和支持等作用。但是无论在实验环境还是生产环境部署OpenStack云平台基本上选择CEPH作为分布式存储服务,当然在此个人补充一下

OpenStack多节点一键部署(超详细)

♀尐吖头ヾ 提交于 2020-03-08 22:16:30
实验环境下OpenStack多节点一键部署(超详细) 前言 ​ OpenStack项目是一个开源的云计算平台项目,是控制着计算、网络和存储三大资源的分布式系统。搭建这样的一个云平台系统,可以为我们提供IaaS(基础设施即服务)模式的云服务。本文核心不在相关的理论,因此有关云计算和OpenStack的概念等相关整体介绍可以参考下面的三篇文章: 云计算浅谈 OpenStack概念以及核心组件概述 OpenStack部署节点类型和架构 ​ 本文旨在给出实验环境下多节点一键部署OpenStack的详细实验流程,该部署为本地(使用yum源)部署的R版的OpenStack。下面笔者从自己的实验环境与所需资源、系统资源情况、部署节点规划、具体部署、部署总结过程四个方面进行简述、实践与总结。 一、实验环境与所需资源 1.1系统环境 win10宿主机、采用VMware15版本(可以自行下载,最好实验时使用该版本)上安装操作系统(Centos7.5); 1.2资源包 Centos7.5的镜像文件、R版本的OpenStack源;资源链接如下: 链接: https://pan.baidu.com/s/1hFENGyrRTz3lOLUAordTGg 提取码:mu5x 二、系统资源情况 ​ 系统资源情况主要是介绍一下笔者的宿主机硬件情况,主要考虑到OpenStack项目还是非常占用资源的

openstack rabbitmq

不羁的心 提交于 2020-03-08 18:46:51
这两天研究了一下,OpenStack的工作原理,并着重调研了一下RabbitMQ在OpenStack中扮演的角色。 首先,OpenStack中模块Volume Control、Network Controller、ComputeController以及Scheduler之间的通信是通过AMQP协议实现,消息由RabbitMQ作为中间件转发,以一种RPC(Remote Process Call)的方式进行的。具体可见图 其中用户在dashboard中进行的操作通过Nova.api、Glance.api等调用Volume、Network、ComputeController等模块,上图中是一个逻辑结构,可以看出这种基于RPC的松耦合调用可以不用关心某些模块是否在本机,Openstack的多个模块间可以轻易以分布式的方式解决。 以Nova为例,每一个Nova服务都会在初期建立两个队列,两个队列同时与相同的exchange(名称叫做Nova、类型为Topic)绑定,但是二者的RoutingKey不同也就是Topic不同,格式分别为NODE-TYPE.NODE-ID以及NODE-TYPE,其二者功能也有所不同,并且由于采用RPC结构,所以当操作完成,结果会以Direct的方式回复给服务调用方。该流程是RabbitMQ在Openstack中实现的核心思想,具体图示如下:

OpenStack中RabbitMQ RPC 调用研究

浪尽此生 提交于 2020-03-08 18:43:53
这两天研究了一下,OpenStack的工作原理,并着重调研了一下RabbitMQ在OpenStack中扮演的角色。 首先,OpenStack中模块Volume Control、Network Controller、ComputeController以及Scheduler之间的通信是通过AMQP协议实现,消息由RabbitMQ作为中间件转发,以一种RPC(Remote Process Call)的方式进行的。具体可见图 其中用户在dashboard中进行的操作通过Nova.api、Glance.api等调用Volume、Network、ComputeController等模块,上图中是一个逻辑结构,可以看出这种基于RPC的松耦合调用可以不用关心某些模块是否在本机,Openstack的多个模块间可以轻易以分布式的方式解决。 以Nova为例,每一个Nova服务都会在初期建立两个队列,两个队列同时与相同的exchange(名称叫做Nova、类型为Topic)绑定,但是二者的RoutingKey不同也就是Topic不同,格式分别为NODE-TYPE.NODE-ID以及NODE-TYPE,其二者功能也有所不同,并且由于采用RPC结构,所以当操作完成,结果会以Direct的方式回复给服务调用方。该流程是RabbitMQ在Openstack中实现的核心思想,具体图示如下:

OpenStack中RabbitMQ RPC 调用研究

拥有回忆 提交于 2020-03-08 18:42:42
这两天研究了一下,OpenStack的工作原理,并着重调研了一下RabbitMQ在OpenStack中扮演的角色。 首先,OpenStack中模块Volume Control、Network Controller、ComputeController以及Scheduler之间的通信是通过AMQP协议实现,消息由RabbitMQ作为中间件转发,以一种RPC(Remote Process Call)的方式进行的。具体可见图 其中用户在dashboard中进行的操作通过Nova.api、Glance.api等调用Volume、Network、ComputeController等模块,上图中是一个逻辑结构,可以看出这种基于RPC的松耦合调用可以不用关心某些模块是否在本机,Openstack的多个模块间可以轻易以分布式的方式解决。 以Nova为例,每一个Nova服务都会在初期建立两个队列,两个队列同时与相同的exchange(名称叫做Nova、类型为Topic)绑定,但是二者的RoutingKey不同也就是Topic不同,格式分别为NODE-TYPE.NODE-ID以及NODE-TYPE,其二者功能也有所不同,并且由于采用RPC结构,所以当操作完成,结果会以Direct的方式回复给服务调用方。该流程是RabbitMQ在Openstack中实现的核心思想,具体图示如下:

openstack_ice之wsgi详解(paste从ini配置文件->routesr具体发布流程)

ぐ巨炮叔叔 提交于 2020-03-08 18:34:44
感谢朋友支持本博客,欢迎共同探讨交流,由于能力和时间有限,错误之处在所难免,欢迎指正! 如有转载,请保留源作者博客信息。 Better Me的博客 : blog.csdn.net/tantexian 如需交流,欢迎大家博客留言。 对Restful API有了一个基础的了解,那么我们来看通过URL是怎样映射到具体的应用程序操作函数上了。在OpenStack中的API Daemon都会有一个Router类,来构建资源与URL直接的映射关系,完成从接收到URL请求然后映射到具体的函数上执行的整个过程。 这就要了解Python 中的Routes模块。 Routes 是一个python重新实现的Rails routes system,用来将urls映射到应用具体的action上,相反的,还生成url。由于Routes是Rails routes system的python实现,并且网上关于Routes的文档很少,故从rails的routes system入手,就能很好的理解Routes库了。 首先看一个简单的例子,就明白routes的作用, 例如浏览器接收到下面的HTTP请求, GET /instances/1 Rails的路由请求则负责将此请求解析后dispatch来代码中的具体某个函数,完成调用,例如返回虚拟机的信息。 第一部分:讲解wsgi的调用入口(paste)

openstack部署安装

烂漫一生 提交于 2020-03-08 17:13:12
OpenStack实战 准备环境 controller 10.0.0.11 compute1 10.0.0.31 常用服务端口 mariadb:3306 memcached:11211 消息队列:5672和25672 时间同步:123和323 keystone:5000和35357 glance:9191和9292 nova:6080,novncproxy:8774,nova-api:8775 yum源配置 cd /etc/yum.repos.d/ ls mkdir qiangge mv *.repo qiangge ls echo '[openstack] name=openstack baseurl=http://192.168.21.92/repo/ gpgcheck=0 [local] name=local baseurl=http://192.168.21.92/local/ gpgcheck=0' >openstack.repo yum clean all yum makecache 时间同步 controller上面配置一个时间服务器,上游时间,ntp3.aliyun.com allow:10/8 compute1与controller同步 上游时间:controller 在所有节点安装chrony服务 yum install chrony -y

Openstack入门篇(十四)之horizon服务的部署与测试

≡放荡痞女 提交于 2020-03-08 17:12:36
1.Horizon介绍 •提供一个web界面操作openstack的系统 •使用Django框架基于openstack API开发 •支持将session存储在DB、memcached •支持集群 tips:创建虚拟机的方法:horizon,api,命令行 服务未启动,不要再keystone上注册,否则会报错 创建云主机失败排查思路: 服务的判断 nova neutron glance keystone nova service-list -->保证nova的服务是正常的,state为up neutron agent-list -->保证网络服务是正常的,不正常的话会提示找不到主机 常见的:创建云主机正常的,计算节点上的eth0是没有ip地址的,桥接网卡上才会有ip地址 如果某台计算节点重启了,可能桥接网卡不会被绑定上,此时重启linuxbridge服务,或者硬重启一台新的虚拟机。 2.Horizon的安装 为了避免多样服务在同一台机子上,horizon服务安装在node2节点上 (1)安装软件包 [root@linux-node2 ~]# yum install openstack-dashboard -y (2)编辑/etc/openstack-dashboard/local_settings [root@linux-node2 ~]# vim /etc/openstack

Openstack(十三)部署管理服务horizon

烈酒焚心 提交于 2020-03-08 17:12:23
13.1horizon介绍 horizon是openstack的管理其他组件的图形显示和操作界面,通过API和其他服务进行通讯,如镜像服务、计算服务和网络服务等结合使用,horizon基于python django开发,通过Apache的wsgi模块进行web访问通信,Horizon只需要更改配置文件连接到keyston即可,过程如下: 12.2控制端安装horizon # yum install openstack-dashboard 12.3配置horizon # vim /etc/openstack-dashboard/local_settings 159 OPENSTACK_HOST = "192.168.10.100" 28 ALLOWED_HOSTS = ['*',] #配置memcache会话保持, 129 SESSION_ENGINE = 'django.contrib.sessions.backends.cache' #新增加 130 CACHES = { #注释之前的配置 131 'default': { 132 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 133 'LOCATION': '192.168.10.100:11211', 134 }, 135 }