Информационные технологии в науке, образовании и производстве ИТНОП-2010. Материалы IV-й Международной научно-технической конференции. Том 2

Подождите немного. Документ загружается.

ИТНОП-2010

УДК 658.012.011.56

Н.В. ВОЛКОВА

АВТОМАТИЗИРОВАННАЯ ПОДСИСТЕМА ПРИНЯТИЯ РЕШЕНИЯ

О НАЗНАЧЕНИИ СОЦИАЛЬНОЙ ПОМОЩИ

В данной статье рассматривается один из подходов к автоматизации процесса выбора

льгот в рамках подсистемы принятия решения АИС «ЭСРН». Представлена структура

подсистемы. Рассмотрены критерии выбора оптимального списка льгот.

Ключевые слова: автоматизация; подсистема принятия решения; социальная поддержка.

Annotation The one of approaches to automation of a privileges choice of for a subsystem of

decision-making AIS «ESRP» is considered in this paper. The subsystem structure is presented here. The

criteria of a choice of the optimum list of privileges are considered.

Keywords: automation; decision support subsystem; public assistance.

На сегодняшний день важной проблемой социальной политики государства является

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

социальную помощь в соответствии с законодательством РФ, что приводит к ее

несвоевременному и неполному назначению и выплате.

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

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

работы автоматизированной информационной системы «Электронный социальный регистр

населения» (АИС ЭСРН) субъекта РФ [1]. Структура системы представлена на рисунке 1.

Рисунок 1 – Структура АИС «ЭСРН»

IV Международная научно-техническая конференция

В соответствии с нормативными актами субъектов РФ главным критерием оказания

государственной социальной помощи является принадлежность гражданина к социально

уязвимой группе (категории). Каждой из утвержденных категорий на основании

соответствующих законов и постановлений присваивается определенный набор льгот –

преимуществ и дополнительных прав, предоставляемых определенным гражданам [2,3].

Специалистами органов социальной защиты населения (ОСЗН), являющимися

пользователями автоматизированной информационной системы ЭРСРН, осуществляется

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

решения о назначении социальной помощи по имеющимся у гражданина документам.

Проблема автоматизации принятия решения о назначении социальной помощи

состоит в выделении списка льгот гражданина, наиболее выгодных ему в финансовом и

социальном аспектах [4].

Решение указанной проблемы заключается в разработке автоматизированной

подсистемы выбора оптимального списка льгот, структура которой приведена на рисунке 2.

Рисунок 2 – Структура автоматизированной подсистемы выбора оптимального списка льгот

