Соглашения об именовании [дубликат]

Зависит очень от среды, в которой Вы работаете.

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

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

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

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

Пример

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

Поставщик веб-сервиса, делая разработку и операции для веб-проектов. Главным образом материал ЛАМПЫ, хотя в более крупном масштабе (размер проектов, не количество).

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

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

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

Для логических объектов:

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

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

• ПРОЕКТ был идентификатором проекта, который собрал в группу различные сервисы проекта.
• СРЕДА могла быть производством, подготовкой или разработкой, 4 буквы abbrevation
• СЕРВИС был относительно свободной формой, хотя общие падежи были стандартизированы, как сеть, дб, mailout, и т.д.
• ДОМЕН был первичным доменом рассматриваемого проекта.

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

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

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

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

Подведение его итогов

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

При контакте с именем хоста логического объекта мы всегда знали:

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

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

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

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

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

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

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

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

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

таким образом, PHLVMCLDEV01 был бы первым кластером разработки в Филадельфии, и это - узлы, virutal

это состояло бы из PHLVMDEV01-N1 и PHLVMDEV01-N2 и т.д.

Существует много существующих вопросов об этом Предмете

• Хорошая конвенция имени хоста для немногих серверов со многими различными сервисами?
• Каковы самые управляемые и интересные используемые схемы именования сервера?

В моем предыдущем задании я назвал все рабочие станции/серверы в новой сборке после планет/лун Звездных войн - Татуин, Hoth, Endor, Dantooine и т.д. В моем текущем задании локальные серверы/рабочие станции назвали в честь символов Star Wars, но медленно постепенно сокращают к большему количеству родовых названий. В нашей продуктивной среде серверы называют в честь символов в греческой Мифологии.

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

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

• "Местоположение" - "Тип Сервера" - "Число":
  • "Main-DB-01"
  • "Main-FW-01"
  • "Wing2-FS-01"
  • "Wing2-FS-02", и т.д.

И

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

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

Мы в настоящее время используем смесь frivious схемы именования (Станции лондонского метрополитена) и функциональные имена. Последний произошел, когда это начало становиться хитрым для запоминания, который 11 серверов были в кластере веб-сервера. Помня victoria, Юстон, Паддингтон, овальный, Кокфостерз, ангел, банк и т.д. немного более тверд, чем w000, w001, w002 и т.д.

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

Lovecraftian большие старые и внешние боги.

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

(даже если я не соглашаюсь с большим количеством его, и много там устарело).

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

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

Лично мне нравятся имена устройств, которые являются:

1. Короткий
2. Легкий записать
3. Забавное

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

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

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

Я использую уникальные имена для описания уникальных машин. Например, в моем текущем проекте, 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 или дополнительный записи) с этой целью.

Примечание: Это все сгенерировано с 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>

Сгенерированы несколько псевдонимов:

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

... а также много записей TXT

Реальный ответ - это никто не отвечает.

Я попробовал много конвенций и за имена серверов и за имена компьютеров. Мое заключение состоит в том, что само имя бессмысленно, пока у Вас есть легко доступное, легко и непоследовательно модифицируемое поле описания.

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

Большой список сети и схемы именования сервера.

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

Пример был бы: PHOU-DMOSQL01

• Физический
• Houstonm
• Демонстрационная среда
• SQL Server
• 01

Для Рабочих столов/Ноутбуков я обычно использую указатель типа и имя пользователя (предполагающий, что машины присвоены определенному пользователю) (LT|DT) - например, мой ноутбук является LT-KCOLBY

Я использую агентов. Чем более важный поле, тем вентилятор агент... Я пытался сгруппировать их фильмами, в которых они были вместе, но это скоро не разрабатывало больше, когда перемещенные серверы и повторно ставились целью. Мой Спутниковый сервер RHEL является ошалевшим, мои серверы системного журнала являются brando и деканом. Siebel работает на pitt и jolie и т.д.

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

2-letter-country-code - трехбуквенный "Кодекс Сити" - название машины

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

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

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

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

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