Технический нейминг серверов. По какому принципу называть сервера?

Question

[Алексей Арх]

Хочу поразмышлять и послушать ваш опыт.

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

Но мне кажется такие слова не очень подходят. Например города можно неосознанно ассоциировать с географическими координатами, а сервер "Москва" это просто название, он не стоит физически тут, может быть путаница. Например если это часть CDN. И так можно к любому слову прикопаться. Например ты против курения, а твои проекты лежат на сервере winston.

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

Идея
Самый короткий вариант нейминга у меня получился 2х символьный.
Например (a0.example.com, b9.example.com, xz.example.com)
Суть в том, что надо нарисовать таблицу по типу шахмат или морского боя или в экселе.
В таблице будут стобцы от A до Z и поля 0 - 9 - A - Z


В такой таблице видно какие сервера заняты, какие свободны. Если заполнять их по порядку, то можно понять какие новые, какие старые (a0, a1, a2, ...)

Если человек работает с сотней серверов, то он не запомнит их даже если будет называть их именами родственников.
Ему в любом случае понадобится какой то wiki.
Если работает с парочкой, то C1 и B6 запомнятся не хуже имён своих родителей.

А если написать простенькую программу, которая отображает эту таблицу, в которой можно создавать проекты и привязывать туда сервера и раздавать права пользователям на доступ к проектам, то это вообще красота мне кажется.

Суть вопроса
Какую методику используете вы?
Может я изобретаю колесо?
Может есть уже даже софт специальный?
Или в этом подходе какая то принципиальная ошибка, подводные камни которой уже набили вам шишек?
Поделитесь опытом. Думаю многим будет полезно почитать холивар на эту тему.

Comments

[Валентин]

Обычно в имя зашивают какой-то принцип, причём понятный не только двум админам из отдела, но и монтёрам, безопасникам, аудиту и тд. Хорошо бы, чтобы имя ассоциировалось с географией или зоной ответственности, сервер однозначно идентифицировался по номеру (проще говорить по телефону, и на бирках можно сократить название). Например: krv-srv-010-monitor01 - сервер в Кирове десятый по счету с целью мониторинга.

[shurshur]

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

Например, у моего работодателя все сервера имели красивые трёхбуквенные названия (bux, dix, kex итд), а виртуалки на них (точнее зоны Solaris) уже именовались z[назначение][номер]. По мере роста концепция поменялась, теперь сервера именуются [буква]XXXX, где XXXX - инвентарный номер, а буква отражает общее назначение (например, b - балансер, v - сервер с виртуалками, k - нода kubernetes). Предлагали ещё добавлять в конце букву с обозначением датацентра, но это не прижилось, тем более сервера могут переезжать с места на место, а физическое размещение в основном нужно знать только выделенному админу по железякам и начальнику отдела, для этого в вики есть красивая таблица по каждой стойке с точным описанием что в каком порядке идёт. У многих серверов есть алиасы по их назначению вида YYYYsrv[номер] либо на основной адрес сервера, либо на адрес в отдельном vlan соответствующего проекта. Реальный hostname сервера содержит оба имени: [буква]XXXX-YYYYsrv[номер] - поэтому заходом на сервер или опросом их через ansible всегда можно понять, где что. Иногда физический сервер меняется (и, соответственно, инвентарник), а его чаще всего используемое админами имя по на значению сохраняется. В завершение отмечу, что некоторые сервера по историческим причинам именовать по-новому не стали. Например, почти все базы данных имеют привычные старые имена, но их немного и они обслуживаются выделенными DBA.

Но подобная практика подойдёт далеко не всем. Например, если есть много проектов с малым числом серверов на каждом, или если сервера вперемешку используются на разных проектах (например, выбираются из соображений необходимого объёма памяти или наличия CUDA для работы нужного приложения), или сервера виртуальные и создаются в облаках по мере необходимости, то задачи перед именованием серверов могут стоять совсем другие.

[Алексей Арх]

Валентин,

Обычно в имя зашивают какой-то принцип, причём понятный не только двум админам из отдела, но и монтёрам, безопасникам, аудиту и тд.

Не вижу смысла закладывать в название толщину стенок корпуса для специалистов по пожарной безопасности.
Всё это можно описать там же, где лежит ip сервера, его пароли и прочее.

Например: krv-srv-010-monitor01 - сервер в Кирове десятый по счету с целью мониторинга.

krv-srv-011-telegram-bot01
Если появится другой телеграм бот, с другим функционалом, то это будет krv-srv-012-telegram-bot02?
А если это сильно нагруженные боты и надо обеспечить отказоустойчивость четырьмя серверами?
Так?
krv-srv-012-telegram-bot02 (тут уже нельзя bot02-1, потому что мы сначала не знали про 4 сервера и уже есть bot02, хотя придётся этот переименовывать)
krv-srv-013-telegram-bot02-2
krv-srv-014-telegram-bot02-3
krv-srv-014-telegram-bot02-4

