Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных



Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных
Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных
Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных
Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных
Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных
Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных
Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных
Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных

 


Владельцы патента RU 2604344:

Общество с ограниченной ответственностью "РЭЙДИКС" (RU)

Изобретение относится к системам распределения и хранения данных. Технический результат заключается в повышении качества обслуживания процесса управления запросами в системе хранения данных. Разработан способ формирования профиля приложений для управления запросами, в котором обрабатывают поток запросов на чтение и запись и собирают данные о запросах соответствующего приложения. Определяют сигнатуры запросов на чтение и запись информации, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса. Далее из упомянутых сигнатур формируют профиль приложения. 2 н. и 10 з.п. ф-лы, 5 ил., 4 табл.

 

Данные изобретения относятся к системам распределения и хранения данных, точнее, к способам управления запросами в системах хранения данных и способам предоставления уровня обслуживания при запросах инициаторов в системах хранения данных.

Современный подход к системам распределения и хранения данных предусматривает использование как можно меньшего количества энергии при высоком уровне обслуживания с минимальными ресурсами на хранение информации и обеспечение наивысшего качества хранения за минимальную стоимость.

Задачи, решаемые данными изобретениями, связаны между собой, так как необходимость предоставления необходимого уровня обслуживания по запросам клиентских приложений к системе хранения данных напрямую связана со способом анализа данных входящих запросов и формированием профиля приложений, который используется для управления запросами. Необходимость поддерживать оптимальный уровень обслуживания для каждого приложения, обращающегося к системе хранения данных, характеризуется скоростью обработки запросов, надежностью системы при разумных затратах. Можно сказать, что от способа формирования профиля приложений зависит эффективность работы всей системы хранения данных.

Следует учесть, что основной задачей большинства современных систем хранения данных является одновременное предоставление ресурсов хранения нескольким клиентским станциям (инициаторам).

Следует разделять задачи, требующие ресурсов хранения на критичные для бизнеса и некритичные для бизнеса компании. Невозможность выполнения критичных для бизнеса задач в связи с тем, что все необходимые ресурсы были захвачены приложениями, выполняющими некритичные задачи, может привести к серьезным финансовым потерям.

Достаточно часто предоставление уровня обслуживания по запросам различных инициаторов формируется вручную системным администратором. Администратор может предоставить приоритет одному или нескольким инициаторам, тогда запросам от них будет предоставлена гарантированная пропускная способность. Однако такой способ управления в системах хранения данных не может обеспечить уровень обслуживания с оптимальной производительностью и надежностью.

Известны решения, в которых предоставление уровня обслуживания осуществляется автоматически. При этом первоначально формируются характеристики, которые, в том или ином виде, используются для управления запросами в системе хранения данных.

В заявке US 2008222311, опубликованной 11.09.2008, МПК G06F 3/00, описан способ управления в системе хранения данных при чтении - записи информации. Политика управления приоритетами используются для определения, должны ли соответствующие запросы ввода-вывода выдаваться общей системе хранения немедленно или их выполнение должно быть отложено на основе очередей. Для автоматического управления данными в процессе чтения-записи используются эвристические критерии, которые задает администратор. Эти критерии, например, могут включать в себя предоставление приоритета запросам, исходящим от руководителей компании, в дневное время и запросам персонала по информационным технологиям в ночное время, а также определяют политику управления запросами.

В заявке US 20120124319, опубликованной 17.05.2012, МПК G06F 12/00, описан способ повышения производительности системы хранения данных. В данном способе формируется профиль приложений, который включает информацию, идентифицирующую желаемую и одновременно наиболее оптимальную конфигурацию логического тома, которая используется для функционирования соответствующей программы хост-системы. Варианты возможной конфигурации логического тома сопоставляются с информацией профиля, что позволяет либо автоматически настраивать логический том, или разрешить пользователю выбрать нужные опции в опциях конфигурации. В качестве характеристик используются, в частности, характеристики, зависящие от планируемого качества обслуживания и политики хранения информации в логическом томе, геометрические характеристики логического тома, локальные характеристики для создания резервной копии логического тома. Данное изобретение направлено на решение задачи определения конфигурации хранилища для данных в зависимости от профилей приложений. Запросы приложений классифицируются по одному. В качестве характеристик для формирования профиля приложения используются данные адресов приложений и эвристические характеристики, сформированные для различных конфигураций логических томов, формируемые администратором.

