私は疑問を提起したい、それは私には、誰も以前に体系的に検討したことがないようです。 質問は次のとおりです。

ネットワーク内のノードとノードのインターフェースに名前を付ける方法は？

まず、問題の本質を概説します。サーバーが2-3-5-10の場合、名前、アドレスなどがあります。 あなたはすぐに覚えており、それらは多くの混乱を引き起こしません。 ただし、数千のサーバーがある場合（実際のサーバーに仮想サーバーを追加しましょう）、ルーターに数百の実インターフェイスまたは仮想インターフェイス（ビラナ）があり、それぞれに名前を付ける必要があります（少なくともDNSのPTR / Aレコードの場合）スイッチ、プリントサーバー、ネットワークプリンターを構成するためのインターフェイスがあります。これらの状況では、実際に座って何を呼び出すかを考える必要があります。 通話を始める前に座った後で考えるよりも、座った後に考える方が良いです。

簡単な方法

まず、最初に思い浮かぶシンプルなソリューションを検討してください。

適切な名前で呼びます

たとえば、周期表の要素（Yandexを追跡したのは誰ですか）。 小さな名前で百人で十分です。 それから、ヘリウムがカリウムからのメールを拒否することをログで読むことは興味深いでしょう。 さらに、短いエイリアスの既製の略語のセットがあり、それはユニークです。 同様に、たとえば国を選択できます。 または都市。 または、名前を持つ他のセット。



これの欠点は理解できます。サーバー名を見ると、それが何をしているかを理解することは不可能です。 プラス-名前は明確で、記憶に残り、区別できます。 カルシウムとカリウムを混同しないことは明らかです。 決して。

番号で呼びます

たとえば、fsbk3333、fsbk32232 ...かなりの名前です。 サーバーが同種の場合。 そうでない場合は？ 「333」がメールサーバーであり、5622がバックアップVPNゲートウェイの帯域外インターフェースであることを思い出してください。

役割別に名前を付ける

mail.domain、gateway.domain、vpn.domain、radius.domain、databases.domain、printer.domainなど プラスは、各サーバーの機能を正確に理解することです。 欠点は、混合機能との混乱です（ルーターがmail.domainサーバーの半径に接続するのはなぜですか？ああ、そこにradiusサーバーがありますか？そしてなぜ "mail"という名前なのですか？）



次に、webserver23は毎回入力するのにうんざりするため、番号を付ける必要があり、名前を短くしたいという明確な要望があります。



さらに大きな問題は、部門、フロア、建物、都市、企業などへの分割です。 webserver12はPermの管理棟にあるワークステーション用のプリセットを備えたサーバーであり、webserver22は本社に企業CMSを備えたイントラWebサーバーであることがわかります。 そして、そのような名前を印刷することも難しいです。

LDAPが支配します！

OU = MSK、OU = "Main Branch"、OU = labs、CN = "intranet web server"ほど明確で明確なものはありません...特に毎回手動で印刷する場合。 さらに、DNSとはあまり互換性がありません。 毎回「intranet-web-server.labs.mainbranch.msk.our_domain」を印刷しない限り。

問題の一般的な構成

ここで、一般的な方法で問題の検討に移ります。



一般的な要件：

• 適切な名前サイズを維持する
• 名前の記憶
• ドメインコンポーネントを考慮しないホスト名でのデータストレージ。 これは、DNSサフィックスを見ずにホストのコンソールの背後にあるホスト名全体を表示できるようにするために必要です。

特定の要件：

• 地理的な場所
• 管理提出
• 機能的役割
• タイプ（ホストはコンピューターでも、特殊なハードウェアでもかまいません）
• 番号、同一ホストのグループの場合
• 仮想化またはその他の特別なマークの表示（たとえば、ラックマウント鉄製かどうか）

特定の要件をそもそも拡張できることは明らかです（たとえば、ネットワークの複雑な管理組織の場合、管理従属のコーディング自体は、たとえば、それぞれにユニットを持つ「企業グループ」になると、非常に困難になる可能性があります相対的自律;同様に、地理的、機能的...他の分野について話すことができます



また、組織の種類によっては、一部のフィールドが需要がない場合があることも明らかです。 たとえば、地理的または管理上の部分。



ただし、一般的なケースでは、上記のリストを使用できます。



次に、次の2つの質問があります。各パーツのサイズ。 これらの部品をどのように分離する必要がありますか？ 3番目の質問：名前の各部分の長さを変えることはできますか、それとも厳密に修正する必要がありますか？



