Pull to refresh

Comments 87

Толковая статься, я тоже над этой проблемой бился долго. В итоге остановился на виде ГОРОД-ИНФРАСТРУКТУРА-ТИП-НОМЕР
В невероятном по размеру Philips, в котором я работал, проблема решена так: Страна, город,. номер домена, тип инфраструктуры(ноутбук, рабочая станция, почтовый сервер, домен-контроллер, sharepoint сервер и т.д.), номер. Если ноутбук и рабочая станция, то еще отдел. Все сокращениями, понятное дело.
В избранное — однажды может пригодиться :)
Еще небольшой хинт: сами машины называть в соответствии с утвержденной схемой наименования (например, как в статье), а для служб делать алиасы. Пример: машина nskhd-mfst11-2.domain.local, а алиас mail.domain.local. В такой схеме несколько преимуществ:
— можно легко переносить сервисы с одной машины на другую меняя алиас в днс,
— решается проблема машин исполняющих несколько сервисов — все обращаются к ним по разным алиасам: mail, proxy, radius etc, а при необходимости разделить службы — просто перенаправляем алиас на новую железку.
Вот как раз алиас (в смысле CNAME) для mail строго недопустим (CNAME и MX'ы плохо дружат). В остальном, да. Причём (у меня это в разделе про псевдонимы есть) лучше даже короче.

Отдельные имена (и IP) для служб — это отдельный разговор.
ой. а расскажи пожалуйста поподробнее про «плохо дружат» пожалуйста!
Описание в RFC 974, RFC 1034

Для сопротивляющихся, разжёвано в RFC 1912:
A CNAME record is not allowed to coexist with any other data.  In
   other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
   can't also have an MX record for suzy.podunk.edu, or an A record, or
   even a TXT record.  Especially do not try to combine CNAMEs and NS
   records like this!:

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      CNAME   mary
           mary            IN      A       1.2.3.4

пошёл посыпать голову пеплом… :(
mail.domain, gateway.domain, vpn.domain, radius.domain, databases.domain, printer.domain и т.д. Плюсом является точное понимание, что каждый сервер делает. Минусом — некоторая путаница при смешанном фунционале (зачем у вас маршрутизатор коннектится к радиусу на сервер mail.domain? Ах, у вас там радиус-сервер? А почему имя «mail»?)

В DNS прописываем:
172.20.15.60 mail.domain
172.20.15.60 vpn.domain
172.20.15.60 radius.domain
И нам больше не надо конектиться к радиус серверу mail.domain когда можно записать radius.domain.

Дополнительный профит: в случае переезда радиуса с одного сервера на другой меняем запись в DNS и не бегаем перенастраивать mail.domain на printer.domain
В логах-то реверс все равно 1 домен будет.
Вам хорошо :) у вас город-… а у кого-то еще и страна-город-…

По поводу городов — удобно использовать IATA коды аэропортов. Они трехбуквенные и однозначные. Только вот msk в этом случае — это аэропорт на Багамах, а spb это штатовские «Virgin Islands».

Итого получается страна-город-улица(строение)-медиа-тип-назначение. Вот так и получаются всякие us-lax-ver-e-r1-core.
:)
>По поводу городов — удобно использовать IATA коды аэропортов.

Далеко не всегда это удобно, поскольку в одной отдельно взятой области(крае, штате, ...) городов обычно куда больше, чем аэропортов, а в отдельно взятом городе может быть несколько аэропортов (хотя, вроде бы, в IATA кодах последнее предусмотрено, если не ошибаюсь — для мегаполисов есть общее название города, и есть коды для каждого аэропорта)
Вы совершенно правы. Изначально схема пришла из штатов. Там как раз, лучше по аэропорту, чем по городу. Ибо тот же LA может быть LAX (LA International) или BUR (Burbank). По сути, разные county, но тем не менее все тот же LA.

Тут наверное еще вот какой момент. Естетственно есть база всего сетевого оборудование, это может быть как Sharepoint, так и что-то самописное. Но. При поступлении, например, заявки в сетевую службу. У вас спросят, откуда вы звоните (страна, город). По этим данным отфильтруют и дальше найти из той оставшейся сотни-две активного железа найти по трем первым буквам или названию комплекса — совсем просто.

