Соглашение об именовании должно соответствовать производственным требованиям
Насколько важно распространить единую схему именования на все серверы инфраструктуры предприятия? Ответ зависит от числа серверов. Если оно невелико, то администратор может держать в памяти сведения о каждой машине: где она расположена и как ее отказ повлияет на инфраструктуру.
Иное дело — большая, распределенная инфраструктура, насчитывающая сотни серверов. Предположим, получен сигнал об аварии: служба мониторинга обнаружила неполадки в системе SERVER27. Администратору приходится вспоминать, что представляет собой SERVER27 и какие функции он выполняет. Если SERVER27 — сервер резервного копирования для производственной системы, то устранить неполадку можно позже, но если это сервер Microsoft Exchange Server для высшего руководства, значит, любые сбои должны немедленно привлечь внимание администратора. Возможность быстро отыскать серверы в случае аварии — главный и самый практичный аргумент в пользу соглашения об именовании.
Типовые методы
Выбирая тип соглашения об именовании, полезно учитывать приведенные ниже факторы.
- Коды офиса или местоположения. Если у компании много офисов, то расположение сервера удобно идентифицировать с помощью кода офиса или местоположения. Например, в одной известной мне компании используются коды местоположения ZKO, REO и DBO. Если офисный комплекс состоит из нескольких зданий, то можно добавить имена зданий, например REO1 и DBO2. Однако следует помнить, что, если офис закроется и серверы придется переместить, возникнут проблемы с именованием.
- Географические названия. Большое преимущество географических названий, таких как Лондон, Париж или Нью-Йорк, заключается в том, что они вряд ли изменятся до того, как предприятию потребуется заменить сервер. По этой причине многие компании используют в качестве основания имен трех- и четырехсимвольные сокращения географических названий, например LON, PAR и NYC.
- Индикатор функции. Сведения о местонахождении неисправного сервера полезны, но главное — информация о функциональном назначении сервера. Многие компании используют такие обозначения, как EXMBX (почтовый сервер Exchange), EXBHS (сервер-мост Exchange), EXPFS (общедоступная папка Exchange), GC (сервер Global Catalog), DHCP (DHCP-сервер) и WS (отдельная рабочая станция), чтобы указать роль конкретного компьютера в инфраструктуре.
- Идентификатор. Если в одном месте расположено несколько серверов определенного типа, нужно присвоить им уникальные идентификаторы. Одни компании нумеруют свои серверы, другие используют значения, которые несут дополнительную информацию о сервере. Например, аббревиатурой CL1 можно обозначить первый узел кластера, а PL380-4 — четырехпроцессорный сервер HP ProLiant DL380. Однако детализация может быть и излишней, обычно достаточно использовать простую схему нумерации.
Объединяем компоненты
Применяя такие соглашения об именовании, можно получить имена вида NYC1-EXMBX1 — первый сервер Exchange в офисе, расположенный в офисе 1 в Нью-Йорке. Некоторые администраторы рекомендуют указывать сообщество пользователей, которое обслуживают серверы Exchange, добавляя такие суффиксы, как -VIP (почтовые ящики руководителей), -FIN (почтовые ящики финансового отдела) и т. д. Поэтому в итоге имя может иметь вид NYC-EXMBX-FIN1.
Предупреждение: прежде, чем указать роль сервера в соглашении об именовании, следует получить разрешение от специалистов по безопасности. Иногда считают, что добавление такой информации делает серверы более заметными мишенями для атаки. Однако специалисты по безопасности порой склонны излишне перестраховываться и предпочитают, чтобы серверы имели имена типа AAAZZZ-ZXYY-003-AAZ. Если Windows позволяет использовать в именах серверов специальные символы, то группа безопасности одобрит их применение.
Зачем это нужно
Некоторые администраторы не придают значения именам серверов просто потому, что впоследствии их можно переименовать. Но на практике большинство администраторов никогда не меняют имен серверов и сохраняют первоначальные имена до тех пор, пока серверы не устаревают и постепенно не выводятся из инфраструктуры. Рекомендуется составить гибко изменяемое соглашение об именовании, которое соответствует ограничениям, накладываемым другими должностными лицами компании (например, аудиторами и сотрудниками подразделения ИТ-безопасности).
Тони Редмонд - редактор издания Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services. exchguru@windowsitpro.com