Пусть X = {x

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

где x

– p-ый документ этого множества. Множество нормативных документов, на основании

которых определяется множество возможных категорий, обозначим через D = {d

}, где d

–

k-ый нормативный документ этого множества.

Пусть K

– категория, к которой может принадлежать гражданин в соответствии с

набором имеющихся у него исходных документов, где

i = (1…N), N – количество общих групп категорий, установленных правительством;

j = (1…M

), M

– количество подкатегорий в i-ой общей категории.

Например, K

1,7

соответствует общей категории (i=1) «Пенсионер» и типу льготника

(j=18) «Пенсионер по потере кормильца».

Категория K

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

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

нормативного документа (законы РФ и постановления правительства), определяющего

основание для отнесения гражданина к той или иной категории льготников.

В общем случае элементу множества исходных документов ставится в соответствие

элемент множества возможных категорий, то есть:

→

f,g

– льгота, где

f = (1…T), T – количество общих групп льгот, установленных на законодательном

уровне;

ИТНОП-2010

g = (1…P

) , P

– количество конкретных льгот в группе f.

Например, L

15,1

определяет вид льготы (g = 1) «50% скидка по оплате электроэнергии»

из общей группы льгот (f = 15) «Льготы по оплате электроэнергии».

В общем случае вид предоставляемой льготы определяется в соответствии с

нормативными документами D

на основании присвоенной категории:

→

Можно сделать вывод, что каждому элементу множества видов льгот ставятся в

соответствие элементы множества категорий. На сегодняшний день одна льгота может

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

соответствии с нормативными документами может соответствовать несколько видов льгот

(связь «многие ко многим»).

Рассматривая льготы как экономический механизм решения социальных проблем

можно выделить две группы льгот: монетарные (связанные с выплатой денежного

эквивалента) и социальные (различного рода социальные блага, поощрения, преимущества).

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

f,g[монетарные]

= {О, В, К, Е, С, И},

где О – объект льготы (например, электроэнергия, вода, газ и т.д.);

В – вид возмещения льготы (например, перевод средств на банковский счет);

К – количественный параметр монетарной льготы (например, сумма возмещения,

доля уплаты и т.п.);

Е – единица измерения (например, проценты, рубли);

С – субъект льготы (например, льготник, семья льготника);

И – источник финансирования (федеральный, местный бюджет).

Подобное представление вида льготы обеспечивает возможность использования

средств автоматизации в процессе принятия решения о выборе выгодного для гражданина

списка льгот из числа причитающихся.

Исходя из того, что гражданин может относиться к нескольким категориям и,

соответственно, иметь несколько видов льгот, необходим механизм оптимизации льгот L

f,g

Оптимальный список монетарных видов льгот (q

) определяется как объединение по

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

которым принадлежит гражданин, в соответствии с законодательством РФ:

монетарныеgf

Lq }max{

][,

= .

Наравне с монетарными гражданину предоставляется набор различного рода

социальных благ, поощрений и преимуществ.

Оптимальный список льгот для категорий, которым соответствует набор только

социальных (q

) преимуществ, определяется следующим образом:

U U

K f

социальныеgfс

Lq }{

][,

= .

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

отсутствия взаимоисключающих социальных видов льгот.

Оптимальный список льгот для категорий, которым соответствует набор монетарных

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

смо

qqq =

Результатом разрабатываемой автоматизированной подсистемы выбора оптимального

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

гражданину в соответствии с законодательством РФ.

В настоящее время действующая автоматизированная информационная система

«Электронный социальный регистр населения» работает под управлением семейства

операционных систем Windows, необходимый объем оперативного запоминающего

IV Международная научно-техническая конференция

устройства не менее 64 Мбайт, используемая система управления базами данных – Microsoft

SQL Server 2005.

ЛИТЕРАТУРА

1. Электронный социальный регистр населения [Электронный ресурс]. – Реализация

информационных проектов в социальной сфере. – Режим доступа:

http://www.systematic.ru. – Систем. требования: ПК 486 или выше; 8 Мб ОЗУ; Windows 3.1

или Windows 95; SVGA 32768 и более цв.; 640х480; Internet Explorer 4.0 и выше.

2. Бойченко Е.В. О концепции создания единой автоматизированной системы

«Государственный регистр населения» /Е.В. Бойченко, В.Г. Лисицин, Л.Ф. Марин. –

Издательство «Компьюлог». – №1 (37), 2000 год.

3. Бойченко Е.В., Михеев А.В. Методология автоматизации проектирования элементов АС

ГРН. – Московский государственный институт радиотехники, электроники и автоматики,

2001 год. – 372 с.

4. Марин Л.Ф., Бойченко Е.В. Технология создания автоматизированных систем о

населении. – М: Издательство «Проспект», 2006 г. – 400 с.

Волкова Наталья Вячеславовна

Орловский государственный технический университет, г. Орел

Аспирант УНИИИТ

Тел.: + 7(4862)76-19-10

E-mail:

ns1986@yandex.ru

ИТНОП-2010

УДК 004.415.2

П.В. ДМИТРИЕНКО

ОБОСНОВАНИЕ ПОДХОДА К ПОСТРОЕНИЮ СИСТЕМЫ

ЛОКАЛЬНОГО МОНИТОРИНГА ДЛЯ ГРИД-ИНФРАСТРУКТУРЫ

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

мониторинга. В данной статье рассмотрен подход к построению ее компонента, ориентированного

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

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

разработанный для ЦИВК ОИЯИ.

Ключевые слова: мониторинг; грид; Nagios; SNMP.

The important condition of qualitative work of any grid-system is the advanced monitoring system.

This article describes the approach to construction of its important component focused on local monitoring of

services, resources and devices providing functioning of a grid-infrastructure. The working prototype of such

system, developed for JINR CICC is described.

Keywords: monitoring; GRID; Nagios; SNMP.

В текущем году в ЦЕРН (Швейцария) после завершения технических работ будет

возобновлена эксплуатация большого адронного коллайдера (БАК, LHC, Large Hadron

Collider, lhc.web.cern.ch/lhc) — самого крупного в мире ускорителя элементарных частиц.

Данный проект предполагает ежегодную генерацию около 15 Пбайт данных–результатов

экспериментов, поступающих с четырех основных (ATLAS, CMS, LHCb, ALICE) и двух

вспомогательных (TOTEM, LHCf) детекторов. Каждому экспериментальному событию

будет соответствовать получение 1-2 Мбайт данных для детекторов общего назначения и до

гигабайта для специализированного детектора ALICE. Уникальна и частота поступления

событий — 100-200 событий в секунду для каждого детектора БАК. С началом работы

ускорителя в нормальном режиме более чем 5 тысячам ученым из нескольких сотен

исследовательских институтов и университетов со всего мира будет необходим доступ

к этим экспериментальным данным, их статистике (за сроки от нескольких месяцев до

нескольких лет) и средства их анализа. Эта деятельность, включающая сравнение

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

мощностей.

Чтобы это стало возможным, в рамках проектов WLCG (Worldwide LHC Computing

GRID, lcg.web.cern.ch/LCG), EGEE (Enabling Grids for E-sciencE, public.eu-egee.org) и OSG

(Open Science Grid, www.opensciencegrid.org) разработана модель хранения и обработки

данных на базе грид-технологий. Грид представляет собой географически распределённую

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

ресурсов (процессоры, память, сети, хранилища и базы данных), доступ к которым возможен

из любой точки, независимо от места их расположения. Так, проект WLCG призван решить

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

центров, нацеленных на хранение и обработку полученной информации; в рамках проекта

EGEE осуществляется организация мировых компьютерных ресурсов в единую однородную

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

построенной в рамках этих проектов, – сообщество ученых, занимающихся физикой

высоких энергий, и на основе этого проекты часто рассматривают как единое целое,

называя интегрированную инфраструктуру EGEE/WLCG.

Центральный информационно-вычислительный комплекс (ЦИВК, CICC)

Объединенного Института Ядерных Исследований (ОИЯИ, JINR) в Лаборатории

информационных технологий (ЛИТ, LIT) объединяет несколько вычислительных кластеров с

IV Международная научно-техническая конференция

общим количеством узлов около 140. В ЛИТ создан комплекс для включения его в

инфраструктуру проекта LCG (LHC Computing Grid). На нем проводятся сеансы массового

моделирования событий для всех экспериментов, готовящихся на LHC.

Качественная система мониторинга является важным условием эффективной работы

любой грид-системы – как в силу специфики построения систем данного типа, так и по

своему вкладу в увеличение их производительности и надежности. Так, OSG (Open Science

Grid, инфраструктура грид-компьютинга США, обеспечивающая свободное сотрудничество

ученых, программистов и поставщиков компьютерных ресурсов) декларировала в своем

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

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

определения статуса серверов и хода выполнения приложения. Сюда также относится

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

устройств. Сотрудники ОИЯИ принимали участие в развитии средств мониторинга для

вычислительных кластеров с большим количеством узлов (10 тыс. и более), эти разработки

включены в создаваемую архитектуру системы глобального мониторинга GMA (Grid

Monitoring Architecture).

Существенным элементом данного процесса является локальный мониторинг – то

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

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

имеют большое значение как для сетевых администраторов, ответственных за

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

grid. В рамках программы по развитию грид-мониторинга для эффективного

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

системы локального мониторинга для нужд ЦИВК ОИЯИ.

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

1) Мониторинг оборудования, то есть отдельных компьютеров и устройств.