А если это бот для мониторинга? krv-srv-010-monitor01. Его нельзя на этот же сервер? Нужно krv-srv-015-telegram-bot01-for-krv-srv-010-monitor01?

[Алексей Арх]

shurshur,

При малом числе серверов и несложном распределении их ролей не очень-то важно, как они называются

Допустим у тебя vs01, vs02, vs03, vs04, vs05
Потому ты решаешь убить первые 4 за ненадобностью, а vs05 всё ещё нужен.
В итоге есть vs05, но где 04, где 01? Перфекционизм, ОКР и прочие неудобства.

Если брать название сервера из рандомных пустых ячеек таблицы, тогда ОКР не побеспокоит =)

Если же серверов много, то какие-то принципы их именования всё же приходится придумывать с учётом своей специфики ...

Классно когда порядок в работе =)

Скажи, если бы допустим у вас вместо всех этих правил с инвентарными номерами было 4 символа какого то рандомного md5 к примеру (ed2c).
А инвентарный номер и прочая инфа всё так же в вашей красивой таблице. Это было бы удобней или нет или без разницы?
Всё равно же если серверов [буква]XXXX-YYYYsrv[номер] больше одного, то можно перепутать (человеческий фактор), а если их больше 50, то точно не запомнишь и нужно таблицу открывать.

[shurshur]

Алексей Арх, мы вводили в действие две новые площалки и поставили на одну из них первые XXXsrv00 и XXXsrv01, а на другую - XXXsrv02 и XXXsrv03. Потом имевшиеся старые сервера на Solaris постепенно превратили в XXXsrv03...XXXsrv13, за одним замечанием: XXXsrv07 был старым слабым сервером и был выведен из эксплуатации сразу же по завершении миграции. Потом когда ещё какой-то старый сервер переквалифицировали в сервер этой платформы, он стал XXXsrv17, а не XXXsrv07. Недавно вывели из эксплуатации XXXsrv04 и XXXsrv05, заменили на XXXsrv22. Нас дырки в нумерации не поугают. Наоборот, наша специфика как раз в том, что лучше новому серверу (не аналогичному на замену - такое тоже бывало при разных миграциях, или вот у одного сервера были аппаратные проблемы и его заменили из зипа) дать новый номер, нам это удобнее.

Всё равно же если серверов [буква]XXXX-YYYYsrv[номер] больше одного

Такое длинное имя есть только в hostname сервера. Его в DNS нет и никто им никогда не пользуется. Двух таких не бывает. Тут тоже, кстати, элемент специфики: железками и первичной установкой серверов у нас занимается практически только один человек, и он не путается в начальной подготовке, а мы уже не путаемся в том, что получилось.

а если их больше 50, то точно не запомнишь и нужно таблицу открывать

У нас их больше 50, но на одну платформу приходится от 2 до ~20. Мы не путаемся. Я же говорю - у каждого своя специфика.

[Алексей Арх]

shurshur,

Такое длинное имя есть только в hostname сервера. Его в DNS нет и никто им никогда не пользуется.

А если говорить про dns поддомены? Есть технические?

Например есть проект name.site.com
Он размазан балансиром по 10 серверам.
Разработчикам надо туда ходить по ssh, смотреть логи. Какой может быть нейминг?

Или другой пример. Один сервер, на нём несколько проектов от разных разработчиков. Все хотят туда ходить по разным причинам.
Допустим у одного там проект, есть в dns hello.site.com, у другого там скрипт, который он иногда запускает из консоли. Если первый будет ходят по ssh на hello.site.com, то второй по ip? Если ip поменялся, если hello.site.com разросся до нескольких серверов.

[shurshur]

Алексей Арх,

А если говорить про dns поддомены? Есть технические?

У нас сервера сами в Internet не выставлены (кроме балансеров - и то там есть нюансы), к ним доступ делается пробросами портов на маршрутизаторах (Cisco). Адреса серверов внутренние, DNS тоже внутренний со своей зоной, кроме того, есть всякие служебные зоны разного уровня типа dte, dev.flex.k8s итд итп.

Разработчики у нас в основные платформы вообще не ходят, только в тестовые и препрод-стенды. Ну ещё в молодые проекты они таки да, имеют доступ иногда. Логи смотрит эксплуатация, если надо - передаёт логи разработчикам. Если разработчикам нужны ещё какие-то данные (логи, записи из боевой базы, параметры серверов итд) - они их просят у эксплуатации.

