OpenStack 部署分布式应用的一个坑

之前基于 OpenStack 部署了一个云，运营下来一段时间下来还算正常，出现了各种问题也是意料之内，基本都很快搞定。

搞云计算的人嘛，就得懂得多一些、深一些不是：）

但有一天有个客户找上来反映了一个小问题，虽然最终解决掉，却引发了我的深思。

问题

客户的应用很简单，也是在我们的平台上申请了虚机，然后自己用 keepalived 为后面的某 db 业务提供 HA 保障。一切运行的都很正常，突然有一天，死活访问不通 db 了。

通过查看日志，发现故障发生前 keepalived 发生了切换，灾备节点被切换了。一开始怀疑是 keepalived 配置问题，检查后发现都正常，而且灾备节点确实也拿到地址了。我们搞运维的同学怀疑是网络问题，但底下排查了半天，也没找到原因，而且别的业务都跑的好好的。

分析和解决

出现问题肯定不会是莫名其妙的，我仔细回想了 VRRP 的原理和 Neutron 的实现。keepalived 基于 VRRP 来切换主从节点，被激活的节点会抢到配置的虚地址。然而，neutron 里面为了防止虚机作恶，会记录每个虚机启动时候分配的 IP 和 Mac，并用这个地址来过滤，避免出现篡改源地址的恶意流量。好了，那问题来了，neutron 并不知道某个虚地址其实是在两个 port 上都可能出现的，就会阻碍切换后的灾备节点流量通信。

