Эта небольшая заметка посвящена одной часто встречающейся проблеме, о которой много говорят в различных форумах сети. Ее можно формулировать по разному, например так: почему оказываются неэффективными сетевые устройства хранения данных ( NAS – Network Attached Storage ) для совместного редактирования видео в рабочих группах.

История вопроса такова: с повсеместным переходом ряда телекомпаний на обработку несжатого SD видео (и тем более различных форматов HD видео) потребность в огромных массивах для хранения и доступа к видеоданным резко возросла. Кроме этого, стало крайне неудобным держать видеоданные на локальных массивах без возможности групповой работы над одним и тем же материалом. Разумеется, взоры администраторов обратились в первую очередь к локальной сети, поскольку в любой организации из более чем трех сотрудников она обычно есть всегда «по определению». Идея очевидна — подключить к приличному серверу (серверам) внешние дисковые массивы с емкостью в нужное количество терабайт, далее соединить такие сервера гигабитной сетью с компьютерами пользователей и все.

Элементарные расчеты показывают, что вроде бы все должно получиться. Реальная полоса гигабитной сети 60-70 мегабайт в секунду, и ее должно хватить чуть ли на 20 DV потоков, что по 3.5 мегабайт в секунду. Иными словами, вроде бы 10 человек могут в реальном времени смотреть и редактировать DV видео (если рабочая станция + программа позволяют) без каких-либо проблем. Сказано – сделано. И ряд студий попытались внедрить у себя подобные системы. Результат оказался плачевным — не то что 10, даже 5 человек не могли комфортно работать с DV видео. И самое парадоксальное в том, что чем проще была работа (чем проще используемые эффекты и переходы), тем более дискомфортным было ее выполнение. Вроде бы все правильно делается, да и формально работать можно, но вот производительность труда, если можно так выразиться, никакая. Понятно, что следующий вопрос будет из разряда вечных: «Кто виноват и что делать?».

Кто виноват?

В начале, как обычно, возникает подозрение, что не оптимально использована и/или сконфигурирована сеть в студии. Попавшийся под горячую руку системный администратор может быть предупрежден о неполном служебном соответствии, а то и просто наказан. Все исходные расчеты ожидаемой производительности перепроверены еще раз, но на конечный результат это никак не влияет! При этом толковый сисадмин с помощью тестов убедительно доказывает, что с сервера уходит требуемый поток, так что Ethernet сеть работает как часы, а далее умывает руки. Как это не печально, он будет абсолютно прав. Даже выжав оптимизацией топологии, применением и правильной настройкой дорогих коммутаторов из сети все, что можно, комфортной работы на гигабитном Ethernet не получится.

Ключевой фразой здесь является понятие комфортной работы. Суть проблемы в том, что большинством пользователей не учитывается тот простой факт, что для нормальной (привычной) работы с видео пропускная способность канала «видеоредактор — данные» должна быть как минимум не меньше канала «локальный диск — программа». В противном случае любой человек немедленно почувствует заметную задержку в отклике системы, а это и есть дискомфорт. Если же скорость падает на порядок, как в примере выше, то работа становится просто невыносимой.

Что же происходит, когда данные находятся где-то там в сети, а не на собственном локальном диске? Все очень просто — программа начинает обработку, но ей приходится долго (по сравнению с локальным диском) ждать запрошенных данных. Разница особо разительна, когда обработка видеокадров на рабочей станции происходит быстрее «реального» времени. Поскольку полоса в сети делится между всеми пользователями, то и время реакции на каждый запрос видеомонтажной программы увеличивается в разы по сравнению с локальным диском. Разница между работой с локальным диском (под локальным диском здесь и далее мы будем понимать любой локальный диск, массив и т.п.) и работой по сети будет тем больше, чем мощнее рабочая станция и чем быстрее ее локальный диск. Пропускная способность сети фактор постоянный — и в результате, перекачивая туда-сюда данные по сети, практически уменьшается производительность собственно рабочей станции.

Иными словами, разница между работой по сети и с локальным диском для старого компьютера с двумя процессорами Pentium III 800 MHz будет весьма небольшой по сравнению с рабочей станцией на современном двухъядерном процессоре Pentium D 3.2 GHz. Вполне возможно, что пользователь старого компьютера даже не заметит разницы: локальные диски его компьютера намного медленнее современных, да и процессорам не требуется быстрая подача данных, поскольку они все равно не успеют их обработать. Напротив, на современной рабочей станции все упрется в скорости приема/передачи данных для обработки, и на ней разница в скорости работы будет заметна даже неспециалисту.

Что делать?

К сожалению, в рамках гигабитного Ethernet ничего сделать нельзя. Больше пары-тройки пользователей подключить к групповой работе по сети не стоит даже для работы с DV, не говоря уже о больших потоках. Светлое будущее за 10 гигабитным Ethernet и iSCSI, в этом нет никакого сомнения. Но когда наступит это светлое будущее? Основной сдерживающий фактор здесь — высокая стоимость оборудования для 10 Gbit сети. Сетевые карты от $900 и коммутаторы от $500 за порт не вдохновляют на приобретение этой неплохой технологии. К тому же внешних массивов и контроллеров iSCSI реально пока еще нет в продаже, и когда будут неизвестно поскольку — см. выше – слишком высока стоимость 10 Gbit оборудования.

Поэтому единственный на сегодня и на ближайшие год-два реальный путь совместного редактирования в рабочих группах — это применение 4Gbit Fibre Channel оборудования, построение SAN ( Storage Area Network ) хранилищ. Конечно, назвать Fibre Channel оборудование дешевым тоже никак нельзя, но оно все-таки более доступно, по крайней мере существенно дешевле оборудования 10 Gbit Ethernet. И, наконец, для Fibre Channel серийно выпускаются сравнительно недорогие внешние дисковые массивы. Полосы пропускания 4Gbit Fibre Channel в 400 мегабайт в секунду в одну сторону и столько же обратно с лихвой хватает для подавляющего большинства задач. А применение multipath технологии позволяет даже удвоить полосу пропускания и получить результат, полностью перекрывающий реальные потребности не только сегодня, но и на ближайшие годы.

По материалам компании Стоик