功能服务器命名约定

Question

我看到了“The Coolest Server Names”，还看到了另一个与我相关的smaller-ish question，不幸的是，它已关闭。

这是一个严肃的问题，因为我在一个内部应用程序开发团队中，负责管理几十台服务器上的应用程序。网络人员通常不在乎我们如何称呼服务器，只要他们知道它们，因此我们可以提出任何约定。

服务器处理的应用程序可以是自行开发的自定义应用程序，也可以是 SharePoint 等大型供应商的应用程序。它们可以是：

• 在无法相互通信的多个网络环境中（想想防火墙关闭的外部服务器与 Intranet 式服务器）
• 在不同的物理位置（加利福尼亚办公室与纽约等）
• 在多个部署层（生产、暂存、测试、开发）中
• 具有一种或多种功能（Web 服务器、DB 服务器、邮件服务器、应用服务器）
• 负载均衡与否
• 备用（用于灾难恢复）或主要

哇！认为甚至有可能提出一个可以解决所有这些方面或重要方面的约定？很高兴听到服务器名称（或它的 DNS 条目）并能够立即知道它的作用，并且它也有助于让新人加快速度。 “sharepoint-IPC-1 已关闭”可以解析为“位于加利福尼亚数据中心的内部生产 SharePoint Web 服务器，它是负载平衡中的第一个节点已关闭！”...但乍一看似乎过于复杂。

在我脑海中的另一件事是旧的邮件中继服务器正在退役，这意味着我们必须搜索许多旧应用程序来重新指向硬编码的服务器值（我知道...... :)。

Answer 1

根据我过去犯过的错误，以下是我尝试遵守的一些一般准则。

永远不要将您的机器名称基于...

• 硬件 机器总是被换掉，如果您从 IBM 服务器更改为 Sun 服务器，再更改为戴尔服务器。

• 位置可以根据业务需求或技术问题移动设备甚至整个服务器机房。

• 预期用途随着产品的发展，每台服务器的预期用途也会随之变化。拥有一台名为“dbsrv”但最终也充当文件服务器的机器是令人困惑的。

• 所有者“拥有”设备的人（员工）可能会因公司内的解雇、裁员和调动而发生变化。

• 子网 正如我之前所说，实验室可以移动，子网也可以。 DNS 的主要目标之一是让您摆脱与特定 IP 地址的束缚，那么为什么要不必要地束缚自己呢？

现在，针对您所描述的情况提出一些建议……

• 机器分布在一个区域 这就是 DNS 中子域的用途。你可以有“west.company.com”和“east.company.com”。

• 有一个或多个功能不要根据预期用途来命名它们。如果你根据一些大的名字集合来命名它们——例如希腊诸神——你最终会直观地知道 zeus.east 意味着你的主数据库服务器，而 apollo.west 是你的备份数据库服务器。最坏的情况，在电子表格中查找。

• 负载平衡与否 您可以采用两种方法。您可以在负载均衡器后面为每个节点设置一个唯一的名称，或者您可以执行诸如 athena-1.east、athena-2.east 之类的操作。无论哪种方式，负载均衡器都会（希望）让您不必担心太多每个节点的名称。

• 待机与否这听起来不像是应该影响机器名称的标准。

我的意思是：

1. 将您的设备分成不同的区域子域
2. 选择具有大量名称的命名方案（本例中为希腊诸神）
3. 不要将名称基于我上面提到的任何标准（预期用途、位置等）

尝试做任何事情更多比这更麻烦。

Answer 2

我知道为描述其功能和其他类似属性的服务器分配名称是很诱人的，并且在一个可以工作的完美世界中，但实际上我发现一段时间后这些事情会因为函数和其他参数而变得混乱服务器发生变化（随着业务需求的变化），因此名称不再反映现实。

我认为您应该为服务器分配唯一的名称，这些名称不会告诉任何有关功能或其他参数的信息，并有某种（最新的）列表详细说明这些内容，以便您的人员可以查找它。这就是我们在这里所做的。

另一个极端是仅使用 IP 地址或使用基于 IP 地址的名称，如果您不得不更改 IP 地址，这也会导致灾难。