about NetApp

http://searchstorage.techtarget.com/news/2240203615/Photobucket-expands-environment-with-NetApps-clustered-Data-Ontap

Расположенная в Денвере веб-компания Photobucket , занимающаяся хранением пользовательских фото и видео, накопила с 2003 года около 17 петабайт данных. Это потребовало от нее, ранее в этом году, запустить новый, уже второй датацентр, который позволит увеличить объемы хранения и обеспечить высокий уровень аптайма для их 100 миллионов зарегистрированных пользователей.

Компания хранит более 13 миллиардов изображений и видеороликов, а еждневно на системы хранения компании загружается еще около 5 миллионов. Компания входит в список 200 крупнейших вебсайтов ??нтернета (по подсчетам Alexa), и является хранилищем по умолчанию для изображений для пользователей сервиса Twitter (tinypic.com - это сервис компании Photobucket) “Одной из серьезнейших проблем, с которой нам пришлось столкнуться при создании системы - это огромное количество файлов, потому что мы, кроме всего, храним по нескольку копий каждого пользовательского изображения: оригинал, копию пониженного разрешения для web, и эскиз-thumbnail” - говорит Майкл Кларк, CTO компании.

Photobucket использует системы хранения NetApp с самых ранних лет работы компании, поясняет Кларк, но решил, что переезд в новый датацентр в Финиксе будет хорошим поводом сделать переоценку решений и поискать альтернативные варианты: “Мы решили, что это время для того, чтобы заново оценить предложения рынка”, - объясняет он. “Мы просто захотели посмотреть, кто сегодня работает с NFS лучше, чем это есть у нас, а также кто позволит нам выполнять репликацию данных лучше и эффективнее с точки зрения затрат”

Датацентры в Денвере и Финиксе практически идентичны, на обоих работают системы хранения NetApp в конфигурации Clustered Data ONTAP и Data ONTAP 8, используются контроллеры NetApp FAS3210, 3240, 6040 и 6240. Системы хранения обеспечивают данными 1100 физических и 500 виртуальных серверов, организованных в соответствии с архитектурой FlexPod, и использующих гипервизор KVM.

Компания использует самописанную объектную файловую систему хранения для сервиса TinyPic.com, в которой хранится сегодня около 2 миллиардов медиа-объектов.

До покупки NetApp Clustered Data ONTAP, Photobucket тестировал системы хранения от Hitachi Data Systems и несколько коммерческих платформ объектного хранения. Но после того, как IT-отдел компании столкнулся с проблемами производительности у объектного хранилища и сравнении общих затрат на датацентр, Photobucket остановился на NetApp.

Кларк пояснил, что Photobucket не мог мигрировать данные со старых томов в новую кластерную систему, и потребовалось переобучение IT-команды компании, так как изменился интерфейс командной строки, и это усложнило внедрение.

Однако наиболее существенной выгодой от кластерной системы для компании стала возможность проводить работы по обслуживанию не останавливая работу сервисов. Кларк пояснил, что эти возможности недавно помогли команде справиться с отказом дисков в системе без остановки работы и даунтаймов. “Мы просто мигрировали данные, разделили тома на несколько других контроллеров, провели все необходимые работы, и потом вернули все на место”. “Мы смогли проделать все это не прерывая работу системы, и весьма быстро. Я был в самом деле удивлен тому, насколько это прошло легко и быстро, для системы прямо “из коробки”.”

Майкл Кларк, CTO компании, также упомянул, что инструмент репликации данных SnapMirror оказался для них очень востребованным и полезным, когда им пришлось делать резервную копию больших объемов данных. “Когда мы пробовали работу других систем хранения в ходе их тестирования, одной из проблем, с которыми мы тогда на них столкнулись было то, что ни одна из имеющихся систем репликации не работала нормально с таким гигантским числом файлов”, рассказал он.

С использованием SnapMirror, Photobucket может реплицировать свои данные как снэпшоты на несколько массивов FAS2240 и FAS3210 каждые 30 минут, и хранить их там все в течение месяца.

В дополнение к продолжающейся миграции данных на Clustered ONTAP, Photobucket также запускает в работу и свою новую инфраструктуру объектного хранилища.

Как я и обещал, прошлым постом новости про VNX не ограничатся, тем более, что EMC World дал кое-какую интересную пищу для размышлений. В новом посте Dimitris Krekoukias кратко описывает своим мысли, посетившие его после интересного анонса на EMC World экспериментального контроллера, который, возмжно, будет в будущем моделью VNX.Next.

Напоминаю, что это не мой личный авторский текст, а перевод текста в его блоге, оригинальный текст которого вы можете найти по ссылке и там же, при желании, поучаствововать в обсуждении.

Как расшифровать анонс EMC о новых VNX и заглянуть за маркетинговую завесу

http://recoverymonkey.org/2013/05/16/how-to-decipher-emcs-new-vnx-pre-announcement-and-look-behind-the-marketing

Я с интересом посмотрел некоторые объявления, сделанные в ходе EMC World. Отчасти оттого, что это новости нашего конкурента, отчасти же потому, что я нерд, которому интересно увидеть и узнать что-нибудь по настоящему технически крутое.

BTW: Хочу сказать спасибо Mark Kulacz за его помощь в отношении пруфов. Марк, хоть это и трудно признать, даже больший нерд, чем я.

??так… EMC сделал что-то новое. Демонстрация возможного VNX следующего поколения (VNX2?), недоступна на момент написания поста (на самом деле было много суеты вокруг того, что это существует пока только в виде лабораторного стенда, и т.д.).

Один из результатов, который был показан, это увеличенная производительность по сравнению с их топовой на сегодня VNX7500.

Задача данной статьи - показать, что продемонстрированное увеличение производительности не пропорционально тому, что на этот счет утверждает EMC, и что оно достигнуто не настолько за счет программного улучшения, как это утверждает EMC, и более того, это может означать, что текущие системы VNX внезапно "устареют" без разумной на то причины.
Хотя это и позволит EMC опять поднять денег.

Много шумихи было создано вокруг того, что софт есть ключевой движущий элемент за всеми улучшениями производительности, и того, как теперь можно задействовать все ядра CPU, в то время как раньше, оказывается, это было не так. Софт - здесь, софт - там, и, в общем, это было основной темой всего мероприятия.

OK, убедили. Многоядерность и расширение ее поддержки в сегодняшнем IT-ландшафте это то, о чем говорят все. Параллелизация задач - ключевой момент сегодняшнего IT.

Затем они показали интересный график (я взял слайд из публичного видео):

Я добавил стрелки для уточнения наиболее интересных моментов.

Отметьте, что на левом графике, согласно утверждению самой EMC, текущий VNX использует примерно 2,5 ядра из 6 имеющихся, если вы составите все столбики вместе (например, Core 0 загружен целиком, Core 1 на 50%, Cores 2-4 заняты немного, Core 5 не занят почти ничем). Это важно, и мы к этому еще вернемся. Но, в настоящий момент, если это в самом деле правда, это показывает крайнюю неэффективность использования многоядерности. Все выглядит так, будто ядра процессора фиксированно закреплены за процессами - Core 0 занимается только RAID, например, и так далее. Возможно это способ снизить накладные расходы на переключение контекстов?