長さから始めましょう：データベースは完全に「db」に収まり、ターミナルサーバーは「ts」に収まります。次に、2文字でエンコードします。たとえば、「backup」はもう少し複雑です。他の略語と重複する可能性がある任意の一般的ではない略語を取得します。 同じことが地理的な名前にも当てはまります。 ヴァシリエフスキー島の各線に枝があると仮定します。 それらを2文字でエンコードするとします。 l4は4行目、l8は8行目です...そして17行目はどうですか？ そして明日、モスクワのゲート、モスコフスカヤの地下鉄駅、モスコフスキーの別の支店、モスクワの別の支店に支店があります。 名前の堅固な長さのプロクラス階のベッド、IMHOに自分自身を追い込むことは合理的ではありません。



次に、名前はどうあるべきですか？ 明らかに：可能な限り最小ですが、「自然な」削減です。 「m」に他のブランチがない場合でも、モスクワを（mskの代わりに）「m」に減らすことは、名前のニーモニックと読みやすさを減らすことです。

地理的部分

地理的な名前の略語の技術は長い間マスターされており、公に知られているため、原理的には非常に簡単です。 米国の2文字の州コード、ロシアの3文字の都市名（地理的ドメインから）、2文字の国コード（ISOから）...通りの名前も省略できますが、ここではいくつかの工夫を示す必要があります（上記のVasilyevsky島の例を参照）。

管理提出

管理上の従属の問題はもう少し複雑です。 部門/支部のフルネームは判読できないか、なじみのないものです。 誰もこの問題について考えていなかった可能性があります。 銀行には支店があり、支店には番号があります。 しかし、「銀行支店」ではない中間サーバールームのサーバーとはどういうものですか？



おそらく最も痛い質問は、音訳または翻訳を使用すべきかということです。 誰もが自分で決定できるようにします（翻訳は嫌いですが）。



もう1つの重要な「しかし」ことは、サーバーの管理所有権を権限のない人に明らかにすることは、コンピューター名を権限のない人に言うすべての中で最も痛みを伴う可能性があることです。 msk-yukos-acc-12は明らかに他の人に見せたい名前ではありません。



「誰もそれを外から見ることはないだろう」ということは決してしないでください。 手紙の断片（転送に関するヘッダー付き）、SQLと通信できないことを示すサーバーからのメッセージ、またはそのような詳細な情報がないと役に立たないその他の愚かな情報をどこで誰が見るかわからないサーバー名...

機能部

さらに、機能的な役割について。 メインサービスのプロトコルの名前を書くのは間違っているように思えますが、そのような誘惑はまだ生じます。 役割について正確に話す方が正しいでしょう（同時に、現時点では、1つのサーバーに関連付けられている会社に多すぎるかどうかを考えるかもしれません）。



例：wwwサーバーの代わりに、 'pa'（パブリックアクセス）または 'ea'（外部アクセス）サーバー（FTPサーバーも見栄えが良い）を作成できます。 プロキシの代わりに、ag（アプリケーションゲートウェイ）と呼ぶことができます。これは、偶然にも、中間メールリレーにとって非常に論理的です。 同時に、他の役割を割り当ててはならないサーバーの場合は、ドメインコントローラーのDC、交換のEX、専用のsyslogサーバーのSLなど、主な唯一の機能にちなんで名前を付けることができます。



ルーターについては別に。 ルーターの主な役割は何ですか？ ルート、ルート、ルート！ 実際、よく見ると、ルーターの役割は通常、サーバーの役割よりもさらに凸です。 たとえば、ほとんどすべてのネットワークにはゲートウェイ（gw）があり、通常は大規模ネットワークdl（配布レベル）およびal（アクセスレベル）にコアレベル（clまたはcr-コアルーター）があります。 最も可能性が高いのは（ブランチの条件において）vpnルーター（ネットワーク間）です-名前にvpnが要求されます。 ただし、ポイントツーネットワーク接続を終了する場合は、「vpn」ではなく（実際には完全なネットワークが存在しないため）、たとえばra（リモートアクセス）という名前を付けることをお勧めします。 さらに、-GWサフィックスはRFC 952の使用を示唆しています。



私からは、名前はスマートな鉄片だけでなく、愚かなもの（ネットワークに存在する場合）にも付けられるべきであることに注意してください。 msk-al-12タグが存在すると、リクエストの精度が大幅に向上します。

マルチヘッド

ルーターに30の異なるネットワーク、30の異なるIPアドレスがある場合、それぞれに独自のリバース名が必要です。 ここには別の選択肢があります。この番号に意味を入れるか、連続して番号を付けます。 これとは別に、長いリンク（ネイティブオプティクス、VPNの仮想インターフェイス、建物間のリンク）の場合、外部インターフェイス（境界ルーター上）、内部インターフェイスとブリッジインターフェイス（br）を強調する価値があります。

ワークステーションと周辺のゴミ

