假设环境中包含由人偶管理的，由不同服务器组成的群集-各种硬件，软件，操作系统，虚拟/专用等。
您是否要选择有意义的主机名（mysqlmaster01..99， mysqlslave001..999，vpnprimary，vpnbackup等）还是您更喜欢无意义的主机名，例如书或电影中的字符？
我看到的有意义的主机名存在的问题是名称通常代表单个服务如果服务器具有多个用途，则它会变得很混乱（尤其是服务器角色经常更改）。
不是将服务名称映射到IP地址，而是保持该DNS应该映射的映射
这两种方法的优缺点是什么？选择的方法必须解决哪些实际问题？
#1 楼
从前，我有机会决定一个命名方案。因此，我四处询问了我的开发人员，这些开发人员毕竟是每天必须使用这些名称的人员，他们是否更喜欢功能名称（即以某种编码形式表示名称的名称）。机器的用途）或助记符名称（即，从某些先前存在的人类命名方案中提取的名称，其中不包含有关机器用途的隐式内容）。在38个开发人员中，有37个首选助记符名字;只有一个首选功能名称。因此，我都以河流命名（有很多可能的名字，其中许多都很简短，易于记忆并且可以快速键入）。
人脑设计得很好用于在名称上附加含义。如果您提供令人难忘的名称，人们会很快记住这些名称的用途并加以使用。如果使用来自某些常见背景的名称（例如河流，元素，星星，县，酒水，您就会想到），它可以帮助人们在遇到公司名称时立即识别出该公司的名称；否则，诸如“所有电子邮件均以
betelgeuse结尾”之类的陈述可能会有点混乱。]相反，我的开发人员感到，他们在以前的工作中很难记住pr1ms001的确切含义。 br /> 但是我应该补充一点，我们在内部DNS中使用了CNAME来提供功能名称到助记符名称的映射，因此，如果您真的容易记住，在PR站点的第一个群集中的主邮件服务器是
pr1ms001，那么DNS会让您知道当前是orwell。另外，这使我们每台计算机拥有许多功能名称，因此，只要您始终使用与正在使用的功能相关的功能名称，就可以确保pr1imap001始终指向IMAP服务器，即使我们将其移动了从orwell到rhine的功能。当hudson死后，我们可以在不影响操作功能的情况下更改替换的名称，因此我们再也没有“您是指新的hudson还是旧的hudson？”困惑。评论
您可能会认为，但是我的开发人员说，无论是否传递其他任何内容，助记符方案都更好，因为他们都建立了自己的内部状态表（位于什么地方），并且这样的内存更容易建立在名称上人类的大脑喜欢记忆。
– MadHatter
13年2月18日在14:25
您应该以冰岛的火山命名。
– Chloe
13年2月20日在4:50
+1代表“河流”；）
–科尼拉克
13年2月20日在7:18
这是一个很棒的主意，我正在偷它。
–SpacemanSpiff
13年2月28日在2:13
我同意以这种方式命名服务器在自动构建系统中的工作更多，但是我注意到构建服务器的目的是供其他人使用它们-上面的数据来自必须使用它们的人。可能是他们想要的东西已经改变了，但是我认为我们在服务器管理上的决定应该以使我们的工作变得简单的更多为基础。
– MadHatter
15年6月11日在18:06
#2 楼
这主要取决于您的服务器是pets还是livestock。宠物可以使用单独的名称。它们彼此不同，我们关心这些差异。当一个人生病时，我们通常会尝试将其恢复健康。传统上，服务器是宠物。牲畜获得数量。它们大部分是相同的，并且有什么区别，我们不在乎，通常会尽量减少。当一个人生病时，我们把它放下来，再得到另一个。完全虚拟化的服务器，尤其是IaaS服务器（例如AWS）是牲畜。
在大多数复杂的环境中，您混在一起。例如，您的Web后端几乎可以肯定是牲畜。如果需要更多功能，则可以使用标准配置增加一些功能。如果不需要那么多，可以将其关闭。在某些配置中，数据库服务器是宠物。每种设置可能有很多特殊设置；您甚至可以在裸机上而不是在虚拟机上运行它们。
当然，在两种环境中，您都可以命名SERVICES并直接对其进行寻址。无论如何，这都是最佳做法。您的开发人员不需要知道或关心服务的实际主机名是什么。主机名应该纯粹是操作细节。然后，考虑对主机名称中的操作人员有用的信息进行编码-例如，通常指示服务器所在的数据中心通常会很有帮助。
评论
宠物或家畜-这是放置它的好方法。
–迈克尔·汉普顿
13年2月18日在21:17
我最近在以下位置重新找到了我第一次看到此概念的文章：gregarnette.com/blog/2012/05/cloud-servers-are-not-our-pets
–泰利
13年5月6日在20:16
谢谢@Ian我一直在寻找那篇文章的最后一天，SEO失败了，呵呵
–旧帐户
15年3月24日在17:10
#3 楼
我的建议是功能名称和助记符名称的组合...
如果您正在编写应用程序，则需要地址
ccts-logserver1，请始终使用该名称，但要使用CNAME或别名。真实的主机名可以是您想要的任何名称：水果或蔬菜，希腊神话或Seinfeld字符...但是当您需要关联真实的功能名称时，它为您提供了一定的灵活性，但保留了人们可以记住的名称。以
mango的示例为例，数据库服务器发生故障...但是被其他内容代替，例如peach。也许现有的流程和应用程序需要查看cmt-prod-db1。您可以交换系统，构建它们而无需命名冲突，并使应用程序（和开发人员）满意。#4 楼
在我工作的地方，我们管理着多个城市中的多个站点，多个公司。对我们而言，助记符名称无效。相反，我们使用描述服务器的简写形式。这在我们的情况下效果很好，因为我们有一些客户端，这些客户端可能在不同域上有多个办公室（或在多个域上有一个办公室，或在同一域上有多个办公室，或以上所有！） >对于我们来说，该信息包含公司/域名，城市，职能，编号。因此，对于公司的域控制器来说，赛普拉斯在芝加哥说的是：CYPRCHSQL001就是SQL服务器CYPRCHMGM001将是其管理（即防病毒，备份等），而CYPRCHAPP001将是混合应用程序服务器。易于记忆，易于分类，易于教学。
评论
因此，您还记得在CYPRCHAPP001而不是CYPRCHAPP003上运行哪些应用程序？我承认这也与词组名称有关，但是，如果您要使用某种功能名称，则可能也要具体。
–用户
13年2月18日在19:44
@MichaelKjörling服务器上的详细信息并不属于名称，它们属于某种文档。如果有人需要了解CYPRCHAPP001上正在运行的内容，请阅读文档。除了移动应用程序外，当公司将薪资软件移动到托管解决方案时，CYPRCHAPP001_PointofSale_Payroll_HRSoftware-etc也将被误用。
–沃尔夫哈特
13年2月19日在23:17
@Wulfhart我同意您的观点，但是使用CNAME作为销售点，工资单等有什么问题？这样，除了系统管理员之外，没有人需要真正关心工资软件的运行位置。对于其他所有人，它都可以正常工作。想要将东西移到另一个数据中心吗？没问题是否要将销售点系统数据库移至其专用服务器？只需更新销售点数据库CNAME以指向新位置即可。等等。
–用户
13年2月20日在8:47
假设您需要更换一台机器：构建CYPRCHSQL002并对其进行测试后，您是否要撤消CYPRCHSQL001的名称（从不更换），或者在删除旧的001之后将002重命名为001，或进行其他操作？其他？
– nickgrim
13年2月20日在11:22
@MichaelKjörling对我来说似乎是个好主意。 “特定名称不属于名称”是指不在计算机的主机名中。
–沃尔夫哈特
13年2月20日在22:39
#5 楼
主机名的唯一要求是它们在网络上应该唯一。含义不仅仅与服务器功能有关。如果您必须处理物理设备，则位置非常有用。知道设备是虚拟的还是物理的也很有用。在弄清楚要使用哪种工具登录时，能够分辨出网络设备，Linux服务器或Windows盒之间的区别非常方便。
我们处理它的方法是请尝试按以下方式将此信息放入设备名称：
L或T-实时或测试
P或V-物理或虚拟
S或N-服务器或网络（我们没有任何Linux服务器）
确保唯一性的序号
ISO 3166-1三个字母的国家/地区代码，指示设备的位置。
然后我们使用DNS中的CNAMES可以将各种服务名称映射到主机名。
对此我百感交集。当然，它省去了查找特定设备所在位置的时间。另一方面，与我们以前使用宝石的系统相比，记住给定服务器的主机名时要记住的工作要困难得多。宝石一点也不暗示任何意义，但是它们很容易记住，因为每个人都可以创建自己的联系。
我想唯一的建议是将一个模式视为最大的困惑。当我们从一个系统过渡到另一个系统时出现了。
评论
我确实不同意这一点：在命名讨论的上下文中，“知道设备是虚拟的还是物理的也可能有用”。当然，这是有用的信息，但这并不是您需要通过读取服务器名称来了解的第一件事。此外，P2V或V2P要么破坏您的方案，要么需要重命名服务器，这可能会破坏其他内容。
– mfinni
13年2月19日在15:38
以我的经验，P2V或V2P破坏了很多事情，应该尽可能避免使用-我们这样做了，因此命名约定不是问题。命名约定必须满足设计它的人的要求-在我工作的组织中，命名约定是由管理所有服务器和网络设备的团队设计的，他们希望能够说出上述内容。它可能不适合您，但是所有这些都可以辩论。唯一的技术要求是唯一性。
– Dunxd
13年2月20日在12:46
评论
如果您控制DNS，则可以始终同时进行。我将其保留在这里：RFC 1178
尽管从表面上看是一个基于意见的问题，但实际答案是基于实证和经验调查，并基于人类的认知功能（人脑如何记忆事物）。我认为这个问题应该重新讨论。