Имя сервера в компьютерной сети

Именование узлов в сети

Хочу поднять вопрос, который, как мне кажется, никто не рассматривал ранее системно. Вопрос звучит так:

как называть узлы и интерфейсы узлов в сети?

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

Простые пути

Сначала рассмотрим простые решения, которые приходят первыми в голову.

Называть их по именам собственным

Например, по элементам таблицы менделеева (кто делал трейс до яндекса, видел). Хватит на сотню с небольшим имён. Потом будет интересно читать в логах, что Helium reject mail from potassium. Плюс этого — есть готовый набор аббревиатур для коротких алиасов, и он однозначен. Аналогично можно выбрать, например, страны. Или города. Или ещё какое-то множество с именами.

Минус этого вполне понятен: глядя на имя сервера невозможно понять, что он делает. Плюс — имена ясные, запоминаемые, различимые. Ясно, что мы кальций с калием никогда не перепутаем. Никогда.

Называть их по номерам

Например, fsbk3333, fsbk32232… Вполне себе имена. Если сервера однородны. А если нет? Помнить, что «333» это почтовый сервер, а 5622 — это out-of-band интерфейс запасного vpn-шлюза… Может, лучше по IP сразу?

Называть их по ролям

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

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

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

LDAP shall rule!

Нет ничего более отличительного и однозначного, чем OU=MSK, OU=«Main Branch», OU=labs, CN=«intranet web server»… Особенно, если это печатать руками каждый раз. Плюс, это не очень хорошо совместимо с DNS. Если только не печатать каждый раз «intranet-web-server.labs.mainbranch.msk.our_domain».

Общее построение задачи

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

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

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

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

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

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

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

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

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

Географическая часть

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

Административное подичнение

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

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

Ещё одним важным «но» является то, что раскрытие административной принадлежности сервера посторонним людям может быть самым болезенным из всего, что говорит имя компьютера постороним лицам. 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.

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

Многоголовость

Если у маршрутизатора 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

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

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

1. nsk-hd-mf-st-11-2
2. nskhd-mfst-11-2
3. nsk-hdmfst-11-2
4. nskhd-mfst11-2
5. 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? Разумеется, это имена только для «внутреннего» употребления, их не следует анонсировать наружу или использовать для конфигураций, в которых могут меняться используемые сервера.

Как планировать название?

1. Определитесь с размером нумерации. Возможно, всё обойдётся s1-s5 для серверов и парочкой устройств r1-r2
2. Выпишите все существующие названия и аббревиатуры, попытайтесь продумать их на хотя бы пол-года в будущее и представьте себе появление такого же, но в другом здании.
3. Определитесь, можете ли вы переименовывать устройства? Маршрутизатор можно переименовать, переименование почтового сервера уже тяжеловато, переименование контроллера домена может быть проблемой, а переименование файлового сервера, на который у всех ссылки на конкретные файлы — катастрофа [Hint: в виндах есть DFS, в линуксе — CNAME в DNS]
4. Сделайте пару десятков названий, посмотрите, читаемы ли они (т.е. понятно ли «что это»), попробуйте это напечатать
5. Проверьте, нет ли там конфиденциальной информации (лучше уточнить у начальства, что есть «конфиденциальная» — имя фирмы, город, адрес, номер филиала)

Источник