Каковы наиболее управляемые и интересные схемы именования серверов? [закрыто]

Мне любопытно узнать, какие схемы используются при именовании серверов …

6 Solutions collect form web for “Каковы наиболее управляемые и интересные схемы именования серверов? [закрыто]”

Во-первых, любой, кто выбирает схему именования, должен прочитать RFC 1178 – «Выбор имени для вашего компьютера» . Люди говорили об этой проблеме до тех пор, пока компьютеры получили имена, поэтому ознакомьтесь с тем, что говорили другие, прежде чем изобретать колесо.

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

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

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

Использование функционального имени (например, mail, web, fileserver) – хорошая идея для виртуальных машин, но плохая идея для физических хостов в моем опыте. Физические хосты часто заканчивают выполнение нескольких функций (даже если это не идеально), а отдельные функции будут меняться в отношении использования ресурсов и требований с течением времени, так что они будут перенесены на другие хосты.

Проблемы с темами :

  • Обычно они предоставляют небольшой пул имен. Как только у вас кончились римские боги, вы переходите на греческий? Повторно ли вы используете имя из отставного хоста, которое соответствует вашей теме именования, или выберите новое имя из новой темы, чтобы избежать проблем и путаницы, которые могут возникнуть в результате повторного использования имени?
  • Они позволяют антропоморфизировать ваши машины. Это плохо – компьютерам это не нравится. Если вы относитесь к своим машинам так, как будто у них отличная индивидуальность, вы рискуете игнорировать доказательства, которые противоречат вашим предположениям о том, как эта машина «ведет себя», а также иногда полагая, что ошибка связана с конкретной машиной, потому что «это Всегда плохо себя вести ».

Проблемы с схемами включают в себя:

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

В реальном мире вы находите обе используемые системы, иногда бок о бок. Например, по моему опыту высокопроизводительные вычислительные кластеры всегда имеют имена. Имя часто назначается головному узлу (который используется в интерактивном режиме), в то время как различные узлы кластера будут иметь имена, такие как compute-01, highmem-01, storage-01 и т. Д.

И, как упоминалось ранее, для виртуальных машин и физических хостов общепринято (и полезно) иметь разные схемы именования.

Под интересной категорией есть один из ответов переполнения стека

Элементы периодической таблицы. Мы также используем номер элемента в IP-адресе, поэтому

Водород = 192,168,0,1

Гелий = 192.168.0.2

и т.п.

Я ОЧЕНЬ твердо верю в именование физических серверов по их местоположению (например, код страны / код города / центра данных / пол / стойка / стойка-высота) и программные / виртуальные серверы только по их функциям ( платформа / функция / кластер / повторение). Я знаю, что это может сделать имена длиннее, чем называть их после семи гномов или что-то еще, но это отличный способ убедиться, что вы более «надежны в будущем» и структурированны с виртуализацией.

В качестве примера у нас есть серверы VMWare, называемые 044LONTH72G216 (это находит сервер именно в мире) с гостевыми серверами VM, такими как NESQLC11S08. Вы всегда можете создавать короткие имена для внутренней ИТ-команды, каждый из которых ссылается на эти более длинные, более организованные имена.

Надеюсь это поможет.

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

Люди знали, на каких серверах они работали регулярно, но при работе над новым проектом, перекрестном обучении или попытке помочь другому админу с чем-то все пропустит, потому что «никто не знал, что псалмы были почтовым сервером» или тому подобное.

Теперь мы вернулись к более описательной схеме именования.

Мы даем имена наших серверов в соответствии с их ролью, то есть тем, что они делают.

Таким образом, наши серверы имеют такие имена, как

- PDC - SQL - EXCHANGE - RDP - FILE etc.. 

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

Человекочитаемое имя с соответствующими метаданными, хранящимися в поле описания или аналогичном, похоже, менее подвержено проблемам PEBKAC.

  • Проблема с решением имен хостов на CentOS с использованием Bind
  • Запросы на домен с использованием неправильного имени домена
  • Действительно ли для имени хоста начинается цифра?
  • Хост-имена в fileе конфигурации HAProxy
  • Оптимальная практика для нескольких доменных имен SharePoint
  • Хорошее соглашение об имени хоста для нескольких серверов с множеством разных сервисов?
  • Повторное использование имен в схеме именования
  • Не удается подkeyиться к MySQL, используя «localhost», но используя «127.0.0.1», все в порядке?
  • IIS: имя хоста разбивает веб-website
  • Когда домен разрешен для serverа openvpn?
  • JBoss за проблемой имени узла NAT
  • Interesting Posts

    Отдельные домены против одного домена с псевдонимами

    Могут ли те же узлы Hyper-V быть добавлены на несколько serverов под управлением System Center Virtual Machine Manager?

    Стандарт Microsoft SQL Server с высокой степенью доступности без общего хранилища

    boost уровня лесов в период с 2000 по 2003 год, какие-либо предviewенные проблемы?

    Что означает тип ожидания SQL Server BACKUPIO?

    Сервер 2003 Natting и двойные Nics

    Какова важность имени хоста при настройке VPS?

    SAS диск, красный свет означает, что он не работает?

    Посещение веб-websiteа из command line показывает страницу по умолчанию Plesk

    Возникают ли последствия для использования gzip для веб-сервисов?

    Как настроить субдомен с помощью отдельного веб-хостинга и регистратора доменов?

    Как вkeyить DHCP для устройства «br0» для qemu?

    SSMS 2008 – не удается добавить планы обслуживания

    Диспетчер контактов Outlook с удаленным обменом через OWA

    Удаление принтеров из каталога, расположенного на старом сервере