Отчет о научно-исследовательской работе

1 Введение

2 Требования к системе мониторинга

1. 
   Гибкость собираемой информации. Для этого вводится понятие метрики. Метрика – это некая «элементарная», «неделимая» характеристика ресурса. Примерами метрик служат: количество доступных байт памяти, процент загруженности процессора, версия операционной системы, объем свободного места на диске и т. д. Кроме того, все метрики можно разделить на два класса: статические и динамические. Первые меняются медленно или не меняются вообще, вторые меняются быстро. Таким образом, механизм метрик позволяет нам четко структурировать собираемую информацию. Система должна поддерживать конфигурацию метрик: набор собираемых метрик, вид метрики (статическая или динамическая), интервал обновления и др.
   
2. 
   Универсальность относительно используемого программного окружения. Здесь, в первую очередь, речь идет о поддержке различных операционных систем, таких как:
   
   1. 
      ОС семейства Microsoft Windows NT;
      
   2. 
      ОС семейства Unix (Linux, Solaris, Mac OS, …).
      

• 
  Универсальность относительно программ, которым выдается собранная
  информация. Система мониторинга не должна быть ориентирована лишь на какое-то конкретное программное обеспечение (нельзя рассчитывать только на одну систему управления кластером, на одну службу сбора информации и т. д.). Иными словами, не должно быть зависимости от конкретных внешних интерфейсов. Конкретный интерфейс реализуется специальным модулем, добавление которого не требует изменения существующего кода системы. Написание этого модуля, как правило, не требует особых усилий.
  
• 
  Универсальность относительно систем параллельного запуска программ. Система мониторинга должна предоставлять информацию не только о загрузке системы в целом, но и о том, насколько система загружена конкретными GRID-программами. На узлах GRID приложения запускаются, как правило, с помощью средств параллельного запуска, таких как MPI, PVM, Cluster OpenMP и т. д. Для успешной работы система мониторинга должна поддерживать существующие системы. Также весьма желательно, чтобы присутствовала возможность добавления поддержки новых систем. Для того, что бы этот процесс был простым, необходим стандартный интерфейс добавления новых средств.
  
• 
  Развитая клиентская часть. Собранная информация должна быть доступна не только стороннему программному обеспечению, но также и пользователю в удобном для него виде. Иными словами, в системе должен быть предусмотрен графический клиент. Информация должна быть представлена в виде графиков и таблиц. Для удобной навигации по метрикам можно использовать дерево.
  
• 
  Анализ собранной информации. Собранную информацию можно анализировать. В результате этого можно выдавать экспертные рекомендации, советы, подсказки и т. д.
  
• 
  Доступность. Система должна быть свободно распространяемой и с открытым исходным кодом. Только в этом случае возможно оперативное устранение ошибок и добавление новых функциональных возможностей.
  

3 Анализ технических средств

1. 
   Собирает информацию о функционировании узлов СКИФ-ГРИД полигона.
   
2. 
   Хранит информацию в репозитории (MonALISA repository)
   
3. 
   Предоставляет информацию для использования другими службами (ресурс-брокер)
   

4 Портал системы мониторинг

• 
  Ресурсы сайтов СКИФ-ГРИД:
  

• 
  Занятые и доступные ресурсы:
  

• 
  Задачи в СКИФ-ГРИД:
  

5 Описание программы

5.1 Описание модулей сбора информации мониторинга из промежуточного программного обеспечения UNICORE и системы пакетной обработки заданий Cleo

• 
  Функциональное назначение:
  

• 
  Описание логической структуры:
  

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

• 
  Вызов и загрузка.
  

• 
  Входные данные.
  

• 
  Выходные данные.
  

5.2 Настройка модуля получения информации мониторинга UNICORE

1. 
   Site/Name, название сайта в системе мониторинга;
   
2. 
   Source/URL, сетевое имя сервера UNICORE и порт доступа к информационной системе (в формате host.domain:port);
   

• 
  Source/username и Source/password, имя учетной записи с правами суперпользователя в UNICORE (значение: controlRole) и пароль для авторизации по этой учетной записи;
  
• 
  разрешить доступ к файлу настроек только из учетной записи пользователя (не имеющего прав суперпользователя в ОС!), от имени которого будет выполняться код модуля мониторинга.