背景介绍

OpenFlow中的信息有很多种,以of13_msg_features_request为例,
原先在每个SW上起两个线程,一个接收,一个发送

1
2
3
//by:yhy 创建收发线程
pthread_create(&(sw->pid_recv), NULL, msg_recv_thread, (void *)&(sw->index));
pthread_create(&(sw->pid_proc), NULL, msg_proc_thread, (void *)&(sw->index));

这个是交换机中定义的结构体



typedef struct gn_switch
{
    UINT1 ofp_version;
    UINT1 state;						//标记Switch是否启用
    UINT1 pad[2];
    INT4 index;
    UINT8 dpid;							/* 数据通路唯一的 ID。低 48-bits 是 MAC 地址,高 16 位是开发者定义。 */
    UINT4 sw_ip;			
    UINT4 sw_port;
    UINT4 sock_fd;						//by:yhy 本交换机的socket连接句柄
    UINT4 n_buffers;					/*一次缓冲最大的数据包数。 	*/
    UINT4 n_tables;						/* 数据通路支持的表数量。 	*/
    UINT4 n_ports;						/* 交换机端口数量			*/
    UINT4 capabilities;					/* 位图的支持"ofp_capabilities". */
    switch_desc_t sw_desc;				//交换机的描述信息
    gn_port_t lo_port;					//by:yhy  Local openflow "port"
    gn_port_t ports[MAX_PORTS];
    neighbor_t *neighbor[MAX_PORTS];	//by:yhy 数组neighbor的索引与ports的索引匹配,neighbor[a]即为ports[a]的邻居节点
    mac_user_t **users;
    msg_driver_t msg_driver;
    buffer_list_t recv_buffer;			//by:yhy 接收缓存
    UINT4 send_len;
    UINT1 *send_buffer;					/*长度:g_sendbuf_len*/
    gn_flowmod_helper_t flowmod_helper;
    gn_flow_t *flow_entries;			//by:yhy 本交换机流表
    gn_meter_t *meter_entries;
	INT4 qos_type;
	gn_qos_t* qos_entries;
    gn_group_t* group_entries;
	gn_queue_t* queue_entries;
    pthread_mutex_t users_mutex;
    pthread_mutex_t send_buffer_mutex;
    pthread_mutex_t flow_entry_mutex;
    pthread_mutex_t meter_entry_mutex;
    pthread_mutex_t group_entry_mutex;
    pthread_t pid_recv;   				//by:yhy 接收线程pid
    pthread_t pid_proc;   				//by:yhy 处理线程pid
    UINT8 connected_since;
    UINT8 weight;         //sw_weight
    UINT1 sock_state;     //socket status  判断当前线程是否拥有操作的权利"0"有效
    pthread_mutex_t sock_state_mutex;
}gn_switch_t;

但是在每个包的处理过程中,会占用sw结构体中的buffer,并且每个包在存的时候都会加锁

1
2
3
4
5
6
7
8
static INT4 of13_msg_features_request(gn_switch_t *sw, UINT1 *fea_req)
{
	LOG_PROC("OF13", "of13_msg_features_request -- START");
    UINT2 total_len = sizeof(struct ofp_header);
    init_sendbuff(sw, OFP13_VERSION, OFPT13_FEATURES_REQUEST, total_len, 0);
	LOG_PROC("OF13", "of13_msg_features_request -- STOP");
    return send_of_msg(sw, total_len);
}

这个是init_sendbuff的函数,把header中的数据写到sw结构中的buffer中


