“Терабайты” – мегапиксели сегодня

Уже можно считать что прошли времена, когда на рынке фототехники правили бал ”мегапиксели”. Сегодня совсем немногие люди, покупающие фотоаппарат, покупают “мегапиксели”, также как, чуть раньше, производители процессоров перестали продавать им “гигагерцы”. Все больше людей стали осознавать, что этот единственный параметр не является ни определяющим, ни исчерпывающим для того, чтобы выбрать лучший продукт, да и вообще сделать выбор. Но по прежнему я сталкиваюсь с тем, что покупающий систему хранения, покупает “терабайты”. Или, по крайней мере, считает, что хочет их купить.

Что на самом деле хочет купить пользователь, пришедший за системой хранения?

  • Производительность в random IOPS. Это, пожалуй, определяющий фактор, который по праву занимает первое место в списке. Производительность – решает. В наше время трехтерабайтных дисков на рынке, емкость, как я уже и писал, зачастую, получается как “побочный эффект” достижения определенного уровня производительности в IOPS. Сперва надо удовлетворить требованию по производительности в random IOPS, читай по количеству физических дисков в системе, а там, глядишь, емкость и так получилась порядочная. Опять же, системы хранения, где емкость является определяющим фактором, когда производительность не важна совсем, это довольно узкая ниша архивных хранилищ. Уверен ли спрашивающий про “терабайты”, что ему совсем не нужна производительность в random IOPS на получившемся? Не дал ли он себя заморочить величинами “паспортной” производительности интерфейса SATA-II или Fibre Channel? Что это за задача, где производительность работы на получившемся сторадже не нужна?
  • “Фичи”, возможности использования системы хранения. Современные системы хранения уже давно не просто “банки с байтами”. “Хранение” в них всего лишь одна из множества возможностей. Даже сама пресловутая емкость хранилища может сильно зависеть от того, какие возможности системы хранения пользователем задействуются. Дедупликация, снэпшоты, клоны, unified-концепция хранения, thin provisioning, storage tiering, очень часто эти функциональные возможности, позволяет значительно снизить так называемый data footprint, то есть занимаемый данными объем на хранилище. То, что без использования “фич” заняло бы куда больший объем, с “фичами” поместится в куда меньший. Что уж говорить про многие новые возможности использования хранилища, которые эти фичи дают, и о которых пользователь, покупающий “объем” часто еще просто не задумывался?
  • Надежность хранения данных и их защиту. Что толку от производительной и фичастой системы хранения, если она при этом ненадежна, если жить с ней вы будете как на пороховой бочке? RAID-0 это, наверное, очень быстро. Но недолго :) “Жить быстро, умереть молодым” это для рокенрола хорошо. Но вряд ли это хорошо для данных вашей компании. А сегодня уже и RAID-5, судя по всему, уже стоит рассматривать в ряду ненадежных (в отличие от RAID-0, который ненадежный, но, хотя бы, быстрый, RAID-5 при этом еще и не быстрый;). Диски SATA, особенно большого размера, уже просто в обязательном порядке должны предполагать использование их в RAID-6. И не забывайте – надежность IT инфраструктуры компании, как и скорость эскадры, которая определяется скоростью самого медленного корабля, определяется надежностью наименее надежного ее компонента. Или как говорил один мой знакомый: “Неважно, насколько быстра ваша система хранения, если в данный момент она не работает”. Но надежность и защита данных это не только RAID, часто она не исчерпывается локальными возможностями стораджа. Это может быть и репликация, это и средства резервного копирования и восстановления данных, например снэпшоты уровня стораджа или приложения, и так далее. А как насчет гарантийного сервиса в вашем регионе и его стоимости?
  • Интеграцию с используемым софтом. Несмотря на то, что “настоящий сисадмин пользуется исключительно консолью” на практике все гораздо сложнее. И выбор между тремя ничего не успевающими сисадминами, ежемесячно еще и требующими за свою напряженную работу прибавки зарплаты, и одним, который все успевает, пользуясь удобными инструментами, предоставляемыми вендором системы хранения, может также заметно повлиять на итоговую стоимость решения. Интеграция это не просто красивые маркетинговые слова. Поддержка специфических возможностей программного решения, в качестве примера могу привести поддержку VAAI для продуктов VMware, или “аппаратную” поддержку deploy/redeploy виртуальных машин на уровне возможностей стораджа, может напрямую отразиться и на производительности, и, в конечном счете, на цене решения.
  • Поддержку и совместимость с используемыми софтовыми решениями. Важный аспект – наличие поддержки использования покупаемой системы хранения со стороны производителя программного решения, присутствия в Hardware Compatibility Lists (HCL), Support Matrix, существования описанных Best Practices применения, и так далее. В противном случае вы рискуете остаться со своими проблемами один на один, и пользоваться “помощью” только различных форумов. Наличие подтвержденной поддержки как со стороны разработчика софта данной модели стораджа, так и со стороны производителя стораджа – данного софта, обычно гарантирует минимальные проблемы на этапе внедрения. Также не забывайте, что supported (поддерживаемое) это не то же самое, что functional (работающее).
  • Экономические аспекты. Долгосрочные затраты на эксплуатацию, поддержку, администрирование. Несмотря на то, что TCO (Total Cost of Ownership – “совокупная стоимость владения”) в России традиционно игнорируется, все больше пользователей начинает осмыслять тот факт, что заплатить за покупку – это еще не все затраты на систему хранения. Часто это только самое начало трат. Стораджем надо не только “завладеть”, но и “содержать” его. И, часто, стоимость содержания (куда входят эксплуатационные расходы, сервис и прочее)бывает для пользователя очень неприятным сюрпризом. Это вам подтвердит любой владелец, например, дорогого и редкого (в вашей местности) автомобиля. Не забывайте также, что в сегодняшних датацентрах примерно половина потребляемого ими электричества, это потребление не связанное напрямую с IT-оборудованием. Это потребление кондиционеров и прочих “инфраструктурных элементов”. Половина! Снижение затрат на электропитание, охлаждение, затрат на инсталляцию, сервис, эксплуатационное обслуживание и warranty, отличающихся у разных вендоров и разных моделей, может отлиться во вполне полновесные доллары экономии.