Разработчик не запускает "иногда скрипт из консоли". И по имени hello.site.com он никуда не пойдёт. Админ - если он не в курсе или не помнит наизусть - пойдёт посмотрит в вики, что такое hello.site.com (и вообще как этот проект устроен), узнает что это балансер из 6 нод, посмотрит конфиг этого балансера в git, поймёт что оно пробрасывается в пару, XXXsrv05:8085 и XXXsrv11:9216, далее будет смотреть логи уже на этих серверах. Дежурный админ посреди ночи у нас регулярно решает такие квесты.

Такой бред, как пихать на сервера hello.site.com приложения проекта foobar.co.il у нас не делают в принципе. Выраженным исключением является запуск cassandra на куче серверов, потому что она давно перестала справляться с нагрузкой на 12 серверах того проекта, где используется (да-да, из-за GC), а переезд на scylla пока был неудачен из-за critical bug в scylla (очень хотелось, ведь по нагрузочным тестам scylla способна обойтись раз в 5 меньшим числом нод). У нас тут шутят, что на любом свежеустановленном сервере самозарождается ccassandra.

[Алексей Арх]

shurshur,

Такой бред, как пихать на сервера hello.site.com приложения проекта foobar.co.il у нас не делают в принципе.

"Бред" потом у что это архитектурно чем то грозит или просто вы радуетесь что есть бюджет и не приходится заниматься таким "бредом"?)

[shurshur]

Алексей Арх,

"Бред" потом у что это архитектурно чем то грозит

Ничто не мешает готовить пищу в мастерской, но как это может повредить и еде, и продукции этой мастерской - сложно предсказать. А у нас критическая инфраструктура, серьёзный уровень SLA и высокие риски.

просто вы радуетесь что есть бюджет и не приходится заниматься таким "бредом"?)

Бюджет тут причём? Нам в итоге оказалось удобнее не весь отдел гонять по датацентрам, а конкретного человека, который вполне справляется с этой работой. За всё время работы в компании я сам ездил туда всего один раз.

[Валентин]

Алексей Арх,

Не вижу смысла закладывать в название толщину стенок корпуса для специалистов по пожарной безопасности.

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

Принцип должен быть такой, что важная для смежных подразделений коллег нужно было как меньше читать и писать. То есть инфа после krv-srv-015 их вообще не должна касаться. Да и у вас должен быть какой-нибудь простой критерий, фильтрануть в файле эксель все серверы по какому-либо критерию (телеграм это, или в Кирове, или просто все физические серверы...)

[Алексей Арх]

shurshur,

Бюджет тут причём?

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

[shurshur]

Алексей Арх,

Бюджет выделается, на него можно купить n серверов

Когда мы выводим сервер из эксплуатации и отдаём его в какой-нить другой проект, то обычно полностью его перезаливаем. Имя у него при этом легко меняется. Например, мне недавно отдали под расширение сервер m0823, который раньше был нодой кластера mesos, при этом сервер был перезалит, в нём перебрали диски, воткнули другую сетевуху и назвали i0823. Кстати, его платформенное имя XXserver6, это третий сервер, первые два имеют номера 2 и 3.

История такой нумерации длинная и затяжная. Сервер 0 был первым сервером проекта на арендованном у одного маленького датского хостера сервере proxy0.company.ru, Однажды у хостера в том датацентре случилась серьёзная авария, из-за которой более половины новых tcp-коннектов не устанавливались, и мы в аварийном режиме стянули всё это на proxy1.company.ru в другом датацентре. На всякий случай арендовали запасную виртуалку XXserver1.company.ru, на которую делались бэкапы (lsyncd, репликация базы), чтобы в случае повторения аварии можно было бы быстро восстановиться. Виртуалка так и не понадобилась, когда проект из экспериментального переехал на специально купленные два сервера XXserver2 (i1918) и XXserver3 (i1917) в разных датацентрах. Первоначально планировалось, что приложение будет запускаться в двухголовом режиме на двух серверах, реально всё было на XXserver2, вторую голову поднимать не стали (и дальнейшие изыскания показали, что это почти никогда не имеет смысла). Когда из-за аппаратных проблем сетевузи там померли обе ноги bonding, приложения срочно растащили пополам на два временных сервера новых (не введённых в эксплуатацию) нод mesos m2024 и m2025, они же XXserver4 и XXserver5. В дальнейшем в проблемном сервере и в его брате-близнеце поменяли сетевухи, приложения с 4 перетащили на 2, с 5 - на 3. Кстати, сервера m2024 и m2025 в итоге в mesos не включили, а решили использовать для кубера и они стали k2024 и k2025 с перезаливкой. Когда ресурсы двух серверов закончились (на самом деле не совсем, ресурсы ещё оставались, но мы упёрлись в bcqueuelen у macvlan, а в текущем ядре этот параметр нельзя было изменять без пересборки), добавили третий сервер, который получил номер 6. Нас совершенно не парит, что номера не переиспользуются, это вообще не проблема, и решать тут просто нечего.

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