Осуществляется сбор и отображение данных об отдельных узлах, их аппаратном

обеспечении и ОС, сетевой доступности, загруженности процессоров и свободном дисковом

пространстве, источниках бесперебойного питания, температурном режиме.

2) Сетевой мониторинг (доступность различных сетевых устройств и служб). В

рамках ОИЯИ сюда входит сбор и отображение данных о состоянии локальной сети ЦИВК и

ЛИТ, состояние памяти и загрузка процессоров используемых маршрутизаторов,

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

маршрутизатором ЦИВК и маршрутизаторами следующего уровня; состояние внешнего

канала и доступность важнейших сетей.

3) Мониторинг сервисов, включая грид-специфичный мониторинг.

Система должна выдавать результаты своей работы единообразно и централизованно,

посредством единого веб-интерфейса, независимо от количества и способа интеграции

используемых при построении программных средств. Эти результаты могут включать

текущее состояние интересующих объектов, историю сбоев и нештатных ситуаций, графики

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

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

объектов и их состояния.

Наиболее интересным и эффективным решением является система мониторинга со

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

условиях их возникновения и методике устранения и способная использовать их для

оперативной реакции на сбои параллельно с оповещением соответствующего персонала, а

также и выявления потенциальных сбоев до их возникновения. Однако такая система может

быть довольно сложна в разработке и требует дополнительно большого объема работы для

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

