現在、 MNX ではクラウドホスティングサービスの新しいデータセンタを立ち上げているところで、とてもバタバタしています。クラウドホスティングサービスは、今の私たちの主な業務ですが、この会社が始まった当初は、Linux管理のコンサルティングサービスを中心としていました。そのサービスを通じて、たくさんの顧客環境を目の当たりにしましたし、それと同じ数だけの、顧客ごとに異なるデバイス名の指定方法も見てきました。そしてもちろん、その全ての指定方法をいいなと思ったわけではありません。名前の付け方は、コンピュータ草創期からの問題ですよね。おのおのがホスト名の指定方法について一家言持っていました。でも、それらの方法は最初のうちはうまくいっても、時を経てシステムインフラが拡大し、状況に応じて変更を余儀なくされるようになると、すぐに扱いにくくなってしまうものがほとんどでした。

そこで今回は、先述した私たちのデータセンタが白紙状態からの立ち上げということもあり、これまでに見てきた一般的な問題を踏まえる形で、独自の命名規則を考えてみることにしました。まずやるべきことは、参考となるアイデアの収集です。大企業が公開しているデータや、名前の付け方に関するRFC、それにブログやフォーラムなど、様々なソースを見て回りました。そして、それらのソースを精査した上で、これは優れていると自信を持って言える命名規則を編み出しました。この規則は、中小規模のほとんどの企業にうってつけだと思います。

まずは、私たちの規則の概要を見ていき、その後で、その優れた点や妥当性をご紹介します。

Aレコード

手始めに、（お使いのOSの設定方法に従って）それぞれのホストに名前を付けて、リストからランダムに選択した単語でDNSのAレコードを設定しましょう。

crimson.example.com.   A   192.0.2.11

単語が集積された リストは数多くありますが、特にお勧めしたいのはOren Tirosh氏の Mnemonic encoding プロジェクトです。ここに紹介されている1633の単語は、音声的に互いに異なる短い（4-7文字）単語で、電話越しでも理解しやすく、国際的にも認識が容易なものです。またMnemonicのリストにある単語を使うと、複雑な構造を持つ単語に比べて、文字を前後逆にしたりスペルを間違ったりする可能性を大きく減らすことができます。この単語リストは多くの時間と研究の上に出来上がっており、その成果は、私たちの目的に理想的と言えるでしょう。
基本的に、ホストの目的や機能を示唆するような名前をホスト名にするのはお勧めできません。それよりも、ハードウェアのライフサイクルを通じてその対象を指し示すような、恒久的で独自の識別子を持った名前の方がいいと思います（ハードウェア交換の際、名前の使い回しはできるだけ避けたいところです）。つまり、その名前を対象ハードウェアの物理的なラベルとして機能させ、ほとんどの場合、例えばエンジニアの運用時であれリモート作業時であれ、またはレコードの記録時であっても、使い勝手が変わらないようにした方がいいということです。また、DNSの逆引き（PTR）レコードにとっても有益です。

CNAMEレコード

次に、マシンの機能的な詳細を明示するために、例えば地域や環境、作業部門、用途など、1つ以上のDNS CNAMEレコードを割り当てましょう。割り当てた全ての情報は CMDB にミラーリングされるため、容易に参照ができます。
CNAMEレコードは、ディベロッパが知っておくべき情報で、サービスを相互接続する際に使われるものです。これらの名前に一貫性を持たせておくと、ホスト名を覚えなければならない時の精神的な労力を軽減することができますよ。

標準化されたCNAME構造

まず登録したドメインへ順番に適切なサブドメインを追加情報として割り当てていきます。DNSは階層構造になっていて、その構造を利用することで、後々、利便性が出てきます。

<wip>.example.com.   CNAME   crimson.example.com.

地域を指定する