[Алексей Арх]

shurshur,

Я ещё раз повторю: у каждого своя специфика, свои традиции, свои возникающие проблемы.
Если бы мы меняли назначение серверов ежедневно, ... но мы это делаем эпизодически,

А как вы понимаете что условно i0823 - это бывший m0823. Ну вот есть физическая железка, ну или виртуальная. Она переустанавливается, переименовывается, пересобирается, переезжает. Какой то железобетонный уникальный ID это и есть XXserverX?

[shurshur]

Алексей Арх, а зачем мне знать, что это бывший m0823? Мне эта информация ничего особо не говорит. Его железобетонный уникальный ID это 823 - его инвентарный номер. У железячника в GLPI есть его история (с момента появления GLPI, конечно).

У нас при миграции с Solaris на Linux некоторые сервера поменяли имена. Какие на какие - теперь уже только в старых тикетах искать. Но мы это даже не ищем, потому что эта информация никакого смысла не имеет. Что нам с ней делать? Повесить на стену в рамочку?

[Алексей Арх]

shurshur,

Что нам с ней делать?

Да хотя бы документацию вести. Там и историю можно было бы видеть.

Не знаю, могу только фантазировать.
Можно конечно завести новую страницу в доке, а старую удалить. Но сервер то никуда не удалялся, просто информация о нём обновилась.

[shurshur]

Алексей Арх, так документация есть. Для документации неважно, что имя сервера поменялось. Тем более, что часть имени при этом постоянна.

Зачем фантазировать, если есть конкретные реалии?

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

[Алексей Арх]

shurshur,

Зачем фантазировать, если есть конкретные реалии?

Что бы минимизировать риски.

Вообще, ты как будто считаешь, что есть универсальное решение

Я не знаю есть ли решение, по этому и спросил "Может есть уже даже софт специальный?"

любые мыслящие иначе должны быть приговорены к расстрелу

Нет. Просьба поделиться опытом подразумевает принятие существования других взглядов.

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

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

[shurshur]

Алексей Арх,

Что бы минимизировать риски.

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

Да даже к твоей "уникальной ситуации" можно применить разные подходы.

Можно, но зачем? Мы пытались применять некоторые другие идеи, например, в имя сервера вначале добавляли букву, соответствующую датацентру, но в итоге пришли к такой вот схеме. Датацентр, кстати, легко определяется по IP (10.15x.* - железные адреса, 10.16x.* - сервисные адреса, где x=0,2,3 в зависимости от датацентра, датацентр с x=1 выведен из эксплуатации в силу своей упоротости - это Курчатовский институт с запретом доступа после 18:00 и на праздниках, с единственным электрическим вводом и единственным провайдером-монополистом).

Наши офисные админы, кстати, именуют сервера просто по именам. Но там серверов мало, поэтому всё очень просто. Сначала была пара гипервизоров east и west, спаренных с помощью drbd, потом появилась ещё пара серваков для разработчиков - rock, wolf...

[Алексей Арх]

shurshur,

Имя сервера риски не создаёт. Риски создаёт хаос ... если всё время переименовывать сервера

Какое то противоречие. Но не суть, я то и предлагаю за сервером уникальный ID закреплять, а не переименовывать i0823 в m0823. Точнее я ничего не предлагаю, я интересуюсь просто, спрашиваю.

Можно, но зачем? Мы пытались применять некоторые другие идеи

Но вот вы другие идеи применяли. Зачем? Что бы найти решение, близкое к идеальному. А что бы это всё не пробовать сразу в продакшене, можно сначала в голове пофантазировать, понавыдумывать разных ситуаций, спроецировать гипотетические ситуации на гипотетические подходы. Анализ - прогноз - принятие решения.

[shurshur]

Алексей Арх, так 823 и есть уникальный идентификатор сервера, это его инвентарник.

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

Что бы найти решение, близкое к идеальному.

Не совсем. Скорее мы отказались от идей, которые оказались бесполезными и неудобными, а также вернули вещи, которые применялись при старой концепции. Но, наверное, проще рассказать, как примерно это происходило, чтобы было понятнее.