ситуации. Оптимальным было бы оставить возможность дальнейшего внедрения в систему

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

ИТНОП-2010

Важное значение при выборе либо разработке системы мониторинга, в том числе

сетевого, имеет архитектура программного продукта. Это подразумевает ответы на

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

сбора информации на работу сети, серверов и отдельных служб; будут ли установлены

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

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

иерархии сети и вытекающих из нее зависимостей между различными сервисами; как и где

будут храниться обрабатываемые данные.

Функциональная декомпозиция позволяет выделить следующие составные части, в

той или иной степени характерные для любой системы мониторинга:

1) Подсистема сбора данных – осуществляет с заданной регулярностью опрос

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

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

полученных значений как нормальных, требующих вмешательства оператора либо

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

объект наблюдения какой-либо однотипной системой или сетевыми параметрами. В этом

смысле оптимальной представляется уже упомянутая архитектура – расширяемый набор

средств получения данных об объектах произвольной природы (плагинов) и центральная

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

2) Подсистема оповещения – отвечает за уведомление лиц, ответственных за

функционирование проверяемых объектов о нештатных ситуациях и иных значимых

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

сетевого мониторинга предоставляет сетевому администратору возможность выбора

режимов оповещения – вывода сообщений на консоль, привычных всплывающих

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

на пейджер, RSS-feed, сообщений по SNMP. Существуют системы мониторинга, имеющие

общий интерфейс с некоторыми популярными пакетами сетевого менеджмента.

Эти две подсистемы считаем базовыми составными частями любой системы,

ориентированной на оперативный мониторинг, направленный на оценку текущей

работоспособности и эффективности работы исследуемых объектов и немедленную реакцию

на разнообразные внештатные ситуации.

. 3) Подсистема хранения – отвечает за накопление, хранение, архивацию данных о

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

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

объема хранимой информации и т.п. Очевидно, что для успешного решения таких задач, как

поиск закономерностей в повторяющихся неисправностях, подготовка отчетов о работе

объектов за указанный период времени, построение графиков с указанными параметрами –

необходимо хранение результатов проверок в базе данных. Необходимо определить

наиболее эффективные методы для уменьшения объема базы: простейший подход –

удаление записей старше определенного срока (неактуальных), более сложный –

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

между проверками, по некоторому алгоритму.

4) Подсистема анализа данных – включает компоненты, производящие исследования

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

операции.

Эти подсистемы решают задачи, относящиеся к фоновому мониторингу,

подразумевающему систематическое долговременное накопление и анализ данных о работе

объектов.

5) Подсистема вывода – отвечает за представление информации о работе системы и

результатов проверок в виде, удобном для восприятия пользователем. Для взаимодействия с

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

IV Международная научно-техническая конференция

Рисунок 1 – Структура системы локального мониторинга

Подсистема

сбора

данных

Подсистема

оповещения

Подсистема

коррекции

Подсистема

хранения

Подсистема

анализа

данных

Подсистема

вывода

Объекты

мониторинга

Система мониторинга

Пользо-

ватель

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

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

реконфигурации системы авторизованным пользователем (администратором) – добавления

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

6) Подсистема коррекции – в том случае, если предусмотрена возможность

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

данная подсистема будет включать компоненты для выбора и осуществления подходящих

действий в соответствии с типом проблемы и другими параметрами. Логично тесное

взаимодействие ее с подсистемой анализа данных.

Взаимодействие указанных подсистем представим на рисунке 1.

Изложенные положения были взяты за основу в процессе построения системы

локального мониторинга ресурсов ЦИВК ОИЯИ. Основным программным средством,

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

с открытым кодом – Nagios. Он идеально соответствует предъявленным требованиям, легко

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

дополнений, используемых как для усовершенствования веб-интерфейса (NagiosGrapher,

Nagvis), так и для расширения возможностей самой системы (NDO2DB, RssNagios). Так,

NDO2DB включает в себя событийный брокер, экспортирующий данные Nagios в сокет либо

текстовый файл, откуда они извлекаются демоном, размещающим их в базе данных (Nagios

по умолчанию не поддерживает работы с БД). В рамках описываемой системы использована

СУБД MySQL, обеспечивающая достаточную производительность, простая в использовании

и внедрении. Определенные при конфигурации системы группы пользователей получают e-

mail извещения о критических ситуациях (реализована также рассылка по jabber).

Стандартные средства Nagios позволяют производить мониторинг таких сетевых сервисов,

как SMTP, TELNET, SSH, HTTP, DNS, POP3, IMAP, NNTP и многих других. Базовый набор