Резюмируя.
Вариант хоть и не идеален (минусы вы описали), но имеет место на существование в крупных международных структурах, потому как для вас — msk — это Москва, nnv — Нижний, nsk — Новосиб, а вот для индуса это с таким же успехом могут быть Минск, Нижневартовск, и Норильск. В данном случае именно однозначность и стандартизированность ставится во главу угла.
Все таки неправы насчет LAX и BUR. Да, они размещены в одной metropolitan area, но физически размещаются в разных городах — LAX — Los Angeles, BUR — Burbank

Если же в городе располагаются несколько аэропортов, то можно использовать общий код. Например для Москвы это будет MOW.
Все верно. Я и не утверждал что это одно и тоже. Мы такими темпами можем скатиться к тому, что тот же West Hollywood тоже отдельный город, но мы то знаем что это по сути LA. Так что давайте лучше мир, дружба, жвачка :)
Ах, у вас там радиус-сервер? А почему имя «mail»?

Думаю радиус лучше вынести с почтового сервака при условиях описываемой виртуализации.

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

Сам же когда поднимали распределенную сеть, отсортировал офисы по удаленности от главного (без шансов на расширение) — получил индексные номера и по этим номерам начал именовать шлюзы island-12-gw (шлюз в главном офисе до второго), соответствено встречать его будет island-21-gw. В моем случае все было просто и понятно. Кто-то путался.
Когда в обиход вошли еще управляемые коммутаторы стало тяжелее, потому как в офисе их было от 1 до 5 штук и возникли проблемы с именованием, потому как роли у них были идентичны. пришлось нумеровать по номерам стоек и порядку установки.
Прочитай я этот пост двумя годами раньше — все было бы иначе.
Спасибо, хоть ныне мне это уже с большой долей вероятности и не пригодиться.
Топик скучен, автор явно читал мало литературы по cisco (иначе бы не стал писать этот текст). Почти в каждой книге есть упоминания об удобной политике по формированию hostname, соотв. те, кто держат более 100 узлов и так это знают, а другим, кто держит десяток, она и не нужна.
+замечания:
1) у ТС в явном виде не сказано, что следует избегать букв разного регистра в названиях узлов.
2) использование файла hosts (а так же resolv.conf и пр.) следует избегать, все псевдонимы имеет смысл задавать только на уровне маршрутизаторов.
Вас не затруднит ткнуть в соответствующее руководство циски? Особенно то, которое позволит ужить и маршрутизаторы, и сервера, и рабочие станции.
Насчёт Cisco не скажу, а по теме именования есть целая глава в The practice of system and network administration, причём там более обобщённый взгляд на namespace'ы в целом.
спасибо, добавлю к своему списку внеклассного чтения.
Недавно вышла и русская версия, весьма недурный перевод, читать можно.
> Насчёт Cisco не скажу, а по теме именования есть целая глава в The practice of system and network administration, причём там более обобщённый взгляд на namespace'ы в целом.

Вот именно что более обобщённый, по сути то же что и здесь.
Это хорошо или плохо, по комментарию как-то непонятно :)
Ну для меня это плохо — очевидные вещи, ничего нового, никаких конкретных предложений. А хотелось бы однозначно чёткой схемы именования, в которой имена были бы пусть плохочитаеыми (например представляющие из себя мешанину букв и цифр), пусть недостаточно инфоративными (указание географической и организационной принадлежности отбрасываем т.к. они могут менятся или быть неоднозначны, функциональная часть и подавно), но однозначными, чтобы вопрос как назвать хост не требовал ни секунды раздумий.
Ну, называйте их по uuid'ам. Будет гарантированно уникальное имя, чёткое, плохочитаемое и неудобное.
Ещё надо чтобы длинна была 15 символов и чтобы ну хоть какую-то информацию несло.
Очень интересно, где в литературе CISCO почитать конкретно про именование (да, не приходилось в ней сколько-нибудь углубляться, но иенно этот вопрос очень интересен). Приведите, пожалуйста, хотябы название книги.
Ну вообще именование — это довольно принципиальный вопрос.
Когда я работал в Дальсвязи, то мы использовали следующую схему именования:
[идентификатор филиала][телефонный идентификатор][тип ресурса]-[функциональный признак ресурса][порядковый номер ресурса в филиале]

