portfelio

По вашим вопросам

1) Вы можете прописать хоть 22 А-записи.
2) Проканает, если под этим вы подразумеваете, что клиент будет получать пул адресов
3) RR DNS далеко не самый лучший вариант распределения нагрузки. Правильнее было бы раскидывать клиентов через балансировщик. И не забывайте про сессии. Весьма неприятны ситуации, когда я залогинен на сервере в Токио, а при следующем запросе получаю адрес сервера в Торонто, который еще не успел получить мои сессионные данные.

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

P.S. Если соберетесь таки делать "синхронизацию файлов" советую присмотреться к этой реализации DFS www.leofs.org

Как такое может быть рассказали выше. Увы, но многие операторы грешат очень длительным кешированием НС-записей, а страдают из-за этого в первую очередь их клиенты, которые не могу себе прописать альтернативу 8.8.8.8 8.8.4.4 ;)

А предпринять можно вот что:

1) При обращении на старый сайт делать редирект на новый IP с каким-то доп.параметром в URL (например, redir=1)
2) Новый сайт повесить на IP по-умолчанию
3) Для тех, кто обращается к IP с реферером с redir=1 отображать сайт, всех остальных редиректить на сайт
4) Как только число уникальных посетителей с таким поведением приблизиться к нулю полностью отключить такую костыльную схему, то есть всех с IP редиректить на сайт либо отключить отображение сайта по IP.

1) Удалите hosts и создайте заново
2) После этого проверьте ping и если не работает, то
2.1) Покажите результаты
ls -al /etc/hosts
и
strace ping your_site 2>&1 | grep "open(" (от рута и пользователя)

strace установите при необходимости.
2.2) Напишите, каким редактором создавали/правили hosts