инструментов (плагинов) включает слежение за использованием ресурсов серверов, таких,

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

время архитектура «главная программа (core program) + подключаемые модули/агенты

(plugins)» позволяет, без преувеличения, осуществлять мониторинг чего угодно – при

условии разработки программного компонента (плагина), поставляющего интересующие

ИТНОП-2010

Рисунок 2 – Компоненты, используемые в построении системы

локального мониторинга

Подсистема

сбора данных

Подсистема

оповещения

Подсистема

хранения

Подсистема

вывода

Nagios

MRTG

MySQL

NAGVIS

ndo2db-

grapher

NDO2DB

Плагины

(SNMP,

PHP,Perl)

данные о необходимом объекте. Эти плагины, по сути, скрипты, реализующие требуемые

проверки, могут быть реализованы на любом удобном для этого языке: Perl, PHP, bash.

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

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

объектов, таких, как сервер БД Oracle) осуществляется посредством запроса по протоколу

SNMP (Simple Network Management Protocol – простой протокол управления сетью),

служащему для управления сетями связи на основе архитектуры TCP/IP.

Web-интерфейс системы реализован в основном на языке PHP с использованием для

разметки страниц и представления данных XHTML и Javascript. Для каждого объекта

динамически генерируется страница с данными по всем определенным для него проверкам –

текущее состояние, график значений за прошедшие сутки и некоторые другие

вспомогательные данные. Специальные ссылки позволяют открыть дополнительные окна:

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

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

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

в закрытый раздел пользователю предоставляется возможность добавления новых объектов с

указанием класса (маршрутизатор указанной фирмы (HP Procurve, Cisco), UPS, обычный

компьютер и др.), а также реконфигурации существующих сервисов (смена интервала

проверки, критических значений).

Для построения непрерывно обновляемых графиков текущего состояния объектов

используется MRTG (Multi Router Traffic Grapher) – свободное программное обеспечение под

лицензией GPL. Это инструмент для организации сервиса мониторинга и измерения сетевого

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

устройств при помощи протокола SNMP, а затем отображать в виде графиков. В основном он

используется для построения графиков загрузки каналов, нагрузки роутеров и коммутаторов.

Для функционирования MRTG необходимо указать в crontab-файле LINUX запуск его

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

качестве параметра конфигурационный файл и в соответствии с ним получать новые

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

данные для построения графиков могут извлекаться из лог-файлов nagios либо из его базы

данных (при использовании NDODB).

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

схематично изображенную на рисунке 2.

Система, разработанная в соответствии с данными выводами, в настоящее время

работает в тестовом режиме (на рисунке 3 можно увидеть пример фрагмента системной

сводки по головному маршрутизатору ЦИВК и дерево объектов).

IV Международная научно-техническая конференция

Рисунок 3 – Пример сводки, предоставляемой системой локального

мониторинга

Исследуются варианты ее расширения (как с точки зрения разнообразия

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

сервисов); взаимодействие с пользователями направлено на оптимизацию интерфейса и

выбор приоритетных направлений расширения функциональности системы: введение

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

автоматическое реагирование на возникшие сбои (подсистема коррекции);

усовершенствование веб-интерфейса, соответствующего специфике системы; расширения

множества поддерживаемых системой видов и моделей объектов.

ЛИТЕРАТУРА

1. Ильин В., Кореньков В., Солдатов А. Российский сегмент глобальной инфраструктуры

LCG / Открытые системы, №01. – 2003 г. – C. 21-23.

2. Грид-словарь. Глоссарий терминов, принятых в OSG [Электронный ресурс]: Перевод с

англ.: Бродская И.М., Корягин Д.А.,Ухов Л.В., ИПМ РАН – Режим доступа:

http://www.gridclub.ru/library/Glossary%20OSG.pdf

3. Бешков А. Создание системы сетевого мониторинга на основе Nagios / Системный

администратор, № 2. – 2003 г. – C. 6-14.

4. Barth W. Nagios System and Network Monitoring [Текст]: W. Barth / No Starch Press, 2006 г.

5. Galstad E. NDOUTILS Documentation Version 1.4. [Электронный ресурс]: Etien Galstad,

NDOUtils Documentation – Режим доступа: http://nagios.sourceforge.

net/docs/ndoutils/NDOUtils.pdf

Дмитриенко Павел Владимирович

Международный университет природы, общества и человека «Дубна», г. Дубна

Аспирант

Тел.: 8-910-261-7224

E-mail:

orelnotre@mail.ru