Наиболее близким к изобретению является решение, описанное в патенте US 8762583, публикация 24.06.2014, МПК G06F 15/18. В данном изобретении описан способ управления системой хранения данных, который обеспечивает чтение или запись в процессе доступа к данным с использованием новой архитектуры. Способ состоит в каталогизации запросов на чтение - запись и отметки этих запросов разными маркерами в соответствии с политикой управления запросами в зависимости от того, направляются ли они на диск для записи или с диска для операции чтения. Политика управления автоматически обновляется в зависимости от результатов обработки операций ввода-вывода после выполнения услуги. Способ в части формирования профиля приложений для управления запросами не конкретизирован и предусматривает поиск закономерностей в данных приложений с помощью нейронной сети. Какие характеристики выявляются при поиске этих закономерностей, в материалах заявки не поясняется. Способ в части предоставления уровня обслуживания по запросам инициаторов предусматривает предварительную процедуру обучения с использованием полученного профиля приложений и производится также с использованием нейронной сети. Далее производится анализ запросов на основе выработанной политики и производится выставление приоритетов по запросам инициаторов.

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

Этот результат достигается тем, что в части способа формирования профиля приложений для управления запросами в системе хранения данных появилась возможность формирования профиля приложения на основе ряда характеристик, определенных на основе длины запроса и времени прихода запроса, без использования какой-либо иной служебной информации. Способ может быть применен в различных системах хранения данных. Сформированные профили обеспечивают высокую точность и скорость идентификации, при использовании сравнительно небольших вычислительных ресурсов.

В части способа предоставления уровня обслуживания выставления приоритетов, по запросам инициаторов в системе хранения данных, также обеспечивается высокая точность и скорость идентификации, при использовании сравнительно небольших вычислительных ресурсов. Кроме того, способ обеспечивает быструю реакцию на динамическое изменение состояния в системе хранения данных.

Изобретение способ формирования профиля приложений для управления запросами в системе хранения данных, характеризуется тем, что:

- обрабатывают поток запросов на чтение и запись и собирают данные о запросах соответствующего приложения;

- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса;

- и далее из упомянутых сигнатур формируют профиль приложения.

Способ заключается в том, что при формировании профиля приложений анализируется поток запросов соответствующего приложения. В качестве данных запросов на чтение-запись каждого приложения используются характеристики - длина запроса и время прихода запроса. На основе этих полученных характеристик определяют сигнатуры запросов - набор параметров, однозначно идентифицирующий поток запросов от конкретного приложения в определенный период времени, как на чтение, так и на запись. На основе этих сигнатур формируют профиль приложения.

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

В частном случае использования способа в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:

конкретная длина запроса,

доля запросов конкретной длины,

отношение запросов конкретной длины на запись ко всем запросам конкретной длины,

среднее время между приходами запросов конкретной длины,

количество запросов конкретной длины.

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

Кроме того, могут дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации использоваться следующие:

среднее количество запросов между запросами конкретной длины,

среднее количество уникальных запросов по длинам между запросами конкретной длины,

средняя разность между конкретными длинами запросов у сигнатур, полученных за один промежуток времени, если их упорядочить по убыванию долей запросов этих длин.

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

Дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации, и сигнатуру запросов на запись информации могут быть использованы следующие:

доля последовательных запросов на запись конкретной длины,

доля последовательных запросов на чтение конкретной длины,

доля случайных запросов на чтение конкретной длины,

доля случайных запросов на запись конкретной длины.

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

В частности, данные о параметрах запросов приложений, собирают периодически, в течение предопределенных временных интервалов, которые составляют t0 (заданный заранее параметр) секунд.

Кроме того, при обработке потока запросов собирают данные о параметрах только тех запросов, которые входят в определенный заранее порог Threshold нагрузки во временном интервале (обычно Threshold=90%).

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

Способ предоставления уровня обслуживания по запросам инициаторов в системе хранения данных характеризуется тем, что:

