Время от времени я помогаю ИТ специалистам решать проблемы с системами электронной почты, построенными на базе Microsoft Exchange Server 2010 . Часто у меня вызывает удивление отсутствии логики в названиях серверов. Например их называют Server1, srv1 или alfa, beta.
Для систем с небольшим количеством серверов это не является недостатком, т.к. через некоторое время администратор привыкает к любым именам, знает, где находится сервер и какие функции выполняет.
При большом же количестве серверов, раскиданным по разным городам и выполняющим разные функции, отсутствие логики в названиях сильно усложнит управление системой, поэтому названия серверов просто обязаны иметь какую-то логику. Какой же принцип выбрать?
На самом деле существует хорошо известная и проверенная временем система именования объектов, нужно лишь адаптировать ее под свои нужды. Выглядит она следующим образом.
Галактика—Планета—Континент—Страна—Область—Город—Район—Улица—Строение—Роль—Порядковый номер.
- Серверы лучше называть, как можно короче, чтобы имена было удобно набирать в командной строке.
- Названия лучше сокращать до трех букв, выкидывая гласные.
- Для серверов с одинаковой ролью использовать цифры.
- Использовать разделители «-«,»_» или вообще не использовать разделители.
Давайте рассмотрим использование вышеописанной системы на примере.
- RU-MSK-DCS-01 — этот сервер находится в России, в городе Москва. Поскольку в Москве находится только один офис, поэтому сразу указываем роль сервера, DCS — домен контроллер, 01 — порядковый номер. Если появится еще один домен контроллер, то он будет называться RU-MSK-DCS-02, а файловый сервер RU-MSK-FIL-01. А домен контроллер в Германии, в Берлине будет называться DE-BRL-DCS-01.
- EU_FR_PRS_FIL_04 — этот сервер находится в Европе, во Франции, в городе Париже. Выполняет роль файл сервера. Всего в сайте уже установлено три файл сервера и этот будет четвертым.
- SPBDCS02 — это домен контроллер № 2 в офисе компании в городе Санкт Петербурге.
- SMR_HUB_22 — это двадцать второй транспортный сервер в Самарском офисе.
- 23-NVR-SPS-01 — код Краснодарского края 23. Это SharePoint сервер в Новороссийске. А 23-KRD-SPS-01 — это SharePoint сервер в городе Краснодаре Краснодарского края.
Выбор продуманной системы именования серверов при первоначальном планировании позволит Вам сэкономить время и силы при развитии вашей системы. Никто не знает, что будет завтра с вашей компанией и до каких размеров она может разрастись в ближайшие пять лет.
Если у Вас есть какая-то своя, более продуманная система, напишите об этом в комментариях.
UPDATE: Комментарии содержат очень важные дополнения.
Ну что тебе сказать, Паша… Статья вроде и годная, а вроде и не полная. Попробую дополнить.
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.
Ну вот что вспомнил — написал. А вообще грамотная политика именования объектов — это целое искусство, учесть абсолютно все, да еще сделать это удобным — не всякий справится 🙂
Олег, спасибо, это именно то, что нужно. Народ сможет выбрать самое лучшее, что больше подходит к их ситуации.
Кстати, а ссылку на RFC по именованию можешь показать?
Да, я доставлю ссылок. 🙂
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/ — конченный мудак и школота. Его читать не надо 🙂
Заметка важная, и комментарий Олега по делу.
А еще касаемо транспортных серверов надо не забывать менять имена на отправляющих коннекторах, иначе некоторые антиспам фильтры (в sendmail’е например) по текстовому шаблону считают длинные имена — диалам пулами.
к примеру из практики:
DSL or DialUp sender 2×2-e10-ch-1.2x2tv.ru [91.220.223.219] (1), please use Provider SMTP
Коллеги, статья с дополнениями в первом комментарии — здорово. Смутил только один момент: в DNS символ underscore («_») является зарезервированным и не может использоваться в именах серверов (underscore используется в именах сервисных записей в DNS, ИМХО). Поправьте меня, если я не права 🙂 Желательно ткнуть пальцем в соответствующие RFC 🙂
Таня, похоже на правду. Посмотри здесь. Соглашения об именах в Active Directory для компьютеров, доменов, узлов и подразделений
DNS-имен может содержать только буквы (A-Z), цифры (0-9), знак минус (-) и точки (.).
Disallowed characters:
DNS host names cannot contain the following characters:
запятая (,)
тильда (~)
двоеточие (:)
восклицательный знак (!)
знак (@)
знак номера (#)
знак доллара ($)
Процент (%)
знак крышки (^)
амперсанд (&)
apostrophe (‘)
точка (.)
круглые скобки (())
фигурные скобки ({})
символ подчеркивания (_)
В статье есть ссылки на RFC
Угу. Я эти символы знаю, в общем-то 🙂 Это был сарказм (с) The Big Bang Theory
А я, кстати, знак подчеркивания нет, нет, да использую в различных названиях. Хорошего в этом ничего нет, буду заменять на «-»
Паша, ну вот не смогла удержаться — я эти символы затвердила, когда первый свой DNS-сервер настраивала на BIND в FreeBSD 🙂 Там в конфигах белым по синему (в mcedit, в vi — белым по черному, ага) было в комментариях написано про underscores и другие спецсимволы, со ссылкой на RFC уже не помню даже, на какой именно.
PS Интересный какой движок — при редактировании текста комментария на FF ведет себя странно как-то…
Ещё одно небольшое дополнение. Обычно внутренняя географическая структура организации известна. То есть каждый офис в структуре имеет какое-то внутреннее обозначение. А следовательно привязывать сервера к странам/городам смысла особого нет. Лучше использовать внутренее обозначение офисов. Для стороннего человека это может быть сложно, но для сотрудника который работает достаточно давно это будет проще, чем запоминать страну/город/улицу расположения соответствующего офиса при именовании серверов.
Поэтому вместо RU-MSK-DCS-01 можно использовать, например, HQ-DCS-01.
Стас, про внутреннюю привязку дельное замечание. У нас так сделано. Со стороны никто не поймет обозначений, но внутри сразу понимают, что эти коды значат.
Таня, я как-то учился на курсах и меня поразило знание тонкостей работы PKI у преподавателя. Он сказал, что если раз настроить PKI под *nix, то вопросов про ключи, сертификаты и запросы не останется 🙂 Слишком много в Микрософт скрыто за кадром и автоматизировано.
Ну, наверное, да. И в принципе, это хорошая штука — действительно, учишься очень многому как бы из первоисточника. Мне, например, знания, приобретенные за несколько лет администрирования *nix-like серверов часто помогали уже после того, как это дело осталось в прошлом 🙂 И первое время на Windows-серверах злило отсутствие стандартных вещей для *nix — текстовых логов, на которые можно по-быстрому PERL-парсер написать на коленке, например 🙂 И эта автоматизация тоже первое время злила, особенно при диагностике ошибок и поиске проблемных мест 🙂
Еще, как ни крути, помогают навыки программирования и знание PowerShell.
Это сейчас есть PowerShell, а тогда, кроме WMI-скриптов встроенного функционала не было никакого толком. 3-rd party не рассматриваем — оно и сейчас-то редко когда хорошее попадается, а тогда вообще полный ахтунг был 🙂
Моя твоя прекрасно понимайт 🙂
Спасибо! Полезная статейка! А у меня, поскольку всё в одном городе и организации шаблон именования серверов примерно такой:
srv-db
srv-dc1
srv-dc2
srv-exch
srv-hv1
srv-rdp
Тоже всё гармонично и понятно, на мой взгляд. 🙂 А рабочие станции — ws, а чтоб отличать какие в домене, а какие в рабочей группе, добавляю префикс домена:
vid-ws01
vid-ws02
vid-ws03
vid-ws04 …
Переименовал всё от предыдущего админа — так и учитывать легче. Раньше именами компов были фамилии пользователей и это была (_*_). Ушел пользователь, пришел новый — переименовывали. Какой-то комп устарел, какой-то сломался, какой-то перенесли, что-то на что-то меняется — концов не найти. А теперь у меня табличка в которой имена компов неизменны и никуда не пропадают — меняются только пользователи. Если с компом что-то случилось — просто помечаю в ней, что такого компа больше нет по такой-то причине, но имя так и остается закрепленным даже за трупом.
Ну тоже хорошо 🙂 Главное, чтобы было удобно самому и если вдруг начнется бурный рост компании, появление новых филиалов, то чтобы это органично вписалось в структуру.
Добавлю по поводу ws: Опять же поддерживать пользователей легче, если нужно удаленно. Вопросы: «А как и где посмотреть имя компьютера?» — отпали с таким нововведением. Поскольку имена неизменны, можно смело клеить наклейки на корпуса, где крупными буквами написано имя компа в сети. 🙂
У нас сделано проще, в поле описание компьютера в AD скриптами вносится имя последнего работающего пользователя, потом powershell делается поиск имени пользователя, вычисляется имя компа и осуществляется помощь.
Просто некоторым пользователям совсем не просто объяснить, как искать имя компьютера.
Скрипты в ad и повер шелл это конечно круто, но, господа, не проще ли дать задание эникеям пронумеровать системные блоки наклейками и тогда пользователь сможет назвать имя своего компьютера быстрее чем запускать смотреть его скриптами?
Системные блоки часто стоят под столами, а на них лежат бумаги или еще что. В общем пользователь не всегда может назвать имя компьютера.