//初始化发送缓存
UINT1 *init_sendbuff(gn_switch_t *sw, UINT1 of_version, UINT1 type, UINT2 buf_len, UINT4 transaction_id)
{
    UINT1 *b = NULL;
    struct ofp_header *h;

    pthread_mutex_lock(&sw->send_buffer_mutex);
    if(sw->send_len < g_sendbuf_len)
    {
        b = sw->send_buffer + sw->send_len;
    }
    else
    {
        printf("........\n");
        write(sw->sock_fd, sw->send_buffer, sw->send_len);
        memset(sw->send_buffer, 0, g_sendbuf_len);
        sw->send_len = 0;
        b = sw->send_buffer;
    }

    h = (struct ofp_header *)b;
    h->version = of_version;
    h->type    = type;
    h->length  = htons(buf_len);

    if (transaction_id)
    {
        h->xid = transaction_id;
    }
    else
    {
        h->xid = random_uint32();
    }

    return b;
}

这个是send_of_msg函数,把消息的total_len加上去,然后解锁,最后通过交换机的发送线程发送 //发送openflow消息(解锁switch的发送缓存,具体发送在发送线程中执行)

1
2
3
4
5
6
7
INT4 send_of_msg(gn_switch_t *sw, UINT4 total_len)
{
//    INT4 ret = 0;
    sw->send_len += total_len;
    pthread_mutex_unlock(&sw->send_buffer_mutex);
    return GN_OK;
}

重构后:

思路,把消息进来存的buffer和sw解耦,sw的buffer每次只能被一个消息所占用,很影响效率,改动后如下,每次给一个包分配一个msgbuf,等写完之后,全部扔给sw_buffer,从而提高性能

1
2
3
4
5
6
7
8
static INT4 of13_msg_features_request(gn_switch_t *sw, UINT1 *fea_req)
{
    Msg_Buf(struct ofp_header);
  
    UINT2 nLen = sizeof(struct ofp_header);
    init_header(pMsg,OFP13_VERSION,OFPT13_FEATURES_REQUEST,nLen,0);
    send_packet(sw, msgbuf, nLen);
}

重构init_header,把header中的数据封装


void init_header(struct ofp_header *p_header,UINT1 of_version, UINT1 type, UINT2 len, UINT4 transaction_id)
{
	p_header->version = of_version;
	p_header->type = type;
	p_header->length = htons(len);
    if (transaction_id)
    {
        p_header->xid = transaction_id;
    }
    else
    {
        p_header->xid = random_uint32();
    }
}

细节改动:

在common.h中加入
创建一个msgbuf给每个消息10K的大小的一个buffer,并初始化

1
2
3
4
5
6
#define MSG_MAX_LEN  10240
#define Msg_Buf(msgtype) \
    char msgbuf[MSG_MAX_LEN];\
    memset(msgbuf, 0, sizeof(msgbuf));\
    msgtype* pMsg = NULL;\
    pMsg = (msgtype*)msgbuf;

在conn-svr.h中加入


INT4 send_packet(gn_switch_t *sw, INT1* pBuf, UINT4 nLen);
void init_header(struct ofp_header *p_header,UINT1 of_version, UINT1 type, UINT2 len, UINT4 transaction_id);

在conn-svr.c中加入
直接将msgbuffer扔给sw_buffer处理

1
2
3
4
5
6
7
8
INT4 send_packet(gn_switch_t *sw, INT1* pBuf, UINT4 nLen)
{
    pthread_mutex_lock(&sw->send_buffer_mutex);
    memcpy(sw->send_buffer + sw->send_len, pBuf, nLen);
    sw->send_len += nLen;
    pthread_mutex_unlock(&sw->send_buffer_mutex);
}

问题

Openstack Mitaka版本,终止了云主机之后,发现无法删除对应的云硬盘,删除提示报错为云硬盘的状态不是错误或者可用状态 image

思路

1 切换至admin用户,进入数据库手动更新云硬盘的状态至错误状态
2 针对lvm,可以用命令lvdisplay列出所有卷的信息,如果现在应用命令lvremove来删除相应的卷,则会提示要删除的卷正在使用中,所以我们使用命令lsof查看相应卷所占用的进程,然后kill这个进程;
3 应用命令lvremove来删除相应的卷.
这里只针对第一种方法实践

操作

查看云硬盘状态:

1
cinder list | grep error  

image

命令行删除,提示报错说还有依赖的快照

cinder delete XXX

