Как стать автором
Обновить

Комментарии 39

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

А может мне и правда везет?
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/
Я сложно отношусь к синтетическим тестам.
Мне больше интересно, как ведет себя оборудование в реальной работе.
Про Atto — понятно. что это «измерение в попугаях», просто у меня накоплена информация по разным устройствам от QNAP именно на этом тесте.
Про IOmeter мне уже написали в одном из предыдущих комментариев, обязательно попробую.
Про FIO не знал ничего, спасибо.
Я как раз публиковал статьи по IOMeter, может пригодиться.
Спасибо, обязательно попробую этот тест.
Raid 5 — точно не подходит. Я бы выбрал самосбор на freenas. 6000 IOPS — это круто.
НЛО прилетело и опубликовало эту надпись здесь
SMB
6к iops на 6 red дисках в рейд 5? Серьезно? На кэше можно и 60к намерить. 6 х 2 tb wd red в рейде 10 у меня выдают около 500 iops при латенси 40 мс. Для теста лучше отдать масив по iscsi и провести тест fio с линукс хоста не забывая контролировать латенси.
А смысл в тестировании iSCSI?
Интересно было не тестирование «сферического коня в вакууме», а реальной системы, с реальными клиентскими машинами.
Мне систему надо заказчику сдавать.
Там будут клиенты под Mac OSX и, возможно, Windows.
Там IOPS мало кого заинтересует. Линейная скорость чтения-записи важнее.
Потому что:
а) Нормально тестировать iops'ы можно только на блочном устройстве.
б) Тесты на блочном устройстве дадут представление о производительности массива сверху. Можно будет понять какоя его максимальная производительность.
Здорово.
А чем значение «производительности массива сверху» поможет настроить эту систему для заказчика?
Я правда хочу понять алгоритм, которым вы предлагаете пользоваться.
Еще раз — интересна не производительность вообще, а производительность для конкретного способа работы с сетевым накопителем.
Будет понятно верно ли вы настроили или тестируете NAS. Например получив на блочном тесте 500 Мб/с на чтение/запись, а самбе 550 будет понятно, что тест проведен не корректно и мешает кеширование. Получив 300 Мб/с будет ясно, что требуется дальше крутить настройки самбы. Как-то так.
А можно ли уточнить, что значит «крутить настройки самбы»?
Я из настроек на NAS вижу только выбор максимальной версии SMB от 1.0 до 2.1
Или имелось в виду что-то другое?
Если в данном насе нет тонких настроек самбы, то крутить конечно нечего. Мой комментарий был о общей методологии тестирования и настройке.
Вас не затруднит дополнить статью ещё некоторыми подробностями?
Например, какой коммутатор использовался при тестах, версия ОС на тестовой станции и кратко о железе тестовой станции.
Просто для полноты картины, вдруг кто-то захочет протестировать другие NASы в сходной конфигурации=)

И лично у меня такой интерес: как происходит бэкап в облако? Это встроенные средства устройства или с перекачкой данных через сервер?
Коммутатор был 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
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории