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 теперь стал тривиальным в том смысле, что смотреть особо не на что. Это непривычно: раньше дисковая статистика была первым местом, куда смотришь при жалобах. Теперь придётся искать проблемы в других слоях.