ワークステーションの命名の重要性を過小評価しないでください。 これらの名前は、SMTPヘッダーに表示されます（ワークステーション自体がkomputerと呼ばれるものと見なしたワークステーションの名前（PTRによる）tupayasuka.domain.ruの履歴書への返信で手紙を受け取ったとき、どういうわけか大笑いしました）。 ワークステーションに代わって何が必要ですか？ サーバーとは異なり、汎用性と機能的な役割を必要としないため、この数で十分です。 さまざまなタイプのステーション（シンクライアント、Windows、Linux）がある場合は、おそらくこれについて言及します。 もちろん、地理的な場所です。



それとは別に、「自分の管理者」である従業員のラップトップの存在を考慮する必要があります。名前の多様性はまれです...

名前の分離

セパレータには名前が必要ですか？ 比較してみましょう：

• mskmainac012
• spbnpcl-02
• msk-main-ac-012
• spb-np-cl-02

答えは明らかだと思います。 シンボルについて。 多くのオプションはありません。

• ドット-DNS用に予約済み
• アンダースコア-DNSと完全には互換性がありません。印刷時に押すとシフトします
• コロン-珍しい、DNSと互換性がない

印刷が簡単で、目に馴染みやすいDNSと互換性のある文字が1つ残っています。これはハイフンです。 おそらくその欠点は、スマートフォン画面のサブキーボードで入力する不便さと、トークンのメインスペースにマイナス記号があるプログラミング言語との非互換性です（これは重大な問題になるとは思いませんが、通常のシェルではハイフンはハイフンです、マイナスではありません）。



では、セパレーターの数について教えてください。 非常に大規模な会社があり、ITの鉄がたくさんあるとしましょう。



名前のおおよその構成：

nsk（ノボシビルスク）、hd（ヘッドから）、mf（製造、生産施設から）、st（ストレージ、ストレージ）、11（同じタイプの11番目のサーバー）、2番目のインターフェース（3つのうち、2つは冗長性のためにスイッチに行き、1つはクラスター内のヘッドビート）。



オプション：

1. nsk-hd-mf-st-11-2
2. nskhd-mfst-11-2
3. nsk-hdmfst-11-2
4. nskhd-mfst11-2
5. nskhdmfst11-2

個人的には、私は最後から2番目のものが好きです。 それにもかかわらず、各部分のサイズでカバーされ、さらに、別個の地理（nsk + hd-地理的な意味での場所、mf + st-正確な場所（オフィス内）およびおおよその役割）があります。

バーチャル

考慮すべき点：地理的移動の可能性（サーバーmskを呼び出すのは愚かです-アムステルダムとヘルシンキの間をさまよう場合は）; インフラストラクチャ（たとえば、L2アプリケーション（vlan'y、pppoe、arpプロキシ）がある場合のチャネルセグメント）へのバインディングの存在。



原則として、私は（自分自身のために）ホストに文字 'h'（ホストシステム）を使用し、クエスト（仮想マシン）に 'v'を使用することに決めました。 たとえば、nskhd-hx1とnskhd-hx15の間で移行するv-mf11（動作するものを自分で推測します）。

ローカルエイリアス

作業のもう1つの興味深い点は、ローカルエイリアスです。 一部のサーバー（機器）が閉じられている場合（たとえば、ローカルの問題を解決するサーバーのグループ）、それらに短い名前を付けることは理にかなっています。 DNSに煩わされないようにするために（これは完全に管理とは無関係です）、hostsファイルは非常に場違いである可能性があります（はい、このファイルはvkontakte / odnoclassnikiだけでなく作成されました）。 たとえば、ストレージサーバー、コントローラーのペア、およびレポートサーバーが存在する場合、なぜそれらをstor、ctl1、ctl2、repと呼ばないのですか？ もちろん、これらの名前は「内部」で使用するためのものであり、外部で発表したり、使用するサーバーを変更できる構成に使用したりしないでください。

名前を計画する方法は？

要約すると：

1. 番号付けサイズを決定します。 おそらく、サーバーと2〜3台のデバイスr1〜r2については、すべてがs1〜s5かかります
2. 既存のすべての名前と略語を書き留め、少なくとも半年先まで考えてみて、同じ建物が別の建物にあることを想像してみてください。
3. デバイスの名前を変更できるかどうかを決定しますか？ ルーターの名前を変更できます。メールサーバーの名前の変更はすでに困難です。ドメインコントローラーの名前の変更は問題になる可能性があります。特定のファイルへのすべてのリンクが災害であるファイルサーバーの名前の変更[ヒント：WindowsにはDFS、LinuxにはDNSのCNAME]
4. 数十のタイトルを作成し、読みやすいかどうかを確認します（つまり、「それが何であるか」が明確である）、印刷してみます。
5. 機密情報があるかどうかを確認します（会社名、市、住所、支店番号-「機密」があることを当局に確認することをお勧めします）