Регистрация потока

[abc]

Знакомый попросил прикинуть, во что выльется решение такой вот задачи.
Нужно обеспечить регистрацию непрерывного входного потока 100 МБайт/сек в течении суток. Потом накопленная инфа будет как-то  обрабатываться. Требования по надежности отсутствуют (это пока, потом, думаю, они появятся  :lol: ). Каким может быть решение?
Думаю, нормальный сервер с таким потоком справится, нужно только разнести входной и выходной поток по разным PCI-X; а заливать это все на RAID-0 с числом шпинделей поболе. И вот с этим числом главный вопрос - как рассчитать, чтобы не возникало критических задержек. Кеширование конечно что-то сгладит, но не надолго.
Второй вопрос - это файловая система, которая будет вносить ощутимые задержки. В *nix кажется воможно  (:oops: слаб я в этом) представление всего диска как потока, можно ли это здесь применить? В Windows - и этого нету.
Конечно, специализированный драйвер, обеспечивающий линейную запись без всяких индексов и пр. был-бы лучшим решением, но им самим это не сделать.
И третий вопрос - наверно есть специализированные системы такого рода, подскажите, кто знает, в каком направлении искать...

[a_shats]

На самом деле сервер с современным RAID контроллером и WB кэшем может выжать на синтетике (IOmeter) порядка  130-170 МБайт/сек.
Но - я принципиально не рекомендую так делать, ибо запас остается весьма и весьма скромный.
Я бы порекомендовал все же задуматься о FC-FC аппарате типа Chaparral RIVA (R2500) с 1 ГБ кэша на кажды из двух его контроллеров - вот он реально способен спокойно переварить такой поток, и с запасом - на всякие непредвиденные случаи. Опять же в Риве на этот счет есть возможность отключения синхронизации кэша на контроллерах - что позволит солидноподнять производительность на запись (практически - к включенной синхронизацией кэшей порядка 190 МБайт/сек, с выключенной можно выжать вдвое больше - если лить через разные контроллеры на разные LUNы, конечно же.

[abc]

...на синтетике (IOmeter) порядка  130-170 МБайт/сек.

Синтетика - это по совокупности запись/чтение? (мне с IOmeter работать не приходилось, увы). Но здесь же будет непрерывный поток записи, и кеширование работает только на сглаживание пиков; чтения же практически не будет, работа с таблицами размещения не в счет, мизер - и тогда что WB, что сквозная запись, все едино.
ИМХО, тут все определяется самими дисками, сколько они сумеют принять. До уровня набортного буфера дисков должно бы пролетать без проблем - а дальше механика и собственно запись. И вроде число дисков просто рассчитать, берем эти 100 мегабайт/сек, делим на размер буфера, умножаем на максимальное время разгрузки буфера и вот результат! Вот только где это время взять-то?

Я бы порекомендовал все же задуматься о FC-FC аппарате типа Chaparral RIVA (R2500) с 1 ГБ кэша на кажды из двух его контроллеров - вот он реально способен спокойно переварить такой поток, и с запасом - на всякие непредвиденные случаи.

Ну я тоже про это сразу подумал, хотя сам и не имел дела с подобными штуками, форум-то читаю  . Только человек еще морально не готов решать задачу в килобаксах, надеется (пока!) на более легкие варианты.

[gs]

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

Но есть другое соображение. Вы умножьте цифру потока на число секунд в сутках. Получится потребный объем. А такой объем осилит только дисковая система нехилого класса (которая и скорость автоматически обеспечит). Так что стоит задумываться не о килобаксах, а о десятках-сотнях килобаксов.
Или умерить аппетиты.

[abc]

Такую задачу рассчетным путем могут решать только оголтелые оптимисты.

Это я-то? Ни в коем случае!

В реальности переменных столько, что лучше оперировать цифрами реальных испытаний.

И кто здесь оптимист?  :lol: Чтобы испытывать, нужно хоть что-то подобное собрать, а это та еще задачка.

Вы умножьте цифру потока на число секунд в сутках. Получится потребный объем. А такой объем осилит только дисковая система нехилого класса (которая и скорость автоматически обеспечит).

Один в один моя первоначальная реакция. А потом я призадумался: 30 дисков по 300GB нужную емкость дадут (КАК это будет - пока не рассматриваем). А нужную скорость обеспечат? по-моему - нет. То есть класс еще не гарантия - можно промахнуться, в спецификациях-то средняя или пиковая скорость, а этого для реал-тайм недостаточно. Нужна методика расчета, чтобы решить, можно ли вообще использовать для такой задачи универсальную дисковую систему.
Про специализированные решения пока же ничего нету, увы...

Так что стоит задумываться не о килобаксах, а о десятках-сотнях килобаксов.

Ну я имел ввиду, что в прайс-листе: диск - 300$, сервер - 6000$... а тут система - XXX K$.

[gs]

Я честно говоря уже наелся такого рода самопальных массивов. Обычно это плохо кончается.
Максимум, что можно посоветовать - несколько серверов в корпусах типа Supermicro SC933T-R760 и с парой контроллеров 3ware 9500S-8. За надежность такой банки еще как-то можно поручиться. Больше винтов в один сервер - я бы от такой сделки отказался сразу.
Или как вариант FC-SATA Infortrend - относительно дешево, но достаточно быстро и надежно.
Не просто так придуманы внешние массивы - RIVA действительно обеспечит гарантированный поток и надежность.

[abc]

Самопальные решения - это, конечно, плохо. Но, согласитесь, и вариант: взять RIVA в максимальной конфигурации, и она перекроет все запросы - тоже не очень вдохновляет. Хотя бы потому, что в спецификации не написано, в какой конфигурации достигается "551MB/second sequential RAID-5 writes to disk", и как зависит эта скорость от конфигурации.
Процессы реального времени нужно рассчитывать на худший случай, но как раз эти параметры и неизвестны. Вот и приходится заниматься странными изысканиями.

А Infortrend - это набирать конфигурацию Head плюс JBOD модули, или есть лучше варианты по критерию функциональность/цена?

[gs]

Параметры РИВЫ очень хорошо расписаны в перфоманс репорте, который, к сожалению, для служебного пользования. Вы лучше точнее сформулируйте задачу - мы точно и ответим, на что она способна. Что касается приведенной Вами цифры, то это линейная запись в несколько потоков через несколько каналов (одного канала ей просто мало - она и 3 забивает запросто, причем как на чтение, так и на запись) на минимум два тома, развешанные на два контроллера с выключенным кэш-миррорингом. И она эти цифры честно выдает - проверяли. Винтов при этом в перфрепорте 64шт по 10к, но и на 32 она примерно то же самое кажет.

В варианте Инфортренд модульная система только FC-FC. Тогда уж лучше РИВУ взять - ценники более-менее сравнимы, а скорострельность ее проверена боем.
Но я имел в виду несколько аппаратов FC-SATA немасштабируемых 16-ти дисковых. Они намного дешевле и довольно шустрые. Хотя конечно по скорости записи сильно уступают FC-FC системам.

[abc]

С RIVA примерно понятно. 32 диска - это уже ответ. Но задача не моя, и я сам имею только одну цифру: всего 100 мегабайт/сек, зато непрерывно. Приоткройте еще чуть-чуть, там величины нерегулярных задержек нормируются? типа перекалибровки, ошибки верификации, перенаправление секторов и прочее? Все же интересует возможность минимизировать конфиг по заданной вероятности потери данных (или там по любому гарантия 100%?).
Про Infortrend еще немножко, пожалуйста.
Если набирать нужную емкость из нескольких FC-SATA, как они выглядят со стороны хоста - как отдельные драйвы или образуют единое логическое устройство? В спецификации про возможность наращивания есть, но этот момент не ясен.

[gs]

Величины задержек не нормируются. Но этим можно пренебречь - при таком числе шпинделей и наличии кэша этого просто не видно.
Плохо, если во время линейной записи кто-то еще на диск ломанется - кэша контроллера может не хватить, чтобы сгладить рывок. Но это собственно уже не совсем проблема контроллера - это надо решать админскими мерами.

Про вероятность потери данных - сорри, не понял. В иистеме присутствуют все стандартные методы защиты. Но в цифрах это выразить весьма затруднительно. Но 100% в природе не бывает. Даже на Хитачи ЮСП

32 винта я к слову сказал. Нужный Вам поток она легко выдаст и при 16 винтах (да и с 8 скорее всего).

Несколько немасштабируемых массивов будут выглядеть как насколько отдельных дисков (да собственно многие массивы ограничивают размер тома до 2ТБ). Но это дело не так уж важно -винда все равно больше 2ТБ не понимает.

[gs]

Кстати как промежуточный вариант можно рассмотреть LSI (ex IBM) ProFibre DF4000R. Это FC-FC энтри левел. Он 120-150МБ/с на запись может дать. Только там на предмет стабильности потока надо настройки кэша поковырять (мы скажем что и как).

[abc]

Большое спасибо!
Область поиска решения достаточно определилась.
Теперь время собирать деньги