思源基于Docker和OpenStack的私有云平台实践
思源基于Docker和OpenStack的私有云平台实践
2016-01-19 10:35:33 来源：36大数据
抢沙发
2016-01-19 10:35:33 来源：36大数据
摘要：本次分享从以下三方面进行：使用Docker对OpenStack平台压力测试实践、使用Docker加速Sahara-Hadoop、Docker在 Nova项目的使用和实践。
关键词：
Docker
OpenStack
5. 遇到的问题
5.1 幽灵容器问题
我们环境中早期的Docker是1.5版本的，在升级1.7的时候，部分container的进程从容器逃逸，容器处于Destroyed状态，容器进行任何stop、remove都会出现如下报错：
Container does not exist：container destroyed。这是个社区已知的问题，目前社区没有完整的解决方案。升级过程中先关闭老的容器后再升级Docker可以避免该问题。出现问题之后要恢复相对麻烦。
5.2 用户隔离不足
我们测试环境中，容器密度较大。Container新建用户对外全部映射为 UID 500或者501，出现了Resource Temporarily unavailable。
CentOS默认用户UID从500开始，虽然ulimit设置上限是相对独立的，但是统计已经使用资源时却是一起统计的。所以在密度较大的测试和预生产环境可能会出现这样的问题。我们的解法是在我们添加的FirstBoot中创建一个随机UID的用户。这样相同的镜像创建出的用户UID也不同。大家各自统计，尽可能避免问题。
5.3 NFS Server无法启动
这个问题是两个小问题：
kernel模块的reload设置。
kthreadd创建进程。
第一个问题代表了一系列问题，这个是由于因为文件系统没有kernel的目录，模块依赖关系无从查起。通常此类服务都可以在配置文件中关闭模块的 reload过程，例如NFS就可以配置。第二个问题是rpc.nfsd 通知kernel去建立nfsd服务，kernel通过kthreadd来创建nfsd服务。所以nfsd进程不会出现在Container内部，而是暴露在宿主机上。
5.4 线程数量上限” fork: Cannot allocate memory”
我们的环境中出现过1次，表现为宿主机无法ssh登录，通过IPMI Console进行登录闪断。这个问题原因是由于某个应用的问题导致生成大量的线程，达到了系统线程的上线。
我们认为：
pid_max 和 threads-max 值如何设置不影响单个进程的线程数量，上限目前为32768。
pid_max 和 threads-max 影响所有线程的总量，二者较小者为系统上限。超过系统上限后部分系统命令都无法使用。
调整系统上限后虽然可以有更多的线程，但是太多的线程将会对系统稳定性造成影响。
解决思路
环境中所有宿主机将/proc/sys/kernel/pid-max设置为65535，并通过nagios监控告警宿主机上的线程数量。
从应用层(tomcat)限制线程上限。
5.5 .device mapper discard导致的宕机
这个问题反复出现在某些服务器上，宕机重启后通过IPMI consule进入时系统已经重新挂载了CoreDump的Kernel，看到CoreDump生成dump之前进行Recover操作和Data Copying操作，导致恢复时间很慢。通过Coredump分析属于Kernel在DM discard方面的一个BUG，方法为禁用docker devicemapper的discard。具体为设置Docker启动参数”–storage-opt dm.mountopt=nodiscard –storage-opt dm.blkdiscard=false”。该问题已经在多个公司分享中看到，解决思路也基本一致。
第四十一届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训
责编：pingxiaoli
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
