Назад | Перейти на главную страницу

Управление статическими IP-адресами в дата-центре

Университет, в котором я работаю, использует DHCP для подавляющего большинства наших потребностей в IP-адресации. Рабочие станции и тому подобное.

Однако для серверов мы явно используем статические IP-адреса. Текущий метод определения доступности IP-адреса работает следующим образом.

  1. Угадайте IP-адрес в диапазоне центра обработки данных или найдите тот, который не отображается в электронной таблице, созданной каждую ночь с управляемого коммутатора
  2. пингуйте его, если он отвечает, вернитесь к шагу 1, если нет, перейдите к шагу 3
  3. nslookup и посмотрите, не назвал ли его кто-нибудь еще

Примерно в 90% случаев это работает нормально, но трудоемко и не идеально. Учитывая 10 администраторов и около 300 серверов в главном центре обработки данных и еще около 50 серверов в нашем вторичном центре обработки данных, кажется, что должно быть решение.

Для статических IP-адресов (принтеров, МФУ, случайных рабочих станций) в диапазонах рабочих станций, используемых Client Services Ипплан. Кажется, нам не хватает нескольких вещей, которые нам бы хотелось: регистрации того, кто потребовал IP-адреса; несколько логинов, желательно с LDAP, чтобы мы могли использовать существующие учетные записи; пользовательский интерфейс настолько прост, что даже если вам приходится использовать его всего полдюжины раз в год, это все равно легко.

Как вы управляете IP-адресацией вашего центра обработки данных? Вы это отслеживаете? Есть ли "парень IP-адреса"? Бумажный список на стене? Какой-то вариант того, что мы делаем с тычком, пока ты его не найдешь?

Я использую файл конфигурации DHCP (ISC dhcpd.conf или базу данных DHCP-сервера Microsoft) в качестве «электронной таблицы». Таблицы выпадают из-под данных и, как известно, неточны в сетях любого размера. Я разрешаю новым устройствам получать адреса, а потом исправлять их с оговорками. Если бы я работал в сетях, достаточно больших, чтобы нуждаться в выделенных «DHCP-специалистах», я бы все равно придерживался той же стратегии. В таких случаях я бы выполнил автоматический экспорт (возможно, через Интернет) конфигурации, чтобы группы, которые не администрируют DHCP, могли видеть, как выглядят конфигурации.

Все статически назначенные устройства (которых я стараюсь сохранить как можно меньше) показаны как зарезервированные (с примечанием, указывающим, что они действительно статические назначения). Все устройства, которые могут получать DHCP, делают это, а те устройства, которые должны «отображаться» как статические адреса, зарезервированы.

Я придерживаюсь противоположной позиции, как Кевин Купал: я использую резервирование DHCP почти для всего, что возможно (мне приходилось перенумеровать слишком много сетей слишком много раз). DHCP - важная инфраструктурная служба, такая же важная, как DNS или даже базовая IP-маршрутизация, и я активно ее использую и проверяю наличие плана аварийного переключения на случай, если я потеряю свой DHCP-сервер.

DNS. Мы регистрируем все назначенные IP-адреса на нашем DNS-сервере. Если адрес указан там, он занят. Если это не так, я все равно пингую, чтобы убедиться, что кто-то не назначил его, и забыл зарегистрировать его (может случиться с любой схемой), но затем я назначаю его и ввожу информацию в DNS.

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

Мы используем копию dokuwiki со страницей для каждой используемой подсети. Всякий раз, когда что-то заказывается, оно обновляется, хотя мы достаточно малы, чтобы, если что-то не обновлено для чего-то, мы, вероятно, сможем выяснить, кто это сделал.

На самом деле нет ничего плохого в использовании DHCP на IP-адресе сервера. Но для простоты вы всегда можете просто сохранить электронную таблицу Excel с указанием своих подсетей, IP-адреса, имени сервера, местоположения и того, к какому коммутатору / порту он подключен.

Вы можете отслеживать все свои статические общедоступные IP-адреса, ваши резервирования DHCP, гарантировать, что определенные IP-адреса всегда доступны в подсети для таких вещей, как IPS / Router / Firewall / printer.

Может быть, мне и моим коллегам просто нравится сохранять простоту, используя электронную таблицу в общей папке.

Я также использую DHCP для своих серверов со статическим распределением на основе MAC-адресов, а затем, когда нам нужно внести изменения или быстро найти IP-адрес сервера, мы просто заходим в конфигурацию нашего брандмауэра / маршрутизатора. Избавились от необходимости изменять параметры DNS-сервера на 40+ виртуальных машинах, когда мы недавно реорганизовали нашу инфраструктуру.

Вам нужна авторитетная ссылка на выделенные IP-адреса. Мы используем DNS. (Ну, на самом деле у нас есть настраиваемый perl-скрипт, который преобразует авторитетный текстовый файл в записи DNS и NIS-хостов. Если система также описана с адресом Ethernet, она также получает DHCP-резервирование на своем статическом IP.)

Обычно мне не нравится DHCP для серверов и управления серверами, потому что я встречал слишком много сценариев, когда сервер или BMC, требующий аренды DHCP, запрашивает его только один раз, во время загрузки, а мой DHCP-сервер еще не работает. .

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

Лично я пытаюсь убедить людей начать использовать DHCP для серверов со статическими назначениями или с длительным сроком аренды. Таким образом, ваши DHCP-серверы становятся вашей единой базой данных IP-адресов. Это непривычно для многих серверных парней, которые хотят быть уверены в том, что IP-адрес сервера не может случайно измениться. В любом случае ваши серверы также должны быть в DNS, и любые подключения к ним должны осуществляться через полное доменное имя.

SolarWinds имеет программное обеспечение, предназначенное для этого типа отслеживания (доступны как бесплатная, так и коммерческая версии). http://www.solarwinds.com/products/freetools/ip_address_tracker/

IP-адресация центра обработки данных ... У нас есть небольшая область DHCP на 8-10 адресов с очень низким временем аренды в подсетях центра обработки данных. Это позволяет нам настроить систему (насколько это возможно с динамическим IP-адресом), а затем запросить реальный адрес у DNS-парней. Ребята из DNS отслеживают, кто и зачем запрашивал.

Если эта область DHCP когда-либо заполняется (пока этого не произошло, но это может произойти), пора найти других администраторов и посмотреть, что эти серверы делают с таким временным адресом. Помогает то, что сервер DHCP не управляется DNS-парнями, поэтому мы можем сами искать аренду.

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

Но один из наших проектов «когда у нас есть время» - перейти на использование резервирования DHCP для всего, что требует статического адреса. Сейчас мы делаем это для большинства наших принтеров, и в последнее время это избавило от многих хлопот. У всех секретарей и исполнительных помощников есть принтеры, подключенные к сети, и в последнее время была проведена большая реорганизация. С резервированием DHCP, когда люди меняют местами отделы, мы «меняем» IP-адреса их принтеров в DHCP и приказываем им выключить / включить свои принтеры.