Как называть серверы в системе электронной почты под управлением Microsoft Exchange Server 2010?

Как называть серверы в системе электронной почты под управлением Microsoft Exchange Server 2010?

Время от времени я помогаю ИТ специалистам решать проблемы с системами электронной почты, построенными на базе Microsoft Exchange Server 2010 . Часто у меня вызывает удивление отсутствии логики в названиях серверов. Например их называют Server1, srv1 или alfa, beta.

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

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

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

Галактика—Планета—Континент—Страна—Область—Город—Район—Улица—Строение—Роль—Порядковый номер.

  • Серверы лучше называть, как можно короче, чтобы имена было удобно набирать в командной строке.
  • Названия лучше сокращать до трех букв, выкидывая гласные.
  • Для серверов с одинаковой ролью использовать цифры.
  • Использовать разделители «-«,»_» или вообще не использовать разделители.

Давайте рассмотрим  использование вышеописанной системы на примере.

  1. RU-MSK-DCS-01 — этот сервер находится в России, в городе Москва. Поскольку в Москве находится только один офис, поэтому сразу указываем роль сервера, DCS — домен контроллер, 01 — порядковый номер. Если появится еще один домен контроллер, то он будет называться RU-MSK-DCS-02, а файловый сервер RU-MSK-FIL-01. А домен контроллер в Германии, в Берлине будет называться DE-BRL-DCS-01.
  2. EU_FR_PRS_FIL_04 — этот сервер находится в Европе, во Франции, в городе Париже. Выполняет роль файл сервера. Всего в сайте уже установлено три файл сервера и этот будет четвертым.
  3. SPBDCS02 — это домен контроллер № 2 в офисе компании в городе Санкт Петербурге.
  4. SMR_HUB_22 — это двадцать второй транспортный сервер в Самарском офисе.
  5. 23-NVR-SPS-01 — код Краснодарского края 23.  Это SharePoint сервер в Новороссийске.   А 23-KRD-SPS-01 — это SharePoint сервер в городе Краснодаре Краснодарского края.

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

Если у Вас есть какая-то своя, более продуманная система, напишите об этом в комментариях.

UPDATE: Комментарии содержат очень важные дополнения.

Связанные записи:


, ,

  • Oleg Krylov

    Ну что тебе сказать, Паша… Статья вроде и годная, а вроде и не полная. Попробую дополнить.
    1. Имя сервера в FQDN может достигать 64 символов, что вроде бы и удобно и можно вписать все буковки, но не забываем, что NetBIOS имя ограничено 15 символами. От этого и надо плясать. Т.е. стараться не расходовать символы на длинные названия.
    2. Есть RFC по именованию серверов. Но он невнятен до ужаса. Одно там прописано и заслуживает интереса: в мире принято указывать город в виде кода его аэропорта. У Москвы во всех аэропортах код MOW, например.
    3. Использование разделителей съедает символ. Каждый раз. Если у тебя четкая Name Policy, и ты знаешь, что, допустим, два символа — Location, три — Service, два — Role ну и т.п., то символы разделения нужно выкинуть. Ты же способен запомнить номер мобильного телефона, даже если он записан в плоской форме, без привычного дробления.
    4. В пределах одного широковещательного домена (одна подсеть) избегай одинаковых имен. Например, у тебя есть корень домена и его дочка — рабочий домен. В нем два контроллера: s-mow-adds-dc01.domain.com и s-mow-adds-dc01.corp.domain.com, так вот главный сюрприз — ты не сможешь ввести второй контроллер, т.к. совпадают NetBIOS имена. Если ты юзаешь WINS — нельзя такого допускать даже в разных подсетях с маршрутизируемым NetBIOS — траффиком. Одно из решений в этом случае — сквозная нумерация узлов.
    5. Считаю, что нужно обязательно добавлять префикс — сервер это (S) или рабочая станция (W). Это сильно поможет при отборе в скриптах. Так же, рабочие станции делят на стационарные и мобильные. Я тут советовался с полубогом OpsMgr как-то, и мы пришли к выводу, что вполне достаточно суффикса, ну например (m-mobile), тогда машина приобретает вид w-mow-acc-001m (тип-регион-отдел-номер-тип станции), что тоже поможет в скриптовании. Получается, что у тебя группа машин (W), у которой есть подгруппа (m). Удобно.
    6. Location — спорный компонент имени, т.к. его можно указать в аттрибутах объекта и отбирать по нему. Т.е. если у тебя нехватка символов — выкидывай Location.
    Ну вот что вспомнил — написал. А вообще грамотная политика именования объектов — это целое искусство, учесть абсолютно все, да еще сделать это удобным — не всякий справится 🙂

  • Pavel Nagaev

    Олег, спасибо, это именно то, что нужно.  Народ сможет выбрать самое лучшее, что больше подходит к их ситуации.

    Кстати, а ссылку на RFC по именованию можешь показать?

  • Oleg Krylov

    Да, я доставлю ссылок. 🙂
    1. http://www.faqs.org/rfcs/rfc1178.html — невнятнейший RFC.
    2. http://en.wikipedia.org/wiki/IATA_airport_code — коды аэропортов (юзают IATA)
    3. http://support.microsoft.com/kb/909264 — очень годная КВ, в которой написано много того, чего делать нельзя. Перед разработкой Name Convention — must read!
    4. http://support.microsoft.com/gp/gp_namespace_master — еще один годный ресурс от MS, в стиле «мы тут вот для вас собрали все в одном месте»
    На самом деле RFC по именованию чуть меньше, чем дофига. Но они посвящены другим аспектам, в них просто затронуты вопросы имнования. Ну например, описание NetBIOS (1001-1002), описание требований к интернет-хостам и т.п.
    Есть еще один RFC, но аккуратно, он гомосячий!!! http://tools.ietf.org/html/rfc2100 — вот это творение неизвестного бойца. Чувак рекомендующий в качестве имен хостов «Cool hostname list», лежащий вот тут: http://namingschemes.com/ — конченный мудак и школота. Его читать не надо 🙂

  • http://galushka.com Dmitry Galushka

    Заметка важная, и комментарий Олега по делу. 
    А еще касаемо транспортных серверов надо не забывать менять имена на отправляющих коннекторах, иначе некоторые антиспам фильтры (в sendmail’е например) по текстовому шаблону считают длинные имена — диалам пулами.

    к примеру из практики:
    DSL or DialUp sender 2×2-e10-ch-1.2x2tv.ru [91.220.223.219] (1), please use Provider SMTP 

     

  • http://tails-up.blogspot.com Tatiana Ilchenko

    Коллеги, статья с дополнениями в первом комментарии — здорово. Смутил только один момент: в DNS символ underscore («_») является зарезервированным и не может использоваться в именах серверов (underscore используется в именах сервисных записей в DNS, ИМХО). Поправьте меня, если я не права 🙂 Желательно ткнуть пальцем в соответствующие RFC 🙂

  • Pavel Nagaev

    Таня, похоже на правду. Посмотри здесь. Соглашения об именах в Active Directory для компьютеров, доменов, узлов и подразделений

    DNS-имен может содержать только буквы (A-Z), цифры (0-9), знак минус (-) и точки (.).

    Disallowed characters:
    DNS host names cannot contain the following characters:
    запятая (,)
    тильда (~)
    двоеточие (:)
    восклицательный знак (!)
    знак (@)
    знак номера (#)
    знак доллара ($)
    Процент (%)
    знак крышки (^)
    амперсанд (&)
    apostrophe (‘)
    точка (.)
    круглые скобки (())
    фигурные скобки ({})
    символ подчеркивания (_)

    В статье есть ссылки на RFC

     

  • http://tails-up.blogspot.com Tatiana Ilchenko

    Угу. Я эти символы знаю, в общем-то 🙂 Это был сарказм (с) The Big Bang Theory

  • Pavel Nagaev

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

  • http://tails-up.blogspot.com Tatiana Ilchenko

    Паша, ну вот не смогла удержаться — я эти символы затвердила, когда первый свой DNS-сервер настраивала на BIND в FreeBSD 🙂 Там в конфигах белым по синему (в mcedit, в vi — белым по черному, ага) было в комментариях написано про underscores и другие спецсимволы, со ссылкой на RFC уже не помню даже, на какой именно. 
    PS Интересный какой движок — при редактировании текста комментария на FF ведет себя странно как-то…
     

  • http://www.buldakov.ru Stanislav Buldakov

    Ещё одно небольшое дополнение. Обычно внутренняя географическая структура организации известна. То есть каждый офис в структуре имеет какое-то внутреннее обозначение. А следовательно привязывать сервера к странам/городам смысла особого нет. Лучше использовать внутренее обозначение офисов. Для стороннего человека это может быть сложно, но для сотрудника который работает достаточно давно это будет проще, чем запоминать страну/город/улицу расположения соответствующего офиса при именовании серверов.

    Поэтому вместо RU-MSK-DCS-01 можно использовать, например, HQ-DCS-01.

  • Pavel Nagaev

    Стас, про внутреннюю привязку дельное замечание. У нас так сделано. Со стороны никто не поймет обозначений, но внутри сразу понимают, что эти коды значат.

    Таня, я как-то учился на курсах и меня поразило знание тонкостей работы PKI у преподавателя. Он сказал, что если раз настроить PKI под *nix, то вопросов про ключи, сертификаты и запросы не останется 🙂 Слишком много в Микрософт скрыто за кадром и автоматизировано.

  • http://tails-up.blogspot.com Tatiana Ilchenko

    Ну, наверное, да. И в принципе, это хорошая штука — действительно, учишься очень многому как бы из первоисточника. Мне, например, знания, приобретенные за несколько лет администрирования *nix-like серверов часто помогали уже после того, как это дело осталось в прошлом 🙂 И первое время на Windows-серверах злило отсутствие стандартных вещей для *nix — текстовых логов, на которые можно по-быстрому PERL-парсер написать на коленке, например 🙂 И эта автоматизация тоже первое время злила, особенно при диагностике ошибок и поиске проблемных мест 🙂

  • Pavel Nagaev

    Еще, как ни крути, помогают навыки программирования и знание PowerShell.

  • http://tails-up.blogspot.com Tatiana Ilchenko

    Это сейчас есть PowerShell, а тогда, кроме WMI-скриптов встроенного функционала не было никакого толком. 3-rd party не рассматриваем — оно и сейчас-то редко когда хорошее попадается, а тогда вообще полный ахтунг был 🙂

  • Pavel Nagaev

    Моя твоя прекрасно понимайт 🙂

  • http://modicus.su Modicus

    Спасибо! Полезная статейка! А у меня, поскольку всё в одном городе и организации шаблон именования серверов примерно такой:
    srv-db
    srv-dc1
    srv-dc2
    srv-exch
    srv-hv1
    srv-rdp
    Тоже всё гармонично и понятно, на мой взгляд. 🙂 А рабочие станции — ws, а чтоб отличать какие в домене, а какие в рабочей группе, добавляю префикс домена:
    vid-ws01
    vid-ws02
    vid-ws03
    vid-ws04 …
    Переименовал всё от предыдущего админа — так и учитывать легче. Раньше именами компов были фамилии пользователей и это была (_*_). Ушел пользователь, пришел новый — переименовывали. Какой-то комп устарел, какой-то сломался, какой-то перенесли, что-то на что-то меняется — концов не найти. А теперь у меня табличка в которой имена компов неизменны и никуда не пропадают — меняются только пользователи. Если с компом что-то случилось — просто помечаю в ней, что такого компа больше нет по такой-то причине, но имя так и остается закрепленным даже за трупом.
     

  • http://www.facebook.com/profile.php?id=1386655156 Павел Нагаев

    Ну тоже хорошо 🙂 Главное, чтобы было удобно самому и если вдруг начнется бурный рост компании, появление новых филиалов, то чтобы это органично вписалось в структуру.

  • http://modicus.su Modicus

    Добавлю по поводу ws: Опять же поддерживать пользователей легче, если нужно удаленно. Вопросы: «А как и где посмотреть имя компьютера?» — отпали с таким нововведением. Поскольку имена неизменны, можно смело клеить наклейки на корпуса, где крупными буквами написано имя компа в сети. 🙂
     

  • http://www.facebook.com/profile.php?id=1386655156 Павел Нагаев

    У нас сделано проще, в поле описание компьютера в AD скриптами вносится имя последнего работающего пользователя, потом powershell делается поиск имени пользователя, вычисляется имя компа и осуществляется помощь.

    Просто некоторым пользователям совсем не просто объяснить, как искать имя компьютера. 

  • Alex

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

  • Pavel Nagaev

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