предварительно, в процессе обучения, формируют программный модуль для анализа запросов, содержащий профили, свойственные каждому из приложений, используемых в запросах инициаторов, для чего

- обрабатывают поток запросов на чтение и запись и собирают данные о запросах соответствующего приложения;

- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса;

- и из упомянутых сигнатур формируют профиль приложения.

Далее в процессе выставления приоритетов:

- обрабатывают поток запросов на чтение и запись и собирают данные о параметрах запросов каждого инициатора;

- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации каждого инициатора, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса и далее формируют профиль каждого инициатора;

- сравнивают профиль, свойственный каждому из приложений с профилем каждого инициатора и выносят решение о предоставлении уровня обслуживания на основе этого анализа.

В частности, в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации используют следующие:

конкретная длина запроса,

доля запросов конкретной длины,

отношение запросов конкретной длины на запись ко всем запросам конкретной длины,

среднее время между приходами запросов конкретной длины,

количество запросов конкретной длины,

при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.

Кроме того, дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации, и сигнатуру запросов на запись информации используют следующие:

среднее количество запросов между запросами конкретной длины,

среднее количество запросов по уникальным длинам между запросами конкретной длины,

средняя разность между конкретными длинами запросов у сигнатур, полученных за один промежуток времени, если их упорядочить по убыванию долей запросов этих длин,

при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.

Дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации, и сигнатуру запросов на запись информации могут быть использованы следующие:

доля последовательных запросов на запись конкретной длины,

доля последовательных запросов на чтение конфетной длины,

доля случайных запросов на чтение конкретной длины,

доля случайных запросов на запись конкретной длины,

при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.

В частном случае, в процессе обучения данные о параметрах запросов приложений собирают периодически, в течение предопределенных временных интервалов, которые составляют t0 секунд.

Кроме того, в процессе выставления приоритетов обрабатывают поток запросов на чтение и запись и собирают данные о параметрах запросов каждого инициатора периодически, в течение временных интервалов, равных упомянутым предопределенным временным интервалам, используемым в процессе обучения.

Изобретения поясняются схемами и диаграммами.

На Фиг. 1 приведена блок-схема устройства системы хранения данных для реализации способов.

На Фиг. 2 приведена блок-схема устройства анализатора запросов в системе хранения данных.

На Фиг. 3 приведена блок-схема операций при реализации способа формирования сигнатур в анализаторе запросов.

На Фиг. 4 приведена блок-схема операций при реализации модуля обучения в анализаторе запросов.

На Фиг. 5 приведена блок-схема операций при реализации способа предоставления уровня обслуживания по запросам инициаторов в системе хранения данных.

Система хранения данных 2 (Фиг. 1) подключается к ряду инициаторов 1 и, в свою очередь, содержит последовательно соединенные: входной модуль 3, отвечающий за прием запросов и формирование очереди запросов, модуль 4 качества обслуживания QoS, блок 5 обработчиков запросов и блоки 7 памяти. Блок 5 обработчиков запросов соединен двухсторонней связью с памятью кэша 6. Входной блок 3 связан также с анализатором запросов 8. Анализатор запросов 8 соединен с модулем 4 качества обслуживания QoS.

Анализатор запросов 8 (Фиг. 2) в свою очередь содержит модуль расчета сигнатур 9, модуль обучения 10, модуль определения приложений 11, область памяти, где хранятся профили приложений 12 и предсказатель 13.

Система хранения данных работает следующим образом (Фиг. 1-5).

От инициаторов 1 (Фиг. 1) поступают запросы на чтение или запись, которые поступают в модуль приема запросов 3. Модуль 4 QoS определяет, какие запросы нужно обработать с большим приоритетом, и направляет их в нужном порядке обработчикам запросов 5. Обработчики запросов 5 осуществляют эти запросы, используя кэш 6 и блоки памяти 7. Анализатор запросов 8 получает запросы от модуля приема запросов 3 и на их основе предсказывает, какие приложения в данные момент работают на каких инициаторах, и генерирует инструкции для модуля 4 QoS. Инструкции передаются в модуль 4 QoS и используются в дальнейшем для улучшения механизма выставления приоритетов.