1
2
3
Delete for volume XXX failed: Invalid volume: Volume still has 1 dependent snapshots. (HTTP 400) 
(Request-ID: req-5ba025fb-5a61-422b-b00a-556e19083bd5)
ERROR: Unable to delete any of the specified volumes.

image

方法有很多,这里介绍一种简单的。采取暴力手段,进入元数据库。

image

show databases;

image

use cinder;

show tables;

image

select找到出错的数据

image

删除元数据库中的数据,不过不能简单得把这个cinder盘的数据删除,以为数据库有外键依赖,而是要把cinder盘的error—deleting改成deleted

image

再次查看云硬盘状态:
image

发现已经成功得删除了出错的cinder盘

总结:
1、删除的时候注意id和volume-id两个字段,不要弄混掉了; 2、测试环境,暴力解决问题还是不太好,注意检查日志来对症下药。
3、不要简单得去删除表中数据,而是需要更改状态

简述

第三、四天的峰会基本上厂商的Presentation都差不多结束了,重点都放在Design Summit上面了。这样也提供了很好的机会跟开发者面对面进行交流。因为有些议题比较庞大,所以今天还是有一些分享,比如热门的老牌项目Nova以及Neutron,这两个项目基本上改一个的话另一个也需要改动。在新兴的项目Docker,k8s等跟OpenStack进行结合,但是因为这些项目讨论的余地还是比较大的,所以到了第三天仍有不少的Presentation。由于Neutron这个项目的特殊性,基本上需要跟很多项目挂钩,比如与容器的网络对接,与上层的网络管理的项目的API等对接。网络除了功能以外还有性能的问题,一些厂商也提供了一些提高性能的解决方案。

1.虚拟机疏散

虚拟机的疏散问题很早之前就已经被反复讨论了,这次峰会也不例外。虚拟机疏散就是虚拟机跑在Hypervisor上,如果Hypervisor挂掉之后需要将虚拟机疏散到正常的compute节点之上。这个问题看似简单,这次峰会很多discussion都是关于这个问题或者是提到了这个问题。因为讲虚拟机疏散这个指令发起之后,调度器就要检查有没有多余的硬盘资源,计算资源以及网络资源。需要三个资源都被确认OK之后,才可以被转移。但是由于OpenStack系统是动态变化的,当三块资源被确认之后,如果用户又创建了一些虚拟机,那么就可能导致疏散的虚拟机得不到某一个足够的资源,从而导致迁移失败。另一个重要的问题时社区在讨论疏散的“undo”功能,即一旦疏散失败或者之前宕掉的compute节点恢复之后怎么把疏散的虚拟机由重新迁移回来。以上说的都是比较粗略的,具体涉及到迁移的虚拟机的mac地址是否需要变化,在混合云的迁移的不同的hypervisor等情况还是很难解决的。

2.提高Neutron网络的扩展性

由于现在的Neutron网络都是虚拟机连在虚拟子网或者vlan子网上,子网与子网之间通过vxlan或者gre等三层网络技术进行连接的,但是这样的网络架构对于网络的扩展性来说却是不利的,当网络上了规模之后Neutron的瓶颈就出现了。基本上目前使用社区版的网络,高可用部署,VRRP的网络冗余方案只能支持数百台服务器的规模,当OpenStack的规模到了很大的程度,则必须想到对策解决扩展性的问题。

image

IBM的一个silde就提到传统neutron的问题
These network become complex at largr scale
Also have large failure domains

就是在二层的网络中再加上一个segment头部标志,把每一个物理机架作为一个segment,这样网络的规模变的非常大的时候,对每一个机架的segmenet都可以进行很好的管理,同一个segment的网络是具有路由功能的,而不是之前的网络的单纯桥接方式。

image

他们提出了新的网络架构,现在已经被merge到Newton版本中了

image

3.Dragonflow

