Выбор между значимыми и бессмысленными именами хостов [закрыто]
Предположим, что среда с марионеточным управляемым кластером из различных серверов - различного оборудования, программного обеспечения, операционных систем, виртуальных / выделенных и т. д.
Вы бы выбрали значимые имена хостов (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup и т. д.) или вы бы предпочли бессмысленные имена хостов, такие как персонажи из книги или фильма?
Я вижу проблему со значимыми именами хостов в том, что имена обычно представляют единственная служба, и если у сервера более одной цели, это становится действительно беспорядочным (особенно, если роли сервера часто меняются).
Разве DNS не сопоставляет имя службы с IP-адресом и поддерживает это сопоставление?
В чем преимущества и недостатки Есть ли какие-то сведения об обоих подходах и какие реальные проблемы вам приходилось решать с помощью выбранного вами подхода?
Давным-давно у меня была возможность выбрать схему именования. Поэтому я обошел стороной и спросил своих разработчиков, которые, в конце концов, были людьми, которым приходилось работать с этими именами изо дня в день, предпочитают ли они функциональные имена (то есть имена, которые представляют, в некоторой закодированной форме - назначение машины) или мнемонических имен (то есть имена, взятые из некоторой ранее существовавшей схемы именования людей, которая не содержала неявного содержания о назначении машины).
Out из 38 разработчиков 37 предпочтительных мнемонических имен; только одно предпочтительное функциональное имя. Поэтому я назвал их в честь рек (существует очень большой набор возможных имен, и многие из них короткие, легко запоминаются и быстро набираются).
Человеческий мозг довольно хорошо приспособлен для придания значения именам . Если вы укажете запоминающиеся имена, люди довольно быстро запомнят, для чего эти имена используются, и будут их использовать. Если вы используете имена, взятые из некоторого общего фона (например, реки, элементы, звезды, округа, напитки, вы поняли), это помогает людям сразу узнавать имя хоста компании, когда они сталкиваются с ним; в противном случае утверждения вроде «вся электронная почта попала на betelgeuse » могут немного сбивать с толку).
И наоборот, мои разработчики чувствовали, что на предыдущих должностях им было очень трудно вспомнить, что именно pr1ms001 было.
Но я должен добавить, что мы использовали CNAME во внутреннем DNS, чтобы предоставить функциональное имя для отображения мнемонических имен, поэтому, если вам действительно было легче запомнить, что основной почтовый сервер в первом кластере на сайт PR был pr1ms001 , тогда DNS сообщит вам, что это в настоящее время или . Кроме того, это позволило нам иметь много функциональных имен для каждой машины, поэтому, если вы всегда используете функциональное имя, относящееся к функции, над которой работаете, вы можете быть уверены, что pr1imap001 всегда будет указывать на сервер IMAP. , даже если мы переместим эту функциональность из Оруэлла в Рейн . А когда hudson умер, мы могли изменить название замены, не затрагивая рабочие функции, так что у нас никогда не было «вы имеете в виду новый hudson или старый hudson ]? " путаница.
pr1imap001 всегда будет указывать на сервер IMAP, даже если мы переместим эту функцию из или - Рейн . А когда hudson умер, мы могли изменить название замены, не затрагивая рабочие функции, так что у нас никогда не было «вы имеете в виду новый hudson или старый hudson ]? " путаница. поэтому до тех пор, пока вы всегда использовали функциональное имя, соответствующее функции, над которой вы работали, вы можете быть уверены, что pr1imap001 всегда будет указывать на сервер IMAP, даже если мы переместим эту функцию из или - Рейн . А когда умер hudson , мы могли изменить название замены, не затрагивая рабочие функции, так что у нас никогда не было «вы имеете в виду новый hudson или старый hudson ]? " путаница. мы могли изменить название замены, не затрагивая рабочие функции, так что у нас никогда не было вопроса «Вы имеете в виду новый хадсон или старый хадсон ?» путаница. мы могли изменить название замены, не затрагивая рабочие функции, так что у нас никогда не было вопроса «Вы имеете в виду новый хадсон или старый хадсон ?» путаница. Это в значительной степени зависит от того, являются ли ваши серверы домашними животными или домашний скот .
Домашние животные получают индивидуальные имена. Они отличаются друг от друга, и мы заботимся об этих различиях. Когда человек заболевает, мы обычно стараемся вылечить его. Традиционно серверами были домашние животные.
Домашний скот получает числа. В основном они идентичны, и нас не волнует, какие различия есть, и мы стараемся их минимизировать. Когда один заболевает, мы кладем его и получаем другого. Полностью виртуализированные серверы, особенно серверы IaaS, такие как AWS, являются домашним скотом.
В большинстве сложных сред у вас есть смесь. Например, ваши веб-серверы почти наверняка являются домашним скотом. Если вам нужно больше, вы можете добавить еще несколько с помощью стандартной конфигурации; если вам не нужно столько, вы отключите некоторые. Ваши серверы баз данных в некоторых конфигурациях являются домашними животными. На каждом может быть много специальных настроек; вы даже можете запускать их на «голом железе» вместо виртуализации.
Конечно, в любой среде вы можете назвать СЛУЖБЫ и обращаться к ним напрямую. В любом случае это лучший способ; вашим разработчикам не нужно знать или заботиться о фактическом имени хоста службы. Имя хоста должно быть чисто оперативной деталью. Тогда подумайте о кодировании информации, которая будет полезна вашему операционному персоналу, в именах хостов - например, это '
Это уже обсуждалось здесь раньше ...
Моя рекомендация - комбинация функциональных имен и мнемонических имен ...
Если вы пишете приложение, и оно должно быть адрес ccts-logserver1 , используйте это имя повсюду, но сделайте его CNAME или псевдонимом. Настоящее имя хоста может быть любым: фруктом или овощем, греческой мифологией или персонажем Сайнфельда ... но это дает вам некоторую гибкость, когда вам нужно связать реальные функциональные имена, но сохранить то, что люди могут запомнить.
Подумайте об этом. пример, где манго , сервер БД выходит из строя ... но заменяется чем-то другим, скажем персиковым . Возможно, существующие процессы и приложения должны видеть cmt-prod-db1 . Вы можете поменять местами системы,
Там, где я работаю, мы управляем несколькими сайтами, несколькими компаниями в разных городах. Для нас мнемонические имена не работают. Вместо этого мы используем сокращенную форму, которая описывает наши серверы. Это хорошо работает в нашем случае, поскольку у нас есть несколько клиентов, у которых может быть несколько офисов в разных доменах (или один офис в нескольких доменах, или несколько офисов в одном домене, или все вышеперечисленное!)
Для нас информация содержит компанию / домен, город, должность, номер. Итак, для контроллера домена для компании, скажем Cypress в Чикаго, это будет:
CYPRCHDOM001 (в разговоре мы будем называть это основной DOM Cypress)
CYPRCHSQL001 - это сервер SQL, CYPRCHMGM001 - его управление (т. Е. Антивирус, резервное копирование и т.д.), а CYPRCHAPP001 - смешанный сервер приложений. Легко запомнить, легко сортировать, легко научить.
Единственное требование для имен хостов - это то, что они должны быть уникальными в сети.
Значение не обязательно должно иметь отношение только к функциям серверов. Местоположение может быть очень полезным, если вам приходится иметь дело с физическими устройствами. Также полезно знать, является ли устройство виртуальным или физическим. Способность различать сетевое устройство, сервер Linux или окно Windows может быть очень полезной, когда дело доходит до определения того, какой инструмент использовать для входа в систему.
Мы с этим справляемся, пытаясь ввести эту информацию. в имя устройства следующим образом:
L или T - Live или Test P или V - физический или виртуальный S или N - сервер или сеть (у нас нет серверов Linux) порядковый номер для обеспечения уникальности Трехбуквенный код страны ISO 3166-1 , указывающий, где находится устройство.
Затем мы используем CNAMES в DNS для сопоставления различных имен сервисов с именем хоста.
У меня смешанные чувства по этому поводу. . Это, безусловно, экономит время, связанное с необходимостью искать, где находится определенное устройство. С другой стороны, гораздо сложнее запомнить, что делает данный сервер, когда он представлен с его именем хоста, по сравнению с нашей предыдущей системой, которая использовала драгоценные камни. Драгоценные камни вообще не имели никакого значения, но их было легко запомнить, потому что каждый человек мог создавать свои собственные связи.
Я думаю, единственный совет - остановиться на одной схеме, поскольку наибольшая путаница возникла, когда мы перешли от одна система в другую.