问题定位到，就好解决了，直接改 iptables 规则，或者开启 Allowed-Address-Pairs (https://review.openstack.org/#/c/38230/) 即可。

进一步思考

从应用的角度看，VRRP 这种切换地址机制毫无问题；从 OpenStack 角度看，你申请一个虚机配置好了地址后，我只允许已知地址的流量出来，也是正常的。但偏偏两个结合到一起就有了问题。这根子上还是在于上层应用和底层平台之间的整合出现了偏差。其实系统就是这样，俩都正常的组件，放一起不出问题的概率很小，这也是为啥接口设计很关键。

我们一直说，要懂业务，要理解业务，其实也是避免设计出的产品跟真实的需求出现偏差。

首先，客户往往并不懂技术（甚至自己都不懂业务），这意味着他们很难用准确的语言描述清楚自己的真正需求（甚至自己都不知道真正需求是啥）。这就需要提供服务的团队要做到比客户更懂自己的业务，这是赢得客户信任的一个极大的优势。懂得从客户需求到业务流程到底下各种技术栈的灵活运用，这才是优秀的技术人员。

另外，就是产品的形态很重要，为什么现在云有 IaaS、PaaS、SaaS 等多种分类，其实这不同的产品形态都是针对不同的客户群体，满足不同的业务需求。呈现细节越少，意味着灵活性越差，但客户使用难度会降低。但无论是那种形态，都应该有严格的范围限制和操作保障，要让完全不懂技术的人能成功操作，甚至各种误操作也能纠正过来。在这点上，OpenStack 是做得很差的，这也是为什么基于 OpenStack 做云服务，首要任务是替换掉 Horizon。极简设计和极繁设计，无所谓高低，合适最好。

最后就是要选择合适的工具。现在开源特别发达，甚至同一个应用场景会出现数个优秀的开源产品，光看特性都是很吸引人。这个时候，选择就很重要了，最看重啥特性？二次开发的难度有多大？针对需求选这个是否合适？选择对了，事半功倍，反之往往陷入各种坑难以自拔。

集群负载均衡技术概述

集群负载均衡技术（Load Balancing）是目前互联网后端服务的关键技术，是互联网系统演化到现在这样巨大规模的基础。

客观地说，负载均衡是一个门槛相当不低的领域，已有技术主要包括硬件方案和软件方案。简单说，硬件方案性能好，但是昂贵；软件方案性能差，但是成本相对可控。

硬件方案代表为F5、Ctrix、A10、Redware 等 LB 厂商的产品，每年市场营收额高达百亿。

开源的软件实现方案也有不少，知名的包括 HAProxy、Nginx、LVS 等。

在实际大规模高性能的场景下，往往很难靠单一方案实现可靠的负载均衡服务。

很多 LB 厂家现在已经不再使用“负载均衡设备”这个术语了，改叫做应用分发（ADC、ADN）设备（甚至直接叫做 4-7 层交换机），但在这些设备中的最为基础和关键的技术仍然是对海量流量进行处理的负载均衡技术。

实际上，从客户端是否能感知或参与负载均衡的过程来区分，可以首先将负载均衡技术大概分为两大类：客户端可感知的负载均衡和客户端透明的负载均衡。当然，两类技术又可以进一步地结合起来使用。

客户端可感知负载均衡

顾名思义，客户端主动参与负载均衡过程，可以感知负载均衡存在。

典型的例子是一些客户端应用，需要动态获知服务地址。从这个意义上看，不少 P2P 应用都属于该范畴。

基本的过程可以为，客户端先向某个控制（Control）服务器发起请求，获取业务（Service）服务器地址（域名或者 IP 地址）的列表。获取列表成功后，本地按照某种均衡策略向这些业务服务器发出请求。

这样做的好处显而易见，可以降低对服务器端进行负载均衡的要求，甚至服务端可以不需要再进行负载均衡，简单资源池即可。

技术难点主要在于客户端和服务端之间的信息同步。比如业务服务器池调整后信息怎么及时更新到客户端；某些负载均衡策略需要获取实时服务器的状态信息，等等。

具体实现上，往往需要客户端和服务端进行一些配合。针对某些特定的业务场景，可以进行一些调整和优化，例如 Yahoo 就在某些互联网业务中使用了这种模式。

桌面时代的客户端往往受控性差，情况比较复杂，这种模式实现难度较大。

现在移动互联网发展起来后，客户端 APP 的可控性大大提高，比较看好这种模式的应用前景。

客户端透明负载均衡

客户端透明负载均衡实际上又包括很多层面的技术，这里都统归为一类。不同实现可能放在不同地方（运营商或者服务商等），但原理都是一致的，核心都是借用了“Overlay”的思想（计算机行业的所有问题，基本都可以通过引入新的层来实现）。

下面从客户端发出请求后的完成流程来看，可以在哪些步骤实现负载均衡。

DNS 层

首先，客户端会向某个业务服务器的域名发起请求，要先解析这个域名为具体的 IP 地址。

域名解析这块能做的事情很多，但大致上要么是运营商本地应答，要么运营商扔给服务商的域名服务器。

如果是前者（一般情况下）的话，运营商会通过本地 cache 进行查询，无命中则扔给上层域名服务或者服务商。

域名解析的过程直接决定了进行 LB 的效果。这里就有问题了，由于域名是由运营商进行维护答复的，一旦发生变化，服务商怎么去快速地调整呢，传统域名更新的方式可达数分钟甚至数小时的时延。

一种思路是跟运营商去谈，所有相关请求都服务商自己来处理或者怎么能合作进行快速更新；一种是将请求想办法绕开运营商，隧道给自己（又是一种 Overlay），腾讯的 HttpDNS 就是这个思路，域名解析不走传统 DNS 协议，而是通过 HTTP 请求来实现。

总结下，基于 DNS 的 LB 方式是比较简单直接，容易实现的，但是存在问题也不少，主要有多级 DNS 结构不可控，容易分布不均匀，和难以及时刷新等等。

IP 层

拿到 IP 之后，客户端可以发起请求到对应的 IP 地址，之后就等着接收到源地址为该 IP 的响应数据包。很自然的，可以在 LB 上替换掉这个地址，发给后端的真实服务池。这也是目前大量三层负载均衡器的基本原理。

实践中，前面挡一层 DNS 均衡，后面进行三层负载均衡，已经可以支持很大规模的场景了。

典型的，LVS 是这一类的软件方案，但具体实现上，LVS 支持三种模式：NAT（Network Address Translation）、DR（Direct Routing）、TUN（IP Tunneling）。NAT 就是把 LB 做 NAT 网关；DR 和 TUN 是想办法把流量转发给后端服务器，让后面服务器自己处理，形成三角路由。

首先，负载均衡器上会带有一个 VIP（用户看到的服务地址）和 DIP（用于探测后端服务的存活），后端真实服务器上会有 RIP。

NAT 模式下，请求和响应流量都经过负载均衡器，性能会差一些。

通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。

DR 模式下通过改写请求报文的目的 MAC 地址为某个真实服务器的 MAC（ARP 请求肯定不能自动响应了），将请求发送到真实服务器。而真实服务器将响应直接返回给客户。该模式扩展型号，但要求 LB 与真实服务器可以二层连通。这种模式因为性能好，用的很多。

TUN 是解决 DR 无法跨网络的问题，不是拿 MAC 做转发，而是封装完整包做 IP 转发，比 DR 处理要复杂。

此外，肯定要保证 Session 一致性，可以根据 IP 头和 TCP 头记录之前决策，保证流调度到同一台机器。实践中，支持十几台到数十台后端服务器比较合适。

应用层

用户访问资源需要通过 URI，一个 IP 地址上可能支持数个 URI，在三层均衡的同时，可以根据这些 URI 来制定具体的分发策略，比如访问 Front_IP:80/app1 的流量可能会被分配到 Back_IP1:80/app1；而到 Front_IP:80/app2 的流量被分配到Back_IP1:80/app2 等等。

这种应用层均衡，特点当然是最灵活，可以多级划分，但因为要看应用层的信息，计算复杂性大一些，对均衡器要求也比较高，很少有能做高性能的。

OpenStack Summit 2015 Tokyo 有感

本次峰会是 10.27 ~ 10.30，四天在东京的品川站附近召开，6000 多人参会，几百个主会 speak 和各个项目的 design summit。

因为要做一个有关容器和网络的 speak，所以，虽经波折，最终还是按时参加了峰会。业余玩社区确实挑战比较大。

整体感受是，时间很紧，内容很多，身体压力很大。虽然只挑了最核心最热门的话题去听，也是从早到晚急匆匆地从一个会场赶到另一个（好几个 building）。一天下来，疲劳的很。

社区，不只是技术

开源项目的成功，除了技术外，往往还有很多很重要的因素。

比如怎么运营社区，怎么跟商业公司合作，怎么处理各个团队的关系……

毫无疑问，OpenStack 到今天能这么火，在各个方面做得都是非常优秀的。

本届大会，基本上越大的主题演讲 topic 都越浅显一些，但是人满为患；design summit 则集中到具体项目进行设计的讨论，反而人气没那么旺。

参加的人员，技术人员仍然是主体，但是非技术人员也不少见。

云，其实本质上不是个技术的事情。呵呵呵~

容器和网络是热点

OpenStack 社区对容器还是很积极的一个主动拥抱态度，各个项目都在考虑虚拟化对象是容器的新场景。

实际上，无论是 Docker 系列，K8s、Mesos，都有一些相对完整的 solution，无需 IaaS 的支持，自己就可以玩得很好。

但 OpenStack 社区还是希望底下用自己，所以努力提供新的 API 来支持这些 solution。

两边的定位有 overlap，肯定会冲突。底层平台必须要主动考虑上层 workload，考虑应用特性。这个是生产关系决定的。

网络话题这次被广泛关注，大会报告中有好几个都在谈网络（包括 SDN 和 NFV）。这次来参会的公司也有不少是网络公司，不过技术上新的东西不多。

比较搞笑的是，这次峰会的超级用户奖颁给了 NTT（sponser 了现场的网络接入），然而 wifi 接入体验比较一般（本来多好的宣传机会！）。

两个值得关注的项目，kuryr 还有 ovs 自己搞的 ovn 等开始亮相社区，都挺有意思，定位思路很清晰，不像 Magnum，做起来的问题不大。

围绕 neutron，问题不少，但是老框架在这里，能周旋的余地很少。怎么能跟别的项目更好的集成，怎么提供更好的性能，都是很现实的问题。

强调下，云计算的技术基础是计算虚拟化，然而成功能否，根本取决于网络。

到现在还没意识到这点的，基本可以歇了。

比较遗憾的是，有一些传统网络厂商，没能很好的抓住云计算这波机会。亡羊补牢，为时未晚，还可以考虑抓紧时间布局物联网。

技术周期趋向成熟

基本上，新的项目 focus 的 scope 都圈得比较小。

很多人开始关注实际的部署和运维方面的一些问题（再次强调下我的观点，云环境中，ops 将变得比 dev 更重要！）。

这很正常，最多的 80% 的需求也是最基本的，剩下 20% 不好做，不是通用需求，但往往是差异化和体现技术实力的点。

很多人会松了口气，趋向成熟，意味着再也不用跟着后面折腾太多升级了。

成熟后怎么能再健康的发展下去，是每一个成功社区都会碰到的问题，现在已经有点由盛转衰的意味，虽然不明显。

国内力量不可小觑

market place，国内公司（特别创业公司）见到不少。除了传统方案和硬件厂商，就是日本本地企业和国内企业，甚至国内企业感觉比日本企业还多一些。

而且来的人好多，一下子就是好几十号人，庞大的队伍！

做应用的企业没见到……，不过有一些很有特色的小企业，比如 cumulix 啊、puppet、solinea 啊，哈哈哈~

这次本地报告也不少，竟然还出现了用日语讲报告的情况。

各种基于 OpenStack 的方案，各种特点。

乐观看，大家都尽量兼容 OpenStack，又努力做出自己的特色；悲观看，差异化和成长空间可能有限。

日本的文化和生活

日本是一个很有意思的地方，学习了东方和西方的文化，糅合在一起，难免有不少纠结的地方。

也许是意识到这种文化的缺位，对于传下来的和服啊、武士道啊、艺伎表演啊，就都十分重视。

但日本文化上其实是封闭的，现在年青一代很少愿意去接触外面的世界。整个日本社会就像是一个精密的大机器，每个人按照职责努力的工作。七八点上班，十一二点下班，很少有跳槽，很少有变化，压力太大，森严的规矩，老龄化……日本的年轻人，不容易！

生活成本低、贫富差距不大，这些西方社会普遍的特色，也造成了日本现在已经进入了高度稳定甚至停滞期。

云计算的第二个十年 -- IT 行业的新变化

如果从概念的提出（2006 年由 IBM、Google 联合提出）算起，云计算即将步入第二个十年。

在第一个十年里，云计算从被质疑到成为新一代 IT 标准，从单纯技术上的概念到影响到整个业务模式。

虽然到目前为止，还有很多不成熟的地方值得探索，但云计算在第一个十年里已经正式确立了它的地位，已经被广泛接受并实践。

在云时代的下一个十年里，IT 行业又会发生哪些变化呢？

ops 将变得比 dev 更重要

在过去，无论是企业还是个人市场，新产品的研发能力是最核心的，运营团队一贯被视为“第二梯队”。

造成这种局面的原因很复杂，根子上是基础设施的缺乏。大量的重复性、非标准化、非核心的研发任务，造成 dev 在整个生产链中的核心地位，造成运营团队话语权的缺失。

在云时代，随着基础设施服务的成熟和标准化，新产品研发的效率和复杂度将大大下降。反而是产品上线后，怎么应对不同时间、不同场景的需求变得更为重要。运营能力将直接决定云的质量。

所以，即使是研发团队，也一定要具备一定的运维能力。devops 的紧密结合，才能具备在云时代的快速应变能力。

PaaS 将变得比 IaaS 更重要

如果说 IaaS 是云计算一切服务的基础，那么 PaaS 将变成未来云计算服务的核心。

IaaS 的定位是提供基础架构能力，从整个云计算栈上看，无论是提供裸机、虚机还是容器，这只是对物理计算资源进行单纯的抽象和管理，并不具备任何面向业务属性。而 PaaS 则在基础架构的基础上进一步抽象计算资源为软件业务能力。

如果以盖房子为例子，IaaS 相当于提供了砖头和水泥。而 PaaS 则进一步的整合这些基础材料为墙板、横梁。显然，施工团队更喜欢直接用后者。

同时，由于 PaaS 更贴近应用，也具有更多话语权。

那么，比 PaaS 再上一层的 SaaS 是否更有优势呢？理论上是没错的，但是实际上在下一个十年里，公有 SaaS 成为主流的可能性不大。一方面是大量的企业的应用并不具有太强的通用性，需要定制化开发；另一方面是过度耦合到第三方服务的隐患。

私有 SaaS 会有，但是一定种类不会太多。办公类、娱乐类将成主体。

通用平台将越来越少

由于搭建和运维云成本的进一步降低，云将成为家家户户都可以创建的资源，面向公共服务的通用云平台将进一步集中，成为两三家的业务。

另外一方面，面向通用计算的云平台将很难获利。反而是某些具有特色服务的专有云将大量出现。

这些特色应该至少包括安全性、高性能、跟托管业务紧耦合的一些辅助服务，例如域名、CDN 等等。

Consul 简介

概述

Consul 是一套开源的分布式服务发现和配置管理系统，由 HashiCorp 公司用 Go 语言开发。

它具有很多优点。包括： 基于 raft 协议，比较简洁； 支持健康检查, 同时支持 HTTP 和 DNS 协议 支持跨数据中心的 WAN 集群 提供图形界面 跨平台，支持 Linux、Mac、Windows

安装

从 www.consul.io/downloads.html 下载二进制文件到本地即可。

consul 在每个节点上都只需要相同的单一二进制文件，部署十分简单。

基本概念

agent

组成 consul 集群的每个成员上都要运行一个 agent，可以通过 consul agent 命令来启动。agent 可以运行在 server 状态或者 client 状态。自然的，运行在 server 状态的节点被称为 server 节点；运行在 client 状态的节点被称为 client 节点。

client 节点

负责转发所有的 RPC 到 server 节点。本身无状态，且轻量级，因此，可以部署大量的 client 节点。

server 节点

负责组成 cluster 的复杂工作（选举、状态维护、转发请求到 lead），以及 consul 提供的服务（响应 RCP 请求）。考虑到容错和收敛，一般部署 3 ~ 5 个比较合适。

第一个节点：

$ consul agent -data-dir=/tmp/consul -server -bootstrap-expect 1 -bind $IP

其他节点：

$ consul agent -data-dir=/tmp/consul -server -join $IP

通过 $IP:8500/v1/catalog/nodes 可以访问到注册上的节点。

Gossip

基于 Serf 实现的 gossip 协议，负责成员、失败探测、事件广播等。通过 UDP 实现各个节点之间的消息。分为 LAN 上的和 WAN 上的两种情形。

架构

相关项目

registrator

可以监听主机上的容器信息，并把有暴露端口的容器注册到给定的 consul/etcd 等服务上。

consul-template

可以监听 consul 服务的内容变化，并根据变化实时更新应用的配置文件。

Mesos 热门框架

framework 是实际干活的，可以理解为 mesos 上跑的 应用，需要先注册到 master 上。

长期运行的服务

Aurora

利用 mesos 调度安排的任务，保证任务一直在运行。

提供 REST 接口，客户端和 webUI（8081 端口）

Marathon

一个 PaaS 平台。

保证任务一直在运行。如果停止了，会自动重启一个新的任务。

支持任务为任意 bash 命令，以及容器。

提供 REST 接口，客户端和 webUI（8080 端口）

Singularity

一个 PaaS 平台。

调度器，运行长期的任务和一次性任务。

提供 REST 接口，客户端和 webUI（7099、8080 端口），支持容器。

大数据处理

Cray Chapel

支持 Chapel 并行编程语言的运行框架。

Dpark

Spark 的 Python 实现。

Hadoop

经典的 map-reduce 模型的实现。

Spark

跟 Hadoop 类似，但处理迭代类型任务会更好的使用内存做中间状态缓存，速度要快一些。

Storm

分布式流计算，可以实时处理数据流。

批量调度

Chronos

Cron 的分布式实现，负责任务调度。

Jenkins

大名鼎鼎的 CI 引擎。使用 mesos-jenkins 插件，可以将 jenkins 的任务被 mesos 来动态调度执行。

ElasticSearch

功能十分强大的分布式数据搜索引擎。

数据存储

Cassandra

高性能分布式数据库。

转载请注明：http://blog.csdn.net/yeasy/article/details/46698419

Mesos 的 配置项 可以通过启动时候传递参数或者配置目录下文件的方式给出（推荐方式，一目了然）。

分为三种类型：通用项（master 和 slave 都支持），只有 master 支持的，以及只有 slave 支持的。

通用项

• --ip=VALUE 监听的 IP 地址
• --firewall_rules=VALUE endpoint 防火墙规则，VALUE 可以是 JSON 格式或者存有 JSON 格式的文件路径。
• --log_dir=VALUE 日志文件路径，默认不存储日志到本地
• --logbufsecs=VALUE buffer 多少秒的日志，然后写入本地
• --logging_level=VALUE 日志记录的最低级别
• --port=VALUE 监听的端口，master 默认是 5050，slave 默认是 5051。

master 专属配置项

• --quorum=VALUE 必备项，使用基于 replicated-Log 的注册表时，复制的个数
• --work_dir=VALUE 必备项，注册表持久化信息存储位置
• --zk=VALUE 必备项，zookeepr 的接口地址，支持多个地址，之间用逗号隔离，可以为文件路径
• --acls=VALUE ACL 规则或所在文件
• --allocation_interval=VALUE 执行 allocation 的间隔，默认为 1sec
• --allocator=VALUE 分配机制，默认为 HierarchicalDRF
• --[no-]authenticate 是否允许非认证过的 framework 注册
• --[no-]authenticate_slaves 是否允许非认证过的 slaves 注册
• --authenticators=VALUE 对 framework 或 salves 进行认证时的实现机制
• --cluster=VALUE 集群别名
• --credentials=VALUE 存储加密后凭证的文件的路径
• --external_log_file=VALUE 采用外部的日志文件
• --framework_sorter=VALUE 给定 framework 之间的资源分配策略
• --hooks=VALUE master 中安装的 hook 模块
• --hostname=VALUE master 节点使用的主机名，不配置则从系统中获取
• --[no-]log_auto_initialize 是否自动初始化注册表需要的 replicated 日志
• --modules=VALUE 要加载的模块，支持文件路径或者 JSON
• --offer_timeout=VALUE offer 撤销的超时
• --rate_limits=VALUE framework 的速率限制，比如 qps
• --recovery_slave_removal_limit=VALUE 限制注册表恢复后可以移除或停止的 slave 数目，超出后 master 会失败，默认是 100%
• --slave_removal_rate_limit=VALUE slave 没有完成健康度检查时候被移除的速率上限，例如 1/10mins 代表每十分钟最多有一个
• --registry=VALUE 注册表的持久化策略，默认为 replicated_log，还可以为 in_memory
• --registry_fetch_timeout=VALUE 访问注册表失败超时
• --registry_store_timeout=VALUE 存储注册表失败超时
• --[no-]registry_strict 是否按照注册表中持久化信息执行操作，默认为 false
• --roles=VALUE 集群中 framework 可以所属的分配角色
• --[no-]root_submissions root 是否可以提交 framework，默认为 true
• --slave_reregister_timeout=VALUE 新的 lead master 节点选举出来后，多久之内所有的 slave 需要注册，超时的 salve 将被移除并关闭，默认为 10mins
• --user_sorter=VALUE 在用户之间分配资源的策略，默认为 drf
• --webui_dir=VALUE webui 实现的文件目录所在，默认为 /usr/local/share/mesos/webui
• --weights=VALUE 各个角色的权重
• --whitelist=VALUE 文件路径，包括发送 offer 的 slave 名单，默认为 None
• --zk_session_timeout=VALUE session 超时，默认为 10secs
• --max_executors_per_slave=VALUE 配置了 --with-network-isolator 时可用，限制每个 slave 同时执行任务个数

slave 专属配置项

• --master=VALUE 必备项，master 所在地址，或 zookeeper 地址，或文件路径，可以是列表
• --attributes=VALUE 机器属性
• --authenticatee=VALUE 跟 master 进行认证时候的认证机制
• --[no-]cgroups_enable_cfs 采用 CFS 进行带宽限制时候对 CPU 资源进行限制，默认为 false
• --cgroups_hierarchy=VALUE cgroups 的目录根位置，默认为 /sys/fs/cgroup
• --[no-]cgroups_limit_swap 限制内存和 swap，默认为 false，只限制内存
• --cgroups_root=VALUE 根 cgroups 的名称，默认为 mesos
• --container_disk_watch_interval=VALUE 为容器进行硬盘配额查询的时间间隔
• --containerizer_path=VALUE 采用外部隔离机制（--isolation=external）时候，外部容器机制执行文件路径
• --containerizers=VALUE 可用的容器实现机制，包括 mesos、external、docker
• --credential=VALUE 加密后凭证，或者所在文件路径
• --default_container_image=VALUE 采用外部容器机制时，任务缺省使用的镜像
• --default_container_info=VALUE 容器信息的缺省值
• --default_role=VALUE 资源缺省分配的角色
• --disk_watch_interval=VALUE 硬盘使用情况的周期性检查间隔，默认为 1mins
• --docker=VALUE docker 执行文件的路径
• --docker_remove_delay=VALUE 删除容器之前的等待时间，默认为 6hrs
• --[no-]docker_kill_orphans 清除孤儿容器，默认为 true
• --docker_sock=VALUE docker sock 地址，默认为 /var/run/docker.sock
• --docker_mesos_image=VALUE 运行 slave 的 docker 镜像，如果被配置，docker 会假定 slave 运行在一个 docker 容器里
• --docker_sandbox_directory=VALUE sandbox 映射到容器里的哪个路径
• --docker_stop_timeout=VALUE 停止实例后等待多久执行 kill 操作，默认为 0secs
• --[no-]enforce_container_disk_quota 是否启用容器配额限制，默认为 false
• --executor_registration_timeout=VALUE 执行应用最多可以等多久再注册到 slave，否则停止它，默认为 1mins
• --executor_shutdown_grace_period=VALUE 执行应用停止后，等待多久，默认为 5secs
• --external_log_file=VALUE 外部日志文件
• --frameworks_home=VALUE 执行应用前添加的相对路径，默认为空
• --gc_delay=VALUE 多久清理一次执行应用目录，默认为 1weeks
• --gc_disk_headroom=VALUE 调整计算最大执行应用目录年龄的硬盘留空量，默认为 0.1
• --hadoop_home=VALUE hadoop 安装目录，默认为空，会自动查找 HADOOP_HOME 或者从系统路径中查找
• --hooks=VALUE 安装在 master 中的 hook 模块列表
• --hostname=VALUE slave 节点使用的主机名
• --isolation=VALUE 隔离机制，例如 posix/cpu,posix/mem（默认）或者 cgroups/cpu,cgroups/mem
• --launcher_dir=VALUE mesos 可执行文件的路径，默认为 /usr/local/lib/mesos
• --modules=VALUE 要加载的模块，支持文件路径或者 JSON
• --perf_duration=VALUE perf 采样时长，必须小于 perf_interval，默认为 10secs
• --perf_events=VALUE perf 采样的事件
• --perf_interval=VALUE perf 采样的时间间隔
• --recover=VALUE 回复后是否重连上旧的执行应用
• --recovery_timeout=VALUE slave 恢复时的超时，太久则所有相关的执行应用将自行退出，默认为 15mins
• --registration_backoff_factor=VALUE 跟 master 进行注册时候的重试时间间隔算法的因子，默认为 1secs，采用随机指数算法，最长 1mins
• --resource_monitoring_interval=VALUE 周期性监测执行应用资源使用情况的间隔，默认为 1secs
• --resources=VALUE 每个 slave 可用的资源
• --slave_subsystems=VALUE slave 运行在哪些 cgroup 子系统中，包括 memory，cpuacct 等，缺省为空
• --[no-]strict 是否认为所有错误都不可忽略，默认为 true
• --[no-]switch_user 用提交任务的用户身份来运行，默认为 true
• --fetcher_cache_size=VALUE fetcher 的 cache 大小，默认为 2 GB
• --fetcher_cache_dir=VALUE fetcher cache 文件存放目录，默认为 /tmp/mesos/fetch
• --work_dir=VALUE framework 的工作目录，默认为 /tmp/mesos

下面的选项需要配置 --with-network-isolator 一起使用 --ephemeral_ports_per_container=VALUE 分配给一个容器的临时端口，默认为 1024 --eth0_name=VALUE public 网络的接口名称，如果不指定，根据主机路由进行猜测 --lo_name=VALUE loopback 网卡名称--egress_rate_limit_per_container=VALUE 每个容器的 egress 流量限制速率 * --[no-]network_enable_socket_statistics 是否采集每个容器的 socket 统计信息，默认为 false

转载请注明：http://blog.csdn.net/yeasy/article/details/46683297

浅析 hyper -- 新一代虚拟机技术？

容器技术的快速发展，挤占了传统虚拟机技术的很多地盘。没办法，在启动速度和运行性能上，容器实在有着太多的优势，而虚拟机技术的发展实在太过缓慢。

现在，hyper_ 团队 推出了启动速度可以跟容器媲美的新一代虚拟机技术 -- hyper。

简介

hyper 是基于 go 实现的开源项目，代码托管在 github 上。。

简单的说，hyper = Hypervisor + Kernel + Docker Image，本质上还是一种虚拟机技术，只不过是应用中心（app-centric）的虚拟机。

hyper 将容器运行在了虚拟机里，只不过这个虚拟机是精简过的（基于 qboot），可以快速启动停止的虚拟机。目前，可以运行在 KVM 上，操作系统要求为比较新的 debian/ubuntu、centos 等，内核建议为 4.0.1，docker 版本至少为 1.5.0，qemu 至少为 2.0。

hyper 每个虚拟机中可以同时运行多个容器进程，借用了 kubernetes 中的 pod 的概念。每个虚拟机就是一个 pod（使用外部的 podfile， JSON 或 YAML 格式，来定义包括哪些应用），其中的运行的容器进程共享命名空间（不使用命名空间隔离），但用 mount 命名空间来隔离内部多个镜像的 root 文件系统。

优势

优势很明显，就是容器技术一直缺乏的，跟传统虚拟机相关的优势：

• 可以平滑地跟已有基于虚拟机的技术和平台进行整合；
• 大大提高了容器已有隔离技术的安全性，特别是不需要共享内核；
• 不依赖已有容器技术（Docker daemon, LXC, Cgroup, Namespace），只需要 MOUNT 命名空间支持。

劣势

劣势也很明显：

• 增加了额外的资源消耗，包括额外的内核和进程；
• 并非像宣称的那样成熟，目前还只是 0.1 版本；
• 硬盘 IO 性能没公布，猜测会跟虚拟机类似；
• 暂时不支持分层文件系统；

总之，生态环境还有待建立。

安装使用

安装

很简单，直接下载 bash 脚本安装。

# curl -sSL https://hyper.sh/install | bash

使用

# docker pull ubuntu:14.04

# hyper run ubuntu:14.04
POD id is pod-IEKZbVtzef
root@ubuntu:14:/#
...

# hyper list
POD ID                      POD Name             VM name    Status
 pod-IEKZbVtzef                        ubuntu    14.04-5551572656

支持的命令跟 docker 很类似，包括 run、start、stop、attach、exec、create、replace、rm、info、list 等等，更多信息可以参考 官方文档。

原理

hyper 的组件十分简单：

• hyper 提供命令行接口
• hyperd 提供核心维护引擎，支持 REST
• 虚拟机实例：hyperkernel 作为 guest os 的kernel；hyperstart 作为启动 init 服务。

展望

实际上，现在已有一些类似的技术，包括两大类：

• 直接基于容器进行进一步封装，CoreOS、RancherOS、Photon 等，实际上还是直接跑容器，跑的应用还是在容器内；
• Intel 的 Clear Container 跟 hyper 很像，都是直接运行一个轻量级的虚拟机，然后里面再做事。

这些技术都有各自的优缺点，以及各自适合的应用场景，在很长一段时间内将会共存，甚至出现更多适合云计算时代场景下的虚拟化技术。