Как назвать файловый сервер

Обновлено: 24.11.2024

В этой статье описываются соглашения об именовании учетных записей компьютеров в Windows, доменных имен NetBIOS, доменных имен DNS, сайтов Active Directory и организационных единиц (OU), определенных в службе каталогов Active Directory.

Применимо к: Windows Server 2012 R2
Исходный номер базы знаний: 909264

Обзор

В этой статье обсуждаются следующие темы:

Допустимые символы для имен
Минимальная и максимальная длина имени
Зарезервированные имена
Имена, которые мы не рекомендуем
Общие рекомендации, основанные на поддержке Active Directory в малых, средних и крупных развертываниях.

Все объекты, названные в Active Directory или в AD/AM и LDS, подлежат сопоставлению имен на основе алгоритма, описанного в следующей статье:

В этой статье это соглашение об именовании применяется к именам компьютеров, подразделений и сайтов.

Имена компьютеров

Имена компьютеров NetBIOS

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

Имена компьютеров NetBIOS не могут содержать следующие символы:

знак больше (>)

Имена могут содержать точку (.). Но имя не может начинаться с точки. Использование не DNS-имен с точками разрешено в Microsoft Windows NT. Точки не должны использоваться в Microsoft Windows 2000 или более поздних версиях Windows. Если вы обновляете компьютер, NetBIOS-имя которого содержит точку, измените имя компьютера. Дополнительные сведения см. в разделе Специальные символы.

В Windows 2000 и более поздних версиях Windows компьютеры, являющиеся членами домена Active Directory, не могут иметь имена, полностью состоящие из цифр. Это ограничение связано с ограничениями DNS.

Дополнительную информацию о синтаксисе имен NetBIOS см. в разделе Синтаксис имен NetBIOS.

Минимальная длина имени: 1 символ

Максимальная длина имени: 15 символов

16-й символ зарезервирован для обозначения функций, установленных на зарегистрированном сетевом устройстве.

Специальные символы: точка (.)

Точка разделяет имя на идентификатор области NetBIOS и имя компьютера. Идентификатор области NetBIOS — это необязательная строка символов, идентифицирующая логические сети NetBIOS, работающие в одной и той же физической сети TCP/IP. Чтобы NetBIOS работал между компьютерами, компьютеры должны иметь одинаковый идентификатор области действия NetBIOS и уникальные имена компьютеров.

Использование областей NetBIOS в именах является устаревшей конфигурацией. Его не следует использовать с лесами Active Directory. Дополнительные сведения об областях NetBIOS см. на следующих веб-сайтах:

Имена узлов DNS

DNS-имена могут содержать только буквы (A–Z), цифры (0–9), знак минус (-) и точку (.). Символы точки допускаются только в том случае, если они используются для разделения компонентов имен доменного стиля.

В системе доменных имен (DNS) Windows 2000 и DNS Windows Server 2003 поддерживаются символы Unicode. Другие реализации DNS не поддерживают символы Unicode. Избегайте использования символов Unicode, если запросы будут передаваться на серверы, использующие реализации DNS сторонних производителей.

Для получения дополнительной информации посетите следующие веб-сайты:

Имена узлов DNS не могут содержать следующие символы:

пробел (пусто)

Подчеркивание играет особую роль. Это разрешено для первого символа в записях SRV по определению RFC. Но новые DNS-серверы также могут разрешать это в любом месте имени. Дополнительную информацию см. в разделе Соответствие ограничениям имен для хостов и доменов.

Все символы сохраняют форматирование регистра, кроме символов американского стандартного кода для обмена информацией (ASCII).

Первый символ должен быть буквенным или цифровым.

Последний символ не должен быть знаком минус или точкой.

Двухсимвольные пользовательские строки SDDL, перечисленные в списке известных SID, использовать нельзя. В противном случае операции импорта, экспорта и принятия контроля завершатся сбоем.

При регистрации имени хоста DNS недопустимые символы заменяются символом дефиса (-).

Минимальная длина имени: 2 символа

Максимальная длина имени: 63 символа

Максимальная длина имени хоста и полного доменного имени (FQDN) составляет 63 байта на метку и 255 байтов на полное доменное имя.

Windows не разрешает имена компьютеров, длина которых превышает 15 символов, и вы не можете указать имя хоста DNS, отличное от имени хоста NETBIOS.Однако вы можете создать заголовки хоста для веб-сайта, размещенного на компьютере, который затем подпадает под действие этой рекомендации.

