Технология QoS (Quality of Service) в сетевой инфраструктуре известна достаточно давно. Позже подобные алгоритмы нашли применение и в сфере хранения данных, став фактически стандартом для систем, претендующих на рынок Enterprise. В СХД Qsan данный функционал стал доступен относительно недавно с появлением firmware версии 1.4.0.  Сама идея установки приоритетов для различных задач (а именно в этом заключается суть работы алгоритмов QoS) происходит из-за равного доступа к ресурсам со стороны хостов. Если общей производительности СХД достаточно, то нечастые всплески активности определенных сервисов смогут компенсироваться пониженным требованием к производительности со стороны прочих приложений. Однако в реальной жизни на одной СХД часто располагаются сразу несколько критичных к производительности сервисов. Если полагаться на их равноправный доступ к ресурсам, то вполне может случиться «торможение» как минимум одного из них из-за работы остальных приложений.  Помимо продуктивных приложений, критичных к показателям производительности, на СХД могут располагаться и тестовые среды разработчиков, которые также следует ограничить в производительности, чтобы не мешать основной работе. Плюс всегда имеются плановые и внеплановые работы по обслуживанию систем, которые также требуют определенных ресурсов, отнимая их у главных сервисов. Поэтому ранжирование приложений, расположенных на СХД, в соответствии с их приоритетом доступа к ресурсам с точки зрения производительности будет очень кстати. С точки зрения настройки QoS можно выделить две основные политики: Для работы QoS выбирается какая-то одна из них. В случае необходимости всегда можно переключить настройки «на лету». Сами политики QoS применяются к отдельным томам. В качестве максимальных значений используются параметры IOPS и пропускная способность. По умолчанию используется значение Unlimited (без ограничений). В случае установки конкретных значений производительность будет ограничена именно этими цифрами.   Если использовать ограничение «снизу», то необходимо задать приоритет доступа к ресурсам: низкий, средний или высокий. В случае высокого приоритета также можно задать минимальное желаемое значение параметра Response Time. Данный параметр не зря обозначен как желаемый, т.к. далеко не всегда возможно его достижение из-за конфигурации используемых накопителей и текущей нагрузки на систему.  В качестве тестового стенда использовался один сервер, подключенный напрямую к СХД XS5224 через интерфейс Fibre Channel. СХД была заполнена дисками NL-SAS 7.2K, собранными в 3 пула RAID-0. На каждом из пулов был создан один том, итого 3 тома. Нагрузкой выступал тест IOmeter.   Отчетливо видно, что при изменении приоритета производительность перераспределяется в соответствующем порядке.   При изменении приоритета производительность перераспределяется в соответствующем порядке. Для тома Vol-1 значение Response Time стремится к заданным 25мс, но не достигает его из-за недостатка производительности RAID группы.   При ограничении производительности в IOPS для некоторых томов остальные тома получают прибавку в скорости за счет высвободившихся ресурсов.   При ограничении производительности по пропускной способности также происходит увеличение производительности отдельных томов за счет высвободившихся ресурсов.