Системы хранения данных считаются классическим «узким местом» на серверах. Поэтому производители накопителей регулярно предлагают рынку новые технологии для увеличения скорости работы дисков, роста их объема и надежности. Но такой подход приводит к появлению других проблем. Например, к тому, что механизмы ядра Linux уже не могут справиться с обслуживанием скоростных накопителей.
Современные релизы Linux позволяют использовать специальный софт, который получил название «планировщики для блочных устройств». Их работа основана на новом способе передачи запросов – Multiqueue Block Layer (или BLK-MQ). Подобные системы работают и в ЦОД провайдера timeweb.cloud, чтобы давать доступ клиентам к имеющимся ресурсам без лимитов, иногда появляющихся из-за несовершенства программного обеспечения.
Теперь подробнее. Классический подход к обслуживанию дисковой подсистемы включает запросы к драйверам двух типов: с очередью и без нее. Первый вариант предполагает исполнение активных задач в общей для всех процессов очереди. Чтобы сделать систему более управляемой, разработчики прибегают к планировщикам с функцией «перестановки запросов» с целью ускорить конкретные процессы, но при условии, что остальные будут неизбежно тормозиться.
Причем образовавшаяся очередь так и остается «узким местом» для операционной системы, потому что время завершения всех поставленных в нее задач так или иначе остается неизменным. Поэтому ряд специалистов решает проблему отправкой запросов напрямую в драйверы устройств. Отчасти такой подход помогает, ведь он позволяет избежать общей очереди. Но при активной эксплуатации внутри драйверов образуются свои очереди (система характерна для виртуальных машин).
Решение появилось в 2013 году – это BLK-MQ, или Multiqueue Block Layer. Запросы сначала попадают в стандартную программную очередь, количество которых равно числу ядер серверного процессора. Последовательно они попадают в очередь отправки, их в зависимости от драйвера устройства может быть от 1 до 2048. Планировщик раскидывает запросы во все свободные потоки без жесткой привязки к конкретной очереди.
Вернемся к стандартным решениям. В большей части дистрибутивов Linux обычно интегрированы три планировщика – NOOP, CFQ и DEADLINE. Первый из них получил название от сокращения фразы «No Operation». Он выполняет создание простых FIFO-очередей без возможности изменять последовательность запросов внутри них. Плюс он объединяет запросы к соседним блокам. Все более сложные задачи остаются за нижележащим уровнем, например аппаратным RAID-контроллером.
CFQ (Completely Fair Queueing) работает чуть посложнее:
В CFQ имеется возможность указать класс процесса и приоритет внутри класса. За счет довольно сильного дробления и появляется ожидаемая гибкость управления. Главное, правильно задать приоритеты, чтобы пользователь получил максимум производительности, но и без ущерба для административных задач. Примерно тем же занят и третий планировщик Deadline. В его функции входит переназначение приоритетов в пользу запросов на чтение данных.
Принцип действия был выбран исходя из практики, согласно которой большинство приложений в случае временной нехватки ресурсов блокируются именно на чтении, а не на записи или других процессах. Хотя всех трех вариантов обслуживания оказалось недостаточно с появлением дисков NVMe. С их появлением пришлось разрабатывать новые решения для BLK-MQ: NONE, BFG, MQ-DEADLINE и KYBER.
При использовании технологии BLK-MQ есть смысл отключить стандартные планировщики путем переключения в режиме none. Относительно популярный инструмент BFG стал наследником CFQ в плане алгоритма и настроек. Здесь тоже идет группировка синхронных запросов по задачам, а асинхронных по устройствам. Новым является применения планировщика Round Robin, в который заложено понятие бюджетов, определяющих алгоритм распределения приоритетов.
Мало чего кардинально нового появилось и в MQ-Deadline. Это всего лишь адаптация предыдущей утилиты под особенности алгоритмов BLK-MQ. Работает такая система все с тем же приоритетом в пользу запросов на чтение данных с накопителей. Схожий принцип используется и в программе Kyber.
Внедренный в продукт алгоритм создает две очереди. Одна включает все запросы на чтение данных, а вторая – на их запись. Первым всегда предоставляется приоритет, но с учетом заданных настроек, регламентирующих фиксированное время выполнения каждого запроса. Встроенный алгоритм дает возможность автоматически корректировать фактический размер очередей для получения нужного значения задержек при выполнении операций чтения-записи.
В старых версиях ядра (до 4.12.0) процесс инсталляции планировщика был усложнен тем, что требовался патчинг для включения поддержки BFQ-v7r2. Однако в новых версиях, начиная с 4.12.0, такая необходимость отсутствует — BFQ уже включен в ядро Linux, и дополнительных действий не требуется. При этом в любом случае рекомендуется обновить ядро до последней версии.
Далее установим пакеты для тюнинга настроек планировщика:
$ sudo apt-get install hdparm bonnie++
Все, сервер готов к эксплуатации и предварительному тестированию дисковой подсистемы.
По умолчанию BFQ настроен достаточно эффективно, все-таки его и разрабатывали под задачи по увеличению производительности. Но при желании поэкспериментировать можно изменить часть параметров, который записаны в конфигурационном файле /sys/block/sda/queue/iosched.
Чаще тестируют с изменением настроек:
Последний параметр применяется с учетом всех имеющихся временных лимитов. Если не менять нулевое значение, система будет автоматически подстраивать бюджет. Перечисленными пунктами можно регулировать длину очереди, заставляя дисковую подсистему функционировать быстрее в конкретных операциях. Но нужно соблюдать осторожность – так, например, при слишком большом значении quantum система обычно начинает «тормозить».
Проверить влияние планировщика на работу дисковой подсистемы весьма затруднительно. Простой однопоточный тест, скорее всего, покажет сходные результаты как до, так и после установки BLK-MQ. Но в реальной практике такие процессы редки, чаще происходит многопоточная загрузка, ее же получить можно только при использовании какого-то реального приложения. Или провести ряд синтетических тестов, имитирующих «бурную деятельность».
В качестве примера при тестировании разных вариантов системы будем замерять значение Latency, задержки при выполнении запросов при наибольшей скорости передачи данных, доступной тому или иному типу накопителей. В качестве платформы используем сервер 2 x Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.40GHz со 128 ГБ ОЗУ и предустановленной Ubuntu 16.04 с версией ядра 4.13.0-17, взятой из официального репозитория.
Результаты двухчасового теста с жестким диском 8 ТБ HGST HUH721008AL:
Выводы простые – с жесткими дисками переходить на новые планировщики особого смысла нет, хоть они и показывают улучшение работы дисковой подсистемы в целом. Здесь HDD остается тем самым «узким местом», которым он является из-за конструктивных особенностей накопителей. Это и определяет массовый переход минимум на SSD (твердотельные диски), которые мы и протестируем во вторую очередь.
В этом случае используем платформу Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz с 64 ГБ ОЗУ и 1.6 ТБ INTEL SSD DC S3520 Series. В качестве операционной системы используем Ubuntu 14.04 с ядром 4.12.0-041200-generic. Вкратце о результатах тестирования:
Интересная ситуация возникла с CFQ: утилита по неизвестной причине отдавала приоритет любым запросам на запись, чем и ухудшила свой показатель чтения данных. Такой алгоритм не очень хорошо сказывается на общей эффективности, ведь считыванию принято отдавать максимальные «полномочия». В этом случае работа BFQ представляется более «честной», нацеленной именно на рост производительности, а не бездумно» перераспределение приоритетов.
Теперь о NVMe. Ряд специалистов считает, что с ними вообще не требуется использовать какие-либо планировщики, и лучше сделать акцент на модернизации всего сервера для получения высокой пропускной способности как контроллеров ввода-вывода, так и остальной системы. Но в некоторых случаях решение об установке BLK-MQ остается оправданным. Например, когда важно уменьшить время задержки даже при снижении количества операций ввода-вывода за единицу времени.
При тестировании накопителя NVMe на той же платформе, что и с SSD, минимальных показателей Latency при чтении данных также достигла утилита Kyber (всего 0,612 мс против 1,3-1,4 секунд для остальных планировщиков). Продукт BFQ выделился довольно сильной нагрузкой на процессор в четвертом результате тестов. Если считать слева направо и сверху вниз, это сильно заметно.
В статье мы разобрались, что такое планировщик, какие изменения он вносит в работу дисковой подсистемы. Понятно, что обзор получился довольно скромным, скорее нацеленным на получение общих знаний. В реальной практике нагрузка на сервер сложнее по структуре, и далеко не всегда нужно давать приоритет именно запросам на чтение. Многое будет зависеть от таких факторов, как модель контроллера RAID, материнской платы и пр.
В целом, применение инструментов вроде BFQ Scheduler оправдано, особенно при установке твердотельных накопителей. Хоть MQ-Deadline и Kyber тоже используются активно, здесь лучше отталкиваться от тестирования сервера в реальных задачах и выбирать наилучший вариант. При выборе рекомендуется отталкиваться от следующих моментов:
Стоит учитывать и тот факт, что все перечисленные планировщики продолжают развиваться. И в новых релизах алгоритм вполне может измениться настолько кардинально, что придется подбирать новый инструмент для увеличения производительности дисковой подсистемы.