Каковы наиболее управляемые и интересные схемы именования серверов? [закрыто]


19

Мне любопытно посмотреть, какие схемы используются при именовании серверов ...

Ответы:


27

Прежде всего, любой, кто выбирает схему именования, должен прочитать RFC 1178 - «Выбор имени для вашего компьютера» . Люди говорили об этой проблеме до тех пор, пока компьютерам давали имена, поэтому прочитайте то, что сказали другие, прежде чем заново изобретать колесо.

Мои собственные мысли - я склонен разбивать политику именования на темы и схемы .

Использование темы (например, греческие боги, персонажи доктора Кто, бренды водки) хорошо работает в небольшой сети. Если у вас менее 20 хостов, скорее всего, у вас несколько конфигураций оборудования - возможно, каждый хост имеет уникальную конфигурацию. В таких случаях хорошо иметь возможность думать о каждой машине как об уникальной личности, потому что, скорее всего, это так.

Использование схемы (например, имя, составленное из элементов географического местоположения, положения стойки, идентификатора оборудования и т. Д.) Хорошо работает, когда у вас есть большое количество машин с одинаковыми аппаратными и / или программными конфигурациями. Это также хорошо работает, если вам нужно общаться о машине с людьми, которые не занимаются ею изо дня в день. Например, если вам нужно сообщить персоналу NOC о необходимости перезагрузить компьютер, лучше использовать имя, которое поможет им найти его в стойке, чем искать в стойке машину с определенной меткой.

Использование функционального имени (например, mail, web, fileserver) - хорошая идея для виртуальных машин, но плохая идея для физических хостов по моему опыту. Физические хосты часто заканчивают тем, что выполняли многократные функции (даже когда это не идеально), и отдельные функции со временем изменятся в использовании ресурсов и требованиях, так что они будут перенесены на другие хосты.

Проблемы с темами включают в себя:

  • Как правило, они предоставляют небольшой пул имен. Когда у вас кончатся римские боги, вы переключитесь на греческий? Вы повторно используете имя с удаленного хоста, которое соответствует вашей теме именования, или выбираете новое имя из новой темы, чтобы избежать проблем и путаницы, которые могут возникнуть из-за повторного использования имени?
  • Они позволяют вашей антропоморфизировать ваши машины. Это плохо - компьютерам это не нравится. Если вы относитесь к своим машинам так, как будто они имеют отличительную индивидуальность, вы рискуете игнорировать доказательства, которые противоречат вашим предположениям о том, как эта машина «ведет себя», а также иногда предполагать, что ошибка связана с конкретной машиной, потому что «это всегда плохо себя ведет ".

Проблемы со схемами включают в себя:

  • Они приводят к именам хостов, которые труднее запомнить. Это гораздо меньше проблем, когда у вас есть хорошее управление системами, но иногда полезно иметь возможность мгновенно вспомнить, что конкретная проблема проявлялась более одного раза на конкретной машине, или что именно за машину отвечает выполняя определенную функцию.
  • Если схема изменится, вам, возможно, придется переименовать все ваши хосты. Это может привести к большому количеству изменений DNS, изменений конфигурации, списка доступа и изменений разрешений и т. Д.

В реальном мире обе системы работают, иногда рядом. Например, по моему опыту, высокопроизводительные вычислительные кластеры всегда имеют имена. Имя часто присваивается головному узлу (который используется в интерактивном режиме), в то время как различные узлы кластера будут иметь имена, такие как compute-01, highmem-01, storage-01 и т. Д.

И, как упоминалось ранее, для виртуальных машин и физических хостов характерно (и полезно) иметь разные схемы именования.


9

Под интересной категорией есть ответ из Stack Overflow

Элементы периодической таблицы. Мы также используем номер элемента в IP-адресе, поэтому

Водород = 192.168.0.1

Гелий = 192.168.0.2

и т.п.


1
что ты делаешь в 118? :)
Chopper3

Понятия не имею ^^ Переключитесь на 192.168.1. * И начните снова. Я предполагаю: PI не использует это лично, просто подумал, что это интересная идея. Не моя идея, была от ТАК.
Адам Гиббинс

Chopper3: вы бы просто пошли и использовали «ununoctum» :) Однако, ваша точка
зрения верна

9
118, очевидно, начало диапазона DHCP :)
Кевин Куфал

7

Я ОЧЕНЬ твердо верю в именование физических серверов по их расположению (например, код страны / код города / код центра данных / этаж / стойка / стойка-U-высота) и серверов программного обеспечения / виртуальных машин только по их функциям ( платформа / функция / кластер / повторение). Я знаю, что это может сделать имена длиннее, чем называть их после семи гномов или чего-то еще, но это отличный способ убедиться, что вы более «ориентированы на будущее» и имеете дело с виртуализацией структурированным образом.

