|
自定义安装Framework Executor 创建您的自定义executor之后，您需要将其提供给集群中的所有的slaves。. 一种发布 framework executor是当scheduler向slave发布tasks时让 Mesos fetcher 按需求下载 . ExecutorInfo 是一个Protocol Buffer Message类(定义于include/mesos/mesos.proto), 它包含一个 CommandInfo类型的字段. CommandInfo 允许schedulers规定,除其他事项外, 一些资源作为URIs. 在尝试执行ExecutorInfo 命令前这些资源被slave上的sandbox文件夹取回。支持的URI 模式包括HTTP、FTP、 HDFS、和S3 (注，见src/examples/java/TestFramework.java例子). 或者，当你发布他们去规定framework executors在哪安装 (注， 在一个可以提供给所有slaves的NFS挂载)时，你可以通过传递 frameworks_home 到mesos-slave 守护进程配置选项 (默认为:MESOS_HOME/frameworks) , 然后用CommandInfo.uris里的相对路径, slave 将frameworks_home的值前置于相对路径。 一旦你确定所有mesos-slaves都可以获取executors, 你就可以运行scheduler，它向Mesos master注册并开始接接受offers！ 可以在FrameworkInfo, TaskInfo, DiscoveryInfo和TaskStatus信息中找到标签（Labels）。计算框架和模块的编写者可以在Mesos内使用标签来标记和传递非机构化的信息。标签是以key-value的自由格式提供给计算框架调度器或标签装饰钩子。下面是protobuf的标签定义： optional Labels labels = 11; /** * 标签集合。 */ message Labels { repeated Label labels = 1; } /** * 以Key，value的形式来自由存储用户数据。 */ message Label { required string key = 1; optional string value = 2; } 标签并不是Mesos给它自己进行解释，但作为管理器和节点之间的终点状态。此外，执行器和调度器在TaskInfo和TaskStatus以编程的方式进行标签解析。下面是列举了两个对标签的例子 ("environment": "prod" 和 "bananas": "apples")可以从管理器状态终点进行获取。 $ curl http://master/state.json ... { "executor_id": "default", "framework_id": "20150312-120017-16777343-5050-39028-0000", "id": "3", "labels": [ { "key": "environment", "value": "prod" }, { "key": "bananas", "value": "apples" } ], "name": "Task 3", "slave_id": "20150312-115625-16777343-5050-38751-S0", "state": "TASK_FINISHED", ... }, 发现服务Service discovery 当你的计算框架注册了执行器，并启动了任务，可以给发现服务提供额外的信息。这些信息存储在Mesos管理器伴随着其他重要信息 例如节点（slave）正在运行的任务。在Mesos集群运行多计算框架多任务时，发现服务系统可以以编程的方式准备号纠正并恢复创建DNS索引、配置代理、或者更新不一致的存储信息。 DiscoveryInfo选项信息将会传递给TaskInfo和ExecutorInfo，声明如下代码位于：MESOS_HOME/include/mesos/mesos.proto message DiscoveryInfo { enum Visibility { FRAMEWORK = 0; CLUSTER = 1; EXTERNAL = 2; } required Visibility visibility = 1; optional string name = 2; optional string environment = 3; optional string location = 4; optional string version = 5; optional Ports ports = 6; optional Labels labels = 7; } 显而易见的，通知发现服务器系统应当发现已经通知过的Key参数。我们现在列举三个不同的案例： 任务不除了所属的计算框架以外的不应当被发现。 任务应当在所运行的Mesos集群中的所有计算框架发现，而不是在外部被发现。 任务应当无误的发现。 大量的发现服务系统提供附加的管理可见的字段。（举例来说，系统中基于代理的ACL，DNS的安全扩展，VLAN或者子网选择）不打算使用可见的资源来管理这些功能。服务发现系统重新从管理器获取任务或者执行器信息，这种方式解决没有DiscoveryInfo如何获取任务。举例，任务不会对其他计算框架可见。（等价于 visibility=FRAMEWORK）或者对所有计算框架可见（等价于 visibiility=CLUSTER）。 名称字段的数据格式是字符串，字符串可以保证服务发现系统通过名字的形式发现任务。典型的名称字段是提供有效的域名。如果名称无法提供，则需要服务发现系统在taskInfo或者其他信息中的名称字段来为任务创建名称。 环境变量、地址信息、和版本等字段在大型部署中提供了第一类的支持，对象的属性相同但是在不同地方应用的相似服务。环境可以接收如吃产品/质量检查/开发，位置字段可以接收如下值：EAST-US/WEST-US/EUROPE/AMEA, 以及版本字段可以接收如下值v2.0/v0.9。发现系统需要正确的把这些字段提供给服务发现系统。 端口字段允许计算框架定义任务的监听端口并明确名称的功能，端口字段是可以再次提交并使用网络的第四层通讯协议（TCP，UDP或者其他）。举例，Cassandra的任务定义如下端口"7000,Cluster,TCP", "7001,SSL,TCP", "9160,Thrift,TCP", "9042,Native,TCP", 和 "7199,JMX,TCP"。由服务发现系统以适当形式的协议把潜在的把DiscoveryInfo的名称字段进行绑定。 标签字段允许计算框架以key/value对的格式传递主观标签给服务发现系统。注意：通过这些字段传递的任何事情，是无法保障执行移动到下一步。虽然如此，字段提供扩展性。这些共同使用的字段允许我们确认需要请求第一类支持的例子。 |
|
|
