centos vlan状态？centos查看服务状态

centos优点

概述一下，centos与redhat的区别和优缺点？

CentOS是一种基于RedHat企业级操作系统代码（RHEL）构建的操作系统，因此它与RedHat具有许多共同之处。但是，它们之间有一些主要区别：

1.支持：RedHat是一种商业操作系统，需要订阅才能获得支持和更新。CentOS则是一个社区版的发行版，完全免费，并不需要购买订阅或付费支持计划。

2.更新：RedHat一般会在发布后的数年内提供更新和支持，而CentOS的重要更新则可能要比相应的RHEL版本稍晚一些。

3.品质保证：RedHat是一种经过广泛测试和验证的操作系统，而CentOS则更加注重稳定性和可靠性。

4.应用场景：RedHat更适合高性能、高安全性和商业关键任务。CentOS则更适合个人使用、中小型企业、组织以及一些开发人员等用户群体。

5.社区：CentOS是一个社区驱动的项目，社区用户可以对代码进行修改和分发。RedHat则更多的是企业驱动，用户只能使用其已发布的产品。

以下是他们各自的优缺点：

RedHat的优点：

-专业的技术支持和服务

-更长的支持周期

-一流的安全性和稳定性

-适合企业关键任务使用

RedHat缺点：

-需要购买订阅才能获得支持和更新

-软件更新速度可能较慢

-价格相对较高

CentOS的优点：

-免费使用和更新

-非常稳定和可靠

-社区活跃，有更多的社区支持和帮助

-拥有与RHEL相似的功能和性能

CentOS的缺点：

-不提供商业支持

-更新可能比RHEL版本稍慢

-对于一些生产环境来说，不如RedHat稳定

centos最小化安装优点

（1）Linux系统的第一个进程（pid=1）为init：

Linux操作系统的启动首先从BIOS开始，接下来进入bootloader，由bootloader载入内核，进行内核初始化。内核初始化的最后一步就是启动pid为1的init进程。这个进程是系统的第一个进程。它负责产生其他所有用户进程。

（2）init进程是所有进程的祖先，不可以kill（也kill不掉）

init以守护进程方式存在，是所有其他进程的祖先。init进程非常独特，能够完成其他进程无法完成的任务。Init系统能够定义、管理和控制init进程的行为。它负责组织和运行许多独立的或相关的始化工作(因此被称为init系统)，从而让计算机系统进入某种用户预订的运行模式。

（3）大多数linux发行版的init系统是和systemV相兼容的，被称为sysvinit

sysvinit就是systemV风格的init系统，顾名思义，它源于SystemV系列UNIX。它提供了比BSD风格init系统更高的灵活性。是已经风行了几十年的UNIXinit系统，一直被各类Linux发行版所采用。

（1）CentOS5

（2）CentOS6

（1）优点

sysVinit运行非常良好，概念简单清晰，它主要依赖于shell脚本。

（2）缺点

按照一定的顺序执行--启动太慢、很容易夯（hang）住，fstab与nfs挂载问题

说明：CentOS6采用了Upstart技术代替sysvinit进行引导，Upstart对rc.sysinit脚本做了大量的优化，缩短了系统初始化时的启动时间，但是CentOS6为了简便管理员的操作，Upstart的很多特性并没有凸显或者直接不支持，因此在CentOS6中的服务启动脚本还是以原来的sysv的形式提供的，

（1）CentOS6

（2）Ubuntu14

说明：systemd技术的设计目标是克服sysvinit固有的缺点，提高系统的启动速度，和sysvinit兼容，降低迁移成本，

做主要的优点：并行启动

（1）RedHat7/CentOS7

（2）Ubuntu15

方法1（在装系统时修改）：

在安装系统的时候配置,修改内核选项：net.ifnames=0biosdevname=0

方法2（装系统时忘记修改，装系统后修改）：

（1）编辑网卡

#cd/etc/sysconfig/network-scripts/#mvifcfg-ens160ifcfg-eth0#mvifcfg-ens192ifcfg-eth1#vimifcfg-eth0TYPE=EthernetBOOTPROTO=noneDEFROUTE=yesIPV4_FAILURE_FATAL=noIPV6INIT=yesIPV6_AUTOCONF=yesIPV6_DEFROUTE=yesIPV6_FAILURE_FATAL=noIPV6_ADDR_GEN_MODE=stable-privacyNAME=eth0#网卡名称改为eth0DEVICE=eth0#设备名称改为eth0ONBOOT=yesIPADDR=xxx.xxx.x.xxPREFIX=24GATEWAY=xxx.xxx.x.xDNS1=xxx.xxx.x.xIPV6_PEERDNS=yesIPV6_PEERROUTES=yesIPV6_PRIVACY=no注：删掉网卡内的UUID=176582f7-d198-4e4f-aab0-34ab10d17247通用唯一识别码和HWADDR=00:0c:29:a5:3f:39MAC地址这两行。所有网卡都需要修改

