OpenSVC刚刚移植到FreeBSD平台。那份声明中的小信息引起了我的兴趣,于是我去了OpenSVC网站,发现了以下内容:
OpenSVC是一个“服务”管理器,就像集群服务管理器一样,为现实世界中的异构数据中心和大规模操作协调器(例如灾难恢复)而设计。服务是资源的集合(虚拟机、ip、磁盘组、文件系统、文件同步和应用程序启动程序)。服务可以启动、停止和查询状态,为非常不同的服务集成类型提供一致的命令集。服务配置、状态和日志被推送到连接到web前端(收集器)的中央数据库中。服务可以使用部署在节点(nodeware)上的独立GPLv2软件栈管理,也可以通过web前端进行管理。
加上一些UML类型的图形。这一切都很整洁,但我还是不明白:它是做什么的?我是不是太笨了?这个系统的用例是什么?
发布于 2010-06-16 21:19:06
我将尝试描述特定的案例来解释OpenSVC的有用性。
以公司中的系统管理员为例,他为客户/用户提供服务。他负责大约50项服务。他喜欢FreeBSD,所以他倾向于在这个基础上部署他的服务。他很好地掌握了r快照是如何工作的,所以他创建了一些脚本来自动备份,并且尽职尽责地准备好了脚本,以帮助从服务器崩溃中恢复过来,甚至可能会导致站点瘫痪。
下一个小隔间的系统管理员还负责大约50项其他服务。他也会做好家庭作业,但要有自己的风格。他可能更喜欢Linux和rsync,他的恢复脚本将位于不同的位置(可能在它的桌面中)。他的客户可能需要更多的可用性,所以他不得不选择一个集群堆栈。
现在可以扩展到几十个管理员和成千上万的服务。数据中心是一系列技术:3到4种不同的操作系统,2种不同的存储硬件,它们有自己的复制协议(日立影子副本,emc srdf,netapp snapmirror),2种集群堆栈(hacmp,redhat集群,own集群,veritas集群),以及无数不同的脚本,用于在小范围内自动执行操作。
想象一下一些频繁的场景:o泄露到机架上: 20台服务器关闭,50项服务需要故障转移,10名不同的管理员与他们的所有具体故障转移机制一起停电:相同的草图,一个10倍的公司外包了服务监控:很难相信微调的服务启动/停止行动的责任和系统管理员的翻转:所有的微调不容易传递给新来的人。
OpenSVC可以被看作是一个免费的、易于部署、部署无处不在的集群堆栈.低关键度服务只能有一个节点。中等关键度服务可以有两个节点,没有自动故障转移。高关键度服务,具有自动故障转移的2+节点加上一个用于灾难恢复的远程节点。
为所有人提供相同的工具,尊重每个系统管理员的偏好(os、虚拟化模型、文件系统、复制方案)和每个可用目标,为不同类型的集成提供停止/启动/复制操作。
我把这个例子集中在一个大规模的环境上,以突出OpenSVC的实用性,但在现实生活中,许多用户使用OpenSVC来管理1到4个服务,只是为了展示他们以前维护过的许多脚本。
网络收集器带来了额外的优势,作为一个报告,警报和数据挖掘前端.此组件不是GPL‘’ed的,但不需要从上面的内容中获益。自由职业者倾向于使用互联网收集器来为他们为不同客户提供的服务提供单一的报告点。
希望它有助于澄清OpenSVC在集群世界中的地位。
发布于 2010-06-16 17:40:18
听起来它是数据中心中的机器集群上服务状态的聚合器。比如,监控您的文件服务器、web服务器、NFS服务器、虚拟机等的中心位置,以及状态日志等等。
此外,听起来您可以重新启动服务,停止它们,"ping“它们,etc...basically是帮助从一个地方控制和监视数据中心中的许多计算机的工具。
发布于 2010-06-16 20:59:53
有几个用于高可用性Linux的集群服务管理器。(不过,我没有更多的链接)这似乎是一个以FreeBSD为中心的服务,可以在集群设置中管理资源(例如,确保web服务器在集群@中的至少一个节点上随时可用,等等)
https://serverfault.com/questions/151803
复制相似问题