Покупать систему хранения исходя из единственного аспекта – ее емкости, сегодня также нелепо, как покупать автомобиль в автосалоне, исходя из его максимальной скорости. “Мне нужен автомобиль, который может ехать со скоростью 140 километров в час” говорит покупатель в салоне. Даже если оставить в стороне то, что сегодня любой новый автомобиль может ехать со скоростью 140 километров в час, очевидно, что это не является для покупателя основным критерием покупки (даже если он сам, по непониманию темы, пока еще и не догадывается об этом). И, разумеется, грамотный пресейл сегодня знает, что когда покупатель говорит, что хочет “сторадж на двадцать терабайт”, на самом деле он хотел сказать совсем не это. Он хотел сказать, что:

“Мы хотим развернуть виртуальную серверную инфраструктуру, ориентировочно на 20 серверов. Задачи переносимых в виртуальную инфраструктуру серверов сегодня это два файловых сервера, почта MS Exchange 2010, сервера баз данных MS SQL Server 2005 для бизнес-задач и девелоперский PostgreSQL, контроллер домена и около десятка разнообразных серверов для веб-разработчиков и тестировщиков. Ожидаемая нагрузка на хранилище по вводу-выводу, на этапе запуска, для текущих наших задач, около 7-15 тысяч IOPS в steady random read/write, при оценочном профиле read/write – 75%/25%. Мы ожидаем, в ближайшие год-два, минимум двукратный рост нагрузки по вводу-выводу и примерно 50-75% рост по емкости. Мы планируем использовать гипервизор VMware vSphere, и, возможно Xen Desktop или VMware View для планируемого VDI на 300 рабочих мест. В следующем году мы хотим также развернуть резервный датацентр, куда будем реплицировать данные с основного датацентра, для обеспечения отказоустойчивости и непрерывности бизнеса. Достаточные требования по RPO/RTO для наших бизнес-задач 4 часа RPO и 30 минут RTO.”