На заре существования фирмы - когда оба её основателя лично программировали и админили всё это, серверов было мало и все они назывались короткими трёхбуквенными звучными именами типа tax, dix или sox. Приложения запускались прямо на этих серверах. Позже на серверах поднимались зоны Solaris с именами вида zcnrXX, zchlXX, zmngXX для коннекторов, каналов, менеджеров итд итп. Зоне при этом присваивался хостнейм вида zcnr06-dix или zchl05-tax, котороый отражал её расположение. При переезде зоны менялся хостнейм. В DNS этих имён с дефисами не было. Когда появились новые проекты, просто в имена зон добавлялись ключевые слова, например, zavicnrXX для коннекторов платформы avi, zpushrotXX для роутеров платформы push... Особых проблем с поддержанием всего этого хозяйства не было в силу не очень большого количества серверов и зон, а также из-за того, что админил всё это один человек, которому несложно было поддерживать в этом порядок.

При переезде на Linux от использования зон отказались. Во-первых, потому что в Linux сложнее с изкоробочным инструментарием для этого, во-вторых, потому что было принято важное решение не смешивать разные платформы на одних и тех же серверах. Также всерьёз думали над полным переводом на докер или мезос. У нас в какой-то момент было бурное двухчасовое обсуждение того, как всё же именовать сервера, и договорились до именования PXXXXD, где P - однобуквенный символ платформы (a - avi, p - push итд), XXXX - инвентарник, D - однобуквенный символ датацентра (например, k - KIAE). Все остальные варианты - алиасы в DNS. Первый админ фирмы почему-то очень не хотел цифр в именах и придумал остроумную схему именования на аббревиатурах, где каждой цифре соответствует буква, например 5 - p ("пять"), 9 - n ("найн", потому что d уже занята цифрой "два"). Поэтому у нас и были какое-то время сделанные им всякие странные алиасы типа pnp CNAME s0595k (поддерживал он их, впрочем, недолго). Сразу же стали делать алиасы без буквы датацентра (s0595 CNAME s0595k) и в целом буква датацентра оказалась никому не нужна, поэтому указывать её быстро забросили. На этом история формирования основного имени железных серверов закончилась. Предлагали ещё что-нибудь писать в TXT, но это не особо пошло, хотя у некоторых имён это применяется иногда (например, у виртуалок часто есть TXT со ссылкой на тикет, по которой её завели, чтобы в случае чего хотя бы примерно понять, куда искать, даже если на эту виртуалку нет логина и понимания как посмотреть её назначение).

Но я уже сказал, что был и процесс возвращения к истокам. Началось всё с того, что для платформы push сделали имена вида pushsrv00 CNAME p0882, причём в реальном употреблении внутри платформы были именно имена pushsrvXX (сами приложения при этом запускались докере, имена использовались только для указания места деплоя). После того как админу, который был главный ответственный за эту платформу, надоело в очередной раз вспоминать, что на сервере p0882 на самом деле pushsrv00, он вспомнил про концепцию времён Solaris и переименовал все свои сервера в вид pushsrv00-p0882.

Для некоторых других платформ позже сделали то же самое. Правда, там есть нюанс: имя XXXsrvXX было не CNAME, а адресом в другом VLAN, на котором работают эти платформы (там нет docker и приложения работают непосредственно на серверах, но по этим сервисным именам внутри кластера). Начальник в какой-то момент высказал этим недовольство и попытался потребовать сделать их CNAME на железные адреса серверов, но войско взбунтовалось^W^W админы возмутились и сказали, что нужно тогда ещё третий вид имён для сервисных, но смысла мало, так как вместо смотреть в DNS можно просто зайти на сервер и узнать его инвентарник, а если кому-то уж прям невероятно надо через DNS - пусть напряжётся и заполняет TXT-записи (что никто так и не сделал, и вопрос исчерпался).

В итоге достигли консенсуса, по сути не внося никаких существенных изменений. И что очень важно - целый ряд инициатив "как сделать лучше" просто на старте никак не прижились, так как оказались не такими нужными, как это казалось.

Answer 1

[Талян]

Ну у нас сервера зовутся:

CR-MOW-DC (центр реабилитации - москва - домен контроллер)
MS-SYK-HV (Медцентр Суперский - сыктывкар - гипервизор)

Ну имена вымышленные, но суть передал.

И я по названию понимаю, к какой организации относится сервер, в каком он городе, и чем занимается.

Comments

[Алексей Арх]

Неподходит например под идею докер контейнеров.
Когда есть машина (1) с каким то проектом, у неё есть в простое некоторый запас мощности, который можно использовать. Есть нагруженный проект на втором сервере (2), можно его скопировать на сервер (1) в контейнере каком то и балансировать между ними нагрузку.

Ну и география в названии сервера не особо что то даст. Может даже помешает.
Допустим есть сервер MOW-1. Там лежит к примеру бот для соц сети. Захотелось уйти из этого дц в Питербург, а ты уже привык что бот на MOW-1, в питерском дц такой сервер уже не повторить.
Да и буквы лишние.

