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

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

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

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

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

Каковы преимущества и недостатки обоих подходов и с какими реальными проблемами вам пришлось столкнуться с выбранным вами подходом?

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

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

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

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

Но я должен добавить, что мы использовали CNAME во внутреннем DNS для предоставления функционального имени для мнемонического сопоставления имен, поэтому, если вам действительно будет проще запомнить, что основным почтовым сервером в первом кластере на сайте PR был pr1ms001DNS, тогда 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 или тест P или V - физический или виртуальный S или N - сервер или сеть (у нас нет серверов Linux) последовательный номер для обеспечения уникальности Трехбуквенный код страны ISO 3166-1, указывающий, где находится устройство расположен.

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

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

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