OpenStack支持多种SDN控制器的对接,之前的对接方案是将一个mechanism driver的一个python文件放在neutron ml2的目录下面,使得OpenStack对neutron的操作可以转发给SDN控制器。但是这样的处理方式存在许多问题,后来的driver被命名为xxx-networking的项目,主要是为了更好地对接HA部署的OpenStack,因为Neutron server分布在多个物理机上的时候会出现更加复杂的情况,而导致SDN控制器接受到错误的消息,这篇文章以ODL-Networking为例,介绍ODL是如何实现的,自研控制器的对接也可以参考ODL的设计思想。

ODL的ODL-Networking项目位于下面的链接中
https://github.com/openstack/networking-odl

ODL-Networking 介绍

OpenStack networking-odl是一个二进制文件的一个plugin,它的作用是集成OpenStack的Neutron API和OpenDaylight SDN控制器。networking-odl有ML2 driver和L3 plugin的模块,可以支持OpenStack Neutron L2和L3的API,再转发数据到OpenDaylight控制器上

ODL驱动架构v1

ODL-Networking分为v1 driver和v2 driver v1 driver会把OpenStack上的网络的更改同步到ODL控制器上。举个例子来说,用户创建了一个网络,首先这个操作会被写进OpenStack的数据库中,然后ODL driver会发送一个POST请求到ODL控制器

虽然这个操作看起来很简单,但是却有一些隐含的问题

  • ODL并不是实时反应的,即使REST call成功给到了ODL,ODL也不一定可以马上响应
  • 在负载很大的时候(可能是odl或者openstack),两边的同步可能会存在瓶颈
  • 在遇到odl与openstack同步失败的时候,v1 driver在下次的call REST API的时候会尝试去“full sync”整个neutron DB,所以会导致下次的REST API call花费很长的时间
  • 在多个rest api call竞争的情况下可能会出问题:
    1.例如,创建subnet的时候再创建port的情况,再neutron的HA部署的时候,这2个创建的消息会同步的通过v1 driver发给ODL,导致创建port失败
    2.在前面的“full sync”的操作的时候,这个时候数据库如果正在删除资源,那么这个时候同步的话,会把下一时刻会被删除的资源,同步到odl这边,形成openstack和odl的资源不同步

ODL驱动架构v2

面对前面的这些问题,社区又重新设计了v2 driver

  • v2 driver最重要的机制是引入了journaling(记录)机制,v2 driver会把openstack传给open daylight的数据记录在一个journal表中,journal表使用一堆队列来构成的。而不是直接把openstack的数据传递给odl
  • v2 driver中会起一个journal的线程,它会周期性地检查journal表中是否有新的数据,然后处理新的数据,另外的,openstack neutron的postcommmit的操作也会触发这个线程工作
  • 用户在创建一个网络资源的时候,这条数据会一开始存在neutron DB中,v2 driver再把这条数据存在“journal entry”里面,这个时候触发journal线程来处理这条数据
  • 数据在pre-commit的时候就已经被记录在journal entry中了,以防止这个commit失败的时候,journal entry也可以马上中止,实现消息的同步

Journal Entry架构

  • journal entry一开始创建的时候,把状态置为“pending”等待状态,在这种状态下,entry在等待线程来处理,很多线程在处理entry的时候,只有一个线程可以“选中”这个entry
  • 当这个entry被选中时,状态会被置为“processing”状态,并且被lock住,防止其他的线程来处理这个entry
  • 当线程开始处理的时候,它先检查这个entry的依赖关系,如果这个entry依赖其他的entry,那么这个线程会把这个entry放回原位,然后再处理下一个entry
  • 当这个entry没有其他依赖关系的时候,这个线程会吧entry里面的消息传递给opendaylight,具体是PUT,POST,DELETE这些操作,当这个REST call成功的时候,那么把这个entry的状态置为“completed”
  • 当出现错误的时候,线程首先判断这个是“expected”意料之中的错误(如网络连通性等问题)还是“unexpected”意料之外的错误。对于那些意料之外的错误,会引入一个计数器,并对这个计数器设置一个数字,这个entry会被再次处理,处理的次数是这个计数器的数字。对于那些意料之中的错误,不会改变计数器的数字,当entry再次处理,直到计数器数字的次数后,这个entry就被设置为“failed”状态。否则,这个entry重新被标记为“pending”等待,等待下次被处理。

