Предположим среду с марионеточным управляемым кластером из разных серверов - различного оборудования, программного обеспечения, операционных систем, виртуальных / выделенных и т. Д.
Вы бы выбрали осмысленные имена хостов (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup и т. Д.) Или предпочли бы бессмысленные имена хостов, такие как персонажи из книги или фильма?
Проблема, которую я вижу с осмысленными именами хостов, заключается в том, что имена обычно представляют одну службу, и если у сервера более одной цели, он становится действительно беспорядочным (особенно если роли сервера часто меняются).
Разве не сопоставление имени службы с IP-адресом и поддержка этого сопоставления должны выполнять DNS?
Каковы преимущества и недостатки обоих подходов и какие реальные проблемы вам приходилось решать с помощью выбранного вами подхода?
Однажды мне довелось определиться со схемой именования. Поэтому я пошел и спросил своих разработчиков, которые в конце концов были людьми, которым приходилось работать с этими именами изо дня в день, предпочитают ли они функциональный имена (то есть имена, которые представляют в некоторой закодированной форме назначение машины) или мнемонический имена (то есть имена, взятые из некоторой ранее существовавшей схемы именования людей, которая не содержала неявного содержания о назначении машины).
Из 38 разработчиков 37 предпочитали мнемонические имена; только одно предпочтительное функциональное имя. Поэтому я назвал их все в честь рек (существует очень большой набор возможных имен, и многие из них короткие, легко запоминаются и быстро набираются).
Человеческий мозг очень хорошо приспособлен для придания значения именам. Если вы укажете запоминающиеся имена, люди довольно быстро запомнят, для чего эти имена используются, и будут их использовать. Если вы используете имена, взятые из некоторого общего фона (например, реки, элементы, звезды, округа, напитки, вы поняли), это помогает людям сразу узнавать имя хоста компании, когда они сталкиваются с ним; в противном случае утверждения вроде "все письмо попало на betelgeuse"может немного сбить с толку).
И наоборот, мои разработчики чувствовали, что на предыдущих должностях им было очень трудно вспомнить, что именно pr1ms001 был.
Но я должен добавить, что мы использовали CNAME во внутреннем DNS, чтобы предоставить функциональное имя для отображения мнемонических имен, поэтому, если вам действительно было легче запомнить, что главный почтовый сервер в первом кластере на сайте PR был pr1ms001, то DNS сообщит вам, что в настоящее время orwell. Кроме того, это позволило нам иметь много функциональных имен для каждой машины, поэтому, если вы всегда использовали функциональное имя, относящееся к функции, над которой работали, вы могли быть уверены, что pr1imap001 всегда будет указывать на сервер IMAP, даже если мы переместим эту функцию из orwell к rhine. И когда hudson умерла, мы могли изменить название замены, не затрагивая рабочие функции, так что у нас никогда не было сообщения "вы имеете в виду новый hudson или старый hudson?" спутанность сознания.
Во многом это зависит от того, работают ли ваши серверы pets или livestock.
Домашние животные получают индивидуальные имена. Они отличаются друг от друга, и мы заботимся об этих различиях. Когда человек заболевает, мы обычно стараемся вылечить его. Традиционно серверы были домашними животными.
Животноводство получает цифры. В основном они идентичны, и нас не волнует, какие различия есть, и мы стараемся их минимизировать. Когда один заболевает, мы кладем его и получаем другого. Полностью виртуализированные серверы, особенно серверы IaaS, такие как AWS, являются домашним скотом.
В самых сложных средах у вас есть смесь. Например, ваши веб-серверы почти наверняка являются домашним скотом. Если вам нужно больше, вы можете добавить еще несколько с помощью стандартной конфигурации; если вам не нужно столько, вы отключите некоторые. Ваши серверы баз данных в некоторых конфигурациях являются домашними животными. На каждом может быть много специальных настроек; вы даже можете запускать их на голом железе вместо виртуализации.
Конечно, в любой среде вы можете назвать СЛУЖБЫ и обращаться к ним напрямую. В любом случае это лучший способ; вашим разработчикам не нужно знать или заботиться о том, каково фактическое имя хоста службы. Имя хоста должно быть чисто оперативной деталью. Тогда подумайте о кодировании информации, которая может быть полезна вашему операционному персоналу, в именах хостов - например, часто бывает полезно указать, в каком центре обработки данных находится сервер.
Об этом уже говорилось здесь раньше ...
Моя рекомендация - сочетание функциональных имен и мнемонических имен ...
Если вы пишете заявку, и в ней нужно адресовать ccts-logserver1используйте это имя во всем, но сделайте это CNAME или псевдоним. Настоящее имя хоста может быть любым: фруктом или овощем, греческой мифологией или персонажем Сайнфельда ... но это дает вам некоторую гибкость, когда вам нужно связать настоящие функциональные имена, но сохранить то, что люди могут запомнить.
Подумайте о примере, где mango, сервер БД выходит из строя ... но заменяется чем-то другим, например peach. Возможно, существующие процессы и приложения должны увидеть 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 для сопоставления различных имен сервисов с именем хоста.
У меня смешанные чувства по этому поводу. Это, безусловно, экономит время, связанное с необходимостью искать, где находится определенное устройство. С другой стороны, гораздо сложнее запомнить, что делает данный сервер, когда он представлен с его именем хоста, по сравнению с нашей предыдущей системой, которая использовала драгоценные камни. Драгоценные камни вообще не имели никакого значения, но их было легко запомнить, потому что каждый человек мог создавать свои собственные связи.
Я думаю, единственный совет - остановиться на одной схеме, поскольку наибольшая путаница возникла при переходе от одной системы к другой.