Storage Class Memory в СХД — если вам нужно еще побыстрее

2018-12-06 в 12:53, admin, рубрики: 3par, HPE, intel, nimble, NVMe, Optane, scm, Блог компании Hewlett Packard Enterprise, высокая производительность, деньги на ветер, здравый смысл, Компьютерное железо, кэширование, мы не такие, системное администрирование, хранение данных

Картинка не выражает позицию компании и является личным видением автора, не обязательно связанным с темой данного текста, аминь Как вы наверное помните, НРЕ давно вкладывается в тему новых типов хранилищ данных (конечно, The Machine) и в оптимизацию доступа к хранилищам (наше членство в консорциуме Gen-Z).

Цель этого движения — ускорить работу приложений наших заказчиков. Причем движение это многоуровневое: пока куется совершенно новая архитектура вычислительных систем The Machine (т.н. памяте-центричная архитектура), мы понимаем, что ускоряться нужно уже сейчас. Давайте посмотрим что можно сделать сегодня, и что появится у HPE завтра. Подсказка — речь пойдет о сильном ускорении наших СХД 3PAR и Nimble с помощью умного и относительно бюджетного кэширования на Storage Class Memory (SCM) в форме Intel Optane.

Во-первых, установим границы исследуемой задачи. Нам в этом посте не интересны высокопроизводительные вычисления со своей спецификой и не интересны задачи, требующие исключительно внутри-серверного быстрого хранилища. Последние — это несомненно тоже тема для Intel Optane и вообще SCM, но такие задачи зачастую специфичны, плохо поддаются виртуализации и соответственно консолидации. Мы поговорим о задачах и приложениях, которые вполне уживаются с внешней СХД класса 3PAR, Nimble или MSA (хотя MSA-ки трогать не будем тоже).

Итак, как можно повысить производительность виртуализованного приложения, работающего с данными на внешней СХД:

посмотреть что сдерживает приложение сейчас. Возможно дело совсем не в СХД, а в ожидании процессора, во внутренней логике работы с данными, в неоптимально написанных запросах;
если задержки большие со стороны ожидания данных (IO), то сначала стоит проверить соблюдены ли все рекомендации по настройке связки приложение-ОС-драйверы (SCSI, HBA, т.п.)
возможно дело в сети SAN (Ethernet, FC);
возможно дело все-таки в СХД. Где в СХД? В железе контроллера (что с кэшем, какова загрузка процессора), в ОС контроллера и драйверах, в шине данных, в дисках...

Возможный ход мысли: О, точно — диски! Все остальное сложно и не хочется трогать, а вот с дисками попробуем. Что у нас, гибрид — ну значит надо all-flash. У нас уже all-flash? А что лучше бывает? Смотрим рекламу уважаемых брендов:

Все понятно, берем хранилку с «NVMe-дисками». Подождите, сколько стоит? И надо купить новую СХД, я не могу апгрейдить свою текущую? Ну, надо так надо…

А можно ли по-другому все-таки? Мы в НРЕ считаем, что не только можно, но и нужно. И вот почему:

Дело в том, что большинство NVMe SSD на рынке сейчас — это тот же самый тип носителя, NAND-flash, только подключенный к контроллеру не по Serial Attached SCSI (SAS) протоколу, а по новому протоколу NVMe. Новый протокол без сомнения прекрасен, и вот немного фактов:

доступно 64 000 очередей с 64 000 потоков каждая — IOPS выше крыши
контроллер прямо в CPU — ниже нагрузка на процессор
каждое ядро процессора видит каждый SSD напрямую — низкие задержки

При полной замене SCSI-протокола на всем пути от приложения до дисков возможно значительно снизить задержку доступа. Но что предлагают нам маркетологи сегодня? «NVMe-диски». Т.е. вся цепочка до самого контроллера СХД остается та же — SCSI. А потом контроллер просто перепаковывает SCSI в NVMe и так общается с подключенными NAND SSD. Результат на графике выше — выигрыш в задержке минимальный. Хотя выигрыш по пиковым IOPS действительно может быть очень заметен — парадокс. Но реальность в том, что он будет не так заметен для вашего реального приложения, и на наш взгляд совсем не будет стоить той разницы в цене и проигрыше в доступной емкости в сравнении с SAS SSD.

Что HPE предлагает вместо простой замены «последней мили» с SAS на NVMe — использование подключенных по NVMe совершенно новых накопителей Intel Optane в качестве кэша на чтение в контроллерах наших СХД 3PAR и Nimble.

(И арифмометр и админа на фото зовут Феликс, но разница огромна!)

Почему мы решили пойти по этому пути:

так мы можем предложить нашим заказчикам обновить уже закупленные СХД (конкретно 3PAR 9450, 20450, 20850 и Nimble AF60 и AF80 — все топовые all-flash)
при этом очень простым способом (добавлением карты расширения с Optane на борту в каждый контроллер) мы понижаем максимальную задержку примерно в 15 раз, и среднюю — на 30-40% (IOPS тоже растут, ну да и ладно). А самое главное, что задержка не скачет от маркетинговых "от 0,2 мс!" до бесконечности (маркетинг не наш, просто цитирую), а становится гораздо стабильнее:

(Величины задержек на основе внутренних тестов НРЕ)
поконкретнее чего можно ожидать от такого снижения задержки на массиве для вашего любимого Oracle, например: по нашим внутренним тестам IO wait сокращается в среднем на 37%, а выполнение SQL select'ов ускоряется на 27%.
почему кэш на чтение, а не на запись? Потому что и в 3PAR и в Nimble уже многие годы в качестве кэша на запись используется оперативная память DRAM (в случае Nimble — энергонезависимая NVRAM). Она в свою очередь в разы быстрее NVMe-устройств, и до появления Gen-Z или аналогичных новых протоколов будет оставаться таковой. Т.е. запись ускорять через NVMe не надо.
почему именно Intel Optane? Потому что это новейший тип носителя, пусть пока отстающий от NAND по плотности, но на порядок быстрее по отклику. Плюс, Optane обладает практически неисчерпаемым ресурсом на перезапись. В общем и целом, для нагруженных систем стоимость транзакции на Optane горазде ниже, чем на NAND NVMe. А кэш — это слой очень нагруженный со всех сторон. В него копируются с более медленного слоя горячие данные (поэтому нужен ресурс), с него идет чтение, если данные не найдены в NVRAM-кэше контроллера (поэтому нужен быстрый отклик, чтобы выход за пределы NVRAM-кэша не выглядел как поездка в гипермаркет по сравнению с походом в магазин у дома).
почему не поставить NVMe-диски все-таки? Обязательно поставим! Например шасси Nimble позволяет установку таких дисков уже сейчас (бэкплейн к этому готов), только диски такие мы для Nimble пока не продаем, потому что рано. SCM-кэш уже сейчас дает кратный прирост производительности за относительные копейки. Так давайте использовать его, пока NVMe NAND еще есть куда дешеветь, сам протокол NVMe еще развивается (multi-pathing появился в стандарте только в марте 2018 года, и еще сильно отстает от стабильности SCSI), и в целом экосистема NVMe от приложения до дисков еще не развита (NVMe over fabric пошел в детский сад, производители спорят как это должно выглядеть, драйверы обладают минимальным функционалом, чтобы потом не переписывать слишком много, когда всё устаканится).
ну и еще потому что мы очень любим все кэшировать. Вот например про Nimble:

Да, кстати, знакомы с HPE InfoSight? С помощью этого инструмента вы всегда знаете где искать задержку. Например вот так:

(Нашедшим задержку просьба обращаться в нашу веру.)

Пора подвести итог: если вы являетесь счастливым обладателем 3PAR 9000 или 20000, то вы можете заказать 3PAR 3D Cache на базе Intel Optane прямо сейчас. Если вы присматриваетесь к массиву Nimble All-flash — берите, т.к. это надежная база для защиты инвестиций в будущем. Начните с SAS NAND SSD сейчас, подключите All Flash Turbo-кэш на базе SCM позже, потом поменяйте диски на NVMe.