Анализатор запросов 8 (Фиг 2) принимает запросы с помощью модуля расчета сигнатур 9. Сигнатуры, полученные от модуля 9, в зависимости от активного режима работы системы хранения данных направляются либо в модуль обучения 10, либо в модуль определения приложений 11. Модуль обучения 10 оперирует профилями приложений 12, на основе которых формирует предсказатель 13. Модуль определения приложений 11 формирует предсказания по инициаторам на основе сигнатур, полученных от модуля расчета сигнатур 9 и результатов работы предсказателя 13.

В последующем описании используются следующие параметры:

- t0 - длина интервала времени, за который собираются I/O запросы для дальнейшего подсчета характеристик;

- Intensity0 - минимально допустимая интенсивность запросов, при которой выполняется расчет характеристик;

- Threshold - порог на рабочую нагрузку, собираются данные о параметрах только тех запросов, чьи длины входят в порог нагрузки во временном интервале.

- Threshold0 - порог для предсказаний по сигнатурам; если вероятность успешной идентификации сигнатуры меньше, чем данный порог, то данной сигнатуре сопоставляется метка «не удалось определить» вместо идентификатора конкретного приложения;

- Threshold1 - порог для предсказаний по инициаторам; если доля сигнатур, идентифицированных, как конкретное критически важное приложение, превышает этот порог, приоритет инициатору выставляется.

- Threshold2 - порог на снятие приоритета с инициатора; количество подряд идущих интервалов, на которых должно не определиться критически важное приложение, чтобы инициатор перестал быть приоритетным.

Работа модуля расчета сигнатур 9 разделена на этапы (Фиг. 3). На этапе 2-1 происходит сбор I/O запросов за интервал времени t0. По окончании интервала на этапе 2-2 интенсивность запросов от каждого инициатора сравнивается с Intensity0. Если она не превышает этот порог, производится возврат к этапу 2-1. В случае превышения порога на этапе 2-3 происходит расчет характеристик. В качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.

В качестве характеристик могут использоваться следующие:

- конкретная длина запроса,

- доля запросов конкретной длины,

- отношение запросов конкретной длины на запись ко всем запросам конкретной длины,

- среднее время между приходами запросов конкретной длины,

- количество запросов конкретной длины,

- среднее количество запросов между запросами конкретной длины,

- среднее количество уникальных запросов по длинам между запросами конкретной длины,

- средняя разность между конкретными длинами запросов у сигнатур, полученных за один промежуток времени, если их упорядочить по убыванию долей запросов этих длин,

- доля последовательных запросов на запись конкретной длины,

- доля последовательных запросов на чтение конкретной длины,

- доля случайных запросов на чтение конкретной длины,

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

В некоторых случаях в качестве параметра запроса применяется и адрес запроса.

На этапе 2-4 на основе рассчитанных характеристик формируются сигнатуры. Выбор тех или иных характеристик, или их сочетаний, при формировании сигнатур, определяется в зависимости от вида базы данных, вида инициаторов, а также вида информации, сохраняемой в базе данных.

При обработке потока запросов могут собираться данные о параметрах только тех запросов, которые входят в Threshold нагрузки во временном интервале.

На этапе 3-1 модуля обучения 10 производится получение сигнатур, рассчитанных за интервал времени t0 (Фиг. 4). На этапе 3-2 производится проверка на поступление от администратора системы хранения данных команды на окончание обучения. Если команда не поступила, производится возврат к этапу 3-1 с сохранением полученных сигнатур. Если команда поступила, производится переход к этапу 3-3. На этапе 3-3 все полученные сигнатуры объединяются в профиль приложения, в ходе чего может производиться отсечение повторяющихся и нерелевантных сигнатур, далее профилю сопоставляется метка приложения, указанная администратором. На этапе 3-4 данный профиль приложения добавляется к профилям других приложений, составленных ранее. На этапе 3-5 на основе данного профиля и профилей других приложений формируется предсказатель 13 (Фиг. 2).

