Friday, August 22, 2014

修改OpenStack中的vlan tag

在OpenStack中,用户网络的隔离可以用vlan、gre或者最新的vxlan来支持。
其中vlan模式目前是较为成熟和普遍的一种。
在vlan模式下,用户的vm流量在抵达openvswitch的时候,会被分配一个vlan id。相同vlan id的vm是互相可见的,不同的是彼此隔离的。
有时候,我们需要去手动修改这个vlan tag来完成一些诊断或测试工作。
首先,可以通过如下的命令来直接修改openvswitch端口上的vlan tag。
ovs-vsctl set port PORT_ID tag=xx
此时,查看端口的tag,确实已经被修改过了。
但是这样修改后,一旦发生流量,本地的ovs-agent会进行检查,发现不一致后会强行再同步回来。
因此,如果想要让修改能保持住,需要修改db中的记录信息。
在ovs_neutron表中,我们能看到有个ports子表,这张表记录了端口的信息,包括该端口上所应该对应的网络id。
如果想让某个端口的vlan tag跟另外一个端口的一致,只需要修改它的network_id为另外一个端口的network_id即可了。
那么,网络到vlan的tag的映射关系是存在哪里呢?
我们可以找到另外一个子表ovs_network_bindings,这里面记录了每个网络和所对应的分片信息。
vlan的tag,一般会跟segmentation_id保持一致。

最后,为了避免出现错误,最好还要更新subnets子表,这里面记录了每个subnet是属于那个network的。我们需要把自己端口所在的subnet更新到新的network上去。

注意,这样修改过之后,OpenStack会认为这个端口已经挂载到另外一个网络上了,在网络拓扑中会显示修改后的结果。

在OpenStack中绕过或停用security group (iptables)

目前,OpenStack中默认采用了security group的方式,用系统的iptables来过滤进入vm的流量。这个本意是为了安全,但是往往给调试和开发带来一些困扰。
因此,临时性的禁用它可以排除因为iptables规则错误问题带来的网络不通等情况。
在H版本中,可以通过修改neutron plugin.ini中的firewall配置来禁用security group。
但在I版本中,类似的操作只会让vm出来的流量都无法通过安全网桥。
因此,在正常配置启用security group的情况下,我们需要想办法来让流量绕过它。
通过《深入理解OpenStack中的网络实现》中的分析,我们知道,从vm出来的流量被过滤的规则在 neutron-openvswi-o9LETTERID链上,而到vm里面的规则在neutron-openvswi-i9LETTERID链上。
因此,我们只需要对应在链上添加允许通过的规则即可。
首先,查看vm出来的安全规则链上的规则
iptables -nvL neutron-openvswi-o9LETTERID
一般情况下,类似于下面几条
Chain neutron-openvswi-o4430511a-6 (2 references)
 pkts bytes target     prot opt in     out     source               destination        
    6  1968 RETURN     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:68 dpt:67
 1437  121K neutron-openvswi-s4430511a-6  all  --  *      *       0.0.0.0/0            0.0.0.0/0          
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:67 dpt:68
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
  278 23352 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
 1159 97356 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0          
    0     0 neutron-openvswi-sg-fallback  all  --  *      *       0.0.0.0/0            0.0.0.0/0     
可见,默认允许通过的流量只有源端口为67而目标端口68的dhcp请求流量,另外就是neutron-openvswi-s4430511a-6链中,会对源地址和源mac进行检查,如果跟分配到的一致,则允许通过。
例如,我们让所有的ping包(不管源地址和源mac)都允许从vm发出来,则需要添加
iptables -I neutron-openvswi-o9LETTERID -p icmp -j RETURN
更简单粗暴的,允许所有的从vm出来的流量,不进行任何检查,则需要添加
iptables -I neutron-openvswi-o9LETTERID -j RETURN

需要注意的是,这样添加的规则,不在neutron的维护中,因此,过一段时间后会被清理掉,这时候就需要重新添加。

Tuesday, August 19, 2014

云时代的编程——从计算模型演化看编程模式发展

从有计算机开始,计算模型先后经历了专业(大小型)机-->pc-->网格计算-->云计算的过程。【注】暂不考虑一些专业领域的计算机器演化。
而编程模型,也由底层的纸带-->汇编-->面向过程编程-->面向对象编程的过程。
随着云计算的进一步发展,特别是paas的发展,编程的环境、库都可以以服务的形式来动态提供,即演变为“编程即服务”模式。
在这种模式下,程序员能获取的资源已经不是以库的形式存在,而是服务组件,即每个组件会实现某些高级的业务功能。
以前,比如我们要编程实现一个web应用,我们需要有网络库、认证库、web服务器库等等的支持,开发大量的代码。
而在云时代,我们直接可以获取各种现成的web组件,就像搭建积木一样把它们拼凑在一起就可以实现自己所需要的功能了。
之前,我曾认为编程模型,从面向过程到面向对象,后面一定会演化到更进一步的面向目的。
而云时代的编程模式已经有了面向目的的雏形。更进一步的,开发者只需要定义好清晰的业务逻辑和模型,AI引擎会自动拼接各种服务组件,完成程序的构建。真到了那个时候,计算机的能力才会更进一步的被释放出来,各种产业也会面临新的变革和机遇!