Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 87
Толковая статься, я тоже над этой проблемой бился долго. В итоге остановился на виде ГОРОД-ИНФРАСТРУКТУРА-ТИП-НОМЕР
В избранное — однажды может пригодиться :)
Вот как раз алиас (в смысле CNAME) для mail строго недопустим (CNAME и MX'ы плохо дружат). В остальном, да. Причём (у меня это в разделе про псевдонимы есть) лучше даже короче.
Отдельные имена (и IP) для служб — это отдельный разговор.
Отдельные имена (и IP) для служб — это отдельный разговор.
ой. а расскажи пожалуйста поподробнее про «плохо дружат» пожалуйста!
Описание в RFC 974, RFC 1034
Для сопротивляющихся, разжёвано в RFC 1912:
Для сопротивляющихся, разжёвано в 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
Вам хорошо :) у вас город-… а у кого-то еще и страна-город-…
По поводу городов — удобно использовать IATA коды аэропортов. Они трехбуквенные и однозначные. Только вот msk в этом случае — это аэропорт на Багамах, а spb это штатовские «Virgin Islands».
Итого получается страна-город-улица(строение)-медиа-тип-назначение. Вот так и получаются всякие us-lax-ver-e-r1-core.
:)
По поводу городов — удобно использовать IATA коды аэропортов. Они трехбуквенные и однозначные. Только вот msk в этом случае — это аэропорт на Багамах, а spb это штатовские «Virgin Islands».
Итого получается страна-город-улица(строение)-медиа-тип-назначение. Вот так и получаются всякие us-lax-ver-e-r1-core.
:)
>По поводу городов — удобно использовать IATA коды аэропортов.
Далеко не всегда это удобно, поскольку в одной отдельно взятой области(крае, штате, ...) городов обычно куда больше, чем аэропортов, а в отдельно взятом городе может быть несколько аэропортов (хотя, вроде бы, в IATA кодах последнее предусмотрено, если не ошибаюсь — для мегаполисов есть общее название города, и есть коды для каждого аэропорта)
Далеко не всегда это удобно, поскольку в одной отдельно взятой области(крае, штате, ...) городов обычно куда больше, чем аэропортов, а в отдельно взятом городе может быть несколько аэропортов (хотя, вроде бы, в IATA кодах последнее предусмотрено, если не ошибаюсь — для мегаполисов есть общее название города, и есть коды для каждого аэропорта)
Вы совершенно правы. Изначально схема пришла из штатов. Там как раз, лучше по аэропорту, чем по городу. Ибо тот же LA может быть LAX (LA International) или BUR (Burbank). По сути, разные county, но тем не менее все тот же LA.
Тут наверное еще вот какой момент. Естетственно есть база всего сетевого оборудование, это может быть как Sharepoint, так и что-то самописное. Но. При поступлении, например, заявки в сетевую службу. У вас спросят, откуда вы звоните (страна, город). По этим данным отфильтруют и дальше найти из той оставшейся сотни-две активного железа найти по трем первым буквам или названию комплекса — совсем просто.
Резюмируя.
Вариант хоть и не идеален (минусы вы описали), но имеет место на существование в крупных международных структурах, потому как для вас — msk — это Москва, nnv — Нижний, nsk — Новосиб, а вот для индуса это с таким же успехом могут быть Минск, Нижневартовск, и Норильск. В данном случае именно однозначность и стандартизированность ставится во главу угла.
Тут наверное еще вот какой момент. Естетственно есть база всего сетевого оборудование, это может быть как Sharepoint, так и что-то самописное. Но. При поступлении, например, заявки в сетевую службу. У вас спросят, откуда вы звоните (страна, город). По этим данным отфильтруют и дальше найти из той оставшейся сотни-две активного железа найти по трем первым буквам или названию комплекса — совсем просто.
Резюмируя.
Вариант хоть и не идеален (минусы вы описали), но имеет место на существование в крупных международных структурах, потому как для вас — msk — это Москва, nnv — Нижний, nsk — Новосиб, а вот для индуса это с таким же успехом могут быть Минск, Нижневартовск, и Норильск. В данном случае именно однозначность и стандартизированность ставится во главу угла.
Ах, у вас там радиус-сервер? А почему имя «mail»?
Думаю радиус лучше вынести с почтового сервака при условиях описываемой виртуализации.
Первую часть про сервера читал как пол себя. но когда перешло к сетевым железкам меня накрыло и я вспомнил нашего провайдера, который всех кошек по географии и именует.
Сам же когда поднимали распределенную сеть, отсортировал офисы по удаленности от главного (без шансов на расширение) — получил индексные номера и по этим номерам начал именовать шлюзы island-12-gw (шлюз в главном офисе до второго), соответствено встречать его будет island-21-gw. В моем случае все было просто и понятно. Кто-то путался.
Когда в обиход вошли еще управляемые коммутаторы стало тяжелее, потому как в офисе их было от 1 до 5 штук и возникли проблемы с именованием, потому как роли у них были идентичны. пришлось нумеровать по номерам стоек и порядку установки.
Прочитай я этот пост двумя годами раньше — все было бы иначе.
Спасибо, хоть ныне мне это уже с большой долей вероятности и не пригодиться.
Топик скучен, автор явно читал мало литературы по cisco (иначе бы не стал писать этот текст). Почти в каждой книге есть упоминания об удобной политике по формированию hostname, соотв. те, кто держат более 100 узлов и так это знают, а другим, кто держит десяток, она и не нужна.
+замечания:
1) у ТС в явном виде не сказано, что следует избегать букв разного регистра в названиях узлов.
2) использование файла hosts (а так же resolv.conf и пр.) следует избегать, все псевдонимы имеет смысл задавать только на уровне маршрутизаторов.
+замечания:
1) у ТС в явном виде не сказано, что следует избегать букв разного регистра в названиях узлов.
2) использование файла hosts (а так же resolv.conf и пр.) следует избегать, все псевдонимы имеет смысл задавать только на уровне маршрутизаторов.
Вас не затруднит ткнуть в соответствующее руководство циски? Особенно то, которое позволит ужить и маршрутизаторы, и сервера, и рабочие станции.
спасибо, добавлю к своему списку внеклассного чтения.
> Насчёт Cisco не скажу, а по теме именования есть целая глава в The practice of system and network administration, причём там более обобщённый взгляд на namespace'ы в целом.
Вот именно что более обобщённый, по сути то же что и здесь.
Вот именно что более обобщённый, по сути то же что и здесь.
Ну для меня это плохо — очевидные вещи, ничего нового, никаких конкретных предложений. А хотелось бы однозначно чёткой схемы именования, в которой имена были бы пусть плохочитаеыми (например представляющие из себя мешанину букв и цифр), пусть недостаточно инфоративными (указание географической и организационной принадлежности отбрасываем т.к. они могут менятся или быть неоднозначны, функциональная часть и подавно), но однозначными, чтобы вопрос как назвать хост не требовал ни секунды раздумий.
Очень интересно, где в литературе 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
в принципе этого было достаточно в своё время.
Когда я работал в Дальсвязи, то мы использовали следующую схему именования:
[идентификатор филиала][телефонный идентификатор][тип ресурса]-[функциональный признак ресурса][порядковый номер ресурса в филиале]
Филиалы были такими:
Генеральная Дирекция 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
в принципе этого было достаточно в своё время.
Отличная статья.
После долгих размыщлений на эту тему пригли к решению «ГОРОД-ПОДРАЗДЕЛЕНИЕ-ТИПНОМЕР» коротко и ясно.
Пример:
и так можно продолжать бесконечно.
Для компаний с количеством хостов от 100-300 и более, думаю в самый раз.
Более крупные сети, думаю, имеет смысл дробить уже уровнями домена типа .nsk.corp.domain.ru и т.п.
После долгих размыщлений на эту тему пригли к решению «ГОРОД-ПОДРАЗДЕЛЕНИЕ-ТИПНОМЕР» коротко и ясно.
Пример:
- Рабочая станция в корпоративном отделе в Новосибирске — NSK-CORP-WS01,
- Виртуализированный контроллер домена в москве — MSK-VIRT07-DC02 (контроллер №2 на ESX-ноде №7),
- Принтер в отделе продаж в Перми — PRM-SALE-PRINT02
и так можно продолжать бесконечно.
Для компаний с количеством хостов от 100-300 и более, думаю в самый раз.
Более крупные сети, думаю, имеет смысл дробить уже уровнями домена типа .nsk.corp.domain.ru и т.п.
как по мне, каждый называет хосты в соответствии со своими вкусовыми предпочтениями, и писать целую статью об этом — напрасная трата сил
Суровые сети у вас, однозначно :)
Тут вот выплывает на поверхность один вашный вопрос.
Статья об именовании узлов. Именование netbios/smb и разрешение их dns — хоть исопряженные вещи, но немного разные. И решаемые ими задачи — тоже различны по своему назначению. Согласитесь — hоstname и FQDN — немного разные вещи. Что же касается именования — ХОСТОВ, тут действительно, на вкус и цвет..., как говориться, а вот что касается dns — то на эту тему стоит, наверное, отдельную тему поднимать, так как назначение имени в DNS «именованием» назвать сложновато, на то он и Domain NS чтобы обслуживать хосты на уровне домена. К именованию хостов как таковых DNS, по сути, никакого отношения не имеет.
Так к чему это я все — о чем говорим-то, товариши. Просто я как-то немного дезориентирван комментами.
Статья об именовании узлов. Именование netbios/smb и разрешение их dns — хоть исопряженные вещи, но немного разные. И решаемые ими задачи — тоже различны по своему назначению. Согласитесь — hоstname и FQDN — немного разные вещи. Что же касается именования — ХОСТОВ, тут действительно, на вкус и цвет..., как говориться, а вот что касается dns — то на эту тему стоит, наверное, отдельную тему поднимать, так как назначение имени в DNS «именованием» назвать сложновато, на то он и Domain NS чтобы обслуживать хосты на уровне домена. К именованию хостов как таковых DNS, по сути, никакого отношения не имеет.
Так к чему это я все — о чем говорим-то, товариши. Просто я как-то немного дезориентирван комментами.
ну, если честно, виндовые имена для меня чуть второстепенны, речь про юникс. Но, в принципе, это же можно полностью применять и к виндам — в конце-концов машины в домене всё равно именуются линейно (если мы деревья не изобретаем, а обходимся узлами).
а присем тут ОС?
Я не о Домене MS AD Говорил, а о доменах, которые являют собой иерархию системы доменнных имён (DNS), что есть вотчина ICANN.
Я не о Домене MS AD Говорил, а о доменах, которые являют собой иерархию системы доменнных имён (DNS), что есть вотчина ICANN.
Ну, нетбиос вы сказали :)
Имена доменов — это имена доменов. К именам машин это может относиться, а может и нет, потому что основная цель, чтобы имя машины (в отрыве от доменов, доменных префиксов и т.д.) имело самостоятельный смысл. Это может быть оверкиллом, но это гарантирует, что вы видите, как называется сервер, а не кусаете мучительно губы за кривой domain suffix.
Имена доменов — это имена доменов. К именам машин это может относиться, а может и нет, потому что основная цель, чтобы имя машины (в отрыве от доменов, доменных префиксов и т.д.) имело самостоятельный смысл. Это может быть оверкиллом, но это гарантирует, что вы видите, как называется сервер, а не кусаете мучительно губы за кривой domain suffix.
Об этом я и говорил комментарием выше
Поэтому и задал вопрос, о чем говорим то? Именование машин или все-же адресация? прояснить этот момент — необходимо, судя по генезу комментариев и вопросов.
Поэтому и задал вопрос, о чем говорим то? Именование машин или все-же адресация? прояснить этот момент — необходимо, судя по генезу комментариев и вопросов.
Это имя машин. И для использования в доменной системе имён, и использования в качестве hostname компьютера.
Так. Вы о чем сейчас речь ведете?
Если мы говорим об именовании машин — это одно.
Если мы говорим об именовании на уровне A-записей, что не корректно называть «именованием хоста» — это другое.
Да можно и на уровне NS серверов разрулить все, но как Вы же сами сказали сказали — К именам машин это может относиться, а может нет… и, делая вывод из Ваших же слов, можно сказать, что это не гарантирует видимось и доступность сервера по имени.
Я же придерживаюсь той версии, что A-запись машины не говорит нам ничего о самом хосте.
Вот о чем Вам говорит мой хост sliderweb.ru. Да ни о чем он не говорит. на него прилеплено куча адресов и доменов.
Но у него есть понятное имя и по этому имени он доступен всегда и везде, не зависимо от DNS.
ЗЫ. здается мне что об одном и том же говорим.
Если мы говорим об именовании машин — это одно.
Если мы говорим об именовании на уровне A-записей, что не корректно называть «именованием хоста» — это другое.
Да можно и на уровне NS серверов разрулить все, но как Вы же сами сказали сказали — К именам машин это может относиться, а может нет… и, делая вывод из Ваших же слов, можно сказать, что это не гарантирует видимось и доступность сервера по имени.
Я же придерживаюсь той версии, что A-запись машины не говорит нам ничего о самом хосте.
Вот о чем Вам говорит мой хост sliderweb.ru. Да ни о чем он не говорит. на него прилеплено куча адресов и доменов.
Но у него есть понятное имя и по этому имени он доступен всегда и везде, не зависимо от DNS.
ЗЫ. здается мне что об одном и том же говорим.
Я считаю, что для любого hostname обязательно должно быть соответствующее A-имя. Хотя бы одно.
«Имя сайта» это несколько не то, что «имя узла». Может быть много A-записей, среди них могут быть прикладные (например, то, что отдаётся пользователю как имя сайта), а должны быть служебные, которые указывают на конкретные сервера, маршрутизаторы и т.д.). Светить ли их во внешнюю сеть — отдельный вопрос. Внутри оно должно быть. (Так же как PTR).
«Имя сайта» это несколько не то, что «имя узла». Может быть много A-записей, среди них могут быть прикладные (например, то, что отдаётся пользователю как имя сайта), а должны быть служебные, которые указывают на конкретные сервера, маршрутизаторы и т.д.). Светить ли их во внешнюю сеть — отдельный вопрос. Внутри оно должно быть. (Так же как PTR).
согласен.
но иногда имя узла = @ или вообще * (как у меня на хостинге).
Тут вопрос вы подняли довольно спорный. Есть оборудование, которе нельзя именовать кроме как через DNS (например некоторые управляемые свитчи или некоторые модели access point).
Универсального метода нет и быть не может.
Еще раз повторюсь, что статья отличная. Мне понравилась, но суть ее как-то размазана немного какраз по причине того, что Вы постарались разносторонне подойти к вопросу, который рассматриваться должен скорее индивидуально, так как методик именования узлов, а если говорить правильным языкаом «объектов инфраструктуры» (коими могут являться не только сетевое но и переферийное оборудование, доступное удаленно, но не имеющее прямых сетевых интерфейсов) — тьма-тьмущая. поэтому нужно было наверное задать какие-то направляющие/ограничивающие рамки рассуждений, иначе можно получить хаос (хоя и он тоже есть разновидность порядка), особенно на таком ресурсе как хабр.
Я не осуждаю, нет. просто мы с Вами говорили долго об одном и том-же заходя с разных сторон. а в итоге пришли к одному и тому-же. =)
но иногда имя узла = @ или вообще * (как у меня на хостинге).
Тут вопрос вы подняли довольно спорный. Есть оборудование, которе нельзя именовать кроме как через DNS (например некоторые управляемые свитчи или некоторые модели access point).
Универсального метода нет и быть не может.
Еще раз повторюсь, что статья отличная. Мне понравилась, но суть ее как-то размазана немного какраз по причине того, что Вы постарались разносторонне подойти к вопросу, который рассматриваться должен скорее индивидуально, так как методик именования узлов, а если говорить правильным языкаом «объектов инфраструктуры» (коими могут являться не только сетевое но и переферийное оборудование, доступное удаленно, но не имеющее прямых сетевых интерфейсов) — тьма-тьмущая. поэтому нужно было наверное задать какие-то направляющие/ограничивающие рамки рассуждений, иначе можно получить хаос (хоя и он тоже есть разновидность порядка), особенно на таком ресурсе как хабр.
Я не осуждаю, нет. просто мы с Вами говорили долго об одном и том-же заходя с разных сторон. а в итоге пришли к одному и тому-же. =)
Это всё хорошо и красиво пока не столкнётся с начальником IT безопасности.
Мне, порой, сложно давать короткие и, главное, понятные имена классам, методам, переменным…
сколько статей по код стайлу для прогеров и вот свершилось! есть одна для одминов
а переименование файлового сервера, на который у всех ссылки на конкретные файлы — катастрофа [Hint: в виндах есть DFS, в линуксе — CNAME в DNS]
В виндах тоже можно CNAME использовать, только придётся добавить алиас на самом сервере (для CIFS).
Кстати, в некоторых случаях города можно обозначать трёхбуквенным кодом IATA. Например, MOW — Москва, LED — Санкт-Петербург, OVB — Новосибирск, VVO — Владивосток и так далее.
советская власть стремится использовать свой классификатор. 77-москва.
Про таблицу Менделеева.
Каждому элементу таблицы кроме уникального имени сопоставлено еще и три параметра: атомный номер, период и степень окисления. Можно сопоставить им некие свойства серверов и получить собственную периодическую таблицу серверов. Распечатать и повесить на стене для удобства пользования.
Каждому элементу таблицы кроме уникального имени сопоставлено еще и три параметра: атомный номер, период и степень окисления. Можно сопоставить им некие свойства серверов и получить собственную периодическую таблицу серверов. Распечатать и повесить на стене для удобства пользования.
в нашей сети — простое решение, главное запомнить схему и знать условн. обозн. регионов
функция.филиал-регион.домен
пример:
core.north-msk.domain.ru
sw.south-spb.domain.ru
но конечно необходимо оптимизировать в зависимости от нужд
функция.филиал-регион.домен
пример:
core.north-msk.domain.ru
sw.south-spb.domain.ru
но конечно необходимо оптимизировать в зависимости от нужд
Это-то все понятно. А вот как именовать принтеры, чтобы можно было легко найти и понять, что это…
порты можно называть по схеме:
номер узла — номер устройства — номер шасси — номер порта
н-р: 013-102-001-003
третий порт в 102 свитче на 013 узле (введение номера шасси актуально для модульных устройств).
Также можно расширить до города, страны и т.п.
номер узла — номер устройства — номер шасси — номер порта
н-р: 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.
недавно заметил что имена серверов 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 и Толкиена) названия нас. пунктов и имена собственные. Благо в Сети достаточно скриптов для их генерации, множество более-менее неограниченное. Минус — на слух записывать не очень удобно, зато можно тенгваром — на схемах прикольно выглядит :-).
А я тут придумал использовать фэнтезийные (в стиле AD&D и Толкиена) названия нас. пунктов и имена собственные. Благо в Сети достаточно скриптов для их генерации, множество более-менее неограниченное. Минус — на слух записывать не очень удобно, зато можно тенгваром — на схемах прикольно выглядит :-).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Именование узлов в сети