Entry依赖检查机制

以下是社区的Entry依赖检查机制BP,Entry依赖检查机制将会被提前到entry创建的时候进行
https://blueprints.launchpad.net/networking-odl/+spec/dep-validations-on-create
当前v2 driver的Entry依赖检查机制发生在entry被处理的时候,但是将会被改为entry被创建的时候就进行依赖检查机制 当原先Entry依赖检查机制发生在entry被处理的时候,如果依赖检查机制fail,那么这个entry就会被送回队列,这样的处理方式可能会有以下几个问题

  • entry依赖检查机制fail但是不知道哪里出了问题
  • 很难去debug
  • 当循环依赖的情况发生的话很难定位问题
  • 一个entry可能会被反复进行依赖检查,导致CPU浪费
  • 过多地检查依赖关系的话会导致数据库压力剧增

因此,Entry依赖检查机制将会被提前到entry创建的时候就进行,在entry被创建的时候,journal就会检查这个entry是否有依赖其他的entry,如果有的话,那么把这个entry放在一个链表中。这样的话,journal在选择entry的时候就会只去选择没有其他依赖的entry,当entry被处理后,无论是成功还是失败,依赖这个entry的链表都会被清空,这样可以使得后面的entry不会依赖到它。
下面是journal依赖的表,一个entry如果有依赖的话,那么下面的表中的行列就是这个entry的外键,entry被删除的时候,这些外键也需要被同时删除。entry在被处理的时候,这个entry所依赖的parent被存入parent_id中,依赖这个entry的被存入dependent_id中,在journal处理这个entry的时候,必须要保证这个entry没有与parent有依赖关系(当parent被处理完之后会自动断开所有依赖),这样的话就保证了不会存在parent没处理完,而直接去处理这个entry的情况。

1
2
3
4
5
6
+------------------------+
| odl_journal_dependency |
+------------------------+
| parent_id              |
| dependent_id           |
+------------------------+

Entry恢复机制

以下是社区的Entry恢复机制BP,
https://docs.openstack.org/developer/networking-odl/specs/completed/ocata/journal-recovery.html
Journal entry在处理失败的情况,entry需要再被处理
entry可能由于以下几个原因处理失败

  • 在最大尝试次数条件下,一直处理失败
  • ODL中的数据和OpenStack Neutron数据库不一致
  • Neutron和ODL中的数据同步失败 目前失败的entry就一直会存在journal表中,这样会影响journal表的性能,大量的失败的entry存在journal表中的话对性能的影响还是很大的

现在需要解决的问题是如何处理entry中标记为fail的entry
下面是社区BP的流程图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
+-----------------+
| For each entry  |
| in failed state |
+-------+---------+
        |
+-------v--------+
| Query resource |
| on ODL (REST)  |
+-----+-----+----+
      |     |                          +-----------+
   Resource |                          | Determine |
   exists   +--Resource doesn't exist--> operation |
      |                                | type      |
+-----v-----+                          +-----+-----+
| Determine |                                |
| operation |                                |
| type      |                                |
+-----+-----+                                |
      |              +------------+          |
      +--Create------> Mark entry <--Delete--+
      |              | completed  |          |
      |              +----------^-+       Create/
      |                         |         Update
      |                         |            |
      |          +------------+ |      +-----v-----+
      +--Delete--> Mark entry | |      | Determine |
      |          | pending    | |      | parent    |
      |          +---------^--+ |      | relation  |
      |                    |    |      +-----+-----+
+-----v------+             |    |            |
| Compare to +--Different--+    |            |
| resource   |                  |            |
| in DB      +--Same------------+            |
+------------+                               |
                                             |