华为的dragonflow团队正在研究BGP的问题,以及跨数据中心的网络控制,其中的mac地址变换,以及虚拟机从一个数据中心迁移到另一个数据中心等问题进行了研究,以及对这个虚拟机配置的security group在迁移到另一个数据中心是否生效等问题。在控制不同的数据中心时候对不同的数据中心中的每个虚拟机都需要知道怎么路由或者进行l2的转发,在最后一天的discussion中针对以上的问题进行了讨论。

image

在Okata版本中的计划如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
PLAN:
Deployment
Kolla
Ansible +1+1
Puppet +1+1
Troubleshooting Tools
North Bound database changes
subnets to have their own table, and not part of lswitch (Networks)+1
IPv6+1
SFC+1+1
Distributed Load Balancing+1
BGP advertising for dynamic routing +1+1+1+1
Distributed DNS+1
Multicast and IGMP
Is there a viable use case for multicast in the overlay network?
Backend Drivers
eBPF+1
P4
Migration from ML2/OVS ?
Dragonflow API Layer 
TAP as a Service
VLAN Aware VMs
Distributed NAT+1

在第三天的discussion中把dragonflow的测试报告也公布了出来

image

image

image

对于Neutron来说则是有很大提升的,dragonflow也是目前做对接OpenStack做的最好的。我司也在做一个对接OpenStack的控制器,名称为DCFabric

4.Okata Road Map

Okata版本基本上的roadmap也出来了,社区做了一个session是讲各个项目的下个版本的计划

image

image

image

由于我比较关注网络方面,因此大部分都是网络。其实4天听下来网络的问题是最多的,加入向Docker等虚拟化技术对Nova的影响远远没有网络影响大,而且在规模大了之后,网络的延迟的吞吐量也是很值得关注的,而且Neutron作为OpenStack必须部署的组件之一,关键程度不言而喻。因此网络的问题也是社区放了很多力量在上面。下次的OpenStack版本是Okata,希望可以波士顿见~

简述

第二天的峰会先是在大会场中进行Keynote的介绍。中国移动的出场率比较高。作为世界上最大的移动电话的服务商,已经率先使用OpenStack了。混合云正在成为今后企业云形态的主流,在Best practice的session里面大会也在强调企业正在不断得推进OpenStack,容器和k8s也占有会议的一席之地,在越来越多的企业加入进来之后,安全问题也被提上议程。

1

KEYNOTE

1.The future is Multi-Cloud

What is mutil-cloud look like?
大会花了很长的时间来介绍他们的CI/CD system
World’s lagest mutil-cloud is CI/CD system
1.7 million test jobs every day
10-20k vms per day
gerrit/zuul/nodepool
2000+ jobs per hour
5000 PB every two day
社区正在帮助更多的企业参与到OpenStack中。其中一个Demo是把OpenStack的虚拟机传到AWS上,这个Demo也是很符合今天Multi-Cloud的主旨

2.Best Practice Share

IBM也在向云转型,投入了很大的精力
What proving “interop” means for the ecosystem?
Materna acts a s service provider
Materna acts as software developer
Materna acts as trusted advisor/platform designer

Why head for OpenStack?
Scalability
Speed
Cost
Interoperability

platform9 system做了一个关于为什么他们的商务伙伴选择OpenStack的调查。OpenStack的标准化的API这个优势是最多企业选择的

2

3.Containers in bare metal

容器技术的重要在本次峰会中又被再一次的验证了
嘉宾分享关于容器的技术

Challenges
KVM
Cost
Bootstrapping
Small Team

Advantage
bare Metal
perfomance
cost effective
fast deployment

Containers
give control back to developers
simple bootstrapping
safe deployments
mix match stacks

在昨天很多关于容器的分享中,今天的keynote又提到了很多容器技术,Kolla,Magnum作为一个社区的明星项目,也是社区正在发力的地方,在分享中k8s的使用频率比其他的mesos等容器管理技术高。

3

社区正在攻克Magnum的网络层面。即使用Neutron网络对容器的网络进行管理。社区提到了容器的不同部署方式的管理,即针对Docker的bare metal和容器跑在虚拟机中这两种部署方式,Magnum都会一视同仁得对容器进行管理,以及对网络层面进行不同方式的连接。

