Archive for июня 2013

SnapVault

Продолжим наш курс Back to basics. Кроме репликации SnapMirror у NetApp есть еще один Snap-что-то продукт – SnapVault. Давайте посмотрим, что это и для чего может в жизни сгодиться.

SnapVault, как можно догадаться из названия, это средство, позволяющее сложить снэпшоты (Snap) на долговременое хранилище (Vault), то есть это такое средство бэкапа данных с системы хранения, например главной, рабочей, или, в терминах NetApp – Primary, на резервную, или Secondary.

Зачем? Ну, зачем вообще используется резервное копирование на другой сторадж? Чтобы обезопаситься и обезопасить данные от физического отказа системы хранения. Почму бы для этого не использовать SnapMirror? Очень просто. Потому же, почему RAID это не бэкап. Репликация никак не поможет в случае повреждения непосредственно данных. Поврежденные данные, например испорченные на уровне приложения, точно также отреплицируются на резервную систему, и вы будете иметь два комплекта плохих данных. Тут выручили бы снэпшоты. Но снэпшоты, как вы помните, хранятся на самой системе хранения, непосредственно на исходном томе, такова их принциппиальная конструкция, и если мы вдобавок ко всему, имеем поврежденную или физически потерянную primary систему хранения, то вместе с ней погибнут и данные снэпшотов. Хорошо бы эти снэпшоты уметь выносить куда-то наружу, чтобы потом иметь возможность из них исходные данные не любой сохраненный момент восстанавливать. Вот как раз этим и занимается SnapVault.

Continue reading ‘SnapVault’ »

SnapMirror, часть 2

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

Начнем же подробнее про именно SnapMirror.

Continue reading ‘SnapMirror, часть 2’ »

Новинки на EMC World или всегда ли “рулит софт”?

Как я и обещал, прошлым постом новости про 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.

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

MCX_core_util_arrow[1]

 

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

Отметьте, что на левом графике, согласно утверждению самой 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/>

18/0.143

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.