在MNX上，我们一直致力于为我们的云托管服务建立一个全新的数据中心。起初我们是一家提供管理Linux服务的咨询公司，这也就意味着我们将置身于大量的不同用户环境，以及已有的与之同等数量的设备命名方案…这些并非都是好的。这个问题可以回溯到计算机出现的时候，每个人都有自己最佳的选择来命名主机。起初，绝大多数的方案都是好的，但是很快随着基础设备的扩展以及时间的推移就变得臃肿不便。
由于我们启用了全新的数据中心，于是想要提出自己的命名方案来解决在别处出现过的常见问题。我们从各个方面吸收想法，比如说大型企业公开的数据，有关该主题的各种各样RFC草案，数不胜数的博客/论坛帖子。将他们所有都考虑进去，我们制定了一套最佳方案，那就是应该为中小企业命名自己的硬件而服务。
XKCD似乎在每个主题都涉及到了
首先，我将先回顾一下现有的命名方案，包括他们的一些亮点和我们做出选择的理由。
A Records（一条记录）
在开始之前，为每个主机命名（通过适用于你操作系统的方法）并设置它的DNS A Records为从一个词，该词是从一个列表随机选择的：
crimson.example.com. A 192.0.2.11
虽然有许多词库可供选择，但是我们推荐的特定词列表来自于Oren Tirosh的记忆编码项目。该项目特定选择的1633个词都是比较短的（只有4-7个字母），而且相互之间读音上也不同，在电话中就能很容易理解，同时这也是国际上普遍认同的。这些助记词汇列表应该是不易出现拼写错误，当与更多结构化名称比较时可以转换字符。我们在这些词汇上花费了大量的时间和研究，他们的特点很符合我们的要求。
本来，主机名不应该暗含任何有关主机的用途和功能，但是与一个永久性的名称不同的是，作为标记一块特定硬件部分的唯一标识，将贯穿它整个生命周期（当硬件损坏后不再对其重命名）。该命名方式应该是物理上用来标记设备，且将极大方便运维工程师，远程管理，记录保存。这也是反向解析域名的PTR记录所应解决的。
CNAME Records（别名记录）
其次，指派一个或多个DNS别名来掩盖有关设备有用的功能细节，比如说地理位置，环境，工作部门，用途等等。这些所有的信息都将在你的CMDB（配置管理数据库）中记录下来并且能够方便地引用。
别名记录是开发者应该了解并用于组合服务。当你需要一个主机名时，保证这些命名结构的一致性将减少记住该主机名所需的脑力劳动。
Standardized CNAME Structure（标准化别名结构）
在你开始注册域名是，要将每一条附加信息分割成一个适当的子域名。DNS是按分层设计的，因此充分利用这个分层结构将会使我们受益。
<wip>.example.com. CNAME crimson.example.com.
Specify Geography（指定地理位置）
域名注册之后，添加一条有关主机地理位置的子域名。使用基于该主机数据中心位置的五个字符的UN/LOCODE（联合国贸易和交通位置编码值）。这比那些诸如IATI（国际航空运输协会）编码能覆盖更多特定的位置，而且它还是定义良好的标准。
在大多数的情形中，你可以去掉包含2个字符的国家代码那部分，仅仅使用余下3个字符的位置代码。也就是说，你可以只使用nyc.example.com 而不是nyc.us.example.com，除非你在多个国家都有数据中心，而且这些位置碰巧使用了有冲突的代码。
<wip>.nyc.example.com. CNAME crimson.example.com.
Specify Environment（指定所属环境）
接下来，指定主机所属环境的某一部分：
dev– Developmenttst– Testingstg– Stagingprd– Production
这些应该都要遵循任何你发布的管理过程模型…你或多或少有一些名称的，类似于像沙箱，实训环境等等…
<wip>.prd.nyc.example.com. CNAME crimson.example.com.
Specify Purpose and Serial Number（指定用途和编号）
然后，我们指定主机的功能所属的基本范畴，并且附加上一个编号
app– Application Server (non-web)sql– Database Serverftp– SFTP servermta– Mail Serverdns– Name Servercfg– Configuration Management (puppet/ansible/etc.)mon– Monitoring Server (nagios, sensu, etc.)prx– Proxy/Load Balancer (software)ssh– SSH Jump/Bastion Hoststo– Storage Servervcs– Version Control Software Server (Git/SVN/CVS/etc.)vmm– Virtual Machine Managerweb– Web Server
对于编号来说，基于你预期的长度使用补零。计划是有扩展的，但通常2个数字就已经绰绰有余了。
web01.prd.nyc.example.com. CNAME crimson.example.com.
编号按顺序增加并且在一个特定的数据中心基于服务类型对编号进行划分，而不是一个全局唯一的索引。那就意味着你可能在多个数据中心都有一个web01。
Convenience Names（易记的名字）
除了标准化的结构之外，你也许为了方便会增加额外的别名记录，比如webmail,cmdb,puppet等词。
webmail.example.com. CNAME crimson.example.com.
Special Cases（特别的情形）
Networking and Power Equipment（网络和能源设备）
对于网络和能源设备来说，硬件就决定了它们的用途，它也不可能不经过重新配置就移动。了解了这些，忽视掉随机词的命名约定，并使用功能性缩写来描述DNS A record：
- con – Console/Terminal Server
- fwl – Firewall
- lbl – Load Balancer (physical)
- rtr – L3 Router
- swt – L2 Switch
- vpn – VPN Gateway
- pdu – Power Distribution Unit
- ups – Uninterruptible Power Supply
…你也可能会想获得数据中心的地理位置信息。如果需要，你仍可以为像这些内核/硬盘，公有还是私有等特定信息添加别名记录。
rtr01.nyc.example.com. A 192.0.2.1
Secondary and Virtual IP Addresses（辅助的虚拟IP地址）
辅助的虚拟IP地址（用于高可靠性，Web服务，网络迁移，VLAN标签通信等等）的微妙之处在于它们可能是流动性，并不会绑定到硬件的某一部分。既然如此，直接向DNS分配一个功能性名称就变得很容易，而且遵循了常规的命名习惯。
Mail and Name Servers （邮件和名称服务器）
对于你的邮件和名称服务器来说，由于MX和NS记录不能指向别名，你需要利用DNS A records。也就是说，你可以拥有多个DNS A record，因此继续正则表达式，并且为了能利用公共的MX和NS记录添加另外的一些东西。
puma.example.com. A 192.0.2.20 mta01.example.com. A 192.0.2.20
DNS Configuration（DNS配置）
由于每个数据单元我们都使用合适的DNS子域名，因此我们可以在每台主机上配置搜索域，这样就可以只管理属于他们自己本地范畴的设备。
search prd.nyc.example.com example.com
当设备运作的时候就变得很方便了，因为你可以利用较短的主机名，比如，当与一个数据中心通信的时候，使用ping sql01 而不是它的全称ping sql01.prd.nyc.example.com。
一般来说，我们的命名方案也允许你为了防止只是随机短的主机名的公开而造成意外的信息泄漏，而在互联网上对功能性的名称进行单独的分解。这有点像隐藏式安全，但总归是考虑到这方面了。（注意，如果你也想隐藏“特例”的命名约定你需要对此进行微调）
Private Network and Out-of-Band Addressing（私有网络和界外寻址）
你也可以充分利用内置的DNS解析来显示私有的网络地址和界外/IPMI/iDRAC地址。该域名应该匹配另一部分记录，但再一次，利用一个恰当的子域名。注意，最佳的实践表明不要使用伪造的TLD（顶级域名），因为ICANN（互联网名称与数字地址分配机构）可以在任何时候登记它们，那么整合网络的时候将变得更棘手。
完整的命名方案样例
crimson.example.com. A 192.0.2.11 crimson.lan.example.com. A 10.0.2.11 crimson.oob.example.com. A 10.42.2.11 web01.prd.nyc.example.com. CNAME crimson.example.com.
melody.example.com. A 192.0.2.12 melody.lan.example.com. A 10.0.2.12 melody.oob.example.com. A 10.42.2.12 web02.prd.nyc.example.com. CNAME melody.example.com.
verona.example.com. A 192.0.2.13 verona.lan.example.com. A 10.0.2.13 verona.oob.example.com. A 10.42.2.13 cfg01.prd.nyc.example.com. CNAME verona.example.com. mon01.prd.nyc.example.com. CNAME verona.example.com. puppet.example.com. CNAME verona.example.com. nagios.example.com. CNAME verona.example.com.
banjo.example.com. A 192.0.2.104 banjo.lan.example.com. A 10.0.2.104 banjo.oob.example.com. A 10.42.2.104 web01.dev.pdx.example.com. CNAME banjo.example.com. martinlutherkingsr.melblanc.kugupu.stevejob.kenkesey.music.filmhistory.calligraphy.example.com CNAME banjo.example.com.
Capacity（功能）
该命名方案可以很方便地支持1500+个全局服务器。如果有更多的服务器，你可以为随机名称加入地理位置信息部分，然后再使用列表中的词汇。缺点在于crimson.nyc.example.com可能会与crimson.pdx.example.com具有完全不同的目的，因此还是有一点内在的障碍。或者，你可以扩展最初的词汇列表，试着添加一些类似于助记词编码的词汇。
如果你管理着10000+的服务器，主机极可能只有一个单独的模块用途，因此，忽视以上我们所讲的所有东西，只需要使用基于位置或者功能性命名方案就可以了。
Tip & Tricks（建议和技巧）
- 如果在你的环境中它是一个技术用语，你应该从助记编码词汇列表中去除易混淆的词汇，比如像’email’。
- 保证用途缩写词长度上的一致性，并经常进行编号填充匹配（也就是说，不要在某些地方使用
01而在其他地方使用1，一般在所有地方都要使用较长的01） - 你所使用的实际用途的缩写词并不重要，只要选定一个方案，确保它是在档的，并坚持使用它。
- 很容易保证用途缩写词稍微的广义性，因为更多的细节信息可以从你的CMDB（配置管理数据库）获取。
- 不论如何，所有的信息都应该保存在CMDB中而且易于访问。
- 当因为逻辑设置多个别名记录，记住你设置的记录越多，你需要维护的就多。
- 尽可能地自动化。
- 我们已经写了一个名为genhost的短脚本，它可以帮助你随机选择并记录你曾使用过的主机名词汇。
总结
我们的服务器命名方案降低了因为记录设备情况，连接服务器和直接维护合适的硬件记录所需的脑力劳动。设备的某些部分很可能随着时间的变化而改变，他们也只会包含在别名记录中。那就意味着如果一个服务器当掉了，你不需要去在其他的设备上更新对那台服务器的引用，因为你可以仅仅更新别名记录，让它指向一个新的主机就可以了。尽管我们的方案在开始时增加了一些复杂性，但他能够很好地平衡易用性，可维护性以及与支持长期增长之间的关系。