Вопрос: Выбор между значимыми и бессмысленными именами хостов [закрыт]


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

Вы бы выбрали значимые имена хостов (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup и т. Д.), Или вы предпочли бы бессмысленные имена хостов, такие как персонажи из книги или фильма?

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

Не отображает ли имя службы на IP-адрес и поддерживает ли это отображение того, что должен делать DNS?

Каковы преимущества и недостатки обоих подходов и какие фактические проблемы вы столкнулись с выбором, который вы выбрали?


74
2018-02-18 14:04


Источник


Если вы контролируете DNS, вы всегда можете обойти оба. - jscott
Я просто оставлю это здесь: RFC 1178 - gelraen
Хотя поверхностно вопрос, основанный на мнениях, фактические ответы основаны на фактах с эмпирическим опросом и основаны на человеческой когнитивной функции (как мозг человека помнит вещи). По-моему, этот вопрос должен быть вновь открыт. - dotancohen


Ответы:


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

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

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

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

Но я должен добавить, что мы использовали CNAME во внутреннем DNS для предоставления функционального имени для отображения мнемонических имен, поэтому, если вам действительно было легче запомнить, что основной почтовый сервер в первом кластере на PR-сайте был pr1ms001, то DNS сообщит вам, что в настоящее время orwell, Кроме того, это позволяет нам иметь множество функциональных названий для каждой машины, поэтому, если вы всегда использовали функциональное имя, относящееся к функции, над которой вы работали, вы можете быть уверены, что pr1imap001 всегда указывал бы на сервер IMAP, даже если бы мы перенесли эту функциональность из orwell в rhine, И когда hudson умер, мы могли бы изменить название замены, не влияя на операционные функции, так что у нас никогда не было «вы имеете в виду новые hudsonили старый hudson? "путаница.


96
2018-02-18 14:10



спасибо, я буду ждать ответа из другого лагеря и посмотреть, какой из них я приму (хотя я не уверен, что у этого вопроса есть правильный или неправильный ответ) - keymone
Вы могли бы подумать об этом, но мои разработчики сказали, что мнемоническая схема была лучше, если бы что-то еще было передано, потому что все они построили свои собственные внутренние таблицы состояний того, что было где, и такую ​​память проще строить на именах, которые человеческий мозг любит вспоминать. - MadHatter
Вы должны были назвать их после вулканов в Исландии. - Chloe
Это потрясающая идея, и я ворую ее. - SpacemanSpiff
Я согласен с тем, что именования серверов таким образом больше работают с системой автообъектов, но я отмечаю, что цель их создания заключается в том, чтобы другие люди использовали их, а данные выше - от людей, которым приходилось использование их. Возможно, что то, что они хотят, изменилось, но я думаю, что наши решения по администратору сервера должны основываться на чем-то, что облегчает нашу работу. - MadHatter


В основном это зависит от того, являются ли ваши серверы pets или livestock,

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

Животноводство получает цифры. Они в основном идентичны, и какие различия существуют, нас не волнуют и обычно пытаются свести к минимуму. Когда заболевает, мы кладем его и получаем еще один. Полностью виртуализированные серверы, особенно IaaS-серверы, такие как AWS, являются скотом.

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

Конечно, в любой среде вы можете назвать УСЛУГИ и обратиться к ним напрямую. Это наилучшая практика в любом случае; вашим разработчикам не нужно знать или заботиться о том, каково фактическое имя хоста службы. Имя хоста должно быть чисто оперативным. Подумайте, например, о кодировке информации, которая полезна для вашего персонажа ops в именах хостов - например, часто полезно указать, в каком центре данных находится сервер.


93
2018-02-18 18:16



Домашние животные или домашний скот - это хороший способ выразить это. - Michael Hampton♦
Недавно я вновь нашел статью, в которой я впервые увидел эту концепцию: gregarnette.com/blog/2012/05/cloud-servers-are-not-our-pets - Ian
Спасибо @Яй я охотился за последний день для этой статьи, SEO не хе - Rudolf Olah


Это было рассмотрено здесь раньше ...

Моя рекомендация - сочетание функциональных имен и мнемонических имен ...

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

Подумайте о примере, где mango, сервер БД выходит из строя ... но заменяется чем-то другим, скажем, peach, Возможно, существующие процессы и приложения должны видеть cmt-prod-db1, Вы можете поменять местами системы, построить их, не именовав конфликты, и поддерживать приложения (и разработчики) счастливыми.


