Apache Mesos(8)-部署生产系统的考虑

目录
  1. 部署生产系统的考虑
    1. 生产系统部署概览
    2. MESOS MASTERS
    3. ZOOKEEPER ENSEMBLE
  2. 日志
    1. 定位和解析日志文件
      1. 服务的日志文件
      2. 任务的日志文件
    2. 配置日志文件
  3. 监视Mesos和ZooKeeper集群
    1. 监视Mesos master
    2. 监视Mesos slave
    3. 监视ZooKeeper
  4. 修改master的法定人数
    1. 增加masters
    2. 减少masters
    3. 取代masters

作者：杨冬 欢迎转载，也请保留这段声明。谢谢！
出处：https://andyyoung01.github.io/ 或 http://andyyoung01.16mb.com/

前面我们安装部署了Mesos集群，并且通过Marathon框架运行了几个任务。但是如果将Mesos集群用于生产，就需要考虑更多的问题。本篇我们探索将Mesos集群用于生产的一些最佳实践。虽然本篇并不能包括生产系统需要考虑的所有问题，但也为部署、管理Mesos生产集群提供了一些参考。

部署生产系统的考虑

生产系统部署概览

对于生产系统，需要最少3个Mesos masters和3个ZooKeeper ensemble组成一个高可用的集群。ZooKeeper集群可以部署在单独的物理机上，也可以为了简单，部署在与Mesos masters相同的机器上。当把这些服务部署到专用的物理机、虚拟机或者云提供商提供的云主机上时，一定要考虑在硬件级别的冗余。就是说如果您有自己的数据中心，这些服务应该部署到位于不同机柜，连接到不同的网络交换机以及不同的电力线路的机器上。如果使用的是虚拟机或云环境，确保使用一定的策略，来确保这些虚拟机运行在不同的hypervisors或不同的可用区里。

MESOS MASTERS

如果计划将Mesos集群的部署跨越到多个数据中心，要确保这些不同数据中心之间的网络延时较低。否则，在不同数据中心的Masters彼此通信时会出现超时，即如果leading master不能在registry_store_timeout（默认：5s）时间内写入到standby masters上时，Mesos的注册更新便会失败。如果考虑增加这个延时，也同时考虑增加registry_fetch_timeout（默认：1分钟）的数值。根据环境的不同，也可以考虑在不同的数据中心部署不同的Mesos集群，然后在这些集群间进行负载均衡。

ZOOKEEPER ENSEMBLE

在ZooKeeper的集群（被称为ensemble）里，需要保持一个quorum（法定人数）。集群可以同时容纳的失败节点，取决于你的环境和你个用户提供的SLA。如果需要创建一个可以容纳F个失败节点的集群，则需要部署（2xF+1）个节点。通常情况下集群的节点数都是奇数，一般推荐部署从5个节点开始的用于生产环境的集群，它可以在一个节点下线进行维护时，整个集群还可以容纳一个节点失败的能力。

日志

服务生成的日志文件可以和服务本身一样重要。当问题产生时，详细可用的日志文件对故障的处理是非常重要的。

定位和解析日志文件

服务的日志文件

关于管理日志，Mesos给系统管理员提供了很大的灵活性。事件可以写到磁盘上Mesos管理的日志文件中，或者是系统日志（syslog）中。Mesos的安装包默认的配置确保Mesos master和slave服务将日志发送给syslog，以便可以被日志管理服务如Logstash或Splunk进行收集和分析。
Mesos master和slave都可以使用–log_dir来配置日志文件的存储位置。通常设置为/var/log/mesos，但也可以省略该配置使日志发送到standard error（标准错误输出）位置。如果Mesos为你管理日志文件，它将根据文件的大小来进行自动轮换，不过你应该确保定期删除这些旧的文件。

任务的日志文件

在每个任务的sandbox中，Mesos提供了两个默认的日志文件：stdout和stderr。这允许管理员通过web界面查看任务或者命令的控制台输出，而不用实际登录到运行此任务的节点上去查看。这些日志文件和其它任务需要的文件一起存储在任务的work_dir，它是通过slave的--work_dir来配置的。如果slave的work_dir被配置为/var/lib/mesos，则到任务的sandbox的路径类似于下面这样：

/var/lib/mesos/slaves
└── <slave-id>/
    └── frameworks/
        └── <framework-id>/
            └── executors/
                └── <task-name>/
                    └── runs/
                        ├── <run-id>/
                        │   ├── stderr
                        │   └── stdout
                        └── latest

与Mesos服务的日志文件不同的是，当Mesos slave在旧的sandbox目录里进行垃圾收集时，这些文件自动清除。垃圾收集默认是一周一次，但根据可用的磁盘空间大小可能更频繁的进行。

配置日志文件

Mesos提供了很多配置选项用来配置日志，这些选项包括：

  • log_dir—日志文件在磁盘上的存储路径。如果没有指定，将不会向磁盘写入，而将事件发送到stderr。该选项可以用在master和slave上，没有默认值。
  • logging_level—只记录此级别（或高于）的日志信息。可能的值包括（级别依次递增）：INFO, WARNING, 和ERROR。此选项可以用于master和slave，默认值为INFO。
  • work_dir—当在slave上配置时，此选项指定某框架的工作目录（sandbox），它包含任务的stdout和stderr日志文件。默认值为/tmp/mesos。
  • external_log_file—指定到外部管理的日志文件的路径，用来再web界面上显示和HTTP API。可以用于master和slave上，没有默认值。
  • quiet—当指定后，没有日志输出到stderr。可以用于master和slave上，此配置默认不指定。
  • logbufsecs—在日志写入磁盘前，缓存日志信息的秒数。可以用于master和slave上，默认值为0（立即将日志信息写入磁盘）。

