OpenStack与Docker集成

Download Report

Transcript OpenStack与Docker集成

OpenStack与Docker集成
张华 zhhuabj
http://blog.csdn.net/quqi99
2014年12月19日
Agenda
•
•
•
•
一些有利于理解的原理
高密度容器下网络设计的主要挑战
Neutron L2pop特性
Open questions
网络虚拟化技术演进基本思想
• 数据包从虚拟机到物理机的路径是:虚拟机进程(用户空间) -虚拟TAP网卡(用户空间)-- Hypervisor层 -- 网桥(内核空间) -物理网卡
• 总的原则:减少层数,让虚拟网卡趋近物理网卡的性能
virtio,vhost,vhost-user|snabb,openonload
virtio, 拷贝多次,且切换两次
+---------+------+--------+--------+
|
+------+ +---------+ |
| user |
| |
| |
| space |
| | guest
| |
|
|
| |
| |
| +----+ qemu | | +-+------+ |
| | |
|
| | virtio | |
| | |
|
| | pci | |
| | +------+ +-+---++---+ |
| |
|
|
|
|
|
+-+-----+------- ------+--+-------+| |tap | +--------+ kvm.ko | |
| +-----+
+--+-------+ |
|
kernel
|
+------------------------------ ------+
vhost, 首先guest mem与
vhost-user, 同在用户态的
vhost-net通过vhost共享内
snabb与guest mem通过
存;其次vhost-net模块直
vhost共享内存;其次
接读取tap又少了一次切换
snabb直接写驱动操作网卡
+--------+------+-----+------+--+
|
+------+ +---------+ |
| user |
| |
| |
| space |
| | guest
| |
|
|
|
|
| |
|
| qemu | | +-+------+ |
|
|
|
| | virtio | |
|
|
|
| | pci | |
|
+------+ +-+---++---+ |
|
|
|
|
|
+-+-----+--+-+----+----+----+--+
| |tap | |vhost-net.ko| | kvm.ko|
| +---^-+ +----+---- +----+---+
| |-------| kernel |----------| |
+-------------------------------------
+--------------+------+--+-----+--+
|
+------+ +----------+ |
| user
|
| |
| |
| space
|
| | guest | |
|
|
| |
| |
| + ----+ | qemu | | +-+----+ |
| | vhost | |
| | | virtio | |
| | backend | | | | | driver | |
| +---- + +------+ +-+---++--|
snabb
|
|
|
|
+------------------------------ +--+
| phy nic
+-------------+---------------+
kernel
|
+----------------------------------+
物理网卡的发展
•
•
VMDQ将原来VMM中L2 virtual switch实现的队列功能通过硬件实现, 软件交
换机无需排序和路由操作
SR-IOV更彻底,将二层交换的功能也通过硬件实现,并且创建不同的虚拟功
能(VF)的方式,呈现给虚机的就是具有独立的中断号的物理网卡,因为虚机
直接和物理网卡通信,不需要经过软件交换机, 虚机与VF之间通过DMA传输
内核态协议栈 & 用户态协议栈
• 协议栈的主要处理开销:中断处理、内存拷贝、系统调用、协议处理
• 千兆万兆网络出现后,更加频繁的硬件中断、软中断及上下文切换都
会占据大量的CPU周期。
• 传统协议栈针对通用性设计,区分内核空间和用户空间,应用无法直
接访问协议栈的地址空间,因此协议栈的安全性较高。有数据表明,
在Linux协议栈中,数据包通过socket从内核缓冲区复制到用户空间的
时间占到了整个数据包处理时间的57.1%。
• 系统调用是内核态向用户态提供的一组API集,一般通过软中断实现
,会产生较大的上下文 开销。
• 协议处理,耗时主要包括:校验和计算,定时器管理,IP分片/重组,
可靠传输机制,拥塞控制等。
云操作系统 OSv, CoreOS, Ubuntu Core
• 单内核减小IPC调用,每个CPU核上单线程
• 最小化系统,去掉Shell, 去掉不必要的库,去掉不必要的开机服务,
减小容器共享内核的攻击面
• 使用systemd/upstart加速启动,认为shell拖累启动
• 基于容器技术
• 云操作系统image文件小,应用的文件也小,有的可以delta分发
• 装载容器,在应用分发上做文章, Ubuntu Core使用了基于事务的包
管理工具snappy, 且使用了微内核由vendor来实现snappy应用
• 在升级方面,Ubuntu Core基于事务升级,要不升级成功,要不升级
不成功但不影响原有系统;CoreOS更绝采用两个root文件系统,有
一个用于升级;
• 在配置管理方面,OSv是零配置无状态;CoreOS使用共享的etcd;
Ubuntu Core采用Snappy打包
• 在安全方面,容器间的共享的内核受到攻击后对容器威胁很大,
Ubuntu Core采用apparmor来对程序进行资源的访问控制
• 内核方面,CoreOS与Ubuntu Core基于Linux内核,OSv无用户空间
减少了用户态内核态切换的开销
• CoreOS实现了HA容器,有点儿入侵了Neutron的地盘啊 :)
容器,Linux容器(LXC), Docker
容器的优点:
• 密度大,启动快,因为它省去了一个操作系统栈,正是这点,给网络设计带来了挑战
• 容器解偶了应用与操作系统,为应用的分发提供了可能,更适合SaaS。它使用
namespace进程资源隔离(IPC,NET,PID,UTS,NS,USER);使用chroot隔离根文件系统
;使用cgroup做资源限制;
• 所有容器共享相同的内核,便于维护。但同时也带来了安全性风险
容器的缺点:
• 容器共享内核带来了安全性风险,所以云OS应该是最小化操作系统,减小攻击面
• 隔离性还不如虚机,如netlink暂时不支持namespace所以导致不支持iSCSI存储
• 在线迁移,所以LXD要在LXC上再添加这样更等价虚机的功能
• 更高密度带来的网络挑战
Docker基于LXC基础上继续:
• 封装了REST API,交叉式
Shell, 日志功能
• 采用CoW创建根文件系统,
让镜像变得Delta,部署极其
快捷
• 类似于OpenStack的镜像及
调度管理
• 应用分发机制
应用分发机制,以 Ubuntu Core为例
•
•
•
•
•
•
•
•
•
•
•
•
•
Play with Snappy
$ wget http://cdimage.ubuntu.com/ubuntucore/preview/ubuntu-core-alpha-01.img
$ sudo kvm -m 512 -redir :8090::80 -redir
:8022::22 ubuntu-core-alpha-01.img
$ ssh -p 8022 ubuntu@localhost
$ snappy info
$ snappy versions -a
$ snappy search docker
$ sudo snappy install docker
$ snappy update-versions
$ sudo snappy update ubuntu-core
$ sudo snappy rollback ubuntu-core
$ sudo reboot
http://www.ubuntu.com/cloud/tools/snappy
#snappy-local
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Anatomy of a snappy package
$ sudo add-apt-repository ppa:snappydev/beta
$ sudo apt-get update
$ sudo apt-get install snappy-tools bzr
$ bzr branch lp:~snappy-dev/snappyhub/snappy-examples
$ cd snappy-examples/hello-world
$ snappy build .
$ snappy-remote --url=ssh://localhost:8022
install ./hello-world_1.0_all.snap
$ hello-world.hello
ubuntu@localhost:~$ ls -l /apps/helloworld/
drwxr-xr-x 5 clickpkg clickpkg 4096 Dec 15
lrwxrwxrwx 1 clickpkg clickpkg 5 Dec 15
current -> 1.0.2
ubuntu@localhost:~$ ls /apps/helloworld/current/meta/
hello.apparmor hello.svg package.yaml
readme.md
高密度容器带来的网络挑战
• 2没有控制平面,高密度直接要求必须禁掉ARP广播,改
由地址学习。neutron的数据库是一个学习的好地方,
neutron l2pop特性能允当控制平面。
• 高密度要求网络资源必须充足,像limit, namespace,
neighbor table size, vlan等,Linux是一个通用的操作系统
,不是为云设计的
• 容器的快速启动特性要求dnsmasq支持HUP信号持HUP
信号
• ...
快速搭建可运行的环境 - devstack
•
Available devstack localrc http://blog.csdn.net/quqi99/article/details/25923921
•
Involved feature & components
–
–
–
•
nova-docker
neutron dvr
neutron l2pop
command demo
–
–
–
–
–
–
–
–
–
$ export OS_USERNAME=admin
$ export OS_PASSWORD=password
$ export OS_TENANT_NAME=demo
$ export OS_AUTH_URL=http://172.16.1.1:5000/v2.0
$ export OS_AUTH_STRATEGY=keystone
$ nova boot --flavor 1 --image cirros i1
$ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
$ nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
$ sudo ip netns exec $container_id ping -c 1 10.0.1.6
PING 10.0.1.6 (10.0.1.6) 56(84) bytes of data.
64 bytes from 10.0.1.6: icmp_seq=1 ttl=64 time=0.040 ms
计算节点 (LXC+ OVS)
•
1, plug vifs
– ip link add name tap2e331369-67 type veth peer name ns2e331369-67
– ovs-vsctl --timeout=120 -- --if-exists del-port tapb9cd4fd6-b7 -- add-port br-int
tapb9cd4fd6-b7 -- set Interface tapb9cd4fd6-b7 external-ids:iface-id=b9cd4fd6b79c-4035-8873-8467989148d6 external-ids:iface-status=active externalids:attached-mac=fa:16:3e:87:ab:54 external-ids:vm-uuid=4e3a5767-921f-4232a777-80c877b26cde
– ip link set tapb9cd4fd6-b7 up
•
2, create namespace and attach vifs into namespace
– container_id=785c14069f7e63a4f013ee2c35cec85473da2e571c9d690edba64f9
d6d349fcc
– ln -sf /proc/22595/ns/net /var/run/netns/$container_id
– ip link set ns2e331369-67 netns $container_id
– ip netns exec $container_id ip link set ns2e331369-67 address fa:16:3e:1f:ed:f5
– ip netns exec $container_id ifconfig ns2e331369-67 10.0.1.6/24
– ip netns exec $container_id ip route replace default via 10.0.1.1 dev
ns2e331369-67
网络节点
•
1, all namespace
–
–
–
–
–
•
2, lxc instance namespace
–
–
–
–
–
–
•
hua@hua-ThinkPad-T440p:~$ container_id=785c14069f7e63a4f013ee2c35cec85473da2e571c9d690edba64f9d6d349fcc
hua@hua-ThinkPad-T440p:~$ sudo ip netns exec $container_id ip addr show |grep global
inet 10.0.1.6/24 brd 10.0.1.255 scope global ns2e331369-67
hua@hua-ThinkPad-T440p:~$ sudo ip netns exec $container_id route -n
0.0.0.0
10.0.1.1
0.0.0.0
UG 0
0
0 ns2e331369-67
10.0.1.0
0.0.0.0
255.255.255.0 U 0
0
0 ns2e331369-67
3, qrouter- namespace
–
–
–
–
–
•
hua@hua-ThinkPad-T440p:~$ sudo ip netns list
785c14069f7e63a4f013ee2c35cec85473da2e571c9d690edba64f9d6d349fcc
qdhcp-7b5090e3-4ed5-4b6e-93de-01f72b91e382
snat-13594a5a-dcdf-4a7e-aba0-edbc1338a8b8
qrouter-13594a5a-dcdf-4a7e-aba0-edbc1338a8b8
hua@hua-ThinkPad-T440p:~$ router_id=13594a5a-dcdf-4a7e-aba0-edbc1338a8b8
hua@hua-ThinkPad-T440p:~$ sudo ip netns exec qrouter-$router_id ip addr show |grep global
inet 10.0.1.1/24 brd 10.0.1.255 scope global qr-8cace44e-a5
hua@hua-ThinkPad-T440p:~$ sudo ip netns exec qrouter-$router_id route -n
10.0.1.0
0.0.0.0
255.255.255.0 U 0
0
0 qr-8cace44e-a5
4, snat- namespace
–
–
–
–
–
–
–
hua@hua-ThinkPad-T440p:~$ sudo ip netns exec snat-$router_id ip addr show |grep global
inet 10.0.1.2/24 brd 10.0.1.255 scope global sg-1d495a48-e5
inet 192.168.99.104/24 brd 192.168.99.255 scope global qg-64d1b580-ad
hua@hua-ThinkPad-T440p:~$ sudo ip netns exec snat-$router_id route -n
0.0.0.0
192.168.99.1 0.0.0.0
UG 0
0
0 qg-64d1b580-ad
10.0.1.0
0.0.0.0
255.255.255.0 U 0
0
0 sg-1d495a48-e5
192.168.99.0 0.0.0.0
255.255.255.0 U 0
0
0 qg-64d1b580-ad
网络拓扑图
Neutron L2pop
l2pop is used to disable arp broadcast and address study, see
http://blog.csdn.net/quqi99/article/details/17789907
• neutron db has ip,mac mapping data
• for ovs, using ebtable to intercept arp request.
– ebtables -t nat -A PREROUTING -i tapPORT_ID -p arp --arp-opcode
Request --arp-ip-dst REMOTE_VM_IP -j arpreply --arpreply-mac
REMOTE_VM_MAC --arpreply-target ACCEPT
• address study, adding ovs bridge forward rules for unicast and
broadcast flow.
– ovs-ofctl add-flow br-tun
hard_timeout=0,idle_timeout=0,priority=3,dl_dst=REMOTE_VM_MAC,in_po
rt=OVS_VM_PORT_ID, dl_vlan=LOCAL_VLAN_ID,
actions=set_tunnel:SEGMENTATION_ID,TUNNEL_PORT_NAME
– ovs-ofctl add-flow br-tun
hard_timeout=0,idle_timeout=0,priority=3,dl_dst=01:00:00:00:00:00/01:00:0
0:00:00:00,in_port=OVS_VM_PORT_ID, dl_vlan=LOCAL_VLAN_ID,
actions=set_tunnel:SEGMENTATION_ID,TUNNEL_PORT_NAME#1,...,TUN
NEL_PORT_NAME#n
Open questions