18
2018-02-18 14:17





Там, где я работаю, мы управляем несколькими сайтами, несколькими компаниями, в нескольких городах. Для нас мнемонические имена не могут работать. Вместо этого мы используем сокращенную форму, которая описывает наши серверы. Это хорошо работает в нашем случае, так как у нас есть несколько клиентов, которые могут иметь несколько офисов в разных доменах (или один офис в нескольких доменах или несколько офисов в одном домене или все вышеперечисленное!)

Для нас информация содержит компанию / домен, город, функцию, номер. Итак, для контроллера домена для компании, скажем, Cypress в Чикаго, это будет:

CYPRCHDOM001 (Мы будем ссылаться на это как на главную главную страницу Cypress в разговоре)

CYPRCHSQL001 будет сервером SQL, CYPRCHMGM001 будет его управлением (т. Е. Антивирусом, резервным копированием и т. Д.), А CYPRCHAPP001 будет смешанным сервером приложений. Легко запомнить, легко сортировать, легко учить.


4
2018-02-18 18:31



Итак, как вы помните, какие приложения запускаются на CYPRCHAPP001, а не CYPRCHAPP003? Я признаю, что это проблема и с именами mnenomic, но если вы собираетесь использовать какие-то функциональные имена, может также быть конкретным. - Michael Kjörling
@ MichaelKjörling Точная спецификация зерна того, что находится на сервере, не принадлежит имени, они принадлежат к какой-то документации. Если кто-то должен знать, что работает на CYPRCHAPP001, они читают документацию. Кроме того, приложения перемещаются, CYPRCHAPP001_PointofSale_Payroll_HRSoftware-и т. Д. Будет неправильным, когда компания перемещает свое программное обеспечение для расчета заработной платы в размещенное решение. - Wulfhart
@Wulfhart Я согласен с вашей точки зрения, но что не так с тем, что CNAME для pointofsale, payroll, и т.д.? Таким образом, никто, кроме системных администраторов, не должен заботиться о том, где именно работает программа расчета заработной платы; для всех остальных это просто работает. Хотите переместить что-то в другой центр данных? Совершенно никаких проблем. Хотите переместить базу данных точки продажи на свой выделенный сервер? Просто обновите pointofsale-database CNAME, чтобы указать на новое местоположение. И так далее. - Michael Kjörling
Предположим, вам нужно заменить машину: как только вы построили CYPRCHSQL002 и протестировали ее, вы просто удаляете имя CYPRCHSQL001 (никогда не заменяетесь) или переименовываете 002 в 001 после удаления старого 001 или чего-то еще еще? - nickgrim
@ MichaelKjörling Это кажется отличной идеей для меня. «Специфика не принадлежит имени», я имел в виду не имя хоста машины. - Wulfhart


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

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

Способ, которым мы справляемся с этим, состоит в том, чтобы попытаться поместить эту информацию в имя устройства следующим образом:

L или T - Live или Test P или V - физическое или виртуальное S или N - сервер или сеть (у нас нет серверов Linux) последовательный номер для обеспечения уникальности ISO 3166-1 трехбуквенный код страны указывая, где находится устройство.

Затем мы используем CNAMES в DNS для сопоставления имен различных служб с именем хоста.

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

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


2
2018-02-19 15:18



Я не согласен с этим: «Знание того, является ли устройство виртуальным или физическим, также может быть полезным» в контексте именование обсуждение. Конечно, это полезная информация, но не первое, что вам нужно знать о том, как сервер читает свое имя. Кроме того, P2V или V2P либо нарушают вашу схему, либо требуют переименования сервера, что может нарушить другие вещи. - mfinni
По моему опыту P2V или V2P ломают целую кучу вещей и их следует избегать, когда это возможно - мы это делаем, поэтому это не проблема с нашим соглашением об именах. Соглашение об именовании должно отвечать требованиям тех, кто его проектировал - в организации, в которой я работаю, она была разработана командой, которая управляет всеми серверами и сетевым оборудованием, и они хотят иметь возможность рассказать о вышеуказанных вещах. Возможно, это не подходит вам, но тогда все открыто для обсуждения. Единственное техническое требование - уникальность. - dunxd