я надеюсь там cpuspeed не висит ? реально чифтек корпуса делал неплохие. и блоки питания у них вполне даж ничего были. за серверные правда не скажу в те времена они юнитами не занимались. ну а если это тауэр то советую таки разобраться с вентилями. сейчас не жмет а завтра может зажать очень сильно. и как всегда в самое неподходящее время.
слава богу я больше не занимаюсь чем либо в россии. видимо здесь по прежнему пытаются сделать реальность фантастикой и наоборот.
если я вижу такое:
kernel: CPU0: Running in modulated clock mode
kernel: CPU0: Temperature above threshold
то пишу в дц чтоб поменяли вентиль что и выполняется в течение от 15 минут до 2 часов...
50 сайтов если они не тяжелые по диску вполне можно разнести в разные дц. 2 сервака под веб + 1 для баз данных + 2 пара днсок с простейшим скриптом мониторинга по доступности одного из серверов и все дела. дороже конечно чем один сервер зато гарантия устойчивости почти 100% но, вам нельзя светить истинные ай-пи веб серверов в зонах днс. иначе получится тот же дурацкий роунд робин.
40 мбит это немало. помните зепланет нулили ай-пи серваков уже при 10 мбитах при том что у них стандартно защита была включена в цену (NetGuard).
неа, это фантастика :)
ну как костыль, таймаутов подрезать. на коннекшн особенно.
чиго то они там намутили :) ну ждать тогда что ж делать. от вас ничего не зависит.
сделать трейс до домена и отписать в суппорт. а еще проверить локальный фаерволл - может он блочит по каким то причинам.
по моему тут речь шла не о таких кластерах:) может я конечно ошибаюсь но, вроде имелся в виду географический кластер. но, даже если я ошибаюсь то суть описанного кластера в двух вещах :
1) повышенная отказоустойчивость - минимум два веб-сервера, минимум один сервер под базы, два под днски и т.п и т.д. все это повышает отказоустойчивость. если упал один веб-сервер - трафик плавно и прозрачно переключается на другой. на одном серваке - такое естественно невозможно реализовать - некуда переключать.
2) регулирование нагрузки (лоад балансинг) - для реализации вообще говоря нужен аппаратный или софтверный лоад балансер притом случаются минусы (например с сессиями могут быть проблемы)
два выше указанных пункта обычное дело и давно известное во многих дата-центрах. помнится ракшак торговал этим просто как комплектами.
если вспомнить еще и о географическом кластере (хотя это больше попадает в категорию контент хостинга - по типа к примеру акамай) то в реализации того что делает акамай это и свой класс сети и бгп роутинг и собственные магистральные каналы.
все можно сделать и дешевле - вопрос в том какие задачи ставятся.
грид выглядит весьма привлекательным решением но, поскольку он строится опять же на технологии виртуализации вполне возможно что со временем когда он получит большее распространение всплывут и его подводные камни. о них просто пока могут не знать (а если и знаю то особо не распространяются)
PS. В вопросах скажем так со стороны клиентов прозвучала заинтересованность больше в выделении ресурсов и т.п. Это кстати тоже показатель. Первый вариант это не столько решение в сторону ресурсов, сколько все же к повышению отказоустойчивости.
PPS. Сосбтвеный дедик и админ это все конечно хорошо, но что случится если админ спит а сервер упал? Правильно понимаете - даун получится. Так вот кластер для того и нужен чтобы даунов не случалось. Так что дедик у вас или впс или просто хостинг - если реализовано без n+1 то и фиг вам - простой будет по любому...
вам никак :) единственное что можно посоветовать быть максимально точным в общении с суппортом. понимаю что для вас может быть нет никакой разницы но, вот для суппорта есть большая разница между двумя собщениями от клиента о проблеме:
а) у меня не работает почта
(плохой вариант)
б) у меня не работает почта. при попытке соединения с помощью почтового клиента TheBat, выдается сообщение о том что отправка собщения невозможна (Ошибка RFC1324).
([хороший вариант)
помните "какой вопрос такой и ответ". Если суппорт получает собщение "Вашу мать, почему у меня сайт не виден" что вы получите в ответ?
