Каждый охотник желает знать где сидит... IOPS

Стандартная проблема владельцев бюджетных серверов не в том, что серверу хронически не хватает вычислительной мощности (а самим владельцам — денег). Тут ведь как в больнице: прежде чем лечить, надо поставить диагноз. Если не умеешь и не хочешь пользоваться простыми и бесплатными инструментами оценки нагрузки на подсистемы сервера — покупаешь сервер практически вслепую. При поверхностном подходе, что дешевый сервер, что дорогой — с равной вероятностью стреляют в молоко. Богатый погорюет и купит второй, бедному остается пенять на себя.

При выборе сервера недооценка роли дисковой подсистемы в многопользовательских приложениях — куда более частая ошибка, чем недобор процессорной мощности или оперативной памяти. Для бюджетных серверов в особенности. Получить оценку нагрузки на текущий сервер и его подсистему ввода/вывода просто — с помощью доступных, встроенных в Windows утилит, было бы желание оптимизировать сервер еще до его покупки.

Для массовых приложений, работающих с базами данных (БД) — таких как 1С, и емкость дисков, и их потоковая производительность (в MBps), и тип интерфейса (SAS или SATA) — параметры второстепенные, легко определяемые заранее (тем же объемом БД). Ключевым параметром дисковой подсистемы для работы с БД является ее способность обработать большое количество относительно мелких операций ввода/вывода — IOPS (Input Output operations Per Second). Именно IOPS на запись и чтение характеризуют способность дисков успевать за запросами приложения. В данном материале мы ограничимся недорогими реализациями, оценив их возможности по стандартному тесту IOMeter.

Сразу оговоримся, что сравнивать аппаратный RAID-контроллер и софт-RAID мы не будем. Несмотря на приемлемую производительность программного массива на SSD, говорить о высокой надежности и управляемости софт-RAID в целом не приходится (до 90% обращений в сервис по вопросам разрушения RAID-массива приходится на софт-RAID с HDD). Недорогой сервер, как правило, достается в руки начинающим администраторам, является единственным в компании и содержит критически важные данные и приложения — поэтому на контроллере лучше не экономить, в конечном счете это будет дешевле. Серверы с БД на программном RAID — удел крупных сетевых компаний с хорошим подменным фондом, ежедневным централизованным бэкапом и большим штатом фланирующих системных администраторов.

Исходим из того, что в сервере начального уровня установлен пусть и недорогой, но аппаратный RAID-контроллер cо своим процессором и кэш-памятью. Он нужен для:

— разгрузки центрального процессора, шин ввода/вывода и оперативной памяти;

— создания логических томов из разных типов дисков, разного объема и уровня RAID;

— прозрачности построения и управления массивами;

— обеспечения достаточного уровня устойчивости к сбоям;

— минимизации времени реконструкции RAID’а в случае сбоя диска.

Для тестов мы взяли Adaptec 6405E, демократичный по цене, с хорошим и простым управляющим ПО. Исключив по соображениям стоимости решения комбинации с дисками SAS HDD, мы сталкивали SSD и SATA HDD в трех сценариях:

• «консервативный» 2 SATA HDD в RAID 1

• «cмешанный» 1 SSD + 2 SATA HDD в Hybrid RAID
  

• «радикальный» 2 SSD в RAID 1

В качестве SSD использовались накопители Intel SSD 320-й серии {SSDSA2CW080G310} 80GB — на такой диск помещается база данных 1С небольшой компании на 5-15 пользователей, занимая в среднем 10-25% его емкости. HDD были представлены 2TB Hitachi Ultrastar A7K2000 {HUA722010CLA330} 7200 rpm.

Моделировалась следующая постановка:

1. Небольшая БД объемом 0,5-4GB (к примеру, под «1С:Предприятие 8.2 Бухгалтерский учет для Украины»);

2. Чувствительная к быстродействию дисковой подсистемы в IOPS, БД располагается на максимально быстром RAID-томе;

3. Операционная система, приложения и т.д. располагаются на другом RAID-томе.

Исключая споры, какие именно подсистемы и операции использовать в тестах под 1С, как наполнять БД, «и вообще у нас другая конфигурация», мы тестировали дисковую подсистему с помощью IOMeter. Да, это синтетический тест, в реальной работе столь стабильную и регулярную нагрузку никакие пользователи не создадут. Но результат IOMeter для баз данных (68% read / 32% write) очень хорошо коррелирует с поведением системы 1С при пиковых нагрузках (вроде перепроведения периода или закрытия месяца), утилита проста в использовании и доступна всем. Перепроверяйте.

