All-Flash SAN и OLTP: первое боевое внедрение вместо гибридного массива

Эту историю мы начали наблюдать примерно в феврале, а закончили только сейчас - когда стало понятно, что пилот перерастает во что-то постоянное и стоит об этом написать.

Клиент - торговая компания с несколькими сотнями транзакций в минуту в часы пик. Основная нагрузка: SQL Server на VMware vSphere, под ним классический гибридный SAN - несколько полок с SSD в качестве кеша и SATA-дисками в основном объёме. Схема рабочая, проверенная, недорогая. Работала несколько лет без вопросов.

Вопросы появились, когда бизнес вырос.

Что пошло не так

Гибридный SAN справлялся пока рабочий набор данных влезал в SSD-кеш. Когда объём транзакционных таблиц вырос и кеш перестал покрывать горячую часть - latency начала ползти вверх. Не катастрофически, но заметно: средняя задержка по I/O стала держаться в районе 8 мс, а в пиковые часы и выше.

8 мс звучит немного, но для OLTP это другой мир. SQL-запросы, которые раньше укладывались в 50-100 мс, начали растягиваться на 300-500 мс. SLA с клиентами у компании был завязан на время отклика приложения, и они начали его нарушать. Не постоянно, но регулярно - именно в те часы, когда нагрузка максимальная, то есть именно тогда, когда это важнее всего.

Первая реакция была ожидаемой: добавить SSD-кеша. Добавили. Помогло на несколько месяцев - рабочий набор снова влез, latency вернулась в норму. Потом история повторилась.

Стало понятно, что это не проблема размера кеша, а проблема архитектуры.

Почему гибрид упирается

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

SSD-кеш снижает среднюю latency, но не устраняет хвостовые задержки. А именно хвост (99-й перцентиль, иногда даже 95-й) убивает SLA в OLTP.

Пилот all-flash

Договорились с поставщиком на месячный пилот с полкой Pure Storage FlashArray. Не потому что именно Pure - просто у них была готовая демо-единица, и условия пилота оказались разумными. Параллельно смотрели в сторону EMC XtremIO, но до живого железа там не дошли - слишком долго согласовывался доступ.

Схема пилота была простой: перенести несколько самых нагруженных баз данных на all-flash хранилище, оставить остальное на гибридном SAN, сравнить метрики за две недели.

Перенос прошёл без сюрпризов - VMware Storage vMotion мигрировал VMDK без остановки. Ночью перемигрировали, утром посмотрели на метрики.

Разница оказалась неприличной.

Средняя latency упала с 8 мс до 0.3 мс. Не 8 → 4, не 8 → 2 - именно до 0.3. 99-й перцентиль, который раньше уходил за 20-30 мс в пики, теперь держался в районе 1-2 мс. SQL-запросы, которые раньше плавали от 50 до 500 мс в зависимости от нагрузки, выровнялись - почти все укладываются в 80-100 мс независимо от времени суток.

SLA перестали нарушаться с первого дня пилота.

Что мы зафиксировали по ходу

Несколько наблюдений, которые оказались неочевидными.

Первое - дедупликация работает. Pure Storage честно показывает в интерфейсе коэффициент дедупликации и компрессии. На транзакционных базах SQL Server с типичными корпоративными данными суммарный коэффициент вышел примерно 3:1 - то есть физически занимаемое место в три раза меньше заявленного объёма данных. Это важно для экономики решения: реальная цена гигабайта эффективного хранилища ощутимо ниже той, что кажется по прайсу.

Второе - контроллер не стал узким местом. Мы ожидали, что при переходе с медленного хранилища к быстрому узким местом станет что-то другое - FC-коммутатор, HBA, контроллер VMware. Ничего подобного: контроллеры флеша успевают обслуживать то, что вылезало из очереди к SATA, и весь стек держит темп.

Третье - Pure Storage управляется неожиданно просто. Это субъективно, но интерфейс массива разительно контрастирует с тем, к чему привыкли на классических EMC/NetApp - никаких LUN-менеджеров с двадцатью вложенными меню. Purity OS выглядит как продукт, который делали люди, которым самим приходилось с этим работать.

Четвёртое - питание. All-flash полка потребляет заметно меньше электричества, чем сопоставимый по ёмкости гибридный массив с несколькими десятками шпиндельных дисков. Это не главный аргумент, но в серверной с ограниченной мощностью стойки - приятный бонус.

Где цена всё ещё кусается

Честно: all-flash стоит дороже гибрида на тот же сырой объём. Не вдвое, но заметно. Для задач, где latency не критична - архивные данные, резервные копии, файловые шары - смысла переплачивать нет.

Для OLTP-нагрузки, где промах кеша стоит задержки в десятки миллисекунд и нарушения SLA - экономика уже другая. Посчитали вместе с клиентом: стоимость нарушений SLA за полгода превышает разницу в цене между гибридом и флешем на три года вперёд. Это не маркетинговый расчёт - это реальные штрафные санкции из договоров с их клиентами.

Что дальше

Решение о переходе с пилота на постоянную эксплуатацию ещё не принято - идёт согласование бюджета. Пока флеш-полка работает как арендованная. Но по факту переносить назад на гибридный SAN никто не хочет - слишком разительная разница видна на дашборде каждый день.

Параллельно смотрим на то, что происходит с остальными LUN на гибридном массиве - там осталась часть менее критичных баз. Вопрос в том, есть ли смысл в смешанной архитектуре для этого клиента или проще стандартизироваться на одном типе хранилища. Ответ неочевиден.

Инфраструктурные задачи такого рода ведём в рамках managed-сопровождения.