ドメイン名の後には、ホストの地域を示したサブドメインを加えます。ホストのデータセンタの場所に基づいて国連欧州経済委員会（UNECE）によって制定された 港及び地名コード （UN/LOCODE）を使いましょう。IATAの空港コードよりも、さらに具体的な場所を示せ、よく定義された規格です。

ほとんどのケースで、国を示す2文字は省略でき、3文字の地域名コードだけで使えます。つまり、複数の国にまたがってデータセンタがあって、国は違うのに、たまたま同じ地域名コードが使われているなんてことがない限りは、nyc.us.example.com.ではなく nyc.example.comを使用できます。

<wip>.nyc.example.com.   CNAME   crimson.example.com.

環境を指定する

次に、ホストが所属する環境を指定します。

• dev – Development（ディベロップメント）
• tst – Testing（テスティング）
• stg – Staging（ステージング）
• prd – Production（プロダクション）

上記に挙げた例は、あなたがリリース管理のために従っているプロセスモデルに基づく必要があります。全く同じプロセスモデルである必要はなく、サンドボックスやトレーニングなどのような環境を指定する場合もあります。

<wip>.prd.nyc.example.com.   CNAME   crimson.example.com.

用途とシリアルナンバーを指定する

最後に、ホストの機能の基礎となるカテゴリーを指定し、シリアル番号を付けます。

• app – アプリケーションサーバ（non-web）
• sql – データベースサーバ
• ftp – SFTPサーバ
• mta –メールサーバ
• dns – ネームサーバ
• cfg – 構成管理（puppet/ansible/など）
• mon – モニタリングサーバ （nagios, sensu,など)
• prx – プロキシ/ロードバランサ（ソフトウェア）
• ssh – SSH認証のスキップ/要塞ホスト
• sto – ストレージサーバ
• vcs – バージョンコントロールソフトウェアサーバ（Git/SVN/CVS/など)
• vmm –仮想マシンマネージャ
• web – Webサーバ

シリアル番号には、必要とするキャパシティに基づいて、ゼロパディングを使用してください。拡張を考えたとしても、2桁あれば十分こと足ります。

web01.prd.nyc.example.com.   CNAME   crimson.example.com.

全世界で固有のインデックスよりも、むしろ特定のデータセンタのサーバタイプに基づき割り当て、シリアル番号を増やし関連づけていきましょう。つまり複数のデータセンタで web01 を持つ可能性があることを意味します。

利便性のあるネーム

標準化された構造の他、 webmail, cmdb, puppet などといった利便性のある機能を示す単語のために、さらにCNAMEレコードが必要になるかもしれません。

webmail.example.com.   CNAME   crimson.example.com.

特殊ケース

ネット機器と電力装置

ネット機器と電力装置に対して、ハードウェアは用途を指示しますが、再構成せずに動かすことはほとんど不可能でしょう。ですので、ランダムな単語の命名規則ではなく、機能の略語をDNSのAレコードに割り当ててください。

• con – コンソール/ターミナルサーバ
• fwl – ファイアウォール
• lbl – ロードバランサ(物理的な)
• rtr – L3ルータ
• swt – L2 スイッチ
• vpn – VPNゲートウェイ
• pdu – PDU（電源タップ）
• ups – UPS（無停電電源装置）

恐らく、ここでもデータセンタの地理的情報が欲しくなるでしょう。希望すれば、core/dist、パブリック vs プライベートといったさらに具体的な情報としてCNAMEレコードを追加することができます。

rtr01.nyc.example.com.   A   192.0.2.1

セカンダリIPアドレスと仮想IPアドレス

セカンダリIPアドレスと仮想IPアドレス（高可用性、Webサービス、ネットワーク移行、トラフィックがタグづけされた仮想LANに使われます）が、一筋縄でいかないところは特定のハードウェアと結びついていないところです。このケースでは、直接、機能的なネームをDNSのAレコードに割り当てて、通常の命名規則に従うことが最も簡単です。

メールサーバとネームサーバ