В Windows 2000 и Windows Server 2003 максимальное имя хоста и полное доменное имя используют стандартные ограничения длины, упомянутые ранее, с добавлением поддержки UTF-8 (Unicode). Поскольку длина некоторых символов UTF-8 превышает один октет, вы не можете определить размер путем подсчета символов.

Контроллеры домена должны иметь полное доменное имя менее 155 байт.

Зарезервированные имена в соответствии с RFC 952

Для получения дополнительной информации см. rfc952.

Зарезервированные имена в Windows

При создании имен для DNS-компьютеров в новой инфраструктуре DNS Windows Server 2003 руководствуйтесь следующими рекомендациями:

Выбирайте имена компьютеров, которые пользователям легко запомнить.
Указать владельца компьютера в имени компьютера.
Выберите имя, описывающее назначение компьютера.
Для символов ASCII не используйте регистр, чтобы указать владельца или назначение компьютера. Для символов ASCII DNS не учитывает регистр, Windows и приложения Windows не сохраняют регистр во всех местах.
Сопоставьте доменное имя Active Directory с основным DNS-суффиксом имени компьютера. Дополнительную информацию см. в разделе "Разрозненные пространства имен" ниже.
Используйте уникальное имя для каждого компьютера в вашей организации. Избегайте одинаковых имен компьютеров для компьютеров в разных доменах DNS.
Используйте символы ASCII. Это гарантирует совместимость с компьютерами, на которых установлены более ранние версии Windows, чем Windows 2000.
В именах компьютеров DNS используйте только символы, перечисленные в RFC 1123. Эти символы включают A-Z, a-z, 0-9 и дефис (-). В Windows Server 2003 DNS допускает использование большинства символов UTF-8 в именах. Не используйте расширенные символы ASCII или UTF-8, если только все DNS-серверы в вашей среде не поддерживают их.

Доменные имена

Вот подробная информация о доменных именах NetBIOS и доменных именах DNS.

Доменные имена NetBIOS

Доменные имена NetBIOS могут содержать все буквенно-цифровые символы, за исключением расширенных символов, перечисленных в разделе Запрещенные символы. Имена могут содержать точку, но имена не могут начинаться с точки.

Имена компьютеров NetBIOS не могут содержать следующие символы:

знак больше (>)

Имена могут содержать точку (.). Но имя не может начинаться с точки. Использование не DNS-имен с точками разрешено в Microsoft Windows NT. Точки не должны использоваться в доменах Active Directory. Если вы обновляете домен, NetBIOS-имя которого содержит точку, измените имя, перенеся домен в новую структуру домена. Не используйте точки в новых доменных именах NetBIOS.

Минимальная длина имени: 1 символ

Максимальная длина имени: 15 символов.

16-й символ зарезервирован для обозначения функций, установленных на зарегистрированном сетевом устройстве.

Зарезервированные имена в Windows

Имена обновленного домена могут содержать зарезервированное слово. Однако в этой ситуации не удается установить доверительные отношения с другими доменами.

Специальные символы: точка (.).

Использование областей NetBIOS в именах является устаревшей конфигурацией. Его не следует использовать с лесами Active Directory. В этом нет внутренней проблемы, но могут быть приложения, которые фильтруют имя и предполагают имя DNS при обнаружении точки.

Доменные имена DNS

Для получения дополнительной информации посетите следующие веб-сайты:

Имена доменов DNS не могут содержать следующие символы:

пробел (пусто)

Подчеркивание играет особую роль. Это разрешено для первого символа в записях SRV по определению RFC. Но новые DNS-серверы также могут разрешать это в любом месте имени.Дополнительную информацию см. в разделе Соответствие ограничениям имен для хостов и доменов.

При продвижении нового домена вы получаете предупреждение о том, что символ подчеркивания может вызвать проблемы с некоторыми DNS-серверами. Но он по-прежнему позволяет вам создать домен.

Все символы сохраняют форматирование регистра, кроме символов ASCII.

Первый символ должен быть буквенным или цифровым.

Последний символ не должен быть знаком минус или точкой.

Минимальная длина имени: 2 символа

Максимальная длина имени: 255 символов

Максимальная длина имени хоста и полного доменного имени (FQDN) составляет 63 байта на метку и 255 символов на полное доменное имя. Последнее основано на максимально возможной длине пути для доменного имени Active Directory с путями, необходимыми в SYSVOL , и должно соответствовать ограничению 260 символов MAX_PATH.

Пример пути в SYSVOL содержит:

Может содержать пользовательский ввод, например имя файла сценария входа, поэтому может достигать значительной длины.

