Методика прагматического анализа информации состояния «облачного» сервиса в интересах организации интерфейса службы
жүктеу/скачать 1,48 Mb. Pdf көрінісі
|
- Бұл бет үшін навигация:
- Пример графа конфигурации ГРИС
| с которого отправлена информация
Это позволит, во-первых, скрыть от оператора относящиеся к происходящим в данный момент изменениям сообщения как являющиеся результатом выполняемого технического обслуживания, а значит не требующие незамедлительной реакции для устранения сбоя. И, во-вторых, для сообщений, относящихся к недавно завершенному изменению, проинформировать об этом оператора, что позволит ему принять решение о процедуре устранения сбоя, которая, в соответствии со стандартами эксплуатации, будет возвращением состояния ГРИС к исходному («откат» изменения). Каждый сбой в работе ГРИС, который влияет на качество обслуживания (например, приводит к отказу в обслуживании ряда пользователей), документируется. Фиксируется время начала сбоя, время его устранения, а также сервера или группы серверов, на которых были зафиксированы превышения пороговых значений. Первоочередной задачей при устранении такого сбоя (в соответствии с процессом управления сбоями) является максимально быстрое устранение его влияния на SLO. В качестве процедуры традиционно используется переключение на резервные вычислительные мощности, однако в этом случае с «пораженных» серверов продолжает поступать информация о превышении пороговых значений, которая уже не будет требовать незамедлительных действий со стороны службы эксплуатации. Полный цикл восстановительных работ здесь может занять продолжительное время, например, в случае если необходимо произвести замену вышедшего из строя оборудования. События системы мониторинга с таких серверов не имеют практического значения для службы эксплуатации; более того – они являются избыточно вредными. Отсюда целесообразным является прагматический анализ информации о превышении пороговых значений на связь с открытыми в данный момент записями о сбоях. Анализ может быть проведен посредством сопоставления списка серверов, указанных в записях о сбоях, с серверами, с которых пришло событие системы мониторинга (по аналогии с анализом на соответствие плановому изменению). Это уменьшает объем информации, который необходимо воспринять и проанализировать оператору, сокращая тем самым время реакции на сообщения, которые требуют принятия решения о выборе процедуры восстановления. ГРИС как любая система состоит из набора элементов (вычислительных машин, серверов хранения данных), связанных между собой, что можно описать с помощью графа. Связи могут быть как на физическом (наличие соединения с помощью сетевого кабеля, размещение в одной стойке ЦОД), так и на логическом (группа серверов, обрабатывающих один и тот же тип запроса) уровне. Такой граф (рис. 6) называется конфигурацией ГРИС и традиционно хранится в базе данных конфигурации (Configuration Management DataBase, CMDB) [8]. № 3–2021 Вестник СПб ун-та ГПС МЧС России http://vestnik.igps.ru 188 Труды молодых ученых Рис. 6. Пример графа конфигурации ГРИС При этом часть связей – иерархическая, к примеру: сервер системы виртуализации обеспечивает работу ряда виртуальных серверов, а одно устройство маршрутизации запросов обеспечивает связь группы серверов с остальными, размещенными в локальной сети. При выходе из строя такого «родительского» элемента также выйдут из строя и его «дочерние» элементы, в результате чего будут зафиксированы превышения пороговых значений на ряде серверов. Однако при таком сбое процедура, которая позволит восстановить работоспособность ГРИС, будет связана с воздействием на «родительский» элемент, а воздействие на «дочерние» элементы эффекта иметь не будет. Таким образом, для выбора точки приложения процедуры восстановления целесообразным является прагматический анализ событий системы мониторинга на иерархическую связь серверов, с которых эти события пришли, между собой. Таким образом, имея в каждый момент набор событий , из каждого из них может быть извлечена информация о сервере s, с которого оно пришло: . А для каждого сервера определено множество S его «родительских» серверов , являющееся подмножеством всех серверов C из конфигурации, хранящейся в CMDB. Пересечение P всех множеств и будет являться искомым общим «родительским» узлом: ∩ . Гипотетически, это поможет оператору службы эксплуатации быстрее выявить «точку отказа» и применить соответствующую процедуру устранения сбоя. В соответствии с практиками эксплуатации ГРИС, описанными в вышеупомянутых стандартах (ITIL, SRE), служба эксплуатации ведет учет всех процедур восстановления ГРИС в базе данных известных ошибок (Known Error DataBase, KEDB). Соответственно, при возникновении сообщения о сбое целесообразным является анализ этого сообщения на соответствие одной или нескольким процедурам восстановления. Производя анализ данных о состоянии серверов ГРИС, в случае превышения порогового значения система мониторинга «обогащает» исходное сообщение текстовым сообщением, предназначенным для восприятия и обработки оператором. Такими сообщениями могут быть, например, следующие: BGP connection with 206.81.80.248: is not established. Free /mnt/rclogbackup-sjc51 space < 10% Volume Usage (vol/vserver grouped by node/aggregate)-mss_dir1_6_rp/iad41-c01-efs07-svm01 SpacePercentUsed. № 3–2021 Вестник СПб ун-та ГПС МЧС России http://vestnik.igps.ru 189 Труды молодых ученых Эти сообщения могут содержать информацию о конкретном сервере и конкретном значении метрики; однако составляются системой мониторинга по определенному шаблону. Операция на соответствие сообщения шаблону может быть произведена в простейшем случае с помощью регулярных выражений [9], таких как: Free CMS memory (heap|is) .* Network partitioning is detected on .* .*Volume (Usage|.apacity) .*lg_st01.* В результате решение оператора упрощается с необходимости выбора процедуры восстановления из многих до согласия/несогласия с предложенной процедурой. Потенциально, в ряде случаев, применение процедуры восстановления может быть автоматизировано. Резюмируем предложенное выше в виде пошаговой методики прагматического анализа информации состояние «облачного» сервиса. Шаг 1. Анализ событий системы мониторинга на связь с недавними изменениями в ГРИС посредством сопоставления списка серверов, на которых производились изменения, с сервером, с которого пришло событие. Шаг 2. Анализ событий системы мониторинга на принадлежность к одному из сбоев, зарегистрированных в системе управления сбоями, посредством сравнения списка серверов, отнесенных к сбою, с сервером, с которого пришло событие. Шаг 3. Анализ событий системы мониторинга на взаимную иерархическую связь. Для этого список серверов, с которых пришли активные в данный момент события, проверяется на наличие общего «родительского» элемента в соответствии с графом конфигурации ГРИС, хранящимся в CMDB. Шаг 4. Анализ событий системы мониторинга на принадлежность к одному или нескольким процедурам восстановления ГРИС, описанным в KEDB. жүктеу/скачать 1,48 Mb. Достарыңызбен бөлісу:
|