メールサーバとネームサーバの場合は、DNSのAレコードを利用する必要があります。というのも MXレコードとNSレコードはCNAME仮想ファイルを指してはいけないからです。 とはいえ、DNS のAレコードを複数持つことができるので、通常の構造に従い、パブリックMXレコードとNSレコードを利用するために別のものを加えます。

puma.example.com.    A   192.0.2.20
mta01.example.com.   A   192.0.2.20

DNS設定

各データユニットに適切なDNSサブドメインを使用したので、検索ドメインはホストごとに、マシンのローカルなカテゴリーに注意を払うためだけに設定できます：

search  prd.nyc.example.com  example.com

これにより短いバージョンのホスト名を使えるようになるため、そのマシンで仕事をしている時に便利です。例えば、データセンタ内で通信する際に、 ping sql01 と入力するだけでよく、 ping sql01.prd.nyc.example.com と完全な名前を入力する必要がありません。

一般的に、この命名規則を使うと不注意により情報が開示されるのを防ぐこともできます。公開されるのは短いランダムなホスト名だけで、機能的名称は内部ネットワークでのみ解決されるからです。これはちょっとした 隠すことによるセキュリティ ではありますが、考慮すべき事項です（”特殊ケース”の名前も隠したい場合は、その命名規則を微調整する必要があります）。

プライベートネットワークと帯域外アドレッシング

内部の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.

許容数

この命名規則では1500以上のグローバルサーバを問題なくサポートします。これよりも多くのサーバをお持ちの場合は、ランダムな名前に地域情報の部分を追加して、リストの単語を複数回利用することで対処できます。この手法のマイナス面としては、 crimson.nyc.example.comとcrimson.pdx.example.com の用途がまったくかけ離れている可能性があることで、それを考えると少しためらわれるところです。その場合は、最初の単語リストを拡張することにして、mnemonic encoding単語と同様の基準で選んだ単語を追加して使用するといいでしょう。

10,000台以上のサーバを管理している場合は、ホストは単一の区分化された用途を持っている場合がほとんどでしょうから、上記のことはすべて無視して、ロケーションベースの命名規則または機能的な命名規則をお使いください。

ヒントとコツ

• 自分の環境で専門用語として使われている単語（例：「email」など）は、混乱を招く可能性があるため、mnemonic encoding単語リストから削除する必要があります。
• 用途の略語はすべて同じ長さになるようにし、シリアル番号のゼロパディングも統一します（つまり、あるところでは01、別の場所では1を使ったりしないで、常に長い方の01を使います）。
• 実際に使用する用途の略語は重要ではありません。大切なのは、命名規則を選び、それを文書化して、常にその命名規則に従うことです。
• 詳細な情報をCMDBから引き出すことができるように、用途の略語はある程度法則化することをお勧めします。
• 何があってもすべての情報は必ずCMDBに保存して、簡単にアクセスできるようにする必要があります！
• 必要に応じて、複数のCNAMEレコードを設定できますが、レコードが増えるほど保守しなければならないものが増えることに注意してください。
• できる限り命名手順を自動化しましょう。
• genhost という短いスクリプトを作成したのでお使いください。ホスト名に使用する単語をランダムに選択したり、使用したことのある単語を記録したりするために便利です。

結論

このサーバ命名規則は、マシンを追跡しなければならないという精神的負担を減らしてくれます。また、サービスの関連付けや適切なハードウェアレコードの保守を直接的で分かりやすいものにしてくれます。時間の経過とともに変化する可能性のあるマシンの情報はCNAMEレコード内にだけ存在します。このため、もしサーバが故障しても、新しいホストを指すようにCNAMEレコードを更新すればいいだけなので、他のマシンのそのホストへの参照すべてを更新する必要がありません。この規則には、先行投資として多少の煩雑さはありますが、使いやすさ、保全性、長期的成長のサポートという利点を考えれば、決して損はありませんよ。