Это уже похоже на более высокий слой нейминга. Например техническое имя b1.example.com, а имя для географиической какой то логики mow1. Тогда можно mow1 домен перевязать на сервер a1 или балансировать между a1 и b1

[Талян]

Алексей Арх, Ну вы верно мыслите, если у вас разнозадачные сервера, то именуйте их как:
docker-srv1-8-4 (задача-порядок-порядоквстойке).

Вы не скрестите сразу и то что на нём крутится, и зачем этот сервер нужен. Так что предлагаю идентифицировать только назначение сервера.

А вот хостнеймы контейнеров, или служб - уже более осмысленно.

Ну вы как себе по другому представляете нейминг?

[Алексей Арх]

Талян,

Вы не скрестите сразу и то что на нём крутится, и зачем этот сервер нужен. Так что предлагаю идентифицировать только назначение сервера.

Как раз хочется уйти от ассоциаций проет-сервер.
Сервер из стойки может переехать в другую стойку. Или сервер в облаке.
Сервер может поменять своё предназначение.
Докера на сервере может не быть. Иногда может хватить bash в кроне и на этом его полномочия всё =)

Ну вы как себе по другому представляете нейминг?

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

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

Answer 2

[Vamp]

Я использую нейминг по физическому расположению сервера.

{имя дц}-{номер стойки}-{номер юнита в стойке}

Получается что-то типа:

miran-8-40
itsoft-1-1

Если хотите покороче и фикс длину, можно брать первую букву ДЦ (или две буквы, если есть совпадения) и выравнивать цифры ведущим нулём:

m-08-40
i-01-01

Если серверов не так много чтобы арендовать стойки целиком, то просто порядковый номер сервера:

m-01
i-15

Ну или два/три ведущих нуля, если количество серверов 1000/10000:

m-001
i-015

Самый короткий вариант нейминга у меня получился 2х символьный.

Почему не 1 символ?

Comments

[Алексей Арх]

Почему не 1 символ?

Потому что серверов больше чем 0-9-A-Z =)
А 2 символа это уже большой запас.

Но идея именно в табличном представлении, а тут минимум 2 символа надо.

{имя дц}-{номер стойки}-{номер юнита в стойке}

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

Если серверов не так много чтобы арендовать стойки целиком, то просто порядковый номер сервера:
m-01

Это получатся тоже самое, что и номер из таблицы m1,a0.

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

[Vamp]

Нравится эта идея. Но опять же хотелось бы покрывать не только физические, но и виртуальные

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

Это получатся тоже самое, что и номер из таблицы m1,a0.

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

Это супер универсальный вариант, подходящий к любой ситуации. Все остальные варианты так или иначе требуют некоторых усилий по поддержке, от которых никуда не деться.

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

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

Не бойтесь экспериментировать. С первого раза вы точно не придумаете идеальный нейминг. Это эволюционный процесс.

[Алексей Арх]

Vamp,

Но если ваша специфика предполагает частую перестановку серверов между стойками,

Частую не предполагает, просто наткнулся 2 раза, когда были локальные сервера и переезжали в другой офис.
Имеет место быть.

Не бойтесь экспериментировать. С первого раза вы точно не придумаете идеальный нейминг. Это эволюционный процесс.

Судя по ответам тут, вырисовывается такая картина, что у сервера должен быть некий базовый уникальный id. За которым в документации можно закрепить все ip адреса этого сервера, доступы и т.д.
А дальше уже сколько угодно DNS алиасов для разных нужд, которые прикрепляются в документации к этому уникальному id.
Получается id привязан к конкретной машине, виртуальной или физической неважно. А проекты и DNS адреса могут уже мигрировать между машинами как абстрактный слой.

Answer 3

[Saboteur]

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

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

Если у сервера нет конкретного назначения, используетс просто геолокация и бренд.

ibm-ny-0519-01 - IBM, New York DC, 2019/Mar, 01
hp-sf2-0619-01 - HP San-Francisco DC2, 2019/Jun, 01

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

Поэтому хостнейм машины - должен нести на себе инвентаризационные данные.
А если на машине постоянно крутится какое-то конкретное приложение, добавляешь DNS алиас типа myapp.mycompany.intranet.com
Если появляется еще одна "идея", то добавляется еще один DNS алиас myanotherapp.mycompany.intranet.com
Если приложение выросло или требует других ресурсов - оно уезжает на другой хост вместе со своим алиасом, и все довольны.

Comments

[Алексей Арх]

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

Не такая уж и слишком.

Взять например любого программиста. У него появляется идея сделать что то сетевое, допустим html страница с портфолио. Он берёт самый дешёвый vps где то, называет её porlf-01-moscow. Эта html живёт себе, ресурсов не требует.
Появляется другая идея. Какой то веб калькулятор расхода топлива от фазы луны. По идее он должен потратить ещё денег и купить новый vps с названием calk-01-spb. Но зачем? Есть же уже сервер, на котором 0 трафика и 100% свободных ресурсов.

