Ganga文档首页入口

3 实现

这章提供了GANGA中一些重要部分的当前实现细节。

3.1 组件

作业的各个组件以插件类的形式来实现，需用户在配置文件中设为enabled，则会由GANGA在启动时导入。这表示用户仅能看到与其特定工作环境相关的组件。

插件维护十分简单，采用了一组内部接口和一个产生代理类的机制。组件类继承自接口类。每个插件类都定义了一个schema，用它描述插件的属性和指定类型（只读/读写/内部）、可见性以及相关的用户友好(user-convinence)的过滤器和语法快捷方式(shortcut)。

与用户直接进行交互的不是插件类，而是一个自动产生的代理类，代理类在GPI中可见。代理类只包含插件类中的一些在schema中定义可见的属性以及选出用于导出的方法。插件和代理的层次（level)分离十分灵活。在GPI层插件的实现细节不可见；所有代理类都遵循相同的设计逻辑（例如按值拷贝copy-by-value)；持续性自动化，会话等级锁定透明。用这种方法，底层的内部的API就与用户层的GPI分离开。

框架不强迫开发者支持app和backend的所有组合，只要支持有意义和有趣的组合即可。为便于管理这些组合，提出了submission handler的概念。sumission handler是app和backend组件的一个连接器。在提交时间，它将app的内部表示（representation)传送给特定backend可以接受的表示(representation)。这种策略允许完全(inherently)不同的backend和app的结合，而不需要强制一个lowest-common-denominator接口。

3.2 作业保持（persistence）

作业仓库在一个简单数据库中提供作业保持，以便任何之后的Ganga会话都可以访问所有之前定义的作业。每当在Ganga会话中定义一个作业，它就会被自动地存入这个数据库中。作业仓库还提供了一个bookkeeping系统用来根据metadata挑选特殊的作业。metadata包括以下一些参数如作业名称、app类型、要提交的backend类型、以及作业状态等。它可以根据需要轻松地进行扩展。

GANGA同时支持本地和远程的作业仓库。在本地仓库的情况下，数据库存储在本地的文件系统中，它提供一个孤立的解决方案。在远程情况下，客户端访问AMGA metadata服务器。远程服务器基于网格证书提供与可信和授权用户的加密连接。表现测试中,两种仓库在每个用户高达10000个作业,每个下都仍旧表现出了良好的scalability，单个作业的平均生成时间大约是0.2秒。。。（各种好。。。）

作业仓库考虑到插件组件中的schema的升级维护，还包含了一个提供schema迁移的机制。

3.3 输入输出文件

Ganga在作业工作区存储作业的输入输出文件。在当前的实现中使用了本地文件系统，并且有一个简单的接口允许在Ganga构架下透明地访问作业文件。这些文件在为每个作业分别指定的目录中存储，该目录有一些子目录来存储输入输出文件或者用于子作业。

用户可以在文件系统中直接访问作业文件或者使用Ganga命令访问（如job.peek()).从内部来看，考虑到额外的工作区实现的琐碎的集成，Ganga通过一个简单的抽象层持有输入输出文件。测试表明。。。

远程工作区和远程作业仓库的结合有效地生成了一个漫游的profile，相同的Ganga会话可以在多个位置访问，这有点类似于在一个IMAP服务器上访问e-mail信息的情况。

4 监测

Ganga提供了两种类型的监测：内部监测用作业进程信息来更新用户，外部监测处理来自第三方服务的信息。

4.1 内部监测

Ganga使用监测程序自动保存作业状态的变更历程，这个监测程序设计用来处理变化的backend响应次数和加载功能。每个backend被poll进一个不同的从pool中取出的thread中，同时有一个有效的机制来避免响应较慢的backend造成的死锁。poll rate可以对每个backend都有单独的设定。

监测子系统也会保存权限证书的remaining有效性的历程，比如网格代理和Kerberos tokens.用户需要注意更新，而如果没有动作那么Ganga就会被置入状态，在该状态下操作需要有效证书会不可用。

4.2 外部监测