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

Миграция сервера, минимизация неправильных запросов DNS

У меня большой сайт (500 тыс. Уникальных посетителей в день), и я собираюсь перейти к другому хостеру.

Моя новая машина настроена и протестирована, все файлы скопированы, поэтому я почти готов изменить IP-адрес моего домена в моем регистраторе.

Теперь я хотел бы знать, есть ли возможность минимизировать количество людей, обращающихся к старому серверу, потому что их информация DNS еще не обновлена.

Иногда на обновление может уйти много времени, и люди, попадающие на старый сервер, могут нарушить синхронизацию моего сайта.

Есть ли способ заставить людей перейти на новую машину со старой?

Нет, ну да, но на самом деле нет.

Установите очень низкий TTL для DNS перед миграцией (например, 5 минут), это говорит клиенты должны кэшировать DNS только на 5 минут, а затем обновить. Теоретически, после того, как вы измените IP-адрес в своем DNS, у клиентов должно пройти всего 5 минут, чтобы начать использовать новый IP-адрес сервера.

К сожалению, теория не соответствует действительности. Некоторые интернет-провайдеры и DNS-провайдеры кэшируют записи длиннее установленного TTL (я видел, как некоторые интернет-провайдеры кэшируют TTL 5 минут в течение 48 часов), и, короче говоря, вы абсолютно ничего не можете сделать с технической точки зрения, чтобы помешать им делать это, даже хотя они не должны. И, увы, убедить всех ваших пользователей перейти на OpenDNS - не лучшая идея.

Когда я перемещал большие сайты раньше, я обычно следую этому процессу;

Настройте синхронизацию между двумя (новым и старым) серверами баз данных.

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

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

Другой вариант, и, вероятно, самый простой для реализации, - это установить прокси на старый сервер, который пересылает любые запросы на новый сервер. Пользователи на старом сервере будут испытывать некоторую задержку из-за дополнительных переходов в прокси-сервере, но с умной конфигурацией кэширования вы, вероятно, сможете минимизировать это.

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

Конечно, всего этого можно было бы избежать, если бы все следовали стандартам, которым они должны были следовать.

Использовать обратный прокси

Если у вас есть root-доступ к обеим системам, вы можете проксировать трафик со старого сервера на новый, используя Apache mod_proxy.

С помощью mod_proxy вы можете настроить обратный прокси со старого сервера на новый. Таким образом, все действия клиента происходят на одном сервере. При тщательном планировании у вас может быть минимальное время простоя (например, время, необходимое для перезапуска apache).

Мне нравится этот подход, поскольку он позволяет вам тестировать перед изменение DNS. Хорошая проверка работоспособности в последнюю минуту.

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

Некоторые сайты используют канонические URL-адреса, что может вызвать проблемы. Один из приемов - установить IP-адрес нового сервера в файле / etc / hosts на старом сервере. Затем вы можете добавить что-то подобное в настройку вашего прокси:

ProxyPass / http://www.domain.com/
ProxyPassReverse / http://www.domain.com/

Вот и все. Вы можете сделать это и для HTTPS.

Также обратите внимание, что многие интернет-провайдеры игнорируют значения TTL. Comcast, ATT и другие будут обновлять свои кеши DNS только несколько раз в день.

Мысль о двух крошечных дополнениях к sam: если доступ к базе данных может допускать задержку между двумя серверами, вы также можете настроить оба для использования базы данных на новом компьютере. (Если вам нужна безопасность, вы можете использовать SSH-туннель или VPN).

Другой вариант - настроить старый компьютер так, чтобы он отвечал на все запросы с временными перенаправлениями HTTP (307) на новый IP-адрес (или вы можете настроить временное доменное имя, например www1.yoursite.com, с новым IP-адресом, и использовать его в перенаправляет).