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

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

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.

  • Не удалось разрешить имя хоста в curl, wget, yum on Centos
  • Изменение имени хоста с помощью http? мягкая фетровая шляпа
  • JBoss за проблемой имени узла NAT
  • Проблема с изменением имени хоста в экземпляре CentOS, заданном по умолчанию,
  • Переслать имя хоста через мой маршрутизатор на другой компьютер для отладки
  • Имя хоста CentOS 6.0 Server при перезагрузке
  • Как установить имя хоста в MySQL? (OS X)
  • Разрешение имен хостов serverа samba
  • Apache Subversion и Sudo - Почему я не могу решить это имя хоста?
  • Как сделать виртуальную машину RHEL5 viewимой по имени хоста для ОС хоста
  • MySQL - имя хоста
  • Interesting Posts

    Как связь между двумя экземплярами Aplication и BD

    веб-server / iis не будет установлен на serverе 2012

    Контроль притяжения directoryа мариоlessками

    Exchange 2010 POP3 / IMAP4 / Транспортные службы жалуются, что не могут find certificate SSL после синего экрана

    Информация отзыва для certificateа безопасности недоступна при связывании данных Sharepoint с Microsoft Access 2010

    Samba не работает в локальной сети без подkeyения к Интерlessу

    Открыть настраиваемый порт для брандмауэра Windows IIS или групповой политики

    Как я могу измерить IOPS RAM / tmpfs из определенного приложения?

    Установить header ответа serverа в IIS7

    Шаги по устранению неполадок Windows ADFS

    Javascript для Windows XP и IE8 не будет работать, даже если вkeyена активизация активных сценариев

    Перенос Mailstore с Exchange 2003 на Exchange 2010 в новом домене

    Как настроить Glassfish + NGINX для обслуживания статических fileов с помощью NGINX?

    Как «перезапустить» определенный сетевой interface на RHEL?

    Как выбрать автоматическую замену fileа в cmd?