Сеть платников. Как правильно организовать?

Всем доброго времени суток.

На текущий момент есть сеть платников (около 10 сайтов) которая потихоньку начинает загибаться из-за ежедневного увеличения траффика. Стоит задача переделать серверную и программную(код+бд) архитектуру.

Что имеем на текущий момент:
- 1 back-end server (mysql, apache, php) - так же выполняет задачу по созданию FHG и конвертацю видеосов (wmv,mp4... -> flv)
- 1 front-end server (apache, php) на нем размещаются платники, которые используют единую базу бэкенда.
- 3 content servers (хостит видеосы и фотосеты), доступ к этим серверам идет через NFS Frontend's member area->Content servers. (не уверен, что это лучший способ доступа к контенту).
- 1 NATS server

Сейчас никакой балансировки, кеширования фронтэнда нет. Делалось все очень давно и не рассчитывалось на большое число подписок. Сейчас имеем большую загрузку CPU на back-end MySQL-ом + тормоза при отдаче фотосетов и видеосов.
Планируется оптимизация MySQL запросов, самой ДБ, какое-либо front-end кеширование, вынос медиа-конвертора на отдельную машину.

Что еще можете посоветовать? PgSQL? Балансировка? nginx + ngx_http_proxy_module? Может быть где есть схемы построения таких систем? Поделитесь опытом

Заранее огромное спасибо за помощь.

rolikoff писал:

Всем доброго времени суток. На текущий момент есть сеть платников (около 10 сайтов) которая потихоньку начинает загибаться из-за ежедневного увеличения траффика. Стоит задача переделать серверную и программную(код+бд) архитектуру. Что имеем на текущий момент: - 1 back-end server (mysql, apache, php) - так же выполняет задачу по созданию FHG и конвертацю видеосов (wmv,mp4... -> flv) - 1 front-end server (apache, php) на нем размещаются платники, которые используют единую базу бэкенда. - 3 content servers (хостит видеосы и фотосеты), доступ к этим серверам идет через NFS Frontend's member area->Content servers. (не уверен, что это лучший способ доступа к контенту). - 1 NATS server Сейчас никакой балансировки, кеширования фронтэнда нет. Делалось все очень давно и не рассчитывалось на большое число подписок. Сейчас имеем большую загрузку CPU на back-end MySQL-ом + тормоза при отдаче фотосетов и видеосов. Планируется оптимизация MySQL запросов, самой ДБ, какое-либо front-end кеширование, вынос медиа-конвертора на отдельную машину. Что еще можете посоветовать? PgSQL? Балансировка? nginx + ngx_http_proxy_module? Может быть где есть схемы построения таких систем? Поделитесь опытом Заранее огромное спасибо за помощь.

Ну кроме оптимизации БД и кода - однозначно нужно менять сервера. Для back-end server нужен мощный CPU, памяти минимум 8Gb + сервер должен стоять на канале 1Gbit. В выносе медиа-конвертера на отдельную машину я смысла не вижу - я бы конвертирование запускал по крону тогда когда по статистике минимальная загрузка CPU ну или к примеру приоритет конвертеру поставить минимальный. Ты бы описал конфигурацию серверов которую сейчас используешь - было бы проще что-то советовать...

Все сервера одинаковые:
- Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
- RAM 8gb

На счет Ethernet - 100mbit, увы. Но думаю это поправимо, разговариваю с датацентром сейчас.

хм, статику, типа пикчей апачем раздаёте? В сторону nginx под статику можно было и сразу смотреть, как только запускались )

Цитата:

1 back-end server (mysql, apache, php) - так же выполняет задачу по созданию FHG и конвертацю видеосов (wmv,mp4... -> flv)

под конверт видео в идеале отдельный сервер нужен, пусть не очень быстрый, но на котором больше ничего не вертится, типа мускульных баз фронтэнда и скриптов мемберок, хотя всё от нагрузок зависит, но если 10 платников, для которых регулрно режется промо и семплы, то думаю она не маленькая, однако

Цитата:

В выносе медиа-конвертера на отдельную машину я смысла не вижу - я бы конвертирование запускал по крону тогда когда по статистике минимальная загрузка CPU

то есть таки да, статсы нужны... если конверт происходит часто, то отдельный сервер действительно нужен, и смотря что дешевле подойдёт в твоём случае: один дорогой и мощный универсальный сервак или два несколько разных по конфигурации и ценовой политике, но независимые друг от друга (лично я склоняюсь ко второму варианту)

Цитата:

хм, статику, типа пикчей апачем раздаёте? В сторону nginx под статику можно было и сразу смотреть, как только запускались )

Согласен, ошибка с самого старта.

Цитата:

то есть таки да, статсы нужны...

Генерация FHG раз в неделю, 100 TGP/ 100 MGP, скрипт работает около 6 часов ;) Это с учетом самого оптимального по загрузке времени.
Что касается конверта видеосов, новые видеосы добавляются в течение дня от 0 до 5 новых видео. Т.е. я бы не сказал что сильно часто, но генерится несколько видов FLV для одного видео (Low, normal quality, 2 min FLV для превью)

Размер базы на бек энде?
Я думаю есть смысл переставить по паре гигов памяти с контент серверов на него, если база гораздо больше памяти.
Установка второго процессера в бек энд так же поможет, и базе и конвертации видео.

Цитата:

тормоза при отдаче фотосетов и видеосов

видимо предел по скорости для дисков настал

