OpenStack

概述： 在应用devstack时，有时会遇到下面的场景从一台安装成功的devstack服务器上复制devstack 到一台全新的服务器上。当然可以通过虚拟机复制来实现，本文介绍通过手工迁移devstack的方式进行迁移，并最大化减少软件下载时间。 1. 迁移准备 步骤1： 操作系统准备 准备一台安装相同的操作系统版本的服务器 修改国内软件源，并进行软件升级 个人建议：推荐使用阿里源，速度快些，但是从稳定性来说还是清华源。 # 具体修改源的方法参考链接 更新源和软件 apt update apt -y upgrade 重新安装部分软件 apt-get install python-dev apt-get install python-pip pip install --upgrade pip pip install -U os-testr #原因见附录 步骤2：【旧服务器】迁移软件准备 stack 整个目录，包括 tar -zcvf stack_ocata.tar.gz /opt/stack/ python软件相关软件目录 cd /usr/local/lib/ tar -zcvf python_2.7.tar.gz python2.7 注意：迁移该目录下的文件，目的是减少与pip源的交互，减少下载文件的时间 cd /usr/local/bin tar -zcvf local_bin

简介 Glance是Openstack的镜像服务。可以让用户注册、查找和检索在Openstack环境中使用的虚拟镜像。Openstack镜像服务支持将镜像文件存储在各种类型的存储环境中。例如本地文件系统或分布式文件系统，如Openstack的对象存储服务（Swift）。下边我们开始部署Glance组件。 创建数据库 与keystone部署一样，需要先创建名为glance的数据库 $ mysql -u root -p MariaDB [(none)]> CREATE DATABASE glance; MariaDB [(none)]> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' IDENTIFIED BY 'glance'; MariaDB [(none)]> GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' IDENTIFIED BY 'glance'; 组件部署 Glance分为两个子服务，如下所示 Glance-api：接受云系统镜像的创建、删除、读取服务 Glance-Registry：云系统的镜像注册服务 安装 # yum install openstack-glance 配置 编辑/etc/glance/glance-api.conf文件

在上一篇分享中，我向各位演示了开源的OpenStack平台与NSX DC集成场景下，当用户在Horizon图形界面或者命令行执行了配置操作后，NSX DC是如何通过Neutron Plugin来响应这些操作，并借助逻辑网络、安全微分段等组件为OpenStack平台构建软件定义的网络与安全的。 我们已经知道，相对于只面向vSphere环境的NSX for vSphere，NSX DC产品中的NSX-T能应对多种异构的Hypervisor和平台，其中除了OpenStack之外，也包括了裸金属服务器。 拿目前最新的NSX-T2.4.1来说，如果管理员尝试添加一台独立的主机传输节点，在下拉菜单中可以看到NSX-T支持的裸金属服务器操作系统清单： Rad Hat Enterprise Linux操作系统 Ubuntu操作系统 CentOS操作系统 SUSE Linux Enterprise操作系统 这里需要注意两点： 显而易见的第一点是，NSX-T暂时不支持裸金属服务器部署Windows操作系统的场景； 隐含的第二点是，NSX-T对于支持的Linux操作系统是有一定的版本要求的，管理员可以查阅VMware官方网站获取兼容性列表：https://docs.vmware.com/cn/VMware-NSX-T-Data-Center/2.4/installation/GUID-26D8A6AE

简介 openstack的nova项目在创建虚拟机的时候，需要在多个主机中选择一个主机来创建虚拟机，这个选择的过程通过nova-scheduler完成，整个选择过程分析如下。 首先nova-scheduler收到创建的请求会在filter_scheduler通过类FilterScheduler的schedule_run_instance启动调度创建虚拟机的流程。 代码如下，红色为关键代码（红色加粗为获取可用主机的部分） def schedule_run_instance ( self , context , request_spec , admin_password , injected_files , requested_networks , is_first_time , filter_properties , legacy_bdm_in_spec ) : vm_uuids = request_spec . get ( 'instance_uuids' ) * #get available hosts for vm create weighed_hosts = self . _schedule ( context , request_spec , filter_properties , vm_uuids ) * instance_uuids = request_spec .

操作区别 rebuild：xp系统的虚拟机用烦了，想换个linux的操作系统，就可以使用rebuild。 evacuate：虚拟机所在的host宕机了，可以使用evacuate将虚拟机在另外一个host上启起来，其实利用这个接口配合host监控工具，可以实现虚拟机的HA能力。 为什么要将这两个一起说呢，是因为在底层，这两个接口其实对应一个操作spawn。 1、rebuild 引用一下官方的API文档说明： 底层的实现，其实就是在虚拟机所在的host上，将原来的虚拟机干掉，然后再根据新的镜像创建一个新的虚拟机，实现虚拟机系统盘的变更，而用户盘的数据是不变的（软件的安装和配置会丢失），虚拟机的网络信息也不变。API里的accessIPv4和accessIPv6参数，在使用Quantum的场景下，是无效的。 目前rebuild仅支持active和stopped状态的虚拟机。而且使用后端卷启动的虚拟机，rebuild之后系统盘不会发生变化，见后面的实验部分。 2、evacuate 引用官方的API文档说明： 该接口使用的前提是虚拟机所在的host宕机。 参数onSharedStorage是让使用者指明，计算节点是否使用共享存储。其实在计算节点是有能力判断是否使用共享存储的（并且计算节点也确实会再进行判断），这里写在接口里，猜测应该是为了在API层做判断吧。 当使用共享存储时

