owncloud 配置openstack对象存储作为外部存储

 openstack  owncloud 配置openstack对象存储作为外部存储已关闭评论
3月 122018
 

本人使用的owncloud版本号: 8.2.8

第一步:

使用admin账号在“管理”部分开启外部存储配置:

第二步:

在任意账号(也可以是管理员账号)配置外部存储:

 

注意:

  • 这里支持的keystone协议版本号只能是v2.0 的,不可配置,所以Identity URI 类似于: http://openstack-controller:5000/v2.0/
  • 其中的swift就是对象存储服务的名字,可以通过openstack endpoint list查到
  • 其中的test(bucket)就是openstack中对象存储部分创建的一个容器的名字,当然,如果没有预先创建的话,会自动创建的,所以,你可以随便写

 

问题:

  • 只要openstack对象存储中的容器被owncloud挂载过,容器根目录就会出现一个名字为 “.” 的文件,该文件在owncloud中看不见的,在openstack-dashboard中可以看见,但是删除总失败,而且,如果不删除该文件的话,容器也是删除不了的; 测试发现,openstack-dashboard中是创建不了一个名字叫做”.” 的目录的,相关issue: https://github.com/owncloud/core/issues/7191
    • 解决办法:
      • 通过openstack命令删除 “.” 文件:
      • end
    • 总结:这里似乎暴露了两个问题:
      • owncloud为什么要创建一个 “.” 文件,真的有必要吗?而且,就算是把 “.” 文件删除掉了,只要owncloud一访问,该文件就又出现了,暂且不太影响,pass
      • openstack-dashboard为什么就删除不了 “.” 文件,应该是个bug吧

 

owncloud + openstack 对象存储的好处:

  • 给owncloud找了一个可靠的存储
  • 给openstack对象存储找了一个比较好的前端
    • 可以通过浏览器直接访问
    • 也可以通过webdav的方式直接mount到各种操作系统和终端(windows、linux、手机端等)
      • linux 上mount,eg:

参考:

 Posted by at 下午 2:37

gnocchi-api 访问慢的问题

 openstack  gnocchi-api 访问慢的问题已关闭评论
1月 112018
 

gnocchi-api 访问基本在10s +, why ?

gnocchi-api 使用了 wsgiref , wsgiref 使用了 :

/usr/bin/gnocchi-api:

/usr/lib64/python2.7/wsgiref/simple_server.py :

(这里提到了个REMOTE_HOST的环境变量,含义就是“REMOTE_ADDR 对应的域名”, 而 address_string() 的命名也是ip地址对应的域名的意思,因为绝大部分的ip地址是反解不到域名的,所以,这个逻辑基本可以注释掉,不过,直接修改人家的代码不大好)

然而上面的 WSGIRequestHandler 基本上会执行到get_environ() , 进而执行到 BaseHTTPServer.py 中的 self.address_string() ,如下:

address_string() 函数又调用了 /usr/lib64/python2.7/socket.py 中的 getfqdn(), 如下:

然后就肯定会执行到gethostbtaddr() 了,该函数的具体实现又是什么逻辑呢? socket.py import了 _socket 模块中的所有函数,而gethostbyaddr()正是_socket 模块实现的,_socket 模块的实现见: /usr/lib64/python2.7/lib-dynload/_socketmodule.so , 可见,这是一个c实现的so文件,稍后再看:

 

测试发现,该函数当遇到IP地址时,肯定会做一次反向地址解析,反向地址解析不是所有dns都能支持的很好的,有些能快速返回,有些却不能(具体原因,稍后再查),比如: 公网地址的反向地址解析可以很快返回,私网地址的反向地址解析就很慢

 

解决办法:

办法一: 在 dns 上给自己的IP地址添加反向地址解析,这样反向地址解析就可以很快; 给每个IP地址都添加反向地址解析的话,比较麻烦,最好能有一个更好的办法,让某一类IP地址能直接返回错误,或返回一个自定义的域名; 这个办法的优点是: 不需要修改程序 ; 如果搞不定dns,那就修改程序吧

办法二: 修改/usr/lib64/python2.7/BaseHTTPServer.py  ,在 address_string() 中直接返回host,而不进行socket.getfqdn(host) 的调用

办法三: 修改 /usr/lib64/python2.7/socket.py 中的 getfqdn() 函数,对于ip地址的情况,不再调用 gethostbyaddr()

办法四: 其实,不是特别有信心的话,不要修改的太底层,没准儿影响到别的程序的; 更好的办法是:

在 /usr/bin/gnocchi-api 中wss.make_server(…) 时,提供了三个参数,还有两个参数是可以定制的,我们可以自己在 /usr/bin/gnocchi-api  中实现一个 MyWSGIRequestHandler ,继承自./simple_server.py 中的WSGIRequestHandler , 然后覆盖其中的address_string() 方法即可

 

按照办法四 修改后的 /usr/bin/gnocchi-api 如下:

 

测试发现,访问确实快多了,不再感觉到延迟了

 Posted by at 上午 11:56

docker on openstack

 docker, openstack  docker on openstack已关闭评论
12月 142017
 

场景,用docker做开发用的虚拟机,每个docker都有一个可以公开访问的IP地址。

由于docker和宿主机共享内核,一不小心可能会把整个宿主机搞挂,而且,docker热迁移也是个难题,所以,尽管openstack马上可以支持docker,我也不想让docker直接部署在计算节点;我的思路是,将docker部署在openstack管理的kvm虚拟机上,这样还能通过热迁移kvm的方式将容器迁移到别的计算节点。

 

注意事项:

  1. 关闭openstack的端口安全
  2. 热迁移后容器的IP地址在交换机上的mac地址与端口的映射不能及时更新
    1. 如果容器频繁地和外部通信的话,mac地址与端口的映射会被及时刷新
    2. 如果没能及时刷新的话,可以在与容器IP同网段的机器上,先clear一下arp缓存,在ping 一下容器IP,就可以了;
    3. 如何自动处理呢?在kvm虚拟机上(就是容器的宿主机上),docker exec到容器内部,然后ping一下网关就行。
 Posted by at 下午 2:01

vxlan 问题排查

 openstack  vxlan 问题排查已关闭评论
12月 042017
 

现象:

openstack中创建的vpc网络中,虚拟机不能dhcp到IP地址,抓包分析如下:

这是openstack控制节点的网络相关信息,问题是: vxlan-60中一个虚机想要通过dhcp获取IP地址,现在dhcp的数据包可以通过eth0到达brqce4d2a54-44,抓包可以验证 :

但是vxlan-60上却抓不到dhcp数据包:

我觉得,到达了 brqce4d2a54-44 的vxlan数据包,如果vxlan id是60就直接转给vxlan-60 就是了,还可能被哪里的规则给拦截?问题都定位了这地步了,应该问题就出现在openstack-controller身上吧?不应该和其它机器有关系吧?(我不断祭出bridge fdb、brctl、ip等工具,浪费了有半天的时间)

后来,在我都试图想重启openstack-controller的时候,我决定分别在两个compute上创建两个机器,如果两个机器之间能够通信,则说明openstack-controller 的问题,否则,就不是openstack-controller的问题; 测试发现,两个机器不能通信,我才把重点放在了compute节点;

compute节点网络架构:

话说,这个网络和官方指导架构或者书本上指导的架构都不一样; 正常来讲,把bond0 添加到 /etc/neutron/plugins/ml2/linuxbridge_agent.ini 中就可以了,也不会出现今天的问题,因为最初是这样的,我测试vpc功能都是OK的;

加入我把bond0给了neutron,则neutron会将bond0的IP转移给brqce4d2a54-44 , 由于机器有限,我需要在这些compute节点上起ceph node,ceph node也通过虚拟机提供存储服务(如上图的vnet0),如果让vnet0桥接到brqce4d2a54-44 上,总感觉不大好,于是,便有了上述的网络架构;

既然  /etc/neutron/plugins/ml2/linuxbridge_agent.ini  里面配置成了veth_neutron ,那么 /etc/neutron/plugins/ml2/linuxbridge_agent.ini 里面的 local_ip 也应该修改为 veth_neutron 的IP,不是吗?(当然不是,错就错在这儿了),于是我就这么改了

 

 

因为vxlan-60 的 dev 是brqce4d2a54-44 ,数据只有先到达brqce4d2a54-44  才可能进入vxlan-60 ;

我发现,进入的vxlan数据包首先是要走到bond0的,然后走到br0,我期望能通过veth_br0 到 veth_neutron , 再到 brqce4d2a54-44 ,然后再到vxlan-60, 然而,实际情况是,vxlan数据包根本不进入veth_br0; 我猜测,很可能内核已经在分析vxlan数据包了,该给谁给谁,没人要就丢掉呗; 然而,vxlan-60是base在brqce4d2a54-44  上的,没有base在br0上; 如果让vxlan-60 base在br0上是不是就可以了呢?

关于vxlan-60 base在哪个设备是通过/etc/neutron/plugins/ml2/linuxbridge_agent.ini  里面的local_ip 来决定的,和 physical_interface_mappings 是不必相同的。

修改后,重启 neutron-linuxbridge-agent.service , 重新创建vpc, 问题解决。

 

思考:

为什么vxlan的目的IP是brqce4d2a54-44, 而实际却不能真正落到brqce4d2a54-44 上?

 Posted by at 下午 6:30

vxlan实践

 openstack  vxlan实践已关闭评论
12月 042017
 

vxlan 也能在单台机器上演示:

网络拓扑:

pic

执行命令:

  1. 创建两个网络名字空间:(相当于做了两个虚拟机)

     
  2. 创建一个设备对儿:

     
  3. 将设备对分别添加到两个名字空间:

     
  4.  进入名字空间进行配置:

     
  5. 进入另外一个名字空间进行类似配置:

     
  6. 通过ip link show veth01   和ip link show veth10, 查到:
    veth01 Mac: fe:ea:f2:aa:1f:fc
    veth0 Mac: ee:b4:c4:3f:b3:2b
  7. 添加转发表:
  8. 验证:

     
  9. 注意:我们在各自的名字空间内ping不到自己的IP,因为我们没有启动lo,启动lo就可以ping到自己了

 

参考: http://tech.mytrix.me/2017/04/vxlan-overlay-in-linux-bridge/

 Posted by at 上午 10:42

变化的mac地址

 docker, openstack  变化的mac地址已关闭评论
11月 212017
 

 

一个bridge诞生时,会有一个mac地址;当向bridge上addif  veth2时,bridge的mac地址就跟随了veth2的mac地址,难道br0就不能固定一个mac地址吗?

可以的:

默认情况下,bridge总是跟随port中mac地址最小的那个port的mac地址,如果不想让mac地址总是变化,则可以设置bridge的首选mac地址,方法就是显式地给bridge设置mac地址:

参考:

http://blog.csdn.net/fanwenbo/article/details/2131193

 Posted by at 下午 2:58

openstack 网络问题

 openstack  openstack 网络问题已关闭评论
11月 062017
 
  1. 同网段的机器ping的时候报没有路由的问题
    1. arp -an查看,发现mac地址都没查到
    2. 通过宿主机直接看虚拟机,发现虚拟机的网卡、ip都是在的
    3. 解决:
      1. 虚拟机桥接的网桥重启过,而虚拟没有重启,相当于“网线断了”
    4. 结论:
      1. 不要随便重启网桥,重启之后端口信息就没了,其下属的机器就相当于断了网线,后果很严重
  2. openstack启动的机器我们都可以看到libvirtd的xml配置文件,xml配置文件中有关于网卡机器对应的tap的信息; 我们直接virt-manager上通过桥接方式配置的网卡,在xml文件中找不到关于tap的名字的信息,但是对应的网桥下确实会多出来一个类似于vnet的网络设备

 

 

 

 

 Posted by at 下午 12:14

关于mactap的使用

 openstack  关于mactap的使用已关闭评论
10月 302017
 

在使用neutron的provider网络时,使用linuxbridge做驱动,配置是这样的:

提供一个设置了IP的网络设备(不能是bridge)

当启用该网络时,linuxbridge会创建一个bridge,将配置中的IP配置到该bridge上,然后,把配置的设备插到该bridge上

其实,我不想把宿主机上唯一的网卡给neutron,于是:

  1. 在宿主机网卡上配置一个bridge
  2. 把宿主机IP配置在该bridge上
  3. 创建一个设备对儿
  4. 设备对的一端叫veth@br0,插到上面创建的bridge上
  5. 设备对儿的另一段叫veth@neutron,配置一个IP,把该IP和veth@neutron写到neutron的配置文件中

