EGEE – технологический рывок к построению Грид инфраструктуры для науки

1. EGEE – технологический рывок к построению Грид инфраструктуры для науки В.А. Ильин (НИИЯФ МГУ), В.В. Кореньков (ОИЯИ), А.А. Солдатов (РНЦ КИ) От имени РДИГ – консорциума «Российский грид для интенсивных операций с данными» НИВЦ МГУ, 5 апреля 2005

2. О проекте EGEE EGEE – Enabling Grids for E-sciencE создание глобальной инфраструктуры типа грид для распределенных вычислений и интенсивных операций с данными в научных исследованиях EGEE – проект EC FP6 с бюджетом 31 M€, апрель 2004 – апрель 2006 ( 2009), 70 партнеров (контракторов) из 30 стран (Европа, США, Россия), более 30 ассоциированных партнеров EGEE – создание грид инфраструктуры (SA1), Gridvs Networking (SA2), разработка/развитие MW (JRA):Globus2+Condor+EDG+…, создание грид-приложений (NA4), обучение (NA3), dissemination(NA2) 50% 25% 25% EGEE сейчас – более 1000 членов коллаборации, более 100 сайтов, ~10 прикладных областей, в инфраструктуре более 10000 CPU и более 5 Pbyte данных

3. РДИГ РДИГ – Российский грид для интенсивных операций с данными 8 институтов-участников инфраструктурного проекта EGEE: ИФВЭ (В.Петухов), ИТЭФ (В.Гаврилов), РНЦ КИ (А.Солдатов), ИПМ РАН (Д.Корягин), ИМПБ РАН (В.Лахно), ПИЯФ РАН (Ю.Рябов), НИИЯФ МГУ (А.Крюков), ОИЯИ (В.Кореньков) РДИГ – национальная федерация в проекте EGEE (всего 12 федераций): В.Ильин – член EGEE Project Management Board, годовой бюджет 0.5 M€ + российское паритетное финансирование (ФЦНТП+Росатом) РДИГ – создание российского сегмента глобальной инфраструктуры EGEE: участие в SA1 (все 8 институтов), SA2 (РНЦ КИ), NA2-NA4 РДИГ - полнофункциональная грид инфраструктура – российский грид для науки, также и как полигон для российских разработок в этой области. РДИГсейчас – более 100 членов коллаборации, (~) 10 сайтов, 3 (+3) прикладных областей, в инфраструктуре более 300 CPU и ~50 Tbyte данных Грид – ОК Ресурсы - проблема

4. Мониторинг EGEE http://goc.grid-support.ac.uk/gridsite/gocmain/

5. Operations (SA1, SA2) Management

6. Структурные элементы • CIC – Core Infrastructure Center • Обеспечение функционирования базовых грид сервисов 24х7НИИЯФ МГУ • Мониторинг и реагирование на черезвычайные ситуацииОИЯИ • Ведение учета ресурсов и выполненных работ (accounting)НИИЯФ МГУ, ОИЯИ • Управление и поддержка виртуальных организацийНИИЯФ МГУ • Поддержка безопасности инфраструктуры, CAРНЦ КИ • Сертификация (валидация) грид ПОИПМ РАН • ROC – Regional Operations Center • ИФВЭ, ИТЭФ (user support), ИПМБ РАН, ПИЯФ • RC – Resource Center (8++) • VO – Virtual Organization • физика высоких энергий:LHC – ATLAS, ALICE, CMS, LHCb; PHOTON, … • биомед (ИМПБ РАН ++ EGEE) • российские VOs: e-Earth (геофизика - ИФЗ и ГЦ РАН), fusion (РНЦ КИ ++), химфизика (Черноголовка, МГУ ++), МГУгрид (НИВЦ, НИИЯФ, ин-т Белозерского, ++), ++

7. РДИГ инфраструктура ЦБГС (CIC) РОЦ (ROC) Регистрация ВО CA Поддержкапользователей Регистрацияпользователей Поддержка РЦ Мониторинг Регистрацияновых РЦ Группа дежурныхпо EGEE Ресурсные центры Базовые сервисы ... JINR SINP ITEP IHEP MyP ... BDII RLS RB

