Comments 39
Чего тут еще понимать! Дергай за ручки да верти руль. Покупаешь 10G сетевуху, втыкаешь ее в USB-порт NAS'а… 
А на каких дисках вы получили 6000 IOPS? Ну, и «сколько раз твердили миру» — не используйте RAID5, это опасно на больших емкостях.
WD Red 3TB
Тут ещё стоило бы уточнить протокол (CIFS/NFS), задержки, соотношение чтение/запись, средний размер оперируемого блока и рандумность. Хотя рандомность полагаю = 0%, т.е. в принципе нет — все данные это фотографии большего размера.
Сами по себе иопсы — попугаи без удава.
alsakharov
Сами по себе иопсы — попугаи без удава.
alsakharov
Доступ был по SMB.
В тестах использовались RAW файлы размером от 20 до 50 мегабайт и файлы с видео по несколько гигибайт.
Я вполне допускаю, что IOPS тут далек от реальности. Но в реальности этот параметр не сильно и нужен. Скорость считывания-записи — вот что актуально.
В тестах использовались RAW файлы размером от 20 до 50 мегабайт и файлы с видео по несколько гигибайт.
Я вполне допускаю, что IOPS тут далек от реальности. Но в реальности этот параметр не сильно и нужен. Скорость считывания-записи — вот что актуально.
У вас на картинке не видно латенси. Подскажите какое оно было?
И IOPS это на фронтенде ведь?
И IOPS это на фронтенде ведь?
Вот ссылка на оригинал картинки
www.flickr.com/photos/21927555@N03/15795017550/in/set-72157647345967434
Но на графике, выдаваемом монитором ресурсов NAS она просто не видна.
Почему система выбрала такой масштаб — не знаю.
Попробую еще раз нагрузить устройство и посмотреть на этот график.
IOPS — это тоже данные с монитора ресурсов NAS.
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] наблюдается в один момент времени для одного теста.
Может у вас есть такие данные? Если нет, если не сложно, делая новый тест, запишите их пожалуйста.
Если вы имеете на 6ти R5 SATA дисках 6000 IOPS, то у вас должно быть высокое латенси.
Интересует какое значение IOPs, латенси [ms], соотношение чтение/запись [%], скорость чтения/записи [MByte/sec] наблюдается в один момент времени для одного теста.
Может у вас есть такие данные? Если нет, если не сложно, делая новый тест, запишите их пожалуйста.
Я перепубликовал screenshot с iOPS/latency.
Шла операция записи на NAS больших несжимаемых файлов.
IOPS в районе 5-6 тысяч, latency — 120-140msec. Скорость записи была 400-450 мегабайт в секунду.
Вопрос — чем мне в данном случае может быть интересна latency? То есть я понимаю, что это время выполнения одной операции. Но мне оно в моем случае чем поможет, если бы было не 130, а скажем 50?
Шла операция записи на NAS больших несжимаемых файлов.
IOPS в районе 5-6 тысяч, latency — 120-140msec. Скорость записи была 400-450 мегабайт в секунду.
Вопрос — чем мне в данном случае может быть интересна latency? То есть я понимаю, что это время выполнения одной операции. Но мне оно в моем случае чем поможет, если бы было не 130, а скажем 50?
Спасибо.
В случае последовательных операций с большими файлами вам не будет интерестна латенси, вместо этого более интерестно рассматривать в данном случае MB/s.
IOPs'ы обычно являются мерой операций случайного чтения/записи на нагрузках мелкими блоками ( Базы Данных, VDI, почтовые сервисы и т.д.), для таких задач латенси выше 20мс считается не приемлемо высоким значением.
Другими словами, в случае вашей нагрузки, латенси 120-140msec 6000IOPs это совсем не много.
В случае последовательных операций с большими файлами вам не будет интерестна латенси, вместо этого более интерестно рассматривать в данном случае MB/s.
IOPs'ы обычно являются мерой операций случайного чтения/записи на нагрузках мелкими блоками ( Базы Данных, VDI, почтовые сервисы и т.д.), для таких задач латенси выше 20мс считается не приемлемо высоким значением.
Другими словами, в случае вашей нагрузки, латенси 120-140msec 6000IOPs это совсем не много.
С оборудованием этой компании я работаю уже немало лет, и опыт пока имею только положительный.
А вы везунчик.
Qnap это конечно лучше чем совсем китайские бренды, но по моему опыту под нагрузкой или мрут как мухи или просто не могут обеспечить стабильной производительности.
А какие NAS вы порекомендуете? Желательно, без увеличения цены на порядок.
Я занимаюсь восстановлением систем после сбоев т.е. когда всё работает ко мне не обращаются и поэтому не обладаю положительной статистикой. К сожалению.
QNAP один из самых дешевых вендоров, который может быть использован в интерпрайз решениях, тут спору нет. Но поскольку это название я слышу намного чаще остальных, выводы начинают напрашиваться сами.
QNAP один из самых дешевых вендоров, который может быть использован в интерпрайз решениях, тут спору нет. Но поскольку это название я слышу намного чаще остальных, выводы начинают напрашиваться сами.
Возможно, вы делаете ошибку восприятия, аналогичную «ошибке выживших».
В моем кратком переложении:
В вашем случае вы наблюдаете наибольшее количество поломок у QNAP, и делаете вывод, что QNAP самый ненадежный бренд. Но вы сами говорите, что он самый популярный (и возможно, с большим отрывом!).
Предположим, вы наблюдали четыре сломанных QNAP и один сломанный HP. Значит ли это, что HP в четыре раза надежнее QNAP? Нет, вывод можно делать только после сопоставления с общим количеством устройств. И если окажется, что у QNAP сломались четыре из десяти, а у HP один из двух, то получится, что QNAP надежнее.
Я не утверждаю надежность QNAP, я привел абстрактный пример. Но я предполагаю, что по надежности QNAP вполне может не уступать конкурентам, в том числе более дорогим.
В моем кратком переложении:
Во время второй мировой войны авиаконструкторы гадали, как распределить по корпусу самолета броню, количество которой ограничено грузоподъемностью самолета. И они решили посмотреть, куда чаще всего попадают вражеские пули. Осмотрели самолеты, вернувшиеся с боя, и решили усилить крылья (видимо, защитив таким образом бензобаки).
Вот только это не помогло бы. У самолета были гораздо более уязвимые места, и когда пули попадали в них, эти самолеты просто не возвращались. И наоборот, места, где конструкторы обнаружили пулевые отверстия, были некритичны, ведь самолеты с повреждениями в этих местах благополучно вернулись.
Соответственно, логичнее было обшивать места, где пулевые отверстия обнаружены не были. Подробнее об ошибке восприятия можете почитать тут: youarenotsosmart.ru/2013/07/survivorship-bias/
В вашем случае вы наблюдаете наибольшее количество поломок у QNAP, и делаете вывод, что QNAP самый ненадежный бренд. Но вы сами говорите, что он самый популярный (и возможно, с большим отрывом!).
Предположим, вы наблюдали четыре сломанных QNAP и один сломанный HP. Значит ли это, что HP в четыре раза надежнее QNAP? Нет, вывод можно делать только после сопоставления с общим количеством устройств. И если окажется, что у QNAP сломались четыре из десяти, а у HP один из двух, то получится, что QNAP надежнее.
Я не утверждаю надежность QNAP, я привел абстрактный пример. Но я предполагаю, что по надежности QNAP вполне может не уступать конкурентам, в том числе более дорогим.
Есть хорошая софтина для тестирования реальных скоростей работы с дисками. Называется iometr. С её помощью можно загружать дисковую систему всякими фокусами вроде random access с заданным соотношением операций чтения/записи. Это позволяет эмулировать реальную нагрузку и посмотреть как поведет себя хранилка в динамике. Синтетические тесты тут не показательны т.к. дают очень непродолжительную нагрузку.
Я не говорил, что qnap ломается (читай сгорает физически), я имел в виду, что во время таких тестов, для них является нормальной ситуацией или зависнуть напрочь или деградация скорости до уровня перфокарт.
Так то я не пытаюсь вас ни в чём убедить, просто поделился наблюдением.
Я не говорил, что qnap ломается (читай сгорает физически), я имел в виду, что во время таких тестов, для них является нормальной ситуацией или зависнуть напрочь или деградация скорости до уровня перфокарт.
Так то я не пытаюсь вас ни в чём убедить, просто поделился наблюдением.
Спасибо, я попробую погонять с iometr.
> Я не говорил, что qnap ломается (читай сгорает физически), я имел в виду, что во время таких тестов, для них является нормальной ситуацией или зависнуть напрочь или деградация скорости до уровня перфокарт.
Без сравнения с конкурентами в идентичных условиях эти наблюдения мало что значат.
Без сравнения с конкурентами в идентичных условиях эти наблюдения мало что значат.
Скажите, а с какого числа пользователей решение становится enterprise?
Потому что в моем случае есть 2, в крайнем случае 3 пользователя.
Потому что в моем случае есть 2, в крайнем случае 3 пользователя.
По-моему ентерпрайз решение, это когда:
Это мое личное восприятие.
- Есть дублирование всех физических компонент, для обесписения высокой доступности
- Уровень доступности обеспечивает какое-то кол-во девяток, к примеру «пять девяток»
- Интеграция с софтом
- Наличие некой парадигмы высокой доступности всей инфраструктуры (не только самой СХД) поддерживающей несколько путей к одним данным
- Наличие стратегии резервного копирования данных и их восстановления: Архивирование и DR, гарантирующих заданное время восстановления
Это мое личное восприятие.
Мысль понятна.
Применительно к конкретному проекту. Настраивается репликация в «облако». В плюс к этому планируется резервное копирование на внешние диски.
Для простоты забудем про внешние диски. Есть только «облако».
Представим, что устройство у нас сгорело. Совсем.
Идем и покупаем другое устройство. Настраиваем его (пара часов потребуется). Подключаем к интернет каналу (100мегабит в Москве — это не проблема).
Еще через пару часов получаем локальную копию последней съемки. Все терабайты старых съемок могут еще долго реплицироваться, они нам сейчас не важны. Главное, что они где-то есть.
То есть за пол дня мы восстановились до рабочего состояния, ничего не потеряли.
Если предположить, что нас устраивает время восстановления один день, является ли это подходящим решением для нашего enterprise?
Применительно к конкретному проекту. Настраивается репликация в «облако». В плюс к этому планируется резервное копирование на внешние диски.
Для простоты забудем про внешние диски. Есть только «облако».
Представим, что устройство у нас сгорело. Совсем.
Идем и покупаем другое устройство. Настраиваем его (пара часов потребуется). Подключаем к интернет каналу (100мегабит в Москве — это не проблема).
Еще через пару часов получаем локальную копию последней съемки. Все терабайты старых съемок могут еще долго реплицироваться, они нам сейчас не важны. Главное, что они где-то есть.
То есть за пол дня мы восстановились до рабочего состояния, ничего не потеряли.
Если предположить, что нас устраивает время восстановления один день, является ли это подходящим решением для нашего enterprise?
Ну я же не зря написал «пока имею только положительный».
А если серьезно, то за последние года 4 ни одного аппаратного сбоя не испытал.
Были программные моменты.
Как раз на этой неделе пришлось переустановить Surveillance Station — стала в логи ошибки сыпать.
Но переустановил — и все, дальше работает нормально. Даже конфигурацию по камерам не потеряла.
А может мне и правда везет?
А если серьезно, то за последние года 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 не знал ничего, спасибо.
Мне больше интересно, как ведет себя оборудование в реальной работе.
Про Atto — понятно. что это «измерение в попугаях», просто у меня накоплена информация по разным устройствам от QNAP именно на этом тесте.
Про IOmeter мне уже написали в одном из предыдущих комментариев, обязательно попробую.
Про FIO не знал ничего, спасибо.
Я как раз публиковал статьи по IOMeter, может пригодиться.
Raid 5 — точно не подходит. Я бы выбрал самосбор на freenas. 6000 IOPS — это круто.
Было бы много для такого маленького девайса, если бы там латенси была не выше 20 мс.
6к iops на 6 red дисках в рейд 5? Серьезно? На кэше можно и 60к намерить. 6 х 2 tb wd red в рейде 10 у меня выдают около 500 iops при латенси 40 мс. Для теста лучше отдать масив по iscsi и провести тест fio с линукс хоста не забывая контролировать латенси.
А смысл в тестировании iSCSI?
Интересно было не тестирование «сферического коня в вакууме», а реальной системы, с реальными клиентскими машинами.
Мне систему надо заказчику сдавать.
Там будут клиенты под Mac OSX и, возможно, Windows.
Там IOPS мало кого заинтересует. Линейная скорость чтения-записи важнее.
Интересно было не тестирование «сферического коня в вакууме», а реальной системы, с реальными клиентскими машинами.
Мне систему надо заказчику сдавать.
Там будут клиенты под Mac OSX и, возможно, Windows.
Там IOPS мало кого заинтересует. Линейная скорость чтения-записи важнее.
Потому что:
а) Нормально тестировать iops'ы можно только на блочном устройстве.
б) Тесты на блочном устройстве дадут представление о производительности массива сверху. Можно будет понять какоя его максимальная производительность.
а) Нормально тестировать iops'ы можно только на блочном устройстве.
б) Тесты на блочном устройстве дадут представление о производительности массива сверху. Можно будет понять какоя его максимальная производительность.
Здорово.
А чем значение «производительности массива сверху» поможет настроить эту систему для заказчика?
Я правда хочу понять алгоритм, которым вы предлагаете пользоваться.
Еще раз — интересна не производительность вообще, а производительность для конкретного способа работы с сетевым накопителем.
А чем значение «производительности массива сверху» поможет настроить эту систему для заказчика?
Я правда хочу понять алгоритм, которым вы предлагаете пользоваться.
Еще раз — интересна не производительность вообще, а производительность для конкретного способа работы с сетевым накопителем.
Будет понятно верно ли вы настроили или тестируете NAS. Например получив на блочном тесте 500 Мб/с на чтение/запись, а самбе 550 будет понятно, что тест проведен не корректно и мешает кеширование. Получив 300 Мб/с будет ясно, что требуется дальше крутить настройки самбы. Как-то так.
Вас не затруднит дополнить статью ещё некоторыми подробностями?
Например, какой коммутатор использовался при тестах, версия ОС на тестовой станции и кратко о железе тестовой станции.
Просто для полноты картины, вдруг кто-то захочет протестировать другие NASы в сходной конфигурации=)
И лично у меня такой интерес: как происходит бэкап в облако? Это встроенные средства устройства или с перекачкой данных через сервер?
Например, какой коммутатор использовался при тестах, версия ОС на тестовой станции и кратко о железе тестовой станции.
Просто для полноты картины, вдруг кто-то захочет протестировать другие 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
На тестах использовались 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
Sign up to leave a comment.
Система хранения медиа данных с 10G доступом