INTAS SimGrid Статус работ ПИЯФ,

Комментарии по модели Как мы понимаем, в текущий момент модель не учитывает работу с данными (и, соответственно, сетями). Учитывается только распределение задач и связанные с ним косвенные нагрузки (запросы к BDII). Это, с одной стороны, сильно упрощает модель, но с другой – моделирование работы с данными важно, поскольку создаёт целый класс нетривиальных событий (репликации, нагрузку на сети и т.д.) Таким образом мы предполагаем, что на данном этапе моделирования принимается постулат: любые данные мгновенно доступны любой задаче, время тратится лишь на счёт и на накладные расходы (т.е. распределение данных идеально).

Метрики, относящиеся к текущей модели (1). Поток задач к брокеру. –Выражается в задачах/сек. –Имеет ли смысл рассматривать отдельные UI как генераторы задач? Может просто исходить из входной нагрузки на брокер? Поток задач к вычислителю –Выражается в задачах/сек. Поток запросов к информационной системе –Выражается в запросах/сек. –Имеет ли смысл отделять информационную систему от брокера? Да, если одной системой будет пользоваться несколько брокеров.

Метрики, относящиеся к текущей модели (2). Скорость обработки заданий брокером. –Выражается в задачах/сек. –Имеет выражение в виде a+b*k, где a – начальная скорость обработки, k – коэффициент замедления, b – нагрузка. –Будем ли мы учитывать, что брокер отслеживает все задания до момента их завершения? Скорость обработки заданий вычислителем –Выражается в задачах/сек. –Имеет сложное значение: a, если n n max, где n – количество заданий, n max – количество слотов и a*n/n max, если n > n max. При этом a – начальная скорость обработки. Скорость обработки запросов информационной системой –Выражается в запросах/сек. –Имеет выражение в виде a+b*k, где a – начальная скорость обработки, k – коэффициент замедления, b – нагрузка. –Практика показывает (на примере CERN BDII), что скорость обработки мало зависит от количества запросов (обычно 2 – 2.5 секунды на запрос).

Метрики, относящиеся к текущей модели (3). Начальная скорость обработки (a зап./сек.) – сколько запросов (заданий) в секунду обрабатывает сервис в ненагруженном состоянии. Коэффициент замедления (k сек. -1 ) – показывает на сколько снижается скорость обработки запросов при добавлении одного нового (конкурентного) запроса (задания). Нагрузка (b зап.) – показывает количество конкурентных запросов (заданий) на данный момент времени.

Сбор данных Вычислители: –Основные данные доступны из аккаунтинга (и уже собраны в БД) нет проблем. –Возможно потребуется написать конвертер (есть прототип). Брокеры –Данные не доступны стандартным путём (в LCG не распространён мониторинг брокеров), но могут быть получены при установке сенсора на узел с RB. –Хотелось бы привлечь мониторинг НИИЯФ… –Необходимо написать дополнительное ПО (прототипа пока нет). Информационная система –Данные не доступны напрямую удобным путём, но могут быть получены при установке сенсора на узел BDII. –Необходимо написать дополнительное ПО (есть прототип).

Предоставление информации Два основных пути: 1.Набрать статистику в БД и подавать её на вход симулятора +Можно понять, насколько симуляция близка к реальной жизни -Сложно управлять входными данными 2.Набрать статистику, обработать и сосчитать основные стат. параметры, на основе которых генерировать псевдослучайный поток на входе симулятора. +Легко управлять генератором, можно получить оценки для различных типов задач и методик использования Грид -Должны быть и минусы…

Начало работ по сбору данных Первым делом нужно согласовать параметры модели У нас есть прототип сенсоров для CE (не требуется ничего никуда устанавливать) и для BDII (нужно установить на какой-то BDII. НИИЯФ ?) Работы по созданию сенсора для RB пока не завершены. НИИЯФ занимался мониторингом брокера, может что-то можно использовать? В любом случае потребуется установка сенсора на RB Сенсор на UI устанавливать не потребуется в любом случае В ПИЯФ создана БД для сбора данных, реальный мониторинг планируется начать в ближайшее время