在一系列演讲中，Adrian Cockcroft谈到了他们如何转向Cattle Servers解决Netflix的可伸缩性问题。
具有这种区别的挑战始终是管理持久状态。将您的数据库服务器视为Cattle是否有意义？如果您（a）管理牛模型之外的状态（docker容器的外部卷），或者（b）使用像Cassandra这样的分布式数据库，该数据库允许单个节点发生故障，但仍保持集群中的状态，则可以。
我知道，通过将AMI启动到安装共享驱动器的计算机实例，您可以非常接近Docker容器安装共享卷的“具有持久状态的可处置性”。您可以通过拥有一个自动伸缩组来重新创建被淘汰的计算机，从而更进一步地了解计划群集管理的概念。
对我来说-机器实例缺乏docker容器的粒度。他们更倾向于“宠物”领域。
我的问题是：“牛不是宠物”的区别是否同样适用于机器实例和容器？
#1 楼
从技术上讲，容器和虚拟机有很大的不同，但是从软件的角度来看并没有明显的区别。看来您的问题中的论点是数据是特殊的，并且将永远是唯一的雪花，因此您的问题基本上可以归结为如何处理DevOps，CI和自动化方面的问题。这是DevOps模型的永恒挑战。最终，您要问的是，要么A）您的数据将存储在数据库中，要么B）一个数据存储区，那么如何管理它？答案是，是的，您的数据库服务器可以并且还应被视为牛-我最近详细介绍了一些在室内使用的技术。如果您不将数据存储（数据库，存储文件管理器）当做牛，您会发现您的数据库基础结构中存在单点故障，并且缺乏可伸缩性和冗余性。我在链接的答案中讨论的这些技术基本上使您能够以类似于Cassandra的方式分布和集群化关系数据库。
管理数据库（数据库）并使数据库（数据库）冗余可能是最多的DevOps面临的艰巨挑战。解决问题的最简单方法是：将头痛问题外包给云提供商。
总之，是的，“牛不是宠物”的区别同样适用于机器实例和容器。
评论
我认为值得一提的是，除了避免可伸缩性问题之外，对数据库和其他数据存储库采用“牛与牛”的方法将极大地改善灾难恢复的状况。将宿主视为牲畜的很大一部分具有很高的自动化水平，因此宿主始终处于同一水平。对于数据库，它有望包括一个自动的备份还原，因此从头开始部署和从灾难中恢复只是同一自动化的两个不同用例。
–耶路撒冷
17年6月1日23:21
评论
一分钟以为生产数据库应该是牛而不是宠物的人都不会理解生产数据库...但是除了数据库，还不清楚您打算使用哪种实例。使用内部卷使用nas或nas卷的前提基础结构，您可以做的完全一样，无论后台基础结构如何，牛与宠物都适用。
@ Michael-sqlbot最好在此基础上再扩展一点并创建答案...（至少，我很想阅读它！）
@MichaelB谢谢，但是我不确定这是主题。我的评论的重点是要承认，是的，数据库是一个明显的例外-它们是最终的状态维护者，贵族，固定的要塞/堡垒/事实和真理的大厦，而在没有扩展的地方因此，琐碎的主数据库（但不一定是副本数据库）完全不受适用于“工人阶级” VM和容器的可处置性范式的影响……对我而言，这是无可争议的，所以我目的是要问：问题中除了数据库之外还考虑了哪些案例？
@ Michael-sqlbot：我认为您正在混淆数据库服务器和数据。您的数据库服务器是100％一次性的。您的数据不是。如果您不这样认为，我建议您考虑一下您的想法对于以可支配的心态对待数据库服务器实例不起作用-将会面临哪些具体挑战-并提出这些问题。您可能会为克服这些挑战而得到的答案感到惊讶。