FastCGI - права менять не придется, перейти попробуйте, но сильно может не улучшить ситуацию. Нагрузка по посещаемости на сервер вообще существенная ?
В каком состоянии у вас диски ? S.M.A.R.T. ?
из-за прослойки в виде впса. Может такое быть? Попробовать переехать на чистый дедик?
еще как может.
ради интереса перетащите сайты на чистый дедик. я видел контейнер на весь ресурс сервера только один раз. wa конечно не зашкаливало, но было приличным для той нагрузки, которая была. перенесли на чистый дедик, загрузили родное ядро - стало хорошо.
если таки воткнули ссд, перенесли туда файлы и все равно дикий wa - то и гадать нечего, это уже потеря времени и шаманство. Просто смените железо.
ну .. не то что бы испытывают. ip-адреса есть у многих хостеров. просто теперь их не дают пачками на что угодно.
смотрите в сторону sladkydze, инферно (extra на этом форуме), xserver, eserver еще может у кого.. у них есть... 180айпи .. на три впски, или сколько там .. 250баксов +/- я думаю вам все это станет, если опять же - ip-адреса не будут попадать в различные блеки.
клиентам советую использовать свой настроенный прокси, в ряде случаев этого достаточно.
если же фигачит по полной программе , то qrator.net , оверсан как тут ранее писали.
PS: понять для себя , что если нужна качественная полноценная защита , то это действительно будет стоить денег. О хорошей защите от хорошего ддоса за 10$-20$ речи быть не может. Приличные фильтраторы начинаются от 400$\сутки до 5000$ в месяц.
ТС, вам подойдет любой хостер, который VPS-ит в России, и у которого есть техническая возможность. При таких объемах, я думаю, можно найти по 1$-1.5$ за айпи адрес в месяц.
Главное условие - белота. Если будет малейшая чернота, фишинг, кардинг, скам, спам, таблетки, ДП, трава - то вас просто сразу заблокируют.
Если же просто какой-нибудь форекс у вас, накрутка счетчиков каких-то, парсинг - то это не так страшно.
да всегда пожалуйста. я не считал запросы\с, но это банеро-генерилка-кликалка для адвертов. в топовое время нагрузки было более 3млн одновременных кликов на один банер. думаю можно это считать за запрос, даже серия запросов. это составляло 40-50% всей мощности. Хозяин считал так: если несколько раз повторяется долговременный рост нагрузки выше 70%, то ставим еще воркеров. Нагрузка определялась самописной опрашивалкой по snmp показаний воркеров: время отклика nginx, время реакции fpm, время отдачи, показания htop, top -d 1. По этим циферкам делали примерную общую нагрузку.
Если вникнуть очень приближенно, то в принципе моя схема - проста. ничего сверх-гениального нет в ней.
В вашем случае - мне кажется - есть узкое место: база данных. MySQL до сих пор не умеет вменяемо чтото параллелить и балансить. Репликация мастер-мастер - это не совсем то, даже совсем не то. Значит нужно переходить на percona, но - я не программист, детально не скажу, но насколько мне известно у перкона есть свои нюансы в SQL-запросах, работе с движками и т д. Percona xtra db cluster рекомендуют собирать из 3+ серверов, а не из двух, так как один из трех в минимальной сборке - это севрер-контроллер, который контроллит целостность работы двух нод, ну или сколько их там у вас будет.
Далее у вас есть контент, в данном случае php-скрипты их можно синхронизировать без проблем через какой-нибудь lsyncd, не использовать для этого блочные девайсы, drbd - не подходит. Да и вообще опасная штука, rm -rf /dev/drbd0 и все, можно сказать - данные потеряны на всем диске. Так вот - синхронизировать на другие воркеры, настроить на них fpm + nginx.
Картинки - можно отдельный сервер или группу серверов поставить под них, varnish -отдельный сервер, класть в него css, js какой-нибудь. Счетчики, статистику и прочий изврат - вынести из MySQL\percona в Redis - это сильно разгрузит мускуль ваш, если используете счетчики, статистику и т д.
Например один из моих клиентов загружает картинки на сайт (ну пользователи сайта загружают за него) через буффер: сначала они попадают на один сервер, а с него синхронизируются на 10 воркеров. в общем ... как не крути .. без совещаний с подобным заказчиком, без брифингов с проггерами на предмет - как они видят архитектуру - не обойтись.
Настроить то можно все что угодно, но 90% сайто-владельцев думают, что "построим кластер и все будет быстро", и потом приходится очень долго рассказывать, что нужны программисты))))
ну все вышеописанное - это чисто субъективно ...
Паша, здарова, а наш городской форум на чем ? nginx мордой, php в fastcgi или fpm (а хотя какая разница по большому счету....) ? mysql ? чего переписывал\дописывал?---------- Добавлено 04.08.2014 в 11:20 ----------
фронт - haproxy -----> nginx... статический контент.
базы - да, собирали данные и обрабатывали их.
а.. ну и забыл еще добавить, то, чего мы не сделали, но надо было:
мы сделали еще RRDNS -но это не совсем то.... в идеале нужно было бы у ДЦ попросить failover ip парочку и на самом-самом фронте сделать heartbeat.
TTL TTL'ем конечно, но все равно в случае RRDNS - падал какой-нибудь хост - все равно днс отдуплялись минимум 20-30 минут, за это время сайт с фидом лагали, не то что бы заметно клиенту, но лагали...
вообще конечно такие вещи очень долго вместе с заказчиком рисуются на бумажке, планируются и анализируются, а уже потом реализуются. Иначе косяк на косяке будет.
все уже придумано.
varnish, haproxy, redis , данные в mongo, mysql , NGINX, php-fpm.
вот презентация об этом, как сделан например youporn:
https://dl.dropboxusercontent.com/u/8275035/youporn.pdf---------- Добавлено 04.08.2014 в 10:50 ----------только единственный нюанс - возможно код дефолта вашего таки придется в чем то пилить.---------- Добавлено 04.08.2014 в 10:55 ----------
я настраивал клиенту крупную ppc-партнерку.
4 фронта-блансировщика и все это на 50 бэкендов, вуаля. все работало.
балансировщики с 10гбит карточками. Бэкенды - обычные простенькие ксеончики с nginx+php-fpm, 16гб памяти.
база данных - четыре сервера percona, севрер mongo, ключи - redis.
один фронт-балансировщик на два бэка для varnish.
всего ровно 63 сервера.
все работает.
система должна быть мощной, надежной - да. но самое главное - МАСШТАБИРУЕМОЙ. Что бы когда тебе нужна будет производительность, ты за 15 минут настроил и поставил очередной дедик-воркер к остальным: трафик упал, мы изъяли 11 серверов, что бы не платить лишнее за аренду, трафик возрос, мы подсунули в систему 6 серверов. на них нужно было только yum install nginx php-fpm ну и необходимые php-модули, ну и конфиги nginx, fpm влить, далее restart и все, на все уходило 15 минут максимум. и новая нода становилась в строй. На черную американскую пятницу помнится - мы сразу 30 бэкендов клонировали на неделю, так как трафик взлетел в пик, америкосы за покупками побежали, потом снимали их с аренды. При таких объемах датацентр шел науступки, как например посуточная аренда, понедельная.
PS пилить код таки прийдется, так как какой-нибудь DLE понятия не имеет о redis, mongo и прочих малейших уходах от стандартов. В общем то, если пациент вырос до таких объемов, а хозяин не занимался продумыванием архитектуры сайта, переписыванием частей кода итд и теперь мы имеем например голый Wordpress с дикой посещалкой, то мне видится только вариант: вынести СУБД отдельно, вынести кеш отдельно, навертеть fpm... а дальше только наращивать железо, как будет утыкаться в производительность. Но этот вариант - очень дорог и не рентабелен, для этого и придуман различный софт для высоких нагрузок, что бы можно было на недорогом распространенном железе обрабатывать кучу данных.
если интересно - пиши.. расскажу детальнее.
а hts вкурсе вообще ?)
Олег, сдай ему мощности. В скайпе проконсультирую - какие.
я ему все настрою :) . Указанные Тобой нагрузки - совершенно обычны для нагруженного проекта.
Если он рассчитывает укладываться где-нибудь в жалкие 1000руб-1500руб в месяц за поддержание работоспособности своего ресурса, то он не мой, и самое главное, не твой клиент :)
Они хотят гарантию работоспособности - они готовы эту гарантию подкреплять повышенной месячной платой за риски, или они хотят, что бы за указанные выше копейки, хостер перед ними отвечал ГАРАНТИЕЙ работоспособности?