Доменное имя AD FQDN появляется в пути дважды, так как длина доменного имени AD FQDN ограничена 64 символами.

Пространства доменных имен с одним ярлыком

Проблемы, связанные с однокомпонентными пространствами имен, включают:

DNS-имена с одной меткой нельзя зарегистрировать с помощью интернет-регистратора.

Домены с однокомпонентными DNS-именами требуют дополнительной настройки.

Службу DNS-сервера нельзя использовать для обнаружения контроллеров домена в доменах с однокомпонентными DNS-именами.

По умолчанию члены домена под управлением Windows Server 2003, члены домена под управлением Windows XP и члены домена под управлением Windows 2000 не выполняют динамические обновления однокомпонентных зон DNS.

Разрозненные пространства имен

Как возникают несвязанные пространства имен:

Первичный контроллер домена Windows NT 4.0 обновляется до контроллера домена Windows 2000 с использованием исходной версии Windows 2000. В элементе "Сеть" на панели управления определяется несколько суффиксов DNS.

Домен переименовывается, когда лес находится на функциональном уровне леса Windows Server 2003. И основной суффикс DNS не изменяется, чтобы отразить новое доменное имя DNS.

Последствия разрозненного пространства имен:

Контроллер домена динамически регистрирует свои записи местоположения службы (SRV) в зоне DNS, соответствующей его доменному имени DNS. Однако контроллер домена регистрирует свои записи узлов в зоне DNS, которая соответствует его основному суффиксу DNS.

Дополнительную информацию о непересекающихся пространствах имен см. в следующих статьях:

Другие факторы

Леса, подключенные к Интернету

Пространство имен DNS, подключенное к Интернету, должно быть поддоменом домена верхнего или второго уровня пространства имен DNS Интернета.

Максимальное количество доменов в лесу

В Windows 2000 максимальное количество доменов в лесу — 800. В Windows Server 2003 и более поздних версиях максимальное количество доменов на функциональном уровне леса 2 — 1200. Это ограничение является ограничением многозначных несвязанных атрибутов. в Windows Server 2003.

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

Не используйте в качестве доменного имени название существующей корпорации или продукта. Позже вы можете столкнуться с конфликтом имен.

Избегайте использования общего имени, например, domain.localhost. Другая компания, с которой вы объединитесь через несколько лет, может последовать тому же принципу.

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

Избегайте использования символов подчеркивания (_) в именах доменов. Приложения могут быть очень послушны RFC и отвергать имя, а также не будут устанавливаться или работать в вашем домене. Кроме того, у вас могут возникнуть проблемы со старыми DNS-серверами.

Не используйте название бизнес-подразделения или подразделения в качестве имени домена. Бизнес-подразделения и другие подразделения будут меняться, и эти доменные имена могут вводить в заблуждение или устареть.

Не используйте географические названия, которые сложно написать и запомнить.

Избегайте расширения иерархии доменных имен DNS более чем на пять уровней от корневого домена. Вы можете сократить административные расходы, ограничив пределы иерархии доменных имен.

Если вы развертываете DNS в частной сети и не планируете создавать внешнее пространство имен, зарегистрируйте доменное имя DNS, созданное для внутреннего домена. В противном случае вы можете обнаружить, что это имя недоступно, если вы попытаетесь использовать его в Интернете или подключитесь к сети, которая подключена к Интернету.

Названия сайтов

Мы рекомендуем использовать действительное DNS-имя при создании нового имени сайта. В противном случае ваш сайт будет доступен только там, где используется DNS-сервер Microsoft. Дополнительную информацию о допустимых DNS-именах см. в разделе DNS-имена хостов.

Для правильной работы демона in.named требуется файл конфигурации и четыре файла данных.

Файл конфигурации

Файл конфигурации главного сервера — /etc/named.conf. Файл конфигурации содержит список имен доменов и имен файлов, содержащих информацию о хостах. Дополнительную информацию о файле named.conf см. в файле named.conf.

Имена файлов данных DNS

Если вы внутренне непротиворечивы, вы можете назвать файлы данных зоны как угодно. Такая гибкость может привести к некоторой путанице при работе на разных сайтах или при обращении к разным руководствам и книгам по DNS.

Например, имена файлов, используемые в руководствах Sun и на многих сайтах Solaris, отличаются от тех, которые используются в книге DNS и BIND, опубликованной O'Reilly & Associates, и обе эти номенклатуры имеют некоторые отличия от общедоступных. -domain Name Server Operations Guide for BIND .

