Расчёт производительности СХД: IOPS, пропускная способность и задержки для критичных приложений

Ключевые метрики производительности СХД: IOPS, пропускная способность, задержка

Производительность системы хранения данных (СХД) определяют три взаимосвязанные метрики: IOPS, пропускная способность и задержка. IOPS (Input/Output Operations Per Second) - это количество операций ввода-вывода, которое массив выполняет за секунду. Пропускная способность (throughput) - объём данных, передаваемых за ту же единицу времени, измеряется в МБ/с или ГБ/с. Задержка (latency) - время, за которое система завершает один запрос ввода-вывода, измеряется в миллисекундах или микросекундах.

Связь между метриками выражается формулой: Пропускная способность = IOPS × размер блока. Если массив выдаёт 10 000 IOPS с блоком 4 КБ, пропускная способность составит 40 МБ/с. При блоке 64 КБ те же 10 000 IOPS дадут 640 МБ/с. Выбор доминирующей метрики зависит от нагрузки: транзакционные системы требуют высоких IOPS и минимальной задержки, потоковое видео или резервное копирование - пропускной способности.

Для комплексной оценки производительности дисковых подсистем в реальных сценариях используйте готовые методики тестирования SSD, RAID и ZFS с помощью fio.

Что такое IOPS и почему это главная метрика для транзакционных систем

IOPS - ключевой показатель для систем, обрабатывающих множество мелких операций. Базы данных, почтовые серверы, VDI-фермы генерируют тысячи запросов в секунду, и каждый запрос требует чтения или записи небольшого блока данных. Производители указывают IOPS для идеальных условий: блок 4 КБ, глубина очереди 32, 100% случайный доступ. Реальные значения всегда ниже.

Различают случайные и последовательные IOPS. Случайный доступ характерен для баз данных: данные разбросаны по диску, головка HDD или контроллер SSD постоянно перемещается между несмежными областями. Последовательный доступ типичен для резервного копирования: блоки читаются или пишутся подряд. Один современный HDD (7200 RPM) выдаёт 100–200 случайных IOPS. SATA SSD обеспечивает 10 000–100 000 случайных IOPS. NVMe-накопитель достигает 500 000 и более IOPS на операциях чтения.

При оценке IOPS учитывайте соотношение чтения и записи. Типичный профиль OLTP-базы данных: 70% чтения, 30% записи. Запись всегда дороже чтения, особенно в RAID-массивах с избыточностью. Практические аспекты настройки кэширования и tiering для оптимизации IOPS разобраны в руководстве по настройке производительности HP-массивов.

Пропускная способность: когда важны мегабайты в секунду

Пропускная способность выходит на первый план при работе с большими файлами: видео-продакшен, геофизические данные, резервное копирование, потоковая аналитика. В этих сценариях количество операций невелико, но каждая передаёт крупный блок. Расчёт прост: 1000 IOPS с блоком 64 КБ дают 62,5 МБ/с. 1000 IOPS с блоком 1 МБ - уже 1000 МБ/с.

Пропускная способность ограничена интерфейсами подключения. Один канал SAS 12 Гбит/с обеспечивает около 1200 МБ/с. Четыре канала SAS - до 4800 МБ/с. 32-гигабитный Fibre Channel даёт примерно 3200 МБ/с на порт. iSCSI через 10GbE - около 1250 МБ/с. Суммарная пропускная способность массива не может превысить суммарную пропускную способность всех интерфейсов контроллера. Узким местом часто становится не диски, а каналы связи между сервером и СХД.

Задержка (latency): скрытый убийца производительности

Задержка - сумма времени обработки запроса накопителем и времени ожидания в очереди контроллера. Для синхронных операций, где приложение ждёт подтверждения записи перед отправкой следующего запроса, задержка напрямую определяет время отклика. Рост задержки с 1 мс до 10 мс снижает производительность однопоточной транзакционной системы в 10 раз.

Целевые значения задержки для разных нагрузок:

• Высокопроизводительные базы данных (Oracle, PostgreSQL, 1С при интенсивной работе): менее 1 мс.
• Средненагруженные СУБД и виртуальные машины общего назначения: 3–5 мс.
• Файловые серверы, архивное хранение: 5–10 мс.
• Значения выше 20 мс указывают на проблему, требующую немедленной диагностики.

Закон Литтла связывает задержку, IOPS и глубину очереди: Количество запросов в системе = IOPS × задержка. При 1000 IOPS и задержке 5 мс в очереди одновременно находится 5 запросов. Рост задержки при неизменных IOPS означает увеличение очереди - верный признак перегрузки дисков или контроллера. Для быстрой диагностики узких мест на уровне операционной системы воспользуйтесь руководством по мониторингу CPU, памяти и дисковой подсистемы в Linux.

Методика сбора требований к производительности: от приложения к цифрам

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