8. РДИГ SA1 Distributed ROC https://edms.cern.ch/file/479460/4/EGEE-SA1-ExecPlan-RU-v1.6.pdf IHEP, plus some functions provided by ITEP (user support), JINR (operational monitoring), IMPB RAS and PNPI: - serve 8 RCs, 5 new RCs to appear in next 3 months and next 5 to the end of 2005 - support RDIG SA1 managers http://mail.ihep.ru/Lists/roc_support/List.html - MW repository http://grid-cvs.ihep.su - user support http://ussup.itep.ru - GridIce serverhttp://lcfgmon.itep.ru/gridice Distributed CIC - preparing to start in April 2005 (TA) Now some core servces are 8x5 supported (preparing to 24x7): - RB, IS, RC, MyProxy, (regional) VO management (SINP MSU) - Grid monitoring and accounting (JINR) - CA (SINP MSU -> RRC KI), today about 300 (active) certificates, http://lcg20.sinp.msu.ru/CA/ - MW validation and documentation localization (KIAM RAS), http://www.gridclub.ru

9. CIC-on-duty

10. CIC-on-duty (прод.) • Оперативная группа дежурных постоянно наблюдает за определенными параметрами. • Наблюдение за списком рассылки LCG-ROLLOUT и реагирование на оперативные проблемы. Список должен проверяться каждый час. • Окно браузера должно быть открыто на странице монитора GIIS (GIIS Monitor), и дежурные должны наблюдать за сайтами, выпадающими из информационной системы. В случае появления подобного сайта проверка файла истории (history of published values) может показать является ли проблема временной или имеет место нарушение работоспособности сайта. При необходимости связь с администраторами сайта. Эта проверка не реже, чем каждые 2 часа. • Один раз в день проверка протокола монитора GIIS (GIIS Monitor reports) с точки зрения противоречий и отсутствующих сервисов. http://egee.sinp.msu.ru