Magnum的小组讨论也是最激烈的

8

4.Hackthon

Hackthon也是社区正在力推的一个活动,Hackthon帮助更多的人参与到社区里面,对项目提出意见贡献代码等。也是因为更多的人拥有开发OpenStack的能力,所以社区推出的OpenStack的认证也是水到渠成。

Design Summit是今后峰会的亮点,也正式与之前的Hackthon和OpenStack认证一脉相承,社区正在鼓励大家对OpenStack出谋划策。

4

分会场:一些有趣的特性

网络层面富士公司对于DVR网络的防火墙问题,另外对于Neutron的网络难于troubleshooting的问题做了“neutron logging”地项目

5
6
7

OpenStack社区也在积极得向Opendaylight社区以及OPNFV社区合作,也符合OpenStack的“big tent”的一贯作风

9

简述

由于本文介绍重点主要是以一个技术人的角度去观察OpenStack的下一个重点和趋势在哪里,由于会场太多分身无术。文章就重点介绍一些热门度高的和社区投入精力大的项目。通过阅读本文也可以了解到OpenStack在全球的重要的应用场景和开发的重点。由于时间匆忙,一些句子仍然使用英文。

2016年峰会在美丽的巴塞罗那举行,地点在巴塞罗那会议中心

cert

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

cert

上午的会议是在”TED”风格的演讲厅中进行的。开头主要是介绍的OpenStack的新版本”Newton”,新版本还是围绕以下四个主题展开。
open source
open community
open development
open design

cert

然后介绍了一个由OpenStack官方认证的一个证书。大会的前两天是对于这个证书的一个培训以及介绍如何通过这个认证的测试。

cert

正文

介绍主要分为4个部分

1.Enterprise Big Data

介绍了一个企业拥有16.6 million client,其中banking users 6.9 million,面向金融客户。 banking clients is facing a changlenge,金融客户在传统的IT架构中正在面临越来越大的挑战。 而OpenStack的以下优势正好可以满足金融客户的需求。
automation
open source hybrid approach
real time and big data analytics
good engneering work
big data was enabled in our openstack cloud

2.Media Broadcasting

分享企业:SKY UK
Why SKY runs on openstack?
cost
speed of delivery
flexible
software defined
400tb CEPH

分享企业:Huawei
huawei fusionsphere
taking openstack to industries
tier goverment cloud enables service sharing tech
应用客户:江西省信息中心、东风汽车公司

3.Telecom/NFV

分享:svp system的视频通话的Demo
openstack实实在在得给运营商提供了好处unlock the public cloud potential of openstack openstack也正在成为云的一个标准openstack as the opensourec cloud standard 运营商面临一个更加严峻的挑战,即使高可用因为运营商的云can not fail

4.Scientfic Research

分享研究所:欧洲原子能机构
largest machine in CERN
a lot of pyscics
160pb store in CERN
5000 vm migrated in 2016
containers on cloud
Magnum in the future

分享研究所:澳大利亚天文所
ska data process 澳大利亚
ska deep look in unverse

分享研究所:剑桥大学: openstack in health care
bio medical cloud(big data的处理是优势)
lager scale NGS sequencing & analytics
medical imaging @ wolfson brain imaging centre
the challenges of science
HPC:cloud for science

分会场

OpenStack社区正在力推他们自己官方的认证,所以这次峰会特地开了一个track是关于怎么提交bug和贡献代码的

cert

Ceph正在成为OpenStack中呼声最高的后端存储方案,几乎客户都是使用Ceph的 cert

Docker也是大家都争先恐后对接的新技术,Google的kubernetes管理docker的使用率最为普遍

cert

基本上从第一天就可以看出社区的走向和各个项目的趋势,是被废除的概率高还是被用户越来越多的使用等情况。第二天准备去Design Summit跟deverloper做一些交流。