ну да, если раз в неделю на 6 часов, имхо терпимо, тогда апдейд железа, nginx, всевозможные кэши и возможно оптимизация некоторых наиболее ресурсоёмких скриптов, но думаю, просто в виде форумной дискуссии это не решается, и скорее-всего имеет смысл закроспостить сюда, так как по-любому потребуется ручное вмешательство с анализом и мониторингом, а тут обитает множество админов с нормальными репутациями (или здесь заинтересованный народ вскоре отпишется).
Просто подобные сабжи требуют определённой конкретики, для решение конкретно твоей специфической проблемы.

Я прав в своем предположении, что знаю, о какой компании речь?

Ошибка главная вот где:

Цитата:

3 content servers (хостит видеосы и фотосеты), доступ к этим серверам идет через NFS Frontend's member area->Content servers. (не уверен, что это лучший способ доступа к контенту).

Естественно, не лучший. Это вообще извращенский способ - сначала front end должен получить эти файлы по NFS. Для этого сервер, которым раздаешь видео, маппит эти файлы - да, через NFS и это очень медленно, хоть 10 nginx'ов поставь.

Фронтенд не должен http запросы на себя выдавать на статику. Он должен выдавать URLи в страницах типа

http://static1.example.com/url/pic.png
http://static2.example.com/url2/video.mp4
... в зависимости от того, где эти пикчи/видео _реально_ лежат

ну и так далее. Чтобы сами же сателлиты выдавали всю статику прямо клиенту. А то получается, весь трафик прет через front end, да еще и два раза - сначала по NFS, а потом по http. Поставь nginx на каждый сателлит, измени логику работы страниц в мемберке, чтобы фронтенд не через себя все это гнал, а только ссылки выдавал на сателлиты, и все будет мухой летать.

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

Последний раз редактировалось: Dr.Syshalt (02/02/11 в 16:53), всего редактировалось 1 раз

2 taj

Цитата:

Размер базы на бек энде?

Размер базы ~700mb

Цитата:

видимо предел по скорости для дисков настал

Что в таком случае делают?

2 mr. snatch

Цитата:

...но думаю, просто в виде форумной дискуссии это не решается, и скорее-всего имеет смысл закроспостить сюда...

Спасибо, если ничего не решу сам, придется искать специалистов.
Что касается nginx - это понятно. Не понял на счет "всевозможных кэшей", nginx-а для этого будет недостаточно? Что и как лучше кешировать на front-end платника с его мемберкой вообще?

2 Dr.Syshalt

Цитата:

Я прав в своем предположении, что знаю, о какой компании речь?

Сомневаюсь, что Вы знаете Отпишите в личку название компании, я отвечу более точно.

Цитата:

Фронтенд не должен http запросы на себя выдавать на статику. Он должен выдавать URLи в страницах типа

Как в таком случае лучше всего защитить мемберский контент от доступа не мемберов? Учитывая то, что user management работает на основе .htpasswd, не по базе.

rolikoff писал:

Размер базы ~700mb?

ну тогда только в сторону запросов смотреть. Индексы во всем ключевым полям созданы я надеюсь? innodb или myisam? инно, можно ещё с журналом транзакций по колдовать ) В общем более тонкой настройкой нужно заняться.

rolikoff писал:

Что в таком случае делают?

Хм. Сначала я не понял что контент сервера отдают данные фронт энду. Это ппц - возможно там уже тупо канала не хватает? (как я понял сетка 100мб между всеми?)
Такую схему работу в любом случае нужно менять

Последний раз редактировалось: taj (02/02/11 в 17:07), всего редактировалось 1 раз

rolikoff писал:

Сомневаюсь, что Вы знаете Отпишите в личку название компании, я отвечу более точно.

Ошибся, возможно - просто странное совпадение, что у разных компаний настроено все одинаково.

Цитата:

Как в таком случае лучше всего защитить мемберский контент от доступа не мемберов? Учитывая то, что user management работает на основе .htpasswd, не по базе.

Элементарно, Ватсон

http://wiki.nginx.org/HttpSecureDownload
http://wiki.nginx.org/HttpAccessKeyModule

Ключ генерится на ходу и вставляется в URL на ресурс.

Цитата:

Ключ генерится на ходу и вставляется в URL на ресурс.

Класс. Спасибо.

taj писал:

ну тогда только в сторону запросов смотреть. Индексы во всем ключевым полям созданы я надеюсь? innodb или myisam? инно, можно ещё с журналом транзакций по колдовать ) В общем более тонкой настройкой нужно заняться.

С индексами все ок. Долго занимался именно оптимизацией и структурой ДБ при создании. Но за последнее время столько новых фич добавили, что структура базы устарела, над этим будем работать. MyISAM

rolikoff писал:

Сейчас имеем большую загрузку CPU на back-end MySQL-ом + тормоза при отдаче фотосетов и видеосов.

Тормоза при отдаче могут быть вызваны разными причинами, например:

1. Банально забито все 100Mbit канала.
2. Диски не справляются с отдачей.
3. Так как у тебя стоит один Апач без Nginx - оперативная память может быть исчерпана система уходит в своп и все тормозит.
4. Недостаточно ресурсов CPU.

Чтобы понять в чем именно проблема я лично советую установить на все сервера систему статистики Munin и там по графикам все смотреть.

У нгинкса есть кеш для "медленной статики", его стоит включить для того контента который берется с NFS. Или заменить NFS проксированием (с кешем опять же).
NFS легко может быть узким местом.
(это вот что можно сделать "быстро" и не меняя почти ничего)

Ну и про secure download уже сказали выше

(update) Полез смотреть как называется этот кеш, но не нашел на вскидку (это может быть и аддон какой-то) -- я относительно недавно видел упоминание этого в рассылке). Оно кеширует обычную статику, так же как кеширует ответы от прокси/fcgi.
Таки да это аддон -- http://labs.frickle.com/nginx_ngx_slowfs_cache/