SSD в серверной: первый опыт с enterprise-накопителями и подводными камнями

Разговор про SSD в серверной долгое время заканчивался одинаково: дорого, ресурс неизвестен, consumer-шники не подходят, enterprise - только для избранных с бюджетом. В начале этого года картина начала меняться: Intel S3700 и Samsung 840 Pro появились по ценам, с которыми уже можно разговаривать не только с банками.

Мы взяли их на один из клиентских проектов на сопровождении - производственная компания, 1С в клиент-серверном режиме на MS SQL, несколько десятков активных пользователей, и хроническая жалоба на скорость проведения документов в конце месяца.

Откуда взялась идея

Профиль нагрузки у этой базы - типичная OLTP-жизнь: много мелких транзакций, активная запись в лог транзакций, периодические тяжёлые запросы по отчётам. Мы давно смотрели на дисковую подсистему как на узкое место. RAID 10 из SAS-дисков справлялся, но в пиковые периоды IOPS буквально заканчивались - это было видно в счётчиках perfmon и в ожиданиях SQL Server: PAGEIOLATCH_EX и WRITELOG лезли наверх.

Классический ответ - больше шпинделей, расширить RAID. Но стойка у клиента небольшая, слотов под диски почти нет. Вот тут и возникло предложение попробовать SSD.

Выбор накопителей

Брать consumer-шники типа Samsung 840 (не Pro) в сервер - сомнительная затея: они не гарантируют поведение при внезапном обесточивании, и у них нет capacitor-защиты кэша записи. Для логов транзакций это критично.

Остановились на двух вариантах для тестирования:

• Intel S3700 Series - специально спроектирован для серверной нагрузки, есть power-loss protection, заявленная равномерность latency. Дорогой, но честный.
• Samsung 840 Pro - MLC NAND, более доступный, тоже с защитой кэша. Чуть хуже по endurance, но для нашего объёма записи должно хватить с запасом.

Intel пошёл под лог транзакций SQL Server (самый «горячий» паттерн - последовательная запись, но критичная к задержкам). Samsung - под данные tempdb и горячий tier основной базы.

Что выяснилось при подготовке

И вот тут началось то, чего не было в маркетинговых брошюрах.

Выравнивание разделов. Оба диска пришли неразмеченными, и первый импульс - разметить как обычно, через diskpart. Но у SSD есть физический размер блока (erase block), и если раздел выровнен неправильно, каждая запись превращается в операцию read-modify-write на уровне контроллера накопителя. Производительность падает, износ растёт. Windows Server 2008 R2 при разметке через стандартный мастер ставит смещение 1 МБ - это правильно для современных дисков. Но мы проверили через fsutil fsinfo ntfsinfo и wmic partition get - убедились, что Starting Offset делится на размер erase block без остатка. Лучше проверить явно, чем доверять дефолтам.

Wear leveling и мониторинг ресурса. У обоих дисков есть SMART-атрибуты для отслеживания износа: у Intel - Media Wearout Indicator (начинается с 100, снижается), у Samsung - Total bytes written в сыром виде. Стандартный SMART-мониторинг через CrystalDiskInfo на десктопах это покажет, но в серверном окружении нужно было встроить в Zabbix. Написали скрипт на PowerShell, который читает SMART через smartmontools и кладёт значения в пользовательские параметры Zabbix. Теперь видим wear indicator в дашборде рядом с температурой и счётчиками I/O.

Прошивки. Intel S3700 при первом подключении показал firmware версии, которая была не последней. Обновление прошивки на работающем диске - это отдельный квест: нужен загрузочный образ от Intel, холодный старт, и желательно сделать это до того, как на диск легли данные. Сделали на этапе подготовки, благо успели.

Результаты

После переноса лога транзакций на Intel S3700 счётчики SQL Server изменились заметно. WRITELOG-ожидания упали практически до нуля - последовательная запись в лог стала настолько быстрой, что SQL Server перестал на ней тормозить. PAGEIOLATCH_EX снизились по tempdb после переноса на Samsung. Общий IOPS по системе в пике вырос примерно в 10 раз по сравнению с тем, что давал RAID на SAS.

Конец месяца, закрытие периода - пользователи отметили разницу без подсказок с нашей стороны. Документы стали проводиться заметно быстрее.

Что остаётся открытым

Мониторинг износа пока работает неделю - слишком мало, чтобы делать выводы о реальном темпе расходования ресурса. Производитель заявляет endurance в TBW, мы посчитали по паттерну записи, что при текущей нагрузке запас большой, - но это расчёт, а не наблюдение. Будем смотреть динамику несколько месяцев.

Ещё открытый вопрос - что делать при выходе SSD из строя быстрее ожидаемого. С HDD всё понятно: SMART предупреждает, диск деградирует, есть время на замену. У SSD картина может быть резче: ресурс кончился - диск перешёл в read-only, или вообще пропал. Настроили алерты по wear indicator с запасом, так что теоретически успеем. Но практика это покажет.

Пока - первый результат хороший. Задержки убрали, железо работает. Дальше - наблюдение.