Система хранения медиа данных с 10G доступом

    Эта статья — развитие идеи создания 10G сети для обработки изображений.

    Заказчик — небольшая фотостудия, активно снимающаяся всевозможные eventы — свадьбы, встречи, корпоративные праздники и т.д.
    После дня съемки одним-двумя фотографами надо быстро отсортировать до нескольких тысяч фотографий, сделать предварительную выборку лучших, быстро их обработать и представить заказчику первую версию выборки фотоснимков.
    Иногда к этому добавляется видео съемка мероприятия.
    Позже часто требуется более тонкая обработка фото и видео материалов, верстка фотоальбомов и фотокниг, подготовка коротких фильмов.
    Со стороны компьютерной системы нужна высокая емкость (в год студия производит порядка 10 терабайт фото-видео материалов) и высокая скорость доступа к имеющейся фото и видео библиотеке с 3-4 компьютеров. В основном это компьютеры производства Apple.
    Через год примерно 90-95% фото-видео контента стирается, оставшиеся 5-10% сохраняются на несколько лет.

    Учитывая пожелания по суммарному объему хранимых данных, было предложено использовать сетевое хранилище NAS с емкостью не менее 6 дисков. В результате было выбрано 8 дисковое хранилище, но на начальном этапе в него было установлено 6 дисков по 3ТБ.
    Потребность в быстром доступе к сетевым ресурсам с компьютеров Apple реализовали двумя способами:
    проводной доступ через конвертер Thunderbolt — 10G Ethernet.
    беспроводной доступ для ноутбуков был реализован на стандарте WiFi AC.

    Сетевым хранилищем была выбрана модель QNAP TS-870Pro. С оборудованием этой компании я работаю уже немало лет, и опыт пока имею только положительный.

    TS-870Pro


    Модели с индексом Pro позволяют устанавливать дополнительную сетевую карту, в том числе с 10 гигабитными портами. Такие модели выпускаются уже не первый год, но в моем проекте использвались впервые. Предыдущие решения, в которых были 10гигабитные магистрали, строились на основе Windows серверов, поэтому было интересно, как поведет себя NAS при работе в такой скоростной сети.
    Некоторым ограничением был довольно короткий список совместимых 10G сетевых карт. К счастью, у дистрибьютора нашлась одна из подходящих моделей — Emulex OCe11102-NX.
    Карта была установлена в NAS и “завелась” без каких-либо проблем.

    Emulex 10G

    Подключена она была через коммутатор с 10G SFP+ портами кабелем прямого подключения.
    Один из компьютеров удалось подключить по медному SFP+ кабелю, другой — по оптике-мультимоду через SFP+ трансиверы. Трансиверы использовались китайские, от 10Gtek.
    Но на тестах использовались только медные кабели.

    TS-870Pro back

    На накопителе была установлена последняя доступная на момент тестирования версия firmware 4.1.1.
    Тестировалась конфигурация на основе RAID5 — та, которая и будет работать у заказчика.
    Для начала были запущены несколько синтетических тестов.
    Один из наиболее известных — Intel NASPT.

    NASPT Sum

    Несколько подозрительным выглядит значение для HD Video Record, Похоже, это результат кеширования.
    А вот результат для одновременного чтения и записи интересен для нашего случая. И он получился вполне достойным.

    HD Video 1Play 1Record

    Тест от Atto показал следующее:

    Atto

    Но все это синтетические тесты.
    Интересно было понять, какая скорость чтения-записи получилась на реальных задачах.
    Вот как выглядит Dashboard на NAS. Сначала была операция чтения с хранилища, потом чтения и запись (с разных компьютеров), потом опять чтение:

    Dashboard

    Как можно предположить, мы использовали всю производительность нашей дисковой подсистемы. Только на чтение получаем чуть меньше 500 мегабайт в секунду. Добавляем процесс записи — и скорость чтения пропорционально падает.
    Если посмотреть в операциях ввода-вывода, получаем порядка 5000-6000 IOPS, latency в районе 130мсек.

    IOPS

    Загрузка процессора хранилища при этом не превышает 50%. Интересно, что загрузка распределяется по 4 ядрам CPU достаточно равномерно.

    На считывании больших файлов (имитация работы со “слоеными” файлами Photoshop и видео файлами) получалась скорость порядка 400-450 мегабайт в секунду.

    Read from NAS

    На сколько это хорошо для устройства класса SOHO — мне сказать сложно. Было бы интересно узнать, какие результаты получались на других моделях сетевых накопителей подобного класса.

    По ощущениям от работы в программах, работающих со множеством графических файлов, типа Lightroom, Premiere Pro, скорость работы при “пролистывании” каталога картинок, кэшировании видео файлов и других операциях, в которых скорость считывания будет определяющей, по сравнению с гигабитным подключением, скорость возросла в несколько раз.
    Работа в задачах, для которых важна еще и скорость обработки информации, хотя и возросла, но не так значительно. Это были задачи генерации JPG файлов и слайд шоу видео роликов из RAW файлов, размером по 30–50мегабайт каждый. В этом случае заметна стала разница в мощности процессора используемых компьютеров. Скачивать-то данные мы можем быстро, а их обработка в нашем случае “упирается” в производительность процессора.

    Для резервного копирования используется внешние диски, подключаемые по USB3, и копирование в “облако” CrashPlan.

    Кому может быть полезно такое решение?
    На мой взгляд, это небольшие студии, работающие с потоком фото и видео материалов. Если людей, обрабатывающих эти материалы больше одного, и работать они могут с разных компьютеров, появляется смысл в организации всех медиа файлов, часто разбросанных по множеству внешних дисков, на одном устройстве. И скорость доступа повышается (на обычных внешних дисках я не видел скорости чтения-записи больше 100-120 мегабайт в секунду), и защита от сбоев одиночных дисков, и автоматическое резервное копирование можно настроить.
    Кроме этого подобный NAS предоставляет еще много дополнительных функций. Для кого-то будет важна его возможность работать сервером видеонаблюдения, кто-то использует его для закачки torrentов, кому-то покажется полезной возможность встроенного XBMC плеера.

    А вот чем эта система сама по себе точно не является, так это backup системой. При условии, что она у вас одна. RAID5 хоть и защищает от одиночного сбоя диска, не переживет выхода из строя второго диска, пока первый синхронизируется после замены сбойнувшего. Никто не мешает организовать RAID10 или RAID6, но потери полезного дискового пространства будут значительны, да и в случае затопления или пожара это не поможет. В этом случае — либо синхронизация со вторым таким же устройством, расположенным в географически удаленном месте, либо резервные копии на внешние диски, либо резервное копирование “в облако”, что и было реализовано в этом проекте.

    Мне было бы интересно узнать, как подобную задачу хранения — доступа к фото-видео исходникам при не-корпоративном бюджете решали «коллеги по цеху».
    Share post

    Comments 39

      +7
      Чего тут еще понимать! Дергай за ручки да верти руль. Покупаешь 10G сетевуху, втыкаешь ее в USB-порт NAS'а… image
        +5
        А на каких дисках вы получили 6000 IOPS? Ну, и «сколько раз твердили миру» — не используйте RAID5, это опасно на больших емкостях.
          0
          WD Red 3TB
            0
            Тут ещё стоило бы уточнить протокол (CIFS/NFS), задержки, соотношение чтение/запись, средний размер оперируемого блока и рандумность. Хотя рандомность полагаю = 0%, т.е. в принципе нет — все данные это фотографии большего размера.
            Сами по себе иопсы — попугаи без удава.
            alsakharov
              0
              Доступ был по SMB.
              В тестах использовались RAW файлы размером от 20 до 50 мегабайт и файлы с видео по несколько гигибайт.
              Я вполне допускаю, что IOPS тут далек от реальности. Но в реальности этот параметр не сильно и нужен. Скорость считывания-записи — вот что актуально.
                0
                У вас на картинке не видно латенси. Подскажите какое оно было?
                И IOPS это на фронтенде ведь?
                  0
                  Вот ссылка на оригинал картинки
                  www.flickr.com/photos/21927555@N03/15795017550/in/set-72157647345967434

                  Но на графике, выдаваемом монитором ресурсов NAS она просто не видна.
                  Почему система выбрала такой масштаб — не знаю.
                  Попробую еще раз нагрузить устройство и посмотреть на этот график.

                  IOPS — это тоже данные с монитора ресурсов NAS.
                    0
                    Я так понимаю это была серия тестов. И IOPs 6000 это один тест, а 500 МБ/sec это другой тест, не так ли?
                    Если вы имеете на 6ти R5 SATA дисках 6000 IOPS, то у вас должно быть высокое латенси.

                    Интересует какое значение IOPs, латенси [ms], соотношение чтение/запись [%], скорость чтения/записи [MByte/sec] наблюдается в один момент времени для одного теста.

                    Может у вас есть такие данные? Если нет, если не сложно, делая новый тест, запишите их пожалуйста.
                      0
                      Я перепубликовал screenshot с iOPS/latency.
                      Шла операция записи на NAS больших несжимаемых файлов.
                      IOPS в районе 5-6 тысяч, latency — 120-140msec. Скорость записи была 400-450 мегабайт в секунду.
                      Вопрос — чем мне в данном случае может быть интересна latency? То есть я понимаю, что это время выполнения одной операции. Но мне оно в моем случае чем поможет, если бы было не 130, а скажем 50?
                        0
                        Спасибо.
                        В случае последовательных операций с большими файлами вам не будет интерестна латенси, вместо этого более интерестно рассматривать в данном случае MB/s.
                        IOPs'ы обычно являются мерой операций случайного чтения/записи на нагрузках мелкими блоками ( Базы Данных, VDI, почтовые сервисы и т.д.), для таких задач латенси выше 20мс считается не приемлемо высоким значением.

                        Другими словами, в случае вашей нагрузки, латенси 120-140msec 6000IOPs это совсем не много.
            0
            С оборудованием этой компании я работаю уже немало лет, и опыт пока имею только положительный.


            А вы везунчик.
            Qnap это конечно лучше чем совсем китайские бренды, но по моему опыту под нагрузкой или мрут как мухи или просто не могут обеспечить стабильной производительности.
              0
              А какие NAS вы порекомендуете? Желательно, без увеличения цены на порядок.
                +1
                Я занимаюсь восстановлением систем после сбоев т.е. когда всё работает ко мне не обращаются и поэтому не обладаю положительной статистикой. К сожалению.
                QNAP один из самых дешевых вендоров, который может быть использован в интерпрайз решениях, тут спору нет. Но поскольку это название я слышу намного чаще остальных, выводы начинают напрашиваться сами.
                  +2
                  Возможно, вы делаете ошибку восприятия, аналогичную «ошибке выживших».

                  В моем кратком переложении:

                  Во время второй мировой войны авиаконструкторы гадали, как распределить по корпусу самолета броню, количество которой ограничено грузоподъемностью самолета. И они решили посмотреть, куда чаще всего попадают вражеские пули. Осмотрели самолеты, вернувшиеся с боя, и решили усилить крылья (видимо, защитив таким образом бензобаки).

                  Вот только это не помогло бы. У самолета были гораздо более уязвимые места, и когда пули попадали в них, эти самолеты просто не возвращались. И наоборот, места, где конструкторы обнаружили пулевые отверстия, были некритичны, ведь самолеты с повреждениями в этих местах благополучно вернулись.

                  Соответственно, логичнее было обшивать места, где пулевые отверстия обнаружены не были. Подробнее об ошибке восприятия можете почитать тут: youarenotsosmart.ru/2013/07/survivorship-bias/

                  В вашем случае вы наблюдаете наибольшее количество поломок у QNAP, и делаете вывод, что QNAP самый ненадежный бренд. Но вы сами говорите, что он самый популярный (и возможно, с большим отрывом!).

                  Предположим, вы наблюдали четыре сломанных QNAP и один сломанный HP. Значит ли это, что HP в четыре раза надежнее QNAP? Нет, вывод можно делать только после сопоставления с общим количеством устройств. И если окажется, что у QNAP сломались четыре из десяти, а у HP один из двух, то получится, что QNAP надежнее.

                  Я не утверждаю надежность QNAP, я привел абстрактный пример. Но я предполагаю, что по надежности QNAP вполне может не уступать конкурентам, в том числе более дорогим.
                    +1
                    Есть хорошая софтина для тестирования реальных скоростей работы с дисками. Называется iometr. С её помощью можно загружать дисковую систему всякими фокусами вроде random access с заданным соотношением операций чтения/записи. Это позволяет эмулировать реальную нагрузку и посмотреть как поведет себя хранилка в динамике. Синтетические тесты тут не показательны т.к. дают очень непродолжительную нагрузку.
                    Я не говорил, что qnap ломается (читай сгорает физически), я имел в виду, что во время таких тестов, для них является нормальной ситуацией или зависнуть напрочь или деградация скорости до уровня перфокарт.

                    Так то я не пытаюсь вас ни в чём убедить, просто поделился наблюдением.
                      0
                      Спасибо, я попробую погонять с iometr.
                        0
                        > Я не говорил, что qnap ломается (читай сгорает физически), я имел в виду, что во время таких тестов, для них является нормальной ситуацией или зависнуть напрочь или деградация скорости до уровня перфокарт.

                        Без сравнения с конкурентами в идентичных условиях эти наблюдения мало что значат.
                      0
                      Скажите, а с какого числа пользователей решение становится enterprise?
                      Потому что в моем случае есть 2, в крайнем случае 3 пользователя.
                        0
                        По-моему ентерпрайз решение, это когда:
                        • Есть дублирование всех физических компонент, для обесписения высокой доступности
                        • Уровень доступности обеспечивает какое-то кол-во девяток, к примеру «пять девяток»
                        • Интеграция с софтом
                        • Наличие некой парадигмы высокой доступности всей инфраструктуры (не только самой СХД) поддерживающей несколько путей к одним данным
                        • Наличие стратегии резервного копирования данных и их восстановления: Архивирование и DR, гарантирующих заданное время восстановления


                        Это мое личное восприятие.
                          0
                          Мысль понятна.
                          Применительно к конкретному проекту. Настраивается репликация в «облако». В плюс к этому планируется резервное копирование на внешние диски.
                          Для простоты забудем про внешние диски. Есть только «облако».
                          Представим, что устройство у нас сгорело. Совсем.
                          Идем и покупаем другое устройство. Настраиваем его (пара часов потребуется). Подключаем к интернет каналу (100мегабит в Москве — это не проблема).
                          Еще через пару часов получаем локальную копию последней съемки. Все терабайты старых съемок могут еще долго реплицироваться, они нам сейчас не важны. Главное, что они где-то есть.
                          То есть за пол дня мы восстановились до рабочего состояния, ничего не потеряли.
                          Если предположить, что нас устраивает время восстановления один день, является ли это подходящим решением для нашего enterprise?
                            0
                            Конечно да! :)

                            Главное чтобы вы знали плюсы, минусы, были с ними согласны и довольны.
                    0
                    Ну я же не зря написал «пока имею только положительный».
                    А если серьезно, то за последние года 4 ни одного аппаратного сбоя не испытал.
                    Были программные моменты.
                    Как раз на этой неделе пришлось переустановить Surveillance Station — стала в логи ошибки сыпать.
                    Но переустановил — и все, дальше работает нормально. Даже конфигурацию по камерам не потеряла.

                    А может мне и правда везет?
                    +2
                    RAID5 хоть и защищает от одиночного сбоя диска, не переживет выхода из строя второго диска, пока первый синхронизируется после замены сбойнувшего.

                    Хорошо, когда Вы и заказчик осознаёте, что RAID ≠ backup. Небольшая ремарка: RAID — это не просто защита от полного выхода диска из строя, это защита целостности данных. Смерть RAID-5 для дисков большого объема провозгласили уже давно. Для WD Red показатель UER (уровень невосстановимых ошибок чтения) составляет 1x10-14. После потери одного диска в RAID-5 в 8x3ТБ массиве вы практически неизбежно прочитаете не то, что записали.
                    Ничего против Qnap, Synology и прочих настольных хранилок с софтовым RAID под Linux и веб-мордой не имею — отлично подходят для SMB, всё работает из коробки, но в некоторых случаях не хватает расширяемости и производительности. Тогда рассматриваем для бюджетных вариантов недорогой сервер на обычном железе плюс Windows Storage Server 2012 R2 или Open-E.
                    P.S. Использование для серьёзного тестирования ATTO benchmark, HDTune и подобного софта, IMHO, является моветоном. Освойте IOmeter и/или FIO. О последнем есть хороший пост на Хабре: habrahabr.ru/post/154235/
                      0
                      Я сложно отношусь к синтетическим тестам.
                      Мне больше интересно, как ведет себя оборудование в реальной работе.
                      Про Atto — понятно. что это «измерение в попугаях», просто у меня накоплена информация по разным устройствам от QNAP именно на этом тесте.
                      Про IOmeter мне уже написали в одном из предыдущих комментариев, обязательно попробую.
                      Про FIO не знал ничего, спасибо.
                        0
                        Я как раз публиковал статьи по IOMeter, может пригодиться.
                          +1
                          Спасибо, обязательно попробую этот тест.
                      0
                      Raid 5 — точно не подходит. Я бы выбрал самосбор на freenas. 6000 IOPS — это круто.
                      0
                      А по какому протоколу оно работает с несколькими компами сразу? FTP? SMB?
                      0
                      6к iops на 6 red дисках в рейд 5? Серьезно? На кэше можно и 60к намерить. 6 х 2 tb wd red в рейде 10 у меня выдают около 500 iops при латенси 40 мс. Для теста лучше отдать масив по iscsi и провести тест fio с линукс хоста не забывая контролировать латенси.
                        0
                        А смысл в тестировании iSCSI?
                        Интересно было не тестирование «сферического коня в вакууме», а реальной системы, с реальными клиентскими машинами.
                        Мне систему надо заказчику сдавать.
                        Там будут клиенты под Mac OSX и, возможно, Windows.
                        Там IOPS мало кого заинтересует. Линейная скорость чтения-записи важнее.
                          0
                          Потому что:
                          а) Нормально тестировать iops'ы можно только на блочном устройстве.
                          б) Тесты на блочном устройстве дадут представление о производительности массива сверху. Можно будет понять какоя его максимальная производительность.
                            0
                            Здорово.
                            А чем значение «производительности массива сверху» поможет настроить эту систему для заказчика?
                            Я правда хочу понять алгоритм, которым вы предлагаете пользоваться.
                            Еще раз — интересна не производительность вообще, а производительность для конкретного способа работы с сетевым накопителем.
                              +1
                              Будет понятно верно ли вы настроили или тестируете NAS. Например получив на блочном тесте 500 Мб/с на чтение/запись, а самбе 550 будет понятно, что тест проведен не корректно и мешает кеширование. Получив 300 Мб/с будет ясно, что требуется дальше крутить настройки самбы. Как-то так.
                                0
                                А можно ли уточнить, что значит «крутить настройки самбы»?
                                Я из настроек на NAS вижу только выбор максимальной версии SMB от 1.0 до 2.1
                                Или имелось в виду что-то другое?
                                  0
                                  Если в данном насе нет тонких настроек самбы, то крутить конечно нечего. Мой комментарий был о общей методологии тестирования и настройке.
                        +1
                        Вас не затруднит дополнить статью ещё некоторыми подробностями?
                        Например, какой коммутатор использовался при тестах, версия ОС на тестовой станции и кратко о железе тестовой станции.
                        Просто для полноты картины, вдруг кто-то захочет протестировать другие NASы в сходной конфигурации=)

                        И лично у меня такой интерес: как происходит бэкап в облако? Это встроенные средства устройства или с перекачкой данных через сервер?
                          0
                          Коммутатор был Cisco SG500X. Но было и прямое подключение NAS — WS. Результат не менялся.
                          На тестах использовались OSX Mavericks, Windows 7, Windows Server 2008. Все, которые нашлись вокруг.
                          Windows Server был с аппаратным RAID, который на тестах в районе гигабайта в секунду что на чтение, что на запись дает. Если не ошибаюсь, Adaptec 7805.
                          Под OSX работал Macbook Pro конца 2013г. Его SSD диск по BlackMagic Disk дает в районе 700-750 мегебайт в секунду.
                          Под Windows 7 была рабочая станция с SSD и 32GB RAM, в которой RAMDisk делался.
                          Только все это не очень важно — нет разницы, с какой системы тесты шли. Результаты очень похожие. Судя по всему, NAS в любом случае был самым медленным звеном. Если только скорость 400-450 мегабайт в секунду можно назвать медленной :-)

                          Что касается CrashPlan, то на NAS ставится стандартный компонент для нужного вам «облачного» сервиса, туда вводятся данные по доступу к сервису, и помечаются те разделы, которые надо копировать.
                          asakharov.livejournal.com/34386.html

                        Only users with full accounts can post comments. Log in, please.