如何维持IT基础设施正常运行

　　如果你拥有一个大型的基础设施，你就必须保证它们被正确的配置，这样的话，每天你究竟需要做些什么?答案是Cfengine(配置引擎)。

　　如果你从建筑的观点考虑大型的计算基础设施，它们很少与整齐规划的社区类似;相反，它们类似于没有严格规划的城市。后者倾向于无规则的增长，平均计算基础设施也是如此。

　　正将为系统管理员带来问题，因为现有已经存在的脚本和监控机制将被破坏，然后再安装到新机器上。管理工具版本的轻微改变，对整个环境来说，不会花费大量时间。不过这回对正在运行的东西造成重大问题，因为管理工具非常脆弱(当环境中发生某些改变，如操作系统升级时，管理工具很可能被中断)。新人员的加入也非常令人头疼，你要尽快将它们的设备置于管理工具之下，这非常重要，当然也会花费许多。

　　Cfengine(配置引擎)被开发用来解决这些问题。与在不同的机器上运行一套轻微差异的工具不同，Cfengine(配置引擎)使用中心式方法进行管理，它声明一台机器应该如何被配置的定义，然后确保每台机器执行此定义。

　　这种方法的优点是显而易见的。首先，每台机器的定义只需要被放在一个地方; 这避免每台机器必须有它自己的一套管理工具，并且只能在那台机器上运行的的问题。其次，它允许简单的升级管理设置，一旦某一台机器发生变化并升级，就能够很容易的将其推送到所有剩余的基础设施中去。 最后，由于Cfengine(配置引擎)的宣言采用的是面向对象的方法，它能够用一套管理文件管理所有不同的机器(例如，Solaris和Linux)。

　　不过，这种强大的功能势必会带来一定的成本。乱七八糟的管理机制如此普遍，其中一个原因就是增加另一台机器需要的边缘成本较低;只有在考虑整个管理负担时，你才会发现那种方式在维持碎片式的基础设施时需要非常大的工作量。

　　执行Cfengine需要留出时间熟悉这种产品，并且根据基础设施的情况计划好实施的进度。一旦这些最初的实施Cfengine的努力结束，日常的管理工作量将大幅降低。

　　Cfengine以客户端/服务器(client/server)方式工作。一个中心服务器将定义系统配置，然后每台机器执行配置中的适用于它的所有部分。Cfengine的元配置能够被设置为允许客户机投票选举中心服务器，或者让中心服务器推送配置文件到客户机。

　　配置Cfengine

　　Cfengine运行的主配置文件叫做cfengine.conf，下面是此文件的一个非常简单的例子:

　　# Comment...

　　control:

　　actionsequence = ( links )

　　links:

　　sun4::

　　/bin -> /usr/bin

　　# other links

　　osf::

　　# other links

　　本质上，control(控制)部分列出了有关系统的和Cfengine应该采取何种动作的元信息。既然这样，“links”就是要执行的动作。在配置文件的“links”部分，就定义了动作本身。

　　在links部分，你将看到两个条目，一个是“sun4::”，另一个是“osf::”。这里的双冒号表示的是Cfengine调用何种类，指的是分享一套特征的一系列机器的术语。假若这样，上面配置中的特征指的就是操作系统的类型。因此，在配置文件中无需列出每一台机器，而是只需列出它们的类即可。当客户机执行配置文件时，它将根据所列出的类，确定这种类应该适合的动作，进而执行这种动作。类的确定丰富多彩，不只是操作系统类型可以确定类，如天、星期和月份同样能够定义一个类，你只需从中选择Cfengine能够让日常维护或升级任务更便利的即可。

　　我们在上述例子的配置文件中仅包含了一个动作:links(链接)。而Cfengine在设置动作方面，有着更丰富的选择。这里列出了一些可能的动作:groups(组合)、control(控制)、homeservers(主服务器)、binservers(执行文件服务器)、mailserver(邮件服务器)、mountables(挂载表)、import(导入)、broadcast(广播)、resolve(解析)、defaultroute(默认路由)、directories(目录)、miscmounts(杂项挂载)、files(文件)、ignore(忽略)、tidy(整理)、required(必需)、links(链接)、disable(禁用)、shellcommands(shell命令)、editfiles(编辑文件)、processes(过程)。

　　使用这些众多的动作组合，Cfengine为我们提供了一个非常强大的管理工具。因为它了解这么多的动作，所以系统管理在声明方面有多得多的方法:你只需仅仅定义你想执行某种任务的基础设施的特征，Cfengine就会加以执行。

　　如果你阅读了我之前的有关Nagios的文章(Nagios是另外一个具有很大可伸缩性的集中式系统管理工具)，你可能想直到到底该选择Cfengine或Nagios中的哪一种，才能够适合你的要求。不过结果却很可能是不必在它们之间进行选择，使用其中一个，却抛弃另一个，因为它们关注的领域并不完全相同。Cfengine擅长的是执行标准的系统管理任务，但它不能够提供更多的扩展性(虽然shellcommands――shell命令动作提供了添加新命令的能力)，而Nagios则主要集中于当某件事情出现问题时，发出警告的能力上。虽然在这两个工具之间，还是存在着功能上的重叠，但它们却能够通过配置，达到互为补充，共同高效的管理公司的IT基础设施。

　　这篇文章只是简略谈了Cfengine的能力，并且在Cfengine灵活的声明配置上，也仅仅触及到一点皮毛。由于Cfengine是如此的综合和复杂，这里给出一些如何更进一步学习和使用Cfengine的指引:

　　l 在Cfengine的官方网站www.cfengine.org深入了解Cfengine。充分利用此网站上存在的优秀资源和教学指南。

　　l 以小的和简单的配置开始使用Cfengine。上面的“links”例子提供了学习和使用Cfengine的好方法。从中我们可以发现，一个重要的，需要花费大量时间的系统管理任务可能并不复杂。开始时，可以在两台或少数几台机器上执行自动化任务，然后在此基础上进行增加。

　　l 用几周的时间仔细加以研究，以确定Cfengine的执行效果。理解Cfengine的系统需要时间，也同样需要实验。不要尝试做的太多太块，贪多嚼不烂的道理在这里得到了验证。

　　l 在你将初始配置投入使用并正常运行后，继续采用双重方式。检查Cfengine所管理的机器，确保你设想的情况与实际发生的情况相一致。

　　实施Cfengine，看起来好像需要进行大量的功能才能让其正常运行，但考虑到在Cfengine正确配置后，节省下来的大量手工检查机器的工作量，我们将发觉实施Cfengine还是非常有意义。对比前后的变化，从根本上来说，Cfengine可以说并没有花费太多的工作，而是节省了时间，提升了工作的效率。

　　Bernard Golden是Navica Inc.的CEO，Navica Inc.是一家专注于开放源码软件的系统整合公司。Bernard Golden为SearchEnterpriseLinux.com撰写名为Golden's Rules的专栏，并且回答有关开放源码软件的问题。