Tuesday, June 30, 2015

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

高性能分布式数据库。

Monday, June 29, 2015

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

Sunday, June 28, 2015

OpenStack 主要项目一览

OpenStack 发展十分迅速,目前已经包括了几十个正式项目,和大量的孵化项目,基本实现了 AWS 的大部分功能。

业务项目

基础架构层

计算服务

  • Compute (Nova):提供虚拟机形式的虚拟化
  • Bare Metal (Ironic):提供裸机形式的虚拟化
注:目前除了不完整的 Nova-Docker,还没有提供容器形式的虚拟化项目,Magnum 目前定位更多的是在上层。

存储服务

  • Image service (Glance):存虚拟机镜像
  • Object Storage (Swift):存对象
  • Block Storage (Cinder):块设备
  • Shared Filesystems (Manila):最初基于 Cinder 的共享文件系统。这个有单独存在的必要么?

网络服务

  • Networking (Neutron):十分完整的网络虚拟化功能,缺乏完善的安全服务,或许可以独立为新的项目。
  • DNS (Designate):DNS 服务

认证服务

  • Identity (Keystone):十分完整的认证、鉴权管理

编排

  • Orchestration (Heat):通过模板描述需要的基础资源组合,提供对其生命周期的高层管理接口。

其它

  • Key management (Barbican):加密数据管理
  • Governance service (Congress):Policy 管理

应用层

  • Message service (Zaqar):消息队列
  • Database Service (Trove):数据库
  • Data processing (Sahara):大数据处理
  • Containers service (Magnum):容器
  • Application catalog (Murano):应用目录
  • Workflow service (Mistral):工作流管理,任务之间的依赖,什么时间启动
  • Key-value store as a Service (MagnetoDB):键值数据库

支持项目

  • Dashboard (Horizon):web 界面。一贯的丑,但能用
  • Telemetry (Ceilometer):审计,统计,目前没有控制
  • Common Libraries (Oslo):基础库,这个应该是最有用的了,包括若干子库,config、context、messaging 等
  • Deployment (TripleO):部署一套 OpenStack 环境。实际上包括 RDO、DevStack 在内,都还不咋好用
  • Command-line client (OpenStackClient):对各个服务的 API 进一步封装为命令行客户端
  • Benchmark service (Rally):测试在大规模情况下的性能。这个估计各家会自己搞一套方案
  • Puppet modules (PuppetOpenStack):各种使用 puppet 相关的模块。puppet 和 chef 这种过度设计的工具,估计至少会消亡一个

Friday, June 26, 2015

浅析 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 的组件十分简单:
  • hyper 提供命令行接口
  • hyperd 提供核心维护引擎,支持 REST
  • 虚拟机实例:hyperkernel 作为 guest os 的kernel;hyperstart 作为启动 init 服务。

展望

实际上,现在已有一些类似的技术,包括两大类:
  • 直接基于容器进行进一步封装,CoreOS、RancherOS、Photon 等,实际上还是直接跑容器,跑的应用还是在容器内;
  • Intel 的 Clear Container 跟 hyper 很像,都是直接运行一个轻量级的虚拟机,然后里面再做事。
这些技术都有各自的优缺点,以及各自适合的应用场景,在很长一段时间内将会共存,甚至出现更多适合云计算时代场景下的虚拟化技术。

Thursday, June 25, 2015

Pacemaker 安装与使用

Pacemaker 只做资源管理器(CRM),底下的消息系统采用 corosync。

安装

ubuntu 为例,
sudo aptitude install -y pacemaker corosync

配置 corosync

修改 /etc/default/corosync 文件,修改 start=yes,否则服务脚本无法启动。
/etc/corosync/corosync.conf 中,修改 bindnetaddr 的值为节点之间互相通知监听的网段(例如 eth1 所在的 10.0.100.0 网段)。
添加如下内容,让corosync 启动的时候也启动 pacemaker(ubuntu 上运行会有 bug,还得是手动启动)。
service {
    ver:  0
    name: pacemaker}

修改 expected_votes 的值为大于节点数目一半的数字。
执行 corosync-keygen 命令,会生成 /etc/corosync/authkey 文件,该文件和 corosync.conf,分别复制到集群的各个成员节点上。
启动 pacemaker 和 corosync
$ sudo service pacemaker restart
$ sudo service corosync restart
如果启动成功了,可以通过 sudo corosync-cmapctl |grep members 或者 sudo crm status查看集群中成员的状态。

