Как грамотно переехать на новый сервер внутри хостинга

Сорри за поддержку оффтопа, но уж больно интересно.

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

Лихо Вы сейчас обвинили в невменяемости крупнейшего в мире DNS-anycast провайдера Amazon Route53, Google и более мелких сошек типа Bluehost, Hostmonster, JustHost и прочих... Ну и в том же списке "неадекватов" Reg.ru, Masterhost, Sweb, nic.ru и т.д.

У Godaddy тысячи хостинговых серверов и всего 90 NS-серверов (и это под 30 миллионов доменых зон). Godaddy неадекватны?

Не имел счастья пользоваться хостингм гугла. Амазон - заниматься шаредом ни разу об этом не слышал ....

Блухост и хостмонстр - недавно тестировал: железо уровня как я купил на ебее за 250 баксов - LA сервера 16-30. Логи забитые тоннами ошибок типа "сегминтешен фалюре" причем в свободном доступе для всех - явные проблемы с памятью и явно забитый болт на это тех персонала.

Даже не знаю, просто привел пример того, что недавно видел. Тоже показалось странноватым.

Разве что, это полностью исключает как таковую проблему DDoS'а на dns, ибо уже бессмысленно.

Они по другому не умеют

я пожалуй промолчу. конечно же никто кроме захолустного хостинга не умеет приворачивать по два DNS-сервера к каждому шаредному. Там же навыки нужны огого какие. Это вам не ядро линукса кодить. Тут уже разбираться надо. Хотя бы кандидатскую на тему DNS защитить.

ясно, теперь все встало на свои места. По крайней мере, при следующем подобном переезде я уже буду знать, что делать...

По нормальному: Вам надо перенести базу на новый сервер и настроить коннект на старом месте к новой базе.

Дальше переносите фалы наовый сервер.

Дальше вы меняете ДНС сервера на новые.

И все без простоя. При условии что нет фаервола и возможно иметь один одинаковый домен на разных серверах.

Если хостер идет вам навстречу, то вариантов вагончик.

1. уменьшение ttl dns в старых NS-ах, и смена НС-ов на новые уже после переезда (смены IN A).

2. проксирование трафика с одного серера на другой при помощи nginx или mod_proxy

3. редирект (бинат) на роутере, если у вас есть выделенный ip для этого сайта

4. разнос сайта с www и без на разные ip и использование редиректа 304 (не идеально для поисовиков, но

зато доступно любому пользователю, не требуются доп права.)

---------- Добавлено 01.05.2012 в 11:37 ----------

При такой схеме все хорошо, кроме аватаров и других загруженных файлов.

Я кстати этот способ и выбрал в итоге.

Мне этот способ понравился в силу его простоты. Да, есть небольшое ограничение по отправке сообщений пользователями, в плане загрузки картинок и прочих файлов. Плюс к этому естественно форум малость тормозил в процессе переезда, поскольку все грузилось получается с двух серверов (файлы на одном, база на другом сервере). Но на сайте крупными красными буквами вывесил соответствующее объявление.

Все прошло хорошо. На форуме все пользователи отнеслись с пониманием :)

Как правило клиентам предлагаем след схему:

1) перенос контента

2) перенос бд

3) переключение бд на новый сервер

4) при необходимости проксирование запросов

5) тестирование новой конфигурации

6) переключение днс