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

Question

Я видел «The Coolest Server Names», и я видел еще smaller-ish question, связанных с моим, который, к сожалению, был закрыт.

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

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

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

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

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

Answer 1

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

Никогда не основывает свои имена машин на ...

• Hardware Машина получает выгружена все время, и вы не хотите, чтобы сделать слишком много работы, если вы меняете от IBM сервер на сервер Sun, на сервер Dell.

• Местоположение Оборудование и даже целые серверные помещения могут быть перемещены в соответствии с бизнес-требованиями или техническими проблемами.

• Предполагаемое использование Поскольку ваш продукт развивается, это также может предполагать использование каждого сервера. Наличие машины с именем «dbsrv», но в конечном итоге также выступает в качестве файлового сервера, запутывает.

• Владелец Человек, который «владеет» оборудованием (работником) может измениться из-за увольнений, увольнений и ходов внутри компании.

• Подсети Как я уже говорил, лаборатории могут перемещаться, и поэтому могут быть подсети. Одной из основных целей DNS является освобождение вас от привязки к определенному IP-адресу, поэтому зачем вам бесполезно связывать себя?

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

• Машины распространяются по всему региону Это то, что поддомены для в DNS. Вы могли бы иметь «west.company.com» и «east.company.com».

• Есть одна или несколько функций Не называть их на основании предполагаемого использования. Если вы назовете их на основе какой-то большой коллекции имен - например, греческих богов, вы, в конце концов, интуитивно узнаете, что zeus.east означает ваш основной сервер базы данных, а apollo.west - ваш резервный сервер баз данных. Худший случай, посмотрите его в таблицу.

• Сбалансированный груз или нет Вы можете использовать два подхода. У вас может быть уникальное имя для каждого узла за балансировщиком нагрузки, или вы можете сделать что-то вроде athena-1.east, athena-2.east и т. Д. В любом случае, балансировщик нагрузки (надеюсь) освободит вас от чрезмерного беспокойства что называется каждым узлом.

• Ожидание или нет Это не похоже на критерий, который должен влиять на имя машины.

То, что я в основном говорю,:

1. Раздельное ваше оборудование в различные региональные поддомены
2. Выберите схему именования с большим количеством имен (греческих богов в этом примере)
3. Дон 't основывайте имена по любому из критериев, упомянутых выше (предполагаемое использование, местоположение и т. д.)

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

Answer 2

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

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

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