Источник - http://brj.pp.ru/wiki/isp/ptrs

См. также:

• http://citrin.ru/net:ptrs
• http://wiki.rsu.edu.ru/index.php/Правила_именования_записей_в_ДНС_для_маршрутизаторов_и_коммутаторов

Для начала обрисую суть проблемы: когда у вас 2-3-5-10 серверов, то их названия, адреса и т.д. вы быстро запоминаете, и особой путаницы они не вызывают. Но если у вас несколько тысяч серверов (добавим к реальным ещё виртуальные), если у вашего маршрутизатора несколько сотен реальных или виртуальных (в виланах) интерфейсов, каждому из которых нужно дать имя (хотя бы для PTR/A записей в DNS), когда у вас есть интерфейсы для конфигурирования коммутаторов, принт-серверов, сетевых принтеров… В этих условиях нужно реально садиться и думать, как их называть. Лучше садиться думать до того, как начали называть, чем после.

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

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

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

Ещё большей проблемой будет наличие деления по отделам, этажам, зданиям, городам, фирмам и т.д. Выяснять, что webserver12 — это сервер с пресидами для рабочих станций в здании администрации в Перми, а webserver22 — интравеб-сервер с корпоративной CMS в головном офисе тяжело. Да и печатать такие названия тоже тяжеловато.

Перейдём теперь к рассмотрению задачи в общем виде.

Общие требования:

1. Сохранение разумного размера имени
2. Мнемоничность названия
3. Хранение данных в hostname, без учёта доменной составляющей. Это нужно для того, чтобы находясь за консолью хоста, видеть его имя целиком, без необходимости смотреть на DNS-суффиксы.

Специфичные требования:

1. Географическое положение
2. Административное подчинение
3. Функциональная роль
4. Тип (хост может быть компьютером, а может быть специализированной железкой)
5. Номер, в случае группы идентичных хостов
6. Указание на виртуализированность или иные особые отметки (например, стоечное железо или нет)

Понятно, что специфичные требования могут быть во-первых расширены (например, в случае сложной административной организации сети, само кодирование административного подчинения, может быть весьма и весьма сложным, например, если речь идёт о… «группе компаний», с подразделениями в каждой с относительной автономности; аналогично можно говорить и о других полях — географическом, фунциональном…)

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

Однако, в общем случае, мы можем остановиться на вышеприведённом списке.

Теперь следующие два вопроса: какого размера должна быть каждая часть; как эти части должны разделяться? И третий вопрос: могут ли части имени иметь разную длину или они должны быть строго фиксированными?

Начнём с длины: database вполне укладывается в 'db', а terminal server в 'ts', то закодировать в две буквы, например, 'backup' уже немного сложно, получится произвольная необщеупотребимая аббревиатура, которая может наложиться на другие сокращения. Аналогично касается и географических названий. Допустим, у вас филиалы на каждой из линий Васильевского острова. Допустим, вы кодируете их двумя буквами. l4 — четвёртая линия, l8 — восьмая линия… А 17 линия как? А завтра у вас будут филиалы на станциях метро «Московские ворота», «Московская», ещё филиал просто «на Московском» и ещё филиал в Москве. Загонять себя в прокрустово ложе жёсткой длины имени, ИМХО, не разумно.

Далее, какими должны быть названия? Очевидно: наменьшими из возможных, но в «естественном» сокращении. Даже если у вас нет иных филиалов на «м», сокращать Москву до «m» (вместо msk) — это снижать мнемоничность и читаемость названия.

В принципе, тут довольно просто, ибо искусство аббревиатур для географических названий давно освоено и публично известно. Двухбуквенные коды штатов в США, трёхбуквенные названия городов в России (из географических доменов), двухбуквенные коды стран (из ISO)… Аналогично могут сокращаться и названия улиц, хотя тут уже придётся проявить некоторую сообразительность (см выше пример про линии Васильевского острова).

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

Итого получается страна-город-улица(строение)-медиа-тип-назначение. Вот так и получаются всякие us-lax-ver-e-r1-core.

Вопрос административного подчинения чуть более сложен. Полное название отдела/филиала может быть либо неудобочитаемым, либо малознакомым. Возможно, что об этой проблеме просто никто не думал. У банка могут быть отделения, и у отделений будут номера. Но как вы назовёте сервера в промежуточной серверной, которая совсем не «отделение банка»?

Наверное, самый болезенный вопрос: использовать ли транслит или перевод? Пусть каждый это решит для себя сам (хотя я терпеть не могу транслит).

Ещё одним важным «но» является то, что раскрытие административной принадлежности сервера посторонним людям может быть самым болезенным из всего, что говорит имя компьютера постороним лицам. msk-yukos-acc-12 — явно не то имя, которое хочется показывать окружающим.

