OpenStack与Docker集成.ppt

OpenStack与Docker集成 张华 zhhuabj /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 | +------------------------------ ------+ 物理网卡的发展 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容器（