Пробовали ли Вы делать то же у других регистраторов?
Если нет, то почему считаете, что там будет не по документам?
WEBST, Art-Host, о чем спор-то? интересно ведь :)
sidor80, можно использовать один сервер для распределения нагрузки - он будет просто перенаправлять запросы на остальные ваши сервера с копиями сайта. Притом на первый сервер нагрузка будет минимальная, так как он фактически только будет выполнять функции прокси (ни базы, ни скриптов, ни статического контента на нём размещать не надо).
Но это довольно дорогое решение (нужно, как минимум, 3 сервера), как правило, им пользуются сайты только с очень большой посещаемостью.
Вариант с DNS тоже успешно работает (например, попробуйте проверить ip-адрес login.icq.com с разных компьютеров), но если один из хостингов у вас упадёт, то часть народу всё равно будет идти на него, так как мгновенно DNS не обновится.
А если считать, что сервер для распределения нагрузки работает очень стабильно, то этот вариант предпочтительнее, так как все коррективы относительно рабочих серверов в кластере можно вносить мгновенно.
cscope, думаю, тут в первую очередь надо обращаться к хостеру.
Как правило, хостер согласно договору может прекратить размещение сайта за распространение вирусов.
sep, у меня периодически бывает WM к обмену (меняю WMZ на Я-Д по курсу 27). Стучи в ICQ.
Скорее всего буду.
Чем меньше зон, тем меньше путаницы.
Для России было бы достаточно зоны .ru.
KLOZ, список свободных доменов - это вообще что?
Знаю, где взять список занятых...
SantaClaus, для начала надо понять, где тонкое место. "too many connection" вам кто говодит? MySQL или Web-сервер?
Если MySQL, то его лучше вынести на отдельный сервер, притом с 64-битной архитектурой. Если слишком большая нагрузка на базу, то можно сделать 2 сервера, с которых будут делаться SELECT'ы (на один из них будут делаться также команды на запись, а на втором можно просто настроить репликацию базы).
Если web-сервер, то смотрите, какие файлы больше всего жрут ресурсов, статика или скрипты. Если статика, то перевести её на nginx, а главное проверить, что нету личеров на картинки (не так давно на одном проекте пришлось забанить всех клиентов с "неправильным" HTTP_REFERER после чего нагрузка упала раз в 5 и трафик с китайских ip - до нуля :)). Если скрипты, отлаживать скрипты, оптимизировать работу с базой, настроить кеширование, но не допуская огромного количества файлов в одной директории.
И правильно сделали.
