4 revs, 2 users 69%unkn Asked: 2009-06-02 13:59:44 +0800 CST2009-06-02 13:59:44 +0800 CST 2009-06-02 13:59:44 +0800 CST 命名约定 [重复] 772 可能重复： 正在使用的最易于管理和最有趣的服务器命名方案是什么？ 你如何决定一个新的主机名？ hostname 18 个回答 Voted Michael Renner 2009-06-02T15:55:03+08:002009-06-02T15:55:03+08:00 很大程度上取决于你工作的环境。 首先也是最重要的 - 放弃对（流行）文化的任何引用，坚持使用有意义和描述性的名称。 您可能知道“zeus”是代理服务器，因为您安装了它。但是任何未来的同事都非常想通过它的作用来引用服务器，而不是他的名字。 如果您接受这一点，我建议您进行头脑风暴会议并写下您拥有哪些不同类型的网络实体（“主机”），如何将它们组合在一起以及哪些信息足够重要以编码在主机名中。您的命名约定应该能够明确地命名所有现有设备，并让用户大致了解主机的功能。一定要留出足够的增长空间来适应未来的发展，这样你就不需要在几个月内放弃你的命名约定。 记录您的命名约定（不仅是如何，还有为什么），确保需要定期使用它的每个人都了解它的布局，对评论/建议持开放态度，不要将其吹捧为圣杯，在需要时进行调整。 例子 作为思考的食物，这是我们在我的一位前雇主使用的架构： Web 服务提供商，为 Web 项目做开发和运营。主要是 LAMP 的东西，尽管规模更大（项目规模，而不是数量）。 对于物理设备： <站点>-<机架>-<设备>.in.<域>.<TLD> SITE 是唯一的站点标识符，主要是三个字母 RACK 是我们分配的或从托管设施接管的标识符，应该能够在 SITE 唯一标识机架 DEVICE 是一个“设备类”，后面有一个计数器，例如 vnodeXX 用于 OpenVZ 节点，swge 用于千兆交换机等。 DOMAIN/TLD 是给定设备所有者的域。 对于逻辑实体： 逻辑实体可能是任何具有与给定物理设备/位置没有强耦合的 IP 地址的东西。这主要是客户操作系统的 IP 地址（在我们的例子中是 OpenVZ 或 ESX）。 <项目>-<环境>-<服务>.in.<域>.<TLD> PROJECT 是一个项目标识符，它将项目的各种服务组合在一起。 ENVIRONMENT 可以是生产、分期或开发，4 个字母缩写 SERVICE 的形式相对自由，但常见的情况是标准化的，例如 web、db、mailout 等。 DOMAIN 是相关项目的主要域。 对于 IP 地址： 我们所有的服务都只能从专用网络访问，我们有 NAT 和/或带有“服务 IP 地址”的负载平衡器，面向互联网的主机使用它们来访问我们的服务。对于那些我们使用这样的东西： <项目>-<环境>-vip-<标识符>.<域>.<TLD> IDENTIFIER 是唯一标识 IP 地址用途的东西，例如，专门用作德国域项目的 Web 虚拟主机的地址可能称为“wwwde”。 总结一下 命名约定对我们来说很好用，有些人（比如我们的开发人员；））可能会称它为夸大其词。请记住，如果您只维护一个站点并拥有分配给单个项目的服务器，那么这完全是夸大其词。但对我们来说，它完成了一些非常重要的事情。 在处理逻辑实体的主机名时，我们总是知道： 涉及哪个项目： 不同的项目对不同的负责开发团队具有不同的重要性。快速浏览一下主机名会告诉您如何确定任务的优先级以及您需要在管理/开发方面询问谁 主机所在的环境： 开发环境中的问题会导致开发人员速度变慢。暂存环境中的问题会给测试人员带来痛苦，并可能危及产品展示。如果生产受到影响，公司就会赔钱。 受影响的子系统： 邮件后台处理程序、批处理工作程序等并不那么重要，但如果 Web 或数据库服务器出现故障，事情就会很快变脏。 对于物理设备，确切的位置总是可以从主机名中推断出来的。 物理设备和逻辑服务器之间的弱耦合可能会让某些人感到厌烦（例如，当我拔掉交换机 x/server y 的插头时，我怎么知道哪些项目会受到影响），但这是必须的我们的环境，因为我们的项目具有很高的周转率，而且通常我们甚至不知道哪些项目将托管在我们刚刚配置的新硬件上。 Kevin Colby 2009-06-02T14:05:46+08:002009-06-02T14:05:46+08:00 对于服务器，我喜欢我办公室目前使用的标准 <3 个字母位置代码>-<2 位递增数字以避免重复名称> 一个例子是：PHOU-DMOSQL01 身体的 休斯顿 演示环境 SQL 服务器 01 对于台式机/笔记本电脑，我通常使用类型指示符和用户名（假设机器分配给特定用户）（LT|DT）- 例如我的笔记本电脑是 LT-KCOLBY V. Romanov 2009-06-02T14:15:55+08:002009-06-02T14:15:55+08:00 真正的答案是没有答案。 我为服务器和计算机名称尝试了许多约定。我的结论是，名称本身是没有意义的，只要您有一个现成的、容易且不会因此而修改的描述字段。 因此，我对此的看法是——发疯。幻想英雄、StarWars 图标、神话 - 任何适合您的幻想，并且有足够的范围来包含您现有的所有主机和扩展。（并且不会剔除您的管理层经常缺乏幽默感，老板可能对名为“pointyhaireddimwit”的服务器很挑剔:)）。 niXar 2009-06-03T05:23:21+08:002009-06-03T05:23:21+08:00 我使用独特的名称来描述独特的机器。例如，在我当前的项目中，200 多台服务器，我使用了来自 Wikipedia 的星名列表。原因是实际名称比超级紧凑索引（例如 srv-05-92）具有更多冗余。这对一件事很重要：在嘈杂的服务器机房中转录、打字或通过电话交谈时，它的错误率很小。 描述性信息存储在 DNS 的 TXT 字段中，Mac 地址等也是如此。也可以根据mac地址请求名称： $ host 00-12-34-56-78.mac.fr.dom 00-12-34-56-78.mac.fr.dom is an alias for arcturus.eqx.vl304.fr.dom arcturus.eqx.vl304.fr.its has address 10.21.4.30 您绝对要避免的一件事是根据机器的功能命名机器。这迟早会咬到你的屁股。只需为此目的使用别名（CNAME 或附加 A 记录）。 注意：这都是使用自定义 XML 文件中的 XSLT 生成的： <?xml version="1.0" standalone="yes"?> <domain suffix="dom" xmlns:h="http://www.w3.org/1999/xhtml"> <vlans> <vlan name="vl304" value="4" /> </vlans> <country code="fr" prefix="10.21"> <datacenter name="eqx" desc="Equinix"> <host name="arcturus" lso="30"> <vlan name="vl300" if="eth0" mac="00:12:34:56:78" /> <txt type="loc">rack 5</txt> <txt type="sn">99A0632</txt> <txt type="model">xSeries x3350</txt> <doc>Load balancer</doc> <rsa ip="192.168.101.30" /> <role type="loadbalancer1" /> </host> </datacenter> </country> </domain> 生成了几个别名： arcturus.eqx.vl306.fr.dom（规范名称） arcturus.vl306.fr.dom arcturus.fr.dom 00-12-34-56-78.mac.fr.dom arcturus-rsa.fr.dom loadbalancer1.eqx.vl306.fr.dom loadbalancer1.vl306.fr.dom loadbalancer1.fr.dom ...以及许多 TXT 记录 Matt Simmons 2009-06-02T15:11:10+08:002009-06-02T15:11:10+08:00 应该注意的是 RFC 1178 专门讨论这个主题： http: //www.faqs.org/rfcs/rfc1178.html （即使我不同意其中的很多内容，并且其中很多内容已经过时）。 raspi 2009-06-02T14:08:52+08:002009-06-02T14:08:52+08:00 洛夫克拉夫特式的大旧神和外神。 KevinRae 2009-06-03T10:14:48+08:002009-06-03T10:14:48+08:00 基于位置和/或功能的命名服务器可能会导致安全问题。如果您在外部发布您的 DNS，那么您就是在向坏人提供一张所有好东西在哪里的地图。通过默默无闻的安全性不是可以依赖的，但我不会让脚本小子容易。 此外，您无需在主机名中描述设备的所有详细信息。而是使用主机名作为配置管理数据库的键。（您可以购买 CMDB、使用开源解决方案或参考 Excel 电子表格）。 我个人喜欢以下设备名称： 短的 容易拼写 有趣的 示例：我们曾经将其中一台备份服务器称为树懒。 不幸的是，这只适用于较小的网站。如果您管理较大的安装，您将需要尽可能清晰的命名约定，以便您的所有员工都可以快速轻松地识别所有这些主机的功能。在这种情况下，您可能希望实施拆分 DNS，这样您就不会在野外宣传所有这些主机名。 如果您的内部命名约定是私有的，那么您使用哪种轻率的命名方案实际上并不重要。但这里有一个想法。从您的支持人员那里获取技术线索，并询问他们是否有任何建议。这会让他们觉得自己很重要。 Alakdae 2009-06-02T14:06:43+08:002009-06-02T14:06:43+08:00 我的朋友使用凯尔特神的名字。我公司终端使用野生动物名称，服务器使用药品名称。我使用托尔金《精灵宝钻》中的名字。 anynomous 2010-12-22T22:35:43+08:002010-12-22T22:35:43+08:00 我使用演员。盒子越重要，演员就越酷……我试图按照他们在一起的电影对他们进行分组，但是当服务器移动并重新调整用途时，这很快就不再奏效了。我的 RHEL Satellite 服务器很宽敞，我的 syslog 服务器是 Brando 和 Dean。西贝尔在皮特和朱莉等人身上奔跑。 Lazlow 2009-06-03T12:13:25+08:002009-06-03T12:13:25+08:00 在我之前的工作中，我以星球大战的行星/卫星命名了新版本中的所有工作站/服务器 - Tatooine、Hoth、Endor、Dantooine 等。在我目前的工作中，本地服务器/工作站以星球大战角色命名，但正逐渐被更通用的名称逐步淘汰。在我们的生产环境中，服务器以希腊神话中的人物命名。 在家里，我所有的物理/虚拟服务器都以它们的用途命名——文件服务器、邮件服务器、ftpserver、webserver、mssqlserver 等。然而，现在证明这很困难，因为我正在构建额外的 web 服务器。出于怀旧的原因，我正在考虑改用我以前工作的命名约定。
很大程度上取决于你工作的环境。
首先也是最重要的 - 放弃对（流行）文化的任何引用，坚持使用有意义和描述性的名称。
您可能知道“zeus”是代理服务器，因为您安装了它。但是任何未来的同事都非常想通过它的作用来引用服务器，而不是他的名字。
如果您接受这一点，我建议您进行头脑风暴会议并写下您拥有哪些不同类型的网络实体（“主机”），如何将它们组合在一起以及哪些信息足够重要以编码在主机名中。您的命名约定应该能够明确地命名所有现有设备，并让用户大致了解主机的功能。一定要留出足够的增长空间来适应未来的发展，这样你就不需要在几个月内放弃你的命名约定。
记录您的命名约定（不仅是如何，还有为什么），确保需要定期使用它的每个人都了解它的布局，对评论/建议持开放态度，不要将其吹捧为圣杯，在需要时进行调整。
例子
作为思考的食物，这是我们在我的一位前雇主使用的架构：
Web 服务提供商，为 Web 项目做开发和运营。主要是 LAMP 的东西，尽管规模更大（项目规模，而不是数量）。
对于物理设备：
<站点>-<机架>-<设备>.in.<域>.<TLD>
对于逻辑实体：
逻辑实体可能是任何具有与给定物理设备/位置没有强耦合的 IP 地址的东西。这主要是客户操作系统的 IP 地址（在我们的例子中是 OpenVZ 或 ESX）。
<项目>-<环境>-<服务>.in.<域>.<TLD>
对于 IP 地址：
我们所有的服务都只能从专用网络访问，我们有 NAT 和/或带有“服务 IP 地址”的负载平衡器，面向互联网的主机使用它们来访问我们的服务。对于那些我们使用这样的东西：
<项目>-<环境>-vip-<标识符>.<域>.<TLD>
总结一下
命名约定对我们来说很好用，有些人（比如我们的开发人员；））可能会称它为夸大其词。请记住，如果您只维护一个站点并拥有分配给单个项目的服务器，那么这完全是夸大其词。但对我们来说，它完成了一些非常重要的事情。
在处理逻辑实体的主机名时，我们总是知道：
不同的项目对不同的负责开发团队具有不同的重要性。快速浏览一下主机名会告诉您如何确定任务的优先级以及您需要在管理/开发方面询问谁
开发环境中的问题会导致开发人员速度变慢。暂存环境中的问题会给测试人员带来痛苦，并可能危及产品展示。如果生产受到影响，公司就会赔钱。
邮件后台处理程序、批处理工作程序等并不那么重要，但如果 Web 或数据库服务器出现故障，事情就会很快变脏。
对于物理设备，确切的位置总是可以从主机名中推断出来的。
物理设备和逻辑服务器之间的弱耦合可能会让某些人感到厌烦（例如，当我拔掉交换机 x/server y 的插头时，我怎么知道哪些项目会受到影响），但这是必须的我们的环境，因为我们的项目具有很高的周转率，而且通常我们甚至不知道哪些项目将托管在我们刚刚配置的新硬件上。
对于服务器，我喜欢我办公室目前使用的标准 <3 个字母位置代码>-<2 位递增数字以避免重复名称>
一个例子是：PHOU-DMOSQL01
对于台式机/笔记本电脑，我通常使用类型指示符和用户名（假设机器分配给特定用户）（LT|DT）- 例如我的笔记本电脑是 LT-KCOLBY
真正的答案是没有答案。
我为服务器和计算机名称尝试了许多约定。我的结论是，名称本身是没有意义的，只要您有一个现成的、容易且不会因此而修改的描述字段。
因此，我对此的看法是——发疯。幻想英雄、StarWars 图标、神话 - 任何适合您的幻想，并且有足够的范围来包含您现有的所有主机和扩展。（并且不会剔除您的管理层经常缺乏幽默感，老板可能对名为“pointyhaireddimwit”的服务器很挑剔:)）。
我使用独特的名称来描述独特的机器。例如，在我当前的项目中，200 多台服务器，我使用了来自 Wikipedia 的星名列表。原因是实际名称比超级紧凑索引（例如 srv-05-92）具有更多冗余。这对一件事很重要：在嘈杂的服务器机房中转录、打字或通过电话交谈时，它的错误率很小。
描述性信息存储在 DNS 的 TXT 字段中，Mac 地址等也是如此。也可以根据mac地址请求名称：
您绝对要避免的一件事是根据机器的功能命名机器。这迟早会咬到你的屁股。只需为此目的使用别名（CNAME 或附加 A 记录）。
注意：这都是使用自定义 XML 文件中的 XSLT 生成的：
生成了几个别名：
...以及许多 TXT 记录
应该注意的是 RFC 1178 专门讨论这个主题： http:
//www.faqs.org/rfcs/rfc1178.html
（即使我不同意其中的很多内容，并且其中很多内容已经过时）。
洛夫克拉夫特式的大旧神和外神。
基于位置和/或功能的命名服务器可能会导致安全问题。如果您在外部发布您的 DNS，那么您就是在向坏人提供一张所有好东西在哪里的地图。通过默默无闻的安全性不是可以依赖的，但我不会让脚本小子容易。
此外，您无需在主机名中描述设备的所有详细信息。而是使用主机名作为配置管理数据库的键。（您可以购买 CMDB、使用开源解决方案或参考 Excel 电子表格）。
我个人喜欢以下设备名称：
示例：我们曾经将其中一台备份服务器称为树懒。
不幸的是，这只适用于较小的网站。如果您管理较大的安装，您将需要尽可能清晰的命名约定，以便您的所有员工都可以快速轻松地识别所有这些主机的功能。在这种情况下，您可能希望实施拆分 DNS，这样您就不会在野外宣传所有这些主机名。
如果您的内部命名约定是私有的，那么您使用哪种轻率的命名方案实际上并不重要。但这里有一个想法。从您的支持人员那里获取技术线索，并询问他们是否有任何建议。这会让他们觉得自己很重要。
我的朋友使用凯尔特神的名字。我公司终端使用野生动物名称，服务器使用药品名称。我使用托尔金《精灵宝钻》中的名字。
我使用演员。盒子越重要，演员就越酷……我试图按照他们在一起的电影对他们进行分组，但是当服务器移动并重新调整用途时，这很快就不再奏效了。我的 RHEL Satellite 服务器很宽敞，我的 syslog 服务器是 Brando 和 Dean。西贝尔在皮特和朱莉等人身上奔跑。
在我之前的工作中，我以星球大战的行星/卫星命名了新版本中的所有工作站/服务器 - Tatooine、Hoth、Endor、Dantooine 等。在我目前的工作中，本地服务器/工作站以星球大战角色命名，但正逐渐被更通用的名称逐步淘汰。在我们的生产环境中，服务器以希腊神话中的人物命名。
在家里，我所有的物理/虚拟服务器都以它们的用途命名——文件服务器、邮件服务器、ftpserver、webserver、mssqlserver 等。然而，现在证明这很困难，因为我正在构建额外的 web 服务器。出于怀旧的原因，我正在考虑改用我以前工作的命名约定。