Затем они показали, как работает новый контроллер, с 16 ядрами на контроллер (нынешний VNX7500 имеет 6 ядер на контроллер).

ОК, пока все нормально.

Затем они показали, как Святым Духом Программного Обеспечения (в оригинале By The Holy Power Of Software, прим romx), они могут равномерно задействовать все 16 ядер этого нового контроллера поровну (картинка справа).

Далее была интересная часть. Они показали тесты в IOmeter для этого нового контроллера (и только для него).

Они упомянули, что текущий VNX 7500 достигает 170,000 8K операций произвольного чтения (random reads) с SSD (эти цифры сами по себе хороший подарок для разговора с продавцами EMC, обещающими безумные показатели VNX7500 IOPS). ?? что существующая в текущей модели проблема с производительностью связана с тем, что софт не может загрузить равномерно все ядра.

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

Записи это всегда отдельная сложность для дискового массива, конечно. Как мы уже сталкивались с этим производительность VNX в этом случае падает радикально.

Однако, это все оставило несколько больших вопросов:

1. Если все это действительно результат оптимизации софта VNX, будет ли это также работать для VNX7500?
2. Почему бы не показать новый софт также и на VNX7500? Это, возможно, даст увеличение производительности более 2x раз, просто за счет лучшей (равной) загрузки ядер контроллера. Но если простой апргрейд софта на VNX7500 позволит стораджу заработать вдвое быстрее, разве не будет это сильнейшим подтверждением утверждения EMC, что “софт – рулит”? Почему нужно пропускать такую прекрасную возможность это доказать?
3. ?? если с новым софтом на VNX7500 мы можем получить, допустим, 400 000 read IOPS на том же тесте, разница между старым контроллером и новым не будет столь радикальна, как ее показывает EMC… правильно? :)
4. Но если загрузка ядер CPU VNX7500 все же НЕ столь плоха, как это показывает EMC в графике выше (зачем было бы заморачиваться с двумя дополнительными ядрами на VNX7500 в сравнении с VNX5700, если бы это было действительно так), тогда улучшение производительности вызвано в основном простой дополнительной мощностью нового железа контроллера. Что, опять же, противоречит заявленной идее про то, что “софт – рулит”!
5. Почему клиентам EMC нужен XtremeIO если новый VNX так быстр? Как насчет VMAX? ;)

Пункт #4 наиболее важен. Например, EMC годами рекламирует улучшение многоядерной производительности. Текущий релиз VNX FLARE имеет якобы на 50% выше эффективность использования ядер, чем ранее. ??, ранее, в 2008 году, многоядерность рекламировалась как дающая двукратное преимущество по сравнению с софтом, использовавшемся ранее. Однако, после всего последовательного улучшения, график выше показывает нам крайне низкую эффективность использования ядер. Кто же тут прав?

??ли же, может быть, новый контроллер демонстрирует улучшение производительности не столько за счет волшебного нового софта, а, в основном, за счет значительно быстрее работающей аппаратной платформы – более быстрый процессор Intel (выше частота, не просто больше ядер, плюс более эффективные инструкции), более новый чипсет, быстрее память, быстрее SSD, шина, и т.д, и т.п. Потенциально новый контроллер сам по себе в 3-5 раз быстрее, без всякого софта, только за счет новой аппаратной платформы.

Однако я, или, по крайней мере действующие клиенты VNX, скорее всего будут более всего обеспокоены пунктом 1. Разу уж, как нам пообещали, все это решается программным путем… :)

Если новый софт так здорово помогает, будет ли он доступен на существующей платформе VNX? Это должно было бы пойти им на пользу, с учетом того, что, согласно EMC, часть ядер там не занимается ничем. Бесплатное улучшение производительности!

Однако… Если они все же НЕ сделают это доступным, единственным рациональным объяснением тут будет то, что они намерены в очередной раз принудить своих клиентов купить новое железо, и сделать новый forklift upgrade (CX->VNX->”new box”).

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

Если все это про "Software Defined Storage", то почему этот софт так привязан к железу?

У нас в лабе стоят старинные NetApp FAS3070. ??х контроллеры выпущены поколения назад (2006 год, древняя старина), и при этом они работают под текущей версией кода GA ONTAP. Они были произведены примерно 3-4 поколения контроллеров назад, и, на момент их выпуска, они работали изначально под управлением софта очень, очень отличающегося от существующего сегодня, и все равно нормально работающего на них.

??ногда я думаю, что мы тем самым портим наших клиентов :)

Могут ли CX3-80 (самая навороченная в линейке CX3, такая же древность, как NetApp FAS3070) взять и использовать код, показанный на EMC World? Могут ли они взять действующий GA-код для VNX? Могут ли они взять хотя бы код для CX4? Может ли CX4-960 (опять же, самая навороченная из CX4) взять софтовый код с VNX? Я могу продолжать. Но все это рисует только лишь угнетающую картину того, как EMC относится к защите инвестиций в железо для своих клиентов.

Но разговор про работу с устаревающим оборудованием и его поддержка это отдельная крутая история, о которой мы поговорим в другой раз.

D

??сточник <http://recoverymonkey.org/>

Так как я теперь, стихийным образом (вернее будет сказать попустительством EMC, похоже положившим на продвижение VNX в русскоязычном интернете крупный дюймовый болт) являюсь, в некотором роде, неожиданно для себя, авторитетным источником информации про эту модель стораджей, будем пользоваться сим фактом. ?? сегодня вам очередной перевод из блога Recoverymonkey, с очередными укусами за жёппу ;).

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

Еще несколько предостережений про EMC VNX

http://recoverymonkey.org/2013/05/06/more-emc-vnx-caveats/.

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

Я уже писал в недалеком прошлом вот эту статью (есть перевод, прим. romx), и сегодня я хочу углубленнее рассмотреть несколько аспектов. Обсуждаемые сегодя темы:

1. Эффективность хранения на VNX
2. Утверждение, что LUN-ы могут обслуживаться обоими контроллерами
3. Утверждение, что autotiering помогает в большинстве задач
4. Утверждение, что сторадж-пулы – это просто
5. Производительность thin provisioning
6. Новые снэпшоты VNX

Я буду указывать по каждому утверждению ссылки на актуальные документы EMC, а то иначе это ничем не будет отличаться от работы “маркетингового робота”.

Эффективность хранения на VNX

EMC любит утверждать, что на ее системах не требуется отдать 10% пространства в “налог” OS, как это требуется у NetApp (WAFL reserve, прим. romx). Однако, как утверждается по  ссылке рекомендации best practices указывают, что на autotiered pool, как минимум 10% свободного места должны быть всегда доступны на каждом из tier-ов, для обеспечения его нормальной работы.

Также присутствует минимально 3GB оверхеда на каждом LUN, плюс оверхед на метаданные, который вычисляется по формуле, приведенной в статье по ссылке. Плюс дополнительно метаданные, если вы используете дедупликацию.

