OpenSVC 刚刚移植到 FreeBSD 平台。公告中的简短介绍引起了我的兴趣，所以我去了OpenSVC 网站并发现了这一点：
OpenSVC 是一个“服务”管理器，就像集群服务管理器一样，专为现实世界的异构数据中心和大规模操作协调器（例如灾难恢复）而设计。
服务是资源（虚拟机、IP、磁盘组、文件系统、文件同步和应用程序启动器）的集合。
可以启动、停止和查询服务状态，为截然不同的服务集成类型提供一致的命令集。
服务配置、状态和日志被推送到与 Web 前端（收集器）耦合的中央数据库。
可以使用部署在节点（节点软件）上的独立 GPLv2 软件堆栈或通过 Web 前端来管理服务。
加上一些 UML 类型的图形。这些都很棒，但我还是不明白：它有什么用？我是不是太笨了？这个系统的用例是什么？
答案1
我将尝试描述具体案例来解释 OpenSVC 的实用性。
假设一家公司的系统管理员为客户/用户设置服务。他负责大约 50 项服务。他喜欢 FreeBSD，因此他倾向于在此基础上部署服务。他非常了解 rsnapshot 的工作原理，因此他创建了脚本来自动执行备份，并尽职尽责地准备了脚本来帮助从服务器崩溃甚至网站中断中恢复。
隔壁隔间的系统管理员还负责大约 50 个其他服务。他也将做好自己的功课，但有自己的风格。他可能更喜欢 Linux 和 rsync，他的恢复脚本将位于不同的位置（可能在其桌面中）。他的客户可能需要更高的可用性，因此他不得不选择集群堆栈。
现在扩展到数十名管理员和数千个服务。数据中心是各种技术的拼凑：3 到 4 种不同的操作系统、2 种不同的存储硬件及其自己的复制协议（日立影子复制、EMC SRDF、NetApp SnapMirror）、2 个集群堆栈（HACMP、Redhat 集群、Suncluster、Veritas 集群）、大量不同的脚本，用于在小范围内自动执行操作。
想象一下一些常见的场景：o 机架泄漏：20 台服务器宕机，50 个服务需要故障转移，10 个不同的管理员以及他们各自的特定故障转移机制o 站点停电：相同的草图，十倍o 公司已将服务监控外包：很难信任低调的筛选人员对经过微调的服务启动/停止操作负责o 系统管理员的更替：所有的微调都不容易交给新来者。
OpenSVC 可以看作是一个免费、易于部署、随处部署的集群堆栈。低关键性服务只能有一个节点。中等关键性服务可以有 2 个节点，没有自动故障转移。高关键性服务，2 个以上节点，具有自动故障转移功能，外加一个用于灾难恢复的远程节点。
对所有人都使用相同的工具，尊重每个系统管理员的偏好（操作系统、虚拟化模型、文件系统、复制方案）和每个可用性目标，为不同类型的集成提供停止/启动/复制操作。
我重点介绍了大规模环境中的示例以突出 OpenSVC 的实用性，但在现实生活中，许多用户使用 OpenSVC 来管理 1 到 4 个服务，只是为了分发他们之前自己维护的大量脚本。
网络收集器作为报告、警报和数据挖掘前端，具有额外的优势。此组件未获得 GPL 许可，但无需从上述功能中获益。自由职业者倾向于使用网络收集器来为他们为不同客户维护的服务提供单一报告点。
希望它有助于明确 OpenSVC 在集群世界中的地位。
答案2
听起来它像是数据中心中机器集群上服务状态的聚合器。可能像是一个用于监控文件服务器、Web 服务器、NFS 服务器、虚拟机等以及状态日志等内容的中心位置。
此外，听起来您可以重新启动服务，停止它们，“ping”它们等等......基本上是一个帮助从一个地方控制和监控数据中心中的大量计算机的工具。
答案3
有多个集群服务管理器用于高可用性Linux. （不过我手边没有更多链接）这似乎是一个以 FreeBSD 为中心的产品，用于在集群设置中管理资源（即确保 Web 服务器在集群中至少 1 个节点上始终可用，等等）