1. Определите тип нагрузки: база данных, почтовый сервер, файловый сервер, VDI.
2. Соберите данные о пиковых операциях: транзакции в секунду, количество одновременных пользователей, объём данных, проходящих через систему в часы максимальной активности.
3. Оцените соотношение чтения и записи, средний размер блока.
4. Примените формулы для перевода бизнес-показателей в IOPS и пропускную способность.

Профили нагрузки: базы данных, виртуальные машины, файловые серверы

Каждый тип приложения формирует характерный паттерн ввода-вывода. Понимание паттерна позволяет точно рассчитать требования без длительного тестирования.

OLTP-базы данных (1С, PostgreSQL, MySQL/InnoDB) генерируют множество мелких случайных операций. Типичное соотношение чтения/записи - 70/30, размер блока - 8 КБ. Одна транзакция создаёт от 5 до 20 операций ввода-вывода в зависимости от сложности запросов и эффективности кэширования. Пиковые нагрузки приходятся на рабочее время, возможны всплески при формировании отчётов.

OLAP-системы (аналитические хранилища, ClickHouse) читают данные крупными последовательными блоками по 256 КБ – 1 МБ. Запись обычно пакетная, соотношение чтения/записи - 90/10 или 95/5. Ключевая метрика - пропускная способность, а не IOPS.

VDI-фермы создают два типа нагрузки: boot storm при массовом включении виртуальных машин утром (90% чтения, 10% записи, блок 4–16 КБ) и steady state в течение рабочего дня (смешанная нагрузка, 60/40 чтение/запись). Boot storm - самый жёсткий тест для СХД: сотни машин одновременно читают загрузочные образы.

Файловые серверы демонстрируют смешанный профиль. Офисные документы - мелкие случайные операции. Медиафайлы и резервные копии - крупные последовательные. Усреднённый профиль: 80/20 чтение/запись, блок от 4 КБ до 64 КБ.

Инструменты для измерения текущей нагрузки: iostat, fio, диспетчер задач

Если система уже работает, не гадайте - измеряйте. iostat -x 1 показывает детальную статистику по каждому диску в реальном времени. Ключевые поля вывода:

• r/s, w/s - чтений и записей в секунду (IOPS).
• rkB/s, wkB/s - килобайт прочитано и записано в секунду.
• await - среднее время ожидания завершения запроса (задержка), включает время в очереди и время обработки.
• %util - утилизация устройства. Значение близкое к 100% указывает на перегрузку.

Для синтетических тестов используйте fio - гибкий инструмент, эмулирующий любые профили нагрузки. Пример команды для теста случайного чтения блоками 4 КБ с глубиной очереди 32:

fio --name=randread --ioengine=libaio --direct=1 --bs=4k --rw=randread --numjobs=4 --iodepth=32 --runtime=60 --time_based --filename=/dev/sdb

Синтетические тесты полезны для сравнения конфигураций, но не отражают реальную картину полностью. Реальная нагрузка всегда сложнее лабораторной. Пошаговые методики нагрузочного тестирования серверов и кластеров с примерами команд для stress, sysbench и Apache Benchmark собраны в отдельном практическом руководстве.

Расчёт требуемой производительности: формулы и практические примеры

Исходная формула для расчёта: Общие IOPS = количество операций в секунду × IOPS на операцию × коэффициент пиковой нагрузки. Коэффициент пиковой нагрузки (1.2–1.5) страхует от всплесков активности. Пропускная способность вычисляется как произведение общих IOPS на средний размер блока.

Пример для OLTP-базы данных: 1000 транзакций в секунду, каждая генерирует 10 IOPS (70% чтения, 30% записи), блок 8 КБ. Общие IOPS = 1000 × 10 × 1.3 = 13 000 IOPS. Пропускная способность = 13 000 × 8 КБ ≈ 104 МБ/с. Это требования к массиву без учёта избыточности.

Учет RAID и типа дисков в расчетах

RAID-массивы с избыточностью накладывают штраф на запись (write penalty). Каждая запись в RAID 5 требует двух чтений и двух записей на диски (чтение старых данных и чётности, запись новых). Штрафы для разных уровней RAID:

Реальные значения IOPS для распространённых носителей (случайный доступ, блок 4 КБ):

• HDD 7200 RPM: 100–200 IOPS.
• HDD 10 000 RPM: 150–250 IOPS.
• HDD 15 000 RPM: 200–350 IOPS.
• SATA SSD: 10 000–100 000 IOPS (зависит от модели и глубины очереди).
• NVMe SSD: 100 000–1 000 000 IOPS.

Для массива из 8 HDD в RAID 10 (эффективно 4 диска для записи, 8 для чтения) с нагрузкой 10 000 IOPS чтения и 3000 IOPS записи: эффективные IOPS на диск по записи = (10 000 + 2 × 3000) / 8 = 2000 IOPS. Это превышает возможности HDD (100–200 IOPS). Вывод: HDD не подходят, нужны SSD.

Пример расчета СХД для базы данных 1С

Исходные данные: 100 активных пользователей, 200 транзакций в секунду, каждая транзакция - 15 IOPS (80% чтение, 20% запись), блок 8 КБ. Коэффициент пиковой нагрузки - 1.3.

Общие IOPS = 200 × 15 × 1.3 = 3900 IOPS. Из них чтения: 3900 × 0.8 = 3120 IOPS, записи: 3900 × 0.2 = 780 IOPS. Пропускная способность = 3900 × 8 КБ ≈ 31 МБ/с.

Выбираем RAID 10 из SSD. Для расчёта количества дисков используем штраф на запись: эффективные IOPS = (3120 + 2 × 780) / N = 4680 / N. При использовании SATA SSD с реальной производительностью 20 000 случайных IOPS на диск: N = 4680 / 20 000 = 0.23. Одного диска хватит по IOPS. Но для отказоустойчивости RAID 10 требует минимум 4 диска. Итоговая конфигурация: 4 SATA SSD в RAID 10 с запасом по производительности более 10 раз. Задержка при такой конфигурации не превысит 1 мс.

Анализ задержек и поиск узких мест

Задержка растёт нелинейно с увеличением нагрузки. Пока глубина очереди мала, задержка определяется скоростью носителя. Когда запросы начинают накапливаться, время ожидания в очереди резко увеличивается. Точка перегиба наступает при утилизации диска около 70–80%.

Диагностика через iostat -x: поле await показывает среднюю задержку. Если await превышает целевые значения (5 мс для общих нагрузок, 1 мс для высокопроизводительных БД), а %util близок к 100%, диск перегружен. Если await высокий, а %util низкий - проблема в сети хранения или контроллере.

Типичные узкие места и способы их устранения:

• Недостаток IOPS у дисков: добавить диски в массив, заменить HDD на SSD, перейти на NVMe.
• Перегрузка контроллера: распределить нагрузку между контроллерами (Active-Active конфигурация), увеличить кэш контроллера.
• Проблемы с сетью хранения: проверить заполнение буферов коммутаторов, увеличить количество ISL-линков, перейти на более скоростные интерфейсы.
• Неоптимальная конфигурация RAID: RAID 5 для нагрузки с интенсивной записью даёт четырёхкратный штраф, переход на RAID 10 снижает штраф до двух.

Мониторинг производительности СХД: на что смотреть в первую очередь

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

• IOPS на диск - сравнение с паспортными значениями. Устойчивое приближение к пределу требует добавления дисков.
• Средняя задержка - порог предупреждения: 5 мс, порог критической тревоги: 10 мс.
• Максимальная задержка - единичные выбросы до 50 мс допустимы, регулярные пики выше 100 мс указывают на проблемы.
• Глубина очереди - стабильное значение выше 10–15 сигнализирует о перегрузке.
• Пропускная способность - сравнение с пропускной способностью интерфейсов. Заполнение канала более чем на 80% требует расширения.

Инструменты мониторинга зависят от производителя СХД: HPE System Management Homepage и iLO для HP-массивов, Dell OpenManage для Dell EMC, проприетарные решения для NetApp и Pure Storage. На уровне операционной системы универсальными остаются iostat, sar, dstat.

Проектирование СХД с запасом: как избежать проблем в будущем

Запас производительности - не роскошь, а страховка от пиковых нагрузок и роста данных. Коэффициент запаса зависит от критичности системы: для внутренних приложений достаточно 20%, для клиентских сервисов - 50%, для систем реального времени - 100% и более.

Горизонтальное масштабирование (scale-out) предполагает добавление дисковых полок или узлов кластера. Современные программно-определяемые СХД (Ceph, VMware vSAN) позволяют наращивать производительность линейно с добавлением узлов. Вертикальное масштабирование (scale-up) - замена дисков на более быстрые в существующих полках, апгрейд контроллеров.

Типичные ошибки при проектировании:

• Экономия на контроллерах: один контроллер вместо двух в Active-Active. При выходе из строя производительность падает вдвое или до нуля.
• Игнорирование boot storm в VDI: утренний запуск 100 виртуальных машин создаёт пиковую нагрузку, в 3–5 раз превышающую среднюю.
• Расчёт только по средним значениям: средняя нагрузка 1000 IOPS при пиках 5000 IOPS приводит к деградации в часы максимальной активности.
• Использование RAID 5 на медленных дисках для нагрузки с интенсивной записью: штраф 4 плюс низкая базовая производительность HDD дают неприемлемые задержки.

Планируйте рост на 2–3 года вперёд. Учитывайте не только увеличение объёма данных, но и рост числа пользователей, внедрение новых приложений, изменение характера нагрузки. Методологии проектирования высоконагруженных систем с чек-листами и инструментами диагностики подробно разобраны в руководстве по архитектуре высоконагруженных систем.