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

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

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

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

Пример с Apache:

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

1 ответ

Решение

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

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

После теста перезагрузки проводится обширный аудит брандмауэра (при условии, что ваша сеть разделена и все не находится в одном сегменте / подсети): выясните, с какими серверами нужно общаться друг с другом, и убедитесь, что вы полностью понимаете правила брандмауэра, которые пусть это общение произойдет.
Аудит брандмауэра должен также включать в себя такие вещи, как NAT/ двунаправленный NAT/Port Mappings (для таких вещей, как общедоступные почтовые / веб-серверы).
Из этого аудита межсетевого экрана и хорошего понимания вашей среды вы можете придумать новые правила межсетевого экрана для нового 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)

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

Источник
Другие вопросы по тегам