OpenStack云计算之路-Mitaka 版本 分类: OpenStack , 容器/虚拟化 标签: 一小时搞定OpenStack 1.1 云计算简介 云计算（英语：cloud computing ），是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需求提供给计算机各种终端和其他设备。 云计算是继1980年代大型计算机到客户端-服务器的大转变之后的又一种巨变。用户不再需要了解“云”中基础设施的细节，不必具有相应的专业知识，也无需直接进行控制。云计算描述了一种基于互联网的新的IT服务增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展而且经常是虚拟化的资源。 1.1.1 云计算的特点 互联网上的云计算服务特征和自然界的云、水循环具有一定的相似性，因此，云是一个相当贴切的比喻。根据技术研究院的定义如下。 云计算服务应该具备以下几条特征： 🥦 随需应变自助服务。 🥦 随时随地用任何网络设备访问。 🥦 多人共享资源池。 🥦 快速重新部署灵活度。 🥦 可被监控与量测的服务。 一般认为还有如下特征： 🍀 基于虚拟化技术快速部署资源或获得服务。 🍀 减少用户终端的处理负担。 🍀 降低了用户对于IT专业知识的依赖。 1.1.2 云计算服务模式 云计算定义中明确了三种服务模式： 图 - 服务模式详情 软件即服务（SaaS ）： 即Software-as-a-service

openstack各项目之间通过restful api进行通信，相同项目内不同组件进程组件之间通过消息总线进行通信。服务进程通过向消息总线上发送和获取消息，openstack是基于消息驱动的。 目前项目内部消息通信采用两种方式实现RPC和事件通知。 1、RPC（remote procedure call）主要包含call和cast两种（call：同步调用；cast：异步接口）。 2、事件通知（event notification） AMQP的架构如图所示 消息的处理分发主要有Exchange（消息交换）和Queue（消息队列）实现。 当producer将消息发送给消息服务器时，由Exchange和消息的routing key决定将消息发送给哪个queue队列，然后consumer在queue拿取自己感兴趣的消息进行处理。 Exchange并不会保存消息，只是对消息进行分发，负责指定消息发送到哪个队列上。 基于AMQP的RPC实现 client发送消息request给exchange，routing key指明到op_queue消息队列，并从res_queue取返回。 Exchange将消息推送到op_queue消息队列 server端从op_queue取出自己需要处理的数据，执行对应的任务，并将执行的响应结果发送给exchange，指明到res_queue

简介 　　本次部署neutron组件，neutron组件主要管理openstack网络。分别部署neutron和controller neutron节点，与上一篇博客部署nova类似，controller和compute节点同样分别部署到两台设备上。 部署controller neutron 创建数据库 　　与其他组件一样，首先需要创建neutron需要的数据库，操作如下： $ mysql -u root -p 　　创建neutron数据库 MariaDB [(none)] CREATE DATABASE neutron; 　　授权数据库 MariaDB [(none)]> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' \ IDENTIFIED BY 'neutron'; MariaDB [(none)]> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' \ IDENTIFIED BY 'neutron'; 组件部署 　　设置环境变量 [root@localhost ~]# source admin-openstack.sh 创建neutron user $ openstack user create --domain default --password

前两篇博文分别研究了Compute节点和Neutron节点内部的网络架构。本文通过一些典型流程案例来分析具体网络流程过程。 0. 环境 同 学习OpenStack之（7）：Neutron 深入学习之 OVS + GRE 之 Neutron节点篇 中所使用的环境。 简单总结一下： Compute 节点上由Neutron-OVS-Agent负责： br-int：每个虚机都通过一个Linux brige连到该OVS桥上 br-tun：转化网络packet中的VLAN ID 和 Tunnel ID GRE tunnel：虚拟GRE通道 Neutron节点上： br-tun/br-int：同Compute节点，由Neutron-OVS-Agent负责 br-ex：连接物理网卡，用于和外网通信 Network namespace：用于tenant 网络DHCP服务的qDHCP由Neutron-DHCP-Agent负责，和用于网络间routing的qRouter由Neutron-L3-Agent负责 2. 几个典型流程案例 2.1 流程1： 同一个host上同一个子网内虚机之间的通信过程 因为br-int是个虚拟的二层交换机，所以同一个host上的同一个子网内的虚机之间的通信只是经过 br-int 桥，不需要经过 br-tun 桥。如下图中红线所示： 2.2 流程2：

文章目录 简介 结构 调度 管理卷 备份 简介 cinder 在虚拟机与具体存储设备之间引入了一层 “逻辑存储卷” 的抽象，为虚拟机提供持久化的块存储能力，实现虚拟机存储卷的创建、挂载、卸载、快照等生命周期管理。 cinder 本身并不是一种存储技术。它只是提供了一个中间抽象层，为后端不同的存储技术提供了统一的接口。不同的块设备服务厂商在 cinder 中以 driver 的形式实现这些接口来与 OpenStack 进行整合。 cinder 默认使用 LVM 作为后端存储。 结构 cinder 主要由 cinder-api、cinder-scheduler、cinder-volume 以及 cinder-backup 组成，它们之间通过 AMQP 消息队列进行通信。 cinder-api ：cinder 的 HTTP 接口。 cinder-volume ：运行在存储节点上，管理具体存储设备的存储空间。 cinder-scheduler ：根据预定的策略选择合适的 cinder-volume 节点来处理用户请求。如果用户明确指定了具体的存储节点，则该节点上的 cinder-volume 会进行处理，而无需 cinder-scheduler 的参与。 cinder-backup ：提供存储卷的备份功能，将存储卷备份到存储后端，如 swfit 。 调度 FilterScheduler