Моя позиция: Не бывает бесплатного сыра. Если вы хотите новых фич, использующих для своей работы пулы, за это есть определенная цена. В противном случае продолжайте использовать традиционные RAID-группы, там нет новых фич, но они дают гораздо более предсказуемую производительность и характер использования пространства дисков.

LUN-ы могут обслуживаться обоими контроллерами, обеспечивая “load balancing”

Вот тут пошло веселье. Утверждается, что LUN ownership может быть мгновенно переключен с одного контроллера VNX на другой, чтобы обеспечить балансировку их загрузки. Ну, как всегда тут есть тонкости. Важно также отметить здесь, что на момент написания этого поста, в VNX не было никаких средств для организации автоматической балансировки LUN ownership в зависимости от загрузки контроллеров.

1. Если это делается с традиционными RAID LUN-ами: Передача LUN ownership делается без проблем. Это так, как было всегда.
2. Если же LUN находится в пуле – это история другая. Нет способа быстро переключить LUN ownership для такого LUN, без существенного влияния этого процесса на производительность системы.

Обильная информация по тому поводу может быть найдена здесь. Говоря коротко: Вы не можете менять LUN ownership, при использовании пулов, вместо этого вам придется перенести содержимое LUN, на другой LUN, на другом контроллере (именно на другой LUN, перенос LUN-а “как есть” может создать проблемы), в противном случае готовьтесь заплатить производительностью.

Утверждение, что autotiering помогает на большинстве задач

Не торопитесь. (в оригинале: “Not so FAST”, прим. romx). Собственные документы EMC, такие как “best practice guides” полны предупреждений и замечаний, относительно использования autotiering. Несмотря на то, что эта фича фактически пропагандируется в каждой кампании продаж, как создающее множество преимуществ гигантское достоинство.

Вот, например, очень подробный документ “EMC Scaling performance for Oracle Virtual Machine“, этот график найден там на странице 35:

Стрелки добавил я. Отметьте, что наибольшее преимущество в производительности достигается тогда, когда кэш правильно сконфигурирован с точки зрения сайзинга. Дополнительные 5 SSD для VNX tiering (FAST VP) почти не дают существенного повышения производительности на задаче с нагрузкой типа базы данных.

Можно только гадать, какой прирост дали бы эти 4 SSD, если бы были установлены не в autotiering, а увеличили бы кэш…

Быть может, если бы все 8 SSD были бы использованы как all-flash-storage, это было бы даже еще быстрее, чем 4 cache SSD и 5 tier SSD, но это просто лишний раз продемонстрирует слабый “замах” autotiering-а FAST-VP и недостатки его маркетинга.

Утверждение, что storage pools это упрощение работы со стораджем

Типичный подход сэйла EMC к пользователю для продажи VNX это: используйте единый, суперпупер-простой пул дисков с автотирингом данных на нем. Однако вопреки тому, что утверждает маркетинговое шоу, к сожалению, с использованием пулов VNX сложность снижается совсем не так, как это обещается, наприме просто потому что пулы рекомендуются совсем не для любой задачи и не для любой рабочей нагрузки. Рассмотрим типовой сцеарий развертывания VNX, смоделированный по документам best practice:

1. Журнальные LUN-ы RecoverPoint рекомедуется держать на отдельной группе RAID10
2. LUN-ы SQL log на отдельной группе RAID10
3. Exchange 2010 log LUN-ы на отдельной группе RAID10 
4. Exchange 2010 data LUN-ы могут находиться в пуле, но лишь в случае, если он состоит из однотипных дисков, в противном случае нужно использовать несколько традиционных RAID-групп
5. SQL data могут быть помещены на autotiered pool
6. VM могут быть на отдельном пуле, или жить совместно на пуле SQL
7. Репозиторий VDI linked clone может использовать SSD в отдельной группе RAID10

Ну, отлично. Я понимаю все достоинства разделения ввода-вывода, которыми продиктованы рекомендации выше. Однако “продающая” позиция компании в отношении пулов и autotiering это то, что они призваны снизить сложность, общую стоимость решения, улучшить производительность и эффективность распределения пространства. Ясно, что вряд ли все приведенные варианты могут одновременно встретиться в одном стораже на практике. Но что за причина, отчего они не могут быть в одном, или двух пулах, и использовать какой-то вид QoS на массиве, чтобы обеспечить приоритезацию трафика?

?? что получится, если вы отдали лишнего на диски под традиционные RAID-группы в примере выше? Как насчет вернуть или перераспределить это неиспользуемое там пространство другим задачам?

А что насчет варианта, когда места не хватает, как просто вам будет добавить немножко пространства или производительности? (Не в 2-3 раза, допустим, а всего на 20% больше). Сможете вы расширить традиционные VNX RAID-группы на несколько дисков?

?? как там насчет общей эффективности хранения, если все эти задачи нам придется держать отдельно друг от друга? Хмммм…

Для подробностей смотрите документы по дизайну хранилища под Exchange и SQL.

Производительность thin provisioning

О,это просто здорово. Производительность VNX thin provisioning сильно хуже в сравнении с thick, а они оба – в сравнении с традиционными RAID-группами. Проблема с производительнстью возникает прежде всего вследствие того, как VNX выделяет пространство при записи на thin LUN. При этом используются блоки, размером 8KB. Хорошее описание того, как распределяется пространство на сторадж-пуле можно найти здесь (у меня есть перевод, прим. romx). VNX пишет в пулы сементами, размером 1GB. Thick LUN-ы резервируют столько сегментов, размеров 1GB, сколько необходимо, и производительность получается вполне приемлемая. Thin LUN-ы не резервируют место, и, тем самым, не имеют возможности оптимизировать записи и чтения – в результате начинается фрагментация, вдобавок к более высокой загрузке CPU, дискового оверхеда, больше занимается памяти контроллера, все это для обслуживания thin LUN-ов.

Вновь смотрим документ по дизайну хранилища под Exchange 2010, страница 23:

Снова, стрелки на скриншоте, выделяющие важные моменты, добавлены мной:

1. Thin provisioning не рекомендован для высокой нагрузки на VNX
2. Конечно, он такой медленный сам по себе, что вы должны делать ваши thin pools хотя бы на RAID10!!!

Но погодите, thin provisioning придуман для экономии места на дисках, а теперь я должен использовать его на RAID10, который это место просто пожирает?

Какой-то нонсенс.

А что если пользователь желает повышенную надежность и, поэтому, хочет использовать RAID6 на весь пул? Как быстро с этим будет работать thin provisioning?

А, вдобавок у VNX нет способа устранить фрагментацию, которая бесчинствует на их thin LUN-ах. Только через миграцию на другой LUN.

Новые снэпшоты VNX

В VNX появился способ облегчить удар по производительности, присущий традиционным снэпшотам FLARE, перейдя от метода создания снэпшота COFW (Copy On First Write) на ROFW (Redirect On First Write).

Проблема?

Новым снэпшотам VNX требуется использование пулов и thin LUN-ов. Это кажется только технической особеностью, но…

Это те самые две фичи VNX, которые существенно понижают его производительность.

Есть и другие существенные проблемы с новыми сэпшотами VNX, но это тема другого поста. Так что ничего удивительного, что EMC проталкивает RecoverPoint гораздо активнее, чем свои снэпшоты…