（2）编辑grub文件

[root@localhostnetwork-scripts]#cp-a/etc/sysconfig/grub/etc/sysconfig/grub.bak#备份文件[root@localhostnetwork-scripts]#vim/etc/sysconfig/grubGRUB_TIMEOUT=5GRUB_DISTRIBUTOR="$(sed's,release.*$,,g'/etc/system-release)"GRUB_DEFAULT=savedGRUB_DISABLE_SUBMENU=trueGRUB_TERMINAL_OUTPUT="console"GRUB_CMDLINE_LINUX="crashkernel=autonet.ifnames=0biosdevname=0rhgbquiet"#这行添加net.ifnames=0biosdevname=0GRUB_DISABLE_RECOVERY="true"

（3）生成启动菜单

[root@localhostnetwork-scripts]#grub2-mkconfig-o/boot/grub2/grub.cfgGeneratinggrubconfigurationfile...Foundlinuximage:/boot/vmlinuz-3.10.0-514.el7.x86_64Foundinitrdimage:/boot/initramfs-3.10.0-514.el7.x86_64.imgFoundlinuximage:/boot/vmlinuz-0-rescue-7d9a96ac2162427d937e06ede5350e9eFoundinitrdimage:/boot/initramfs-0-rescue-7d9a96ac2162427d937e06ede5350e9e.imgdone

然后重启服务器：reboot，重启服务器后查看网卡信息，

再安装操作系统的时候使用的最小化安装，有很多包没有安装，使用时发现好多命令没有如{vim、wget、tree...等}，下面就安装命令，可以根据需求自行调整。

yum-yinstallwgetnet-toolsscreenlsoftcpdumpncmtropenssl-develvimbash-completionlrzsznmaptelnettreentpdateiptables-services

rpm-ivh

需要开机自启动的脚本或者配置，可以放在/etc/rc.local里，但是发现并没有执行，下面我们看一下原因。

#ll/etc/rc.locallrwxrwxrwx1rootroot13Jan523:31/etc/rc.local-rc.d/rc.local#发现是个软连接文件#ls-l/etc/rc.d/rc.local-rw-r--r--1rootroot473Oct2011:07/etc/rc.d/rc.local#问题在这里，没有执行权限#chmod+x/etc/rc.d/rc.local#添加执行权限#ls-l/etc/rc.d/rc.local-rwxr-xr-x1rootroot473Oct2011:07/etc/rc.d/rc.local注：这样添加在rc.local里的开机自启动配置就可以执行了。

linux系统下都有一个默认的超级管理员root，ssh服务的默认端口是22，圈内都知道，那么接下来我们可以修改一下我们的默认端口和禁止root用户远程登录，初步提高一下服务器的安全

1、首先修改ssh的默认端口#sed-i"s#\#Port22#Port53226#g"/etc/ssh/sshd_config#端口可以改成1-65535之间任意端口，建议改成较大的端口，因为一万以内的端口常用的服务有占用，防止冲突（需要注意的是：这个端口要记住，否则连接不上服务器）2、禁止root用户远程登陆a）：添加一个普通用户并设置密码（注：这一步必须执行，否则将造成远程连接不上服务器）#useraddxxx#添加xxx用户#echo"pass"|passwd--stdinxxx#给xxx用户设置密码为passb)：修改ssh服务配置文件并撑起服务#sed-i's/#PermitRootLoginyes/PermitRootLoginno/'/etc/ssh/sshd_config#systemctlrestartsshd

此时断开当前连接或者新开一个连接就会发现使用root用户连接不上服务器了，莫慌，使用xxx用户连接然后切换到root用户即可

SELinux(Security-EnhancedLinux)是美国国家安全局（NSA）对于强制访问控制的实现，说白了就是安全机制，当然如果会配置的话建议配置更好，这里就介绍一下如何关闭吧，哈哈哈。

#sed-i.bak's#SELINUX=enforcing#SELINUX=disabled#g'/etc/selinux/config#修改配置文件需要重启服务器配置才会生效，如何立即生效那？#setenforce0#关闭SELinux立即生效，重启服务器后配置失效。

防火墙，不解释，内网服务建议关掉，对外开放的服务器需要配置规则，这里先关掉，关于防火墙配置规则等待后续更新。

#systemctlstopfirewalld#临时关闭#systemctldisablefirewalld#永久关闭

装机后主机名默认为localhost，这里个人想更改自己的主机名，在不搭建内网DNS的情况，能通过主机名找到本机的IP地址。