+-------------------+                        |
| Create entry for  <-----Has no parent------+
| resource creation |                        |
+--------^----------+                  Has a parent
         |                                   |
         |                         +---------v-----+
         +------Parent exists------+ Query parent  |
                                   | on ODL (REST) |
                                   +---------+-----+
+------------------+                         |
| Create entry for <---Parent doesn't exist--+
| parent creation  |
+------------------+

entry中标记为fail状态的entry不能对后面进来的entry产生影响
BP的实现可以分为两个部分,第一个部分,当我们检查到entry处于fail状态的时候,这个entry的动作可能是create或者update操作,如果这个资源再ODL中并没有存在、生效的话,那么我们就创建一个新的”create resource”这样的entry出来 其中,处理这个fail的entry是由一个专门的线程来处理,称为”maintenance thread”

代码分析

v2的driver相比以前只有一个python文件来说,代码量大了许多,主要内容在networking_odl目录下
其中bgpvpn,fwaas,lbaas,qos,sfc这几个高级功能都是针对ODL的北向接口开发的,因此参考意义不大。主要的内容还是journal机制的实现以及l2和l3的实现

1
2
3
4
5
6
7
L2_RESOURCES = {ODL_SG: ODL_SGS,
                ODL_SG_RULE: ODL_SG_RULES,
                ODL_NETWORK: ODL_NETWORKS,
                ODL_SUBNET: ODL_SUBNETS,
                ODL_PORT: ODL_PORTS}
L3_RESOURCES = {ODL_ROUTER: ODL_ROUTERS,
                ODL_FLOATINGIP: ODL_FLOATINGIPS}

在判断pending还是processing的时候,通过session.query去数据库中查找

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
def check_for_pending_or_processing_ops(session, object_uuid, seqnum=None,
                                        operation=None):
    q = session.query(models.OpendaylightJournal).filter(
        or_(models.OpendaylightJournal.state == odl_const.PENDING,
            models.OpendaylightJournal.state == odl_const.PROCESSING),
        models.OpendaylightJournal.object_uuid == object_uuid)

    if seqnum is not None:
        q = q.filter(models.OpendaylightJournal.seqnum < seqnum)

    if operation:
        if isinstance(operation, (list, tuple)):
            q = q.filter(models.OpendaylightJournal.operation.in_(operation))
        else:
            q = q.filter(models.OpendaylightJournal.operation == operation)
    return session.query(q.exists()).scalar()

上述的2个机制分别位于2个类中,实现了描述的功能
Journal Entry架构:class OpendaylightJournalThread(object):
Entry恢复机制:class MaintenanceThread(object):
而L2和L3 的转发分别位于以下2个类中:

1
2
3
4
5
6
7
8
class OpenDaylightL2gwDriver(service_drivers.L2gwDriver):

class OpenDaylightL3RouterPlugin(
        common_db_mixin.CommonDbMixin,
        extraroute_db.ExtraRoute_db_mixin,
        l3_dvr_db.L3_NAT_with_dvr_db_mixin,
        l3_gwmode_db.L3_NAT_db_mixin,
        l3_agentschedulers_db.L3AgentSchedulerDbMixin):

在性能方面,ODL-Networking对对entry做cache缓存,有timeout和value属性,应该会有不小的性能提升
class CacheEntry(collections.namedtuple(‘CacheEntry’, [‘timeout’, ‘values’])):
为了更好的支持ODL增加的北向接口,ODL-Networking还特定会起一个start_odl_websocket_thread,位于下面的类中
class OpendaylightWebsocketClient(object):

参考文献

https://docs.openstack.org/developer/networking-odl/

由于ODL社区的文档更新实在是很慢,而且文档很多都是用DevStack或者是Ubuntu的环境,导致稍微版本更新一下,或者底层的OS换一下,参考的文档便不再适用了,由此还需要中文文档可以及时更新。

实验环境:

系统:CentOS7 OpenStack:Mitaka Stable版本,一台物理机起controller+network+compute ,一台物理机起compute
ODL:Opendaylight Boron(硼)-SR3版本,部署在单独的物理机

安装OpenStack:

如何安装OpenStack不在本文档的讨论范畴之内,可参考该官方文档,网络类型选择self-service就可以了 https://docs.openstack.org/mitaka/install-guide-rdo/

如何安装ODL:

由于ODL的安装可以下载编译好的代码,对新手已经有很大的帮助了,但是由于ODL的feature再不断的更新,使用氦版本的文档还是有问题 http://www.sdnlab.com/1931.html 上面的链接文档还是可以借鉴,需要先安装JDK版本,我安装了1.8版本,设置完环境变量之后就可以使用ODL了


# unzip distribution-karaf-0.5.3-Boron-SR3.zip
# cd distribution-karaf-0.5.3-Boron-SR3/
# cd bin
# ./karaf

硼版本已经不会有”线程异常且No route to host错误”这个问题了 在ODL shell中, 需要按照顺序安装下列的features:

1
2
3
opendaylight-user@root>feature:install odl-ovsdb-openstack
opendaylight-user@root>feature:install odl-dlux-core
opendaylight-user@root>feature:install odl-dlux-all

使用下列命令检查上述的features有没有正确的安装

1
2
3
4
5
opendaylight-user@root>feature:list | grep dlux
  < showing the list of features installed … >
opendaylight-user@root>feature:list | grep openstack
  < showing the list of features installed … >
opendaylight-user@root>

临时关闭防火墙和selinux


setenforce 0
systemctl stop firewalld

安装完成之后可以使用下列命令在任意节点获取到ODL上面的对接OpenStack API的信息:


openstack@controller:~$ curl -u admin:admin http://192.168.51.110:8080/controller/nb/v2/neutron/networks
{
   "networks" : [ ]
}openstack@controller:~$

到这里ODL上设置就基本完成了
注意:请按照一定的顺序安装,安装顺序不合理的话,会导致后面Web界面无法访问!且记录遇到的一个问题:在没有按照顺序安装组件的情况下,无法登录进入ODL主界面。解决方法是通过logout退出karaf平台,进入bin目录:cd bin,执行./karaf clean,再次重复上面的安装组件操作。

OpenStack对接ODL

清理OpenStack环境:

使用下列命令关闭neutron-server

1
openstack@controller:~$ sudo service neutron-server stop

在OpenStack上所有节点移除openvswitch-agent

1
2
3
4
5
6
7
8
9
10
11
openstack@network:~$ systemctl stop neutron-openvswitch-agent
openstack@network:~$ systemctl disable neutron-openvswitch-agent
openstack@network:~$ sudo rm -rf /var/log/openvswitch/
openstack@network:~$ sudo rm -rf /etc/openvswitch/conf.db
openstack@network:~$ sudo mkdir /var/log/openvswitch/
openstack@network:~$ sudo service openvswitch-switch start
openvswitch-switch start/running
openstack@network:~$ sudo ovs-vsctl show
2c63096f-74f3-46eb-9904-00305ef84106
    ovs_version: "2.5.0"
openstack@network:~$

让每个节点上的ovs连接ODL,没有br-int的话重新新建一个

1
2
sudo ovs-vsctl set-manager tcp:192.168.51.110:6640
ovs-vsctl set-controller br-int "tcp:192.168.51.110:6633"

然后在ODL的界面上就可以显示2个OVS已经连上来了 ODL的网页URL跟氦版本也有所不同 http://$your_odl_ip:8181/index.html 登录名/密码都是admin

image

如果需要上外网的话,需要增加br-ex

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
openstack@network:~$ sudo ovs-vsctl add-br br-ex
openstack@network:~$ sudo ovs-vsctl add-port br-ex eth0
openstack@network:~$ sudo ovs-vsctl show
2c63096f-74f3-46eb-9904-00305ef84106
    Manager "tcp:192.168.51.110:6640"
        is_connected: true
    Bridge br-ex
        Port br-ex
            Interface br-ex
                type: internal
        Port "eth3"
            Interface "eth0"
    Bridge br-int
        Controller "tcp:192.168.51.110:6653"
            is_connected: true
        fail_mode: secure
        Port br-int
            Interface br-int
                type: internal
    ovs_version: "2.5.0"
