Приветствую. Давайте поговорим о важности настройки времени внутри вашей инфраструктуре. Сегодня не будет готовых скриптов и инструкций в стиле “делай раз, делай два”, речь пойдет о принципах и идеях.
Субъективный опыт показывает, что люди не задумываются о том, что часы, вообще говоря, должны показывать правильное время. При этом самое интересное заключается в том, чтобы время внутри инфраструктуры должно быть не столько правильным в смысле абсолютной точности синхронизации с атомными часами или каким-нибудь GPS. Куда важнее, чтобы время было одинаковым на всех устройствах.
Для чего это нужно? Ну, во-первых, есть сервисы, которые просто не смогут нормально работать, если разница составит больше некоторой величины. Во-вторых, сотрудники не должны думать над тем, куда правильно смотреть, чтобы узнать – пора идти обедать или еще рано, свободна переговорка или там еще кто-то сидит и так далее. В-третьих, любые расследования, опирающиеся на логи будут невозможны – синхронизировать происходящие события просто не получится, а держать в голове “тут плюс три минуты, а здесь минус час-тридцатьпять” вообще невозможно.
Ноги растут здесь из нескольких мест. Чаще всего сисадмины-линуксоиды доверяют синхронизации времени с мировыми часами и даже не думают сверять, как оно работает. Windows-админы находятся в чуть лучшем положении – в домене синхронизация времени происходит через механизмы AD и для этого не надо делать вообще ничего. Ну и все дружно забывают про standalone-сервера и разного рода железо типа свитчей и телефонов.
Собственно, что с этим делать? Глобально – выстраивать систему времени по аналогии с мировой. Конкретные решения зависят от масштабов вашей инфраструктуры, но идея примерно такая:
- Самый Главный Сервер Времени, который синхронизируется с мировыми часами. Он – базовая точка истины в смысле времени
- На втором уровне живут сервера, обслуживающие те или иные части инфраструктуры – домен, сеть, телефония, видеонаблюдение и прочее. Они, соответственно, синхронизируются с сервером из предыдущего пункта.
- Ну и “оконечные” устройства уже забирают время со своих серверов. Рабочие станции с контроллеров домена, телефоны смотрят на сервер IP-телефонии, камеры договариваются с сервером видеонаблюдения.
Плюсов у такого подхода несколько. Помимо снижения нагрузки на сервер времени, мы логически сегментируем сеть времени в соответствии с логической струтурой сети в целом. Мы же помним, что правильно разделять разные функции по разным IP-подсетям и вообще по разным каналам физически или VLAN? Соответственно, мы, с одной стороны, минимизируем траффик “наружу” из сегмента, а с другой – гарантируем насколько это возможно, что хотя бы на всех, например, камерах у нас будет одинаковое время, даже если центральный сервер времени будет недоступен. Ну и приятным бонусом не придется ковырять дополнительные дырки в файрволе для каждой новой железки, а потом администрировать это решето.
Разумеется, если сеть маленькая, ничто не мешает использовать тот же PDC в качестве сервера времени вообще для всего. Разумный подход никто не отменял – никто в здравом уме не станет делить неуправляемый свитч, два телефона, одну камеру и три компа на разные сегменты и поднимать миллион серверов для обслуживания всей этой радости. Но, в любом случае, при появлении нового хоть как-то управляемого устройства в инфраструктуре одним из первых шагов должна быть настройка синхронизации времени.
И да, если у вас в компании еще нет регламента по вводу в эксплуатацию нового оборудования и серверов – самое время начать его писать.