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

Смена IP сервера без простоев

Я меняю серверы своего сайта example.org. IP старого сервера нельзя использовать для нового. Я хочу заменить старый сервер на новый с нулевым временем простоя.

На example.org работает множество различных сервисов, это не только приложение веб-сервера, это также почтовый сервер, сервер git, сервер mumble и т. Д.

Моя идея:

  1. Синхронизировать данные серверов, чтобы на новом сервере были данные, являющиеся копией старого сервера.
  2. Обновите доменное имя, чтобы example.org указывал на новый IP-адрес.
  3. На старом сервере настройте правила iptables для перенаправления всего трафика для http, https, smtp и т. Д. На новый сервер. Я не уверен, какие правила IP использовать для этого, поэтому мне нужна помощь.

Это звучит хорошо и все такое, но я чувствую, что возникнет проблема с SSL.

Например, если пользователь Алиса переходит на example.org в своем браузере, и он разрешается на старый IP-адрес, поскольку изменение DNS еще не распространено на нее, а затем старый IP-адрес перенаправляет ее на новый IP-адрес, я думаю, что она браузер бы взбесился. Он будет видеть новый IP-адрес с использованием сертификата SSL для example.org, в то время как example.org, очевидно, разрешается на другой IP-адрес, старый IP-адрес, поскольку кеш DNS не обновляется для Алисы. Таким образом, Алиса будет встречена огромным красным предупреждением SSL в ее браузере о том, что новый IP-адрес не принадлежит example.org.

Аналогичная проблема будет с почтовым сервером (SSL smtp) и другими службами, работающими на example.org. Как мне решить эту проблему?

Идеальным решением было бы каким-то образом использовать iptables, чтобы старый сервер проксировал новый сервер вместо перенаправления пользователя на новый сервер. Таким образом, пользователи, чей кеш DNS еще не обновлен, будут общаться следующим образом: [пользователь] <---> [старый сервер] <---> [новый сервер]. Они не будут знать, что новый сервер вообще существует, для них это будет похоже на их обычное общение со старым сервером. Моя единственная проблема с этим прокси-решением заключается в том, что новый сервер будет видеть исходные IP-адреса старого сервера, а не пользователей. Это может привести к поломке многих вещей, например, Fail2Ban может брандмауэром старого IP-адреса сервера на 10 минут, потому что некоторые пользователи вводили неправильный пароль почты несколько раз, по сути, запрещая доступ к почтовому серверу всем другим пользователям, у которых не обновлен DNS и, следовательно, использовать прокси.

Самый простой способ сделать это - не использовать прокси через старый сервер:

  1. Нижняя TTL быть чем-то вроде 300 секунд.
  2. Подождите хотя бы старую TTL для истечения срока действия кешей.
  3. Меняйте IP, когда трафика меньше.
  4. Измените TTL обратно к исходному значению.

Ваше максимальное время простоя теперь крайне низкое.

Для вашего беспокойства:

  • SSL / TLS не заботится об IP-адресах, а только об именах хостов. Возможно даже иметь кластер с несколькими IP-адресами, обслуживающий один и тот же сайт с одним и тем же сертификатом. Нет проблем с любым браузером.
  • Fail2ban имеет белый список: использовать ignoreip = чтобы сделать исключение для вашего старого сервера.
  • Для этого сценария нет необходимости реплицировать SQL в реальном времени. Заранее переместите вашу базу данных и сделайте сайты на старом сервере, чтобы использовать SQL с нового.
  • Не прокси-сервер SMTP. Вы можете ретранслировать всю почту через старый сервер на новый с помощью вашего MTA даже до смены DNS. Просто настройте старый сервер как вторичный MX и сделайте так, чтобы новый сервер доверял ему.

Вы можете изучить ssh-туннелирование, чтобы отправлять запросы на обслуживание на новый сервер. Я видел это, когда имя хоста разрешается на старый сервер, а затем перенаправляет трафик на новый сервер через ssh. Если на новом сервере старый IP-адрес сервера игнорируется, тогда у fail2ban не должно быть проблем.