openstack@network:~$

在Neutron服务节点更改配置

1
2
3
4
5
6
7
8
9
10
openstack@network:~$ sudo vi /etc/neutron/plugins/ml2/ml2_conf.ini
[ml2]
type_drivers = flat,vxlan
tenant_network_types = vxlan
mechanism_drivers = opendaylight 

[ml2_odl]
password = admin
username = admin
url = http://192.168.51.110:8080/controller/nb/v2/neutron

在OpenStack Controller节点重新配置数据库


openstack@controller:~$ source ./admin_openrc.sh 
openstack@controller:~$ mysql -u root -pmysqlpassword
MariaDB [(none)]> DROP DATABASE neutron;
Query OK, 157 rows affected (1.76 sec)

MariaDB [(none)]> CREATE DATABASE neutron;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' IDENTIFIED BY 'NEUTRON_DBPASS';
Query OK, 0 rows affected (0.05 sec)

MariaDB [(none)]> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' IDENTIFIED BY 'NEUTRON_DBPASS';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> exit
Bye
openstack@controller:$ rm -rf /etc/neutron/plugin.ini
openstack@controller:$ ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini
openstack@controller:$ su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron

安装networking-odl

ODL现在已经不用在ml2文件下放入一个python脚本了,目前搞了一个专门的项目叫netwoking-odl,安装一下然后改下配置就可以了。从最新的Neutron代码中,已经发现了诸如原来的opendaylight和其他一些sdn Plugin,已经开始从项目中移除,统一命名为诸如networking-xxxx之类的独立项目。

1
2
openstack@controller:$ yum install python-pip -y 
openstack@controller:$ sudo pip install networking-odl

另一种安装方式如下

1
2
3
openstack@controller:$ git clone https://github.com/openstack/networking-odl -b stable/mitaka
openstack@controller:$ cd networking-odl/
openstack@controller:$ ./setup.py

文档说明安装完成之后才可以启动neutron-server,否则会出现如下的报错,说明OpenStack找不到ODL插件


2017-05-26 22:57:27.434 5518 INFO neutron.common.config [-] Logging enabled!
2017-05-26 22:57:27.435 5518 INFO neutron.common.config [-] /usr/bin/neutron-server version 8.3.0
2017-05-26 22:57:27.436 5518 INFO neutron.common.config [-] Logging enabled!
2017-05-26 22:57:27.436 5518 INFO neutron.common.config [-] /usr/bin/neutron-server version 8.3.0
2017-05-26 22:57:27.454 5518 INFO neutron.manager [-] Loading core plugin: neutron.plugins.ml2.plugin.Ml2Plugin
2017-05-26 22:57:27.756 5518 INFO neutron.plugins.ml2.managers [-] Configured type driver names: ['flat', 'vxlan']
2017-05-26 22:57:27.759 5518 INFO neutron.plugins.ml2.drivers.type_flat [-] Allowable flat physical_network names: ['provider']
2017-05-26 22:57:27.765 5518 INFO neutron.plugins.ml2.managers [-] Loaded type driver names: ['flat', 'vxlan']
2017-05-26 22:57:27.766 5518 INFO neutron.plugins.ml2.managers [-] Registered types: ['flat', 'vxlan']
2017-05-26 22:57:27.766 5518 INFO neutron.plugins.ml2.managers [-] Tenant network_types: ['vxlan']
2017-05-26 22:57:27.766 5518 INFO neutron.plugins.ml2.managers [-] Configured extension driver names: []
2017-05-26 22:57:27.767 5518 INFO neutron.plugins.ml2.managers [-] Loaded extension driver names: []
2017-05-26 22:57:27.767 5518 INFO neutron.plugins.ml2.managers [-] Registered extension drivers: []
2017-05-26 22:57:27.767 5518 INFO neutron.plugins.ml2.managers [-] Configured mechanism driver names: ['opendaylight']
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension [-] Could not load 'opendaylight': No module named opendaylight.driver
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension [-] No module named opendaylight.driver
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension Traceback (most recent call last):
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension   File "/usr/lib/python2.7/site-packages/stevedore/extension.py", line 163, in _load_plugins
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension     verify_requirements,
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension   File "/usr/lib/python2.7/site-packages/stevedore/named.py", line 123, in _load_one_plugin
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension     verify_requirements,
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension   File "/usr/lib/python2.7/site-packages/stevedore/extension.py", line 184, in _load_one_plugin
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension     plugin = ep.resolve()
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension   File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2235, in resolve
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension     module = __import__(self.module_name, fromlist=['__name__'], level=0)
2017-05-26 22:57:27.768 5518 ERROR stevedore.extension ImportError: No module named opendaylight.driver

