Tag Archives: Openstack

最近在研究 OpenStack Manila 的代码,总结成这篇文章,介绍了 Manila Share 主要代码和设计,重点在其网络的实现上。

Manila 网络模块

tags: Manila Network


前言

Manila 是目前比较完善的一个 OpenStack PaaS 服务组件,它需要借助 Neutron 来完成其管理和网络连接,其网络架构主要如下图,本文会主要介绍 Manila 的网络组件代码,而不是其网络架构。

Manila 网络逻辑架构

对于一个类似的 PaaS 项目,其主要需求是在 Neutron 上启动属于自己的 Service Network 和 Service Port,项目的 Agent 可以通过 Service Port SSH 连接到处于 Service Network 的 Service VM。

启动

服务的启动

先看 Manila 的启动过程。Manila share 的启动没有像 Neutron 的 agent 一样直接运行特定的main()函数,而是在manila/bin/manila-service通过service完成实例化,实例化的类并不是一个hard-code的类,而是可以通过share_manager这个配置修改的,其运行过程如下:

#bin/manila-share.py
       server = service.Service.create(binary='manila-share')

#manila/service.py
class Service(object):
   def create(cls, host=None, binary=None, topic=None, manager=None,
              report_interval=None, periodic_interval=None,
              periodic_fuzzy_delay=None, service_name=None):
       if not topic:
           topic = binary
       if not manager:
           subtopic = topic.rpartition('manila-')[2]
           manager = CONF.get('%s_manager' % subtopic, None)

#manila/common/config.py
   cfg.StrOpt('share_manager',
              default='manila.share.manager.ShareManager',
              help='Full class name for the share manager.'),

Driver 的加载

实例化share_manager时,首先获得配置文件对象,然后加载 driver,默认为GenericShareDriver

Read More →

原帖由 Neutron PTL: @Kyle 发在社区:

http://specs.openstack.org/openstack/neutron-specs/priorities/kilo-priorities.html

重构类:

  • REST API、RPC 等都将重构;
  • WSGI 从自己写的原生 API 改为由 pecan 实现;
  • 降低从 nova-network 迁移到 neutron 的难度;
  • 将第三方的 drivers 从主目录分出来;
  • 分割高级服务功能(LBaaS、VPNaaS、FWaaS)

测试类:

  • 增加全栈测试;
  • 增加更多的功能测试;

Agent 类:

  • L2 Agent:抽象、功能测试、OVSDB、ML2 Agent;
  • DHCP Agent:重启优化、负载均衡调度、死亡 Agent 重新调度、功能测试

新功能:

  • 插件化的 IPAM(IP 地址管理);
  • 实现 Trunk Port,主要为 NFV 使用;
  • 提高 Agent 子进程的可监视性;
  • 使用“daemon mode”代替 rootwrap 提高调用系统指令的的性能

吐槽:

重构动作好大,对 Neutron 有很多修改的公司又被坑苦了;

Read More →

Neutron 的软件架构

综述

OpenStack 是目前开源界第二大的项目,参与的厂商之多可谓少见,同时作为目前最大的以 Python 作为主要语言的项目,可以说这个项目是经过重重困难发展起来的,算是目前在发展的分布式系统软件大作了,面对这么一个项目,我想我们有很多值得学习和借鉴的地方,因为时间和个人经验的缘故,我在这里主要与大家分享以 Neutron 为例的 OpenStack 软件设计。

Why Python

设计一个分布式系统可以说会面对诸多挑战,这不只是 Python 会遇到的,使用别的语言也会碰到,但是呢,Python 作为一个与 Java 等语言相比不够成熟的语言可能会面临一些其他可能已经在一些语言下解决了的问题,在 OpenStack 社区里就有人提过多次这个问题,为什么我们选择 Python,而非别的语言。

在我看来,一个大型软件的选型是一个复杂的事情,对于 OpenStack,可能第一是因为历史原因。因为我们知道 OpenStack 最早的源代码是 Rackspace 和 NASA 一起贡献的,他们当初内部的选择为我们建立了一个基调,如果再用其他语言重写的话,可能在当时是一个不合实际的考虑;再有,OpenStack 与其说是一个大型软件,倒不如说是一个框架,它的虚拟化来自于 KVM、Qemu 等的支持,它的网络来自于 Open vSwitch、iptables 等的支持,至于存储,也需要 lvm、Ceph 作为底层。那么 OpenStack 是干嘛的呢,它是一个总的调度器,集成这一切功能,完成一个真正的自由云计算软件。做运维的同学一般比较熟的语言都是 Shell、Python,老一点的可能熟悉 Perl,为什么?因为这些脚本语言,很适合做这种调度的工作,或者说它很适合做粘合剂,正如一些人称 Python 为“胶水语言‘一样,它能够方便的粘合各个组件,而且代码量相对少,可以让人专注于高层的事情,而不是为了底层费脑筋;再有,作为一个高级语言,Python 有着一些相对完美的特性,比如社区的有过提交的开发者有数千,活跃的开发者也有几百,为什么 OpenStack 能快速吸引这么多开发者,所有人都是之前就接触过 Python 么?不是的,很多人都是现学的,因为 Python 的基本语法真的很简单,只需要看一个晚上第二天就能阅读 OpenStack 基本的代码了,这对吸引开发者来说很有好处,就像为什么有些公司做项目首先考虑 Java,因为好招人啊!Python 作为一个学习曲线平滑的语言,可以说为吸引开发者带来很多方便。再有,反射、自省这些高级特性也不缺,这位开发带来了方便,丰富的库,比如Paste、Routes、requests、WebOb、alembic、Jinja2 等,更是提升前期效率的利器。

