从今天开始,我们将学习 OpenStack 的 Networking Service,Neutron.Neutron 的难度会比前面所有模块都大一些,内容也多一些.为了帮助大家更好的掌握 Neutorn,CloudMan 也会分析地更详细一些. Neutron 概述 传统的网络管理方式很大程度上依赖于管理员手工配置和维护各种网络硬件设备:而云环境下的网络已经变得非常复杂,特别是在多租户场景里,用户随时都可能需要创建.修改和删除网络,网络的连通性和隔离不已经太可能通过手工配置来保证了. 如何快速响

最近在学习 OpenStack 的相关知识,一直苦于 OpenStack 的体系庞大以及复杂程度,学习没有进度,停滞不前.偶然机会在 51CTO 上发现了一个热点的专题关于 OpenStack 的,题目叫做<每天5分钟 玩转 OpenStack>,抱着试试的态度看了几篇,被文章的内容和书写风格吸引了,内容全面,思路清晰,简单易懂,关键是每篇博文的内容很少,绝对是一泡大便的功夫.每周一.周三.周五定时更新,微信也有同步更新.不过大神在博客园cnblogs上的博文没有目录,每次翻阅的时候甚是费劲,

<每天5分钟玩转 OpenStack>是一个 OpenStack 教程,这是第 1 篇. 这个教程有下面两个特点: 系统讲解 OpenStack 从架构到各个组件:从整体到细节逐一讨论 重实践并兼顾理论 主要从实际操作的角度带着大家学习 OpenStack. 为啥要写这个? 简单回答是:因为OpenStack 学习难度大,但如果掌握了价值会很大 先做一个自我介绍吧. 本人网名CloudMan,在 IT 这个行当已经摸爬滚打了十多年,05年之前是搞上层应用开发的,那时候 Java 比较火,所以

作为 OpenStack 的核心教程,我们已经到了最后总结的部分. OpenStack 目前已经有好几十个模块,本教程讨论的是最最重要的核心模块:Keystone,Nova,Glance,Cinder 和 Neutron.请大家看下图: 此图截自 https://www.openstack.org/software/project-navigator/,这是 OpenStack 官方定义的 6 个 Core Service.每个模块都会从三个维度来衡量: ADOPTION - 采用度 MATUR

本节介绍几个 cloud-init 的典型应用:设置 hostanme,设置用户初始密码,安装软件. 设置 hostname cloud-init 默认会将 instance 的名字设置为 hostname.但这样不太方便,有时希望能够将二者分开,可利用 cloud-init 的set_hostname 模块实现.set_hostname 它会查询 metadata 中 hostname 信息,默认值就是 instance 的名字.我们可以指定自己的 hostname,方法是将下面的内容传给 c

OpenStack是云操作系统,要学习OpenStack,首先需要掌握一些虚拟化和云计算的相关知识. 虚拟化 虚拟化是云计算的基础.简单的说,虚拟化使得在一台物理的服务器上可以跑多台虚拟机,虚拟机共享物理机的 CPU.内存.IO 硬件资源,但逻辑上虚拟机之间是相互隔离的. 物理机我们一般称为宿主机(Host),宿主机上面的虚拟机称为客户机(Guest). 那么 Host 是如何将自己的硬件资源虚拟化,并提供给 Guest 使用的呢?这个主要是通过一个叫做 Hypervisor 的程序实现的. 根

OpenStack 由 Glance 提供 Image 服务. 理解 Image 要理解 Image Service 先得搞清楚什么是 Image 以及为什么要用 Image? 在传统 IT 环境下,安装一个系统是要么从安装 CD 从头安装,要么用 Ghost 等克隆工具恢复.这两种方式有如下几个问题: 如果要安装的系统多了效率就很低 时间长,工作量大 安装完还要进行手工配置,比如安装其他的软件,设置 IP 等 备份和恢复系统不灵活 云环境下需要更高效的解决方案,这就是 Image. Image

本节讨论 nova-compute,并详细分析 instance 部署的全过程. 先给大家道个歉:今天这篇文章的篇幅比以往要多一些,本来想分两次发,但考虑到文章的完整和系统性,还是一次发了出来,这次可能要超出 5 分钟了,大家见谅. nova-compute 在计算节点上运行,负责管理节点上的 instance. OpenStack 对 instance 的操作,最后都是交给 nova-compute 来完成的. nova-compute 与 Hypervisor 一起实现 OpenStack

​这是 OpenStack 实施经验分享系列的第 13 篇. instance snapshot 操作可用于备份或者将 instance 保存为新的 image.如果在生产系统中执行 snapshot 操作,必须确保此操作快速且安全.这里有两个关键点: 快速. 为保证数据的一致性,snapshot 时需要 pause instance,操作完后再 resume.在这个过程中 instance 是无法对外服务的,为了减少对业务的影响,我们希望 snapshot 越快越好. 安全. 即数据一致性,s

