OpenStack

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

实验环境下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在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在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在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中实现的核心思想，具体图示如下：

感谢朋友支持本博客，欢迎共同探讨交流，由于能力和时间有限，错误之处在所难免，欢迎指正！ 如有转载，请保留源作者博客信息。 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实战 准备环境 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

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

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 }