Соглашения об именах функциональных серверов

Я видел "Самые крутые имена серверов, и я видел еще один вопрос меньшего размера, связанный с моим, который, к сожалению, был закрыт.

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

Приложения, с которыми работают серверы, могут быть собственными пользовательскими приложениями, или они могут быть более крупными поставщиками, такими как SharePoint. Они могут быть:

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

Уф! Подумайте, можно ли даже придумать соглашение, которое может адресовать все эти аспекты или значимые? Было бы неплохо услышать имя сервера (или запись DNS для него) и быть в состоянии сразу узнать, что он делает, и оно работает для того, чтобы новые ребята могли также ускориться. "sharepoint-IPC-1 down" может быть проанализирован на "внутренний веб-сервер SharePoint SharePoint" в Калифорнийском центре обработки данных, в котором первый node в балансировке нагрузки не работает! "... но это кажется чрезмерно сложным с первого взгляда.

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

Ответ 1

Вот некоторые общие рекомендации, которые я стараюсь соблюдать, основанные на ошибках, которые я сделал в прошлом.

Не основывайте свои имена машин на...

Аппаратные средства Машины все время меняются, и вам не нужно делать слишком много работы, если вы переходите с сервера IBM на сервер Sun, на Сервер Dell.
Местоположение Оборудование и даже целые серверные комнаты могут перемещаться в соответствии с бизнес-требованиями или техническими проблемами.
Предполагаемое использование. По мере развития вашего продукта также возможно использование каждого сервера. Имея машину с именем "dbsrv", но в конечном итоге также выступает в качестве файлового сервера, запутан.
Владелец Человек, который "владеет" оборудованием (работником) может измениться из-за увольнений, увольнений и ходов внутри компании.
Подсеть Как я уже говорил, лаборатории могут перемещаться, а также подсети. Одной из основных целей DNS является освобождение вас от привязки к определенному IP-адресу, поэтому зачем вам бесполезно связывать себя?

Теперь, некоторые предложения для описанной вами ситуации...

Машины распространяются по региону. Это то, что существуют в поддоменах в DNS. Вы могли бы иметь "west.company.com" и "east.company.com".
Имейте одну или несколько функций. Не называйте их на основе предполагаемого использования. Если вы назовете их на основе какой-то большой коллекции имен - например, греческих богов, вы, в конце концов, интуитивно узнаете, что zeus.east означает ваш основной сервер базы данных, а apollo.west - ваш резервный сервер баз данных. Худший случай, посмотрите его в электронной таблице.
Сбалансированность нагрузки или нет. Вы можете использовать два подхода. У вас может быть уникальное имя за node за балансировщиком нагрузки, или вы можете сделать что-то вроде athena-1.east, athena-2.east и т.д. В любом случае, балансировщик нагрузки (надеюсь) освободит вас от беспокойства многое о том, что названо каждым node.
Ожидание или нет. Это не похоже на критерий, который должен влиять на имя машины.

Я, по сути, говорю:

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

Попытка сделать что-то большее, чем это будет больше проблем, чем это стоит.

Ответ 2

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

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

Другая крайность использует только IP-адреса или имеет имена на основе IP-адресов, что также может привести к катастрофе, если вам когда-либо придется менять IP-адреса.