Кроме того, в этом руководстве и другой документации по DNS используются общие имена, определяющие основное назначение файла, и конкретные примеры имен для этого файла в примерах кода. Например, в этом руководстве используется общее имя hosts при описании функции и роли этого файла, а примеры имен db.doc и db.sales в примерах кода.< /p>

Необходимы следующие файлы данных.

/var/named/named.ca Дополнительные сведения о файле named.ca см. в разделе Файл named.ca. Пока вы внутренне непротиворечивы, вы можете назвать этот файл как угодно.

/var/named/hosts См. Файл hosts для получения дополнительной информации о файлах hosts.

/var/named/hosts.rev Дополнительную информацию о файле hosts.rev см. в разделе Файл hosts.rev.

/var/named/named.local См. Файл named.local и дополнительную информацию о файле named.local. Пока вы внутренне непротиворечивы, вы можете назвать этот файл как угодно.

Файлы $INCLUDE

Включаемый файл — это любой файл, имя которого указано в операторе $INCLUDE() в файле данных DNS. Файлы $INCLUDE можно использовать для разделения различных типов данных на несколько файлов для вашего удобства. См. файлы $INCLUDE.

Для справки в следующей таблице сравниваются имена файлов BIND из вышеупомянутых источников.

Имена О'Рейли или другие имена

Ю.К. Имена Беркли

Содержание и назначение файла

/etc/named.conf, одинаковое имя файла для всех трех источников

BIND 8.1 добавляет новый файл named.conf, заменяющий прежний файл named.boot. Этот файл конфигурации добавляет безопасность, параметры запуска, ведение журнала. Он указывает тип сервера, на котором он работает, и выборочно применяет параметры для каждой зоны или сервера, а не для всех зон или серверов. Он содержит список доменных имен и имена файлов данных.

/etc/resolv.conf , одинаковое имя файла для всех трех источников

Этот файл находится на каждом DNS-клиенте (включая DNS-серверы) и определяет серверы, к которым клиент запрашивает информацию DNS.

Этот файл устанавливает имена корневых серверов и перечисляет их адреса.

Общие: hosts Примеры: db.doc, db.sales

Общий: db.domain Примеры: db.movie, db.fx

Этот файл содержит все данные о машинах в локальной зоне, которую обслуживает сервер.

Общий: hosts.rev Примеры: doc.rev

Общий: db.ADDR Примеры db.192.249.249 db.192.249.253

В этом файле указана зона в домене in-addr.arpa., специальном домене, допускающем обратное сопоставление (адрес-имя).

Общий: db.cache Пример: db.127.0.0

В этом файле указан адрес локального интерфейса замыкания на себя или локального хоста.

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

Ошибка новичков номер один – присвоение имен серверам в зависимости от их роли. Конечно, это позволяет очень легко выяснить, какой компьютер что делает, но что происходит, когда вам нужно перепрофилировать сервер? Или добавить больше ролей? Внезапно ваш файловый сервер стал вашим сервером Redis, и вы бьетесь головой о стену, потому что назвали его file-server-01.

Еще одна ошибка новичка — называть его по местоположению. Это лучше, но компьютеры могут и двигаются. В облаке это не так уж плохо, но регионы, как правило, очень большие, поэтому вам придется использовать массу номеров: mycorp-aws-west-392.

Вот как я люблю это делать. Выберите тему, совершенно не связанную с вычислительной техникой, и придерживайтесь ее. Один из моих любимых — использовать злодеев Марио (большой респект Nintendo!). Это очень запоминается, и эта роль больше не является частью имени машины. Кроме того, это совершенно весело. Если у вас есть физические коробки, наклейте на них наклейку. (Для физических блоков ВМ сам хост ВМ должен иметь собственное имя. Не начинайте наклеивать наклейки для каждого гостевого контейнера, иначе у вас получится липкий беспорядок.)

Редактировать. Некоторые отмечают, что в больших развертываниях у вас закончатся имена. Я хотел бы добавить, что вы всегда можете смешивать и сопоставлять имена (docker делает что-то подобное для контейнеров): mario-bowser-pikachu.

Если вы в конечном итоге будете использовать персонажей видеоигр, скорее всего, вы столкнетесь с спрайтами в пиксельной графике для выбранных вами имен. Для большего удовольствия на хостах Linux я добавляю пиксельное представление имени хоста в /etc/motd, чтобы каждый раз, когда я вхожу в систему, я получал красивое графическое представление окна, в которое я вхожу.