但是我在CentOS7下安装完了之后还是有上述报错,neutron-server依然起不来
我的默认的ml2 plugins像openvswitch是安装下如下路径下的/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/
而且我的networking_odl安装包已经安装在如下路径下/usr/lib/python2.7/site-packages/networking_odl/ml2/
谷歌了几天之后,得出以下解决方案
我需要把/usr/lib/python2.7/site-packages/networking_odl-2.0.1.dev15-py2.7.egg-info/entry_points.txt
里面的内容合并到/usr/lib/python2.7/site-packages/neutron-8.3.0-py2.7.egg-info/entry_points.txt中,终于neutron-server停止抱怨了
合并完成的entry_points.txt如下


[neutron.ml2.mechanism_drivers]
opendaylight = networking_odl.ml2.mech_driver:OpenDaylightMechanismDriver
opendaylight_v2 = networking_odl.ml2.mech_driver_v2:OpenDaylightMechanismDriver
fake_agent = neutron.tests.unit.plugins.ml2.drivers.mech_fake_agent:FakeAgentMechanismDriver
l2population = neutron.plugins.ml2.drivers.l2pop.mech_driver:L2populationMechanismDriver
linuxbridge = neutron.plugins.ml2.drivers.linuxbridge.mech_driver.mech_linuxbridge:LinuxbridgeMechanismDriver
logger = neutron.tests.unit.plugins.ml2.drivers.mechanism_logger:LoggerMechanismDriver
macvtap = neutron.plugins.ml2.drivers.macvtap.mech_driver.mech_macvtap:MacvtapMechanismDriver
openvswitch = neutron.plugins.ml2.drivers.openvswitch.mech_driver.mech_openvswitch:OpenvswitchMechanismDriver
sriovnicswitch = neutron.plugins.ml2.drivers.mech_sriov.mech_driver.mech_driver:SriovNicSwitchMechanismDriver
test = neutron.tests.unit.plugins.ml2.drivers.mechanism_test:TestMechanismDriver

验证

在OpenStack中创建网络后,执行下面命令


[root@controller ~]#  curl -u admin:admin http://192.168.51.110:8080/controller/nb/v2/neutron/networks
{
   "networks" : [ {
      "id" : "6a678525-2853-419a-8a4e-26a714644cc6",
      "admin_state_up" : true,
      "status" : "ACTIVE",
      "tenant_id" : "93545f587b074e50ad70571e2d9df7a6",
      "name" : "net1",
      "shared" : false,
      "router:external" : false,
      "provider:network_type" : "vxlan",
      "provider:segmentation_id" : "80",
      "segments" : [ ]
   } ]
}[root@controller ~]#

ODL已经可以获取到网络信息 创建2台虚机,可以成功获取到IP地址,并且可以相互访问 image

OpenStack与ODL安装至此就成功了。

