功能服务器命名约定

发布于 2024-07-16 07:22:52 字数 894 浏览 4 评论 0原文

我见过“最酷的服务器名称”,并且我还见过另一个<一个与我相关的 href="https://stackoverflow.com/questions/631220/good-server-naming-convention">较小的问题,不幸的是已关闭。

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

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

  • 在无法相互通信的多个网络环境中(考虑防火墙关闭的外部服务器与内部网式服务器)
  • 在不同的物理位置(加利福尼亚办公室与纽约等)
  • 在多个部署层(生产、登台、测试、开发)
  • 具有一项或多项功能(Web 服务器、数据库服务器、邮件服务器、应用程序服务器)
  • 是否负载平衡
  • 备用(用于灾难恢复目的)或主

唷! 您认为甚至有可能提出一个可以解决所有这些方面或重要方面的公约吗? 如果能够听到服务器名称(或它的 DNS 条目)并能够立即知道它的用途,那就太好了,而且它也有助于让新手快速上手。 “sharepoint-IPC-1 已关闭”可以解析为“作为负载平衡中第一个节点的加利福尼亚数据中心的内部生产 SharePoint Web 服务器已关闭!”...但乍一看似乎过于复杂。

我脑海中的另一件事是旧的邮件中继服务器即将退役,这意味着我们必须搜索大量旧应用程序以重新指向硬编码的服务器值(我知道......:)。

I've seen "The Coolest Server Names," and I've seen another smaller-ish question related to mine, which was unfortunately closed.

It's a serious question though, as I'm on an internal applications dev team that manages the apps on a couple dozen servers. The networking folks typically don't care what we call the servers as long as they know about 'em, so we can come up with whatever conventions.

The apps the servers deal with can be home-grown custom apps, or they can be larger vendor ones like SharePoint. They can be:

  • In multiple networking environments that can't speak to each other (think firewalled-off external servers versus intranet-esque servers)
  • In different physical locations (California office versus New York, etc.)
  • In multiple deployment tiers (production, staging, testing, dev)
  • Have one or many functions (web server, DB server, mail server, app server)
  • Load-balanced or not
  • Standby (for disaster recovery purposes) or primary

Whew! Think it's even possible to come up with a convention that can address all of these aspects, or significant ones? It'd be nice to hear a server name (or DNS entry for it) and be able to immediately know what it does, and it works for getting new guys up to speed as well. "sharepoint-IPC-1 is down" could be parsed into "the internal production SharePoint web server in the California datacenter that's the first node in the load balancing is down!"...but that seems overly complicated at first glance.

Another thing in the back of my mind is that an old mail relay server is getting decommissioned, which means we have to scour through a lot of old apps to repoint hardcoded server values (I know... :).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

离笑几人歌 2024-07-23 07:22:52

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

切勿将计算机名称基于...

  • 硬件 计算机总是会被更换,如果您从 IBM 服务器更改为Sun 服务器到 Dell 服务器。

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

  • 预期用途 随着您的产品不断发展,每台服务器的预期用途也会随之发展。 拥有一台名为“dbsrv”的计算机,但最终也充当文件服务器,这会令人困惑。

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

  • 子网 正如我之前所说,实验室可以移动,子网也可以。 DNS 的主要目标之一是将您从特定 IP 地址的束缚中解放出来,那么为什么要不必要地束缚自己呢?

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

  • 计算机分布在一个区域 这就是 DNS 中的子域。 您可以拥有“west.company.com”和“east.company.com”。

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

  • 负载平衡与否您可以采取两种方法。 您可以在负载均衡器后面为每个节点指定一个唯一的名称,或者您可以执行类似 athena-1.east、athena-2.east 等操作。无论哪种方式,负载均衡器(希望)都会让您免于过多担心每个节点的名称是什么。

  • 是否待机这听起来不像是一个应该对机器名称产生影响的标准。

我本质上想说的是:

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

尝试做任何事情更多都会比它的价值更麻烦。

Here are some general guidelines I try to abide by, based on mistakes I've made in the past.

Never base your machine names on...

  • Hardware Machines get swapped out all the time, and you don't want to have to do too much work if you change from an IBM server, to a Sun server, to a Dell server.

  • Location Equipment and even entire server rooms can be moved based on business requirements or technical issues.

  • Intended Use As your product evolves, so too may the intended use of each server. Having a machine named "dbsrv" but eventually acts as a file server too, is confusing.

  • Owner The person who "owns" the equipment (an employee) can change, due to firings, layoffs, and moves within the company.

  • Subnet As I said before, labs can move, and so can subnets. One of the main goals of DNS is to free you from being tied to a specific IP address, so why tie yourself down needlessly?

Now, some suggestions for the situation you described...

  • Machines spread across a region This is what subdomains are for in DNS. You could have "west.company.com" and "east.company.com".

  • Have one or many functions Don't name them based on intended use. If you name them based on some large collection of names--Greek gods, for example--you will eventually intuitively know that zeus.east means your master database server and apollo.west is your backup database server. Worst case, look it up in a spreadsheet.

  • Load-balanced or not You can take two approaches. You could have a unique name per node behind the load balancer, or you could do something like athena-1.east, athena-2.east, etc. Either way, a load balancer will (hopefully) free you from worrying too much about what each node is named.

  • Standby or not This doesn't sound like a criterion that should have an impact on the machine name.

What I'm essentially saying is:

  1. Separate your equipment into different regional subdomains
  2. Choose a naming scheme with plenty of names (Greek gods in this example)
  3. Don't base the names on any of the criteria I mentioned above (intended use, location, etc.)

Trying to do anything more than that will be more trouble than it's worth.

可可 2024-07-23 07:22:52

我知道为描述其功能和其他类似属性的服务器分配名称是很诱人的,并且在一个完美的世界中这是可行的,但在实践中我发现,随着服务器的功能和其他参数发生变化,一段时间后这些事情就会变得混乱(随着业务需求的变化)所以名称不再反映现实。

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

另一个极端是仅使用 IP 地址或基于 IP 地址命名,如果您必须更改 IP 地址,这也可能导致灾难。

I know that it's tempting to assign names to servers that describe their functions and other similar attributes and in a perfect world that will work but in practice I have found that after a while these things get messed up as functions and other parameters of the servers change (as the requirements of the business change) so the names no longer reflect the reality.

I think you should assign unique names to the servers that do not tell anything about the function or other parameters and have some sort of (up to date) list detailing those things so that your people can look it up. That's what we do here.

The other extreme is using IP addresses only or having names based on IP addresses which can lead to a disaster too if you ever have to change your IP addresses.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文