11. CIC-on-duty (прод.) • Окно браузера должно быть открыто на странице монитора выполняемых заданий (Live Job Monitor). Обнаружение симптомов подозрительного поведения (группы незавершенных задач, большое количество задач в очереди на каком-то отдельном сайте и т.п.). Просматривать этот дисплей каждые 30 минут. • Приблизительно в 10:30 просмотреть отчеты о работе сайтов (Site Test Reports) и сравнить их с задачами в системе слежения "Саванна" (Savannah tracking system). В случае получения результата, следует повторить тесты для определенных сайтов. • Утром проверка монитора истечения сертификатов (Certificate Lifetime Monitor) и принятие мер, если видны сайты с сертификатом, истекающим в течение недели. • Наблюдение за монитором задач Главного оперативного центра (GOC Job Monitor) (проверка несколько раз в день). • Приняв дежурство от предыдущей оперативной группы, просмотр сборников часто задаваемых вопросов и руководства по устранению неисправностей (FAQs and Troubleshooting Guides). • В начале дежурства ознакомление со списком задач, к которым должна быть применена процедура эскалации. • Действия в начале и конце дежурства должны быть основаны на ежедневных отчетах, получаемых с сайта Главного оперативного центра (https://cic.in2p3.fr).

12. ЦБГС (CIC): ИПМ РАН • Сертификация (валидация) грид ПО • Локализация документации на русский язык.

13. FS FS DBII RLS FS FS Запуск заданий в грид Site RB UI CE WN SE UI – Интерфейс пользователя RB – Брокер ресурсов BDII – Информационная база данных по ресурсам RLS – Сервер реплик файлов CE – Компьютерный элемент SE – Элемент хранения данных WN – рабочая нода FS – файловый сервер MyProxy – сервер продление действия сертификата пользователя Site CE WN SE

14. FS FS DBII RLS FS FS Запуск заданий в грид Site RB UI CE WN SE Site CE UI – Интерфейс пользователя RB – Брокер ресурсов BDII – Информационная база данных по ресурсам RLS – Сервер реплик файлов CE – Компьютерный элемент SE – Элемент хранения данных WN – рабочая нода FS – файловый сервер WN SE

15. FS FS DBII RLS FS FS Запуск заданий в грид Site RB UI CE WN SE Site CE UI – Интерфейс пользователя RB – Брокер ресурсов BDII – Информационная база данных по ресурсам RLS – Сервер реплик файлов CE – Компьютерный элемент SE – Элемент хранения данных WN – рабочая нода FS – файловый сервер WN SE

16. FS FS DBII RLS FS FS Запуск заданий в грид Site RB UI CE WN SE Site CE UI – Интерфейс пользователя RB – Брокер ресурсов BDII – Информационная база данных по ресурсам RLS – Сервер реплик файлов CE – Компьютерный элемент SE – Элемент хранения данных WN – рабочая нода FS – файловый сервер WN SE

17. FS FS DBII RLS FS FS Запуск заданий в грид Site RB UI CE WN SE Site CE UI – Интерфейс пользователя RB – Брокер ресурсов BDII – Информационная база данных по ресурсам RLS – Сервер реплик файлов CE – Компьютерный элемент SE – Элемент хранения данных WN – рабочая нода FS – файловый сервер WN SE

18. FS FS RLS BDII FS FS Запуск заданий в грид Site RB UI CE WN SE Site CE UI – Интерфейс пользователя RB – Брокер ресурсов BDII – Информационная база данных по ресурсам RLS – Сервер реплик файлов CE – Компьютерный элемент SE – Элемент хранения данных WN – рабочая нода FS – файловый сервер WN SE

19. Computing Resources: Feb 2005 • Country providing resources • Country anticipating joining • In LCG-2: • 113 sites, 30 countries • >10,000 cpu • ~5 PB storage • Includes non-EGEE sites: • 9 countries • 18 sites

20. Infrastructure metrics Countries, sites, and CPU available in EGEE production service EGEE partner regions Other collaborating sites

21. Service Usage • VOs and users on the production service • Active HEP experiments: • 4 LHC, D0, CDF, Zeus, Babar • Active other VO: • Biomed, ESR (Earth Sciences), Compchem, Magic (Astronomy), EGEODE (Geo-Physics) • 6 disciplines • Registered users in these VO: 500 • In addition to these there are many VO that are local to a region, supported by their ROCs, but not yet visible across EGEE • Scale of work performed: • LHC Data challenges 2004: • >1 M SI2K years of cpu time (~1000 cpu years) • 400 TB of data generated, moved and stored • 1 VO achieved ~4000 simultaneous jobs (~4 times CERN grid capacity) Number of jobs processed/month

22. Current production software (LCG-2) • Evolution through 2003/2004 • Focus has been on making these reliable and robust • rather than additional functionality • Respond to needs of users, admins, operators • The software stack is the following: • Virtual Data Toolkit • Globus (2.4.x), Condor, etc • EU DataGrid project developed higher-level components • Workload management (RB, L&B, etc) • Replica Location Service (single central catalog), replica management tools • R-GMA as accounting and monitoring framework • VOMS being deployed now • Operations team re-worked components: • Information system: MDS GRIS/GIIS  LCG-BDII • edg-rm tools replaced and augmented as lcg-utils • Developments on: • Disk pool managers (dCache, DPM) • Not addressed by JRA1 • Other tools as required: • e.g. GridIce – EU DataTag project

23. The deployment process • Key point – a certification process is essential • However, it is expensive (people, resources, time) • But, this is the only way to deliver production quality services • LCG-2 was built from a wide variety of “research” quality code • Lots of good ideas, but little attention to the “mundane” needs of production … • Building a reliable distributed system is hard – • Must plan for failure, must provide fail-over of services, etc • Integrating components from different projects is also difficult • Lack of common standards for logging, error recovery, etc

24. SA1 – Operations Structure • Operations Management Centre (OMC): • At CERN – coordination etc • Core Infrastructure Centres (CIC) • Manage daily grid operations – oversight, troubleshooting • Run essential infrastructure services • Provide 2nd level support to ROCs • UK/I, Fr, It, CERN, + Russia (M12) • Taipei also run a CIC • Regional Operations Centres (ROC) • Act as front-line support for user and operations issues • Provide local knowledge and adaptations • One in each region – many distributed • User Support Centre (GGUS) • In FZK – manage PTS – provide single point of contact (service desk) • Not foreseen as such in TA, but need is clear

25. RC RC RC RC ROC RC RC RC RC RC ROC RC RC RC CIC CIC RC ROC RC CIC OMC CIC CIC CIC RC RC RC ROC RC RC RC Grid Operations • The grid is flat, but • Hierarchy of responsibility • Essential to scale the operation • CICs act as a single Operations Centre • Operational oversight (grid operator) responsibility • rotates weekly between CICs • Report problems to ROC/RC • ROC is responsible for ensuring problem is resolved • ROC oversees regional RCs • ROCs responsible for organising the operations in a region • Coordinate deployment of middleware, etc • CERN coordinates sites not associated with a ROC RC = Resource Centre

26. Summed CPU (Seconds) consumed by resources in selected Region Accounting menu may be used to select different views of the data Accounting views Select date range Select VOs (Default = All) Web form to apply selection criteria on the data Aggregate data across an organisation structure (Default= All ROCs)

27. Best practice Guides Policy – Joint Security Group Incident Response Certification Authorities Audit Requirements Usage Rules Security & Availability Policy Application Development & Network Admin Guide User Registration http://cern.ch/proj-lcg-security/documents.html

28. gLite Services for Release 1Software stack and origin (simplified) • Computing Element • Gatekeeper (Globus) • Condor-C (Condor) • CE Monitor (EGEE) • Local batch system (PBS, LSF, Condor) • Workload Management • WMS (EDG) • Logging and bookkeeping (EDG) • Condor-C (Condor) • Storage Element • File Transfer/Placement (EGEE) • glite-I/O (AliEn) • GridFTP (Globus) • SRM: Castor (CERN), dCache (FNAL, DESY), other SRMs • Catalog • File and Replica Catalog (EGEE) • Metadata Catalog (EGEE) • Information and Monitoring • R-GMA (EDG) • Security • VOMS (DataTAG, EDG) • GSI (Globus) • Authentication for C and Java based (web) services (EDG)

29. Main Differences to LCG-2 • Workload Management System works in push and pull mode • Computing Element moving towards a VO based scheduler guarding the jobs of the VO (reduces load on GRAM) • Distributed and re-factored file & replica catalogs • Secure catalogs (based on user DN; VOMS certificates being integrated) • Scheduled data transfers • SRM based storage • Information Services: R-GMA with improved API and registry replication • Prototypes of additional services • Grid Access Service (GAS) • Package manager • DGAS based accounting system • Job provenance service • Move towards Web Services

30. Standards • Web Services Fast moving area • Follow WSRF and related standards but are not early adopters • WS-I compatibility is a target • Challenging to write WSDL which is WS-I compatible AND can be processed by all the tools • Industry strength tooling not always available • Trying to keep back from the bleeding edge • Work on standards bodies • Active contributions to • GGF OGSA-WG • GMA in OGSA • Data Design team • GGF INFOD-WG • OASIS WS-N • GGF GSM-WG (SRM) • Co-chairing WG • Replica Registration Service • And following many, many others • Adopting mature standards is a goal

31. Release Timeline First public nightly build (B 39) RC1 (I20041217 B 151) Release 1.0 Builds First automated build (B 1) First Integration build (I20041020 B 80) RC1 (I20050204 B 206) VOMS, Site Configuration AliEn, R-GMA Prototype Available to ARDA users I/O Client I/O Server Data Local Transfer Service, Single Catalog CE, LB, WMS, WN Functionality May 2004 June 2004 July 2004 Aug 2004 Sep 2004 Oct 2004 Nov 2004 Dec 2004 Jan 2005 Feb 2005 March 2005 April 2005 Today

32. RDIG in MW evaluation and testing Testing/adaptation MW components (SA1): IHEP, PNPI, JINR IHEP will participate in the pre-production testing/adaptation of gLite (SA1) Testing new MW components (NA4 ARDA): - Metadata catalog,Fireman catalog, gridFTP, ... (JINR, SINP MSU) - testing gLite for ATLAS and CMS (PNPI, SINP MSU) EGEE work plan : January-March 2005: evaluation OMII (JINR, KIAM RAS) April-October 2005: evaluation GT4 (SINP MSU, JINR, KIAM RAS)

33. SINP MSU+ INFN (Padua)new mw - improved job flow CERN-INTAS meeting, 14 March 2005, CERN

34. SINP MSU: new mw - monitoring of application jobs • No LCG MW modification required (wrappers + additional server); • Access to the intermediate job output via Web-interface; • Authorization is based on the standard GSI certificates and proxy certificates • Starting Web-page for interested users (with instructions): http://grid.sinp.msu.ru/acgi-bin/welcome.cgi CERN-INTAS meeting, 14 March 2005, CERN

35. New MW: JINR, KIAM RAS, SINP MSUOGSA/Globus evaluation for data intensive applications • Based on the experience with OGSA/GT3 evaluation in 2003-2004 (T. Chen et al. “OGSA Globus Tolkit Evaluation Activity at CERN”, in Proc. of ACAT03, NIMA 534 (2004) 80) • Release of the Globus Toolkit 4 is currently scheduled for April 29, 2005 www-unix.globus.org/toolkit/docs/development/4.0-drafts/GT4Facts • Therefore: testing/evaluation of other OGSA/WS systems potentially interesting for LCG/EGEE CERN-INTAS meeting, 14 March 2005, CERN

36. Testing the OMII basic functionality (KIAM RAS+JINR): • Applications must be pre-installed on the (Job Service) server; an execution of programs prepared on client side is impossible. • No such core services like RB, IS, RC • Management of (grid) accounts is not well scalable, not well suitable for management of large dynamic VOs • Clients must be installed for each user separately (e.g., not under root) • Failed to deploy a new custom service into the OMII container • Report was submitted to JRA1 and OMII Support • The OMII 1.1.1 Job service was found to be robust in a test with 20 concurrent clients • The maximal job submission rate ~ 6 jobs/min • no bulk batch mode for job submission --> problem for submitting large number of jobs • The Data Service was found to work stable with up to 5 concurrent clients and a file size of up to 10MB (no tests beyond this limits yet). CERN-INTAS meeting, 14 March 2005, CERN

37. Re-Certify CIC Release Release Client Release Deploy Client Releases (User Space) 11 GIS Deploy Major Releases (Mandatory) Deploy Service Releases (Optional) ROCs RCs CICs RCs New Deployment – new CIC/ROC YAIM Release(s) Update Release Notes Update User Guides EIS GIS Every 3 months on fixed dates ! User Guides Release Notes Installation Guides Every Month Certification is run daily Every Month at own pace

38. gLite • Differences • Unit and functional testing already performed by JRA1 • Releases have to be synchronized between JRA1, SA1 based on NA4’s priorities • New Sequence • Certification Testbed (CERN) • Installation/config tests • Rerun functional tests (to validate configuration) • Synthetic stress tests • Preproduction Service • Sites • Krakow, FZK, IN2P3, CNAF, Padua, Bari, NIKHEF, SNIC, Protvino-IHEP, UOM, LIP, PIC, RAL • sites test installation and configuration • Applications test by using their production software and give feedback on reliability and functionality • Status • Documentation of process is in draft state • Certification Testbed • gLite pre-release installed • Preproduction Service • Sites are installing current LCG2 release as a platform for the gLite components • Porting of tests and collection of existing tests (JRA1, NA4, ARDA) started

39. SA2 (РНЦ КИ): Проблемы организации интерфейса взаимодействия EGEE-NRENs • Ограничения «типичного» НОКа: • Разрешение проблем внутри собственного административного домена • Собственная схема взаимодействия с пользователями • Сложность сетевой инфраструктуры • Большое количество ресурсных центров, подключенных к разным сетям • Большое количество НОКов со своими схемами взаимодействия • Новые сетевые сервисы • Необходимо создать службу для решения сетевых проблем, связанных с деятельностью EGEE – ENOC

40. SA2 (РНЦ КИ): Схема решения сетевых проблем https://edms.cern.ch/document/503527 ENOC Helpdesk NREN NREN RC RC

41. Участники процесса интеграции VO • Совет по развитию РДИГ • В.А. Ильин - координатор проекта РДИГ • Е.А. Тихоненко (NA4) - ответственная за взаимодействие прикладных областей с инфраструктурой РДИГ • А.П. Демичев - ответственный за технические аспекты регистрации и поддержки работы ВО • Центр базовых грид-сервсов (ЦБГС, А.П.Крюков): • Настройка базовых сервисов (Шамардин) • Поддержка сайта регистрации пользователей и БД ВО (Демичев) • Региональный операционный центр (РОЦ, Ю.А.Лазин): • помощь в инсталляции и поддержка UI • поддержка пользователей новой VO • Менеджер создаваемой VO. • Ресурсные центры РДИГ

42. Процесс создания с точки зрения VO • Инструкция на rdig-registrar.sinp.msu.ru/newVO.html: • Выбор имени VO. • Регистрация VO в Совете по вопросам развития РДИГ: • Меморандум о взаимопонимании; • Ответы на вопросник (информация о кандидате в VO) • Формирование первоначального состава VO • регистрации пользователей - членов VO на rdig-registrar.sinp.msu.ru • Интеграция новой VO в грид-инфраструктуру РДИГ • переговоры с менеджерами ресурсных центров (РЦ) о допуске новой организации к использованию их ресурсов

43. Меморандум о взаимопонимании между СР-РДИГ и VO • Представители VO • ФИО руководителя новой VO • для текущих орг. и технических контактов с РДИГ • В частности, вопросы включения новых пользователей в члены в VO • получающие право установки программного обеспечения VO в РЦ (software managers group) • VO обязуется строго следовать «Правилам использования … РДИГ», … содействовать предупреждению и ликвидации последствий случаев, представляющих угрозу безопасности … • РДИГ: максимальное предоставление ресурсов в рамках возможностей и локальной политики РЦ

44. (первая новая) VO в РДИГ • RGStest – для тестирования РДИГ • eEarth – задачи геофизики и космических исследований, • в частности, интерактивная картография и визуализация научных данных в Интернет = задачи хранения геофизической информации на параллельном кластере баз данных, интерактивного поиска событий в окружающей среде, и совместной интерактивной визуализации карт (есть более подробное описание задачи – кто будет анализировать?) • В рамках международных проектов • Space Physics Interactive Data Resource (SPIDR) и • Integrated Distributed Environmental Archive System (IDEAS), • входящих в программу Президиума РАН «Электронная Земля» • на базе Геофизического центра и Института физики Земли РАН • Руководитель VOeEarth - зав. лаб. ИФЗ и ГЦ РАН М.Н. Жижин. • Численность VO в течение ближайшего года ~ 10

45. Намерение организации, проекта и т.п. создать VO для использования ресурсов РДИГ Веб-страница rdig-registrar.sinp.msu.ru/newVO.html, документ «Создание и регистрация ВО в рамках инфраструктуры РДИГ: правила и процедура», образец «Меморандума о взаимопонимании» и «Вопросник для кандидата на создание ВО РДИГ» Подготовка менеджером VO Меморандума и информации о VO по пунктам Вопросника Тихоненко, Демичев знакомятся с информацией о кандидате в VO РДИГ, представляют информацию Ильину; Ильин одобряет/отклоняет/редактирует Меморандум От-каз На основе решения СР-РДИГ + ЦБГС + РОЦ Демичев готовит мотивиро-ванный отказ и направляет заявителям Положительное решение Регистрация новой VO На основе информации + Меморандума СР-РДИГ совместно с Крюковым (ЦБГС) и Лазиным (РОЦ) принимают решение о начале процедуры регистрации или отклонении заявки

46. ЦБГС (Крюков): - конфиг. базовых сервисов (Шамардин); - конфиг. сервера ВО (Демичев); - тех. поддержка менеджмента VO = база VO, регистрация членов VO (Демичев) РОЦ (Лазин) - помощь в инсталляции и поддержка UI - поддержка пользователей новой VO NA4 (Тихоненко): - на основании информации от VO (ответы на Вопросник) подбирает список РЦ, удовлетворяющих требованиям VO - предоставляет этот список (с координатами менеджеров РЦ) и образец Соглашения VO↔РЦ менеджеру новой VO Менеджер новой VO и менеджеры РЦ ведут переговоры и заключает соглашения между РЦ РДИГ и VO об обслуживании VO Интеграция новой ВО

47. Вместо заключения: • РДИГ (+EGEE) – грид инфраструктура для научных исследований • приглашаем новые прикладные области (VO) • РДИГ (+EGEE) – технологический полигон для • изучения существующего MW • тестирования/развития нового MW • новых архитектурных и инфраструктурных разработок • приглашаем российских разработчиков MW