Но, против воли, у него вырвалось про “20 терабайт”. :)

 

PS. Вы должно быть заметили, что ни разу в этом посте я не сказал слово “NetApp”? :)

15 комментариев

  1. Umlyaut:

    >PS. Вы должно быть заметили, что ни разу в этом посте я не сказал слово “NetApp”? :)

    Увы, сказали. В постскриптуме поста… :P

  2. panvartan:

    При всем уважении, а почему вы все одиозные характеристики систем хранения сравниваете со скоростью легкового автомобиля. Почему емкость(тб) сравнивается со скоростью и почему именно легкового? Это попахивает приемчиками продавцов цептера домохозяйкам. СХД это профессиональная (помогающая в профессии) техника, и если подбирать аналогии, то netapp это скорее трактор с двигателем 40 лс (поверьте, это не смешно - это вполне достаточная мошность - привет селерону в 2020), скоростью 50 км/ч (mb/s), и главное - кучей разнообразного навесного оборудования, нацепленного со всех сторон - его может быть очень много, соизмеримо количеству програмных опций netappа. И если вам надо построить животноводческую (серверную) ферму, то можно купить трактор (netapp) с умелым водителем(сертифицированным адмиинстратором), а можно купить bmw x5 (bmw x5) и нанять толпу “узбеков” (студентов).

  3. panvartan:

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

    PS. Вы должно быть заметили, что ни разу в этом посте я не сказал слово “NetApp”?

    поскольку как раз вы, по-видимому этого как раз и не заметили.

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

    В третьих, хочу особо отметить в вашем комментарии, что вы все же не поняли о чем я веду разговор. Такой неутешительный вывод я привожу из вашего упоминания “селерона”.
    Вы по прежнему типом процессора меряете работу стораджа, а мегапикселями - качество камеры. Это неверно. Возвращаемся к началу разговора.

  4. panvartan:

    Правда ваша - не заметил, наверное смотрел выше и прочел “about NetApp”. А по поводу тракторов - жаль что вы не уловили качество предложенной аналогии, помогло бы в общении с “инженерными умами”.

  5. panvartan:

    Ну так и вы не уловили основную мысль поста, что никакой _один_ произвольно выбранный пользователем параметр не может исчерпывающе характеризовать сложную систему, будь то фотоаппарат, автомобиль, микропроцессор или система хранения.

  6. sl0n:

    > для текущих наших задач, около 7-15 тысяч IOPS в steady random read/write

    Мне вот этот момент очень интересен, каким образом я могу изменирить предполагаемую “нагрузку”?

  7. sl0n:

    Ну, прежде всего это зависит от того, что у вас за OS. В разных OS есть разные инструменты. Например в Windows можно воспользоваться стандартным perfmon, с достаточной степенью точности он дает представление и цифры. Я как-то об этом даже писал.
    http://blog.aboutnetapp.ru/archives/13

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

  8. sl0n:

    2romx: спасибо, почитаю.

    Моя реальная задача - это спланировать как раз VDI на ~ 400 рабочих мест, на данный момент я лишь знаю что одна вирт. машина “генерит” порядка 20 IOPS. Есть какие-то best practices может быть на этот счет?

    Еще выпорос: допусим я знаю, что NFS volume - vdi, на которой лежат VDI машины находится на aggr из 14 SAS дисков. Предполагая, что 200 IOPS на диск мы получаем 2800 IOPS. В реальности я наблюдаю что vdi генерит в пиках 3400 IOPS. Вопрос: откуда беруться 3400 - 2800 = 600 IOPS еще? Я догадываюсь, что это RAM cash моего filer’a влияет, но мне хотелось быть иметь четкую формулу, по которой я могу расчитать число IOPS, которое я получу скажем на 2 полках с SAS дисками.

    PS: как подписаться на комменты?

  9. sl0n:

    > Есть какие-то best practices может быть на этот счет?
    Рекомендую вот это:
    http://media.netapp.com/documents/tr-3705.pdf

    8 глава там как раз про сайзинг.
    Я его даже перевожу, и даже где-то в следующем месяце он будет опубликован в библиотеке Netwell. Там же, в библиотеке, есть уже и про Xen Desktop, если интересно.

    Также вот имеет смысл посмотреть блог автора Best Practices
    http://communities.netapp.com/community/netapp-blogs/virtualization/blog
    И вот этот документ может дать полезную пищу подумать.
    http://media.netapp.com/documents/tr-3949.pdf

    Насчет подписаться на комменты - ну… я попробую что-нибудь придумать :)

  10. sl0n:

    2romx: большое спасибо, на данный момент то что надо! изучаю …

  11. slu_x3m:

    Подскажите какой средний показатель IOPS full random для SSD диска.
    Совсем недавно в беседе с сотрудниками компании EMC они упомянули, что в своих расчётах принимают этот показатель равный 1000 (при “пессимистичной” оценке) и 5000 (при оценке “оптимистичной”), но сдаётся мне, что они лукавят на этот счёт.

    Моя задачка: 6000 IOPS full random; 2TB места в 6 RAID (RAID-DP); бюджет 20-25 k$
    Имеет ли мне смысл рассматривать FAS 2040 или лучше сразу смотреть более “взрослые” версии?

    Спасибо огромное за ответ.

  12. slu_x3m:

    Сложно сказать однозначно, они, SSD, ведь разные бывают.
    А почему вы чувствуете недоверие к данным EMC, по вашему сколько должно быть, больше или меньше?
    Вы еще не забывайте, что на запись у SSD, по крайней мере у тех, что сейчас используются в энтерпрайз-системах, все совсем не радужно при random write, и при наличии в паттерне ввода-вывода случайной записи мелкими блоками на SSD, вы сразу сильно, в десятки раз просядете.

    C 2040 вы в 20-25 тысяч не уложитесь :(
    Хотя 2040 с дисками, допустим, SAS 300GB, возможно, будет довольно близка к вашему решению.

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

  13. slu_x3m:

    Почитал спецификацию на Intel X 25-E http://download.intel.com/design/flash/nand/extreme/319984.pdf и действительно 35kIOPS на чтение и 3,3 kIOPS на запись. Поменял своё мнение. =)

  14. bbk:

    Про RPO/RTO это конечно же хорошая идея. Но как это считать заказчику и как считать интегратору/партёру на конкретное решение/систему?

    Я нарочно поставил через чёрточку “систему”. Так как на практике конечный покупатель выбирает “решение” по СХД, но в целом для его инфраструктуры, это только часть решения. Соответственно в реальной жизни, многих деталей мы можем просто не знать, чтобы (правильно) считать RPO/RTO.

  15. bbk:

    > Соответственно в реальной жизни, многих деталей мы можем просто не знать, чтобы (правильно) считать RPO/RTO.

    А кто говорил, что будет легко? ;) Если требования RPO/RTO не знает клиент, ему должен помочь их сформулировать интегратор/партнер, в конце концов получает он свой процент разницы между партнерской ценой, и тем, что появляется в инвойсе, отправленном клиенту, совсем не за красивые глаза. Именно эти услуги и оплачивает конечный клиент этим процентом, да, я понимаю, что многие из партнеров уже это какбыэтосказать забыли про эту функцию интегратора.
    Ну пусть не обижаются, что у клиентов все шире представление о интеграторах, как о бездельниках и ненужных мироедах. Оно, зачастую, справедливо. К сожалению.

Оставить комментарий

20/0.152

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.