配置资源信息

在任意一个 node 上执行下面的 crm 配置命令(实际上是通过 CLI 来编辑后面的 XML 文件)。
# crm
crm(live)# configure          #进入配置模式
crm(live)configure# verify    #校验配置
   error: unpack_resources:     Resource start-up disabled since no STONITH resources have been defined
   error: unpack_resources:     Either configure some or disable STONITH with the stonith-enabled option
   error: unpack_resources:     NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid
  -V may provide more details
crm(live)configure# property stonith-enabled=false #根据校验情况,关闭 stonith
crm(live)configure# commit  # 提交修改
crm(live)configure# verify  # 重新校验
crm(live)configure# primitive web_ip ocf:IPaddr params ip=9.186.100.102  #定义 IP 资源,这个 ip 资源会被主节点配到自己的网卡上
crm(live)configure# primitive nginx_service lsb:nginx  #定义服务资源
crm(live)configure# commit
crm(live)configure# group mygroup web_ip nginx_service   #定义资源组
crm(live)configure# commit
crm(live)configure# property no-quorum-policy=ignore     #投票权不到一半时的策略
crm(live)configure# commit
crm(live)configure# exit

测试

分别在各个节点上启动 nginx,页面填入不同内容。
访问配置的虚 IP,即 9.186.100.102,查看具体访问到了哪个节点,然后在该节点上断开 eth1,同时删除 eth0:0(如果 enable 了 stonith 可以自动完成,否则要手动解决 split),过一会重新查看虚 IP 页面,会发现自动变成了其它的节点。

Tuesday, June 23, 2015

Mesos 基本原理与架构

首先,Mesos 是一个资源调度框架,并非一整套完整的应用管理平台,本身是不能干活的。但是它可以比较容易的跟各种应用管理或者中间件平台整合,一起工作,提高资源使用效率。

架构

mesos-arch master-slave 架构,master 使用 zookeeper 来做 HA。
master 单独运行在管理节点上,slave 运行在各个计算任务节点上。
各种具体任务的管理平台,即 framework 跟 master 交互,来申请资源。

基本单元

master

负责整体的资源调度和逻辑控制。

slave

负责汇报本节点上的资源给 master,并负责隔离资源来执行具体的任务。
隔离机制当然就是各种容器机制了。

framework

framework 是实际干活的,包括两个主要组件:
  • scheduler:注册到主节点,等待分配资源;
  • executor:在 slave 节点上执行本framework 的任务。
framework 分两种:一种是对资源需求可以 scale up 或者 down 的(Hadoop、Spark);一种是对资源需求大小是固定的(MPI)。

调度

对于一个资源调度框架来说,最核心的就是调度机制,怎么能快速高效的完成对某个 framework 资源的分配(最好是能猜到它的实际需求)。

两层调度算法:

master 先调度一大块资源给某个 framework,framework 自己再实现内部的细粒度调度。
调度机制支持插件。默认是 DRF。

基本调度过程

调度通过 offer 方式交互:
  • master 提供一个 offer(一组资源) 给 framework;
  • framework 可以决定要不要,如果接受的话,返回一个描述,说明自己希望如何使用和分配这些资源(可以说明只希望使用部分资源,则多出来的会被 master 收回);
  • master 则根据 framework 的分配情况发送给 slave,以使用 framework 的 executor 来按照分配的资源策略执行任务。

过滤器

framework 可以通过过滤器机制告诉 master 它的资源偏好,比如希望分配过来的 offer 有哪个资源,或者至少有多少资源。
主要是为了加速资源分配的交互过程。

回头机制

master 可以通过回收计算节点上的任务来动态调整长期任务和短期任务的分布。

HA

master

master 节点存在单点失效问题,所以肯定要上 HA,目前主要是使用 zookpeer 来热备份。
同时 master 节点可以通过 slave 和 framework 发来的消息重建内部状态(具体能有多快呢?这里不使用数据库可能是避免引入复杂度。)。

framework 通知

framework 中相关的失效,master 将发给它的 scheduler 来通知。