На этапе 4-1 модуля определения приложений 11 производится получение сигнатур, рассчитанных за интервал времени t0 (Фиг. 5). На этапе 4-2 по каждой сигнатуре с использованием предсказателя 13 (Фиг. 2) предсказывается метка приложения. На этапе 4-3 вероятность истинности каждого из предсказаний сравнивается с порогом Threshold0. В случае превышения порога сигнатуре сопоставляется предсказанная метка. В противном случае сигнатуре сопоставляется метка «не удалось определить». На этапе 4-4 сигнатуры объединяются в профили, каждый из которых соответствует одному из инициаторов. На этапе 4-5 для каждого инициатора подсчитывается доля сигнатур каждого приложения. Приоритет инициатору выставляется, если доля критически важного приложения на нем больше порога Threshold1 (пороги могут быть разные для разных приложений). На этапе 4-6 с инициатора снимается приоритет, если доля критически важного приложения не соответствует порогу Threshold1 более чем на Threshold2 интервалах. На этапе 4-7 в модуль QoS 4 передается инструкция по каждому инициатору: выставить приоритет, снять приоритет, поддерживать приоритет с предыдущего интервала (ничего не делать).

В примерах выполнения способов использованы следующие параметры t0=20 секунд, Intensity0 = 5 запросам в секунду, Threshold = 90%, Threshold0 = 60%, Threshold1 = 50%, Threshold2 = 2.

Профили приложений, полученные по способу формирования профиля приложений для управления запросами, используются в примерах для иллюстрации способа предоставления уровня обслуживания по запросам инициаторов в системе хранения данных.

Примеры формирования профиля приложения.

В статистическом профиле приложения должно быть достаточное количество релевантных I/O сигнатур. Релевантность здесь означает, что сигнатуры должны быть собраны при различных рабочих нагрузках приложений. К примеру, при формировании I/O сигнатур приложение должно осуществлять запросы не только на чтение, но и на запись. В таблице ниже приводится примерное время для формирования профиля приложения, который гарантируют точность дальнейшей идентификации порядка 99.9%. Если рабочая нагрузка во время интервалов to одинаковая, или слабо меняющаяся, то I/O сигнатуры получаются похожими. Для объединения сигнатур в один профиль 3.3 используется метод k-средних, хотя возможно использование любого другого метода кластеризации или иного способа объединения.

Формирование профилей в зависимости от выбранных характеристик входящих в сигнатуры отличается в дальнейшем точностью идентификации. В системе, где работают только мультимедийные приложения и низкоприоритетные приложения, объединенные в один класс, наиболее предпочтителен выбор следующих характеристик:

- конкретная длина запроса,

- доля запросов конкретной длины,

- отношение запросов конкретной длины на запись ко всем запросам конкретной длины,

- среднее время между приходами запросов конкретной длины,

- количество запросов конкретной длины,

- среднее количество уникальных запросов по длинам между запросами конкретной длины,

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

Использование характеристики “среднее количество запросов между запросами конкретной длины”, не целесообразно, так как она линейно зависима от такой характеристики, как “среднее количество уникальных запросов по длинам между запросами конкретной длины”.

Проблема отбора характеристик может решаться с помощью алгоритмов Feature Selection (выбор характеристик).

Примеры выполнения способа предоставления уровня обслуживания по запросам инициаторов в системе хранения данных.

В трех примерах идентифицируются:

1. приложения с похожей рабочей нагрузкой (см. пример 1);

2. паттерны внутри одного приложения (см. пример 2);

3. различные типы приложений (см. пример 3).

В модуле обучения 10 применяется классификатор Random Forest, возможно использование и других алгоритмов машинного обучения.

Одним из достоинств алгоритма Random Forest является то, что у этого алгоритма всего два параметра:

1. Количество деревьев - во всех примерах оно равно 100.

2. Количество выбираемых параметров для построения одного дерева равно целой части из квадратного корня от количества характеристик в сигнатуре .

В таблицах ниже приведена вероятность ошибки неправильной идентификации для различных способов выбора характеристик.

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

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

Профиль 1, характеристики:

- конкретная длина запроса;

- доля запросов конкретной длины;

- отношение запросов конкретной длины на запись ко всем запросам конкретной длины;

- среднее время между приходами запросов конкретной длины;

- количество запросов конкретной длины;

