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

10

Я прочитал несколько важных вопросов здесь, но я все еще не уверен, что лучший ответ.

Я перемещаю пару сайтов с IP-адреса "1.abc" на "2.def". На данный момент в существующем DNS я установил все TTL на 300 секунд, и у меня есть новая зона DNS, готовая к использованию (на AWS Route 53), с новыми серверами имен и всеми TTL на 60 секунд. Поэтому я считаю, что я готов с точки зрения DNS. После переезда через несколько дней я установлю TTL на более разумные номера на маршруте 53.

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

Я не понимаю, как браузер пользователя (кэш) играет роль в этом. Мои собственные эксперименты с локальным файлом hosts (Win7) говорят мне, что в браузере есть что-то, что не позволяет старому IP-адресу идти - мне пришлось перейти в историю -> очистить все, чтобы показать новое местоположение сайта даже послеipconfig /flushdns

(РЕДАКТИРОВАТЬ) - У меня нет корневого доступа к старому серверу, поэтому я не могу реализовать принятый ответ на этот вопрос .

Вопрос: я действительно не хочу, чтобы моим пользователям приходилось сталкиваться с этим, поэтому я могу что-то сделать, чтобы заставить все браузеры повторно кэшировать? И если да, то как долго оставить его включенным?

Спасибо...

domain-name-system migration

— CC
источник

My own experiments with a local hosts file (Win7) tell me there is something about the browser that is not letting the old IP address go

Можете ли вы предоставить некоторую информацию об этом? Afaik, браузеры не кэшируют записи DNS более 1 минуты.

— Tanmay

Не уверен, но после нескольких ipconfig / flushdns и «ctrl-F5» (в Firefox) я продолжал получать смесь страниц как со старого сайта, так и с нового сайта… наконец, пришлось очистить «все» и перезапустить браузер. Я не хочу, чтобы мои пользователи делали подобное ...

— CC

JBTW, решение по предоставленной вами ссылке также может работать, если у вас есть root-доступ к новому серверу. Обновите записи DNS и перенаправьте весь трафик со нового сервера на старый, пока DNS не будет правильно распространен.

— Tanmay

спасибо ... но тогда мне придется снова синхронизировать старый обратно с новым (базы данных и т. д.), нет?

— CC

Вам придется синхронизировать базу данных один раз, непосредственно перед выключением пересылки.

— Tanmay

15

Нет, ты не можешь. Проблема в том, что ответ DNS может быть кэширован в любом месте между пользователем и сервером DNS, и нет никакого способа сделать их недействительными.

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

Таким образом, вы можете достичь почти 0с времени простоя вашего сайта.

Обновить

Если у вас нет root-доступа, есть несколько вариантов:

Выполнить проксирование в PHP
Настройте прокси на втором сервере (если у вас есть root-доступ), переключите DNS и, когда вы будете готовы, измените прокси на веб-сервер
Этот метод может быть источником проблем. Имеют 2 адреса (www.domain.tld и www2.domain.tld). Настройте www2 (который совпадает с www) и установите правильные записи DNS. Затем подготовьте www версию своего сайта и сделайте переключение DNS. Установите перенаправление всех запросов на старом сервере на поддомен www2.

— Ярик Дот
источник

Не могли бы вы немного рассказать об этом, или указатель на статью или Q / A, которые я мог бы прочитать? У меня нет корневого доступа к существующему серверу, поэтому я не могу напрямую манипулировать таблицами IP ... так что, может быть, есть альтернативный способ?

— CC

@CC, возможно, у вас есть доступ для замены вашего приложения на экземпляр HAProxy? Или заменить код вашего приложения другим, который просто перенаправляет запрос на новый сервер?

— Джейсон Мартин

@JasonMartin - у меня есть доступ к .htaccess и коду приложения. Итак, да, я мог бы, вероятно, получить запрошенный URL-адрес и перейти к новому IP-адресу - может быть, я должен попробовать это?

— CC