Никогда не закладывайтесь на «это снаружи никто не увидит». Вы не знаете, где и кто увидит фрагмент письма (с заголовками о пересылке), сообщение сервера о том, что он не может связаться с SQL или ещё какой-то глупый ошмёток информации, который был бы бесполезен, если бы там не фигурировали столь подробные имена серверов…

Далее, о функциональной роли. Мне кажется, неверным было бы тут писать название протокола основного сервиса хотя такой соблазн всё-таки возникает. Правильнее было бы говорить именно о роли (заодно, в этот момент, можно подумать о том, не оказывается ли слишком много в компании завязано на один сервер).

Примеры: вместо www-сервера мы можем сделать 'pa' (public access) или 'ea' (external access) сервер (где отлично будет смотреться и FTP-сервер). Вместо proxy мы можем назвать его ag (application gateway), куда, кстати, весьма логично впишется и промежуточный почтовый релей. В то же самое время, для сереверов, которым по наилучшим практикам, не следует назначать иные роли, наверное, можно позволить называться по имени основной и единственной функции: DC для контроллера домена, EX — для exchange'а, SL для выделенного сервера syslog.

Отдельно о маршрутизаторах. Какая основная роль у маршрутизатора? Маршрутизировать, маршрутизировать, маршрутизировать! Хотя, на самом деле, если хорошо присмотреться, то роли у маршрутизаторов обычно даже более выпуклые, чем у серверов. Например, практически в любой сети есть шлюз (gw) обычно есть core level (cl или cr — core router), в сколь-либо крупной сети dl (distribution level) и al (access level). Вероятнее всего (в условиях филиалов) есть vpn-маршрутизаторы (которые network to network) — vpn им так и просится в название. А вот тем, кто терминирует point to network соединения, лучше давать название не 'vpn' (так как полноценных сетей тут не особо), а, например, ra (remote access). Дополнительно, суффикс -GW предлагает использовать RFC 952.

