Перенос веб-сервера в новый центр обработки данных и новый IP-адрес

У меня есть веб-сервер, на котором размещено более 200 доменов, но его нужно перенести в другой центр обработки данных и получить новый IP-адрес. Но так как все настройки DNS приходится обновлять вручную, я подумал, можно ли настроить какой-нибудь прозрачный прокси на старый IP-адрес, который перенаправляет весь http/https-трафик на новый IP. Чтобы посетители не обнаружили, что переход на DNS исправляется.

Моей первой мыслью было использовать для этого nginx, но я подумал, что это вызовет проблемы с SSL-сертификатами на доменах. Есть ли хороший способ решить проблему?

I use the following migration process in these cases:

1. Change DNS TTL to minimum value
2. Wait for DNS TTL to update
3. Copy keys / certificates to new server
4. Put site to maintenance mode
5. Synchronise files/database to new server
6. Set up reverse proxy from old server to new server
7. Remove maintenance mode on new server
8. Change DNS entries to point to new server

Step 6 ensures that end users don't end up to the old server even though their DNS has resolved to the old server IP.

After this, keep monitoring the old server logs to see when traffic has stopped there. Then you can dismantle the old setup.

Reverse proxy is set up using proxy_pass directive. If end user IP address is important information, you need to add it into HTTP headers on the old server -> new server requests, and tell new server to use the header value as the IP address.

Вы можете сначала решить (или оценить), чем вы хотите пожертвовать при переезде:

1. Простота перехода (если многие пункты ниже важны, переход будет проектом, а не задачей, у вас также может не быть необходимого опыта)
2. Время простоя (можно ли выполнить весь переход ночью или когда активность ваших пользователей минимальна?)
3. Непротиворечивость журналов доступа (это может быть очень важно, и прокси-сервер http или tcp будет маскировать удаленные IP-адреса)
4. Непротиворечивость данных, показываемых пользователям (приемлемо ли, что некоторые пользователи видят устаревшие данные?)
5. Возможность обновления контента на время
6. Безопасность данных (во многих случаях важно обеспечить абсолютную защиту данных от повреждения и/или утечек, даже если это означает некоторое время простоя)
7. Доступное время (ваш хостинг-контракт истекает)
8. Непротиворечивость сеанса пользователя (формально это включено в пункт 4, но заслуживает дополнительного рассмотрения из-за различных возможных мер по смягчению последствий)

В зависимости от комбинации вышеперечисленного вы можете использовать один или несколько из них:

• TCP-прокси (например, socat)
• HTTP-прокси (nginx, squid и т. д.)
• Комплексное решение для маршрутизации/VPN, позволяющее одному серверу отвечать на запросы по 2 IP-адресам.
• Репликация базы данных
• Миграция виртуальной машины

Вещи, которые вам понадобятся, независимо от выбранной стратегии:

1. Снижение TTL DNS (вы можете увеличить его после того, как все будет готово)
2. Бэкап — да, во время переходов и миграций случаются неприятные вещи.
3. План
4. План возврата, если план перехода не сработает.

Другой альтернативой является использование комбинации NAT, VPN и маршрутизации на основе политик.

Вы настраиваете VPN между серверами в старом и новом местоположениях, на сервере в старом местоположении вы используете целевой NAT для перенаправления входящего трафика по VPN. На сервере в новом местоположении вы используете политику маршрутизации, чтобы гарантировать, что ответы на трафик, пришедший из VPN, возвращаются обратно в VPN.