Вводились ограничения: длина очереди запросов к диску — от 1 до 8 (типичные показатели для класса задач), размер блока данных в 4 и 8 KB (наиболее типичны для БД). Кэш на запись в HDD и SSD отключался в целях безопасности данных.

На первой и второй диаграмме — результат сравнения быстродействия в IOPS для обычного RAID 1 на 2-х HDD и гибридного RAID 1, в котором используется часть емкости SSD (25% оставили неразмеченной для over provisioning) и небольшая часть емкости HDD — в итоге получаем том ёмкостью 60GB под данные БД. Первая диаграмма — с 10% заполнения тома в 60GB, вторя с 50% заполнения тома.

Тест 1. Диаграмма 1. (10% заполнения, глубина очереди 4, блоки 4KB и 8KB, без кэш)

Тест 2. Диаграмма 2. (50% заполнения, глубина очереди 4, блоки 4KB и 8KB, без кэш)

Хорошо заметно, что:
а) при 10% заполнении тома гибридный RAID 1 на SSD+HDD показывает прирост производительности почти в 2,9 раза относительно RAID 1 на HDD+HDD;
б) при 50% заполнении тома гибридный RAID 1 на SSD+HDD показывает прирост производительности почти в 2,5 раза относительно RAID 1 на HDD+HDD.

Показательна Диаграмма 3, где отображена зависимость производительности классического тома RAID 1 на HDD+HDD и гибридного тома RAID 1 на SSD+HDD от длины очереди запросов к дискам.

Тест 3. Диаграмма 3. (50% заполнения, глубина очереди 1-2-4-8, блоки 4KB)

По статистике около 80% времени на малых серверах длина очереди запросов к дискам не превышает 2. Другими словами, данный график демонстрирует «реактивность» отклика системы при типовых пользовательских, а не пиковых нагрузках.

Завершает тест Диаграмма 4 с данными производительности в IOPS томов RAID 1 «консервативого» (HDD+HDD), «смешанного» (SSD+HDD) и «радикального» (SSD+SSD).

Тест 4. Диаграмма 4. (50% заполнения, глубина очереди 4, блоки 4KB и 8KB)

То, что производительность RAID 1 на SSD+SSD выше классического RAID 1 на HDD+HDD в терминах IOPS в 12-15 раз — вряд ли для кого-то новость. Отрыв RAID 1 на SSD+SSD от гибридного RAID 1 на SSD+HDD в IOPS в 5-6 раз тоже существенен. Вопрос лишь в «цене на билет»...

Разница в цене между бюджетным сервером с дисковой подсистемой RAID 1 на HDD+HDD и гибридным RAID 1 на SSD + 2 HDD — на стоимость SSD ($150 в нашем случае). Оснащение сервера аппаратным контроллером уровня Adaptec 6405E обойдется в $280. Добавление SSD в классический (HDD+HDD) RAID-массив и доведение его до гибридного обойдется в 10-15% стоимости сервера. При этом прирост производительности самого медленного компонента сервера — дисковой подсистемы — составит порядка 2,5 раз в IOPS. Интересно?

Наиболее производительный вариант сервера с RAID 1 на SSD+SSD плох только тем, что к нему неизбежно придется добавить RAID 1 на HDD+HDD — для размещения на нем операционной системы, приложений, ежедневных архивных копий. Переход к дисковой подсистеме (SSD+SSD) + (HDD+HDD) от традиционной пары HDD+HDD добавит к цене сервера 20-25% стоимости сервера — в обмен на 12-15 кратный прирост производительности дисковой подсистемы в IOPS.

Как в сказке про белого бычка, вернемся к началу. Чтобы понять, какой дисковой подсистемы достаточно серверу под имеющиеся задачи, требуется анализ нагрузки: нужны MBps или IOPS, сколько, на чтение или на запись, какова длина очереди запросов, моментальная и средняя? Вполне может оказаться, что даже на пиках нагрузки будет достаточно классического RAID 1 на HDD+HDD с его физическими 80-100 IOPS на запись и 200-240 IOPS на чтение. Пользователям с повышенными требованиями подойдёт гибридный RAID с его впечатляющими 12-16К IOPS по чтению и пристойными 300-400 IOPS на запись. Если же нагрузка будет требовать 18-32K IOPS на чтение или 600-4K IOPS на запись в режиме БД — то это прямой сигнал к переходу к более затратным решениям: массивам из SSD или схемам с SSD-кэшированием. Иначе охотник — и не охотник вовсе, а экстрим-турист.