Филиалы были такими:
Генеральная Дирекция HQ
Приморский P
Амурский A
Камчатский K
Магаданский M
Сахалинский S
Хабаровский H
ЕАО Е

Телефонный идентификатор позволял разграничивать населённые пункты, т.к. однозначен для них внутри региона (филиала)
Типы ресурсов были такие:
Сервер S
Рабочая станция W
Мобильный компьютер M
Принтер P
Терминал T
IP телефон F

Для серверов были следующие функциональные признаки:
Файловый FS
Почтовый (Exchange) EX
Почтовый (Lotus) LT
Кластер CL
Контроллер домена DC
Прокси сервер PX
Принт-сервер PR
SQL SQ
Oracle OR
SMS MS
Backup BC
ServiceDesk SD
HP NNM NM
HP OpenView OV
MS MOM MO
Cisco Works CW
Axapta AX
Boss Кадровик BK
Справочные системы (Гарант, Консультант+) SS
Tacacs TA
Radius RA
Сервер сертификатов CA
MS MIIS MI
Терминальный сервер TS
Временный cервер TM
Web cервер W3
Windows Server Update Services WU
Control Station CS
SMTP Relay / Proxy SR
Сервер безопасности SE

в принципе этого было достаточно в своё время.

Дальсвязь, как много в этом звуке, для сердца сахалинского слилось :)
Интересно! Является ли эта информация конфиденциальной? Или же её время вышло?
А может в отношении этих сведений в Дальсвязи введен режим коммерческой тайны? Вот я и поинтересовался — не разгласил ли он чего пока тут опытом обменивался.
Отличная статья.
После долгих размыщлений на эту тему пригли к решению «ГОРОД-ПОДРАЗДЕЛЕНИЕ-ТИПНОМЕР» коротко и ясно.

Пример:
  • Рабочая станция в корпоративном отделе в Новосибирске — NSK-CORP-WS01,
  • Виртуализированный контроллер домена в москве — MSK-VIRT07-DC02 (контроллер №2 на ESX-ноде №7),
  • Принтер в отделе продаж в Перми — PRM-SALE-PRINT02

и так можно продолжать бесконечно.
Для компаний с количеством хостов от 100-300 и более, думаю в самый раз.
Более крупные сети, думаю, имеет смысл дробить уже уровнями домена типа .nsk.corp.domain.ru и т.п.
А если неожиданно переедет виртуальная машина с одной ноды на другую?
Дапусть себе переезжает. vCenter для того и существует, что-бы облегчить менедмент всего этого зоопарка. Хост vCenter и есть нода, а за ним уже кластер из ESX-ов.
А если он между системами виртуализации переезжает?
Ну это редкость редкостная, и является уже глобальным перездом. Из одного филиала в другой и естественно у него сменится имя в любом случае. Не думаю, что найдутся админы (не берем во внимание хостеровир эксперементаторов) у которых хватит ума несколько нод в одном офисе поднимать.
А, то есть у вас привязка идёт к хосту vCenter, тогда понятно всё :)
UFO landed and left these words here
См первый же «очевидный» пример. На второй сотне начнёте путаться.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Согласен, деление в DNS по сервисам- это удобно. А вот изобретение сложных имен для компов только будет путать, удобнее все-же делить доменами 2-го,3-го...n-го уровня по географическому и функциональному назначению.
до тех пор, пока не сделаете shutdown не на том сервере…
как по мне, каждый называет хосты в соответствии со своими вкусовыми предпочтениями, и писать целую статью об этом — напрасная трата сил
У меня приятель называл сервера и рабочие станции названиями песен, которые слушал в данный момент.
Хотя не знаю, удобно ли гадать, что за тачка в сети — moment_of_peace или, например, fear_of_the_dark )

А статья да, хорошая, интересно почитать, но, к сожалению, вдрядли когда нибудь в будущем мне пригодится.
>Хотя не знаю, удобно ли гадать, что за тачка в сети — moment_of_peace или, например,
>fear_of_the_dark )