Сценарий, который я использовал для создания, доступен в виде краткого описания. Он довольно прост в использовании и использует таблицу поиска цветов, чтобы найти ближайший цветовой код ANSI, поэтому он отлично работает с большинством изображений (просто держите их маленькими, например, около 48 x 48).

Я делаю что-то подобное для именования ролей сервера (в частности, контейнеров Docker), но это тема для другой статьи.

Кстати, есть RFC, который охватывает все это. RFC1178 (спасибо xtagon!)

Автор Джулиан Диаз

Советы по теме

Удаленный доступ к ноутбукам IPython через SSH

Найти все диапазоны IP-адресов в ASN

Добавить самоподписанный SSL-сертификат на Android (для просмотра)

25 ответов

Отличная вещь, мне нужно это использовать!

Планеты полезны для нас. У нас небольшое количество серверов. Когда у нас закончатся планеты, мы перейдем к звездам и более удаленным объектам. :)

Хороший материал, мне очень нравятся поздравления в пиксельной графике.
Мы столкнулись с теми же вопросами, когда выбирали имена для наших серверов, и остановились на названиях пабов :)

Я называю все свое электронное оборудование в честь персонажей греческой мифологии, например, мой Macbook называется Zeus, iPhone — Thor, а мой Wlan Router — Olymp.
Мне очень нравится идея использовать ascii-арт имени сервера при входе в систему.

Не следует называть материальные вещи, иначе к ним привязываешься.

Ваша идея очень классная, но вы не можете использовать эту схему именования, если у вас тысячи серверов, потому что она не масштабируется. Если вы используете какое-либо программное обеспечение для оркестровки и, например, хотите повлиять только на веб-серверы, это очень легко сделать, если в имени хоста у вас есть что-то, с чем вы можете сопоставить, например, если имя хоста будет lpcaweb, это можно сопоставить, используя ' Интернет'.

Вы должны сделать правильный выбор и принять во внимание масштаб вашей инфраструктуры.

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

Мне вообще не нравится использовать числа, потому что нам, людям, их трудно запомнить — весь аспект идентичности теряется. По крайней мере, лучше объединить кучу тем вместе, чем начинать использовать цифры (начать с персонажей «Звездных войн», перейти к «Звездному пути», затем к «Вавилону-8» и т. д.). Быть привязанным к серверу, потому что он назван в честь вашего любимого персонажа, может быть даже хорошо; мы не хотим, чтобы они пострадали и упали! :)

Что происходит, когда вы понимаете, что оборудование, которое вы выделили для своих веб-серверов, лучше подходит для роли базы данных? lpcaweb-01 — неудачное имя в этом случае. Именно таких ситуаций я стараюсь избегать.

PS: ваше программное обеспечение для оркестровки должно иметь возможность группировать серверы, не полагаясь на имя хоста.

На самом деле я с этим полностью не согласен. Именование машин на основе темы — это весело для небольшого подмножества (или вашей домашней сети), но на самом деле это кошмар. Вот несколько сценариев.

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

например. www01.dc1, www02.dc1, www01.dc2 и т. д.

Это позволяет чрезвычайно легко обучить нового сотрудника тому, для чего предназначены эти машины и в каком центре обработки данных находится эта машина. Что касается переименования сервера. Насколько сложно изменить запись в /etc/ и перезагрузиться (на всякий случай). Раньше мы называли каждую машину в честь погодных явлений (буря, ледник, ветер, торнадо, ураган и т. д.), но примерно на 200 узлах стало очевидно, что 1) мы выскребали дно бочки, чтобы получить новые классные имена и 2) новые сотрудники были настолько сбиты с толку, что потребовались месяцы, чтобы разработать основы с нуля.

Что касается многофункционального сервера в целом, повторюсь, он работает, если ваша сеть небольшая, однако, когда вы начинаете расти, вы действительно хотите перейти к модели разделения ответственности, когда один узел выполняет одну задачу и делает это хорошо. (философия Unix). Кстати, я использую OpenVZ для целой кучи инфраструктуры. Это означает, что один узел занимает около 4 ГБ дискового пространства (служебные данные находятся в службах NAS), и, таким образом, можно дешево раскрутить гостевые системы, чтобы хорошо выполнить еще одну задачу.

например. База данных, Интернет, Мониторинг, Обратные прокси, Системный журнал.

Это, конечно, означает, что я НИКОГДА не «переназначаю» сервер для другой задачи в любое время, НИКОГДА. Серьезно, это просто приводит к абсолютному раздуванию серверов/дисков и приводит к огромному количеству неизвестных, когда дело доходит до аудита программного обеспечения (версий и обновлений).