??того

Существует маркетинг, и существует “инженерная” реальность.

Поскольку VNX может работать как с пулами, так и с традиционными RAID-группами, маркетинг мудро выбрал не слишком вдаваться в детали о том, что с чем там у него работает.

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

Если вы рассматриваете вариант покупки VNX – по меньшей мере убедитесь, что понимаете, какая из проталкиваемых маркетингом фич будет работать для конкретно вашей задачи. Попросите сделать полную схему разбиения системы на LUN-ы (LUN layout).

?? опять же, мы никак еще не говорили про использование RAID-6 для защиты данных в пуле, это опять же отдельная история для отдельного поста.

D

Сегодня очередной перевод одного из моих любимых авторов, инженера NetApp Dimitris Krekoukias, пишущего в блоге recoverymonkey.org. Текст крайне важный и заставляющий задуматься. Казалось бы, все мы знаем, что такое “IOPS”, но знаем ли мы это на самом деле, и не упускаем ли мы, говоря про IOPS-ы, нечто важное из виду? Насколько полнятие IOPS является однозначно идентифицируемым и можно ли показатели “в IOPS” трактовать однозначно, и сравнивать различные результаты, различных вендоров между собой?

IOPS: Возможно наиболее известный показатель производительности системы хранения.

IOPS означает Input/Output (operations) Per Second, "операций ввода-вывода в секунду". Смысл величины выглядит довольно очевидно. Он измеряет объем работы за определенный промежуток времени (и это не то же самое, что мегабайты в секунду, MB/s).

Кто из вас не видел вендоров, которые превозносят достоинства своих систем хранения, демонстрируя огромные величины IOPS ими достигнутые? Кто из вас не принимал решения покупки системы хранения, основываясь на обещаниях вендорами этих величин? Однако: как часто вендоры, приводя свои результаты, в действительности четко определяли то, что они понимали под аббревиатурой "IOPS", публикуя эти результаты?

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

А теперь подробнее…

Continue reading ‘Что такое IOPS?’ »

Я не первый раз рубликую тут переводы постов инженера NetApp – Dimitris Krekoukias, ведущего автономный, и крайне интересный блог http://recoverymonkey.org/ (другие мои переводы его постов вы можете найти в рубрике “переводы”)

После долгого молчания, Dimitris опубликовал пост, вызванный публикацией отличных результатов кластера FAS6240 в Data ONTAP 8.1.1 Cluster-mode в бенчмарке блочного (FC) доступа – SPC-1, о котором я уже написал в понедельник. Однако вопросу почему он так хорош, и насколько именно он хорош – посвящен сегодняшний перевод.

NetApp опубликовал великолепные результаты тестирования Cluster-Mode в бенчмарке SPC-1

Опубликовано June 20, 2012

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

Мы недавно выпустили ONTAP 8.1, которая, в Cluster-Mode, позволяет создать 24-узловой кластер (каждый узел которого может иметь до 8TB кэша) для задач NAS, и 4-узловой кластер для блочного доступа (FC и iSCSI).

А с выпуском ONTAP 8.1.1 (выпущенного 14 июня), мы увеличили лимит узлов для блочного доступа до 6, плюс добавили ряд дополнительных оптимизаций и возможностей. Между прочим, число узлов в кластере это пока только условный лимит официальной поддержки, это не жестко заданное ограничение.

После публикации нашего рекордного результата в бенчмарке NFS, люди спрашивали, как обстоит дело с производительностью блочного ввода-вывода в ONTAP Cluster-Mode, поэтому мы провели тестирование и опубликовали результаты бенчмарка SPC-1, используя часть той же системы, что уже была протестирована на SPEC sfs2008 NFS.

Для тех кто до сих пор думает, что NetApp не подходит для блочного доступа (это типичный FUD наших конкурентов): Это, на сегодня, лучший результат SPC-1 среди всех дисковых систем хранения, из расчета на уровень latency при достигнутом уровне IOPS (то есть возможно получить даже более высокие показатели IOPS на бОльших лимитах по latency, как я покажу далее в этом посте).

Вот ссылка на результаты и еще одна ссылка, на полную версию со всей доступной информацией.

В этом блоге я уже говорил о том, что представляет собой бенчмарк SPC-1 . Вкратце: Бенчмарк SPC-1 это общепринятый в индустрии, аудируемый, бенчмарк блочного доступа к системе хранения (по Fiber Channel) который проводит стресс-тестирование дисковой подсистемы большим объемом записей, перезаписей, локальных "хотспотов" и смешанной произвольно/последовательной, чтение-после-записи, запись-после-чтения нагрузкой. Около 60% рабочей нагрузки это операции записи. Размеры используемых в бенчмарке операций ввода-вывода различны, от маленьких до больших (таким образом IOPS в бенчмарке SPC-1 не идентичны и не могут быть сравнены напрямую с классическим тестом IOPS в full random блоками 4KB).

Если сторадж успешно работает на нагрузке SPC-1,, он, обычно, также крайне производительно работает на сложной, чувствительной к показателям latency, динамично изменяющейся нагрузке типа баз данных, в особенности OLTP. Полная спецификация для смертельно любопытных может быть найдена здесь.

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

Перед тем, как мы перейдем к анализу и сравнению результатов, несколько замечаний для неверующих:

1. В тестах NetApp не используется диски "с коротких ходом" (short-stroking), так часто любимые многими вендорами, проводящими тестирование, при котором используется только внешняя, наиболее быстродействующая часть диска, где сочетается максимальная линейная скорость и малый разбег механики коромысла жесткого диска, на чем можно показать наилучшие результаты. Вместо этого мы используем настройку параметров системы , чтобы использовать всю поверхность дисков, и не зависеть от того, насколько заполнены данными диски. Смотрите полный отчет здесь, страница 61. Для любителей распространять FUD: это эффективно "старит" состояние WAFL, приближая его к реальному состоянию реально эксплуатируемой системы. Мы также не используем оптимизацию размещения блоков путем их реаллокации.
2. Падения производительности в ходе продолжительного тестирования не наблюдалось.
3. Средняя величина latency (“All ASUs” в результатах) была плоской и оставалась ниже уровня 5ms на протяжении нескольких итераций теста, включая sustainability test в течение 10 часов (страница 28 полного отчета).
4. Не использовался дополнительный кэш, кроме того, который поставляется в базовой поставке FAS6240 (Контроллеры 6240 поставляются с Flash Cache емкостью 512GB, при максимальной возможной емкости данной модели 3TB на ноду (контроллер), то есть для работы с большими нагрузками есть еще значительный запас).
5. Это не "звездолет", построенный исключительно для завовевания победы и установления рекорда в бенчмарке. Мы использовали сравнительно немного дисков, в сравнении с конфигурациями других вендоров, и это не самая быстрая наша модель контроллера (еще есть 6280).

Анализ

Когда мы смотрим на результаты бенчмарка, следует сфокусироваться на следующих моментах:

1. Высокий уровень установившейся производительности в IOPS (нестабильность показателей показывает на наличие проблем).
2. IOPS/диск (это показатель эффективности – 500 IOPS/drive это вдвое лучше и эффективнее, чем 250 IOPS/drive, что, как следствие, означает меньше необходимых дисков в системе, снижает ее стоимость, уменьшает физический занимаемые в датацентре объем, и так далее.)
3. Стабильно низкая latency (пики показывают наличие проблем).
4. IOPS связан и зависит от latency (Получили ли вы высокие показатели IOPS вместе с высокой latency на максимуме? Это практически используемо?)
5. Какой тип RAID использовался (RAID6? RAID10? RAID6 обеспечивает значительно лучшую защиту данных и лучшие результаты эффективности использования дискового пространства, чем зеркалирование, что ведет к снижению стоимость даже более надежного хранилища данных).
6. Какие диски использовались? Хотите ли вы покупать такие диски?
7. ??спользовался ли autotiering? Если нет, то почему нет? Разве он не помог бы в такой сложной ситуации?
8. Какое оборудование потребовалось, чтобы получить стабильную производительность (сколько дисков и контроллеров потребовалось для построения системы? Означает ли это более сложную и дорогую систему? Как это все будет управляться?)
9. Цена (некоторые вендоры указывают цену уже с учетом дисконта, в то время как другие публикуют цену в list price, так что будьте тут внимательнее).
10. Цена/IOPS (наиболее полезная метрика – но следует сравнивать цену list price с list price).

SPC-1 это бенчмарк НЕ для измерения максимума потока данных; для измерения чистого GB/s смотрите другие бенчмарки. Большинство систем не дает больше 4GB/s в этом бенчмарке, так как много операций в нем рандомные (и 4GB/s это довольно много для рандомного ввода-вывода).

Сравнение систем

В этой части мы сравним дисковые системы хранения. Предсказуемо "чистые SSD" (или RAM) системы хранения имеют, конечно, очень высокие показатели производительности, и могут подойти, если ваша задача - обеспечивать работу с небольшим объемом данных очень быстро.

Но мы сосредоточимся на задачах высоконадежных систем общего применения, которые обеспечивают одновременно и высокую производительность, и низкую latency, и большую емкость, за разумную цену, а также, одновременно, большое количество функциональных фич(снэпшоты, репликация, кэширование в flash (megacaching), thin provisioning, дедупликация, компрессия, многопротокольность, включая NAS, и так далее). Опа – оказывается никто из конкурентов не может сделать сразу все что умеет делать NetApp.

Ниже приведен список систем и ссылки на их полные отчеты тестирования SPC-1, где вы сможете найти всю необходимую информацию. Все эти системы имеют высокие результаты и относительно плоскую кривую latency.

• NetApp 6240
• IBM SVC with V7000
• IBM SVC with DS8700
• HDS VSP
• HP 3Par V800
• Huawei Symantec S8100

Также есть несколько других дисковых систем хранения, со значительными результатами по IOPS, но если мы посмотрим на их результаты sustained latency (“Sustainability – Average Response Time (ms) Distribution Data” в любом из полных отчетов) мы увидим, что общие показатели latency чересчур высоки и наблюдается значительная неравномерность, в особенности в начальной фазе, с пиками до 30ms (что крайне много), поэтому мы не взяли их в расчет.

Вот краткий перечень систем и их параметров, отсортированных в соответствии с latency. Кроме этого показана и их стоимость в ценах list price (это можно найти в полном отчете о тестировании) плюс стоимость операции $/IOPS, посчитанная исходя из list price (многие вендоры приводят в отчетах цену с уже введенной скидкой, чтобы цена выглядела пониже):

…но ведь тут показано, что некоторые системы быстрее NetApp… Как так?

Это зависит от того, насколько важен для вас показатель latency и его низкая величина (и от того, принимаете ли вы в расчет используемый тип RAID). Для подавляющего большинства нагрузок типа баз данных, низкая latency операций ввода-вывода гораздо предпочтительнее высоких показателей latency.

Вот как это увидеть:

1. Выберите один из приведенных выше линков на полные отчеты Допустим это будет 3Par, так как он показывает одновременно и высокие показатели производительности, и высокие значения latency.
2. Найдем в отчете главу под названием "Response Time – Throughput Curve". Например это страница 13 в отчете по системе 3Par.
3. Проследим, как latency резко растет при повышении загрузки системы.

Например посмотрим на кривую 3Par:

Заметьте то, как latency резко растет после некоей точки.

Теперь сравним с результатом NetApp (страница 13):

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

Вот почему колонка“SPC-1 IOPS around 3ms” была добавлена в таблицу. Фактически это ответ на вопрос что бы было, если бы уровень latency был в тесте одинаков для всех протестированных систем?

Когда вы примете эту позицию, вы увидите, что система 3Par фактически медленнее, чем NetApp, если сравнить их на одинаково низком желаемом уровне latency.

Вы можете взять точные показатели latency из графика на странице 13, у NetApp таблица выглядит так (озаглавлено "Response Time – Throughput Data"):

Действительно, при сравнении результатов мы видим, что только IBM SVC (с кучей стораджей V7000 за ним) оказывается быстрее NetApp при столь же хороших показателях latency. Что плавно подводит нас к следующей главе…

Сколько железа обеспечивает такую производительность?

Почти любая инженерная задача может быть решена, если дать приложению достаточное количество необходимого оборудования. Результат IBM это как раз хороший пример того, как можно получить хороший результат собрав вместе большую кучу дорогостоящего железа:

• 8 SVC контроллеров (virtualization engines) плюс…
• …16 отдельных систем V7000…
• …каждая состоящая из еще 2 контроллеров SVC и 2 контроллеров RAID
• 1920 дисков 146GB 15K RPM (не так-то просто такие купить нынче, не так ли?)
• ??того 40 контроллеров SVC (8 больших и 32 поменьше), 32 RAID-контроллера, и все это битком наполнено дисками.

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

Сравним эту кухню с вариантом конфигурации NetApp:

• 6 контроллеров в одном кластере
• 432 диска 450GB 15K RPM (самый распространенный и массовый наш диск по состоянию на июнь 2012).

Вопросы (с удовольствие увижу ответы на них от других вендоров):

