如何解决 U盘启动 Lunix 系统死机问题

故障排除 Linux *** 作系统死机处理方法总结

Linux 有多种机制来保证发生系统崩溃后，可以获取有价值的信息用以分析问题。确定是硬件故障，还是应用程序bug 导致的。

Linux 中，有如下几种方法来获取各种崩溃时产生的信息。

1Core dump

Core dump 通常用来调试应用程序错误，当某些应用程序运行出现异常崩溃时，可以开启系统的 core dump 功能，来得到一个程序崩溃时的内存信息，用来分析崩溃原因：

在/etc/profile里加上(或者修改)一条：

ulimit -c 0

运行命令：sysctl -w "kernelcore_name_format=/coredump/%ncore"

该命令意思是指core文件放在/coredump目录下，文件名是进程名+core

2Diskdump

diskdump工具提供了在单机上创建和采集vmcore(kernel dump)的能力，而无须使用网络。当内核本身出现崩溃的时候，当前的内存和CPU状态以及相关的信息都会被保存到一个支持diskdump的磁盘上的保留分区上。在下一次重新启动的时候，当系统重新启动，diskdump的初始化脚本会从保留分区中读取保存的信息并创建一个vcore文件,然后这个文件被再次存放到/var/crash/目录下，文件名为127001-

如下是一个配置 HP SCSI 设备上启用 diskdump 的过程，如果不是 HP SCSI 设备(即设备名为 /dev/sdX的形式)，则无须执行第三、四两个步骤。但需要在第一步前先执行命令： modprobe

diskdump

第一步：编辑 /etc/sysconfig/diskdump文件，将一个空白分区的设备名填入后保存退出，例如：

DEVICE=/dev/cciss/c0d0p2

第二步：初使化 dump 设备

#service diskdump initialformat

警告：该分区的所以数据会丢失。

第三步：使用 cciss_dump 模块替换当前的 cciss 模块：

在 /etc/modprobeconf 找到如下行：

alias scsi_hostadapter cciss

修改为：

alias scsi_hostadapter cciss_dump

再增加一行：

options cciss_dump dump_drive=1

