подробно…

Разрешение топологии WLCG-сайтов на уровне коллектора xRootD-мониторинга в Dashboard.
xRootD – это один из широко используемых протоколов передачи данных в WLCG.
Существуют две системы его мониторинга: на основе Monalisa и разработанная в Dashbord.
Они основаны на получении сырой информации из UDP-пакетов, которые постоянно
создаются xRootD серверами. Затем информация агрегируется и выводится в виде графиков,
гистограмм и таблиц на соответствующих веб-страницах. Эта информация позволяет
администраторам Grid-сайтов следить за интенсивностью потока информации, проходящего
по протоколу xRootD. Также эта информация даёт представление о вкладе каждого сайта в
процесс обработки данных LHC.
Большой трудностью в процессе агрегации сырых данных является определение
имени сайта источника и сайта назначения передачи. В UDP-пакетах содержится лишь имя
хоста и имя домена. Зная их, в большинстве случаев можно определить, с какого сайта на
какой осуществлялась передача. Иногда определить название сайта не представляется
возможным, тогда считается что имя сайта «n/a» («not available»).
Задача построения топологии сайтов WLCG не является тривиальной. До сих пор не
существует единого сервиса, позволяющего определить, к какому сайту относится тот или
иной домен и хост. Основной трудностью в создании подобной системы является
необходимость собирать данные из множества разных источников, а также необходимость
следить за изменениями и появлениями новых топологических имён. Хорошим примером
системы с требуемой функциональностью является сервис AGIS, однако он работает только с
сайтами ATLAS..
Со временем было принято решение дать возможность xRootD-серверам самим
указывать имена сайтов: добавилось ещё одно поле — SERVER_SITE. Для системы
мониторинга xRootD в Dashboard, написанной на языке Python, потребовалось использовать
это поле, если оно присутствует (у 1% всех сообщений это поле пустое. В Dashboard
изначально хранились данные, агрегированные только по доменам и хостам, что не
позволяло использовать поле SERVER_SITE. Имена у сайтов появлялись только на уровне
пользовательского интерфейса (веб-страницы). Это вносило неприятную погрешность в
результаты мониторинга.
Решение данной задачи потребовало изменить коллектор (программу, которая вносит в
базу данных Oracle сырые данные). Если раньше коллектор служил только посредником
между очередью сообщений и базой данных, то после обновления он сам определял имя
сайта на основе доменного имени и имени хоста. Это используется, прежде всего, для того
чтобы присвоить имена сайтов клиентам, так как они пока не могут предоставить их сами.
Очень важным шагом стало использование на уровне пользовательского интерфейса не
только доменного имени, как это было раньше, но и имени хоста, что очень важно для сайта
IN2P3.
Следующее изменение коснулось базы данных Oracle. Её модификация, тестирование
и валидация отняли большую часть времени. Вся агрегация по 10-ти минутным периодам и
дневным периодам осуществляется средствами PL/SQL и DBMS_Scheduler базы данных
Oracle. Подобная архитектура при больших нагрузках является «узким местом»
(«bottleneck») для всей системы, создавая задержку на пользовательском интерфейсе. Сейчас
активно ведётся многообещающая работа по изучению таких технологий как Hadoop и
MapReduce для выполнения задачи агрегации по временным периодам. Последним
изменения затронули пользовательский интерфейс. Потребовалось избавится от такой
функциональности, как трансляция домена в GocDB-имя и GocDB-имени в VO-имя.
Во время визита в CERN была завершена работа по обновлению системы
мониторинга xRootD Dashboard для эксперимента CMS, а также начата работа по
обновлению системы мониторинга xRootD Dashboard для эксперимента ATLAS. Также были
созданы инструкции, которые помогут другим специалистам закончить эту работу в
кратчайшие сроки.