Например, у нас есть серверы VMWare с именем 044LONTH72G216 (он точно находит сервер в мире) с виртуальными машинами гостевых серверов, такими как NESQLC11S08. Вы всегда можете создать для них короткие имена для работы внутренней ИТ-команды, каждая из которых ссылается на эти более длинные, более организованные имена.

Надеюсь это поможет.


7

Мы начали с именования наших серверов с определенной темой (книги Библии), но по мере того, как наша ИТ-команда (и количество серверов) росла и становилась более специализированной - и, поскольку у нас была большая текучесть кадров, мы обнаружили, что любая система именования, которая не каким-то образом относиться к функции (или местоположению) сервера стал запутанным.

Люди знали серверы, на которых они работали регулярно, но при работе над новым проектом, перекрестном обучении или попытке помочь другому администратору что-то пропустили, потому что «никто не знал, что псалмы были почтовыми серверами» или тому подобное.

Теперь мы вернулись к более наглядной схеме именования.


4
Все знают, что послания должны быть почтовыми серверами.
Приостановлено до дальнейшего уведомления.

5

Мы даем всем нашим серверам имена в соответствии с их ролью, то есть тем, что они делают.

Таким образом, наши серверы имеют такие имена, как

- PDC
- SQL
- EXCHANGE
- RDP
- FILE etc..

3
Я стараюсь избегать этого в максимально возможной степени, так как это неприятно, если серверы когда-либо меняют назначение, вы теряете счет того, какой сервер был каким. Многие серверы также имеют несколько целей.
Адам Гиббинс

2
Если сервер меняет цели, он должен быть переформатирован (и, следовательно, переименован) в любом случае.
Портман

4
Это то, что вы можете иметь как CNAME. А-запись должна быть уникальной для хоста и ничего не говорить о ее функции. Пользователям не нужно знать A-записи, только CNAMEs imo.
Командир Кин

1
Взятый до крайности ... кто-то назвал весь домен RTC-2k. RTC был доменом, а 2k был потому что ... это был домен 2000 года. Теперь все клиенты и домен связаны с RTC-2k, что не имеет смысла для пользователей или новых администраторов. Назовите сервер по тому, что он делает, а не по тому, что он есть.
Джозеф Керн

3

По моему опыту, серверы с нечитаемыми именами (то есть метод схемы) не управляемы. Я часто видел ошибочные символы, приводящие к тому, что на неправильном сервере выполнялась операция xyz, иногда с катастрофическими результатами.

Удобочитаемое имя со связанными метаданными, хранящимися в поле описания или аналогичном, кажется менее подверженным проблемам PEBKAC.



2

Мы начали с Берта и Эрни в те времена, когда кластер из 2 microVAX 3400 был большой проблемой для компании. Мы какое-то время оставались на Улице Сезам - Bigbird, Elmo, Grover, thecount (финансовая система), но в итоге пришлось пойти по схеме. Какие именно элементы в схеме зависят от размера вашей компании, мы должны были включить:

Местоположение (двухбуквенное сокращение для города) Подразделение (компания была образована путем слияния 4-х сот, поэтому у нас было 3-х буквенное сокращение для них) Функция (PDC, mail, print, www и т. Д.) Серийный номер (I Мне всегда нравилось иметь год и месяц как часть серийного номера)



1

Был клиент один раз, который назвал серверы в честь кроликов Playboy. Однако это не было широко освещено за пределами ИТ. ;-)

Мне нравилось называть их в честь больших кошек, но потом появилась OS X и разрушила это для меня.

Другая популярность - это виды алкоголя. JimBeam, Beefeater, Stoli и др. Различные классы алкоголя были разными классами сервера. Джин для почтовых серверов, виски для баз данных, парктроник всегда был самогоном.


1

Начиная с любых новых систем в этом году, мы начнем использовать скучные описательные имена (почта, печать и т. Д.), Но до сих пор мы использовали животных - с разными типами животных для разных целей: птицы, рыбы, животные в джунглях и т. Д.


0

Музыканты в топ 40.

Они меняются достаточно часто, чтобы постоянно предлагать новые, но, что более важно, они будут достаточно загадочными для всех, кто старше 12 лет.



0

Мы используем это, что работает довольно хорошо.

  • сайт (2 символа)
  • dev / test / live (3/4 символа)
  • функция (3+ символа)
  • считать (2 символа)
  • вм или нет (2 символа)

0

В работах, которые у меня были, я видел следующие тенденции, кроме классического server01, server02 и т.д .:

  • драгоценные камни
  • рыбы
  • цветы
  • Персонажи звездных войн
  • животные

0

В университете, где я учусь, они используют имена разных персонажей из историй Астерикса и Обеликса. Такие как miraculix, astmatix и т. Д.


0

Наши серверы названы в честь домашних животных. с небольшой разбивкой по типу. Все контроллеры домена названы в честь птиц. Собаки для файла и печати. Кошки для серверов приложений.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.