Вероятность неправильной идентификации при выборе приведенных выше характеристиках имеет порядок 0.5%.

Профиль 2, дополнительно к профилю 1 характеристики:

- среднее количество запросов между запросами конкретной длины;

- среднее количество уникальных запросов по длинам между запросами конкретной длины;

- средняя разность между конкретными длинами запросов у сигнатур, полученных за один промежуток времени, если их упорядочить по убыванию долей запросов этих длин;

Вероятность неправильной идентификации для второго способа имеет порядок 0,1%.

Профиль 3, дополнительно к профилю 2 характеристики:

- доля последовательных запросов на запись конкретной длины;

- доля последовательных запросов на чтение конкретной длины;

- доля случайных запросов на чтение конкретной длины;

- доля случайных запросов на запись конкретной длины.

Пример 2. Идентификация различных паттернов в одном приложении.

На данном примере видно, что введение лишних атрибутов не улучшает, а даже ухудшает результат предсказания.

В примере проводится идентификация паттернов: обработка видео разрешения 4K - Smoke4K, обработка видео 2K Smoke2K, само приложение Autodesk Smoke.

Пример 3. Идентификация различных типов приложений.

В данном примере приводится идентификация различных паттернов и типов приложений, включающих в себя конвертер видео Compressor, базу данных MS SQL, средство виртуализации VMware, и класс нежелательных приложений Bad - туда входят приложение резервного копирования, антивирус, офисный пакет, почтовый сервер и др.

Способ формирования профиля приложений для управления запросами в системе хранения данных и способ предоставления уровня обслуживания по запросам инициаторов могут применяться в различных системах хранения данных, для решения различных задач, в частности:

- Предоставление качества обслуживания для I/O-интенсивных приложений со стороны системы хранения данных.

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

- Применение политик сжатия или хранения данных на разных видах памяти в зависимости от приложения, которое с ними работает.

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

Способ предоставления уровня обслуживания по запросам инициаторов в системе хранения данных может применяться в различных системах хранения, где необходимо автоматическое выставление приоритетов с высоким уровнем обслуживания.

1. Способ формирования профиля приложений для управления запросами в системе хранения данных, характеризующийся тем, что
- обрабатывают поток запросов на чтение и запись и собирают данные о запросах соответствующего приложения;
- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса;
- и далее из упомянутых сигнатур формируют профиль приложения.

2. Способ по п. 1, характеризующийся тем, что в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
конкретная длина запроса,
доля запросов конкретной длины,
отношение запросов конкретной длины на запись ко всем запросам конкретной длины,
среднее время между приходами запросов конкретной длины,
количество запросов конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.

3. Способ по п. 1, характеризующийся тем, что дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
среднее количество запросов между запросами конкретной длины, среднее количество уникальных запросов по длинам между запросами конкретной длины,
средняя разность между конкретными длинами запросов у сигнатур, полученных за один промежуток времени, если их упорядочить по убыванию долей запросов этих длин,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.

4. Способ по п. 1, характеризующийся тем, что дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
доля последовательных запросов на запись конкретной длины,
доля последовательных запросов на чтение конкретной длины,
доля случайных запросов на чтение конкретной длины,
доля случайных запросов на запись конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов,
встречающихся в процессе обработки потока запросов на чтение и запись.

5. Способ по п. 1, характеризующийся тем, что данные о параметрах запросов приложений собирают периодически, в течение предопределенных временных интервалов.

6. Способ по п. 5, характеризующийся тем, что при обработке потока запросов собирают данные о параметрах только тех запросов, которые входят в заранее определенный порог нагрузки во временном интервале.

7. Способ предоставления уровня обслуживания по запросам инициаторов в системе хранения данных, характеризующийся тем, что предварительно, в процессе обучения, формируют программный модуль для анализа запросов, содержащий профили, свойственные каждому из приложений, используемых в запросах инициаторов, для чего
- обрабатывают поток запросов на чтение и запись и собирают данные о запросах соответствующего приложения;
- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса;
- и из упомянутых сигнатур формируют профиль приложения;
далее в процессе выставления приоритетов
- обрабатывают поток запросов на чтение и запись и собирают данные о параметрах запросов каждого инициатора;
- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации каждого инициатора, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса, и далее формируют профиль каждого инициатора;
- сравнивают профиль, свойственный каждому из приложений, с профилем каждого инициатора и выносят решение о предоставлении уровня обслуживания на основе этого анализа.

