Назад | Перейти на главную страницу

Соглашения об именах

Возможный дубликат:
Какие наиболее удобные и интересные схемы именования серверов используются?

Как вы выбираете новое имя хоста?

Во многом зависит от среды, в которой вы работаете.

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

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

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

Задокументируйте свое соглашение об именах (не только как, но и почему), убедитесь, что все, кому нужно работать с ним на регулярной основе, понимают, как оно изложено, будьте открыты для комментариев / предложений и не рекламируйте его как святой Грааль. при необходимости адаптируйте его.

пример

В качестве пищи для размышлений вот схема, которую мы использовали у одного из моих бывших работодателей:

Поставщик веб-услуг, занимающийся разработкой и эксплуатацией веб-проектов. В основном LAMP-вещи, хотя и в более крупном масштабе (размер проектов, а не количество).

Для физических устройств:

<САЙТ> - <СТОЙКА> - <УСТРОЙСТВО> .in. <ДОМЕН>. <TLD>

  • САЙТ - уникальный идентификатор сайта, в основном состоящий из трех букв.
  • СТОЙКА - это идентификатор, присвоенный нами или принятый на хостинге, он должен иметь возможность однозначно идентифицировать стойку на САЙТЕ.
  • DEVICE был "классом устройства" со счетчиком после него, например vnodeXX для узлов OpenVZ, swge для гигабитных коммутаторов и т. д.
  • DOMAIN / TLD был доменом владельца данных устройств.

Для логических сущностей:

Логическими объектами может быть что угодно, имеющее IP-адрес, который не был сильно связан с данным физическим устройством / местоположением. В основном это были IP-адреса гостевой ОС (в нашем случае OpenVZ или ESX).

<ПРОЕКТ> - <СРЕДА> - <СЕРВИС> .в. <ДОМЕН>. <TLD>

  • ПРОЕКТ - это идентификатор проекта, который объединяет различные услуги проекта.
  • ОКРУЖАЮЩАЯ СРЕДА может быть производством, постановкой или разработкой, сокращением из 4 букв.
  • СЛУЖБА была относительно свободной формой, хотя общие случаи были стандартизированы, например, веб, база данных, рассылка и т. Д.
  • DOMAIN был основным доменом рассматриваемого проекта.

Для IP-адресов:

Все наши сервисы были доступны только из частной сети, у нас были NAT и / или балансировщики нагрузки с «IP-адресами сервисов», которые использовались хостами, подключенными к Интернету, для доступа к нашим сервисам. Для них мы использовали что-то вроде этого:

<ПРОЕКТ> - <СРЕДА> -vip- <ИДЕНТИФИКАТОР>. <ДОМЕН>. <TLD>

  • ИДЕНТИФИКАТОР был чем-то, что однозначно определяло использование IP-адреса, например адрес, который использовался исключительно в качестве виртуального хоста сети для немецкого домена проектов, может называться wwwde.

Подводя итоги

Соглашение об именах сработало для нас, некоторые (например, наши разработчики;)) могли бы назвать его чрезмерным. Имейте в виду, что это является полностью раздуты, если вы поддерживаете только один сайт и имеете серверы, назначенные для одного проекта. Но для нас это выполнило несколько очень важных вещей.

Имея дело с именем хоста логической сущности, мы всегда знали:

  • В каком проекте участвовали:
    Различные проекты имели разную важность с разными ответственными командами разработчиков. Быстрый взгляд на имя хоста рассказал вам, как вам нужно расставить приоритеты задач и кого вам нужно спросить на стороне управления / разработки.
  • В какой среде находился хост:
    Проблемы в средах разработки замедляют работу разработчиков. Проблемы в промежуточной среде причиняют боль тестировщикам и могут поставить под угрозу презентацию продукта. И если что-то нарушается в производстве, компания теряет деньги.
  • На какую подсистему влияет:
    Спулеры почты, пакетные обработчики и т. Д. Были не так важны, но если веб-серверы или серверы баз данных не работают, все становится довольно быстро.

А для физических устройств точное местоположение всегда определялось по имени хоста.

Слабая связь между физическими устройствами и логическими серверами может быть отключением для некоторых людей (например, как мне узнать, какие проекты будут затронуты, когда я отключу переключатель x / server y), но это было необходимо в наша среда, поскольку у наших проектов была высокая скорость оборачиваемости, и чаще всего мы даже не знали, какие проекты будут размещены на новом оборудовании, которое мы только что подготовили.

Что касается серверов, мне нравится стандарт, который сейчас используется в моем офисе <трехбуквенный код местоположения> - <2-значное увеличивающееся число, чтобы избежать дублирования имен>

Примером может быть: PHOU-DMOSQL01

  • Физический
  • Хьюстон
  • Демо-среда
  • SQL Server
  • 01

Для настольных / портативных компьютеров я обычно использую обозначение типа и имя пользователя (при условии, что машины назначены конкретному пользователю) (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>

Генерируются несколько псевдонимов:

  • arcturus.eqx.vl306.fr.dom (каноническое имя)
  • arcturus.vl306.fr.dom
  • arcturus.fr.dom
  • 00-12-34-56-78.mac.fr.dom
  • arcturus-rsa.fr.dom
  • loadbalancer1.eqx.vl306.fr.dom
  • loadbalancer1.vl306.fr.dom
  • loadbalancer1.fr.dom

... а также ряд записей TXT

Настоящий ответ в том, что ответа нет.

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

Поэтому я считаю, что с ума сойти. Фэнтезийные герои, значки Звездных войн, мифология - все, что вам нравится и имеет достаточно возможностей, чтобы включить всех ваших существующих хостов и дополнений. (и это не означает, что у вашего руководства часто не хватает чувства юмора, боссы могут быть придирчивыми к серверу с именем «pointyhaireddimwit» :)).

