さまざまなサーバー(さまざまなハードウェア、ソフトウェア、オペレーティングシステム、仮想/専用など)の操り人形管理クラスターがある環境を想定します。
意味のあるホスト名(mysqlmaster01..99、mysqlslave001..999、vpnprimary、vpnbackupなど)を選択しますか、それとも本や映画の文字など、意味のないホスト名を使用しますか?
意味のあるホスト名で私が目にする問題は、名前が通常単一のサービスを表し、サーバーに複数の目的がある場合、それが本当に面倒になることです(特にサーバーの役割が頻繁に変わる場合)。
サービス名をIPアドレスにマッピングし、そのマッピングを維持して、DNSが行うことになっているのではないですか?
両方のアプローチの長所と短所は何ですか?また、選択したアプローチで取り組む必要があった実際の問題は何ですか?
むかしむかし、私は命名スキームを決定する機会がありました。だから私はラウンドして、結局のところ、日常的にこれらの名前を扱う必要のある人たちである開発者に、functional名前(つまり、 、いくつかのエンコードされた形式では、マシンの目的)またはニーモニック名前(つまり、マシンの目的に関する暗黙のコンテンツを含まない、既存の人間の命名スキームから引き出された名前)。
38名の開発者のうち、37名がニーモニック名を好んだ。 1つの優先機能名のみ。だから私は川にちなんでそれらすべてに名前を付けました(可能な名前の非常に大きなプールがあり、それらの多くは短く、覚えやすく、すばやく入力できます)。
人間の脳は、名前に意味を付けるためにかなりうまく設計されています。覚えやすい名前を付けると、人々はそれらの名前が何のために使用されているかをすぐに思い出し、それらを使用します。いくつかの一般的な背景から抽出した名前を使用すると(たとえば、川、要素、星、郡、飲み物など、アイデアが浮かび上がります)、企業のホスト名を見つけたときにすぐにそれを認識できるようになります。それ以外の場合、「すべての電子メールがbetelgeuse
に到達した」などのステートメントは少し混乱する可能性があります)。
逆に、私の開発者は、以前の仕事で彼らが持っていたものを正確に覚えるのは本当に大変だったと感じましたpr1ms001
でした。
ただし、内部DNSでCNAMEを使用して機能名からニーモニック名へのマッピングを提供したので、PRサイトの最初のクラスターのメインメールサーバーがpr1ms001
の場合、DNSはそれが現在orwell
であることを通知します。また、マシンごとに多くの機能名を持たせることで、作業中の機能に関連する機能名を常に使用している限り、pr1imap001
は、その機能をorwell
からrhine
に移動した場合でも、常にIMAPサーバーを指します。そして、hudson
が亡くなったとき、運用機能に影響を与えることなく、置き換えの名前を変更できるため、「新しいhudson
と古いhudson
のどちらを意味しますか?」錯乱。
これは主に、サーバーがpets
かlivestock
かによって決まります。
ペットは個々の名前を取得します。それらはお互いに異なり、私たちはそれらの違いを気にします。人が病気になったとき、私たちは通常、それを健康に戻すために看護しようとします。従来、サーバーはペットでした。
家畜は番号を取得します。それらはほとんど同一であり、どのような違いがあるかは気にせず、通常は最小化しようとします。人が病気になったとき、私たちはそれを下に置いて別のものを得ます。完全に仮想化されたサーバー、特にAWSなどのIaaSサーバーは家畜です。
ほとんどの複雑な環境では、混在しています。たとえば、Webバックエンドはほぼ確実に家畜です。さらに必要な場合は、標準の設定でさらにいくつかを起動します。必要ない場合はオフにします。データベースサーバーは、一部の構成ではペットです。それぞれに特別な設定がたくさんあるかもしれません。仮想化ではなく、ベアメタルで実行することもできます。
もちろん、どちらの環境でも、SERVICESに名前を付けて直接アドレス指定できます。これはどの場合でもベストプラクティスです。開発者は、サービスの実際のホスト名を知る必要も、気にする必要もありません。ホスト名は、純粋に運用上の詳細である必要があります。次に、運用担当者がホスト名で役立つエンコーディング情報について考えてください。たとえば、サーバーがどのデータセンターにあるかを示すと役立つことがよくあります。
私の推奨は、機能名とニーモニック名の組み合わせです...
アプリケーションを作成していて、ccts-logserver1
をアドレス指定する必要がある場合は、その名前を全体に使用しますが、CNAMEまたはエイリアスにします。実際のホスト名は、果物や野菜、ギリシャ神話、またはサインフェルドの文字など、何でもかまいませんが、実際の機能名を関連付ける必要がある場合はある程度の柔軟性が得られますが、覚えやすいものを保持してください。
mango
の例を考えてみてください。DBサーバーは失敗しますが、Peach
のように別の何かに置き換えられます。おそらく、既存のプロセスとアプリケーションはcmt-prod-db1
を参照する必要があります。システムを交換して、名前の競合なしにシステムを構築し、アプリケーション(および開発者)を満足させることができます。
私が働いている場所では、複数の都市にある複数のサイト、複数の企業を管理しています。私たちにとって、ニーモニック名は機能しません。代わりに、サーバーを説明する省略形を使用します。これは、異なるドメインに複数のオフィス(または複数のドメインに1つのオフィス、同じドメインに複数のオフィス、または上記すべて)を持つクライアントがいるため、私たちのケースではうまく機能します。
私たちにとって、情報には会社/ドメイン、都市、機能、番号が含まれています。したがって、会社のドメインコントローラの場合、シカゴのサイプレスは次のようになります。
CYPRCHDOM001(これを会話中のサイプレスのメインDOMと呼びます)
CYPRCHSQL001はSQLサーバー、CYPRCHMGM001はその管理(ウイルス対策、バックアップなど)、CYPRCHAPP001は混合アプリケーションサーバーです。覚えやすく、並べ替えも、教えるのも簡単です。
ホスト名の唯一の要件は、ホスト名がネットワーク上で一意であることです。
意味は、サーバー機能だけに関係する必要はありません。ロケーションは、物理デバイスを扱う必要がある場合に非常に役立ちます。デバイスが仮想であるか物理であるかを知ることも役立ちます。ネットワークデバイス、Linuxサーバー、またはWindowsボックスの違いを識別できると、ログインに使用するツールを理解する上で非常に便利です。
これを処理する方法は、次のようにこの情報をデバイス名に挿入することです。
LまたはT-ライブまたはテストPまたはV-物理または仮想SまたはN-サーバーまたはネットワーク(Linuxサーバーはありません)一意性を確保するための連続番号An ISO 3166-1 3文字の国コード デバイスが配置されている場所を示します。
次に、DNSでCNAMESを使用して、さまざまなサービス名をホスト名にマッピングします。
私はこれについて複雑な気持ちを持っています。それは確かに特定のデバイスがどこにあるかを調べる必要がある時間を節約します。一方、ジェムストーンを使用していた以前のシステムと比較すると、特定のサーバーがそのホスト名を提示されたときに何をするかを覚えるのははるかに困難です。宝石は何の意味もありませんでしたが、一人一人が自分のつながりを作ることができたので、覚えやすかったです。
1つのシステムから別のシステムに移行したときに最大の混乱が生じたので、唯一のアドバイスは1つのスキーマで解決することだと思います。