【专家问答（翻译稿）】关于Isilon Job引擎的技术讨论

用户Astack向专家提问：

Isilon 7.0版本后对JOB引擎的并行工作机制进行了重新定义，但是在一块磁盘故障的情况下，必须等到FlexProtect运行完成后其他JOB才能正常工作。如果在一个大型集群或者不带GNA的集群，这个FlexProtect的过程将会花费很长的时间。如果群集中有1000块以上磁盘，你可能会发现MTBF（平均无故障时间）将基本处于这种状态下，FlexProtect的过程会非常长。

当然，也有一种应对方法。我们可以在技术支持人员的配合下，通过将集群设置为“degraded（降级）”模式来禁止这个功能。这样FlexProtect就可以像其它OneFS Job一样并行运行。需要强调的是，这个操作只能在EMC技术支持授权的情况下进行。

我的问题是为什么JOB引擎机制是这样设计的呢？磁盘故障是经常发生的事情，不应该占有这么高的优先级。诚然，数据安全非常重要，但随着N+X保护模式和其它安全保护机制的应用，是否可以把Flexprotect就当做一个简单的后台任务。

您作为一个OneFS JOB引擎的专家，可否谈谈您对这样设计的看法呢？

专家Rash回复用户Astack如下：

你这个问题问的非常专业！除了FlexProtect或者FlexProtectLin Job引擎外，只要JOB来至于不同的Exclusion，3个JOBs都可以并行运行。当有磁盘出现故障，集群将会处于“降级（degraded）”模式，这种情况下只有“FlexPrtect”或者 “FlexProtectlin” 引擎允许运行，除非你在环境中覆盖这些参数。

在理想的情况下，用户都会遵循配置建议，根据集群大小和节点类型为集群设置正确的保护级别，并且将集群的使用率控制在90%以下，这种情况您当然可以在FlexProtect运行的情况下运行其它Job引擎。但是，有需要集群并没有运行在这种理想的情况下。例如：有些集群初始配置为4个节点，+2：1保护模式，但当节点数量增长到18后，保护模式是+2：1，而且可能使用率还达到了92%。如果在这种情况下我们还并行运行JOB，这些JOB将占用CPU和磁盘I/O。如果CPU和磁盘I/O利用率超过阀值，那么将威胁Isilon正在运行的所有Jobs的运行。另外，18个节点的集群坏二块盘的概率比4个节点的集群坏二块盘的几率高的多。当集群利用率超过90%以上，很难找到磁盘空间来重新保护数据，如果这时候其他JOB还在运行，还容易威胁到集群的正常运行。

对于Isilon来说保护数据是最重要的事情，Isilon开发人员认为不是所有集群都运行在理想状态。有些顾客会将性能和容量利用率用到极限，这样就要求我们在磁盘故障时，将FlexProtect JOB的优先级设置到最高，而且默认只能运行FlexProtect这个JOB。

也许系统应该根据不同的参数，例如：利用率、CPU、磁盘I/O和保护级别，让用户可以自动设置“降级（degraded）”模式选项。

专家Rash将介绍Isilon job引擎的一些基本信息：

Job引擎通过运行不同的JOB完成不同的任务，有些JOB是由事件触发的（例如：驱动器故障），有些JOB是功能型的（例如：删除快照），有些JOB是用户操作的（例如：批量删除数据）。

JOB引擎通过将任务分解成更小的工作单元，然后将这些工作单元分配给集群中的不同节点，以利用集群中的所有节点资源。每个节点可以运行一个或多个工作单元，这种机制促使任务可以更快的被完成。JOB引擎在后台运行这些任务，并使用每个节点的资源。OneFS 7.1.1.X及以上版本操作系统会监控资源（CPU和磁盘I/O）的利用，并可以自己调节分配到各节点的工作量。

Isilon Job引擎中的每个JOB都有Impact级别和priority级别二个参数：

Impact级别决定了多少资源将被用于完成这个任务。Impact级别越高的Job被完成的速度越快（在大多数情况下，除了少数工作流）。用户可以配置正在运行的JOB的Impact级别，比方说，OFF_HOURS就是指在工作时间之外运行。

Priority级别用于决定Isilon Job的优先级。OneFS 7.1.1.X之前的版本，任何时间Isilon都只允许运行一个Job，最高Priority级别的JOB在运行时，其它JOB只能等待。OneFS 7.1.1.X及以上版本，Isilon允许3个JOB同时运行，这3个JOB必须来源于Exclusion set。 当二个或者多个JOB属于相同的Exclusion set，Priority生效。或者

如果您对Isilon JOB运行机制非常了解，您可以自定义ISILON JOB的Priority级别或者Impact级别。当然在设置之前，最好咨询一下EMC技术支持的建议。

通过命令“isi job status -v”可以看到Isilon集群正在运行的JOB，下面列举了一些常见的JOB：

FlexProtect或者FlexProtectlin：当磁盘出现故障时，自动运行以保护数据。

SanpshotDelete：当快照过期时，SnapshotDelete将自动删除过期快照。

SmartPools：用于将数据移动到不同的数据层。