8. Способ по п. 7, характеризующийся тем, что в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
конкретная длина запроса,
доля запросов конкретной длины,
отношение запросов конкретной длины на запись ко всем запросам конкретной длины,
среднее время между приходами запросов конкретной длины,
количество запросов конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.

9. Способ по п. 7, характеризующийся тем, что дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
среднее количество запросов между запросами конкретной длины, среднее количество запросов по уникальным длинам между запросами конкретной длины,
средняя разность между конкретными длинами запросов у сигнатур, полученных за один промежуток времени, если их упорядочить по убыванию долей запросов этих длин,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.

10. Способ по п. 7, характеризующийся тем, что дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
доля последовательных запросов на запись конкретной длины,
доля последовательных запросов на чтение конкретной длины,
доля случайных запросов на чтение конкретной длины,
доля случайных запросов на запись конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.

11. Способ по п. 7, характеризующийся тем, что в процессе обучения данные о параметрах запросов приложений собирают периодически, в течение предопределенных временных интервалов, которые составляют t0 секунд.

12. Способ по п. 11, характеризующийся тем, что в процессе выставления приоритетов обрабатывают поток запросов на чтение и запись и собирают данные о параметрах запросов каждого инициатора периодически, в течение временных интервалов, равных упомянутым предопределенным временным интервалам, используемым в процессе обучения.



 

Похожие патенты:

Изобретение относится к способу и устройству обеспечения исполнения внешнего JavaScript (JS) с использованием расширенного интерфейса JS. Технический результат заключается в предоставлении поиска и просмотра web-страниц с использованием платформы WebApp.

Изобретение относится к области связи. Техническим результатом является повышение эффективности эксплуатации и управления браузером для сервера и клиента, содержащего браузер.

Изобретение относится к технологиям обработки электронных документов. Техническим результатом является обеспечение классификации изображений документов на основе функции классификации.

Изобретение относится к электронному портфолио работника по безопасности производства. Технический результат заключается в обеспечении санкционированного доступа к сведениям о работнике.

Изобретение относится к области хранения пространственных объектов. Техническим результатом является снижение нагрузки на сервер при выборе объектов благодаря использованию односвязного списка.

Изобретение относится к обработке данных. Технический результат заключается в повышении точности оценки сходства массивов бинарных данных.

Изобретение относится к области информационных технологий, в частности к устройствам обработки информации, таким как сервер управления документами. Технический результат заключается в повышении скорости извлечения документов за счет исключения необходимости определения иерархической структуры папок хранения документов.

Изобретение относится к области обработки информации. Технический результат - обеспечение повышения точности процесса поиска и слежения за движущимся объектом в изображениях.

Изобретение относится к технологиям мгновенного обмена сообщениями. Техническим результатом является осуществление автоматизированного приглашения пользователей в группу.

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

Изобретение относится к созданию политики управления доступом и конфигурированию системы управления доступом с помощью политики управления доступом. Техническим результатом является повышение точности определения набора документов, к которым применяется политика доступа. Система для формирования политики управления доступом содержит пользовательский интерфейс (1) для предоставления пользователю возможности указывать тему (10) и набор разрешений (15), анализатор (2) документов, подсистему (3) ассоциации, средство (5) поиска свойств и средство (6) выбора документов. Анализатор (2) документов анализирует содержимое множества документов (11), чтобы найти набор документов (13), имеющих отношение к теме (10). Средство (5) поиска свойств анализирует содержимое документов (11), чтобы найти отличительное свойство (12) документов, имеющих отношение к теме (10). Средство (6) выбора документов выбирает набор документов (13), основываясь на отличительном свойстве (12). Подсистема (3) ассоциации ассоциирует набор разрешений (15) с набором документов (13), чтобы получить политику (4) управления доступом. 4 н. и 8 з.п. ф-лы, 5 ил.
Наверх