таких имён в DNS быть не может
в DNS, да, а вот в netbios — может. Хоть и придупредит система, что не корректное имя (винда например или OSX), но работать будет.
> таких имён в DNS быть не может

Если DNS полность соответствеует RFC, то не может.
А если это MicrosoftDNS, то по умолчанию там разрешены и такие корявые имена.
Тут вот выплывает на поверхность один вашный вопрос.
Статья об именовании узлов. Именование netbios/smb и разрешение их dns — хоть исопряженные вещи, но немного разные. И решаемые ими задачи — тоже различны по своему назначению. Согласитесь — hоstname и FQDN — немного разные вещи. Что же касается именования — ХОСТОВ, тут действительно, на вкус и цвет..., как говориться, а вот что касается dns — то на эту тему стоит, наверное, отдельную тему поднимать, так как назначение имени в DNS «именованием» назвать сложновато, на то он и Domain NS чтобы обслуживать хосты на уровне домена. К именованию хостов как таковых DNS, по сути, никакого отношения не имеет.

Так к чему это я все — о чем говорим-то, товариши. Просто я как-то немного дезориентирван комментами.
ну, если честно, виндовые имена для меня чуть второстепенны, речь про юникс. Но, в принципе, это же можно полностью применять и к виндам — в конце-концов машины в домене всё равно именуются линейно (если мы деревья не изобретаем, а обходимся узлами).
а присем тут ОС?
Я не о Домене MS AD Говорил, а о доменах, которые являют собой иерархию системы доменнных имён (DNS), что есть вотчина ICANN.
Ну, нетбиос вы сказали :)

Имена доменов — это имена доменов. К именам машин это может относиться, а может и нет, потому что основная цель, чтобы имя машины (в отрыве от доменов, доменных префиксов и т.д.) имело самостоятельный смысл. Это может быть оверкиллом, но это гарантирует, что вы видите, как называется сервер, а не кусаете мучительно губы за кривой domain suffix.
Об этом я и говорил комментарием выше
Поэтому и задал вопрос, о чем говорим то? Именование машин или все-же адресация? прояснить этот момент — необходимо, судя по генезу комментариев и вопросов.
Это имя машин. И для использования в доменной системе имён, и использования в качестве hostname компьютера.
Так. Вы о чем сейчас речь ведете?
Если мы говорим об именовании машин — это одно.
Если мы говорим об именовании на уровне A-записей, что не корректно называть «именованием хоста» — это другое.

Да можно и на уровне NS серверов разрулить все, но как Вы же сами сказали сказали — К именам машин это может относиться, а может нет… и, делая вывод из Ваших же слов, можно сказать, что это не гарантирует видимось и доступность сервера по имени.
Я же придерживаюсь той версии, что A-запись машины не говорит нам ничего о самом хосте.
Вот о чем Вам говорит мой хост sliderweb.ru. Да ни о чем он не говорит. на него прилеплено куча адресов и доменов.
Но у него есть понятное имя и по этому имени он доступен всегда и везде, не зависимо от DNS.

ЗЫ. здается мне что об одном и том же говорим.
Я считаю, что для любого hostname обязательно должно быть соответствующее A-имя. Хотя бы одно.

«Имя сайта» это несколько не то, что «имя узла». Может быть много A-записей, среди них могут быть прикладные (например, то, что отдаётся пользователю как имя сайта), а должны быть служебные, которые указывают на конкретные сервера, маршрутизаторы и т.д.). Светить ли их во внешнюю сеть — отдельный вопрос. Внутри оно должно быть. (Так же как PTR).
согласен.
но иногда имя узла = @ или вообще * (как у меня на хостинге).

Тут вопрос вы подняли довольно спорный. Есть оборудование, которе нельзя именовать кроме как через DNS (например некоторые управляемые свитчи или некоторые модели access point).

Универсального метода нет и быть не может.