分布式系统中面临的问题

连接建立与服务初始化
事件分离与事件处理程序分派
IPC 与网络协议处理
静态和动态组件
并发与同步

Neutron 简介

因为很多人对 OpenStack 不那么熟,我就先简单介绍下 Neutron 是什么。Neutron 是 OpenStack 的虚拟网络组件,用洋气点的话说,就是一个 SDN 控制器。为什么我们需要虚拟网络?过去我们只给客户提供虚拟机,你花钱,我租你一台,想连接上就再买个公网 IP,就像很多人在 DigitalOcean 做得一样(当然 DigitalOcean 现在也有虚拟网络)。那有了虚拟网络可以干什么呢?我们来看一下 UStack 控制面板里的一张图:
Read More →

之前一直没有好好看过 Neutron API 服务的实现,这几天好好看了一下,对 WSGI、paste.deploy、Webob、routes 熟悉的人估计很快就能看完,可惜我对上面的概念/库没有个熟悉的,所以看了好久才看明白…… 下面是记录,这一部分主要是从 main 开始逐句分析 server 启动的大概过程,主要针对 API,对 RPC 的介绍等下次在看。

安装 Neutron-server 后,其将作为一个服务,启动,和别的服务一样,启动文件在 /etc/init.d,这里挑选部分:

. /etc/rc.d/init.d/functions  
# 执行 /etc/rc.d/init.d/functions,主要是引用里面的函数

prog=neutron
exec="/usr/bin/$prog-server"  # 目标执行文件是/usr/bin/neutron-server
configs=(
   "/usr/share/$prog/$prog-dist.conf" \
   "/etc/$prog/$prog.conf" \
   "/etc/$prog/plugin.ini" \
)  # 配置文件位置
pidfile="/var/run/$prog/$prog.pid"
logfile="/var/log/$prog/server.log"

[ -e /etc/sysconfig/$prog ] && . /etc/sysconfig/$prog
#如果存在 /etc/sysconfig/neutron 则执行

lockfile=/var/lock/subsys/$prog-server

start() {
   [ -x $exec ] || exit 5  # 若 /usr/bin/neutron-server 存在且可执行则运行
   for config in ${configs[@]}; do
       [ -f $config ] || exit 6  # 检验文件是否存在且为普通文件
   done
   echo -n $"Starting $prog: "
   daemon --user neutron --pidfile $pidfile "$exec ${configs[@]/#/--config-file } --log-file $logfile &>/dev/null & echo \$! > $pidfile"
   # 引号部分比较复杂,其实是执行这么一句话:
   # "/usr/bin/neutron-server --config-file /usr/share/neutron/neutron-dist.conf
   # --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini --log-file
   # /var/log/neutron/server.log",并丢弃其输出,然后获得其 pid,把 pid 输出到
   # /var/run/neutron/neutron.pid,去掉执行 /usr/bin/neutron-server 时加的乱七八糟一大堆参数
   # 其实简化相当与这样:
   # daemon --user neutron --pidfile /var/run/neutron/neutron.pid /usr/bin/neutron-server
   # damon 是来自 /etc/rc.d/init.d/functions 用于产生 service 的函数
   retval=$? # 获取 damon 执行后的状态值
   echo
   [ $retval -eq 0 ] && touch $lockfile
   # 执行成功(状态值为0)则更新 /var/lock/subsys/neutron-server 的使用/更新时间为当前
   return $retval
}

ok,这个启动脚本主要还是执行 /usr/bin/neutron-server,我们看下这个脚本的内容:

#!/usr/bin/python
# PBR Generated from 'console_scripts'

import sys

from neutron.server import main

if __name__ == "__main__":
   sys.exit(main())

就是执行了一下 neutron.server.main(),下面我们来看下这个函数(server/__init__.py文件): Read More →

下面是部分源自我实习期间的调研报告,本作品采用知识共享Attribution-NonCommercial-NoDerivatives 4.0 国际许可协议进行许可,转载前请先联系作者(MatheMatrix)。

下面我们以这样一个场景来解释Open vSwitch如何在Neutron(OpenStack发挥作用),假定读者实践过前文第二章“Neutron与其他OpenStack模块安装 ”(暂未公开~不过基本类似于前边的OpenStack 安装脚本与常见问题),或对OpenStack有一定认识,最好实践过官方OpenStack安装手册的内容。

场景(一个租户,两个网络,一个路由,内部网络使用GRE,Libvirt VIF Driver使用LibvirtHybridOVSBridgeDriver):

场景一虚拟网络拓扑 场景一虚拟网络拓扑

Figure 11 场景一虚拟网络拓扑

如图我们有一个外网(External Network),IP段为172.16.0.0/16,两个内网,分别是Internal:10.18.0.0/24,和Internal2:10.22.22.0/24,值得注意的是这是两个网络(network),而不是子网(subnet)。

在这个场景下,计算节点的内部应当是这样的:

 

计算节点网络连接原理 计算节点网络连接原理

下面我将解释如何得到这幅图。 Read More →