Потом он решает убрать портфолио, работа найдена, проект больше не нужен. Но появилась идея другого проекта, при этом есть сервер porlf-01-moscow, на котором уже настроена OS и всё необходимое окружение - пользователь, права, nginx, cerbot итд
Во первых зачем его удалять, брать новый и заново всё настраивать. Во вторых там всё ещё крутится портфолио его жены, да и своё он просто отключил, не удалять же сервер.

Сейчас олимпиада, лям компаний сделали спецпроекты одностаничники под это событие. Эти сервера получается "однодневки"? Завтра новое событие, новый спец проект. Новый сервер?

то в другую стойку перехать то еще что-то

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

Если у сервера нет конкретного назначения, используетс просто геолокация и бренд.

А зачем бренд? Это же лишняя информация. Бренд, материал, толщина корпуса сервера, его ip и географию - всё это можно где то отдельно хранить в описании.

[Saboteur]

Взять например любого программиста. У него появляется идея сделать что то сетевое, допустим html страница с портфолио

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

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

Поэтому хостнейм машины - должен нести на себе инвентаризационные данные.
А если на машине постоянно крутится какое-то конкретное приложение, добавляешь DNS алиас типа myapp.mycompany.intranet.com
Если появляется еще одна "идея", то добавляется еще один DNS алиас
myanotherapp.mycompany.intranet.com

Если приложение пожирнело, ему нужны другие ресурсы, оно уезжает на другой сервер вместе со своим DNS алиасом.

А хостнейм никто не трогает.

А зачем бренд? Это же лишняя информация. Бренд, материал, толщина корпуса сервера, его ip и географию - всё это можно где то отдельно хранить в описании.

Бренд полезно хранить чтобы понимать что это за хост вообще.
Например
vm- виртуалка
hp- железка на HP
lb- loadbalancer
wip- wide-ip-load-balancer

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

[Алексей Арх]

Saboteur,

Что за бред. Откуда у программиста появляется идея, и уж тем более портфолио?

Вы видимо не пересекались с программистами.

Он работает на работе. Что ему делать ему говорит заказчик.

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

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

Да, я наверное зря не уточнил что под "техническим" именем сервера скорее имею ввиду его "технический" сетевой поддомен. Хотя может и не зря. Я же сказал что это техническое имя сервера, а не имена продакшен проектов.

полезно по хостнейм понимать что там под капотом

Я понял ваш ваш подход. Условно к порядковому id сервера добавлять необходимые ассоциации.
id сервера это ключ, по которому можно вести документацию где то, а сахар в нейминге это уже слой алиасов поверх базового, для удобства конкретных пользователей, причём у каждого могут быть свои предпочтения.

[Saboteur]

Алексей Арх, Ну просто когда много серверов, нужно понимать что это в первую очередь чьи-то деньги. И программист их не считает, их считает ITAO или менеджер/архитектор, кто выполняет эти функции и распоряжается бюджетом проекта/компании выделяемый на инфраструктуру.

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

А девелопер к этому никак не относится. Среднестатистический девелопер даже не интересуется на каком именно сервере крутится его приложение. И может даже и не знать.

[Алексей Арх]

Saboteur,

Среднестатистический девелопер даже не интересуется на каком именно сервере крутится его приложение

Согласен. Но есть главные разрабы. Если большая компания с большим количеством команд, там много главных разрабов. Есть компании где внутренние хакатоны проводятся, чем проект лучше, тот и пойдёт в продакшен, а тут надо экосистему из серверов выстроить. Но опять же есть личные сервера, я думаю у каждого разработчика есть несколько vps с тестами, неудачными/удачными проектами, родственники попросили сделать сайт итд.

менеджер/архитектор, кто выполняет эти функции и распоряжается бюджетом проекта/компании выделяемый на инфраструктуру

Бюджет как правило выпрашивают и закладывают. Выделили 100к в месяц на пополнение бюджета определённого хостинга. Прошло время, часть проектов померло, у части выросла нагрузка.
Новое утверждение бюджета ещё не состоялось. При этом есть живые сервера от которых можно откусить мощность.
Начинается жонглирование проектами по серверам.

[Saboteur]

Алексей Арх,

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

Так это же не рабочие сервера, это личные сервера и он их не на работе держит, а сам покупает у какого-то провайдера/в облаке.

При этом есть живые сервера от которых можно откусить мощность.
Начинается жонглирование проектами по серверам.

Тогда это головная боль тех, кто жонглирует и закупает.

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