Еще раз повторюсь, что статья отличная. Мне понравилась, но суть ее как-то размазана немного какраз по причине того, что Вы постарались разносторонне подойти к вопросу, который рассматриваться должен скорее индивидуально, так как методик именования узлов, а если говорить правильным языкаом «объектов инфраструктуры» (коими могут являться не только сетевое но и переферийное оборудование, доступное удаленно, но не имеющее прямых сетевых интерфейсов) — тьма-тьмущая. поэтому нужно было наверное задать какие-то направляющие/ограничивающие рамки рассуждений, иначе можно получить хаос (хоя и он тоже есть разновидность порядка), особенно на таком ресурсе как хабр.
Я не осуждаю, нет. просто мы с Вами говорили долго об одном и том-же заходя с разных сторон. а в итоге пришли к одному и тому-же. =)
Это всё хорошо и красиво пока не столкнётся с начальником IT безопасности.
Угу… и не надо голову ломать возможному злоумышленнику — who is who =)
Именно =)
Все имена должны быть безличными.

Хотя в большей степени это касается только больших, международных или гос. компаний.
Мне, порой, сложно давать короткие и, главное, понятные имена классам, методам, переменным…
UFO landed and left these words here
Ну, тут уже у кого-то промелькнул «bc», у меня на одной из работ тоже было такое сокращение.
сколько статей по код стайлу для прогеров и вот свершилось! есть одна для одминов
а переименование файлового сервера, на который у всех ссылки на конкретные файлы — катастрофа [Hint: в виндах есть DFS, в линуксе — CNAME в DNS]

В виндах тоже можно CNAME использовать, только придётся добавить алиас на самом сервере (для CIFS).
Кстати, в некоторых случаях города можно обозначать трёхбуквенным кодом IATA. Например, MOW — Москва, LED — Санкт-Петербург, OVB — Новосибирск, VVO — Владивосток и так далее.
советская власть стремится использовать свой классификатор. 77-москва.
А Королев и Долгопрудный — оба 50.
К сожалению, такой подход не обеспечивает уникальности в наименовании. В пределах одного региона может быть много повторяющихся адресов, различающихся лишь именем населенного пункта.
Про таблицу Менделеева.
Каждому элементу таблицы кроме уникального имени сопоставлено еще и три параметра: атомный номер, период и степень окисления. Можно сопоставить им некие свойства серверов и получить собственную периодическую таблицу серверов. Распечатать и повесить на стене для удобства пользования.
Степень окисления сервера? Отпусти меня, морская трава…
в нашей сети — простое решение, главное запомнить схему и знать условн. обозн. регионов

функция.филиал-регион.домен

пример:
core.north-msk.domain.ru
sw.south-spb.domain.ru

но конечно необходимо оптимизировать в зависимости от нужд
Это-то все понятно. А вот как именовать принтеры, чтобы можно было легко найти и понять, что это…
У нас по номеру помещения нумеровались.
порты можно называть по схеме:
номер узла — номер устройства — номер шасси — номер порта
н-р: 013-102-001-003
третий порт в 102 свитче на 013 узле (введение номера шасси актуально для модульных устройств).
Также можно расширить до города, страны и т.п.
любопытно, а сколько у топикстартера компов в хозяйстве, что подтолкнуло на столь основательную статью?
Калий и Кальций? :))
Нет, «нормальный» и «для экспериментов»
а на статью то сколько сподвигло?
таки таблица менделеева — отличная идея…
а то у пантеона греческих богов часто невыговариваемые имена.
таблицы Менделеева говорите…
недавно заметил что имена серверов promodj.ru названы в честь треков Fatboy Slim :)

dig -t ptr +short {100..255}.196.213.91.in-addr.arpa
rightnow.promodeejay.net.
rockafeller.promodeejay.net.
kingofsnake.promodeejay.net.
slashdotdash.promodeejay.net.
bodymovin.promodeejay.net.
marshall.promodeejay.net.
righthere.promodeejay.net.
yamama.promodeejay.net.
> Например, по элементам таблицы менделеева (кто делал трейс до яндекса, видел). Хватит на сотню с небольшим имён.

А я тут придумал использовать фэнтезийные (в стиле AD&D и Толкиена) названия нас. пунктов и имена собственные. Благо в Сети достаточно скриптов для их генерации, множество более-менее неограниченное. Минус — на слух записывать не очень удобно, зато можно тенгваром — на схемах прикольно выглядит :-).
Only those users with full accounts are able to leave comments. Log in, please.