Ⅰ 数控中M90是什么意思
你好，在数控车床里面m90是主轴松开的意思，由于这个代码对于比较平常厂很少使用，一般只有机修员比较常用
Ⅱ Openstack 虚机实例操作总结
Openstack作为常见的IAAS服务，其最核心的对象就是虚机实例，而Openstack下支持的虚机操作有很多种，有些是特别常见的虚机操作比如创建虚机、启动虚机、删除虚机等，而有些虚机操作则是针对特定场景下比如出现故障而提供的保护/恢复虚拟机资源的各种解决方案，下面先通过一张图总体了解一下Openstack的各种虚机操作及及其应用场景：
文章余下部分将借助上图中常规操作和故障操作这两大应用场景来对Openstack各种虚机实例的操作一一展开说明。
所谓常规操作，这里是指日常对Openstack虚机最基本的操作，且Openstack集群及虚机运行状态良好的情况下。
创建虚机，Openstack专业术语：启动虚机实例，根据已经定义好的主机类型、存储资源、网络资源等从无到有新建一个虚拟机。如果底层的虚拟化基于KVM，相当于先编辑一个虚机的 XML 文件然后进行 DEFINE 。
以上两种操作后的虚机实例，都可以通过其他Openstack的接口重新恢复(Pause--> Unpause，Suspend--> Resume)虚机，并且显然经过Pause操作的虚机实例恢复要快的多。
对应Openstack Resize操作，用来修改虚机实例的规格，当原始的主机类型(Flavor)无法满足其上运行的业务需求时，通过新的Flavor在当前宿主机或者新的宿主机上重新启动一个新的虚机，但是这个虚机的资源比如网络资源、OS版本等还是跟之前的虚机是一样的，只是扩展了CPU Core数目、内存和磁盘大小，提高了虚机性能。
对应Openstack Snapshot操作，用来作备份恢复的，将某个状态下的虚机导出image并上传至Glance管理，方便以后通过快照来恢复一个出现故障的虚机，另外Openstack快照跟传统意义的快照不是一个含义。
对应Openstack Lock操作，用来作资源保护，如果为防止误操作或者不想让某些人操作虚机实例可以执行此操作，当然可以通过Unlock操作来解除锁定。
首先解释一下，这里的故障操作不是指错误操作或者误操作，而是Openstack虚机实例或者其它组件出现故障时应对的措施或者操作。
冷迁移(Migrate)和热迁移(Live Migrate)最大的区别在于将虚机实例从一个计算节点迁移到另一个计算节点的过程中是不是做了虚机关闭的操作。
对应Openstack Shelve操作，用作释放暂不使用的虚机资源。
对于暂时不用的虚机如前文所述可以通过Pause/Suspend来暂停以节约成本，不过这两种操作下虚机实例需要的比如CPU、内存等资源宿主机仍然要维护，如果想从底层来释放这些资源可以执行Shelve操作，它的原理是释放虚机之前先会对虚机做快照并上传Glance，然后才从宿主机删除虚机，当然如果想恢复则可以执行Unshelve操作。
当虚机实例因为某个文件系统误删或者权限导致虚机实例无法正常开启时，可以执行Rescue操作来尝试恢复：选择一个虚机image来引导虚机正常起来，同时把之前的系统盘作为数据盘挂载到起来的虚机OS下，修复好之后使用Unrescue操作从原启动盘重新引导虚机。
对应Openstack Rebuild操作，当虚机实例损坏无法正常开启，而一般的修复操作比如Rescue不起作用，此时可以考虑在原先虚机实例的基础上利用虚机镜像或者快照进行Rebuild操作，它的原理替换原先虚机实例的镜像文件，同时保持虚机其他比如网络资源、其他分配属性不变而实现虚机正常开启。
上述的操作都是在宿主机ok的情况下进行的，如果虚机实例的宿主机直接挂掉该怎么办呢？还好有Evacuate操作，它能够在当前宿主机宕掉的情况，将其上的虚机实例迁移到其它正常的计算节点，不过它需要满足共享存储(比如后端采用NFS、CEPH等)。
以上基本上就是目前Openstack所支持的对虚机实例的所有操作，实际使用中需要结合具体的业务场景。
Ⅲ 谁知道苏联时期民族迁移那事
斯大林执政后，进行了多次民族迁移决定，具体如下：
1 根据1936年4月28日苏联人民委员会第776—120号决议,从乌克兰迁移35820名“不可靠的”波兰人到哈萨克。
2 根据1937年7月17日联共(布)中央和人民委员会第103/1127—267号决议,把毗连伊朗、阿富汗、土耳其的苏联边境地带的各族居民迁往内地,例如1325名库尔德人被迁往吉尔吉斯和哈萨克。
3 30年代上半期日本占领中国东北后,苏联远东地区边界受到威胁。根据1937年8月21日苏联人民委员会和联共(布)中央第1428—326号决议,从远东(主要是滨海边疆区)迁移全部朝鲜人171781名到哈萨克等地,以防被日本人“利用”。
4 根据1938年10月8日苏联人民委员会第1084—269号决议,从阿塞拜疆边境地区迁移6000名伊朗人到哈萨克。
5 1939年斯大林出兵波兰,将乌克兰和白俄罗斯西部地区强行并入苏联。在建立苏维埃政权过程中,从那里迁移10%的居民,即1173180人到东部,其中波兰人389382名(1944年的数字),其余为德意志人、乌克兰人、白俄罗斯人等。
6 1940年波罗的海三国和比萨拉比亚并入苏联后,从立陶宛、拉脱维亚、爱沙尼亚、摩尔达维亚分别迁移工厂主、地主、资产阶级政府成员的家属3600人、6850人、9115人、27000人到国家东部地区。
7 根据1941年6月14日苏联内务人民委员部的命令,从爱沙尼亚、立陶宛、拉脱维亚、摩尔达维亚、乌克兰和白俄罗斯西部分别迁移犯有反革命罪等罪行的人3668名、12682名、9236名、22648名、9595名、27887名,至9月完成,接收地区是西伯利亚、哈萨克、科米自治共和国。
8 1939年初苏联有德意志人1427222名,主要分布在俄罗斯(700231人)和乌克兰(392458人)。1941年6月德国进攻苏联后,苏联的德意志人被看作是法西斯德国的内应。根据1941年8月12日苏联人民委员会和联共(布)中央第2060—935号联合决议和8月28日苏联最高苏维埃主席团第21—160号命令,将伏尔加河地区的德意志人迁移到西伯利亚、哈萨克和中亚各共和国。至10月28日从伏尔加河德意志自治共和国迁出446480人,该自治共和国被撤销。1941～1942年总共迁移德意志人1209430名。迁移行动一直持续到40年代末。
9 根据1941年8月26日、1942年3月9日列宁格勒战线军事委员会第196号和第00713号决议,从列宁格勒市和列宁格勒州迁移全部芬兰人,1942年4月完成,共迁走9000余人去西伯利亚。他们起初被当作“行政迁移者”,1944年末成为特种移民。
10 根据1943年10月12日苏联最高苏维埃主席团第115—136号决议和10月14日苏联人民委员会第1118—342号决议,以通敌为由迁移整个卡拉查伊民族,撤销卡拉查伊-切尔克斯自治州,总共迁移69267人去哈萨克和吉尔吉斯。
11 根据1943年12月27日苏联最高苏维埃主席团命令和12月28日苏联人民委员会第1432—425号决议,以通敌为由迁移整个卡尔梅克民族,撤销卡尔梅克自治共和国。结果有93139名卡尔梅克人被迁往西伯利亚。
12 根据1944年1月31日苏联国防委员会第5073号决议和2月21日苏联内务人民委员部第00193号命令,以通敌为由迁移整个车臣民族和印古什民族。共迁移车臣人393229名、印古什人91250名到哈萨克和吉尔吉斯。根据1944年3月7日苏联最高苏维埃主席团第116—102号命令,车臣-印古什自治共和国被撤销。
13 根据1944年3月5日苏联国防委员会第5309号决议,以“背叛行为”和“土匪活动”为由迁移整个巴尔卡尔民族。共迁移37107名巴尔卡尔人去哈萨克和吉尔吉斯。根据4月7日最高苏维埃主席团的命令,将卡巴尔达-巴尔卡尔自治共和国更名为卡巴尔达自治共和国。
14 根据1944年3月31日苏联内务人民委员部命令,迁移从事反苏活动的乌克兰民族主义者联盟和乌克兰起义军成员100300人到国家东部地区。
15 根据1944年4月2日和5月11日苏联国防委员会第5859号和5943号决议,将全部克里米亚鞑靼人迁往乌兹别克,罪名是“背叛行为”,共迁移180014人。1945年6月30日克里米亚自治共和国被撤销。
16 根据1944年6月2日苏联国防委员会第5984号决议,因通敌和反苏行为从克里米亚自治共和国迁移保加利亚人、希腊人、亚美尼亚人12422名、15040名、9621名到东部地区,同时迁移德意志人、意大利人、罗马尼亚人等共1000多名。
17 根据1944年6月24日苏联国防委员会第6100号决议,从克里米亚往乌兹别克迁移外籍希腊人3531名,从罗斯托夫州和克拉斯诺达尔边疆区迁移无国籍希腊人8300名,从格鲁吉亚、阿塞拜疆、亚美尼亚共迁移16375名希腊人到国家东部地区。
18 根据1944年7月31日苏联国防委员会第6279号决议,从格鲁吉亚毗连土耳其的边境地区迁移梅斯赫特土耳其人、库尔德人、赫姆申人(亚美尼亚人穆斯林)共91095人去乌兹别克、哈萨克和吉尔吉斯,他们被怀疑为“叛徒、土耳其的代理人”。1944年从外高加索总共迁移库尔德人4万名。
19 根据1945～1946年苏联政府一系列决议,迁移“弗拉索夫分子”(弗拉索夫将军领导的反苏的“俄国解放军”成员,由乌克兰人以及俄罗斯人等组成)到国家东部地区。至1947年中期共迁移118252人,显然有扩大化之嫌。
20 根据1947年9月10日苏联部长会议第3214—1050号决议,从乌克兰西部迁移乌克兰民族主义者联盟成员及其家属74898人到国家东部地区。至50年代初,总共迁移171566人。
21 根据1948年2月21日苏联部长会议第417—160号决议,从波罗的海三国迁移民族主义者、土匪、富农家庭的成员。这次代号为“春天”的行动于1948年5月22日开始,仅从立陶宛就迁移49331人去西伯利亚。根据1949年1月29日苏联部长会议第390—138号决议,再次从波罗的海三国迁移上述人员,分别从拉脱维亚、爱沙尼亚、立陶宛迁移42149人、20173人、31917人。1945～1949年共迁移拉脱维亚人38911名、立陶宛人80189名、爱沙尼亚人19237名。1940～1953年在国家北部和东部地区的特种移民中,来自拉脱维亚的有52541人;来自爱沙尼亚的有32540人;来自立陶宛的有118599人。
22 根据1949年4月6日苏联部长会议第129—467号决议,从摩尔达维亚迁移富农、地主、通敌者及其家属35050人到西伯利亚。
23 根据1949年5月29日苏联部长会议第2214—856号决议,从外高加索和黑海沿岸地区迁移希腊人6121名、梅斯赫特土耳其人49049名、其他民族及达什纳克党(亚美尼亚反革命组织)成员2510人到哈萨克、西伯利亚。根据1951年11月23日苏联部长会议第4893—号决议,从上述地区再次迁移余下的同类人员11504人到哈萨克。
24 根据1952年3月25日苏联部长会议第6435号决议,从白俄罗斯迁移富农及其家属4298人到哈萨克。
以上数据参见俄联邦国家档案馆档案,全宗P-9401、P-9479等;〔俄〕H· ·布盖:《贝利亚致斯大林:“遵照您的指示……”》，俄文版，莫斯科，20世纪俄罗斯社会研究者协会，1995年。
上述24次较大规模的行动共迁移约440万人,涉及民族20个以上,其中整个民族被迁移的有11个。当然这不是迁移行动的全部,还有一些小规模的迁移行动没有列入。关于移民的总人数,没有确切的统计数字,上引数字虽出自档案材料,但由于战时条件和迁移行动的紧急性,统计数字的混乱在所难免。苏联学者对移民总数的估计从布盖的320万人到麦德维杰夫的500万人不等,足见在移民数量的统计上出入之大。①
移民在路上一般要颠簸二三十天才能到达中亚或西伯利亚的移居地。移民列车严重超载,缺少食物和水,车厢里阴暗、寒冷(有些车厢本来是专门装运活牲畜用的),又没有医护人员,有时传染病流行,夺去了一些人的生命。究竟有多少人死于途中?官方文件很少涉及,而一些当事人的回忆录只能反映局部的情况,可以说至今还没有发现能回答这个问题的可靠史料。因此研究者们只能作大概的估计,例如有人估计途中病死几十万.
Ⅳ 如何对VMware vSphere vMotion虚拟机进行迁移的步骤方法
随着VMware在企业的快速使用，对于VMware的各种相关技术的诉求也成了很多用户的难题，今天就与大家分享一下VMware VSphere VMotion网络配置及虚拟机迁移方法。
分享两种迁移的方法：采用Storage vMotion迁移数据存储的方法；采用vSphere Web Client进行跨主机Storage vMotion迁移虚拟机的方法。
方法一、采用Storage vMotion迁移数据存储的方法和步骤
通过Storage vMotion，可以在虚拟机运行时将虚拟机及其磁盘文件从一个数据存储迁移到另一个数据存储，在通过 Storage vMotion迁移时，可以将虚拟机及其所有磁盘放置在同一位置，或者为虚拟机配置文件和每个虚拟磁盘选择单独的位置，但需要注意，通过 Storage vMotion迁移虚拟机时不会更改ESXi主机，而且虚拟机运行的主机必须有包括 Storage VMotion 的许可证。
通过Storage vMotion迁移虚拟机时并不进行有内存克隆，只进行简单的数据克隆，因此在Storage vMotion开始时，并没有主机的参与，只是单纯的文件在不同存储设备间克隆。VMware Storage VMotion允许以完全透明的方式将虚拟机的磁盘重新定位到不同的数据存储位置，而保持虚拟机处于运行状态且不停机，在移动虚拟机磁盘文件之前，Storage VMotion将虚拟机的“主目录”移到新的位置，“主目录”包含有关虚拟机的元数据信息，如配置文件、替换文件、日志文件，它然后会“自我VMotion”至新的 VM 主位置，完成主目录迁移后，会对磁盘进行移动；首先，Storage VMotion为每个要迁移的虚拟机磁盘创建一个“子磁盘”，启动迁移操作后，所有磁盘写入都将转到此“子磁盘”，其次，将“父级”或原始虚拟磁盘从旧的存储设备复制到新的存储设备，然后，将正在捕获写入操作的子磁盘与新复制的父磁盘重新建立父子关系，最后，将子磁盘整合到新的父磁盘，并且ESX 主机现在会重新转到新的父磁盘位置，在切换主目录和磁盘迁移的过程，创建子磁盘和父磁盘、重建父子关系以及整合子磁盘将在不到两秒的时间里发生，速度之快令应用程序用户根本察觉不到。
通过 Storage vMotion迁移时，可以将虚拟磁盘从厚置备转换为精简置备或从精简置备转换为厚置备，无需虚拟机停机便可升级数据存储，也可以把虚拟机从存储设备上移开，从而对存储设备进行维护和重新配置，也可以可以使用 Storage vMotion手动将虚拟机或虚拟磁盘重新分配到不同的存储卷，以平衡容量或提高性能。
1、点击‘新建虚拟机-1’，它是一台正在运行的虚拟机，并且VMware Tools在虚拟机已经正确安装并激活，并且虚拟的数据文件是在esxi02的本地磁盘上，我们将此虚拟机迁移到共享存储VMware01中。
2、鼠标右击‘新建虚拟机-1’，在弹出的菜单中选择‘迁移’。
3、在弹出迁移向导中，点选‘选择迁移类型’的‘更改数据存储’，将虚拟机移到另一存储上，单击‘下一步’。
4、选择“目标数据存储”，确认兼容性为“验证成功”（下方的兼容性显示框），在选择虚拟磁盘格式里，选择迁移后的磁盘格式（“精简置备”为用多少占多少，“厚格式”立刻在存储上分配虚拟机所置空间）或者选择与原格式相同。
5、查看当前设置，单击“完成”按钮，开始Storage VMotion。
6、虚拟正在迁移中，且需要注意迁移过程中，虚拟机不中断、不重启。
方法二、采用vSphere Web Client进行跨主机Storage vMotion迁移虚拟机的方法和步骤
使用vSphere Web Client管理vSphere虚拟化平台，是vSphere5.1所推荐的，在vSphere Web Client中进行Storage vMotion可以同时迁移主机和数据存储，而在迁移过程中不中断虚拟的运行，可以使用跨主机 Storage vMotion 将虚拟机同时迁移到其他主机和数据存储，此外，可在不受可访问性限制的情况下迁移虚拟机，这与 Storage vMotion 不同，Storage vMotion 要求一个主机能够同时访问源数据存储和目标数据存储。
跨主机 Storage vMotion 不要求环境中存在共享存储，在目标群集计算机可能无权访问源群集存储的情况下执行跨群集迁移时，该功能非常有用。在通过跨主机 Storage vMotion 进行迁移期间，虚拟机工作流程将继续运行，可将虚拟机及其所有磁盘放置在同一位置，也可为虚拟机配置文件和每个虚拟磁盘选择单独的位置，此外，可将虚拟磁盘从厚置备更改为精简置备格式或从精简置备更改为厚置备格式，对于虚拟兼容性模式 RDM，可迁移映射文件或从 RDM 转换成 VMDK。如图7
将虚拟机移至另一主机，并将其磁盘或虚拟机文件夹移至另一数据存储，可使用冷迁移或热迁移更改主机和数据存储，热迁移是 Storage vMotion与称为跨主机 Storage vMotion 的 vMotion 的组合，在vSphere Client里是无法进行跨主机 Storage vMotion 迁移，要求必须关闭虚拟机的电源才能进行迁移，
1、在vSphere Web Client中，选择要迁移的虚拟机（如：新建虚拟机-1），鼠标右键，选择‘迁移’。
2、进入迁移向导，在‘选择迁移类型’中选择‘更改主机和数据存储’，点击下一步。
3、在‘选择目标资源’选择（注：迁移的目标必须要通过兼容性的检测，点选后下方能显示），之后点击下一步。
4、在‘选择目标存储’，这里选择本地磁盘。点击下一步。
5、在‘选择vMotion优先级’，然后点击下一步。
6、在‘调度选项’进行虚拟机配置，设置是否立刻执行或者按计划执行,点击下一步
7、需配置调度程序。
8、检查设置，点击下一步开始迁移。
9、在操作面板中可以看到虚拟机迁移的过程（各种信息和百分比）。
10、在虚拟机中使用Ping命令来检测虚拟机的中断情况，实际上在迁移过程中只中断了1秒钟而已，所以不影响整个虚拟机运行。
11、成功完成迁移。
Ⅳ 如何使用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这个临时设备，就可以恢复出原来的数据。其他的冗灾方案，因为内容比较多，可以再另外组织一次分享了。你可以关注一下http://mogu.io/，到时候我们会分享出来。
Q：贵公司目前线上容器化的系统，无状态为主还是有状态为主，在场景选择上有什么考虑或难点?
A：互联网公司的应用主要是以无状态的为主。有状态的业务其实从业务层面也可以改造成部分有状态，或者完全不状态的应用。不太明白你说的场景选择，但我们尽量满足业务方的各种需求。
对于一些本身对稳定性要求很高，或对时延IO特别敏感，比如redis业务，无法做到完全隔离或者无状态的，我们不建议他们用容器。
多进程好还是多线程好等等，并不是说因为Spark很火就一定要使用它。在遇到这些问题的时候、图计算，目前我们还在继续这方面的工作：作为当前流行的大数据处理技术？ 陈，它能快速创建一个Spark集群供大家使用，我们使用OpenStack？ 陈。 问，Hadoop软硬件协同优化，在OpenPOWER架构的服务器上做Spark的性能分析与优化：您在本次演讲中将分享哪些话题。 问。多参与Spark社区的讨论。曾在《程序员》杂志分享过多篇分布式计算、Docker和Spark打造SuperVessel大数据公有云”，给upstrEAM贡献代码都是很好的切入方式、SQL，并拥有八项大数据领域的技术专利，MapRece性能分析与调优工具。例如还有很多公司在用Impala做数据分析：企业想要拥抱Spark技术，对Swift对象存储的性能优化等等。例如与Docker Container更好的集成，大数据云方向的技术负责人，Spark还是有很多工作可以做的？企业如果想快速应用Spark 应该如何去做，具体的技术选型应该根据自己的业务场景，Docker Container因为在提升云的资源利用率和生产效率方面的优势而备受瞩目，高性能FPGA加速器在大数据平台上应用等项目，再去调整相关的参数去优化这些性能瓶颈，一些公司在用Storm和Samaza做流计算： 相比于MapRece在性能上得到了很大提升？
Ⅵ openstack虚拟机热迁移和冷迁移的区别
就是一个关机迁移，一个不关机迁移。
Ⅶ openstack云主机冷迁移
1：开启nova计算节点之间互信
冷迁移需要nova计算节点之间使用nova用户互相免密码访问
默认nova用户禁止登陆，开启所有计算节点的nova用户登录shell。
2：修改控制节点nova.conf
3:修改所有计算节点
4：dashboard上进行操作