форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Оптимизация и Промышленные системы (Кластеры)
Изначальное сообщение		[ Отслеживать ]

"Конвертирование видео на backend'е"		+/–
Сообщение от ciwl (ok) on 10-Мрт-10, 13:36
Добрый день. Необходимо организовать видеопортал. Одно из условий реализации - видео должно корвертироваться и хранится на backend'е, дабы не загружать сам вебсервер. Какие есть обкатаные схемы реализации подобной задачи?
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Конвертирование видео на backend'е"		+/–
Сообщение от ciwl (ok) on 14-Мрт-10, 15:52
что, перевелись спецы? или сабж настолько идиотский/тривиальный, что лень даже об этом сказать? )
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	3. "Конвертирование видео на backend'е"		+/–
	Сообщение от Hate (ok) on 01-Май-10, 10:03
	>что, перевелись спецы? или сабж настолько идиотский/тривиальный, что лень даже об этом >сказать? )   Второе.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	4. "Конвертирование видео на backend'е"		+/–
	Сообщение от ciwl (ok) on 04-Май-10, 13:21
	>>что, перевелись спецы? или сабж настолько идиотский/тривиальный, что лень даже об этом >>сказать? ) > >  Второе. да вы что! ну-ка пруфлинк в студию...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	7. "Конвертирование видео на backend'е"		+/–
	Сообщение от Hate (ok) on 04-Май-10, 18:36
	>>>что, перевелись спецы? или сабж настолько идиотский/тривиальный, что лень даже об этом >>>сказать? ) >> >>  Второе. > >да вы что! ну-ка пруфлинк в студию... Ща, только все брошу... Тебя на гугле забанили? :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "Конвертирование видео на backend'е"		+/–
	Сообщение от ciwl (ok) on 06-Май-10, 11:30
	>>>>что, перевелись спецы? или сабж настолько идиотский/тривиальный, что лень даже об этом >>>>сказать? ) >>> >>>  Второе. >> >>да вы что! ну-ка пруфлинк в студию... > > Ща, только все брошу... Тебя на гугле забанили? :) То-то же, уважаемый тролль. Ценность ваших постов == 0
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Конвертирование видео на backend'е"		+/–
Сообщение от sHaggY_caT (ok) on 01-Май-10, 03:46
>Добрый день. > >Необходимо организовать видеопортал. Одно из условий реализации - видео должно корвертироваться и >хранится на backend'е, дабы не загружать сам вебсервер. > >Какие есть обкатаные схемы реализации подобной задачи? Добрый день. А какого рода помощь Вас интересует, конкретизируйте? Мы реализовывали подобный проект.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	5. "Конвертирование видео на backend'е"		+/–
	Сообщение от ciwl (ok) on 04-Май-10, 13:26
	>>Добрый день. >> >>Необходимо организовать видеопортал. Одно из условий реализации - видео должно корвертироваться и >>хранится на backend'е, дабы не загружать сам вебсервер. >> >>Какие есть обкатаные схемы реализации подобной задачи? > >Добрый день. А какого рода помощь Вас интересует, конкретизируйте? Мы реализовывали подобный >проект. механизм взаимодействия www-сервер <---> convert-сервер пока ничего умнее не придумал, кроме как сделать каталог с "сырым" видео примонтированным по NFS. после загрузки ролика, делается соответствующая запись в БД и конвертирующий сервер начинает его кодировать, выкладывая результат в такую же общую папку, доступную по сети с www-сервера
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	6. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 04-Май-10, 13:45
	>[оверквотинг удален] >> >>Добрый день. А какого рода помощь Вас интересует, конкретизируйте? Мы реализовывали подобный >>проект. > >механизм взаимодействия www-сервер <---> convert-сервер > >пока ничего умнее не придумал, кроме как сделать каталог с "сырым" видео >примонтированным по NFS. после загрузки ролика, делается соответствующая запись в БД >и конвертирующий сервер начинает его кодировать, выкладывая результат в такую же >общую папку, доступную по сети с www-сервера NFS+web = тормоза гарантированы. Можно использовать: а) Быстрый линк(bound из нескольких интерфейсов?) и NFSv4: меня терзают сомнения по поводу производительности такой схемы, NFSv3 определенно не подойдет. б) iscsi через _несколько_ гигабитных интерфейсов в bound,и параллельной ФС вроде gfs в) мощную дисковую подсистему (быструю, прежде всего, и с хорошим кэшем, защищенным батарейкой, что бы пики раздавал на нескольких гигабитах из кэша, сглаживая рывки), при наличии пункта б) Я бы скорее выделила в отдельную железку (обязательно с двумя блоками питания, и массивом с хорошей избыточностью и производительностью вроде raid60) Если есть бюджет, то лучше вообще использовать готовый DAS А вообще, схема однозначно дурацкая и бесполезная, а для снижения нагрузки, обычно, выделяют 1. Отдельный акселератор-балансер трафика между web-серверами. Иногда разделяют балансеры и акселераторы. 2. Видео хранят именно на web-серверах (нескольких) 3. Выносят на отдельный сервер базу данных
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	9. "Конвертирование видео на backend'е"		+/–
	Сообщение от ciwl (ok) on 06-Май-10, 11:55
	>[оверквотинг удален] >Я бы скорее выделила в отдельную железку (обязательно с двумя блоками питания, >и массивом с хорошей избыточностью и производительностью вроде raid60) >Если есть бюджет, то лучше вообще использовать готовый DAS > >А вообще, схема однозначно дурацкая и бесполезная, а для снижения нагрузки, обычно, >выделяют > >1. Отдельный акселератор-балансер трафика между web-серверами. Иногда разделяют балансеры и акселераторы. >2. Видео хранят именно на web-серверах (нескольких) >3. Выносят на отдельный сервер базу данных спасибо за ответ. с кодированием как поступить? понятно, что если заставить web-сервер кодировать видео то долго он не протянет. На данный момент это bottleneck N1 Касаемо хранения видео - да, возможно, имеет смысл действительно хранить его на веб-сервере и по шаре отдавать кодировщику. web соединён с кодировщиком (пока одним) гигабитным линком, скорость обмена ~650Mbps, скорость обмена по NSF намного меньше. Хотелось бы получить совет по этому поводу (один уже есть - gfs  :) )
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	10. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 06-Май-10, 12:09
	>[оверквотинг удален] > >спасибо за ответ. >с кодированием как поступить? понятно, что если заставить web-сервер кодировать видео то >долго он не протянет. На данный момент это bottleneck N1 >Касаемо хранения видео - да, возможно, имеет смысл действительно хранить его на >веб-сервере и по шаре отдавать кодировщику. web соединён с кодировщиком (пока >одним) гигабитным линком, скорость обмена ~650Mbps, скорость обмена по NSF намного >меньше. >Хотелось бы получить совет по этому поводу (один уже есть - gfs > :) ) Кодирование можно зарубить cpulimit, или cgroups в "пионерских" ядрах линуха (но скоро будет в RHEL/CentOS 6)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	11. "Конвертирование видео на backend'е"		+/–
	Сообщение от ciwl (ok) on 06-Май-10, 13:06
	>[оверквотинг удален] >>долго он не протянет. На данный момент это bottleneck N1 >>Касаемо хранения видео - да, возможно, имеет смысл действительно хранить его на >>веб-сервере и по шаре отдавать кодировщику. web соединён с кодировщиком (пока >>одним) гигабитным линком, скорость обмена ~650Mbps, скорость обмена по NSF намного >>меньше. >>Хотелось бы получить совет по этому поводу (один уже есть - gfs >> :) ) > >Кодирование можно зарубить cpulimit, или cgroups в "пионерских" ядрах линуха (но скоро >будет в RHEL/CentOS 6) тогда скорость кодирования будет неприемлемо мала
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	12. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 06-Май-10, 13:46
	>[оверквотинг удален] >>>веб-сервере и по шаре отдавать кодировщику. web соединён с кодировщиком (пока >>>одним) гигабитным линком, скорость обмена ~650Mbps, скорость обмена по NSF намного >>>меньше. >>>Хотелось бы получить совет по этому поводу (один уже есть - gfs >>> :) ) >> >>Кодирование можно зарубить cpulimit, или cgroups в "пионерских" ядрах линуха (но скоро >>будет в RHEL/CentOS 6) > >тогда скорость кодирования будет неприемлемо мала С cgroups можно ставить мягкие и жесткие лимиты. Кроме того, можно просто поставить в сервер несколько cpu-ядер, и посадить процесс(ы) кодирования на специально для этого предназначенные ядра (можно и в RHEL/CentOS уже сейчас)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	13. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 06-Май-10, 13:50
	>[оверквотинг удален] >>> >>>Кодирование можно зарубить cpulimit, или cgroups в "пионерских" ядрах линуха (но скоро >>>будет в RHEL/CentOS 6) >> >>тогда скорость кодирования будет неприемлемо мала > >С cgroups можно ставить мягкие и жесткие лимиты. >Кроме того, можно просто поставить в сервер несколько cpu-ядер, и посадить процесс(ы) >кодирования на специально для этого предназначенные ядра (можно и в RHEL/CentOS >уже сейчас) P.S. cgroups так же есть в в Debian Squeeze (еще не вышел официально, но, говорят, уже можно использовать)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	14. "Конвертирование видео на backend'е"		+/–
	Сообщение от ciwl (ok) on 06-Май-10, 14:14
	>[оверквотинг удален] >>> >>>тогда скорость кодирования будет неприемлемо мала >> >>С cgroups можно ставить мягкие и жесткие лимиты. >>Кроме того, можно просто поставить в сервер несколько cpu-ядер, и посадить процесс(ы) >>кодирования на специально для этого предназначенные ядра (можно и в RHEL/CentOS >>уже сейчас) > >P.S. cgroups так же есть в в Debian Squeeze (еще не вышел >официально, но, говорят, уже можно использовать) с жёсткими лимитами неустраивает скорость кодирования. с мягкими будет страдать производительность веб-сервера. Несколько ядер на несколько процессов кодирования - интересно, но пока нет финансовой возможности юзать дорогое железо, да и непонятно как это будет работать. А вот держать отдельную машину под кодирование - самое оно ИМХО, только взаимодействие надо наладить. ЗЫ юзаю генту
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 06-Май-10, 14:22
	>[оверквотинг удален] >>> >>>С cgroups можно ставить мягкие и жесткие лимиты. >>>Кроме того, можно просто поставить в сервер несколько cpu-ядер, и посадить процесс(ы) >>>кодирования на специально для этого предназначенные ядра (можно и в RHEL/CentOS >>>уже сейчас) >> >>P.S. cgroups так же есть в в Debian Squeeze (еще не вышел >>официально, но, говорят, уже можно использовать) > >с жёсткими лимитами неустраивает скорость кодирования. с мягкими будет страдать производительность веб-сервера. Не будет, по крайней мере в OVZ/PVC не страдает(опыт эксплуатации более сотни PVC и OVZ нод), а Cgroups во многом это код Parallels из того же OVZ. Просто ставите совсем маленький приоритет на группу процессов, кодирующую видео, и по-больше на рабочие...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	16. "Конвертирование видео на backend'е"		+/–
	Сообщение от ciwl (ok) on 06-Май-10, 14:32
	>[оверквотинг удален] >>> >>>P.S. cgroups так же есть в в Debian Squeeze (еще не вышел >>>официально, но, говорят, уже можно использовать) >> >>с жёсткими лимитами неустраивает скорость кодирования. с мягкими будет страдать производительность веб-сервера. > >Не будет, по крайней мере в OVZ/PVC не страдает(опыт эксплуатации более сотни >PVC и OVZ нод), а Cgroups во многом это код Parallels >из того же OVZ. Просто ставите совсем маленький приоритет на группу >процессов, кодирующую видео, и по-больше на рабочие... как же не будет, если ему (web-серверу) самому надо справлятся со своей работой (это следующий bottleneck, после кодирования) а тут ещё и кодировать заставляют что-то? перенеся процесс на отдельный физ.сервер я избавляюсь от лишних головняков, получаю стабильность. В будущем, планирую ставить ещё сервера кодирования с возможностью кодировать 1 ролик на нескольких машинах одновременно. Софт под эту задачу написан на 70%
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "Конвертирование видео на backend'е"		+/–
	Сообщение от ciwl (ok) on 06-Май-10, 14:35
	линк по сабжу http://www.intuitive.sk/fflib/post/how-to-make-youtube-with-...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	19. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 06-Май-10, 15:03
	>линк по сабжу >http://www.intuitive.sk/fflib/post/how-to-make-youtube-with-... ужс, зачем дотнеты? Не вчитывалась внимательно...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	21. "Конвертирование видео на backend'е"		+/–
	Сообщение от ciwl (ok) on 06-Май-10, 15:07
	>>линк по сабжу >>http://www.intuitive.sk/fflib/post/how-to-make-youtube-with-... > >ужс, зачем дотнеты? Не вчитывалась внимательно... там суть не в дотнетах, а в описании самого принципа (см. картинку ))
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	18. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 06-Май-10, 14:58
	>>Не будет, по крайней мере в OVZ/PVC не страдает(опыт эксплуатации более сотни >>PVC и OVZ нод), а Cgroups во многом это код Parallels >>из того же OVZ. Просто ставите совсем маленький приоритет на группу >>процессов, кодирующую видео, и по-больше на рабочие... > >как же не будет, если ему (web-серверу) самому надо справлятся со своей >работой (это следующий bottleneck, после кодирования) а тут ещё и кодировать >заставляют что-то? Исходя из опыта, в OVZ не мешает, хорошая изоляция(в отличае от renice, который, по-моему, ни на фре ни на Линухе особенно ничего не дает), думаю, в Cgroups будет так же. Мы даже компилим софт на нагруженной OpenVZ ноде, убрав верхний лимит(cpulimit), но поставив очень маленький cpuunits: кванты cpu достаются make-у в сборочном контейнере по остаточному принципу, тогда как "боевые" контейнеры голода по cpu не испытывают (а idle в это время ноль) Единственное, что может ухудшиться, это количество переключений контекста, но оно все равно составляет доли процента от общего времени, да и кодировать Вы будете не в 100-200 потоков, а в 1-2, так что этим можно пренебречь. >перенеся процесс на отдельный физ.сервер я избавляюсь от лишних головняков, получаю стабильность. >В будущем, планирую ставить ещё сервера кодирования с возможностью кодировать 1 >ролик на нескольких машинах одновременно. Софт под эту задачу написан на >70%
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	20. "Конвертирование видео на backend'е"		+/–
	Сообщение от ciwl (ok) on 06-Май-10, 15:03
	>[оверквотинг удален] > >Единственное, что может ухудшиться, это количество переключений контекста, но оно все равно >составляет доли процента от общего времени, да и кодировать Вы будете >не в 100-200 потоков, а в 1-2, так что этим можно >пренебречь. > >>перенеся процесс на отдельный физ.сервер я избавляюсь от лишних головняков, получаю стабильность. >>В будущем, планирую ставить ещё сервера кодирования с возможностью кодировать 1 >>ролик на нескольких машинах одновременно. Софт под эту задачу написан на >>70% т.о. вы предлагаете и www-запросы, и кодирование выполнять на одном дорогом физическом сервере? а если с ним что случиться? в моём варианте, я просто меняю упавший сервер (который стоит куда меньше), заливаю бэкап и всё продолжает работать виртуализация, бесспорно, вещь хорошая, но в моём случае она только добавляет ряд хлопот и снижает стабильность
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	22. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 06-Май-10, 15:16
	>т.о. вы предлагаете и www-запросы и кодирование выполнять на одном дорогом физическом >сервере? а если с ним что случиться? в моём варианте, я >просто меняю упавший сервер (который стоит куда меньше), заливаю бэкап и >всё продолжает работать Нет, я бы вообще сделала по-другому в принципе, при нормальном бюджете: Во-первых, нужно разделять HA и балансировку нагрузки, это в принципе разные вещи Во-вторых, я бы кодировала на бэкэндах(где Nginx и лежит статика) с низким приоритетом. В-третьих, я бы вынесла сервера баз данных на две отдельные машины В-четвертых, я бы отделила фронт-энд для балансировки нагрузки от веб-серверов. Бэкэнды лучше бы оставить(имхо) обычными традиционными железками, а для баз данных, управляющего ПО, и балансировщика нагрузки использовать две железки с какой-нибудь системой виртуализации (если базы данных не очень сильно нагруженные, обычно на таких задачах основная нагрузка на бэкэнд) - Между двумя бэкэндами организуется HA-кластер (например, RedHat Cluster Suite) - Между нодами виртуализации организуется HA-кластер (виртуалки одной из нод будут перезапущены в случае ее падения) - Управляющая нода RedHat Cluster Suite в первом случае виртуалка на кластере виртуализации - Во втором случае, ставиться на один из бэкэндов (роль не оказывает сильной нагрузки). Для кластера виртуализации _нужно_ общее блочное устройство, для бэкэндов _желательно_ общее дисковое устройство. В первом случае, если диск дергается не очень сильно (базами данных) можно использовать drbd Но вообще, лучше взять четырехпортовый DAS с SAS интерфейсом, и прицепить к нему все четыре железки. Бэкэнды лучше сделать более дорогими, а два сервера под виртуализацию использовать что-то значительно более простое (но лучше с ECC памятью) По DAS, в зависимости от Вашего бюджета, я бы смотрела на любой двухголовый Infortrend, так как дешево и сердито :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	23. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 06-Май-10, 15:19
	>[оверквотинг удален] >использовать drbd > >Но вообще, лучше взять четырехпортовый DAS с SAS интерфейсом, и прицепить к >нему все четыре железки. > >Бэкэнды лучше сделать более дорогими, а два сервера под виртуализацию использовать что-то >значительно более простое (но лучше с ECC памятью) > >По DAS, в зависимости от Вашего бюджета, я бы смотрела на любой >двухголовый Infortrend, так как дешево и сердито :) ЗЫ а балансировку можно делать, например (но не только) с помощью LVS
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	25. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 06-Май-10, 15:41
	>ЗЫ а балансировку можно делать, например (но не только) с помощью LVS Хотя lvs сам по себе тоже обладает функционалом HA (не только балансировки): может выкидывать из балансировки не отвечающие бэкэнды
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	24. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 06-Май-10, 15:24
	>[оверквотинг удален] >использовать drbd > >Но вообще, лучше взять четырехпортовый DAS с SAS интерфейсом, и прицепить к >нему все четыре железки. > >Бэкэнды лучше сделать более дорогими, а два сервера под виртуализацию использовать что-то >значительно более простое (но лучше с ECC памятью) > >По DAS, в зависимости от Вашего бюджета, я бы смотрела на любой >двухголовый Infortrend, так как дешево и сердито :) Да, и при виртуализации, сервер баз данных может быть и один (все равно будет перезапущен при падении той железки, на которой находится)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	26. "Конвертирование видео на backend'е"		+/–
	Сообщение от ciwl (ok) on 06-Май-10, 16:11
	> >>т.о. вы предлагаете и www-запросы и кодирование выполнять на одном дорогом физическом >>сервере? а если с ним что случиться? в моём варианте, я >>просто меняю упавший сервер (который стоит куда меньше), заливаю бэкап и >>всё продолжает работать > >Нет, я бы вообще сделала по-другому в принципе, при нормальном бюджете: > >Во-первых, нужно разделять HA и балансировку нагрузки, это в принципе разные вещи > угу ) >Во-вторых, я бы кодировала на бэкэндах(где Nginx и лежит статика) с низким >приоритетом. вот я тоже так делаю, только nginx тут не при чём. backend будет исключительно  кодировать, с высоким приоритетом. пока. >В-третьих, я бы вынесла сервера баз данных на две отдельные машины обязательно, но 3м этапом >В-четвертых, я бы отделила фронт-энд для балансировки нагрузки от веб-серверов. есть подробная статья,. тут же http://www.opennet.ru/docs/RUS/webcluster/ > >Бэкэнды лучше бы оставить(имхо) обычными традиционными железками, а для баз данных, управляющего >ПО, и балансировщика нагрузки использовать две железки с какой-нибудь системой виртуализации >(если базы данных не очень сильно нагруженные, обычно на таких задачах >основная нагрузка на бэкэнд) планирую при помощи БД делать распределение задач. что-то вроде своего протокола. > >- Между двумя бэкэндами организуется HA-кластер (например, RedHat Cluster Suite) вот это лишнее (см. пред. пункт). К тому же неохота разводить зоопарк операционных систем (повторюсь - юзаю генту) >- Между нодами виртуализации организуется HA-кластер (виртуалки одной из нод будут перезапущены >в случае ее падения) >- Управляющая нода RedHat Cluster Suite в первом случае виртуалка на кластере >виртуализации >- Во втором случае, ставиться на один из бэкэндов (роль не оказывает >сильной нагрузки). виртуализацию (пока) не планирую использовать - зачем? нескольько серверов, взаимодействие - через БД > > >Для кластера виртуализации _нужно_ общее блочное устройство, для бэкэндов _желательно_ общее дисковое >устройство. >В первом случае, если диск дергается не очень сильно (базами данных) можно >использовать drbd > >Но вообще, лучше взять четырехпортовый DAS с SAS интерфейсом, и прицепить к >нему все четыре железки. > очень нужно )  какие сетевые/кластерные фс посоветуете? железные решения приобретать пока нет возможности >Бэкэнды лучше сделать более дорогими, а два сервера под виртуализацию использовать что-то >значительно более простое (но лучше с ECC памятью) > >По DAS, в зависимости от Вашего бюджета, я бы смотрела на любой >двухголовый Infortrend, так как дешево и сердито :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	27. "Конвертирование видео на backend'е"		+/–
	Сообщение от sHaggY_caT (ok) on 06-Май-10, 17:23
	>[оверквотинг удален] >>приоритетом. > >вот я тоже так делаю, только nginx тут не при чём. backend >будет исключительно  кодировать, с высоким приоритетом. пока. >>В-третьих, я бы вынесла сервера баз данных на две отдельные машины > >обязательно, но 3м этапом >>В-четвертых, я бы отделила фронт-энд для балансировки нагрузки от веб-серверов. > >есть подробная статья,. тут же http://www.opennet.ru/docs/RUS/webcluster/ не понравилось. Имхо, если Linux, стоит использовать стандартный для этой цели LVS >>- Между двумя бэкэндами организуется HA-кластер (например, RedHat Cluster Suite) > >вот это лишнее (см. пред. пункт). К тому же неохота разводить зоопарк >операционных систем (повторюсь - юзаю генту) Насчет Gentoo не знаю, но RHCS есть, например, под Debian(хотя и старый), и, конечно, под CentOS. Про Gentoo: не обжайтесь, но, по-моему, она и серверные задачи не совместимы (если хотите порты, используйте FreeBSD), так как by design отсуствуют стабильные релизы, и Вы в любой момент при накатывании security или bug fix'а можете поймать много проблем (а "работает-не трогай" изначально неверный, для публичных сервисов, подход) >>- Между нодами виртуализации организуется HA-кластер (виртуалки одной из нод будут перезапущены >>в случае ее падения) >>- Управляющая нода RedHat Cluster Suite в первом случае виртуалка на кластере >>виртуализации >>- Во втором случае, ставиться на один из бэкэндов (роль не оказывает >>сильной нагрузки). > >виртуализацию (пока) не планирую использовать - зачем? нескольько серверов, взаимодействие - через >БД Схем может быть много... HA для бэкэндов можно и через LVS получить (без RHCS) Я имела ввиду для других сервисов. Ту же БД или придется делать в двух экземплярах, или на одной виртуалке. Управляющее ПО, сам сайт, на котором будет лежать видео, это еще два сервера (или будут друг другу мешать), если использовать LVS, выделать под нее отдельную железку жалко, проще чуть более мощную виртуалку. >[оверквотинг удален] >>устройство. >>В первом случае, если диск дергается не очень сильно (базами данных) можно >>использовать drbd >> >>Но вообще, лучше взять четырехпортовый DAS с SAS интерфейсом, и прицепить к >>нему все четыре железки. >> > >очень нужно )  какие сетевые/кластерные фс посоветуете? железные решения приобретать пока >нет возможности Мы работали только с gfs, народ еще хвалит ocfs[2], gfs2 мы пока еще не использовали. DAS не так дорого стоит, а drbd означает очень(!) большие тормоза, и требование, на Вашей задаче, очень(!) мощной дисковой подсистемы на каждом сервере (6-го рейда с большим кэшем, защищенным батарейкой на запись может и не хватить, может понадобиться 60 в 2U корпусе), практически то же по деньгам, это DAS с 8-12 SATA дисками и средненьким контроллером. Это же не SAN, не FC, и даже не iscsi, а просто полка с дисками, подключаемая по SAS к нескольким серверам :) Посмотрите цены, уверяю Вас, они не такие большие, и сравнимы со стоимостью хорошего сервера.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема