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

Лучшие практики для переназначения IP-адресов / миграции серверов и приложений

Некоторые из этих вопросов будут сильно зависеть от приложений, но какие подходы вы используете при переносе приложений с одного сервера / платформы на другой и серверов из одного сегмента сети в другой?

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

Для «обычных» приложений (httpd, почта, службы каталогов и т. Д.), Какие проверки вы выполняете до, во время и после перемещения, чтобы убедиться в работоспособности перенесенного приложения / сервера?

Пример с Apache:

  1. резервное копирование каталога httpd conf
  2. изменить файлы httpd conf для использования нового IP-адреса сервера
  3. изменить (или добавить) IP сервера
  4. обновить записи DNS
  5. перезапустить Apache
  6. проверить, что веб-сервер по-прежнему обслуживает страницы
  7. перезагрузить сервер
  8. убедиться, что среда восстанавливается здоровой

Мне нужно было сделать около 4-5 больших проектов по перенумерации, так что возьмите все это с ведром соли :)

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

После теста на перезагрузку проводится обширный аудит брандмауэра (при условии, что ваша сеть разделена и все не находится в одном сегменте / подсети): выясните, какие серверы должны взаимодействовать друг с другом, и убедитесь, что вы полностью понимаете правила брандмауэра, которые пусть это общение произойдет.
Аудит брандмауэра также должен включать такие вещи, как NAT / двунаправленный NAT / сопоставление портов (для таких вещей, как общедоступные почтовые / веб-серверы).
Из этого аудита брандмауэра и хорошего понимания вашей среды вы можете придумать новые правила брандмауэра для нового IP-пространства. Если среда, которую вы переносите, какое-то время часто использовалась, вы, вероятно, также найдете (и закроете) кучу дыр, которые закрались за эти годы.

Для переноса отдельных приложений (и конфигурации ОС) ваш пример Apache очень хорошо обобщает. Как я могу сделать это как агностик ОС / приложения:

  1. Сделайте резервную копию всего, к чему вы собираетесь прикоснуться (файлы конфигурации, DNS и т. Д.), В автономное хранилище.
    (Если вы не уверены, что именно будет затронуто, сделайте полную резервную копию всей проклятой среды!)
  2. Обновите правила брандмауэра.
  3. Обновите службы имен (DNS, NIS, /etc/hosts & подобное, аналогичное, похожее).
    Если вы не используете DNS, возможно, сейчас самое подходящее время для его развертывания ...
  4. Отредактируйте файлы конфигурации системы (и не забудьте такие вещи, как resolv.conf)
    (Сделайте локальную копию каждого файла, прежде чем редактировать его, на случай, если вы напортачите, особенно если вы проигнорировали # 2 выше!)
  5. Отредактируйте файлы конфигурации приложения с теми же предостережениями, что и # 3
    (Сайты Postgres особенно обращают внимание на ограничения IP в pg_hba.conf)
  6. Перезагрузите компьютер хотя бы один раз, чтобы убедиться, что он выживает после перезагрузки.
  7. После того, как все будет перенесено, выключите и снова включите среду
    (Включая межсетевые экраны - на случай, если вы что-то пропустили в # 5)

Как правило, я сначала переношу сетевое оборудование (конфигурации коммутатора / маршрутизатора / прошивки), затем следуют службы имен (DNS) и аутентификация / авторизация (LDAP, NIS, AD и т. Д.), А затем «все остальное в том порядке, в котором оно должно быть. во время перезапуска ", что обычно неплохо работает.