这样neutron只需要操作veth@neutron就行了

这样基本是可以的,唯一的问题在于veth@neutron这个名字里面的@不招待见,neutron服务会报错, 修改个名字就行了

续: veth@br0 的命名也是会遭到抵制的,在使用ip link list的时候,会出现这样一个设备:

似乎@也是一个特殊字符,如果@出现两次,则linuxbridge代码中会出现异常,如下:

显然,这里只觉得设备名称最多有一个@

 

相关脚本:

 Posted by at 下午 7:50

openstack kvm 磁盘限速

 kvm, openstack  openstack kvm 磁盘限速已关闭评论
10月 252017
 

设置:

读写最大10MB/s,iops最大50/s

  • 设置flavor, 在flavor上添加属性

  • 通过virsh dumpxml验证:

  • 验证

关于对卷的限速: http://ceph.com/planet/openstack-ceph-rbd-and-qos/

The disk I/O options are:

  • disk_read_bytes_sec
  • disk_read_iops_sec
  • disk_write_bytes_sec
  • disk_write_iops_sec
  • disk_total_bytes_sec
  • disk_total_iops_sec

参考: https://docs.openstack.org/nova/pike/admin/flavors.html

对于单独创建的卷来讲,可以在创建卷时指定卷类型,而卷类型可以预先关联已定义好的qos规格的,如:

 

注意:

  1.  对于创建虚拟机时使用新建卷的情况,该限速没有被应用,应该是bug吧
  2. 官方文档的一点儿要问题
  3. openstack的dashboard上也有一些误导的地方:

    这里的提示仅仅可以当做是示例,真正需要什么就写什么就行了,如,关于磁盘限速的相关键为:

    • read_bytes_sec
    • read_iops_sec
    • write_bytes_sec
    • write_iops_sec
    • total_bytes_sec
    • total_iops_sec
      注意: 这里不需要上面所谓的 disk_ 前缀

 

 Posted by at 下午 5:50

openstack with ceph

 ceph, openstack  openstack with ceph已关闭评论
10月 242017
 

前言

openstack是个很不错的东西,结合ceph之后,openstack就如同插上了翅膀,更加强大了。

 

ceph的好处:

  1. 有了ceph这个共享存储,guest的热迁移就方便多了
  2. ceph提供的块儿存储支持snap和clone,是的创建虚机和快照都不用copy磁盘,使得创建虚机可以秒级完成,而且非常节省存储

我遇到的问题:

  1. 在我将openstack和ceph结合起来之后,创建虚机依然很慢,并没有达到创建虚机不复制磁盘的效果

解决办法:

  1. 调试虚拟创建过程,发现如果要利用上rbd的snap和clone的特性,需要在image上有location属性;然而,我创建的image并没有该属性,openstack image命令行没有location相关选项,dashboard上创建镜像也没有该属性,只有glance命令行允许指定或单独添加该属性,却又报location invisible的错误;临时解决办法:直接修改代码,在代码中添加:
  2. 关于glance设置location失败的问题,根据关键字去glance代码中查看代码,发现当配置文件中的show_multiple_locations = false时,是不允许操作location的:

    然后,去glance-api的机器上grep show_multiple_locations ,并修改为True,重启glance-api 服务;然后再尝试location-add,提示url已存在,其实,该信息本来是存在的,只是显示与否的问题,现在不需要做任何操作,已经可以从image的信息中看到url了,如下:

    参考配置文件 /etc/glance/glance-api.conf 得知,show_multiple_locations = True使得image的地址直接暴露给了client,client就可以直接操作image了,可能存在一定的安全问题;当我们认为这不是问题的时候,我们就可以修改该配置,现在,我正是想利用rbd的一些特性,就需要将给选项设置为True;

  3. 至此,纠结已经的问题正式告一段落

总结:

  1. 按照手册安装openstack没有太大意义,能发现问题并解决问题才能进步;在解决该问题的过程中,尝试了python的单步调试(效果很差)、从代码上了解了虚拟机创建的过程,也了解了一些glance的代码,受益匪浅
 Posted by at 下午 1:54