ADG Оставить заявку
Блог Инфраструктура 4 мин чтения

All-flash СХД у финансового клиента: latency упала с 12 мс до 0.3 мс, а TCO за три года сопоставим с гибридным SAN

Внедряем первый all-flash массив у финансового клиента под 1С и SQL Server. Latency рухнула на два порядка. Считаем TCO за три года и сравниваем с гибридным SAN.

Контекст момента

All-flash массивы в 2016 году снижаются в цене до уровня, доступного для среднего бизнеса

Год назад разговор про all-flash СХД у среднего бизнеса обычно заканчивался на прайс-листе. Сейчас - нет. Цены на SLC и MLC NAND упали достаточно, чтобы разговор стал предметным: несколько вендоров выпустили массивы для сегмента ниже enterprise-флагманов, и цифры в коммерческих предложениях перестали вызывать острую физическую боль.

У финансового клиента на сопровождении сложилась типичная картина: гибридный SAN с тиерингом, там перемешаны SAS 15K и SSD-кеш. Основная нагрузка - 1С Предприятие 8.3 на нескольких серверах и SQL Server с транзакционными базами. Latency на дисковые операции держалась в районе 10-14 мс в часы пик. Для 1С это ощущалось: пользователи жаловались на тормоза при проведении документов, и часть проблем вела именно в хранилище.

Что мы мерили до замены

Перед принятием решения несколько недель снимали метрики с хоста и с самого массива. Инструментарий простой: перфмон на Windows-хостах по счётчикам LogicalDisk\Avg. Disk sec/Read и Write, на vSphere - стандартная статистика латентности из vCenter.

Картина в часы нагрузки (утро, конец месяца):

  • Средняя latency read/write: 10-14 мс по хостам SQL Server, в пике до 18-20 мс.
  • IOPS: реально выходило около 3-4 тысяч на весь массив, дальше очередь росла.
  • Тиеринг: SSD-кеш в гибридном массиве помогал, но объём горячих данных рос быстрее, чем вмещал кеш. Алгоритм тиеринга гонял данные между уровнями, добавляя собственный overhead.

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

Выбор и установка

Остановились на массиве среднего уровня от одного из вендоров с чистым all-flash профилем без механических дисков вообще - не называем, чтобы не звучало как реклама. Ключевые параметры: двойной контроллер, inline-дедупликация и компрессия, iSCSI + FC, объём под наши рабочие данные с запасом.

Миграцию делали через VMware Storage vMotion - живой перенос VMDK с гибридного массива на новый без остановки ВМ. Процесс небыстрый (терабайты), но downtime - ноль. Параллельно настроили iSCSI-пути с multipath по схеме, которую мы уже отработали раньше на других хостах. После переноса последней ВМ гибридный массив освободился и ждёт решения о судьбе.

Что получилось с latency

После переноса сняли те же метрики. Результат несколько обескуражил - в хорошем смысле:

  • Средняя latency read: около 0.2-0.4 мс. В пике - не выходит за 0.8 мс.
  • Write latency: примерно столько же - 0.3-0.5 мс, inline-write на контроллере без ротационных задержек.
  • IOPS: массив спокойно держит 20-25 тысяч, нагрузка от 1С и SQL туда даже не упирается.

Разница с 12 мс до 0.3 мс - это не проценты, это другой порядок. Пользователи 1С заметили сами, без анонса: «что-то открывается быстрее». В конце месяца, когда идёт массовое закрытие документов - нагрузка была, очереди к диску - не было.

По SQL Server: планы запросов не изменились, но время выполнения ряда OLTP-запросов сократилось. Это именно I/O-компонент: там, где раньше execution plan упирался в физические чтения, теперь это исчезает из статистики как значимый фактор.

Экономика: зачем вообще считать TCO

Первая реакция на прайс all-flash массива - «дорого». Это правда на момент покупки. Но если считать не цену закупки, а стоимость владения за три года, картина другая.

Гибридный SAN за три года: начальная стоимость меньше, но туда идут замены дисков (15K SAS ходят меньше flash по MTTF при интенсивной нагрузке), возможная докупка полок под рост данных, электричество (шпиндели жрут больше), охлаждение.

All-flash за три года: выше начальная цена, ниже операционные расходы. Нет шпинделей - нет расходных компонентов с механическим износом. Inline-дедупликация и компрессия дают реальный коэффициент на финансовых данных (SQL-базы с транзакционными записями сжимаются неплохо). Эффективная ёмкость после компрессии оказалась существенно больше сырой.

Точные цифры клиентские, не наши. Но по нашим расчётам разрыв в TCO за три года между гибридным и all-flash оказался заметно меньше, чем разрыв в цене закупки. Для финансовой организации, где latency напрямую влияет на операционный процесс, аргумент стал достаточным.

Что осталось не решённым

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

Мониторинг latency теперь стал тривиальным в том смысле, что смотреть особо не на что. Это непривычно: раньше дисковая статистика была первым местом, куда смотришь при жалобах. Теперь придётся искать проблемы в других слоях.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.