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 個服務，只是為了分發他們之前自己維護的大量腳本。
Web 收集器作為報告、警報和資料探勘前端帶來了額外的優勢。該組件不是 GPL 許可的，但不需要從上述組件中受益。自由工作者傾向於使用網路收集器來對他們為不同客戶維護的服務進行單點報告。
希望它有助於闡明 OpenSVC 在叢集領域的地位。
答案2
聽起來它是資料中心機器叢集上服務狀態的聚合器。也許是一個監控檔案伺服器、Web 伺服器、NFS 伺服器、虛擬機器等以及狀態日誌等的中心位置。
此外，聽起來您可以重新啟動服務、停止它們、「ping」它們等等……基本上是一種幫助從一個地方控制和監視資料中心中的大量電腦的工具。
答案3
有幾個集群服務管理器高可用性Linux。 （不過，我沒有更多的連結）這似乎是一個以 FreeBSD 為中心的產品，用於管理叢集設定中的資源（即，確保 Web 伺服器在叢集中至少 1 個節點上始終可用， ETC）