В общем я лет 20 работаю в очень разных проектах, и такого, чтобы сервера часто и быстро бегали по разным проектам в компании - не видел. А если и бегают, то в основном это виртуалки, которые не передаются от проекта к проекту, а одни декомиссятся, новые создаются (с новыми хостнеймами).
Потому что неизвестно какие хвосты могут остаться на старом хостнейме, какие данные могут быть на этом сервере. Создать другую виртуалку с другим ID - это в том числе и SecOps
Даже по юзерам есть правило, что удаляя юзер, его ID просто блочится навсегда, чтобы новый юзер случайно не мог его занять.

[Алексей Арх]

Saboteur,

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

Ну это же абстрактный холивар. У вас не было, у меня было, у какого нибудь Васи было такое, что мы и представить не можем.

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

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

Потому что неизвестно какие хвосты могут остаться на старом хостнейме

Опять же пример с докером приведу как всё может быть запутано. На хосте настраивается базовое ПО, всё остальное в контейнерах.
Есть проект project.com, спустя время появляется какой то микросервис к этому проекту (micro1.project.com), ставится контейнер рядом на туже виртуальку (путь будет a0).
Появляется ещё один микросервис micro2.project.com, но он уже не влезет сюда по требованиям мощности, ставится на другую виртуалку (a1).
Серверов больше нет, бюджета пока нет. Появилась задача сделать бота, он ничего не жрёт. Ставится контейнер на второй сервер (где micro2 крутится - a1). Потом появляется бюджет и новый проект project2.ru и сервер a3.
А micro2.project.com например больше не актуален. Но удалить сервер a2 мы не можем, там же ещё бот есть живой, по этому просто удаляем контейнер micro2. В итоге есть мощный сервер a2, на котором только хилый бот.
На проекте project2.ru появляется задача, как на project.com. Проект project2.ru начинает обращаться к микросервису micro1.project.com (a1), потому что он уже решает эту задачу. Нагрузка растёт. Вспоминаем что есть сервер с ботом (a2), выносим туда micro1 к которому обращается и project(a1) и project2(a3).
Если это не жонглировать, то получиться что первый сервер перегружен, а второй в простое.

Вполне распространённая ситуация мне кажется =)

Создать другую виртуалку с другим ID - это в том числе и SecOps

Вот это полезно, запомню. Иногда остаются обращения к несуществующему, их проще найти и отключить,/переключить а если тут что то новое заработает с кодом 200, будет проблематично.

[Saboteur]

Алексей Арх,
"Ну это же абстрактный холивар. "
Ну я к тому вел, что это много разных проектов, с разными компаниями и разными инфраструктурами, но везде инвентаризация была на уровне инвентаризации компов, а не проектов на них.

Опять же пример с докером приведу как всё может быть запутано. На хосте настраивается базовое ПО, всё остальное в контейнерах.

Я думаю в этом плане, особенно если контейнеров много, давно пора ехать в кубернетес и тогда у приложения будет кубернетес_кластер_1

А хост kub1-node1, kub1-node2 и все. И на какой конкретно ноде запустится приложение уже вообще не важно, важно что в кластере 1. А задача кубернетес саппорта добавлять туда столько нод, сколько нужно. Хостнеймы тут вообще уже никто не видит кроме куб.саппорт тимы

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

Answer 4

[Alexey Dmitriev]

Обычно соглашение по именам (формализованное и утвержденное) использует в качестве кодирования размещение + структурные подразделения в организации + физический\виртуальный + роли серверов + двухсимвольную нумерацию.
Так как непонятно - что у вас за организация - конкретное посоветовать сложно.
Вот вам пример для транснациональной компании:
2 символа номера зоны\части света + 2 символа iso кода страны + 2 символа кода города + V\P (виртуальный физический) + 1 символ роли + двухзначный порядковый номер.
Получим Z1USNYVD01 - виртуальный контроллер домена 01, размещенный в Зоне Америки, стране США, городе Нью-Йорк.
Если есть деление по Tier - добавляются еще 1,2,3 тиры.

Вот вам пример для организации в рамках страны - город, офис, tier, тип, роль, порядковый номер.

Comments

[Алексей Арх]

Так как непонятно - что у вас за организация

Вот специально хотелось бы абстрагироваться.
Но серверов меньше 1000. Хотя это не суть, ведь можно просто увеличить количество символов.

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

Answer 5

[profesor08]

domain-subdomain-subsubdomain-subsubsubdomain-sub(n)domain

Если не знаешь что выбрать главнее, то бросай монетку.

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

Comments

[Алексей Арх]

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

Вот и я так подумал. "некий каталог" - есть что то более или менее подходящее для такой задачи?

[profesor08]

Алексей Арх, текстовый файлик, эксель табличка, mysql. Выбирай на вкус и цвет.