Чтобы поддерживать много серверов, как вы даете имя своим серверам? Только по имени хоста сервера я хотел бы классифицировать тип службы сервера, будь то виртуальная машина или нет, этапы (альфа, бета, реальный), характеристики оборудования и так далее.
Есть идея?
В то время как я обычно закрываю подобные вопросы, я очень сильно отношусь к этой конкретной проблеме, поэтому я прикусил.
Схемы именования обычно можно разделить на два типа: мнемонические имена и функциональные имена.
Мнемонические имена - это имена, повторно используемые из какой-то другой области; Персонажи «Властелина колец» популярны, как и элементы, и я уверен, что вы видели много других; Я предпочитаю реки. Но дело в мнемонических именах в том, что они все проверенные имена из какой-то другой области человеческой деятельности, и они не содержат скрытой информации о машине. Это просто имена.
Функциональные имена - это имена, которые включают некоторые функции машины, иногда в простой форме (solaris-database-5.example.com), иногда в более непрозрачной форме (s10db01.example.com). В функциональные имена я включаю имена, которые не содержат никакой информации, если они не мнемонические (s00345.example.com).
По моему опыту, ИТ-группы и менеджеры любят функциональные схемы именования. Но в последний раз, когда я взял на себя полномочия по созданию схемы именования, я пошел и спросил людей, которые будут чаще всего использовать эти имена на повседневной основе: разработчиков.
Около 40 разработчиков, все, кроме одного, сказали, что предпочитают мнемонические имена. В хорошем имени есть что-то, что легко запомнить человеческий мозг, и мы хорошо спроектированы для того, чтобы вешать на эти имена записи о функциях (Стив Грегсон живет по соседству. Стив - пекарь. Стив водит Land Rover. Стив одолжил) мне его угловая шлифовальная машина). Мы, как вид, не приспособлены для навешивания подобных структур памяти на случайные числа.
Как вторичная схема, они попросили включить функциональные имена в записи CNAME. Таким образом, каждый хост получил мнемоническое имя в качестве основного имени; который жил и умер вместе с шасси; когда модернизировали шасси, оно получило другое название. Но функциональные имена все еще может использовать любой, кому они подходят, а поскольку они являются CNAME, многие могут указывать на один хост.
Таким образом, администраторы баз данных будут использовать pr1db01.example.com; почтовые парни будут использовать pr1ms01.example.com; ребята из приложений будут использовать pr1je03.example.com. Но все три CNAME указали на nile.example.com. Если функция удалялась, CNAME был перенаправлен. Если бы nile был обновлен, CNAME указывали бы на другое шасси. Но когда вы вошли в систему как pr1db01 или pr1ms01, системная подсказка сказала "nile". Когда я разослал электронное письмо, в котором говорилось, что нил опустится с 23:00 до 03:30 следующего дня, все прочитали то, что им нужно, в этом имени, потому что nile - это имя, используемое людьми, на которое мозгу легко вешать внутренние записи .
Вот что я рекомендую. И не забывайте, что DNS - это иерархическое пространство имен; используйте иерархию как часть вашей схемы именования, чтобы упростить ее, если вам нужно; sol1.dba.example.com может быть CNAME, отличным от sol1.mail.example.com).
Их, наверное, столько же, сколько организаций. Большинство организаций, которые я видел, не именуют серверы в соответствии с их функцией, но некоторые делают (некоторые просто нумеруют их произвольно). Местоположение сервера часто добавляется, но я почти никогда не видел, чтобы кто-то делал это на основе технических характеристик оборудования.
Любая комбинация данных, используемая для создания имени сервера, будет иметь равные недостатки (в частности, информация будет длинной, и вам нужно будет знать ее все, чтобы узнать имя сервера). Однако вы можете использовать какой-то код, например, 2-4 символа имени службы, необязательный v для виртуального, один символ для этапа (обычно используются имена dev, UAT и prod) и некоторый код, который соответствует оборудование. Возможно, вы могли бы назвать производственный контроллер домена dc1pvnv522us. Его можно расшифровать, и я думаю, что это соответствует устаревшим требованиям к именованию, но это уродливо.
Я действительно не могу придумать какой-либо практический способ поместить туда спецификации оборудования. Вы можете использовать номер модели, но это не сработает для виртуальных машин и не будет говорить ни о чем, что вы добавили. Я бы не советовал этого делать. Как правило, такие данные подробно обрабатываются с помощью какой-либо системы инвентаризации (возможно, электронной таблицы или программного обеспечения для отслеживания активов).
Я видел, как люди использовали местоположение и числовой код актива (например, vax00313d для сервера номер 313 в Vauxhall, часть среды разработки; спецификации сервера будут храниться в другом месте), а также соглашения, такие как функция сервера, местоположение, среда , и номер для уникальности являются общими (например, dc-vaxp1 для первого серийного DC в Vauxhall).
Используйте все, что вы сочтете удобным, но не пытайтесь упаковать слишком много информации в имя хоста.