Еще один момент (как также упоминается @pincoded для аналогичного метода) заключается в следующем.

Я использую saltstack для управления сервером и нацеливания на хосты с помощью команд, подобных приведенным ниже;

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

В целом, статья интересная, только в большей степени посвящена небольшой сетевой структуре.

Фото: Трэвис Уайз

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

Мне было интересно узнать от вас, какие схемы именования вы используете для серверного оборудования и т. д.?

Вы предпочитаете использовать в качестве примера более традиционный Win.web.clus1 или все, что связано с Бартом, Лизой и Гомером?

179 ответов

Сэмюэл Смит

Мы используем префикс для сайта (в каком городе находится сервер), а затем краткое описание того, что сервер делает. Например, XXXFS01 будет служить файлом в местоположении XX. XXXFS02, если был второй файловый сервер.

Оно дополняет название рабочего стола/ноутбука, которое имеет тот же префикс, а затем возрастающее число. XXDT01 или XXNB01 (ноутбуки)

Точно

-Алдрин-

КримсонКидА

Мы просто используем: "Функция местоположения"

Лично я ненавижу добавлять серийные номера и служебные теги в имена машин. Просто делает имя сложным и невозможным для запоминания без причины ИМХО.

Дэйв4113

Мы используем те же соглашения, что и Samuel и Neally. Мы делаем организацию, местоположение, продукт или тест, цель, количество. Я также не использую имена повторно.

Джереми Р. – СПС

Физическое или виртуальное: P
Марка ОС: W
Функция устройства: APPSRV
Номер устройства: 003

Физический или виртуальный:
P = физический
V = виртуальный

Бренд ОС:
A = Cisco ASA
D = Dell Storage Center
E = ОС Equalizer
F = Встроенная прошивка
I = Cisco IOS
L = Linux
M = VMWare
N = ОС Brocade Network
U = Dell FluidFS
V = VNXe
W = Windows
X = Force 10

Функции устройства:
APPSRV = сервер приложений
BAKSRV = сервер резервного копирования
BLDENC = корпус блейд-сервера
DIRSRV = сервер каталогов
EMLSRV = сервер электронной почты
FIREWL = Брандмауэр
FTPSRV = FTP-сервер
HYPVIS = Гипервизор
NASSRV = Файловый сервер NAS
PDU = Блок распределения питания
RPS = Резервный источник питания
SANSRV = SAN Appliance
SQLSRV = SQL Server
SW-BLD = коммутатор блейд-корпуса
SW-SAN = специальный коммутатор SAN
SW-SVR = общий сервер/сетевой коммутатор
ИБП = источник бесперебойного питания
WEBSRV = веб-сервер

Номер устройства.
Номер устройства, соответствующий первым четырем частям схемы именования.

MHunt

Я использую Greek Gods, наша команда разработчиков использует морскую тему (наш бизнес основан на морской тематике) для своих серверов, которая меняется в зависимости от использования.

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

Я также никогда не использую имя повторно (независимо от того, насколько оно крутое ;)).

Джереми Р. – СПС

Раньше я использовал имена супергероев, но затем некоторые из наших клиентов начали сходить с ума, увидев активность, происходящую в "Человеке-пауке"; которое я буду защищать как лучшее имя для веб-сервера.

Для одного сайта я просто использую роль. DC-01, Fileserver-01 и т. д. Имена планет, персонажей и даже «Звездных войн» закончатся.

Элсворт

Ну, я фанат StarTrek, так что ENTERPRISE, DEFIANT и т. д.Но если серьезно, мне нравится использовать местоположение/функцию/нумерацию.

Глобальный или отдел, поэтому файловый сервер предназначен для предприятия, а не для конкретного отдела.

WFILEUS01 = Windows, файловый сервер, США (глобально)

WFILEACCT01 = Windows, файловый сервер, учет

WEXCHUS01 = Windows, Exchange, США (глобальные)

WSQLACCT01 = Windows, SQL, учет

Бен8917

MHunt

Джереми Р. - SPS написал:

Вот мой.

Образец: PWAPPSRV003

Физическое или виртуальное: P
Марка ОС: W
Функция устройства: APPSRV
Номер устройства: 003

Физический или виртуальный:
P = физический
V = виртуальный

Номер устройства:
номер устройства, который соответствует первым четырем частям схемы именования.

Моя цель — добиться максимальной управляемости. Я выбираю имена на основе этого.