参考文档 https://docs.openstack.org/developer/networking-odl/installation.html
https://wiki.opendaylight.org/view/OpenStack_and_OpenDaylight
http://docs.opendaylight.org/en/stable-boron/submodules/netvirt/docs/openstack-guide/openstack-with-netvirt.html#installing-opendaylight-on-an-existing-openstack

实验环境:

首先介绍一下实验环境
系统:CentOS7
CPU:Intel(R) Xeon(R) CPU E5-2630 @ 2.30GHz
Memory:DDR4 1600MHZ 16GB
OVS版本:2.5.0
拓扑描述:
再两台物理服务器上搭建OpenStack计算节点,两台物理服务器之间通过INTEL 100G网卡进行连接,保证物理带宽够用。计算节点上分别启动5台虚拟机,计算节点上面启动着OVS组件,同时虚拟机连接到OVS。
下图是部署在物理服务器上的2台OVS:

image

实验:

首先在OpenStack中每个物理服务器上起5台虚拟机,每台物理机上有5台,通过OVS进行连接,OVS又通过100G链路进行连接。

image

下图是物理的拓扑图,每个OVS下面挂了5台虚拟机,为了可以使得OVS可以满负荷运载

image

再5对虚拟机上使用IPERF进行打流,即跨物理机的5对同时打流

image

通过TOP命令观察物理服务器的资源消耗,下图得出资源消耗率比较低

image

下图是在OVS上面下发的流表,可以使得2台OVS上面的5对虚拟机可以顺利通信

image

以下就是打流的最终结果了,使用IFTOP命令观察物理服务器上面的所有流量,可以看到5对虚拟机分别的流量,以及最后的流量的总和,可以看到OVS的流量可以达到30G以上。

image

总结:OpenvSwitch使用了2.5.0版本,可以看出在吞吐量上面已经可以轻松达到30G以上,这对于云计算的组网来说已经是比较高了,因为目前物理链路大部分还是10G的链路。

OpenStack Boston Summit Day1 Keynote

2017年波士顿OpenStack Summit在Hynes会议中心如期举办

image

Keynote会场

image

下面是本次峰会的主要赞助商

image

Keynote简述

这次的峰会主题重点从周一上午的Keynote中就可以看出,这次的Keynote一开始就强调了私有云(Private Cloud)的重要性,以及公有云和私有云之间的对(si)比(bi)。不像之前大家都在讨论公有云那样,这段时间大家都开始把自己的业务迁移到了自家建的私有云中。Keynote的后半部分强调了容器和谷歌的K8S的技术前景和Ebay在容器技术方面的实践,也阐述了今后技术演化的路线。

Keyword: Private Cloud、OpenCloud、Containers
接下去是各家厂商及用户的一些分享:
image

GE

然后GE的人就上来强调了GE有多少业务迁移到了自家的私有云中
接着给出了以下的一些数据
530 applications migrated to cloud
42% applications in cloud
Shared automation strategy across public&private
image

US Army

US Army强调了OpenStack在减少开支方面的主要作用,OpenStack在 他们的教育系统“Education with agile development”方面减少了很多开支,而且使得教育方式变得十分灵活高效。而且把业务迁移到了OpenStack之后可以帮助他们确实的减少开支
image

Mirantis

接下去是mirantis公司说出了一些担忧,public cloud把大家的注意力都吸引走了,但是真正的要建设一个opencloud的大环境,需要private cloud的成功。AWS的提及,以及要建立一个真正的opencloud是由public cloud垂直的自顶向下的设计,而不是一个企业软件的缝缝补补。
image

AT&T

接下去是AT&T的director的topic,他们的重点是“Next generation video platform,AT&T”他们也会更加关注更多业务层方面的东西,当然他们也在使用OpenStack作为重要的IaaS层。

Ebay

Ebay首先说了他们对基础设施的要求,因为他们的业务量也很大,他们引入了Docker,Kubernetes等新的技术。首先他们的k8s是powered by openstack,他们喜欢opensource
“Managing k8s at scale”是他们的目前主要工作。
image

Redhat