Если у маршрутизатора 30 разных сетей, 30 разными IP-адресами, то каждый из них должен иметь своё обратное имя. Здесь есть очередной выбор: либо мы вкладываем в этот номер смысл, либо нумеруем подряд. Отдельно, наверное, стоит выделять внешние интерфейсы (на граничных маршрутизаторах), внутренние и мостовые интерфейсы (br) в случае долгих линков (собственная оптика, виртуальные интерфейсы в VPN'е, просто линки между зданиями).

Не стоит недооценивать важность именования рабочих станций. Эти имена видны в заголовках SMTP (я как-то очень смеялся, когда мне пришло письмо в ответ на резюме с именем рабочей станции (по PTR'у) tupayasuka.domain.ru, cама рабочая станция считала, что называется komputer). Что нужно от имени рабочей станции? В отличие от сервера, ей не нужна многоголовость и функциональная роль, так что номер — вполне достаточно. Если есть разные типы станций (тонкие клиенты, винды, линухи) — то, возможно, упоминание об этом. Ну и географическое положение, разумеется.

Отдельно нужно учитывать наличие ноутбуков сотрудников, на которых они «сами себе админы» — разнообразие в названиях там будет редкостное…

Нужен ли разделитель в имени? Давайте сравним:

• mskmainac012
• spbnpcl-02
• msk-main-ac-012
• spb-np-cl-02

Я думаю, ответ очевиден. О символе. У нас не особо много вариантов:

• точка — зарезервирована за DNS
• знак подчёркивания — не полностью совместим с DNS, при печати нужно нажимать шифт
• двоеточие — непривычно, несовместимо с DNS

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

Теперь о том, сколько разделителей? Допустим, что у нас очень крупная компания, в которой очень много айтишного железа.

Примерный состав имени: nsk (Новосибирск), hd (от head), mf (от manufacture, производственные помещения), st (storage, хранилище), 11 (одиннадцатый однотипный сервер), второй интерфейс (из трёх, два идут к коммутаторам для резервирования, один — для headbeat'ов в кластере).

Варианты:

• nsk-hd-mf-st-11-2
• nskhd-mfst-11-2
• nsk-hdmfst-11-2
• nskhd-mfst11-2
• nskhdmfst11-2

Лично мне нравится предпоследний. Он всё-таки охватен по размеру каждой части, плюс, у него разделена география (nsk+hd — место в географическом смысле, mf+st — точное место (в рамках офиса) и примерная роль)

Моменты, которые следует учитывать: вероятность географической миграции (глупо называть сервер msk-…, если он будет мотаться между Амстердамом и Хельсинки); наличие привязок к инфраструктуре (например, к канальному сегменту при наличии каких-то L2 приложений (vlan'ы, pppoe, arp proxy)).

В принципе, я (для себя) остановился на использовании буквы 'h' (host system) для хостов и 'v' для гвестов (виртуальных машин). Например, v-mf11, мигрирующий между nskhd-hx1 nskhd-hx15 (догадайтесь сами, на чём оно работает).

Ещё одной интересной вещью в работе могут быть локальные псевдонимы. Если какие-то сервера (оборудование) замкнуто (например, группа из серверов, решающая локальную задачу), то имеет смысл дать им короткие имена. Чтобы не напрягаться с DNS (который может быть при этом совсем в чужом административном управлении), возможно, файл hosts окажется очень даже к месту (да, этот файл создавался не только для vkontakte/odnoclassniki). Например, если есть сервер-хранилище, пара контроллеров и сервер отчётов, то почему бы их (в рамках своей группы) не назвать stor, ctl1, ctl2, rep? Разумеется, это имена только для «внутреннего» употребления, их не следует анонсировать наружу или использовать для конфигураций, в которых могут меняться используемые сервера.

Определитесь с размером нумерации. Возможно, всё обойдётся s1-s5 для серверов и парочкой устройств r1-r2 Выпишите все существующие названия и аббревиатуры, попытайтесь продумать их на хотя бы пол-года в будущее и представьте себе появление такого же, но в другом здании.

Определитесь, можете ли вы переименовывать устройства? Маршрутизатор можно переименовать, переименование почтового сервера уже тяжеловато, переименование контроллера домена может быть проблемой, а переименование файлового сервера, на который у всех ссылки на конкретные файлы — катастрофа [Hint: в виндах есть DFS, в линуксе — CNAME в DNS]

Сделайте пару десятков названий, посмотрите, читаемы ли они (т.е. понятно ли «что это»), попробуйте это напечатать.

Проверьте, нет ли там конфиденциальной информации (лучше уточнить у начальства, что есть «конфиденциальная» — имя фирмы, город, адрес, номер филиала)

От себя замечу, что названия стоит давать не только умным железкам, но и тупым (ежели таковые в вашей сети ещё есть) — иногда нужно попросить перезагрузить / выключить / включить «вот тот коммутатор», а какой из них «тот»? Наличие на нём лычки msk-al-12 сильно увеличит точность выполнения просьбы.

Преимущества данной схемы:

• Каждое устройство имеет короткое имя которое можно быстро набрать в консоли
• По имени устройства легко определить назначение (тип) устройства и его расположение
• Имя зависит от функции выполняемой устройством, а не от модели/производителя и при замере коммутатора AT на Cisco не нужно ничего переименовывать в DNS и запоминать новое название

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

В общем виде имя выглядит так:

[ интерфейс ] . обозначение_устройства . точка_присутствия .example.ru

Точки присутствия называются по такой схеме - краткое наименование города и номер точки в этом городе, например msk3 - 3-я точка в г. Москва, nog1 - 1-я точка в г. Ногинск и т. д. Список точек присутствия с адресами, контактными телефонами и т. п. удобно держать в wiki.

Обозначения устройства:

• br - border router, пограничный маршрутизатор (связан по BGP с другими AS).
• gw - gateway, маршрутизатор к которому подключены клиенты и на котором осуществляется NAT для них.
• rt - router, обычный маршрутизатор внутри сети.
• sw - switch, коммутатор 2-го уровня. Например Catalyst 2950
• sr - swithch-router, коммутатор 3-го уровня, например Catalyst 3550/3750
• as - Access Server (например, модемный пул на базе Cisco AS53xx)
• ap - wifi access point, точка доступа
• esx - VmWare ESXi (например, холодный аппаратный HV сама железка)
• srv - Server ESXi (например, сервер. пофигу физический или виртуальный)

Этот список можно продолжить.

Для маршрутизаторов еще добавляется обозначение интерфейса. Если это Loopback то он не указывается.

Обозначение интерфейса приближено к тому, что есть на маршрутизаторе.

Например для Cisco

• fa-0-0 - FastEthernet0/0
• e-2-0 - Ethernet2/0

Для FreeBSD так и пишем как есть - vlan5, fxp0. если используются интерфейсы вида em0.99 то их пишем как em0-99

Примеры:

• e-2-2.br1.msk1.example.ru - ip на интерфейсе Ethernet2/2 1-го пограничного маршрутизатора на точке msk1
• br1.msk1.example.ru - ip на Loopback того же маршрутизатора.
• sw2.msk3.example.ru - 2-й коммутатор на точке присутствия msk3

Части названия удобно разделять именно точкой а не дефисом, чтобы было четко видно где кончается наименование интерфейса и начинается наименования маршрутизатора. Имя вида e-2-2-br1-msk1 читается хуже.

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

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

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

Любая сеть /24 распиливается следующим образом:

1. 0-10 - маршрутизаторы, коммутаторы точки доступа и т.д.
2. 10-40 - серверы
3. 40-60 - принтеры / сканеры / мфу
4. 60-160 - стационарные рабочие станции, ноутбуки
5. 160-199 - мобильные / временные пользователи. свободное пространство.
6. 200 - резерв для любого неведанного оборудования с езернатами