В университете, где я работаю, для большинства наших нужд IP-адресации используется DHCP. Рабочие станции и тому подобное.
Однако для серверов мы, очевидно, используем статические IP-адреса. Текущий метод выяснить, доступен ли IP-адрес, работает следующим образом.
- Угадайте IP-адрес в диапазоне центра обработки данных или найдите тот, который не отображается в таблице, создаваемой каждую ночь с управляемого коммутатора.
- отправьте ping, если ответит, вернитесь к шагу 1, если нет, перейдите к шагу 3
- nslookup на нем и посмотрите, назвал ли его кто-нибудь еще
Примерно в 90% случаев это работает нормально, но это трудоемко и не идеально. Учитывая 10 администраторов и около 300 серверов в главном центре обработки данных, а также еще около 50 серверов в нашем вторичном центре обработки данных, похоже, что должно быть решение.
Для статических IP-адресов (принтеры, МФУ, отдельные рабочие станции) в диапазонах рабочих станций Клиентские службы используютипплан. Кажется, в нем не хватает нескольких вещей, которые нам бы хотелось: регистрация тех, кто зарегистрировал IP-адреса; множественные входы в систему, желательно с LDAP, чтобы мы могли использовать существующие учетные записи; пользовательский интерфейс, достаточно простой, чтобы даже если вам придется использовать его всего полдюжины раз в год, он все равно был удобен.
Как вы управляете IP-адресацией вашего центра обработки данных? Вы отслеживаете ее? Есть ли "парень по IP-адресам"? Список на бумаге на стене? Какой-то вариант того, что мы делаем с помощью тыка, пока не найдем один?
решение1
Мы используем копию dokuwiki, со страницей для каждой используемой подсети. Всякий раз, когда что-то заказывается, оно обновляется, хотя мы достаточно малы, чтобы, если оно не обновляется для чего-то, мы, вероятно, можем вычислить, кто это сделал.
решение2
Я использую файл конфигурации DHCP (ISC dhcpd.conf или базу данных сервера Microsoft DHCP) в качестве «электронной таблицы». Электронные таблицы выпадают из данных и, как известно, неточны в сетях любого размера. Я позволяю новым устройствам получать адреса, а затем исправляю их с помощью резервирования позже. Если бы я работал в сетях достаточно больших, чтобы нуждаться в выделенных «парнях DHCP», я бы все равно следовал той же стратегии. Я бы выдвинул автоматизированный экспорт (вероятно, веб-ориентированный) конфигурации в таких случаях, чтобы группы, которые не администрируют DHCP, все равно могли видеть, как выглядят конфигурации.
Все статически назначенные устройства (которых я стараюсь оставить как можно меньше) отображаются как резервирования (с примечанием, указывающим, что это действительно статические назначения). Все устройства, которые могут получить DHCP, получают, а те устройства, которые должны «выглядеть» как статические адреса, зарезервированы.
Я придерживаюсь противоположной позиции, чем Кевин Купхал: я использую резервирование DHCP практически для всего, что возможно (мне приходилось перенумеровывать слишком много сетей слишком много раз). DHCP — это важная инфраструктурная служба, такая же важная, как DNS или даже базовая IP-маршрутизация, и я использую ее широко и слежу за тем, чтобы у меня был план отказоустойчивости на случай потери DHCP-сервера.
решение3
DNS. Мы регистрируем все назначенные IP-адреса на нашем DNS-сервере. Если адрес там указан, он занят. Если его там нет, я все равно пингую, чтобы убедиться, что кто-то не назначил его и не забыл зарегистрировать (это может случиться с любой схемой), но затем я назначаю его и вношу информацию в DNS.
Я не использую резервирование DHCP, поскольку для работы наших статически назначенных служб требуется работоспособность DHCP.
решение4
Я также использую DHCP для своих серверов, со статическим распределением на основе MAC-адресов, затем, когда нам нужно внести изменения или быстро найти IP сервера, мы просто заходим в конфигурацию нашего брандмауэра/маршрутизатора. Избавились от необходимости менять параметры DNS-сервера на более чем 40 виртуальных машинах, когда мы некоторое время назад перестраивали нашу инфраструктуру.