#hostnamectlset-hostnameweb01#设置主机名为web01，这样设置连配置文件里都修改了

#echo"192.168.6.6web01"/etc/hosts#192.168.6.6为本机IP

如果是云服务器，这步优化基本都被作了，如果是物理机需要执行此步

#sed-i.bak's@#UseDNSyes@UseDNSno@g;s@^GSSAPIAuthenticationyes@GSSAPIAuthenticationno@g'/etc/ssh/sshd_config#systemctlrestartsshd

说明：GSSAPIAuthentication参数是用于Kerberos验证的，而对于绝大多数人来说，不可能使用这种验证机制的，所以要注意把他们停掉。然后重启服务会发现远程连接速度有明显提升

设置服务器字符集，国际通用utf-8，根据自身业务来定

#localectlstatus#查看当前字符集SystemLocale:LANG=en_US.UTF-8VCKeymap:usX11Layout:us#localectlset-localeLANG=zh_CN.UTF-8#修改字符集为zh_CN.UTF-8，命令行和配置文件都生效#cat/etc/locale.conf#查看配置文件LANG=zh_CN.UTF-8

CentOS7.2系统默认最大打开文件限制为1024，每建立一个TCP连接既浪费一个限制（这里不细讲，后续会更新详细说明），为了提升服务器性能，所以我们要增加打开文件的最大限制

#ulimit-n#默认大小1024#echo"*softnofile65536"/etc/security/limits.conf#xi修改最大限制为65535#echo"*hardnofile65536"/etc/security/limits.conf

时间同步，这里不多说了，向OpenStack的所有节点的时间不一致会导致创建不了虚拟机，也会有其他的问题，不多说，我们生产上所有服务器时间都是同步的。

#yuninstall-yntpdate#前面已经装过了#ntpdatentp1.aliyun.com#这里同步的是aliyun的时间，公司内部建议自己搭建时间服务器（减少流量、广播等），然后加入crontab即可，内网时间服务器等待后续更新。

TCP断开连接时会有一个等待时间为2msl（60秒）对应的状态为TIME_WAIT，如果业务并发较大的话会有很多的TIME_WAIT状态(详细等待后续更新)，如何来解决那？

#cat/proc/sys/net/ipv4/tcp_timestamps#时间戳，默认是开启的#cat/proc/sys/net/ipv4/tcp_tw_reuse#连接复用，tcp_timestamps是开启的状态下是可以开启的，1为开启，默认是关闭的状态。#cat/proc/sys/net/ipv4/tcp_tw_recycle#socket快速回收，net网络状态下不可以开启，负载均衡上不可以打开，读者根据自身情况开启或关闭，默认为关闭状态。

好了，服务器优化就介绍到这里，以上优化不分先后顺序！！

Centos7系统有什么特点？

CentOS7是一款基于RedHatEnterpriseLinux（RHEL）开发的免费开源操作系统。它具有以下特点：

兼容性高：CentOS7兼容大多数硬件，可以运行在多种计算机硬件平台上，包括x86、x64和ARM等处理器体系结构。

稳定性好：CentOS7采用了RHEL的源代码，在稳定性方面有很大优势。

安全性高：CentOS7安装时会自动开启防火墙和SELinux，可以有效保护系统安全。

支持软件包管理：CentOS7采用了YUM包管理器，可以方便地安装、升级和卸载软件包。

网络功能强大：CentOS7提供了丰富的网络功能，包括虚拟网络、Bonding、VLAN等，可以满足各种网络需求。

免费开源：CentOS7是一款免费开源的操作系统，可以免费下载使用。

如何使用OpenStack,Docker和Spark打造一个云服务

蘑菇街基于 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基础上自研了编排调度等组件，支持应用的弹性伸缩、灰度升级等功能，并支持一定的调度策略，从而实现了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 6.5。曾经有个业务方误以为他用的Docker容器是物理机，在Docker容器里面又装了一个Docker，瞬间导致内核crash，影响了同一台物理机的其他Docker容器。

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

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

经过分析，发现是内核对pid的隔离性支持不完善，pid_max(/proc/sys/kernel/pid_max)是全局共享的。当一个容器中的pid数目达到上限32768，会导致宿主机和其他容器无法创建新的进程。最新的4.3-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层的动态路由，通过域名的方式，或者名字服务来暴露出对外的接口。我们能够做到基于容器的灰度升级，和弹性伸缩。

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

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/vifs.py中实现的。实现的原理就是通过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-dmesg.txt。日志的生成时间与宿主机重启时间一致，可以说明宿主机是发生了kernel crash然后导致的自动重启。“kernel BUG at drivers/md/persistent-data/dm-btree-remove.c: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，还可以配置kmem.limit_in_bytes来做一定的限制。

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

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

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

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

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的持续集成与集群管理，但发现容器多了管理也是个问题，比如容器的弹性管理与资源监控，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：上面分享的一个案例中，关于2.6内核namespace的bug，这个低版本的内核可以安装Docker环境吗，Docker目前对procfs的隔离还不完善，你们开发的container tools是基于应用层的还是需要修改内核?

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

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

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

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