注：假设diskdump文件中配置的为 /dev/cciss/c0d[#a]p[#b], 请设置为： options cciss_dump dump_drive=[#a]

第四步：重建 initrd 文件：

#mv /boot/initrd-`uname -r`img /boot/initrd-`uname -r`imgold

#mkinitrd /boot/initrd-`uname -r`img `uname -r`

第五步：设置 diskdump 服务能够开机自启动：

# chkconfig diskdump on

3Netdump

如果使用红旗DC40 或 30 版本系统，是不能支持 diskdump 的，可以利用netdump 来达到输出vmcore 的目的。但是Netdump要求至少有一个服务器以及任意数目的客户端。服务器用来接收客户端死机时的信息，客户端是经常死机的机器。　

（一）服务器配置:

(1)检验netdump服务器是否安装完毕:

rpm -q netdump-server

如果未安装,请在光盘 RedFlag/RPMS/ 目录中找到 netdump-server 打头的软件包，执行命令:

rpm -ivh netdump-server-xxxrpm (x为版本号)

进行安装。

(2)服务器包安装后,用命令:

passwd netdump

更改用户的密码

(3)打开服务:

chkconfig netdump-server on

(4)运行服务器:

service netdump-server start

（二）客户端配置:

(1)校验客户端是否已安装

rpm -q netdump

如果未安装，在光盘 RedFlag/RPMS/ 目录中找到 netdum 打头的软件包，执行命令:

rpm -ivh netdump-xxxrpm (x为版本号)

安装

(2)编辑文件/etc/sysconfig/netdump，添加如下行:

DEV=eth0

NETDUMPADDR=1721681182

NETDUMPMACADDR=00:0C:29:79:F4:E0

1721681182指 netdump 服务器地址。

(3)运行下面的命令，出现提示符时输入密码:

service netdump propagate

(4)打开客户端:

chkconfig netdump on

(5)运行客户端:

service netdump start

(6)测试

为了测试netdump的配置是否正确，在netdump客户机上做下面 *** 作：

cp /usr/share/doc/netdump-xxxxxx/crashc

gcc -DKERNEL -DMODULE -I/lib/modules/$(uname -r)/build/include -c crashc

insmod /crasho

这会造成系统崩溃，你会在netdump服务器的/var/crash/<客户端IP>/目录下，看到一个核心转储。当客户机正在转储数据到服务器的时候，你会看到一个名叫“vmcore-incomplete"的文件。当转储结束后，该文件会改名成 "vmcore"。"vmcore"文件的大小会变化，可能达到几个GB在一个内存是512M的系统上，上面的测试会产生大约510M的vmcore文件。

怎么判断网卡是否支持netdump功能？

内核调试工具netdump需要网卡驱动支持netpoll功能。netpoll的目的是让内核在网络和I/O子系统尚不能完整可用时，依然能发送和接收数据包。主要用于网络控制台（net console）和远程内核调试（KGDBoE）中。实现netpoll功能，主要是要实现kernel中的poll_controller函数，该函数定义：void (poll_controller)(struct net_device dev)。该函数的作用是在缺少设备中断的情况下，还能对控制器做出响应。几乎所有的poll_controller函数都定义成如下形式：

void my_poll_controller(struct net_device dev) {

disable_device_interrupt(dev);

call_interrupt_handler(dev->irq, dev);

enable_device_interrupt(dev);

}

所以，poll_controller只是模拟了来自指定设备的中断。一个最简单的判断一个网卡驱动是否这次支持netpoll功能的方法是安装内核源代码，然后在代码树 /usr/src/kernel-＜version＞中搜索HAVE_POLL_CONTROLLER的定义, grep -r "HAVE_POLL_CONTROLLER" /usr/src/linux-＜version＞/drivers/net示例如下：

# grep -r "HAVE_POLL_CONTROLLER" /usr/src/linux-24/drivers/net

/usr/src/linux-24/drivers/net/3c59xc:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/3c59xc:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/e100/e100_mainc:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/e100/e100_mainc:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/e1000/e1000_mainc:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/e1000/e1000_mainc:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/e1000/e1000_mainc:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/eepro100c:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/eepro100c:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/pcnet32c:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/pcnet32c:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/tg3c:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/tg3c:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/tlanc:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/tlanc:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/tulip/tulip_corec:#ifdef HAVE_POLL_CONTROLLER

/usr/src/linux-24/drivers/net/tulip/tulip_corec:#ifdef HAVE_POLL_CONTROLLER

从输出可以看到，3c59x, e100, e1000, eepro100, pcnet32, tg3, tlan和tulip都支持netpoll。

如果系统使用了这些网卡，那么系统应该支持netpoll，那么就支持netdump。

如果希望进一步确认网卡是否是使用这些网卡，可以查看/etc/modulesconf:

# cat /etc/modulesconf

alias eth1 e100

alias eth0 3c59x

4SysRq

SysRq组合键是一组"魔术组合键"，只要内核没有被完全锁住，键盘还能够使用，不管内核在做什么事情，使用这些组合键可以立即打印出内核的信息。

使用sysrq组合键是了解系统目前运行情况的最好方式。如果系统出现挂起的情况或者在诊断一些和内核相关，比较怪异，比较难重现的问题的时候，使用sysrq键是一个比较好的方式。

为了安全起见，默认SysRq组合键是关闭的。

打开这个功能，运行:

# echo 1 > /proc/sys/kernel/sysrq

关闭这个功能:

# echo 0 > /proc/sys/kernel/sysrq

如果想让此功能一直生效，在/etc/sysctlconf里面设置kernelsysrq的值为1 重新启动以后，此功能将会自动打开。

kernelsysrq = 1

因为打开sysrq键的功能以后，有终端访问权限的用户将会拥有一些特殊的功能。因此，除非是要调试，解决问题，一般情况下，不要打开此功能。如果一定要打开，请确保您的终端访问的安全性。

如何触发一个sysrq事件

有几种方式可以触发sysrq事件。在带有AT键盘的一般系统上，在终端上输入一下组合键:

Alt+PrintScreen+[CommandKey]

例如，要让内核导出内存信息(CommandKey "m")，您应该同时按下Alt 和 Print Screen 键，然后按下 m 键 提示: 此组合键在Xwindows上是无法使用的。所以，您先要切换到文本虚拟终端下。如果您现在是在图形界面，可以按Ctrl+Alt+F1切换到虚拟终端。

当我触发一个sysrq事件的时候，结果保存在什么地方

当一个sysrq命令被触发，内核将会打印信息到内核的环形缓冲并输出到系统控制台。此信息一般也会通过syslog输出到/var/log/messages

有时候，可能系统已经无法响应，syslogd可能无法记录此信息。在这种情况下，建议您配置一个串口终端来收集这个信息。

那些类型的sysrq事件可以被触发

sysrq功能被打开后，有几种sysrq事件可以被触发。不同的内核版本可能会有些不同。但有一些是共用的:

m - 导出关于内存分配的信息

t - 导出线程状态信息

p - 到处当前CPU寄存器信息和标志位的信息

c - 故意让系统崩溃(在使用netdump或者diskdump的时候有用)

s - 立即同步所有挂载的文件系统

u - 立即重新挂载所有的文件系统为只读

b - 立即重新启动系统

o - 立即关机(如果机器配置并支持此项功能)

故障分析

虽然我们可以通过上述的几种方法来获取应用程序或 *** 作系统崩溃时的各种信息，但是分析这些问题有一定难度。

常见问题

软件相关

系统平时运行一切正常，自从新实施了一项应用后，频繁发生崩溃现象，此类问题多数与应用程序Bug有关，不一定在所有相同配置系统中都会产生，但是一旦触发该Bug，就有可能发生崩溃。

系统平时运行一切正常，自从新实施了一项应用后，频繁发生崩溃现象，也有一些情况是新增的应用需要做一定的 *** 作系统配置，没有设置的话，也有可能出现资源利用问题，导致崩溃发生。

系统平时运行一切正常，自从新实施了一项应用后，频繁发生崩溃现象，也有一些情况是应用的版本与 *** 作系统版本不匹配，应用软件所需的系统库文件版本不对应，容易引发应用程序崩溃。

系统平时运行正常，近期没有任何新增应用，也没有更改系统配置，却接连发生多次崩溃现象。此类问题多数是压力增大，超出了硬件所能承受的负载，耗尽资源，发生崩溃。

系统平时运行正常，近期无新增应用，系统负载也不高，却发生崩溃现象。不排除 *** 作系统本身的问题，有可能某种 *** 作诱发了一个系统Bug，发生崩溃。

硬件相关

新增内存后，系统经常发生崩溃现象，此类问题有可能是32位机器配置了超过12GB的内存，但没有使用 hugemem 核心导致，具体原因可参见第一节中的说明。

机器使用期限较长，某个硬件发生故障，也会导致系统崩溃的发生。

新配置的机器经常发生崩溃现象，有可能硬件较新，而驱动程序版本较低，一般可通过升级驱动解决，驱动一般集成在内核当中，常见的办法是升级内核版本。

蘑菇街基于 OpenStack 和 Docker 的私有云实践

本次主要想分享一下过去一年时间里，我们在建设基于Docker的私有云实践过程中，曾经遇到过的问题，如何解决的经验，还有我们的体会和思考，与大家共勉。

在生产环境中使用Docker有一些经历和经验。私有云项目是2014年圣诞节期间上线的，从无到有，经过了半年多的发展，经历了3次大促，已经逐渐形成了一定的规模。

架构

集群管理

大家知道，Docker自身的集群管理能力在当时条件下还很不成熟，因此我们没有选择刚出现的 Swarm，而是用了业界最成熟的OpenStack，这样能同时管理Docker和KVM。我们把Docker当成虚拟机来跑，是为了能满足业务上对虚拟化的需求。今后的思路是微服务化，把应用进行拆分，变成一个个微服务，实现PaaS基于应用的部署和发布。

通过OpenStack如何管理Docker我们采用的是OpenStack+nova-docker+Docker的架构模式。nova- docker是StackForge上一个开源项目，它做为nova的一个插件，通过调用Docker的RESTful接口来控制容器的启停等动作。

我们在IaaS基础上自研了编排调度等组件，支持应用的d性伸缩、灰度升级等功能，并支持一定的调度策略，从而实现了PaaS层的主要功能。

同时，基于Docker和Jenkins实现了持续集成(CI)。Git中的项目如果发生了git push等动作，便会触发Jenkins Job进行自动构建，如果构建成功便会生成Docker Image并push到镜像仓库。基于CI生成的Docker Image，可以通过PaaS的API或界面，进行开发测试环境的实例更新，并最终进行生产环境的实例更新，从而实现持续集成和持续交付。

网络和存储

网络方面，我们没有采用Docker默认提供的NAT网络模式，NAT会造成一定的性能损失。通过OpenStack，我们支持Linux bridge和Open vSwitch，不需要启动iptables，Docker的性能接近物理机的95%。

容器的监控

监控方面，我们自研了container tools，实现了容器load值的计算，替换了原有的top、free、iostat、uptime等命令。这样业务方在容器内使用常用命令时看到的是容器的值，而不是整个物理机的。目前我们正在移植Lxcfs到我们的平台上。

我们还在宿主机上增加了多个阈值监控和报警，比如关键进程监控、日志监控、实时pid数量、网络连接跟踪数、容器oom报警等等。

冗灾和隔离性

冗灾和隔离性方面，我们做了大量的冗灾预案和技术准备。我们能够在不启动docker daemon的情况下，离线恢复Docker中的数据。同时，我们支持Docker的跨物理机冷迁移，支持动态的CPU扩容/缩容，网络IO磁盘IO的限速。

遇到的问题及解决方法

接近一年不到的产品化和实际使用中我们遇到过各种的问题，使用Docker的过程也是不断优化Docker、不断定位问题、解决问题的过程。

我们现在的生产环境用的是CentOS 65。曾经有个业务方误以为他用的Docker容器是物理机，在Docker容器里面又装了一个Docker，瞬间导致内核crash，影响了同一台物理机的其他Docker容器。

经过事后分析是2632-431版本的内核对network namespace支持不好引起的，在Docker内创建bridge会导致内核crash。upstream修复了这个bug，从2632-431升级到2632-504后问题解决。

还有一个用户写的程序有bug，创建的线程没有及时回收，容器中产生了大量的线程，最后在宿主机上都无法执行命令或者ssh登陆，报的错是"bash: fork: Cannot allocate memory"，但通过free看空闲的内存却是足够的。

经过分析，发现是内核对pid的隔离性支持不完善，pid_max(/proc/sys/kernel/pid_max)是全局共享的。当一个容器中的pid数目达到上限32768，会导致宿主机和其他容器无法创建新的进程。最新的43-rc1才支持对每个容器进行pid_max限制。

我们还观察到docker的宿主机内核日志中会产生乱序的问题。经过分析后发现是由于内核中只有一个log_buf缓冲区，所有printk打印的日志先放到这个缓冲区中，docker host以及container上的rsyslogd都会通过syslog从kernel的log_buf缓冲区中取日志，导致日志混乱。通过修改 container里的rsyslog配置，只让宿主机去读kernel日志，就能解决这个问题。

除此之外，我们还解决了device mapper的dm-thin discard导致内核crash等问题。

体会和思考

最后分享一下我们的体会和思考，相比KVM比较成熟的虚拟化技术，容器目前还有很多不完善的地方，除了集群管理、网络和存储，最重要的还是稳定性。影响稳定性的主要还是隔离性的不完善造成的，一个容器内引起的问题可能会影响整个系统。

容器的memcg无法回收slab cache，也不对dirty cache量进行限制，更容易发生OOM问题。还有，procfs上的一些文件接口还无法做到per-container，比如pid_max。

另外一点是对容器下的运维手段和运维经验的冲击。有些系统维护工具，比如ss，free，df等在容器中无法使用了，或者使用的结果跟物理机不一致，因为系统维护工具一般都会访问procfs下的文件，而这些工具或是需要改造，或是需要进行适配。

虽然容器还不完善，但是我们还是十分坚定的看好容器未来的发展。Kubernetes、Mesos、Hyper、CRIU、runC等容器相关的开源软件，都是我们关注的重点。

Q&A

Q：请问容器间的负载均衡是如何做的

A： 容器间的负载均衡，更多是PaaS和SaaS层面的。我们的P层支持4层和7层的动态路由，通过域名的方式，或者名字服务来暴露出对外的接口。我们能够做到基于容器的灰度升级，和d性伸缩。

Q：请问你们的OpenStack是运行在CentOS 65上的吗

A: 是的，但是我们针对OpenStack和Docker依赖的包进行了升级。我们维护了内部的yum源。

Q：请问容器IP是静态编排还是动态获取的

A: 这个跟运维所管理的网络模式有关，我们内部的网络没有DHCP服务，因此对于IaaS层，容器的IP是静态分配的。对于PaaS层来说，如果有DHCP服务，容器的App所暴露出来IP和端口就可以做到动态的。

Q：请问你们当时部署的时候有没有尝试过用Ubuntu，有没有研究过两个系统间的区别，另外请问你们在OpenStack上是怎样对这些虚拟机监控的

A: 我们没有尝试过Ubuntu，因为公司生产环境上用的是CentOS。我们的中间件团队负责公司机器的监控，我们和监控团队配合，将监控的agent程序部署到宿主机和每个容器里，这样就可以当成虚拟机来进行监控。

当然，容器的数据是需要从cgroups里来取，这部分提取数据的工作，是我们来实现的。

Q：容器间的网络选型有什么建议，据说采用虚拟网卡比物理网卡有不小的性能损失，Docker自带的weaves和ovs能胜任吗

A: 容器的网络不建议用默认的NAT方式，因为NAT会造成一定的性能损失。之前我的分享中提到过，不需要启动iptables，Docker的性能接近物理机的95%。Docker的weaves底层应该还是采用了网桥或者Open vSwitch。建议可以看一下nova-docker的源码，这样会比较容易理解。

Q：静态IP通过LXC实现的吗

A: 静态IP的实现是在nova-docker的novadocker/virt/docker/vifspy中实现的。实现的原理就是通过ip命令添加 veth pair，然后用ip link set/ip netns exec等一系列命令来实现的，设置的原理和weaves类似。

Q：容器内的进程gdb你们怎么弄的，把gdb打包到容器内吗

A: 容器内的gdb不会有问题的，可以直接yum install gdb。

Q：共享存储能直接mount到容器里吗

A: 虽然没试过，但这个通过docker -v的方式应该没什么问题。

Q：不启动Docker Daemon的情况下，离线恢复Docker中的数据是咋做到的

A: 离线恢复的原理是用dmsetup create命令创建一个临时的dm设备，映射到Docker实例所用的dm设备号，通过mount这个临时设备，就可以恢复出原来的数据。

Q：Docker的跨物理机冷迁移，支持动态的CPU扩容/缩容，网络IO磁盘IO的限速，是怎么实现的，能具体说说吗

A：Docker的冷迁移是通过修改nova-docker，来实现OpenStack迁移的接口，具体来说，就是在两台物理机间通过docker commit，docker push到内部的registry，然后docker pull snapshot来完成的。

动态的CPU扩容/缩容，网络IO磁盘IO的限速主要是通过novadocker来修改cgroups中的cpuset、iops、bps还有TC的参数来实现的。

Q：请问你们未来会不会考虑使用Magnum项目，还是会选择Swarm

A：这些都是我们备选的方案，可能会考虑Swarm。因为Magnum底层还是调用了Kubernetes这样的集群管理方案，与其用Magnum，不如直接选择Swarm或者是Kubernetes。当然，这只是我个人的看法。

Q：你们的业务是基于同一个镜像么，如果是不同的镜像，那么计算节点如何保证容器能够快速启动

A：运维会维护一套统一的基础镜像。其他业务的镜像会基于这个镜像来制作。我们在初始化计算节点的时候就会通过docker pull把基础镜像拉到本地，这也是很多公司通用的做法，据我了解，腾讯、360都是类似的做法。

Q：做热迁移，有没有考虑继续使用传统共享存储的来做

A： 分布式存储和共享存储都在考虑范围内，我们下一步，就计划做容器的热迁移。

Q：请问你们是直接将公网IP绑定到容器吗，还是通过其他方式映射到容器的私有IP，如果是映射如何解决原本二层的VLAN隔离

A：因为我们是私有云，不涉及floating ip的问题，所以你可以认为是公网IP。VLAN的二层隔离完全可以在交换机上作。我们用Open vSwitch划分不同的VLAN，就实现了Docker容器和物理机的网络隔离。

Q：Device mapper dm-thin discard问题能说的详细些吗

A：4月份的时候，有两台宿主机经常无故重启。首先想到的是查看/var/log/messages日志，但是在重启时间点附近没有找到与重启相关的信息。而后在/var/crash目录下，找到了内核crash的日志vmcore-dmesgtxt。日志的生成时间与宿主机重启时间一致，可以说明宿主机是发生了kernel crash然后导致的自动重启。“kernel BUG at drivers/md/persistent-data/dm-btree-removec:181!”。 从堆栈可以看出在做dm-thin的discard *** 作(process prepared discard)，虽然不知道引起bug的根本原因，但是直接原因是discard *** 作引发的，可以关闭discard support来规避。

我们将所有的宿主机配置都禁用discard功能后，再没有出现过同样的问题。

在今年CNUTCon的大会上，腾讯和大众点评在分享他们使用Docker的时候也提到了这个crash，他们的解决方法和我们完全一样。

Q：阈值监控和告警那块，有高中低多种级别的告警吗，如果当前出现低级告警，是否会采取一些限制用户接入或者砍掉当前用户正在使用的业务，还是任由事态发展

A：告警这块，运维有专门的PE负责线上业务的稳定性。当出现告警时，业务方和PE会同时收到告警信息。如果是影响单个虚拟机的，PE会告知业务方，如果严重的，甚至可以及时下掉业务。我们会和PE合作，让业务方及时将业务迁移走。

Q：你们自研的container tools有没有开源，GitHub上有没有你们的代码，如何还没开源，后期有望开源吗，关于监控容器的细粒度，你们是如何考虑的

A：虽然我们目前还没有开源，单我觉得开源出来的是完全没问题的，请大家等我们的好消息。关于监控容器的细粒度，主要想法是在宿主机层面来监控容器的健康状态，而容器内部的监控，是由业务方来做的。

Q：请问容器的layer有关心过层数么，底层的文件系统是ext4么，有优化策略么

A：当然有关心，我们通过合并镜像层次来优化docker pull镜像的时间。在docker pull时，每一层校验的耗时很长，通过减小层数，不仅大小变小，docker pull时间也大幅缩短。

Q：容器的memcg无法回收slab cache，也不对dirty cache量进行限制，更容易发生OOM问题。----这个缓存问题你们是怎么处理的

A：我们根据实际的经验值，把一部分的cache当做used内存来计算，尽量逼近真实的使用值。另外针对容器，内存报警阈值适当调低。同时添加容器OOM的告警。如果升级到CentOS 7，还可以配置kmemlimit_in_bytes来做一定的限制。

Q：能详细介绍下你们容器网络的隔离

A：访问隔离，目前二层隔离我们主要用VLAN，后面也会考虑VXLAN做隔离。 网络流控，我们是就是使用OVS自带的基于port的QoS，底层用的还是TC，后面还会考虑基于flow的流控。

Q：请问你们这一套都是用的CentOS 65吗，这样技术的实现。是运维还是开发参与的多

A：生产环境上稳定性是第一位的。CentOS 65主要是运维负责全公司的统一维护。我们会给运维在大版本升级时提建议。同时做好虚拟化本身的稳定性工作。

Q：请问容器和容器直接是怎么通信的网络怎么设置

A：你是指同一台物理机上的吗我们目前还是通过IP方式来进行通信。具体的网络可以采用网桥模式，或者VLAN模式。我们用Open vSwitch支持VLAN模式，可以做到容器间的隔离或者通信。

Q：你们是使用nova-api的方式集成Dcoker吗，Docker的高级特性是否可以使用，如docker-api，另外为什么不使用Heat集成Docker

A：我们是用nova-docker这个开源软件实现的，nova-docker是StackForge上一个开源项目，它做为nova的一个插件，替换了已有的libvirt，通过调用Docker的RESTful接口来控制容器的启停等动作。

使用Heat还是NOVA来集成Docker业界确实一直存在争议的，我们更多的是考虑我们自身想解决的问题。Heat本身依赖的关系较为复杂，其实业界用的也并不多，否则社区就不会推出Magnum了。

Q：目前你们有没有容器跨DC的实践或类似的方向

A：我们已经在多个机房部署了多套集群，每个机房有一套独立的集群，在此之上，我们开发了自己的管理平台，能够实现对多集群的统一管理。同时，我们搭建了Docker Registry V1，内部准备升级到Docker Registry V2，能够实现Docker镜像的跨DC mirror功能。

Q：我现在也在推进Docker的持续集成与集群管理，但发现容器多了管理也是个问题，比如容器的d性管理与资源监控，Kubernetes、Mesos哪个比较好一些，如果用在业务上，那对外的域名解析如何做呢，因为都是通过宿主机来通信，而它只有一个对外IP

A： 对于Kubernetes和Mesos我们还在预研阶段，我们目前的P层调度是自研的，我们是通过etcd来维护实例的状态，端口等信息。对于7层的可以通过Nginx来解析，对于4层，需要依赖于naming服务。我们内部有自研的naming服务，因此我们可以解决这些问题。对外虽然只有一个IP，但是暴露的端口是不同的。

Q：你们有考虑使用Hyper Hypernetes吗 实现容器与宿主机内核隔离同时保证启动速度

A：Hyper我们一直在关注，Hyper是个很不错的想法，未来也不排除会使用Hyper。其实我们最希望Hyper实现的是热迁移，这是目前Docker还做不到的。

Q：你们宿主机一般用的什么配置独立主机还是云服务器

A：我们有自己的机房，用的是独立的服务器，物理机。

Q：容器跨host通信使用哪一种解决方案

A： 容器跨host就必须使用3层来通信，也就是IP，容器可以有独立的IP，或者宿主机IP+端口映射的方式来实现。我们目前用的比较多的还是独立ip的方式，易于管理。

Q：感觉贵公司对Docker的使用比较像虚拟机，为什么不直接考虑从容器的角度来使用，是历史原因么

A：我们首先考虑的是用户的接受程度和改造的成本。从用户的角度来说，他并不关心业务是跑在容器里，还是虚拟机里，他更关心的是应用的部署效率，对应用本身的稳定性和性能的影响。从容器的角度，一些业务方已有的应用可能需要比较大的改造。比如日志系统，全链路监控等等。当然，最主要的是对已有运维系统的冲击会比较大。容器的管理对运维来说是个挑战，运维的接受是需要一个过程的。

当然，把Docker当成容器来封装应用，来实现PaaS的部署和动态调度，这是我们的目标，事实上我们也在往这个方向努力。这个也需要业务方把应用进行拆分，实现微服务化，这个需要一个过程。

Q：其实我们也想用容器当虚拟机使用。你们用虚拟机跑什么中间件我们想解决测试关键对大量相对独立环境WebLogic的矛盾

A：我们跑的业务有很多，从前台的主站Web，到后端的中间件服务。我们的中间件服务是另外团队自研的产品，实现前后台业务逻辑的分离。

Q：贵公司用OpenStack同时管理Docker和KVM是否有自己开发Web配置界面，还是单纯用API管理

A：我们有自研的Web管理平台，我们希望通过一个平台管理多个集群，并且对接运维、日志、监控等系统，对外暴露统一的API接口。

Q：上面分享的一个案例中，关于26内核namespace的bug，这个低版本的内核可以安装Docker环境吗，Docker目前对procfs的隔离还不完善，你们开发的container tools是基于应用层的还是需要修改内核

A：安装和使用应该没问题，但如果上生产环境，是需要全面的考虑的，主要还是稳定性和隔离性不够，低版本的内核更容易造成系统 crash或者各种严重的问题，有些其实不是bug，而是功能不完善，比如容器内创建网桥会导致crash，就是network namespace内核支持不完善引起的。

我们开发的container tools是基于应用的，不需要修改内核。

Q：关于冗灾方面有没有更详细的介绍，比如离线状态如何实现数据恢复的

A：离线状态如何实现恢复数据，这个我在之前已经回答过了，具体来说，是用dmsetup create命令创建一个临时的dm设备，映射到docker实例所用的dm设备号，通过mount这个临时设备，就可以恢复出原来的数据。其他的冗灾方案，因为内容比较多，可以再另外组织一次分享了。你可以关注一下>

以上就是关于如何解决 U盘启动 Lunix 系统死机问题全部的内容，包括:如何解决 U盘启动 Lunix 系统死机问题、如何使用OpenStack，Docker和Spark打造一个云服务、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！