一个Docker附加参数引起的网络服务异常
|
删除失败带来的后续结果是,由于文件系统层的namespace文件没有完全删除,而实际的networknamespace已经释放,所以这个“半删除”的namespace从用户态程序的角度就呈现出这样的状态：能够查看到namespace,对应2.1第5)步中ensure_namespace()操作正常,但set操作时会失败,对应2.1第6)步set_ns()操作失败 setns(4,1073741824) ???????????????????= -1 EINVAL (Invalid argument) write(2,“seting the network namespace &;ns”…,60seting the network namespace “ns1” failed: Invalid argument 解决方法 修改neutron-*-agent容器的启动参数： – -v /run/netns:/run/netns:shared ?-v /run:/run:rw + -v /run/netns:/run/netns:shared ?-v /run:/run:rw:shared 2.3.确定触发场景模拟再现故障 1)?创建网络和子网 neutron net-create –shared –provider:network_type vlan –provider:physical_network physnet1 –provider:segmentation_id 108 vlan108 neutron subnet-create –name subnet108 vlan108 192.168.0.0/24 2)?重启neutron_dhcp_agent容器 docker restart neutron_dhcp_agent 这时neutron_dhcp_agent所创建的namespace已被docker daemon和其他容器引用,权限已转移不允许neutron_dhcp_agent删除 3)?删除该网络的子网 neutron subnet-delete subnet108 neutron删除子网成功,但后台实际删除namespace失败,而且namespace命名空间已释放,但文件系统接口任然存在,处于“半删除”状态,直接删除网络不会触发后续异常. 4)?为该网络重新创建子网 neutron subnet-create –name subnet108 vlan108 172.16.0.0/24 neutron创建子网成功,这时后台应当重新创建namespace,但由于上一步删除namespace动作失败导致namespace非正常残留,所以这里跳过创建namespace动作,接下来为tap设备设置namespace的动作失败,开始进入2.1描述的循环状态. 用Docker模拟局部故障 1)?启动两个容器共享可操作network namespace文件系统docker run -d –name testa -it –v /run:/run:rw -v /run/netns:/run/netns:shared –privileged –net=host nova-compute:latest bash docker run -d –name testb -it –v /run:/run:rw -v /run/netns:/run/netns:shared –privileged –net=host nova-compute:latest bash 2)?在容器A中创建namespace?ns1 docker exec -u root testa ip netns add ns1 3)?重启容器A docker restart testa 4)?使用容器A删除之前创建的namespace docker exec -u root testa ip netns del ns1 Cannot remove namespace file “/var/run/netns/ns1”: Device or resource busy 5)?使用容器A设置namespace docker exec -u root testa ip netns exec ns1 ip a seting the network namespace “ns1” failed: Invalid argument 3.?小结 3.1.经验总结Mount陷阱 每个Mount namespace有自己独立的文件系统视图,但是这种隔离性同时也带来一些问题：比如,当系统加载一块新的磁盘时,在最初的实现中每个namespace必须单独挂载磁盘.为此内核在2.6.15引入了shared subtrees feature：“The key benefit of shared subtrees is to allow automatic,controlled propagation of mount and unmount events between namespaces. This means,for example,that mounting an optical disk in one mount namespace can trigger a mount of that disk in all other namespaces.”?每个挂载点都会标记Propagation type,用于决定在当前挂载点下创建/删除(子)挂载点时,是否传播到别的挂载点.功能同样带来潜在的复杂,如2.2描述的权限传播转移出乎使用者的预料. 目前容器技术的存储管理和使用最终都依赖Mount系统调用,后续的使用场景需注意. 应该温柔的重试 如果neutron的重试机制“聪明”一点,就不会累计产生越来越多的tap设备,也就不会造成实际用户可见的网络异常.更好的方式是采用随机化、指数型递增的重试周期,有时候系统出现的一个小故障可能会导致重试请求同时出现,这些请求可能会逐渐放大故障.在不同场景应该考虑限制某个请求的重试次数或者进程整体在单位时间内的重试配额. 谨慎对待重启 我们常使用重启服务“快刀斩乱麻”,解决一般性问题,但从这件事的处理经过来看,两次重启服务使问题影响范围不断扩大,而且在其他很多场景下,重启服务时程序会重新读取外部资源,也常常会暴露出很多已经潜在、但尚未产生影响的问题.所以,在生产环境应该避免草率重启,而且还应在服务可中断时间有计划的演练重启,以便提前发现、解决未来被动重启时才会暴露的问题. 容器化的利与弊 这次事故由容器启动参数的不正确使用引起,但同样因为容器利于部署应用的特性,现场较快的在其他节点部署恢复了网络服务,减少了业务中断时间. 3.2.事件还原附录参考： Docker基础技术——Linux Namespace http://coolshell.cn/articles/17010.html Mount namespace and mount propagation http://hustcat.github.io/mount-namespace-and-mount-propagation/ Shared Subtrees https://lwn.net/Articles/159077/ Mount namespaces and shared trees https://lwn.net/Articles/689856/ 作者：崔昊之,云技术开发者和爱好者,Openstack化石玩家,Docker社区committer,就职于中电科华云,希望和大家分享云技术实践过程中有趣的事儿. 文章来自微信公众号：云计术实践 （编辑：东莞站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