@CC это звучит многообещающе. DNS является «в конечном итоге непротиворечивым» инструментом, и некоторые DNS-серверы устанавливают уровни в своих TTL и игнорируют ваши 300. Если вы хотите избежать каких-либо перерывов, лучшим вариантом будет прокси-сервер пересылки.

— Джейсон Мартин

4

Теоретически, установка TTL домена на низком уровне и ожидание этого изменения, а затем изменение IP должны привести к почти прозрачной миграции. В конце концов, в этом и заключается смысл настройки TTL.

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

Вы не делаете ничего плохого, хотя.

— Гонки легкости на орбите
источник

Должен ли я немедленно переключиться на новый DNS AWS Route 53 - со старым IP-адресом - после завершения миграции просто смените IP-адрес на новый? - или просто сменить DNS на новый и одновременно сменить IP?

— CC

1

@CC: Я не являюсь сетевым администратором, поэтому возьмите это с собой (и я рад услышать иначе от гуру ServerFault), но я бы лично рекомендовал не менять оба сразу. Разберитесь со своим DNS, затем измените IP и дайте новому DNS сделать свою работу, помогая вам с последней частью.

— Гонки легкости на орбите

1

Ну, я попробовал эксперимент. На одном сайте я заранее поменял DNS-часы, а затем изменил IP-адрес A-записи. Работал отлично. На другом сайте я поменял оба сразу. Он часами перебирался между старым / новым IP-адресом - я наконец удалил зону AWS Route 53 и повторил ее так же, как первый сайт. Работал отлично. Так что не нужно щепотку соли - вы были на месте!

— CC

1

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

Как бы я это сделал:

Создайте запись A, например www2.yourdomain.com, указывая на новый IP. Эта запись никогда не должна была использоваться раньше; поэтому никогда не кешируется.
Перенаправить запросы на старом сервере на www2.yourdomain.com
Монитор перенаправляет, и когда трафик падает до приемлемого уровня, удалите старый сервер.
И, наконец, после удаления старого сервера, перенаправьте www2.yourdomain.comна www.yourdomain.com.

Обязательно используйте 301 Постоянные перенаправления. https://en.wikipedia.org/wiki/HTTP_301

— ClickLabs
источник

Мне кажется, что он не должен использовать 301 для первого раунда перенаправлений, а только для второго. Есть ли какая-то особая причина, по которой он должен знать об этом только человека с эзотерической SEO-мудростью?

— Random832

@ Random832 Перманент велит агенту пользователя забыть о старом URL-адресе и, например, обновить закладки, чтобы они указывали на новый URL-адрес (поэтому в следующий раз они могут получить доступ к новому URL-адресу напрямую). Нет никакого вреда в повторном перенаправлении позже (или даже к исходному URL). Временное перенаправление с другой стороны указывает агенту пользователя сохранить исходный URL-адрес (поскольку перенаправление может произойти с другой целью или вообще не произойти в следующий раз). Следовательно, с временными перенаправлениями мониторинг перенаправления никогда не упадет до «приемлемого уровня».

— Хаген фон Айцен

@HagenvonEitzen Он упадет до приемлемого уровня, поскольку браузеры перестанут получать IP-адрес старого сервера для www.yourdomain.com, который является DNS-объектом и не будет зависеть от используемого типа перенаправления HTTP. И «потому что перенаправление может произойти ... совсем не в следующий раз», поэтому точно верно.

— Random832

0

Похоже, вы планируете изменить свои серверы имен одновременно? Из-за способа обнаружения серверов имен их обновление занимает намного больше времени, чем обычной записи - часто это составляет около 24 часов или дольше.

Я настоятельно рекомендую вам обновить DNS у вашего текущего провайдера, прежде чем менять DNS, или поменять свои серверы имен за 7 дней до того, как вы измените IP сайта.

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

— codatory
источник

Спасибо, и да, это отражает мой комментарий под ответом Lightness выше. Средство распознавания обновило серверы имен довольно быстро - в течение нескольких минут. Ключ должен был сделать это сначала, затем подождать несколько часов, прежде чем изменить IP-адрес назначения. Оба сразу были плохими ... очень плохими.

— CC