Redhat是openstack峰会的元老,先是强调了一下openstack以及取得的巨大成果,以及介绍了redhat的openstack用户,和帮助这些用户们取得了巨大的进步, “innovation evolution” 和“openstack+containers”已经成为今后的技术方向。

基本上从第一天的Keynote上就可以看出整个OpenStack社区的关注点和技术发展的趋势,以及用户对开源社区提出了哪些新的需求。无疑,容器和Kubernetes正在成为新宠儿。

OpenStack Boston Summit Day2 Keynote

第二天的Keynote由OpenStack的CO-Founder Mark Collier来主持,第二天简直就是Kuberneters的Keynote了,上来的演示几乎都要展示一个Kuberneters的界面。而提到架构也是OpenStack上面就是Kuberneters了,见下图。
image

Ironic的一个演示,由IBM来进行演示,先是通过Baremetal来启动各种OpenStack服务。其中多次提到了编排层通过Kuberneters来进行编排服务。由OpenStack来提供IaaS层,再由Kuberneters来进行对容器的编排。

image

接下去是mirantis的演示,是一个Bigdata analydemo通过容器的形式,由Kuberneters来进行编排。也是通过Baremetal的环境来进行演示。

Intel推了他们的“clear containers”,也是准备在容器的层面发力。他们也强调了他们的芯片设计,如何对OpenStack有更好的贡献,Intel还强调了与华为的一个BugSmash的合作,在国内也是颇有影响力。
image

Google Cloud CTO进行的分享是“开源”的话题,谷歌也在变得越来越开源,还提到了AI技术,几年前觉得AI是20年以后的事,但是科技的发展已经变得越来越迅速。机器学习可以解决问题,而且也是开源的,非常的有价值。
image

COREOS说了一个cloud native的数据库 CockroachDB,这个数据库主要是为了解决mysql等传统数据库的扩展性,他们把CockroachDB部署在了多个Kuberneters的node上面,然后把一个node上面的CockroachDB关闭然后重启,再观察这个cluster的功能,其中CockroachDB在Kuberneters上面还有realtime的界面,可以对数据库的问题有更好的定位。
image

Open Telecom Cloud强调了混合云的需求
Clould business will go hybrid
Openstack has consistent success private cloud
并强调了要使得混合云成功,需要各家厂商使用相同的接口
image

第二天最大的惊喜莫过于请来了斯诺登来讨论安全了,当斯诺登提到当用户把虚拟机和数据放在AWS或者其他的一些公有云上,怎么能够确定他们没有在监视你呢?还说了一写关于安全的更深层,更人性的一些问题,这里就不具体展开了。不过可以深切的感受到OpenStack对于开源,对于科技,对于人文的精神的理解。
image

希望下次可以温哥华见

GDB概述

GDB是GNU开源组织发布的一个强大的UNIX下的程序调试工具。或许,各位比较喜欢那种图形界面方式的,像VC、BCB等IDE的调试,但如果你是在UNIX平台下做软件,你会发现GDB这个调试工具有比VC、BCB的图形化调试器更强大的功能。所谓“寸有所长,尺有所短”就是这个道理。

一般来说,GDB主要帮忙你完成下面四个方面的功能:

  • 启动你的程序,可以按照你的自定义的要求随心所欲的运行程序。
  • 可让被调试的程序在你所指定的调置的断点处停住。(断点可以是条件表达式)
  • 当程序被停住时,可以检查此时你的程序中所发生的事。
  • 动态的改变你程序的执行环境。

从上面看来,GDB和一般的调试工具没有什么两样,基本上也是完成这些功能,不过在细节上,你会发现GDB这个调试工具的强大,大家可能比较习惯了图形化的调试工具,但有时候,命令行的调试工具却有着图形化工具所不能完成的功能。让我们一一看来。

启动程序

1

找到对应需要寻找的函数

1

打断点

1

启动程序run

1

退出程序

1

Backtrace 查找堆栈

1

l查看下面的代码

1

next

1

continuing

1

查看断点

1

删除断点

1

打印变量

1

打印功能

1