搭建日志基础设施，可以使用Elasticsearch, Logstash, and Kibana (ELK) stack，用来收集、分析和索引日志条目，方便将日志条目以数据的方式进行搜索和可视化。使用上面这些选项可以使Mesos的日志和您的日志基础设施相适应，不管你使用的是何种日志基础设施。

监视Mesos和ZooKeeper集群

可以使用各种监视系统如Nagios、Zabbix等来监视Mesos集群中的服务正常运行。而且Mesos有丰富的基于JSON的HTTP API，可以用来查询集群健康状态的更多信息。可以使用下面的链接来查询关于API终端的更多信息：

更多信息可以参考http://mesos.apache.org/documentation/latest/monitoring/。

监视Mesos master

除了基本的主机监视（CUP，内存，磁盘，网络）和进程监视（Mesos-master服务）外，Mesos master的法定人数的状态对整个集群能否正常工作也有关键的影响。OpenTable团队提供了一个Nagios check脚本，通过它可以监视leading master的下述状态：

  • 基本健康检查
  • 注册了最少数目的slave
  • 注册了某个框架

另外，Mesos提供了广泛的REST API，可以用来查询集群健康状态的更多信息，如：

  • 使用了的资源
  • 收到和处理过的Framework的信息（如果认证被启用）
  • 系统负载
  • 连接了的slaves

监视Mesos slave

虽然slave不像master那样负责保证法定人数和决策将任务分配到集群中的哪里，但对slave的正确监控，可以确保集群不会出现没有资源可分配或没有磁盘空间等警报。下面是一些对Mesos slave监控的建议：

  • 确保Mesos-slave进程正常运行（端口5051可访问）
  • 确保docker进程正常运行（如果使用docker的话）
  • 监视基础信息，包括CUP、内存、磁盘、和网络使用状态，如果可以生成不同时间的状态图表最好。
  • 监视每个容器的指标（CPU、内存、磁盘、网络）

和Master类似，slave也提供了广泛的REST API，但不同的是，slave的API返回的是该slave自己的信息，而不是整个集群的指标。通过slave的API终端，不但可以得到OS级别的资源使用率的信息，而且可以得到在某个slave上运行的容器内部的信息。

监视ZooKeeper

可以使用开源工具Exhibitor监控ZooKeeper集群，它提供了如下功能：

  • 确保实例启动并且对请求做出响应。
  • 执行备份和恢复
  • 管理集群的配置
  • 通过REST API和web界面浏览ZNodes树。

除了Exhibitor，还有很多监控脚本与ZooKeeper一起分发。check_zookeeper.py脚本可以用做Nagios check。当然也可以通过一系列查询ZooKeeper的内置命令编写自己的Nagios监控脚本。
这些内置命令是一系列四个字符的命令，通过Netcat工具发送到ZooKeeper实例上，例如假设ZooKeeper实例在2181端口进行监听，可以通过如下命令：

$ echo 'ruok' | nc zookeeper-ip 2181

如果返回imok字符串，说明服务正在运行。

ZooKeeper的四字符命令列表

修改master的法定人数

当修改master的法定人数时，有一些需要注意的事项：Mesos master通过--quorum配置选项修改了集群的法定人数后，需要重启masters以使修改生效。另外，需要确保集群中master的数量不超过其对应的法定人数的数量（对应关系见下表）。和任何其它的生产服务一样，确保在预生产环境测试修改，之后再谨慎地对生产系统进行修改。
{% asset_img 1.png “Mesos master的法定人数”%}

增加masters

假如我们想将masters的数量从3增加到5，可以通过下面的步骤进行：

  1. 当前，有3个masters正在以--quorum=2运行。重新配置每个masters，使--quorum=3并重新启动每个master进程。
  2. 添加两个masters，这两个master都以--quorum=3启动。

减少masters

假如将masters的数量从5减少到3，可以通过下面的步骤进行：

  1. 当前，有5个masters正在以--quorum=3运行。从集群中去掉2个master，并确保它们不会重新上线加入集群。
  2. 重新用--quorum=2配置剩下的3个masters，重启每个master。

取代masters

如果需要取代一个现有的master（删除一个master，在它的位置再添加一个master并且保持当前配置的quorum数），应该可以进行此操作而不用停机。步骤如下：

  1. 当前，有3个masters正在以--quorum=2运行。去掉你想取代的master，并确保它不会重新上线加入集群（可以用删除虚拟机，擦除硬盘等手段）。
  2. 提供一个新的master，并以和其它master相同的quorum配置，这里是--quorum=2。
  3. 启动这个master服务，使replicated log和已经存在的masters同步。

本篇我们探索了一些将Mesos集群用于生产的最佳实践。虽然并没有列出生产系统中应考虑的所有问题，如怎样实施安全和访问控制，怎样进行滚动升级等，但也对Mesos生产集群给出了一些参考。

分布式系统, Apache mesos
Apache mesos, 分布式系统