Возможный дубликат:
Какие наиболее удобные и интересные схемы именования серверов используются?
Как вы выбираете новое имя хоста?
Во многом зависит от среды, в которой вы работаете.
Прежде всего - откажитесь от любых ссылок на (поп-) культуру, придерживайтесь значимых и описательных имен.
Вы может знать, что «zeus» - это прокси-сервер, потому что вы его установили. Но любой будущий коллега очень хотел бы обратиться к серверу через что оно делаетне то, что его собственное имя является.
Если вы согласны с этим, я предлагаю вам провести сеанс мозгового штурма и записать, какие у вас есть разные типы сетевых объектов («хостов»), как их можно сгруппировать и какая информация достаточно важна, чтобы ее можно было закодировать в имени хоста. Ваше соглашение об именах должно иметь возможность однозначно называть все существующие устройства и давать пользователю приблизительное представление о том, что делает хост. Обязательно оставьте достаточно места для роста, чтобы адаптироваться к будущим разработкам, чтобы вам не пришлось отказываться от соглашения об именах через несколько месяцев.
Задокументируйте свое соглашение об именах (не только как, но и почему), убедитесь, что все, кому нужно работать с ним на регулярной основе, понимают, как оно изложено, будьте открыты для комментариев / предложений и не рекламируйте его как святой Грааль. при необходимости адаптируйте его.
В качестве пищи для размышлений вот схема, которую мы использовали у одного из моих бывших работодателей:
Поставщик веб-услуг, занимающийся разработкой и эксплуатацией веб-проектов. В основном LAMP-вещи, хотя и в более крупном масштабе (размер проектов, а не количество).
Для физических устройств:
<САЙТ> - <СТОЙКА> - <УСТРОЙСТВО> .in. <ДОМЕН>. <TLD>
Для логических сущностей:
Логическими объектами может быть что угодно, имеющее IP-адрес, который не был сильно связан с данным физическим устройством / местоположением. В основном это были IP-адреса гостевой ОС (в нашем случае OpenVZ или ESX).
<ПРОЕКТ> - <СРЕДА> - <СЕРВИС> .в. <ДОМЕН>. <TLD>
Для IP-адресов:
Все наши сервисы были доступны только из частной сети, у нас были NAT и / или балансировщики нагрузки с «IP-адресами сервисов», которые использовались хостами, подключенными к Интернету, для доступа к нашим сервисам. Для них мы использовали что-то вроде этого:
<ПРОЕКТ> - <СРЕДА> -vip- <ИДЕНТИФИКАТОР>. <ДОМЕН>. <TLD>
Соглашение об именах сработало для нас, некоторые (например, наши разработчики;)) могли бы назвать его чрезмерным. Имейте в виду, что это является полностью раздуты, если вы поддерживаете только один сайт и имеете серверы, назначенные для одного проекта. Но для нас это выполнило несколько очень важных вещей.
Имея дело с именем хоста логической сущности, мы всегда знали:
А для физических устройств точное местоположение всегда определялось по имени хоста.
Слабая связь между физическими устройствами и логическими серверами может быть отключением для некоторых людей (например, как мне узнать, какие проекты будут затронуты, когда я отключу переключатель x / server y), но это было необходимо в наша среда, поскольку у наших проектов была высокая скорость оборачиваемости, и чаще всего мы даже не знали, какие проекты будут размещены на новом оборудовании, которое мы только что подготовили.
Что касается серверов, мне нравится стандарт, который сейчас используется в моем офисе <трехбуквенный код местоположения> - <2-значное увеличивающееся число, чтобы избежать дублирования имен>
Примером может быть: PHOU-DMOSQL01
Для настольных / портативных компьютеров я обычно использую обозначение типа и имя пользователя (при условии, что машины назначены конкретному пользователю) (LT | DT) - например, мой ноутбук LT-KCOLBY
Большой список схемы именования сетей и серверов.
Я использую уникальные имена для описания уникальных машин. Например, в моем текущем проекте, насчитывающем более 200 серверов, я использовал список звездных имен из Википедии. Причина в том, что фактические имена имеют большую избыточность, чем суперкомпактные индексы, такие как srv-05-92. Это важно с одной стороны: это дает небольшую вероятность ошибок при расшифровке, наборе текста или разговоре по телефону в шумной серверной.
Описательная информация хранится в полях TXT в DNS, как и Mac-адреса и так далее. Вы также можете запросить имя на основе MAC-адреса:
$ host 00-12-34-56-78.mac.fr.dom
00-12-34-56-78.mac.fr.dom is an alias for arcturus.eqx.vl304.fr.dom
arcturus.eqx.vl304.fr.its has address 10.21.4.30
Единственное, чего вы абсолютно не хотите, - это называть машины в соответствии с их функциями. Это рано или поздно укусит тебя за задницу. Просто используйте для этой цели псевдонимы (CNAME или дополнительные записи A).
Примечание: Все это создается с помощью XSLT из пользовательского XML-файла:
<?xml version="1.0" standalone="yes"?>
<domain suffix="dom" xmlns:h="http://www.w3.org/1999/xhtml">
<vlans>
<vlan name="vl304" value="4" />
</vlans>
<country code="fr" prefix="10.21">
<datacenter name="eqx" desc="Equinix">
<host name="arcturus" lso="30">
<vlan name="vl300" if="eth0" mac="00:12:34:56:78" />
<txt type="loc">rack 5</txt>
<txt type="sn">99A0632</txt>
<txt type="model">xSeries x3350</txt>
<doc>Load balancer</doc>
<rsa ip="192.168.101.30" />
<role type="loadbalancer1" />
</host>
</datacenter>
</country>
</domain>
Генерируются несколько псевдонимов:
... а также ряд записей TXT
Настоящий ответ в том, что ответа нет.
Я испробовал ряд соглашений для имен серверов и компьютеров. Я пришел к выводу, что само имя не имеет смысла, если у вас есть легкодоступное, легко изменяемое поле описания без каких-либо последствий.
Поэтому я считаю, что с ума сойти. Фэнтезийные герои, значки Звездных войн, мифология - все, что вам нравится и имеет достаточно возможностей, чтобы включить всех ваших существующих хостов и дополнений. (и это не означает, что у вашего руководства часто не хватает чувства юмора, боссы могут быть придирчивыми к серверу с именем «pointyhaireddimwit» :)).
Наверное, стоит отметить, что RFC 1178 посвящен этой теме:
http://www.faqs.org/rfcs/rfc1178.html
(даже если я не согласен со многими из них, и многое из них устарело).
Именование серверов на основе местоположения и / или функции может привести к проблемам с безопасностью. Если вы публикуете свой DNS извне, вы показываете плохим парням карту всего хорошего. На безопасность через безвестность нельзя полагаться, но я бы не стал упрощать задачу для скрипачей.
Также вам не нужно описывать все детали устройства в имени хоста. Вместо этого используйте имя хоста в качестве ключа в базе данных управления конфигурацией. (Вы можете купить CMDB, использовать решения с открытым исходным кодом или обратиться к электронной таблице Excel).
Лично мне нравятся следующие названия устройств:
Пример: мы называли один из наших серверов резервного копирования - sloth.
К сожалению, это работает только для небольших сайтов. Если вы управляете более крупными установками, вам понадобится максимально четкое соглашение об именах, чтобы все ваши сотрудники могли быстро и легко определить, что делают все эти хосты. В этом случае, вероятно, вы захотите реализовать разделенный DNS, чтобы вы не рекламировали все эти имена хостов в дикой природе.
Если ваше внутреннее соглашение об именах является частным, то на самом деле не имеет значения, какую схему именования вы используете. Но вот идея. Получите технических рекомендаций от вашей службы поддержки и спросите их, есть ли у них какие-либо предложения. Это заставит их почувствовать себя важными.
Лавкрафт Великие Древние и Внешние боги.
Я использую актеров. Чем важнее коробка, тем круче актер ... Я пытался сгруппировать их по фильмам, в которых они снимались вместе, но вскоре это больше не сработало, когда серверы переместились и были переназначены. Мой сервер RHEL Satellite просторен, мои серверы системного журнала - brando и dean. Сибел бегает от Питта, Джоли и так далее.
На моей предыдущей работе я назвал все рабочие станции / серверы в новой сборке в честь планет / лун из «Звездных войн» - Татуин, Хот, Эндор, Дантуин и т.д. На моей текущей работе локальные серверы / рабочие станции были названы в честь персонажей «Звездных войн», но постепенно сокращаются до более общих имен. В нашей производственной среде серверы названы в честь персонажей из греческой мифологии.
Дома все мои физические / виртуальные серверы названы в честь их использования - файловый сервер, почтовый сервер, ftpserver, веб-сервер, mssqlserver и т. Д. Однако сейчас это оказывается трудным, поскольку я создаю дополнительные веб-серверы. По ностальгическим причинам я подумываю перейти к соглашению об именах, которое использовалось на моей предыдущей работе.
Мы испробовали два варианта соглашений об именах серверов для нашей среды среднего размера:
И
Из этих двух условностей 80% техников (включая меня) нравится соглашение о названии города больше, чем «Loc-Serv- #».
В настоящее время мы используем смесь фальшивой схемы именования (станции лондонского метро) и функциональных названий. Последнее произошло, когда стало сложно запомнить, какие 11 серверов были в кластере веб-серверов. Запоминать викторию, юстон, паддингтон, овал, кокфостеры, ангела, банк и т. Д. Немного сложнее, чем w000, w001, w002 и т. Д.
Мой друг использует имена кельтских богов. Моя компания использует имена диких животных для терминалов и названия лекарств для серверов. Я использую имена из «Сильмариллиона Толкина».
На этот вопрос нет "хорошего" ответа:
Если ваши серверы сгруппированы в кластер, вам может потребоваться идентифицировать других членов кластера, чтобы иметь возможность включить их. Если ваш сервер является мультиролевым, вы не можете использовать их роли как часть имени ... Фактически, ваши имена хостов должны содержать информацию, которая будет ценна для вас и людей, которые будут работать над поломкой компьютера.
Некоторое время назад на Slashdot была отличная ветка об этом:
http://ask.slashdot.org/story/08/07/06/2014237/Best-DNS-Naming-Scheme-For-SmallMedium-Busshops?art_pos=1
У нас есть система, аналогичная колби.
так что PHLVMCLDEV01 будет первым кластером разработки в Филадельфии, и его узлы являются вирутальными
он будет состоять из PHLVMDEV01-N1 и PHLVMDEV01-N2 и т. д.
Есть ряд существующих вопросов по этой теме
Не могу поверить, что у вас действительно есть все эти длинные и сложные имена. Вы все время это печатаете? Вы знаете, сколько информации вы теряете (включая расположение физических серверов ???).
Используемый нами подход заключается в том, чтобы дать серверам простые имена на основе мультфильмов, фильмов и т. Д. Внутри мы храним базу данных, связывающую забавные имена с их местоположением, назначением и т. Д.
* Со всеми этими длинными именами хостов вместо этого легко запомнить ips :)
Просто используйте это соглашение (все еще немного привязанное к старым ограничениям на 8 символов)
Двухбуквенный код страны - трехбуквенный код города - название машины
Имена машин обычно основаны на фактическом назначении (mssql для сервера MSSQL) или типе, если запущены мультисервисы (rhel001 как машина с красной шляпой).
Вы получаете такие имена, как us-dco-rac01 (первый узел Oracle RAC).