1. Что произойдет при использовании RAID6 у других вендоров? NetApp всегда тестирует системы с использованием своей версии RAID6 (RAID-DP). RAID6 значительно надежнее, чем зеркалирование, особенно в больших пулах (не говоря уже о более эффективном использовании пространства дисков). Большинство клиентов не хотят покупать большую систему в конфигурации только-RAID10… (пользователи - задавайте вопросы вашим вендорам. Тут нет никакого волшебства – ручаюсь, у них есть внутренние результаты для RAID6, попросите показать их вам).
2. Autotiering это одна из самых раскрученных сегодня фич, с признаками того, что это достижение, превосходящее изобретение пенициллина, или даже колеса, а может даже и огня… Однако никто из дисковых массивов не рассматривает использование SSD для autotiering (IBM опубликовала однажды результат – не впечатляет, делайте выводы). Это при том, что бенчмарк, по своей спецификации активно создающий "горячие точки" (hotspots) нагрузки, должен бы быть здесь идеальным кандидатом для демонстрации эффективности…
3. Почему EMC и Dell не желают публиковать результаты SPC-1? (Они оба, кстати, члены SPC, Storage Performance Council). Только два этих вендора, из крупных игроков на рынке, кто еще не опубликовали свои результаты. EMC ранее говорила, что SPC-1 это нереалистичный тест – ну, типа только ваше приложение с вашими данными на вашем сторадже может показать по-настоящему реальные результаты. Это так, однако SPC-1 это общепринятый индустрией стандартный бенчмарк для блочного доступа произвольного характера, и отличная "лакмусовая бумажка".
4. Для системы, которая регулярно позиционируется для нагрузки Tier-1, IBM XIV, результаты бенчмарков, увы, отсутствуют также, даже для самой новой ее Gen3. Неужели IBM стесняется показать свои результаты SPC-1 для этой системы?
5. Наконец – некоторые наши конкуренты продолжают утверждать, что NetApp, дескать, это "не настоящий SAN", что это, якобы "эмуляция SAN", и так далее. Что бы это все ни значило на самом деле – может быть подход NetApp, с такой "эмуляцией" оказывается, по факту, лучше?… Максимальная write latency в этом тесте составила 1.91ms для в основном записываемой нагрузки!

??тоговые мысли

В накануне опубликованном результате бенчмарка SPC-1, NetApp показала вновь, что Data ONTAP в Cluster-Mode это высокопроизводительная и масштабируемая система, одинаково подходящая как для SAN, так и для NAS задач. Суммируя все вышесказанное, можно сказать, что ONTAP Cluster-Mode:

• Позволяет строить высокопроизводительные и динамически-масштабируемые кластеры хранения для FC, iSCSI, NFS и CIFS.
• Демонстрирует низкую latency при высокой производительности.
• Предлагает исключительно хорошее соотношение price/performance.
• Позволяет доступ к данным одной ноды с любых других нод.
• Перемещает данные между нодами, не прерывая работы с ними (включая CIFS, что ранее не было практически невозможно).
• Поддерживает традиционные для NetApp возможности (оптимизацию процессов записи, взаимодействие с приложениями, снэпшоты, дедупликацию, компрессию, репликацию, thin provisioning, и кэширование во flash (megacaching).
• Может работать на в точности тех же самых контроллерах FAS, что и в 7-mode, что защищает инвестиции.
• Может виртуализовывать системы хранения, расположенные за ними.

??сточник <http://recoverymonkey.org/2012/06/20/netapp-posts-great-cluster-mode-spc-1-result/>

Третья часть серии постов в блоге Wahl Network, посвященных вариантам использования NFS в Vmware и организаци балансировки трафика по нескольким физическим путям.

NFS в vSphere – погружение в детали: часть 3, VMware Load Balancing Teaming

В предшествующих трех постах этой серии мы рассмотрели основные ошибки и заблуждения, связанные с использованием NFS в VMware, а также рассмотрели два варианта построения сети хранерия с использованием NFS - с единой подсетью, и с множественными подсетями. Если вы не слишком хорошо знакомы с тем, как NFS работает в vSphere, рекомендую вам начать с чтения этих статей. Выводы, к которым мы пришли, состоят в том, что NFS в vSphere требует использовать множественные подсети, чтобы использовать множественные физические линки к системе хранения, за исключением, когда EtherChannel правильно настроен правильно используется на одной подсети. Однако, даже при использовании static EtherChannel, множественные таргеты на стороне стораджа, и правильно спланированные least significant bits в адресе необходимы для использования более одного физического пути к системе хранения.

Continue reading ‘VMware и использование NFS: часть 3d – Трафик NFS и балансировка Load Based Teaming’ »

Продолжаем публикацию переводов серии постов в блоге Wahl Network, посвященных вариантам использования NFS в VMware.

NFS в vSphere – погружение в детали: часть 2, порты vmkernel и экспорты NFS в разных подсетях

Apr 27, 2012

Ранее мы уже рассмотрели некоторые ошибочные концепции относительно NFS в vSphere, а также убедились в том, как трафик NFS идет при использовании одной подсети. Сейчас давайте посмотрим, как трафик NFS в vSphere пойдет в случае использования множественных подсетей. Хотя мы говорим тут прежде всего о NFS, это все также применимо и в случае iSCSI, если для него не используется binding.

Continue reading ‘VMware и использование NFS: часть 3c – Трафик NFS в разных подсетях’ »

Для рассмотрения вопроса, как работает доступ к стораджу по NFS с хоста ESXi, я снова воспользуюсь серией постов блога Wahl Network, переводы которых я публикую сегодня и в ближайшие несколько дней. Его автор провел экспериментальную работу, показав то, как работает NFS в сети хранения, когда датасторы и vmkernel расположены в одной общей подсети, в разных подсетях, и рассмотрел вариант использования Load-based teaming, доступный для пользователей версии vSphere уровня Enterprise Plus.

Я надеюсь, что эти статьи ответят на вопрос, как же все же работает NFS в сети хранения vSphere, и как стораджи с использованием этого протокола правильно использовать для VMware vSphere 5.0.

NFS в vSphere – погружение в детали: часть 1, порты vmkernel и экспорты NFS в единой общей подсети

Apr 23, 2012

Конфигурация

Для эксперимента, показывающего, как vSphere направляет трафик NFS в одной подсети, я создал тестовый стенд, с использованием 2 серверов NFS (я использовал для этого NetApp Simulator) с каждого их которых выведено по 2 экспорта, суммарно 4 экспорта NFS. Весь трафик направлен в VLAN 5 (это подсеть 10.0.5.0/24 моего стенда) и идет на хост ESXi 5.0 update 1 (build 623860). Хост имеет 2 физических порта-аплинка и 4 порта vmkernel, дающих трафику NFS множество возможны путей. Для того, чтобы создать существенный трафик в сети хранения, я развернул 4 VM с VMware IO analyzer appliance – по одному на каждый экспорт. Это позволит мне быстро создать трафик с виртуальных машин на все экспорты разом.

Continue reading ‘VMware и использование NFS: часть 3b – Трафик NFS в одной подсети’ »

Несмотря на то, что основная тема блога – системы хранения, прежде всего системы хранения NetApp, поневоле приходится затрагивать интересные смежные темы. Раз уж мы заговорили тут про NFS, стоит затронуть тему использования LACP при организации EtherChannel, так как, как я заметил, понимание этой темы у многих все еще довольно зыбкое.

Поэтому, в очередных переводах в этом блоге – перевод поста в интересном блоге Wahl Network

Демистификация LACP и Static EtherChannel в vSphere

May 9, 2012

Удивительно часто я слышу о людях, которые воспринимают LACP как некую волшебную палочку, которой достаточно махнуть, и все чудесным образом становится лучше, а трафик волшебным образом распределяется по множеству линков. Я думаю, что это происходит от непонимания базового устройства того, как работает EtherChannel, так как я слышал множество ошибочных утверждений и FUD вокруг этого. Этот пост является попыткой описать то, что же за штука, этот LACP, почему он не работает на обычных, native vSphere switches, и почему он, на деле, имеет совсем небольшое количество преимуществ, в сравнении со static EtherChannel.

??так, что такое LACP?

LACP, иначе известный как IEEE 802.1ax Link Aggregation Control Protocol, это простой способ динамически строить EtherChannel. Для этого "активная" сторона группы LACP посылает специальный фрейм, оповещающий о возможностях и желаемых формах EtherChannel. Возможно существование, и чаще всего так и бывает, когда обе стороны являются "активными" (может быть и пассивная сторона). Также следует отметить, что LACP поддерживает только full duplex линки (в настоящий момент, в мире гигабитных, и более, линков, которые всегда full duplex, это уже не является значимым ограничением). Как только обмен фреймам произведен, и порты на обоих сторонах согласовали поддержку требований, LACP создает EtherChannel.

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

LACP отсутствует в Native vSphere Switches

Ситуация проста, нативные коммутаторы vSphere не отвечают на фреймы LACP. Они не слушают и не передают соответствующие кадры. Если вы настроили LACP на внешнем коммутаторе, он не получит отклика на запросы LACP от хоста vSphere, и, следовательно, EtherChannel не будет создан.

Если вы хотите создать EtherChannel с участием хоста vSphere, вы должны создать Static EtherChannel. Когда порт установлен в Static, он не участвует в процессах объявления или распознавания LACP – канал EtherChannel немедленно создается физическим коммутатором.

Как работает распределение нагрузки (Load Distribution)?

Главная мысль:
Как Static так и Dynamic (LACP) EtherChannel используют одни и те же методы распределения нагрузки (load distribution).

Я специально выделил это курсивом и жирным шрифтом. Да, это правда. ?? Static, и LACP используют одни и те же техники балансировки нагрузки для распределения трафика по линкам. Если кто-то утверждает иное, то можете поспорить с ним на деньги, можете хорошо выиграть.

Но Static EtherChannel требует IP Hash, а LACP - нет, не так ли?

А сейчас переходим в темную часть. Ответ на заданный в заголовке вопрос: "Это не так", но вот почему это не так?

IP Hash это требование native vSphere switch. Он не поддерживает никакие другие методы load distribution.

Скриншот выше взять из vSphere Networking guide

А это уведомление из vSphere:

Отметьте, что если я хочу использовать EtherChannel, я выбираю IP Hash в качестве метода балансировки, и появляется данный бокс с сообщением.

Внимание: Термин IP Hash эквивалентен политике load distribution policy вида src-dst-ip на коммутаторе Cisco.

Static EtherChannel в других случаях может использовать любые из доступных политик распределения нагрузки. Но когда порты работают с хостом vSphere, мы вынуждены использовать только IP Hash, так как vSphere ничего другого не умеет.

Если вы хотите использовать LACP с vSphere, вам потребуется установить виртуальный коммутатор Cisco Nexus 1000V (или IBM 5000v). Нет других способов задействовать LACP с vSphere на момент написания этого поста. ??, так как 1000V это (почти) полнофункциональный коммутатор Cisco, в отличие от native vSphere switch, вы можете использовать любые политики load distribution – вы не ограничены только IP Hash (src-dst-ip)

Преимущества LACP перед Static

LACP имеет несколько "карт в рукаве", но это не относится к методам распределения трафика по каналам EtherСhannel.

Hot-Standby Ports

Если вы добавите больше поддерживаемого числа портов в LACP port channel, есть возможность использовать лишние порты в качестве портов hot-standby mode. Если произойдет отказ активного порта, порт hot-standby автоматически заменит его.

Однако, типичное число поддержваемых портов в LACP равно 8, так что для системы vSphere это не та возможность, о коорой стоит беспокоиться. Сомнительно, что у вас сделан 8-канальный EtherChannels к одному хосту vSphere.

Failover

Если у вас имеется dumb-устройство между двумя концами EtherChannel, например media converter, и один из линков, идущих через него отказывает, LACP это понимает и перестает слать трафик в отказавший линк. Static EtherChannel не мониторит состояние линков. Это не типичная ситуация для большинства систем vSphere, которые мне встречались, но в ряде случаев это может оказаться полезным.

Проверка конфигурации

EtherChannel с использованием LACP не активируется, если есть какие-то проблемы с конфигурацией. Это помогает убедиться, что все настроено нормально. Static EtherСhannel не делает каких-либо проверок перед своим задействованием, то есть вам нужно заранее быть уверенными, что все сделано правильно.

Выводы

Я не хочу сказать, что LACP (или Nexus 1000V) это плохо. LACP - это очень полезный и популярный протокол, активно используемый. Проблема, побудившая меня написать этот пост в том, что я вижу людей, которые считают что с использованием LACP они получат лучшую балансировку трафика, или же что-то еще, что он совершенно точно не делает. Так что не спешите закупать Cisco 1000V для вашей системы vSphere только оттого, что вы хотите использовать LACP, пока вы не будете иметь ясного плана того, что, на самом деле, вы хотите получить в результате.

??сточник:
http://wahlnetwork.com/2012/05/09/demystifying-lacp-vs-static-etherchannel-for-vsphere/

Сегодня в переводах новый автор, это principal technologist регионального представительства NetApp по Австрали и Новой Зеландии, и директор SNIA ANZ - Richard J Martin. Его блог это вообще и в целом довольно отличающееся явление от, увы, распространенного сейчас стиля среди блоггеров “Так как мне не хватает 140 символов моего твиттера, я вынужден написать эти 320 символов в блог, но лучше читайте мой твиттер”, его записи в блог это, порой, настоящие глубокие статьи, которые интересно читать и трудно переводить.

Надеюсь, что он еще не раз появится в моих переводах.

Ричард Мартин, NetApp Australia отвечает на вопрос “как заполненность данными системы хранения влияет на ее производительность?”

How does capacity utilisation affect performance ?

September 10, 2011 storagewithoutborders

Несколько дней назад я получил письмо с вопросом "Каковы рекомендации по максимальному уровню использования пространства системы хранения, не вызывающему падения ее производительности?". С одной стороны такие вопросы раздражают меня, так как чаще всего рождаются из регулярно вбрасываемого FUDa о NetApp, с другой стороны, даже несмотря на то, что правильно спроектированная для стабильного уровня производительности система хранения редко (если такое и вообще возможно) сводится к любой единственной метрике, понимание особенностей использования емкости хранилища и его влияния на производительность, это важный аспект при проектировании вашей системы хранения.

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

Поэтому, отвечая на вопрос, как уровень заполненности системы хранения влияет на ее производительность, мне приходится оговариваться, что "это зависит от ряда факторов", но в большинстве случаев, когда задают такой вопрос, то спрашивающего он интересует для нагрузки с высоким уровнем операций записи, например VDI, некоторые виды online transaction processing, и системы электронной почты.

Если вы рассматриваете такие варианты нагрузки, то можно смотреть наш старый добрый TR-3647 в котором как раз рассматриваются высокие нагрузки со значительными объемами записи, и где говорится:

Структура размещения данных WAFL, используемая в Data ONTAP, оптимизирует записи на диск, для улучшения производительности системы и повышения уровня использования полосы пропускания дисков. Оптимизация в WAFL использует небольшой объем свободного или зарезервированного пространства в пределах aggregate. Для высокой нагрузки, связанной с интенсивной записью, мы рекомендуем оставлять незанятым пространство, равное, в среднем, 10% от usable space, для работы этого оптимизационного процесса. Это пространство не только обеспечивает высокопроизводительную запись, но также работает как буфер при неожиданно возникающих потребностях приложения в свободном месте при объемных записях на диск.

Я видел некоторые бенчмарки, использующие синтетическую нагрузку, где точка перелома графика производительности наблюдалась между 98 и 100% usable емкости, после вычета WAFL reserve, я также видел проблемы производительности, когда люди полностью заполняли все доступное пространство на системе хранения, а затем начинали писать не нее мелкими блоками множество перезаписей данных. Это не является уникальным свойством именно WAFL, в случае любой системы хранения такое ее использование будет довольно плохой идеей, заполнить все пространство на любой структуре данных, а затем пустить на нее объемный random write.

Однако можно смело сказать, что на подавляющем большинстве нагрузок, вы получите на системах NetApp больше "IOPS со шпинделя", чем у любой аналогично сконфигурированной (и за сходную цену) системы хранения других производителей.

Оставляя в стороне тему FUD, (подробный его разбор требует довольно глубокого понимания внутренней архитектуры ONTAP) при рассмотрении того, как влияет заполнение емкости на производительность на системах хранения NetApp FAS, надо хорошо понимать следующие моменты:

1. Для любого конкретного типа рабочей нагрузки и типа системы хранения вы можете достичь только сравнительно ограниченного числа операций на диск, это число на диск 15K RPM составляет, обычно менее 250.
2. Производительность системы хранения обычно определяется тем, на сколько дисков может быть распараллелена нагрузка ввода-вывода.
3. Большинство производителей систем хранения предоставляют для рабочей нагрузки ввода-вывода диски, объединенные в RAID-10, который использует вдвое больше raw-дисков на данный объем usable. При этом NetApp использует RAID-DP, который не требует удваивать количество дисковых шпинделей на заданный объем usable данных.
4. В большинстве бенчмарков (см. например SPC-1), NetApp использует для тестирования все доступное дисковое пространство, кроме 10% от usable space (в соответствии с написанным в TR-3647) что дает пользователю примерно 60% от емкости raw дисков, при этом достигая того же уровня IOPS/диск, которое другие производители получают при уровне usable в 30% от raw. Таким образом, равную производительность из расчет на жесткий диск мы обеспечиваем при на 10% большем уровне usable пространства, чем другие производители могут теоретически достичь при использовании RAID-10.

В итоге, даже без использования дедупликации и thin provisioning, или чего-то подобного, вы можете хранить вдвое больше данных на системе хранения NetApp FAS, обеспечивая тот же уровень производительности, как и большинство конкурирующих решений с RAID-10.

Хотя все это действительно правда, следует отметить, что тут есть и один недостаток. Хотя величина IOPS/Spindle более-менее та же, величина "плотности IOPS" (IOPS density) измеренная в IOPS/GB для результатов NetApp SPC-1 составляет примерно половину от решений конкурентов, (те же IOPS , 2x данных = вдвое меньше плотность). Хотя это на самом деле и сложнее сделать, за счет более низкого соотношения cache/data, если у вас есть приложение, которое требует очень высокой плотности IOPS/GB (например некоторые инфраструктуры VDI), тогда вы можете не использовать всю имеющуюся у вас дополнительную емкость под эту нагрузку ввода-вывода. Все это дает вам, в результате, возможность выбора из трех вариантов.

1. Не использовать это дополнительное место, оставив его незанятым на aggregate, позволить работать на нем оптимизации записей и получить лучшую производительность.
2. ??спользовать дополнительное место, например для данных некритичных к производительности, таким как хранение снэпшотов, или зеркальная реплика данных, или архивы, и так далее, и установить этой нагрузке пониженный приоритет с помощью FlexShare.
3. Установить карту Flash Cache, которая удвоит эффективные показатели IOPS (зависит от вида нагрузки, конечно) на физический диск, что обойдется дешевле, и сэкономит ресурсы, чем удвоение количества физических дисков.

Если вы поступаете иначе, то вы можете получить ситуацию, когда наша высокая эффективность использования пространства позволяет пользователю запустить слишком большую нагрузку по вводу-выводу на недостаточном количестве физических жестких дисков, и, к сожалению, снова снова порождает пресловутый и бесконечно гуляющий FUD о "Netapp Capacity / Performance".

Он некорректен прежде всего потому, что причина тут не в каких-то тонкостях Data ONTAP или WAFL, а в том, что на систему, сайзинг которой был проведен для рабочей нагрузки X, помещают 3X данных, так как "на дисках еще есть место", и весь ввод-вывод этих 2-3-кратного объема данных наваливается на дисковые шпиндели, запланированные под совсем другой уровень нагрузки и объемов.

Для того, чтобы сделать счастливыми, и, что немаловажно, поддерживать это состояние в пользователях вашей системы хранения, вам, как администратору, нужно уметь управлять не только доступной вам емкостью, но и доступной производительностью системы хранения. Чаще всего у вас будет исчерпываться одно раньше, чем другое, и работа эффективной IT инфраструктры означает умение балансировать рабочую нагрузку между этими двумя ресурсами. В первую очередь это означает, что вы потратили определенное время измеряя и мониторя емкость и производительность вашей системы. Кроме этого вам следует настроить вашу систему так чтобы иметь возможность мигрировать и ребалансировать нагрузку между ресурсными пулами, или же иметь возможность легко добавлять дополнительную производительность для имеющейся нагрузки не прерывая нормальной работы системы, что может быть осуществлено с помощью таких технологий, как Storage DRS в vSphere 5, или Data Motion и Virtual Storage Tiering в Data ONTAP.

Когда вы наблюдаете за параметрами вашей системы хранения, вы можете своевременно принять меры, до того, как какие-либо проблемы проявятся. У NetApp есть множество великолепных инструментов по мониторингу производительности всей системы хранения. Performance Advisor дает вам визуализированные и настраиваемые алерты и пороги их срабатывания для встроенных метрик производительности, доступных в каждой системе хранения FAS, а OnCommand Insight Balance предоставляет углубленный отчет и упреждающий анализ для всей вашей виртуализованной инфраструктуры, включающей, в том числе, и стороннее, не-NetApp, оборудование.

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

Хотя я понимаю весь соблазн вернуться к старой практике, привычной для "классических" систем хранения, когда для системы хранения почти нет шансов превысить ее возможности по IOPS, прежде чем она исчерпает свои возможности по емкости, это почти всегда невероятно расточительно, и ведет, по моему опыту, к уровню использования емкости около 20% и менее, и приводит к экономически неоправданной цене/GB для таких “Tier-1″ хранилищ. Возможно еще настанут "сытные годы", когда администраторы будут снова иметь роскошь не обращать внимания на цену решения, или, быть может, вы окажетесь в такой редкой отрасли, где "цена не имеет значения", однако для остальных нынешние времена - времена начистить и привести в готовность свои навыки мониторинга, настройки и оптимизации. Сегодня спрос есть на умение делать больше с меньшими затратами, и надо учиться этому.