MultiScan：当节点被添加到集群后，运行2个JOB来实现Autobalance和Collect。

MediaScan：该JOB将在每月第一个周六自动运行，用于检查ECC和校正。

通过命令“isi job types list --verbose”或者网页 Cluster Management > Job Operations > Job Types，可以看到所有Job和日程表。

用户dynamox向专家提问：

您可以介绍一下FsAnalyze Job吗？据我所知，在初次扫描时它会扫描所有文件系统，并且用于以后快照的扫描。但每次我查看FsAnalyze Job所需时间时，它总是显示需要相同时间，难道初次扫描的结果没有被后面的快照使用吗？

用户Dynamox向用户Yan提问：

我好奇为什么Isilon不能清除失效的事情程序？现在的设计造成FSAnalyze扫描需要花费太长时间，和我理想中的统计有很大的差距！

用户Yan回复用户Dynamox如下：

根据以上EMC高级工程师Bernard Case提供的信息，我们曾经使用FSAnalyze扫描快照，这种机制似乎很好，因为通过整体扫描可以获得文件系统的连续视图。但是，这种方法也会遇到问题。如果FSAnaylze job在运行时被中断，该快照将处于hang状态，同时造成容量不断增长，最终可能耗尽整个集群的容量。这就是为什么后来停止使用FSAnalyze JOB来扫描快照。

因此，FSAnalyze也不再使用快照来加速后续FSAnalyze的运行。每次它都会重新扫描整个文件系统，在FSAnalyze Job的第一阶段，整个任务会被打散再分配各个节点，在FSAnalyze Job的第二阶段，系统将各个节点生成的db文件汇总成一个大的db文件，以便InsightIQ加载。第一阶段消耗的时间相对较少，第二阶段可能比较花时间。这就是为什么你觉得FSAnalyze Job运行起来比较慢。

据说在未来OneFS版本中会优化FSAnalyze的速度，不过我也是道听途说。

提示：通过命令"isi_fsa_tool list -v"可以看到FSAnalyze在第一阶段和第二阶段分别用了多少时间。第一阶段使用的时间是从“Start_time”到“merge_start”，第二阶段使用的时间是从“merge_start”到“end_time”。

用户Yan回复用户Dynamox如下：

当前的实现的确不理想，我认为你提到的差距主要是指FSAnalyze相关数据，而不是指InsightIQ中的集群性能统计。

如果你发现FSAnalyze第二阶段花费了太长时间，你可以验证当前合并索引选项设置（OneFS 7.x以以上版本）：

isi_gconfig -t job-config jobs.fsa.disk_usage_post_merge_indexing

如果设置为true，你可以将它改为false，看看是否能提高FSAnalyze第二阶段的合并时间。

如果设置为false，你可以在集群的一个节点运行如下命令：

isi_gconfig -t job-config jobs.fsa.disk_usage_post_merge_indexing=false

新设置将在你下次运行FSAnalyze JOB时生效。

用户Dynamox向用户YAN提问：

是的，我指的的确是IIQ中文件系统统计。

如果将当前值从”True“改成”False“会有什么后果呢？通过将值设置为”False“会有什么作用呢？我的OneFS版本为7.1.0.6。

用户YAN回答用户Dynamox提问如下：

概括地说：

第一阶段：集群中所有节点都将获得一部分工作，每个节点基于它们处理的文件系统都将生成一个单独的results.db文件。

第二阶段：所有单独的result.db文件将被合并成一个主result.db文件。

在第2阶段或者结束时，标记“jobs.fsa.disk_usage_post_merge_indexing”控制主result.db文件上的索引创建。默认情况下，当编辑为“true”时，它创建于第二阶段结束时。可是在第二阶段结束时创建索引会有一个问题，如果在索引创建的过程中FSAnalyze job发生中断，由于索引没有快照，所以索引创建将必须重新启动。

如果将标记“jobs.fsa.disk_usage_post_merge_indexing”设置为“False”，那么索引将被创建在之前，那么也就消除了索引创建被中断的风险。

注：在OneFS 7.1.1.5到7.2.0.3，这个标记值默认是“False”，因为“False”已经被证明是集群中最好的选择。

用户go向专家Rash提问：

问：我们可以像设置SyncIQ一样设置它吗？

答：当然，我们可以改变设置。在图形化界面SyncIQ可以轻松被设置，Isilon JOB Worker也可以在命令行设置。增加worker的数量会大量占用CPU资源，影响终端用户的性能，所以需要让工程师查看InsightIQ每日/每小时的性能数据，来调整worker的数量。最佳的增加和减少worker的方法是通过不同JOB的Impact level来设置，还有就是将任何job impact设置为高，都可能极大影响性能。

用户go向专家Rash提问：

问：每个节点的每个JOB使用多少个work呢？

答：这个值取决于JOB的Impact level和集群中节点的数量，

    Low Impact - 1 to 2 workers / node

    Medium Impact - 4 to 6 workers / node

    High Impact - 12 or more workers / node

每个JOB上的worker数量 = 那个JOB的Impact level × 集群中节点的数量