OpenSVC只是移植到FreeBSD平台上。 这个消息让我感到很兴奋，所以我去了OpenSVC网站 ，发现这个：
OpenSVC是一个“服务”pipe理器，就像在集群服务pipe理器中一样，为真实世界的异构数据中心和大型操作协调器（例如灾难恢复）而devise。
服务是资源（虚拟机，IP，磁盘组，文件系统，文件同步和应用程序启动器）的集合。
可以启动，停止和查询服务的状态，为大量不同的服务集成types提供一致的命令集。
服务configuration，状态和日志被推送到耦合到Web前端（收集器）的中央数据库。
可以使用部署在节点（节点软件）上的独立GPLv2软件堆栈或通过Web前端来pipe理服务。
再加上一些UMLtypes的graphics。 哪一个都很整齐，但我还是不明白：它是做什么的？ 我只是密集？ 这个系统的用例是什么？
我将尝试描述具体案例来解释OpenSVC的用处。
考虑一个公司的系统pipe理员，他为客户/用户build立服务。 他有大约50个负责的服务。 他喜欢FreeBSD，所以他倾向于在这个基础上部署他的服务。 他很好地掌握了rsnapshot是如何工作的，因此他创build了脚本来自动执行备份和尽职的准备脚本，以帮助从服务器崩溃中恢复，甚至可能会导致网站被黑掉。
隔壁的系统pipe理员也负责约50个其他服务。 他也会做正确的功课，但有自己的风格。 他可能更喜欢Linux和rsync，他的恢复脚本将在不同的位置（可能在桌面上）。 他的客户可能需要更多的可用性，所以他必须select一个集群堆栈。
现在扩展到数十个pipe理员和数千个服务。 该数据中心是一个技术拼凑：3到4个不同的操作系统，2个不同的存储硬件与自己的复制协议（Hitachi影子副本，emc srdf，netapp snapmirror），2个群集堆栈（hacmp，redhat群集，suncluster，veritas群集），无数的不同的脚本来自动化小周边的行动。
并描绘出一些频繁的情况：o机架泄漏：20台服务器停机，50台需要故障转移的服务，10台不同的pipe理员及其所有特定的故障转移机制o站点停电：相同的草图，10倍o公司外包了服务监控：很难相信低调的筛选器，具有微调的服务启动/停止操作的响应能力o系统pipe理员的转换：所有的微调都不容易传递给新手。
OpenSVC可以被看作是一个免费的，易于部署的，部署在任何地方的集群堆栈。 低评价服务只能有一个节点。 中等批评服务可以有2个节点，没有自动故障转移。 高评价服务，2 +节点自动故障切换加上一个远程节点的灾难恢复。
为所有人提供相同的工具，尊重每个系统pipe理员首选项（操作系统，虚拟化模型，文件系统，复制scheme）和每个可用性目标，为这些不同types的集成提供停止/启动/复制操作。
我将这个例子集中在一个大规模的环境中来突出OpenSVC的用处，但是在现实生活中，许多用户使用OpenSVC来pipe理1到4个服务，只是为了清除以前维护的很多脚本。
networking收集器带来了额外的优势，如报告，警报和数据挖掘前端。 这个组件不是GPL的，但不需要从上面获益。 自由职业者倾向于使用互联网收集器为他们为不同的客户维护的服务提供单点报告。
希望它有助于澄清OpenSVC在聚类世界中的位置。
听起来就像它是数据中心中一组机器上的服务状态的聚合器。 也许就像是一个集中监控你的文件服务器，networking服务器，NFS服务器，虚拟机等的地方，还有状态日志等。
此外，听起来像你可以重新启动服务，停止他们，“ping”他们等…基本上是一个工具，帮助从一个地方控制和监视数据中心的大量计算机。
有几个高可用性Linux的集群服务pipe理器。 （尽pipe我没有更多的链接）这似乎是一个以FreeBSD为中心的产品来pipe理集群设置中的资源（即，确保集群中至less有一个节点上的Web服务器可用@等等）