Правильное имя сервера должно содержать информацию, которая поможет вам выполнять свою работу лучше и быстрее. Но это не должно быть имя, которое быстро устаревает или требует постоянного обслуживания.

Название я начинаю с кода сайта (одна буква). В случае виртуализации следует буква «V». Далее идет последний октет IP. Затем указание на его функцию.

K60V = кампус Keene в x.x.x.60 и это виртуальный хост (V)

SV11FILE = виртуальная машина кампуса шерифа по адресу x.x.x.11, на которой хранятся файлы

Но независимо от того, как вы их назовете, используйте DNS, чтобы упростить себе жизнь. Вот почему это здесь.

K-WSUS — это CNAME для сервера WSUS кампуса Keene. K-KMS — это CNAME для сервера Keene KMS. Меня не волнует (и мне не нужно знать), что на самом деле они оба находятся на виртуальной машине под названием KV21IT.

Крейг582

Серверы: инициалы школы, назначение, номер — если требуется, например. наши файловые серверы работают по принципу ABCFS01

Для наших администраторов это либо то же самое, что и их имя пользователя, либо название и номер соответствующего отдела/должности — если требуется

Ноутбуки идут по строкам «L-», затем либо имя пользователя сотрудника, которому они назначены, либо идентификатор и номер соответствующего отдела, например. Л-АВС-02

Дж.НФамер

Я начал с греческих букв. Это сработало очень хорошо; и если бы у меня кончились, я планировал использовать иврит или что-то в этом роде.

Когда я начал виртуализировать, я назвал их в честь городов. Поскольку они должны были быть на нескольких языках, я бы использовал названия городов в этих странах, например, для серверов с французским языком, имя Париж, Марсель, Ницца, Тулуза, Ренн, для серверов в Германии Берлин, Мюнхен, Кельн, Франкфурт и др.

Мои зарубежные коллеги хотели это изменить; они хотели использовать 2 буквы кода страны, за которыми следуют 3 цифры, а затем 4 символа для описания функции. Например. DE123DCS1. Не так легко запомнить.

Однако я пошел дальше до того, как это стало необходимо. В новом месте использовался очень загадочный метод, основанный на местоположении или предполагаемом физическом местоположении. Например, сервер вполне мог находиться в дата-центре, но использовался сайтом в Лондоне, поэтому был назван UKLON-145-FPS. Все еще непросто.

Последнее место имело еще более причудливую структуру; хотя было хорошо то, что они использовали букву T для обозначения тестового сервера и P для рабочего сервера, что немного облегчало жизнь.

Мы в MNX заняты созданием нового центра обработки данных для наших облачных сервисов. Мы начинали как консалтинговая компания, предоставляющая управляемые услуги Linux, а это значит, что мы столкнулись с множеством различных клиентских сред и равным количеством схем именования оборудования… не все из них хороши. Эта проблема восходит к тому времени, когда существовали компьютеры, и у каждого свое мнение о «лучшем» способе именования хостов. Большинство методов вначале работают нормально, но быстро становятся громоздкими по мере расширения и адаптации инфраструктуры с течением времени.

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

Сначала я расскажу о схеме именования, а затем расскажу о некоторых тонкостях и обосновании нашего выбора

А записи

Для начала назовите каждый хост (с помощью метода, подходящего для вашей операционной системы) и установите его DNS-запись A на случайно выбранное слово, взятое из списка:

Существует множество наборов слов на выбор, но рекомендуемый нами список слов взят из проекта мнемонического кодирования Орена Тироша. Эти 1633 слова были выбраны специально, чтобы быть короткими (4-7 букв), фонетически отличными друг от друга, легкими для понимания по телефону, а также узнаваемыми на международном уровне. Список мнемонических слов должен быть гораздо менее подвержен опечаткам и транспонированным символам по сравнению с более структурными именами. На эти слова ушло много времени и исследований, и их свойства делают их идеальными для нашей цели.

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

Записи CNAME

Затем назначьте одну или несколько записей DNS CNAME, чтобы охватить полезные функциональные сведения о машине, такие как географическое положение, среда, рабочий отдел, цель и т. д. Это вся информация, которая будет отражена в вашей базе данных CMDB, и на нее будет легко ссылаться.

Записи CNAME — это то, что разработчики должны знать и использовать для подключения сервисов. Сохранение согласованной структуры этих имен снизит умственные усилия, необходимые для запоминания имени хоста, когда оно вам понадобится…

Стандартная структура CNAME

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

Указать географию