Q：贵公司目前线上容器化的系统，无状态为主还是有状态为主，在场景选择上有什么考虑或难点?

A：互联网公司的应用主要是以无状态的为主。有状态的业务其实从业务层面也可以改造成部分有状态，或者完全不状态的应用。不太明白你说的场景选择，但我们尽量满足业务方的各种需求。

对于一些本身对稳定性要求很高，或对时延IO特别敏感，比如redis业务，无法做到完全隔离或者无状态的，我们不建议他们用容器。

多进程好还是多线程好等等，并不是说因为Spark很火就一定要使用它。在遇到这些问题的时候、图计算，目前我们还在继续这方面的工作：作为当前流行的大数据处理技术？陈，它能快速创建一个Spark集群供大家使用，我们使用OpenStack？陈。问，Hadoop软硬件协同优化，在OpenPOWER架构的服务器上做Spark的性能分析与优化：您在本次演讲中将分享哪些话题。问。多参与Spark社区的讨论。曾在《程序员》杂志分享过多篇分布式计算、Docker和Spark打造SuperVessel大数据公有云”，给upstrEAM贡献代码都是很好的切入方式、SQL，并拥有八项大数据领域的技术专利，MapReduce性能分析与调优工具。例如还有很多公司在用Impala做数据分析：企业想要拥抱Spark技术，对Swift对象存储的性能优化等等。例如与Docker Container更好的集成，大数据云方向的技术负责人，Spark还是有很多工作可以做的？企业如果想快速应用Spark应该如何去做，具体的技术选型应该根据自己的业务场景，Docker Container因为在提升云的资源利用率和生产效率方面的优势而备受瞩目，高性能FPGA加速器在大数据平台上应用等项目，再去调整相关的参数去优化这些性能瓶颈，一些公司在用Storm和Samaza做流计算：相比于MapReduce在性能上得到了很大提升？

虚拟化技术实战之:CentOS7 KVM+VLAN

本文将详细介绍如何在 CentOS7上配置 KVM与 VLAN技术，为部署云平台 OpenStack做好准备。先从 VLAN的基础知识开始，通过实践操作理解其工作原理。

环境要求：

一台物理服务器安装 CentOS7u3。

操作步骤如下：

首先，为了安装 VLAN相关命令，需要配置额外的软件仓库。

[root@wing~]# yum install epel-release-y

[root@wing~]# yum install vconfig-y

接着，加载必要的内核模块。

[root@wing~]# modprobe 8021q

模块加载成功后，通过命令创建 VLAN网络。

[root@wing~]# vconfig add ens33 10

[root@wing~]# vconfig add ens33 20

创建网桥，并将 VLAN接口连接到网桥。

[root@wing~]# brctl addif br10 ens33.10

[root@wing~]# brctl addif br20 ens33.20

使用 virt-manager或命令行方式创建虚拟机。

将虚拟机连接到 VLAN网络。

[root@wing~]# brctl addif br10 vnet0

[root@wing~]# brctl addif br10 vnet1

[root@wing~]# brctl addif br20 vnet2

[root@wing~]# brctl addif br20 vnet3

配置虚拟机网络接口。

#vim/etc/sysconfig/network-scripts/ifcfg-br10

#vim/etc/sysconfig/network-scripts/ifcfg-ens33.10

测试网络连接，确保 VLAN网络配置正确。

分别在虚拟机上配置 IP地址。

通过 ping命令验证网络连接。

vnet0和 vnet1能相互 ping通。

vnet2和 vnet3能相互 ping通。

vnet0和 vnet2不能相互 ping通。

vnet1和 vnet3不能相互 ping通。

至此，完成了 CentOS7上的 VLAN配置。如果在物理交换机上测试，可以配置相同 VLAN并进行验证。

最后，将配置写入到系统文件，确保重启后配置依然生效。

#vim/etc/rc.local

#vim/etc/sysconfig/network-scripts/ifcfg-br10

#vim/etc/sysconfig/network-scripts/ifcfg-ens33.10

以上步骤详细介绍了如何在 CentOS7上配置 KVM与 VLAN技术，为后续搭建云平台 OpenStack做好准备。通过实践操作，深入理解 VLAN网络的工作原理和配置细节。