Наверное, стоит отметить, что RFC 1178 посвящен этой теме:
http://www.faqs.org/rfcs/rfc1178.html

(даже если я не согласен со многими из них, и многое из них устарело).

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

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

Лично мне нравятся следующие названия устройств:

  1. короткий
  2. Легко написать
  3. Веселая

Пример: мы называли один из наших серверов резервного копирования - sloth.

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

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

Я использую актеров. Чем важнее коробка, тем круче актер ... Я пытался сгруппировать их по фильмам, в которых они снимались вместе, но вскоре это больше не сработало, когда серверы переместились и были переназначены. Мой сервер RHEL Satellite просторен, мои серверы системного журнала - brando и dean. Сибел бегает от Питта, Джоли и так далее.

На моей предыдущей работе я назвал все рабочие станции / серверы в новой сборке в честь планет / лун из «Звездных войн» - Татуин, Хот, Эндор, Дантуин и т.д. На моей текущей работе локальные серверы / рабочие станции были названы в честь персонажей «Звездных войн», но постепенно сокращаются до более общих имен. В нашей производственной среде серверы названы в честь персонажей из греческой мифологии.

Дома все мои физические / виртуальные серверы названы в честь их использования - файловый сервер, почтовый сервер, ftpserver, веб-сервер, mssqlserver и т. Д. Однако сейчас это оказывается трудным, поскольку я создаю дополнительные веб-серверы. По ностальгическим причинам я подумываю перейти к соглашению об именах, которое использовалось на моей предыдущей работе.

Мы испробовали два варианта соглашений об именах серверов для нашей среды среднего размера:

  • «Местоположение» - «Тип сервера» - «Номер»:
    • «Майн-ДБ-01»
    • «Майн-FW-01»
    • «Крыло2-ФС-01»
    • «Крыло2-ФС-02» и др.

И

  • Названия городов:
    • "Нью-Йорк"
    • «Майами»
    • «Портленд»
    • «Сиэтл» и др.

Из этих двух условностей 80% техников (включая меня) нравится соглашение о названии города больше, чем «Loc-Serv- #».

В настоящее время мы используем смесь фальшивой схемы именования (станции лондонского метро) и функциональных названий. Последнее произошло, когда стало сложно запомнить, какие 11 серверов были в кластере веб-серверов. Запоминать викторию, юстон, паддингтон, овал, кокфостеры, ангела, банк и т. Д. Немного сложнее, чем w000, w001, w002 и т. Д.

Мой друг использует имена кельтских богов. Моя компания использует имена диких животных для терминалов и названия лекарств для серверов. Я использую имена из «Сильмариллиона Толкина».

На этот вопрос нет "хорошего" ответа:

  • в моей текущей работе я управляю небольшим набором серверов (10/15), но у меня много оборудования, расположенного у наших клиентов. Мы используем названия островов для наших офшорных серверов, названия канадских провинций для наших внутренних серверов и названия канадских городов для рабочих станций (да, мой босс из Канады). У устройств есть общее название, включающее номер клиента.
  • Раньше я работал в более крупной международной фирме с большим количеством серверов (около 3К). Каждый сервер был посвящен своей задаче и находился в кластере. Имя хоста включает страну (Великобритания, Бельгия, Нидерланды), роль сервера (DC, SQL), центр обработки данных, в котором хранится сервер, и рейтинг в кластере. Мы также включаем среду (производство, разработка, тестирование), потому что каждая среда была закрытой и не могла взаимодействовать друг с другом.
  • На моей предыдущей работе я работал в банке с примерно 100 тысячами серверов. Имя хоста включает город, в котором расположен сервер, название, версию и редактор операционной системы, аппаратную платформу (i386, ..) и номер сервера в виде 5 цифр.

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

Некоторое время назад на Slashdot была отличная ветка об этом:
http://ask.slashdot.org/story/08/07/06/2014237/Best-DNS-Naming-Scheme-For-SmallMedium-Busshops?art_pos=1

У нас есть система, аналогичная колби.

  1. Код аэропорта или другое уникальное трехбуквенное сокращение.
  2. vm, если он виртуальный
  3. cl, если это кластер
  4. функция
  5. уникальный номер
  6. и необязательно -n1,2, ... если это член кластера

так что PHLVMCLDEV01 будет первым кластером разработки в Филадельфии, и его узлы являются вирутальными

он будет состоять из PHLVMDEV01-N1 и PHLVMDEV01-N2 и т. д.

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

Используемый нами подход заключается в том, чтобы дать серверам простые имена на основе мультфильмов, фильмов и т. Д. Внутри мы храним базу данных, связывающую забавные имена с их местоположением, назначением и т. Д.

* Со всеми этими длинными именами хостов вместо этого легко запомнить ips :)

Просто используйте это соглашение (все еще немного привязанное к старым ограничениям на 8 символов)

Двухбуквенный код страны - трехбуквенный код города - название машины

Имена машин обычно основаны на фактическом назначении (mssql для сервера MSSQL) или типе, если запущены мультисервисы (rhel001 как машина с красной шляпой).

Вы получаете такие имена, как us-dco-rac01 (первый узел Oracle RAC).