После вашего доменного имени добавьте субдомен, указывающий на географическое положение хоста. Используйте 5-значный код Организации Объединенных Наций для торговых и транспортных местоположений (UN/LOCODE) на основе адреса центра обработки данных хоста. Он охватывает более конкретные места, чем что-то вроде кодов аэропортов IATA, и по-прежнему является четко определенным стандартом.

Указать среду

Далее укажите среду, частью которой является узел:

dev — разработка
tst — тестирование
stg – постановка
prd — Производство

Они должны быть основаны на той модели процесса, которой вы придерживаетесь для управления выпусками… у вас может быть больше или меньше обозначений, а также такие среды, как песочница, обучение и т. д.

Укажите назначение и серийный номер

Наконец, укажите базовую категорию функции хоста и добавьте серийный номер:

приложение — сервер приложений (не веб-сайт)
sql — сервер базы данных
ftp — SFTP-сервер
mta — почтовый сервер
dns — сервер имен
cfg — Управление конфигурацией (puppet/ansible/и т. д.)
mon — сервер мониторинга (nagios, sensu и т. д.)
prx – прокси-сервер/балансировщик нагрузки (программное обеспечение)
ssh – хост перехода/бастиона SSH
sto — сервер хранения
vcs — программный сервер управления версиями (Git/SVN/CVS/и т. д.)
vmm — диспетчер виртуальных машин
web — веб-сервер

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

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

Удобные названия

Помимо стандартной структуры, вам могут понадобиться дополнительные записи CNAME для удобства использования таких слов, как веб-почта, cmdb, puppet и т. д. р>

Особые случаи

Сетевое и силовое оборудование

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

con — Консоль/терминальный сервер
fwl — брандмауэр
lbl – балансировщик нагрузки (физический)
rtr — маршрутизатор L3
swt — переключатель L2
vpn — VPN-шлюз

pdu — блок распределения питания
ИБП — источник бесперебойного питания

…вам, вероятно, также понадобится географическая информация центра обработки данных. Вы по-прежнему можете добавлять записи CNAME для получения более конкретной информации, такой как ядро/распределение, общедоступные и частные и т. д., если это необходимо.

Дополнительные и виртуальные IP-адреса

Почтовые и именные серверы

Для ваших почтовых серверов и серверов имен вы должны использовать записи DNS A, поскольку записи MX и NS никогда не должны указывать на псевдоним CNAME. Тем не менее, у вас может быть более одной записи DNS A, поэтому придерживайтесь обычной схемы и добавляйте что-то еще для общедоступных записей MX и NS.

Конфигурация DNS

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

В целом, наша схема именования также позволяет предотвратить непреднамеренное раскрытие информации, публикуя только короткие случайные имена хостов, а функциональные имена разрешаются исключительно во внутренней сети. Это немного безопасности из-за неясности, но кое-что следует учитывать. (Обратите внимание: вам придется изменить соглашение об именах «особых случаев», если вы хотите скрыть и их).

Частная сеть и внешняя адресация

Вы также можете воспользоваться внутренним разрешением DNS для раскрытия адресов частной сети и внеполосных/IPMI/iDRAC-адресов. Домены должны совпадать с другими записями, но опять же, используйте правильный субдомен. Обратите внимание, что передовой опыт предписывает не использовать поддельные TLD , поскольку ICANN может зарегистрировать их в любое время, и объединение сетей становится более сложным.

Полный пример схемы именования

Емкость

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

Советы и рекомендации

Вам следует удалить потенциально запутанные слова, такие как 'электронная почта', из списка слов мнемонической кодировки, если это технический жаргон для вашей среды.
Сохраняйте аббревиатуры назначения одинаковыми по длине и всегда совпадайте с заполнением серийного номера (т. е. не используйте 01 в некоторых местах и просто 1 в других, всегда используйте длиннее 01 для всего).
Фактические сокращения, которые вы используете, не важны. Просто выберите схему, убедитесь, что она задокументирована, и придерживайтесь ее.
Проще всего использовать аббревиатуры целей в несколько обобщенном виде, поскольку более подробную информацию можно получить из базы данных CMDB.
Несмотря ни на что, вся информация должна храниться в базе данных CMDB и быть легко доступной!
Задайте несколько записей CNAME, если это логично, но имейте в виду, что чем больше у вас записей, тем больше потребуется поддерживать.
Максимально автоматизируйте это.
Мы написали короткий скрипт под названием genhost, который поможет вам случайным образом выбирать и отслеживать слова, которые вы использовали для имен хостов.

Заключение

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

Читайте также: