Системы хранения данных ЕМС — это как хорошая немецкая машина. Знаешь, что немного переплачиваешь за бренд, но безопасность данных и чуткость управления обеспечены. И сервис: премиальная гарантия, например, доставка запчастей в течение 4 часов с выездом инженера в случае необходимости. Ну и главное: пугающие слова DU/DL перестанут появляться в отчётах. А это ведь самое страшное сочетание для сервисных инженеров и заказчиков. Снижение рисков простоя или потери данных – это то, за что ИТ-директор готов бороться любыми средствами.
Так вот, относительно недавно вышла новая линейка оборудования. Ниже её обзор с кратким ликбезом про СХД в принципе. И рассказ о том, как реально хорошие вещи сделали ещё лучше.
Сразу
Знаю, что сразу спросите по стоимости. Она высокая. Заплатить нужно не меньше тридцати тысяч долларов. За эти деньги дают полностью отказоустойчивую конфигурацию с мощным функционалом, трёхлетней поддержкой и обновленным софтом, о котором пойдет речь ниже. То есть система далеко не домашняя и даже не для малого бизнеса.
Зачем нужны СХД гибридного типа?
Сначала немного истории. Многоуровневое хранение – это сочетание быстрых и дешевых, но ёмких дисков в одном массиве данных. Существовала возможность такого комбинирования еще тогда, когда о flash-дисках мы только мечтали ввиду их космической стоимости. Так вот, существует миф, что эту фишку придумали для улучшения производительности. А вот и нет! Изначально такое хранение использовалось для экономии: положим данные, которые не используются на медленные и дешевые диски. Значит быстрых понадобится меньше – только для «горячих» данных.
Затем SSD плотно вошли в нашу жизнь. Логично было добавить в наш «суп» из быстрых и медленных дисков немного приправы из SSD. Самые быстрые и «горячие» данные, всего 5-10 процентов от всего объема, теперь попадали на них. Обновленные СХД VNX– это уже третье поколение гибридных массивов, в котором они, на мой взгляд, преуспели на славу.
Итак, с одной стороны у нас есть решения, целиком состоящие из вычислительных и flash-модулей. Они работают с горячими данными со скоростью скорее близкой к DRAM, чем к классическим HDD, но при этом такие системы очень дорого обходятся при пересчете стоимости гигабайта хранимых данных. Как правило, их используют там, где нужно постоянно «перемалывать» 10-20 терабайт с большой скоростью. Пример – высоконагруженные СУБД, VDI. С другой стороны, системы на классических механических дисках не позволяют работать с данными настолько быстро, но дают возможность хранить их очень много (стоимость за хранимый гигабайт может быть на порядок ниже).
Однако в большинстве случаев нужно одновременно и иметь большой объём хранилища, и быстро предоставлять доступ к «горячим» данным. Примером могут служить типичные задачи для СХД, когда надо хранить какую-нибудь СУБД одновременно с томами под виртуализацию, почтой, архивами и т.д… В этих случаях используются либо связки Flash-СХД + классическая СХД, либо СХД смешанного (гибридного) типа. Мы сегодня говорим как раз о последних – поддерживающих в одной системе как flash-накопители, так и классические диски.
Итак, система прошлого поколения уже была очень хороша. Сама умела работать с flash-модулями и умела вообще всё, что нужно для работы с высоконагруженными приложениями. В целом, могло показаться, что сделать что-то лучше довольно сложно, и дальнейшее увеличение производительности возможно только за счет железа. Но нет, разработчикам удалось, внеся серьёзные изменения в софтверную часть платформы, добиться просто огромного выигрыша в производительности.
Новое поколение
Вот эти штуки.
Первое – новый EMC рассчитан на большие объёмы. Флагман позволяет поставить до 1500 дисков. Одному из наших клиентов, кстати, эти 6 ПБ могут пригодиться, благо данных там довольно много – но на практике пока внедрений больше 2ПБ не было.
Всё работает быстрее. Стало больше кэша, X-BLADE (файловые сервера) теперь более оптимизированы. Да-да, не забываем, что доступ к этой СХД может быть как блочный (FC, iSCSI, FCoE), так и файловый (CIFS, NFS).
Добавилась новая блочная дедупликация. Про неё и другие софтверные детали ниже.
Обновилась аппаратная составляющая. Блочные контроллеры теперь умеют работать с полной SSD-конфигурацией и поддерживают до 32 ядер.
Архитектура блочных контроллеров
Главные отличия от прошлой линейки (подробнее ниже)
- Многоядерная архитектура MCx (R5.33): в 4 раза большая производительность по сравнению с предыдущим поколением, многоядерное управление Сache и FAST Сache, многопоточное управление RAID
- Обновление FAST VP
- Синхронный Active/Active режим работы LUN
- Виртуальный Recoverpoint (vRPA)
- Поддержка HyperV ODX и SMB 3.0
Железо
Появился новый аппаратный конструктив контроллера — всё кроме флагмана использует новую платформу DPE. Из крупных изменений – другой модуль резервного питания. Батареи отказоустойчивого питания встроены в контроллер для всех моделей кроме флагмана. В старшей модели по-прежнему есть батареи, но их теперь не 2, а 4 штуки и заменяются они теперь на порядок удобнее.
Компоновка контроллеров и полок всё такая же, как и раньше (VNX8000 – исключение):
Взгляните на диски:
Теперь флеш-диски деляется на две категории: сверхбыстрые (eMLC) используется для кэша и уровневого хранения, обычные (просто MLC) – только для уровневого хранения.
Софт
Базовый функционал софта «из коробки» теперь тоже больше, но это, в целом, было ожидаемо.
Что интересно – появились новые программные фишки. Например, очень порадовал новый подход к выделению ресурсов процессора. Раньше процесс получал определённое количество ядер и работал только на них. То есть при неравных загрузках тех или иных процессов (достаточно частых для реальных систем) имела место неравномерная нагрузка на ядра. Где-то ядро могло простаивать, а где-то загрузка была близка к 100%. В новой архитектуре сделан шаг к большей виртуализации — динамическое деление ресурсов и многопоточная обработка.
Полностью переработан кэш. Раньше память делилась на 2 области: кэш на запись и кэш на чтение. Эти два буфера не пересекались. Соответственно, один делал оптимизацию записи данных на диск оптимальными блоками, а второй предсказывал чтение следующих блоков. Так вот, на новых массивах работа кэша полностью реорганизована, массивы теперь используют динамический кэш, отвечающий за обе задачи одновременно без разделения памяти на разные области. Такой подход не только позволил более эффективно использовать место в памяти, но и резко повысил производительность. На типовых нагрузках со слов производителя это очень волшебно повышает быстродействие кэша до 5 раз.
Переработан Fast Caсhe – это flash-диски, используемые как дополнительный кэш. Ему теперь отдаётся больше ресурсов процессора из-за динамического распределения ресурсов. Плюс под Fast Cache теперь отдаются более быстрые eMLC диски. В итоге разработчики смогли использовать более агрессивные алгоритмы, что делает разогрев кэша куда более быстрым. Заодно инженеры вместе с разработчиками алгоритмов классического кэша прошлись по драйверам и переписали их под модульный принцип, что также здорово подняло производительность и в разы понизило время отклика отдельного обращения.
Fully Automated Storage Tiering Virtual Pool (FAST VP). Это как раз тот самый механизм объединения различных дисков в единый «пул». Его тоже значительно переработали и теснее интегрировали с FAST cache. Кстати, гранулярность Fast VP уменьшена в 4 раза и теперь данные перемещаются кусками по 256 МБ.
Вот здесь, наверное, актуально будет вернуться к началу, где я говорил, что смешивание дисков не приводит к увеличению производительности. Вот теперь, когда мы получили возможность использовать SSD для хранения и как кэш, — можно говорить и о скорости, и об эффективности хранения и обработки данных.
Новая блочная дедупликация. Принцип старый как мир: данные бьются на блоки, одинаковые блоки хранятся один раз. Для дублирующихся блоков используются ссылки на те же блоки как в архивах. Теперь всё это очень сильно «заточено» под виртуальные среды.
На новых СХД дедупликация происходит по расписанию. Например, приложения пишут данные в пул без дедупликации в течение рабочего периода. Затем в момент уменьшения нагрузки движок СХД начинает анализ записанных данных и сжимает их за счёт удаления дубликатов. Всё это здорово согласуется с фаст-кэшем (поскольку нагрузка на дедуплицированные блоки возрастёт, а их количество закономерно уменьшится, как следствие они переедут на фаст-кэш). На практике это означает, что в фаст-кэш поместится субъективно больше данных. Это очень ускоряет работу массива. Два наиболее типичных типа нагрузки максимально выигрывающих от нового механизма:
- Однотипные виртуальные среды, например VDI.
- Множественные применения для одного набора данных.
Расчетная экономия для подобных нагрузок составит:
Новый принцип работы с дисками. ЕМС также сменило принцип работы с дисками. Ранее адрес диска жестко привязывался к его физическому расположению в полке, в новом поколении система запоминает диски по их уникальным идентификаторам, что дает возможность не привязываться больше к расположению дисков в системе. Вроде бы несущественное изменение, однако, насколько теперь упростится переезд массива на другую площадку! Ведь теперь можно не мучиться с расположением дисков в том же порядке что и раньше. И проблему несбалансированной нагрузки на back-end решить можно просто на порядки проще и быстрей: переставил диски по очереди – и готово, даже базу гасить не нужно. Да и теперь при необходимости часть данных можно просто физически выдернуть из массива и увести на время на другую площадку, такой своеобразный хот-бэкап получается, сами думаю, придумаете, зачем он может понадобиться.
Добавленая технология Permanent Sparing хорошо зарекомендовавшая себя на Hi-end системах. Помимо этого теперь не нужно выделять специальные диски под горячую замену, массив будет использовать по умолчанию максимально подходящий не занятый диск.
Есть важные изменения в принципе доступа контроллера к дискам. Изначально в mid-range системах с дисками работал один контроллер, а пути доступа других контроллеров использовались только при сбоях. При сбое том переезжал на другой контроллер. Это означало, что если какой-то массив требует полных ресурсов системы, получить он сможет даже теоретически не более 50% общих ресурсов системы — от одного контроллера. Эта проблема была частично решена в 2 прошлых линейках: появился механизм ALUA. Суть механизма: передача запросов хостов контроллеру владельцу тома через интерфейс синхронизации кэша. К сожалению, пропускная способность этого интерфейса далеко не безгранична и обращение к контроллеру владельцу тома все-равно обрабатывается быстрее. Пути стали делиться на оптимальные и неоптимальные вместо активных и пассивных. Грубо говоря, в идеальном случае — до 75% мощности массива на том. В новом поколении разработчики пошли дальше. Без изменения аппаратной структуры(!) они поменяли логику работы массива на Active-Active. Теперь оба контроллера одновременно параллельно пишут в разные области, просто блокируя свою область на время записи.
На практике, если у нас массив используется под одну задачу — можно использовать более дешевую младшую модель СХД. Да и балансировка нагрузки на путях становится куда проще. Плюс раньше при процедуре переезда LUN под управление другого контроллера были серьезные задержки в обработке внешних обращений ввода-вывода, а сейчас не будет ни того ни того.
Обновился софт для массива. Внешне интерфейс работы с массивом изменился не сильно. По моей субъективной оценке, это как был, так и остался (к счастью) самый удобный интерфейс для СХД — 99% задач делается парой кликов прямо в веб-интерфейсе. Экзотика, конечно, требует консоли.
В базовом комплекте теперь идёт ещё очень полезный новый инструмент долговременного мониторинга. Можно видеть отчёты по файловой и блочной части — куча метрик. Позволяет легко находить узкие места. Ещё один инструмент на основе этих метрик позволяет планировать расширение инфраструктуры – это чтобы администратор не считал руками, чего и сколько потребуется в следующем году.
Ещё одна очень важная вещь для виртуальных сред. Массивы по-прежнему поддерживают плотную интеграцию с системами виртуализации. Если кто не знает, VMware — это подразделение EMC (довольно самостоятельное, но подразделение). Отсюда – совместная работа программистов VMware и разработчиков СХД. Следствие — удобная бесшовная и крайне глубокая интеграция. Виртуальные машины интегрируются в интерфейс СХД (мониторинг ресурсов машин на уровне СХД), типичные нагрузки по копированию и клонированию машин можно переложить на сам массив, типовые задачи по администрированию СХД можно делать из интерфейса инфраструктуры VMware.
Как это ни странно, но аналогичные плюсы есть и для Hyper-V (поскольку EMС тесно и очень давно сотрудничает с MS — исторически сложилась работа разработчиков вместе). Почти такой же уровень глубины интеграции: общее управление, разгрузка инфраструктуры. Есть и специальные фишки для MS – например, Branch Caсhe при слабых каналах связи разгружает сетевую инфраструктуру. Да! EMC VNX – первая СХД c поддержкой SMB 3.0.
Пока всё. Вопросы можно задавать в комментарии или на почту VBolotnov@croc.ru. По стоимости под конкретные задачи могу сориентировать довольно быстро с конкретными расчётами – если нужно, запрашивайте, не проблема.
Да. Мы свою демо-систему VNX5400 в руках уже покрутили и отдали на тестирование одному из заказчиков, который планирует обновление своих СХД в этом году. В скором времени она вернется, поэтому если кому интересно пощупать реальную систему самостоятельно, можно будет приехать к нам в офис и заглянуть в EMC Solution Center. Пишите, договоримся о дате.
Автор: BoVados
