まず、命名スキームを選ぶ人は誰でもRFC 1178- "Choosing a Name for Your Computer" を読む必要があります。コンピュータに名前が付けられている限り、この問題について人々が話しているので、ホイールを再発明する前に、他の人が言ったことを読んでください。
私自身の考え-ネーミングポリシーを テーマ そして スキーム。
テーマを使用する （例：ギリシャの神々、ドクター・フーのキャラクター、ウォッカのブランド）は、 小さい 通信網。ホスト数が20未満の場合は、複数のハードウェア構成がある可能性があります-おそらくすべてのホストに固有の構成があります。そのような場合、各マシンに固有の個性があると考えることができるのは良いことです。
スキームを使用する （たとえば、地理的な場所、ラックの位置、ハードウェアIDなどの要素から構成される名前）は、同一のハードウェアまたはソフトウェア、あるいはその両方の構成を持つマシンが多数ある場合に適切に機能します。また、日常的にマシンを扱っていない人とマシンについて通信する必要がある場合にも、うまく機能します。たとえば、NOCスタッフにマシンをリセットするように指示する必要がある場合は、特定のラベルが付いたマシンをラック内で検索するよりも、ラック内でマシンを見つけるのに役立つ名前の方が適しています。
関数名を使用する （メール、ウェブ、ファイルサーバーなど）は仮想マシンには良いアイデアですが、私の経験では物理ホストには悪いアイデアです。物理ホストは、多くの場合（理想的ではない場合でも）複数の機能を実行することになり、個々の機能は他のホストに移行されるように、時間の経過とともにリソースの使用状況と要件が変化します。
テーマの問題 含める：
- それらは通常、名前の小さなプールを提供します。ローマの神を使い果たしたら、ギリシャ語に切り替えますか？名前のテーマに合った廃止されたホストの名前を再利用しますか、または名前の再利用から生じる可能性のある問題と混乱を避けるために、新しいテーマから新しい名前を選びますか？
- 彼らはあなたの機械を擬人化させます。それは悪いです-コンピュータはそれを好きではありません。マシンに個別の性格があるかのように扱う場合、そのマシンの「動作」に関する想定に反する証拠を無視するリスクがあり、「特定のマシンに障害があるため、常に不正行為」。
スキームの問題 含める：
- その結果、覚えにくいホスト名が作成されます。これは、適切なシステム管理を実施している場合はそれほど問題ではありませんが、特定のマシンで特定の問題が複数回発生したこと、または特定のマシンが原因であることを即座に思い出せると便利な場合があります。特定の機能を実行します。
- スキームが変更された場合、すべてのホストの名前を変更する必要がある場合があります。これにより、DNSの変更、構成の変更、アクセスリスト、アクセス許可の変更などが多数発生する可能性があります。
現実世界では 両方のシステムが使用されていることを確認します。たとえば、私の経験では、高性能コンピューティングクラスタには常に名前があります。多くの場合、名前は（インタラクティブに使用される）ヘッドノードに割り当てられますが、さまざまなクラスターノードには、compute-01、highmem-01、storage-01などの名前が付けられます。
また、前述のように、仮想マシンと物理ホストで異なる命名方式を使用することは一般的（かつ便利）です。
興味深いカテゴリの下に、 Stack Overflow回答 からの1つがあります。
周期表の要素。また、IPアドレスには要素番号を使用しているため、
水素= 192.168.0.1
ヘリウム= 192.168.0.2
等.
私は物理サーバーに場所（つまり、国コード/都市コード/データセンターコード/フロア/ラック/ラック-U-高さ）とソフトウェア/ VMサーバーをその機能のみで命名することに非常に強い信念を持っています（プラットフォーム/関数/クラスター/反復）。これは、7人のドワーフなどにちなんで名前を付けるよりも長くなる可能性があることを知っていますが、これは、より「将来性」があり、構造化された方法で仮想化に対処するための優れた方法です。
例として、NESQLC11S08などのゲストサーバーVMを備えた044LONTH72G216（これはサーバーを世界中で正確に検索します）と呼ばれるVMWareサーバーがあります。社内のITチームがそれぞれ長くて整理された名前を参照するために、いつでもそれらの短い名前を作成できます。
お役に立てれば。
私たちは特定のテーマ（聖書の本）でサーバーに名前を付けることから始めましたが、ITチーム（およびサーバーの数）が成長してより専門的になるにつれて、そしてスタッフの入れ替わりが増えるにつれて、どのようなネーミングシステムでもどういうわけかサーバーの機能（または場所）に関連していませんでしたが混乱しました。
人々は自分が定期的に取り組んでいるサーバーを知っていましたが、新しいプロジェクトに取り組んだり、クロストレーニングをしたり、別の管理者を支援したりすると、「誰もpsalmsがメールだとは知らなかったため、見落とされていました。サーバー」など。
これで、よりわかりやすい命名体系に戻りました。
すべてのサーバーに、その役割に応じて名前を付けます。
したがって、サーバーには次のような名前があります。
- PDC
- SQL
- EXCHANGE
- RDP
- FILE etc..
私の経験では、人間が読めない名前のサーバー（つまり、スキームメソッド）はnotで管理できます。入力ミスした文字が原因で、xyzの操作が誤ったサーバーに適用されることがありました。
関連するメタデータが説明フィールドなどに格納された人間が読める名前は、PEBKACの問題が発生しにくいようです。
2つのmicroVAX 3400のクラスターが会社にとって大きな問題であった時代に、BertとErnieから始めました。私たちはしばらくの間セサミストリートに固執しました-Bigbird、Elmo、Grover、thecount（金融システム）、しかし結局は計画に行かなければなりませんでした。スキームに含まれる要素は、会社の規模によって異なります。以下を含める必要があります。
場所（市の2文字の省略形）部門（会社は4 co.sをマージして形成されたため、3文字の省略形がありました）機能（PDC、メール、印刷物、wwwなど）シリアル番号（I年と月をシリアル番号の一部として持つことが常に好きでした）
まあ、いくつかの永続的なお気に入りは次のとおりです。
- ギリシャの神々
- ローマの神々 （「惑星」と区別できないことがある）
- Norse gods （ほとんどの不正なサーバーはLokiになる可能性があります）
- 琥珀のプリンセス
- 哲学者
シンプソンズのキャラクター:)
かつてプレイボーイのバニーにちなんでサーバーを指名したクライアントがいた。しかし、それはIT以外では広く公表されていませんでした。 ;-)
私は大きな猫にちなんでそれらに名前を付けるのが好きでしたが、その後OS Xが登場して私のためにそれを台無しにしました。
別のお気に入りは、アルコールの種類です。 JimBeam、Beefeater、Stoliなど。異なるクラスのアルコールは異なるクラスのサーバーでした。メールサーバーの場合はジン、データベースの場合はウィスキー、PDCは常にMoonshineでした。
今年の新しいシステムからは、退屈なわかりやすい名前（メール、印刷など）を使い始めますが、これまでは、鳥、魚、ジャングルの動物など、さまざまな種類の動物の動物を使用していました。
トップ40のミュージシャン。
新しいものを提供し続けるのに十分な頻度で変化しますが、さらに重要なのは、12歳以上の誰にとっても十分に謎めいていることです。
私たちのサーバーはすべてペットにちなんで名付けられています。タイプごとに若干の内訳があります。すべてのドメインコントローラは鳥にちなんで名付けられています。ファイルと印刷用の犬。アプリケーションサーバーの猫。
会社のイニシャル、タスク、番号の順になる傾向があります。
GSK-WEB-12
ST-DB-3
私たちはこれを使用していますが、これはかなりうまくいきます。
- サイト（2文字）
- dev/test/live（3/4文字）
- 関数（3文字以上）
- カウント（2文字）
- vmかどうか（2文字）
これまでの仕事では、クラシックなserver01、server02など以外に次のような傾向が見られます。
- 貴重な石
- 魚
- フラワーズ
- スターウォーズのキャラクター
- 動物
私が勉強している大学では、彼らはアステリックスとオベリックスの物語の異なるキャラクターの名前を使用しています。 miraculix、astmatixなど。