- что, перевелись спецы или сабж настолько идиотский тривиальный, что лень даже о,
 ciwl (ok), 15:52 , 14-Мрт-10 (1)что, перевелись спецы? или сабж настолько идиотский/тривиальный, что лень даже об этом сказать? )
- Второе , Hate (ok), 10:03 , 01-Май-10 (3)
>что, перевелись спецы? или сабж настолько идиотский/тривиальный, что лень даже об этом
>сказать? ) Второе.
- да вы что ну-ка пруфлинк в студию , ciwl (ok), 13:21 , 04-Май-10 (4)
>>что, перевелись спецы? или сабж настолько идиотский/тривиальный, что лень даже об этом
>>сказать? )
>
> Второе. да вы что! ну-ка пруфлинк в студию...
- Ща, только все брошу Тебя на гугле забанили , Hate (ok), 18:36 , 04-Май-10 (7)
>>>что, перевелись спецы? или сабж настолько идиотский/тривиальный, что лень даже об этом
>>>сказать? )
>>
>> Второе.
>
>да вы что! ну-ка пруфлинк в студию... Ща, только все брошу... Тебя на гугле забанили? :)
- То-то же, уважаемый тролль Ценность ваших постов 0, ciwl (ok), 11:30 , 06-Май-10 (8)
>>>>что, перевелись спецы? или сабж настолько идиотский/тривиальный, что лень даже об этом
>>>>сказать? )
>>>
>>> Второе.
>>
>>да вы что! ну-ка пруфлинк в студию...
>
> Ща, только все брошу... Тебя на гугле забанили? :) То-то же, уважаемый тролль. Ценность ваших постов == 0
- Добрый день А какого рода помощь Вас интересует, конкретизируйте Мы реализовыв, sHaggY_caT (ok), 03:46 , 01-Май-10 (2)
>Добрый день.
>
>Необходимо организовать видеопортал. Одно из условий реализации - видео должно корвертироваться и
>хранится на backend'е, дабы не загружать сам вебсервер.
>
>Какие есть обкатаные схемы реализации подобной задачи? Добрый день. А какого рода помощь Вас интересует, конкретизируйте? Мы реализовывали подобный проект.
- механизм взаимодействия www-сервер --- convert-серверпока ничего умнее не прид, ciwl (ok), 13:26 , 04-Май-10 (5)
>>Добрый день.
>>
>>Необходимо организовать видеопортал. Одно из условий реализации - видео должно корвертироваться и
>>хранится на backend'е, дабы не загружать сам вебсервер.
>>
>>Какие есть обкатаные схемы реализации подобной задачи?
>
>Добрый день. А какого рода помощь Вас интересует, конкретизируйте? Мы реализовывали подобный
>проект. механизм взаимодействия www-сервер <---> convert-сервер пока ничего умнее не придумал, кроме как сделать каталог с "сырым" видео примонтированным по NFS. после загрузки ролика, делается соответствующая запись в БД и конвертирующий сервер начинает его кодировать, выкладывая результат в такую же общую папку, доступную по сети с www-сервера
- gt оверквотинг удален NFS web тормоза гарантированы Можно использовать а , sHaggY_caT (ok), 13:45 , 04-Май-10 (6)
>[оверквотинг удален]
>>
>>Добрый день. А какого рода помощь Вас интересует, конкретизируйте? Мы реализовывали подобный
>>проект.
>
>механизм взаимодействия www-сервер <---> convert-сервер
>
>пока ничего умнее не придумал, кроме как сделать каталог с "сырым" видео
>примонтированным по NFS. после загрузки ролика, делается соответствующая запись в БД
>и конвертирующий сервер начинает его кодировать, выкладывая результат в такую же
>общую папку, доступную по сети с www-сервера NFS+web = тормоза гарантированы. Можно использовать: а) Быстрый линк(bound из нескольких интерфейсов?) и NFSv4: меня терзают сомнения по поводу производительности такой схемы, NFSv3 определенно не подойдет.
б) iscsi через _несколько_ гигабитных интерфейсов в bound,и параллельной ФС вроде gfs
в) мощную дисковую подсистему (быструю, прежде всего, и с хорошим кэшем, защищенным батарейкой, что бы пики раздавал на нескольких гигабитах из кэша, сглаживая рывки), при наличии пункта б) Я бы скорее выделила в отдельную железку (обязательно с двумя блоками питания, и массивом с хорошей избыточностью и производительностью вроде raid60)
Если есть бюджет, то лучше вообще использовать готовый DAS А вообще, схема однозначно дурацкая и бесполезная, а для снижения нагрузки, обычно, выделяют 1. Отдельный акселератор-балансер трафика между web-серверами. Иногда разделяют балансеры и акселераторы.
2. Видео хранят именно на web-серверах (нескольких)
3. Выносят на отдельный сервер базу данных
- gt оверквотинг удален спасибо за ответ с кодированием как поступить понятно,, ciwl (ok), 11:55 , 06-Май-10 (9)
>[оверквотинг удален]
>Я бы скорее выделила в отдельную железку (обязательно с двумя блоками питания,
>и массивом с хорошей избыточностью и производительностью вроде raid60)
>Если есть бюджет, то лучше вообще использовать готовый DAS
>
>А вообще, схема однозначно дурацкая и бесполезная, а для снижения нагрузки, обычно,
>выделяют
>
>1. Отдельный акселератор-балансер трафика между web-серверами. Иногда разделяют балансеры и акселераторы.
>2. Видео хранят именно на web-серверах (нескольких)
>3. Выносят на отдельный сервер базу данных спасибо за ответ.
с кодированием как поступить? понятно, что если заставить web-сервер кодировать видео то долго он не протянет. На данный момент это bottleneck N1
Касаемо хранения видео - да, возможно, имеет смысл действительно хранить его на веб-сервере и по шаре отдавать кодировщику. web соединён с кодировщиком (пока одним) гигабитным линком, скорость обмена ~650Mbps, скорость обмена по NSF намного меньше.
Хотелось бы получить совет по этому поводу (один уже есть - gfs :) )
- gt оверквотинг удален Кодирование можно зарубить cpulimit, или cgroups в пион, sHaggY_caT (ok), 12:09 , 06-Май-10 (10)
>[оверквотинг удален]
>
>спасибо за ответ.
>с кодированием как поступить? понятно, что если заставить web-сервер кодировать видео то
>долго он не протянет. На данный момент это bottleneck N1
>Касаемо хранения видео - да, возможно, имеет смысл действительно хранить его на
>веб-сервере и по шаре отдавать кодировщику. web соединён с кодировщиком (пока
>одним) гигабитным линком, скорость обмена ~650Mbps, скорость обмена по NSF намного
>меньше.
>Хотелось бы получить совет по этому поводу (один уже есть - gfs
> :) ) Кодирование можно зарубить cpulimit, или cgroups в "пионерских" ядрах линуха (но скоро будет в RHEL/CentOS 6)
- gt оверквотинг удален тогда скорость кодирования будет неприемлемо мала, ciwl (ok), 13:06 , 06-Май-10 (11)
>[оверквотинг удален]
>>долго он не протянет. На данный момент это bottleneck N1
>>Касаемо хранения видео - да, возможно, имеет смысл действительно хранить его на
>>веб-сервере и по шаре отдавать кодировщику. web соединён с кодировщиком (пока
>>одним) гигабитным линком, скорость обмена ~650Mbps, скорость обмена по NSF намного
>>меньше.
>>Хотелось бы получить совет по этому поводу (один уже есть - gfs
>> :) )
>
>Кодирование можно зарубить cpulimit, или cgroups в "пионерских" ядрах линуха (но скоро
>будет в RHEL/CentOS 6) тогда скорость кодирования будет неприемлемо мала
- gt оверквотинг удален С cgroups можно ставить мягкие и жесткие лимиты Кроме то, sHaggY_caT (ok), 13:46 , 06-Май-10 (12)
>[оверквотинг удален]
>>>веб-сервере и по шаре отдавать кодировщику. web соединён с кодировщиком (пока
>>>одним) гигабитным линком, скорость обмена ~650Mbps, скорость обмена по NSF намного
>>>меньше.
>>>Хотелось бы получить совет по этому поводу (один уже есть - gfs
>>> :) )
>>
>>Кодирование можно зарубить cpulimit, или cgroups в "пионерских" ядрах линуха (но скоро
>>будет в RHEL/CentOS 6)
>
>тогда скорость кодирования будет неприемлемо мала С cgroups можно ставить мягкие и жесткие лимиты.
Кроме того, можно просто поставить в сервер несколько cpu-ядер, и посадить процесс(ы) кодирования на специально для этого предназначенные ядра (можно и в RHEL/CentOS уже сейчас)
- gt оверквотинг удален P S cgroups так же есть в в Debian Squeeze еще не выше, sHaggY_caT (ok), 13:50 , 06-Май-10 (13)
>[оверквотинг удален]
>>>
>>>Кодирование можно зарубить cpulimit, или cgroups в "пионерских" ядрах линуха (но скоро
>>>будет в RHEL/CentOS 6)
>>
>>тогда скорость кодирования будет неприемлемо мала
>
>С cgroups можно ставить мягкие и жесткие лимиты.
>Кроме того, можно просто поставить в сервер несколько cpu-ядер, и посадить процесс(ы)
>кодирования на специально для этого предназначенные ядра (можно и в RHEL/CentOS
>уже сейчас) P.S. cgroups так же есть в в Debian Squeeze (еще не вышел официально, но, говорят, уже можно использовать)
- gt оверквотинг удален с жёсткими лимитами неустраивает скорость кодирования с, ciwl (ok), 14:14 , 06-Май-10 (14)
>[оверквотинг удален]
>>>
>>>тогда скорость кодирования будет неприемлемо мала
>>
>>С cgroups можно ставить мягкие и жесткие лимиты.
>>Кроме того, можно просто поставить в сервер несколько cpu-ядер, и посадить процесс(ы)
>>кодирования на специально для этого предназначенные ядра (можно и в RHEL/CentOS
>>уже сейчас)
>
>P.S. cgroups так же есть в в Debian Squeeze (еще не вышел
>официально, но, говорят, уже можно использовать) с жёсткими лимитами неустраивает скорость кодирования. с мягкими будет страдать производительность веб-сервера. Несколько ядер на несколько процессов кодирования - интересно, но пока нет финансовой возможности юзать дорогое железо, да и непонятно как это будет работать. А вот держать отдельную машину под кодирование - самое оно ИМХО, только взаимодействие надо наладить. ЗЫ юзаю генту
- gt оверквотинг удален Не будет, по крайней мере в OVZ PVC не страдает опыт экс, sHaggY_caT (ok), 14:22 , 06-Май-10 (15)
>[оверквотинг удален]
>>>
>>>С cgroups можно ставить мягкие и жесткие лимиты.
>>>Кроме того, можно просто поставить в сервер несколько cpu-ядер, и посадить процесс(ы)
>>>кодирования на специально для этого предназначенные ядра (можно и в RHEL/CentOS
>>>уже сейчас)
>>
>>P.S. cgroups так же есть в в Debian Squeeze (еще не вышел
>>официально, но, говорят, уже можно использовать)
>
>с жёсткими лимитами неустраивает скорость кодирования. с мягкими будет страдать производительность веб-сервера. Не будет, по крайней мере в OVZ/PVC не страдает(опыт эксплуатации более сотни PVC и OVZ нод), а Cgroups во многом это код Parallels из того же OVZ. Просто ставите совсем маленький приоритет на группу процессов, кодирующую видео, и по-больше на рабочие...
- gt оверквотинг удален как же не будет, если ему web-серверу самому надо спра, ciwl (ok), 14:32 , 06-Май-10 (16)
>[оверквотинг удален]
>>>
>>>P.S. cgroups так же есть в в Debian Squeeze (еще не вышел
>>>официально, но, говорят, уже можно использовать)
>>
>>с жёсткими лимитами неустраивает скорость кодирования. с мягкими будет страдать производительность веб-сервера.
>
>Не будет, по крайней мере в OVZ/PVC не страдает(опыт эксплуатации более сотни
>PVC и OVZ нод), а Cgroups во многом это код Parallels
>из того же OVZ. Просто ставите совсем маленький приоритет на группу
>процессов, кодирующую видео, и по-больше на рабочие... как же не будет, если ему (web-серверу) самому надо справлятся со своей работой (это следующий bottleneck, после кодирования) а тут ещё и кодировать заставляют что-то?
перенеся процесс на отдельный физ.сервер я избавляюсь от лишних головняков, получаю стабильность. В будущем, планирую ставить ещё сервера кодирования с возможностью кодировать 1 ролик на нескольких машинах одновременно. Софт под эту задачу написан на 70%
- линк по сабжу http www intuitive sk fflib post how-to-make-youtube-with-fflib-, ciwl (ok), 14:35 , 06-Май-10 (17)
- ужс, зачем дотнеты Не вчитывалась внимательно , sHaggY_caT (ok), 15:03 , 06-Май-10 (19)
- там суть не в дотнетах, а в описании самого принципа см картинку , ciwl (ok), 15:07 , 06-Май-10 (21)
- Исходя из опыта, в OVZ не мешает, хорошая изоляция в отличае от renice, который,, sHaggY_caT (ok), 14:58 , 06-Май-10 (18)
>>Не будет, по крайней мере в 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% - gt оверквотинг удален т о вы предлагаете и www-запросы, и кодирование выполня, ciwl (ok), 15:03 , 06-Май-10 (20)
>[оверквотинг удален]
>
>Единственное, что может ухудшиться, это количество переключений контекста, но оно все равно
>составляет доли процента от общего времени, да и кодировать Вы будете
>не в 100-200 потоков, а в 1-2, так что этим можно
>пренебречь.
>
>>перенеся процесс на отдельный физ.сервер я избавляюсь от лишних головняков, получаю стабильность.
>>В будущем, планирую ставить ещё сервера кодирования с возможностью кодировать 1
>>ролик на нескольких машинах одновременно. Софт под эту задачу написан на
>>70% т.о. вы предлагаете и www-запросы, и кодирование выполнять на одном дорогом физическом сервере? а если с ним что случиться? в моём варианте, я просто меняю упавший сервер (который стоит куда меньше), заливаю бэкап и всё продолжает работать виртуализация, бесспорно, вещь хорошая, но в моём случае она только добавляет ряд хлопот и снижает стабильность
- Нет, я бы вообще сделала по-другому в принципе, при нормальном бюджете Во-первы, sHaggY_caT (ok), 15:16 , 06-Май-10 (22)
>т.о. вы предлагаете и www-запросы и кодирование выполнять на одном дорогом физическом
>сервере? а если с ним что случиться? в моём варианте, я
>просто меняю упавший сервер (который стоит куда меньше), заливаю бэкап и
>всё продолжает работать Нет, я бы вообще сделала по-другому в принципе, при нормальном бюджете: Во-первых, нужно разделять HA и балансировку нагрузки, это в принципе разные вещи
Во-вторых, я бы кодировала на бэкэндах(где Nginx и лежит статика) с низким приоритетом.
В-третьих, я бы вынесла сервера баз данных на две отдельные машины
В-четвертых, я бы отделила фронт-энд для балансировки нагрузки от веб-серверов. Бэкэнды лучше бы оставить(имхо) обычными традиционными железками, а для баз данных, управляющего ПО, и балансировщика нагрузки использовать две железки с какой-нибудь системой виртуализации (если базы данных не очень сильно нагруженные, обычно на таких задачах основная нагрузка на бэкэнд) - Между двумя бэкэндами организуется HA-кластер (например, RedHat Cluster Suite)
- Между нодами виртуализации организуется HA-кластер (виртуалки одной из нод будут перезапущены в случае ее падения)
- Управляющая нода RedHat Cluster Suite в первом случае виртуалка на кластере виртуализации
- Во втором случае, ставиться на один из бэкэндов (роль не оказывает сильной нагрузки).
Для кластера виртуализации _нужно_ общее блочное устройство, для бэкэндов _желательно_ общее дисковое устройство.
В первом случае, если диск дергается не очень сильно (базами данных) можно использовать drbd
Но вообще, лучше взять четырехпортовый DAS с SAS интерфейсом, и прицепить к нему все четыре железки. Бэкэнды лучше сделать более дорогими, а два сервера под виртуализацию использовать что-то значительно более простое (но лучше с ECC памятью) По DAS, в зависимости от Вашего бюджета, я бы смотрела на любой двухголовый Infortrend, так как дешево и сердито :)
- gt оверквотинг удален ЗЫ а балансировку можно делать, например но не только , sHaggY_caT (ok), 15:19 , 06-Май-10 (23)
>[оверквотинг удален]
>использовать drbd
>
>Но вообще, лучше взять четырехпортовый DAS с SAS интерфейсом, и прицепить к
>нему все четыре железки.
>
>Бэкэнды лучше сделать более дорогими, а два сервера под виртуализацию использовать что-то
>значительно более простое (но лучше с ECC памятью)
>
>По DAS, в зависимости от Вашего бюджета, я бы смотрела на любой
>двухголовый Infortrend, так как дешево и сердито :) ЗЫ а балансировку можно делать, например (но не только) с помощью LVS - Хотя lvs сам по себе тоже обладает функционалом HA не только балансировки мож, sHaggY_caT (ok), 15:41 , 06-Май-10 (25)
>ЗЫ а балансировку можно делать, например (но не только) с помощью LVS Хотя lvs сам по себе тоже обладает функционалом HA (не только балансировки): может выкидывать из балансировки не отвечающие бэкэнды
- gt оверквотинг удален Да, и при виртуализации, сервер баз данных может быть и , sHaggY_caT (ok), 15:24 , 06-Май-10 (24)
>[оверквотинг удален]
>использовать drbd
>
>Но вообще, лучше взять четырехпортовый DAS с SAS интерфейсом, и прицепить к
>нему все четыре железки.
>
>Бэкэнды лучше сделать более дорогими, а два сервера под виртуализацию использовать что-то
>значительно более простое (но лучше с ECC памятью)
>
>По DAS, в зависимости от Вашего бюджета, я бы смотрела на любой
>двухголовый Infortrend, так как дешево и сердито :) Да, и при виртуализации, сервер баз данных может быть и один (все равно будет перезапущен при падении той железки, на которой находится)
- угу вот я тоже так делаю, только nginx тут не при чём backend будет исключител, ciwl (ok), 16:11 , 06-Май-10 (26)
>
>>т.о. вы предлагаете и www-запросы и кодирование выполнять на одном дорогом физическом
>>сервере? а если с ним что случиться? в моём варианте, я
>>просто меняю упавший сервер (который стоит куда меньше), заливаю бэкап и
>>всё продолжает работать
>
>Нет, я бы вообще сделала по-другому в принципе, при нормальном бюджете:
>
>Во-первых, нужно разделять HA и балансировку нагрузки, это в принципе разные вещи
>угу )
>Во-вторых, я бы кодировала на бэкэндах(где Nginx и лежит статика) с низким
>приоритетом. вот я тоже так делаю, только nginx тут не при чём. backend будет исключительно кодировать, с высоким приоритетом. пока.
>В-третьих, я бы вынесла сервера баз данных на две отдельные машины обязательно, но 3м этапом
>В-четвертых, я бы отделила фронт-энд для балансировки нагрузки от веб-серверов. есть подробная статья,. тут же http://www.opennet.me/docs/RUS/webcluster/
>
>Бэкэнды лучше бы оставить(имхо) обычными традиционными железками, а для баз данных, управляющего
>ПО, и балансировщика нагрузки использовать две железки с какой-нибудь системой виртуализации
>(если базы данных не очень сильно нагруженные, обычно на таких задачах
>основная нагрузка на бэкэнд) планирую при помощи БД делать распределение задач. что-то вроде своего протокола.
>
>- Между двумя бэкэндами организуется HA-кластер (например, RedHat Cluster Suite) вот это лишнее (см. пред. пункт). К тому же неохота разводить зоопарк операционных систем (повторюсь - юзаю генту)
>- Между нодами виртуализации организуется HA-кластер (виртуалки одной из нод будут перезапущены
>в случае ее падения)
>- Управляющая нода RedHat Cluster Suite в первом случае виртуалка на кластере
>виртуализации
>- Во втором случае, ставиться на один из бэкэндов (роль не оказывает
>сильной нагрузки). виртуализацию (пока) не планирую использовать - зачем? нескольько серверов, взаимодействие - через БД
>
>
>Для кластера виртуализации _нужно_ общее блочное устройство, для бэкэндов _желательно_ общее дисковое
>устройство.
>В первом случае, если диск дергается не очень сильно (базами данных) можно
>использовать drbd
>
>Но вообще, лучше взять четырехпортовый DAS с SAS интерфейсом, и прицепить к
>нему все четыре железки.
> очень нужно ) какие сетевые/кластерные фс посоветуете? железные решения приобретать пока нет возможности
>Бэкэнды лучше сделать более дорогими, а два сервера под виртуализацию использовать что-то
>значительно более простое (но лучше с ECC памятью)
>
>По DAS, в зависимости от Вашего бюджета, я бы смотрела на любой
>двухголовый Infortrend, так как дешево и сердито :) - gt оверквотинг удален не понравилось Имхо, если Linux, стоит использовать ста, sHaggY_caT (ok), 17:23 , 06-Май-10 (27)
>[оверквотинг удален]
>>приоритетом.
>
>вот я тоже так делаю, только nginx тут не при чём. backend
>будет исключительно кодировать, с высоким приоритетом. пока.
>>В-третьих, я бы вынесла сервера баз данных на две отдельные машины
>
>обязательно, но 3м этапом
>>В-четвертых, я бы отделила фронт-энд для балансировки нагрузки от веб-серверов.
>
>есть подробная статья,. тут же http://www.opennet.me/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 к нескольким серверам :)
Посмотрите цены, уверяю Вас, они не такие большие, и сравнимы со стоимостью хорошего сервера.
|
Свернуть нити
Пометить прочитанным
Создать тему
