一千萬個為什麽

搜索

“牛不寵物”區別是否適用於機器實例和容器?



來自對牛與寵物的區別進行了很好的討論Randy Bias 此處馬丁福勒談論 SnowFlakeServer

系列演講中, Adrian Cockcroft 介紹了他們如何在解決可伸縮性問題方面轉向Cattle Servers, Netflix

這種區別帶來的挑戰始終是管理持久狀態一>。將數據庫服務器視為牛是否合理?如果您(a)管理您的牛模型之外的狀態(Docker容器的外部卷),或(b)使用分布式數據庫(如 Cassandra ,它允許單個節點失敗,但仍然保持群集中的狀態。

我知道你可以非常接近Docker容器的'持久狀態的可處置性'來安裝一個共享卷,並且啟動AMI到裝載共享驅動器的機器實例。您可以通過擁有一個自動縮放組來重新創建已經被吹走的機器,從而更加接近這個計劃集群管理的想法。

對我來說 - 機器實例缺乏碼頭容器的粒度。他們更傾向於“寵物”的尾聲。

My question is: Does the "cattle not pets" distinction apply as equally to machine instances as to containers?

轉載註明原文: “牛不寵物”區別是否適用於機器實例和容器?

一共有 1 個回答:

雖然技術上,容器和虛擬機有很大的不同,但從軟件的角度來看,沒有明顯的差異。您的問題中的觀點似乎是數據是特殊的,並且始終是一個獨特的雪花,所以您的問題基本上歸結為DevOps,CI和自動化方面應如何處理。

這是DevOps模型的永恒挑戰。最終,你要問的是,或者A)你的數據將在數據庫中或B)數據存儲,那麽你如何管理它?

答案是肯定的,您的數據庫服務器可以也應該被視為牛 - 並且我最近詳細介紹了幾種技術和技術所以在內部。如果不將數據存儲(數據庫,存儲過濾器)視為牛,則會發現數據(基礎)基礎架構中存在單點故障,缺乏可擴展性和冗余性。我在鏈接的答案中討論的這些技術基本上允許您以與Cassandra類似的方式分發和集群關系數據庫。

管理您的數據(基礎)並使數據(基礎)冗余可能是DevOps面臨的最困難的挑戰。解決問題的最簡單方法是:將頭痛外包給雲提供商。

簡而言之,是的,“牛不寵物”的區別同樣適用於機器實例和容器。