Мне любопытно посмотреть, какие схемы используются при именовании серверов ...
Мне любопытно посмотреть, какие схемы используются при именовании серверов ...
Ответы:
Прежде всего, любой, кто выбирает схему именования, должен прочитать RFC 1178 - «Выбор имени для вашего компьютера» . Люди говорили об этой проблеме до тех пор, пока компьютерам давали имена, поэтому прочитайте то, что сказали другие, прежде чем заново изобретать колесо.
Мои собственные мысли - я склонен разбивать политику именования на темы и схемы .
Использование темы (например, греческие боги, персонажи доктора Кто, бренды водки) хорошо работает в небольшой сети. Если у вас менее 20 хостов, скорее всего, у вас несколько конфигураций оборудования - возможно, каждый хост имеет уникальную конфигурацию. В таких случаях хорошо иметь возможность думать о каждой машине как об уникальной личности, потому что, скорее всего, это так.
Использование схемы (например, имя, составленное из элементов географического местоположения, положения стойки, идентификатора оборудования и т. Д.) Хорошо работает, когда у вас есть большое количество машин с одинаковыми аппаратными и / или программными конфигурациями. Это также хорошо работает, если вам нужно общаться о машине с людьми, которые не занимаются ею изо дня в день. Например, если вам нужно сообщить персоналу NOC о необходимости перезагрузить компьютер, лучше использовать имя, которое поможет им найти его в стойке, чем искать в стойке машину с определенной меткой.
Использование функционального имени (например, mail, web, fileserver) - хорошая идея для виртуальных машин, но плохая идея для физических хостов по моему опыту. Физические хосты часто заканчивают тем, что выполняли многократные функции (даже когда это не идеально), и отдельные функции со временем изменятся в использовании ресурсов и требованиях, так что они будут перенесены на другие хосты.
Проблемы с темами включают в себя:
Проблемы со схемами включают в себя:
В реальном мире обе системы работают, иногда рядом. Например, по моему опыту, высокопроизводительные вычислительные кластеры всегда имеют имена. Имя часто присваивается головному узлу (который используется в интерактивном режиме), в то время как различные узлы кластера будут иметь имена, такие как compute-01, highmem-01, storage-01 и т. Д.
И, как упоминалось ранее, для виртуальных машин и физических хостов характерно (и полезно) иметь разные схемы именования.
Под интересной категорией есть ответ из Stack Overflow
Элементы периодической таблицы. Мы также используем номер элемента в IP-адресе, поэтому
Водород = 192.168.0.1
Гелий = 192.168.0.2
и т.п.
Я ОЧЕНЬ твердо верю в именование физических серверов по их расположению (например, код страны / код города / код центра данных / этаж / стойка / стойка-U-высота) и серверов программного обеспечения / виртуальных машин только по их функциям ( платформа / функция / кластер / повторение). Я знаю, что это может сделать имена длиннее, чем называть их после семи гномов или чего-то еще, но это отличный способ убедиться, что вы более «ориентированы на будущее» и имеете дело с виртуализацией структурированным образом.
Например, у нас есть серверы VMWare с именем 044LONTH72G216 (он точно находит сервер в мире) с виртуальными машинами гостевых серверов, такими как NESQLC11S08. Вы всегда можете создать для них короткие имена для работы внутренней ИТ-команды, каждая из которых ссылается на эти более длинные, более организованные имена.
Надеюсь это поможет.
Мы начали с именования наших серверов с определенной темой (книги Библии), но по мере того, как наша ИТ-команда (и количество серверов) росла и становилась более специализированной - и, поскольку у нас была большая текучесть кадров, мы обнаружили, что любая система именования, которая не каким-то образом относиться к функции (или местоположению) сервера стал запутанным.
Люди знали серверы, на которых они работали регулярно, но при работе над новым проектом, перекрестном обучении или попытке помочь другому администратору что-то пропустили, потому что «никто не знал, что псалмы были почтовыми серверами» или тому подобное.
Теперь мы вернулись к более наглядной схеме именования.
Мы даем всем нашим серверам имена в соответствии с их ролью, то есть тем, что они делают.
Таким образом, наши серверы имеют такие имена, как
- PDC
- SQL
- EXCHANGE
- RDP
- FILE etc..
По моему опыту, серверы с нечитаемыми именами (то есть метод схемы) не управляемы. Я часто видел ошибочные символы, приводящие к тому, что на неправильном сервере выполнялась операция xyz, иногда с катастрофическими результатами.
Удобочитаемое имя со связанными метаданными, хранящимися в поле описания или аналогичном, кажется менее подверженным проблемам PEBKAC.
Ну, некоторые постоянные фавориты включают в себя:
Мы начали с Берта и Эрни в те времена, когда кластер из 2 microVAX 3400 был большой проблемой для компании. Мы какое-то время оставались на Улице Сезам - Bigbird, Elmo, Grover, thecount (финансовая система), но в итоге пришлось пойти по схеме. Какие именно элементы в схеме зависят от размера вашей компании, мы должны были включить:
Местоположение (двухбуквенное сокращение для города) Подразделение (компания была образована путем слияния 4-х сот, поэтому у нас было 3-х буквенное сокращение для них) Функция (PDC, mail, print, www и т. Д.) Серийный номер (I Мне всегда нравилось иметь год и месяц как часть серийного номера)
Был клиент один раз, который назвал серверы в честь кроликов Playboy. Однако это не было широко освещено за пределами ИТ. ;-)
Мне нравилось называть их в честь больших кошек, но потом появилась OS X и разрушила это для меня.
Другая популярность - это виды алкоголя. JimBeam, Beefeater, Stoli и др. Различные классы алкоголя были разными классами сервера. Джин для почтовых серверов, виски для баз данных, парктроник всегда был самогоном.
У нас обычно есть инициалы компании, сопровождаемые ее задачей, затем ее номером, т.е.
GSK-WEB-12
ST-DB-3
В университете, где я учусь, они используют имена разных персонажей из историй Астерикса и Обеликса. Такие как miraculix, astmatix и т. Д.