NetApp AFF: All-Flash FAS. Комментарии специалиста.
Автор блога NTAPgeek расспросил Ника Триантоса, одного из ведущих инженеров NetApp, по поводу All-Flash FAS систем, стоящих за ними технических решений, и чем AFF отличается от других flash-стораджей, в том числе и тех, что производит сам NetApp, например уже известного вам EF550.
Ник говорит:
“Наибольшая проблема для нас была не в том, как WAFL пишет; на деле это как раз большой плюс архитектуры. Основные проблемы и задачи при разработке были:
Оптимизация под многоядерные процессоры – Долгое время Data ONTAP не умела эффективно использовать многоядерность процессоров. Проект по проведению оптимизации под многоядерность стартовал с версии 7.3 и продолжался вплоть до релиза Data ONTAP 8. Я уверен, что вам доводилось видеть ситуацию, когда один CPU работает с загрузкой 90% и другой - на 20%! Если нагрузка упирается на уровне ONTAP domain, который должен выплняться на одном единственном ядре, то возникает узкое место для роста производительности. ?? при этом неважно, что другие ядра были недозагружены. Эта задача была, в итоге, решена.
Управление метаданными – Когда вы используете маленькие блоки данных, например у NetApp это 4K, то при этом вы получаете множество метаданых, которыми нужно управлять. Для того, чтобы получить максимально быстрый доступ к даным, вам нужно сперва максимально быстро получить доступ к их метаданным. А где быстрее всего доступ к метаданым? В оперативной памяти. Вот почему мы используем так много оперативной памяти на контроллерах серий FAS2500 и FAS8000; мы стараемся как можно больше метаданных при работе держать в быстрой памяти контроллера.
Защита данных – Это связано с темой выше. Системы AFF имеют больше возможностей по защите данных, чем любая другая система c flash (и, кстати, не только flash) на сегодняшнем рынке. Хотя это и полезная штука, есть определенные недостатки. Недостатки состоят в более динных путях ввода-вывода, так как метаданные размещаются и валидируются отдельно от блоков данных.
Как вы защищаетесь от lost writes? Что случится, если вы торговая компания, и на вашей системе хранения SSD сказал, что данные записаны, а на деле он их не записал, или записал не так или не туда? Вы рискуете огромными финансовыми потерями. Data ONTAP не только обнаруживает такие ситуации, но и защищает, а также помогает восстановить данные, испорченые в результате lost writes (это крайне коварная проблема).”
Потерянные операции записи, или “Lost writes”, это редкая, но при этом очень трудно обнаруживаемая ошибка, и самое плохое с ней то, что вы не знаете, что она уже произошла, и обнаруживаете ее только дни или даже месяцы спустя. Но когда она случилась, она повреждает ваши данные! ?? тут можно только пожелать удачи вам, в поисках бэкапа, снэпшота или точки репликации, в котором эта ошибка еще не проявилась и данные еще не повреждены. Конечно же, любые фичи по зашите данных имеют свои побочные эффекты и недостатки.
Другими словами, хорошая скорость работы и устойчивость к отказам сразу двух дисков – недостаточны для того, чтобы считать, что ваши данные надежно защишены. В особенности, когда flash-хранилища используются для бизнес-критичных приложений. Вам следует проанализировать возможные ситуации отказов, и убедиться, что ваше хранилище устойчиво к ним, а данные - защищены. Более 20 лет мы совершенствеум и развиваем Data ONTAP, и достигли в ней очень высокого уровня надежности и устойчивости против всех видов отказов и различных их комбинаций.”
Напомним, бандлы NetApp AFF имеют:
- Больше памяти
Больший объем кэша чтения-записи в FAS8000, что позволяет держать в нем больше метаданных - Более быстрый NVRAM
Быстрее отрабатываются ACK, как следствие – ниже отклик и задержки - Значительно оптимизированную многоядерную эффективность OS
Проводилась начиная с Data ONTAP 7.3 - Continuous Segment Size Cleaning (CSS)
Переменный размер сегмента Data ONTAP (4K-256K) - ??нтеллектуальные алгоритмы упреждающего чтения, определяющие типовые паттерны операций:
- Последовательное чтение с тем же (например 32k) и различными размерами блоков (4k,64k,4k,64k)
- Скачущее (strided) чтение: Начнем с блока N и прочитаем, считая с него, блоки 10 и 12, но пропустим блок 11
- Обратное чтение: Начнем с блока N, и прочитаем –10 блоков, считая от него
- Несколько потоков чтения, читающих из разных точек
Бандлы NetApp AFF доступны к заказу с 23 июня 2014 года.
Меня терзают смутные сомнения насчёт проблемы lost write. Сколько я не искал в интернете, в основном, все источники были либо нетапповские, либо около-нетапповские, что может натолкнуть на мысль, что эта проблема слегка искусственна.
Nostromo:
Что значит “искусственна”, если ее регистрируют (причем в работах вполне научного уровня). Другое дело, что, скорее всего, другие вендоры, не имея средств этому противодействовать, занимают позицию “меньше знаешь - крепче спишь”.
romx:
Ну, я соглашусь с тем, что она присутствует. Но, тут вопрос в том, насколько она часто встречается? Не является ли это проблемой из области “заряженная частица пролетела через кристалл процессора и он неправильно посчитал что-то” и для решения оной требуется приобрести мейнфрейм, так как в вашей x86 сквозного контроля данных нет?
Nostromo:
Зависит от вас, в конечном счете. Я видел людей, которые считают, что ECC DRAM в серверах - буржуйство и роскошь, несмотря на то, что результаты исследования частоты ошибок в памяти совсем неутешительны и широко доступны:
http://research.google.com/pubs/archive/35162.pdf
http://www.zdnet.com/blog/storage/dram-error-rates-nightmare-on-dimm-street/638
http://serverfault.com/questions/26483/statistics-on-ram-malfunction
2 nostromo:
сарказм понятен - однажды был по касательной вовлечен в процесс с проблемами SRAM в процессорах UltraSPARC II , где первоначально объяснения шли на уровне космических лучей. В тот раз “дело было не в бобине”
Что касается lost write. Сам термин действительно NetApp-овский - у них есть даже патент на это. Но если откровенно, то это просто один из характерных патернов сбоев диска(или точнее сбоя на всем пути записи на физический медиа) и способ защиты от него. Другие производители могут не выделять этот патерн от других вариантов сбоя, так как они не обеспечивают “лекарства” для этой болячки. В чем смысл для них говорить об этом? Для них это просто сбой медиа, вероятно фатальный.
Случаи с “лост райт” есть - они описаны в burt-ах и эти случаи не получится показать на пальцах рук :) Шит хаппенс в прошлом - и бывает сейчас ( это не научные исследования, а последствия реальных кейсов) . А что будет дальше не понятно - вот уже-уже диски 6ТБ, а потом еще более емкие с частотой вращения =< 5400. Диски становятся более емкими, более медленными и более ненадежными. Клевая конфигурация :) В этой ситуации “лост райт” еще один уровень спокойствия.
ВСЕ ??МХО.
romx:
“А вы так любую стенку убрать можете?” (ц) :). Мы же вроде о дисках говорим, при чём тут RAM?…
Odna Ptichka:
Я извиняюсь, что это выглядело, как сарказм, я не стремился к этому. Однако, если есть статистика, аналогичная той, что привёл romx для RAM - это уже отличный предмет для разговора! ??, да, прошу прощения за необразованность, а что такое “burt”?
Nostromo:
> Мы же вроде о дисках говорим, при чём тут RAM?
Мы говорим о людях, для которых все - “маркетинг”, и никакие результаты, полученные другими, не убеждают, пока их лично за задницу не укусит. Но тогда обычно бывает уже поздно “пить боржом”.
По “космические лучи” заговорили вы. По третьей ссылке: “In a population of server class 36 machine, I see a correctable failure detected by the ECC circuitry once every 3 months.” Вам решать, насколько актуален “вопрос в том, насколько она часто встречается?”
romx:
Я не из таких людей, вы, по-видимому, меня с кем-то путаете. Бегло погуглив, я особо информации не нашёл, разве что от оракла и чуть-чуть майкрософта и техдоков нетаппа. То есть - статистики, подобной тому, что вы привели по RAM, я не нашёл. ??з чего можно сделать вывод, что lost write происходит, как минимум, реже, чем ecc error. Вопрос в том - насколько? Если у вас есть какая-либо статистика по этому вопросу - давайте обсудим.
?? да, раз уж пошёл разговор про burt (говорил же - я погуглил :)), можете вот это прокомментировать: http://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=672232 ?
Nostromo:
> Я не из таких людей, вы, по-видимому, меня с кем-то путаете.
Разве это писали не вы?:
“все источники были либо нетапповские, либо около-нетапповские, что может натолкнуть на мысль, что эта проблема слегка искусственна.”
“Не является ли это проблемой из области “заряженная частица пролетела через кристалл процессора и он неправильно посчитал что-то””
Я в ответ, показал вам, что проблема “пролетела заряженная частица” совсем не искуственна, несмотря на то, что вам она кажется таковой, что вы даже привели ее в качестве, ха-ха, варианта. Как и другие, считающие, что проблема несущественна, и маловероятна, пока они с ней лично не столкнулись.
> Бегло погуглив, я особо информации не нашёл
Плохо “гуглили”, даже я в этом блоге писал и давал ссылку
http://blog.aboutnetapp.ru/archives/294
Похоже появилась “онлайн дедубликация нулей” для AFF.
http://alikulov.me/blog/all/chto-novogo-v-data-ontap-8-3/