RU2604344C2 - Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных - Google Patents
Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных Download PDFInfo
- Publication number
- RU2604344C2 RU2604344C2 RU2014144602/08A RU2014144602A RU2604344C2 RU 2604344 C2 RU2604344 C2 RU 2604344C2 RU 2014144602/08 A RU2014144602/08 A RU 2014144602/08A RU 2014144602 A RU2014144602 A RU 2014144602A RU 2604344 C2 RU2604344 C2 RU 2604344C2
- Authority
- RU
- Russia
- Prior art keywords
- requests
- request
- length
- specific
- signatures
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
- G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
- G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
- G06F11/3075—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting the data filtering being achieved in order to maintain consistency among the monitored data, e.g. ensuring that the monitored data belong to the same timeframe, to the same system or component
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3485—Performance evaluation by tracing or monitoring for I/O devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N20/00—Machine learning
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Artificial Intelligence (AREA)
- Evolutionary Computation (AREA)
- Medical Informatics (AREA)
- Computational Linguistics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Computer Hardware Design (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Изобретение относится к системам распределения и хранения данных. Технический результат заключается в повышении качества обслуживания процесса управления запросами в системе хранения данных. Разработан способ формирования профиля приложений для управления запросами, в котором обрабатывают поток запросов на чтение и запись и собирают данные о запросах соответствующего приложения. Определяют сигнатуры запросов на чтение и запись информации, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса. Далее из упомянутых сигнатур формируют профиль приложения. 2 н. и 10 з.п. ф-лы, 5 ил., 4 табл.
Description
Данные изобретения относятся к системам распределения и хранения данных, точнее, к способам управления запросами в системах хранения данных и способам предоставления уровня обслуживания при запросах инициаторов в системах хранения данных.
Современный подход к системам распределения и хранения данных предусматривает использование как можно меньшего количества энергии при высоком уровне обслуживания с минимальными ресурсами на хранение информации и обеспечение наивысшего качества хранения за минимальную стоимость.
Задачи, решаемые данными изобретениями, связаны между собой, так как необходимость предоставления необходимого уровня обслуживания по запросам клиентских приложений к системе хранения данных напрямую связана со способом анализа данных входящих запросов и формированием профиля приложений, который используется для управления запросами. Необходимость поддерживать оптимальный уровень обслуживания для каждого приложения, обращающегося к системе хранения данных, характеризуется скоростью обработки запросов, надежностью системы при разумных затратах. Можно сказать, что от способа формирования профиля приложений зависит эффективность работы всей системы хранения данных.
Следует учесть, что основной задачей большинства современных систем хранения данных является одновременное предоставление ресурсов хранения нескольким клиентским станциям (инициаторам).
Следует разделять задачи, требующие ресурсов хранения на критичные для бизнеса и некритичные для бизнеса компании. Невозможность выполнения критичных для бизнеса задач в связи с тем, что все необходимые ресурсы были захвачены приложениями, выполняющими некритичные задачи, может привести к серьезным финансовым потерям.
Достаточно часто предоставление уровня обслуживания по запросам различных инициаторов формируется вручную системным администратором. Администратор может предоставить приоритет одному или нескольким инициаторам, тогда запросам от них будет предоставлена гарантированная пропускная способность. Однако такой способ управления в системах хранения данных не может обеспечить уровень обслуживания с оптимальной производительностью и надежностью.
Известны решения, в которых предоставление уровня обслуживания осуществляется автоматически. При этом первоначально формируются характеристики, которые, в том или ином виде, используются для управления запросами в системе хранения данных.
В заявке 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-интенсивных приложений со стороны системы хранения данных.
- Разграничение трафика сетевых приложений с возможностью обеспечения качества обслуживания наиболее важным из них.
- Применение политик сжатия или хранения данных на разных видах памяти в зависимости от приложения, которое с ними работает.
- Обнаружение аномальной активности среди запросов к системе хранения данных или в сетях передачи данных.
Способ предоставления уровня обслуживания по запросам инициаторов в системе хранения данных может применяться в различных системах хранения, где необходимо автоматическое выставление приоритетов с высоким уровнем обслуживания.
Claims (12)
1. Способ формирования профиля приложений для управления запросами в системе хранения данных, характеризующийся тем, что
- обрабатывают поток запросов на чтение и запись и собирают данные о запросах соответствующего приложения;
- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса;
- и далее из упомянутых сигнатур формируют профиль приложения.
- обрабатывают поток запросов на чтение и запись и собирают данные о запросах соответствующего приложения;
- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса;
- и далее из упомянутых сигнатур формируют профиль приложения.
2. Способ по п. 1, характеризующийся тем, что в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
конкретная длина запроса,
доля запросов конкретной длины,
отношение запросов конкретной длины на запись ко всем запросам конкретной длины,
среднее время между приходами запросов конкретной длины,
количество запросов конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.
конкретная длина запроса,
доля запросов конкретной длины,
отношение запросов конкретной длины на запись ко всем запросам конкретной длины,
среднее время между приходами запросов конкретной длины,
количество запросов конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.
3. Способ по п. 1, характеризующийся тем, что дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
среднее количество запросов между запросами конкретной длины, среднее количество уникальных запросов по длинам между запросами конкретной длины,
средняя разность между конкретными длинами запросов у сигнатур, полученных за один промежуток времени, если их упорядочить по убыванию долей запросов этих длин,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.
среднее количество запросов между запросами конкретной длины, среднее количество уникальных запросов по длинам между запросами конкретной длины,
средняя разность между конкретными длинами запросов у сигнатур, полученных за один промежуток времени, если их упорядочить по убыванию долей запросов этих длин,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.
4. Способ по п. 1, характеризующийся тем, что дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
доля последовательных запросов на запись конкретной длины,
доля последовательных запросов на чтение конкретной длины,
доля случайных запросов на чтение конкретной длины,
доля случайных запросов на запись конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов,
встречающихся в процессе обработки потока запросов на чтение и запись.
доля последовательных запросов на запись конкретной длины,
доля последовательных запросов на чтение конкретной длины,
доля случайных запросов на чтение конкретной длины,
доля случайных запросов на запись конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов,
встречающихся в процессе обработки потока запросов на чтение и запись.
5. Способ по п. 1, характеризующийся тем, что данные о параметрах запросов приложений собирают периодически, в течение предопределенных временных интервалов.
6. Способ по п. 5, характеризующийся тем, что при обработке потока запросов собирают данные о параметрах только тех запросов, которые входят в заранее определенный порог нагрузки во временном интервале.
7. Способ предоставления уровня обслуживания по запросам инициаторов в системе хранения данных, характеризующийся тем, что предварительно, в процессе обучения, формируют программный модуль для анализа запросов, содержащий профили, свойственные каждому из приложений, используемых в запросах инициаторов, для чего
- обрабатывают поток запросов на чтение и запись и собирают данные о запросах соответствующего приложения;
- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса;
- и из упомянутых сигнатур формируют профиль приложения;
далее в процессе выставления приоритетов
- обрабатывают поток запросов на чтение и запись и собирают данные о параметрах запросов каждого инициатора;
- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации каждого инициатора, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса, и далее формируют профиль каждого инициатора;
- сравнивают профиль, свойственный каждому из приложений, с профилем каждого инициатора и выносят решение о предоставлении уровня обслуживания на основе этого анализа.
- обрабатывают поток запросов на чтение и запись и собирают данные о запросах соответствующего приложения;
- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса;
- и из упомянутых сигнатур формируют профиль приложения;
далее в процессе выставления приоритетов
- обрабатывают поток запросов на чтение и запись и собирают данные о параметрах запросов каждого инициатора;
- на основе собранных данных определяют сигнатуры запросов на чтение и запись информации каждого инициатора, при этом каждую из сигнатур определяют для конкретной длины запроса, и каждая из сигнатур содержит ряд характеристик, определенных на основе длины запроса и времени прихода запроса, и далее формируют профиль каждого инициатора;
- сравнивают профиль, свойственный каждому из приложений, с профилем каждого инициатора и выносят решение о предоставлении уровня обслуживания на основе этого анализа.
8. Способ по п. 7, характеризующийся тем, что в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
конкретная длина запроса,
доля запросов конкретной длины,
отношение запросов конкретной длины на запись ко всем запросам конкретной длины,
среднее время между приходами запросов конкретной длины,
количество запросов конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.
конкретная длина запроса,
доля запросов конкретной длины,
отношение запросов конкретной длины на запись ко всем запросам конкретной длины,
среднее время между приходами запросов конкретной длины,
количество запросов конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.
9. Способ по п. 7, характеризующийся тем, что дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
среднее количество запросов между запросами конкретной длины, среднее количество запросов по уникальным длинам между запросами конкретной длины,
средняя разность между конкретными длинами запросов у сигнатур, полученных за один промежуток времени, если их упорядочить по убыванию долей запросов этих длин,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.
среднее количество запросов между запросами конкретной длины, среднее количество запросов по уникальным длинам между запросами конкретной длины,
средняя разность между конкретными длинами запросов у сигнатур, полученных за один промежуток времени, если их упорядочить по убыванию долей запросов этих длин,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.
10. Способ по п. 7, характеризующийся тем, что дополнительно в качестве характеристик, определяющих сигнатуру запросов на чтение информации и сигнатуру запросов на запись информации, используют следующие:
доля последовательных запросов на запись конкретной длины,
доля последовательных запросов на чтение конкретной длины,
доля случайных запросов на чтение конкретной длины,
доля случайных запросов на запись конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.
доля последовательных запросов на запись конкретной длины,
доля последовательных запросов на чтение конкретной длины,
доля случайных запросов на чтение конкретной длины,
доля случайных запросов на запись конкретной длины,
при этом в качестве конкретной длины запроса рассматривают каждую длину запроса, которая входит в последовательность длин запросов, встречающихся в процессе обработки потока запросов на чтение и запись.
11. Способ по п. 7, характеризующийся тем, что в процессе обучения данные о параметрах запросов приложений собирают периодически, в течение предопределенных временных интервалов, которые составляют t0 секунд.
12. Способ по п. 11, характеризующийся тем, что в процессе выставления приоритетов обрабатывают поток запросов на чтение и запись и собирают данные о параметрах запросов каждого инициатора периодически, в течение временных интервалов, равных упомянутым предопределенным временным интервалам, используемым в процессе обучения.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| RU2014144602/08A RU2604344C2 (ru) | 2014-11-05 | 2014-11-05 | Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| RU2014144602/08A RU2604344C2 (ru) | 2014-11-05 | 2014-11-05 | Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| RU2014144602A RU2014144602A (ru) | 2016-05-27 |
| RU2604344C2 true RU2604344C2 (ru) | 2016-12-10 |
Family
ID=56095752
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2014144602/08A RU2604344C2 (ru) | 2014-11-05 | 2014-11-05 | Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных |
Country Status (1)
| Country | Link |
|---|---|
| RU (1) | RU2604344C2 (ru) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2476007C2 (ru) * | 2008-09-18 | 2013-02-20 | ЗетТиИ Корпорейшн | Способ и устройство для обработки многоканальных запросов в платформе управления услугами |
| US8762583B1 (en) * | 2010-04-30 | 2014-06-24 | Emc Corporation | Application aware intelligent storage system |
-
2014
- 2014-11-05 RU RU2014144602/08A patent/RU2604344C2/ru not_active Application Discontinuation
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2476007C2 (ru) * | 2008-09-18 | 2013-02-20 | ЗетТиИ Корпорейшн | Способ и устройство для обработки многоканальных запросов в платформе управления услугами |
| US8762583B1 (en) * | 2010-04-30 | 2014-06-24 | Emc Corporation | Application aware intelligent storage system |
Also Published As
| Publication number | Publication date |
|---|---|
| RU2014144602A (ru) | 2016-05-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Park et al. | 3sigma: distribution-based cluster scheduling for runtime uncertainty | |
| WO2021063339A1 (zh) | 集群资源调度方法、装置、设备及储存介质 | |
| US10620839B2 (en) | Storage pool capacity management | |
| CA2780231C (en) | Goal oriented performance management of workload utilizing accelerators | |
| US9197703B2 (en) | System and method to maximize server resource utilization and performance of metadata operations | |
| CN110166282B (zh) | 资源分配方法、装置、计算机设备和存储介质 | |
| JP3944154B2 (ja) | マルチスレッド・サーバ内のスレッド・プールを動的に調整する方法およびシステム | |
| US8190593B1 (en) | Dynamic request throttling | |
| US8997109B2 (en) | Apparatus and method for managing data stream distributed parallel processing service | |
| EP3535976A1 (en) | Live video analytics at scale | |
| US20080077932A1 (en) | Mechanism for Automatically Managing the Resource Consumption of Transactional Workloads | |
| CN107515784B (zh) | 一种在分布式系统中计算资源的方法与设备 | |
| US20100162251A1 (en) | System, method, and computer-readable medium for classifying problem queries to reduce exception processing | |
| CN110851236A (zh) | 一种实时资源调度方法、装置、计算机设备及存储介质 | |
| CN113228574A (zh) | 计算资源调度方法、调度器、物联网系统和计算机可读介质 | |
| Zhang et al. | Zeus: Improving resource efficiency via workload colocation for massive kubernetes clusters | |
| Saxena et al. | Auto-WLM: Machine learning enhanced workload management in Amazon Redshift | |
| CN117667305A (zh) | 基于业务场景的安全策略的部署方法、装置及电子设备 | |
| CN117234733A (zh) | 一种分布式系统任务分配方法、系统、存储介质及设备 | |
| CN116708219A (zh) | 一种基于dpi平台的数据获取方法及装置 | |
| RU2604344C2 (ru) | Способ формирования профиля приложений для управления запросами и способ предоставления уровня обслуживания по запросам в системе хранения данных | |
| CN113596146B (zh) | 一种基于大数据的资源调度的方法及装置 | |
| CN110928649A (zh) | 资源调度的方法和装置 | |
| CN115981817B (zh) | 一种面向htap的任务资源调度方法及其系统 | |
| WO2024119793A1 (zh) | 基于缓存亲和的调度方法、系统、设备及介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FA92 | Acknowledgement of application withdrawn (lack of supplementary materials submitted) |
Effective date: 20160520 |
|
| FZ9A | Application not withdrawn (correction of the notice of withdrawal) |
Effective date: 20160915 |