Linux Bridge 和 Open vSwitch 是目前 OpenStack 中使用最广泛的两种虚机交换机技术. 前面各章节我们已经学习了如何用 Linux Bridge 作为 ML2 mechanism driver 实现 Neutron 网络.今天开始我们将详细讨论如何用 Open vSwitch 实现 Neutron. 实验环境两节点的网卡分配方式与 Linux Bridge 一致,如下所示: 控制节点三个网卡(eth0, eth1, eth2),计算节点两网卡(eth0, eth1

我们已经有了 Load Balance Pool "web servers"和 VIP,接下来需要往 Pool 里添加 member 并学习如何使用 cloud image. 先准备两个 instance: "Web1" 和 "Web2". 使用 Ubuntu Cloud Image 由于 cirros 镜像不能运行 HTTP 服务,我们将使用 Ubuntu Cloud Image.下载地址为 http://uec-images.ubuntu.c

Load Balance as a Service(LBaaS)是 Neutron 提供的一项高级网络服务.LBaaS 允许租户在自己的网络中创建和管理 load balancer. load balancer 可以说是分布式系统中比较基础的组件. 它接收前端发来的请求,然后将请求按照某种均衡策略转发给后端资源池中的某个处理单元,以完成处理. load balancer 可以实现系统高可用和横向扩展. LBaaS 有三个主要的概念: Pool Member,Pool 和 Virtual IP P

本节按照以下步骤部署 DevStack 实验环境,包括控制节点和计算节点 创建虚拟机 按照物理资源需求创建 devstack-controller 和 devstak-compute 虚拟机 安装操作系统 安装 Ubuntu 14.04,并配置 eth0 的 IP devstack-controller  192.168.104.10 devstak-compute    192.168.104.11 下载代码 下载 devstack 代码,并切换到 stable/liberty 分支 apt-

除了前面讨论的 local, flat, vlan 这几类网络,OpenStack 还支持 vxlan 和 gre 这两种 overlay network. overlay network 是指建立在其他网络上的网络. 该网络中的节点可以看作通过虚拟(或逻辑)链路连接起来的. overlay network 在底层可能由若干物理链路组成,但对于节点,不需要关心这些底层实现. 例如 P2P 网络就是 overlay network,隧道也是. vxlan 和 gre 都是基于隧道技术实现的,它们也

上一节我们讨论了 Neutron 将虚拟 router 放置到 namespace 中实现了不同 subnet 之间的路由.今天探讨为什么要用 namespace 封装 router? 回顾一下前面的网络逻辑结构图: 我们需要讨论一个深层次的问题: 为什么不直接在 tape17162c5-00 和 tapd568ba1a-74 上配置 Gateway IP,而是引入一个 namespace,在 namespace 里面配置 Gateway IP 呢? 首先考虑另外一个问题: 如果不用 names

本节开始我们将学习 Linux Bridge 如何实现 Neutron 的各种功能.首先需要配置 linux-bridge mechanism driver. Neutorn ML2 plugin 默认使用的 mechanism driver 是 open vswitch 而不是 linux bridge.那是否还有研究 linux bridge 的必要呢?我的答案是:很有必要! 原因如下: linux bridge 技术非常成熟,而且高效,所以业界很多 OpenStack 方案采用的是 lin

前面讨论了 Neutron 的架构和基础知识,接下来就要通过实验深入学习和实践了. 第一步就是准备实验用的物理环境,考虑如下几个问题: 需要几个节点? 如何分配节点的角色? 节点上部署哪些服务? 配几个网卡? 物理网络如何连接? 1 控制节点 + 1 计算节点 的部署方案 我们的目的是通过实验学习 Neutron 的各种特性. 为了达到这个目的,实验环境应尽量贴近典型的部署方案:但同时,由于是个人学习使用,受物理条件的限制需要尽量利用有限的资源,所以我们采用下面的部署方案: Q:需要几个节点?

前面我们详细讨论了 Neutron 架构,包括 Neutron Server,Core 和 Service Agent.现在用两张图做个总结.先看第一张: 与 OpenStack 其他服务一样,Neutron 采用的是分布式架构,包括 Neutorn Server.各种 plugin/agent.database 和 message queue. Neutron server 接收 api 请求. plugin/agent 实现请求. database 保存 neutron 网络状态. mess

上一节我们讨论了 ML2 Plugin 解决的问题,本节将继续研究 ML2 的架构. ML2 对二层网络进行抽象和建模,引入了 type driver 和 mechansim driver. 这两类 driver 解耦了 Neutron 所支持的网络类型(type)与访问这些网络类型的机制(mechanism),其结果就是使得 ML2 具有非常好的弹性,易于扩展,能够灵活支持多种 type 和 mechanism. Type Driver Neutron 支持的每一种网络类型都有一个对应的 ML

我们在 Neutron Server 小节学习到 Core Plugin,其功能是维护数据库中 network, subnet 和 port 的状态,并负责调用相应的 agent 在 network provider 上执行相关操作,比如创建 network.上一节也介绍了两个 Core Plugin:linux bridge plugin 和 open vswitch plugin.本节将详细讨论更重要的 ML2 Core Plugin. Moduler Layer 2(ML2)是 Neutr